Systémique

Le fonctionnement global de notre « système » sociétal consiste trop souvent à simplifier à l’extrême toutes les analyses à un point tel qu’elles tendent à devenir absurdes. Constatez-le avec les médias et l’information qui est « débitée » en tranches continues tous les jours et vous aurez un petit aperçu des dégâts engendrés par l’éviction de l’intellect de notre quotidien.

Convoquons à nouveau notre intellect et posons nous la question suivante : la systémique a-t-elle été oubliée ou n’a-t-elle jamais eu prise dans notre société ? Je ne suis pas suffisamment qualifié pour répondre à cette question, je ne fais que constater l’absence de la systémique dans notre vie de tous les jours. Mais qu’est-ce que la systémique ? Inutile de réinventer la roue, fions nous au Larousse qui nous indique ceci :
« Se dit d’une approche scientifique des systèmes politiques, économiques, sociaux, industriels qui s’oppose à la démarche rationaliste en abordant tout problème comme un ensemble d’éléments en relations mutuelles. Cette démarche s’appuie sur des découvertes en cybernétique, théorie de l’information, biologie, linguistique et anthropologie ». Je vous conseille la consultation du site de la « systémique attitude » dont la lecture m’a paru très enrichissante (http://www.systemique.com/).

Hors donc, la démarche cartésienne que les français pratiquent excellemment s’oppose presque à la systémique car la relation de cause à effet y est bien moins visible et demande des degrés d’abstractions que nous ne voulons plus (que nous ne savons plus ?) invoquer car trop couteux en temps, en énergie et en dépenses « neurales » (ce bulbe que tout ce qui nous entoure nous engage à solliciter le moins possible !).

Prenez l’exemple de la route. Je roule tous les jours au milieu d’une cohue de voitures et au fils des années qui s’écoulent, j’ai de plus en plus la sensation que la bêtise domine de plus en plus le paysage. Tout se déroule comme si nos cerveaux étaient débranchés lorsque nous conduisons. Tel véhicule qui roule à 60 km/h sur une autoroute, tel autre qui slalome entres les voitures, tel autre qui freine de manière incompréhensible et inconsidérée, etc … Pour lutter contre les dangers évidents de la route, les infractions permanentes au code de la route et les incivilités nous avons mis en place tout un arsenal dissuasif de lois, de contrôles, de répressions. Force est de constater que la route n’est jamais assez sécurisée et continue à tuer des milliers de personnes tous les ans ! Pire que cela, nous savons tous que si nous supprimions les radars ou que la présence policière se faisait moins sentir, la quantité de morts et de blessés remonterait en flèche. Nous traitons la conséquence, pas la cause en attaquant la problématique par sa partie apparente. D’aucun me répondrons qu’il manque le volet éducatif à « un système outrageusement répressif … » (ya tcha !!!). Je répondrais … et le civisme, comment l’acquérir ? Et la compréhension des mécanismes de base de la physique comment la faire rentrer dans les cranes ? Et la responsabilisation qui vous fait assumer vos actes, comment l’inculquer ? Et oui, dans un monde qui considère la culture Nabila comme une référence, qui nous apprends via les Chti que nous avons deux soleils, qui nous fait croire que la culture générale se résume à réciter par cœur des dates dans des jeux télévisés ou enfin qui a vu Corneille devenir au mieux un chanteur au pire un chien de dessin animé, ne nous étonnons pas que le système devienne incompréhensible en apparence. La systémique a été oubliée mais elle peu nous aider ! La résultante cumulative de tous nos actes, apprentissages, réflexions, inflexions qui ressurgie dans notre quotidien peut trouver quelques explications grâce à l’analyse systémique. Ce monde produit les conditions qui nous ramènent à la non maitrise de ce qui se déroule sous nos yeux sur la route. Comme nous avons décorrélé tous ces phénomènes les uns des autres (la chaine est longue entre les Chti et la route !!), alors il ne nous apparait pas de manière limpide les relations qui existent entre ce chauffard idiot, qui plus est incompétent et quelquefois ivre, et le monde d’inculture et de passivité que nous avons tous contribuer à créer.

Pourquoi est-ce que je vous « bassine » avec la systémique ? Parce que nous vivons dans le monde des TIC avec des problématiques qui relèvent de la systémique. Celle qui m’anime ici est le maillon « très » pauvre de nos processus de développements, la phase de test/validation/intégration qui est, pour moi, l’un des exemples paroxystique d’un manque d’analyse systémique. Qui n’a pas vécu au quotidien des arbitrages dans les développements logiciels qu’il anime ou auxquels il participe quasi systématiquement en défaveur des tests ? Combien parmi vous ne connaissent pas la réponse rituel de son manager : « mais tu ne te rends pas compte, cela coute beaucoup trop cher » ! Quand le développement logiciel va t’il murir suffisamment pour admettre une bonne fois pour toute les éléments suivants :

  • Le test devrait représenter 50% de l’effort en matière de développement
  • Le test devrait être tellement important que chaque développeur devrait avoir son testeur ou un mi-temps dédié à la réalisation de tests
  • Les impacts liés à une absence de tests sont présent dans toutes la chaine de valeur d’un produit et se manifestent partout y compris dans des notions intangibles comme l’image ou la réputation d’une entreprise
  • Un éditeur de logiciel qui n’intègre pas ces notions en 2014 s’assimile au constructeur automobile des années 1950 !
  • Tout ce qui permet d’améliorer la traçabilité, le suivi, la remontée d’informations dans un développement logiciel doit être mis en œuvre au plus vite dans le cadre d’une politique de tests

Bien que mes propos soient délibérément exagérés, tous les managers ont lu, entendu, rencontré des dizaines de fois des experts expliquant tous les mérites d’une véritable politique en matière de tests. Une majorité pourtant continue à ne pas agir et à ne pas investir dans ce domaine. Les raisons sont à la fois simples et presque ridicules :

  • Lorsque des ressources sont allouées aux tests, c’est rarement de manière pérenne (dans une organisation dédiée par exemple), avec des moyens matériels appropriés, avec un outillage adapté. Les effets de ces investissements sont alors long à venir et le couperet tombe : trop cher, trop long, nous avons mieux à faire
  • Une politique de test ne porte ses premiers fruits qu’au bout de longs mois d’efforts (12 à 18 minimum). Lorsque le processus à le temps de s’installer il se produit plusieurs phénomènes comme l’accumulation pour les tests unitaires, la consolidation des « maigres » outils installés et/ou développés in vivo et donc stabilisés par les équipes, la structuration d’un environnement de tests en fonction des moyens alloués, le changement des habitudes de productions au travers de PIC par exemple (impact fort sur le processus de développement), l’intégration en amont des chaines de delivery qui s’industrialisent, la transparence dans des newsletters ou des dashboards publics donnant de la visibilité à tous les acteurs de la vie de l’entreprise. Notez que le test relève d’une démarche complexe et globale qui inclus de nombreux aspects du développement logiciel (et je ne suis pas exhaustif). C’est cet effort qui est souvent arrêté en plein vol car jugé trop couteux !
  • La mesure du retour sur investissement se fait non seulement attendre mais restera toujours difficile à réaliser et incomplète … jusqu’à la bascule ! Au support (SAV, hotline, …) les outils qui permettent de relier les problématiques clients directement avec la politique de tests sont inexistants sauf à constater la baisse en volume des demandes clients. Il est toujours plus facile de ne pas faire l’effort de traçabilité car cela est moins « couteux ». Dans les services en charge du déploiement, les mêmes causes entrainent les mêmes effets et ainsi de suite ! La chaine de suivi et de remontée de l’information est rompue dès que le logiciel quitte les « chaines » de fabrication. Imaginons cinq minutes la même situation dans le monde automobile ! (ah, on m’informe que c’est pareil sic !)

En résumé j’affirme, du haut de l’incompétence et de la conviction qui caractérisent mes 25 années passées dans le monde du numérique, les points suivants à destination des managers et dirigeants de toutes catégories :

  • Investissez dans le test au-delà de tout ce que vous auriez imaginé. Pour moi désormais le ratio idéal en matière de constitution des équipes de développement est de 40-50% pour le test
  • Investissez dans des outils d’industrialisation des tests. Que ces outils soient légers, ouverts, lisibles et rapides à mettre en œuvre me parait la seule contrainte à respecter. Évitez les usines à gaz des marchands de rêves qui transformeront votre investissement en chausse trappe. Le but d’un outil consiste à se mettre au service de votre objectif, non pas d’exister pour absorber vos ressources au service de l’outil !
  • Transformez vos processus pour tenir compte du test quitte à réaliser beaucoup moins de développements. La vertu de ce travail vous obligera à faire de véritables choix. Nous développons beaucoup trop et souvent pour rien !
  • Cessez de poursuivre la recherche de la démonstration du ROI car vous n’êtes pas équipé pour le mesurer pleinement et personne ne l’est. Cette attente vous conduit vers de mauvaises décisions simplement parce que vous n’avez pas l’appareil de mesure approprié. Lorsqu’il n’y a plus d’électricité chez vous (plus de lumière, vos appareil électriques arrêtés, …) vous ne cherchez pas un voltmètre de 18ième génération pour prouver la panne électrique. Vous utilisez votre bon sens et vos capacités d’observations pour agir (aller voir le disjoncteur, appeler un expert, …). C’est identique pour le test, vos constats sont les bons, vos intuitions sont correctes alors suivez les, surtout lorsque vous êtes devant des évidences que vous n’arrivez pas à démontrer financièrement
  • De grâce arrêtez d’attendre du monde du développement logiciel un miracle qui n’arrivera pas ! Le miracle consiste à continuer à croire et à faire croire qu’un développement sans bug peut et doit exister. Ce monde est bien lointain et il dépend de nos efforts à investir dans l’intellect des individus, dans leur culture, dans leurs capacités intellectuelles. Tiens, la boucle viens de se refermer et le “système” nous montre à quelle point tout est intimement lié de bout en bout

En clair, appliquer les grandes règles de la systémique et adoptez une démarche factuelle mais résolument réfléchie qui tentera de tenir compte des effets de bords induits par la mise en place d’une véritable politique de tests.

Je conclurais par deux citations :

  • Jean Piaget : « L’intelligence est notre dernier recours quand nous ne savons pas comment faire face à une situation
  • Claude Lévi-Strauss, « L’humanité s’installe dans la monoculture; elle s’apprête à produire la civilisation en masse, comme la betterave. Son ordinaire ne comportera plus que ce plat. »

Note : c’est le physiologiste Ludwig von Bertalanffy qui est reconnu comme le fondateur de la science des systèmes. Après une série d’articles publiés en 1926 et 1930, il a énoncé sa « Théorie générale des systèmes » en 1947. Il en a exposé les bases fondamentales dans un ouvrage du même nom en 1973 chez Dunod. Voir http://en.wikipedia.org/wiki/Ludwig_von_Bertalanffy ou http://www.approche-systemique.com/sytemicien/precurseur/

Advertisements

Principe de simplicité

Le rasoir d’Ockham, connu également sous le nom de principe de simplicité ou principe de parcimonie s’énonce de manière simplifiée comme suit :

« Les entités ne doivent pas être multipliées par delà ce qui est nécessaire » (Guillaume d’Ockham – moine franciscain au XIVe siècle, http://fr.wikipedia.org/wiki/Guillaume_d’Ockham).

Dans la pratique cela consiste à ne pas utiliser de nouvelles hypothèses tant que celles déjà énoncées suffisent et utiliser à fond les hypothèses qu’on a déjà faites avant d’introduire de nouvelles hypothèses. Ceci paraitra d’une grande banalité mais force est de constater que dans de nombreux processus et méthodologies qui sont préconisées aujourd’hui, ce simple principe semble être en passe de tomber dans l’oubli.

Nous avons tous expérimenté les joies et les désillusions de toutes les méthodes qui devaient nous permettre de développer sans développer, de sortir nos produits sans rien faire, d’innover sans réfléchir, etc … J’avoue que j’exagère grandement car toutes les méthodologies, en particulier agiles, ont apporté leurs lots d’améliorations qui ont forcément laissées des traces dans nos organisations et dans l’esprit des individus. Le bilan est donc globalement positif mais très loin du « miroir aux alouettes » qui est continuellement martelé un peu partout.

La simplicité est donc à nouveau à l’ordre du jour dans un monde ou la réduction des dépenses, l’empreinte écologique, le retour au pragmatisme ont à nouveau la vedette.  Pour cela je vous engage à lire le post suivant http://lagestiondeprojet.com/2009/11/30/simplicite-ou-comment-reprendre-le-controle-de-nos-vies/ qui a le mérite de rappeler quelques éléments simples dans la gestion du quotidien.

Il est temps de reprendre le contrôle de nos équipes et de nos développements plutôt que de les confier à des gurus de SCRUM, XP, TDD ou RAD ! Comment faisions-nous avant pour ceux qui développent depuis plus de 20 ans ? La complexité des nouvelles technologies m’a-t-on opposé dernièrement ? Accroissement de la compétence moyenne des ingénieurs de développement est ma réponse. Ce que nous faisions il y a 20 ans, nous le conceptualisons différemment aujourd’hui et de manière tout aussi efficace pourvu que l’on accorde aux individus la place qui leur revient : celle de l’agilité ultime du cerveau ! Tous ces processus et méthodologies ont laissé croire que le développement logiciel pouvait se passer de compétences, d’implication, de volonté et d’investissements. Ce n’est pas ce que le Agile Manisfesto écrit ou préconise mais c’est ce que les « faiseurs de miracles » ont promu. Le résultat, malheureusement tangible à ce jour, c’est un métier qui n’a pas réussit à trouver l’écoute qu’il mérite. Je fais référence au travail des développeurs et technologues du logiciel qui sont encore vu comme de grands « bricoleurs » mais certainement pas comme des professionnels requérants des compétences très pointues et de plus en plus difficiles à acquérir.

Je fais un constat extrêmement simple : les projets qui réussissent sont réalisés par des équipes petites, soudées, fortement expérimentées et/ou formées ayant des objectifs simples avec un encadrement clair. Je fais un autre constat malheureusement simple lui aussi : tous les projets qui mettent en œuvre les méthodes agiles (ou qui le revendiquent) voient leurs effectifs grossir, les délais et les contenus non respectés, le désengagement s’installer car impliquant des processus déresponsabilisant !

Je terminerais par un exemple de simplicité qui m’a marqué voilà bien des années. C’est un échange qui a eu lieu entre Napoléon (1769 – 1821) et Laplace (1749 – 1827):

  • Napoléon : Monsieur de Laplace, je ne trouve pas, dans votre système mention de Dieu ?
  • Laplace : Sire, je n’ai pas eu besoin de cette hypothèse.
  • Devant les savants ayant déploré que Laplace fasse l’économie d’une hypothèse qui avait justement « le mérite de tout expliquer », Laplace répondit cette fois-ci à l’Empereur
  • Laplace : Cette hypothèse, Sire, explique en effet tout, mais ne permet de prédire rien. En tant que savant, je me dois de vous fournir des travaux permettant des prédictions

Les Métriques Software

Un support méthodologique pour la compréhension intrinsèque de la qualité des développements objets

Instinctivement, nous pouvons deviner que les « métriques du logiciel » impliquent des chiffres et des mesures des différents aspects du processus de développement logiciel. Si nous nous tournons vers la littérature, nous pouvons trouver plusieurs définitions, qui donnent une interprétation plus ou moins différentes du même terme.

Goodman (1993)[1] définit les métriques logicielles comme « l’application continue de techniques de mesures sur le processus de développement pour fournir des informations de gestion pertinentes et opportunes, ainsi que l’utilisation de techniques pour améliorer ce processus et ses produits ». Le champ est donc vaste mais le but concerne bien l’amélioration de tous les aspects de la réalisation des logiciels.

Grady (1992)[2] souligne pour sa part que les « métriques de logiciels sont utilisées pour mesurer des attributs spécifiques d’un développement logiciel afin de nous aider à prendre de meilleures décisions ». Cette définition met en évidence l’un des problèmes liés aux développements logiciels, le manque d’informations pour prévoir et évaluer les projets.

D’autres auteurs, comme Zuse (1991)[3], font une distinction entre « mesures logicielles » et « métriques logicielles » ! Cela implique que la mesure et la métrique sont des termes plus mathématiquement corrects lors de l’examen de la valeur empirique de différents objets mesurés dans le processus de développement logiciel. En outre, ils constatent qu’une métrique est un critère utilisé pour déterminer la différence ou la distance entre deux entités, par exemple la métrique d’Euclide, qui mesure la distance la plus courte entre deux points.

Parfois, nous trouvons des tentatives de classification des différents types de métriques logiciels. Une telle distinction est faite entre les mesures primitive et celle qui sont calculées. Les métriques primitives sont directement mesurables ou dénombrable, comme le comptage des lignes de code. Les métriques calculées utilisent une sorte de formule mathématique pour obtenir la valeur d’un attribut déterminé.

Pour différentier les mesures qui sont utilisés pour la prise de décision de haut niveau il est fait référence à des « métriques globales ». Cette expression renvoi à des informations sur la taille, le produit, et la qualité du développement qui influent sur la maintenabilité des logiciels. Cette première notion implique qu’il pourrait également y avoir des « métriques locales » ou « métriques de phase », plus liées à des cycles particuliers du développement.

En tout état de cause nous pouvons proposer de synthétiser la métrique software comme :

Une mesure de différents attributs du processus de développement logiciel dans le but d’obtenir des informations utiles et pertinentes pour améliorer l’efficience globale du processus de développement.

Je pense qu’il est important de reconsidérer la place de ces métriques dans nos processus de développement et qu’il faut appliquer les métriques en fonction des différents buts de mesure. Certaines métriques et méthodes de mesure sont plus utiles à une phase spécifique du développement logiciel :

  • Dans les phases préliminaires comme l’analyse des exigences et la conception du système
  • Dans la phase d’implémentation pour capturer le statut réel du projet afin d’en mesurer la progression
  • Dans la phase des tests dans la remontée du nombre de défauts ainsi que la densité de défauts

Il faut appliquer les métriques pertinentes selon les différentes exigences en matière d’objectifs de qualité du produit final. Si on évalue la convivialité du logiciel, par exemple, le degré de satisfaction des clients en termes de facilité d’utilisation est la mesure la plus parlante !

Enfin il faut appliquer les métriques en regard des différents rôles des membres d’une équipe de développement. Les développeurs choisissent des métriques comme l’effort contribué au projet, la durée estimée pour leur tâche, la complexité du module sur lequel ils travaillent, le nombre de lignes de code produit ou la densité de défauts. Le chef de projet mettra l’emphase sur la complexité ou le volume estimé du projet afin de planifier les tâches, les dates et l’effort global prévus. Le management de l’entreprise s’intéresse plutôt aux métriques incluant la valeur commerciale du produit final en fonction de l’investissement avant le projet, le degré de satisfaction des clients, la comparaison entre le temps prévu et le budget disponible et les valeurs obtenues au cours de la construction.

Le sujet est approfondi dans un document que vous pouvez télécharger.


[1] Goodman, P., « Practical implementation of software metrics”, 1993, McGraw-Hill publication

[2] Grady, R.B., « Practical software metrics for project management and process improvement », 1992, Prentice Hall

[3] Zuse, H., « Software complexity – measures and methods », 1991, Walter de Gruyter & Co

Agilité : Mythe ou Réalité

Adopter la bonne organisation de développement logiciel est ce possible ?

En 1975, Frederick Brooks a écrit un livre sur la gestion de projets informatiques intitulé « The Mythical Man-Month (le mythe du mois-homme) ». Dans cet ouvrage, il démontrait brillamment qu’ajouter des personnes à un projet de développement le ralentissait au lieu de l’accélérer. La raison était mécanique et il démontrait que l’ajout de nouvelles personnes aboutissait à une augmentation non linéaire du temps consacré à la réalisation.

Cinq années avant le livre de Brooks (en 1970), une méthodologie de développement logiciel, appelée le « cycle » en cascade (Waterfall cycle), était inventée. Cette approche appliquait les idées de l’ingénierie (mécanique, civile, etc…) au logiciel. Le principe consistait à commencer par recueillir les spécifications, puis faire le design, puis l’implémenter, enfin le tester, et finalement obtenir un logiciel de manière linéaire.

Il a coulé beaucoup d’eau sous les ponts depuis et nous avons beaucoup appris dans le domaine du développement logiciel. Le modèle en cascade est maintenant de plus en plus désuet car il est trop rigide et irréaliste. Dans notre quotidien, les projets de logiciels sont mal définis et ont des fonctionnalités en constante évolution, ce qui ne permet pas de tout envisager dès le départ. Avec l’avènement des langages de programmation modernes de 4ième ou de 5ième génération (Java, PHP, Python, Perl, C# ou Ruby), les nombreuses bibliothèques et un nombre sans précédent d’infrastructures nous sommes arrivés à la fin des années 90 à un nouveau pallié de l’évolution de l’ingénierie logicielle.

C’est alors que sont apparues de nouvelles méthodes regroupées sous l’appellation de techniques de « conceptions agiles ». Le principe en est simple : pour concevoir un logiciel aujourd’hui, vous n’avez besoin que de quelques bons développeurs ! De plus cette approche permet aux développeurs de réajuster constamment le logiciel en fonction du marché et des exigences des clients.

Mais est-ce si simple ? (Lire la suite …) (Document au format Pdf)