Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
1
© Petko Valtchev Université de Montréal Septembre 2004 1
IFT 3901Analyse et Conception
des Logiciels
Automne 2004Petko Valtchev
© Petko Valtchev Université de Montréal Septembre 2004 2
Analyse et Conception
1. Rappels sur la Qualité
etle Processus logiciel
2
© Petko Valtchev Université de Montréal Septembre 2004 3
Intro Quelques questions…
Pourquoi le génie logiciel?
Pour rationaliser la production, le déploiement et la maintenance du
logiciel.
Quelle portée de la discipline?
On s’intéresse au logiciel en tant que produit.
On s’intéresse à son cycle de vie en tant que processus et aux participantshumains.
Qu’est-ce qu’on vise?
La qualité du logiciel: multiples facteurs, difficilement mesurables.
La qualité du processus (maturité): contrôle, reproductibilité, améliorations.
© Petko Valtchev Université de Montréal Septembre 2004 4
Intro Le début…
Aspects historiques:
La crise du logiciel (“Software Crisis”)
Le logiciel avait tendance à être délivré: Avec des erreurs persistantes En retard par rapport aux plannings A des coûts exorbitants
Quant il était délivré…
1968 Conference d’OTAN, Garmisch (DE)
Formule les questions et les principes fondateurs du domaine Point tournant considéré comme le début de l’époque moderne
dans l’industrie du logiciel (fin de l’artisanat)
3
© Petko Valtchev Université de Montréal Septembre 2004 5
Intro L’essence du logiciel
Cela ne déplairait pas aux vendeurs de logiciel, mais …
… contrairement aux bâtiments, les systèmes (surtout un ) ont:
Une tendance à s’effondrer (à “crash”-er) heureusement, les bâtiments sont relativement stables (de moins enmoins vrai!),
Une ingénierie imparfaite à la livraison l’industrie du bâtiment semble rattraper le pas ici aussi,
Une grande complexité Conséquence : Difficultés de maintenance
Le Génie Logiciel n’est donc pas un Génie ordinaire!
Pourquoi est-ce que les systèmes d’exploitationne peuvent-ils être construits comme on construit
les ponts ou les gratte-ciels?
© Petko Valtchev Université de Montréal Septembre 2004 6
Intro Si Microsoft produisait des chars…
1. À chaque fois qu'on referait la signalétique des routes, il faudraitacheter une nouvelle voiture
2. Occasionnellement, le moteur de votre voiture s'arrêterait alors quevous seriez sur l'autoroute, sans aucune raison.
3. De temps en temps, en faisant une manoeuvre, votre moteurs'arrêterait et ne voudrait plus redémarrer. Il vous faudrait alorsréinstaller le moteur.
4. Vous ne pourriez avoir qu'une seule personne dans la voiture à lafois, à moins d'avoir un modèle 95 ou NT. Mais � ce moment là�, il vousfaudra acheter des sièges supplémentaires.
5. Apple ferait aussi des voitures, qui fonctionneraient � l’énergie solaire,qui seraient plus fiables, plus rapides, et beaucoup plus simples àconduire... Mais uniquement sur 5% des routes.
4
© Petko Valtchev Université de Montréal Septembre 2004 7
Intro Génie Logiciel: Définitions
« Ensemble des connaissances, des procédés et des acquis scientifiqueset techniques mis en application pour la conception, le développement,
la vérification et la documentation de logiciels, dans le but d'en optimaliser la production, le support et la qualité. »
Office de la langue française, 2000
« (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, that is
the application of engineering to software.(2) The study of approaches as in (1). »
IEEE Standards Collection: Software Engineering
Une qui est axée sur les acquis de la discipline :
Une qui est axée sur l’application de ces acquis dans la pratique :
© Petko Valtchev Université de Montréal Septembre 2004 8
Intro
Software Engineering
GL: une technologie par couches
Génie Logiciel
orienté-“qualité”
processus (modèle de cycle de vie)méthodes
outils
[Pressman 2001]
• CASE: TogetherJ,Rrose,• Teamware: CVS• IDE: Eclipse, JBuilder
• OO: OOA&D,• Structuré: SADT,SA&D, Merise
• Classiques: Cascade,RAD, Incrémental, etc.• OO: RUP, XP •Standards: ISO…
• Modèles• Métriques
5
© Petko Valtchev Université de Montréal Septembre 2004 9
Intro Qualité
Qu’est-ce que c’est? (Question ouverte)
Types de facteurs: internes = visibles par les développeurs, mais cachés auxutilisateurs, externes = visibles par les utilisateurs
Quelques critères : Validité, Fiabilité (ou Robustesse), Efficacité Extensibilité, Réutilisabilité, Compatibilité, Portabilité Vérifiabilité, Intégrité Facilité d'emploi
externes ou
internes?
© Petko Valtchev Université de Montréal Septembre 2004 10
Intro Qualité (suite)
Validité : aptitude d'un produit logiciel à remplir exactementses fonctions (définies par le document des spécifications).
Extensibilité : facilité avec laquelle un logiciel se prête à unemodification ou à une extension des fonctions qui lui sontaffectées à l’origine.
Réutilisabilité : aptitude d'un logiciel à être réutilisé, en tout ouen partie, dans de nouvelles applications.
Vérifiabilité : facilité de préparation des procédures de test.
Intégrité : aptitude d'un logiciel à protéger son code et sesdonnées contre des accès non autorisés.
6
© Petko Valtchev Université de Montréal Septembre 2004 11
Intro “Quality is free”
Qualité
Effort(min)
Il ne suffit pas de travailler dur,il faut travailler intelligemment
Quand on travaille trop,la qualité du résultat en souffre.
Une qualité raisonnable peut êtreatteinte à faible coût. Pour plus,
il faut déployer des effortsconsidérables
© Petko Valtchev Université de Montréal Septembre 2004 12
Intro Le Processus
La manière dont nous produisons le logiciel: Le modèle de cycle de vie du logiciel:
Étapes ou phases Activités concrètes Artéfacts produits
Les participants individuels Les outils
Grande variété: Le processus logiciel est différent chez chaque organisation! Dans la littérature: des abstractions
Standards pour l’évaluation:
PMM (SEI)
7
© Petko Valtchev Université de Montréal Septembre 2004 13
Intro
Le processus logicielen tant que résolution de problèmes
La métaphore de la résolution
StatusQuo
définitiondu
problème
Développementtechnique
Intégration de la
solution
© Petko Valtchev Université de Montréal Septembre 2004 14
Intro
Analyse
Conception
Codage
Déploiement
Maintenance
Le modèle en cascade
Modèle obsolète qui a tout de même le mérite de définirles principales étapes du processus logiciel.
8
© Petko Valtchev Université de Montréal Septembre 2004 15
Intro Les étapes
Analyse
Pourquoi : répondre à l'évolution des matériels, des systèmes,des langages de programmation, et surtout la complexité toujourscroissantes des logiciels.
Objectifs
Besoins : Comprendre le problème Spécification : Identifier les caractéristiques requis du
système
La question prédominante: QUOI
© Petko Valtchev Université de Montréal Septembre 2004 16
Intro Les étapes (suite)
Conception
Pourquoi : réduire la complexité du passage entre la description
du problème et sa solution.
Objectif
Traduction progressive des spécifications (Le Problème)
vers une description du système (La Solution) sans pour
autant produire ce système.
La question prédominante: COMMENT
9
© Petko Valtchev Université de Montréal Septembre 2004 17
Intro Modèles Itératifs
Prototyping
Rapid ApplicationDevelopment
© Petko Valtchev Université de Montréal Septembre 2004 18
Intro Le Modèle Incrémental
analysis design code test
System/informationengineering
analysis design code test
analysis design code test
analysis design code test
increment 2
increment 3
increment 4
increment 1
delivery of1st increment
delivery of2nd increment
delivery of3rd increment
delivery of4th increment
temps
10
© Petko Valtchev Université de Montréal Septembre 2004 19
Intro Coût Relatif par Étape
Données de la période 1976–1981
Le coût de la maintenance!
© Petko Valtchev Université de Montréal Septembre 2004 20
Intro Les deux étapes
Analyse et Conception
Pourquoi s’y intéresser plus qu’à la mise au point ou à lamaintenance?
Après tout, la SOLUTION est produite lors de la phasedu codage?
Et tous sont d’accord que c’est la maintenance qui est laplus laborieuse?
11
© Petko Valtchev Université de Montréal Septembre 2004 21
Intro Coût des erreurs
Coût de détection et de correction des erreurs selon les phases
© Petko Valtchev Université de Montréal Septembre 2004 22
Intro Les défauts
60 à 70 % des défauts sont des erreurs de spécificationet de conception
Données de Kelly, Sherif, et Hops [1992]
1.9 erreurs par page de spécification 0.9 erreurs par page de conception 0.3 erreurs par page de code
12
© Petko Valtchev Université de Montréal Septembre 2004 23
Intro Les défauts (suite)
Données de Bhandari et al. [1994]
Erreurs à la fin de la phase de conception d’une nouvelleversion du produit
13% des erreurs provenant de la version précédente duproduit
16% des erreurs provenant des nouvelles spécifications 71% des erreurs provenant de la nouvelle conception
© Petko Valtchev Université de Montréal Septembre 2004 24
Intro En guise de conclusion…
Importance des phases d’Analyse et Conception:
Chacune constitue un modèle du système logiciel, Le système est la solution du problème à résoudre, les
résultats des deux étapes ne sont que des représentations dece système, abstraites et souvent très approximatives.
Principales transformations Conjointement, les deux phases opèrent les principales
transitions d’informations concernant le système.
Difficultés:
faire converger les idées vagues sur le système que lesintéressés ont au début du projet vers un modèle détaillé deconception qui guide le codage.
Primordiales pour l’assurance de la qualité du logiciel