automne 2004 petko valtchev - université de montréal

12
1 © Petko Valtchev Université de Montréal Septembre 2004 1 IFT 3901 Analyse et Conception des Logiciels Automne 2004 Petko Valtchev © Petko Valtchev Université de Montréal Septembre 2004 2 Analyse et Conception 1. Rappels sur la Qualité et le Processus logiciel

Upload: others

Post on 21-Nov-2021

3 views

Category:

Documents


0 download

TRANSCRIPT

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