Mes quatre murs de mon bac à sable : Développement logiciel

Like This!

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to Yahoo BuzzAdd to Newsvine

  1. Introduction

Combien de fois, j’ai attendu dire par des clients ou d’autres personnes, même des professionnels de l’informatique. Qu’il suffisait de mettre beaucoup de programmeurs ensemble pour produire un bon logiciel et parfois, en sous-entendant qu’on pourrait aussi le fouetter de temps en temps, s’ils accumulaient un peu de retard.

Mais aux jours d’aujourd’hui, il ne suffit plus de mettre une gang de programmeurs ensemble. Construire un logiciel aujourd’hui c’est un autant un art qu’une science. Un groupe de programmeurs peuvent faire un excellent travail. Mais, il leur faut un terrain de jeux, un environnement de travail qui leur permettra de mettre efficacement leurs compétences en action.

Qu’est-ce que ça demande de plus ? C’est une question qu’on me pose souvent. Lorsque, je réponds à cette question. J’utilise souvent l’apologie du bac à sable. Un bon bac à sable bien construit, les enfants peuvent y jouer tout en sécurité. C’est un peu à cette image qu’il faut construire l’environnement des programmeurs. En leur donnant tant les outils que l’environnement (le mur et le sables), ils pourront exercer leur travail de programmation au mieux.

  1. Le premier mur celui l’analyse fonctionnelle

Le premier mûr, j’avoue aujourd’hui, c’est lui le moins oublié. D’autant que la formation de nos programmeurs d’aujourd’hui fait partie de la formation de base dont ils reçoivent tant nos Cégeps que nos universités.

  1. L’analyse fonctionnelle, c’est quoi ?

Mais, avant de vous parler de l’importance de l’analyse fonctionnelle, je vais d’abord définir ce que c’est. Pour moi, l’analyse fonctionnelle c’est d’abord le processus qui permet de répondre à la question:  « c’est quoi ce va faire le système à construire ? » ou plus simplement, décrire le comportement attendu par l’application à la fin du processus de développement.

C’est aussi de définir le processus qui permettra de comprendre les différents scénarios d’utilisations possibles (positif). Ceux que l’utilisateur pourra faire. Ainsi que les limites ou le cadre de ces scénarios.

Il est aussi important de définir les scénarios impossibles. Un marteau ne coupe pas une planche de bois. C’est la même chose pour un logiciel. Il ne fait pas tout. Ça serait trop le fun ! 😉

  1. L’importance de l’analyse fonctionnelle

Une règle bien simple pour se rappeler l’importance de faire ou non un dossier fonctionnel. La règle, c’est simple si c’est plus compliqué qu’un « hello word » et qu’on ne peut résumé le « Détail » du traitement et des scénarios en 2 phases que tout le monde va comprendre, on fait un dossier fonctionnel.

Il ne faut pas oublier que le dossier fonctionnel, ne sert pas seulement au développement du logiciel ou de la fonction du logiciel. Il est aussi utile pour la maintenant, les essaies et comme documentation initiale.

Mais d’abord et avant tout, c’est un contrat qui lit l’équipe de développement avec le demandeur de ce logiciel, le client. Qu’il soit externe ou externe à l’organisation ou à l’équipe, il le lit. C’est lui qui permettra de définir si ce qui a été demandé a été bien livré. !

Donc, sans ce mur, nous ne serons pas par où entrer !

  1. Le deuxième mur, l’autre pendant de l’analyse, celle organique ou logicielle

L’autre mu qui a aussi toute son importance, c’est bien l’analyse organique. Mais avant de définir l’importance, je vais définir c’est quoi.

    1. La définition, ça manche quoi en hivers

Ça mange quoi en hivers cette analyse organique. Mais, c’est justement c’est qui nous empêche d’avoir en hiver. L’analyse fonctionnelle nous a dit quel genre de maison et comment elle serait divisée. Mais c’est l’analyse organique qui nous dira comment les murs seront faits et surtout comment commander les matériaux nécessaires pour construire cette maison.

J’allais oublié, en informatique nous ne construisons pas de maison. Mais des logiciels, et parfois des logiciels pour aider à la construire c’est tout… hi hi !

Vous trouvez mon apologie drôle, mais pourtant elle dit vrai. Il faut aussi définir comment sera fait l’ensemble des morceaux de notre logiciel. C’est le plan détaillé de toutes les cloisons, le filage et la tuyauterie de notre maison.

C’est aussi à cette étape qu’on va prendre les décisions sur l’art et le comment on va faire les choses. Qu’ont déterminé si on va se construire des gabarits ou des modèles pour pouvoir récupérer le travail ou encore le simplifier.

Construire un logiciel, c’est bien plus qu’écrit du code dans un langage de programmation.

    1. Est-ce qu’on ne peut pas en faire !

On me dit souvent, mais programmeur sont bons et ont beaucoup d’expérience. Donc, pas besoin de faire cette étape. Mais parfois, il faut savoir où sera la cuisine ou la salle de bain, pour savoir comment passer les files ou les tuyaux.

Vos ouvriers, les programmeurs, sont peut-être très compétents. Mais parfois, il faut avoir plus que la vision de la pièce qu’on construit.

Les programmeurs d’aujourd’hui sont des bons intégrateurs ou de bons assembleurs. Mais il faut parfois, voir souvent leur donner un bon plan. Imaginez vouloir assembler un meuble IKEA sans le manuelle d’instructions. C’est presque impossible, vous risquer d’avoir un résultat incertain ou encore avoir des pièces en trop. C’est la même chose avec logiciels.

Donc, faire une maison ou une meuble IKEA sans plan, pas pour moi. A la limite, j’accepterais un plan partiel plutôt que de ne pas en avoir du tout.

    1. C’est qui le fait

Donneriez-vous à votre meilleur ouvrier le travail de construire le plan du pont qui servira à faire passer des camions. C’est la même chose pour ce travail. Ça demande un professionnel de l’analyse organique. Je vous reviendrais prochaine avec ce profil dans un autre billet.

  1. le troisième mur, les tests unitaires automatisés.

Allez, je vous propose un petit jeu. Je vous donne procédure de 10 étapes et à chacune d’elle vous devrez valider le résultat. Jusque-là c’est facile.

Complexifions ce petit jeu, je vous demande de refaire 100 (cent) fois, voir 1000 (mille) cette même procédure. Et à chaque fois, le résultat des étapes peut changer aléatoirement. Je suis sûr que vous me direz que c’est compliqué et que le risque d’erreurs de tout genre est grand, et vous aurez raison.

C’est pourtant ce qu’on demande à un programmeur de faire pour valider son travail.

  1. L’ordinateur c’est bien faire !

Un ordinateur c’est bien essentiellement quatre grandes taches, addition, soustraire, multiplier et comparer un résultat.

Le plus drôle de l’histoire, c’est aussi ce qu’on demande généralement dans un test unitaire. Donc, pourquoi ne pas demandé à l’ordinateur de le faire pour nous. C’est la réflexion que plusieurs informaticiens on fait lorsqu’ils ont développé les outils de tests unitaires automatisés.

  1. La qualité d’un bon logiciel

La qualité d’un bon logiciel passe par la qualité de ces tests unitaires, mais aussi par leur exécution. Nous savons qu’il est difficile de bien répéter un très grand notre de fois la même procédure sans risque d’erreurs.

Nous savons aussi que l’ordinateur c’est bien faire cette tache. Donc, pourquoi ne pas lui faire faire. D’autant, ce n’est pas parce que les tests exécutés la semaine passée se sont terminés avec succès. Que le résultat ne sera pas différent aujourd’hui avec toutes les modifications qu’il y a eu dans le code.

Avec les tests unitaires automatisés, on peut relancer plusieurs tests, même ceux qu’on pense que le nouveau code. Vous serez peut-être surpris.

Un test unitaire automatisé, c’est un peu comme testé le pilier du pont, tout au long de la construction, et ce, avant que les gros camions passent dessus.

  1. le dernier pour compléter le carré, le gestionnaire de sources.

Faites-vous des backups d’un document important sur lesquelles vous travaillez ? Normalement, oui ! (Sinon vous devriez !).. Imaginez donc, travaillez sur plusieurs documents (fichier de codes sources) en simultanés et surtout par plusieurs personnes.

C’est impossible, pourtant c’est se qu’on fait à tous les jours avec nos fichiers de code. Il y a plusieurs stratégies et plusieurs outils, du simple partage réseaux jusqu’à l’outil qui fait la gestion des sources.

  1. La gestion des sources

La gestion des sources, c’est l’art de prendre une copie des fichiers, mais aussi de conserver les différentes versions. Jusque-là, on peut le faire avec plusieurs répertoires, voir plusieurs disquettes.

En plus, il est intéressant de savoir ce qui a été modifier et surtout par qui, pour le cas, qu’on ne comprendrait pas la démarche de la modification. Ce cas, il ne suffit pas avoir seulement 2 versions du fichier.

Imaginez, une application moyenne d’aujourd’hui, c’est grosso modo 500 voir 1000 et plus fichiers. Donc, savoir à quelle version on est rendu .. Disons simplement que c’est trop compliqué sans outils.

Vous comprendrez aussi, que conserver des dizaines de copies, le volume de données stockées devient rapidement important. C’est pourquoi que nous avons besoin d’un outil qui le fera pour nous. D’autant que les outils de gestion de sources modernes gèrent l’historique des versions en conservant seulement le différentiel. La partie qui a été modifiée, le fichier sont construits en appliquant les modifications sur le fichier de référence

  1. Pour vivre sans !

Vivre sans, c’est possible .. Mais à, mais yeux, on n’a pas justification valable. Car, il y a de bons produits open source et même des sites web qui offre ce service.

Ce n’est pas la qualité de votre personnel ou de vos processus qui peuvent justifier l’absence d’un outil dans votre environnement de développement logiciel.

A titre d’exemple, même les projets que je suis le seul développeur, j’utilise un outil de gestion de sources. Donc, pourquoi pas vous ?

  1. La conclusion

En conclusion, développer un logiciel, c’est bien plus que d’écrire du code qui va répondre aux quelques notes qu’on avait prises pour dire ce que ça ferait.

Si ça était si facile, tout le monde le ferait et nos grandes écoles (collèges et universités) ne forceraient pas pour l’enseigner. Il n’aurait pas non plus des gars comme moi qui prônent l’idée et pour certain en écrive des livres sur le sujet.

Tenez-le pour dit, sans c’est 4 murs indispensables à la construction d’un bon logiciel. Vous allez m’entende argumenter longuement et avec beaucoup d’acharnement.

Vos ressources sont compétences, donnez leur un bon environnement de travail et surtout de bons outils. Ils ne pourront qu’en être meilleurs et davantage concentrer sur le vrai travail de développement logiciel.

  1. Aucun commentaire pour l’instant.
  1. No trackbacks yet.

Répondre

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l'aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s

%d blogueurs aiment cette page :