• 1

pulsar, pulsar consulting

La méthodologie de gestion de projet chez Pulsar

Pulsar a développé sa propre méthodologie de gestion de projet, en intégrant l’expérience pratique de ses consultants et en simplifiant et intégrant différentes méthodologies et outils: 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, Agile et SCRUM.

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.  

Gestion d'application

Le terme "Gestion d'application", en opposition à l'habituel "Gestion de projet", indique que nous cherchons à couvrir l'ensemble du cycle de vie d'une application informatique, depuis les premiers besoins du client à ses dernières améliorations, en passant par des projets à prix fixe de la maintenance.

Réduction du TCO d'une application grâce à la méthodologie Pulsar

Plusieurs points doivent être pris en considération lorsque l'on souhaite obtenir le coût total (TCO) le plus bas possible et exécuter un projet informatique, à prix fixe ou en consultance, de la manière la plus efficace tout au long de son cycle de vie:

  • Une méthodologie ayant fait ses preuves pour le développement de projets à prix fixe devrait définir les phases du projet et les modèles de documents à utiliser, et devrait également couvrir des aspects tels que:
    • principes de développement générique
    • transfert de connaissances et formations
    • processus de changement contrôlé
    • maintenance
  • Un contrat de maintenance de l'application, très flexible et permettant après le développement de l'application de:
    • étendre facilement l'application
    • garder une trace et compter chaque changement, patch et version
    • permettre au client de contrôler et tirer profit de chaque jour-homme consommé
  • Un processus d'assurance qualité et d'évaluation et gestion des risques devrait assurer une excellente qualité de livraison de l'application finale.

 

Tous ces sujets sont couverts par la méthodologie de Pulsar, nous permettant d'être très compétitifs en termes de retour sur investissement, mais aussi de délivrer des applications de haute qualité, maintainable, extensible, et adaptées aux besoins des clients, dans le temps et le budget convenus, en limitant les risques.

Dans tous les cas et quel que soit le mode de fonctionnement choisi, un projet doit être mené en suivant un plan de capacité, permettant de combiner les compétences nécessaires pour atteindre les résultats escomptés, dans les délais et le budget fixés:

 

 

Le Triangle Magique représente les liens entre les 4 concepts principaux qui définissent un projet: le budget disponible, les fonctionnalités demandées, la date limite et les ressources, incluant les personnes et leurs compétences. Il y a une équivalence entre le budget, les fonctionnalités et la date limite; lorsque l'un change, les autres changent également, ou doivent être changés pour compenser. Par exemple, quand les fonctionnalités sont réduites, le budget sera réduit aussi. Ou, lorsque les risques de dépassement de bugdet se font sentir, il faut trouver un compromis avec le client pour, soit réduire les fonctionnalités, soit repousser la date limite. Les compétences apparaissent au milieu de ce triangle car cellesi-ci ont un impact sur les 3 autres concepts principaux. Par exemple, lorsqu'un projet est en dépassement de budget ET dépassement de date, des personnes plus expérimentées peuvent travailler plus vite et faire le travail en moins de jours-hommes. Cela aura un impact positif sur le budget et la date butoire et remettra le projet sur les rails. 

 

Le Carré Magique montre comment les notions de budget et de date limite, comme définies dans la Méthode d'Analyse de la Valeur Acquise ("Earned Value Analysis Method"), permettent de déterminer le statut d'un projet. Cela permet de suivre l'évolution du projet et évaluer si celui-ci dérive. Le carré jaune "hors budget" peut être résolu en retirant des ressources et donc en consommant moins de budget. Le carré jaune "hors planning" peut être résolu en ajoutant des ressources et donc en consommant plus de budget pour aller plus vite. Le carré rouge "hors budget" et "hors planning" peut parfois être absorbé en remplaçant des ressources par d'autres plus expérimentées, mais cela reste souvent impossible ou insuffisant et mène à une révision globale du projet (recadrage du projet sur tout le triangle magique).

Gestion des phases et des modules

Les projets que nous développons sont habituellement divisés en plusieurs fonctions/modules, et pour chaque fonction/module nous appliquons une approche en cascade. Cette façon de travailler nous permet d'être très flexible en terme de chevauchements des phases ("phases overlaps").

 
Documents remis au client

Durant le projet, une partie des documents est livrée au client. Les documents relatifs à l'application qui sont généralement livrés au client sont :

  • Documents d'exigences par rapport au Business et à l'achitecture (BUSREQ et ARCREQ)
  • Document d'architecture (ARC)
  • Document relatif à l'interface utilisateur (GUI)
  • Document de base de données (DB)
  • Manuels d'utilisateur et l'aide en ligne (si c'est applicable) (UMAN et AIDE)
  • Flux de test (si c'est applicable) (TEST-FLOWS)
  • Document d'installation (INST)
  • Document des changements effectués par version (VERSION-CHANGES)

Les documents relatifs à la gestion de projet qui sont généralement livrés au client sont quant à eux :

  • Proposition de projet (PROP) et liste de livraison (DELIV-LIST)
  • Plan de projet et/ou structure de découpage du projet et les tâches (PROJ-PLAN et TASK)
  • Compte rendu de réunion (MM)
  • Rapport de progression du projet (PROJ-PROGRESS et ESTIM-VS-PERF)
  • Contrat de maintenance (MAINT-AGREE) et traçage de l'activité de maintenance (MAINT-TRACE)

Les autres produits livrables relatif au projet sont :

  • La maquette de l'application
  • Le code source de l'application (si spécifié dans le contrat) et les codes binaires ("binaries")

A la requête du client, d'autres documents peuvent être faits et devront être estimés dans le cadre du projet ( si le prix est fixé). Même si ce n'est pas spécialement demandé, d'autres documents sont faits sur le site propre de Pulsar pour les besoins de la documentation interne. Quand ils existent, ils peuvent être rendus disponibles au client par une simple demande. Exemples : TEC, CLASS.

Table des matières - Guide pratique de la méthodologie de Pulsar

  1. Gestion de l'application
  2. Structure et modèles de l'application
  3. Contrôle de version
  4. Orientation du design l'interface utilisateur (GUI)
  5. Lignes directrices du design de l'architecture
  6. Directives du design des bases de données (DB)
  7. Travail d'équipe
  8. Principes génériques de développement
  9. Assurance qualité
  10. Directives d'écriture des documents
  11. Directives du contrat de maintenace

Envoyez-nous une demande via notre formulaire pour obtenir notre méthodologie complète.