Embed Size (px)
Citation preview
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/
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
planification 5
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
Spécification
Conception
générale
Conception
détaillée
Etude
préalable
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
Spécification
Conception
générale
Conception
détaillée
Etude
préalable
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
Spécification
Conception
générale
Conception
détaillée
Etude
préalable
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
Spécification
Conception
générale
Conception
détaillée
Etude
préalable
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
Spécification
Conception
générale
Conception
détaillée
Etude
préalable
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
Spécification
Conception
générale
Conception
détaillée
Etude
préalable
codage
Tests
unitaires
Validation
recette
Tests
d’intégration
exploitation
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
incrémental 32
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
incremental 33
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
incremental 34
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
Il peut ê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
