Organisation des Projets

Buts du chapitre Aider à identifier les activités à mener cycles de vie maintenance Mettre en évidence les responsabilités des différents acteurs Pour ensuite pouvoir Estimer les activités (temps à passer, charges, ressources) Les affecter aux ressources Les planifier Les suivre (contrôler, maîtriser)

Cycle de vie (réalisation) Identification des activités Cycle de vie (réalisation)

Objet du cycle de vie Modélisation conceptuelle, qui aide à la prise de décision durant toute la vie d'un système, de la création au retrait Décomposition du développement (maintenance) en phases successives But = définition d'entités réellement gérables identifiables estimables planifiables contrôlables (mesurables) Maîtrise de chaque phase, étape (méthodes, outils) pour la maîtrise du processus

Contenu d'un cycle de vie traditionnel Pour chaque phase (étape), définition des . produits en entrée (documents, codes) . activités à réaliser, relations entre activités ; distinction entre activités de - réalisation (documentation, programmation, test...) (ingénierie) - gestion (gestion de projet, gestion de configuration, gestion de la documentation...) - qualité (assurance, contrôle) . environnement de réalisation (méthodes, outils) . produits en sortie . processus et critères de validation de la phase, de passage à la phase suivante

Cycle de réalisation en "V" (AFNOR 87) Spécification Validation Conception Intégration préliminaire Conception Tests détaillée unitaires Codage

Cycle de réalisation en “V” : bilan Avantages Ne « choque » pas : Pourquoi ? Quoi ? Comment ? on fait, on vérifie Adapté aux développements « au forfait » sur la base du « quoi » Très connu des partenaires « béton » sur le plan contractuel Inconvénient Pas adapté à la prise en compte des demandes de modification durant le développement (risques) : effet « tunnel », contraintes vérifiées tardivement (performances, volume…) Équipe de réalisation parfois importante (risques) : confusion phase et activités (risques) : orienté « documents » Quand l’appliquer ? Besoins connus, solution connue (risque)

Cycle de réalisation incrémental Spécification de logiciel Validation Conception détaillée Vérification Codage incrément 1 Conception Test Unitaire Intégration Conception Test globale détaillée fonctionnel Installation Recette Vérification Codage Exploitation et Maintenance Test Unitaire Intégration Revalidation Vérification Conception Test détaillée fonctionnel Vérification Codage Test Unitaire incrément 2 incrément 3

Cycle de réalisation incrémental : bilan Avantages : les mêmes + Équipe plus petite (sur une période + longue) Plus adapté à la prise en compte des demandes de modification Moins d’effet « tunnel » Inconvénients Autant de livraisons que d’incréments Davantage de tests (non régression) (risques) : coûts de « cassure » Quand l’appliquer ? Besoins connus, solution connue, mise en œuvre progressive du produit, budget client sur plusieurs périodes

Cycle de réalisation itératif Vers le produit idéal, idéalement fabriqué Domaine du problème Itération 1 Itération 2 Itération 3 P R Domaine de la solution O D U I T Chaque itération commence par une activité de spécification

Le processus itératif Les objectifs : s'assurer de la construction du bon système, en vérifiant systématiquement les besoins et en les raffinant avec les clients à des intervalles de temps réguliers permettre la réalisation de plans détaillés qui collent davantage à la réalité, en organisant le développement au fur et à mesure de la compréhension du système, et de la compréhension de la manière de le construire Le processus doit être contrôlé et dirigé par les besoins (et par les ressources, notamment le temps)

Une itération Itération 1 Plan de développement Itération 2 Spec. + plan Production Evaluation

A propos des itérations (source IBM) Nombre d'itérations : de 3 à 6, selon la taille du projet, la complexité, la stabilité des besoins Typiquement 9 à 18 mois de développement 200 classes, 3000 méthodes Durée d'une itération : de 3 à 6 mois, selon le regroupement logique des fonctions fournies, la disponibilité des clients Avec un cycle moyen de 3, 5 mois 1 à 2 semaines de spécification / planification 2 à 3 semaines d’évaluation 2 à 2,5 mois de production Et maintien de l’intérêt de chacun !

Cycle de réalisation itératif : bilan Avantages On « code » naturellement (c’est écrit !) de suite Le client a des codes à tester rapidement Pas orienté « doc » (ce qui ne veut pas dire….) Parfaitement adapté à la prise en compte des demandes de modification Inconvénients Pas dans les habitudes des partenaires Pas adapté à des réalisations au forfait sur le « quoi » Demande davantage d’implication des utilisateurs Les utilisateurs doivent avoir le temps de tester Quand l’appliquer ? Développement « en interne », sans obligation d’engagement au forfait sur le « quoi » Besoins mal connus, solution mal connue : typiquement projets de R&D

Maquettes et prototypes résultat d’une action ayant pour but d’illustrer un concept (typiquement une maquette d’écran -statique-) permet d ’illustrer, définir ou valider une ergonomie Prototype version exécutable et fonctionnellement incomplète d’un système permet d’étudier une faisabilité Surtout ne pas assimiler prototype et cycle de réalisation itératif ; un prototype peut très bien être élaboré durant n’importe quel cycle de réalisation Si un prototype est envisagé, bien définir en préalable les objectifs recherchés (valider une IHM, démontrer une faisabilité, montrer différentes possibilités d’IHM, etc.)

Identification des activités Maintenance

Maintenance Activité vitale pour les entreprises car Mais le parc applicatif représente un investissement considérable le système d'information est une ressource stratégique Mais mobilise une part importante des ressources du service informatique au détriment du développement de nouvelles applications

Les différents types de maintenance Adaptative Action de maintenance ayant pour but d'adapter un logiciel, à fonctionnalités identiques, aux modifications de son environnement technique, de manière à assurer un fonctionnement conforme aux exigences formulées lors de son développement Corrective Action de maintenance ayant pour but de corriger, soit des anomalies de fonctionnement constatées du logiciel, soit des erreurs dans sa documentation Perfective / Préventive Action de maintenance ayant pour but soit d'améliorer les performances ou la fiabilité du logiciel, soit d'en faciliter l'utilisation, l'exploitation ou la maintenance ultérieures. Soit de réduire la probabilité de défaillance ou la dégradation des performances du logiciel Evolutive Action de maintenance ayant pour but de prendre en compte une évolution fonctionnelle

Principes généraux de la maintenance L'informatique est au service de l'entreprise. Il est nécessaire de mettre en place des dispositions générales pour assurer la qualité de ses prestations Appliquer à la maintenance la même démarche qu'au développement Préparer la maintenance, pour s'assurer que les conditions nécessaires sont remplies désigner l'équipe maintenance prendre connaissance du logiciel et évaluer sa qualité effectuer (proposer) les mises à niveau nécessaires identifier les procédures, méthodes à appliquer, mettre en place les moyens Faire évoluer le logiciel par versions successives contrôlées

Evolution par versions L'évolution se fait uniquement par versions successives contrôlées, les modifications "à la volée", même mineures, sont prohibées (« laisser le temps au temps ») Ceci implique une gestion des demandes de modifications, pour faire les bons choix, coordonner les évolutions de produits différents, mais intégrés dans une certaine mesure Les contraintes quotidiennes sont bien sûr à prendre en compte, mais elles sont réduites au minimum Cette gestion assure alors une bonne visibilité

Le processus de maintenance Il comporte six grandes activités certaines ponctuelles : préparation de la maintenance d'autres cycliques durant la vie du logiciel : prise en compte des demandes de modification assistance aux utilisateurs et exploitants traitement des anomalies réalisation d'une version / révision mise en service d'une version / révision

Organisation fonctionnelle d’un projet

Organisation fonctionnelle d’un projet Met en évidence la manière selon laquelle le chef de projet délègue ses responsabilités les missions des différents intervenants les circuits de communication internes avec l'extérieur (sous-traitants, fournisseurs...) Toutes les responsabilités doivent être clairement identifiées.... et il y en a beaucoup !

Les différentes responsabilités Responsable technique conception et réalisation, coordination de la résolution des problèmes techniques, validation formation, assistance aux équipes de réalisation Responsable du projet coordination des développements, choix des fonctionnalités retenues gestion des équipes et des moyens, suivi du projet organisation de la recette et de la livraison Responsable qualité production et suivi du plan qualité audit des processus, participation aux revues et inspections, contrôle des produits et fournitures Responsables du site, de la gestion de configuration, de la documentation, du matériel, commercial, produit Responsable utilisateurs : ?