Mesurer la qualité d’un projet pour le désendetter

En ingénierie logicielle, tant qu’un projet se développe, la dette technique s’accumule inexorablement. Les sessions de refactoring sont là pour contrebalancer cette tendance et leur mise en place régulière garantit la maintenabilité du projet. Mais ce qui est délicat avec la dette technique, c’est qu’elle n’est pas vraiment mesurable, et comme l’iceberg, on n’en voit que la partie émergée. Résultat, le refactoring est souvent sous-estimé et mal maitrisé. Si on ajoute à cela une mauvaise couverture de test, refondre le code applicatif fait peur, fait mal. Plus personne n’a l’audace de le tenter, et à long terme, c’est la banqueroute assurée du projet.

L’objectif de cet article est de proposer une approche efficace pour savoir comment attaquer efficacement un grosse refonte d’un code mal couvert par les tests. Cette tâche technique est divisée en plusieurs problématiques : comment déterminer les zones de risque du projet, trouver où poser les tests pour sécuriser l’étape de refactoring et trouver les zones à refactorer.

Pour rendre l’article concret, nous allons utiliser à titre d’exemple XDepend qui est un outil d’analyse de code statique java. En effet, on parle d’amélioration de la qualité, donc pour juger de l’efficacité de nos actions, il faut pouvoir les mesurer. Lire la suite

OCTO présent au FLETAN 2009

OCTO Technology sera présent aux 4èmes Rencontres Annuelles de la Fédération Lilloise des Entrepreneurs Tertiaires pour les Architectures Nomades (F.L.E.T.A.N), parrainées cette année par l’acteur Omar Sharif.

OCTO y fera notamment un retour d’expérience sur l’équipement d’une flotte de chalutiers en terminaux mobiles, abordant les problématiques de tracking de bancs de sardines par RFID avec rendu cartographique sous FishEye, de synchronisation de données bi-directionnelles avec la base au port et de radioguidage de cabillauds. Sera aussi détaillé l’impact des nouvelles règlementations européennes pour la préservation des ressources halieutiques sur l’application des méthodes agiles.

Cette conférence, sous forme de harangue puis de questions/réponses, sera suivie par une présentation du logiciel Octopus Microfinance et de ses nouvelles fonctionnalités anti-hameçonnage.

La session sera aussi donnée (ou pas) lors de l’USI 2009 les 1er et 2 juillet 2009, où nous espérons vous voir nombreux !

Pour une Informatique Conviviale

Chronique parue dans 01 Informatique du 3 avril 2009.

En imitant les traits des grandes entreprises pyramidales, l’informatique ne les a finalement faites que peu progresser. Spécialisation, obéissance et territoires fermés caractérisent nos systèmes d’information, miroirs de nos organisations. Qu’en serait-il si nous remettions en cause les règles qui nous ont permis d’informatiser ces entreprises jusqu’à aujourd’hui en ajoutant autonomisation, initiative, et ouverture des territoires à ce jeu de caractères ?

Lire la suite

Référencer les applications RIA Flex et Silverlight

Pourquoi référencer une application dans les moteurs de recherche ?

Le référencement est une étape non négligeable du développement d’un site Internet. Ne pas référencer son application dans les moteurs de recherche revient à imprimer une plaquette publicitaire sans la distribuer. Si les moteurs de recherche savent parfaitement référencer un site HTML, qu’en est-il des applications RIA développées avec des technologies telles que Flex ou Silverlight ?

Lire la suite

L’importance du Definition Of Done

Nous voici en bilan d’itération d’une équipe agile, l’objectif du client est de valider les stories et de déterminer la vélocité de l’équipe

  • « La story 30 est-elle bien terminée ? » demande le client
  • « Oui mais il manque des tests Fitnesse », répond le chef de projet
  • « Bon, s’il manque que les tests Fitnesse, on peut la mettre à terminé plus tard. On va voir ce que ça donne « , dit le client
  • Le client teste l’application à partir de son navigateur web
  • « Mais il manque la validation du champ de saisie ! », s’exclame le client

Lire la suite

Stades de développement d’une équipe

Un groupe ne devient pas une équipe performante du jour au lendemain. L’équipe passe différents stades pour se développer. Différents modèles sont disponibles pour identifier à quel stade se situe une équipe afin de permettre son développement supérieur. Cet article présente un modèle d’analyse de la maturité d’une équipe.

L’équipe passe par 6 stades de développement:

Lire la suite

Et si l’avenir des IHMs (Web) était à la mixité?

Lorsqu’on regarde une application « grand public », on note au moins les besoins suivants : rien de génial la dedans, interagir avec des données, de consulter et de naviguer dans du contenu mise en forme. A côté de ces besoins, on recherche souvent « THE » solution, celle qui va résoudre tous nos problèmes, celle qui va répondre à tous nos besoins. Reste que si une telle technologie existait, on l’aurait déjà trouvée. Un peu comme les alchimistes qui recherche à transformer le plomb en or…

J’ai cette impression que ces applications devront – au moins à moyen terme – mixer les technologies. Flex est adapté pour réaliser des interactions utilisateurs trés riches, trés visuelles : slider, drag&drop, transitions visuelles et autres effets visuels… . A l’inverse, HTML reste la technologie la plus adaptée pour gérer du contenu mis en forme, pour assurer la navigabilité dans ce contenu. Dès lors, comment faire communiquer ces deux mondes : Flex et HTML.
Lire la suite

Monsieur Jourdain et la SOA

Mr Jourdain fait de la prose ou des vers sans qu’il n’en sût rien. Bon, nous le savons depuis la 5e ! Et comme Molière avait le don d’écrire des universalités humaines et intemporelles, il est certain qu’aujourd’hui autour de nous et dans bien des domaines il y a des Mr Jourdain qui s’ignorent. Projetons donc ce monsieur Jourdain dans l’IT de 2009. Quelle pourrait être la chose qu’il fît depuis pas mal de temps sans qu’il n’en sût rien. Ne serait ce pas de la SOA par hasard ? Reprenons une définition communément rencontrée d’un service. Je cite rapidement et pour l’essentiel :

  • Standardisation : Les services exposés respectent les mêmes règles de standardisation.
  • Couplage lâche : Le contrat de service impose un couplage lâche vis-à-vis de ses clients
  • Autonomie : Le service est autonome car il ne fait pas appel à aucun autre système tiers. Il n’en n’est pas dépendant. Ce qui par ailleurs le rend prédictible.
  • Abstraction : Le contrat de service n’expose que les informations essentielles à son invocation.
  • Composition : Le service peut participer à une composition d’appel de services.
  • Sans état : Le service ne conserve aucun état (résultats d’exécution ou autres).

Lire la suite