====== Les Projets SI : le développement d'un système ====== ^ 12 novembre MMX ^ * Projets * Différents modèles de développement * Besoins ===== Rappels sur le cours précédent ===== [[qualité_1|]] Rappel : un produit ou service de qualité est un produit dont les caractéristiques lui permettent ... ?? L'assurance de la qualité :: !! ?? Le contrôle qualité :: est un aspect de la gestion de la qualité. Le **contrôle** !! === ISO 9001 === - Démontrer l'aptitude à fournir __régulièrement__ un porduit onforme aux exigence du client et aux exigence réglementaires applicables. - Chercher à accroître la satisfaction des clients... === ISO 9001-2008 -- 8 principes === - orientation client - implication de la direction (leadership) - implication du personnel - approche processus - approche système (interaction des processus) - amélioration continue - prise de décision factuelle - relation mutuellement bénéficiaires avec les fournisseurs ==== ISO 9126 Qualité des produits logiciels ==== === Caractéristiques : === * capacité fonctionnelle * fiabilité * facilité d'usage * efficacité * maintenabilité * portabilité ===== Gestion des projets ===== ?? un projet :: un engagement irréversible de résultat incertain, non reproductible a priori à l'identique, nécessitant le concours et l'intégration d'une grande diversité de contribution, et répondant à un besoin exprimé. Un projet a pour objet d'utiliser le plus efficacement possible les ressources humaines et techniques disponibles, afin d'apporter un nouveau service ou un produit précis, dans un environnement donné et avec un budget donné. Groupe de ressources principalement matérielles et humaines, qui sont combinées pour la réalisation d'activités et de tâches, avec un coût et une durée de temps... Un projet est un processus unique qui consiste en un ensemble d'activités coordonnées et maîtrisées, comportant des dates de début et de fin, entrepris dans le but d'atteindre un objectif conforme à des exigences spécifiques, telles que les contraintes du délai, de coûts et de ressources. ((ISO 10006)) !! ==== Types AFITEP de projet informatique ==== * progiciel applicatif : mise en place d'un progiciel du marché * développement applicatif : développement spécifique à une entreprise * intégration des systèmes : assemblage de différents logiciels * maintenance évolutive : nouvelle version d'un logiciel existant * infrastructures techniques : mise en place de systèmes d'infrastructure (par exemple réseau) === D'autres classements existent === * stratégie * enjeux de niveau DG * technologie novatrice * ex. : e-commerce, EDI * efficience * amélioration productivité * technologie éprouvée * ex. : progiciel de paie, gestion de stock * obligation * obligation extérieure, réglementaire, de fait ou imposée * technologie banalisée * ex. : An 2000, euro, fusion ?? Maître d'ouvrage :: dans le contexte d'un projet de système d'information, ce terme a été emprunté au vocabulaire du bâtiment de des travaux publics : maître d'ouvrage est celui qui commande (et qui paie) l'ouvrage à construire (par exemple la Direction de l'enseignement commande la construction d'une nouvelle cécole). C'es le __client__. !! ?? Maître d'oeuvre :: dans le ... c'est le __chef de projet__ !! Triangle du projet : - qualité ou performance - délais - coûts ^ échantillon de 365 entreprises et 8 380 projets ^^ ^ 16 % | sont des succès | ^ 31 % | sont arrêtés en cours de réalisation | ^ 53 % | aboutissent mais au prix d'un accroissement du délai et du coût tout en offrant moins de fonctionnalités que prévu, le multiplicateur étant en moyenne 2.89 pour le coût et 3.22 pour le délai. | ==== Facteurs d'échec ==== * expression de besoin initiale confuse * priorités non définies, moyens inadaptés, pouvoir du chef de projet * spécifications relevant de la science fiction plus que du réalisme du métier ou de la technique * versatilité, instabilité de la demande ou caractère inflationniste de la demande * insouciance en ce qui concerne la conduite de projet * mauvaise gestion des risques * évaluation initiale trop faible * manque de compétence des acteurs ==== Facteurs de succès ==== * chef de projet professionnel et expérimenté * implication des utilisateurs, travail collaboratif * implication et soutien fort de la direction * accompagnement au changement, communication * une envergure limitée aux besoins essentiels * une infrastructure technologique normalisée * des spécifications précises et stables * des méthodologies formelles et utilisées * des estimations fiables et rigoureuses ==== Gérer un projet c'est ==== * une activité à part entière (gérer le projet ce n'est pas développer un système) * une activité composée de taches spécifiques et utilisant des outils spécifiques...produisant des livrables spécifiques * une activité basée * sur l'anticipation (vison vers le futur), prévoir, planifier * sur le suivi (tirer des lecons du passé) afin de mieux plainifier * sur une gestion au quotidien (réaction aux problèmes ou évènements) * Plan (planifier), Do (exécuter), Check (suivre vérifier), Act (améliorer)...s'applique aussi! ==== (14) Les phases d'un projet ==== ^ 1. Phase préalable\\ Démarrage ^ 3. Planification \\ Ordonnancement ^ 5. Mise en exploitation ^ ^ 2. Définition ^ 4. Exécution ^ 6. Clôture ^ === 1. Phase préalable et démarrage === * Etude d'opportunité et de viabilité * Calcul prévisionnel de retour sur investissement (ROI) === 2. Phase Définition === * périmètre, contexte * équipes, responsabilités * découpage fonctionnel (WBS, Work Breakdown Structure) * étude d'impacts, identification des facteurs de risques et des facteurs d'échec === 3. Planification / Ordonnancement === * Définition du plan d'exécution en termes de délais, de ressources et de responsabilité === 4. Exécution === * Exécution et pilotage du projet, suivi du franchissement des jalons, gestion des dérives, importance de la réunion de travail projet. === 5. Mise en exploitation === * Recette, vérification des conformités, mise en exploitation, formation, poursuite de l'accompagnement du changement. === 6. Clôture === * Élaboration de la documentation dans une démarche de transfert de la connaissance. * Gestion des évaluations du projet, préparation des évolutions. ==== Phases (3) ==== Prise en charge : Délimiter -> Structurer -> Estimer -> Planifier -> Plan projet PAQ | Conception | Réalisation | Mise en oeuvre | ^ Suivre et gérer les équipes ^^^ ^ Controler / Valider / Assurer la qualité ^^^ Terminer ^ ^ 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é