eric.lemerdy

Last week, we used TDR^[1] to help us understand a problem and the solution finally emerges.

The problem

This is an eclipse RCP application that uses the well known MVC pattern. The data model is hierarchic and several editors can be opened at different levels. The problem is that we have some transversal data that can be viewed along the tree structure. How can a view be always updated against users editions ?
Considering the following structure:

• root
  • node1 - use transverse data X, Y
  • node2 - use transverse data X, Z

Description of the scenario:

1. Editor on node 1 is opened
2. Editor on node 2 is opened
3. Some changes are made in editor 1 on transverse data X
   The editor is "dirty".
4. Some changes are made in editor 2 on transverse data X
   The editor is "dirty".
5. Editor 1 is saved.

How can the changes on transverse data X made in the first editor be reflected in the second one ?

Solving the problem

We shortly came to the fact that an event should be fired when the data model is changed. Editors are registered to listen for those events to make them aware that they should reflect changes. This is not the complicated part of the problem.
The "reconciliation" algorithm that the editor should implement is not trivial.
This was the time to stop trying to code it, step up the team in front of a blank white board and use TDR^[1] to help us specify with some examples.

The white board

After a short discussion, we found a notation to represent data attached to an editor:

Saved

saved data before any edition

Modified

modified data during edition. This is typically a bean that is tied on UI components

Data model

the new data model that is embedded in the event to alert editor that data changed

Output

the output of the algorithm: the reconciliated data

(Our data are indexed list of objects.)
Then we started to scratch on white board. The white board has been "saved" on this sheet:

Then we set up test cases from simple to complex (1.). For each of them, we specify data (2.) as couples: C_A, D_A (Clé (key), Data) and C_A', D_A' for modified data.
The final algorithm emerges in the box (3.). The result is simple:

• if the "Saved data" is the same than "Modified data"
  • "Output" should be set to "Data model"
• otherwise
  • "Output" should be set to "Modified data"

Big letters in output column learns us that algorithm applied for list comparison can be also be applied for list elements themselves when the case become more complex.

Lesson learned

• TDR^[1] is helping emerging conception
• Examples from a TDR^[1] session are capitalized in unit tests (in our case)
• This TDR^[1] session became the technical documentation (because the client want a technical documentation)
• Our examples remains generic because we found it useless to represent real data (a collection of objects
• TDR^[1] is helping to make the implementation of a solution simpler
• The client were intrigued to see programmers out of their usual 'behind-the-screen' position ! It helps our team to show what we were working on.

---

[1]: Test Driven Requirements ou spécifications dirigées par les tests.

A l’extérieur de votre organisation est le chaos, les technologies naissent et meurent en fonctions de facteurs incontrôlés et incontrôlables (les effets de mode, la réglementation en vigueur, la volatilité des marchés, etc.).
A l’intérieur de votre organisation règne l’ordre, la maîtrise technologique, mais c’est aussi le royaume du « legacy-qui-marche-bien-pourquoi-on-le-changerait ». L’obsolescence des applicatifs vous guette, vous êtes fan des nouvelles technologies mais l’entropie de votre organisation ressemble à des sables mouvants qui ensevelissent toute action pour tenter d’y échapper. Comment alors stabiliser la technologie alien qui serait propre à sauver votre organisation de la décrépitude numérique ?
Il existe pour cela la méthode des Technology Readiness Levels (TRLs) pour vous sauver. C’est une méthode qui permet d’évaluer une technologie nouvelle pour la qualifier apte à supporter le développement de vos nouveaux produits. Voici les degrés d’avancement de la méthode (Origine: DOD (2006), Defense Acquisition Guidebook) :

• TRL 1: Principes de base observés et signalés
• TRL 2: Concepts et/ou applications de la technologie formulés
• TRL 3: Fonction critique analysée et expérimentée et/ou « proof-of-concept » la caractérisant
• TRL 4: Validation de l’artefact produit en conditions expérimentales
• TRL 5: Validation de l’artefact produit en conditions de pré-production
• TRL 6: Démonstration du modèle du système/sous-système ou du prototype en conditions de pré-production ou de production
• TRL 7: Démonstration du prototype du système en conditions de production.
• TRL 8: Complément du système résultant et « qualification » pour la production à travers des tests et des démonstrations (environnement de pré-production ou production)
• TRL 9: Exécution du système résultant « prouvée » à travers le succès de la version en production

Plus on avance dans la méthode et moins on doit avoir de technos candidates qui passent les conditions nécessaires. C’est un peu comme cela que fonctionnent les organismes de recherche qui ne font pas aboutir toutes leurs recherches avec une application fonctionnelle et encore moins industrialisable.
Cette méthode a été développée par la NASA. J’ai adapté les termes à un produit logiciel. Par exemple, citons cette analogie : leur environnement de pré-production est le sol et celui de production de l’espace. Je pense que si c’était le cas en informatique, il y aurait sûrement plus de candidats à aimer la prod…
Ce processus est « outillé ». Un calculateur d’avancement réalisé avec Excel permet de suivre l’avancement au sein de la méthode. Attention, les couleurs piquent un peu les yeux… On peut décider de s’évaluer au choix avec le TRL, le Manufacturing Readiness Level et les Programmatic Readiness Level. Cela ajoute plus ou moins de questions au formulaire pour calculer l’avancement.
Voici la fiche de ce programme excel à télécharger (et sa documentation pdf - 16 pages)

Cette méthode est utilisée dans la société de ma mission actuelle comme base au processus de travail de l’équipe R&D. Ils ont des jalons à chaque degré avec des documents types à produire. Cette méthode qui a fait ses preuves aide effectivement à atteindre l'objectif qu'elle se fixe. On ne peut malheuresement pas tout rendre agile. Par contre l'agilité peut permettre de gagner en rapidité sur les "proof-of-concept" ce qui peut augmenter la taille de l'échantillon des technologies candidates et ainsi renforcer la fiabilité et la pertinence du choix final.