Pulsar a développé sa propre méthodologie de gestion de projet sur base de l’expérience pratique de ses consultants. Différentes méthodologies et divers outils y ont été intégrés et simplifiés : approche en cascade et approche RAD cyclique (Rapid Application Development), analyse de la valeur ajoutée, Oracle-CDM (custom development method), méthodologie de projet Belgacom-Promis.

Cette méthodologie, adaptée en fonction des besoins du projet, est suivie pour tous les projets à prix fixe et permet de délivrer dans les délais et budgets prévus.

Le respect strict de cette méthodologie nous permet de réduire les contingences de risques et les temps de développement. Nous pouvons dès lors offrir de meilleurs prix aux clients et être plus compétitifs sur le marché. Notre méthodologie est toujours sujette au changement étant donnée que chaque nouvelle expérience acquise sur des projets peut y être intégrée.

Nous présenterons ci-dessous toutes les phases de la méthodologie, avec mention de tous les documents standards associés à chaque phase. Chaque document possède sa propre structure, reprise dans la Structure de Projet Centralisé Standard de Pulsar.

La méthodologie fixe un nombre de documents standards qui doivent être utilisés dans chaque projet, selon les besoins. De nouveaux documents peuvent être crées spécifiquement pour le projet, si besoin. Si un document se répète dans plusieurs projets, il peut être inclus en tant que document standard dans la méthodologie.

Introduction

Dans le "bon vieux temps" de la gestion de projet, on utilisait souvent l’approche en cascade étant donné sa simplicité de compréhension et de gestion : chaque phase prend cours à la fin de la précédente. Toute l’approche par diagrammes de Gantt pour la gestion de projet est basée sur cette idée.

Trois inconvénients majeurs peuvent être soulignés avec cette méthode classique de gestion de projet:

• Le client doit définir ses besoins de façon correcte et complète au début du projet. Notez que pour les implémenteurs et l’équipe du projet cela est certainement un gros avantage car cela leur permet d’organiser les phases du projet, les modules et le contenu sans avoir à les modifier plus tard. Ce qui est fatal aux jalons de projet et aux budgets, ce sont les changements demandés durant les phases du projet. Plus les changements surviennent tardivement, plus l’impact sur le planning du projet est important. Un processus de gestion de changements doit alors être mis en place.
• Lors de cette approche, le respect des délais requiert de laisser du temps entre les phases du projet pour permettre la synchronisation des phases terminées avant d’entamer la phase suivante.
Cela mène à un délai plus long pour tout le projet.
• Chaque erreur ou changement qui a lieu dans l’une ou l’autre phase du projet a un impact sur toutes les phases suivantes et demande un nouveau cycle complet (commençant à l’erreur ou au changement) pour la correction/l’intégration.

Les "mauvaises" expériences issues de ces divers inconvénients ont mené les experts en gestion de projet à migrer vers ce que l’on appelle aujourd’hui l’approche RAD (Rapid Application Development), ou l’eXtreme Programming, ou encore l’Agile Programming. La propriété principale de ces méthodes est qu’elles permettent une approche de prototypage plutôt qu’une approche en cascade. L’idée principale est de créer un premier prototype, de le soumettre au client, de le changer dans une seconde version, de le resoumettre, etc.

Bien que cela soit très pratique pour le client (plus besoin d’une liste initiale complète des exigences), cette approche est beaucoup plus risquée pour les projets à prix fixe (le prix et les délais sont convenus et fixés au début du projet).

Dans le but de bénéficier des avantages des 2 approches et aussi pour réduire les risques de dépassement de budget/de planning, Pulsar prône une approche combinée:

• Gestion des phases par fonction/module
• Gestion contrôlée des processus de changement

Convention de nomenclature des fichiers

La convention de nomenclature des fichiers a pour but de fixer des règles pour la définition des noms de fichiers. Ceci s’applique pour tout document standard ET DOIT ETRE APPLIQUE A TOUT DOCUMENT NECESSAIRE POUR UN PROJET SPECIFIQUE.

Chaque nouveau document doit en plus être formaté en utilisant les modèles « .dot » qui se trouvent dans le répertoire de la méthodologie Pulsar.
Les catégories suivantes d’extensions de fichiers peuvent apparaître dans un projet/application :

• Extensions de fichiers de documents, de fichiers liés aux bases de données
• Extensions de fichiers de code source ou d’exécution.

Règles générales: Chaque nom contient différents termes décrivant le contenu du document. Ces termes sont fixés par la méthodologie (acronymes liés à la méthodologie), et d’autres sont spécifiques au projet, mais suivent également les mêmes conventions de nommenclature. Les acronymes liés à la méthodologie sont écrits en majuscules. Le premier est obligatoire et est placée au début du nom. Les autres parties possibles se placent juste après, séparées par un trait. Exemple : ARC-DIAGRAM-MyClient-MyProject-MyTopic-Doc_Version.vsd Mis à part ces acronymes, la première lettre de chaque mot doit être en majuscule. Toutes les autres lettres doivent être en minuscule. Si le nom est fait de deux ou plusieurs mots non séparés ou séparés par un trait/soulignement ou par un caractère plus/moins/égal, la même règle s’applique. Tout ceci rend donc le nom du document plus lisible. Les extensions de fichiers doivent être adaptées suivant les outils spécifiques utilisés pour produire ce fichier. Exemple : Si un fichier est édité avec « Notepad », l’extension sera « .txt ». Les caractères spécifiques suivants sont utilisés : " < " et " > " délimitent une information obligatoire qui doit être adaptée " [ " et " ] " délimitent une information non-obligatoire qui doit être adaptée Tous les autres caractères, " - ", "acronymes liés à la méthodologie" sont obligatoires. Le sujet et la version ne sont pas toujours obligatoires, et peuvent être ajoutés à n’importe quel document, suivant les besoins. La version du fichier diffère souvent de la version de l’application. Généralement, la "v1.0" est la même pour les deux (ceci veut dire que la version du fichier "1.0" sera délivrée avec l’application "1.0"). Ceci permet de changer de version de fichier seulement quand son contenu a changé (sinon, des fichiers identiques seraient renumérotés au fil des versions de l’application, et ceci n’est pas pratique).