Système d'inscription aux cours

Plan de développement logiciel

 

Version 1.0

 


Historique des révisions

Date

Version

Description

Auteur

15/01/99

1.0

Version initiale

Rick Bell

 

 

 

 

 

 

 

 

 

 

 

 

 


Table des matières

1.          Introduction         

1.1     Objectif     

1.2     Portée     

1.3     Définitions, acronymes et abréviations     

1.4     Références     

1.5      Aperçu     

2.          Aperçu du projet      

2.1      But, portée et objectifs du projet     

2.2      Suppositions et contraintes     

2.3      Produits de projet     

2.4      Evolution du plan de développement logiciel     

3.          Organisation du projet  

3.1      Structure de l'organisation     

3.2      Interfaces externes     

3.3      Rôles et responsabilités     

4.          Procès de gestion

4.1      Estimations de projet     

4.2      Plan de projet     

4.2.1       Plan de phase      

4.2.2       Objectifs d'itération

4.2.3       Editions      

4.2.4       Calendrier de projet 

4.2.5       Ressources de projet      

              4.2.5.1       Plan d'affectation du personnel      

              4.2.5.2       Plan d'acquisition de ressources      

              4.2.5.3       Plan de formation      

4.2.6       Budget      

4.3      Plans d'itération     

4.4      Surveillance et contrôle du projet     

4.4.1       Plan de gestion des exigences      

4.4.2       Plan de contrôle du calendrier      

4.4.3       Plan de contrôle du budget      

4.4.4       Plan de contrôle de qualité      

4.4.5       Plan de génération de rapports      

4.4.6       Plan de mesure      

4.5      Plan de gestion des risques     

4.6      Plan de fermeture     

5.          Plan de processus technique 

5.1      Cas de développement     

5.2      Méthodes, outils et techniques     

5.3      Plan d'infrastructure     

5.4      Plan d'acceptation du produit     

6.          Plans de processus d'assistance 

7.          Plans supplémentaires 

8.          Annexes 

9.          Index     


Plan de développement logiciel

 

1.                  Introduction 

1.1               Objectif

L'objectif de ce plan de développement logiciel est de définir les activités de développement en termes de phases et d'itérations requises pour implémenter un système d'inscription aux cours par ordinateur pour le Wylie College.

1.2               Portée

Ce plan de développement logiciel décrit le plan global à utiliser par le département informatique de l'université pour développer le système C-Registration. Les détails des itérations seront décrits dans les plans d'itération.
Les plans indiqués dans ce document sont basés sur les exigences de produit définie dans le document de vision [1].

1.3               Définitions, acronymes et abréviations

Voir le glossaire [4].

1.4               Références

Les références applicables sont :

    1. Vision du système d'inscription aux cours, WyIT387, V1.0, Wylie College IT.
    2. Etude de rentabilité du système d'inscription aux cours, WyIT388, BROUILLON, 1998, Wylie College IT.
    3. Document des demandes des parties prenantes du système d'inscription aux cours, WyIT389, V1.0, 1998, Wylie College IT.
    4. Glossaire du système d'inscription aux cours, WyIT406, V1.0, 1998, Wylie College IT.
    5. Calendrier de haut niveau du système d'inscription aux cours, V1.0, 1999, Wylie College IT.
    6. Rational Unified Process, 1999, Rational Software Corp.
    7. Rapport d'analyse et modèle de coût du système d'inscription aux cours, WylIT390, V1.0 Wylie College IT.
    8. Liste des risques du système d'inscription aux cours, WyIT389, V1.0, Wylie College IT.
    9. Cas de développement du système d'inscription aux cours, WyIT390, V1.0, Wylie College IT.
    10. Plan d'itération du système d'inscription aux cours, Itération d'élaboration n°E1, WyIT391, V1.0, Wylie College IT

1.5               Aperçu

Ce plan de développement logiciel contient les informations suivantes :

Aperçu du projet  - description du but, de la portée et des objectifs du projet.  Il définit également les produits que le projet doit livrer.

Organisation du projet - décrit la structure de l'équipe de projet.

Processus de gestion - explique le coût estimé, le calendrier ; définit les principales phases et les jalons du projet ; et décrit comment le projet sera surveillé.

Plans de processus technique - aperçu des processus de développement du logiciel, comprenant les méthodes, outils et techniques à suivre.

Plans de processus de support - inclut le plan de gestion de configuration. 

2.                  Aperçu du projet

2.1               But, portée et objectifs du projet

Ce plan de développement logiciel décrit le plan général que le département informatique du Wylie College utilisera pour développer le système C-Registration. Les détails des itérations seront décrits dans les plans d'itération.

Les plans définit dans ce documents sont basés sur les exigences de produit de la vision [1].

2.2               Suppositions et contraintes

Le système est destiné à devenir le mode d'inscription principal pour les étudiants pour le terme d'automne 1999. Comme les inscriptions commencent en Août 1999, le système doit être terminé avant.

2.3               Produits de projet

Les produits suivants seront créés lors du projet et livrés à l'organisation de maintenance.

D'autres produits seront créés, comme indiqué dans le cas de développement du projet, mais ils ne seront pas livrés à l'organisation de maintenance.

2.4               Evolution du plan de développement du logiciel

Le plan de développement du logiciel sera revu avant le début de chaque phase d'itération.

3.                  Organisation du projet

3.1               Structure de l'organisation

3.2               Interfaces externes

Le responsable de projet fournira une évaluation du statut aux parties prenantes responsables du département informatique, comme prévu dans ce plan (voir la vision [1]).

L'équipe de projet engagera également d'autres parties prenantes pour demander conseil ou une révision de certains produits.

3.3               Rôles et responsabilités

Le tableau suivant identifie les unités d'organisation qui sont responsables des disciplines, activités et processus d'assistance.

Rôle

Responsabilité

Responsable de projet

Comme décrit dans le processus RUP [6]. Responsable de la gestion globale de la discipline de gestion de projet. Dirige l'équipe de projet au sens large.

Ingénieur processus Responsable de l'environnement de projet, assiste les équipe du projet dans les problèmes de processus, comme indiqué dans la discipline Environnement du processus RUP. Fait partir de l'équipe de projet au sens large.
Responsable de la gestion de la configuration / responsable du contrôle des changements Responsable du contrôle de la configuration sur le projet et de l'exécution du processus de demande de changement du Wylie College dans le projet.  Fait partir de l'équipe de projet au sens large.

Chef d'équipe d'ingénierie système

Dirige l'équipe responsable de la modélisation métier et des disciplines de recueil des exigences. Fait partie de l'équipe de projet au sens large. 

Chef d'équipe d'ingénierie logicielle

Responsable principalement des discipline d'analyse, de conception et d'implémentation. Fait partie de l'équipe de projet au sens large.

Chef d'équipe de test

Dirige l'équipe responsable de la gestion de la discipline de test. Fait partie de l'équipe de projet au sens large.  

Chef d'équipe de déploiement Dirige l'équipe responsable les activités d'installation et l'infrastructure de l'environnement.  Fait partir de l'équipe de projet au sens large.  

 

4.                  Processus de gestion

4.1               Estimations de projet

Les estimations de projet sont basées sur le modèle de coût du système C-Registration et le rapport d'analyse [7].

Le système d'inscription aux cours est d'une complexité et d'une architecture similaire à celles du système de bibliothèque en ligne créé par le Wylie College en 1997.  La base de données du système d'inscription est environs 25 % plus complexe et les cas d'utilisations suggèrent que le système sera environs 20 % plus complexe. Les estimations de durée et d'effort de ce rapport forment la base du budget et du calendrier du projet.

4.2               Plan de projet

4.2.1          Plan de phase

Une structure de division du travail est en cours de préparation et sera disponible dans la prochaine version de ce document.

Le développement du système C-Registration suivra une approche par phases dans laquelle chaque phase sera constituée d'un nombre d'itérations. Les phases et itérations de ce plan ne se chevauchent pas. Le tableau ci-dessous offre un résumé du tableau chronologique :

Phase

Nombre d'itérations

Fin

Phase de création

1

Semaine 7

Phase d'élaboration

1

Semaine 14

Phase de construction

1

Semaine 19

Phase de transition

4

Semaine 32

Tableau 4.2.1 Résumé du tableau chronologique

Le tableau 4.2.2 décrit les phases et les jalons qui marquent la fin de chaque phase.

 

Phase

Description

Jalon

Phase de création

La phase de création développe les exigences de produit et établit l'étude de rentabilité du système C-Registration. Les principaux cas d'utilisation seront développés, tout comme le plan de développement logiciel de haut niveau. A la fin de la phase de création, le Wylie College décidera ou non de poursuivre le projet en fonction de l'étude de rentabilité.

La révision de l'étude de rentabilité à la fin de la phase décide si le projet continue ou non.

Phase d'élaboration

La phase d'élaboration contient l'analyse des exigences et le développement du prototype d'architecture. A la fin de la phase d'élaboration, tous les cas d'utilisation sélectionnés pour l'édition 1.0 ont été analysés et conçus. De plus, les cas d'utilisation à risque élevé de l'édition 2.0 ont également été analysés et conçus. Le prototype d'architecture teste la faisabilité et les performances de l'architecture requise pour l'édition 1.0.

Le Prototype d'architecture est le jalon qui marque la fin de la phase d'élaboration. Ce prototype indique que les principaux composants d'architecture de l'édition 1.0 ont été vérifiés.

Phase de construction

Lors de la phase de construction, les cas d'utilisation restant sont analysés et conçus. La version Bêta de l'édition 1.0 est développée et distribuée pour évaluation. Les activités d'implémentation et de test pour les éditions R1.0 et R2.0 sont terminées.

La capacité opérationnelle initiale (fin de la bêta) est le jalon qui marque la fin de la phase de construction.

Phase de transition

La version bêta de l'édition 1.0 est distribuée et évaluée. La phase de transition prépare la distribution des éditions R1.0 et R2.0. Elle apporte l'assistance requise pour une installation sans problème, y compris la formation des utilisateurs.

L'Edition R2.0 est le jalon qui marque la fin de la phase de transition. A ce moment, toutes les capacités décrites dans le document de vision [1], sont installées et disponibles pour les utilisateurs.

Table 4.2.2 Phases du projet et principaux jalons

Chaque phase est divisée en itérations de développement, comme décrit dans la section 4.3.

La section 4.2.4 indique un calendrier de projet de haut niveau, contenant les phases, les itérations et les jalons principaux.

4.2.2          Objectifs d'itération

Chaque phase est composée d'itérations de développement au cours desquelles une partie du système est développée. Généralement, ces itérations :

Le tableau suivant décrit les itérations accompagnées par les jalons associés et les risques adressés.

Phase

Itération

Description

Jalon associé

Risques adressés

Phase de création

Itération préliminaire

Définit le modèle de gestion, les exigences de produit, le plan de développement logiciel et l'étude de rentabilité.

Audit de l'étude de rentabilité

Clarifie les exigences des utilisateurs dès le début.

Crée un plan de développement logiciel et une portée réalistes.

Détermine la faisabilité du projet d'un point de vue métier.

Phase d'élaboration

Itération E1 - Développement du prototype d'architecture

Termine l'analyse et la conception de toutes les exigences à haut risque. Développe le prototype d'architecture.

 

Prototype d'architecture

Problèmes d'architectures résolus.

Risques techniques réduits.

Prototype disponible pour les utilisateurs.

Phase de construction

Itération C1 - Développer la bêta R1

Implémente et teste les exigences clés R1 pour obtenir une version R1 bêta.

 

Décide si l'édition est prête pour le test bêta.

Capacité opérationnelle initiale (Code R1 Bêta terminé)

Toutes les fonctions clés d'un point de vue utilisateur et architecture ont été implémentés dans la bêta.

 

 

Phase de transition

Itération T1 - Développement/déploiement de l'édition R1

Déployer la R1 bêta.

Corriger les défauts et incorporer les commentaires de la bêta.

 

Implémenter et tester les exigences restantes de R1.

Conditionner, distribuer et installer l'édition R1.

Détail complet des cas d'utilisations restant pour R2.

Test bêta R1 terminé

 

Code R1 terminé

 

Publication du produit R1

Commentaires des utilisateurs avant la publication de R1.

 

La qualité du produit devrait être élevée.

Défauts réduits.

Réduction du coût de la qualité.

Une édition en deux étapes réduit le nombre de défauts.

Une édition en deux étapes facilite la transition pour les utilisateurs.

R1 complètement revue par la communauté des utilisateurs.

 

Itération T2 - Développement de R2 Internal 1

Concevoir, implémenter et tester les exigences de R2 Internal 1.

Incorporer les améliorations et défauts de R1.

Déployer R2 Internal 1.

Test de R2 Internal 1 terminé

Si nécessaire, publier R2 Internal 1 pour résoudre les défauts de R1 et améliorer la satisfaction des clients.

 

Itération T3 - Développement de R2 Internal 2

Concevoir, implémenter et tester les exigences de R2 Internal 2.

Incorporer les améliorations et défauts de R2 Internal 2.

Déployer R2 Internal 2.

Test de R2 Internal 2 terminé

R2 Internal 1 revue de manière informelle par la communauté des utilisateurs.

 

Si nécessaire, publier R2 Internal 1 pour résoudre les défauts de R1 et améliorer la satisfaction des clients.

 

Itération T4 - Développement/déploiement de l'édition R2

Conditionner, distribuer et installer l'édition R2.

Code R2 terminé

 

Publication du produit R2

R2 Internal 2 revue de manière informelle par la communauté des utilisateurs.

Une édition en deux étapes facilite la transition pour les utilisateurs.

 

4.2.3          Editions

Ce plan de développement logiciel concerne les deux premières édition du système C-Registration. Les fonctions-clés, définies dans le document de vision [1], sont destinées aux deux premières éditions. Toutes les fonctions essentielles pour l'inscription des étudiants sont prévues pour la première édition (R1.0).

Le contenu prévu pour la première édition devrait évoluer au cours de la progression du projet. Cette évolution proviendra d'une série de facteurs techniques et économiques. Rational RequisitePro permettra de faire face à ces modifications, de gérer les exigences du produit et de suivre le contenu de l'édition. Les attributs d'avantage, d'effort et de risque permettent de déterminer la priorité des exigences de produit et donc l'édition visée.

Il est prévu de publier le système C-Registration pour un usage généralisé au Wylie College en 2 à 4 éditions principales.

La première édition devra au moins contenir les fonctions de base reprises ci-dessous :

L'édition 2 devrait comprendre :

La fonctionnalité de l'édition 3 n'a pas encore été définie. On estime que cette édition contiendra des améliorations aux fonctionnalités existantes.

Le remplacement du système financier existant et du système de base de données des cours est prévu pour l'édition 4 en 2005.

De plus, une version Bêta précédera la version R1.0 et contiendra toutes les fonctions clés de R1. La version bêta sera déployée comme le système final, mais n'interagira qu'avec une copie isolée des systèmes existant pour éviter tout problème sur ces systèmes. Un groupe d'étudiants et d'employés sélectionnés évalueront la bêta de manière formelle.

De plus, il y aura également des éditions internes pour aider à conserver le projet sur les rails et pour disposer d'éditions supplémentaires après l'édition initiale, si nécessaire. Les éditions internes peuvent être évaluées de manière informelle par les étudiants et les employés. Voici une courte description des objectifs de chaque édition interne :

La fonctionnalité de l'édition 3 n'a pas encore été définie. On estime que cette édition contiendra des améliorations aux fonctionnalités existantes.

Le remplacement du système financier existant et du système de base de données des cours est prévu pour l'édition 4 en 2005.

4.2.4          Calendrier de projet

Le calendrier de projet de haut niveau de C-Registration [5] contient un calendrier de haut niveau indiquant les phases du projet, les itérations et les jalons comme illustré ci-dessous.

Calendrier de projet

Date

Phase de création

 

Itération préliminaire (début)

Mar 1/12/98

Jalon de révision de l'étude de rentabilité (fin de la phase de création)

Mar 19/1/99

Phase d'élaboration

 

Itération E1 - développement du prototype d'architecture

 

Jalon du prototype d'architecture (fin de la phase d'élaboration)

Mar 9/3/99

Phase de construction

 

Itération C1 - développement de l'édition 1 Bêta

 

Jalon de capacité opérationnelle initiale (code de R1 Bêta terminé)

Ven 9/4/99

Phase de transition

 

Itération T1 - Développement/déploiement de l'édition 1

 

Fin du test bêta de R1

Ven 16/4/99

Code R1 terminé

Ven 30/4/99

Publication du produit R1 (fin T1)

Ven 7/5/99

Itération T2 - Développement Edition 2 Bêta 1

 

Test R2 Internal 1 terminé (fin T2)

Ven 28/5/99

Itération T3 - Développement Edition 2 Bêta 2

 

Test R2 Internal 2 terminé (fin T3)

Ven 18/6/99

Itération T4 - Développement/déploiement Edition 2

 

Code R2 terminé

Ven 2/7/99

Publication du produit R2 (clôture du projet)

Ven 9/7/99

4.2.5          Ressources de projet

4.2.5.1     Plan d'affectation du personnel

Les employés du département d'informatique identifiés dans le graphique d'organisation de la section 8.1 sont assignés au projet. Les ressources supplémentaires ne seront assignées que lorsque l'étude de rentabilité aura été revue à la fin de la phase de création et une décision aura été prise quant à la poursuite du projet.

L'organisation de test pourra disposer du soutien de l'organisation d'ingénierie, comme illustré par la ligne pointillées dans le graphique.

4.2.5.2     Plan d'acquisition de ressources

Le département informatique du Wylie College ne dispose pas de suffisamment de développeurs et de concepteurs pour réaliser le projet. Le bureau de recrutement du Wylie College est prêt à recruter un développeur expérimenté doté de plusieurs années d'expérience en C++, un intégrateur système expérimenté et deux testeurs/intégrateurs (début de carrière) ayant au moins un an d'expérience en C++.

4.2.5.3     Plan de formation

L'équipe de projet sera formée sur les techniques suivantes avant le début de la conception :

4.2.6          Budget

 

Le budget du projet basé sur les estimations initiales

4.3               Plans d'itération

Veuillez consulter le plan d'itération E1 du système d'inscription aux cours [11].

4.4               Surveillance et contrôle du projet

4.4.1          Plan de gestion des exigences

Les exigences de ce système sont capturées dans la vision [1] et les requêtes des parties prenantes [3].

4.4.2          Plan de contrôle du calendrier

Le responsable de projet maintient un calendrier résumé indiquant la date prévue de chaque jalon et appartenant au rapport d'évaluation de statut, décrit dans le plan de rapport.  Le rapport d'évaluation de statut est envoyé aux responsables du département informatique qui peut s'en servir pour définir de nouvelles priorités ou recommander des actions correctives.

Le calendrier résumé est obtenu à partir d'un calendrier complet maintenu par les chefs d'équipe.  Les éléments du calendrier détaillé sont des modules assignés à des individus.  Chaque individu qui se voit assigner un module fournit un statut en pourcentage à son chef d'équipe chaque semaine.

4.4.3          Plan de contrôle du budget

Les dépenses sont surveillées par le responsable de projet et évaluées à l'aide du rapport d'évaluation de statut.

4.4.4          Plan de contrôle de qualité

Tous les produits doivent passer par le processus d'audit approprié.  L'audit doit vérifier que chaque produit est d'une qualité acceptable en fonction des instructions décrites dans les instructions et listes de contrôle du processus RUP [6].

De plus, les défauts seront enregistrés et suivis et les mesures seront conservées comme indiqué sur le site Web de processus du Wylie College [10].

4.4.5          Plan de génération de rapports

Le rapport d'évaluation de statut sera préparé par le responsable de projet au moins une fois par mois.  Il contient :

    - estimations de coût et de calendrier mises à jour

    - résumé des mesures

4.4.6          Plan de mesure

Les mesures de projet standard, décrites sur le site de processus du College Wylie [10], seront rassemblées et incluses dans le rapport d'évaluation de statut.

4.5               Plan de gestion des risques

Veuillez consulter la liste des risques du système C-Registration [8].

4.6               Plan de clôture

Le calendrier indique une réaffectation graduelle du personnel vers d'autres projets. Au moins un développeur restera à temps partiel pour maintenir le système.

Un rapport de fin de projet, qui résume les leçons apprises et qui contient une étude de la différence entre le coût et le calendrier réels et prévus sera soumis au responsable du département informatique.

5.                  Plans de processus technique

5.1               Cas de développement

Voir le cas de développement du système C-Registration [9].

5.2               Méthodes, outils et techniques

Voir le site Web de processus logiciel du Wylie College [10].

5.3               Plan d'infrastructure

S/O

5.4               Plan d'acceptation du produit

S/O

6.                  Plans de processus d'assistance

Voir le site Web de processus du Wylie College [10].

7.                  Plans supplémentaires

S/O.

8.                  Annexes

S/O.

9.                  Index

S/O.