Organisation des projets 1 /25 Bernard Cherbonneau / M1 Master Informatique / Module TER 2008 Organisation des Projets

Organisation des projets 1 /25Bernard Cherbonneau / M1 Master Informatique / Module TER 2008

Organisation des Projets


Aider à identifier les activités à mener• cycles de vie• maintenance

Mettre en évidence les responsabilités des différents acteurs

Pour ensuite pouvoir • Estimer les activités (temps à passer, charges, ressources)• Les affecter aux ressources• Les planifier• Les suivre (contrôler, maîtriser)

Buts du chapitre


Identification des activités

Cycle de vie(réalisation)


Objet du cycle de vie

Modélisation conceptuelle, qui aide à la prise de décision durant toute la vie d'un système, de la création au retrait

Décomposition du développement (maintenance) en phases successives

But = définition d'entités réellement gérables• identifiables• estimables• planifiables• contrôlables (mesurables)

Maîtrise de chaque phase, étape (méthodes, outils) pour la maîtrise du processus


Contenu d'un cycle de vie traditionnel

Pour chaque phase (étape), définition des. produits en entrée (documents, codes). activités à réaliser, relations entre activités ; distinction entre activités de

- réalisation (documentation, programmation, test...) (ingénierie)

- gestion (gestion de projet, gestion de configuration, gestion de la documentation...)

- qualité (assurance, contrôle)

. environnement de réalisation (méthodes, outils)

. produits en sortie

. processus et critères de validation de la phase, de passage à la phase suivante



Cycle de réalisation en "V" (AFNOR 87)

Spécification

Conceptionpréliminaire

Conceptiondétaillée

Codage

Testsunitaires

Intégration

Validation


Cycle de réalisation en “V” : bilan

Avantages Ne « choque » pas : Pourquoi ? Quoi ? Comment ? on fait, on vérifie Adapté aux développements « au forfait » sur la base du « quoi » Très connu des partenaires « béton » sur le plan contractuel

Inconvénient Pas adapté à la prise en compte des demandes de modification durant le

développement (risques) : effet « tunnel », contraintes vérifiées tardivement (performances,

volume…) Équipe de réalisation parfois importante (risques) : confusion phase et activités (risques) : orienté « documents »

Quand l’appliquer ? Besoins connus, solution connue (risque)


Recette

Cycle de réalisation incrémental

Installation

Exploitation etMaintenance

Revalidation


Vérification Codage

Test Unitaire Intégration

Test fonctionnel


Vérification Codage

Test Unitaire

Conception

globale

Vérification

Intégration

Test fonctionnel

Codage


Vérification

Spécificationde logiciel

Validation

incrément 1

incrément 2

incrément 3

Test Unitaire


Cycle de réalisation incrémental : bilan

Avantages : les mêmes + Équipe plus petite (sur une période + longue) Plus adapté à la prise en compte des demandes de modification Moins d’effet « tunnel »

Inconvénients Autant de livraisons que d’incréments Davantage de tests (non régression) (risques) : coûts de « cassure »

Quand l’appliquer ? Besoins connus, solution connue, mise en œuvre progressive du

produit, budget client sur plusieurs périodes


Cycle de réalisation itératif

PRODU IT

Vers le produit idéal, idéalement fabriqué

Itération 1Itération 2

Itération 3

Domaine de la solution

Domaine du problème

Chaque itération commence par une activité de spécification


Le processus itératif Les objectifs :

– s'assurer de la construction du bon système, en vérifiant systématiquement les besoins et en les raffinant avec les clients à des intervalles de temps réguliers

– permettre la réalisation de plans détaillés qui collent davantage à la réalité, en organisant le développement au fur et à mesure de la compréhension du système, et de la compréhension de la manière de le construire

Le processus doit être contrôlé et dirigé par les besoins (et par les ressources, notamment le temps)


Une itération

Itération 1

Itération 3

Itération 2Plan de

développement

Spec.+ plan

Production Evaluation


A propos des itérations (source IBM) Nombre d'itérations : de 3

à 6, selon• la taille du projet, la

complexité, la stabilité des besoins

Typiquement• 9 à 18 mois de

développement• 200 classes, 3000 méthodes

Durée d'une itération : de 3 à 6 mois, selon• le regroupement logique des fonctions

fournies, la disponibilité des clients

Avec un cycle moyen de 3, 5 mois • 1 à 2 semaines de spécification /

planification• 2 à 3 semaines d’évaluation• 2 à 2,5 mois de production

Et maintien de l’intérêt de chacun !


Cycle de réalisation itératif : bilan

Avantages On « code » naturellement (c’est écrit !) de suite Le client a des codes à tester rapidement Pas orienté « doc » (ce qui ne veut pas dire….) Parfaitement adapté à la prise en compte des demandes de modification

Inconvénients Pas dans les habitudes des partenaires Pas adapté à des réalisations au forfait sur le « quoi » Demande davantage d’implication des utilisateurs Les utilisateurs doivent avoir le temps de tester

Quand l’appliquer ? Développement « en interne », sans obligation d’engagement au forfait sur le « quoi » Besoins mal connus, solution mal connue : typiquement projets de R&D


Maquettes et prototypes

Maquette • résultat d’une action ayant pour but d’illustrer un concept (typiquement une maquette d’écran -statique-)

• permet d ’illustrer, définir ou valider une ergonomie

Prototype• version exécutable et fonctionnellement incomplète d’un système• permet d’étudier une faisabilité

Surtout ne pas assimiler prototype et cycle de réalisation itératif ; un prototype peut très bien être élaboré durant n’importe quel cycle de réalisation

Si un prototype est envisagé, bien définir en préalable les objectifs recherchés (valider une IHM, démontrer une faisabilité, montrer différentes possibilités d’IHM, etc.)


Identification des activités

Maintenance


Maintenance

Activité vitale pour les entreprises car – le parc applicatif représente un investissement considérable– le système d'information est une ressource stratégique

Mais– mobilise une part importante des ressources du service informatique– au détriment du développement de nouvelles applications


Les différents types de maintenance

Adaptative– Action de maintenance ayant pour but d'adapter un logiciel, à

fonctionnalités identiques, aux modifications de son environnement technique, de manière à assurer un fonctionnement conforme aux exigences formulées lors de son développement

Corrective– Action de maintenance ayant pour but de corriger, soit des anomalies

de fonctionnement constatées du logiciel, soit des erreurs dans sa documentation

Perfective / Préventive– Action de maintenance ayant pour but soit d'améliorer les

performances ou la fiabilité du logiciel, soit d'en faciliter l'utilisation, l'exploitation ou la maintenance ultérieures. Soit de réduire la probabilité de défaillance ou la dégradation des performances du logiciel

Evolutive– Action de maintenance ayant pour but de prendre en compte une

évolution fonctionnelle


Principes généraux de la maintenance

L'informatique est au service de l'entreprise. Il est nécessaire de mettre en place des dispositions générales pour assurer la qualité de ses prestations

Appliquer à la maintenance la même démarche qu'au développement

Préparer la maintenance, pour s'assurer que les conditions nécessaires sont remplies– désigner l'équipe maintenance– prendre connaissance du logiciel et évaluer sa qualité– effectuer (proposer) les mises à niveau nécessaires– identifier les procédures, méthodes à appliquer, mettre en place les

moyens

Faire évoluer le logiciel par versions successives contrôlées


Evolution par versions L'évolution se fait uniquement par versions successives

contrôlées, les modifications "à la volée", même mineures, sont prohibées (« laisser le temps au temps »)

Ceci implique une gestion des demandes de modifications, pour– faire les bons choix,– coordonner les évolutions de produits différents, mais intégrés dans

une certaine mesure

Les contraintes quotidiennes sont bien sûr à prendre en compte, mais elles sont réduites au minimum

Cette gestion assure alors une bonne visibilité


Le processus de maintenance

Il comporte six grandes activités certaines ponctuelles :

– préparation de la maintenance

d'autres cycliques durant la vie du logiciel :– prise en compte des demandes de modification– assistance aux utilisateurs et exploitants– traitement des anomalies– réalisation d'une version / révision– mise en service d'une version / révision


Organisation fonctionnelled’un projet


Organisation fonctionnelle d’un projet

Met en évidence– la manière selon laquelle le chef de projet délègue ses responsabilités– les missions des différents intervenants– les circuits de communication

» internes» avec l'extérieur (sous-traitants, fournisseurs...)

Toutes les responsabilités doivent être clairement identifiées.... et il y en a beaucoup !


Les différentes responsabilités Responsable technique

– conception et réalisation, coordination de la résolution des problèmes techniques, validation

– formation, assistance aux équipes de réalisation Responsable du projet

– coordination des développements, choix des fonctionnalités retenues– gestion des équipes et des moyens, suivi du projet– organisation de la recette et de la livraison

Responsable qualité– production et suivi du plan qualité– audit des processus, participation aux revues et inspections, contrôle

des produits et fournitures Responsables du site, de la gestion de configuration, de la

documentation, du matériel, commercial, produit

Responsable utilisateurs : ?

Documents

Organisation des projets 1 /25 Bernard Cherbonneau / M1 Master Informatique / Module TER 2008 Organisation des Projets