Support L3 ISI2 v20060123 PDF

Univ. De Paris 1 Panthon - Sorbonne / UFR..
/ IUP / L3-ISI2 1
OM/Support-L3-ISI2-v20060123.doc / 30/01/2006 Droulement des 15 sances L3-ISI2 Conduite de Projet 62
L3 / ISI2
Conduite de Projet
Universit de Paris 1 Panthon - Sorbonne
UFR..
Enseignant : Olivier MAQUET
Anne universitaire 2005-2006
Prambule :
Ce document nest pas un support de cours. Beaucoup de sujets ne sont pas dtaills dans ce
document. Par contre, ils le seront loral par lenseignant.
Il est fourni aux tudiants afin de les aider dans leur prise de notes pendant les sances de
cours.
Univ. De Paris 1 Panthon - Sorbonne / UFR.. / IUP / L3-ISI2 2
Table des matires
1. INTRODUCTION...........................................................................................................................5
1.1 INFORMATIONS PRELIMINAIRES ............................................................................................................................... 5
1.1.1 Remarque concernant ce support ........................................................................................................................................... 5
1.1.2 Quelles notes ? ...................................................................................................................................................................... 5
1.2 OBJECTIF DE M12 CONDUITE DE PROJET .............................................................................................................. 5
1.2.1 Objectif du cours ................................................................................................................................................................... 5
1.3 INTRODUCTION A LA DEMARCHE DE CONDUITE DE PROJET....................................................................................... 6
1.4 DIFFERENTS TYPES DE PROJETS................................................................................................................................ 8
1.5 LES ACTEURS DUN PROJET INFORMATIQUE ............................................................................................................. 9
1.5.1 Lorganisation dune Direction des Systmes dInformation (DSI) dune entreprise ............................................................... 9
1.5.2 Les acteurs de la matrise duvre......................................................................................................................................... 9
1.5.3 Les acteurs de la matrise douvrage...................................................................................................................................... 9
1.5.4 Implication MOE & MOA dans un projet ............................................................................................................................... 9
1.5.5 Les instances de pilotage ..................................................................................................................................................... 10
1.6 VOCABULAIRE (A EXPLIQUER)................................................................................................................................ 10
1.6.1 Vocabulaire......................................................................................................................................................................... 10
1.6.2 Abrviations ........................................................................................................................................................................ 10
2. LES OUTILS................................................................................................................................. 12
2.1 LES OUTILS DE LEPJUSQUA LA MISE EN PRODUCTION ......................................................................................... 12
2.1.1 Les diffrents types doutils.................................................................................................................................................. 12
2.1.2 Tableau de synthse Outils / Etapes de la dmarche............................................................................................................. 14
2.2 LES OUTILS DADMINISTRATION DU SYSTEME......................................................................................................... 14
3. RAPPELS MERISE & UML (METHODOLOGIES DE MODELISATION)........................... 15
3.1 PRESENTATION DE LA DEMARCHE PAR NIVEAUX..................................................................................................... 15
3.2 UML(RAPPEL)....................................................................................................................................................... 15
3.2.1 Le diagrammes des cas dutilisation (Use case).................................................................................................................... 15
3.2.2 Le diagrammes des classes................................................................................................................................................... 15
3.2.3 Le diagrammes dtats - transitions ..................................................................................................................................... 15
3.2.4 Le diagrammes de squences................................................................................................................................................ 15
3.3 MERISE(RAPPEL)................................................................................................................................................. 16
3.3.1 Le modle des flux (rappel) .................................................................................................................................................. 16
3.3.2 MCD (rappel) ...................................................................................................................................................................... 16
3.3.3 MLD relationnel (rappel)..................................................................................................................................................... 16
3.3.4 MCT (rappel)....................................................................................................................................................................... 16
3.3.5 MOT (rappel)....................................................................................................................................................................... 16
4. SCHEMA DIRECTEUR .............................................................................................................. 17
4.1 LES 2 NIVEAUX DE SD............................................................................................................................................. 17
4.2 SDSTRATEGIQUE ................................................................................................................................................... 17
4.2.1 Dfinition ............................................................................................................................................................................ 17
4.2.2 Les acteurs .......................................................................................................................................................................... 17
4.3 SDDU SI................................................................................................................................................................. 18
4.3.1 Dfinition ............................................................................................................................................................................ 18
4.3.2 Les acteurs .......................................................................................................................................................................... 18
5. ETUDE PREALABLE.................................................................................................................. 19
5.1 OBJECTIFS DE LETAPE........................................................................................................................................... 19
5.2 LES PHASES DE LEP............................................................................................................................................... 19
5.2.1 Lancement de l'EP (Ph1) ...................................................................................................................................................... 19
5.2.2 Bilan de l'existant (Ph2)....................................................................................................................................................... 20
5.2.3 Dfinition des orientations (Ph3) ......................................................................................................................................... 20
5.2.4 Modlisation du systme cible / SER (Ph4)........................................................................................................................... 21
5.2.4.1 Modlisation du fonctionnel ....................................................................................................................................... 21
5.2.4.2 Initialisation de larchitecture technique cible ............................................................................................................ 21
5.2.5 Processus de validation et dcision (Ph5)............................................................................................................................. 23
5.3 LIVRABLES DE L'EP................................................................................................................................................ 25
5.4 IMPORTANCE DU PROCESSUS QUALITE................................................................................................................... 25
5.5 LES ACTEURS DE L'EP............................................................................................................................................ 25
6. ETUDE DETAILLEE................................................................................................................... 27
6.1 OBJECTIFS DE L'ED ............................................................................................................................................... 27
6.2 LES PHASES DE L'ED .............................................................................................................................................. 27
6.2.1 Lancement (Ph1).................................................................................................................................................................. 27
6.2.2 Complment des SFG (Ph2).................................................................................................................................................. 28
6.2.3 Elaboration des SFD Donnes + Traitements (Ph3) ............................................................................................................. 28
6.2.3.1 Elaboration de N&S (Ph3.1) ...................................................................................................................................... 29
6.2.3.2 Elaboration des SFD (Ph3.2)...................................................................................................................................... 29
6.2.4 Dfinition de larchitecture physique (Ph4).......................................................................................................................... 30
6.2.5 Validation et dcision (Ph5)................................................................................................................................................. 31
6.3 LES ACTEURS DE L'ED............................................................................................................................................ 31
6.4 LIVRABLES DE L'ED............................................................................................................................................... 32
7. ETUDE TECHNIQUE.................................................................................................................. 33
7.1 OBJECTIFS DE LET ............................................................................................................................................... 33
7.2 LES PHASES ............................................................................................................................................................ 33
7.2.1 Lancement (Ph1).................................................................................................................................................................. 33
7.2.2 Elaboration des spcifications techniques (Ph2)................................................................................................................... 34
7.2.2.1 Prparation du cadre du dveloppement ..................................................................................................................... 34
7.2.2.2 Identification des composants logiciels dvelopper .................................................................................................. 34
7.2.3 Mise en uvre de la plateforme de dveloppement (Ph3) ...................................................................................................... 36
7.2.4 Fin de lEtude Technique ..................................................................................................................................................... 38
7.3 LES LIVRABLES....................................................................................................................................................... 38
7.4 LES ACTEURS DE L'ET............................................................................................................................................ 38
8. REALISATION ET TESTS UNITAIRES ................................................................................... 39
8.1 OBJECTIFS DE LA REALISATION.............................................................................................................................. 39
8.2 LES PHASES ............................................................................................................................................................ 39
8.2.1 Lancement (Ph1).................................................................................................................................................................. 39
8.2.2 Dveloppement + tests unitaires (Ph2) ................................................................................................................................. 40
8.3 LES LIVRABLES....................................................................................................................................................... 41
8.4 LES ACTEURS DE LA REALISATION.......................................................................................................................... 41
9. QUALIFICATION MOE ............................................................................................................. 42
9.1 OBJECTIFS ............................................................................................................................................................. 42
9.2 LES PHASES ............................................................................................................................................................ 42
9.2.1 Lancement (Ph1).................................................................................................................................................................. 43
9.2.2 Prparation de la Qualification (Ph2).................................................................................................................................. 43
9.2.3 Excution de la qualification (Ph3)...................................................................................................................................... 44
9.2.4 Prparation de la livraison la MOA (Ph4)......................................................................................................................... 44
9.3 LES LIVRABLES....................................................................................................................................................... 45
9.4 LES ACTEURS DE LA QUALIFICATION ...................................................................................................................... 45
10. RECETTE................................................................................................................................. 46
10.1 OBJECTIFS ............................................................................................................................................................. 46
10.2 LES PHASES ............................................................................................................................................................ 46
10.2.1 Lancement (Ph1).................................................................................................................................................................. 46
10.2.2 Prparation des cas de tests et des jeux d'essais de recette (Ph2) .......................................................................................... 47
10.2.3 Excution de la recette (Ph3) ............................................................................................................................................... 47
10.3 LES 2 TYPES DE RECETTE........................................................................................................................................ 48
10.3.1 La VA.................................................................................................................................................................................. 49
10.3.2 La VSR ................................................................................................................................................................................ 49
10.4 LES LIVRABLES (PRODUITS PAR LA MOA) .............................................................................................................. 49
10.5 LES ACTEURS DE LA RECETTE................................................................................................................................. 49
11. PREPARATION A LA MISE EN OEUVRE........................................................................... 51
11.1 LES PHASES ............................................................................................................................................................ 51
11.1.1 Conduite du changement (Ph1)............................................................................................................................................. 51
11.1.2 Prparation du dploiement (Ph2)........................................................................................................................................ 51
11.1.3 Les acteurs .......................................................................................................................................................................... 51
11.1.4 Livrables ............................................................................................................................................................................. 52
12. MISE EN UVRE / DEPLOIEMENT.................................................................................... 53
12.1 LES PHASES ............................................................................................................................................................ 53
12.2 DEPLOIEMENT........................................................................................................................................................ 53
12.2.1 Dploiement de larchitecture technique (Ph1)..................................................................................................................... 53
12.2.2 Dploiement de lapplication (Ph2)...................................................................................................................................... 53
12.2.3 Reprise des donnes (Ph3).................................................................................................................................................... 54
12.2.4 Complments faire lenvironnement de production (Ph4)................................................................................................... 54
12.3 LOTISSEMENT ........................................................................................................................................................ 54
13. BILAN....................................................................................................................................... 55
14. GARANTIE............................................................................................................................... 56
15. MAINTENANCE / TMA.......................................................................................................... 57
15.1 ORGANISATION ...................................................................................................................................................... 57
15.2 OUTILS................................................................................................................................................................... 57
16. LA QUALITE DANS UN PROJET INFORMATIQUE......................................................... 58
16.1 OBJECTIFS DUN PAQ............................................................................................................................................ 58
16.2 DANS QUELS CAS FAIRE UN PAQ ?.......................................................................................................................... 58
16.3 QUELS ACTEURS PARTICIPENT A LA REDACTION DUN PAQ ?................................................................................. 58
16.4 CONTENU DU PAQ ................................................................................................................................................. 58
17. LES ADAPTATIONS DE LA DEMARCHE........................................................................... 60
17.1 ADAPTATION DE LA DEMARCHE DE CONDUITE STANDARD...................................................................................... 60
17.2 AUTRES DEMARCHES / METHODES DE CONDUITE DE PROJET .................................................................................. 60
17.2.1 RAD..................................................................................................................................................................................... 60
17.2.2 SDM/S................................................................................................................................................................................. 60
17.2.3 Autres dmarches................................................................................................................................................................. 60
18. QUEST-CE QUUN CHEF DE PROJET ?............................................................................ 61
18.1 ROLE DU CPI.......................................................................................................................................................... 61
18.2 QUALITES DU CPI................................................................................................................................................... 61
19. METHODE DEVALUATION DES CHARGES.................................................................... 62
19.1 RATIOS DES ETAPES................................................................................................................................................ 62
19.2 METHODOLOGIES DE CHIFFRAGE DES CHARGES..................................................................................................... 62
1. Introduction
1.1 Informations prliminaires
Prsentation O. MAQUET.
Prsentation de Steria (Steria : acteur de recrutement de nb stagiaires de Master 2
me
anne) ;
Tour de table des tudiants :
lesquels sont issus dun IUT ? dun BTS ? de lIUP 1
re
anne ? ..
Quelles mthodes connues : UML ? Merise ? Remora ?
Quelles expriences en utilisation de mthodes ?
1.1.1 Remarque concernant ce support
Ce document nest pas un support de cours. Beaucoup de sujets ne sont pas dtaills dans ce
document. Par contre, ils le seront loral par lenseignant.
Il est fourni aux tudiants afin de les aider dans leur prise de notes pendant les sances de
cours.
1.1.2 Quelles notes ?
Deux notes, dont :
1 note pour le projet de fin de valeur (env. 4 semaines pour faire le devoir par groupe de 3 ou 4
tudiants max.),
1 note pour un partiel.
1.2 Objectif de M12 Conduite de projet
1.2.1 Objectif du cours
O Introduction :
Prsenter le programme des 15 sances : psentation du planning (vrifier les dates des 15
sances : 30 heures).
O Objectifs du programme des 15 sances :
Prsentation de la dmarche de projet : il sagit dune dmarche gnrique , adapter si
ncessaire aux projets pilots (Gros / Petit ; Forfait / Rgie ; Risques levs / Risques faibles ;
Dveloppement spcifique / Intgration dun progiciel ; etc).
La dmarche est dcrite en termes de :
Organisation MOE / MOA,
Tches raliser,
Livrables produire,
processus qualit,
Prsenter le rle dun CP ou DP dune SSII sur les projets qui doit :
connatre les tapes dun projet,
manager un projet (chef de projet),
planifier et organiser les travaux,
1.3 Introduction la dmarche de conduite de projet
Prsentation d'une dmarche standard (ou gnrique )de conduite de projet : mthode trs
complte, .... adapter en fonction de la taille du projet, des contraintes, (voir le 1.4 Diffrents types
de projets), de la problmatique de chaque projet.... Il sagit dune dmarche prvisionnelle labore
par le CP de la MOE.
Elle sert au CP identifier les tches de la MOE (voire aussi celles de la MOA), son planning, son plan
de charge (entres / sorties) sur le projet, etc
La dmarche finalise est fige dans un PAQ du projet, qui doit faire obligatoirement lobjet dune
validation.
Les tapes de la dmarche standard (ou gnrique ) :
Schma Directeur (SD)
validation livrables MOE & MOA
Etude Pralable (EP)
Etude Dtaille (ED)
Etude Technique (ET)
Ralisation et tests unitaires
Qualification (ou recette interne MOE)
Recette MOA
Prparation la mise en uvre
Mise en uvre / dploiement
Garantie
Tierce Maintenance Applicative (TMA)
Remarques sur la dmarche type :
O La dmarche de Conduite de Projet est structure ainsi :
X tapes,
chaque tape est dcompose en Y phases.
Chaque tape est dfinie par :
des missions raliser (livrables produire),
une organisation spcifique, ct MOA et ct MOE,
des process, outils particuliers, .
O Evolution de la conduite de projet depuis 10 ans :
Evolution des mthodes de conception (des outils de + en + automatiss, ...)
Rle majeur des utilisateurs,
Evolution des architectures techniques,
Les directions Utilisatrices (la MOA), qui financent les projets, veulent y participer, ...
O Il sagit dune dmarche standard dfinie pour un projet complet mener depuis un SD jusquau
dploiement, en passant par un dveloppement spcifique.
La dmarche doit tre adapte la taille du projet, le type de prestations (dveloppement spcifique /
intgration dun progiciel), lorganisation (par exemple, MOE de type SSII ou interne, le montage :
forfait ou rgie, etc, ). Ladaptation est une des 1res tches du CP sur son projet.
O Chaque tape fait lobjet dun ou plusieurs livrables, qui doivent tre valids conjointement par la
matrise doeuvre et la matrise douvrage.
O Lordre des tapes est thorique : dans un planning, les phases, voire les tapes peuvent se
chevaucher.
Exemple : Planning PERT montrant les tapes qui peuvent se chevaucher :
Exemple : description succincte des travaux par tape de la dmarche :
Illustrer la dmarche telle que dcrite ci-dessus laide dun exemple : Bouygues Telecom
Etape Illustration de lexemple
Schma Directeur Bouygues se lance dans les annes 80 dans de nvx mtiers : la tlphonie, do de nvx besoins en
Systme dInformation. Elaboration dun plan dvolution du SI sur 5 ans.
Dfinition dun SI aprs une fusion (Air France / Air Inter).
Etude Pralable Lancement du projet Facturation des services de tlphonie mobile aux client. Besoin dune
application Intranet et Internet.
Elaboration de plusieurs scnarii fonctionnels & techniques.
Choix en fin dEP de lancer un projet de dveloppement Web.
Etude Dtaille Elaboration des spcifications (emploi dUML, Merise ou dune autre mthode telle Merise ou Remora).
Elaboration dune maquette, voire dun prototype.
SD
EP
ED
ET
Ralisation
Qualification
Recette
Prp. Mise en oeuvre
MeO
V. V. V. V. V. V.
Processus dassurance Qualit
Etude Technique Spcification des composants logiciels dvelopper dans larchitecture dfinie par les architectes, sur
la base des spcifications ralises en ED.
Dv. & tests
unitaires
Dveloppement & tests unitaires (chaque dveloppeur teste les composants quil dveloppe)
Qualif. &
intgration
Assemblage et tests fonctionnels de bout en bout de lapplication.
Tests techniques (monte en charge)
Recette Tests par le client de lapplication quil rceptionne.
Pr. de la mise en
uvre
Formation des utilisateurs
Migration des donnes blanc
Mise en oeuvre Mise en production de lapplication qui devient accessible par les utilisateurs + arrt de lancienne
application.
1.4 Diffrents types de projets
La dmarche de conduite de projet prsente dans ce document est dimensionne pour des
projets de dveloppement spcifique.
Les projets diffrents (exemple : projets dintgration de progiciels, ERP, ...) ncessitent une autre
dmarche de conduite de projet, qui nest pas dcrit dans ce document.
Principales caractristiques dun projet :
La dmarche doit tre adapte aux caractristiques suivantes :
1) Type - projet de dveloppement
- projet dintgration de progiciel ou ERP
- projet de migration : fonctionnelle [migration de
donnes] et / ou technique [chgt de version dOracle de
serveur J2EE, ]
2) Architecture - mainframe
- client / serveur
- client lger (Web)
3) Taille du projet - Grand projet (Ex : > 5000 jrs*h)
- Projet moyen (Ex : compris entre 1500 et 5000 jrs*h)
- Petit projet (Ex : < 1500 jrs*h)
4) Fonctionnel - application de gestion, compta, RH
- Dcisionnel, infocentre, datawarehouse,
- industriel (informatique embarqu)
- etc
La dfinition dune dmarche adapte au contexte, objectifs, du projet est une tche du Chef de
projet ou Directeur de projet MOE.
1.5 Les acteurs dun projet informatique
1.5.1 Lorganisation dune Direction des Systmes dInformation (DSI) dune entreprise
DSI
Etudes Production
Domaine 1 Domaine 2 Production Rseaux & Telecom
CP1 CP2 CP3 CP4
1.5.2 Les acteurs de la matrise duvre
Matrise d'uvre (MOE principale / dlgue) :
Cpi,
Concepteurs,
Dveloppeurs,
Experts (rseaux, architectures, produits tels Oracle ou WebLogic, .),
1.5.3 Les acteurs de la matrise douvrage
Matrise d'ouvrage :
Direction utilisatrice dune socit (direction commerciale, DRH, DAF, ),
CPu,
Utilisateurs finaux,
1.5.4 Implication MOE & MOA dans un projet
Les poids des responsabilits MOE & MOA dans les tapes de la dmarche de Conduite de
projet :
Poids MOE Poids MOA
Schma directeur . . . . . . . . . . . . . . . . . . . . . . . . . . *** ***
Etude Pralable . . . . . . . . . . . . . . . . . . . . . . . . . . . *** ***
Etude Dtaille . . . . . . . . . . . . . . . . . . . . . . . . . . . . *** ***
Etude Technique . . . . . . . . . . . . . . . . . . . . . . . . . . . ***
Ralisation et tests unitaires . . . . . . . . . . . . . . . . . . . . . ***
Intgration / Qualification . . . . . . . . . . . . . . . . . . . . . . . ***
Recette : recette MOE + recette MOA + bench (si ncessaire) . . . . * ***
Prparation de la mise en uvre . . . . . . . . . . . . . . . . . . . *** ***
Mise en uvre ( dploiement, ) . . . . . . . . . . . . . . . . . . . ***
Garantie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ***
TMA : tierce Maintenance Applicative . . . . . . . . . . . . . . . . . *** **
1.5.5 Les instances de pilotage
Instances de dcision et darbitrage :
Comit de Pilotage
Comit de Projet / Cellule de Suivi / Point hebdomadaire
Prciser :
leur rles,
les frquences de runions,
les acteurs MOE et MOA impliqus,
limportance de CR de runions.
1.6 Vocabulaire ( expliquer)
1.6.1 Vocabulaire
Expliciter le vocabulaire suivant :
Systme dInformation (dfinies par les SFG),
Systme informatique (dfinies par les SFD),
Architecture physique / logicielle,
conduite de projet,
matrise d'uvre (principale / dlgue),
matrise d'ouvrage / doeuvre
assistance matrise douvrage / doeuvre
chef de projet utilisateur (CPu),
chef de projet informatique (CPi),
instances de pilotage (comit de pilotage & comit de suivi),
rgie (= engagement de moyens),
forfait (= engagement de rsultats),
co-traitance,
sous-traitance,
livrable,
assurance qualit,
Plan dassurance Qualit (PAQ),
Maquette,
Prototype.
1.6.2 Abrviations
SD : Schma Directeur
EP : Etude Pralable
ED : Etude Dtaille
ET : Etude Technique
PAQ : Plan dAssurance Qualit
CP : Chef de projet
Cpi : Chef de projet Informatique (ou chef de projet MOE)
Cpu : Chef de projet Utilisateurs (ou chef de projet MOA)
DP : Directeur de projet
MOE : Matrise dOeuvre
MOA : Matrise dOuvrage
SFG : Spcifications Fonctionnelles Gnrales
SFD : Spcifications Fonctionnelles Dtailles
TMA : Tierce Maintenance Applicative
2. Les outils
Importance des outils dans un projet.
2.1 Les outils de lEP jusqu la mise en production
2.1.1 Les diffrents types doutils
O Les outils bureautiques :
Word,
Excel,
PowerPoint.
O Les outils de conception :
outils de modlisation Merise,
outil de modlisation UML, (ex : Together de Borland ; Rose de Rational Rose, Power-AMC
de Sybase, )
O Les outils de dveloppement :
Les principaux middleware, serveurs Web et serveurs dapplications :
TUXEDO (architectures UNIX pour C/S),
WebLogic (architecture J2EE base d'EJB),
WebSphere (architecture J2EE base d'EJB),
Apache, Tomcat, J-Boss ou Jonaz (open source serveur Web et serveur dapplications pour
une architecture),
CICS (IBM),
TDS (Bull).
Les principaux outils de dveloppement :
J-builder, WebGain pour les dveloppements Java (J2EE),
Dvelopper 2000,
PowerBuilder,
Visual Basic,
NATSTAR, (en perte de vitesse)
PROLIFICS, (en perte de vitesse)
Les framework (bcp dopen source) utiliss en dveloppement dun projet J2EE :
Struts,
Spring,
Hivernate,
EjbGen,
Ant,
Les principaux outils de dveloppement (diteurs):
Eclipse (diteur pour code Java),
TextPad (open source),
WorkShop (outil de BEA utiliser notamment pour dvelopper des webservices).
Les compilateurs.
Les principaux outils de gestion de configuration :
CVS (open source) Et/ou Suversion,
PVCS.
Les principaux outils de gestion des demandes (ou Faits techniques), principalement utiliss en TMA :
MANTIS (open source),
Bugzilla (open source)
etc.
O Les outils de tests (qualification, recette) :
Outil de gestion des plans, des scenarri et des cas de tests (Test Director, Mercury)Outils
permettant dautomatiser les tests de non-rgression.
Les principaux outils de tests :
QA-Run de Compuware,
???? de Mercury.
O Les outils de bench :
outils permettant de simuler la monte en charge dune application (ex : simulation dun nb
dinternautes de + en + nombreux). Utilisation dinjecteurs.
Les principaux outils de bench :
QA-Load de Compuware.
???????? de Mercury.
O Les outils de pilotage & planification :
outils de planification et de suivi des charges (ex : MS-Project, PMW)
O Les outils de qualimtrie (essentiellement utiliss en TMA) :
Ces produits reconnaissent la syntaxe de certains langages de programmation. Ils peuvent
servir mesurer la qualit du code source, identifier du code mort, faire des analyses dimpacts,
Les principaux outils de qualimtrie :

CAST de Cast SoftWare.
System Code dACFO.
2.1.2 Tableau de synthse Outils / Etapes de la dmarche
Tableau de synthse Outils / Etapes de la dmarche :
Outils de
conception
Outils de
dveloppement
Outils de tests Outils de bench Outils de pilotage
et planification +
Outils bureautiques
Schma Directeur
(x) x
Etude Pralable
x x
Etude Dtaille
x x
Etude Technique
x x x
Dv. & tests
unitaires
x x
Qualif. &
intgration
x x x x
Recette
x x x x
Pr. de la mise en
uvre
x x x
Mise en oeuvre
x
Un CP doit vrifier davoir les bons outils au bon moment, avec les ressources humaines matrisant ces
outils
2.2 Les outils dadministration du systme
Les outils ncessaires, une fois lapplication finale mise en exploitation sont les suivants :
sauvegarde / restauration,
ordonnancement des batch (exemple : $UNIVERSE),
Outil de surveillance systme (exemple : PATROL).
3. Rappels MERISE & UML (mthodologies de modlisation)
Ce chapitre nest pas au programme. Il pourra toutefois tre ralis la demande des
tudiants.
3.1 Prsentation de la dmarche par niveaux
Prsentation des 3 niveaux de la mthode MERISE.
Prsentation des rles des niveaux conceptuel, ... physique.
Les modles MERISE.
Donnes Traitements Flux
Conceptuel MCD MCT, CVO MCC
Organisationnel MOD MOT MOC
Logique MLD (+ rparti) MLT (+ rparti)
Physique MPD MPT
Rappel de l'historique de MERISE (anne 78 ce jour).
Principe de modlisation :
sparation donnes / traitements,
proccupations distinctes suivant le cycle dabstraction.
MERISE = Modles + dmarche de Conduite de projet.
Les volutions de Merise : Merise/OO, Merise/2,
3.2 UML (rappel)
3.2.1 Le diagrammes des cas dutilisation (Use case)
Prsentation des concepts du diagramme UML.
3.2.2 Le diagrammes des classes
3.2.3 Le diagrammes dtats - transitions
3.2.4 Le diagrammes de squences
3.3 MERISE (rappel)
3.3.1 Le modle des flux (rappel)
Prsentation des concepts du MCC :
domaine,
acteur,
flux dinformation,
proprit.
Prsentation du cas Compagnie dassurance IARD traitement d'un sinistre auto .
3.3.2 MCD (rappel)
Prsentation des concepts du MCD :
entit,
relation,
cardinalits,
proprit.
Exercice : cas Hotel ou autre.
3.3.3 MLD relationnel (rappel)
Rappel de la thorie.
Prsentation de rgles de migration d'un MCD en un MLD/Rel.
Exercice : cas Hotel ou autre.
3.3.4 MCT (rappel)
3.3.5 MOT (rappel)
4. Schma Directeur
4.1 Les 2 niveaux de SD
2 types de SD :le schma Directeur stratgique et le schma Directeur oprationnel du SI.
Schma Directeur stratgique
Schma Directeur des SI
4.2 SD stratgique
4.2.1 Dfinition
Schma Directeur Stratgique : dfinition de la stratgie de l'entreprise 5 ans, voire jusqu 10 ans.
Trs important pour les entreprises pour le mtiers voluent, ou suite
une fusion,
Exemples de cas ou des SD stratgiques ont t raliss :
fusion Air France + Air Inter,
fusion Carrefour + Promods.
Bouygues : volution du BTP vers les tlcoms,
Vivendi Universal : volution du mtier du distributeur deau (ex-CGE) aux mtiers du multimdia
(CEGETEL/SFR, ).
Dans ce 1
er
type de SD, on traite tous les impacts.
Exemple des aspects traiter dans un SD stratgique :
Dans la fusion Air France + Air Inter, on labore des macros plan dactions concernant :
o fusion la fusion des divisions de 2 socits (fusion des 2 directions financires, des 2 directions
des RH, des 2 directions du personnel navigant, ). A la cl, prvision de plan dembauche
et/ou licenciement,
o dlocalisation de certaines structures. par exemple, le sige complet Charles de Gaulle,
rduction des effectifs bass Orly,
o homognisation du parc davions (par exemple, prvoir sur un horizon de qqes annes
dhomogniser le parc des avions : tout Airbus ou tout Boeing, afin de rduire les cots de
maintenance, les cots de formation des pilotes, etc
o restructuration des lignes dsservies : prvision dlimination des lignes redondantes +
crations de nouvelles lignes desservir,
o etc
4.2.2 Les acteurs
Directions Gnrales,
Socits de Conseil ou Consultants Top manager (ex : Alain MINC, ex-PDG, ).
4.3 SD du SI
4.3.1 Dfinition
Mise en uvre du SD stratgique de lentreprise sur le SI ;
Planification des projets lancer un horizon de 2/3 ans ;
Dfinition des moyens ncessaires la ralisation :
o primtre des projets,
o architecture physique du SI,
o budgets,
o ressources,
o macro-planning,
Rq : Dfinir les 2 termes : Systme dInformation et Systme Informatique
Exemple des aspects traiter dans un SD du SI :
Dans lvolution de Bouygues vers la tlphonie mobile, il faut identifier :
o les projets informatiques lancer avec une 1
er
bauche de leur contenu fonctionnel et de leur
architecture respectifs + dfinir un macro planning de ces projets sur les 2/3 ans venir,
o les budgets de la DSI ncessaires pour raliser les projets sur les 2/3 ans venir,
o envisager des embauches au sein de la DSI,
o etc
4.3.2 Les acteurs
DSI
Prciser le rle des cabinets de conseil (Price WaterHouse, Ernst & Young, Andersen
Consulting, Orgaconseil, ).
Systme dInformation
Systme informatique
5. Etude Pralable
5.1 Objectifs de ltape
Objectifs de ltape pour la MOE :
comprendre les besoins de la MOA et laborer une de plusieurs solutions fonctionnelles et
techniques chiffres (cots de mise en uvre + cots de fonctionnement jusqu 5 ans, ). Par
exemple :
dveloppement spcifiques / Intgration dun progiciel ou dun ERP (PeopleSoft, Oracle
Applications, SAP R/3, Oneworld de JD Edwards, ....) ;
architecture X-Net / architecture C-S,
choix obligatoire dune solution unique pour poursuivre vers lEtude Dtaille, parmi les plusieurs
solutions proposes. Chacune des solutions prposes aux instances de pilotage pour dcision doit
tre accompagne du chiffrage des charges, des cots, dun planning et dun recensement des
avantages & inconvnients.
5.2 Les phases de lEP
Les phases de lEP :
Lancement (Ph1),
Bilan de lexistant (Ph2),
Dfinition des orientations (Ph3),
Modlisation du systme cible / SER (Ph4),
Validation et dcision (Ph5).
5.2.1 Lancement de l'EP (Ph1)
O Mise en place de lorganisation du projet :
Organisation MOE + organisation MOA + instances de pilotage du projet :
Matrise duvre - Matrise douvrage,
Assistance Matrise duvre (si ncessaire) - Assistance matrise douvrage (si ncessaire),
Chef de projet informatique (CPI) - Chef de projet utilisateur (CPU),
Les profils de la MOE les + courants pour une EP (sous la responsabilit du CPi) :
o Concepteurs,
o Architectes,
o Experts possibles :administration des donnes, expert technique, ergonome (si
maquettage faire en EP), responsable Qualit (ventuellement pour le PAQ), ...
Mise en place des instances de pilotage du projet (les + courantes)
o Comit de projet,
o Comit pilotage,
Charges / Planning / Cots :
o Charges et planning prcis pour lEP
o Charges et planning estims pour les tapes suivantes : actualiser au fur et mesure de
lavancement du projet.
Planning des instances de pilotage dfinir
Planning runions avec les utilisateurs dfinir
Remarque :
Dans le planning, indiquer la dure de chaque tche raliser, les dates prvisionnelles de
livraison des livrables, les dates des instances de pilotage du projet, les dates prvisionnelles des
runions de travail avec la MOA
O Choix des mthodes de conception :
pour les architectures logicielles non objet (mainframe ou C/S), privilgier Merise,
pour les architectures logicielles objet (Web de type J2EE), privilgier :
Merise donnes pour la modlisation du MCD au MPD,
UML pour la modlisation de la partie dynamique (diagr. de classes, de cas dutilisation,
dtats-transitions, de squences),
O Mise en place de la plate-forme de conception :
un environnement bureautique complet (OFFICE),
outil de suivi de projet (PSN6, MS-Project, PMW),
outil de conception (MEGA, POWER*AMC),
outil de maquettage (a priori loutil de dveloppement).
O Rdaction et validation du PAQ par les 2 parties :
Le PAQ doit tre valid immdiatement (c--d ds la fin de la phase de Lancement) par la MOE et la
MOA document contractuel entre les 2 parties (il engage les 2 parties).
5.2.2 Bilan de l'existant (Ph2)
Modlisation limite aux SFG par rtro-ingnierie de lapplication existante limite le + souvent un
SER Bilan fonctionnel et technique : a minima modlisation des donnes du systme existant, afin
de construire un nouveau modle des donnes dans lequel on sera migrer les donnes de lapplication
existante.
Expliquer SFG et SFD.
Prciser comment dfinir un Sous Ensemble Reprsentatif (SER).
Rq : Expliquer la diffrence entre SFG et SFD.
5.2.3 Dfinition des orientations (Ph3)
Suivant la taille du projet, les enjeux, les risques, possibilit de prvoir plusieurs scnarios pour la
cible :
Scnario(s) fonctionnel(s) + scnario(s) technique(s) classs du plus complet (donc le + cher)
au plus sobre (donc le cher). En rgle gnrale, la MOE propose 3 scnarios max.
Chacun des scnarios va tre spcifi sur un SER, les avantages & inconvnients vont tre identifis,
les charges & cots de chacun seront mesurs,
Exemple, pour un projet de GRH :
Possibilit de revamper (r-habillage) dune vieille application mainframe, pour la rendre
accessible via un intranet,
Possibilit de mettre en uvre un progiciel. Aprs tude du march, on retiendra 2 ou 3
progiciels cible tudier,
Possibilit de r-crire une application from scratch .
5.2.4 Modlisation du systme cible / SER (Ph4)
5.2.4.1 Modlisation du fonctionnel
Sur les projets Nouvelles Technologies (NTIC), privilgier lemploi dUML pour la modlisation des
traitements du systme cible, la mthode MERISE. Toutefois, il est recommand de modliser le
MCD/MLD en plus du diagramme de classes UML, pour les raisons suivantes :
MCD/MLD : Modlisation du systme de stockage des donnes (modle statique).
diagramme de classes UML : Modles mtiers, servant la dfinition des classes mtiers dune
architecture applicative.
Modlisation du systme cible, ventuellement sur un SER.
Modlisation avec une mthode (Merise, UML). Possibilit de mixer les 2 pour les projets X-Net.
Production des SFG (Vision Systme dInformation) : laborer avec Merise et/ou UML.
Rq : Faire des rappels MERISE / UML.
La modlisation peut se faire sur ou plusieurs scnarios identifis en Ph3.
O Cas dune recherche dun progiciel ou ERP :
1. Analyse de loffre des progiciels du march. Slection de 2 5 progiciels max. tudier.
2. Analyse des fonctionnalits du progiciel pour dterminer le taux de couverture du progiciel des
besoins exprims par la MOA.
3. Identification des fonctionnalits qui devront aux cts du progiciel.
5.2.4.2 Initialisation de larchitecture technique cible
O Types darchitectures physiques :
Architecture physique : ensemble des moyens comprenant les serveurs, les PC, logiciels de base
(OS, SGBD, serveurs dapplications), les rseaux WAN et LAN ncessaires
au fonctionnement de lapplication cible
Les types darchitectures physiques possibles :
architecture mainframe avec PC en mulation (mode caractre),
architecture client serveur (client "lourd"),
architecture Web : Intranet / Extranet / Intranet (client "lger").
Initialiser larchitecture physique cible :
OS du serveur (Ex : UNIX ou Linux ou NT),
SGBD (Ex : Oracle, SQL-Server, ou MySQL)
Serveur dapplication (Ex si J2EE : WebLogic, WebSphere ou JBOSS, )
Pour un projet avec une architecture J2EE, on peut proposer plusieurs variantes :
WebLogic + Oracle,
ou Jboss (voire Jonaz) + Oracle, Utilisation dune architecture open source
Exemple :
Schma de larchitecture physique de www.anpe.fr
2 Radware (rpartiteurs)
sur 2 serveurs Linux
3 instances Apache
sur 3 serveurs Linux
(compression des pages Web)
12 instances
WLS sur 6 serveurs
Linux
2 instances Oracle en mode Rack
sur 2 serveurs Unix (Solaris)
Exemple :
Tl-IR : + 200 serveurs physiques dans la priode saisie de lIR.
O Types darchitectures logicielles :
Architecture logicielle : Structure interne dune application, c--d lensemble des composants
logiciels dvelopper.
Exemple : Pour une architecture logicielle J2EE, cest lensemble des pages HTML, JSP, servlets,
EJB, Shell, procdures stockes, composant lapplication. Les composants dvelopper
doivent respecter la norme J2EE en vigueur (en , J2EE v1.1).
Serv. UNIX Serv. UNIX
Serv. Linux
WL WL
Serv. Linux
WL WL
Serv. Linux
WL WL
Serv. Linux
WL WL
Serv. Linux
WL WL
Serv. Linux
WL WL
Serv. Linux
Apache
Serv. Linux
Apache
Serv. Linux
Apache
Serv. Linux
Radware
Serv. Linux
Radware
Exemple :
Schma dune architecture logicielle du type J2EE (norme v2.0 , modle MVC, ) :
Page HTML
JSP
Servlet
EJB Session
EJB Entity
Table(s) du MPD relationnel
Dfinir :
Les avantages / inconvnients de chaque scnario,
Les charges / dlais (planning) de chaque scnario,
Les cots de chaque scnario (prciser les cots dinvestissement et les cots de
fonctionnement (par exemple, sur 5 ans)
On pourra utiliser une grille avec diffrents critres noter, en sappuyant sur des coefficients pour
calculer une note finale et donc justifier la prfrence de la MOE / ou de la MOA.
Pour les dveloppement en architecture J2EE, on pourra utiliser des open source (de + en +
nombreux) :
CVS, subversion pour la gestion de config.,
ant ou spring pour la compilation (*.jar, *.war, *.ear),
ejbgen pour la gnration dses squelettes des EJB,
Struts, pour le dv. de la couche prsentation (framework),
Hibernate,
5.2.5 Processus de validation et dcision (Ph5)
O Finalisation de la production des livrables de lEP :
Finaliser la rdaction des documents, notamment en compltant les parties suivantes :
Dcoupage (si ncessaire) en sous-projets pour les tapes suivre ; dcoupage conseill pour
les grands projets (> 2000 j*h).
EP
ED ET Ral
.
Qualif.
Recette MeP
Sous-projet 1
ET Ral
.
Qualif.
Recette MeP
Sous-projet 2
ED
Actualisation des avantages et inconvnients de chacun des scnarios proposs.
Actualisation des charges de la MOE et des dlais (planning) pour poursuivre le projet jusqu
sa fin.
O Processus de validation et de dcision :
Processus de choix dune solution en fin dtape: comit de projet + comit de pilotage (voire du
comit de direction de lentreprise). 3 dcision possibles :
poursuite sans rserve,
restriction du primtre,
arrt du projet (en gnral si impossibilit avec le budget prvu).
Pour le CPi charg de cette prsentation, il est important dtre synthtique, de montrer les avantages
et inconvnients de chaque solution, de prsenter les budgets prvisionnels associs chacune des
solutions et (ventuellement) de prsenter sa prfrence.
Pour un Comit de Pilotage, on prvoira des slides PowerPoint, en accompagnement des livrables.
Aprs que le Comit de Pilotage ait valid la solution, on peut lancer, avec son accord lED (ou les ED
en cas de lotissement en plusieurs sous-projets).
5.3 Livrables de l'EP
Les livrables de lEtude Pralable :
Note de lancement de lEP (facultatif) (issue de Ph1),
Plan dAssurance Qualit (PAQ) (issue de Ph1).
Dossier de fin dEtude Pralable (aspects fonctionnels) (*)
Dossier darchitecture technique :
Architecture physique (config. des machines, rseaux, )
Architecture logicielle (organisation des composants logiciels par rapport un schma type).
(*) Le dossier de fin dEtude Pralable contient a minima (en gnral sur un SER) les modles MERISE
ou UML suivants :
un MCD,
un diagramme des cas dutilisation (ou Use case),
un diagramme des classes,
Ces diagrammes UML et modles MERISE ne sont pas finaliss. A titre dexemple, le MCD contient
90%-95% des entits et associations et (par exemple) 50% des attributs des entits et associations.
5.4 Importance du processus Qualit
Le PAQ est un contrat qualit entre le matre doeuvre et le matre douvrage :
dmarche de conduite de projet (avec ses livrables) adapte la problmatique du projet,
dfinition de l'organisation du projet : MOE, MOA et instances de pilotage
description du primtre du projet,
description des ressources (effectifs, charges, plannings, outils, ...),
Les SSII se font certifier par lAFAQ (ISO9001).
Normes : ISO9001, CMMI, ITIL.
5.5 Les acteurs de l'EP
O Les acteurs d'un projet en tape dEP :
matrise d'uvre (voir les acteurs) + assistance MOE,
matrise d'ouvrage (voir les acteurs) + assistance MOA.
Expliquer les diffrents profils des acteurs MOE & MOA pour une Etude Pralable.
Prciser les profils des acteurs de la MOE et de la MOA pour une EP. Pour la MOE, on citera plus en
dtails :
le rle du concepteur : bonne connaissance des mthodes de modlisation, capable dtre
force de proposition auprs de la MOA,
le rle de larchitecte : laboration de larchitecture logicielle et de larchitecture physique,
laboration des N&S de dveloppement, garant de lutilisation des N&S,
le rle de ladministrateur des donnes : garant de la cohrence des donnes, optimisation
des modles conceptuels et logiques), consolidation des modles multi-projets,
le rle de lergonome (assimile MOE ou MOA),
le rle de la MOE ayant une bonne bonne connaissance de lancien systme informatique
(celui qui sera arrt lissue de la mise en production de la nouvelle application) : rtro-
documentation, prparation llaboration des SFG/SFD du processus de migration des
donnes,
O Les instances de pilotage en tape dEP :
runions mensuelles pour le comit de pilotage,
runions hebdomadaires pour le comit de projet.
Prciser le rle, les objectifs, les participants aux instances de pilotage.
6. Etude Dtaille
Introduire le vocabulaire suivant :
SFG,
SFD,
maquettage,
prototypage.
6.1 Objectifs de l'ED
Dans lhypothse dune solution cible dvelopper en spcifique, les objectifs de ltape pour la MOE
sont les suivants :
Complter les SFG initialises en EP & laborer les SFD avec la collaboration de la MOA sur la
base de la solution valide en fin dEP,
Prparer le lancement de la conception technique (passage dune proccupation Systme
dinformation Systme informatique ).
Faire valider tous les livrables de lED avant de passer ltape suivante. La solution spcifie en
ED doit tre accompagne du chiffrage des charges, des cots, dun planning pour tre prsente
aux instances de pilotage.
6.2 Les phases de l'ED
Les phases de l'ED sont :
Lancement (Ph1)
Complments des SFG (Ph2)
Elaboration des SFD Donnes + Traitements (Ph3),
Dfinition de l'architecture technique (Ph4),
Validation et dcision (Ph5).
6.2.1 Lancement (Ph1)
O Adaptation de lorganisation du projet aux proccupations de lED :
Matrise duvre - Matrise douvrage,
Assistance Matrise duvre (si ncessaire) - Assistance matrise douvrage (si ncessaire),
Chef de projet informatique (CPI) - Chef de projet utilisateur (CPU),
Equipe MOE (concepteurs, architecte, ) - Utilisateurs
Les profils de la MOE les + courants pour une ED (sous la responsabilit du CPi) :
o Concepteurs (avec des comptences en maquettage et/ou prototypage),
o Architectes,
ncessaire), responsable Qualit (ventuellement pour la MJ du PAQ), ...
Mise en place des instances de pilotage du projet (les + courantes)
o Comit de projet,
o Comit pilotage,
Charges / Planning / Cots
Planning des instances dfinir
o Charges et planning prcis pour lED
O Mise niveau (si ncessaire) de la plate-forme de conception :
par exemple, outil de conception Merise &/ou UML,
par exemple, installation doutil de maquettage (a priori compatible avec loutil de dveloppement).
O Actualisation du PAQ et validation par les 2 parties :
Dans la plupart des cas, il sagit de la mise jour du PAQ initialis en dbut dEP.
Importance du rle d'un PAQ faire dans l'tape de lancement.
Le PAQ devra dcrire valider les procdures visant garantir la qualit du processus.
l'organisation de la MOE, de la MOA, des instances de pilotage : frquence des runions,
rdacteur de l'OJ, rdacteur du CR,
les livrables produire,
les ressources ncessaires la bonne ralisation de ltape (serveur, postes, licences, .),
le planning (mettre en vidence le chemin critique, expliciter les tches de la MOE, de la MOA, )
les modalits de validation d'un livrable,
les modalits de livraison d'une nouvelle version, etc
6.2.2 Complment des SFG (Ph2)
Rappel : SFG Vision Systme dInformation .
Raliser les complments des SFG bauches en EP, c--d sur 100% du domaine tudi, et non
plus par rapport au SER.
Les SFG finales dcriront la cible atteindre. Cette cible sera dcrite avec :
o les diagrammes UML : Diagr. des cas dutilisation, diagr. de classes,
o les modles MERISE : MCD, etc
6.2.3 Elaboration des SFD Donnes + Traitements (Ph3)
Rappel : SFD Vision Systme informatique .
Systme dInformation
Systme informatique
6.2.3.1 Elaboration de N&S (Ph3.1)
Elaboration des normes et standards dun projet (elles sont labores par la MOE, mais elles peuvent
aussi tre fournies par la MOA) :
standards ergonomiques (charte graphique, feuilles de style, ),
standards de dveloppement (rgles de nommage des donnes, des fichiers, rgles de
dveloppement, )
standards dutilisation du SGBD.
6.2.3.2 Elaboration des SFD (Ph3.2)
Elaboration des SFD :
des donnes : MCD complet + MPD.
des traitements de la cible :
traitements transactionnels (TP) :
(Ncssit dune charte dergonomie, charte graphique, feuille(s) de style)
+ application TP Cible Maquette ou prototype dvelopper,
traitements batch :
+ des traitements dinterfaces
+ des traitements de migration des donnes (programmes de dchargement et de
rechargement),
de manire facultative :
+ des systmes transitoires (expliquer le fonctionnement d'un lotissement),
application TP / systme transitoire Maquette ou prototype dvelopper,
+ des processus dgrads.
application TP / systme dgrad Maquette ou prototype dvelopper,
Pour lensemble des SFD, on peut modliser les processus laide des mthodes Merises ou UML.
Maquettage / prototypage :
Importance :
du maquettage (si possible avec loutil de dveloppement, afin de r-utiliser). Objectif du
maquettage : valider l'IHM et l'ergonomie par les utilisaux finaux.
du prototypage. Objectif : valider certains aspects techniques du dveloppement (ex.
dveloppement en JAVA sur LINUX, afin de vrifier la faisabilit et les performances futures)
Dans la mesure du possible, maquetter 100% des crans de lapplication cible.
Systme dgrads :
3 types de systmes dgrads (objectif : pallier un dysfonctionnement temporaire du systme
informatique normal , tel quune panne dun serveur, une panne du LAN ou du WAN,
+ Fonctionnement manuel (sans ressources informatique)
+ Hardware : redondance des quipements informatiques (matriels et rseaux),
Indispensable pour une architecture scurise (disponibilit = 99,9% du temps)
+ Software : traitements de reprise ncessitant des dveloppements TP & batch.
Exemples de conception de systmes dgrads :
Solutions hardware (la majorit des cas) :
redondance des quipements informatiques (matriels et rseaux) qui permettent de maintenir une
activit permanente dune application en production, y compris lorsque une partie des quipements
sont en panne ou arrts pour raisons de maintenance technique ou de dploiement dune
nouvelle version logicielle :
Redondance des instances WebLogic, des instances Apache dans une application J2EE,
Utilisation de loption Oracle Parallel Server (OPS) dOracle.
Sites de backup (exemple : rappeler l'incendie du sige du Crdit Lyonnais, et sa facult
redmarrer les applications en quelques heures) sites en doublon dont le lieu est tenu
secret.
Solutions software (la minorit des cas) :
processus dgrads (salle de march dans une banque, contrle arien, salle de contrle d'une
centrale nuclaire) : solutions TP et/ou batch imaginer.
Systme transitoires :
Dfinition dun lotissement + impacts (charges, contraintes pour les utilisateurs, ...).
Exemple de systme transitoires :
Dans le cadre dun lotissement du systme de paie de tous les fonctionnaires du Ministre de
lEducation Nationale, il faut dfinir le systme de paie dans lancien ou le nouveau systme, selon si la
catgorie des fonctionnaires payer fait partie du lot dvelopper (ou pas).
6.2.4 Dfinition de larchitecture physique (Ph4)
Objectif de cette phase :
dfinir les moyens ncessaires l'architecture technique (architecture physique + architecture
rseaux) et aux environnements de dveloppement,
dfinir les moyens ncessaires l'architecture technique et aux environnements de tests MOE, de
recette MOA, de bench ; voire galement de formation
dfinir les moyens ncessaires l'architecture technique et lenvironnement de dploiement.
Dfinir pour chacun des serveurs utiliss en dv, recette, bench, production :
La RAM,
lespace disque utile,
les licences SGBD, serveurs dapplications,
les machines sur lesquelles il faut installer des compilateurs, un outil de gestion de conf.,
des licences de bench, etc
Les diffrents types de clients - serveurs : faire schma du Gartner Group :
architecture mainframe,
revamping,
client-serveur (client lourd ),
architecture Web (client lger ),
architecture centralise / distribue,
etc ...
Choix de larchitecture technique cible :
Rseau Wan et LAN. Par exemple, IP indispensable pour application X-Net,
serveur UNIX ou NT + dfinition de sa configuration (RAM, CPU, espaces disques, RAID1/5,
machine de backup, )
client - serveur (2 ou 3 tier) ou X-Net (INTRANET, INTERNET),
PC lger ou lourd ,
SGBD : ORACLE, INFORMIX, SYBASE, ...
choix des outils de conception / dveloppement / tests / etc...
ordonnancement des batch,
Scurit de larchitecture dans lenvironnement de production redondance des serveurs, des LS,
utilisation du systme RACK (oracle),
6.2.5 Validation et dcision (Ph5)
Importance de la validation du dossier de fin dEtude Dtaille = contrat entre la matrise duvre
(MOE) et la matrise douvrage (MOA).
Pour le CPi charg de cette prsentation, il est important dtre synthtique, de montrer la matrise
technique et fonctionnelle du projet.
Pour un Comit de Pilotage, on prvoira des slides PowerPoint.
Plusieurs dcisions possibles :
Validation des SFD ralises, de larchitecture dcrite ; ainsi que lenveloppe des charges et le
planning propos ;
Demande de rvision des SFD, par exemple si dpassement du budget prvu
En cas de projet trop gros, possibilit de lotissement des travaux jusqu la mise en production
incluse :
Aprs que le Comit de Pilotage ait valid la solution, on peut lancer, avec son accord lET.
6.3 Les acteurs de l'ED
O Les acteurs d'un projet en tape dED :
EP ED
ET Ral
.
Qualif.
Recette MeP
Sous-projet 1
ET Ral
.
Qualif.
Recette MeP
Sous-projet 2
Prciser les profils des acteurs de la MOE et de la MOA pour une ED. Pour la MOE, on citera plus en
dtails :
le rle du concepteur : bonne connaissance des mthodes de modlisation, capable dtre
force de proposition auprs de la MOA,
le rle de larchitecte : laboration de larchitecture logicielle et de larchitecture physique,
laboration des N&S de dveloppement, garant de lutilisation des N&S,
le rle de ladministrateur des donnes : garant de la cohrence des donnes, optimisation
des modles conceptuels et logiques), consolidation des modles multi-projets,
le rle de lergonome (assimile MOE ou MOA),
le rle du maquetteur (ou dveloppeur HTML pour une maquette Web).
le rle de quelques experts : expert SGBD, expert en architecture,
O Les instances de pilotage en tape dED :
6.4 Livrables de l'ED
Les livrables de lEtude Dtaille :
Note de lancement de lED (facultatif),
Plan dAssurance Qualit (si mis jour) A faire valider en fin de phase Ph1 par la MOA
Dossier de fin dEtude Dtaille (*),
Dossier darchitecture technique (**),
(*) -- Le dossier de fin dEtude Dtaille contient les SFG & SFD dcrivant le systme cible. A minima,
on trouve :
MCD,
un diagramme des cas dutilisation (ou Use case),
un diagramme dtats transitions,
un diagramme des classes,
une maquette ou un prototype
(**) Le dossier darchitecture technique contient,a minima. :
lbauche de larchitecture logicielle cible (qui sera le socle pour faire lET)
une description de larchitecture physique pour les environnements de dveloppements de
tests et de production,
7. Etude Technique
7.1 Objectifs de lET
LEtude Technique est une tape charnire entre les tapes de conception prcdentes et ltape de
ralisation qui suit (passage dune proccupation Systme dinformation une proccupation
Systme informatique ).
Lobjet de lEtude Technique est de prparer le travail des dveloppeurs, en dcrivant (spcifications
techniques) de tous les composants logiciels dvelopper (pour une architecture J2EE, il sagit de
dcrire les spcifications techniques des EJB Entity et Session, des servlet, JSP, des procdures
stockes (si Oracle), etc).
LEtude Technique est une tape 100% MOE. La MOA est donc peu active pendant cette tape. Elle
participe toutefois aux instances de pilotage (travail de suivi des travaux de la MOE).
En entre :
Les SFD (issus de lED).
En sortie :
Les normes et standards de dveloppement,
Les spcifications techniques (vritables dossiers de programmation pour les dveloppeurs),
Scripts de cration du schma de la base de donnes (script SQL).
7.2 Les phases
Les phases :
Lancement (Ph1)
Elaboration des spcifications techniques (Ph2)
Mise en uvre de la plateforme de dveloppement (Ph3).
O Adaptation de lorganisation du projet aux proccupations de lET :
Matrise duvre
Assistance Matrise duvre (si ncessaire)
Chef de projet informatique (CPi)
Les profils de la MOE les + courants pour une ET (sous la responsabilit du CPi) :
o Concepteurs/dveloppeurs (avec des comptences en dv. dans larchitecture logicielle
cible prvue ;),
o Architectes,
ncessaire), responsable Qualit (ventuellement pour la MJ du PAQ), ...
Planification des instances de pilotage du projet pour la dure de lET :
o Comit de projet,
o Comit pilotage,
Charges / Planning / Cots
Planning des instances dfinir
o Charges et planning prcis pour lET
O Mise niveau (si ncessaire) de la plate-forme de conception technique :
par exemple, outil de conception Merise &/ou UML,
par exemple, installation doutil de maquettage (obligatoirement compatible avec loutil de
dveloppement).
O Actualisation du PAQ et validation par les 2 parties :
Dans la plupart des cas, il sagit de la mise jour du PAQ initialis en dbut dEP et complt en ED.
Importance du rle d'un PAQ faire dans l'tape de lancement.
Le PAQ devra dcrire valider les procdures visant garantir la qualit du processus.
l'organisation de la MOE, de la MOA, des instances de pilotage : frquence des runions,
rdacteur de l'OJ, rdacteur du CR,
les livrables produire,
les ressources ncessaires la bonne ralisation de ltape (serveur, postes, licences, .),
le planning (mettre en vidence le chemin critique, expliciter les tches de la MOE, de la MOA, )
les modalits de validation d'un livrable,
les modalits de livraison d'une nouvelle version, etc
7.2.2 Elaboration des spcifications techniques (Ph2)
7.2.2.1 Prparation du cadre du dveloppement
Prparer le cadre du dveloppement :
Rdiger le dossier N & S de dveloppement ( Guide du dveloppeur ),
Rdiger le dossier Guide de gestion de configuration (avec CVS/Subversion, PVCS, ),
Rdiger le dossier Norme de livraison ,
Gestion de configuration des composants logiciels
La Gestion de config. consiste grer les versions dun mme composant logiciel. Par exemple,
connatre le source :
La version du composant source mis en production (dernire version du source mis en production),
La version du composant source en cours de recette,
La version du composant source en cours de qualification,
La version du composant source en cours de dveloppement.
Indispensable sur les gros projets (un mme source peut tre modifi par X personnes), en TMA,
7.2.2.2 Identification des composants logiciels dvelopper
Identifier les composants logiciels dvelopper partir des SFD, sur la base dun dossier de
larchitecture logicielle type ( rdiger dans cette tape).
En entre :
+ Les SFD,
+ Les N& S de dveloppement (les rgles de nommage, les rgles du dveloppement regroups
ventuellement dans un dossier appel le Guide du dveloppeur ).
En sortie :
+ Identification des composants logiciels dvelopper Dossiers de programmation (pour les
traitements),
+ Scripts de cration du schma de la base de donnes (script SQL)
Exemple n1 :
Schma dune architecture logicielle du type J2EE
Page HTML
JSP
Servlet
EJB Session
EJB Entity
Table(s) du MPD relationnel
Identifier les composants logiciels dvelopper par rapport larchitecture logicielle J2EE type dcrite
ci-dessus.
Exemple n2 :
Choisir larchitecture systme adapte la taille du projet (nb accs simultans, volumes de donnes
stockes en BS, etc ) pour lenvironnement de production.
Petit projet Projet moyen Grand projet
HTML HTML HTML
PHP EJB (J2EE) EJB (J2EE)
JBOSS WebLogic
MySql MySql Oracle Oracle
(scnario 1) (scnario 2)
MySql : open Source
JBOSS : open source
Pour les petites architectures, privilgier les open source ou les produits livres.
7.2.3 Mise en uvre de la plateforme de dveloppement (Ph3)
O Mise en place des plateformes ncessaires au bon droulement du projet :
+ Installation du serveur et des postes de dv,
+ Installation des licences de dveloppement (framework, serveur dapplication, SGBD, etc)
+ Installation des compilateurs. Par exemple, compilateurs C, Java, pour un ou plusieurs OS
cible (par exemple AIX, HP-UX, Solaris, ) (cas de lAP-HP).
O Cration des N environnements ncessaires au bon droulement du projet :
+ Cration des environnements dont la MOE aura besoin pour toutes les tapes venir jusqu la
fin de la recette + La MOA devra galement dfinir les environnements dont elle a besoin
notamment pour la recette.
+ Exemple : utilisation de 4 serveurs physiques pour hberger 5 environnements ncessaires au
projet :
Remarques :
O Prvoir un environnement de bench seulement si cest ncessaire.
O Indiquer quelle population utilise chacun des environnements :
Tableau : Environnements ncessaires / types dacteurs :
MOE MOA
Env. de dv. Equipe de projet MOE
Env. de qualif. & intgration Equipe de projet MOE
Env. de recette (VA) Equipe de recetteurs
Env. de formation Formateurs
Env. de bench Equipe de Projet MOE +
Production
Env. de production Production
Env. de
dv.
Env. de
qualif. &
intgration
Env. de
recette
VA
Env. de
bench
Env. de
production
Sources &
binaires
Sources &
binaires
Sources &
binaires
Sources &
binaires
Serveur physique de dv./ qualif. Serveur physique
de recette
Serveur physique
de bench
Serveur(s) physiques
de production
Sources &
binaires
O Indiquer quel(s) environnement(s) utiliss chaque tape de la dmarche :
Tableau : Environnements ncessaires / Etapes de la dmarche :
Env. de dv. Env. de qualif.
& intgration
Env. de
recette (VA)
Env. de bench Env. de
formation
Env. de
production
Nb prvoir Un ou
plusieurs,
suivant le
projet
Un ou plusieurs,
suivant le projet
Un ou
plusieurs,
suivant le
projet
Un Un ou
plusieurs,
suivant le
projet
Un
Obligatoire /
facutatif
Obligatoire Obligatoire Obligatoire Facultatif Facultatif Obligatoire
Schma Directeur
Etude Pralable
Etude Dtaille
Etude Technique
x
Dv. & tests
unitaires
x (x)
Qualif. &
intgration
x x (x)
Recette
x x x (x)
Pr. de la mise en
uvre
x
Mise en oeuvre
x
T.M.A.
x x x x x x
O Installation des logiciels appropris pour chaque environnement :
Logiciels installer dans tout environnement :
Instance du SGBD + cration du schma de la base de donnes
Instance du moniteur transactionnel (ou serveur dapplication),
Autres logiciels installer dans lenvironnement de Dveloppement :
compilateurs
framework
outils de dveloppement
Autres logiciels installer dans les environnements de tests (qualif & recette VA) :
Outils de tests non-rgression
Autres logiciels installer dans les environnements de tests de bench :
Outils de tests de bench
Autres logiciels installer dans les environnements de tests de production :
Automate de production (ex : $Universe)
outil de surveillance (ex : Patrol)
Automate de sauvegarde
O Cration de la base de donnes, sous le SGBD prvu (Oracle ou autre).
Cration dune instance de la base de donnes dans lenv. de dveloppement ;
initialisation des donnes (=chgt des tables de rfrence et cration de petits jeux de donnes
pour les tables Mtiers).
7.2.4 Fin de lEtude Technique
Pas de validation comme dans les tapes prcdentes (une MOA est rarement capable de valider les
rsultats de cette tape, totalement interne la MOE).
7.3 Les livrables
Dossiers de conception technique (identifiant et spcifiant lensemble des composants logiciels
dvelopper).
Dossier N & S de dveloppement ( Guide du dveloppeur ),
Dossier Guide de gestion de configuration ,
Dossier Norme de livraison ,
7.4 Les acteurs de l'ET
O Les acteurs d'un projet en tape dET :
matrise d'ouvrage (voir les acteurs) + assistance MOA Rle limit en ET.
Prciser les profils des acteurs de la MOE et de la MOA pour une ET. Pour la MOE, on citera plus en
dtails :
le rle de larchitecte : laboration des N&S de dveloppement, laboration de larchitecture
logicielle de tous les processus dvelopper, garant de lutilisation des N&S,
le rle du DBA : optimisation du schma de la base de donnes, et des requtes (SQL), ,
le rle du dveloppeur (ou dveloppeur HTML pour une maquette Web). En ET, il assiste
larchitecte pour la prparation de larchitecture logicielle des composant dvelopper. En ET,
on fait donc appel des dveloppeurs seniors (expriments).
O Les instances de pilotage en tape dET :
8. Ralisation et tests unitaires
8.1 Objectifs de la ralisation
Ltape Ralisation et tests unitaires a pour objet de dvelopper tous les composants logiciels de
lapplication cible.
Cela comprend tous les composants logiciels (progr. Java, progr. C, Shells, prcdures SQL,
procdures Shells, etc) suivants :
des traitements transactionnels (TP) :
+ application TP Cible,
+ application TP / systme transitoire,
+ application TP / systme dgrad,
des traitements batch :
+ des traitements dinterfaces
+ des traitements de migration des donnes (programmes de dchargement et de
rechargement),
Ltape Ralisation et tests unitaires est une tape 100% MOE. La MOA est donc peu active
pendant cette tape. Elle participe toutefois aux instances de pilotage (travail de suivi des travaux de la
MOE).
8.2 Les phases
Lancement (Ph1),
Dveloppement et tests unitaires (Ph2).
Prciser les diffrence entre test unitaire , test dintgration (ou de qualification ) et test de
recette .
Rq : pas de phase de validation pour passer ltape suivante, car il sagit de 2 phases sous la
matrise 100% de la MOE.
Mise en place de l'organisation
Rdaction d'un PAQ ddi au dveloppement.
O Organisation de la MOE :
La structure MOE comprend :
une quipe de dveloppeurs (ventuellement spcialise par domaines fonctionnels),
une quipe architecture (N & S, traitements communs, optimisation du modle des donnes,
migration des donnes, )
Plusieurs possibilits dorganiser lquipe MOE lorsquon dveloppe une application dans une
architecture N-tier :
1
re
possibilit : chaque programmeur dveloppe la fois la partie serveur et la partie cliente.
2
me
possibilit : constituer une quipe qui dveloppe la partie cliente, et une quipe qui dveloppe
la partie serveur.
Le rle des experts :
oracle : tuning BD, optimisation des requtes SQL,
DBA : optimiser les modles relationnels, partitionnement physique des disques,
moniteur transactionnel : optimisation des requtes,
dploiement : prparation du dploiement dans l'architecture de production. Pour une appli C/S,
prvoir et organiser le dploiement de l'appli "cliente",
rseau,
etc
O Mise jour du PAQ :
Dans le PAQ (mise jour par rapport aux versions prcdentes), dcrire :
L'organisation du projet, dont les instances de pilotage,
les responsabilits des parties, y compris des ventuels sous-traitants et co-traitants.
Importance du systme qualit pendant tout le projet :
PAQ de conception / PAQ de dveloppement : aspect contractuel entre MOE et MOA,
revue des livrables (programmes ou documents) avant livraison la MOA,
suivi des charges (consomm, RF),
suivi des bordereaux de livraison / bordereaux de rception.
8.2.2 Dveloppement + tests unitaires (Ph2)
o Dveloppement de tous les composants logiciels (tels que prvus en fin dEtude Technique).
o Tests unitaires (chaque composant logiciel doit tre test unitairement par lingnieur quil la
dvelopp : il sagit de vrifier sa conformit aux SFD prises).
Remarques :
O Les diffrents environnements utiliss :
environnement de dveloppement,
environnement de qualification & intgration (les composants une fois tests, sont dploys dans
cet environnement pour tre qualifies voire ltape suivante).
O Faire la documentation associe lapplication :
Documentation des programmes sources ( exemple : JavaDoc)
Dossier dinstallation (explique la procdure suivre pour installer lapplication dans un nouvel
environnement)
Dossier dexploitation (Explique lquipe de Production le schma, lordonnancement des batch
lancer, leur frquence, les input/output ncessaires chaque traitement, etc).
Env. de
dv.
Env. de
qualif. &
intgration
Env. de
recette
VA
Env. de
bench
Env. de
production
Sources &
binaires
Sources &
binaires
Sources &
binaires
Sources &
binaires
Sources &
binaires
8.3 Les livrables
Script SQL (Oracle) de cration du schma de la base de donnes,
Programmes sources & binaires,
Documentation des programmes sources,
Dossier dinstallation : comment dployer lapplication dans u environnement ?
Dploiement chaud : sans arrt de lapplication
Dploiement froid : avec arrt de lapplication.
Dossier dexploitation.
Attention :
1) Ne pas livrer de dossier des tests unitaires Pige !!!
2) Attention viter les migrations techniques pendant les dveloppements du type :
- migration oracle 8.1.7 vers Oracle 9.i,
- migration WebLogic 6.1 vers WebLogic 8.1.
8.4 Les acteurs de la Ralisation
O Les acteurs d'un projet en tape de ralisation :
Prciser les profils des acteurs de la MOE et de la MOA pour ltape de Ralisation. Pour la MOE, on
citera plus en dtails :
le rle de larchitecte :, garant de lutilisation des N&S auprs des dveloppeurs, optimisation
du code,
le rle du dveloppeur. Il dveloppe suivant les spcif. de lET et ralise les tests unitaires,
O Les instances de pilotage en tape de ralisation :
9. Qualification MOE
Autres termes pour dsigner cette tape :
Tests dIntgration,
Recette MOE.
9.1 Objectifs
La MOE doit faire des tests complets avant de livrer lapplication la MOA pour recette. Cest une
tape trs lourde, estime environ 30% des charges de Ralisation et tests unitaires .
Ces tests sont de 2 natures :
des tests fonctionnels (obligatoire !) :
Intgrer & qualifier les programmes transactionnels et batch de la cible,
Intgrer & qualifier la reprise des donnes,
Intgrer & qualifier les procdures dinstallation et dexploitation (cration dun schma, chgt
des tables de rfrence, etc),
des tests techniques (facultatif, suivant la criicit de lapplication dveloppe !) :
tests de performances (Bench) tant sur le transactionnel (exemple : site internet www.anpe.fr)
que sur le batch (exemple : traitement de la paie en fin de mois, traitement des dossiers IJM
la CANAM).
Tests dexcution des traitements batch dans une plage horaire prdfinie.
Par exemple, entre 20h et 6h.
tests de monte en charge dun nb dutilisateurs de + en +.
Par exemple, temps de rponse TP < 1s si moins de 5000 connexions simultanes.
tests avec un volume de donnes croissant dans les tables de la base de donnes,
Par exemple, temps dexcution dune requte SQL si 1 million de lignes, 10 millions, 100
millions de lignes (ex : Renault, application dincidentologie).
tests avec indisponibilit partielle dune partie des ressources (par exemple, simuler le
fonctionnement dun gros site Web si certaines instances WebLogic de production sont
tombes ),
9.2 Les phases
Lancement (Ph1),
Prparation de la qualification (Ph2),
Excution des tests d'intgration (Ph3),
Prparation de la livraison auprs de la MOA (Ph4).
Importance de distinguer au sein de la MOE l'quipe de dveloppement de l'quipe d'intgration.
CPi
Equipe de Equipe de
dveloppement qualification
Livraison de la correction
Tests de qualif. OK
Correction Attention la non rgression
KO
Fiches danomalies
Dans le PAQ, on fixera la dure de la qualification (notamment le nombre ditrations).
Les diffrents environnements utiliss :
environnement de qualification & intgration,
environnement de bench (si ncessaire).
Possibilit d'automatisation des tests :
tests fonctionnels (tests pour vrifier la conformit aux SFD),
tests techniques :
Installer les outils de tests, si ncessaire.
9.2.2 Prparation de la Qualification (Ph2)
Cas de test (df.) : Description dun test (fonctionnel) raliser.
Par exemple, tester la page de chgt dadresse dun client.
Jeux de donnes (df.) :Description du jeu de donnes utiliser pour excuter un cas de test. On
dcrit les donnes relles saisir en entre du cas de test (input), et le
rsultat escompt (output).
Env. de
dv.
Env. de
qualif. &
intgration
Env. de
recette
VA
Env. de
bench
Env. de
production
Sources &
binaires
Sources &
binaires
Sources &
binaires
Sources &
binaires
Sources &
binaires
Prparation des cas de tests et des jeux par la MOE :
Prparation des jeux d'essais (jeux d'essais fonctionnels et jeux d'essais techniques).
Rdaction du "plan de qualification" : jeux d'essais excuter, rsultats attendus.
2 types de tests de qualification :
tests fonctionnels visant vrifier la conformit du codage des rgles de gestion dans les
programmes, vrifier le bon fonctionnement de l'application dans le SI (changes avec les appli
interfaces) + vrifier la non-rgression.
tests techniques : tests de performance, de temps de rponse, de monte en charge.
9.2.3 Excution de la qualification (Ph3)
Itration des 5 tches suivantes :
Equipe MOE de
dv.
Equipe MOE de
qualif.
Excution de la qualification (=Passage des jeux dessais fonctionnels
et/ou techniques)
x
Identification des dysfonctionnements (rdaction des fiches
danomalies)
x
Correction + tests unitaires, aprs instruction des fiches de
dveloppement
x
Livraison de la correction dans lenv. de qualification
x
Nouvelle qualification (2
me
passage des jeux d'essais) = tests de non-
rgression
x
Remarques :
O Remarques sur les tests de non rgression :
Les tests de non-rgression doivent tre ralises sur les composants logiciels qui ont t corrigs par
lquipe de dv., mais aussi sur la totalit des autres processus (y compris ceux qui ont dj fait lobjet
dune 1
re
campagne de tests de qualification).
Itration de lexcution de la totalit des cas de tests suivants :
Tests fonctionnels,
Tests techniques.
O Classer les anomalies par gravit (classification utiliser galement en recette classification
mettre dans le PAQ, car contractuel entre les 2 parties MOE et MOA) :
ano grave / bloquante,
ano gnante / majeure,
ano non gnante / mineure,
amlioration / volution.
O Rdaction du dossier de qualification" : il dcrit les anomalies rencontres, les corrections
ralises, il trace tous les tests raliss par lquipe de qualification.
9.2.4 Prparation de la livraison la MOA (Ph4)
Suivant les conditions prvues au PAQ, on peut livrer en rgle gnrale lapplication (sources &
excutables) lorsque les conditions suivantes sont respectes :
Zro anomalie bloquante,
Nb anomalies majeures < seuil-1 (dfini dans le PAQ) ou le contrat,
Nb anomalies mineures < seuil-2 (dfini dans le PAQ) ou le contrat.
Une fois, lapplication livre en recette, lquipe MOE est rduite. Quelques dveloppeurs (MOE)
resteront toutefois sur le projet pendant la recette, afin de corriger les anomalies identifies par la MOA
en recette.
9.3 Les livrables
Plan de la qualification ( faire par la MOE ds la fin de lED) : il dcrit les cas de tests et les jeux
de donnes prvues pour la qualification de lapplication,
Dossier de qualification : il trace lexcution de la qualification MOE : il contient donc tous les cas
de tests qui ont t excuts et les rsultats constats (il contient donc les fiches danomalies). Il
est rdiger au fur et mesure de lexcution des campagnes de tests.
9.4 Les acteurs de la qualification
O Les acteurs d'un projet en tape de qualification :
Prciser les profils des acteurs de la MOE et de la MOA pour une tape de qualification. Pour la MOE,
on citera plus en dtails :
le rle du dveloppeur. Il corrige les anomalies identifies par le qualificateur.
le rle du qualificateur : il prpare le plan de qualification ( partir des SFD), puis excute les
cas de tests, et rdige si ncessaire les fiches danmoalies,
Si ncessaire, peuvent encore intervenir :
le rle de larchitecte :, garant de lutilisation des N&S auprs des dveloppeurs, optimisation
du code,
O Les instances de pilotage en tape de qualification :
10. Recette
10.1 Objectifs
La MOA doit faire des tests complets avant de mettre en production lapplication.
Dans le mme temps, la MOE maintient une quipe de dveloppeurs rduite pour assurer la correction
des anomalies identifies pendant la recette par la MOA.
Ces tests couvrent :
Recette fonctionnelle des programmes TP / batch de la cible,
Recette fonctionnelle de la reprise des donnes.
NB : le primtre de la recette est diffrents des tests de qualification effectus par la MOE.
De plus, les tests de la MOA peuvent tre accompagns dautres tches, telles des tests auprs dun
chantillon de futurs utilisateurs de lapplication (chantillon reprsentatif).
10.2 Les phases
Lancement (Ph1),
Prparation des jeux d'essais de recette (Ph2),
Excution de la recette (Ph3).
Une organisation particulire au sein de la MOA: une quipe ddie au tests de recette.
Prciser le rle du MOE et du MOA durant la recette.
CPi (MOE) CPu (MOA)
Equipe de Equipe MOA de
dveloppement recette (utilisateurs)
+ qualification
Livraison de la correction
Tests de recette OK
Correction / Attention la non rgression
Dveloppement nouveau
KO
Fiches danomalies
et / OU
Fiches dvolutions
(acceptes par la MOE si avenant au contrat dorigine)
Traitement de correction par la MOE variable, suivant la gravit des anomalies identifies par la MOA :
Si fiche danomalie bloquante correction + relivraison la MOA sous 48 ou 72 heures
(suivant contrat pass)
Dans les autres cas (gravit = majeur ou mineur) regroupement des anomalies dans des
lots.
Les diffrents environnements utiliss par la MOE :
environnement de qualification & intgration.
Les diffrents environnements utiliss par la MOA :
environnement de recette.
Dans le PAQ, on fixera la dure de la recette (la dure de la recette gnre des charges dans la MOE,
que la MOE doit connatre au pralable).
10.2.2 Prparation des cas de tests et des jeux d'essais de recette (Ph2)
Cas de test (df.) : Description dun test fonctionnel raliser. Par exemple, tester la page de
chgt dadresse dun client.
Jeux de donnes (df.) :Description du jeu de donnes utiliser pour excuter un cas de test. On
dcrit les donnes les donnes relles saisir en entre du cas de test
(input), et le rsultat escompt (output).
Prparation des cas de tests et des jeux d'essais (par la MOA) et non par la MOE :
jeux d'essais fonctionnels TP et bach,
jeux d'essais fonctionnels TP et bach de reprise des donnes,
Rq : La MOE peut fournir son assistance la MOA dans la prparation des cas de tests et des jeux de
donnes.
10.2.3 Excution de la recette (Ph3)
Une recette se droule en 2 temps :
recette dans un environnement de tests (VA ou VABF),
= Recette dans un environnement spcifique, par une quipe MOA du projet.
recette dans un environnement de production (VSR).
= Recette dans un environnement rel de production (conditions relles dutilisation), mais limit
un site pilote.
Env. de
dv.
Env. de
qualif. &
intgration
Env. de
recette
VA
Env. de
bench
Env. de
production
Sources &
binaires
Sources &
binaires
Sources &
binaires
Sources &
binaires
Sources &
binaires
Plusieurs parties recetter :
recette fonctionnelle (applicatifs et/ou progiciels): vrification de la conformit des rgles
dveloppes avec les SFD,
recette de la reprise des donnes : vrification de la cohrence et de l'intgrit des donnes
migres de l'ancien systme, vrification que lpuration effectue est OK,
recette technique : vrification des performances, de la solidit de l'appli lors d'une monte en
charge, de l'implmentation conforme des N&S, bench de performances,
Rarement en recette !!
Droulement du processus de recette : itration des 7 tches suivantes :
Equipe MOE
de dv.
Equipe MOE
de qualif.
Equipe MOA
de recette
Excution de la recette VA (= passage des jeux
dessais fonctionnels et/ou techniques)
x
Identification des dysfonctionnements (rdaction des
fiches danomalies)
x
Correction + tests unitaires, aprs instruction des
fiches de dveloppement
x
Livraison de la correction dans lenv. de qualification
x
Qualification de la correction
x
Livraison de la correction dans lenv. de recette
x
Nouvelle recette (2
me
passage des jeux d'essais) =
tests de non-rgression des corrections ralises
x
Remarques :
O Remarques sur les tests de non rgression :
Les tests de non-rgression doivent tre ralises sur les composants logiciels qui ont t corriges
par la MOE, mais aussi sur la totalit des autres processus (y compris ceux qui ont dj fait lobjet
dune 1
re
campagne de tests de recette).
O Remarques sur les fiches danomalies :
Les fiches d'anomalies sont rdiges par la MOA et adresses la MOE pour correction. Les
anomalies doivent tre reproductibles par la MOE.
O Classer les anomalies par gravit (classification utiliser galement en recette) :
ano grave / bloquante,
ano majeure,
ano mineure,
amlioration / volution.
Complexit lorsque 2 systmes informatiques doivent co-exister.
10.3 Les 2 types de recette
Les 2 types de recette sont :
La Vrification dAptitude (VA), aussi appele Vrification dAptitude au Bon Fonctionnement
(VABF),
La Vrification de Service Rgulier (VSR)
10.3.1 La VA
La VA ses caractristiques :
Elle consiste excuter tous les cas de tests fonctionnels (et techniques si ncessaire) de
manire exhaustive avec des jeux dessais blanc,
Elle dure en rgle gnrale - de 15 jrs 3 mois, suivant la taille du projet,
Elle sexcute dans un environnement de recette.
Le dossier de recette VA trace toutes cas passer et les rsultats des tests constats.
10.3.2 La VSR
La VSR ses caractristiques :
Elle se droule sur un site pilote, avant gnralisation du dploiement, donc lenvironnement de
production,
Le site pilote a un fonctionnement normal. Il utilise des donnes relles.
Elle dure en rgle gnrale - de 2 6 mois, suivant la taille du projet,
Il ny a pas de dossier de recette.
Site pilote : site qui utilise avant les autres sites (ou services) de lentreprise la nouvelle application qui
vient dtre recette. Les autres sites (ou services) continuent en rgle gnrale
utiliser lancienne application.
10.4 Les livrables (produits par la MOA)
Plan de la recette ( faire par la MOA ds la fin de lED) : il dcrit les cas de tests et les jeux de
donnes prvues pour la recette,
Dossier de recette : il trace lexcution de la recette VA : il contient donc tous les cas de tests qui
ont t excuts et les rsultats constats (il contient donc les fiches danomalies),
Dossier bilan de la recette VA & VSR ( rdiger au fur et mesure de lexcution des
campagnes de tests),
PV de recette (PV de VA & PV de VSR). Ces documents sont des documents contractuels prvus
pour les projets au forfait (il dclenche en rgle gnrale le paiement dune tranche des
prestations dun projet au forfait).
10.5 Les acteurs de la recette
O Les acteurs d'un projet en tape de qualification :
Prciser les profils des acteurs de la MOE et de la MOA pour une tape de recette. Pour la MOE, on
citera plus en dtails :
le rle du dveloppeur. Il corrige les anomalies identifies par le qualificateur.
le rle du qualificateur : il requalifie les corrections ralises suite aux anomalies dtectes par
la MOA,
O Les instances de pilotage en tape de qualification :
11. Prparation la mise en oeuvre
11.1 Les phases
Les phases :
Conduite du changement (Ph1) Phase exclusivement la charge de la MOA
Prparation du dploiement (Ph2) Phase exclusivement la charge de la Production
11.1.1 Conduite du changement (Ph1)
Conduite du changement, la charge de la MOA exclusivement :
mesures daccompagnement (exemple : volution des tches du personnel dune entreprise,
reconversion en cas de licenciement, ).
Communication, formation (viter les "effets tunnel").
Information vers les utilisateurs finals (journaux, sminaires de communication, ....).
transfert de comptences (entre un diteur de progiciel et une socit cliente, entre un SSII
matre doeuvre et une DSI, ...).
Exemples de conduite du changement :
Ex. n1 :
Entreprise X dcision de la DG de retarder la mise en production dune nouvelle version
devant des risques de grves du personnel qui considrent que leur mtier volue et quil est
sous-form La MOA (en accord avec la DG de lentreprise) dcide de faire des actions de
communication (sminaires) auprs de toutes les directions rgionales.
Ex. n2 :
La MOA (en accord avec la DG de lentreprise) a mis en place une structure permettant de
rpondre aux 500 emails quotidiens dinformations dinternautes candidats ou employeurs sur le
site Web de lentreprise X.
11.1.2 Prparation du dploiement (Ph2)
Prparer le plan de dploiement dans l'architecture de production.
Plan dploiement : Dossier qui dcrit :
- les modalits du dploiement de larchitecture physique (serveurs et PC).
Opration complexe notamment pour les applications C/S avec un client
"lourd".
- les modalits de la migration des donnes. Opration complexe, lorsque le
volume des donnes est trs important, lorsque le service est ouvert 7j/7j et
24h/24h). Cas des sites Internet, ou des applications utilises par des sites
rparti dans le monde entier.
11.1.3 Les acteurs
Les acteurs :
La production, pour la prparation de larchitecture technique physique,
La direction de la formation, pour les plans de formation,
La direction du personnel, pour des mesures possibles de reconversion/licenciement,
La MOA,
11.1.4 Livrables
Les livrables de ltape :
support de communication,
guide utilisateur,
supports de formation,
.
12. Mise en uvre / Dploiement
12.1 Les phases
Les phases :
Dploiement de larchitecture technique (Ph1)
Dploiement de lapplication (Ph2)
Reprise des donnes (Ph3)
Automatisation de lenvironnement de production (Ph4)
Important :
Rle de la MOA : nant
Rle de la MOE : quipe de la production + assistance de la MOE.
12.2 Dploiement
12.2.1 Dploiement de larchitecture technique (Ph1)
Il sagit de dployer larchitecture technique (ou architecture physique) de lenvironnement de
production.
O Mise en place des serveurs de production :
Achat des matriels, logiciels, mise en place des serveurs de production, installation, paramtrage,
mise en place de mirroring, de RAID5, de sites avec bascules automatiques (citer l'exemple de
l'incendie du Crdit Lyonnais en 1999).
O Dploiement des licences ncessaires au fonctionnement de lapplication :
des licences tels Oracle (noyau), WebLogic (licence serveur), etc au niveau des serveurs,
des ventuelles licences sur les postes PC des utilisateurs.
O Mise en place, si ncessaire, dune architecture redonde :
N serveurs dapplications J2EE (WebLogic) dans lenv. de production,
Utilisation de loption Oracle Parallel Serveur (OPS) dOracle ou Oracle Rack,
Redondance des lignes rseau,
Etc
O Prparer le dploiement (ou lupdate) des PC :
Prparer le dploiement sur les PC, voire le remplacement des PC, la mise niveau du rseau,
notamment pour les applications C/S.
O Mise niveau du rseau WAN et LAN :
Notamment passage IP sur le WAN,
augmentation de la bande passante du WAN,
12.2.2 Dploiement de lapplication (Ph2)
Dploiement des progiciels et des applications dveloppes en spcifique (binaires).
12.2.3 Reprise des donnes (Ph3)
Migration des donnes dans larchitecture cible, avec les donnes relles de lancien systme arrt
(par exemple, la veille). Au quel cas, cette opration est souvent raliser pdt un WE, ou une nuit.
Pour le site pilote (VSR) :
Reprise des donnes en dbut de VSR.
Pour les autres sites :
Reprise des donnes en fin de VSR.
12.2.4 Complments faire lenvironnement de production (Ph4)
O Mise en place des outils dexploitation et dadministration du systme :
Les outils ncessaires, une fois lapplication finale mise en exploitation sont les suivants :
ordonnancement des batch (exemple : $UNIVERSE),
Outil de surveillance systme (exemple : PATROL).
O Mise en place ventuellement dune machine de backup,
12.3 Lotissement
Risques lis une mise en oeuvre par lots successifs :
2 systmes informatiques faire cohabiter,
interfaces et systmes transitoires,
inconvnients pour les utilisateurs utiliser 2 systmes.
13. Bilan
Importance du bilan dans une SSII.
Capitaliser sur le chiffrage des UO,
Capitaliser sur les mtiers du client,
Capitaliser sur larchitecture logicielle,
Capitaliser sur les contacts clients, etc
14. Garantie
Garantie = correction des anomalies par la MOE non dtectes en Qualification et en Recette ; et
souvent due au titre dun march au FORFAIT entre une SSII et une socit cliente.
Elle dmarre, en gnral, la fin de la recette ou la fin du dploiement.
Procdures contractuelles mettre en uvre applicables lissue du dploiement :
- dlai dintervention en cas danomalie bloquante sur problme software ou hardware
- dlai dintervention en cas danomalie majeure (ou mineure) sur problme software ou hardware
En rgle gnrale, la SSII na plus dquipe MOE affect au projet. Elle doit toutefois tre mme
dintervenir suivant les dlais dfinis au contrat.
15. Maintenance / TMA
Introduire le vocabulaire suivant :
TMA : Tierce Maintenance Applicative,
Les 4 types de maintenance :
maintenance corrective,
maintenance prventive (exemple : faire voluer un squence de code mal crite, peu
performante, .)
maintenance volutive (exemple : volution de la rglementation).
Maintenance adaptative (exemple : chgt de version de lOS, du SGBD, ).
Pour la TMA, faire un PAQ ddi aux spcificits de ce type dactivits.
15.1 Organisation
Evolution de lorganisation : quipe Front office + quipe Back office.
Font office : mtier, proximit du client,
Back office : ventuellement distant, orient technique.
Evolution vers du near-shore (Espagne, Maroc, ) ou du off-shore (Inde, Roumanie, Chine, ).
15.2 Outils
Outils impratifs dans une TMA :
Outil de gestion des demandes (faits techniques) : Mantis, Bugzilla, XAGA,
Outil de gestion de config. CVS (Subversion) : indispensable, qd dveloppement de plisieurs
versions du logiciel simultanment.
Outil de qualimtrie, analyse dimpacts : CAST, System Code (ACFO). Ces produits
reconnaissent la syntaxe de certains langages de programmation. Ils peuvent servir mesurer
la qualit du code source, identifier du code mort, faire des analyes dimpacts,
16. La qualit dans un projet informatique
16.1 Objectifs dun PAQ
Le PAQ dcrit les modalits dassurance qualit informatique entre une MOE et une MOA pour
lensemble des tapes dun projet.
Le PAQ est rdig en dbut du projet. Il est alors valid par les 2 parties MOE & MOA. Il est applicable
par les 2 parties pendant tout le projet.
16.2 Dans quels cas faire un PAQ ?
Le PAQ est obligatoire (indispensable) :
dans tout projet au forfait entre une SSII et un client,
dans tout projet au-del dune certaine taille (par exemple > 400 / 500 j*h)
Le PAQ est inutile dans les cas suivants :
prestations dune SSII en rgie,
petit projet (par exemple < 200 j *h).
16.3 Quels acteurs participent la rdaction dun PAQ ?
Cas n1 projet interne :
Dans ce cas, il est rdig par le CPi, avec lassistance de la Direction Qualit de sa DSI.
DSI
Etudes Production
Domaine 1 Domaine 2 Production Rseaux & Telecom
CP1 CP2 CP3 CP4
Cas n2 projet confi une SSII :
Dans ce cas, il est rdig par le CPi de la SSII, avec la collaboration du CPi du client et lassistance des
Directions Qualit de la SSII et du Client.
16.4 Contenu du PAQ
Le sommaire dun PAQ est toujours le mme. Ce sommaire type est dfini par la norme AFNOR.
Voir un exemple du PAQ fourni par lenseignant.
Qualit (cas n1)
Qualit (cas n2)
OU
Les principaux sur lesquels il faut porter son attention :
lorganisation du projet (et donc la disponibilit des ressources MOE & MOA),
les procdures de livraison
les procdures de rception et de validation des livrables
les indicateurs et mtriques qualit
17. Les adaptations de la dmarche
17.1 Adaptation de la dmarche de Conduite standard
Adaptation de la dmarche de Conduite de projet si :
grand projet (prvoir un dcoupage en sous-projets + lotissement ventuel),
moyen projet,
petit projet (moins dtapes, moins de livrables, moins de points de validation, ...).
Autres adaptations suivant la nature du projet :
projet de migration,
projet dintgration (ERP par exemple).
17.2 Autres dmarches / mthodes de conduite de projet
17.2.1 RAD
Rapid Application Dvelopment (RAD).
17.2.2 SDM/S
SDM/S (9 tapes, chacune dcompose en 9 phases) :
DBS,
CAS
SES,
SIS,
PRG,
TST,
CONV,
INST
17.2.3 Autres dmarches
Dmarche itrative (en spirale).
Pilotage par les enjeux.
18. Quest-ce quun chef de projet ?
18.1 Rle du CPi
Importance du rle du CPi : vritable chef d'orchestre.
18.2 Qualits du CPi
Les 7 qualits du CP : voir note OM.
19. Mthode dvaluation des charges
Donner des mtriques pour calculer les charges brutes par units doeuvre, en fonction de la
complexit TS, S, M, C, TC.
Cette mthode permet de calculer des charges brutes, auxquelles il faut rajouter des charges
dencadrement, des charges dassurance qualit, dadministration des donnes, ...
19.1 Ratios des tapes
Rappeler le poids de chaque tape :
Schma directeur
Etude Pralable 5%
Etude Dtaille 15%
Etude Technique 10%
Ralisation 35%
Intgration 15%
Recette 10%
Prparation de la mise en oeuvre
Mise en oeuvre 5%
Bilan
2 mthodes :
PERT,
GANTT.
3 proccupations :
valuer les charges et les planifier,
grer le suivi et les carts,
prise de dcisions (si retards sur le chemin critique).
19.2 Mthodologies de chiffrage des charges
Dcrire les mthodologies de chiffrage des charges sur un projet :
recensement des units d'uvre,
attribution d'un facteur de complexit : TS, S, M, C, TC
calcul des charges brutes,
ajout des charges d'encadrement (+15% chez SOPRA),

Support L3 ISI2 v20060123 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Support L3 ISI2 v20060123 PDF

Uploaded by

Copyright:

Available Formats

Univ. De Paris 1 Panthon - Sorbonne / UFR..

Les principaux outils de qualimtrie :

You might also like