EPSP

1
Sur des consoles, en le noir Salon nul
ptyx, Insolite Vaisseau dinanité sonore, Car le
Maître est allé puiser de leau du Styx Avec tous
ses objets dont le Rêve shonore. (S. Mallarmé)
Lobservation scientifique est toujours une
observation polémique  elle confirme ou infirme
une thèse antérieure, un schéma préalable, un
plan dobservation elle hiérarchise les
apparences  elle transcende limmédiat  elle
reconstruit le réel après avoir reconstruit ses
schémas. (G. Bachelard, Le nouvel esprit
scientifique)
2
EPSP

• Éléments les Plus Stables en Premier

par Ivan Maffezzini 22 février 2006
3
Plan

• Pas de plan

4
Les questions qui nous obsèdent
Dans la recherche en ingénierie des exigences,
comment sortir des mots sur les mots avec des
mots non empruntés à des écrits qui maltraitent
les mots ? (Anonyme de XXIe siècle)
Dans un travail dans un domaine industriel,
comment aller au-delà de lapplication des
méthodes qui ont plus ou moins bien fonctionné
( meilleurs  pratiques) pour extraire des
connaissance utiles pour lenseignement et la
recherche? Pour comprendre ?
5
Buts

• Présenter
• Une nouvelle (?) méthode pour aborder le
  développement et en particulier le génie des
  exigences
• Avec des bémols (situation)
• Et un concept subsidiaire (cadenassage sémantique)

6
Hypothèses

• Plus une méthode est restreinte plus elle est
  efficace (pour EPSP aussi !).
• Lefficacité dune méthode est inversement
  proportionnelle au nombre de domaines quelle
  couvre (et couve).
• Les domaines en premier
• La progression des mots aux bits dépend, avant
  tout, du domaine
• Le substrat le plus important inter-domaines est
  le langage naturel
•  Aidé , éventuellement, par des notations comme
  UML

7
Méthodes

• Méthodes en GL dépendent
• Du domaine
• De létat de la techniques
• Des caractéristiques et des capacité du personnel
• Des normes
• De lorganisation
• Des contraintes économiques
• De

8
La situation

• Domaines (états, événements et autres machines)
• Problème, exigences
• Machine (états, événements, et autres machines)
• solution
• Organisation (responsable de régler le problème)
• Procédures, tâches
• Description des exigences
• Paradigmes cachés
• Qui pilotent les choix non justifiables
  rationnellement (idéologie)
• Économie
• Conditionne

9
Domaine (1/2)

• Une partie du monde (réel enveloppé dans le
  langage) doté dune certaine autonomie du point
  de vue fonctionnel et/ou organisationnel (au
  moins en ce qui concerne lautomatisation)
• Un domaine moindrement complexe peut être
  subdivisé en domaines
• Tous les domaines ninteragissent pas
  nécessairement avec la machine.

10
Domaine (2/2)

• Exemple de domaines dapplication
• Protection dans centrales, assistance à la
  navigation maritime, supervision/contrôle des
  radars, traitement de textes, banque
• Exemple de domaines (?) de support
• Temps réel, systèmes critiques, contrôle
  commande, systèmes interactifs, exigences (??)

11
Notre point de référence
Phénomènes privés de la machine
Exigences
Phénomènes privés du domaine
Phénomènes partagée
X
X
X
X
X
X
X
X
Causaux Demandables
X
Domaines
Machine
X
X
X
X
X
X
M. Jackson, The Meaning of Requirements (annals
of S/W Engineering 1997)
12
Dans notre domaine ALCID
13
ALCID histoire

• 1980 GTPNA I
• 1987 Début développement (ALCID)
• 1989 Premier poste automatisé
• 1999 GTPNA II
• 2004 Choix IEC 61850
• 2007 Début conception ALCID II
• 2009 (?) Premier nouveau poste

14
Méthode

• Nette séparation des exigences (génie des
  exigences) du reste (génie du logiciel)
• Avec une souillure (?)
• Approche itérative et incrémentielle dans le
  génie des exigences

15
Artefacts ALCID II (à linterne, avant loctroi
du contrat)

• Plusieurs études
• Description des concepts du domaine (204 pages)
• Principe dopération (IEEE 1362)
• Trois documents (de lordre de 60 pages chacun)
• Spécification des exigences du système (145
  pages)
• Spécification des exigences logicielles
• Quelques documents
• Description de la conception des BD
• Deux documents

16
Progression vers la précision
Génie des Exigences
Génie logiciel
Description de la conception des BD
Principes dopération
Études
Exécutable
Exigences du système
Exigences logiciel
Description des concepts
MUR
17
Dangers quon a voulu éviter

• Mise à lécart du problème
• Confondre les exigences du domaine avec celle
  imposées à la machine
• Mise au centre des utilisateurs
• Cas dutilisation
• Perte de maîtrise à cause de trop dambiguïté

18
De ALCID I à ALCID II

• Une exigence non fonctionnelle (privée à la
  machine)
• Interopérabilité
• Exigences induites
• Déplacement de fonctions
• Ajout de domaines
• Ajout de fonctions
• Contrainte
• Pas de changements (ou presque) pour les
  utilisateurs

19
Cadenassage sémantique (1/3)

• Fermeture quune machine opère sur la
  signification des termes de la langue du domaine
  (fermeture de toutes les portes nayant pas été
  réifiées dans la machine Algorithmes)
• À opposer à
• Appauvrissement sémantique opéré par une
  description en langue naturelle des exigences du
  domaine
• Proche (mais pas la même chose)
• Description formelle

20
Cadenassage sémantique (2/3)
Baie James
Niveau deau (énergie potentielle)
Barrage
M1
Niveau deau BCD
M2
M3
Niveau 37,3
Montréal
21
Cadenassage sémantique (3/3)

• Lavancé des machine diminue la liberté
  dinterprétation et donc favorise lintroduction
  de nouvelles machines
• Toujours moins de domaines sans machines
• Le niveau de cadenassage influence les méthodes
  de développement
•  Le logiciel est un domaine de grands
  changements et instabilité  (Larman) Non
  domaines toujours moins  S/W free 

22
Exemple de fiche (1/4)

• Nom Rapports hors-normes essais électriques
• Identificateur Ex-F-023
• But Produire des listes sur les appareils dont
  les essais électriques ont dépassé certaines
  valeurs limites.
• Événement déclencheur
• X IPM Rapport Rapports normalisés
  Rapports hors normes
• Automatique
• De EvaBrod Vers à définir
• Type de fonction Principale
• X Réutilisable Consulter SER
• Degré de stabilité Haut
• Degré de nécessité Essentielle
• Degré de satisfaction Moyen

23
Exemple de fiche des exigences (2/4)

• Description
• 1. lire une ligne d'essai dans la table des
  essais
• 2. chercher les mesures saisies lors de cet essai
  dans la table des mesures
• 3.Pour chaque mesure lue, chercher la valeur
  tolérée dans la table des moyennes
• 4. Si la mesure dépasse la valeur tolérée alors
  l'appareil est hors-normes
• 5. L'écart équivaut au ratio (valeur mesurée /
  valeur tolérée) 100

24
Exemple de fiche des exigences (3/4)

• Intrants
• Tables des normesTables des essais et des
  mesuresTables des inventaires.
• Extrants vers la BD NIL
• Extrants vers l'utilisateur rapport
• Fabricant et type de l'appareil,
• Tension et courant,
• numéro d'exploitation,
• date de l'essai et code de l'essai,
• mesures, valeurs tolérées,
• écarts entre la valeur tolérée et la valeur
  mesurée

25
Exemple de fiche des exigences (4/4)

• Mises en garde.
• Les appareils doivent être regroupés par code de
  responsabilité et n de poste.
• Commentaires
• Pour savoir quelles sont les mesures qui sont
  prises en compte dans les rapports hors-normes,
  référez vous à la section qui porte sur les
  statistiques (section 4.3)

26
Stabilité(dans les domaines)

• But
• permettre des généralisations méthodologiques
  inter-domaines
• Quoi
• Un indication du nombre des changements attendus
  pour la durée de vie
• Fonction de lexpérience passé et des
  caractéristiques du domaine
• Métriques
• ?????

27
Zones de stabilité(dans les domaines)
Ceinture de
Éléments
Noyau dur
Flottants
protection
Librement inspiré de Lakatos
28
Noyau dur (ND)

• Définition
• Un ensemble dexigences, de contraintes, dobjets
  ou dobjectifs que les parties prenantes
  considèrent stables pendant la durée de vie de la
  machine
• Mobile
• Avoir des points de vue solides pendant tout le
  CV
• Favoriser le creusage des problèmes
• Introduire tôt les  détails  importants pour
  comprendre le problème
• Favoriser lentrée de nouvelles personnes dans le
  projet
• Choix difficile paradigmes cachés et intérêts
• Objection rend difficiles les changements
  radicaux
• ND vide domaine de recherche ou pauvreté de
  lanalyse
• Tout dans le ND (rare) définition formelle des
  interfaces, rigidité des méthodes, développement
  piloté par les gestionnaires

29
Ceinture de protection (CP)

• Définition
• Un ensemble dexigences, de contraintes, dobjets
  ou dobjectifs ayant uns stabilité satisfaisante
  dans la partie initiale mais une grande
  probabilité de changer par la suite
• Mobile
• Protéger le ND des changements abrupts
• Donner une certaine assurance initiale
• Objection définition trop vague et trop
  dépendante déléments subjectifs

30
Éléments flottants (EF)

• Définition
• Un ensemble dexigences, dobjets ou dobjectifs
  qui naissent, varient, meurent tout au long du CV
• Mobile
• Tenir compte des changements et des instabilités
• permettre des développements agiles (mêmes
  extrêmes !)
• Objection Pour réaliser une machine il faut que
  les EF cessent de flotter !
• Commentaire Les contraintes ne sont pas parmi les
  EF

31
Approche pour les exigences

• Fondé sur la stabilité (pour ne pas faire du (ad
  hoc)
• et non
• sur les fonctionnalités
• sur la qualité
• sur la nécessité
• sur limportance
• sur les priorités
• Dans un cadre itératif et incrémentiel
• Donner des éléments pour délimiter les  mini
  projet  UP
• CVL
• Fonction du poids des trois cercles
• Du classique (seul ND) au  jongleur  (seuls
  EF)
• Parenté avec MCEF avec laquelle elle peut
  cohabiter

32
Artefacts (1/5)

• Spécification du ND (SND)
• Spécification de la CP (SCP)
• Description des EF (DEF)
• Ordre naturel du plus stable au moins stable
• Les trois artefacts nemploient pas
  nécessairement la même notation

33
Artefacts (2/5)
Changement après livraison
Début
Parties prenantes
Validation
Revues
Démarrage
Experts domaine
SND
Très rares
Historique du domaine
Experts domaine
Revues
SND avancée
Rares
SCP
Gestionnaires
Historique du domaine
Utilisateurs
Programmation en équipe
DEF
SCP avancée
Très fréquents
Utilisateurs
Produit final
34
Artefacts SND (3/5)

• SND versus Document de définition du système
  (DDS) (Swebok)
• Il ne sagit pas de définir les exigences
  système de haut niveau
• mais
• Spécifier les éléments stables avec un maximum de
  détail
• Approche verticale versus horizontale
• Pas besoin de détails ultérieurs pour ce quil
  aborde
• Pas toutes les exigences comme DDS
• Possibilité de mise en uvre directe
• programmation extrême
• Dans un environnement fortement cadenassé SND
  contiendra les référence aux spécs des interfaces
• SND nest pas une architecture fonctionnelle

35
Artefacts SCP et DEF (4/5)

• SCP
• Plus agile que SND mais même structure
• Rarement des contraintes et des objectifs
• Surtout exigences (optatif de Jackson)
• Peut être vide
• Domaine très cadenassé
• DEF
• Ce nest pas une spéc.
• Souvent même pas imprimé
• Pour IPM références à des protos
• Jamais des contraintes
• Rarement des objectifs

36
Artefacts (5/5)

• Approche GL (UP etc.)
• description et ensuite spécification
• Notre approche
• Spécification (SND) et ensuite description (EF)
• Formalisme et détails dictés par
• Indépendance de la machine à réaliser
• Ne sont pas liés au moment de lécriture dans le
  projet
• Sont liés à la compréhension du domaine

37
Caractéristiques de la méthode

• Absence de raffinement dun document à lautre
• fini (ou presque) avec quel niveau de détail ?
• Exigences selon trois spirales dans la spirale
  du développement
• Développement fondé sur larchitecture
• Importance des documents en langue naturelle
• Fondée sur lhypothèse dun cadenassage toujours
  plus grand
• Adaptable à nimporte quel domaine (sic!)
• Applicable à la recherche pure comme à la
  production à la chaîne

38
Conclusion que faire ?

• Raffiner lapproche
• Mieux définir les concepts
• Appliquer lapproche dans des projets
  denvergure et de domaines différents
• Intégrer à lapproche de Jackson
• laisser tomber.