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 d’un Projet TI.

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 d’un Projet TI 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 d’un Projet TI, 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. D’abord, dans un projet TI, on peut retrouver un grand nombre de documentations différentes; le fameux manuel de l’usager, la documentation des requis destinée à l’exploitant du logiciel, la documentation d’architecture et de design destinée aux analystes, designers et développeurs et finalement, la documentation technique ou documentation logicielle destinée aux programmeurs en sont les principaux exemples.

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

En ce qui nous concerne, nous parlerons de la documentation d’architecture et de conception et de la documentation technique d’un projet de développement TI. 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…)

La vision du Développement orienté-Service, par-delà l’Architecture orientée-Service

Nous voudrions dans ce billet, par-delà l’Architecture orientée-Service, revenir sur 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 Architecture SOA !

La raison en est fort simple, avec l’architecture orientée-service, les services développés se sont retrouvés au cœur des systèmes d’information, 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 peu importe votre domaine d’activités. É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 des Processus et Innovation, un mariage de cœur et de raison

Performance des Processus et Innovation sont un mariage de cœur et de raison au sein de toute entreprise florissante ou, à tout le moins, les entreprises 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 en développement logiciel selon le style de gestion

La perception de la performance en développement logiciel varie selon le style de gestion; il faut le souligner, la mesure de la performance est vraiment une question de perception. L’évaluation de la performance d’une équipe de développement 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 de développement 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’évaluation de la performance d’un développeur, d’une équipe de développement, d’une entreprise de développement logiciel ? Existe-t-il un indicateur clé de performance en développement logiciel, qui dit la vérité ?

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 en développement logiciel comme ailleurs.

(suite…)

Apprentissage Machine

Quelques entreprises récoltent déjà des bénéfices en Apprentissage Machine

Cet article est tiré d’extraits d’une enquête conjointe réalisée par MIT & Google menée à la fin de 2016 et que vous pouvez télécharger ici.

L’apprentissage par machine est pour de nombreuses entreprises le nouveau terrain de preuve pour un avantage concurrentiel. Un récent sondage mené par MIT Technology Review Custom et Google Cloud révèle que, bien que la majorité des entreprises aient du mal à appliquer l’apprentissage machine, d’autres travaillent déjà à développer des stratégies pour cette technologie et réalisent déjà un ROI authentique.

L’enquête comprenait 375 répondants qualifiés représentant une variété d’industries avec une prépondérance provenant de l’industrie de la technologie (43%) mais aussi des services aux entreprises (13%) et des services financiers (10%). La plupart des répondants qualifiés étaient des dirigeants de niveau C (39%) ou des développeurs d’entreprise (37%) ainsi que des cadres supérieurs (23%).

(suite…)