Vous êtes sur la page 1sur 620

SPECIFICATION ET CONCEPTION

DES

SYSTEMES

UNE METHODOLOGIE :

M C S E

Ouvrage publié par Masson en 1990 actuellement épuisé

JEAN PAUL CALVEZ

jean-paul.calvez@polytech.univ-nantes.fr

Polytech’Nantes Rue Christian Pauc BP 50609 44306 NANTES Cedex 03

Cet ouvrage a été élaboré dans le cadre du contrat COMETT 89R/88/3/1724/C-1 "outils de formation industrielle à la conception de systèmes électroniques".

L’auteur remercie toutes les personnes ayant participé à ce contrat, notamment:

- Y. THOMAS

- B. REMAUD

- R. MARTINS

Directeur de l’IRESTE de NANTES,

Professeur IRESTE NANTES,

Professeur Faculté des Sciences & Technologies

UNIVERSIDAD NOVA, LISBONNE,

- G. OJEA

- M. BETHENOD

- F. CARSTEN

- P. GOLBERG

- D.M. NUNES

- M. GARCIA NORIEGA

- M.F. SANCHEZ-REFUSTA Directeur FICYT, OVIEDO,

Professeur ETSII Université d’OVIEDO,

Directeur MATRA MHS NANTES,

Ingénieur Société ERNITEC, COPENHAGUE,

Directeur financier Société SFERE, PARIS,

Ingénieur Société EID, LISBONNE,

Directeur Société SRI, OVIEDO,

NOTA

L’auteur a écrit un second ouvrage dans la même collection intitulé : "Spécification et conception des systèmes. Des études de cas". 270 p. Cet ouvrage est un recueil de 13 problèmes avec pour chacun une description complète de la solution. Il est voulu didactique. Ainsi le concepteur peut plus facilement apprendre, comprendre et assimiler MCSE par des exemples, et ceci en concevant le système qu’il désire par analogie avec un des problèmes proposés. Ce livre est un complément indispensable au présent ouvrage.

Le présent ouvrage est aussi publié en version anglaise sous le titre " Embedded Real- Time Systems. A Specification and Design Methodology". 630 p. John WILEY and Sons limited, 1992.

TABLE DES MATIERES

AVANT-PROPOS

1

Partie 1 : PRESENTATION DE LA METHODOLOGIE

Ch 1 - INTRODUCTION

1.1. LES OBJECTIFS POUR UN DEVELOPPEMENT

6

1.2. LES DIFFICULTES DU METIER DE CONCEPTEUR

6

1.3. INTERETS D’UNE METHODOLOGIE

8

1.4. GENESE DE LA METHODOLOGIE MCSE

9

1.5. OBJECTIF DE CE DOCUMENT

10

Ch 2 - CARACTERISTIQUES DES SYSTEMES

2.1. EVOLUTION DES TECHNIQUES ET DES MOYENS DE REALISATION

13

2.2. LE DOMAINE DE L’INFORMATIQUE INDUSTRIELLE

14

2.3. LES SYSTEMES DEDIES

16

2.4. LES SYSTEMES TEMPS-REEL

16

2.5. QUALITES D’UN SYSTEME

18

2.6. CATEGORIES DE SYSTEMES

18

Ch 3 - CYCLE DE DEVELOPPEMENT D’UN SYSTEME

3.1. CONTEXTE D’UN DEVELOPPEMENT

22

3.2. LES PHASES D’UN DEVELOPPEMENT

24

3.3. MODELES DE CYCLE DE VIE

26

3.3.1. Le Modèle "Waterfall"

26

3.3.2. Le cycle en V

27

3.3.3. Le Modèle "Spirale"

28

3.3.4. Le modèle "Contractuel"

29

3.4. QUELQUES CONSTATATIONS

30

3.4.1. Recouvrement des phases

30

3.4.2. Coût de correction des erreurs

31

3.4.3. Facteurs de Productivité

31

3.4.4. Répartition de l'effort

32

SPECIFICATION ET CONCEPTION DES SYSTEMES

3.5. DEVELOPPEMENT POUR UN SYSTEME ELECTRONIQUE

33

3.6. DOMAINE DE MCSE

35

Ch 4 - BASES POUR UNE METHODOLOGIE

4.1.

TERMINOLOGIE

37

4.1.1. Problème: définition, résolution

37

4.1.2. Modèle et modélisation

38

4.1.3. Méthode et méthodologie

38

4.2.

CARACTERISATION DU TRAVAIL DE CONCEPTION

38

4.2.1. La Conception: une activité humaine

38

4.2.2. Le processus de conception

40

4.2.3. Raffinement et abstraction

41

4.3.

CARACTERISTIQUES D’UNE METHODOLOGIE

42

4.3.1. Modèle de description

42

4.3.2. Méthode et technique pour chaque étape

43

4.3.3. Modèles de solutions

43

Ch 5 - PRESENTATION DE MCSE

5.1. DEVELOPPEMENT DE LA METHODOLOGIE

45

5.2. LE MODELE DE DESCRIPTION

47

 

5.2.1. Le Modèle fonctionnel

49

5.2.2. Le modèle comportemental

50

5.2.3. Le modèle exécutif

51

5.2.4. Intérêt de cette modélisation

52

5.3. LA DEMARCHE

53

 

5.3.1. Elaboration des spécifications

54

5.3.2. Conception fonctionnelle

55

5.3.3. Définition de la réalisation

55

5.3.4. Réalisation

56

5.4. CARACTERISTIQUES DE MCSE

56

Ch 6 - UN EXEMPLE D’ILLUSTRATION

6.1. CAHIER DES CHARGES

62

 

6.1.1. Contrôle du régime de croisière

62

6.1.2. Suivi de la vitesse moyenne

63

6.1.3. Suivi de la consommation de carburant

63

6.1.4. Maintenance

63

6.1.5. Caractéristiques complémentaires

63

6.2. SPECIFICATIONS

64

 

6.2.1. Modélisation de l'environnement

64

6.2.2. Spécifications fonctionnelles

66

6.2.3. Spécifications opératoires et technologiques

69

6.3. CONCEPTION FONCTIONNELLE

71

 

6.3.1. Délimitation du système

71

6.3.2. Première structure fonctionnelle

72

6.3.3. Raffinement

74

6.3.4. Comportement de contrôle vitesse

75

6.3.5. Comportement de supervision

77

6.3.6. Comportement de maintenance

78

6.3.7. Comportement de génération_temps

79

6.4. DEFINITION DE LA REALISATION

80

 

6.4.1. Introduction des interfaces

80

6.4.2. Analyse des contraintes de temps

84

UNE METHODOLOGIE

6.4.3. Répartition matériel/logiciel

85

6.4.4. Spécification de l'implantation logicielle

85

6.4.5. Spécification de la réalisation matérielle

87

6.5.

CONCLUSIONS : QUELQUES REMARQUES

88

BIBLIOGRAPHIE 1

89

 

Partie 2 : MODELES ET METHODOLOGIES

Ch 7 - PANORAMA DES METHODOLOGIES

 

7.1. CLASSIFICATION DES METHODOLOGIES ET HISTORIQUE

96

7.2. SADT

98

7.2.1.

Le modèle

98

7.2.2.

La méthode

100

7.3. STRUCTURED ANALYSIS

101

7.3.1. Le modèle

101

7.3.2. La méthode

102

7.4. STRUCTURED DESIGN

103

7.4.1. Le modèle

104

7.4.2. La méthode

104

7.4.3. Remarques

106

7.5. METHODOLOGIE DE JACKSON (JSD)

106

7.5.1. Les modèles

107

7.5.2. La démarche

109

7.5.3. Remarques

112

7.6. SREM

113

7.6.1. Le modèle

113

7.6.2. La méthode SREM pour la spécification

114

7.6.3. La méthode SYSREM pour la conception

115

7.6.4. Remarques

116

7.7. METHODOLOGIE DE WARD ET MELLOR (SDRTS OU RTSA)

117

7.7.1. Le modèle

117

7.7.2. La démarche

118

7.8. METHODOLOGIE de HATLEY et PIRBHAI

121

7.8.1. Le modèle

121

7.8.2. La démarche

123

7.9. METHODOLOGIE DE LAVI ET HAREL (STATEMATE COMME OUTIL)

124

7.9.1. Le modèle ECS (Embedded Computer Systems)

124

7.9.2. La démarche

126

7.9.3. Remarques

127

7.10.

DARTS (DESIGN APPROACH FOR REAL-TIME SYSTEMS)

127

7.10.1. Le modèle pour DARTS

127

7.10.2. La démarche

127

7.11.

CONCEPTION ORIENTEE OBJET (O.O.D)

128

7.11.1. Le modèle objet

129

7.11.2. Démarche pour la conception

130

7.12.

SYSTEM DESIGN WITH MACHINE CHARTS

133

7.12.1. Le modèle

133

7.12.2. La méthode

134

7.12.3. Remarques

135

SPECIFICATION ET CONCEPTION DES SYSTEMES

7.13. METHODOLOGIE DE NIELSEN ET SHUMATE

137

7.13.1. Modèles

137

 

7.13.2. Démarche

138

7.13.3. Remarques

138

7.14.

BILAN

 

139

Ch 8 - PANORAMA DES MODELES

8.1. BASES POUR L’ANALYSE DES MODELES

142

 

8.1.1. Qualités des modèles

142

8.1.2. Classification des modèles

142

8.1.3. Modèles analytiques

143

8.1.4. Modèles conceptuels

143

8.2. OBJECTIFS DES MODELES POUR LES SYSTEMES

145

 

8.2.1. Modélisation pour les spécifications

145

8.2.2. Modélisation en conception

147

8.3. PANORAMA DES MODELES

148

 

8.3.1. Modèle pour les activités

148

8.3.2. Modèles pour les données

148

8.3.3. Modèles pour les fonctions

149

8.3.4. Modèles pour le comportement

151

8.4. CONCLUSION: LES MODELES DE MCSE

155

BIBLIOGRAPHIE 2

159

 

Partie 3 : SPECIFICATION D’UN SYSTEME

Ch 9 - LE CAHIER DES CHARGES

 

9.1.

LE DEMANDEUR : SOURCE DU BESOIN

168

9.2.

LE CONCEPTEUR: EXPERT DU DOMAINE DE REALISATION

168

9.3.

LE CAHIER DES CHARGES: EXPRESSION DU BESOIN

168

9.4.

SOUHAIT DU DEMANDEUR

169

9.5.

BUT ET IMPLICATION DU CAHIER DES CHARGES

169

9.6.

CONTENU ET GUIDE POUR LE CAHIER DES CHARGES

170

9.7.

REPONSE A UN CAHIER DES CHARGES

172

9.8.

EXEMPLES DE PROBLEMES

172

9.8.1. Système de contrôle en vitessse d'un centrifugeur

173

9.8.2.

Automatisation par chariot filoguidé

174

9.9.

RESUME

176

Ch 10 - OBJECTIF D’UNE SPECIFICATION

10.1. ROLE D'UNE SPECIFICATION

178

 

10.1.1. Distance entre client et concepteur

178

10.1.2. Diversité des partenaires côté client

178

10.1.3. Importance d'une vérification

179

10.1.4. Une spécification comme document formel vérifiable

180

10.2. NATURE D'UNE SPECIFICATION

182

10.3. CARACTERISTIQUES D'UNE SPECIFICATION

182

10.4. GRANDES LIGNES DU CONTENU D'UNE SPECIFICATION

184

10.5. DIFFICULTES DU TRAVAIL DE SPECIFICATION

185

10.6. COMPETENCES POUR SPECIFIER

185

10.7. RESUME

 

186

UNE METHODOLOGIE

Ch 11 - BASES POUR LA MODELISATION

11.1.

QUE FAUT-IL CARACTERISER?

188

11.2.

NATURE DE LA CARACTERISATION : MODELISATION

190

11.3.

CARACTERISATION D’UNE ENTITE

190

11.3.1. Nature d'une entité

190

11.3.2. Nature des éléments caractéristiques

191

11.3.3. Dépendance entre éléments caractéristiques

192

11.3.4. Nature des entrées et des sorties

193

11.4.

TROIS VUES POUR LA DESCRIPTION D’UNE ENTITE

193

11.5.

MODELISATION PAR LES DONNEES/INFORMATIONS

194

11.5.1. Modélisation selon 2 niveaux

195

11.5.2. Modèle pour la description des entités donnée

196

11.5.3. Modèle pour la description des relations

198

11.5.4. Modélisation par les données

199

11.6.

MODELISATION PAR LE COMPORTEMENT

200

11.6.1. Les différents modèles à états discrets

201

11.6.2. Modélisation par les états

203

11.6.3. Modélisation stimuli/réponse

204

11.6.4. Règles préconisées pour le modèle de comportement à états discrets

205

11.7.

MODELISATION PAR LES ACTIVITES

207

11.8.

GUIDE POUR LA MODELISATION

211

11.9.

RESUME

213

Ch 12 - DEMARCHE POUR LA SPECIFICATION

12.1. LES CONSTITUANTS D'UNE SPECIFICATION

216

12.2. PRESENTATION DE LA DEMARCHE

217

12.3. ANALYSE ET MODELISATION DE L'ENVIRONNEMENT

219

 

12.3.1. Modélisation de chaque entité

219

12.3.2. Description fonctionnelle de l'environnement

222

12.4. DELIMITATION DES ENTREES ET SORTIES DU SYSTEME

223

12.5. EXEMPLE : CONTROLE EN VITESSE D’UN CENTRIFUGEUR

224

12.6. SPECIFICATIONS FONCTIONNELLES

226

 

12.6.1. Nature des spécifications fonctionnelles

226

12.6.2. Approches pour élaborer une spécification fonctionnelle

227

12.6.3. Méthode pour élaborer les spécifications fonctionnelles

232

12.6.4. Exemples

234

12.7. SPECIFICATIONS OPERATOIRES

235

12.8. SPECIFICATIONS TECHNOLOGIQUES

236

12.9. PROCEDURES D’INSTALLATION ET D’EXPLOITATION

239

12.10.

EXEMPLE 2: AUTOMATISATION PAR CHARIOT FILOGUIDE

239

12.10.1. Modélisation de l'environnement

240

12.10.2. Spécifications du système

241

12.11.

VERIFICATION, VALIDATION DES SPECIFICATIONS

244

12.11.1. Les participants

244

12.11.2. Planification du travail et des revues

244

12.12. CARACTERISTIQUES DE LA SPECIFICATION

245

12.13. RESUME

246

BIBLIOGRAPHIE 3

247

SPECIFICATION ET CONCEPTION DES SYSTEMES

Partie 4 : CONCEPTION FONCTIONNELLE

Ch 13 - LE MODELE FONCTIONNEL

13.1.

LES CONSTITUANTS DU MODELE FONCTIONNEL

254

13.2.

LE MODELE DE STRUCTURE FONCTIONNELLE

255

13.2.1. Représentation graphique

255

13.2.2. Cohérence et lisibilité d'une S.F.

256

13.2.3. Interprétation d'une S.F.

258

13.2.4. Raffinement et abstraction d'une S.F.

261

13.2.5. Décomposition maximale: fonctions élémentaires ou actions

263

13.2.6. Règles de comportement pour une fonction élémentaire

263

13.2.7. Propriétés d'une structure fonctionnelle

265

13.3.

SPECIFICATION DES FONCTIONS ELEMENTAIRES

266

13.3.1. Objectifs de la spécification

267

13.3.2. Choix du langage de description

267

13.3.3. Le modèle de description

269

13.3.4. Interprétation du modèle

273

13.4.

SPECIFICATION DES DONNEES

274

13.4.1. Objectifs de la spécification des données

274

13.4.2. Modèle de description

275

13.4.3. Catégories de données: les structures

276

13.4.4. Décomposition d'une donnée: minimisation et normalisation

278

13.4.5. Utilisation des données

279

13.5.

PROPRIETES GLOBALES DU MODELE FONCTIONNEL

280

13.6.

RESUME

282

Ch 14 - PRINCIPES EN CONCEPTION

14.1. CONCEPTION ORIENTEE SUJET

284

14.2. CONCEPTION INDEPENDANTE DE LA TECHNOLOGIE

285

 

14.2.1. Fonctions d'interfaçage avec l'environnement physique

286

14.2.2. Fonctions de dialogue homme/machine

287

14.2.3. Répartition géographique

287

14.2.4. Maintenance, sûreté de fonctionnement

288

14.2.5. Importance des catégories de spécification

289

14.3. COMPLEXITE MINIMALE ET INDEPENDANCE

290

 

14.3.1. Orthogonalité ou cohérence des fonctions

290

14.3.2. Réduction des couplages

291

14.4. DEMARCHE POUR LA DEDUCTION D'UNE SOLUTION

291

 

14.4.1. Analyse plutôt qu'intuition

291

14.4.2. Approche par les données plutôt que par les fonctions

292

14.4.3. Raffinement plutôt qu'abstraction

293

14.5. DECOMPOSITION VERTICALE OU HORIZONTALE

294

14.6. MODELES GENERIQUES DE SOLUTIONS

295

14.7. RESUME

296

Ch 15 - DEMARCHE POUR LA CONCEPTION FONCTIONNELLE

15.1. PRESENTATION DE LA DEMARCHE

300

15.2. DOCUMENTS EN ENTREE ET EN SORTIE DE L'ETAPE

302

 

15.2.1. Document de spécification

302

15.2.2. Document de conception

302

15.3. DELIMITATION DES ENTREES ET SORTIES

303

 

15.3.1. Démarche

303

15.3.2. Exemple 1: Contrôle en vitesse d'un centrifugeur

304

UNE METHODOLOGIE

15.3.3. Exemple 2: Automatisation par chariot filoguidé

305

15.4. RECHERCHE D’UNE PREMIERE DECOMPOSITION FONCTIONNELLE

307

15.4.1. Importance de la première décomposition fonctionnelle

307

15.4.2. Démarche pour élaborer une solution

308

15.4.3. Exemple 1: contrôle en vitesse d’un centrifugeur

310

15.4.4. Exemple 2: Automatisation par chariot filoguidé

311

15.5. RAFFINEMENT FONCTIONNEL

312

15.5.1. Critère d'arrêt pour le raffinement

312

15.5.2. Déroulement du raffinement

313

15.5.3. Exemple 1: contrôle en vitesse d’un centrifugeur

313

15.5.4. Exemple 2: Automatisation par chariot filoguidé

314

15.6. COMPORTEMENT DES FONCTIONS ELEMENTAIRES

315

15.6.1. Méthode pour l'obtention d'une description algorithmique

316

15.6.2. Exemple 1: Contrôle en vitesse d’un centrifugeur

316

15.6.3. Exemple 2: Automatisation par chariot filoguidé

319

15.7. DESCRIPTION DES DONNEES

321

15.7.1. Méthode pour décrire les données

322

15.7.2. Illustration par un exemple

323

15.8. CRITERES D'EVALUATION D’UNE SOLUTION

325

15.8.1. Analyse du couplage

325

15.8.2. Analyse de la cohérence

326

15.8.3. Analyse de la complexité

326

15.8.4. Lisibilité d'une solution

326

15.9. DOCUMENTATION

327

15.10. RESUME

327

Ch 16 - MODELES GENERIQUES DE SOLUTIONS

16.1. ROLE ET APPORT D'UN MODELE GENERIQUE

330

16.2. MODELE CONTROLEUR/PROCEDE COMMANDE

330

16.2.1. Principe

330

16.2.2. Le modèle

331

16.2.3. La méthode

332

16.2.4. Exemple

332

16.3. MODELE SUPERVISION/CONTROLE-COMMANDE

334

16.3.1. Principe

334

16.3.2. Le modèle

335

16.3.3. La méthode

335

16.3.4. Exemples

336

16.4. MODELE CLIENT/SERVEUR

336

16.4.1. Principe

336

16.4.2. Le modèle

337

16.4.3. La méthode

338

16.4.4. Exemple: transmission de message par liaison série

339

16.5. MODELE D'INTERACTIVITE

340

16.5.1. Principe

340

16.5.2. Le modèle

341

16.5.3. La méthode

342

16.5.4. Exemple

342

16.5.5. Généralisation du modèle au cas multi-fenêtres

344

16.6. RESUME

344

BIBLIOGRAPHIE 4

347

SPECIFICATION ET CONCEPTION DES SYSTEMES

Partie 5 : DEFINITION DE LA REALISATION

Ch 17 - LE MODELE D’EXECUTION

17.1. CARACTERISTIQUES DU MODELE D’EXECUTION

352

17.1.1. Le modèle d'exécution et ses constituants

352

17.1.2.

Signification des éléments et des relations

353

17.2. LE MODELE DE STRUCTURE D'EXECUTION

355

17.2.1. Représentation graphique

355

17.2.2. Interprétation d'une S.E

357

17.2.3. Raffinement et abstraction d'une structure d'exécution.

358

17.3. SPECIFICATION DES CONSTITUANTS POUR LA REALISATION

359

17.3.1. Spécification d'un processeur

360

17.3.2. Spécification d'une mémoire

360

17.3.3. Spécification d'un noeud de communication

360

17.4. PROPRIETES DU MODELE D’EXECUTION

361

17.5. RESUME

362

Ch 18 - LE MODELE D’INTEGRATION

18.1. LE MODELE D'INTEGRATION ET SES CONSTITUANTS

364

18.2. LE MODELE D'ALLOCATION

365

18.2.1. Correspondance entre les éléments des 2 structures

365

18.2.2. Contraintes pour une allocation

367

18.3. LE MODELE D'IMPLANTATION POUR CHAQUE PROCESSEUR

368

18.3.1. Implantation des tâches

369

18.3.2. Implantation de chaque tâche

371

18.3.3. Spécification de chaque élément

372

18.4. QUELQUES REGLES POUR DEDUIRE UNE IMPLANTATION

372

18.4.1. Correspondance: Fonctions —> Tâches

373

18.4.2. Traduction des relations par partage de variables

374

18.4.3. Traduction des synchronisations par événement

374

18.4.4. Traduction pour des transferts par messages

375

18.5. IMPLANTATION AVEC OU SANS EXECUTIF TEMPS-REEL

376

18.5.1. Implantation sans moniteur temps-réel

377

18.5.2. Implantation avec un exécutif temps-réel

378

18.5.3. Critères de choix de la technique d'implantation

380

18.6. CARACTERISTIQUES DU MODELE D'INTEGRATION

381

18.7. RESUME

382

Ch 19 - DEMARCHE POUR LA DEFINITION DE LA REALISATION

19.1. LES OBJECTIFS A ATTEINDRE

384

19.1.1. Spécifications matérielles

384

19.1.2. Contraintes de temps

385

19.1.3. Réduction du coût de développement

385

19.1.4. Réduction de la partie organisationnelle

386

19.1.5. Règles de qualité

387

19.1.6. Objectifs contradictoires

387

19.2. PRESENTATION DE LA DEMARCHE

388

19.3. INTRODUCTION DES CONTRAINTES DE REPARTITION

388

19.4. INTRODUCTION DES INTERFACES

391

19.4.1. Modèle pour l’introduction des interfaces

392

19.4.2. Introduction des interfaces physiques

393

19.4.3. Introduction des interfaces homme-machine

394

19.4.4. Exemple 1 : contrôle en vitesse d’un centrifugeur

395

UNE METHODOLOGIE

19.4.5. Exemple 2 : automatisation par chariot filoguidé

400

19.5. CONTRAINTES POUR UNE STRUCTURE D’EXECUTION

402

19.5.1. Evaluation des contraintes de temps

402

19.5.2. Techniques pour déduire une structure d’exécution

408

19.6. DETERMINATION DE LA STRUCTURE D'EXECUTION

409

19.6.1. Choix de la répartition matériel / logiciel

409

19.6.2. Exemple 1 : contrôle en vitesse d’un centrifugeur

410

19.6.3. Exemple 2 : automatisation par chariot filoguidé

411

19.7. SCHEMA D'IMPLANTATION LOGICIELLE POUR CHAQUE PROCESSEUR

412

19.7.1. Traduction d’une dépendance temporelle entre deux actions

413

19.7.2. Exemple 1 : contrôle en vitesse d’un centrifugeur

414

19.7.3. Exemple 2 : automatisation du chariot filoguidé

415

19.7.4. Implantation d’une séquence d’actions

416

19.7.5. Implantation d’une séquence bouclée d’actions

417

19.7.6. Implantation de plusieurs séquences d’actions

417

19.7.7. Capacité des ports

419

19.7.8. Utilisation des services d’un processeur

419

19.7.9. Implantation de modules

420

19.8. IMPLANTATION DES DONNEES

421

19.8.1. Critères pour l’implantation des données

421

19.8.2. Implantation pour des données structurées

422

19.8.3. Implantation pour des collections et des relations

422

19.9. SPECIFICATION DE LA REALISATION MATERIELLE

423

19.9.1. Exemple 1 : contrôle en vitesse d’un centrifugeur

424

19.9.2. Exemple 2 : automatisation du chariot filoguidé

424

19.9.3. Couplage entre processeurs

425

19.10. DOCUMENTATION ET CARACTERISTIQUES DE LA SOLUTION

427

19.11. RESUME

428

BIBLIOGRAPHIE 5

431

Partie 6 : REALISATION

Ch 20 - DEMARCHE POUR LA REALISATION

20.1. OBJECTIF DE LA REALISATION

435

20.1.1. Caractérisation de l'étape de Réalisation

436

20.1.2. Variété des méthodes et moyens en réalisation

437

20.1.3. Importance en durée de l'étape de Réalisation

439

20.2. DEMARCHE POUR LA REALISATION

440

20.3. VERIFICATION ET ACCEPTATION DES SPECIFICATIONS

441

20.4. REALISATION MATERIELLE

442

20.4.1. Démarche

442

20.4.2. Les outils

443

20.4.3. Règles à respecter

443

20.5. REALISATION LOGICIELLE

443

20.5.1. Démarche

443

20.5.2. Les outils

444

20.5.3. Règles à respecter

444

20.5.4. Traitement des erreurs

446

20.6. INTEGRATION ET TEST

446

20.7. LES SOURCES D'ERREURS

447

SPECIFICATION ET CONCEPTION DES SYSTEMES

20.8. RAFFINEMENT EN REALISATION

448

20.8.1. Raffinement en réalisation matérielle

449

20.8.2.

Raffinement en réalisation logicielle

449

20.9.

INTERET DE LA REUTILISATION

450

20.10.

RESUME

450

Ch 21 - TECHNIQUES POUR LA REALISATION MATERIELLE

21.1. METHODE POUR LA RECHERCHE D'UNE REALISATION

454

21.2. TECHNIQUES POUR LA REALISATION

454

21.2.1. Réalisation avec des composants existants

454

21.2.2. Développement de composants spécifiques

455

21.3. VERIFICATION, VALIDATION D'UNE REALISATION

457

21.3.1. Test fonctionnel

457

21.3.2. Test de fabrication

458

21.4. REUTILISATION POUR LE MATERIEL

459

21.5. MODELES GENERIQUES POUR LA REALISATION

460

21.6. LE MODELE DE LA MACHINE DE MOORE

461

21.6.1. Le principe

461

21.6.2. Le modèle

462

 

21.6.3. méthode

463

21.7. LE MODELE COMMANDE/EXECUTION

465

 

21.7.1. Principe

465

21.7.2. Modèle

466

21.7.3. Méthode

468

21.8. RESUME

469

Ch 22 - TECHNIQUES POUR LA REALISATION LOGICIELLE

22.1. NIVEAUX DE FONCTIONNALITES ET DEMARCHES

472

22.1.1. Niveaux de fonctionnalités

472

22.1.2. Démarches

473

22.2. REUTILISATION POUR LE LOGICIEL

475

22.3. PRINCIPES DE REALISATION

476

 

22.3.1. Qualités

476

22.3.2. Caractéristiques

477

22.3.3. Principes

477

22.4. TECHNIQUES POUR L'INFORMATIQUE INDUSTRIELLE

478

22.5. IMPLANTATION DIRECTE

479

22.6. UTILISATION D'UN EXECUTIF TEMPS-REEL

480

22.7. UTILISATION DU LANGAGE ADA

481

22.7.1. Le mécanisme de rendez-vous

481

22.7.2. Implantation des relations du modèle fonctionnel

483

22.7.3. Interruptions et exceptions

484

22.8. UTILISATION DU LANGAGE OCCAM ET DU TRANSPUTER

485

22.8.1. Le mécanisme d'échange par canal

485

22.8.2. Implantation des relations du modèle fonctionnel

487

22.9. SERVICES POUR LE MODELE FONCTIONNEL

489

22.10.

REALISATION ORIENTEE OBJET

491

22.10.1. Catégories d'objets

491

22.10.2. MCSE et la conception orientée objet

492

22.10.3. MCSE pour l'identification des objets

493

22.10.4. Structuration avec la programmation objet

497

22.11.

RESUME

499

BIBLIOGRAPHIE 6

501

UNE METHODOLOGIE

Partie 7 : CONDUITE DE PROJET

Ch 23 - MANAGEMENT DE PROJETS

23.1. UNE PRESENTATION DU PROBLEME

508

23.1.1. Modélisation d'une étape de développement

508

 

23.1.2. Types d'Entropie

509

23.1.3. Causes de l'entropie

510

23.2. ORGANISATION DU MANAGEMENT

512

23.3. PLANIFICATION

514

 

23.3.1. Objectifs

514

23.3.2. Principes

515

23.4. TECHNIQUES POUR LA PLANIFICATION

515

23.5. ORGANISATION

516

23.6. CONSTITUTION DES EQUIPES

517

23.7. DIRECTION DE PROJET

517

23.8. CONTROLE

518

Ch 24 -

PLANNING ET COUT D’UN PROJET

24.1. CONTRAINTES DE DEROULEMENT POUR CHAQUE ETAPE

522

 

24.1.1. Etape de spécification

522

24.1.2. Etape de conception

523

24.1.3. Etape de définition de la réalisation

524

24.1.4. Etape de réalisation

525

24.2. DUREE TOTALE D'UN PROJET

526

24.3. OPTIMISATION D'UN PLANNING

527

24.4. METHODE OU PAS DE METHODE

528

24.5. ESTIMATION DU COUT D'UN PROJET

528

Ch 25 - CONFORMITE D’UN PROJET

25.1. TERMINOLOGIE

532

25.2. OBJECTIFS

532

25.3. TYPE D'ERREURS

533

25.4. NATURE DES VERIFICATIONS

534

25.5. METHODES EN CONCEPTION

535

 

25.5.1. Technique pour les revues de conception

536

25.5.2. Simulation/modélisation comme outil d'évaluation

537

25.6. METHODES POUR LA PHASE DE REALISATION

537

 

25.6.1. Analyse statique

537

25.6.2. Analyse dynamique

537

25.6.3. Démarche pour le test

538

25.7. TECHNIQUES POUR L'INTEGRATION

538

 

25.7.1. Assemblage par phase

538

25.7.2. Assemblage incrémental

539

25.7.3. Tests orientés OBJECTIFS

539

25.7.4. Remarques sur ces démarches

540

25.8. ENVIRONNEMENT POUR LE TEST

540

25.9. TESTS AUTOMATIQUES

540

25.10. PLANIFICATION DES TESTS

541

25.11. GUIDE POUR LA SPECIFICATION DU TEST

541

25.12. GUIDE POUR UN DOCUMENT DE TEST

542

 

25.12.1. Information Générale

542

25.12.2. Plan

543

25.12.3. Spécification des Tests

543

SPECIFICATION ET CONCEPTION DES SYSTEMES

 

25.12.4. Evaluation des Tests

544

25.12.5. Description des tests

544

Ch 26 - MAINTENANCE

26.1.

TYPES DE MAINTENANCE

546

26.2.

LES CAUSES DE LA MAINTENANCE

546

26.2.1. Qualité du produit développé

547

26.2.2. Documentation

548

26.2.3. Utilisateurs

548

26.2.4. Personnel

548

26.3.

PROCEDURES POUR LA MAINTENANCE

548

26.3.1. Alternative: maintenance/nouvelle conception

549

26.3.2. Méthode de contrôle des changements

550

26.4.

SOLUTIONS POUR AMELIORER LA MAINTENANCE

550

26.5.

LES OUTILS DE MAINTENANCE

551

26.6.

MANAGEMENT DE LA MAINTENANCE

552

26.6.1. Objectif et activités

552

26.6.2. Règles pour la maintenance

552

26.6.3. gestion des équipes

553

Ch 27 - DOCUMENTATION D’UN PROJET

27.1. JUSTIFICATION FONCTIONNELLE

556

27.2. STRUCTURATION DES DOCUMENTS

557

 

27.2.1. Hiérarchie des documents

557

27.2.2. Documents préliminaires

558

27.2.3. Documents de contrôle

558

27.2.4. Documents de spécification, de conception, de réalisation, de tests

560

27.2.5. Les manuels

561

27.2.6. Document de maintenance

562

27.3. PLANIFICATION POUR LA DOCUMENTATION

562

27.4. PROCEDURES POUR LA DOCUMENTATION

562

 

27.4.1. Problèmes et causes

562

27.4.2. Niveaux de qualité de la documentation

563

27.4.3. Procédures

563

27.5. GUIDE POUR LA REDACTION DES DOCUMENTS

565

 

27.5.1. Défauts d'un document

565

27.5.2. Principes pour la rédaction

566

27.5.3. Rédaction des manuels utilisateurs

567

Ch 28 - GESTION DE LA QUALITE

28.1. TERMINOLOGIE

570

28.2. PRINCIPE POUR L'OBTENTION DE LA QUALITE

570

28.3. LES CRITERES DE QUALITE

571

28.4. FACTEURS OU ATTRIBUTS DE LA QUALITE

572

28.5. MESURE DE LA QUALITE

573

28.6. METHODE

573

28.7. VERIFICATION DE LA QUALITE

574

BIBLIOGRAPHIE 7

577

UNE METHODOLOGIE

Partie 8 : BILAN ET PERSPECTIVES

Ch 29 - APPORT DE LA METHODOLOGIE

29.1. LA BOITE A OUTILS DU CONCEPTEUR

582

29.2. DOMAINES D’UTILISATION

582

29.3. ORGANISATION DES PROJETS

582

29.4. REPARTITION DES COMPETENCES

583

29.5. GUIDE POUR LE DEVELOPPEMENT

584

29.6. DOCUMENTATION DES PROJETS

586

29.7. LES POINTS DELICATS EN CONCEPTION

586

29.8. PERENNITE DE LA METHODOLOGIE

588

Ch 30 - CAHIER DES CHARGES POUR UN OUTIL DE CONCEPTION

30.1.

LES OBJECTIFS

592

30.2.

LES FONCTIONNALITES SOUHAITEES

593

30.2.1.

Description

593

30.2.2.

Documentation

594

30.2.3.

Vérification, validation

594

30.2.4.

Production

595

30.2.5.

Gestion de projets et de versions

596

30.2.6.

Conduite de projets

597

30.3.

SYNTHESE DES FONCTIONNALITES

597

30.4.

STRUCTURE ET CARACTERISTIQUES D’UN OUTIL

598

30.5.

GUIDE POUR UNE ANALYSE DES OUTILS

600

Ch 31 - REALITES ET PERSPECTIVES

31.1. LA COMPETENCE DU CONCEPTEUR

602

31.2. RESPONSABILITES DE L’ORGANISATION

602

31.3. PERSPECTIVES A LONG TERME

603

BIBLIOGRAPHIE 8

607

SPECIFICATION ET CONCEPTION DES SYSTEMES

CONTENTS

Part 1 : Methodology Overview

1

-

Introduction

2

-

Systems characteristics

3

-

System development life cycle

4

-

Methodology basis

5

-

MCSE overview

6

-

An example

Part 2 : Models and Methodologies -

7

8 -

Methodologies survey

Models survey

Part 3 : System Specification -

9

10 - System specification

11 - Modeling concepts

12 - The specification process

System requirements

Part 4 : Functional Design

13 - The functional model

14 - Design principles

15 - The functional design process

16 - Template models for design

Part 5 : Implementation Specification

17 - The executive model

18 - The integration model

19 - The implementation specification process

Part 6 : Implementation

20 - Implementation steps

21 - Hardware development tools

22 - Software development tools

Part 7 : Project Management

23 - The project management process

24 - Project planning and cost

25 - Project verification and validation

26 - Maintenance management

27 - Project documentation

28 - Quality management

Part 8 : Conclusion and Perspectives

29 - Methodology contribution

30 - Requirements for a computer-aided design tool

31 - Realities and perspectives

AVANT-PROPOS

La formalisation d'une méthodologie représente un travail de longue haleine. Seul et sans terrain d'expérimentation, je ne pouvais faire aboutir un tel projet. Je tiens à remercier très chaleureusement mes collègues qui ont contribué efficacement dès le début à ce travail en accceptant à la fois la responsabilité de projets pour des industriels et l’expérimentation de la Méthodologie. Il s'agit tout particulièrement de Pascal CLODIC, Gérard DUCHENE, Jocelyn FRAPPIER, Eric FRIOT, Gérard THIBAUT. Je remercie aussi tous les étudiants et auditeurs qui ont suivi en une occasion ou une autre, la formation à la Méthodologie. Je citerai tout d'abord les étudiants du DESS "Conception et Mise en oeuvre des Systèmes Electroniques". Quatre ans durant, exploitant la méthodologie pour des projets industriels durant leur stage, ils m'ont permis de disposer d'une base expérimentale. Les contacts fructueux que j'entretiens toujours avec un certain nombre d'entre eux, qui dans leur métier d'ingénieur utilisent cette Méthodologie et arrivent à l'imposer comme démarche de travail dans leurs entreprises, sont significatifs d'une reconnaissance de l'effort pédagogique entrepris durant cette formation. Ensuite, la Conception des Systèmes fait partie intégrante du programme de la Formation d'Ingénieur IRESTE en Systèmes Electroniques et Informatique Industrielle. Les étudiants durant leur dernière année, ayant à réaliser un projet industriel de 6 mois en entreprise, prennent conscience de la vraie dimension de cet enseignement et de son intérêt essentiel pour la compétitivité de nos entreprises. Ils disposent ainsi d'un atout majeur qui répond aux préoccupations actuelles et à long terme des industriels. Je remercie aussi toutes les sociétés qui ont fait confiance à l'équipe et aux ingénieurs qui ont trouvé par la Méthodologie une nouvelle dynamique en développement de systèmes. Je ne saurais oublier la lourde tâche de frappe que constituent la saisie et la mise en forme d'un tel document. Je remercie très vivement Marie-Thérèse SALOUX qui a assuré avec qualité et efficacité le travail de saisie, Olivier DEBON et Franck BERTAUD qui ont réalisé les figures et la mise en page.

Le 18 janvier 1990

Jean Paul CALVEZ

PARTIE

1

PRESENTATION DE LA METHODOLOGIE

Cette première partie introduit MCSE comme Méthodologie pour la Conception des Systèmes Electroniques, en présentant la classe des applications concernées, les objectifs visés et les principes essentiels. Le chapitre 1 fixe l’objectif global du document. S’adressant aux concepteurs de systèmes et aux spécialistes de l’Informatique Industrielle, la méthodologie proposée est un outil de travail améliorant la productivité et la qualité en développement de projets. Le chapitre 2 délimite le champ des applications concernées par MCSE. Pour ces applications, les systèmes dits temps-réel sont définis par leurs caractéristiques. On y évoque aussi les techniques mises en oeuvre et les compétences nécessaires. Le chapitre 3 présente le cycle de vie pour le développement de tout produit. Utile pour introduire les différentes phases, le modèle de cycle de vie permet de montrer la nature itérative du processus de développement et le domaine couvert par MCSE. Le chapitre 4 explicite les bases sur lesquelles reposent en général les méthodologies. Le découpage en étapes et la nécessité de modèles de description y sont notamment justifiés. Le chapitre 5 permet au lecteur d'avoir une vue globale de la méthodologie MCSE incluant les modèles et la démarche. Lors du chapitre 6, la démarche est introduite sur un exemple simple mais suffisamment réaliste pour que le lecteur puisse se faire une idée précise de la méthodologie , en ayant une vue synthétique des différentes étapes.

Chapitre 1

INTRODUCTION

Cet ouvrage décrit une méthodologie appelée MCSE pour la Spécification, la Conception et la Réalisation des Systèmes en Informatique Industrielle. Les systèmes visés intègrent à la fois les techniques de l'Electronique et de l'Informatique, et concernent des applications variées quant au domaine et à la complexité. Comme exemples, parmi tant d'autres, citons: un système de commande d'un centrifugeur, la gestion technique centralisée d'un grand bâtiment, la gestion automatique d'un magasin incluant des chariots filoguidés, la surveillance des chaînes d'ancrage pour plateformes pétrolières. De tels types d'exemples correspondent au domaine de l'Informatique Industrielle.

Il s'agit de systèmes temps-réel pour des applications dédiées: ceci veut dire que le développement se fait spécifiquement pour chaque application, et qu'il doit conduire directement à un produit industriel opérationnel respectant à la fois les spécifications du client, les coûts et délais prévus.

Une méthodologie peut être vue comme une boîte à outils dans laquelle le concepteur trouve une variété d'outils: - modèles, méthodes, solutions - pour mener à bien son travail. Les activités concernées par la Méthodologie MCSE sont toutes celles qui permettent de passer du cahier des charges d'un produit, d'un système ou d'une application, à la définition complète de sa réalisation. Ces activités sont structurées en 3 étapes: élaboration des spécifications, conception fonctionnelle, définition de la réalisation.

Pour introduire l'apport de cet ouvrage, évoquons les objectifs de tout développement puis les difficultés de cette activité. Une méthodologie est une réponse à cette problématique.

Partie 1 - PRESENTATION DE LA METHODOLOGIE

1.1. LES OBJECTIFS POUR UN DEVELOPPEMENT

Nous nous plaçons ici dans le cas normal d'un développement de systèmes pour un client. Une situation différente, consiste à développer un produit pour ses besoins propres. Il s'agit d'un cas particulier plus simple puisque le concepteur est aussi le demandeur.

Que demande-t-on à un concepteur? En dehors de la compétence technique pour traiter le problème, plusieurs points essentiels:

- de satisfaire le besoin du demandeur: ceci est un point fondamental. Le demandeur est le client et donc finance contractuellement le développement. Un produit jugé satisfaisant par le concepteur peut ne pas répondre à l’attente du demandeur.

- de respecter des délais et des coûts. Normalement un développement fait l'objet d'un contrat négocié sur la base de propositions incluant des délais et des coûts. Sur cette base, le client définit une stratégie d’entreprise, par exemple vente ou intégration dans une gamme. Un non-respect du délai ou des coûts engendre des dépenses supplémentaires ou une perte de parts du marché, ainsi qu'une perte de crédibilité pour l'équipe de développement.

- de satisfaire des critères de qualité. Au-delà du bon fonctionnement bien entendu nécessaire, les principaux critères concernent: la robustesse du produit (fiabilité, tolérance aux pannes), la lisibilité, qui concerne la compréhension du développement à la fois des documents et du produit, la maintenabilité de manière à corriger les défauts résiduels et pouvoir faire évoluer les caractéristiques du système. Ainsi la QUALITE dans les systèmes a des répercussions sur le coût global de toutes les opérations intervenant dans le cycle de vie du produit.

1.2. LES DIFFICULTES DU METIER DE CONCEPTEUR

La situation habituelle du concepteur est la suivante: Comment faut-il procéder pour aboutir à une réalisation spécifique en état de fonctionnement et répondant à toutes les caractéristiques demandées citées ci-dessus.

Il est aisé de constater la complexité du travail des concepteurs de systèmes. Une triple complexité existe: la première est due à la diversité des techniques et moyens à mettre en oeuvre, la deuxième est liée à la distance entre le domaine du problème et celui de la technique mise en oeuvre, la troisième est en rapport avec l’éventail des complexités et tailles des applications.

Tout d'abord, il faut maîtriser les constituants de la réalisation; or le domaine des techniques est étendu: électronique analogique, électronique numérique et composants VLSI,

informatique et programmation, problèmes d'industrialisation

évoluent et se diversifient très rapidement, un effort important doit être constamment fait, ne serait-ce que pour se maintenir informé des techniques. La mise en oeuvre des systèmes nécessite aussi bien entendu une maîtrise correcte des moyens de développement pour les parties matérielle et logicielle. Le problème posé peut conduire à devoir maîtriser des techniques autres: traitement du signal, (télé)communications, algorithmique, physique

Comme les techniques

Ch 1 - INTRODUCTION

Ensuite, le concepteur est différent du client. Il faut s'intéresser au domaine du demandeur:

un dialogue est strictement nécessaire. En effet, l'objectif d'un système est de satisfaire le besoin du client qui n'est probablement ni électronicien ni informaticien. Pour cela, le concepteur est contraint d'interpréter au mieux la demande pour que le système donne satisfaction.

Troisième point: avec l'accroissement de la complexité des applications, les systèmes ne peuvent plus être développés par une seule personne. Apparaît alors le problème de la gestion du projet, des ressources humaines, de l'organisation du travail en équipe, de la cohérence

Ajoutons encore, que les systèmes électroniques sont sur un marché de

concurrence. Ne survivent que les bons produits et les entreprises compétitives. Avec l'évolution rapide des techniques et des idées, les délais de réalisation d'un produit industriel doivent être les plus courts possibles. Coûts et critères de qualité sont devenus essentiels.

20 à 30 % de l’effort de développement devrait être consacré à l’analyse, la spécification et la conception préliminaire. Toute erreur durant ces phases est très coûteuse pour les corrections. Ceci est connu depuis plusieurs années. Et pourtant, pour bien des projets, la spécification n’est pas élaborée convenablement, entraînant par la suite des coûts exhorbitants en reconception et modification des réalisations. Pourquoi ceci ? Les ingénieurs sont-ils en cause, ne passant pas suffisamment de temps ou n’effectuant pas correctement le travail d’analyse ? Il y a bien d’autres raisons. Tout d’abord, peu de concepteurs sont formés et entraînés à l’analyse des systèmes complexes. Ensuite les concepteurs ne peuvent pas apprendre d’eux-mêmes une ou des méthodes car il existe peu d’ouvrages explicites sur ce sujet. Enfin, la lecture d’un ouvrage n’est pas suffisante; les ingénieurs inexpérimentés doivent être guidés durant des projets pour acquérir une bonne expérience.

d'ensemble

Comment chacun acquiert la compétence? Celle-ci résulte de l'acquisition d'un savoir faire qui s'étoffe au fur et à mesure des nouveaux développements. Chaque problème traité contribue à enrichir l'expérience du concepteur. Il n'est pas étonnant de constater qu'en Informatique Industrielle le savoir faire est habituellement spécifique de groupes relativement restreints, et la méthode utilisée qui découle du travail collectif reste de ce fait très confinée. Aussi, une disparité très importante existe dans la façon de mener à bien des réalisations en fonction des entreprises et même des groupes à l'intérieur de celles-ci.

La démarche la plus fréquemment constatée, procède selon un schéma en 3 phases:

définition du cahier des charges, conception, réalisation. Les concepteurs utilisent directement, sans méthode particulière, le document élaboré par le demandeur. Procédant à une analyse, une solution est élaborée. La forme de description de la solution est très variée: organigramme, schémas blocs, emploi de langages de haut-niveau, ou toute autre forme de description. Très souvent, il est constaté que pour un projet donné, les solutions matérielles sont déjà choisies explicitement ou implicitement. D'autre part, la dépendance Conception puis Réalisation qui devrait exister n'est pas des plus évidentes. Il n'est pas exagéré de faire remarquer que bon nombre de fois, les choix de solutions pour la réalisation influent sur la conception et pas l'inverse.

Partie 1 - PRESENTATION DE LA METHODOLOGIE

Durant le développement, la séparation des 2 activités: -réalisation matérielle, réalisation logicielle- n'est pas non plus évidente, car le couplage entre les 2 parties est important. S'il n'y a pas au préalable, une définition précise de ce que doit faire chaque partie, le travail d'intégration qui consiste à imbriquer les 2 parties, demande, pour un projet mené de cette manière, un temps considérable. La situation s'aggrave encore par la suite, car une partie importante du temps doit être passée à assurer la maintenance, l'évolution ou l'adaptation des systèmes ainsi réalisés. Par maintenance, il faut entendre aussi bien l'évolution, l'adaptation, la correction, que le dépannage du système. Cette situation, qui résulte de la nécessité de corriger a posteriori les erreurs de conception, de spécification, voire de définition du produit, n’est pas viable.

1.3. INTERETS D’UNE METHODOLOGIE

Pour résoudre son problème, le concepteur dispose de techniques et moyens variés. Encore faut-il savoir passer du problème à la mise en oeuvre des moyens. Si pendant des années, la démarche incrémentale a pu paraître suffisante, l'accroissement des types de problèmes, de la variété des techniques et de la complexité des moyens, impose de disposer de méthodes globales qui permettent de passer efficacement du problème à la définition de la solution. Une telle démarche constitue une méthodologie.

Tout développement nécessite de prendre une multitude de décisions. Les connaissances sur le problème, les techniques et moyens, constituent les informations nécessaires qui permettent de décider, tandis qu'une démarche induit la chronologie des décisions.

Ainsi, face à un problème, il est primordial de maîtriser 3 aspects essentiels que sont:

méthodes, techniques, moyens. METHODES MOYENS PROBLEME TECHNIQUES
méthodes, techniques, moyens.
METHODES
MOYENS
PROBLEME
TECHNIQUES

-Figure 1.1- Les 3 aspects essentiels pour résoudre un problème.

Ch 1 - INTRODUCTION

La technique est le support de la réalisation. Les moyens servent à mettre en oeuvre la technique. Les méthodes aident à passer du problème à la réalisation.

Que faut-il attendre d'une méthodologie? Celle-ci doit:

- garantir l’obtention d’un résultat. Elle doit être suffisamment globale pour couvrir une variété de problèmes et de techniques, mais aussi précise, efficace et simple.

- faciliter l'évaluation a priori de la faisabilité de l'application, du coût et du temps du développement.

- augmenter la productivité des concepteurs et la qualité du résultat, ceci en favorisant au maximum la production automatique de solutions qui sont alors sans erreur par construction.

- accroître la réflexion à un niveau conceptuel qui se veut le plus indépendant possible de la technologie. Ceci conduit à une meilleure compréhension du problème, à l'élaboration de spécifications et de solutions générales plus facilement réutilisables.

- permettre l’organisation et la conduite de projets, de manière à pouvoir gérer des développements complexes qui nécessitent la participation d'équipes et de divers spécialistes.

1.4. GENESE DE LA METHODOLOGIE MCSE

Pourquoi une méthodologie pour les Systèmes Electroniques et l'Informatique Industrielle? Différentes raisons ont conduit à une telle nécessité. Tout d'abord, durant ces vingt dernières années, l'évolution des techniques disponibles en Electronique et en Informatique a été considérable, et elle ne cessera de s'amplifier. Grâce à ces techniques, des applications de toute nature et de plus en plus complexes sont devenues réalisables. Pour répondre à une telle demande, la disponibilité de la compétence ou l'acquisition rapide de celle-ci, ainsi que l'organisation des équipes de développement sont devenus des préoccupations essentielles.

Ensuite, à la différence des systèmes généraux ou des produits de série qui sont le résultat de développements progressifs, les systèmes temps-réels pour des applications dédiées sont à produire immédiatement dans la version définitive avec une garantie de résultat. Aussi, les activités en amont de la réalisation, c'est-à-dire celles qui concernent la compréhension du besoin, la rédaction des spécifications, la conception, sont essentielles pour satisfaire des contraintes telles que les délais, les coûts, la qualité.

En plus des nécessités correspondant aux points précédents, nous avons constaté durant cette décennie que l'apport d'une méthodologie correspond pour les entreprises à un investissement essentiel à long terme. Le retour d'investissement, pas facile à estimer a priori, se traduit sous des formes variées: réduction des coûts et délais de développement, meilleure satisfaction des clients, plus grande pérennité des développements, réduction importante des coûts de maintenance.

Une méthodologie résulte d'une volonté à long terme de chercher à mettre à la disposition des développeurs une démarche de travail complète, efficace, cohérente. On peut constater aujourd'hui que pour arriver à maturité, toute méthodologie nécessite près de 10 années. Une telle durée s'explique aisément. Une méthodologie résulte pour leurs auteurs, d'une progression

Partie 1 - PRESENTATION DE LA METHODOLOGIE

incrémentale ascendante, la seule possible pour analyser les difficultés, rechercher des solutions, conceptualiser sous la forme de modèles et méthodes, expérimenter pour vérifier et valider chaque proposition, structurer l'ensemble de manière à mettre à disposition une démarche globale descendante complète directement exploitable. Sans terrain d'expérimentation, une méthodologie ne peut voir le jour. Pour répondre au

besoin des développeurs, il faut déjà connaître leurs problèmes: domaine d'activités, nature des

Pour cela, la participation à des projets industriels est impérative. Ensuite,

l'expérimentation nécessite que soit appliquée tout ou partie de la Méthodologie pour ces développements industriels. L'observation des problèmes, des difficultés et des résultats est aussi une obligation car c'est la source des effets correctifs possibles. Enfin, l'expérimentation concerne les développeurs, utilisateurs de la Méthodologie, et non pas l'auteur de celle-ci ; il faut donc aussi avoir formé des concepteurs à l'approche méthodologique pour pouvoir observer les résultats de conception et aussi les difficultés d'acquisition des concepts qui subsistent, ainsi que les erreurs d'utilisation.

Avec tous ces aspects, la progression est particulièrement longue. Depuis 1978, nous avons travaillé avec des industriels et pour des industriels: développement de prototypes, formation aux techniques et aux méthodes, transfert de savoir-faire et de méthodologie, création de produits puis transfert de ceux-ci à des industriels pour production et commercialisation. Depuis 1980, la Méthodologie MCSE est enseignée à un public d'ingénieurs et de techniciens, bien entendu pas dans sa version actuelle. Ayant débuté par la formation au modèle de description des systèmes: modèles fonctionnel et exécutif, nous avons rapidement constaté la difficulté pour les concepteurs de trouver une solution conforme au modèle. L'accent a alors été mis sur l'aspect méthode: comment déduire de spécifications une solution conforme au modèle?. Simultanément, nous avons observé l'impossibilité de dissocier la phase de conception des autres phases: en amont, celle de spécification, et en aval celle de réalisation. La Méthodologie a alors été progressivement étendue à l'ensemble du cycle de développement. Vers 1985, constatant qu'avec de la méthode, les concepteurs n'élaboraient pas obligatoirement des solutions de qualité, nous avons recherché un moyen au-delà de l'aspect méthode, ayant la particularité d'induire des idées de solutions (bien entendu de qualité). Une analyse des développements déjà entrepris a mis en évidence une relative similitude de solutions par classes de problèmes. Ceci a contribué à l'introduction des modèles génériques de solutions. L'effort entrepris durant 10 ans ne s'achève pas avec cet ouvrage. Seule une partie du chemin est parcourue. Un effort d'ouverture doit suivre avec pour objectifs: accroître la formation des concepteurs en nombre et en qualité, poursuivre le développement des concepts et des méthodes pour augmenter les possibilités de production automatique de solutions, induire la création d'outils informatiques comme support et guide à l'utilisation de la méthodologie.

difficultés

1.5. OBJECTIF DE CE DOCUMENT

Aujourd'hui, peu de méthodes, encore moins de méthodologies sont enseignées. Les raisons sont assez simples: il y a peu d'ouvrages disponibles sur le sujet et peu de spécialistes formateurs ont la maîtrise d'une méthodologie sachant qu'elle nécessite en complément une large connaissance des techniques utilisables et une expérience importante en développement de projets industriels.

Ch 1 - INTRODUCTION

Parmi les méthodologies existantes en rapport avec les systèmes temps-réel, citons les principales. Les références bibliographiques et une présentation succincte de chacune d’elles sont données dans la partie 2.

- SADT (structured analysis and design technique) pour la phase de spécification

[ROSS-85].

- SA/SD (structured analysis, structured design) de DEMARCO, YOURDON et CONSTANTINE pour la spécification par diagramme flots de données et la conception modulaire [DEMARCO-79, JENSEN-79].

- JSD (Jackson system development) de JACKSON couvrant toutes les phases du développement [JACKSON-83]

- O.O.D. (object oriented design) de BOOCH pour la conception orientée objet [BOOCH-83], et des variantes que sont GOOD, HOOD, MOOD, OOSD.

- RTSA (real-time structured analysis) qui est une extension de SA/SD par WARD et MELLOR, et par HATLEY et PIRBHAI pour les systèmes temps réels dédiées [WARD-85, HATLEY-87].

- DARTS (Design Approach for Real Time Systems) pour la spécification et la conception d'applications temps-réel et DARTS/DA pour les applications distribuées [GOMAA-84,89]. Utilisation de cette méthode avec implantation ADA [NIELSEN-

88].

- SDWA (System design with ADA) [BUHR-84] et actuellement SDWMC (System design with Machine Charts [BUHR-89] pour la conception des systèmes événementiels (behaviour intensive).

Ces méthodologies diffèrent quant au domaine d'applications, aux phases du développement, aux modèles et méthodes. Que faut-il utiliser? : l'une de celles citées ci-dessus, MCSE, ou faut-il en développer une nouvelle basée sur d'autres concepts? Question pertinente. Ce document a pour objectif d'améliorer la connaissance sur un tel plan méthodologique. Son contenu ne concerne donc pas des connaissances techniques mais uniquement celui de l'acquisition de concepts et de méthodes. Pour tirer un profit maximum, le lecteur est supposé avoir acquis par ailleurs des connaissances dans les domaines et techniques que sont:

l'électronique analogique, l'électronique numérique, les systèmes à microprocesseurs, les automatismes et systèmes de contrôle/commande, les outils informatiques et les langages de haut-niveau. Ce document a pour ambition de proposer une méthodologie complète pour le développement des systèmes. Aussi, concerne-t-il les industriels et tout particulièrement les ingénieurs qui ont en charge la conception de produits ou de systèmes, ainsi que les étudiants ingénieurs et techniciens qui s'orientent vers ce type d'activités. Sont concernées par tout ou partie du document, au moins 4 catégories d'ingénieurs et techniciens:

- les responsables de projets qui ont en charge: l'estimation, la planification, la conduite de projets,

- les spécifieurs et concepteurs chargés d'effectuer tout le travail de développement en amont de la réalisation,

Partie 1 - PRESENTATION DE LA METHODOLOGIE

- les réalisateurs qui doivent utiliser et donc comprendre les résultats de la conception,

- les formateurs qui ont pour mission de développer chez leurs auditeurs l’esprit méthode en spécification, conception et réalisation de systèmes.

Pour répondre à ces 4 catégories d'utilisateurs, le document est structuré en 3 niveaux d'intérêt:

- le niveau Présentation, qui permet de se faire une idée de ce qu'est une méthodologie. Après une délimitation du domaine d'application, la partie 1 décrit, par une présentation succincte, la méthodologie MCSE, les concepts et les étapes. Elle est illustrée par une étude de cas. La partie 8, montre en conclusion, sur la base de la trilogie: -méthodes, outils, concepteurs en tant qu'utilisateurs de méthodologies-, l'effort à long terme et donc la motivation que suppose l'emploi d'une méthodologie, ainsi que les perspectives d'évolution des outils comme support.

- le niveau Méthodologies et conduite de projets, qui donne une vision assez large pour l'organisation des développements. La partie 2 donne un aperçu des méthodologies connues dans le domaine des systèmes temps-réel. La partie 7 présente les problèmes et principes essentiels en conduite de projets.

- le niveau Manuel de Référence, qui explique en détail les concepts, principes, et démarches pour chaque étape de MCSE. Ce niveau qui constitue le corps du document est l'outil de travail du concepteur. Il comprend: La partie 3, décrivant le rôle et la démarche pour la première étape d'élaboration des spécifications, la partie 4, qui concerne l'étape de conception fonctionnelle, la partie 5 relative à la définition de la réalisation, la partie 6, décrivant les problèmes et techniques pour les réalisations matérielle et logicielle. Un résumé à la fin de chaque chapitre rappelle les points essentiels.

Ainsi, après avoir lu le niveau présentation, il est conseillé au lecteur de s'intéresser soit au niveau Méthodologies et conduite de projets, soit au niveau Manuel de Référence, suivant qu'il désire avoir une vue globale du sujet méthodologies et projets d'abord, ou qu'il aspire à approfondir la Méthodologie en vue de s'en servir.

Il nous semble d'emblée souhaitable de prévenir le lecteur, que, s'il désire devenir compétent en conception, il s'agit d'un investissement à long terme qui nécessite du temps. Lire un ouvrage ne suffit pas pour mettre en application les concepts lus, il faut aussi développer des projets et prendre le temps de faire une analyse critique des résultats bons et mauvais de manière à enrichir progressivement son expérience.

une analyse critique des résultats bons et mauvais de manière à enrichir progressivement son expérience. 12

Chapitre 2

CARACTERISTIQUES DES SYSTEMES

Ce document concerne les systèmes pour lesquels la réalisation résulte de l'association d'une partie matérielle (électronique) et d’une partie logicielle (informatique). Le terme système désigne la partie à développer qui n'est en fait qu'une partie de l'application. La démarche pour concevoir et développer de tels systèmes dépend de la nature de son environnement et des caractéristiques souhaitées pour l'application.

Avant de présenter les principes retenus, il apparaît tout d'abord souhaitable de caractériser les systèmes pour lesquels la méthodologie MCSE a été développée. Aussi, après avoir rappelé l'évolution des techniques et moyens en Electronique et précisé le domaine de l'Informatique Industrielle, ce chapitre présente: les classes de problèmes concernés et les moyens de réalisation pour les systèmes dédiés, les caractéristiques des systèmes temps-réel et les critères de qualité pour un système.

2.1. EVOLUTION DES TECHNIQUES ET DES MOYENS DE REALISATION

A partir du transistor puis des circuits intégrés, une évolution considérable de la technologie a conduit à une diversification des techniques disponibles pour la mise en oeuvre des systèmes électroniques. Comme point de repère, notons le passage de l'analogique aux techniques digitales et numériques, puis le passage de la logique câblée à la logique programmée ou

Partie 1 - PRESENTATION DE LA METHODOLOGIE

programmable que constituent les réseaux logiques et les microprocesseurs. Les avantages sont évidents: une structure matérielle donnée permet de résoudre, non pas seulement le problème concerné, mais toute une famille de problèmes. Notons aujourd'hui une distance de plus en plus importante entre les caractéristiques techniques et technologiques de la partie matérielle et les fonctionnalités possibles pour les applications réalisées avec de tels composants. Ainsi, un même support peut servir pour une multitude d'applications, et inversement, une variété de technologies existe pour une même application. La spécification du fonctionnement du système pour une application particulière se définit de plus en plus par programmation.

La réutilisation du matériel devient possible, et les possibilités de modification, d'amélioration du produit sont importantes grâce au logiciel. Ainsi, progressivement, d'une solution purement matérielle, progressivement les réalisations ont évolué vers un partage matériel/logiciel avec un accroissement de la partie logicielle. En moyenne, aujourd'hui pour tous types de systèmes confondus, la part du logiciel est estimée à plus de 70%. De ce fait, par les applications, l'Electronique et l'Informatique se trouvent intimement mêlés.

Plus récemment, grâce aux techniques et moyens de communication, l'accroissement de la complexité des composants et la diversité des fonctions disponibles ont permis de remplacer les solutions centralisées par des réalisations dont la structure est très proche de la répartition géographique de l'application. Une partie de la complexité est alors prise en charge par un système de communication inter-fonctions. Naturellement, les systèmes auparavant autonomes sont aujourd'hui de plus en plus interconnectés.

Toutes ces techniques sont relativement bien connues et maîtrisées. Au fur et à mesure de l'accroissement de la complexité, les objets disponibles sont de plus en plus proches des fonctionnalités désirées, et la mise en oeuvre se simplifie. Un microprocesseur finit par être plus facile à mettre en fonctionnement qu'un étage d'amplification à 2 transistors.

Les moyens pour la réalisation des systèmes ont aussi suivi l'évolution des techniques. Si auparavant le poste de travail de l'électronicien se reconnaissait à son instrumentation et à son outillage tel que le fer à souder, il est aujourd'hui beaucoup plus proche de celui de l'informaticien. L'Informatique comme outil de travail est utilisé par tous.

Les outils de conception assistée par ordinateur aident les concepteurs à définir, à vérifier, puis à réaliser les composants et systèmes électroniques. En plus de l'utilisation des composants standards, l'électronicien a même la possibilité de développer ses propres composants spécifiques (ASIC).

Pour la partie logicielle, le développeur dispose d'une variété d'outils à la fois comme supports: microordinateurs, systèmes informatiques, ou comme moyens de développement:

cross-compilateurs, analyseurs de performances, progiciels variés.

2.2. LE DOMAINE DE L’INFORMATIQUE INDUSTRIELLE

Les SYSTEMES ELECTRONIQUES (au sens large) entrent dans la constitution d'un grand nombre d'applications. Il n'est pas utile de rappeler ici la diversité des domaines influencées ou concernées par l'Electronique. En effet, comme technique de réalisation, il sert de support pour de multiples activités, contribuant ainsi à améliorer les fonctionnalités, les performances, la sécurité, la souplesse d'exploitation

Ch 2 - CARACTERISTIQUES DES SYSTEMES

Les techniques mises en oeuvre concernent l’ANALOGIQUE, le NUMERIQUE et la PROGRAMMATION. Aujourd'hui, plutôt que de chercher à cerner la frontière entre l'ELECTRONIQUE et l'INFORMATIQUE, toutes deux considérées sous l'aspect techniques de réalisation, il est plus réaliste de considérer la synergie globale. En effet, pour le premier domaine, les systèmes intègrent de plus en plus de moyens informatiques, et pour le deuxième, calculateurs, capteurs, actionneurs, périphériques, interfaces sont nécessaires comme support de réalisation des applications. Ainsi est apparu durant la décennie passée le domaine de l'INFORMATIQUE INDUSTRIELLE comme discipline intermédiaire.

Pour l'Informatique Industrielle, un système est composé de 2 parties:

- une partie matérielle, qui est la partie visible. Elle se décompose en une partie analogique pour laquelle tensions et courants ont une importance dans le fonctionnement, et une partie numérique pour laquelle au niveau utilisation, seuls les états logiques ou numériques sont suffisants. La frontière entre les 2 ne dépend que du niveau d'observation,

- une partie logicielle, pas directement visible, puisqu'elle se concrétise par des états logiques 1 et 0 dans les mémoires de l'appareil, ou dans des supports de masse. Des matériels spécifiques (informatiques et logiciels) permettent de produire, manipuler de telles informations.

La partie analogique est plus ou moins importante suivant l'application. De toute manière, elle existe toujours, car tout système est couplé à son environnement par des interfaces qui véhiculent courants et tensions. D'autre part, certaines fonctions non réalisables par une technique numérique subsistent: émission-réception haute-fréquence, génération et transformation de signaux

La partie numérique est constituée d'un assemblage de composants LSI et VLSI, réalisant chacun une fonction complexe. Ces composants sont de plus en plus programmables, ce qui justifie une architecture bâtie autour d'un ou plusieurs microprocesseurs.

La part du logiciel peut varier dans des proportions considérables. De plus en plus, la fonctionnalité est obtenue par le logiciel, tandis que le matériel n'en est que le support d'exécution. A l'extrême, les systèmes informatiques sont considérés comme des supports fonctionnels complets qui permettent de développer une application sans devoir s'intéresser à la partie matérielle.

La fonctionnalité globale résulte d'une bonne adéquation entre toutes les parties:

assemblage correct de tous les composants, programmation adaptée pour la mise en oeuvre des composants et pour répondre aux spécificités de l'application.

Concevoir et réaliser de tels systèmes nécessite donc une compétence technique dans les 3 domaines: Electronique analogique, Electronique numérique ou Informatique industrielle, Informatique. A cela peuvent s'ajouter des compétences complémentaires: en composants

intégrés lorsqu'il s'agit d'en concevoir, en électronique de puissance lorsque l'environnement utilise les courants forts, en réseaux et communications lorsque des couplages entre systèmes

Mais il faut aussi ajouter obligatoirement l'aptitude à cerner

les besoins de demandeurs de tous domaines qui requièrent la mise en place d'un système, ainsi que la maîtrise d'une démarche de développement. On peut aisément imaginer la difficulté de cette spécialité, ainsi que la responsabilité de cet homme de l'Informatique Industrielle comme maître-d'oeuvre en développement de systèmes.

ou ensembles sont nécessaires

Partie 1 - PRESENTATION DE LA METHODOLOGIE

2.3. LES SYSTEMES DEDIES

Pour les applications considérées dans le paragraphe précédent, le demandeur sollicite la réalisation d'un système dit "dédié". Il faut entendre par là que le système est développé à un instant donné pour répondre à un besoin bien délimité. Sa durée de fonctionnement est définie:

plusieurs années, voire même des dizaines d'années. La pérennité est donc importante. Ainsi, le système est à développer au mieux, directement dans sa version définitive avec la technologie courante. Son évolutivité reste limitée à quelques améliorations pour la même application. Il ne s'agit donc pas d'un système général comme l'est un ordinateur ou un microordinateur, il ne s'agit pas non plus d'un prototype qui démontre un bon fonctionnement

à un moment donné.

Un système dédié est installé une fois pour toutes. Aussi, la démarche pour le développement doit conduire à une efficacité directe puisque la solution ne résulte pas d'un développement incrémental, résultat d'expériences successives.

La technique à mettre en oeuvre se doit d'être juste adaptée et suffisante pour le problème de manière à réduire le coût et le temps de développement ainsi que le coût de reproduction.

Les techniques pour réaliser de tels systèmes sont variées:

- utilisation de systèmes complets: micro-ordinateur, automate programmable, système de régulation, système de traitement d'images, terminaux, ordinateurs, ,

- utilisation de cartes, sous-ensembles et progiciels: cartes à microprocesseurs, alimentation, cartes interface, support de masse, bases de données, générateurs de rapports, système multi-fenêtres

La réutilisation permet de réduire les temps de développement. Elle est strictement nécessaire pour le matériel, car l'utilisateur ne peut pas fabriquer ses composants, et chaque reproduction implique un coût. Moins contraignant pour le logiciel, le concepteur peut vouloir,

à tort, développer complètement le logiciel de son application, avec l'argumentation que le

programme développé sera bien plus approprié que celui qui résulterait de la réutilisation d'un

programme précédent, d'une bibliothèque de logiciel, d'un progiciel plus général

2.4. LES SYSTEMES TEMPS-REEL

Intéressons-nous aux caractéristiques fonctionnelles d'un système à partir des applications. La fonctionnalité est alors expliquée par le vocabulaire de l'application et non par le vocabulaire de la technique mise en oeuvre. Le terme environnement est utilisé pour représenter la partie de l’application exclu le système.

L'environnement d'un système électronique dédié est composé d'objets (au sens général) de diverses natures: certains sont physiques, d'autres sont humains. Les objets sont dynamiques; ainsi par leurs actions, ils génèrent des événements, informations, données. De même, ils sont sensibles à des sollicitations externes. En conséquence, fonctionnellement, les systèmes à développer sont dits du type réactif, car ils réagissent sur l'environnement à partir de sollicitations qui en proviennent. La fréquence des sollicitations est alors un paramètre important.

Ch 2 - CARACTERISTIQUES DES SYSTEMES

Pour satisfaire l'objectif qui lui est assigné, le système est couplé à ces objets par des interfaces pour l'observation et la commande. Ainsi, ces systèmes possèdent de multiples entrées et sorties. On voit ainsi apparaître 2 classes d'interfaces: les interfaces homme-machine et les interfaces physiques. Les procédures d'échange entre le système et son environnement doivent tenir compte de la nature de ces interfaces.

Comme l'environnement physique est souvent composé de plusieurs activités simultanées, parfois même réparties géographiquement, l'application nécessite l'exploitation d'un système qui assure simultanément:

- l'observation de grandeurs pour suivre l'évolution de l'environnement,

- la prise en compte d'événements survenant aléatoirement,

- l'évaluation de décisions à partir des événements et observations,

- la génération d'actions auprès de l'environnement pour assurer la cohérence de l'ensemble de l'application.

Du fait de la multiplicité des entrées et sorties qu'il faut suivre globalement, un système électronique doit effectuer des traitements simultanés. Le degré de simultanéité est fonction de la technique de réalisation. Elle est complète lorsque des parties matérielles sont attribuées à chaque traitement. Elle est pseudo-simultanée lorsqu'un processeur partage son activité pour satisfaire plusieurs traitements. Le fonctionnement pour un tel processeur est alors qualifié de multi-tâches.

Couplé à son environnement, un système électronique est aussi concerné par le temps de réaction des objets qui l'entourent. La commande d'un ascenseur, d'un chariot filoguidé, d'un avion est intimement liée à la vitesse d'évolution de ces objets.

Si les échanges d'informations pour les interfaces du type homme-machine sont plutôt de l'ordre de la seconde ou du 1/10e de seconde, la période de réaction d'un système vis à vis de procédés physiques est plutôt de l'ordre de la milliseconde. Ainsi les temps de réponse requis par les systèmes électroniques sont nettement plus proches de la vitesse de réaction de la technologie mise en oeuvre (100 s à 1 ms pour les microprocesseurs). De tels systèmes sont qualifiés de TEMPS-REEL.

Par définition, un système est dit du type temps-réel lorsqu'il effectue toutes ses activités en respectant des contraintes de temps. En effet, l'interaction importante avec l'environnement fait apparaître plusieurs natures de contraintes de temps, certaines parfois sévères, qu'il s'agit de respecter:

de

- tout

d'abord

une

fréquence

élevée

pour

les

sollicitations

en

provenance

l'environnement: fréquence d'événements, débit en données

- une fréquence élevée pour les actions à entreprendre auprès de l'environnement, par exemple, fréquence élevée pour la commande d'un procédé à faible temps de réponse.

- une limite maximale pour le temps de réaction entre l'instant d'apparition d'une sollicitation et l'instant d'achèvement de l'action conséquente (date d'échéance).

Le non-respect d'une des contraintes peut conduire l'application dans un état assimilable à un état de panne, ce qui peut engendrer des conséquences très graves, jusqu'à la mise en danger de vies humaines.

Partie 1 - PRESENTATION DE LA METHODOLOGIE

Ainsi, les systèmes temps-réel sont différents des systèmes dits interactifs. Ces derniers sont plutôt qualifiés de systèmes "on-line". Couplés à des opérateurs, ils requièrent des temps de réponse courts, qui, s'ils ne sont pas respectés, ne conduisent pas à des conséquences graves. Pour un système de gestion bancaire par exemple, le temps de réponse pour les transactions doit rester faible pour le confort des utilisateurs. Un retard reste supportable s'il n'est que ponctuel.

2.5. QUALITES D’UN SYSTEME

Un système peut aussi être observé selon ses qualités, chacune contribuant à satisfaire un objectif spécifique. Un système peut notamment être:

- adéquat: son comportement avec l'environnement répond aux souhaits du demandeur,

- performant: toutes les contraintes de temps sont satisfaites et les temps de réponse du système sont acceptables,

- robuste: le système reste opérationnel, complètement ou en mode dégradé même en présence de fautes ou d'événements non-prévus en provenance de l'environnement.

- évolutif: le système favorise l'évolution de ses caractéristiques et de ses fonctionnalités. Ceci est nécessaire pour répondre aux évolutions imprévisibles du cahier des charges.

- maintenable: après sa réalisation le système est à conserver en fonctionnement durant la vie de l'application. Les corrections et améliorations font aussi partie des tâches dévolues à la maintenance.

- à coût optimal: le développement et la production du système conduisent à un coût convenable et accepté par le demandeur.

Ces qualités servent d'objectifs pour tout développement. Ainsi, une méthodologie pour le développement de systèmes temps-réel pour des applications dédiées, doit favoriser la détermination de solutions répondant à de tels critères.

2.6. CATEGORIES DE SYSTEMES

Tentons pour conclure ce chapitre d'effectuer un classement des systèmes en se basant sur la technique majeure mise en oeuvre. Pour la classification qui ne peut rester qu'approximative, considérons les disciplines connexes de l'Informatique Industrielle que sont: l'Electronique, l'Automatique, le Traitement du Signal (de la parole et des Images), les Communications, l'Informatique. Sur la figure 2.1, chaque discipline est représentée par un cercle. Les disciplines sont partiellement en recouvrement.

Dans ce document, on s'intéresse aux systèmes qui nécessitent la mise en oeuvre de différentes techniques à des degrés plus ou moins importants. Ces systèmes sont représentés dans le cercle correspondant à l'Informatique Industrielle. Sont exclus les systèmes très spécifiques d'un domaine car ils requièrent alors une méthodologie particulière en rapport direct avec les concepts et techniques à mettre en oeuvre de la discipline.

Ainsi, sont concernés par la méthodologie MCSE, les systèmes suivants:

- les

le

développement de matériels tels que conception de fonctions et composants, association de fonctions,

systèmes

typiquement

électroniques:

qui

impliquent

essentiellement

Ch 2 - CARACTERISTIQUES DES SYSTEMES

AUTOMATIQUE INFORMATIQUE Systèmes Systèmes de interactifs contrôle/commande INFORMATIQUE Systèmes Systèmes
AUTOMATIQUE
INFORMATIQUE
Systèmes
Systèmes de
interactifs
contrôle/commande
INFORMATIQUE
Systèmes
Systèmes
électroniques
de
communication
INDUSTRIELLE
COMMUNICATIONS
ELECTRONIQUE
Systèmes de traitement
TRAITEMENT DU SIGNAL
-Figure 2.1- Disciplines et classes de systèmes.

-

les systèmes de contrôle-commande, dominés par des problèmes de suivi et de commande pour des applications incluant des procédés physiques en tous genres à piloter,

-

les systèmes interactifs concernés par l'exploitation d'interfaces évoluées pour les dialogues homme-machine,

-

les systèmes de communication: dominés par le transfert de données. Ces systèmes reçoivent, transforment et émettent des flots de messages,

-

les systèmes de traitement: concernés principalement par les traitements de toute forme d'information: signal, image, parole

: concernés principalement par les traitements de toute forme d'information: signal, image, parole M.C.S.E 19

Chapitre 3

CYCLE DE DEVELOPPEMENT D’UN SYSTEME

Après avoir caractérisé les systèmes par leurs domaines d'application, les techniques mises en oeuvre et les particularités du temps-réel, nous devons caractériser le processus de développement d'une application.

Il n'est pas utile de développer en préambule toutes les raisons qui font que, même de bons projets ne convergent pas obligatoirement vers un succès: médiocre organisation, outils inadaptés, manque de méthodes, absence de plans et procédures de test et d'intégration, manque de spécifications, pas d'investissement de la part du demandeur dans le projet. L'objectif plus essentiel est d'exprimer quelle démarche suivre pour développer efficacement le système répondant au besoin du demandeur.

Pour caractériser l'activité de développement, celle-ci est tout d'abord replacée dans le contexte de l'entreprise. Un développement est une partie des activités d'un projet, et chaque projet s'intègre dans un objectif d'entreprise. L'obtention de résultats implique la nécessité de disposer d'une démarche pour planifier, organiser et contrôler les développements de projets. Le management de projets nécessite de modéliser le processus de développement lui-même. Le terme général "cycle de vie d'une application ou d'un produit" est utilisé pour décrire un tel type de modèle. Introduit vers 75, ce type de modèle sert de support pour expliciter la procédure à suivre, puis pour effectuer des contrôles.

Partie 1 - PRESENTATION DE LA METHODOLOGIE

Ce chapitre montre que le développement d'un système nécessite une organisation plus complexe que le simple séquencement des étapes de spécification, de conception et de réalisation. De plus, un modèle pour le développement sert aussi de base pour une méthodologie. En fin de chapitre, le modèle proposé pour les systèmes électroniques permet de délimiter le domaine d’intérêt de la méthodologie MCSE.

3.1. CONTEXTE D’UN DEVELOPPEMENT

Le terme Développement est utilisé ici pour caractériser l'ensemble des activités techniques qui permettent de passer d'un cahier des charges au produit industriel répondant au besoin.

Pour l'entreprise ou l'organisme chargé du développement, ces activités font partie intégrante d'un projet. Un projet est caractérisé: d'une part par des objectifs, d'autre part par son déroulement. Il a un début et une fin qui correspond à la satisfaction des objectifs. Un projet est aussi en interaction avec d'autres activités (ou projets), ne serait-ce que par un partage de ressources.

Ainsi, caractériser le contexte d'un développement consiste à positionner celui-ci dans le contexte de l'entreprise comme le montre la figure suivante.

ENTREPRISE Management de l’entreprise ACTIVITES projets projet i management du projet developpement du projet
ENTREPRISE
Management de l’entreprise
ACTIVITES
projets
projet i
management du projet
developpement
du projet
RESSOURCES

-Figure 3.1- Contexte global d'un développement.

L'activité de l'entreprise au sens large concerne un ensemble de projets. Le développement d'une application et d'un système n'est qu'une partie du projet. Pour son activité, l'entreprise dispose de ressources matérielles et humaines qu'elle répartit pour les différentes activités.

Pour mieux caractériser l'activité de développement, précisons ce qu'est un projet et son management.

Ch 3 - CYCLE DE DEVELOPPEMENT D’UN SYSTEME

Un projet est caractérisable par son cycle de vie. Ce cycle débute par une phase d’expression du besoin pour se conclure par une phase de finalisation.

En intermédiaire, s’ajoutent 3 phases comme l'indique la figure 3.2: définition du projet, planification et organisation , développement [RUSKIN-82].

Abstrait Expression du besoin Définition du projet Management du projet Planification organisation
Abstrait
Expression
du
besoin
Définition
du
projet
Management du projet
Planification
organisation
Développement
du projet
Achèvement
du projet
Concret

Temps

-Figure 3.2- Les phases d’un projet.

-A- EXPRESSION D’UN BESOIN

Un projet débute par la nécessité ou le souhait de satisfaire un objectif. L'objectif peut être très varié en nature et forme. Par exemple, il peut s’agir de développer un système de conduite de grands bâtiments, mais l’objectif peut aussi s'exprimer par la volonté d'apporter une aide à la conduite de bâtiments.

La première phase concerne donc l'expression d'un besoin pour satisfaire des objectifs, ce qui conduit à exprimer un concept et à identifier des contraintes essentielles. Cette phase n'indique rien sur la manière d'atteindre ces objectifs. Différentes techniques sont utilisables et en particulier les techniques de créativité et d'analyse de la valeur.

-B- DEFINITION DU PROJET

Cette phase concerne une étude préliminaire du projet. Il s'agit tout d'abord de caractériser le projet par une étude de faisabilité sur la base de suppositions sur les différentes manières d'atteindre les objectifs, les critères de décision, les contraintes, les obstacles potentiels, les ressources, budgets et échéances.

Il s'agit ensuite de sélectionner l'approche globale à suivre pour satisfaire les objectifs. La définition du projet conduit à une description suffisamment détaillée pour qu’une proposition puisse être élaborée.

Partie 1 - PRESENTATION DE LA METHODOLOGIE

La phase de définition du projet nécessite de considérer tous les aspects du développement sans pour cela réaliser le projet.

-C- PLANIFICATION ET ORGANISATION

Lorsque le projet est accepté, les objectifs, le coût et les délais sont fixés. La phase suivante concerne sa planification et son organisation. La planification conduit à élaborer des plans détaillés en identifiant les tâches, les échéances et durées pour chacune, les budgets et les ressources nécessaires pour chaque tâche. Il s'agit aussi d'élaborer l'organisation nécessaire pour exécuter le projet. Cela concerne l'identification des ressources nécessaires en qualité, quantité et durée.

-D- DEVELOPPEMENT DU PROJET

Cette phase constitue la partie technique du travail qui conduit à l'obtention du produit ou de l'application à partir du cahier des charges. Cette phase est détaillée dans le paragraphe suivant.

-E- FINALISATION DU PROJET

Cette activité a pour objectif la vérification de la conformité du produit élaborée vis à vis des objectifs, celle-ci doit se faire si possible tout au long du développement. Une fois le produit achevé, il s'agit d'aboutir à la confirmation que le client est satisfait du résultat. Ce qui se traduit par une recette. La conclusion du projet permet de libérer les ressources utilisées et conduit à un bilan financier.

la figure précédente, autour du travail de développement, le

management d'un projet concerne précisément les activités de planification et d’organisation, ainsi que la direction du développement et son contrôle. L'objet de la méthodologie MCSE ne concerne pas la partie management de projet. Quelques éléments sont décrits dans la partie 7 de manière à connaitre la complémentarité des activités de conduite de projet et de développement, car le management est basé sur un modèle du processus de développement qui est le cycle de développement ou plus communément le cycle de vie du produit.

Ainsi, comme l'indique

3.2. LES PHASES D’UN DEVELOPPEMENT

Le cycle de vie pour une application ou un produit est une représentation purement descriptive. Il décompose le processus de développement selon une série d'activités couplées entre elles, partant du besoin initial pour aboutir au produit opérationnel. Le terme cycle est lié au fait que, habituellement, tout produit développé engendre de nouveaux besoins. Plusieurs modèles ont été élaborés. Avant de s'intéresser aux différences entre eux, notons que tous ont en commun les phases essentielles de tout développement. Ainsi, avec quelques variations en fonction des auteurs, on distingue, au minimum 5 phases:

- définition ou spécification,

- conception,

- réalisation,

- production,

- fonctionnement.

On donne ci-après la signification usuelle pour chacune de ces phases.

Ch 3 - CYCLE DE DEVELOPPEMENT D’UN SYSTEME

-A- DEFINITION ET SPECIFICATION

Un projet résulte généralement d'une demande formulée sous la forme d'un document décrivant les besoins. Le document est appelé Cahier des Charges. Pour l'équipe réalisant, c'est une base de départ, pour exprimer une proposition qui se doit de contenir l'ensemble des spécifications. Si certaines descriptions du cahier des charges paraissent claires pour le demandeur, un tel document ne contient habituellement que peu de détails, ce qui le rend insuffisant pour caractériser le projet complet. Ainsi, durant la phase de définition, les objectifs auxquels doit satisfaire le système final sont recensés. Il s'agit d'obtenir une description détaillée du comportement externe du système. Cette description exprime les fonctions à remplir, les contraintes à respecter, les interfaces à exploiter, toutes les informations complémentaires précisant la taille du système, la vitesse d'exécution, les performances et autres caractéristiques à satisfaire

-B- CONCEPTION

Le travail de conception consiste à passer des spécifications à une définition de la réalisation, c'est-à-dire aux documents nécessaires pour entreprendre la réalisation. Au départ, le concepteur exploite directement les spécifications pour déduire une décomposition en termes de fonctions. Au fur et à mesure que des décisions sont prises, le raffinement se poursuit en exprimant comment chaque fonction considérée comme "boîte noire" contribue à atteindre les objectifs. Ceci est une vue simplifiée, car pour concevoir il faut passer par plusieurs stades intermédiaires. Pour chaque stade, toute spécification est transformée en une réalisation correspondante et par une suite de décisions. Si ce schéma est maintenant classique en particulier pour des projets logiciels, les stades intermédiaires par lesquels il est judicieux de passer, dépendent de la classe des problèmes traités. Pour la catégorie des systèmes temps-réel que nous considérons dans ce document, la conception doit produire simultanément la définition des solutions matérielle et logicielle, ce qui complique la démarche.

-C- REALISATION

La phase de réalisation concerne le développement du matériel, celui du logiciel, puis l'intégration du logiciel sur l'infrastructure matérielle. Cette réalisation aboutit à un ensemble en état de fonctionnement reproductible industriellement et répondant aux spécifications du problème.

-D- PRODUCTION

Cette phase concerne tout d'abord l'expérimentation d'un prototype pour évaluer ses caractéristiques. La mise en production découle ensuite de cette évaluation. Des critères complémentaires d'industrialisation sont introduits à ce stade.

-E- FONCTIONNEMENT

Une fois le produit développé en série et commercialisé, il se retrouve en fonctionnement. Débute alors la phase d'exploitation qui implique bien entendu une maintenance. Diverses maintenances sont possibles: corrective pour exclure les erreurs résiduelles, adaptative pour tenir compte des exigences nouvelles, préventive pour augmenter la fiabilité des systèmes.

Partie 1 - PRESENTATION DE LA METHODOLOGIE

Les 2 dernières phases ne font pas obligatoirement partie du projet. Mais quelle que soit l'organisation, la responsabilité incombe dans tous les cas à l'entreprise. D'autres groupes ou services peuvent par exemple avoir en charge la production et la maintenance des produits développés.

3.3. MODELES DE CYCLE DE VIE

En plus de l'intérêt d'une structuration du travail, la décomposition du projet en étapes facilite le contrôle du développement en définissant pour chacune des phases des objectifs à atteindre planifiables et mesurables. Un modèle pour le développement sert donc de base pour la conduite de projet. Plusieurs modèles ont été proposés pour représenter l'enchaînement des phases de développement. Nous décrivons dans la suite les modèles les plus caractéristiques présentés pour le développement de logiciels.

3.3.1. Le Modèle "Waterfall"

Ce premier modèle décrit le cycle de vie comme une succession d'étapes conduisant à trouver des niveaux de description, du problème jusqu'à la réalisation, en partant de la définition jusqu'à l'exploitation et la maintenance [BOEHM-76].

SPECIFICATION CONCEPTION PRELIMINAIRE
SPECIFICATION
CONCEPTION PRELIMINAIRE

Corrections

CONCEPTION DETAILLEE REALISATION
CONCEPTION DETAILLEE
REALISATION

-Figure 3.3- Le modèle Waterfall.

Chaque étape est liée à l'étape suivante pour représenter l'enchaînement, et à l'étape précédente pour représenter les corrections par retour-arrière. A chaque étape est associée une phase de vérification ayant pour but de s'assurer de la conformité de la solution retenue aux

Ch 3 - CYCLE DE DEVELOPPEMENT D’UN SYSTEME

spécifications en entrée de l'étape. Un défaut de conformité implique de reprendre l'étape ou de revoir le résultat de l'étape précédente. Ce modèle fait déjà apparaître qu'un développement ne peut pas se faire exclusivement selon une démarche purement descendante. Comme le suggère la théorie de la commande en boucle fermée, les incertitudes ou erreurs et omissions sont corrigées par des retours-arrières dès l'observation d'écarts. Bien sûr, ceci n'est possible que si, à l'issue de chaque étape, le résultat est observable et comparable à un objectif.

Un accroissement important de l'effort de validation durant les premières phases favorise une correction rapide des premières erreurs, sinon celles-ci conduisent par la suite à un coût de correction considérable.

la vraie nature du

Un peu limité, ce modèle ne prend que très partiellement en compte développement, c'est-à-dire son caractère itératif.

3.3.2. Le cycle en V

Ce modèle considère en supplément les phases de vérification et d'évaluation du projet pour chaque stade de sa réalisation. Il montre bien que la démarche de spécification-conception est globalement descendante tandis que la phase de réalisation-test est globalement ascendante, car il s'agit d'assembler les constituants pour obtenir les fonctionnalités. La figure suivante présente un exemple type de plan de développement.

fonctionnement Spécification Conception - developpement Test et évaluation maintenance BESOIN PRODUIT
fonctionnement
Spécification
Conception - developpement
Test et évaluation
maintenance
BESOIN
PRODUIT
CERTIFICATION
Evaluation
Cahier
et test
des charges
opérationnel
Test
VALIDATION
Spécification
d’intégration
système
système
Spécification
Tests
VALIDATION
de
logiciel
performances
performances
Spécification
Validation
Conception
VERIFICATION
Test
préliminaire
intégration
Corrections
conception
Réalisation
Conception
Test
détaillée
unitaire
Programme
Code
codage
Mise au point

-Figure 3.4- Exemple de cycle de vie en V.

L'axe horizontal représente les phases du projet et la durée de chacune. L'axe vertical représente le niveau d'abstraction pour l'application. Les phases de spécification et de conception conduisent à définir des niveaux de description de plus en plus détaillés. Pour une

Partie 1 - PRESENTATION DE LA METHODOLOGIE

application logicielle, le codage est la forme la plus détaillée. Les phases d'intégration, de test et de vérification, permettent d'évaluer la conformité de la réalisation pour chaque niveau de la conception en commençant par les parties les plus élémentaires puis en remontant progressivement jusqu'au produit complet. Pour cela, en correspondance de chaque phase de la conception est associée une phase de test et d'évaluation de la conformité. Les 2 démarches descendante et ascendante sont complémentaires. Ce modèle favorise une planification des dates de production et de lecture de documents à l'issue de chaque phase, des échéances pour les procédures de vérification-validation. Toutefois, il est plutôt spécifique d'un développement logiciel.

3.3.3. Le Modèle "Spirale"

Les modèles précédents concernent la création d'un seul produit. Ils n'apparaissent pas très appropriés pour la description d'un ensemble de produits et d'activités autour de ces produits:

faisabilité, prototypage

Le modèle Spirale [BOEHM-86,WILLIAMS-88] décrit le développement comme un processus itératif selon 4 phases, permettant de combiner différentes approches: expression des besoins, faisabilité, prototypage, développement du produit final.

DETERMINATION DES OBJECTIFS , DES CHOIX ET CONTRAINTES. COUT CUMULE EVALUATION IDENTIFICATION RESOLUTION Analyse
DETERMINATION DES
OBJECTIFS , DES
CHOIX ET CONTRAINTES.
COUT CUMULE
EVALUATION
IDENTIFICATION
RESOLUTION
Analyse des risques
Analyse des risques
prototype
Analyse des risques
opérationnel
prototype
R
proto
prototype
A
type
concept d’
plan du
cycle de vie
opération
besoin
logiciel
conception
plan de
Validation
conception
detaillée
developpement
des besoins
logicielle
code
test
Integration
Validation de la conception
et vérification
uni-
intégration
taire
et test
et
test
test
conformité
implémentation
PLANIFICATION
DEVELOPPEMENT
DES PHASES
VERIFICATION
SUIVANTES
NIVEAU N+1 DU PRODUIT

-Figure 3.5- Le Modèle Spirale.

Les 4 phases, une par quadrant, concernent:

- la planification des phases ultérieures,

- la définition des objectifs, des variantes et des contraintes,

- l'évaluation de solutions, analyse des risques,

- le développement et la vérification du produit.

La distance de tout point de la courbe au centre représente le coût cumulé qui a conduit à un tel stade du développement.

Ch 3 - CYCLE DE DEVELOPPEMENT D’UN SYSTEME

3.3.4. Le modèle "Contractuel"

Tout développement implique une interaction entre le client et les concepteurs. Ce modèle présente ce point de vue. Chaque phase du développement est considérée comme le sujet d'un contrat entre les 2 parties: le client et le fournisseur (concepteurs) [COHEN-86].

Phase Client Fournisseur Besoins du client analyse Besoin non (non formel) Analyse Modèle formel des
Phase
Client
Fournisseur
Besoins du client
analyse
Besoin
non
(non formel)
Analyse
Modèle formel
des
Comportement
non
acceptable ?
preuve
Adéquat
besoins
analytiquement ?
oui
oui
Spécification
formelle
Besoin conception
conception
non
Architecture
non
fonctionnelle
Comportement
Conception
preuve
équivalent ?
Adéquate
Proposition
et
oui
réalisable ?
de
oui
Besoin réalisation
conception
Construction
non
Schéma
Implémentation
preuve
Comportement
non
adéquat ?
Proposition
Réalisable ?
oui
reproductible ?
oui
d’implémen-
tation

-Figure 3.6- Le modèle contractuel.

Une phase du développement conduit à passer d'une description à la description suivante. La validation du résultat est faite par le client. L'achèvement de chaque phase est signalé par un accord du client signifiant que la fourniture satisfait les termes du contrat.

Partie 1 - PRESENTATION DE LA METHODOLOGIE

Ainsi, ce modèle montre que le concepteur est dans la situation de devoir découvrir quelque chose qui donnera satisfaction au client. La première phase apparait particulièrement délicate puisqu'elle consiste à formaliser le souhait du client sans que celui-ci l'exprime clairement et complètement.

3.4. QUELQUES CONSTATATIONS

3.4.1. Recouvrement des phases

Les modèles précédents tendent à induire l'idée que les phases sont nettement identifiées et séparées. La réalité est plus complexe. Initialement durant chaque phase, des retours-arrière conduisent à modifier ou à compléter des décisions prises dans les phases précédentes. Il y a donc nécessairement recouvrement des phases comme l'indique la figure suivante [HATLEY- 87]. Ainsi, par exemple, la conception débute sans que la spécification ne soit complètement achevée.

Effort S p é c i f i c a t i o n conception

Effort

Spécification

conception

réalisation

test

Effort S p é c i f i c a t i o n conception réalisation
c a t i o n conception réalisation t e s t Temps -Figure 3.7- Recouvrement
c a t i o n conception réalisation t e s t Temps -Figure 3.7- Recouvrement

Temps

-Figure 3.7- Recouvrement souhaitable des phases.

Cette figure montre que toutes les phases débutent presque simultanément mais avec un effort qui varie en fonction de la progression. Entre autres, on peut remarquer que la phase de test débute très tôt. En effet, durant les premières phases, l'objectif est de préparer les critères et procédures de test et de validation. Ceci peut conduire à prendre rapidement des décisions particulières en conception, ou à la nécessité de développer un système de test. De même, il est habituel de constater que les spécifications ne sont que rarement achevées car des évolutions apparaissent côté demandeur.

Ch 3 - CYCLE DE DEVELOPPEMENT D’UN SYSTEME

3.4.2. Coût de correction des erreurs

La réduction des coûts et délais passe par la réduction des erreurs. Or il est aisé de comprendre que les erreurs détectées très tard dans le cycle de vie et en particulier durant la production et le fonctionnement sont difficiles à cerner et à corriger. Elles sont aussi d'autant plus coûteuses qu'elles peuvent concerner des décisions premières essentielles: spécifications, performances, besoin. La figure ci-après illustre le coût exponentiel de la correction des erreurs.

Coût Echelle log 10 000 Coût de corrections 1000 100 10 1 0.1 Instant de
Coût
Echelle log
10 000
Coût de corrections
1000
100
10
1
0.1
Instant de détection des erreurs
Spécification
conception
Réalisation
Production
Exploitation

-Figure 3.8- Courbe du coût de correction des erreurs.

Les erreurs de réalisation se détectent rapidement et se traduisent par une correction au niveau de la conception détaillée. Les erreurs détectées en industrialisation production sont plus complexes et impliquent une mise en cause de la conception préliminaire et même certaines spécifications. Les erreurs observées durant l'exploitation sont particulièrement graves car elles concernent une mise en cause de l'adéquation du produit au besoin.