© Reproduction interdite ALTRAN Nord – TI Introduction aux méthodologies de développement Cours HEI 2009-2010

© Reproduction interditeALTRAN Nord – TI

Introduction aux méthodologies de développement

Cours HEI 2009-2010

© Reproduction interdite

Sommaire

Les Méthodologies de développement

(Conduite de Projet Informatique )

1. Introduction : le projet

2.Le cycle de vie d’un projet

3.Méthodes de développement

4.Versionning


1- Introduction

Genèse du projet

Idée

Besoin

Opportunité

Innovation

PROJET


Définition

• L'Afitep-Afnor (X 50-105) définit le projet comme : " une démarche spécifique qui permet de structurer méthodiquement et

progressivement une réalité à venir...:

un projet est défini et mis en œuvre pour répondre au besoin d'un client (...)

et implique un objectif et des besoins à entreprendre avec des ressources données".

1- Introduction

Composantes• « Quoi »

• Objectifs, Fonctionnalités• Temps

• Délais, échéances • Moyens disponibles

• Humains et Techniques• Financiers (coût)

• Qualité• Selon le domaine d’activités


2- Cycles de vie d’un projet :

1. Définition d’un cycle de vie

2. Méthodes


« Le cycle de vie d‘un logiciel est la période située entre le début de la conception et l‘arrêt de l‘exploitation de ce logiciel. »

« Le cycle de vie regroupe un ensemble d‘activités suivant les normes AFNOR Z 67 150. Il est envisagé à un instant donné et va comprendre les progrès technologiques et les contraintes organisationnelles » (A. Carlier, 1994)

Le cycle de vie d‘un logiciel « correspond à l‘identification des états successifs d‘une application ou d‘un produit déterminé. Il est essentiellement dynamique, évolutif et presque toujours progressif » (A. Carlier, 1994)

2.1- Définition du cycle de vie


Séquentielle Itératives

Cascade Evolutive Objet

Principe de découper le projet en phases distinctes sur le principe du non-retour. Développée dans les années 1970 par W. ROYCE

Principe basé sur la polyvalence et une approche pluridisciplinaire, qui tendent à minimiser l'impact de l'évolution des besoins en cours de projets

Principe basé sur la séparation de l‘étude d‘architecture de celle de l‘étude fonctionnelle afin de paralléliser au maximum les tâches. Procède par itération comme pour l‘évolutive.

Avantage: proposer au fur et à mesure une démarche de réduction des risques, en minimisant au fur et à mesure l'impact des incertitudes.

Avantage : permettent de se rapprocher davantage des utilisateurs, et ainsi favorisent l'assurance qualité

Avantage : Permet de prendre en compte les problèmes d‘architecture dès le début du projet. Conforme à l‘approche objet dont la dynamique est plutôt ascendante en matière de composants d‘architecture.

Inconvénient : exclusion de l'utilisateur dès la phase de conception car trop technique. Le contrôle qualité significatif survient seulement en fin de projet.

Inconvénient : le produit, résultat d'évolutions permanentes, peut devenir complexe et difficilement maintenable

Inconvénient : Tout repose sur l‘expertise de l‘équipe projet

Risque : refus de recette utilisateur

Risque : Maintenance difficile Risque : Maintenance difficile

2.2- Principales méthodes de conduite de projet


Exemples de méthodes de conduite de projet :

Dynamiques en cascade :

Modèle en b

Modèle de loti

Modèle parallèle

Modèle en V

Dynamiques évolutives (ou dites « Agile ») :

Spirale

RAD

DSDM (Dynamic System Development Management)

RUP (Rational Unified Process)

SCRUM (sprint)

Extreme Programming

2.2- Méthodes


3- Méthodes de conduite de projet :

1. Le modèle en cascade

2. Modèle en “V”

3. Autres modèles

4. Les étapes d’un projet


3.1- Modèle de développement en cascade

Expression des besoins

Spécifications

Conception

Développement

Tests

Maintenance

Projets de petite taille,Projets de Back-Office

Démarche basée sur la spécialisation des tâches qui tendent à contenir les risques et les coûts, dans un enchaînement de phases qui reste simple et intuitif


L'assurance qualité est le processus qui permet de vérifier en continu la qualité du produit à fur et à mesure de sa fabrication.

Le modèle en V met l'accent sur ce processus. Il confronte les différents niveaux de test avec les phases de projet de même niveau. Ceci permet à chaque étape de définir non seulement les fonctions, mais également les critères de validation.

La cohérence entre les deux éléments permet de vérifier en continu que le projet progresse vers un produit répondant aux besoins initiaux.

Ce modèle est adapté aux projets de taille et de complexité moyenne. C'est une amélioration du modèle en cascade traditionnel. Il permet d'identifier et d'anticiper les éventuelles évolutions des besoins.

C'est aussi un moyen de vérifier la maturité des utilisateurs, car s'il en était autrement, ils se trouveraient dans l'incapacité de fournir des tests de recette dès la phase de spécification.

C'est un modèle avantageux pour une maîtrise d'œuvre et rassurant pour une maîtrise d'ouvrage, qui doit cependant s'engager significativement.

3.2- Modèle en « V » (variante du modèle en cascade)


3.3- Le modèle en «V»

Expression des besoins

Spécifications

Conception

Développement Tests unitaires

Tests d’intégration

Recette

Exploitation


3.4- Autres modèles

Principe du modèle itératif

Nouveau besoin

(documentation, code, test)

Faisabilité

Elaboration

Fabrication

Transition

Exploitation ou tests

par les utilisateurs


Similaire au modèle en cascade, il met l'accent sur le processus de maintenance qui est évalué à 70% du cycle complet.

Ce modèle réutilise les scénarios de tests bâtis pendant la phase de développement, notamment pour les tests de non-régression, ainsi que les procédures de mise en exploitation.

Ce modèle se projette plus loin que le traditionnel cycle en cascade.

Il peut servir de base à une maîtrise d'ouvrage pour bâtir un projet complet de développement et de maintenance d'une grosse application de back office.

Son intérêt est de prévoir lors de chaque phase projet la réutilisation des tests et des procédures de mise en exploitation.


Modèle en « B »


Développem

ent

Maintenance

Expression du besoin

Spécifications

Conception

Développement

Tests

Exploitation

Évaluation

Expression du besoin

Spécifications

Conception

Développement


Modèle en « B »


Modèle Incrémental ou en lots

Le modèle incrémental ou loti permet de gérer les projets de développement de grands systèmes. Il découpe le système en domaines qui sont traités individuellement sur le modèle en cascade. Une des idées du modèle incrémental est de gérer la complexité.

C'est un modèle adapté aux projets de grande envergure. Néanmoins, l'architecture du système doit permettre de définir des domaines suffisamment découplés. Dans le cas contraire, certains incréments doivent attendre que les incréments avec lesquels ils sont liés, soient suffisamment développés. Lorsqu'on leur propose un développement par lot, les maîtrises d'ouvrage doivent vérifier le couplage des domaines.

Modèle parallèle

Le modèle parallèle est un modèle incrémental couplé soit par le temps (les différents domaines doivent être mise en production au même moment), soit par les composants (certains composants du système sont étroitement liés).

Bien qu'il réduise la complexité, comme le modèle incrémental, il ne parvient pas à supprimer les risques de délai. Il suppose des montées en charge rapides, avec des équipes relativement fournies.

Adopter ce modèle suppose que les autres facteurs du projet ne présentent pas de risques significatifs. Néanmoins, la maîtrise d'ouvrage devra être attentive à la composition de l'équipe projet et à son mode de management.



Modèle en spirale

Principe :

• Identifier les risques, leur affecter une priorité

• Développer des prototypes pour réduire les risques, en commençant par le plus grand risque

• Utiliser un modèle en V ou en cascade pour implémenter chaque cycle de développement

Contrôler :

• si un cycle concernant un risque est achevé avec succès, évaluer le résultat du cycle, planifier le cycle suivant

• si le risque est non résolu, interrompre le projet



4 phases dans le déroulement du cycle en spirale (défini par Barry Boehm en 1988) :

1. détermination des objectifs, des alternatives et des contraintes ;

2. analyse des risques, évaluation des alternatives ;

3. développement et vérification de la solution retenue ;

4. revue des résultats et vérification du cycle suivant.



Modèle de type « Prototype »

« Un prototype est la première version d'un produit qui vient d'être réalisé afin d'être mis au point ». Autrement il faut parler de maquette, qui recouvre la réalisation à petite échelle de tout ou partie d'un produit à réaliser. Par abus de langage, nous nommerons prototype les maquettes réutilisables.

Les prototypes peuvent être construits suivant un axe horizontal ou vertical. Horizontaux, ils couvrent une couche technique du système sur l'ensemble des fonctions à développer. Verticaux, ils couvrent un échantillon de fonctions sur l'ensemble des couches techniques. Généralement les prototypes réalisés sont des 2 types.

Les prototypes peuvent être réutilisables, comme lors d'un cycle de vie itératif qui étoffe à chaque itération le prototype initial jusqu'au produit fini. Ils peuvent être également jetables à des fins de vérification fonctionnelle ou technique (faisabilité).

Sur les projets techniques, menés par de petites équipes, l'intérêt est de gagner en flexibilité, et de se libérer des contraintes d'une méthodologie plus large. Pour des projets où les utilisateurs sont largement impliqués, on préfèrera toujours un cycle de vie RAD.




Modèle du cycle itératif RAD

Structure d ‘une phase dans le cycle RAD

Cycles de prototypage

Le cycle de vie RAD (Rapid Application Development) est employé lorsque une implication forte de l'utilisateur est nécessaire.

Il permet de construire le système avec l'utilisateur, et participe ainsi à l'assurance qualité.

Néanmoins la condition sine qua non pour mettre en œuvre un cycle RAD est de s'appuyer sur un solide AGL (atelier de génie logiciel) qui seul peut garantir un passage rapide du concept à la mise en œuvre.

L'équipe projet doit nécessairement maîtriser l'AGL employé, c'est le risque principal des projets RAD.


DSDM

"Dynamic System Development Management" (DSDM) met en œuvre de manière structurée la plupart des principes des modèles évolutifs afin de les rendre efficaces dans le cadre de grands projets.

L'objectif initial de DSDM était de pallier le manque de formalisation du concept RAD en proposant une méthode structurée pour le mettre en œuvre.

DSDM est une méthode basée sur une démarche évolutive et incrémentale, c'est à dire que non seulement le système est produit au cours d'itérations, mais en plus il est divisé en lots, et livré de manière progressive.

DSDM est composé de 5 phases :

1. La faisabilité (expression du besoin, coûts/bénéfices, évaluation des risques) ;

2. L’étude business (spécification des fonctions et hiérarchisation) ;

3. Le modèle fonctionnel (prototypes horizontaux et tests) ;

4. La conception et la réalisation (prototypes verticaux et tests) ;

5. La mise en œuvre (optimisation et mise en production).

DSDM doit être l'objet des mêmes attentions que le modèle RAD.



RUP

"Rationale Unified Process" est une méthode développement propriété de la société Rational et basé sur l'utilisation de l'atelier Rational.

Elle est vendue sous la forme d'une documentation hypertexte et d'outils incorporables à chaque composant de l'AGL de Rational.

C'est une méthode évolutive, qui met en œuvre les mêmes principes que le RAD ou le développement en spirale.

Elle composée de 4 phases :

1. L’inception (initial "use case", coût/bénéfice, risques, planification) ;

2. L’élaboration ("use case" à 80% terminés, architecture logicielle, prototype) ;

3. La construction (développement) ;

4. La transition (tests, conversion et déploiement).

RUP utilise le niveau élevé d'automatisation que lui procure l'AGL Rational.

Il permet d'une part de planifier des itérations à l'intérieur de chaque phase, de paralléliser les processus au maximum : ainsi la définition d'architecture peut commencer tandis que les spécifications ne sont pas terminées.



3.5- Les étapes d’un projet

(Extrait d’une proposition commerciale)

•L’initialisation du projet•L’étude d’architecture•La conception fonctionnelle et technique •La Réalisation•Les tests•La recette interne•La recette fonctionnelle•L’intégration•La conversion et la reprise des données•Le site pilote•Le déploiement technique•La formation•Documentations



L’initialisation du projet

Cette phase permettra aux équipes de la maîtrise d’œuvre de :

1. Intégrer le détail des enjeux, objectifs et contraintes du projet,

2. Intégrer l’environnement fonctionnel et technique du projet,

3. Constituer / intégrer les groupes de travail du projet,

4. Définir un macro planning et confirmer l’éventuel lotissement fonctionnel,

5. Définir finement l’ensemble des livrables du projet,



L’étude d’architecture

Cette étude aura pour principaux objectifs :

1. De définir l’architecture applicative, notamment sur la reprise des composants existants, et la conception des composants techniques et fonctionnels propres au domaine,

2. De définir l’architecture technique et de valider définitivement les outils de développement,

3. D’amender, le cas échéant, le périmètre fonctionnel du projet,

4. De finaliser le lotissement défini par la maîtrise d’ouvrage au regard des contraintes architecturales identifiées,

5. De définir l’architecture des données : localisation, répartition, modèle, réplication, sauvegardes,

6. Initialiser les tableaux de suivi des risques,

7. D’avancer dans le degré de détail du planning,

8. D’initialiser un squelette d’application qui permettra d’effectuer une expérimentation ayant pour finalité de valider les principes de l’IHM, l’architecture technique, et la cartographie fonctionnelle,



La conception fonctionnelle et technique

Cette phase concerne l’élaboration des éléments suivants :

1. Architecture applicative (impact issu du découpage fonctionnel),

2. Spécifications techniques,

3. Spécifications fonctionnelles détaillées,

4. Interfaces homme machine (maquettage statique et / ou dynamique),

5. Construction du modèle de données MCD et du MPD,

6. Rédaction des jeux et des plans de tests d’assemblage,



La Réalisation

Pour certains projets, il est parfois recommandé de réaliser une maquette opérationnelle ne comportant que quelques développements.

Cette étape aura pour objectif principal de recetter le socle technique et en particulier de vérifier la montée en charge, ainsi que la conformité des travaux en fonction des attentes du client.

Elle permettra à l’architecte système et aux équipes systèmes du client de valider et / ou d’amender les éléments d’architecture ainsi qu’éventuellement quelques consignes de développement.

En outre, elle permettra de définir l’architecture réseau nécessaire tant en terme de débit que de temps de réponse.

Le lotissement du projet sera défini au cours de la phase d’Initialisation.



Les tests

Cette étape consiste à concevoir et exécuter un plan de tests.

Dans la pratique, il convient d’intégrer les développements unitaires au sein de l’architecture technique cible, tout en testant la cohérence fonctionnelle et technique globale de l’application, avant livraison et installation sur le site du client.

Les tests réalisés seront :

• Un test spécifique du Framework après développement sur la base de la conception définie au début de la conception fonctionnelle et technique,

• Un test de réception des composants achetés pour le projet,

• Les tests unitaires des fonctions développées,

• Les tests d’assemblage sur les plates-formes de développement avec données réelles permettant entre autres le test des procédures de reprise,

• Pour la maquette opérationnelle, un test de charge initialement prévu sera réalisé,

• Les test d’intégration sur les plates-formes,

• Les tests de charge sur chacun des lots sachant que pour une architecture 3 tiers, cette partie nécessite plutôt un monitorat détaillé des composants serveurs et réseau lors de l’installation. Si nécessaire, un test sur automate pourra être prévu,



Tests des composants externes

L’objectif de cette étape est de s’assurer que l’ensemble des composants externes à l’application sont conformes sur les plans fonctionnel et métier aux spécifications prévues dans les phases de conception.

Sur un plan technique, il s’agit de s’assurer que le composant technique ne crée aucune interaction non-souhaitée (ou interférence) de par son installation, registration, instanciation,…

Les composants externes sont par exemple et suivant les technologies employées des composants OCX, VBX, DLL, EJB ,….

La qualification technique pourra avoir été réalisée dans le cadre d’un projet antérieur



Tests Unitaires

Ces tests sont réalisés au fil de l’eau par l’équipe de développement.

Chaque personne de cette équipe consigne que le développement de la fonction X a été réalisé par lui et après exécution en environnement de développement ou sur simulateur.

Il s’agit de confirmer que cette fonction est conforme aux spécifications fonctionnelles et techniques décrites.

Tests d’assemblage

Ces tests sont réalisés par le chef de projet ou sous son autorité par une personne de l’équipe de développement détachée sur cette mission.

Cette phase permet de s’assurer que l’ensemble des composants techniques développés ou acquis s’interfacent correctement : l’application fonctionne sans défaillance, les résultats attendus sont conformes sur les axes règles de calcul et règles de gestion.

Cette phase s’effectue sur le jeu d’essai de développement.



Tests d’intégration

Cette phase de test s’effectue sur une plate-forme d’intégration déclarée conforme par le client à l’environnement de production.

Cela concerne tant les aspects techniques (OS serveur, base, client) que les interfaces (entrantes notamment), ainsi que le jeu de données.

Tests de charge

L’objectif de cette phase est d’effectuer une montée en charge des données entrantes et existantes dans l’application.

La base de données sera chargée avec une volumétrie équivalente au fonctionnement nominal de l’application.

Les transactions devront s’effectuer dans les temps de réponses prévues lors de l’élaboration du cahier de charge.

A défaut de temps de réponse décrit, l’application devra prouver qu’elle fournit les réponses attendues avec la volumétrie nominale.



Test de stress

Cette étape permet de simuler l’intégralité des accès (TP et Batch) effectués simultanément sur l’application sur une période de référence, généralement une période de pointe pour l’application.

Ces tests sont généralement réalisés à l’aide d’un automate qui enchaîne des scénarios de tests définis au préalable.

Les tests de stress peuvent également servir au remplissage de la base ;

Les tests de charges seront alors effectués à l’issue des tests de stress.



La recette interne

Il s’agit d’une validation interne, effectuée par la direction projet, des livrables avant fourniture au client du lot réalisé.

La recette interne assure que le chef de projet en charge du projet suit le déroulement des actions de la contractualisation à la mise en œuvre du résultat prévu.

La recette fonctionnelle

La recette fonctionnelle est effectuée par le client et plus spécifiquement par le Chef de Projet Utilisateur du Client.

Elle est usuellement effectuée sur la plate-forme de développement ou la plate-forme d’intégration.

Les compléments et/ou évolutions détectées lors de la recette fonctionnelle peuvent donner lieu à l’établissement d’avenant(s) au contrat



L’intégration

Cette opération sera placée sous la responsabilité du chef de projet client accompagné par l’Architecte Système notamment pendant les phases d’installation et de démarrage de la plate-forme.

La correction des dysfonctionnements doit être assurée de manière réactive.

Le client pourra être assisté sur les différents dans la réalisation des tests de recette du système, et dans la mise au point globale du système.

La conversion et la reprise des données

Dans le cas d’une migration de système avec reprise des données existantes, la phase de conversion et reprise est considérée comme un sous-projet du projet de réalisation.

La reprise des données donne lieu à l’élaboration de spécifications, développement et tests identifiés. Les règles que doivent respecter les données en entrée ainsi que leur structure sont fournies par le client.

Un taux de rejet peut être admis en production. Il devra être fixé au plus tard au démarrage de cette phase.



Le site pilote

Dans le cas d’un site pilote : pour chacun des lots produits et des évolutions en garantie, un site pilote sera réalisé.

Le site pilote pourra être installé après la validation du Procès Verbal (PV) de recette d’intégration.

Cette étape permet de vérifier le fonctionnement réel du projet.

Ce mode de fonctionnement s’accompagne d’une exploitation sous contrôle.

Le déploiement technique

Ces étapes sont placées sous la responsabilité du client, plus précisément les équipes Installations pour le déploiement technique, et des équipes déploiements / Formation.



La formation

La formation peut prendre plusieurs formes.

Elle peut viser les utilisateurs mais aussi les équipes techniques (exemple : les équipes de maintenance).

Différentes déclinaisons sont envisageables en fonction du contexte projet considéré :

Les sessions de formation : elles s’appuient sur l’alternance d’un enseignement théorique et des mises en pratiques immédiates (TP).

Les sessions de formation doivent impérativement être intégrées dès le début dans le plan projet : pour qu’elles soient optimales, les formations doivent être synchronisées avec le déploiement sur sites ou le passage en maintenance (formation des équipes techniques).

Elle nécessite également la mise en place d’une infrastructure dédiée (logistique : salle de formation équipée, organisationnelle : disponibilité complète des stagiaires, technique : disponibilité de plates formes dédiées).

Le transfert de compétences : il est principalement dédié aux équipes techniques d’exploitation ou de maintenance. L’objectif est de traiter sur la fin du projet l’ensemble des points critiques du projet en parfaite transparence.

L’accompagnement en production : il se met en place lorsque la montée en charge et/ou le déploiement représente(nt) un enjeu majeur et critique du projet. Ainsi, l’ensemble des anomalies pouvant survenir sont traitées en collaboration directe avec l’équipe projet.



Documentations

Dossier de Conceptions Fonctionnelles et Techniques

Ce dossier décrit l’ensemble des transactions, éditions, traitements batch de l’application cible.

Le dossier de conception fonctionnelle et technique décrit également l’ensemble des règles de gestion, de calcul, d’enchaînement et d’ergonomie à réaliser.

Il constitue la référence pour la recette.

Dossier de recette

Le dossier de recette consigne l’ensemble des remarques (bloquantes, mineures, évolutions) identifiées lors de la recette fonctionnelle.

Il reprend ou fait référence aux règles de gestion décrites dans le dossier de Conceptions Fonctionnelles et Techniques.



Documentations

Cahier du développeur

Le cahier du développeur précise l’architecture générale du code de l’application, les composants techniques utilisés, les options de développement (option du projet, de compilation, versions de shells, composants, …) ainsi que les règles particulières utilisées.

Son principal objectif est de permettre à un développeur reprenant le projet de démarrer dans les meilleures conditions.

Préconisations techniques

Ce document reprend l’ensemble des préconisations nécessaires au bon fonctionnement de l’application dans l’environnement de production.

Procédures d’installation

Sont décrits dans ces documents l’ensemble des procédures nécessaires à l’installation de l’application ainsi que des composants nécessaires à l’installation.

Dans le cas d’une installation automatisée, elle décrit le chemin de la routine d’installation à lancer, les principaux écrans et le résultat attendu in fine.



Documentations

Guide de dépannage

Ce guide reprend ou décrit les principales opérations permettant de débloquer une situation d’incident qu’il soit technique ou issu d’un blocage fonctionnel.

Exemple : procédure de compactage / réparation de base, dé fragmentation de base, reconstruction d’index, réinstallation de composant et/ou d’outil, déverrouillage ou modification d’indicateur en base,…

Cahier d’exploitation

Ce cahier doit contenir l’ensemble des procédures assurant l’exploitation normale de l’application et sa disponibilité prévue pour les utilisateurs.

On y trouvera notamment :• les procédures spécifiques de sauvegarde spécifiques si elles ne sont pas prises en

charge par le système,• les procédures de compactage, de ré-indexation,• les procédures de purge,• les procédures de reprise en cas d’indicent,• les procédures de relance d’une procédure normalement automatique



Documentations

Support de formation utilisateurs

Ce document permet la formation des utilisateurs aux outils.

Sauf stipulation particulière, il ne comporte pas de volet métier.

Support de formation technique

Ce document permet la formation des acteurs techniques en vue de la reprise du projet par une autre équipe.

Son contenu est détaillé au démarrage du projet, notamment dans le cadre d’un transfert de compétences intégrés dès le début au périmètre du projet.


Logiciels de gestion de version :

CVS (Concurrent Versions System),

Bitkeeper,

SourceSafe

Logiciels de gestion de configuration

Par rapport aux précédents, apportent des outils permettant :

1. de gérer les demandes de modification du système à faire évoluer.

2. de mettre en correspondance les demandes de modifications avec les changements apportés au système

Exemples : Synergy (Telelogic), PVCS, Perforce ou ClearCase

4- Outils de versionning

© Reproduction interditeALTRAN Nord – TI

Altran Nord / AdventecParvis de Rotterdam1606 Tour Lilleurope

Tél. : +33 (0)3 28 36 22 30Fax. : +33 (0)3 28 36 22 45

Documents

© Reproduction interdite ALTRAN Nord – TI Introduction aux méthodologies de développement Cours HEI 2009-2010