Chapitre 2 –Part I-

INTRODUCTION AU PROCESSUS DE DÉVELOPPEMENT ET À LA

MODÉLISATION
Objectifs

1. Connaître les différents phases de développement d’un logiciel

2. Identifier les différents méthodologies de développement
3. Différencier les méthodes de conception et d’analyse
4. Comprendre le rôle de la modélisation
5. Connaître les différents méthodes d’analyse et de conception orienté objet
Plan

1. Cycle de développement logiciel

2. Approche de génie logiciel
3. Méthode d’analyse et de conception
4. Principaux métiers de développement
5. Méthode d’analyse et de conception orienté objet
La définition de « méthodologie de
développement » ?
Cycle de développement logiciel

Une méthodologie de développement, appelée aussi procédé logiciel

(software process) est un ensemble d’activités conduisant à la
production d’un logiciel

Méthodologie de développement= Cycle de vie d’un logiciel

Cycle de développement logiciel

Cycle de vie d’un logiciel

Un cycle de vie d’un projet informatique est l’ensemble de phases qui

se déroulent depuis le moment où le client commande l’application
auprès d’un fournisseur jusqu’à la livraison et l’exploitation de la
solution (l’application) par les utilisateurs.
Cycle de développement logiciel

Cycle de vie logiciel

Un cycle de vie de développement logiciel est constitué généralement des phases
suivantes:

Expression des
besoins et capture Analyse Conception
des exigences

Réalisation Tests et validation Maintenance

Cycle de développement logiciel
Phase d’expression et de présentation des besoins

Étude de besoin: le client exprime ses besoins de façon plus ou moins complète
auprès d’un informaticien,
L’informaticien ensuite ferra une représentation sous forme de spécifications en
utilisant divers outils de représentation.

Remarque. Le client n’est pas forcement le futur utilisateur de l’application.

Cycle de développement logiciel

Phase d’analyse

 Consiste en la construction d’un modèle du monde réel (le modèle

d’analyse), met en évidence les propriétés importantes du problème.
 Est une abstraction précise et concise du but de l’application et non de la
façon dont elle sera implémentée.
 Les objets du modèle d’analyse doivent être les concepts du domaine
d’application et non des objets informatiques tels que: tables, fichiers,
fenêtres, …
Cycle de développement logiciel

Phase d’analyse (suite)

Le modèle d’analyse doit permettre de:
 structurer les idées (comprendre le problème)
 Simuler le fonctionnement réel (maîtriser la complexité)
 Introduire la phase de conception (trace des décisions de spécifications)
 Communiquer avec le client pour valider les spécifications (accord sur le quoi?)
 Communiquer entre informaticiens (équipes d’analyse et équipe de développement)

C’est un modèle de comportement du système à réaliser

Cycle de développement logiciel

Phase de conception
 Définit l’architecture globale du système à mettre en œuvre
 Le système est découpé en sous-système ou domaines techniques fondés sur le
modèle d’analyse et sur l’architecture proposée pour le logiciel
 Fournit un support à l’implémentation physique du système et doit traduire la
solution dans une architecture réalisable en termes de domaines techniques
Cycle de développement logiciel

Phase de conception (suite)

Quatre catégories de domaines techniques apparaissent:

 Domaine fonctionnel. Fonctions réalisées par l’application

 Domaine de services. IHM, gestion des impressions, droits d’accès, …
 Domaine d’architecture. Mécanismes et composants architecturaux (comme la
structure des données, timers, …)
 Domaine d’implémentation. Système d’exploitation, langage de programmation,
base de données, ..
Cycle de développement logiciel

Phase de développement

 Concerne l’écriture des programmes avec un langage de programmation déterminé

lors de la phase de conception

 Saisie initiale des données contenues dans les fichiers ou la base de données

 Mise en place des outils et protocoles de communication sur le réseau

Cycle de développement logiciel

Phase de test et de validation

 Permet de valider le fonctionnement de traitements en vérifiant l’exactitude

de tous les résultats produits en fonction des entrés
 Permet de valider aussi la logique de l’application à travers son IHM, en
fonction des anomalies constatées dans le programme et des remarques
faites par les utilisateurs
 Différentes corrections peuvent être apportées pouvant aller jusqu’à la
reprise d’une partie des phases précédentes (analyse , conception, …)
Cycle de développement logiciel
Phase de maintenance
 Elle est semblable à la phase de tests et de validation
 La différence est dans la durée.
 La durée de la phase de maintenance est égale à la durée de vie de l’application.
Les modifications apportées aux programmes peuvent être:
▶ Modifications correctives consistent à corriger les nombreux bogues
▶ modifications évolutives se produisant lors de modifications de l'environnement fonctionnel tel
qu'un changement des besoins des utilisateurs, un changement de structure de l'organisation
ou des méthodes de gestion.
▶ Refactoring est un terme anglais sous lequel sont regroupées les évolutions sans modifications
des fonctionnalités.
Questions

Dans quelle phase les spécifications de l’application sont définis ?

Quel est l’objectif de la phase d’analyse ?

Approche de génie logiciel

Génie logiciel

Le génie logiciel (anglais software engineering) est une science de génie industriel
qui étudie les méthodes de travail et les bonnes pratiques des ingénieurs qui
développent des logiciels.
Le génie logiciel s'intéresse en particulier aux procédures systématiques qui
permettent d'arriver à ce que des logiciels de grande taille correspondent aux
attentes du client, soient fiables, aient un coût d'entretien réduit et de bonnes
performances tout en respectant les délais et les coûts de construction [ref.1]
Approche de génie logiciel

Approche de génie logiciel

C’est la manière utilisée pour mettre en œuvre les différents phases du cycle de vie.
Il existe plusieurs approches, les principaux sont:
 Approche en cascade
 Approche en V
 Approche en Spirale
Approche de génie logiciel

Approche en cascade
Approche de génie logiciel

Approche en cascade

 Un ensemble d’étapes (phases) séquentielles

 Chaque étape porte sur la totalité du système
 L'utilisateur ne découvre l'application qu'en tout dernier lieu
 L'utilisateur n'intervient pas dans le processus de conception
Approche de génie logiciel

Approche en cascade (les risques)

 Augmentation des coûts de correction des erreurs croît avec le temps

 La découverte d'une erreur d'analyse ou de conception lors des tests utilisateurs,
peut entraîner l'abandon pur et simple du projet compte tenu du coût prohibitif
de la rectification.
Approche de génie logiciel

Approche en cascade
Quels sont les avantages de l’approche en cascade ?
Approche de génie logiciel

Approche en cascade
Quels sont les avantages de l’approche en cascade ?

▶ Facile à utiliser et à comprendre

▶ Un procédé structuré pour une équipe inexpérimentée
▶ Idéal pour la gestion et le suivi de projets
▶ Fonctionne très bien quand la qualité est plus importante que les coûts et les
délais
Approche de génie logiciel

Approche en V
Approche de génie logiciel

Approche en V
 Système est découpé en différents sous-systèmes conçus, développés et testés
de façon indépendante.
 Les tests réalisés sur les sous-systèmes sont faits par les programmeurs.
 Comme pour l'approche en cascade, l'utilisateur n'intervient pas dans le
processus de conception et ne valide l'application qu'à la fin lorsque le logiciel
complet lui est livré.
 La prise de risque est donc identique à celle de l'approche en cascade.
Approche de génie logiciel

Approche en V
Quels sont les avantages de l’approche en V ?
Approche de génie logiciel

Approche en V
Quels sont les avantages de l’approche en V ?

▶ Met l’accent sur tests et la validation et par conséquent, ça accroît la qualité du

logiciel
▶ Facile à planifier dans une gestion de projets
▶ Facile à utiliser
Approche de génie logiciel

Approche en Spirale
Approche de génie logiciel

Approche en Spirale
 L'application est conçue et développée par prototypages successifs en incluant
dans chaque nouveau prototype des fonctions supplémentaires.
 L'utilisateur valide chaque prototype au fur et à mesure de son codage.
 Le nouveau prototype est construit en intégrant les précédents.
 Lorsque toutes les fonctions demandées ont été intégrées et que l'utilisateur est
entièrement satisfait du dernier prototype celui-ci devient l'application mise en
exploitation
 La prise de risque est alors limitée à la mise au point d'un seul prototype.
Approche de génie logiciel

Approche en Spirale
Quels sont les avantages et les inconvénients de l’approche spirale ?
Approche de génie logiciel

Approche en Spirale (avantages)

▶ Identification rapide des risques

▶ Impacts minimaux des risques sur le projet
▶ Fonctions critiques développées en premier
▶ Feedback rapide du client
▶ Une évaluation continue du procédé
Approche de génie logiciel

Approche en Spirale (inconvénients)

▶ L’évaluation des risques peut prendre beaucoup de temps

▶ Le modèle est très complexe
▶ Les développeurs doivent être réaffectés pendant les phases de non-
développement
Méthodes d’analyse et de conception

On peut distinguer 4 catégories des méthodes d’analyse et de conception des

applications:

 Méthodes descendantes
 Méthodes ascendantes
 Méthodes orientées objets
 Méthodes agiles
Méthodes d’analyse et de conception

Méthodes ascendantes
Méthodes d’analyse et de conception

Méthodes ascendantes
Méthodes les plus anciennes. Exemple: méthode de Blanpré (60-70).
 commencer par les résultats externes demandés par les utilisateurs.
 puis à remonter de manière logique pour trouver les traitements permettant de les
obtenir.
 enfin à remonter à nouveau pour découvrir les données d'entrée nécessaires et
suffisantes pour l'exécution de ces traitements (données saisies et données
enregistrées).
 La seule approche possible pour ce type de méthode est l'approche en cascade.
Méthodes d’analyse et de conception

Méthodes descendantes
(ou symétriques)
Méthodes d’analyse et de conception

Méthodes descendantes (ou symétriques)

 La méthode la plus connue dans cette catégorie est MERISE
 Le point de départ est la structure de l'entreprise considérée comme un système
(système organisationnel).
 A partir de la structure existante, on construit un modèle de données (le MCD :
Modèle Conceptuel des Données de la méthode MERISE par exemple)
 A partir de la base de données ainsi constituée et des besoins des utilisateurs, on
construit les traitements.
 on peut utiliser aussi bien l'approche en cascade que l'approche en V.
Méthodes d’analyse et de conception

Méthodes descendantes – inconvénients-

 Pour bien connaître la structure de l'entreprise, il est nécessaire de procéder à

des interviews d'utilisateurs qui décrivent souvent leurs problèmes en terme de
résultats informatiques à produire;
 Les données et les traitements sont définis de façon complètement séparée
(indépendance données-traitements), ce qui rend très difficile la réutilisation de
modules de programmes et nuit à la productivité des développeurs.
Méthodes d’analyse et de conception

Méthodes orientées objets

Exemple: OOA (Shlaer et Mellor), OOD (Booch), OMT, RUP, UP, MACAO
 Permettre une structuration des programmes en classes d'objets regroupant
données et traitements,
 la structuration des programmes en classes permet une modularité facilitant la
réutilisation et la maintenance.
 La mise en œuvre des méthodes orientées-objets peut être réalisée en utilisant
l'une des trois approches (cascade, V ou spirale). Cependant, l'approche en
spirale est la plus appropriée.
Méthodes d’analyse et de conception

Méthodes Agiles
Exemple: XP, Scrum, RAD
Parmi les méthodes les plus récentes
Elle se base sur les principes de développement d’application Agiles:
 Le logiciel est livré tôt et continuellement à travers le processus de développement, satisfaisant le
client.
 Les changements d’exigences sont adoptées indépendamment du moment où elles se produisent dans
le processus de développement.
 La partie du logiciel terminée est livrée fréquemment au client.
 Les clients et les développeurs travaillent ensemble pour résoudre le problème de l'entreprise.
Méthodes d’analyse et de conception

Méthodes Agiles (suite -1-)

 Les individus motivés créent des solutions; leur fournir les outils et l'environnement
dont ils ont besoin et leur faire confiance.
 La communication en face à face au sein de l'équipe de développement est la
méthode la plus efficace de collecte des besoins.
 La principale mesure du progrès est le travail, l'exécution de logiciels.
 Les clients et les développeurs doivent travailler à un rythme qui soit durable.
Autrement dit, le niveau de travail pourrait être maintenu indéfiniment sans
épuisement des travailleurs.
 L'agilité est renforcée par l'attention portée à l'excellence technique et au bon design.
Méthodes d’analyse et de conception

Méthodes Agiles (suite -2-)

 La simplicité et éviter le travail inutile sont essentiel.
 Les équipes auto-organisatrices développent les meilleures architectures, exigences
et conceptions.
 Les équipes de développement réfléchissent régulièrement à la manière d'améliorer
leurs processus de développement.

Ces méthodes sont basées essentiellement sur la réalisation de prototypes de plus

en plus complets (approche en spirale)
Choisir la méthodologie

Il n’existe pas une méthode qui est meilleur pour tous les projets informatiques.
Critères de sélection
 Clarté des exigences de l'utilisateur
 Familiarité avec la technologie
 Complexité du système
 Fiabilité du système
 Planification courtes
 Visibilité sur la planification
Choisir la méthodologie
Méthodes Méthodes Méthodes orientées Méthodes Agiles
ascendantes descendantes objets
Clarté des exigences
de l'utilisateur
Familiarité avec la
technologie
Complexité du
système
Fiabilité du système
Planification courtes

Visibilité sur la
planification

Pauvre; Bonne; Excellente

Choisir la méthodologie
Méthodes Méthodes Méthodes orientées Méthodes Agiles
ascendantes descendantes objets
Clarté des exigences Pauvre Pauvre Excellente Excellente
de l'utilisateur
Familiarité avec la Pauvre Pauvre Bonne Excellente
technologie
Complexité du Bonne Bonne Excellente Excellente
système
Fiabilité du système Bonne Bonne Excellente Excellente

Planification courtes Pauvre Pauvre Bonne Excellente

Visibilité sur la Pauvre Pauvre bonne Excellente

planification
Principaux métiers de développement

Chef de
Analyste Architecte Développeur Testeur
Projet

Étude du métier Conception Programmation Tests Affectation

Analyse des Architecture du Coordination
besoins système

Documents Conception Programme Plan de tests Planning

Modèles générale
Conception
détaillée
(diagramme de
classe)
Métiers et phases de développement

1. Chef de projet a. Phase d’expression des besoins et

2. Architecte
capture des exigences
3. Testeur
b. Phase d’analyse
4. Développeur
c. Phase de conception
5. Analyste
d. Phase de réalisation
e. Phase de test et de validation
Métiers et phases de développement

1. Chef de projet a. Phase d’expression des besoins et

2. Architecte
capture des exigences
3. Testeur
b. Phase d’analyse
4. Développeur
c. Phase de conception
5. Analyste
d. Phase de réalisation
e. Phase de test et de validation
Next ?
MÉTHODES D’ANALYSE ET DE CONCEPTION ORIENTÉ OBJET
Références

▶ Marylène Micheloud et Medard Rieder, Programmation orientée objets en C++:

Une approche évolutive, PPUR presses polytechniques, 2002, (ISBN
9782880745042)
▶ Thèse de Ferry Nicolas « Formalisation des modèles de la méthode MACAO et
réalisation d’un outil de génie logiciel pour la création d’interfaces homme-
machine. » Université Paul Sabatier - Toulouse III, 2008
▶ Dennis, wixom, tegarden, « Systems analysis & design: an object oriented
approch with UML » 5th édition