Sur la qualité du logiciel, le développement web et les systèmes patrimoniaux

Quel défi captivant !

Introduction au problème – Étude de cas

Depuis un an, on m’a demandé de reprendre un projet mal entamé et qui sera une source de profits récurrents pour l’entreprise m’ayant embauchée. De nombreuses heures de recherche, de conception, de développement et de tests ont été nécessaires pour développer le prototype final du système – dont je tais ici le nom pour en garder l’aspect confidentiel.

Bâti à partir de rien, ce projet a été démarré il y a trois (3) ans de cela. Les exigences du système ? Je ne les ai jamais vus. Les parties prenantes ? Il m’a fallu deux (2) mois pour comprendre qui était le partenaire principal du projet et en quoi il différait des utilisateurs-clients finaux qui allaient payer pour le produit. Les tests ? Des ensembles de tests unitaires avaient été créés pour quelques parties du projet. Le tout me semblait soit trop testé ou bien les tests créés étaient dépendants de sous-systèmes particuliers, comme l’engin de journalisation de trace du programme. Plus tard, je me rendrai compte que l’analyse des traces du programme n’est pas à proscrire pour valider les chemins pris par le programme mais tout de même, dans le cas présent, c’était inadéquat, trop de redondance dans les tests.

Sommairement, il y a un (1) an, donc à mon arrivée sur le projet, j’ai trouvé le tout assez décousu. En terme de performance, la répartition des tâches à l’intérieur du programme qui étaient nécessaires à la réalisation de l’algorithme (cas d’utilisation) principal de l’utilisateur étaient immondes (des tâches planifiées exécutées sur trois (3) applications indépendantes installées en tant que service sur le système) et il y avait une latence minime de 30 à 40 minutes (humaines) entre l’action de l’utilisateur et la réalisation concrète de l’action, la finalité du processus. D’autres éléments rendaient inacceptable la solution développée (appelons la version pré-Alpha) par mon prédécesseur. Entre autre, aucun suivi – de la perspective utilisateur – n’était possible (pas de rétroaction à l’écran sur le mécanisme du système), un couplage tellement élevé entre l’interface graphique et le modèle de données qu’une modification mineure à un fichier texte source – essentiel au système – génèrerait des jours de maintenance et de tests. Une sécurité inadéquate était aussi implémentée (sécurité par obscurcissement – entre autres, pour autant que l’utilisateur soit un véritable navet de l’informatique, ce qui est de plus en plus rare de nos jours). Les informations secrètes d’accessibilité aux données sources du systèmes, qui sont propriété de l’entreprise pour laquelle j’œuvre, programmés directement dans des fichiers XML non chiffrés, une centralisation de droits d’accès inexistante (malgré un requis spécifique pour cette centralisation et pour la gestion des droits d’accès des applications versus des comptes utilisateurs connus et facturables), etc. Pire encore, l’échange des données entre les composantes (j’ai mentionné qu’il y en avait quatre (4) au départ) se faisait au travers de fichiers XML locaux sur disques, non chiffrés, ce qui laissait la place à une panoplie de problèmes potentiels.

Bref, à mon arrivée, j’ai été confronté à un système patrimonial, bien que ce dernier ait été développé entre 2010 et 2012. Un mandat clair d’amener ce système en production commercialisable m’a été confié, duquel je ne pouvais me soustraire.

De nombreux aspects méthodologique étaient à régler avant même que je ne m’attaque au problème du produit à commercialiser en tant que tel. On m’a présenté le carnet de commandes en attentes documenté dans un tableur au format .xsl et j’ai dû retenir mon œsophage pour qu’il ne renvoie pas tout sur la table. À ce moment précis j’ai mis toute activité relié au produit de côté pour installer un système qui allait nous aider à travailler. Fort de mon expérience passée dans une entreprise de logiciel libres reconnue, l’installation d’un système de gestion de projet, qui inclut un carnet de commandes et qui permet l’utilisation amicale de la méthodologie agile SCRUM, a été implantée (plus tard, ce sont tous les projets de l’entreprise qui allaient bénificier d’un tel système).

Ensuite, aucun bon outil visuel n’était disponible pour venir soutenir les activités d’ingénierie logicielle auxquelles je devait m’attaquer. Microsoft Visio n’était pas une option envisageable compte tenu de la lourdeur d’un implantation de telle solution de documentation pour un fonctionnement efficace (ais-je besoin de mentionner le prix des licences, des requis architecturaux, de tous les irritants de cette solution loin d’être idéale?). Visual-Paradigm, une solution UML qui me semble complète, est venu colmater cette brèche.

Le système de gestion de version du code source a dû être changé aussi car la technologie utilisée nous donnait des maux de tête dès que nous devions renommer un fichier dans l’arborescence du projet.

Une plate-forme d’intégration continue amicale a été installée en remplacement du difficilement utilisable système qui avait été mis en place afin de nous permettre de gérer l’intégration continue des versions de façons plus aisée, visuelle surtout, et voir même amusante.

Cela était pour les changements architecturaux et en soutien aux activités de génie logiciel qui allaient suivre tout au long de l’année suivante. Cependant, même en ne le voulant pas, il est très aisé de passer à côté d’étapes primordiales en ingénierie logiciel. En sautant dans la vase de remettre un tel projet sur pied, des étapes très importantes de la qualité ont été sautées ou autrement bâclées pour permettre une version livrable et utilisable du produit. En cours de route, des exigences se sont ajoutées, ces dernières n’ont pas ou trop peu été documentées, analysées et testées.

Au bout de la route, il est de mon devoir de revenir en arrière pour procéder à une rétro-ingénierie des fonctions, services, interfaces, bref de tout élément du système développé pour remonter et créer après-coup les documents des cas d’utilisation et des exigences logicielles. Cela étant dit, il va de soi que l’exercice se fait trop tard et qu’une part majeure du développement du système s’est donc faite d’une manière non structurés (en fait de documentation et de procédures) et que les tests en écopent grandement.

En fait, c’est lorsque arrivé à la nécessité d’implanter des tests systèmes et fonctionnels (unitaires) que la plus grande ambiguïté s’est soulevée. Comment procéder pour tester notre application ? Certes, je suis à l’aise de faire des tests manuels, dans un contexte contrôlé, avec qui un ou deux utilisateurs. Mais qu’en est-il de l’automatisation des tests ? Comment tester ce qui (semble) bien fonctionner alors qu’il est implémenté et que le tout a été fait sans prendre en considération la testabilité des composantes (en fait, pas dans une approche systématique et structurés, dans un grand ensemble rigoureux nommé plan de test et qui est propre au produit lui-même) ?

Autrement dit, vers la toute fin du projet, je me suis mis à me questionner fortement sur la capacité du système à être testé et à utiliser les tests pour améliorer les points de chute du système (là où ça fait mal). Je me suis remis à lire. Premièrement VLIET (Software Engineering), puis sur les tests unitaires, les doublures de test, les tests directs et indirects (tout ça font partie des méthodes de tests unitaires), puis sur la qualité du logiciel web (parce que c’est un projet moderne, tout de même).

C’est ici que j’ai reçu l’aide que je cherchais tant. Le projet, tel qu’il était, ne pouvait pas être testé adéquatement. Il me manquait quelque chose. Il me manquait l’essentiel (Jing). J’ai compris alors pourquoi mes efforts (Qi) n’aboutissaient pas dans une direction claire et concrète (Shen).

L’essence des procédures de test et de tout ce qui en découle, des certitudes à avoir, des défaillances à prévoir et bien, tout cela a comme point d’origine essentiel les cas d’utilisation. Ces cas d’utilisation n’étaient pas documentés pour le système patrimonial. Seulement quelques exigences à implémenter le plus rapidement possible avaient été formulées, éparses, et n’avaient pas été structurées. C’est donc un travail colossal qui m’attend en trait à cette rétro-ingénierie plus qu’importante pour la continuité du projet. On connais peut-être trop pas la nécessité et la valeur de l’analyse des fonctionnalités et je n’ai pas eu la chance de pouvoir étudier cette matière à l’université. Ainsi, c’est ici que je ferai part de mes études sur le sujet et de la démarche continue entreprise pour sortir les exigences des abysses fonctionnelles et les structurer tel que la démarche en génie logiciel le préconise.

Pour vous, lecteur, qui trouvez mon allusion à la médecine traditionnelle chinoise (Jing, Qi, Shen) douteuse, je rappelle au passage qu’ici il est question de santé du logiciel. Je ne me priverai donc aucunement pour user d’allusions médicales et de métaphores connexes lors de mes rédactions.

 

Jing – L’essentiel

 

L’essentiel, c’est d’être aimé. Or, on aime ce que l’on comprend, ce qui résonne en nous, ce qui fait du sens, ce qui est beau, ce qui va nous amener ailleurs, nous sortir de l’embarras, du pétrin, etc. On aime se faire plaisir. On aime comprendre.

J’aime comprendre et j’ai compris quelque chose d’essentiel.

Un ouvrage fort précieux, Quality Web Systems, propose une technique d’analyse de cas d’utilisation qui en illuminera plus d’un. La méthode d’analyse RSI (Requis-Service-Interface) est un ensemble de pratiques permettant d’énumérer des cas d’utilisation, de les séparer en trois groupes distincts et de les tracer entre eux. Ainsi, un requis sommaire (appelons-le RUtiliser le système) sera lié à d’autres cas d’utilisation, directement ou indirectement, tel que I-Menu principal, S-Connexion au système, R-Choisir un fruit, I-Voir la fiche d’un fruit, S-Charger un fruit, etc.

En séparant les cas d’utilisation en requis (R), interfaces (I) et services (S), on découple les couches des besoins et on permet une analyse granulaire des cas d’utilisation.

Les procédures de tests tiennent leur essence de ces cas d’utilisation granulaires, principalement les services (S) mais aussi les interfaces (I) depuis l’apparition d’outils spécialisés pour tester les interfaces graphiques, tel que Jasmine de Google, pour ne nommer que celui-là. Les requis (R) sont généralement vérifiés d’une autre façon, souvent par des tests manuels.

Les cas d’utilisation de types S représentent souvent des étapes automatisées de cas d’utilisation R et I. Les cas d’utilisation I sont des étapes des cas d’utilisation R et leurs données sortantes deviennent des données entrantes aux cas d’utilisation S. Les données sortantes des cas d’utilisation S deviennent des données entrantes aux cas d’utilisation I, généralement des messages devant être affichés à l’utilisateur.

Ainsi, on peut décomposer un cas d’utilisation R de type sommaire en plusieurs cas d’utilisation R, ces derniers incluent des cas d’utilisation I dans lesquels l’interaction utilisateur-système est mieux définie sous forme de composantes graphiques et d’interfaces (c’est en fait un concepteur graphique qui doit piloter la création de ces cas d’utilisation), qui eux-même alimenteront voire définirons les cas d’utilisation S, qui sont les services et qui accèdent directement au modèle de données objet.

Tout se tient donc bien à sa place dans ce modèle RSI de développement de cas d’utilisation. On développera les cas R en premier, les S et I ensuite sont fait en parallèle et finalement un diagramme de tracabilité RSI peut être produit pour chaque acteur ou cas d’utilisation R afin de tracer les requis jusqu’aux éléments du modèle (on se rappelle plus haut qu’un cas d’utilisation S implique des éléments du modèle de données, invariablement, soit en lecture – on dira un S de type requête – soit en écriture – on dira un S de type mise à jour).

Dans mes prochaines publications, je vais traiter de l’application de cette méthode de définition de cas d’utilisation après-coup dans le contexte d’une application patrimoniale ayant été développée sans ces artéfacts – et qui doivent être produits pour assurer un santé et une qualité au logiciel afin de lui permettre de survivre dans le monde cruel du numérique.

(Chi)

Synology 1812+ et VMWare ESXi

Récemment on m’a chargé de relever un nouveau défi, celui de la redondance et de la reprise en cas de panne majeure. Bien que désirant offrir de la haute disponibilité, il a été convenu qu’un temps mort de deux heures reste acceptable dans n’importe quel cas peu importe la catastrophe.

Les solutions sont multiples. La virtualisation à faible coût existe cependant la courbe d’apprentissage de solutions telles KVM/QEMU n’est pas simple pour des utilisateurs/gestionnaire lambda de l’industrie des TI. Ainsi, VMWare est un standard assez accepté de simplicité et de performance/possibilités pour un environnment de virtualisation potable.

Le problème présenté est principalement qu’une quantitié impressionnante de données est utilisé dans le commerce de l’affichage numérique puisque les actifs principaux sont des médias de grans volumes (plusieurs téraoctets de données).

La solution de départ est un serveur physique qui héberge ESXi et qui est limité. Un autre serveur physique de très grande capacité de traitement est dédié pour une application métier importante. Cependant, cette application métier peut être scindée en plusieurs instances plus petites et placés sur des machines virtuelles.

La migration, cependant, de ce serveur vers un serveur de virtualisation, pose problème.

En définitive, après avoir testé la virtualisation de VMWare avec un Synology comme datastore, je me suis rendu à l’évidence que l’es entrées-sorties des disques n’étaient vraiment pas satisfaisantes pour la performance souhaitée de l’application. Néamoins, ça reste un très bon choix pour du stockage VMWare … disons domestique – à mon humble avis.

Nouvelles avenues

Pour ceux ou celles qui me suivent, je veux vous donner quelques nouvelles.

Premièrement, depuis mon départ de SFL en octobre 2012, beaucoup de changements se sont produits. J’ai été embauché par une PME internationale de Montréal dans le domaine de l’affichage numérique où les défis sont légion.

Depuis huit (8) mois, je travaille au développement d’un logiciel spécialisé qui révolutionnera le monde de l’affichage numérique. Toute mon expérience professionnelle y est passée … Administration de systèmes, Programmation orienté-objet, Programmation Client-Serveur, Sécurité et chiffrement, Reporting, Qualité, Développement Web, Administration et développement de bases de données, Infonuagique, Réseautique, etc.

J’ai eu la chance d’avoir à ma disposition une équipe jeune et performante sans laquelle le logiciel ne serait pas ce qu’il est aujourd’hui.

Les efforts ont conduits à la version Beta d’un produit attendu depuis deux ans, que nous avons relevé des cendres.

Je suis fier de cette réussite et je compte relever encore de beaux grands défis comme celui-ci dans ma carrière professionnelle!

Je bloguerai sur les hauts et les bas de mes fonctions dans des prochaines publications.

Cordialement,
Vincent de Grandpré
Chef programmer et Administrateur de systèmes
Région de Montréal, Québec

Stoppez cette guerre médiatique

Stoppez la guerre des médias
Cessez de nous prendre en otage
De nous dire ce qui est juste, bien ou mal

Arrêtez de nous bombarder d’opinions
Nous sommes pris à la gorge dans la
Guerre de l’information

Nos pensées convergent et
C’est en aveugle que nous avançons
Manipulés par des marionnettistes experts

On tisse nos voeux, nos rêves et nos scandales
À partir de filons d’opinion
On critique le mouvement et l’indépendance

Tout écart au Statu Quo est réprimandé
Mis à mal, dénoncé et incendié
Tout doit être honni et banni

Car la marionnette souhaite couper ses cordes
Et le marionnettiste, lui, a tout à perdre
Nous sommes des libres pantins pensants

Confinés sur une scène érigée pour nous
Nous répétons le même scénario
Empêtré dans une liberté hypothétique

NRPE, Shinken(Nagios) et Windows (NSClient++)

Enfin!

Pour obtenir une surveillance dans Windows depuis Shinken, les commandes NRPE sont utilisées.

Premièrement, les préalables :

1. Ouvrir le pare-feu (port Nagios/5666 [par défaut])

Ensuite, deux outils Windows sont nécessaires :

1. NSClient++ (Communication NRPE depuis Nagios)
2. check_winservice.exe (Greffon pour vérifier les services Windows)

Un coup installé, il faudra faire correspondre la commande Nagios à l’exécutable dans une section À AJOUTER de NSClient++ (NSC.ini).

Donc :

A – Ajouter une section [NRPE Handler] dans NSC.ini;
B – Définir la commande p.ex.:

[NRPE Handler]
check_winservice_DNS=C:[Chemin vers check_winservice.exe]check_winservice.exe –service DNS –state !running –critical 0

C – Redémarrer NSClient++
D – Configurer le fichier de commandes Shinken/Nagios pour y avoir une commande qui ressemble à ( command=check_nrpe!check_winservice_DNS )

Bon, cela dit, ce que fait la commande telle qu’elle :

Elle vérifie si le service DNS (–service DNS) ne roule PAS (–state !running) et il renvoie à Shinken (Nagios) la valeur critique s’il trouve plus de zéro (–critical 0) service dans cet état.

Voilà c’est ce qui fonctionne! J’ai essayé de ne faire qu’une commande dans NSC.ini et de récupérer la valeur du service en paramètre depuis Shinken, cependant ça ne fonctionne pas.

Avec cette méthode, cependant, vous verrez le résultat dans Nagios comme tel :

SERVICE OK – 0 service(s).

.. Ce qui peut porter à confusion. C’est de la logique inverse.

Surveillance Open Source avec Shinken (Nagios)

Dans cet article j’explique comment vérifier l’état d’un service TCP qui écoute en local sur un hôte avec Nagios.

Prenons l’exemple d’un serveur qui écoute sur le port TCP 127.0.0.1:1234 au lieu de 0.0.0.0:1234.

Afin d’avoir une vérification saine qui ne tombe pas en expiration de connexion, NRPE doit être utilisé.

Simplement, ajouter à /etc/nagio/nrpe_local.cfg une ligne qui ressemble à :

command[check_tcp_1234] = /usr/lib/nagios/plugins/check_tcp -H 127.0.0.1 -p 1234

et, redémarrer NRPE.

Le difficile parcours de la vie … de famille!

Rien de moins évident que la vie de famille.

On veut être heureux, on passera la majorité de son temps à conclure des ententes, à faire des sacrifices, à s’oublier pour l’autre et pour nos enfants.

Où cela nous mène? Parfois dans une quête de l’idéal, d’autre fois dans un tourbillon de changement.

La vie moderne favorise-t-elle une vie de famille stable pour les 20-30 ans? Pas vraiment. Le coût de la vie, les désirs et les loisirs font collision bien souvent avec les idéaux et la magie qui rend l’homme (et la femme) heureux.

Dès lors on semble ne plus savoir où est le repos, la paix et le bonheur simple devient hors de portée. Tout paraît compliqué.

Cependant rien ne sert de désespérer. Il faut prendre ce que l’on a et poursuivre vers nos aspirations propres. Car, pour chacun, cela me semble le seul chemin logique.

Pourquoi les gens se parlent-ils avec le doigt du millieu ?

J’ai remarqué cela durant mes vacances. Les gens se parlent à Majeur levés. Vous savez, le majeur, le doigt du millieu, celui qui sert à exprimer la colère, la haine et le mécontentement (il peut aussi servir à pointer mais généralement c’est négatif).

Je déteste voir ce doigt. En toutes circonstances. Pour ma part je considère que de s’en servir lors d’une conversation verbale ou gestuelle démontre l’incapacité des personnes à se respecter et à respecter les autres. Ce geste que je prends trop souvent à la légère maintenant m’énerve et m’intimide. Pourquoi en venir là? Aussi bien se lancer des couteaux, non ?!

Pourquoi? Parce que voyez-vous j’en ai assez de voir ça. Assez de constater que les gens sont incapables de laisser une situation qui les dérange et qu’ils préfère s’envoyer paître plutôt que de partir.

Si je ne peux plus dire ce que je penses ou ce que je suis, à quoi me sert d’exister? Je prends donc la résolution formelle de quitter lorsqu’on me présente ce doigt. Je m’engage aussi à ne plus l’ignorer et à accepter le mécontentement des autres que cela m’arrange ou non.

Ainsi j’espère que mon séjour dans la 5ième dimension sera plus agréable! Si les autres n’acceptent pas mon point de vue ou mes actes tant pis. Je suis maître de mon destin et ma vie n’appartient à nul autre qu’à moi et à ceux que j’aime. Ma copine, ma famille, mes amigos.

ÉCO-GESTION se met de la partie pour aider Haïti

Venir en aide à Haïti en signalant un don matériel aux organismes

Les secteurs résidentiels et commerciaux à Haïti sont gravement touchés et les besoins en biens matériels sont grandissants. Outre l’envoi de dons en argent, vous pouvez signaler un don matériel d’articles récupérables pouvant être envoyés à Haïti.

Éco-Gestion est une initiative coopérative d’inventaire et d’échange de biens matériels.

L’inventaire construit ici sera mis à la disposition des organismes humanitaires internationaux.

Une fois la liste remise aux organismes ils vous contacterons pour le transport et la réception de votre don.

Vincent de Grandpré
Fondateur, projet Éco-Gestion