gestion de grands projets  15 heures un logiciel est un ensemble complexe et son développement nécessite une diversité d'acticvités

écran rafraichi le updated 28 févr. 2002-feuillade@freesurf.fr

Objectif
Conduite de projet, assurance qualité, évaluation de la réalisation, organisation des équipes, planification, tests et intégration.

plan du cours IPA   par Treves@cnam.fr
Je 13/12	9h-12h	introduction	norme ISO 9126 105Ko
Je 20/12	9h-12h	exemple d'un contrat informatique ? Rational RequisitPro est une aide à la rédaction Cahier des Charges www.rational.com/products/reqpro/prodinfo.jsp	coaching groupe-projets: étude de faisabilité Me 5/12 au Ve 1/02 préparer un arbre produit pour chacun des 3 projets eVinci-XP, VML, int-base
Je 10/01	9h-12h	la planification p29
Je 17/01	10h30-12h	modèle COMOCO
Je 14/02	9h-10h30	session ad hoc pour chacun des 3 gpe-projets: question /réponses	coaching gpe-projets eVinci-XP, VML, int-base du Lu 11/02 au Lu 8/04
Je 11/04	9h-12h	soutenance 60' (transparents, HTML ou PowerPoint) par groupe-projet eVinci-XP, VML, int-base  +remise rapport selon plan type: 1. Contexte du projet Objectifs techniques Le client, son identification, les données fournies (CdC...) L'approche ingénierie utilisée: cycle de vie, architecture logicielle. 2. Planification Arborescence produit. Organigramme des tâches (à justifier selon une granularité assez fine). Estimation des couts et délais, organisation du groupe projet (chef de projet, compétences de chacun, coaching). Pert, Gantt par personne et consolidé. Plans de charge par personne et consolidé [(courbes rx(t) et r(t)]. 3. Vie du projet, au fil de l'eau Mesures d'avancement et analyse des écarts Difficultés rencontrées (techniques, relationnelles, avec le client) Mesures correctrices mises en oeuvre. ex: capitalisation, replanifier, pbs abordés par le coach, recherche d'expertise extérieure 4. Conclusion Bilan du projet : Respect du modele CQFD; identification du nbre de lignes de codes. Application possible du modele COCOMO au projet? Synthèse des difficultes rencontrees. Satisfaction du client et de l'equipe.	Coaching, jeux de rôles, mise en situation réelle: eVinci-XP vie du gpe-projets du 5/12 au 12/04/02   gpe-projets VML du 5/12 au 12/04/02 gpe-projets int-base du 5/12 au 12/04/02   en capitalisant sur vos précédentes expériences projet: projetJava Debas Vehicule du 31/10 au 6/11 projetJava+bddSQL Makpangou RéseauDeVote du 30/11 au 7/12 projetJava Debas XML-RPC-Lite  60 jours du 22/11 au 25/01/02

Outil de gestion de projets :  MS Project  www.microsoft.com/office/project/default.htm

Atelier développeurs : enregistrez votre projet sur http://sourceforge.net

Environnements de modélisation UML  www.allhtml.com/uml/index.php   http://uml.free.fr   www.omg.org
on pourra utiliser la POO  www.commentcamarche.net/poo/poointro.php3    avec la méthode UML www.commentcamarche.net/uml/umlintro.htm   www.rational.com/uml/index.jsp

• Multi-Gen Paradigm www.multigen.com
• Rational Rose  www.rational.com/products/rose/index.jsp
  www.rational.com/products/rose/datamodel.jsp
• ERwin 30Mo Database design www.cai.com/products/alm/erwin.htm    cr
• emcd designer
• JBuilder6 comporte une visi UML à des fins de rétro-programmation (maintenance de logiciel) ou reverse engeneering

Livres

• UML Unified Modelisation Language, Fowler-Scott, CampusPress 10€
• Le génie logiciel J. Printz, Puf 2001 QueSais-Je
• Puissance et limites des systèmes informatisés J. Printz, Hermes SciencePublications 1998
• Couts et durée des projets informatiques J. Printz, N. Treves, Hermes SciencePublications 2001
• Productivité des programmeurs  J. Printz, Hermes SciencePublications 2001
• La qualité du logiciel, retour d'epériences, cnam AFNOR

• autres livres sur amazon.fr
• autres livres sur amazon.com

UML

1. Les besoins sont consignés dans un cahier des charges fonctionnel et transmis au MOE
2. Le MOE écrit alors le cahier des charges de réalisation

A partir de ces besoins, le MOE établit une solution détaillée permettant de satisfaire le besoin exprimé, cette solution devant être acceptée et validée par le MO. La solution décrite dans le cahier des charges de réalisation sert de référence lors de la recette fonctionnelle du programme. Dans cette organisation le MO commence la description du futur SI et le MOE la termine avant de développer l'application adéquate.

Les litiges possibles :

• Le besoin formalisé par le client est-il exhaustif ?
• Le besoin exprimé est-il compréhensif par le fournisseur ?
• Le client a-t-il les moyens de valider la solution ?

Les besoins sont souvent ambigüs, incomplets ou mal exprimés. Les futurs utilisateurs sont donc invités, avec l'assistance d'experts, à travailler rigoureusement sur la définition des services attendus pour élaborer un cahier des charges du SI. Le SI situe l'informatique dans une vision stratégique de l'entreprise, comme une de ses composantes structurelles. Concevoir un SI consiste à décrire les flux d'information concourant à une même finalité, à en repérer les acteurs, à expliciter la signification des informations utilisées ainsi que les règles de gestion, afin de porter un diagnostic et de construire des scénarios alternatifs d'information et d'organisation.

The Framfab Method www.framfab.com
Framfab Unified Process, FUP, is a project process framework developed by Framfab as an important component to ensure the quality of what we produce as well as that of the production process itself.

FUP is defined at three levels.

1. The first level, "the foundation," defines the major phases, milestones and workflows of a project.
2. The second level, "the practice," which is derived from the foundation, defines project roles, responsibilities and deliverables.
3. The third level, "the toolbox," defines templates for each deliverable and a set of guidelines and checklists for each role.

The idea behind these three levels is that "the foundation" should be followed by every project and is the most stable part of FUP; that "the practice" must be configured slightly for every project and will be improved regularly in FUP; and, finally, that "the toolbox" must always be configured for every project and will be constantly refined in FUP.

6 modèles de cycle de vie

1. modèle en cascade
2. modèle en V
3. modèle de développement par prototypage
4. modèle en cascade adapté à la technique de développement par extensions successives: développer en étandant ses fonctionnalités progressivement, mais il sera nécessaire de s'assurer que les extensions ne viennent pas déstabiliser le logiciel déjà réalisé.
   avantages:
   - les extensions successives de fonctionnalités sont bien plus faciles à tester que les niveaux intermédiaires d'un cycle descendant, utilisé dans le modèle en cascade
   - cette technique fournit un moyen moins couteux d'incorporer l'expérience de l'utilisateur plutôt que d'avoir à tout redévelopper en prototypage.
5. modèle incrémental
   utilise sytématiquement le développement par extensions successives, les extensions pouvant être liées entre elles
6. modèle en spirale

cycle de vie complet du logiciel
Besoin > Exigences > Développement du logiciel > Exploitation > Maintenance > Retrait du logiciel

un projet d'informatisation peut être construit suivant différentes typologies:
- logiciel spécifique développé
- progiciel std développé
- intégration d'un ou plusieurs progiciels (composants logiciels élémentaires) avec personnalisations sur-mesure

Le cycle de développement du logiciel s'intègre dans une organisation de projet

étape spécification se déroule en 2 phases

1. collecte des informations afin de déterminer le role que le systeme doit jouer dans l'environnement et le détail des exigences de l'utilisateur. Les principales actions sont:
   - recueil des besoins
   - détermination des objectifs
   - identification des contraintes
   - inventaire des personnalisations
2. déterminer le produit au moyen d'une définition formelle de ce qui doit être livré et une définition sommaire des essais que l'on envisage de faire pour la recette

Un recueil d'expression des besoins très détaillés matérialise le résultat de l'analyse. Ce document est appelé cahier des charges lorsqu'il y a contractualisation des relations entre la maitrise d'ouvrage et la mautrise d'oeuvre. Le cahier des charges fonctionnels doit faire l'objet d'une validation.

La communication
En appui de la démarche qulité, il importe de mettre en place des actions de communication:
communication interne pour vendre

L'analyse du besoin est une phase délicate. Les besoins sont souvent incomplétement expimés et il appartient au concepteur de les identifier en tenat compte des principaux facteurs de qualité suivants : absence d'ambiguité, ensemble complet, cohérence, facilité de compréhension. le besoin exprimé par lutilisateur ne coincide pas forcement avec l'expression faite par le donneur d'ordres (cahier des charges). derrière un besoin explicite se cache souvent des besoins implicites. En outre le besoin du client pourra évoluer au cours des étapes de la vie du logiciel, certaines évolutions ne dépendant pas du client mais de l'environnement.