Aller directement à la fin des métadonnées
Aller au début des métadonnées

Les gnasseurs de l'équipe Gadz.org ne sont pas les seuls à travailler sur les outils informatiques : de manière générales, toutes les entités / strass / assos ont leur responsable informatique, qui a à sa charge la mise en place et la maintenance d'un site web, d'un logiciel, d'un réseau, d'une base de données, etc. C'est avec ces responsables que l'équipe Gadz.org doit souvent interagir pour implémenter les outils développés.

Pour toutes les raisons listées ci-dessus, nous estimons nécessaire de thuysser nos camarades informaticiens sur les bonnes méthodes à utiliser pour mener un projet informatique au sein de notre communauté AM. Cette thuysse a été faite par les membres de l'équipe qui travaillent (profession) dans des entreprises ou à des postes SI.

 

 

De part sa simplicité de compréhension et de mise en place, nous avons choisi de vous explique comment organiser ses projets suivant le modèle du Cycle en V.

 

Attention !

Quelque soit la méthodologie utilisée, tout projet de nouveau site / logiciel / autre outil informatique qui serait apporté à l'équipe Gadz.org pour une intégration sur nos serveurs / plate-formes, doit être obligatoirement accompagné a minima :

  • du recueil des besoin
  • des spécifications fonctionnelles
  • des spécifications techniques (même incomplètes, sachant qu'elles seront complétées avec l'équipe Gadz.org)

(description de ces documents ci-dessous)

 

 

Le cycle en V, qu'est-ce que c'est ?

Déf. Wikipédia

Le modèle du cycle en V est un modèle conceptuel de gestion de projet imaginé suite au problème de réactivité du modèle en cascade. Il permet, en cas d'anomalie, de limiter un retour aux étapes précédentes. Les phases de la partie montante doivent renvoyer de l'information sur les phases en vis-à-vis lorsque des défauts sont détectés, afin d'améliorer le logiciel.

Le modèle du Cycle en V organise les différentes étapes d'un projet, et définit les interactions entre elles, les passages d'une étapes à une autre. La compréhension de ce modèle est grandement facilitée par la représentation suivante (qui lui a donné son nom) :

En suivante, nous allons décrire chaque étape en donnant :

  • l'objectif de chaque étape
  • les documents qui doivent être rédigés
  • les conditions de passage à l'étape suivante

 

Organisation pré-projet

Avant toute chose, on ne part pas sur un projet informatique la fleur au fusil. Une certaine organisation est à mettre en place, sachant que plusieurs personnes travaillerons ensemble, sur les même supports. Ainsi avant de commencer, vous devez vous assurer que :

  • Les objectifs du projet sont clairement définis
  • Les contraintes de calendrier et de budget sont identifiés
  • Les rôles de chaque contributeurs sont bien définis.
  • Des réunions régulières sont planifiées pour assurer le suivi du projet et les discussions entre les différents contributeurs.
  • Un espace de stockage et de partage des documents rédigés durant le projet est mis en place (nous vous invitons fortement à utiliser les outils GDrive auxquels vous avez accès via vos comptes Gadzmel).

Une fois ces 5 points remplis, le projet peut commencer.

 

Étude du besoin et Faisabilité

Que veut-on faire avec ce nouveau produit ? Qu'est-ce que l'utilisateur final souhaite faire / doit pouvoir faire ? Quel est le but du projet ? L'étude du besoin doit répondre à toute ces questions, et définir avec le maximum de précision le périmètre du projet.

Une première étape est de définir les utilisateurs du produits. Par exemple pour les Sites de promotions :

  • les membres de la promo
  • les gadz'arts "lambda"
  • les délégués de promotion
  • les administrateurs de site
  • les administrateurs Gadz.org
  • les personnes extérieurs à la communauté AM

Il y a potentiellement des besoins différents pour chaque catégorie d'utilisateurs. Il faut également définir les personnes qui ne doivent pas être utilisateurs. Il existe de nombreuses méthodes pour définir ces besoins, telle que la méthode APTE® que la plupart d'entre nous connaissent avec la "bête à corne" ou le "diagramme fonctionnel" (il en existe de nombreuses autres, Google is your friend..)

Erreur courante

Attention, se dire "Nous avons besoin d'un site de prom's", ce n'est pas exprimer un besoin ! Le besoin serait plutôt par exemple "Nous avons besoin d'un outil informatique pour encourager et encadrer les activités de notre prom's" ... ici le site de prom's est une solution parmi d'autres au besoin.

 

La sous étape qui suit est le benchmark et l'étude de faisabilité. Ces 2 études vont déterminer s'il est nécessaire de continuer ou pas :

  • le benchmark est une étude comparative des outils existant, afin de déterminer si un produit répond déjà à tous les besoins exprimés précédemment. Cette étude nécessite une recherche de documentation et la consultation d'experts, qui pourront vous aiguiller sur des solutions adéquates s'il y en a. S'il y existe des solutions qui remplissent partiellement/totalement les besoins, alors le projet peut évoluer en de l'amélioration de solution ou du simple hébergement de produit.

  • l'étude de faisabilité : le nom parle de lui même, il s'agit d'une étude high level afin de déterminer si vous n'avez pas les yeux plus gros que le ventre. Une fois de plus il va s'agit de se documenter sur des projets qui ont pu être similaires, de contacter des experts, et d'évaluer les principaux défis.

Attention

L'étude de faisabilité ne se fait pas uniquement sur des critères techniques : il s'agit aussi d'estimer le budget nécessaire à la réalisation de la solution, et le temps que cela va prendre. Si le prix est trop élevé, ou que cela prendra trop de temps, alors il est peut-être plus sage de revoir ses objectifs à la baisse...

 

L'étape de l'étude du besoin, du benchmark et de la faisabilité se termine par la rédaction et la diffusion du Recueil des Besoins, un document dans lequel toutes les démarches, les réflexions et les résultats sont consignés.

 

Les spécifications fonctionnelles

Les spécifications fonctionnelles sont la description des fonctions d'un logiciel / site en vue de sa réalisation. La question à se poser au long de leur rédaction est :

Comment doit fonctionner mon outil pour répondre aux besoins ?

Les spécifications fonctionnelles doivent décrire tous les processus de l'outil informatique, en commençant par les données d'entrée, et en finissant par le résultat, les données de sortie.

 Exemple de processus décris dans des spécifications fonctionnelles.

Le besoin est : "L'utilisateur A veut effectuer une action B". Les spécifications vont alors dire :

  • L'utilisateur A doit rentrer l'information C, de type numérique, dans le champs D, et l'information E, de type texte, dans le champs F, puis cliquer sur le bouton G
  • SI l'utilisateur A a dans son profil le paramètre H d'activé ET SI le paramètre I dans la configuration du site est réglé à 4, alors les informations E et F sont traitées par le processus J (décris plus tard) pour donner le résultat B
  • Si l'utilisateur A a dans son profil le paramètre H désactivé OU le paramètre I dans la configuration du site est différent de 4, alors le message K est retourné à l'utilisateur A

 

Un bon moyen concevoir ses spécifications est de lister de manière la plus exhaustive possible toutes les actions qu'un utilisateur (utilisateur lambda, admin, autre) peut effectuer, et de décrire tous les processus nécessaires.

 Exemples de cas d'utilisation

Sur un Site de Promotion :

  • Actions liées à l'album photos
    • un camarade souhaite consulter les photos d'un album
    • un camarade souhaite ajouter des photos dans un album
    • un Délégué De Promotion souhaite créer un nouvel album
    • un DDP souhaite éditer ou supprimer un album
  • Actions liées aux actualités
    • un camarade souhaite créer une nouvelle news
    • un camarade souhaite éditer ou supprimer une news dont il est l'auteur
    • un DDP souhaite éditer ou supprimer une news dont il n'est pas l'auteur
    • un camarade souhaite commenter une news
    • un camarade souhaite éditer ou supprimer un commentaire
    • un DDP souhaite créer ou supprimer un commentaire d'une news
  • Actions liées aux profils
    • un camarde souhaite mettre à jour son profil
    • un DDP souhaite mettre à jour le profil d'un camarade
  • Actions liées au design du site
    • un DDP souhaite modifier l'organisation des blocs de la page d'accueil
    • un DDP souhaite modifier les couleurs du site
    • un DDP souhaite modifier le logo du site
    • un DDP souhaite modifier les droits d'accès au site
    • un DDP souhaite ajouter un nouveaux gadget au site

etc etc etc ... on peut continuer à l'infini, jusqu'à avoir couvert tous les besoins exprimés dans le recueil de besoins. La liste ci-dessus est à 2 niveaux, mais vous pouvez évidemment augmenter le niveau de détails.


Le document alors rédigé doit pouvoir être lu et compris par n'importe quelle personne qui souhaite s'initier au fonctionnement de l'outil. Les spécifications fonctionnelles sont obligatoires pour espérer mener un projet informatique solide, avec un résultat satisfaisant et durable.


Les spécifications techniques

Les spécifications techniques sont la description des choix techniques pris pour satisfaire les spécifications fonctionnelles et les besoins. On va pouvoir y trouver :

  • les technologies utilisées
  • les configurations de machines
  • l'architecture technique de produit
  • les principaux processus de code
  • le système de versions
  • l'organisation des fichiers de code et de configuration
  • les librairies utilisées
  • etc etc

Le document des spécifications techniques n'a pas pour but de pouvoir être lu par n'importe qui : il va principalement servir aux opérateurs qui vont développer le produit, ou le reprendre pour le corriger / l'améliorer.

Grâce à leur simple lecture (avec la lecture des spécifications fonctionnelles), les spécifications techniques doivent permettre aux développeurs de savoir quoi faire, de savoir commencer et finir le travail.

 

Le développement

La partie opérative, le moment ou le code est écris, ou les configurations sont faites, ou le produit naît.

Décrire plus en détail cette étape est difficile, étant donné que la méthodologie de travail va dépendre du produit. Cependant nous vous recommandons de documenter au maximum vos avancées sur le produit, de noter les problèmes / obstacles que vous rencontrez !

 

Tests unitaires - Vérifications

Cette étape de test est effectuée par les développeurs. Il s'agit de s'assurer que tous les processus fonctionnent unitairement. Toute cette étape doit être documentée, en listant pour chaque processus

  • la commande d'entrée effectuée (clic, déplacement du curseur, écriture de texte, envoi de mail, etc)
  • le résultat attendu
  • le résultat obtenu

Si le résultat obtenu n'est pas en accord avec le résultat attendu, il est nécessaire de revoir les spécifications techniques, de les corriger si nécessaire, et de corriger le code / la configuration / autre. Dans notre diagramme ci-dessus, il s'agit de la première flèche horizontale :

Il est conseillé de définir dès le début du projet les conditions d'aller-retour au moment des vérifications techniques.

Une fois les corrections effectuées, les tests doivent à nouveau être effectués et validés. Tant que les résultats ne sont pas en accord avec les spécifications techniques, la boucle est ré-parcourue.

 

Tests fonctionnels - Validation

Cette étape de test est effectuée par les analystes fonctionnels. Il s'agit de s'assurer que tous les processus fonctionnent dans le cadre de l'utilisation prévue de l'outil. Il s'agit de s'assurer que toutes les fonctionnalités et les besoins sont respectés. Toute cette étape doit être documentée, en listant pour chaque processus

  • la commande d'entrée effectuée (clic, déplacement du curseur, écriture de texte, envoi de mail, etc)
  • le résultat attendu
  • le résultat obtenu

Si le résultat obtenu n'est pas en accord avec le résultat attendu, il est nécessaire de revoir les spécifications fonctionnelles, de les corriger si nécessaire, et de corriger les spécifications techniques et le code / la configuration / autre au besoin. Dans notre diagramme ci-dessus, il s'agit de la deuxième flèche horizontale :

 

Il est conseillé de définir dès le début du projet les conditions d'aller-retour au moment des vérifications fonctionnelles.

Une fois les corrections effectuées, les tests doivent à nouveau être effectués et validés. Tant que les résultats ne sont pas en accord avec les spécifications fonctionnelles, la boucle est ré-parcourue.

 

Mise en production - Validation client

Une fois tous les tests techniques et fonctionnels validés, il est temps d’implémenter le produit en production, et de l'ouvrir aux utilisateurs. Il est conseillé de ré-effectuer les tests fonctionnels afin de s'assurer que l'environnement de production n'altère aucune fonctionnalités (c'est ce qu'on appelle les tests de non-régression).

 

La suite du projet va consister en

  • du support utilisateur,
  • l'accompagnement des camarades qui utiliseront l'outil
  • la récupération e statistiques de fréquentation
  • la recherche d'optimisation, pouvant mener à un nouveau projet de perfectionnement.

La documentation

 

Nous n'avons pas cessé de le répéter ci-dessus : documentez TOUS vos travaux !!

Une bonne documentation, cela permet :

  • de retrouver les réflexions que vous avez menées pour en arriver au résultat
  • de retrouver les explications des processus fonctionnels et techniques de votre nouvel outil, afin de les optimiser, ou de comprendre ou un bug se situe.
  • d'assurer la passation de votre outils à vos successeurs : il est très difficile de tout expliquer par oral, une bonne documentation permet à votre successeur de compléter les connaissances que vous lui avez transmises.
  • d'assurer que le travail n'est pas perdu si par malheur il vous arrive quelque chose (et oui c'est triste à dire, mais c'est un risque réel..)

Bref vous l'avez compris : tous à vos plus belles plumes !

Risques et adaptations

Toute la procédure écrite ci-dessus n'est qu'un modèle, le prendre au pied de la lettre n'est peut-être pas toujours la bonne solution. Comme expliqué plus haut, au démarrage de tout projet il est nécessaire d’évaluer les risques... les risques liés à la méthodologies font partie de cette réflexion !

  • Le risque le plus connu dans le cadre du modèle de cycle en V, c'est la divergence entre la théorie (illustrée par les spécifications fonctionnelles) et la pratique (quand on code !). Dans la vraie vie, il est plus courant de voir les fonctionnalités du produit grandement évoluer au fur et à mesure de la réalisation, du fait des difficultés ou impasse rencontrées lors du développement.
  • Le modèle en V peut parfois s'avérer trop simpliste pour mener un projet à plusieurs applications, ou pour mener la mise en œuvre d'un logiciel existant. Enfin il ne couvre pas du tout la phase d’utilisation de l'outil. L'utilisation de modèles plus raffiné pour certaines étapes est conseillé.

Du coup, en fonction de l'équipe du projet, des situations des membres respectifs (géographiques, familiales, professionnelles, etc.. et oui nous sommes bénévoles après tout !), il peut etre intéressante :

La seule chose ci-dessus qui restera toujours vrai est décrite dans le paragraphe précédent.

 

 

  • Aucune étiquette
  1. Anonyme dit :

    Wow... Désolé si ce n'est pas très constructif, mais voilà tout ce qui ne marche pas dans le "vrai" monde du logiciel. L'horreur. Je connais les contraintes de gadz.org, qui subit un peu les dev à l'arrache de tous les côtés, mais de là à autant vouloir s'ancrer dans le passé foireux du monde du software... Qui marchera encore moins dans le contexte gadz.org - même si je comprends l'objectif initial. Je suis open pour en parler de façon plus constructive évidemment =)

  2. Anonyme dit :

    Précédent message signé Mathieu Lorber, Cluny 205, je n'ai pas fais gaffe pour l'auth, mes excuses

  3. Sal's Mathieu
    Ton avis m'intéresse, mais je t'avoue que pour le moment tout ce qui est ci-dessus est un premier brouillon, uniquement basé sur ma propre expérience pro. Ensuite le reste de l'équipe Gadz.org fera une relecture, complètera ou supprimera des éléments. Après comme je l'ai dis, ton avis m’intéresse aussi, du coup on pourra se passer un coup de fil un de ces 4 pour partager nos expériences (ya ton numéro sur ton profil (sourire) )
    Merci pour ce retour
    Frat's