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èses1. 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

XX

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 61850

• 2007 : 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 Exigences Gé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

BarrageNiveau 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: 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

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éfinitionUn 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éfinitionUn 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éfinitionUn 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

Partiesprenantes

Validation

Démarrage

SND avancée

SCP avancée

Très rares

Rares

Très fréquents

Experts domaine

Experts domaine

Gestionnaires

Utilisateurs

Utilisateurs

Revues

Historique du domaine

Revues

Historique du domaine

Produit final

Programmationen é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.