Développement d'application rapide GEF492A Automne 2014 [HvV § 3.2.3]

Présentation au sujet: "Développement d'application rapide GEF492A Automne 2014 [HvV § 3.2.3]"— Transcription de la présentation:

1 Développement d'application rapide GEF492A Automne 2014 [HvV § 3.2.3]
GEF Développement d'applications rapide Automne 2013 Développement d'application rapide GEF492A Automne 2014 [HvV § 3.2.3] Capt Vincent Roberge Collège Militaire Royal du Canada Génie électrique et génie informatique roberge.segfaults.net PPL04-DevelopmentApplicationsRapide.pdf Sylvain P. Leblanc

2 GEF492 - 04 Développement d'applications rapide
Automne 2013 Aperçu Développement d'applications rapide (Rapid Application Development – RAD) Ateliers joint Triage des exigences Construction par SWAT Team Variantes au RAD Méthode de développement de systèmes dynamique - DSDM) Principes DSDM Processus DSDM Automne 2014 GEF492 Sylvain P. Leblanc

3 Développement d'applications rapide (Rapid Application Design -RAD)
GEF Développement d'applications rapide Automne 2013 Développement d'applications rapide (Rapid Application Design -RAD) RAD a beaucoup en commun avec autres modèles de processus de développement: Implication de l'utilisateur Prototypage Réutilisation Utilisation d'outils automatisés Petite équipe de développement L'élément le plus important du RAD est la boîte horaire Lapse de temps fixe dans lequel les activités doivent être complétées Avec RAD, on décide du lapse de temps tout d'abord, et le projet essaie de réaliser le plus d'exigences possibles This differs from traditional models which fix the requirements (mostly) and try to develop them in the allotted time. Automne 2014 GEF492 Sylvain P. Leblanc

4 Phases du cycle de vie RAD
GEF Développement d'applications rapide Automne 2013 Phases du cycle de vie RAD Boîte horaire Planification Des exigences Design de l' application Construction It appears to be Waterfall-like in that phases occur sequentially Transfert Automne 2014 GEF492 Sylvain P. Leblanc

5 Ateliers joints Les deux premières phases utilisent des ateliers joints Joints puisque les développeurs et les utilisateurs potentiels travaillent ensemble Ceci implique qu'on peut seulement utiliser RAD quand il est possible d'identifier les utilisateurs potentiels (et d'obtenir leur participation) Difficile pour les projets menés par le marché Automne 2014 GEF492

6 Phase 1 – Planification des exigences
GEF Développement d'applications rapide Automne 2013 Phase 1 – Planification des exigences La planification des exigences a lieu pendant un atelier d'exigences joint (Joint Requirements Planning - JRP ). Le but est d'obtenir les bonnes exigences, dès le début. Est-ce réaliste? Get them to discuss how likely this is to happen … Only in cases where the problem space is very well understood and the user is able to help clearly state the requirements. Automne 2014 GEF492 Sylvain P. Leblanc

7 GEF492 - 04 Développement d'applications rapide
Automne 2013 Triage des exigences Comme il est très improbable que toutes les exigences seront implémentées dans la boîte horaire, on fait triage. Otis Historical Archives Nat'l Museum of Health & Medicine RAD fait le triage avec MoSCoW: Requises (Must haves) – définitivement nécessaires Désirables (Should haves) – importantes, mais pas absolument nécessaires Possibles (Could haves) – si le temps le permet Rejetées (Won't haves )– poussées à la prochaine itération Library system: Must haves: borrow, return an item, enrol as a member Should haves: reserve an item Could haves: handling fines for late items Won't haves: profile users and notify them of new arrivals Automne 2014 GEF492 Sylvain P. Leblanc

8 Phase 2 –Design d'application
GEF Développement d'applications rapide Automne 2013 Phase 2 –Design d'application Le design est typiquement accomplit par deux ateliers de design joints (Joint Application Design – JAD) Premier atelier JAD produit un design initial du système et un prototype avec lequel l'utilisateur expérimente Deuxième atelier JAD évalue le prototype afin d'y faire des améliorations et de finaliser le design Pour de petits projet, on peut combiner les ateliers JRP et JAD Les JRP et JAD durent habituellement moins de deux mois Put that timeframe into context using eProps: about the same sized team, same Time Box, but you are working part-time. Automne 2014 GEF492 Sylvain P. Leblanc

9 GEF492 - 04 Développement d'applications rapide
Automne 2013 Phase 3 - Construction Le système est construit par une équipe SWAT Plus de détails pendant la séance 15 Organisations d'équipes L'équipe SWAT construit plusieurs prototypes (chacun étant évalué par les utilisateurs) pendant la boîte horaire On élimine des exigences si on manque de temps L'horaire doit appartenir à l'équipe SWAT Nécessaire étant donné l'horaire très compressé This will be the same for you in eProps – you will estimate Automne 2014 GEF492 Sylvain P. Leblanc

10 Phase 4 - Transfert Il n'y a plus grand-chose à dire …
Tests finaux du système Entrainement des utilisateurs Installation du système Automne 2014 GEF492

11 Dynamic System Development Method
GEF Développement d'applications rapide Automne 2013 Dynamic System Development Method La méthode de développement de systèmes dynamique (Dynamic System Development Method - DSDM) utilise le RAD Cadriciel de développement agile à buts non-lucratifs On doit devenir membre pour obtenir les détails Discussed as RAD in action Automne 2014 GEF492 Sylvain P. Leblanc

12 GEF492 - 04 Développement d'applications rapide
Automne 2013 Principes du DSDM Implication active de l'utilisateur L'équipe doit être investie de pouvoir décisionnel On met l'emphase sur la livraison de produits fréquente Le critère essentiel pour l'acceptation d'artefacts est la convenance Les processus itératifs et incrémentiels sont nécessaires afin de converger vers une solution d'affaire exacte No need to go into details; just trying to make paralells with other iterative/incremental development processes Automne 2014 GEF492 Sylvain P. Leblanc

13 Principes du DSDM (suite)
Les changements pendant le développement sont réversibles On fixe les exigences à la ligne de base à un haut niveau Les tests sont intégrés au travers du cycle de vie Une approche collaborative et coopérative entre les parties prenantes est essentielle Automne 2014 GEF492

14 GEF492 - 04 Développement d'applications rapide
Automne 2013 Processus DSDM Études de faisabilité Demande habituellement: "est-ce que la solution est faisable"? DSM demande aussi: "est-ce que DSDM est approprié pour ce projet"? Étude d'affaire Description des processus d'affaires à haut-niveau Utilise des ateliers joints Produit une ligne de base de haut-niveau des exigence et de l'architecture Itération de modèles fonctionnels Produit des modèles d'analyse, prototypes et implémentation de composantes fonctionnelles majeurs Chaque itération dure de 4 à 6 semaines, pendant laquelle on décide "qu'est-ce" qu'on construit Can we identify users of the system? Requirements must be known up front. Project should be small enough Automne 2014 GEF492 Sylvain P. Leblanc

15 Processus DSDM (suite)
Design et construction On fait le design du système au standard approprié Utilise également une boîte horaire de 4 à 6 semaines L'emphase est sur la construction d'un système bien mis au point Implémentation On transporte le système chez le client On fait l'entraînement de l'utilisateur Automne 2014 GEF492

16 Le Rational Unified Process
Prochaine séance: Le Rational Unified Process Automne 2014 GEF492