Le Processus Unifié De Rational - Laurent Henocque

laurent.henocque.com

Le Processus Unifié De Rational - Laurent Henocque

Le Processus Unifié de Rational

Laurent Henocque

http://laurent.henocque.free.fr/

Enseignant Chercheur ESIL/INFO France

http://laurent.henocque.perso.esil.univmed.fr/

mis à jour en Novembre 2006


Licence Creative Commons

Cette création est mise à disposition selon le Contrat

Paternité-Partage des Conditions Initiales à

l'Identique 2.0 France disponible en ligne

http://creativecommons.org/licenses/by-sa/2.0/fr/

ou par courrier postal à Creative Commons, 559

Nathan Abbott Way, Stanford, California 94305,

USA.


Références

Le site Wikipedia:

http://en.wikipedia.org/wiki/Rational_Unified_Proc

et les références associées


Objectif de ce document : présenter le

Processus Unifié de Rational

• Définir ce qu’est un processus de développement logiciel

• Décrire le processus unifié de Rational

• Expliquer les 4 phases du processus unifié de Rational et leurs

jalons associés

• Définir les itérations et leurs relations

• Expliquer les relations entre :

Les modèles et les enchaînements d’activités

Les phases, itérations, et enchaînements d’activités

• Définir artéfacts, rôles, activités

• Evaluer l’importance des outils logiciels


A quoi sert un processus logiciel ?

• Un processus logiciel fournit une approche pour assigner des

tâches et des responsabilités à l’intérieur d’une organisation.

• Un processus permet la production d’un logiciel de haute

qualité avec un temps et un budget limité.


Dans la construction d’un système, un langage ne suffit pas.

Équipe de

développement

Langage de

Modélisation

Processus unifié

UML n’est pas un standard pour les processus de développement logiciel.


Qu’est ce que UML ?

Le Langage unifié de Modélisation (UML) est un

langage pour

• Spécifier

• Visualiser

• Construire

• Documenter

Le choix d’un modèle a une profonde influence sur la

façon dont un problème est traité et dont la solution est

conçue.


Histoire d’ UML

1994 : OMT, Booch

1995 : Unified Method 0.8 (Dr. Ivar Jacobson)

1996 : UML 0.9 (Use-Case)

1997 : UML 1.0 (Microsoft, Oracle, IBM, HP)

1997 : UML 1.1

2004 : UML 2.0


Histoire d’UML

UML est aujourd’hui le langage standard industriel de

modélisation. Son développement à été lancé par trois leaders

dans l’industrie de l’approche objet :

•Grady Booch

•Ivar Jacobson

•Jim Rumbaugh.

UML est en développement depuis 1990.


Les contributions à UML

Meyer

Conception par

contrat - invariants

Harel

Diagrammes à état

Rumbaugh

Booch

Jacobson

Fusion

La description des opérations,

Le nombre de messages

Embley

Les classes singletons,

Gamma, et.al

Frameworks, patterns,

notes

Shlaer - Mellor

Les cycles de vie

Odell

Les classification

Wirfs-Brock

Les responsabilités


Les contributions à UML

Le développement d’UML à été fait par un large échantillon de

l’industrie :

HP, ICON Computing, IBM, I-Logix, Intellicorp, MCI Systemhouse,

Microsoft, ObjectTime, Oracle, Platnium, Technology, Ptech, Reich

Technologies, Softeam, Sterling Software, Taskon, et Unisys.


UML fournit des diagrammes standardisés

Use-Case

Diagrams

Use-Case

Diagrammes

Diagrams

D’activité

Use-Case

Diagrams Diagrammes

Use-Case

Diagrams de cas

d’utilisation

State

Diagrams

State

Diagrammes

Diagrams

De Classe

State

Diagrams

State

Diagrammes

Diagrams

D’objet

Scenario

Diagrams

Scenario

Diagrammes

Diagrams

De séquences

Modèles

State

Diagrams

State

Diagrammes

Diagrams

D’états

Scenario

Diagrams

Scenario

Diagrammes

Diagrams

De collaboration

Diagrammes

De déploiement

Component

Diagrams Component

Diagrams

Diagrammes

De composants


Représentation sous différents angles de vue d’un système

Les diagrammes de cas d’utilisation pour illustrer les interactions des

utilisateurs avec le système

Les diagrammes de classes pour illustrer la structure logique

Les diagrammes d’objets pour illustrer les objets et les liens

Les diagrammes d’états pour illustrer leur déroulement

Les diagrammes de composant pour illustrer les structures physiques du

logiciel

Les diagrammes de déploiement pour montrer la répartition du logiciel pour

les configurations hardware

Les diagrammes d’interactions (i.e., les diagrammes de collaboration et de

séquence) pour illustrer leur comportement

Les diagrammes d’activité pour illustrer le déroulement des activités dans un

cas d'utilisation.


Un diagramme représentatif d’UML : Cas d’utilisation

Un système d’enregistrement aux cours dans une université

l’étudiant

Enregistrement aux cours

Le professeur

Choix de cours à enseigner

Catalogue de cours

Mise à jour des informations des professeurs

Dir. Etudes

Mise à jour des informations des étudiants

Arrêt des enregistrements

Système de paie


Diagrammes de cas d’utilisation

Les diagrammes d’utilisation sont utilisés pour montrer

l’existence de cas d’utilisation.

• Un acteur est une entité extérieure au système qui à une

interface avec le système, tel qu'un utilisateur.

•Un cas d’utilisation modélise un dialogue entre les acteurs et le

système. Il est initialisé par un acteur.


Un diagramme de classes

Un système d’enregistrement aux cours dans une université


Ecran

// gérerUnEmploiDuTemps()

1

0..1


Ecran Gestion Edt

+ // ouvrir()

+ // choisir 4 cours obligatoires et 2 facultatifs

1


CatalogueCours

liste des cours()

1 0..*

1


ControlleurEnregistrement

ajout de cours()

lire la liste des cours()

0..1

1


Planning

créer un cours()


Æ ¯Á¤ ¹®¼-¿ ¡ ´ë Ç Ñ º¸± ⸦

» ç¿ ëÀ Ú°¡ ¿ äû Ç Ñ´Ù .

È- ÀÏ °ü ¸®À Ú ´Â À Ð ¾î¿ Â

¹®¼-À Ç Á¤ º¸¸¦ Ç Ø´ç ¹®¼-

°´Ã¼¿¡ ¼³Á ¤ À» ¿ äà »Ç Ñ ´Ù .

È-¸é °´ ü´  À Ð ¾îµ éÀÎ

°´Ã ¼µ é ¿¡ ´ë Ç Ø À ̸§ º° · Î

Á¤ ·Ä À» ½ÃÄ Ñ È-¸ é ¿ ¡

º¸¿© Á Ø´Ù .

1: Doc view request ( )

1 : D oc vi ew re q uest ( )

9 : so rt ByN am e ( )

2: f etch D oc( )

L

3 : cre ate ( )

6 : fill Do cu m en t ( )

9: sortByName ( )

7: readFile ( )

5: readDoc ( )

2: fetchDoc( )

4 : cr eat e ( )

8: fillF ile ( )

5: re a dD oc ( )

7 : re ad File ( )

4: create ( )

8: fillFile ( )

3: create ( )

6: fillDocument ( )

R ep o si t or y

n a m e : c h a r * = 0

re ad D o c( )

re ad F ile ( )

F i leM g r

fe tch D o c( )

so rtB y N a m e( )

re p

(f ro m Pe rsi st e n ce )

UI

DocumentApp

Persistence

a d d( )

d e le te ( )

re a d( )

F ile L ist

F il e

ad d ( )

de le te ( )

D o c ume n tL ist

fL ist

1

G rp F ile

r e ad ( )

o p e n( )

c re a te ( )

fi llF ile ( )

D ocu me n t

n a me : in t

d o ci d : in t

n u mF ie ld : i nt

g e t( )

o p en ( )

cl os e( )

re a d ( )

so r tF i le Li s t( )

cr e a te( )

fil lD o c u me n t( )

global

MFC

RogueWave

re ad () fi ll th e

co d e ..

O p en n in g

R e a d in g

a dd file [ n u mb e rO ffile == MAX ] /

fla g O F F

cl ose file

C lo si n g

cl os e file

a dd file

W ri tin g

ºÐ»ê ȯ°æÀÇÇϵå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇÁ¤º¸ ½Ã½ºÅÛ¿¬°á ¸ðµ¨

- À©µµ¿ì 95 : ŬóÀ̾ðÆ®

- À©µµ¿ì NT:ÀÀ¿ë¼-¹ö

- À¯´Ð½º ¸Ó½Å:ÀÀ¿ë ¼-¹ö¹× µ¥ÀÌŸ ¼-¹ö, Åë½Å ¼-¹ö

- IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌŸ¼-¹ö, Åë½Å ¼-¹ö

Window95

¹®¼-°ü¸®

ŬóÀ̾ðÆ®.EXE

Windows

NT

Windows

NT

¹®¼-°ü¸® ¿£Áø.EXE

Windows95

IBM

Mainframe

µ¥ÀÌŸº£À̽º¼-¹ö

Solaris

ÀÀ¿ë¼-¹ö.EXE

Windows95

¹®¼-°ü¸®¾ÖÇø´

Alpha

UNIX

Les diagrammes sont les artefacts clés

Acteur A

Diagramme de

cas

d’utilisation

Use-Case 1

Acteur B

Diagramme de

classe

Diagramme d’état

transition

Expert du

Domaine

Use-Case 2

Use-Case 3


Customer

name

addr

receive()

withdraw()

fetch()

send()

Classe

Diagramme de

déploiement

Repository

DocumentList

Définition

d’une interface

utilisateur

mainWnd : MainWnd

user : »ç¿ëÀÚ

fileMgr : FileMgr

repository : Repository

m a in W n d file M g r : d o cu m e n t : g Fi le re p o si to ry

u se r

F ile Mg r D o cu me n t

gFile : GrpFile

document : Document

Diagramme de

Collaboration

FileManager

Diagramme de

GraphicFile

paquetage

File

Document

Diagramme de

composant

FileList

Forward Engineering(Code Generation)

and

Reverse Engineering

Codage, compilation,

debugage, édition de lien

Diagramme de séquence

Programme

exécutable


Les diagrammes sont les artefacts clés

•UML fournit un langage unique et commun de modélisation

utilisable à travers plusieurs méthodes,

•Il définit le lien entre les coûts, les exigences et l’analyse, le

design, l’implémentation, et les tests.

•UML facilite la communication entre tous les membres de

l’équipe de développement.


Qu’est ce qu’un processus ?

Un processus définit qui fait quoi, quand et comment

pour atteindre un objectif donné.

Le Processus Unifié de Rational est un processus

générique qui utilise UML comme langage de

modélisation.

Exigences nouvelles

ou améliorées

Processus d’ingénierie

logicielle

Système nouveau

ou amélioré


Un Processus Efficace…

L’objectif d’un processus est de produire un logiciel de haute qualité en

respectant des contraintes de délai, de coûts et de performance

• Fournit les lignes directrices pour un développement

efficace d’un logiciel de qualité

• Réduit les risques et améliore les prévisions

• Décrit les meilleures méthodes de travail pour

– apprendre des expériences précédentes

– l’amélioration du support de formation

• Établit une vision et une culture commune


Un Processus Efficace…

•Facilité de mise en œuvre : grâce aux six meilleures

pratiques de Rational, le processus est facile à mettre en

oeuvre.

•Il dicte au développeur comment implémenter en utilisant

les outils standards de développement.


Le Processus Unifié de Rational permet les

Meilleures Pratiques (Best Practices)

Le processus Unifié Rational décrit comment appliquer les

six directives de l’ingénierie logicielle

Utiliser le Développement Itératif

Analyser

les Besoins

(Ré)Utiliser

Composants

Architectures

Modeler

Visuellement

(UML)

Contrôler

la Qualité

Contrôler le

Changement


Le Processus Unifié de Rational permet les

Meilleures Pratiques (Best Practices)

Les six meilleures pratiques fournissent les bases pour le

Processus Unifié de Rational.

•Cependant, cette application nécessite des instructions

étapes par étapes.

•Ces instructions sont fournies dans le Processus Unifié de

Rational, qui comprend toutes les activités devant être

appliquées pour construire un logiciel


Processus Unifié Rational

Un processus centré sur

l'architecture et la vue 4+1


Processus Unifié de Rational dans un “cas d’utilisation”

Client

Contrôle de la balance

Encaissement

Cas d’utilisation pour une caisse

Un acteur est une entité

hors du système qui

interagit avec le

système

Un Cas d’utilisation est

une séquence

d’actions que le

système exécute qui

retourne un résultat à

un certain acteur


Processus Unifié de Rational dans un “cas d’utilisation”

Le processus Unifié de Rational gère les besoins via les diagrammes de

Cas d’utilisation.

•Ils sont utilisés à travers le cycle de développement pour beaucoup

d’activités, et fournissent de l’information à travers plusieurs modèles.

•Un acteur peut-être un être humain ou un autre système ou un

appareil; tout ce qui est extérieur au système et interagissant avec lui.

Les cas d’utilisation représentent toutes les façons possibles d’utiliser le

système.


Les “Cas d’utilisation” incluent les Flots d’évènements

Exemple : flot d’évènements dans le cas d’un retrait d’argent

1. Le “cas d’utilisation” commence quand le client insère sa carte

de payement. Le système lit et valide les informations sur la

carte.

2. Le système lit le code PIN. Le système valide le code PIN.

3. Le système demande au client quelle opération il veut exécuter.

Le client choisi “Retrait d’argent”

4. Le système demande le montant. Le client entre le montant.

5. Le système demande le type de compte. Le client choisi

“vérifier et enregistrer”.

6. Le système communique avec le réseau ATM . . .


Les apports des “Cas d’utilisation”

Les “Cas d’utilisation” sont concis, simples, et compréhensibles par une large

gamme de participants

– Utilisateurs finaux, développeurs et acquéreur comprennent les exigences

fonctionnelles du système

Les “Cas d’utilisation” permettent bon nombre d’activités dans le processus :

– La création et la validation de la conception du modèle

– La définition de cas de test et de procédures du modèle de test

Le planning des itérations

– La création de documentation utilisateur

Le déploiement du système

Les “Cas d’utilisation” permettent de synchroniser le contenu de plusieurs

modèles


Le processus Unifié de Rational est Architecture-Centré

• L'architecture est le point traité pendant les premières

itérations

– Construire, valider, et fonder l’architecture constituent le

premier objectif de l’élaboration

Le Prototype Architectural valide l’architecture et sert de

base pour le reste du développement

Le document de l’architecture logicielle est le premier

artefact qui décrit l’architecture choisie

• D’autres artéfacts dérivent de l’architecture :

– Documents de conception qui comprennent l’utilisation

de patterns et d’idiomes

– La structure du produit

– La structure de l'équipe


Le processus Unifié de Rational est Architecture-Centré

• L’architecture est utilisée dans le Processus Unifié de Rational comme un

artefact primaire pour conceptualiser, construire, gérer, et élaborer le

système en développement.

Le Processus Unifié de Rational considère le développement et la

validation d’une architecture logicielle comme le concept primordial.

• Il définit 2 artefacts primaires :

– la description de l’architecture logicielle qui décrit l’architecture du

projet

– le prototype de l’architecture.


Représentation de l’architecture : Le Modèle 4+1

Vue

logique

Vue

d’implémentation

Analystes/

Concepteurs

Structure

Fonctionnalités

pour l’utilisateur

final

Cas

d’utilisation

Programmeurs

Génie logiciel

Vue du

processus

Intégrateurs systèmes

Performance

Échelles de mesure

Capacité de traitement

Vue de

déploiement

System Engineering

Topologie du système

Livraison, installation

communication


Représentation de l’architecture : Le Modèle 4+1

Une vue de l’architecture est la description d’un système

d’un point de vue particulier, couvrant certains points et en

omettant certains autres.

Le Processus Unifié de Rational identifie 4 vues + 1 :

•La vue logique concerne les exigences fonctionnelles

du système. Elle identifie la plupart des paquetages,

sous-systèmes et classes.

•La vue d’implémentation décrit l’organisation des

modules du logiciel.


Représentation de l’architecture : Le Modèle 4+1

•La vue du processus concerne les aspects concurrents du

système à l’exécution: taches, threads ou processus, et leur

interaction.

•La vue de déploiement montre comment les différents

exécutables sont structurés dans la plate-forme ou les

différents nœuds.

•La vue des cas d’utilisation contient les scénarios

principaux qui sont utilisés pour faire fonctionner

l’architecture et pour la valider.


Les bénéfices d’un processus Architecture-Centré

• Gagner et conserver un contrôle intellectuel sur le projet, contrôler sa

complexité, et maintenir l’intégrité du système.

• Fournir une méthode pour une réutilisation à grande échelle

• Fournir des bases pour la gestion de projet

• Faciliter le développement par composant

– Un composant remplit une fonction définie dans le contexte d’une

architecture bien définie

– Un composant fournit la réalisation physique d’une série

d’interfaces

Les composants existent dans une architecture donnée


Processus Unifié Rational

Le processus dans le temps


Architecture du ProcessusLes Cycles de vie

Démarrage

Élaboration

Construction

Transition

temps

Le Processus Unifié de Rational comprend 4 phases :

– Démarrage - Définit le champ d’action du projet

– Élaboration – Le plan du projet, il spécifie les exigences, les

bases de l’architecture

– Construction – Réalise le produit

– Transition - Transfère le produit vers les utilisateurs finaux


Architecture du ProcessusLes Cycles de vie

• Durant l’étude d’opportunité (démarrage), nous définissons l’objectif

du projet.

– en identifiant tous les acteurs et les cas d’utilisation, et en dessinant les

cas d’utilisation essentiels (20% du modèle).

– Un plan de gestion de projet est fait pour déterminer les ressources

nécessaires pour le projet.

• Durant l’élaboration, on se concentre sur deux choses :

– avoir une bonne connaissance des besoins (90%) et

– établir une base de l’architecture.

• Ainsi, on peut éliminer beaucoup de risques, avoir une bonne idée de

ce qui doit être fait, et une bonne estimation des ressources et des

coûts.


Architecture du ProcessusLes Cycles de vie

• Durant la Construction, on développe le produit en plusieurs

itérations pour une version bêta.

• Durant la Transition, on prépare le produit pour l’utilisateur

final et la formation, l’installation, le support.

• Pour un projet très complexe l’élaboration peut inclure

jusqu’à 3-5 itérations.


Le Processus Unifié De Rational : Vision temporelle

Démarrage

Élaboration

Construction

Transition

temps

Évaluation des

objectifs

Évaluation

de l’architecture

Évaluation

du produit

Validation

du produit


RUP et Vision Temporelle: phase de démarrage

• Première analyse des fonctionnalités

(diagramme d’utilisation)

• Évaluer les risques (coût, concurrence)

• Critères d’évaluation :

• Concurrence

• Première validation des besoins

• Évaluation des coûts, priorités, risques, du processus de

développement, des frais réels par rapport aux frais prédits.


RUP et Vision Temporelle: phase d’élaboration

• Planifier les activités nécessaires et les ressources

requises.

• Définir précisément les fonctionnalités de

l’application.

• Concevoir l’architecture.

• Critères d’évaluation :

• Stabilité du produit et de la conception.

• Résolution des problèmes critiques.

• Évaluation des coûts, du planning.

• Validation du produit.


RUP et Vision Temporelle: Phase de Construction

• Construire le produit comme une série

d’itérations incrémentales.

• Critères d’évaluation :

• Stabilité et maturité des réalisations (en vue du

déploiement)

• Capacité de mettre en œuvre la transition.

• Coûts acceptables.


RUP et Vision Temporelle: Phase de Transition

• Fournir le produit aux utilisateurs

1. Fabrication

2. Livraison

3. Formation

• Critères d’évaluation :

• Validation des besoins (Recette)


RUP et Vision Temporelle: Jalons d’Évaluation

• Après chacune des quatre phases on

évalue les activités grâce à des critères

spécifiques:

• Évaluation Coût/risque réaliste.

• Validation du produit.

• Architecture valide et réalisable.

• …


RUP Et Vision Temporelle:

Sous Jalons D’évaluation et Itérations

• Chaque phase peut elle-même comporter des

([0..N]) jalons. Entre deux jalons, on parle

d’itérations.

• Une itération est est une séquence d’activités

planifiées et pouvant être vérifiées grâce à un

critère d’évaluation.

• But : vérifier les activités au fur et à mesure.

Deux types :

– Internes : au sein de l’équipe de développement.

– Externes: avec le client et idéalement les utilisateurs

finaux


Processus Unifié Rational

Rôles et Activités


RUP et vision par activités

1. La modélisation métier : possibilités du système et

besoins des utilisateurs.

2. La modélisation des besoins : vision du système et

besoins détaillés des utilisateurs.

3. L’analyse et la conception : manière dont sera réalisé le

projet au cours de la phase 4.

4. L’implémentation : production et acquisition des

composants du système et des exécutables.

5. Les tests : vérification du système dans son ensemble.

6. Le déploiement : livraison du système et formation des

utilisateurs.


Les 2 Visions Rassemblées: Le Modèle Itératif

Flux (workflow) du processus

Flux de gestion

Modélisation métier

Modélisation des

besoins

Analyse et

conception

Implémentation

Tests

Déploiement

Gestion de

Configuration et des

Evolutions

Gestion de projet

Environnement

Démarrag

e

Élaboration Construction Transition

Iter.

#1

Iter.

#2

Iter.

#n

Iter.

#n+1

Iter.

#n+2

Iter.

#m

Iter.

#m+1


RUP : Définitions et Notations(1/2)

• Artéfact : Élément d’information, produit

ou utilisé lors d’une activité de

développement logiciel (modèle, source...)

• Activité : Opération exécutée au sein d’un

état. Une activité peut être interrompue.

• Rôle : Comportement et responsabilités

d’un ensemble de personnes.


RUP : Définitions Et Notations(2/2)

Rôle

Activité

Analyste

Cas d’utilisation

Responsable de

Décrire un cas

d’utilisation

Artéfact

Cas d’utilisation

paquetage des

cas d’utilisation


Les Rôles Dans La Planification Des Ressources

Ressource

Rôle

Activités

Paul

Marie

Joseph

Sylvia

Stefanie

Concepteur

Rédacteur. D.Utilisation

Analyste Système

Développeur.

Architecte

Définir Opérations

Détailler le D. Utilisation

Trouver Acteurs et Cas Util.

Réaliser les tests des unités.

Concevoir.

Chaque individu est

associé

à un ou plusieurs rôles.


Modélisation Métier

• Pour comprendre la dynamique et la

structure de l’organisation.

• Pour vérifier que les clients, les utilisateurs

finaux, et l’équipe ont une vision commune

exacte de l’organisation.

• Pour vérifier la concordance entre les

besoins et l’organisation.


La modélisation métier

Analyste de la

modélisation

métier

Lister le

vocabulaire

commun

Trouver les

acteurs et les

cas

d’utilisation

Finaliser les

cas d’utilisation

Vérificateur

Modèle

métier

Détailler

les cas

d’utilisation

Détailler les

acteurs métier

Revoir les

modèles métier

des cas

d’utilisation

Concepteur

métier

Trouver les

entités et

les acteurs

métier

Détailler les

entités métier

Revoir les

modèles métier

des objets


Modélisation Des Besoins

• Valider les fonctionnalités du système avec le

client et les utilisateurs.

• Donner à l’équipe de développement une idée des

besoins auxquels le système doit répondre.

• Définir les limites du système.

• Définir une base pour planifier les activités

associées à chaque itération.

• Définir une IHM du système.


Modélisation Des Besoins

Analyste

système

Développer Vision

Coordonner les

dépendances

Définir les besoins

pour les jalons

Lister le vocabulaire

commun

Trouver les

acteurs et cas

d’utilisation

Structurer le

modèle cas

d’utilisation

Responsable

Validation

besoins

Analyste Cas d’utilisation

Détailler les cas

d’utilisation

Vérifier les

besoins

Concepteur IHM

Définir IHM

Prototyper IHM

Architecte

Hiérarchiser les cas d’utilisation


Modélisation Des Besoins : Artefacts

• Un document de vision.

• Un document listant les besoins de chaque jalon.

• Un document sur les cas d’utilisation

• Un document de spécification supplémentaire : ce

que va faire précisément le système.

• Glossaire

• Story-board des cas d’utilisation.

• Une charte graphique…


Analyse et Conception

• Passer des besoins à une architecture

concrète.

• Concevoir une architecture robuste pour le

système

• Permettre que le système soit adapté à son

environnement.


Analyse et Conception

Architecte

Analyser

l’architecture

Concevoir

l’architecture

Définir la

concurrence

Définir le

déploiement

Planifier la

vérification

architecture

Responsable

vérification

architecture

Concepteur

Analyser les cas

d’utilisation

Concevoir les

sous systèmes

Concevoir les

classes

Concevoir les

cas d’utilisation

Planifier la

vérification

conception

Responsable

vérification

conception

Concepteur Base

de données

Concevoir la

base de données


Analyse et Conception : artéfacts

Le modèle de conception

Les descriptions de cas d’utilisation

Les descriptions de classes

• L’organisation en sous système

Les documents sur l’architecture logicielle

Le modèle de données


Implémentation

• Définir l’organisation des modules et des

sous systèmes implémentés.

• Implémenter les composants (classes et

objets).

• Tester les composants un par un.

• Utiliser les composants produits par

différentes personnes pour construire le

système.


Implémentation

Structurer le

Modèle d’implémentation

Architecte

Responsable

intégration

système

Planifier l’intégration

du système

Intégrer

Système

Développeur

Planifier

L’intégration des

Sous-systèmes

Implémenter

les Classes

Tester

les unités

Intégrer les

sous systèmes

Fixer les solutions

Responsable vérification

Code

Vérifier le Code


Implémentation : Artéfacts

Le modèle d’implémentation qui définit les

composants.

Les composants.

Le plan d’intégration des composants.


Tests

• Vérifier les interactions entre les

composants.

• Vérifier l’intégration des composants

logiciels.

• Vérifier que tous les besoins ont été

correctement implémentés.

• Identifier les défauts et les signaler au

déploiement.


Tests

Concepteur

des tests

Planifier

Tests

Concevoir

Tests

Tester

implémentation

Evaluer

Test

Testeur de

l’intégration

Tests d'Intégration

Testeur système

Tests Système

Testeur

performances

Tests de Performance

Concepteur

Concevoir les classes de Test

et Packages

développeur

Implémenter le sous système de tests


Tests : Artéfacts

• Modèle de test : définition et procédures.

• Planification des tests.

• Revue de défauts.

• Tests des paquetages, classes, sous

systèmes, et composants.


Gestion de projet

• Définir un environnement de travail pour la

gestion de projet.

• Fournir des documents à propos de la

planification, de la répartition des tâches, de

l’exécution et de la vérification des projets.

• Définir un environnement de travail pour la

gestion des risques.


Gestion de projet

Mener une

étude de cas

métier

Identifier

Les Risques

Développer

plan de

gestion de

projet

Planifier

l’itération

Exécuter

l’itération

Vérifier

l’itération

Chef de projet

Réunir

Équipe

Réviser la liste des risques


Gestion De Projet : artéfacts

• La procédure de développement logiciel

(Liste des risques, plan de projet et

procédure d’actions)

Les cas d’utilisation métier

• La planification des itérations

• L’estimation des itérations

• L’estimation des statuts


Déploiement

• Permet de faire évoluer correctement

(Erreurs, spécifications…) les systèmes

logiciels au cours de leurs différentes

versions.

• Lister les différentes versions des

composants utilisés au cours des différentes

versions du logiciel.


Déploiement

Chef de projet

Définir les processus

de changement de

produit

Définir les besoins des

report et préservation des

statuts

Architecte

Structurer le modèle de

déploiement

Responsable

gestion du

changement

Rédiger le plan

de gestion de

changement

Définir le modèle

de déploiement

Délimiter les

espaces de

travail

Documenter le

défaut

Fonder le produit

Livrer les soussystèmes

Tout membre

de l’équipe

Créer un espace de travail

personnel

Vérifier les

artéfacts d’E/S

S’attacher aux points

sensibles de la

configuration

Intégrateur

Créer un espace de travail

pour l’intégration

Construire le produit


Déploiement : avantages

• Encourager les bonnes méthodes de

développement.

• Maintenir l’intégrité du produit.

• S’assurer de la complétude et de la correction du

produit déployé.

• Fournir un environnement de développement

stable.

• Limiter les changements des artéfacts dus aux

règles internes (policy) du projet.

• Permettre de suivre les changements des artéfacts.


Processus Unifié Rational

Points de vue extérieurs


Point de vue sur le Workflow

• Déployer les processus.

• Améliorer les processus.

• Sélectionner les bons outils et les maîtriser.

• Développer des outils.

• Aider le développement.

• S’entraîner.


Règles, Tutoriaux et Modèles

Les règles sont les obligations, recommandations, les heuristiques qui

aident l’exécution des activités.

ex: règles de codage

Les tutoriels aident à l’apprentissage des outils utilisés lors des

activités.

ex : Tutoriels de Rationnal Rose ou Poseidon

Les modèles (formulaires) sont des artéfacts prédéfinis.

Ex : Un document ayant déjà une structure à remplir.

Leur but est de rendre l’exécution des activités plus facile et que les

processus soient correctement menés à bien.


Liste d'Outils D’aide Au Développement.

Activités de base

Modèle métier

Besoins

Analyse et conception

Implémentation

Test

Déploiement

Activités de support

Config. & Changement

Gestion de projet

Environnement

Requisite Pro, Rose, SoDA

Requisite Pro, Rose, SoDA

Rose, SoDA, Apex

Rose, Apex, SoDA, Purify, ...

SQA TeamTest, Quantify, PerformanceStudio,...

SoDA, ClearCase, ...

ClearCase, ClearQuest

Unified Process, Microsoft® Project, ...

Unified Process, Rational Tools


Suivre Un Processus

• Il faut adapter et exécuter le processus.

• Adapter suivant les besoins et les contraintes de

l’organisation. Cela fournit un document avec le

contexte, les limites, une évaluation de la

proportion des changements par rapport au

processus initial…

• Exécuter en faisant les changements nécessaires

dans le processus.


RUP : Résumé(1/3)

• UML est un langage de spécification,

visualisation, construction, et

documentation des artéfacts d’un système à

composante logicielle.

• Un processus de développement logiciel

répond aux questions qui, quoi quand et

comment.


RUP : Résumé(2/3)

Le RUP a quatre phases : démarrage, élaboration,

construction et transition.

• Chaque fin de phase est ponctuée par un jalon

principal et la fin d’une ou plusieurs itérations.

• Une itération est une suite de diverses activités

qui ont été planifiées, ayant des critères

d’évaluation, et pouvant être exécutées.


RUP : Résumé(3/3)

• Chaque enchaînement d’activité dure une itération

et s’inscrit dans un modèle incrémental.

• Artéfact : Élément d’information, produit ou

utilisé lors d’une activité de développement

logiciel(modèle)

• Activité : Opération exécutée au sein d’un état.

Une activité peut être interrompue.

• Rôle : Comportement et responsabilités d’un

ensemble de personnes

More magazines by this user
Similar magazines