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 |
|
|
|
|
|
|
|
|
|
|
|
|
1.3 Définitions, acronymes et abréviations
2.1 But, portée et objectifs du projet
2.2 Suppositions et contraintes
2.4 Evolution du plan de développement logiciel
3.1 Structure de l'organisation
4.2.5.1 Plan d'affectation du personnel
4.2.5.2 Plan d'acquisition de ressources
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.5 Plan de gestion des risques
5. Plan de processus technique
5.2 Méthodes, outils et techniques
5.4 Plan d'acceptation du produit
6. Plans de processus d'assistance
Plan de développement logiciel
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.
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].
Voir le glossaire [4].
Les références applicables sont :
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.
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].
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.
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.
Le plan de développement du logiciel sera revu avant le début de chaque phase d'itération.
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.
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. |
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.
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.
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. |
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.
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.
|
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.
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++.
L'équipe de projet sera formée sur les techniques suivantes avant le début de la conception :
Le budget du projet basé sur les estimations initiales
Veuillez consulter le plan d'itération E1 du système d'inscription aux cours [11].
Les exigences de ce système sont capturées dans la vision [1] et les requêtes des parties prenantes [3].
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.
Les dépenses sont surveillées par le responsable de projet et évaluées à l'aide du rapport d'évaluation de statut.
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].
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
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.
Veuillez consulter la liste des risques du système C-Registration [8].
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.
Voir le cas de développement du système C-Registration [9].
Voir le site Web de processus logiciel du Wylie College [10].
S/O
S/O
Voir le site Web de processus du Wylie College [10].
S/O.
S/O.
S/O.