© Petko ValtchevUniversité de Montréal Janvier 2002 1 IFT 2251 Génie Logiciel Le Processus (fin) Hiver 2002 Petko Valtchev

© 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


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


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é)?


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


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.


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.


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








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


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



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.



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


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.


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)








BasesBases Le Modèle en Cascade

analyse conception code test

Ingénierie dusystème

Le modèle classique de développement


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.



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.



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.



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.



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.



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.


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!!!




Modèle en cascade Modèle par prototypage « Rapid Application Development » Modèles évolutifs Modèles avancés


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


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).


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é).


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é.






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 ».


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.


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


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




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


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


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


BasesBases

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


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




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


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


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


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





– Modèle de développement par composants

– Modèles centrés sur des méthodes formelles


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.





– Modèle de développement par composants

– Modèles centrés sur des méthodes formelles


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.

Documents

© Petko ValtchevUniversité de Montréal Janvier 2002 1 IFT 2251 Génie Logiciel Le Processus (fin) Hiver 2002 Petko Valtchev