GÉNIE LOGICIEL

(SOFTWARE ENGINEERING)

2ÈME PARTIE – PROCESSUS DE

DEVELOPPEMENT DU LOGICIEL
(SOFTWARE PROCESS)

Faculté des Sciences et Techniques

http://perso.univ-st-etienne.fr/jacquene/gl/

Francois.Jacquenet@univ-st-etienne.fr
 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