Sur des consoles, en le noir Salon : nul ptyx, Insolite Vaisseau d’inanité sonore,

1. Sur des consoles, en le noir Salon : nul ptyx, Insolite Vaisseau d’inanité sonore, Car le Maître est allé puiser de l’eau du Styx Avec tous ses objets dont le Rêve s’honore. (S. Mallarmé) L’observation scientifique est toujours une observation polémique ; elle confirme ou infirme une thèse antérieure, un schéma préalable, un plan d’observation […] elle hiérarchise les apparences ; elle transcende l’immé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 l’application des méthodes qui ont plus ou moins bien fonctionné (« meilleurs » pratiques) pour extraire des connaissance utiles pour l’enseignement 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 !). • L’efficacité d’une méthode est inversement proportionnelle au nombre de domaines qu’elle 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 l’organisation • 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é d’une certaine autonomie du point de vue fonctionnel et/ou organisationnel (au moins en ce qui concerne l’automatisation) • Un domaine moindrement complexe peut être subdivisé en domaines • Tous les domaines n’interagissent pas nécessairement avec la machine.

10. Domaine (2/2) • Exemple de domaines d’application • 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 Machine X Domaines 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 (à l’interne, avant l’octroi du contrat) • Plusieurs études • Description des concepts du domaine (204 pages) • Principe d’opération (IEEE 1362) • Trois documents (de l’ordre 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 d’opération Études Exécutable Exigences du système Exigences logiciel Description des concepts MUR

17. Dangers qu’on 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 d’utilisation • Perte de maîtrise à cause de trop d’ambiguï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 qu’une machine opère sur la signification des termes de la langue du domaine (fermeture de toutes les portes n’ayant 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 d’eau (énergie potentielle) Barrage M1 Niveau d’eau BCD M2 M3 Niveau = 37,3 Montréal

21. Cadenassage sémantique (3/3) • L’avancé des machine diminue la liberté d’interprétation et donc favorise l’introduction 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 normes·Tables des essais et des mesures·Tables 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 l’expé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 d’exigences, de contraintes, d’objets ou d’objectifs 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 l’entrée de nouvelles personnes dans le projet • Choix difficileparadigmes cachés et intérêts • Objectionrend difficiles les changements radicaux • ND vide : domaine de recherche ou pauvreté de l’analyse • 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 d’exigences, de contraintes, d’objets ou d’objectifs 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 • Objectiondéfinition trop vague et trop dépendante d’éléments subjectifs

30. Éléments flottants (EF) • Définition Un ensemble d’exigences, d’objets ou d’objectifs 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 !) • ObjectionPour 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 l’importance • 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 n’emploient 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 s’agit 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 qu’il 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 n’est 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 n’est 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 d’un document à l’autre • fini (ou presque) avec : quel niveau de détail ? • Exigences selon trois spirales dans la spirale du développement • Développement fondé sur l’architecture • Importance des documents en langue naturelle • Fondée sur l’hypothèse d’un cadenassage toujours plus grand • Adaptable à n’importe quel domaine (sic!) • Applicable à la recherche pure comme à la production à la chaîne

38. Conclusion : que faire ? • Raffiner l’approche • Mieux définir les concepts • Appliquer l’approche dans des projets d’envergure et de domaines différents • Intégrer à l’approche de Jackson … laisser tomber.