GÉNIE LOGICIEL
(SOFTWARE ENGINEERING)
2ÈME PARTIE – PROCESSUS DE
DEVELOPPEMENT DU LOGICIEL
(SOFTWARE PROCESS)
Faculté des Sciences et Techniques
[Link]
[Link]@[Link]
Plan de cette partie de cours
2
Modèles de processus de développement du
logiciel
Les activités de ces processus
Prise en compte des changements
Le processus de développement
de logiciel
3
Un ensemble structuré d’activités nécessaires pour
développer un logiciel
Un modèle de développement de logiciel est une
représentation abstraite d’un processus
De nombreux modèles différents mais pour tous :
Spécification : on définit ce que le système devra faire
Conception et implémentation : on définit l’organisation du
système et on l’implémente
Validation : on vérifie que le système fait bien ce que veut
le client
Evolution : on modifie le système en réponse aux
changements des besoins du client
Description du processus de
développement de logiciel
4
Quand on décrit des processus, on parle des
activités au sein de ceux-ci telles que : spécifier
un modèle de données, concevoir une interface,
etc et l’ordonnancement de ces activités
La description du processus peut aussi inclure
Les produits, qui sont les résultats des sorties d’une
activité d’un processus
Les rôles, qui reflètent les responsabilités des
personnes impliquées dans le processus
Les pré- et post-conditions, qui sont des conditions
vraies avant et après l’activité d’un processus
Processus agile vs dirigé par
5
planification
Dans un processus dirigé par la planification,
toutes les activités sont planifiées à l’avance et
les progrès sont mesurés vis-à-vis de ce plan
Dans les processus agiles, la planification est
incrémentale. Il est alors plus facile de
changer le processus pour refléter les
changements de besoins utilisateurs
En pratique : un peu des deux
Il n’y a pas de bon ou mauvais choix
Les modèles de développement de
logiciel
6
Le modèle en cascade
Modèle en V
Développement incremental (prototypage)
Modèle orienté réutilisation
Le modèle en spirale
En pratique : mélange de divers modèles
Le modèle en cascade
7
Etude
préalable
Spécification
Conception
générale
Conception
détaillée
codage
intégration
Validation
recette
diffusion
exploitation
Les étapes du modèle en cascade
8
Etude préalable (feasibility)
Phase exploratoire
Y-a-t-il lieu de réaliser le logiciel ?
Fixer les conditions générales
Débouche sur une phase conceptuelle
Cahier des charges et plan de projet
Spécification (requirements)
Description informelle définition précise
Des objets manipulés
Des tâches à effectuer sur ces objets
Des contraintes de performance
Planification détaillée des étapes suivantes
Le modèle en cascade
9
Etude
préalable
Spécification
Conception
générale
Conception
détaillée
codage
intégration
Validation
recette
diffusion
exploitation
Les étapes du modèle en cascade
10
Conception générale (product design)
Définition réalisation
Architecture du système
Principales structures de données
Décomposition du système en modules
Conception détaillée (detailed design)
Raffinement des éléments précédents jusqu’à
l’obtention d’une forme permettant d’écrire
immédiatement les programmes
Le modèle en cascade
11
Etude
préalable
Spécification
Conception
générale
Conception
détaillée
codage
intégration
Validation
recette
diffusion
exploitation
Les étapes du modèle en cascade
12
Codage (coding)
Écriture des textes des programmes
Intégration
Regroupement des divers modules
Construction de l’architecture générale
Validation globale/recette
Diffusion
Préparation et distribution des différentes versions
Exploitation
Mise en place du système dans son environnement
opérationnel
Le modèle en cascade
13
Deux interprétations
Neutre : c’est une description
Volontariste : on doit suivre ces étapes
On doit suivre TOUTES les étapes
L’ordre doit être respecté
On passe à l’étape n que lorsque l’étape n-1 est
terminée
Les remises en cause font remonter d’un seul niveau
Principale faiblesse : difficulté à s’adapter aux
changements une fois le processus lancé
Documents produits par les étapes du
modèle en cascade
14
Étude préalable
Phase exploratoire
Dossier d’entretiens
Décisions (faire, ne pas faire, faire faire, acheter)
Budget approximatif
Phase conceptuelle
Cahier des charges
Plan général du projet
Budget précis
Définition des contraintes
Spécification
Document de spécification (fonctions et performances)
Première version du manuel utilisateur
Plan détaillé du reste du projet
Plan de validation
Documents produits par les étapes du
modèle en cascade
15
Conception générale
Définition des principales structures de données
Décomposition du système en modules (architecture)
Description du rôle de chaque module
Conception détaillée
Description détaillée des structures de données et des modules
Codage
Texte des programmes
Chaque module est vérifié séparémment
Validation globale, recette
Compte rendu de recette
Rapports d’inspection et de validation
Diffusion
Versions des programmes et de leur documentation adaptées
Exploitation
Programme en fonctionnement
Rapports d’incidents et de correction
Le modèle en cascade
16
Etude
préalable
Spécification
Conception
générale
Conception
détaillée
codage
intégration
Validation
recette
diffusion
exploitation
Spécification
17
Processus qui dresse la liste de ce qui est attendu du
système, ainsi que les contraintes sur l’exécution du
système et son développement
Requirement = besoin/exigence/spécification
Requirement engineering process
Etude de faisabilité
Est-il techniquement et financièrement faisable de construire le
système ?
Elicitation et analyse des exigences
Qu’est-ce que les parties prenantes du système attendent de ce
système ?
Spécification des exigences
On définit les exigences en détail
Validation des exigences
On vérifie la validité des exigences
Le processus de spécification
18
Le modèle en cascade
19
Etude
préalable
Spécification
Conception
générale
Conception
détaillée
codage
intégration
Validation
recette
diffusion
exploitation
Conception et implémentation
20
Processus consistant à convertir la
spécification en un système exécutable
Conception
Conception de la structure du logiciel permettant
de réaliser la spécification
Implémentation
Traduction de cette structure en un code
compilable
Activités très liées
Modèle général du processus de
conception
21
Les activités de la conception
22
Conception de l’architecture
Identification de la structure globale du système
Les principaux composants
Leurs relations
Conception des interfaces
On définit les interfaces du système
Conception des composants
Conception de chaque composant de façon
indépendante
Conception de la base de données
Conception de la structure de la base de données
Vérification et Validation
23
Vérification
Le système est conforme à la spécification
(are we doing the product right?)
Validation
Le système répond aux exigences du client
(are we doing the right product?)
Inspections et tests
Tests
On exécute le système avec des cas de tests issus de
la spécification de données réelles du système futur
Les phases de test
24
Tests unitaires
Les composants sont testés individuellement
Tests d’intégration
Test du système global
Tests de recette
Test avec des données clients pour vérifier que le
système répond aux exigences du client
Les phases de test
25
Problèmes du modèle en cascade
26
Découpage rigide du projet en étapes distinctes
difficile de s’adapter aux changements des
besoins utilisateurs
Modèle bien adapté si les spécifications peuvent être
précises dès le début et changeront peu
Toutefois, il est rare d’avoir des spécifications stables
Les tests sont prévus tardivement
Le modèle en cascade est principalement utilisé
dans les grands projets où les systèmes sont
développés sur plusieurs sites
Dans ce cas, le modèle en cascade facilite la
planification du projet
Le modèle en V
27
Etude
exploitation
préalable
Validation
Spécification
recette
Conception Tests
générale d’intégration
Conception Tests
détaillée unitaires
codage
Modèle en V
28
Evolution du logiciel
29
Les logiciels sont flexibles et peuvent évoluer
Les exigences peuvent changer avec les
évolutions de l’environnement (législatifs,
financiers, techniques, etc) le logiciel basé
sur cet environnement doit évoluer
De plus en plus de nouvelles versions par
évolution de nos jours
Evolution du logiciel
30
Développement incrémental
31
Bénéfices du développement
32
incrémental
Les coûts de l’adaptation aux évolutions des
exigences clients sont réduits
Le volume d’analyse et documentation qui doivent être
conçu à nouveau est moindre que dans le modèle en
cascade
Il est plus facile d’avoir des feedbacks réguliers du
client
Les clients peuvent faire des commentaires lors de
démonstrations et constater l’avancée du travail
Possibilité de livrer plus rapidement des morceaux de
logiciels utiles au client
Le client peut utiliser des morceaux de logiciels plus tôt
que dans le modèle en cascade
Problèmes du développement
33
incremental
Le processus n’est pas visible (moins que dans le
modèle en cascade)
Les managers ont besoin de documents pour mesurer les
progrès. Si le système évolue rapidement il n’est pas
productif de produire des documents reflétant chaque
version du système
La structure du système a tendance à se dégrader à
chaque nouvel incrément
à moins que du temps et de l’argent soient dépensés
pour reconstruire le logiciel pour l’améliorer, les
changements réguliers conduisent à une déterioration de
la structure du logiciel. Plus on incorpore de changements
plus cela devient difficile et couteux
Problèmes du développement
34
incremental
Approche orientée réutilisation
35
Basée sur une réutilisation systématique de
composants existants (commercial-off-the-shelf
– COTS) pour concevoir un nouveau système
Les étapes du processus
Analyse des composants
Spécification des modifications
Conception avec réutilisation
Développement et intégration
De plus en plus utilisé de nos jours
Reuse-oriented software engineering
36
Les types de composants logiciels
37
Les Web services
Développés selon des standards
Disponibles par appel sur un serveur
Collections d’objets intégrés dans un
framework (tel que .NET ou J2EE)
Logiciels autonomes (COTS) configurés pour
une utilisation dans un environnement
particulier
S’adapter aux changements
38
Les changements sont inévitables dans les grands
projets
L’environnement change changement des exigences
Nouvelles technologies possibilité d’amélioration des
implémentations
Evolution des plateformes changement des
applications
Changements Nouvelles charges
Re-analyse des exigences
Coût d’implémentation de nouvelles fonctionnalités
Réduire les coûts du re-développement
39
Eviter les changements
Le processus de développement prévoira des
activités permettant d’anticiper des changements
Exemple : développement d’un prototype pour
montrer des fonctionnalités clés au client
Tolérance au changement
On s’accomode de changements à faible coût
Développement incrémental
Les changements sont implémentés dans des
incréments non encore développés
Si cela est impossible alors un incrément peut
incorporer les changements
Prototypage
40
Un prototype est une version
initiale/intermédiaire d’un système, utilisée
pour démontrer des concepts et faire des
essais de choix de conception
Un prototype peut être utilisé pour
Le processus de spécification pour aider à
l’élicitation des exigences et leur validation
L’étape de conception, pour explorer des choix et
proposer diverses versions d’interfaces
Comparer des versions lors de la phase de tests
Divers types de prototypes
41
Prototype exploratoire (maquette)
Pour expliciter plus clairement l’expression des
besoins (exigences)
Horizontal : permet de tester toutes les
fonctionnalités à un niveau abstrait
Vertical : quelques fonctions sont testées
complètement
Prototype expérimental
étude de choix de conception
Prototype évolutif
Réalisé par raffinements successifs
Bénéfices du prototypage
42
Améliore la facilité d’utilisation du système
Meilleur adéquation avec les besoins réels
Améliore la qualité de la conception
Améliore la maintenabilité
Réduit les efforts de développement
Processus de développement de prototype
43
Développement de prototype
44
Peut être basé sur des langages ou outils de
prototypage
Peut laisser de côté la fonctionnalité du produit
Le prototype se focalise plutôt sur des côtés du
produits qui ne sont pas bien compris
Le traitement des erreurs peut ne pas être
spécialement étudié dans le prototype
Se focalise sur les exigences fonctionnelles plutôt
que les non fonctionnelles
Prototypes jetables
45
Un prototype n’est pas une bonne base pour
un système commercial
Ilpeut être impossible de répondre à des
exigences non fonctionnelles
Les prototypes sont souvent non documentés
La structure d’un prototype se dégrade
généralement rapidement avec les évolutions
Le prototype ne répond souvent pas aux
standards de qualité de l’environnement client
Livraison incrémentale
46
Plutôt que de livrer un système en une fois, le
développement et la livraison sont découpés en
incréments, chaque incrément permettant de livrer une
partie de la fonctionnalité
Les exigences sont ordonnées suivant leur priorité. Les
exigences les plus prioritaires sont inclues dans les
premiers incréments
Lorsque le développement d’un incrément a commencé,
les exigences sont figées. Les exigences pour les autres
incréments peuvent continuer à évoluer
Développement et livraison
incrémental
47
Développement incremental
On développe le système par incrément. Chaque incrément est
évalué avant de commencer le développement de l’incrément
suivant
C’est la démarche usuelle dans les méthodes agiles
Evaluation réalisée par utilisateur/client
Livraison incrémentale
On déploit un incrément pour un utilisateur final
Approche délicate pour les systèmes de remplacement car alors
les incréments possèdent moins de fonctionnalités que le
système à remplacer
Livraison incrémentale
48
Avantage de la livraison
incrémentale
49
Chaque incrément apporte de la valeur pour le
client les fonctionnalités du système sont
disponibles plus tôt
Des incréments précoces peuvent servir de
prototypes et aider à l’élicitation d’exigences
Moins de risque d’échec global du projet
Les services prioritaires du système ont
tendance à subir le plus de tests
Problèmes de la livraison
incrémentale
50
La plupart des systèmes requièrent un ensemble de
fonctionnalités de base utilisées par les diverses parties
du système
Comme les exigences ne sont pas définies en détail tant qu’un
incrément n’est pas implémenté, il peut être difficile d’identifier les
fonctionnalités communes à tous les incréments
L’essence même du processus itératif est que la
spécification est développée simultanément au logiciel
Cela peut être en conflit avec le fait que les spécifs font partie du
contrat
Modèle en spirale
51
Le processus de développement est
représenté par une spirale plutôt qu’une
séquence d’activités avec retour arrière
éventuels
Chaque boucle dans la spirale représente une
étape du processus de développement
Les risques sont explicitement adressés et
résolus tout au long du processus
Modèle en spirale
52
Les divers secteurs du modèle en spirale
53
Définition des objectifs
Les objectifs spécifiques de l’étape sont identifiés
Estimation et réduction des risques
Les risques sont évalués et des activités sont mises
en place pour réduire les risques clés
Développement et validation
Un modèle de développement est choisi pour le
système
Planification
Le projet est inspecté et l’étape suivante de la spirale
est planifiée
54
FIN DE LA 2 ème PARTIE
