Processus_Unifie_et_Approche_Agile chapitre 1.pptx

Processus Unifié et Approche
Agile
Introduction
Processus Unifié
Approche Agile

1. Génie Logiciel
2. Un logiciel de qualité
3. Projet logiciel
4. Cycle de vie d’un logiciel
5. Méthode et Processus
6. UML (rappel)
7. Conclusion
3

Génie Logiciel
4
 Ensemble de méthodes, techniques et outils pour
la conception, la production et la maintenance de
systèmes informatiques complexes.
 Ces méthodes connaissent, au même titre que les
technologies mises en œuvre une évolution
permanente.
 Elles sont incluses dans un domaine des sciences
de l’ingénieur (formalisation, séparation de
problèmes, modularité, abstraction, prévision des
changements, etc.)

Un logiciel de qualité
5
 La crise du logiciel des années 70 est provoquée
par :
 l'impossibilité de maîtriser la sureté des logiciels
(pannes nombreuses)
 l'inflation des délais de développement
 De bonnes techniques de développement logiciel
deviennent nécessaires.
 facteurs externes
 facteurs internes

6
 Utilité :
 Utilisabilité :
 Robustesse (fiabilité) :
 Extensibilité :
 Compatibilité :
 Efficacité :
 Intégrité (sécurité) :

7
 Utilité : le logiciel doit correspondre aux besoins des
utilisateurs,
 Utilisabilité : facilité d'apprentissage et d'utilisation,
 Robustesse (fiabilité) : aptitude à fonctionner dans
des conditions non prévues au cahier des charges,
dysfonctionnement du logiciel,
 Extensibilité : facilité avec laquelle de nouvelles
fonctionnalités peuvent être ajoutées .

8
 Compatibilité : facilité avec laquelle un logiciel peut
être combiné avec d’autres,
 Efficacité : utilisation optimale des ressources
matérielles (processeur, mémoires, équipements
réseau,…),
 Intégrité (sécurité) : aptitude d’un logiciel à se
protéger contre des accès non autorisés.

9
 Re-utilisabilité :
 Vérifiabilité :
 Portabilité :
 Lisibilité et Modularité

10
 Re-utilisabilité : aptitude d’un
réutilisé, en tout ou en partie,
logiciel à être
pour d’autres
aptitude d’un logiciel à être testé
applications,
 Vérifiabilité :
(optimisation de la préparation et de la
vérification des jeux de tests),
 Portabilité : aptitude d’un logiciel à être transféré
dans des environnements logiciels et matériels
différents,
 Lisibilité et Modularité

Projet logiciel
11
 Un projet est un ensemble d’actions effectuées par
des personnes morales ou physique pour atteindre
un objectif, limité par une date, possédant un coût.
 Conduite et direction du projet :
 Organisation méthodologique,
 Gestion des personnes impliquées,
 Gestion technique,
 Gestion de moyens, etc.

Projet logiciel
12
 Capture des besoins:
 Conception:
 Réalisation :
 Validation :
 Maintenance :

Projet logiciel
13
 Capture des besoins: réalisation du cahier des
charges, spécifications fonctionnelles et non
fonctionnelles des besoins,
 Conception: architecture du logiciel, modèles de
conception,
 Réalisation : implémentation du code
 Validation : intégration et déploiement et j’aurais
un logiciel livrable,
 Maintenance.

Projet logiciel
Comment piloter un projet de développement
comportant ces étapes ?
14

Cycle de vie d’un logiciel
15
 Toutes les phases de développement du logiciel,
de l'établissement des besoins du client jusqu'à
l'achèvement du logiciel en tant que produit
commercial.
 Ces phases sont organisées selon des modèles qui
permettent de guider l’ingénieur dans ses
activités.
 Modèles linéaires (en cascade, …)
 Modèles non linéaires (spirale, itératif,…)

Cycle de vie d’un logiciel (modèle en
cascade)
Analyse et spécification des
besoins
Conception
Implémentation
Test
Livraison et
maintenance
 Linéaire, flot descendant.
 Retour limité à une phase en
amont.
 Validation des phases par des
revues.
16

cascade)
Analyse et spécification des
besoins
Conception
Implémentation
Test
Livraison et
maintenance
 Délais longs pour voir
quelque chose qui tourne.
 Test de l’application globale
uniquement à la fin.
 Difficulté de définir tous les
besoins au début du projet.
17

Cycle de vie d’un logiciel (modèle en V)
18

19
(Problèmes et solutions - modèles linéaires)
 Une anomalie détectée dans une phase aval de la
cascade peut remettre en cause des travaux
validés.
 La levée tardive des facteurs à risques.
 Non prise en compte de l’évolution des besoins
pendant le cycle.
 Modèle théoriquement parfait, mais inadapté aux
humains.

(Problèmes et solutions - modèles linéaires)
 Utilisés seulement quand les exigences sont bien
connues et non sujettes à modification.
 Encore assez populaires et souvent utilisés par les
non spécialistes.
20

spirale)
21

Méthode et Processus
22
 Une méthode est une démarche reproductible
permettant d’obtenir des solutions fiables à un
problème donné.
 En GL, on trouve des méthodes:
 de développement
 de conduite de projet
 d’assurance et de contrôle qualité
 etc.

23
 Un processus définit qui fait quoi à quel moment
et de quelle façon pour atteindre un certain
objectif.
 Un processus fournit les directives nécessaires
pour le développement d’un logiciel de qualité.
 Un processus implique la présence des clients,
utilisateurs, développeurs et responsables.
 Un processus suit l’évolution (des technologies,
des outils, des ressources, etc)

24
 Deux approches méthodologiques du développement
de logiciels sont en concurrence :
 L’approche fonctionnelle ou classique (1970)
 Analyse fonctionnelle hiérarchique,
 Liée à la programmation structurée.
 L’approche orientée objets (1990)
 Approche avec grande cohérence (données/traitements),
 Lier le monde des objets au monde de l’application ,
 Encapsulation, abstraction, réutilisation, modularité, extensibilité,
etc.

UML (rappel)
 UML (Unified Modeling Language ou langage
unifié de modélisation) est un langage graphique
destiné à la modélisation de systèmes et de
processus[1].
 Méthode: comment utiliser le langage de
modélisation (recueil des besoins, analyse,
conception, mise en œuvre, validation, ...)
[1] Fien VAN DER HEYDE Laurent DEBRAUWER
26

UML (rappel)
UML
Structuration
Comportement
Relation
Diagramme
Cas d’utilisation, classe, composant, …
Groupement Package, modèle , sous-système…
27
interaction, machine d ’états…
Association, dépendance, génération…
De Cas d’utilisation, de séquence, de classes,
d’activité, de déploiement, …

UML (rappel)
 Les cas d’utilisation servent de fil conducteur
pour l’ensemble du projet.
29

UML (rappel)
40
 UML n'est qu'un langage de modélisation et
non une méthodologie à part entière.
 UML définit des notations utiles dans toutes
les étapes du développement d'un logiciel, de
l'analyse des besoins à la livraison de celui-ci,
mais il ne propose aucune démarche spécifique
pour mener ce développement à terme.

Conclusion
Extreme Programming
41
ASD
Scrum
Crystal
DSDM
RUP
UP
2TUP
EUP
XUP
AUP
EssUP

Travail à faire
42
 Choisir un projet dont sa réalisation demande
l’intervention d’au moins deux acteurs.
 Déterminer le cahier des charges
 Donner une première vision de:
 Diagrammes statiques
 Maquettes IHM
 Rapport + présentation

Plan
44
1. Introduction
2. Les phases du Processus Unifié
3. Caractéristiques du Processus Unifié
4. Les 4 « P » du développement logiciel
5. Les enchaînements d’activités principaux

Introduction
45
 La création des logiciels de
imposants et complexes.
 On cherche des logiciels:
 plus adoptés à nos besoins,
 répondent aux exigences du marché,
 dans des délais fixes,
 avec des coûts réduits,
 mieux documentés,
 …
plus en plus

Introduction
46
 « Le processus unifié (Unified Process) est un
processus de développement logiciel, c’est-à-dire
qu’il regroupe les activités à mener pour transformer
les besoins d’un utilisateur en système
logiciel » (Jacobson, Booch, Rumbaugh 1999).
 Le résultat de la fusion des méthodes Objectory d'Ivar
Jacobson, Booch de Grady Booch et OMT de James
Rumbaugh, enrichi de nombreux apports issus des
travaux d'élaboration du standard UML et du produit
commercial RUP (Rational Unified Process).

Introduction
47
 Le PU utilise le langage UML pour la création des
plans d’élaboration du logiciel.
 Le PU ne fait pas partie intégrante du standard
UML.
 Utilisé pour le développement orienté objet de
logiciel.
 Le PU est :
 piloté par les cas d’utilisation,
 centré sur l'architecture,
 itératif et incrémental.

Les phases du PU
48
 Le PU répète une série de cycles constituant la vie
du système.
 Un cycle conduit à la livraison d’une version du
produit.
 Un cycle s’articule autour de 4 phases:
 Étude préliminaire
 Élaboration
 Construction
 Transition

Les phases du PU
Chaque cycle de développement du PU est géré comme un projet
ayant 4 phases.
Chaque phase s’achève par un jalon définit par un ensemble
d’artefacts.
Etude
préliminaire
Elaboration Construction Transition
Cycle 1 Cycle 2 Cycle 3
49

Les phases du PU - artefact
50
 Un élément d’information produit ou modifié
dans le cadre du processus de développement
(document, diagramme, compte rendu de réunion,
code source, modèle de base de données, etc.)
 Artefacts qui dépendent de l’activité de gestion de
projet.
 Artefacts qui sont directement issus du travail de
fabrication du logiciel.

Les phases du PU – phase 1
Etude
préliminaire
Vision
 Cette phase traduit l’idée en une vision du produit fini .
 Elle répond aux questions suivantes :
 Que va faire le système pour ses utilisateurs ?
 A quoi peut rassembler l’architecture du système ?
 Quels sont l’organisation et les coûts de ce produit?
51

Etude
préliminaire
Vision Architecture
 Concevoir une architecture de référence,
 Formuler les cas d’utilisation pour couvrir environ 80% des
besoins fonctionnels,
 Faire une planification complète (temps, personnel, budget).
 Le jalon est une architecture de base en justifiant les choix
architecturaux.
52

Etude
préliminaire
Vision Architecture
 Mettre en œuvre tous les cas d’utilisation en accord avec les
clients.
 La phase la plus coûteuse qui
conception , test et intégration, etc.
 Le jalon est une version du produit.
englobe le codage, la
Version bêta
53

Etude
préliminaire
Vision Architecture
 Cette phase couvre le test du produit en version bêta .
 Les anomalies et les défauts constatés par l’équipe de test sont
prises en considération.
 La formation des utilisateurs, la préparation des manuels
d’utilisation, la mise en place d’une équipe de maintenance.
 Le produit est déployé chez le client.
Version bêta Produit
livré
54

Les phases du PU
Besoins
Analyse
Conception
Implémentation
T
ests
Phases
Etude Pré Élaboration Construction Transition
Activités
55
principales

Caractéristiques de Processus Unifié
(itératif et incrémental)
56
 Découper le travail en plusieurs parties qui
présentent des mini-projets.
 Une itération contient toutes les activités, conduit au
développement d’un certain nombre de UC.
 Les itérations donnent lieu à un incrément.
 Un incrément correspond à une avancée dans les
différents stades de développement.

Besoins
Analyse
Conception
Implémentation
T
ests
Phases
Itérations
Création Élaboration Construction Transition
It. 1 It. n
It. 2 … … … … … It. n-1
Activités
57
principales

58
 Gestion de la complexité.
 Prise en compte des modifications de besoins.
 Apprentissage rapide de la méthode.
 Maîtrise précoce des risques.
 …

(piloté par les UC)
59
 Un outil de spécification des besoins du système.
 Un outil pour guider le processus de développement.
 Les cas d’utilisation sont:
 détaillés par l’analyse
 réalisés par la conception
 concrètement implémentés par les développeurs
 vérifiés par les scénarios de test

Cas d’utilisation
Modèle d’analyse
Modèle de conception
Modèle de déploiement
Modèle d’implémentation
Modèle de test
spécifié par réalisé par
distribué par
implémenté par
vérifié par
60

61
 Support de communication entre utilisateurs et
concepteurs.
 Assurent la traçabilité de toute décision de
conception.
 Fournissent une vision commune aux participants du
projet.
 …

(centré sur l’architecture)
62
 Une architecture décrit les différentes vues des
modèles du système à construire.
 Une architecture représente les aspects dynamique
et statique du système.
 Une architecture est un lien pour les membres du
projet:
 Une architecture émerge des besoins exprimés à travers
les cas d’utilisation.
 Elle complète les cas d’utilisation.

63
 Dans un premier temps, choisir une architecture
qui définit les parties générales de l’application.
 Ceci mène à la construction d’une ébauche.
 Dans un deuxième temps, stabiliser l’architecture
autour des fonctions essentielles.
 Ceci mène à la construction d’une architecture
référence.
 Dans un troisième temps, l’architecture continue à
se stabiliser dans les itérations suivantes.

64
 Comprendre le système,
 Organiser le développement,
 Favoriser la réutilisation,
 Faire évoluer le système.

Les 4 « P » du développement logiciel
Processus
Personnes Outils
Produit
Projet
Automatisation
Template
65
Participants
Résultat

Les 4 « P » du développement logiciel
66
 Personnes: les architectes, développeurs, testeurs,
la direction, les utilisateurs, les clients.
 Projet: élément d’organisation à travers lequel est
géré le développement du logiciel.
 Produit: ensemble des artefacts créés au cours du
cycle de vie du projet.
 Processus: offre un cadre générique à la création
de projet.

Les enchaînements d’activités principaux
Besoins
Analyse
Conception
Implémentation
T
ests
Phases
Itérations
It. préliminaire It. n
… … … … … It. n-1
Activités
67
principales

-Expression des besoins-
 Décrire les exigences que doit respecter le système
avec précision pour parvenir à un accord entre le
client et les développeurs.
68

 La modélisation du domaine
 La saisie des objets les plus importants dans le contexte du
système.
 Le diagramme du domaine est décrit avec le langage
UML à travers le diagramme de classe contenant les
classes essentielles.
 La modélisation du métier consiste à décrire les
processus métier existants ou perçus afin de les
comprendre.
69

70

 Modèle des cas
d’utilisation
 Représenter les cas
d’utilisation
 Classer les cas d’utilisation
par priorité
 Décrire en détail les cas
d’utilisation
71

72
 La gestion locale est un traitement classique alors le risque est
faible pour ce cas.
 Les réservations en ligne nécessitent une architecture plus
complexe alors le risque est plus élevé.
 Le ménage des chambres entraîne des ressources alors le risque
est moyen.
1. Réserver une chambre sur le site,
2. Gérer la chambre à nettoyer,
3. Réserver une chambre dans le local,
4. ….

73
 CU : Réserver une chambre
 Portée : système de réservation
 Acteur principal : Gérant
 Intervenants et intérêts : Client, Chaîne hôtelière
 Préconditions : une chambre est libre pour la période désirée
 Garanties minimales : rien ne se passe
 Garanties en cas de succès : la chambre est réservée
 Scénario nominal
1. Description du scénario……..

74
 Compléter la description en représentant les
diagrammes de séquence système, diagrammes
d’activité.
 Préparer des maquettes IHM (si nécessaire) pour
l’évaluer auprès du client.
 Recenser les besoins non fonctionnels dans une
liste.

75

76

77

Rôle des besoins dans le cycle de vie
du logiciel
78
 L’expression des besoins s’étale sur plusieurs incréments de
développement.
 Chaque itération apporte de nouveaux cas d’utilisation ou des
détailles des cas d’utilisation existants.
 La capture des besoin s’effectue principalement au cours des
phases d’étude préliminaire et d’élaboration.
 Identification de la plupart des cas d’utilisations durant la phase d’étude
préliminaire.
 La mise à jour des cas d’utilisation durant la phase de l’élaboration.
 Le reste de besoins est formulé et implémenté durant la phase de
construction.

Besoins
Analyse
Conception
Implémentation
T
ests
Phases
Itérations
It. n
… … … … … It. n-1
Activités
79
principales
It. préliminaire

 L'analyse se consacre à l'analyse des besoins décrits
dans l'expression de ces derniers, en les affinant et
en les structurant.
 Réalisation des cas d’utilisation par des objets/
classes d’analyse pour préparer la conception.
 Un point de départ pour l’analyse architecturale en
décomposant le système.
80
-Analyse-

-Analyse-
81

-Analyse-
82
Modèle des cas d’utilisation Modèle d’analyse
Langage du client Langage du développeur
Vue externe du système Vue interne du système
Structuré par les cas Structuré par les classes et les paquetages
Sert à définir un contrat entre le client et les
développeurs
Sert à comprendre le système
Informel Cohérent , non redondant
Capture les fonctions du système et ce qui
conditionne l’architecture
Esquisse la manière de réaliser les fonctions
dans le système et leur répartition dans des
classes

 Le modèle d’analyse est un modèle d’objet
conceptuel.
 Un modèle d’analyse structure les besoins et les
exigences dans le langage des développeurs pour
faciliter la compréhension, la modification.
 Une première ébauche du modèle de conception
constituant une entrée essentielle pour
l’élaboration du système.
83
-Analyse (modèle d’analyse)-

 Une classe d’analyse représente une ou plusieurs
classes et/ou sous systèmes.
84

 Une classe frontière modélise l’interaction entre le
système et ses acteurs.
 Elles présentent des fenêtres, des formulaires, des
interfaces de communication, des terminaux et
des API.
 Elles n’ont pas besoin de décrire la réalisation
physique de l’interaction.
 Elle est liée à au moins un acteur.
85

 Une classe entité modélise les informations de
longue durée et souvent de nature persistante.
 Elles présentent des objets gérés par le système.
 Elles font apparaître une structure de données
logique .
 Elles offrent une meilleure compréhension des
informations dont le système dépend.
86

 Une classe de contrôle représente la coordination, le
87
contrôle
séquencement, les transactions et le
d'objets.
 Elles modélisent la dynamique du système .
 Elles servent souvent à encapsuler le contrôle
associé à un cas d’utilisation spécifique.

88

Processus_Unifie_et_Approche_Agile chapitre 1.pptx

Contenu connexe

Tendances

Similaire à Processus_Unifie_et_Approche_Agile chapitre 1.pptx

Plus de informatiquehageryah

Dernier

Processus_Unifie_et_Approche_Agile chapitre 1.pptx