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)

EPSP Éléments les Plus Stables en Premier par Ivan Maffezzini 22 février 2006

Plan Pas de plan

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 ?

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)

Hypothèses 1.Plus une méthode est restreinte plus elle est efficace (pour EPSP aussi !). 2.L’efficacité d’une méthode est inversement proportionnelle au nombre de domaines qu’elle couvre (et… couve). 3.Les domaines en premier La progression des mots aux bits dépend, avant tout, du domaine 4.Le substrat le plus important inter- domaines est le langage naturel « Aidé », éventuellement, par des notations comme UML

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…

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

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.

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 (??) …

Notre point de référence X DomainesMachine X X X X X X X X X X X X X M. Jackson, The Meaning of Requirements (annals of S/W Engineering 1997) X Phénomènes privés de la machine Phénomènes partagée Phénomènes privés du domaine Exigences Causaux Demandables

Dans notre domaine : ALCID

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

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

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

Progression vers la précision Principes d’opération Exigences du système Exigences logiciel Exécutable Génie des ExigencesGénie logiciel Études Description des concepts Description de la conception des BD MUR

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é

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

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

Cadenassage sémantique (2/3) Baie James Barrage Niveau d’eau (énergie potentielle) Niveau d’eau BCD M1 M2 M3 Montréal Niveau = 37,3

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 »

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: EvaBrodVers: à définir Type de fonction: Principale [X] Réutilisable : Consulter SER Degré de stabilité : Haut Degré de nécessité : Essentielle Degré de satisfaction : Moyen

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

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

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)

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 – ?????

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

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 difficile paradigmes cachés et intérêts Objection rend 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

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 Objection définition trop vague et trop dépendante d’éléments subjectifs

É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 !) Objection Pour réaliser une machine il faut que les EF cessent de flotter ! Commentaire Les contraintes ne sont pas parmi les EF

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

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

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

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

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

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

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

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.