Upload
doannhan
View
214
Download
1
Embed Size (px)
Citation preview
Introductiona la gestionde projets
LaurentPoinsot
Introduction a la gestion de projets
Laurent Poinsot
26 janvier 2009
Introductiona la gestionde projets
LaurentPoinsot
Modele ducycle en V
Cahier descharges -analyse desbesoins
Specificationsgenerales
Specificationsdetaillees
Codage
Testsd’integration
Livraison /Recette
Remarquesrelatives auprojet
Conclusion
Le modele du cycle en V est une methodologie dedeveloppement logiciel qui est devenue un standard del’industrie logicielle. Ce modele est constitue de deuxphases : l’une est dite descendante et l’autre ascendante.Chacune des phases est divisee en plusieurs etapes. Il y aaussi l’etape d’implementation (ou de codage) qui estisolee et n’appartient a aucune des deux phases. Dansl’ordre chronologique les etapes sont les suivantes :
1 Phase descendante :1 Cahier des charges (analyse des besoins) ;2 Specifications generales ;3 Specifications detaillees (conception detaillee).
2 Etape de codage ;3 Phase ascendante :
1 Tests de validation detaillees (ou tests unitaires) ;2 Tests d’integration ;3 Recette (ou livraison finale).
Introductiona la gestionde projets
LaurentPoinsot
Modele ducycle en V
Cahier descharges -analyse desbesoins
Specificationsgenerales
Specificationsdetaillees
Codage
Testsd’integration
Livraison /Recette
Remarquesrelatives auprojet
Conclusion
Chaque etape d’une phase donnee possede un uniquevis-a-vis dans l’autre phase. Seule l’etape de codage estsans vis-a-vis. Ainsi
1 L’etape de redaction d’analyse des besoins est encorrespondance avec l’etape de livraison finale ;
2 L’etape de specifications generales est encorrespondance avec l’etape des tests d’integration ;
3 L’etape de specifications detaillees est encorrespondance avec l’etape des tests unitaires.
Introductiona la gestionde projets
LaurentPoinsot
Modele ducycle en V
Cahier descharges -analyse desbesoins
Specificationsgenerales
Specificationsdetaillees
Codage
Testsd’integration
Livraison /Recette
Remarquesrelatives auprojet
Conclusion
L’idee de cette correspondance entre etapes de phasesdifferentes est la suivante : lors de l’etape de la phasedescendante, on determine les tests que l’on devra effectuerpour prouver que le logiciel realise bien ce qui est demandea cette etape. Bien evidemment on ne peut pas effectuerces tests puisque le logiciel n’est pas code ! Neanmoins onles concoit deja. Puis pendant l’etape correspondante de laphase ascendante, on effectue reellement ces tests et onapporte des corrections au code, si cela s’avere necessaire.
Introductiona la gestionde projets
LaurentPoinsot
Modele ducycle en V
Cahier descharges -analyse desbesoins
Specificationsgenerales
Specificationsdetaillees
Codage
Testsd’integration
Livraison /Recette
Remarquesrelatives auprojet
Conclusion
Par exemple : lors de la phase des specifications generales,on concoit les fonctionnalites d’ordre general du logicielainsi que les tests que l’on fera pour verifier que le code lesimplemente correctement. Lors de la phase des testsd’integration, on realise ces tests et on effectue lescorrections du code necessaires pour que ces testsreussissent.Lors de la phase de conception detaillee, on specifiel’algorithme de toutes les procedures du programme et,pendant cette meme etape, on concoit les tests quivalideront ces procedures. Ces tests sont finalementeffectues lors de l’etape des tests unitaires.
Introductiona la gestionde projets
LaurentPoinsot
Modele ducycle en V
Cahier descharges -analyse desbesoins
Specificationsgenerales
Specificationsdetaillees
Codage
Testsd’integration
Livraison /Recette
Remarquesrelatives auprojet
Conclusion
A chaque etape est fixee une date de livraison a laquelledes livrables doivent etre fournis au client. Ces livrablessont generalement des documents. En ce qui concerne lestrois premieres etapes, les livrables sont des documents quicontiennent le travail effectue durant l’etape. Pour lesetapes de tests, on fournit aussi un document qui contientles resultats des tests effectues, attestant ainsi de la bonnerealisation de l’etape en vis-a-vis de la phase descendante.Lors de la recette, le code est livre.
Introductiona la gestionde projets
LaurentPoinsot
Modele ducycle en V
Cahier descharges -analyse desbesoins
Specificationsgenerales
Specificationsdetaillees
Codage
Testsd’integration
Livraison /Recette
Remarquesrelatives auprojet
Conclusion
Cahier des charges - analyse des besoins
Le point de depart du developpement logiciel est constituepar les besoins exprimes par le client (dans notre cas, ils’agit du sujet du projet). Il est important de realiser quel’enonce d’un besoin ne constitue pas un cahier descharges.
Introductiona la gestionde projets
LaurentPoinsot
Modele ducycle en V
Cahier descharges -analyse desbesoins
Specificationsgenerales
Specificationsdetaillees
Codage
Testsd’integration
Livraison /Recette
Remarquesrelatives auprojet
Conclusion
Objectifs d’un cahier des charges
1 Specifier uniquement le comportement externe dulogiciel, sans faire reference a une eventuelleimplementation. En d’autres termes, on ne parle pas icid’algorithmes !
2 Specifier les contraintes de codage (OS et machinessur lesquelles le logiciel doit fonctionner) ;
3 Servir de documents de reference : toute reponse aune question precise concernant le comportementexterne du logiciel devrait pouvoir etre trouvee dans lecahier des charges ;
4 Specifier des scenarii de tests a effectuer lors de lalivraison finale, afin de demontrer le bon comportementdu logiciel lors de cette livraison finale ;
5 Lever les eventuelles ambiguıtes exprimees dans lesbesoins du client.
Introductiona la gestionde projets
LaurentPoinsot
Modele ducycle en V
Cahier descharges -analyse desbesoins
Specificationsgenerales
Specificationsdetaillees
Codage
Testsd’integration
Livraison /Recette
Remarquesrelatives auprojet
Conclusion
Plan d’un cahier des charges type
1 Presentation du logiciel : On presente le logiciel arealiser en termes de besoins (a quoi sert-il ?) et ondecrit brievement ses fonctions principales. On ypresente les eventuelles notations utilisees dans lasuite du document ;
2 Materiel : Cette section permet de decrire le materielinformatique employe ;
3 Besoins fonctionnels : Description des fonctions dehaut niveau que le logiciel doit realiser ;
4 Besoins non fonctionnels : Contraintes auxquelles estsoumis le logiciel (langage de programmation a utiliser,environnement logiciel) ;
5 Manuel d’utilisation du logiciel (et description de l’IHM) ;6 Scenarii de tests a effectuer lors de la livraison finale.
Introductiona la gestionde projets
LaurentPoinsot
Modele ducycle en V
Cahier descharges -analyse desbesoins
Specificationsgenerales
Specificationsdetaillees
Codage
Testsd’integration
Livraison /Recette
Remarquesrelatives auprojet
Conclusion
Specifications generales
Les specifications generales reprennent la description desfonctionnalites du logiciel mais plus en detail. Ainsi chaquefonctionnalite est decrite en specifiant son algorithme(comment la fonctionnalite est-elle mise en œuvre ?).L’architecture (le squelette) generale du logiciel est aussidecrite. A cette etape est initiee la phase des testsd’integration : on doit deja savoir quels tests seronteffectues pour demontrer que chaque fonctionnalite a etecorrectement implementee.
Introductiona la gestionde projets
LaurentPoinsot
Modele ducycle en V
Cahier descharges -analyse desbesoins
Specificationsgenerales
Specificationsdetaillees
Codage
Testsd’integration
Livraison /Recette
Remarquesrelatives auprojet
Conclusion
Specifications detaillees
On decrit les differents sous-algorithmes composantchacune des fonctionnalites du programme. Dans cettephase, l’idee est de permettre a un programmeur, sansaucune connaissance du logiciel, de coder le logicielsimplement en lisant le contenu des specificationsdetaillees. On est ici tres proche du code final. Ladescription des procedures utilisees est donc tres fine. Acette etape est initiee la phase des tests unitaires : on doitimaginer les tests qui seront realises plus tard afin deprouver l’absence de boggue dans les procedures.
Introductiona la gestionde projets
LaurentPoinsot
Modele ducycle en V
Cahier descharges -analyse desbesoins
Specificationsgenerales
Specificationsdetaillees
Codage
Testsd’integration
Livraison /Recette
Remarquesrelatives auprojet
Conclusion
Codage
Dans cette etape on ne fait que traduire, dans un langagede programmation, les algorithmes des procedures decritsdans les specifications detaillees. On teste le code a l’aidedes tests unitaires tels que decrits dans les specs.detaillees. On corrige alors le code lorsque c’est necessaire.
Introductiona la gestionde projets
LaurentPoinsot
Modele ducycle en V
Cahier descharges -analyse desbesoins
Specificationsgenerales
Specificationsdetaillees
Codage
Testsd’integration
Livraison /Recette
Remarquesrelatives auprojet
Conclusion
Tests unitaires
Comme on vient de le signaler, les tests unitaires, dejadecrits dans les specs. detaillees, sont realises, afin dedemontrer l’absence de boggue au niveau dufonctionnement ”local” des procedures.
Introductiona la gestionde projets
LaurentPoinsot
Modele ducycle en V
Cahier descharges -analyse desbesoins
Specificationsgenerales
Specificationsdetaillees
Codage
Testsd’integration
Livraison /Recette
Remarquesrelatives auprojet
Conclusion
Tests d’integration
A cette etape, on realise les tests d’integration decrits dansles specifications generales. Ils permettent de prouver quechaque fonctionnalite realise bien ce qui etait initialementdemande. Chaque fonctionnalite est donc testee puisvalidee.
Introductiona la gestionde projets
LaurentPoinsot
Modele ducycle en V
Cahier descharges -analyse desbesoins
Specificationsgenerales
Specificationsdetaillees
Codage
Testsd’integration
Livraison /Recette
Remarquesrelatives auprojet
Conclusion
Livraison / Recette
Derniere etape : devant le client, on demontre que le logicielse comporte comme cela est decrit dans le cahier descharges. On utilise pour cela les scenarii de fonctionnementimagines pendant l’etape de redaction du cahier descharges. Si tout est OK, alors le client vous paye ! (Dans ceprojet, on se contentera de vous noter.)
Introductiona la gestionde projets
LaurentPoinsot
Modele ducycle en V
Cahier descharges -analyse desbesoins
Specificationsgenerales
Specificationsdetaillees
Codage
Testsd’integration
Livraison /Recette
Remarquesrelatives auprojet
Conclusion
Remarques relatives au projet
Notre projet est trop ”petit” pour avoir besoin de mettre enœuvre l’integralite du modele en V de developpementlogiciel. Aussi le nombre d’etapes se retrouve etre reduit(voir le sujet du projet). En particulier, les phases despecifications detaillees et de codage sont regroupees dansune unique etape d’implementation.
Introductiona la gestionde projets
LaurentPoinsot
Modele ducycle en V
Cahier descharges -analyse desbesoins
Specificationsgenerales
Specificationsdetaillees
Codage
Testsd’integration
Livraison /Recette
Remarquesrelatives auprojet
Conclusion
Conclusion
Malgre les idees recues la phase de codage n’est pascelle qui dure le plus longtemps. Les trois premieresetapes sont primordiales et doivent etre realisees avecle plus grand soin et la plus grande precision ;Il faut etre ponctuel et livrer les documents attenduspar le client en temps et en heure. (Une partie de votrenote en dependra.) ;Il faut etre patient : ne surtout pas se lancer dans lecodage avant d’avoir bien reflechi a ce que doit faire lelogiciel (c’est-a-dire les trois premieres etapes) ;N’oubliez pas qu’a chaque etape de la phasedescendante, vous devez imaginer et rediger les testsqui seront realises dans l’etape en vis-a-vis de la phasemontante.