Transcript 3.5- Les étapes d`un projet

Introduction aux méthodologies de développement
Cours HEI 2009-2010
ALTRAN Nord – TI
© 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
© Reproduction interdite
1- Introduction
Genèse du projet
Idée
Besoin
Opportunité
PROJET
Innovation
© Reproduction interdite
1- Introduction
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".
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
© Reproduction interdite
2- Cycles de vie d’un projet :
1. Définition d’un cycle de vie
2. Méthodes
© Reproduction interdite
2.1- Définition du cycle de vie
« 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)
© Reproduction interdite
2.2- Principales méthodes de conduite de projet
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
© Reproduction interdite
2.2- Méthodes
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
© Reproduction interdite
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
© Reproduction interdite
3.1- Modèle de développement en cascade
Projets de petite taille,
Projets de Back-Office
Expression
des besoins
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
Spécifications
Conception
Développement
Tests
Maintenance
© Reproduction interdite
3.2- Modèle en « V » (variante du modèle en cascade)
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.
© Reproduction interdite
3.3- Le modèle en «V»
Expression
des besoins
Exploitation
Recette
Spécifications
Conception
Développement
Tests d’intégration
Tests unitaires
© Reproduction interdite
3.4- Autres modèles
Principe du modèle itératif
Nouveau besoin
(documentation, code, test)
Elaboration
Faisabilité
Fabrication
Transition
Exploitation ou tests
par les utilisateurs
© Reproduction interdite
3.4- Autres modèles
Modèle en « B »
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.
© Reproduction interdite
3.4- Autres modèles
Modèle en « B »
Expression du
besoin
Spécifications
Conception
Conception
Développement
Spécifications
Développement
Maintenance
Expression du
besoin
Tests
Évaluation
Exploitation
© Reproduction interdite
3.4- Autres modèles
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.
© Reproduction interdite
3.4- Autres modèles
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
© Reproduction interdite
3.4- Autres modèles
4 phases dans le déroulement du cycle en spirale (défini par Barry Boehm en 1988) :
1.
2.
3.
4.
détermination des objectifs, des alternatives et des contraintes ;
analyse des risques, évaluation des alternatives ;
développement et vérification de la solution retenue ;
revue des résultats et vérification du cycle suivant.
© Reproduction interdite
3.4- Autres modèles
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.
© Reproduction interdite
3.4- Autres modèles
Modèle du cycle itératif RAD
Structure d ‘une phase dans le cycle RAD
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.
Cycles de prototypage
© Reproduction interdite
3.4- Autres modèles
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.
© Reproduction interdite
3.4- Autres modèles
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.
© Reproduction interdite
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
© Reproduction interdite
3.5- Les étapes d’un projet
L’initialisation du projet
Cette phase permettra aux équipes de la maîtrise d’œuvre de :
1.
2.
3.
4.
Intégrer le détail des enjeux, objectifs et contraintes du projet,
Intégrer l’environnement fonctionnel et technique du projet,
Constituer / intégrer les groupes de travail du projet,
Définir un macro planning et confirmer l’éventuel lotissement
fonctionnel,
5. Définir finement l’ensemble des livrables du projet,
© Reproduction interdite
3.5- Les étapes d’un 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,
© Reproduction interdite
3.5- Les étapes d’un projet
La conception fonctionnelle et technique
Cette phase concerne l’élaboration des éléments suivants :
1.
2.
3.
4.
5.
6.
Architecture applicative (impact issu du découpage fonctionnel),
Spécifications techniques,
Spécifications fonctionnelles détaillées,
Interfaces homme machine (maquettage statique et / ou dynamique),
Construction du modèle de données MCD et du MPD,
Rédaction des jeux et des plans de tests d’assemblage,
© Reproduction interdite
3.5- Les étapes d’un projet
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.
© Reproduction interdite
3.5- Les étapes d’un projet
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,
© Reproduction interdite
3.5- Les étapes d’un projet
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
© Reproduction interdite
3.5- Les étapes d’un projet
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.
© Reproduction interdite
3.5- Les étapes d’un projet
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.
© Reproduction interdite
3.5- Les étapes d’un projet
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.
© Reproduction interdite
3.5- Les étapes d’un projet
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
© Reproduction interdite
3.5- Les étapes d’un projet
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.
© Reproduction interdite
3.5- Les étapes d’un projet
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.
© Reproduction interdite
3.5- Les étapes d’un projet
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.
© Reproduction interdite
3.5- Les étapes d’un 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.
© Reproduction interdite
3.5- Les étapes d’un projet
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.
© Reproduction interdite
3.5- Les étapes d’un projet
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
© Reproduction interdite
3.5- Les étapes d’un projet
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.
© Reproduction interdite
4- Outils de versionning
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
© Reproduction interdite
ALTRAN Nord – TI
Altran Nord / Adventec
Parvis de Rotterdam
1606 Tour Lilleurope
Tél. : +33 (0)3 28 36 22 30
Fax. : +33 (0)3 28 36
22 45 interdite
© Reproduction