Pourquoi Business Spirit ?

Problématique adressée

L'idée originelle est née de constats simples :

• Un projet n'abouti qu'à partir d'un certain nombre d'itérations entre spécifications du besoin et résultat. 
• Chaque itération à un coût et un délai important car elle mobilise séquentiellement tous les types de compétences.
• Les utilisateurs et les techniciens communiquent bien lors des phases de spécifications mais très mal lors des études plus détaillées. Ils ne se rejoignent qu'en présence d'un résultat concret: le logiciel.
• Une tendance récente dite "méthodes Agiles" consiste à limiter les objectifs et à essayer de les approcher au plus vite afin de limiter l'impact des erreurs. Ceci constitue bien une réponse aux problèmes évoquées précédemment mais même sur un scope réduit le problème reste entier: il faut avoir réalisé pour valider.
• Il existe une offre importante d'outils pour Les phases techniques d'un projet (outils case, IDEs, etc.). Ils sont abondamment utilisés mais s'adressent uniquement aux techniciens et interviennent donc en aval du problème.
• Il n'existe peu d'outils pour les phases amont.
    Que chaque étape d'un projet aboutisse à quelque chose de concret.
• Les outils case (uses cases UML par exemple) ne permettent de traiter la spécification du besoin que très superficiellement. Ils permettent d'identifier un besoin mais n'ont aucune valeur ajoutée significative dans la matérialisation de ce besoin autre que celle de faire partager des objectifs communs entre utilisateurs et développeurs.
• Les outils de spécification sont rarement utilisés. Ces outils sont des outils de traitement de texte non formels qui permettent de structurer les documents et de suivre l'avancement des tâches décrites. De fait il ne sont utilisés que lorsque la complexité d'un projet est importante pour organiser et suivre les objectifs. Il n'ont cependant aucune valeur ajoutée sur la production du logiciel par lui même. Sur de petits projets par exemple, le besoin d'organisation et de suivi étant réduit, ils ne sont pas du tout utilisés et un simple traitement de texte leur est préféré.
• Il n'existe aucun outil sur le marché pour répondre au problème.

Clé du problème

L'absence de solution vient du simple fait qu'il existe une étape clé dans la chaîne de production du logiciel qui reste une prestation purement intellectuelle et pendant laquelle tout bascule : la phase d'étude technique (la conception).

La phase de conception peut schématiquement se décrire ainsi :

• Les utilisateurs fournissent des spécifications qui décrivent une vision dynamique des fonctions escomptées (modèle dynamique)

• Le concepteur étudie ces spécifications pour identifier les concepts manipulés par le métier (classes)
• Il conçoit un modèle de classes qui vient mettre en relation tous les concepts identifiés (modèle statique) et valide le résultat de son travail par la capacité de ce modèle à supporter les sollicitations dynamiques décrites dans les spécifications.
• Il adapte ce modèle théorique aux capacités et contraintes de l'environnement technique cible (dénormalisations, contraintes d'architecture, de performances, ...) pour obtenir quelque chose de réalisable (modèle d'implémentation)
• S'appuyant sur ce premier modèle, il décrit à l'aide d'autres modèles les composants qui permettrons d'interagir avec ce premier modèle pour permettre la mise en oeuvre de la dynamique décrite dans les spécifications (interfaces graphique, couches de communication, persistance, sécurité, ...).

De façon plus synthétique, le concepteur décortique le besoin fonctionnel exprimé pour trouver les concepts sur lesquels il s'appuie. Ensuite à partir de ces concepts, il imagine une solution technique qui permet de constituer un logiciel correspondant à ce besoin (de la dynamique métier, il descend vers les concepts et des concepts il remonte vers une dynamique de composants techniques équivalente).

Les outils de modélisation utilisés dans cette phase permettent de recevoir et de représenter le résultat des réflexions du concepteur. Ils lui servent d'aide mémoire et lui permettent de communiquer plus facilement avec d'autres techniciens mais ne lui sont d'aucun secours pour trouver des solutions. 

En sortie de cette phase :

• Il n'y a aucune traçabilité possible entre les spécifications fonctionnelles et le résultat obtenu. Cette correspondance n'est restée que dans l'esprit du concepteur.
• Les modèles essentiels (modèles statiques) ne peuvent pas être approuvés par les utilisateurs car la vision dynamique n'y est pas présente, les concepts abordés et la façon de les représenter sont trop éloignés de la réalité quotidienne du métier.
• Il y a rupture de la communication entre le monde fonctionnel et celui des techniciens de l'information (la communication n'est plus possible que dans un seul sens).
• La validité des spécifications et des modèles ne pourra être démontrée qu'après réalisation totale ou partielle du logiciel correspondant. C'est à dire seulement après avoir dépensé du temps et de l'argent.

Quelque soit la taille du projet la problématique reste entière, même en l'absence de conception formelle, il faut attendre le résultat final pour se construire des certitudes.

Conclusion

Même lorsque l'on pense avoir tout étudié et tout prévu, devant la réalité du terrain il faut admettre que la convergence vers une solution optimale reste basée sur un approche empirique par tâtonnement. Ceci est inéluctable du fait même que la qualité essentielle de  l'intelligence de l'homme est de savoir changer d'avis.
 L'analyse des différentes étapes d'un projet démontre clairement que l'étape clé est celle de la conception.

L'analyse des outils existants sur le marché démontre quand à elle que cette étape est la seule qui ne soit pas automatisée à ce jour. 

Face à ces constats, nous nous somme fixés un objectif. Celui de fournir un outil qui permette de changer souvent d'avis et donc de converger rapidement vers la solution optimale à moindre coût :

Un outil qui permet  de passer directement des spécifications à un résultat concret.

C'est à dire un outil qui automatise simultanément les phases de conception et de réalisation.