Direction Technique Cycle de vie du projet et Cas dutilisation

Direction Technique

Cycle de vie du projet et Cas Cycle de vie du projet et Cas d’utilisationd’utilisation

Objectifs

• Détailler le cycle de vie d’un projet itératif.• Connaître les bonnes pratiques de développement

logiciel. • Appréhender le processus de développement

logiciel.• Comprendre les cas d’utilisations.

Qu’est ce qu’un cycle de vie

• Ensemble généralement séquentiel de phases de projet, dont le nom et le nombre sont déterminés en fonction des besoins de suivi par l’(es) organisation(s) impliquée(s) dans le projet.

– Exemples• Cycle en Cascade• Cycle en V• Cycle en Spirale

Principes de basePrincipes de base

• Cycle de vie linéaire, séquentiel, dit «en cascade».• Celui-ci a été défini dans les années 70.• Ce cycle de vie est basé sur la production

d’éléments livrables.• Le cycle de vie «en V» est une alternative au cycle

en cascade.

Cycle de vie en cascade


1. Now is the time for men in the ranks to stay in the ranks.











Recueillirles exigences Analyser

Concevoir

Coder

Intégrer, tester & effectuer le contrôle qualité

2 mois2 mois

1 mois1 mois

4 mois4 mois

12 mois12 mois

2 mois2 mois

Que se passe-t-il lorsqu’on découvre à ce stade des changements par rapport

aux exigences ?

Et à ce stade ?

Et à celui-ci ?


Le cycle de vie en cascade

• Les fonctionnalités (exigences) doivent être clarifiées avant de débuter la conception ou l’implémentation.

• Les objets du domaine (Métier) sont précisément modélisés avant la conception ou l’implémentation.

• Un projet bien mené suit du début à la fin du projet un plan détaillé construit au démarrage.

• Des architectes et analystes experts doivent définir la conception, avant de la transmettre aux programmeurs pour l’implémentation.


Caractéristiques d’un cycle de vie en cascade

• Suppose que l’on puisse définir toutes les exigences, ou au moins la plupart, dès le début.

• Refuse tout changement pour «tout bien faire dès le début».

– La formalisation exacte des exigences doit précéder la conception, qui doit elle-même être finalisée avant de passer à l’implémentation.

• Exige d’accorder une attention très importante aux documents.

– Ex. : livrer une première ébauche, attendre 15 jours les retours, intégrer ces commentaires (10 jours) , livrer une nouvelle version,...


Difficultés liées au cycle de vie en cascade (1)

• Retarde la résolution des facteurs de risque.– Par exemple, intégration tardive dans le cycle de

vie• Entraîne une identification tardive de la conception,

et un démarrage tardif du codage.• Entraîne des relations conflictuelles avec les parties

prenantes en raison :– Du manque de clarté de la définition des exigences.– D’engagements importants dans un contexte de

profonde incertitude.– D’un désir inévitable de procéder à des

changements.


Difficultés liées au cycle de vie en cascade (2)

• Il doit permettre de :– Bien comprendre les demandes des utilisateurs

finaux.– Tenir compte des changements du cahier des

charges.– Empêcher la découverte tardive de défauts

sérieux dans le projet.– Traiter au plus tôt tous les points critiques du

projet.– Bien communiquer avec le client.– Bien maîtriser la complexité.– Favoriser la réutilisation.– Définir une architecture robuste.– Faciliter le travail en équipe.– ...


Le processus « idéal » pour le développement de logiciel

7 bonnes pratiques

Développement de manière itérative.

Pilotage par les risques.

Gestion des exigences (piloté par les cas d’utilisation).

Maîtrise des modifications.

Développement à base de composants centré sur l’architecture.

Évaluation continue de la qualité.

Modélisation visuelle.

Les bonnes pratiques …Les bonnes pratiques …

Qu’est ce qu’un processus ?

• Suite ordonnée d’opérations aboutissant à un résultat.– Un même projet s’appuie sur de multiples processus

simultanés.

ProjetGestion des exigences

Implémentation

Test

Gestion de configuration

Gestion de projet

Origine du processus unifiéOrigine du processus unifié

Notion de processus (1)

Les spécialistes en méthodologie distinguent:

• les processus «lourds» des processus «légers»

– Terme péjoratif qui sert à suggérer que le processus présente l'une des caractéristiques suivantes.

• nombreux artefacts créés dans un environnement bureaucratique;

• rigidité et contrôle; • planification à long terme; • élaborée et détaillée;

– processus prédictif plutôt qu'adaptatif. • les processus «prédictifs»

– tente de prévoir et de planifier en détail toutes les activités et les allocations de ressources (les individus) sur une période relativement longue.

– Les processus prédictifs ont généralement un cycle de vie en "cascade" ou séquentiel, qui consiste à :

1.Définir tous les besoins.2.Mettre au point une conception détaillée. 3.Implémenter.


Notion de processus (2)

•Des processus «adaptatifs». – Accepte que le changement soit un moteur inévitable, et il

favorise souplesse et adaptation. Son cycle de vie est habituellement itératif.

– Un processus "agile" est léger et adaptatif.– De préférence, l'ensemble des activités et des artefacts doit être

restreint. – Comme le Processus Unifié est itératif, les spécifications et la

conception ne sont pas terminées avant le début de l'implémentation. Elles sont développées sur un mode adaptatif lors de la suite des itérations, grâce au feed-back.

– Le projet global n'a pas de plan détaillé.• Il existe un plan de phases qui estime une date d'achèvement et

d'autres échéances majeures, mais ne détaille pas précisément les étapes, nécessaires pour les atteindre.

• Un plan détaillé, nommé plan d'itération, ne planifie de façon détaillée qu'une itération à la fois.

• La planification détaillée s'effectue de manière adaptative d’itération en itération.


Activités du processus (UP)

Inception Élaboration Construction Transition

Organisation selon le temps

Organisation selon le contenu

V1

Itération(s) Itér. #1 Itér. #2 Itér. n Itér. n+1 Itér. n+2 Itér. m

Principaux enchaînements du processus

Modélisation métier

Gestion des exigences

Analyse et conception

Implémentation

Tests

Déploiement

Principaux enchaînements de soutien

Gestion de la config. & des changements

Direction de projet

Environnement

10% 30% 50% 10%

Répartition typique de l’effort

Aspect statique

Aspect dynamique

Processus à 2 dimensionsProcessus à 2 dimensions

Bonne pratique

• Bonne pratique : Développer de manière itérative.

• Une itération est une séquence définie d’activités qui se déroule selon un plan établi et se termine par une livraison (interne ou externe), et pour laquelle on a défini des critères d’évaluation.

Définition d’une itération

Itératif …Itératif …

Qu'est-ce que le Développement Itératif ?(1)

• C’est planifier et gérer.• C’est prévoir.• C’est adapter les modifications des

besoins en douceur.• C’est piloté par le risque.• C’est basé sur des prototypes évolutifs

qui fonctionnent, pas de la documentation.

• Ça implique le client et l’utilisateur pendant tout le processus.


• Basé sur de petites étapes, le feedback et l’adaptation.• Aussi appelé évolutif, en spirale, . . .• Le feedback continu est un élément clé du succès.

– De la part le retour des utilisateurs, des tests, . . .• A chaque itération, on s'adapte en se basant sur le feedback et les leçons de la dernière itération, et on converge doucement

vers de meilleurs : – Conception, Plans, Exigences, Estimations.

Itération1

Con-ception

Code+Conception+Test+IntégrationAna-lyse

...Itération

2

Con-ception

Code+Conception+Test+IntégrationAna-lyse

2 ou 4 semaines 2 ou 4 semaines


Qu'est-ce que le Développement Itératif ?(2)

Analyse et conception

Implémentation

Test

Évaluation

Planification

BesoinsPlanification

initiale

DéploiementChaque itération a pour résultat une version exécutable

Cycle itératif


La réduction du risque pilote les itérations

Risques Projet InitiauxPortée Initiale du Projet

Réviser Plan Global Projet• Coût• Planning• Portée/Contenu

Planifier Itération N• Coût• Planning

Fixer Itération N

Risques ÉliminésRéviser Risques Projet• Réordonner Priorités

Développer Itération N• Collecter coût et métriques de qualité

Définition de scénariosRisques supérieurs

Itération N


Durée des itérations

• « Idéalement, une itération doit durer de 2 à 6 semaines. »P.Kruchten, « The RUP - An Introduction »

• 1 - 30 personnes : 2-4 sem.• 30 - 50 personnes : 2-6 sem.

• Raccourcir les itérations permet de réduire les risques.• Facteurs augmentant la durée :

– Séparation géographique de l’équipe.– Premier projet UP pour l’organisation ou l’équipe.– Premier projet objet pour l’organisation ou l’équipe.

Incep-tion

Elaboration ConstructionTransi-

tion

Modifications des besoins


3 caractéristiques importantes de l’approche itérative

• Attaque du risque avec une progression quantifiable.– La progression est mesurée sur le

produit, pas sur de la documentation ou sur des estimations.

• Intégration continuelle.– Pas testée en une seule fois la veille de

rendre le projet !

• Publications fréquentes d’exécutables.– Certains en interne, certains fournis au

client.


LundiRépartition du travail.Exigences.Analyse & conception

LundiRépartition du travail.Exigences.Analyse & conception

MardiExigences.Analyse & conception.

MardiExigences.Analyse & conception.

MercrediAnalyse & conception Implém.Tests & contrôle qualité.

MercrediAnalyse & conception Implém.Tests & contrôle qualité.

Semaine 1

Semaine 2

JeudiImplém. Préparation Démo.Planif. itération suivante.Plan du projet.

JeudiImplém. Préparation Démo.Planif. itération suivante.Plan du projet.

VendrediÉvaluation de l’itérationFinalisation planification

VendrediÉvaluation de l’itérationFinalisation planification

JeudiAnalyse & conception Implém.Tests & Contrôle qualité

JeudiAnalyse & conception Implém.Tests & Contrôle qualité

VendrediImplém.Tests & contrôle qualité. Intégration

VendrediImplém.Tests & contrôle qualité. Intégration

LundiImplém.Tests & contrôle qualité.Intégration

LundiImplém.Tests & contrôle qualité.Intégration

MardiImplém.Tests & contrôle qualité.Intégration

MardiImplém.Tests & contrôle qualité.Intégration

MercrediImplém.Tests & contrôle qualité.Intégration

MercrediImplém.Tests & contrôle qualité.Intégration


Exemple d’une itération de deux semaines

Bénéfices

• La publication de versions intermédiaires force l’équipe de développement à finir quelque chose à intervalles réguliers.– On ne peut pas tomber dans le piège du “fini

à 90% avec 90% restant à faire”.• Les problèmes et les modifications peuvent

être traités dans des itérations futures, plutôt que de devoir casser la production en cours.

• Les acteurs qui supportent le projet (testeurs, support hotline, …) peuvent organiser leur travail de manière plus efficace.


Modèle en spirale

• Défini par Barry Boehm en 1981.• Réévaluation des risques en cours de

développement.• Chaque phase / itération démarre avec un

objectif et finit par une validation client.

• Estimations budgétaires et calendaires plus réalistes au fur et à mesure de l'avancement du projet.

• Facilité de prise en compte des inévitables changements intervenant en cours de projet.


A retenir

• Décomposer le développement en courtes itérations

Pour surmonter lesdifficultés : itérer !!

ConclusionConclusion

Bonne pratique

• Bonne pratique : Gestion des exigences grâce aux cas d’utilisation.

Cas d’utilisation

• Un cas d’utilisation est une séquence d’actions que réalise un système et qui fournit un résultat observable ayant une valeur pour un acteur particulier.

• Un acteur est quelqu’un ou quelque chose se situant à l’extérieur du système et qui interagit avec lui.

La gestion des exigencesLa gestion des exigences

Exemple(1)

• Etudier le Cas d’utilisation « Retrait Visa » formalisé avec UML.

• Ajouter quelques exigences non fonctionnelles à ce cas d’utilisation.


Système DAB

Client

Système

ConsulterSolde

RetirerArgent

Consulter dernières

OpérationsCas

d’utilisation

ActeursFrontièredu système

Système d’autorisation

VISA

Exemple(2)


Exemple(3)

Liste des acteurs

Liste de pré-conditions

Événementdéclencheur

Liste de post-conditions

Acteurs : client, système d’autorisation VISA

Cas d’utilisation : Retrait VISA

Pré-conditions :- le DAB fonctionne- la caisse du DAB est alimentée

Description :Le cas d’utilisation commence lorsque le client introduit sa cartedans le lecteur.[…]

Post-conditions :- le montant demandé est délivré- l’opération de retrait est enregistrée- le client a récupéré sa carte

Résumé : Retrait d’argent avec une carte bleue VISA

Séquences d’interactions


• Un cas d’utilisation spécifie :– Un enchaînement « nominal ».– Des enchaînements alternatifs.– Des enchaînements d’erreur et d’exception.

Enchaînement nominal :

Lorsqu’un enchaînement nominal ou alternatif est exécuté, les post-conditions sont atteintes.

1. Enchaînement nominal :

a. Le cas d’utilisation commence lorsque le client introduit sa carte

b. Le DAB demande au client de saisir son code d’identification.

e. Le DAB demande une autorisation au système VISA.

f. Le système VISA donne son accord et délivre un numéro d’autorisation.

g. Le DAB demande au client de saisir le montant désiré.

h. Le client saisit le montant désiré.

i. Le DAB contrôle le montant demandé par rapport au solde hebdomadaire

j. Le DAB rend sa carte au client.

k. Le client reprend sa carte.

l. Le DAB délivre les billets et un ticket

m. Le client prend les billets et le ticket.

n. Ce cas d’utilisation se termine lorsque le DAB est prêt à fonctionner

c. Le client saisit son code d’identification.

d. Le DAB vérifie le code d’identification avec celui codé sur la carte.

Exemple(4)


Exemple(5)

Enchaînement d’erreur :

Lorsqu’un enchaînement d’erreur est exécuté, les post-conditions sont toujours atteintes.

2. Enchaînement d’erreur : code d’identification incorrectL’enchaînement démarre au point 1-d. de l’enchaînement nominala. Le DAB indique au client que le code est erronéb. Le DAB enregistre l’échec sur la carteL’enchaînement nominal reprend au point 1-b.

3. Enchaînement d’exception : le client a saisi 3 fois un code erroné : a. le DAB confisque la carteb. Le système VISA est informé et le cas d’utilisation se termine.

4. Enchaînement d’erreur : montant supérieur au solde hebdomadaireL’enchaînement démarre au point 1-i. de l’enchaînement nominal

a. Le DAB indique que le montant demandé est supérieur au solde L’enchaînement nominal reprend au point 1-g.

Enchaînement d’exception :

Lorsqu’un enchaînement d’exception est exécuté, les post-conditions ne sont pas atteintes.


A retenir

• Décomposer le développement en courtes itérations

Décrire les exigencespar les cas d’utilisation !!


…Et aussi

Appliquer les 5 autres bonnes pratiques : Pilotage par les risques. Maîtrise des modifications. Développement à base de composants

centré sur l’architecture. Évaluation continue de la qualité. Modélisation visuelle.


Plus d’informations …

• Livres – Introduction au Rational Unified Process, Philippe Kruchten,

Eyrolles, 2000.– Rédiger des cas d’utilisation efficaces, Alistair Cockburn,

Eyrolles, 2001.– Le processus unifié de développement logiciel, I.Jacobson,

G.Booch, J.Rumbaugh, Eyrolles, 2000.– Rational Unified Process Made Easy: A Practitioner's Guide

to the RUP, Per Kroll & Philippe Kruchten, Addison-Wesley, 2003.

– Object Solutions - Managing the Object-Oriented Project, Grady Booch, Addison-Wesley, 1996.

– Articles• Sites

– UML Rational (IBM) : http://www.therationaledge.com– AmbySoft : http://www.ambysoft.com/– Ronin :

http://www.ronin-intl.com/publications/unifiedProcess.html– OMG : http://www.omg.org/– UML : http://www.uml.org/


Documents

Direction Technique Cycle de vie du projet et Cas dutilisation