3. 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
4. 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.)
5. 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
7. Un logiciel de qualité
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. Un logiciel de qualité
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. Un logiciel de qualité
9
Re-utilisabilité :
Vérifiabilité :
Portabilité :
Lisibilité et Modularité
10. Un logiciel de qualité
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é
11. 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.
13. 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.
15. 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,…)
16. 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
17. Cycle de vie d’un logiciel (modèle en
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
19. Cycle de vie d’un logiciel
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.
20. Cycle de vie d’un logiciel
(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
21. Cycle de vie d’un logiciel (modèle en
spirale)
21
22. 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. Méthode et Processus
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. Méthode et Processus
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.
26. 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
40. 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.
42. 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
44. 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
45. 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
46. 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).
47. 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.
48. 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
49. 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
50. 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.
51. Les phases du PU – phase 1
Etude
préliminaire
Elaboration Construction Transition
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
52. Les phases du PU – phase 2
Etude
préliminaire
Elaboration Construction Transition
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
53. Les phases du PU – phase 3
Etude
préliminaire
Elaboration Construction Transition
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
54. Les phases du PU – phase 4
Etude
préliminaire
Elaboration Construction Transition
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
55. Les phases du PU
Besoins
Analyse
Conception
Implémentation
T
ests
Phases
Etude Pré Élaboration Construction Transition
Activités
55
principales
56. 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.
57. Caractéristiques de Processus Unifié
(itératif et incrémental)
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. Caractéristiques de Processus Unifié
(itératif et incrémental)
58
Gestion de la complexité.
Prise en compte des modifications de besoins.
Apprentissage rapide de la méthode.
Maîtrise précoce des risques.
…
59. Caractéristiques de Processus Unifié
(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
60. Caractéristiques de Processus Unifié
(piloté par les UC)
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. Caractéristiques de Processus Unifié
(piloté par les UC)
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.
…
62. Caractéristiques de Processus Unifié
(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. Caractéristiques de Processus Unifié
(centré sur l’architecture)
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. Caractéristiques de Processus Unifié
(centré sur l’architecture)
64
Comprendre le système,
Organiser le développement,
Favoriser la réutilisation,
Faire évoluer le système.
65. Les 4 « P » du développement logiciel
Processus
Personnes Outils
Produit
Projet
Automatisation
Template
65
Participants
Résultat
66. 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.
67. Les enchaînements d’activités principaux
Besoins
Analyse
Conception
Implémentation
T
ests
Phases
Itérations
Etude Pré Élaboration Construction Transition
It. préliminaire It. n
… … … … … It. n-1
Activités
67
principales
68. Les enchaînements d’activités principaux
-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
69. 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
Les enchaînements d’activités principaux
-Expression des besoins-
71. 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
Les enchaînements d’activités principaux
-Expression des besoins-
71
72. Les enchaînements d’activités principaux
-Expression des besoins-
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. Les enchaînements d’activités principaux
-Expression des besoins-
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. Les enchaînements d’activités principaux
-Expression des besoins-
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.
78. 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.
79. Les enchaînements d’activités principaux
Besoins
Analyse
Conception
Implémentation
T
ests
Phases
Itérations
Etude Pré Élaboration Construction Transition
It. n
… … … … … It. n-1
Activités
79
principales
It. préliminaire
80. 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
Les enchaînements d’activités principaux
-Analyse-
82. Les enchaînements d’activités principaux
-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
83. 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
Les enchaînements d’activités principaux
-Analyse (modèle d’analyse)-
84. Une classe d’analyse représente une ou plusieurs
classes et/ou sous systèmes.
Les enchaînements d’activités principaux
-Analyse (modèle d’analyse)-
84
85. 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
Les enchaînements d’activités principaux
-Analyse (modèle d’analyse)-
86. 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
Les enchaînements d’activités principaux
-Analyse (modèle d’analyse)-
87. 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.
Les enchaînements d’activités principaux
-Analyse (modèle d’analyse)-