Cycle de vie du logiciel

IFT2255:
Introduction au génie logiciel
Chapitre 2:
Cycle de vie du logiciel
Julie Vachon et Houari Sahraoui
Sommaire
Chapitre 2
« Cycle de vie du logiciel»
2.1 Cycle de vie du logiciel
2.2 Le rôle de l’analyste
… Planification
et ingénierie système
2.3 Aperçu
p ç des p
processus de développement
pp
… Modèle
en cascade
… Modèle par prototypage
… Modèle en spirale
… Etc.
p.2
1
2.1 Cycle de vie du logiciel
„
„
Pour réaliser un logiciel
Activités de développement (phases)
Organisation de ces activités dans le temps (procesus
de développement).
Analyse et
spécification
Planification
Du projet
Conception
et spécification
Activités en continu
documentation,
validation et vérification,
gestion
Vérification
Installation
Implémentation
Maintenance
p.3
Planification (étude préliminaire)
Est-ce
possible ?
„
„
Définition globale du problème
Confirmer la faisabilité
…
…
„
„
„
évaluation des stratégies possibles
évaluation des ressources, coûts et délais
Produire le calendrier du projet
Trouver le personnel
Lancer le projet
Documents: rapport de planification
p.4
2
Analyse des besoins
Quoi
faire?
Découvrir et comprendre les besoins
Cueillette d
d’informations
informations
… exigences fonctionnelles / qualités non fonctionnelles
„
Spécification du système
„
Construction de prototypes (pour élaborer la
spécification)
„
Prioriser les éléments de la spécifications
„
Produire et évaluer des solutions alternatives
„
Examiner les recommandations avec le chef de projet
et/ou le client…
Documents: cahier des charges, document de spécification
(analyse), prototype, plan de test.
„
p.5
Conception
1.
2.
Comment
faire?
Conception architecturale: décomposition et
organisation de l'application en modules plus
simples définis par une interface. Bases de
données, environnement d’exploitation,
interfaces.
Conception détaillée: pour chaque module,
d
description
i ti d
de lla manière
iè d
dontt lles services
i
ett
fonctions sont réalisés:
…
…
algorithmes essentiels
structures de données utilisées, etc.
p.6
3
Conception
„
„
„
„
„
„
„
Concevoir et intégrer le réseau
Concevoir l’architecture d’application
Concevoir les interfaces utilisateur
Concevoir les interfaces du système
Concevoir et intégrer la base de données
Faire un prototype des détails de la conception
Concevoir et intégrer les contrôles de sécurité
Documents: document de conception (spécification),
prototype, plan de test global et plan de test par module.
p.7
Implémentation
Traduction de la conception dans un langage de
programmation
p
g
ou mise en œuvre en utilisant des outils
de développement
„
Construire les composantes logicielles
Documents: dossiers de programmation,
code source commenté, prototypes.
p.8
4
Vérification
Est-ce bien fait? Le
programme répond-t-il à
la spécification?
1.
2.
3
3.
Tests
T
t unitaires:
it i
… Tests avec les jeux d'essais par module selon le
plan de test.
Tests d'intégration:
… Composition progressive des modules
… Tests des regroupement de modules
Test du système:
… Test en vraie grandeur du système complet selon
le plan de test global.
Documents: rapport de vérification par test.
p.9
Installation et maintenance
„
Installation:
… Mise
en fonctionnement opérationnel chez les
utilisateurs.
… Conversion des données.
… Parfois restreint (dans un 1er temps) à des
utilisateurs sélectionnés.
„
Maintenance:
… Maintenance
corrective (corriger erreurs)
… Maintenance adaptative (modifications)
… Maintenance perfective (améliorations)
… Aussi: maintenance préventive (pour faciliter les
opérations de maintenance à venir).
p.10
5
Activités en continu
„
Validation
…
Le produit répond-il aux besoins du client? «Construit-on le bon
produit?»
… S’assurer de répondre aux exigences du client.
„
Vérification
…
Le produit est-t-il correct (par rapport à la spécification)? «Construit-on
le produit comme il faut?»
… S’assurer de la qualité du produit (révisions et inspections)
… S’assurer de satisfaire la spécification.
„
Gestion
…
…
Du processus de développement (suivi de projet
projet, révision
révision, etc
etc.))
De la configuration: politique de gestion des versions, des documents,
politique de réutilisation
… Des ressources humaines
… Du risque
„
Documentation
p.11
2.2 Rôle de l’analyste
Membres de l’équipe de développement
Planification
Analyse
Conception architect.
Conception détaillée.
Analyste
Concepteur
Implémentation
Tests unitaires
Programmeur
Test d’intégration
Test système
Testeur
Installation
Formateur
Maintenance
p.12
6
Rôle de l’analyste
„
Responsabilités:
… chargé
de l’analyse et de la conception
… invité à participer à la planification stratégique
„
Titres de poste:
programmeur analyste, consultant, conseiller en
administration des affaires, concepteur de systèmes,
architecte système, concepteur de page web,
ingénieur logiciel,
logiciel chef ou gestionnaire de projet
„
Milieu de travail:
entreprise spécialisée dans l’analyse et la conception,
entreprise requérant les service d’un analyste pour ses
propres projets, à la pige, etc
p.13
Rôle de l’analyste
„
Connaissances et compétences
Techniques
…
…
…
„
Administratives
…
„
Fonctionnement des ordinateurs, périphériques, bases de
données, réseaux, langages de programmation, systèmes
d’exploitation et utilitaires
Outils de développement et progiciels
Technique d’analyse, de gestion, de conception, etc
Compréhension de l’organisation des entreprises en générales…
ett en particulier
ti li ((succès,
è plan
l stratégique,
t té i
ttraditions,
diti
valeurs,
l
etc.)
Relations humaines:
…
…
Comprendre comment les gens pensent, apprennent, réagissent,
communiquent et travaillent
Aptitude à bien communiquer
p.14
7
Ingénierie système
Diagramme de contexte
On peut décrire le cadre du système dans lequel le
logiciel s’inscrit par un diagramme de contexte.
Diagramme de contexte: Graphique montrant
l’ampleur d’un système.
„
„
„
Le système
L
tè
Les objets externes
Flots de données
p.15
Ingénierie système
Diagramme de contexte
Moteur
détecteur
Signal
moteur
Signal
détecteur
Bouton
cabine
Signal
b
bouton
cabine
Bouton
d’appel
Système de
contrôle
d’ascenseur
Signal
indicateur
Indicateur
Signal
porte
Signal
bouton
d’appel
Porte
p.16
8
2.3 Processus de développement
Processus de développement: Description abstraite et
idéalisée des différentes manières d'organiser
g
les
activités du développement d’un logiciel
1.
Décrit un ensemble de tâches ordonnées
impliquant
…
des activités (celles du cycle de vie)
… des contraintes (sur le temps, ressources, etc.)
… des ressources (humaines, matérielles, etc.)
p.17
Processus de développement
2.
Doit être «personnalisé» pour l'entreprise
de façon à définir l'ordonnancement
l ordonnancement idéal
des activités
…
…
…
…
spécifier les artéfacts à produire (types de documents,
format, échéancier)
attribuer activités & artéfacts aux acteurs
proposer des critères pour superviser ll'évolution
évolution du
projet, ses résultats et prévoir plans futurs (vérification,
validation, documentation, etc.)
proposer une méthodologie pour gérer les
changements tant dans le processus et que le logiciel
p.18
9
Processus de développement
Quelques modèles existants
… à personnaliser
Modèle en cascade
„ Modèle en V
„ Modèle par prototypage
„ Modèle en spirale
„ Etc..
„
p.19
Modèle en cascade
„
„
Analyse et
spécification
Etapes réalisées de façon strictement
q
séquentielle.
L’attention est centrée sur les artéfacts
produits à la fin chaque étape. (documentdriven)
Conception et spécif.
(architect. et détaillée)
Programmation
Test (unitaire,
intégration, système)
Installation
Maintenance
p.20
10
Modèle en cascade
Avantages
„ Plan simple de ce qu'il
faut faire
„ Facile à comprendre
„ Cette première définition
a permis la normalisation
des cadres conceptuels
et terminologiques des
différentes activités
„ Pertinent dans le cas des
anciens systèmes
…
…
Plus faciles à analyser et
modéliser;
de conception et mise en
oeuvre coûteuses (ex.
temps de compilation: 2
jours!)
Inconvénients
„ Hypothèses souvent
irréalistes que l'on peut
dès le départ définir
complètement et en détail
…
…
„
„
„
ce qu'on veut réaliser
les résultats intermédiaires
obtenus
Ne reflète pas la façon
dont le code est
réellement développé
pp
Trop rigide, manque de
flexibilité pour imprévus
Pas de «feedback» avant
la livraison au client....
p.21
Modèle en V
„
„
Variation du modèle en cascade
Attention centrée sur la correction: vérification et
validation
lid ti
Installation et
maintenance
Analyse et
spécification
validation
Test de validation
Conception
architecturale
Test du système
vérification
Conception
détaillée
Test unitaire
et d’intégration
Programmation
p.22
11
Modèle par prototypage
„
Le modèle de prototypage est souhaitable pour les projets où les besoins
…
…
„
ne sont pas clairement définis
peuvent changer avec le temps
Le prototypage permet le développement rapide d'une ébauche du futur
système (ni performance, ni fonctionnalités, ni qualité)
Collecte et analyse des besoins
Conception rapide
Raffinement du prototype
Implantation du prototype
Évaluation du client
Production du système
p.23
Modèle par prototypage
Types de prototypes
„
„
Prototype jetable: maquette exploratoire développée
pour mieux comprendre les besoins du client, évaluer
différentes solutions, etc. Développé rapidement et jeté
ensuite.
Prototype évolutif (ou réutilisable): maquette destinée à
êt complétée/optimisée
être
lété / ti i é dans
d
les
l prochaines
h i
étapes
ét
du
d
développement jusqu’à l’obtention du produit final.
p.24
12
Modèle en spirale
„
„
Modèle cyclique. Chaque cycle est composé de 4 étapes
A chaque cycle:
…
…
spécification de nouveaux besoins
critères de robustesse deviennent des critères de correction
2. Identification
des risques et
solutions pour
les réduire
1. Définition
des objectifs,
alternatives,
contraintes
3. Développement et
vérification/validation
de la prochaine
version du produit
4. Planification des
cycles suivants
p.25
Modèle en spirale
„
Risques majeurs du développement du logiciel
… défaillance
du personnel
… calendrier et budget irréalistes
… développement de fonctions inappropriées
… développement d'interfaces utilisateurs inappropriées
… produit « plaqué or »
… validité des besoins
… composants externes manquants
… tâches externes défaillantes
… problèmes de performance
… exigences démesurées par rapport à la technologie
p.26
13