DECRET N° 2002/209 DU 19 AOUT 2002 PORTANT ORGANISATION DU ...
© Petko ValtchevUniversité de Montréal Janvier 2002 1 IFT 2251 Génie Logiciel Le Processus (fin)...
Transcript of © Petko ValtchevUniversité de Montréal Janvier 2002 1 IFT 2251 Génie Logiciel Le Processus (fin)...
© Petko Valtchev Université de Montréal Janvier 2002 1
IFT 2251Génie LogicielLe Processus
(fin)
IFT 2251Génie LogicielLe Processus
(fin)
Hiver 2002 Petko Valtchev
© Petko Valtchev Université de Montréal Janvier 2002 2
BasesBases SommaireSommaire
Logiciel, tentative de définition
Génie logiciel, aspects historiques
La qualité des logiciels
Le processus de production Concepts de base Nature du processus et phases Modèles de processus
© Petko Valtchev Université de Montréal Janvier 2002 3
BasesBases Les QuestionsLes Questions
Questions fondamentales: Quel est le problème à résoudre?
Quelles sont les fonctionnalités désirées du logiciel?
Comment sera conçu et construit le logiciel?
Quelle technique sera utilisée dans la détection des erreurs
(bogues) dans le logiciel
Comment le logiciel sera-t-il maintenu (corrigé et/ou amélioré)?
© Petko Valtchev Université de Montréal Janvier 2002 4
BasesBases Les ActivitésLes Activités
Les Activités constituant le Processus:
1. Acquisition des besoins
2. Analyse
3. Conception
4. Implémentation
5. Vérification et validation
6. Maintenance
7. Retrait
l + Gestion des ressources humaines et matérielles
© Petko Valtchev Université de Montréal Janvier 2002 5
BasesBases DéfinitionsDéfinitions
« Processus: fournit un cadre pour le développement en apportant desréponses aux principales questions d’ordre organisationnel. »
Pressman, 2001
• Comment gérer les activités du projet?• Comment utiliser les ressources techniques?• Comment produire les différents documents (pour décrire modèles, données, avancement du projet, etc.)?• Comment fixer les objectifs du projet à long, moyen et court terme?• Comment gérer les éventuels changements?
Ex. Rational Unified Process, Extreme Programming, etc.
© Petko Valtchev Université de Montréal Janvier 2002 6
BasesBases Définitions (suite)Définitions (suite)
« Méthode: Décrit une manière d’aborder les différentes activités (souvent un sous-ensemble) du développement du logiciel en proposant
des principes, des théories, des formalismes, des techniquesde modélisation et de spécification pour réaliser ces activités. »
Pressman, 2001
Ex. OMT, OOA/OOD, Objectory, etc.
© Petko Valtchev Université de Montréal Janvier 2002 7
BasesBases Définitions (fin)Définitions (fin)
« Outil: Support automatisé ou semi-automatisé pour l’application d’une méthode ou d’un processus. »
Pressman, 2001
Atelier de Génie Logiciel: Ensemble cohérent d'outils informatiques formantun environnement d'aide à la conception, au développement et à la mise aupoint de logiciels d'application spécialisés.
Computer-Aided Software Engineering (CASE) Tool
© Petko Valtchev Université de Montréal Janvier 2002 8
BasesBases SommaireSommaire
Logiciel, tentative de définition
Génie logiciel, aspects historiques
La qualité des logiciels
Le processus de production Concepts de base Nature du processus et phases Modèles de processus
© Petko Valtchev Université de Montréal Janvier 2002 9
BasesBases
statusquo
définitiondu
problème
techniquedéveloppement
solution
intégrationde la
Résolution itérative de problèmes
Le Processus LogicielLe Processus Logiciel
Ré-évaluationde la situation:
Phase 2
Phase 1
Phase 3
© Petko Valtchev Université de Montréal Janvier 2002 10
BasesBases Les Phases, 1Les Phases, 1
Objectifs Besoins : Comprendre le problème Spécification : Identifier les caractéristiques requis du système
Pourquoi : répondre à l'évolution des matériels, des systèmes, des langages de programmation, et surtout la complexité toujours croissantes des logiciels.
1. Définition1. Définition
Quel public (usagers)? Quelles fonctionnalités? Quelles propriétés? Quelles performances? Quelles comportements? Quel type d’interfaces?
QUOI
© Petko Valtchev Université de Montréal Janvier 2002 11
BasesBases Les Phases, 2Les Phases, 2
2. Developpement2. Developpement
Comment structurer l’information? Comment implémenter la conception logicielle? Comment tester le logiciel?
COMMENT
Objectif Traduction progressive des spécifications (Le Problème) vers
une description du système (La Solution) sans pour autant produire ce système.
Pourquoi : réduire la complexité du passage entre la description du problème et sa solution.
© Petko Valtchev Université de Montréal Janvier 2002 12
BasesBases Les Phases, 3Les Phases, 3
3. Maintenance3. Maintenance
Corrections Adaptations Améliorations Modifications préventives
CHANGEMENT Pourquoi :
Erreurs Évolution de l’environnement Nouveaux besoins Anticipation sur les conditions
de fonctionnement et de maintenance
Réingénierie
© Petko Valtchev Université de Montréal Janvier 2002 13
BasesBases Activités de supportActivités de support
I
C
D
Activités de support
1. Suivi du projet
2. Révision formelle
3. Contrôle de la qualité
4. Documentation
5. Gestion de la réutilisation
6. Évaluation
7. Gestion du risque
etc.
1. Suivi du projet
2. Révision formelle
3. Contrôle de la qualité
4. Documentation
5. Gestion de la réutilisation
6. Évaluation
7. Gestion du risque
etc.
© Petko Valtchev Université de Montréal Janvier 2002 14
BasesBases Maturité du ProcessusMaturité du Processus
Primitif (Initial)
Reproductible (Repeatable)
Défini
Bien géré (Managed)
Optimisant
Le modèle proposé par SEI (Software Engineering Institute)
© Petko Valtchev Université de Montréal Janvier 2002 15
BasesBases SommaireSommaire
Logiciel, tentative de définition
Génie logiciel, aspects historiques
La qualité des logiciels
Le processus de production Concepts de base Nature du processus et phases Modèles de processus
© Petko Valtchev Université de Montréal Janvier 2002 16
BasesBases Le Modèle en Cascade
analyse conception code test
Ingénierie dusystème
Le modèle classique de développement
© Petko Valtchev Université de Montréal Janvier 2002 17
BasesBases La CascadeLa Cascade
Ingénierie du système - phase préliminaire
Système (au sens large) = configuration de composantes matérielles, logicielles (BD, réseaux, passerelles Web, etc.), humaines (usagers du système).
dans laquelle devra s’intégrer le logiciel à développer.
Besoins - clarification des besoins relatifs à tous les éléments du système
Vue d’ensemble sur les besoins.
© Petko Valtchev Université de Montréal Janvier 2002 18
BasesBases Les ActivitésLes Activités
Analyse des besoinsAnalyse des besoins
Objectif : éviter de produire un logiciel inadéquat.
Démarche :
Étudier les besoins et les spécifier de la manière la plus claire possible.
Les éléments pertinents incluent:
le domaine d’application,
l'environnement du futur système,
le rôle escompté du système,
les ressources disponibles et requises,
les contraintes d'utilisation,
les performances attendues.
© Petko Valtchev Université de Montréal Janvier 2002 19
BasesBases Les ActivitésLes Activités
ConceptionConception
Objectif : transformer la description du problème obtenu par l’analyse
en une description (de plus en plus détaillée) de la solution, sans pour
autant produire la solution elle-même.
Démarche :
La conception architecturale:
décomposition du système logiciel en sous-systèmes
(composants) de taille et complexité inférieures; chaque sous-
système est décrit par ces fonctions et les interfaces avec le reste
du système.
La conception détaillée:
définition des détails concernant la réalisation de chaque
composant: algorithmes, structures de données, etc.
© Petko Valtchev Université de Montréal Janvier 2002 20
BasesBases Les ActivitésLes Activités
ImplémentationImplémentation
Objectif : Production du code des composants à partir de leurs
conceptions détaillées.
Démarche :
Si la conception est de bonne qualité, la génération se fait de
manière directe et peut être automatisée pour une grande partie.
© Petko Valtchev Université de Montréal Janvier 2002 21
BasesBases Les ActivitésLes Activités
Vérification (tests)Vérification (tests)
Objectif : S’assurer que le logiciel produit respecte les spécifications
initiales.
Démarche :
Vérification de l’ensemble des descriptions produites tout au long du
développement.
Examens des artefacts du développement:
preuves de correction
tests dynamiques = choix d’une sous-ensemble représentatif des
données possibles et exécution du logiciel avec ces données.
© Petko Valtchev Université de Montréal Janvier 2002 22
BasesBases Les ActivitésLes Activités
MaintenanceMaintenance
Objectif : S’assurer que le logiciel livré continue de répondre aux
besoins du client qui peuvent évoluer dans la période post-livraison.
Démarche :
Correction d’erreurs,
Adaptations
Ex. nouvelle plate-forme,
Améliorations
Ex. service accessible via le Web.
Changements au logiciel = nécessité de traverser une ou plusieurs
(voire toutes) les phases du développement en cascade.
© Petko Valtchev Université de Montréal Janvier 2002 23
BasesBases Le Modèle en CascadeLe Modèle en Cascade
BilanBilan
Les projets réels suivent rarement un déroulement purement séquentiel,
souvent il y a des retours en arrière.
Le client est rarement capable d’exprimer la totalité de ses besoin en une
seule fois, d’habitude il prend conscience de certains besoins au cours
du projet.
Le client doit être patient car il ne verra une version exécutable de son système que vers la fin du processus de développement.
Problème de
validation
important!!!
© Petko Valtchev Université de Montréal Janvier 2002 24
BasesBases SommaireSommaire
Le processus de production Concepts de base Nature du processus et phases Modèles de processus
Modèle en cascade Modèle par prototypage « Rapid Application Development » Modèles évolutifs Modèles avancés
© Petko Valtchev Université de Montréal Janvier 2002 25
BasesBases Développement de PrototypesDéveloppement de Prototypes
CLIENT
INGENIEURDU LOGICIEL
Connaissances du domaine
Jargon technique
Connaissances en logiciel
Langages, notations
Indécis, opinion variable
Besoins ambigus, incomplets
Spécifications ésotériques
Document
des besoins
Incomplet
Imprécis
© Petko Valtchev Université de Montréal Janvier 2002 26
BasesBases Modèle par Prototypage
Consulter/ réviser
la maquette
Écouterle
client
Faire tester
la maquette
par le client
Une ou plusieursitérations…
Démarche : • Pour corriger les spécifications du logiciel au fur et à mesure, construction d’un prototype (maquette).
© Petko Valtchev Université de Montréal Janvier 2002 27
BasesBases Les PrototypesLes Prototypes
Deux manières de construire des prototypes:
Approche classique «prototypage jetable » : Réalisation rapide d’un prototype dès le début du cycle de vie. Le
prototype sert alors de référence pour la définition et la validation des spécifications, puis il est « jeté ».
Le système logiciel final ne contient pas d’éléments du prototype.
Approche évolutive «prototypage incrémental» : Réalisation dès le début du cycle de vie d’un premier prototype (p1).
Ajouts progressif de fonctionnalités supplémentaires (raffinements: p2,p3,…) jusqu’à l’obtention du prototype final pn(pn = système visé).
© Petko Valtchev Université de Montréal Janvier 2002 28
BasesBases Le Modèle par PrototypageLe Modèle par Prototypage
BilanBilan
Le client a tendance à vouloir faire du simple prototype son produit final.
Il ignore que souvent la façade cache une conception très
approximative, voire inexistante.
Les choix des développeurs pris lors du prototypage, et donc sous fortes
contraintes temporelles, ont des fortes chances de devenir de choix
définitifs. On oublie que ces choix n’étaient peut-être pas les meilleurs
du point de vue de la qualité.
© Petko Valtchev Université de Montréal Janvier 2002 29
BasesBases SommaireSommaire
Le processus de production Concepts de base Nature du processus et phases Modèles de processus
Modèle en cascade Modèle par prototypage « Rapid Application Development » Modèles évolutifs Modèles avancés
© Petko Valtchev Université de Montréal Janvier 2002 30
BasesBases Rapid Application DevelopmentRapid Application Development
Cycle de développement très court = 60 à 90 jours.
Adaptation « haute vitesse » du modèle en cascade.
Conception à base de composants.
Pré-conditions essentielles:
1. besoins logiciels bien saisis,
2. portée du projet bien définie,
3. projet facilement « modularisable ».
© Petko Valtchev Université de Montréal Janvier 2002 31
BasesBases Le Modèle RADLe Modèle RAD
Cinq grandes phases :
1. Modélisation des fonctions d’affaires (business functions): • Définition des fonctions du système (en termes d’entrées - sorties)
et du flot des informations à être manipulées et transformées.
2. Modélisation des données: • Définition des structures de données qui vont accueillir les
informations manipulées.
3. Modélisation des processus: • Définition des processus qui traitent les informations.
4. Génération de l’application: • Construction de l’application à partir des modèles produits
auparavant.
• Utilisation d’outils de 4e génération (ex. CASE) pour la généation.
5. Test et livraison de l’application.
© Petko Valtchev Université de Montréal Janvier 2002 32
BasesBases Schéma RAD
modéliserles fonctions
d’affaires
business modeling
data modeling
process modeling
application
generation test &
turnover
businessmodeling
datamodeling
processmode ling
applicationgeneration
testing&turnover
équipe #1 équipe #2 équipe #3
60 - 90 jours
Rapid ApplicationDevelopment
modéliserles données
modéliserles processus
générerl’application
testeret
livrer
© Petko Valtchev Université de Montréal Janvier 2002 33
BasesBases Le Modèle RADLe Modèle RAD
BilanBilan Nécessite des ressources humaines importantes:
Afin de pouvoir composer le nombre suffisant d’équipes. Exige l’engagement constant du client sous péril de faire échouer le
projet. Supporte mal des niveaux de risque élevés:
Le modèle RAD n’est pas approprié lorsque des facteurs de risque importants sont présents car ceux-ci peuvent provoquer de retards non-négligeables dans le travail d’une des équipes.
Ex. utilisation de nouvelles technologies Portée limitée:
Le modèle RAD ne se prête pas au développement de certains types de logiciel
© Petko Valtchev Université de Montréal Janvier 2002 34
BasesBases SommaireSommaire
Le processus de production Concepts de base Nature du processus et phases Modèles de processus
Modèle en cascade Modèle par prototypage « Rapid Application Development » Modèles évolutifs
– Modèle incrémental
– Modèle en spirale Modèles avancés
© Petko Valtchev Université de Montréal Janvier 2002 35
BasesBases Les Modèles ÉvolutifsLes Modèles Évolutifs
Afin de permettre un retour de la part du client (usager) plus tôt dans le processus global:
De versions successives du système sont livrées, avec chaque prochaine version possédant des fonctionnalités de plus en plus complètes vis à vis des besoins du client.
Un processus global itératif est utilisé permettant de passer plusieurs fois par les différentes phases du développement.
Ex. Modèle par «prototypage incrémental» - une approche évolutive Modèle incrémental Modèle en spirale
Au sein des modèles vus précédemment:
Le système est divisé en composants séparés qui sont développés pour être intégrés à la fin (juste avant les tests et la livraison).
CONSTAT
© Petko Valtchev Université de Montréal Janvier 2002 36
BasesBases
Modèles par incrément:
• le système est séparé en incréments qui sont constitués d’un ensemble de composants,
• chaque incrément développé selon un modèle de processus complet:
• souvent un modèle en cascade,
• à la fin de leur cycle de vie (indépendante) des incréments viennent s'intégrer, dans l’ordre, à un noyau développé au préalable (le plus souvent, l’incrément 1)
i1i3i2
i1 i1i2
… i4
version 1(noyau) version 2 version finale
Le Modèle IncrémentalLe Modèle Incrémental
© Petko Valtchev Université de Montréal Janvier 2002 37
BasesBases
analysis design code test
analysis design code test
analysis design code test
incrément 2
incrément 1 (noyau)
livraison du1er incrément
temps
analyse concept. code test
incrément 3
incrément 4
livraison du2nd incrément
livraison du3eme incrément
livraison du4eme incrément
Schéma IncrémentalSchéma Incrémental
© Petko Valtchev Université de Montréal Janvier 2002 38
BasesBases
Avantages
• chaque développement est en soi moins complexe,
• l’intégration des incréments se fait de manière progressive,
• possibilité (et non obligation!) d’une livraison et de mise en service après le développement de chaque incrément,
• permet une meilleure gestion de l’ensemble des ressources allouées au projet:
• du temps réduit par rapport au modèle en cascade
• du coût en effort humain réduit par rapport au RAD:
• recouvrement entre processus pour les incréments,
• mis pas de recouvrement entre phases.
Risques
• devoir remettre en cause le noyau ou les incréments précédents,
• une tâche ardue,
• ne pas pouvoir intégrer de nouveaux incréments.
Le Modèle Incrémental, BilanLe Modèle Incrémental, Bilan
© Petko Valtchev Université de Montréal Janvier 2002 39
BasesBases SommaireSommaire
Le processus de production Concepts de base Nature du processus et phases Modèles de processus
Modèle en cascade Modèle par prototypage « Rapid Application Development » Modèles évolutifs
– Modèle incrémental
– Modèle en spirale Modèles avancés
© Petko Valtchev Université de Montréal Janvier 2002 40
BasesBases Le Modèle en SpiraleLe Modèle en Spirale
L’inévitable remise en cause des résultats d’un processus partiel est explicitée sous forme d’une spirale dans le modèle du même nom.
Projet global, divisé en un ensemble de sous-projets réalisés en séquence. Sous-projet = un circuit de la spirale de développement (1 ou + tours). Chaque tour de la spirale traverse six régions d’activités. Région d’activité = ensemble de tâches spécifiques à réaliser.
Chaque tour de la spirale doit produire ses propres résultats: un document de spécification, un prototype initial, une version améliorée du prototype, etc.
De facteurs comme
• l’évolution des besoins ou• leur remise en cause après la livraison,
lesquels entraînent un passage supplémentaire par toutes les phases du cycle de vie, ne sont pas reflétés par les modèles vus précédemment.
CONSTAT
© Petko Valtchev Université de Montréal Janvier 2002 41
BasesBases
Planification
Discussionavec le Client
Évaluationpar le Client
Construction & Livraison
Ingénierie
Analyse des risques
Les itérations sont rendues explicites!
Le Modèle en Spirale, SchémaLe Modèle en Spirale, Schéma
© Petko Valtchev Université de Montréal Janvier 2002 42
BasesBases
Avantages
• Combine les avantages des modèle en cascade, par prototypage et incrémental.
• De façon générale, le modèle est réaliste et bien adapté pour le développement de systèmes de taille large.
Risques
• L’analyse des risques étant, elle aussi, « évolutive », cela risque d’inquiéter le client.
• Modèle moins connu que les modèles en cascade et par prototypage. Moins de recul, donc difficile d’en évaluer l’efficacité.
Le Modèle Incrémental, BilanLe Modèle Incrémental, Bilan
© Petko Valtchev Université de Montréal Janvier 2002 43
BasesBases SommaireSommaire
Le processus de production Concepts de base Nature du processus et phases Modèles de processus
Modèle en cascade Modèle par prototypage « Rapid Application Development » Modèles évolutifs Modèles avancés
– Modèle de développement par composants
– Modèles centrés sur des méthodes formelles
© Petko Valtchev Université de Montréal Janvier 2002 44
BasesBases Le Modèle par ComposantsLe Modèle par Composants
Processus de développement similaire à celui en spirale mais dans lequel l’activité d’ingénierie a une forme particulière.
Ingénierie = conception de l’application à partir de composants logiciels prêts à l’emploi (disponibles sous forme de librairies commerciales)
1. Identification des composants candidats.
2. Chercher composants dans les librairies.
3. Si disponible, extraire les composants. Sinon, les construire
4. soi-même et les ajouter à la librairie.
5. Intégrer les composants à la nième version du système.
Certains Ateliers de génie logiciel offrent l’environnement nécessaire pour ce type de processus.
© Petko Valtchev Université de Montréal Janvier 2002 45
BasesBases SommaireSommaire
Le processus de production Concepts de base Nature du processus et phases Modèles de processus
Modèle en cascade Modèle par prototypage « Rapid Application Development » Modèles évolutifs Modèles avancés
– Modèle de développement par composants
– Modèles centrés sur des méthodes formelles
© Petko Valtchev Université de Montréal Janvier 2002 46
BasesBases Le Modèle « Méthodes Formelles »Le Modèle « Méthodes Formelles »
Plusieurs outils CASE disponibles pour les principales méthodes. Ex.
VDM, B, Z, CTL, Lotos, etc.
Avantages = Détection précise d’ambiguïtés et d’erreurs, de problèmes de complétude et de cohérence.
Inconvénients:
Coûteux en temps, expertise requise, moyen inadéquat pour communiquer avec le client.
Notations mathématiques et techniques d’analyse
rigoureuses pour la spécification, la conception
et la vérification de systèmes informatiques.