Différences

Cette page vous donne les différences entre la révision choisie et la version actuelle de la page.

m2ilc:qualite_2 [2010/11/12 10:49]
suitable
m2ilc:qualite_2 [2010/11/12 12:19] (Version actuelle)
suitable
Ligne 170: Ligne 170:
 ^ Controler / Valider / Assurer la qualité ^^^ Terminer ^ ^ Controler / Valider / Assurer la qualité ^^^ Terminer ^
 ^ Documenter / Informer / Communiquer ^^^ ^ Documenter / Informer / Communiquer ^^^
 +
 +===== (18) Les Cycles de développement =====
 +
 +==== (19) Le modèle en cascade ====
 +
 +Repose sur les hypothèses suivantes
 +  * on ne peut pas construire la toiture avant les fondations
 +  * les conséquences d'une modification en amont du cycle ont un impact majeur sur les coûts en aval (on peut imaginer la fabrication d'un moule dans l'industrie du plastique )
 +  * les phases traditionnelles de développement sont effectuées simplement les unes après les autres, avec un retour sur les précédentes, voire au tout début du cycle.  Le processus de développement utilisant un cycle en cascade exécute des phases qui ont pour caractéristiques :
 +    * produire des livrables définis au préalable
 +    * de se terminer à une date précise
 +    * de ne se terminer que lorsque les livrables sont jugés satisfaisants lors d'une étape de validation-vérification.
 +
 +  * analyse des exigences
 +  * design du système
 +  * programmation
 +  * programmation
 +  * test unitaire et d'intégration
 +  * test du système
 +  * test d'acceptance
 +  * maintenance
 +
 +==== Cycle en V ====
 +
 +| analyse des besoins |  | recette |
 +| spécifications  |  | tests de validation |
 +|   |  | tests d'intégration |
 +|   |  | tests unitaires |
 +|   | codage |  |
 +
 +modèle en W : variant du modèle en V, avec prototype, recette de maquette en phase besoins
 +
 +==== Modèle incrémental ====
 +
 +  * expression des besoins
 +  * spécif fonctionnelle
 +  * conception du système
 +  * deux ou plusieurs branches, des sous-systèmes
 +  * => risques d'incohérences, double travail
 +
 +==== Modèle itératif ====
 +
 +on ne planifie plus les versions en avance, on refait un nouveau cycle complet à chaque nouveau besoin.
 +
 +=== Modèle en spirale ===
 +
 +hyper compliqué, faut voir le dessin. Analyses de risques fréquentes.
 +
 +=== R.A.D. ===
 +
 +encore un dessin nécessaire. 120 jours maximum
 +
 +Prototype vs maquette
 +  * maquette : montre l'enchainement des différents écrans. une maquette papier est tout à fait possible (peut être statique)
 +  * prototype : diffère du produit final par le processus de conception. mais une vraie partie du système.
 +
 +^  ^  Avantages  ^  Inconvénients  ^
 +^ Cascade | logique \\ facile à comprendre | retour en arrière difficile \\ peu évolutif \\ effet tunnel \\ est-on capable d'établir tous les besoins en début de projet?  |
 +^ Cycle en V | logique \\ facile à comprendre \\ validations à chaque phase  | retour en arrière difficile \\ évolutions couteuse \\ évaluation utilisateur tardive  |
 +^ Cycle en W | + intégration de l'utilisateur par maquettage | retour en arrière difficile \\  évolutions couteuse  |
 +^ Cycle incrémental  | délivre assez rapidement quelque chose de visible | Risque d'être figé \\ Mise en cause du noyau? |
 +^ itératif | feedbacks utilisateurs rapides \\ adapté aux changements | risque de remise en cause \\ risque d'impossibilité technique d'intégrer nx besoins \\ necessite de disposer des compétences à chaque iteration \\ confusion maquette et solution \\ jamais fini? |
 +^ R.A.D. | résultats rapidement \\ implication utilisateur | implication utilisateur \\ risque de blocage ... |
 +
 +==== Cycle en V ====
 +
 +=== Analyse des besoins et faisabilité ===
 +
 +  * C'est une activité primordiale
 +  * Comprendre l'activité future...avec le système qu'on va mettre en place :
 +    * faire l'inventaire des personnes (services) concernées directement ou indirectement, voire dans le futur, mais aussi des systèmes adjacents
 +    * faire des scénarios (use cases, mais aussi des évènements externes)
 +  * **Différentes catégories**
 +    * besoins fonctionnels : ce" que le système doit faire (pas une réponse)
 +    * besoins non fonctionnels : propriétés attendues (par exemple besoins en performance), maintenance, interface utilisateur, sécurité, légaux, environnementaux
 +    * critères de réussite --mesurables! ...très importants
 +
 +
 +  * identifier les acteurs, le contexte
 +  * identifier les contraintes réglementaires
 +
 +=== Exemples de besoins ===
 +
 +  * opérationnel 24/24, 7/7
 +  * pouvoir supporter 50 utilisateurs 
 +  * afficher les prévisions météo
 +  * mobiles doivent résister à une chute
 +  * système doit comporter une aide en ligne
 +  * doit fonctionner même si périphérique d'impression sont en panne
 +
 +=== Comment caractériser un besoin ===
 +
 +  * identifiant unique
 +  * description textuelle
 +  * raison/justification
 +  * origine : qui a demandé ça?
 +  * critères de réussite
 +  * satisfaction : combien c'est utile à l'utilisateur
 +  * insatisfaction : combien c'est indisponsable
 +  * documents de référence
 +  * priorité
  
  
 
m2ilc/qualite_2.txt · Dernière modification: 2010/11/12 12:19 par suitable
 
Sauf mention contraire, le contenu de ce wiki est placé sous la licence suivante :CC Attribution-Noncommercial-Share Alike 3.0 Unported
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki