sur des consoles, en le noir salon : nul ptyx, insolite vaisseau d’inanité sonore,
DESCRIPTION
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é ). - PowerPoint PPT PresentationTRANSCRIPT
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.