Traduction

mardi 15 octobre 2013

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

Hier, j'ai publié sur la base du problème et j'ai décrit en somme ce vers quoi je devais aller. Aujourd'hui, je pousse plus loin en recréant les cas d'utilisation depuis l'implémentation.

Cas d'utilisation d'interface (I)


Sous sa forme la plus simple, les cas d'utilisation d'interface (I) sont les plus aisé à modéliser puisqu'ils correspondent à des points d'entrée bien définis dans l'application pour les opérations utilisateurs.

Ces cas d'utilisation I, je les ais aussi modélisé pour les interfaces de systèmes, soit comme points d'entrée de fonction d'un système tier vers l'architecture principale (le modèle du domaine). Ainsi, en plus des cas d'utilisation d'interface évidents (récupérés depuis le navigateur puisqu'il est question d'une application web), les cas d'utilisation d'interface I système ont été ajoutés.

Ces derniers peuvent être confondus avec les cas d'utilisation service S, cependant par leur nature, il y a réellement une barrière de communication entre le modèle de données et le reste du monde et ce sont les objets que l'on peut regrouper dans ces cas d'utilisation I, les interfaces de systèmes. Les interfaces de système ont donc une nomenclature qui se confond avec les cas d'utilisation de services S de par leur nature (cas d'utilisation en mode requête/mise à jour) cependant ils sont placés de sorte qu'ils viennent se poser comme interface au système ou à une autre composante du système (dans une architecture distribuée client-serveur par exemple).

Un premier jet est donc fait en extractant les cas d'utilisation évident des interfaces graphiques et des points d'entrée du code serveur.

Ce qui est bien avec ce processus inversé, c'est qu'il n'est pas nécessaire d'impliquer un designer graphique pour revenir en arrière pas plus que des prototypes d'écrans utilisateurs ne sont requis. Ils feront tout de même partie de la documentation, cependant ils auront déjà été produit.

Cas d'utilisation de services (S) et requis (R)


Par la suite, la plupart des cas d'utilisation de services (S) et requis (R) peuvent être modélisés à partir des cas d'utilisation I. De plus, certains cas d'utilisation S seront modélisés directement à partir de cas d'utilisation de requis (R) - ils sont dits cas d'utilisation S-Essentiel. Ces derniers ne pourront être modélisés à partir des cas d'utilisation d'interface cas ils n'impliquent pour ainsi dire pas d'interface.

L'important est de cerné tous les requis d'utilisation à partir de ce qui a été implanté. Ce ne devrait pas être bien difficile non plus que ça ne devrait être quelque chose qui révèle des requis inexistants ou non-implémentés, évidemment car sinon on aurait un gros problème.

En somme, on devrait avoir grosso-modo tracé les requis jusqu'aux éléments du modèle, des cas R aux cas S en passant par les cas I. Tous ça nous permettra d'avoir une suite qui descend de ces cas d'utilisation et qui puisse être représenté dans un diagramme de tracabilité des cas d'utilisation.

lundi 14 octobre 2013

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 R-Utiliser 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.

jeudi 11 juillet 2013

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