Meilleures pratiques de sauvegarde de documentation d’un projet TI

Il y a de bonnes et de meilleures pratiques de sauvegarde de documentation d’un projet TI; en TI comme en toute chose.

Dans les deux premiers billets de cette série sur la documentation d’un projet de développement TI, nous avons traité du « quoi » ou de ce qu’il faut documenter et du « comment » ou si vous préférez du format que l’on devrait utiliser.

Dans ce billet, nous ne traiterons pas du « pourquoi » mais bien du « où » sauvegarder la documentation.

Si vous pensez que ce billet sur la sauvegarde de documentation d’un projet TI est le parent pauvre des deux précédents, détrompez-vous.  Trop souvent la documentation n’est pas consultée parce qu’elle n’est pas facile d’accès et, pour les mêmes raisons, la documentation n’est souvent pas à jour.

(suite…)

Format de documentation d’un projet TI; meilleures pratiques

Quel est le format de documentation d’un projet TI le plus approprié ?  Et, quelles sont les meilleures pratiques de documentation d’un projet TI en termes de format ?

La question peut paraître étrange car pour plusieurs, cette question ne se pose même pas. Mais en y regardant de plus près, elle mérite qu’on s’y attarde; comment doit-on documenter un projet TI et avec quel type de format ?

Pour mettre en lumière le défi du format de documentation, il faut tenir compte de trois facteurs :

  • Objet de la documentation
  • À qui elle s’adresse ?
  • Par qui est-elle produite ?

(suite…)

Meilleures pratiques de Documentation d’un Projet TI; l’objet de la documentation

Les meilleures pratiques de Documentation d’un Projet TI ne sont pas simples car l’objet de la documentation n’est pas toujours évident. La documentation d’un Projet TI peut avoir une portée très large ou, à l’opposé, une portée très limitée.  La portée de la documentation sera proportionnelle au niveau de criticité de l’application ou du système qu’elle documente ainsi que de l’environnement dans lequel cela s’exécute.  Par exemple, soyez certain que l’application bancaire que vous utilisez sur votre téléphone est bien documentée.

Bref, la documentation d’un Projet de Développement TI, c’est comme les assurances, ça en prend mais il faut trouver le bon équilibre.

Dans un projet TI, on peut retrouver un grand nombre de documentations différentes, le fameux manuel de l’usager étant qu’un seul de ces documents; ainsi, que doit-on documenter ?

Dans cette série de billets, nous allons aborder les points suivants :

  • Que doit-on documenter dans un projet TI ?
  • Comment doit-on documenter ?
  • Où doit-on rendre disponible ces documents aux différents lecteurs ?

(suite…)

Logo d'Analystik en cire pour cacheter une lettre

Revenir à l’essentiel; Analystik revisite son identité corporative !

Analystik a parcouru du chemin depuis la création de son dernier logo en 2005; plusieurs clients se sont ajoutés au porte-folio dont la Banque Laurentienne, Hitachi Capital Canada et Wells Fargo. Son identité corporative est demeurée la même mais beaucoup de choses ont changé en 10 ans…

Cependant, malgré le chemin parcouru, les différentes approches de gestion et les méthodologies de développement utilisées, les nombreuses évolutions de systèmes, frameworks et plateformes mobiles; l’objet de notre travail, lui, est toujours demeuré le même, le processus, et notre objectif est lui aussi toujours demeuré le même, la qualité sur tous les plans.

Conséquemment, lorsque vint le temps de revoir notre identité corporative, cette réflexion nous entraîna spontanément vers une approche de rafraîchissement plutôt qu’une démarche de recréation.

(suite…)

La vision du Développement orienté service, par-delà l’architecture

Nous voudrions dans ce billet revenir sur l’esprit, par-delà l’architecture orienté service, la vision du Développement orienté service car ce n’est pas rien, considérant que beaucoup soutiennent qu’en TI, il y a eu un avant et un après SOA !

La raison en est fort simple, avec l’architecture orienté service, les services développés se sont retrouvés au cœur de l’architecture TI, en interface à la fois avec les applications fondamentales et les données.

Bien que cela ne soit pas évident au premier coup d’œil, beaucoup de développeurs y ont tout à coup gagné une marge de manœuvre, une liberté de conception, d’aucuns diront une créativité nouvelle.

(suite…)

Développement orienté service, tous les bénéfices sans les risques !

Le Développement orienté service offre tous les bénéfices du développement logiciel sur mesure mais sans les risques et sans les coûts d’un logiciel commercial; c’est ce que nous entendons aborder dans cette suite du billet précédent.

Nous expliquions dans le billet précédent qu’alors que le Développement logiciel sur mesure constitue un risque appréciable en termes de pérennité de services et de coûts de développement; le logiciel commercial, lui, entraîne souvent des coûts d’adaptation pré-installation faramineux et des frais récurrents de licence.

Ainsi, nous expliquions avoir pris une autre tangente depuis quelques années parce qu’elle nous apparaissait offrir le meilleur des deux mondes à la fois pour le client et pour le développeur; soit le Développement orienté-service qui s’appuie sur trois principes :

(suite…)

développement en parallèle

Développement orienté-service, le meilleur des deux mondes

Devriez-vous commencer, à titre de Directeur TI, à penser en termes de Développement orienté-service plutôt que de Développement d’application ou encore d’achat d’un logiciel commercial ?

La question mérite d’être posée car, étonnamment, bien que nous ne cessions de vanter les mérites du Développement Agile depuis plus d’une décennie, le fait est que, la majorité des grandes et moyennes entreprises se lancent encore de nos jours à grands frais dans des projets TI lourds, à longue échéance, en s’appuyant sur des plateformes reconnues telles SAP ou Oracle ou en s’appuyant sur des logiciels commerciaux.

(suite…)

atome unique

La performance en développement logiciel, une question de métriques

L’évaluation de la performance d’une équipe de développement logiciel dans le cadre d’un projet de développement logiciel peut varier grandement selon le type de métriques utilisées aux fins de l’évaluation.

Cette requête de mesure de la performance au niveau des projets de développement revient constamment et constitue une source de préoccupation majeure chez les Gestionnaires; ce qui est tout à fait normal considérant le faible ratio de projets livrés dans les temps et les coûts.

(suite…)

Performance et Innovation, un mariage de cœur et de raison

Performance et innovation sont un mariage de cœur et de raison au sein de toute entreprise florissante ou, à tout le moins, elles doivent devenir innovantes pour fleurir car l’innovation entraîne presque toujours un gain de performance sur un plan ou un autre.

Ainsi, l’entreprise qui veut performer doit innover et l’entreprise innovante performera… assurément !

(suite…)

gestion et performance

La perception de la performance selon le style de gestion

La perception de la performance varie selon le style de gestion. Il faut le souligner, l’évaluation de la performance est vraiment une question de perception. L’évaluation de la performance d’une équipe est en fait étroitement liée au style de gestion et aux priorités que celui-ci dicte; en développement logiciel comme dans toute autre activité d’ailleurs.

Tout gestionnaire souhaiterait avoir une évaluation objective de son équipe et de son département TI dans le cadre d’un projet de développement logiciel. Le terme « objectif » est la clé de l’énigme ici. Existe-t-il une méthode objective d’évaluer la performance d’un individu, d’une équipe, d’une entreprise ?

En fait, on ne compte plus les systèmes, méthodes et nomenclatures qui ont été développées depuis le début de l’ère industrielle afin d’évaluer la performance.

(suite…)