Partie 2 Introduction

Méthodologies de conception des SI Auteur: S. SI- SAID CHERFI Maître de conférences- CNAM - PARIS

Bibliographie La méthode MERISE, Principes et outils : H. TARDIEU, A. ROCHFELD, R. COLLETTI. Les éditions d ’organisation, 1979. (à savoir) Ingénierie des systèmes d'information MERISE deuxième génération (4eme édition), D. NANCI, B. ESPINASSE, éditions Vuibert. 2001 (vue complète sur la méthode) Conception des bases de données relationnelles en pratique: Concepts, méthodes et cas corrigés J. AKOKA, I. Comyn-Wattiau. Éditions Vuibert, 2001 (exercices corrigés) Object-Oriented Systems Analysis and Design using UML, S. BENETT, S. McROBB, R. FARMER, éditionsMcGrawwHill, 2001 UML par la pratique P. Roques, (exercices avec corrigés) MSI-B8: 19768

S. SI-SAID CHERFI CNAM-PARIS

1

Copie des transparents de cours 1. Accéder au site du département informatique http://deptinfo.cnam.fr/ 2. Rubriques supports puis chaire Informatique d’entreprise 3. NFE108 MSI-B8: 19768

S. SI-SAID CHERFI CNAM-PARIS

2

1

Méthodologies de conception des SI

Partie I Introduction

MSI-B8: 19768

S. SI-SAID CHERFI CNAM-PARIS

3

Qu’est ce qu’un système d’information? Tout système d’information possède: – une activité humaine nécessitant de l’information – des données stockées – des données en entrée avec un moyen pour les acquérir – un ensemble de processus qui transforment les données – des données en sortie avec un moyen pour les représenter

MSI-B8: 19768

S. SI-SAID CHERFI CNAM-PARIS

4

2

Caractéristiques des systèmes • Un système –est un ensemble d’éléments en interaction dynamique, organisés en fonction d’un but.

• Un système: –a des frontières –est doté d’une structure –fait une ensemble d’activités afin d’atteindre un but –évolue dans un environnement • Un système d’information est un système organisé de ressources, de personnes et de structures qui évolue dans une organisation et dont dont le comportement coordonné vise à atteindre un but commun. • Exemple de systèmes d’information Gestion des réparations dans un garage automobile, Gestion de la scolarité, Gestion des vols dans une compagnie aérienne etc.. MSI-B8: 19768

5

S. SI-SAID CHERFI CNAM-PARIS

Types de SI

• Les systèmes d’information sont sensés aider les utilisateurs dans leurs activités – Stocker et restaurer l’information – Faire des calculs – Aider à communiquer – Ordonnancer et contrôler des tâches – Etc.

MSI-B8: 19768

S. SI-SAID CHERFI CNAM-PARIS

6

3

Types de SI

• Systèmes opérationnels assistent et ou contrôlent l’exécution des opérations de gestion – Un système comptable corrige les erreurs commises par le facturier ou le comptable

• Système de pilotage aide les décideurs dans leurs prises de décision – Un système décisionnel de gestion de places de marché aide les décideurs dans le choix de l’ouverture d’une nouvelle place de marché. MSI-B8: 19768

7

S. SI-SAID CHERFI CNAM-PARIS

Types de SI

• Systèmes temps-réel gèrent essentiellement des dispositifs matériels, souvent dans des domaine de sécurité de fonctionnement – Les centrales nucléaires sont dotés d’un système de control de la température.

MSI-B8: 19768

S. SI-SAID CHERFI CNAM-PARIS

8

4

Où est la difficulté? • Le développement de systèmes, en général et celui des systèmes d'information en particulier est complexe. • Pourquoi? (selon Booch, 1994) 1. Complexité liée au domaine

– complexité des domaines (connaissance et évolution des besoins) – coût de la maintenance des systèmes (problèmes d’interopérabilité générés par l’hétérogénéité des solutions) 2. Complexité du processus de développement

– besoin de gérer des groupes (communication, éloignement géographique et de langue etc.) – besoins de simplifier le processus MSI-B8: 19768

S. SI-SAID CHERFI CNAM-PARIS

9

Où est la difficulté ? (suite)

3. Dangers de la flexibilité le logiciel est flexible et expressif. Il encourage par conséquent l'expression de besoins de plus en plus exigeants, qui conduisent à leur tour à des implémentations complexes et difficiles à évaluer.

4. Difficulté dans la caractérisation des aspect comportementaux Il est plus facile de décrire les aspects statiques d’un systèmes que ses aspects comportementaux. Il faut décrire les états, la séquence de valeurs possibles et les règles qui régissent ces états.

"La tâche de l'équipe de développement est d'organiser l'illusion de la simplicité" [Booch, 94] MSI-B8: 19768

S. SI-SAID CHERFI CNAM-PARIS

10

5

Conséquences

Échec dans la gestion de la complexité

Non respect des contraintes liées au projet de développement : Retard, dépassement des budgets, déficience par rapport aux besoins MSI-B8: 19768

S. SI-SAID CHERFI CNAM-PARIS

11

Conséquences Why Big Software Projects Fail: The 12 Key Questions Watts S. Humphrey, The Software Engineering Institute

In spite of the improvements in software project management over the last several years, software projects still fail distressingly often, and the largest projects fail most often. …. The principal questions concern why large software projects are hard to manage, the kinds of management systems needed, and the actions required to implement such systems.

MSI-B8: 19768

S. SI-SAID CHERFI CNAM-PARIS

12

6

Conséquences

USS London Taurus Denver Ariane E-mail Yorktown buffer 5(1993) baggage Ambulance (1996) overflow (1998) handling System (1998) system (1992)(1992) Mars Climate Orbiter (September 23rd, 1999) The Ariane 5 rocket exploded onsuffer its maiden flight June [4], 1996 because theproject navigation package was A Taurus, The Several crew succession Denver member the E-mail planned airport of systems of software the baggage automated guided-missile engineering handling from transaction a in cruiser "buffer failures, system settlement overflow USS was especially Yorktown so complex error", system in mistakenly when for (involving extremely management, London entered 300 The 125 million dollar Mars Climate Orbiter is assumed lost by officials at the NASA. The inherited from the Ariane 4 without proper testing. The new rocket flew faster, resulting in larger values of a caused Stock computers) long zero e-mail Exchange for 2 failures a data addresses that value, was of loss development London's canceled are which received. resulted (England) after overrun years in Ambulance ainternal prevented division of to failed by the development. zero. airport receiving Thefrom error the Losses opening cascaded are on failure responsible for ofsoftware. the orbiter is5The attributed abuffers failure of NASA’s system some variables in the the navigation Shortly after launch, an attempt to convert a 64-bit floatingengineer process. The process did not specify the system ofadditional measurement to be used and dispatch estimated time.eventually addresses Fixing system. at dothe £75m shut incredibly The check for down repair thefor the project buggy length cost ship's system was and and propulsion £450m estimated allow required their to system. customers. atbuffers an £9m, The but to (Pooley overflow ship itbutisthe 50% believed was &causing ofdead Stevens, the that in on point number into anot 16-bit integer generated an overflow. The error was caught, code that caught it elected to shut down the subsystem. rocket veered off course and exploded. It was unfortunate the project. As a -result, one of theThe development teams used Imperial the people 1999) original the water applications died budget for who several to nearly would crash. hours not $200m. Hostile because have died hackers a ifprogram ambulances use this didn't fault had check toreached trick for measurement valid the them computer as while that other the code that the failed genereated inertial reference information useful only before from lift-off;one had it been the used metric system of measurement. When parameters module input. promptly into a malicious inwould Scientific have program American, done inwithout its place. November the 1998) turnedrunning off(reported at as the they moment of launch, there would have been nofailures. trouble. (Kernighan, 1999) were passed to another during orbit navigation correct, no conversion was performed, resulting in the loss of the craft. http://mars.jpl.nasa.gov/msp98/orbiter/ MSI-B8: 19768

S. SI-SAID CHERFI CNAM-PARIS

13

Conséquences

MSI-B8: 19768

S. SI-SAID CHERFI CNAM-PARIS

14

7

Caractéristiques de la complexité • D ’après Grady Booch 1. La complexité est souvent hiérarchique 2. Le choix des primitives du système est souvent arbitraire (choix de l’architecte système) 3. Les liens intra-composants devraient être plus forts que les liens inter-composants (concept de module) 4. Les systèmes sont souvent issues de combinaisons différentes des mêmes briques de base (patterns récurrents) 5. Tout système devrait être conçu par étape en évoluant du simple vers le complexe (développent incrémental) MSI-B8: 19768

S. SI-SAID CHERFI CNAM-PARIS

15

Développement de systèmes d'information • Le développement de systèmes d'information est:

– Un processus de changement dirigé par un groupe de développeurs qui opère en prenant en compte un système, dans un environnement et ce pour atteindre ou pour maintenir des objectifs fixés par des acteurs

MSI-B8: 19768

S. SI-SAID CHERFI CNAM-PARIS

16

8

Développement et Système

• Le système : l'objet – a des frontières arbitraires fixées par les objectifs et les perspectives – est doté d’une structure composée d'objets et de relations entre ces objets – a des propriétés émergentes et inattendues – peut renfermer des contradictions / des ambiguïtés / des recouvrements MSI-B8: 19768

S. SI-SAID CHERFI CNAM-PARIS

17

Développement et processus de changement • Le processus de changement – agit sur la structure – est dirigé par les objectifs – renferme une dimension sociale – souvent incertain – nécessite des moyens – est spécifique au problème MSI-B8: 19768

S. SI-SAID CHERFI CNAM-PARIS

18

9

Développement et environnement • L'environnement :

• tout ce qui est en dehors de l'objet (le système) et du groupe de développement – est composé de conditions et de facteurs qui ont un impact sur le groupe de développeurs et sur le processus de changement – est constitué d'une multitude de sous environnements: • • • •

économique technique (outils, méthodes et les techniques) légal (législation) humain (acteurs) MSI-B8: 19768

S. SI-SAID CHERFI CNAM-PARIS

19

Développement et développeurs • Les développeurs: – Organisation formelle • rôles • Assignation des tâches • Autorité / responsabilité

– Organisation informelle • rapports de force • relations personnelles • Engagements personnels MSI-B8: 19768

S. SI-SAID CHERFI CNAM-PARIS

20

10

Développement et objectifs

• Les objectifs – implicites / explicites – imposés ou négociés – contradictoires ou complémentaires – conformes à la législation – réalistes / trop ambitieux MSI-B8: 19768

S. SI-SAID CHERFI CNAM-PARIS

21

Développement et acteurs • Les acteurs – internes (utilisateurs, dirigeants, unités organisationnelles) ou externes (clients, instances gouvernementales, associations, éditeurs de logiciels, détenteurs de technologies, etc.) – sont guidés par des intérêts et des objectifs – peuvent être impliqués dans le développements en tant que membres – Peuvent avoir des droits sur le système et ses propriétés.

Le développement est la combinaison de facteurs technologiques, sociaux, psychologiques et culturels MSI-B8: 19768

S. SI-SAID CHERFI CNAM-PARIS

22

11

Comment concevoir un SI • Concevoir un SI revient à: – Résoudre un problème – décomposer le problème – le modéliser

• la modélisation est une activité orientée par le bon sens • Modéliser – abstraire – organiser – « formaliser » MSI-B8: 19768

Besoin de modèles Besoin de méthodes

S. SI-SAID CHERFI CNAM-PARIS

23

Modélisation du processus de développement Les modèles de cycle de vie

• Les modèles de cycle de vie servent à – décrire les activités à effectuer lors du développement d ’un systèmes d’information – prédéfinir l’enchaînements de ces activités

• Ils sont sensés fournir un cadre général pour – comprendre – contrôler et – gérer

le processus de développement MSI-B8: 19768

S. SI-SAID CHERFI CNAM-PARIS

24

12

Exemples de modèles de cycle de vie Le modèle en cascade • Introduit par [Royce, 1970]. Le développement est vu comme un processus séquentiel comprenant les activités suivantes: – – – – –

définition des besoins conception implémentation & tests unitaires vérification exploitation et Maintenance

• Inconvénients : – vision linéaire – pas d ’itération, donc pas de prise en compte du changement – Délai de livraison trop longs MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS

25

Exemples de modèles de cycle de vie Le modèle en spirale et approche incrémentale • Introduit par [Bohem, 1987]. Le développement est vu comme un processus itératif et incrémental. •identifier un problème •définir les besoins associés (req.) •une solution et le risque associé (analyse) •développement et vérification (design & build) •planifier l'étape suivante (plan)

MSI-B8: 19768

S. SI-SAID CHERFI CNAM-PARIS

26

13

Apports de l’approche incrémentale

• Les plus par rapport au modèle en cascade – minimise les risques (en livrant des incrément) – permet la prise en compte de l'évolution des besoins (la livraison des incréments permet de mesurer la satisfaction des utilisateurs et l’adéquation aux besoins)

– plus facile à contrôler (cycles de durée limitée) – peut mieux répondre aux besoins des utilisateurs (architecture modulaire permettant un développement évolutif)

MSI-B8: 19768

S. SI-SAID CHERFI CNAM-PARIS

27

Conclusion sur les modèles de cycle de vie – décrivent les phases du développement à un niveau de détail insuffisant pour guider les développeurs. Ils se focalisent sur l'organisation des activités (contraintes régissant leur exécution) et se soucient peu du produit.

• Les modèles de cycle de vie ne sont que des stratégies d’organisation et de gestion des phases du processus de développement.

MSI-B8: 19768

S. SI-SAID CHERFI CNAM-PARIS

28

14

Méthodes pour le développement de systèmes

• Définition [Booch, 1994] – "…un processus rigoureux permettant de générer un ensemble de modèles et qui décrit divers aspects d'un logiciel en cours de construction en utilisant une certaine notation"

• Objectifs – atteindre les objectifs fixés par les acteurs – aider à la conduite du processus de développement MSI-B8: 19768

S. SI-SAID CHERFI CNAM-PARIS

29

Apport des méthodes au processus de développement • Lorsqu'une méthode est "bien" utilisée, elle: – est un support pour les efforts de standardisation et d'harmonisation du travail de développement et des produits délivrés, – joue le rôle de garant de la qualité du système, – est un support de communication entre les individus, – Améliore le processus de développement des SI • réutilisation, répétition, prédiction et contrôle • adaptation • Diminution de la dépendance envers des personnes clés • facilite le test des systèmes produits MSI-B8: 19768

S. SI-SAID CHERFI CNAM-PARIS

30

15

Exemple de méthodes • Méthodes structurées : SSADM – "Structured System Analysis and Design Method''

• Méthodes systémiques : MERISE

• Méthodes orientées objet : OMT, Processus unifié MSI-B8: 19768

S. SI-SAID CHERFI CNAM-PARIS

31

SSADM : historique • 1980 Central Computer and Telecommunications Agency (CCTA) évalue des méthodes d'analyse et de conception • 1981 LBMS méthode choisie parmi une liste de cinq proposées • 1983 SSADM imposée pour tous les nouveaux développements de SI • 1984 Version 2 de SSADM délivrée • 1989 évolue vers Euromethod, lancement d'outils CASE • 1990 Version 4 lancée • 1995 SSADM V4+ annoncée, V4.2 lancée MSI-B8: 19768

S. SI-SAID CHERFI CNAM-PARIS

32

16

La méthode SSADM : caractéristiques • Adopte le modèle en cascade Analyse: Conception Implémentation & tests unitaires Vérification Exploitation et Maintenance

Analyse des besoins Spécification des besoins Spécification du système logique Spécification du système physique

• Notations • • • • •

Data flow diagrams ER diagrams Data dictionaries Function specifications MSI-B8: 19768 Etc.

S. SI-SAID CHERFI CNAM-PARIS

33

La méthode MERISE : historique • 1976 premières réflexions sur une méthode d'analyse destinée à la conduite des projets du ministère de l'industrie • 1979 naissance de MERISE version 0 • 1982 création de MERISE version 1 en tirant partie des premières années d'expérience • 1985 début des réflexions sur MERISE version 2 • 1991 création de MERISE version 2 • 1991 début des réflexions sur MERISE version 3 – OOM • Mi 1991 début d'utilisation d'OOM MSI-B8: 19768

S. SI-SAID CHERFI CNAM-PARIS

34

17

UML et Processus Unifié : historique

Standardisation par l’OMG 1997, Soumission à l’OMG

OOPSLA’96

OOPSLA’95

UML 1.3 Livres: UML 1.0

Guide de l’utilisateur,Manuel de référence Guide du processus Spécification disponible sur Internet

UML 0.9

Spécification disponible sur Internet

Méthode unifiée 0.8 Booch’93 OMT-2

Autres méthodes

Booch’91 MSI-B8: 19768

OMT-1 Rumbaugh’91

OOSE Jacobson’92

S. SI-SAID CHERFI CNAM-PARIS

Partenaires Rational 35

18