Brique BDL Module Gestion de Projets Logiciels

Cycle de vie du logiciel et bonnes pratiques de dveloppement

Sylvie Vignes

Objectifs de la prsentation Prsenter les cadres de dveloppement du logiciel en milieu industriel En dgager 7 bonnes pratiques Illustrer ces bonnes pratiques dans le contexte dun projet ENST

n n

V1.0

I - Dfinitions de base

Dfinitions de base

Quest-ce-quun projet ? Entreprise temporaire dcide pour obtenir un produit ou un service Ensemble dactivits organises permettant de crer un produit ou un service unique avec une qualit dfinie dans le cadre dun budget fix Effort temporaire ayant un dbut et une fin dtermins Un choix de facteurs de qualit
V1.0 4

Application

Notre projet
n

La DFI de lENST souhaite mettre en place un site intranet permettant :

linscription des tudiants aux briques de leur choix l La consultation par les professeurs des lves inscrits leurs cours l La consultation de lemploi du temps
l

n n

Budget : 12 personnes x mois Dure : 3 mois

V1.0

Dfinitions de base

Quest-ce quun cycle de vie ?

n

Ensemble squentiel de phases, dont le nom et le nombre sont dtermins en fonction des besoins du projet, permettant gnralement le dveloppement dun service ou dun produit
Exemples

Cycle en Cascade l Cycle en V l Cycle en Spirale

l l

Cycle en Y
V1.0 6

Dfinitions de base

Le cycle de vie en cascade

n

Cycle de vie linaire, squentiel, dit en cascade Celui-ci a t dfini dans les annes 70 Ce cycle de vie est bas sur la production dlments livrables Le cycle de vie en V est une alternative au cycle en cascade

n n

V1.0

Application

Le cycle de vie en cascade

1 semaine
1. Now is the time for men in the ranks to stay in the ranks. 2. Now is the time for men in the ranks to stay in the ranks. 3. Now is the time for men in the ranks to stay in the ranks. 4. Now is the time for men in the ranks to stay in the ranks. 5. Now is the time for men in the ranks to stay in the ranks. 6. Now is the time for men in the ranks to stay in the ranks. 7. Now is the time for men in the ranks to stay in the ranks. 8. Now is the time for men in the ranks to stay in the ranks. 9. Now is the time for men in the ranks to stay in the ranks. 10. Now is the time for men in the ranks to stay in the ranks. 11. Now is the time for men in the ranks to stay in the ranks.

1 semaine Analyser 3 semaines Concevoir

Que se passe-t-il lorsquon dcouvre ce stade des changements par rapport aux exigences ? Et ce stade ? Et celuici ?

Recueillir les exigences 1. 2. 3. 4. 5. 6. 7. 8.

1 mois Coder

Interviewer les professeurs et les lves Rdiger des spcifications du site Analyser le besoin Identifier et formaliser une architecture Coder Intgrer, tester Vrifier la qualit du produit Livrer

3 semaines

Intgrer, tester & effectuer le contrle qualit

V1.0 8

Principes de base

Difficults lies au cycle de vie en cascade (1)

n n

Suppose que lon connaisse prcisment les besoins (exigences), ou au moins la plupart, ds le dbut Refuse tout changement pour tout bien faire ds le dbut
l

La formalisation exacte des exigences (spcification) doit prcder la conception, qui doit elle-mme tre finalise avant de passer limplmentation. Ex. : livrer un document, attendre 15 jours les retours, intgrer ces commentaires (10 jours) , livrer une nouvelle version,...

Exige daccorder une attention trs importante aux documents

l

V1.0

Principes de base

Difficults lies au cycle de vie en cascade (2) n Retarde la rsolution des facteurs de risque
l

Par exemple, intgration tardive dans le cycle de vie

Entrane une identification tardive de la conception, et un dmarrage tardif du codage Entrane des relations conflictuelles avec les parties prenantes en raison :
Du manque de clart de la dfinition des exigences l Dengagements importants dans un contexte de profonde incertitude l Dun dsir invitable de procder des changements
l V1.0 10

Principes de base

Le cycle de dveloppement en V
Analyse des besoins
validation

Exploitation et maintenance Tests dacceptation Intgration du systme

Analyse du logiciel Conception de larchitecture

Vrification systme

Vrification sous-systmes

Conception dtaille
Ver. modules

Intgration des sous-systmes

Implementation

Tests unitaires

V1.0

11

Principes de base

V&V

Dfinitions (Boehm 76):

- Validation: Am I building the rigth system? - Verification: Am I building the system right?

ISO 9000-3
Processus d'valuation du logiciel pour s'assurer qu'il satisfait aux exigences spcifies

V1.0

12

Principes de base

Cycle de vie en V : inconvnients

hypothses peu fondes : squentialit des phases non conforme la ralit incapacit en prendre en compte des volutions du CdC pendant la construction du systme absence de V&V la fin de chaque tape absence d'une continuit des outils pas adapt aux systmes non fonctionnels trop d'informel peu ou pas de possibilit de maquettage et/ou de prototypage.

V1.0

13

Principes de base

Evaluation du cycle de Vie en V : avantages

modle prouv car calqu sur la production industrielle classique

permet l'organisation du travail et des quipes => prdiction (Cocomo) et contrle des cots facilits favorise la dcomposition hirarchique fonctionnelle propose des tapes cls (documentation, revues) => bon suivi du projet permet de garantir une certaine qualit (plan assurance qualit) existence de standards: MIL-STD-498, GAM-T17(V2), Do 178 B, STAN-CS 055, ESA, ... adapt de grands projets

beaucoup d'outils support.

V1.0 14

Principes de base

Cycle de vie en spirale

Cot cumul
An aly se des risq ues

Dtermination des objectifs, des choix et des contraintes

Prototype exprimental

e typ o t pro

Conception tion p dtaille e c Validation le Con giciel Plan de dveloppement des besoins lo n Code ceptio n o c e la Test unitaire Plan d'intgration et tests Validation d ification et v r Test conformit Implmentation
V1.0 15

Plan du cycle de vie

Besoin logiciel

Principes de base

Cycle en Y
Branche Technique Capture des besoins techniques Conception gnrique

Branche fonctionnelle Capture des besoins fonctionnels Analyse

prototype

Conception prliminaire Conception dtaille Codage et tests Recette

V1.0

16

Un processus incrmental pour le cycle en Y

Prtude Elaboration Construction

-Validation du principe -outils de dvlp Incrment 1

-Focalis sur larchitecture -Ralisation fcts prioritaires Inc.2 Inc. 3

Avancement jusquau systme complet

Inc.4

Inc.5

Inc.6
V1.0 17

temps

Principes de base

Le processus idal pour le dveloppement de logiciel n doit permettre de :

Bien comprendre les demandes des utilisateurs finals l Tenir compte des changements du cahier des charges l Empcher la dcouverte tardive de dfauts srieux dans le projet l Traiter au plus tt tous les points critiques du projet l Bien communiquer avec le client l Bien matriser la complexit l Favoriser la rutilisation l Dfinir une architecture robuste l Faciliter le travail en quipe l ...
l V1.0 18

Principes de base

Dfinition de la fiabilit
n

De faon oprationnelle, on parle de Sret de fonctionnement Proprit d'un systme informatique permettant ses utilisateurs de placer une confiance justifie dans le service qu'il dlivre

V1.0

19

Principes de base

Dclinaisons de la notion de fiabilit

Terme Franais Disponibilit Fiabilit Maintenabilit Terme Anglais Availability Reliability Maintenability Description
Capacit tre prt dlivrer le service Capacit maintenir la continuit de service Aptitude aux rparations et volutions Absence de dfaillances catastrophiques Absence de divulgation non autorise Pas de dtrioration (matriel ou logiciel) Confidentialit + scurit + disponibilit
V1.0 20

Scurit-innocuit Safety Confidentialit Intgrit Scuritconfidentialit Confidentiality Integrity Security

II - Maturit et normes de dveloppement

Maturit et normes de dveloppement

Des mthodes dvaluation et dvolution des organisations

(Des cadres de management normaliss )
n

Standard

CMM (Capability Maturity Model)

l

Mis au point par Software Engineering Institute l Standard; version franaise sur http://www.CRIM.ca
l

SPICE
ISO 15504 (Software Process Improvement Capability dEtermination) l Norme Internationale qui volue paralllement la norme ISO 9000

V1.0

22

Maturit et normes de dveloppement

Les 5 niveaux de maturit du CMM Processus en Optimis

amlioration continue Processus prvisible Processus standard cohrent Dfini Matris

Processus structur

Reproductible

Les hros

V1.0

23

Maturit et normes de dveloppement

secteurs cls
n n n n n n

Niveau 2 reproductible : Gestion des exigences Planification de projet Suivi et supervision de projet Gestion de la sous-traitance Assurance Qualit Gestion de la configuration

Consensus dans l'entreprise sur la manire de faire mais pas de formalisation Gestion rigoureuse des cots et des dlais mais repose sur des comptences individuelles
V1.0 24

Maturit et normes de dveloppement

Niveau 3 Dfini :
n n n n n n

secteurs cls

Focalisation organisationnelle Dfinition du Processus Programme de formation Coordination intergroupes Revue par des pairs

Processus de dveloppement formalis et document Service de dfinition et de suivi des mthodes de l'entreprise
V1.0 25

Maturit et normes de dveloppement

Niveau 4 Matris :
n n

secteurs cls

Gestion de la qualit logicielle Gestion quantitative de processus

r

Processus formel de collecte d'informations pour mesurer le processus d'laboration de systmes ainsi que les produits rsultants P

Niveau o 5 Optimis :
n n n

c e Gestion des changements s s Prvention des dfauts u s

secteurs cls

technologiques,

f des rsultats de la mtrologie pour amliorer les mthodes Utilisation o r

V1.0 26

III- Les 7 bonnes pratiques du dveloppement logiciel

Les bonnes pratiques du dveloppement logiciel

Le LogicielUn Mtier Risque 53% des projets cotent au moins 200% des estimations initiales. On estime 81 billion de dollars la somme dpense en 1995 au U.S.A. sur des projets arrts Arrt avant la fin. avant la
fin 30%

Men terme 70%

Source: Rapport Standish, 1995

V1.0

28

Les bonnes pratiques du dveloppement logiciel

Symptmes Courants d'Echec des Projets (1) Symptmes les plus frquents des projets ayant chous :

DIncapacit de grer les modifications des exigences. DMauvaise comprhension des besoins des utilisateurs finals. DLes modules qui ne fonctionnent pas ensemble. DDu logiciel difficile maintenir ou faire voluer. DDu logiciel de mauvaise qualit (beaucoup d'anomalies).

V1.0

29

Les bonnes pratiques du dveloppement logiciel

Symptmes Courants d'Echec des Projets (2) DConstruction d'un processus non fiable.

DMembres de l'quipe isols,

incapables de dterminer qui a chang quoi, quand, o et pourquoi.

DProcdures de test coteuses. DDcouverte tardive de problmes.

V1.0

30

Les bonnes pratiques du dveloppement logiciel

7 bonnes pratiques (1)

Meilleures pratiques reconnues Lutilisation de ces pratiques maximise les chances de russite du projet Le non respect de ces pratiques introduit un maillon faible
V1.0 31

Les bonnes pratiques du dveloppement logiciel

7 bonnes pratiques (2)

Dveloppement de manire itrative Dveloppement base de composants centr sur larchitecture Pilotage par les risques Gestion des exigences Matrise des modifications Evaluation continue de la qualit Modlisation visuelle
V1.0 32

Ce sont celles prconises dans le Processus Unifi

IV - Le Processus Unifi

Origines du Processus Unifi

1998 : Apparition de UP

Pas de nouvelles ides mais un ensemble de bonnes pratiques largement rpandues dans les processus modernes Adoption rapide comme standard de fait en Europe et en Amrique du nord
l

IBM, Chase-Manhattan, Alcatel, MCI, British Aerospace, Volvo, Intel, Merrill, E&Y, Deloitte, Ericsson, Cartier International,Valtech . . .
V1.0 34

Origines du Processus Unifi

Quest-ce que le Unified Process ?

n n

Cest un processus de dveloppement de logiciel Il permet de dfinir et daffecter des tches et des responsabilits au sein dune organisation de dveloppement Son but est dassurer la production dun logiciel de grande qualit, satisfaisant les demandes des utilisateurs finals dans les dlais et avec un budget prvisibles

V1.0

35

IV.1 -Le Processus Unifi

Bonne pratique : Dveloppement de manire itrative

Dveloppement de manire itrative

n n

Qu'est-ce que le Dveloppement Itratif ? Bas sur de petites tapes, le feedback et ladaptation. Aussi appel volutif, en spirale, . . .

Itration 1

Itration 2

...

Analyse

Conception

Code+Conception+Test+Intgration

Analyse

Conception

Code+Conception+Test+Intgration

2 ou 4 semaines

2 ou 4 semaines

V1.0

37

Dveloppement de manire itrative

Feedback et Adaptation
De part le retour des utilisateurs, des tests, . . .

Le feedback continu est un lment cl du succs.

l

A chaque itration, on s'adapte en se basant sur le feedback et les leons de la dernire itration, et on converge doucement vers de meilleurs :
l

Conception, Plans, Exigences, Estimations.

2 or 4 semaines

itrations

itrations
V1.0 38

Dveloppement de manire itrative

Une itration est une squence dfinie dactivits

l

qui se droule selon un plan tabli et se termine par une livraison (interne ou externe), et pour laquelle on a dfini des critres dvaluation

V1.0

39

Dveloppement de manire itrative

Planification initiale

Besoins

Analyse et conception

Planification

Implmentation Dploiement Test

V1.0 40

valuation
Chaque itration a pour rsultat une version excutable

Dveloppement de manire itrative

Exemple pour le site de lENST

Itration 1 Itration 2 ...

Analyse

Conception

Code+Conception+Test+Intgration

Analyse

Conception

Code+Conception+Test+Intgration

2 ou 4 semaines

2 ou 4 semaines

Consulter la liste des cours

Sinscrire un cours

V1.0

41

Dveloppement de manire itrative

Exemple dune itration de deux semaines pour le site de lENST

Semaine 1
Lundi Lundi Rpartition Rpartition du dutravail travail Exigences Exigences Analyse Analyse& & conception conception Mardi Mardi Exigences Exigences Analyse Analyse& & conception conception Mercredi Mercredi Analyse Analyse& & conception conception Implm. Implm. Tests Tests& & contrle contrle qualit qualit Jeudi Jeudi Analyse Analyse& & conception conception Implm. Implm. Tests Tests& & Contrle Contrle qualit qualit Vendredi Vendredi Implm. Implm. Tests Tests& & contrle contrle qualit qualit Intgration Intgration

Semaine 2
Lundi Lundi Implm. Implm. Tests Tests& & contrle contrle qualit qualit Intgration Intgration Mardi Mardi Implm. Implm. Tests Tests& & contrle contrle qualit qualit Intgration Intgration Mercredi Mercredi Implm. Implm. Tests Tests& & contrle contrle qualit qualit Intgration Intgration Jeudi Jeudi Implm. Implm. Prparation Prparation dmo dmo Planif. Planif. itration itration suivante suivante Plan Plandu du projet projet Vendredi Vendredi valuation valuation de delitration litration Finalisation Finalisation planification planification

V1.0

42

Dveloppement de manire itrative

Pratique inspire les mthodes agiles n Bases sur des itrations trs courtes, des incrments petits n Beaucoup de tests
http://www.xprogramming.com/ (des environnements de tests tlcharger)

Requirent lutilisateur quasiment en permanence n La plus connue Extreme Programming http://www.xp-france.org/ Communication Feed-back http://agilealliance.org/ Simplicit
n

Courage
V1.0 43

IV-2 Le Processus Unifi

Bonne pratique : Dveloppement base de composants centr sur larchitecture

Dveloppement base de composants centr sur larchitecture

Au cours des premires itrations, on construit et on valide une architecture logicielle

A partir de composants existants, standards du march l viter les dveloppements spcifiques
l

Construire larchitecture et la tester tt mme si la solution nest pas parfaite et incomplte

V1.0

45

Dveloppement base de composants centr sur larchitecture

Des Composants?

n n

Des units logicielles "bote-noire" avec une API Fonctionnent gnralement dans une (locale ou distante) architecture base de composants:
l

EJB, COM, .NET, JavaBeans, Servlet Acqurir des composants existants afin d'acclrer le dveloppement Etablir une culture d'acquisition ou d'achat de composants, plutt que de dvelopper toutes les parties du logiciel.

Le UP encourage la bonne pratique suivante:

l l

V1.0

46

Avantage des Architectures Base de Composants Les composants favorisent les architectures rsistantes. La modularit permet d'avoir une sparation claire entre les lments d'un systme. La rutilisation est facilite par l'utilisation de composants commerciaux.

Dveloppement base de composants centr sur larchitecture

V1.0

47

Exemple dune architecture pour le site de lENST

Navigateur Internet Explorer
:Client Browser :Server HTTP Request (GET FILEXYZ) HTTP Server transformed request Java Virtual Machine :MyServlet

Dveloppement base de composants centr sur larchitecture

Chaque requte HTTP se Each HTTP request goes dirige vers le processus JVM to the existing JVM existant et sexcute process, and simply runs simplement on a new thread. sur un nouveau thread

Serveur Web TomCat

V1.0

48

IV-3 Le Processus Unifi

Bonne pratique : Pilotage par les risques

Pilotage par les risques

Quest ce quun risque ?

n

Un risque est un vnement redout dont loccurrence est plus ou moins prvisible et provoquant, lorsquil se produit, des dommages sur le projet. Il ne faut pas confondre risque et problme.
l

Lhiver, il faut se faire vacciner contre la grippe

Vous avez la grippe, je vais vous prescrire des antibiotiques

Un problme est un risque qui sest rvl.

V1.0 50

Pilotage par les risques

Le pilotage par les risques, cest :

l

Analyser les risques potentiels le plus tt possible ds les premires itrations l Les hirarchiser l Commencer par travailler sur les lments les plus exposs l Par exemple :
l l

Lintgration, larchitecture La gestion des ressources humaines ncessite une attention particulire : Besoins ? Profils ? Organisation de lquipe projet ? Communication et management de lquipe

V1.0

51

Pilotage par les risques

Penser aux risques techniques, mais aussi :

aux risques lis au client l aux risques lis au domaine applicatif l aux risques lis lorganisation du projet
l

V1.0

52

Pilotage par les risques

Exemple de risques pour le site de lENST

n

Risques lis au client :

l

Convergence du besoin
l

Cause : de nombreux utilisateurs : direction, professeurs, tudiants

Risques techniques :
l

Matrise du serveur web

l

Cause : premire utilisation du serveur tomcat Cause : rentre des tudiants simultane

Pic daccs au site au mois de septembre

l

Risques lis lorganisation du projet :

l

Disponibilit de lquipe
l

Cause : le projet se droule durant la priode des examens

V1.0 53

Le Processus Unifi
IV-4 Bonne pratique : La gestion des exigences

La gestion des exigences

Facteurs de dpassement et dabandon

1) Lack of User Input 1) 1)Manque Manquede departicipation participationdes desutilisateurs utilisateurs 2) Incomplete Requirements 2) incomplte 2)Identification Identification incompltedes desBesoins Besoins and Specifications 2) Incomplete Requirements

1) Lack of User Input

Grer les
exigences

and Specifications 3) Changing Requirements 3) Besoins 3) Changing qui Requirements au 3) Besoins quichangent changent aucours coursdu duprojet projet and andSpecifications Specifications
Standish Group, 97

V1.0

55

La gestion des exigences

Identification des exigences

n

Quest ce quune exigence ?

l

Condition laquelle le systme doit satisfaire ou une capacit dont il doit faire preuve.
[RUP]

On distingue :
l

Les exigences fonctionnelles

l

Qui formulent ce que le systme est charg de faire Dcrivent la qualit des services attendus du systme (performance, scurit de fonctionnement, IHM)

Les exigences non fonctionnelles

l

Le UP recommande de se servir des Cas dUtilisation UML pour identifier les exigences fonctionnelles.

V1.0

56

La gestion des exigences

Exemple dexigences pour le site de lENST (1)

Site ENST
Consulter Liste des cours
Etudiant Systme Frontire du systme

Acteurs

Sinscrire Un cours

Professeur

Consulter Liste des tudiants

Cas dutilisation

V1.0

57

La gestion des exigences

Exemple dexigences pour le site de lENST (2)

Cas dutilisation : Consulter Liste des tudiants Rsum : Liste des tudiants inscrits un cours Acteurs : Professeur Pr-conditions : -le site est actif -le professeur a accs au site -le cours est ouvert aux inscriptions Description : Le cas dutilisation commence lorsque le professeur se connecte sur le site. [] Post-conditions : - la liste des tudiants inscrits au cours est affiche

Liste des acteurs Liste de pr-conditions vnement dclencheur Squences dinteractions Liste de post-conditions

V1.0

58

La gestion des exigences

Exemple dexigences pour le site de lENST (3)

n

Un cas dutilisation spcifie :

Un enchanement "nominal" l Des enchanements alternatifs l Des enchanements derreur et dexception
l
1. Enchanement nominal : a. Le cas dutilisation commence lorsque le professeur se connecte sur le site b. Le site demande un identifiant et un mot de passe c. Le professeur saisit son identifiant et son mot de passe d. Le site vrifie lidentifiant et le mot de passe e. Le site demande le code du cours consulter f. Le professeur saisit le code g. Le site vrifie que code du cours existe et quil est ouvert aux inscriptions h. La liste des tudiants inscrits au cours est affiche lcran

Enchanement nominal : Lorsquun enchanement nominal ou alternatif est excut, les postconditions sont atteintes.

V1.0

59

La gestion des exigences

Exemple dexigences pour le site de lENST (4)

Enchanement derreur :

Enchanement dexception : Lorsquun enchanement dexception est excut, les postconditions ne sont pas atteintes.

Lorsquun enchanement derreur est excut, les post-conditions sont atteintes.

2. Enchanement derreur : identification incorrect Lenchanement dmarre au point 1-d. de lenchanement nominal a. Le site indique au professeur que lidentifiant et/ou le mot de passe sont errons Lenchanement nominal reprend au point 1-b. 3. Enchanement dexception : le professeur a saisi 3 fois un Identifiant ou un mot de passe erron : a. La connexion au site est coupe 4. Enchanement derreur : le cours nexiste pas Lenchanement dmarre au point 1-g. de lenchanement nominal a. Le site indique que le cours correspondant au code nexiste pas Lenchanement nominal reprend au point 1-e.
V1.0 60

La gestion des exigences

Comment Perdre un Client ...

1.

2.

3.

Votre quipe a l'habitude de toujours essayer de satisfaire le client (cela semble logique). Pendant le dveloppement, un professeur vient voir un dveloppeur et lui dit, Paul, j'aime ce que je vois mais je souhaiterais galement connatre la liste des tudiants inscrits plusieurs de mes cours. Pensezvous que vous pouvez le rajouter ? Paul: Bien sr! Pas de problme! Je m'en rappellerai.
V1.0 61

La gestion des exigences

Comment Perdre un Client ... Mauvaise rponse!

Pourquoi?

V1.0

62

La gestion des exigences

La Gestion des Exigences

n

Cela ne signifie pas :

l

Avoir des exigences correctes ds le dmarrage du projet.

C'est une pense irraliste du cycle "en cascade". Cela signifie:

l l l l

Ne pas tre ngligent. Les recueillir efficacement. Enregistrer, tracer, organiser (srement avec un outil). Et cela se rapporte au fait de considrer les changements de manire formelle (matriser les changements).
V1.0 63

Le Processus Unifi
IV-5 Bonne pratique : Matrise des modifications

Matrise des modifications

Multiplication du nombre de versions

l l

Lie au nombre ditrations Lie lvolution des besoins dans le temps Pour ne pas retarder une quipe Pour rpondre un besoin ponctuel du client

Ncessit de parallliser les dveloppements

l l

Grer les
modifications

n n n

Ngocier les volutions et les tracer ; enregistrer, valider, grer la configuration et les versions Documenter le projet Communiquer les changements Prvenir les conflits
V1.0 65

Matrise des modifications

Quest-ce quune demande de changement ?

n

Demande de changement (Change Request ou CR)

l

Requte pour modifier un artefact ou un processus. Dans la documentation dune demande de changement figurent des informations sur lorigine et limpact du problme considr, sur la solution propose et sur son cot. Demande dEvolution
l

Deux types
l

Spcifie une nouvelle caractristique du systme ou un changement par rapport au comportement tabli. Erreur ou dfaut
V1.0 66

Rapport dAnomalie
l

Matrise des modifications

Support type

Utilisation de fiches de demande de changement

l

Type
l

Demande dvolution Connatre la liste des tudiants inscrits plusieurs cours dun mme professeur Rapport danomalie Le nombre de tentatives pour se connecter au site est gal 3

l l

Status Informations complmentaires

V1.0 67

Le Processus Unifi
IV-6 Bonne pratique : Evaluation continue de la qualit

Evaluation continue de la qualit

Faire les Tests & AQ la fin ?

n

Il est dmontr que :

l

Corriger une anomalie plus tard cote 10-100 fois plus que de la corriger son origine.
Software Engineering Economics , Boehm, 1981.

Les produits avec le moins d'anomalies ont les dlais les plus courts.
l

La mauvaise qualit est la raison la plus courante de dpassement des dlais.

l

Applied Software Measurement, 1st edition, Jones 1991.

Assessment and Control of Software Risks, Jones 1994, 4000 project study.
l

La correction des anomalies consomme 40-50% du cot total. 60% des anomalies existent au moment de la conception.
l

IEEE Computer, Boehm, Sept 1987.

Principles of Software Engineering Management, Gilb, 1988.

V1.0 69

Evaluation continue de la qualit

Evaluation continue de la Qualit

n

Solution construite contrle produit

Vrification de ladquation de la solution aux besoins l Tests systmatiques et priodiques l Actions qualit
l

Process (UP) valuation interne

l

Respect des bonnes pratiques du Processus Unifi

Avantages :
Identification prcoce des dysfonctionnements Ractivit aux dviations constates l Matrise des risques de drapage
l l V1.0 70

Vrification de la qualit

Vous avez pass 3 mois construire le site de lENST. Maintenant que vous tes prts sortir le produit Alors, vous demandez vos amis :
n

A 11 heures demain matin, tout le monde se connecte et essaye de sinscrire un cours ainsi on pourra vrifier si le systme rsiste la charge prvue.

Est-ce le moment de vrifier cette proprit significative de l'architecture?

V1.0 71

Le Processus Unifi
IV- 7 Bonne pratique : La modlisation visuelle

Modlisation visuelle

Pourquoi Utiliser la Modlisation Visuelle?

n

On doit enregistrer nos penses et communiquer en utilisant des langages visuels et schmatiques (par ex., UML). Parce que :
l

On estime qu'au moins 50% de notre cerveau est impliqu dans le processus visuel. Les langages visuels sont naturels et faciles pour notre cerveau.

V1.0

73

Modlisation visuelle

La Bonne Quantit de Modlisation Visuelle

n

Se situe entre trop et, videmment, pas assez de modlisation visuelle. Des schmas, spcialement sur un tableau blanc, sont plus rapides que d'crire ou de changer du code. Ils permettent de rapides recherches et la modification des grandes lignes du systme en ignorant les dtails que la programmation nous obligerait prendre en compte.
V1.0 74

O UML est-il utilis dans le UP?

n

Modlisation visuelle

Par exemple. . .
Use-Case Model

Diagrammes des cas d'utilisation

Modle de Conception

Diagrammes de package Diagrammes de classe Diagrammes de collaboration

UML est principalement utilis ici.

Modle de Dploiement

Diagrammes de dploiement

V1.0

75

Modlisation visuelle

Diagramme de classe pour le site ENST

Etudiant Nom Anne Age 10..* assure 1..* sinscrit 1..* Cours Libell Code Professeur Nom Matire 1..2

V1.0

76

Les 7 bonnes pratiques du UP ?

n n

Sans regarder vos notes Retrouvez les 7 bonnes pratiques de UP

V1.0

78

Conclusion

Conclusion

7 bonnes pratiques pour le dveloppement de logiciel :

Dveloppement base de composants centr sur larchitecture Pilotage par les risques Gestion des exigences Matrise des modifications Evaluation continue de la qualit Modlisation visuelle

V1.0

80

Conclusion

mais cest surtout Dcomposer le dveloppement en courtes itrations

Pour surmonter les difficults : itrer !!

V1.0

81

Conclusion

Pour
l l

Bien comprendre les demandes des utilisateurs finals Tenir compte des changements du cahier des charges Empcher la dcouverte tardive de dfauts srieux dans le projet Traiter au plus tt tous les points critiques du projet Bien communiquer avec le client Bien matriser la complexit Favoriser la rutilisation Dfinir une architecture robuste Faciliter le travail en quipe
V1.0 82

l l l

Conclusion

Bibliographie
l

Livres
l

Extreme Programming Explained Embrace Change Kent Beck Addison Wesley, 2000 Software Project Management - A Unified Framework, Walker Royce, Addison-Wesley, 1998 Rational Unified Process - An Introduction, Philippe Kruchten, Addison-Wesley, 1999 Object Solutions - Managing the Object-Oriented Project, Grady Booch, Addison-Wesley, 1996

V1.0

83