Nous aspirons tous à ce que nos projets logiciels soient livrés dans les délais et selon le budget*. Les logiciels sont complexes et, à moins que nous planifiions leur réussite, il est peu probable qu'ils « se produisent tout simplement ». Lors de la planification de projets logiciels, nous avons heureusement l’expérience des échecs passés dont nous pouvons tirer des leçons. Nous devons tirer les leçons de ces erreurs afin que nos projets puissent éviter la voie « pathologique ».
Qu’entend-on par retard dans un projet ? Le retard concerne en réalité un projet qui est livré en retard par rapport aux attentes, ou en d'autres termes en retard par rapport au devis. Pour éviter toute déception, nous devons créer des attentes (estimations) réalistes ET nous devons effectuer les activités pour éviter les problèmes qui pourraient conduire à ce que les estimations ne soient pas respectées.
Dans une étude portant sur 84 projets d'IBM et d'AT&T, Capers Jones a observé que les projets en retard de 6 mois ou plus montraient peu de signes de difficultés au début. Les derniers projets avaient lésiné sur de nombreuses activités cruciales, notamment : les revues des exigences, les inspections, le contrôle qualité. Tout cela concerne une attention précoce portée à la qualité.
Pourquoi ont-ils été mal estimés ? Soit l'estimation était inappropriée, soit les activités qui auraient pu la maintenir dans les délais n'ont pas été correctement réalisées.
Capers cite 10 facteurs conduisant à une inadéquation estimation/réel :
*Certaines parties bénéficient des frais supplémentaires générés lors de la prolongation d'un projet.
Comment l'IA peut aider
La planification commence tôt, comme vous le savez ou lorsque vous découvrez les exigences. ScopeMaster utilise l'IA pour vous aider à comprendre très rapidement les exigences. Qui conduit à meilleurs plans.
Facteurs affectant le calendrier du logiciel et estimer la fiabilité
| Facteur | Description | Impact sur le calendrier | Atténuation |  |
|---|---|---|---|---|
Erreurs de métriques |
L'utilisation de mesures inappropriées telles que les Story Points ou similaires entraînera de mauvaises estimations | Jusqu'à 100% | Utiliser le dimensionnement fonctionnel, les points de fonction COSMIC | ScopeMaster automatise le dimensionnement fonctionnel et élimine la plupart de ces erreurs. |
Ajustement technologique |
Incertitude/retard causé lors de l'introduction de nouveaux outils/technologies/techniques | L'impact observé peut entraîner des erreurs d'estimation allant jusqu'à 150% | Prévoyez au moins un mois pour que la nouvelle technologie soit intégrée à l'utilisation, planifiez-la | |
Erreurs de chemin critique |
L'illusion que les progrès sont sur la bonne voie jusqu'à ce que le projet soit stoppé par un événement bloquant | Erreur dans les horaires jusqu'à 25% | Une meilleure surveillance du chemin critique et une atténuation proactive des risques techniques peuvent les minimiser. | ScopeMaster incite à une réflexion précoce sur les complexités et les intégrations, qui sont des causes courantes de problèmes de CP |
Problèmes de dimensionnement/portée |
Une mauvaise sous-estimation de la véritable ampleur d'un projet entraînera une augmentation du travail et du calendrier. La qualité et l'exhaustivité des exigences ont également un impact sur la capacité à dimensionner correctement | Erreur 15-100% | Le dimensionnement fonctionnel et la vérification automatisée de l’exhaustivité contribueront à atténuer ce problème. | Résolu par ScopeMaster (même pour les chefs de projet inexpérimentés). |
Exigences rampantes des utilisateurs |
Les exigences changeantes (à distinguer des exigences manquantes) entraîneront une augmentation du travail et du calendrier. | Les taux d'erreur sont plus élevés sur les projets plus longs 2-10% par mois | Cela doit être planifié et adopté (Agile). | ScopeMaster aide de plusieurs manières : amélioration de la qualité des premières exigences, meilleure élicitation et suivi de la volatilité. |
Erreurs d'affectation |
Ne pas allouer le personnel approprié à une activité au sein d’un projet. Chaque personne remplissant un rôle donné a une capacité limitée à effectuer un travail et doit être affectée au moment approprié du projet. | Erreur jusqu'à 100% | Des gestionnaires compétents qui comprennent les capacités d’affectation (voir ci-dessous). | ScopeMaster aide en fournissant une taille fonctionnelle à partir de laquelle les étendues d'affectation peuvent être déterminées. |
Erreurs de taux de production |
La différence entre le taux de production attendu et réel. | 20-100% | Des mesures réalistes et appropriées du taux de production seront utiles, par exemple. CFP/mois pour une équipe donnée. | ScopeMaster aide en fournissant une taille fonctionnelle à partir de laquelle les taux de production peuvent être mesurés, comparés et surveillés. |
Renforcement du personnel |
Ne pas déployer le bon nombre de personnel doté des bonnes compétences au bon moment entraînera des retards. | Probablement un impact d’ici des semaines, voire des mois. | Les gestionnaires compétents doivent planifier de manière appropriée. | ScopeMaster aide en fournissant une taille fonctionnelle à partir de laquelle l'affectation et les portées peuvent être déterminées. |
Sélection des tâches |
Ne pas prendre en compte toutes les activités du projet, et pas seulement le codage, entraînera des erreurs de planification. | Observé jusqu'à 1000% | Les gestionnaires compétents doivent planifier toutes les activités de manière appropriée. | |
Ingérence exécutive ou politique |
Les dirigeants décrètent des délais ou d'autres contraintes inappropriées qui conduisent à une mauvaise qualité. | Erreur jusqu'à 50% pour le planning, 100% pour les coûts | Les managers compétents devraient s’opposer fermement à une telle ingérence. | ScopeMaster crée des estimations de taille fonctionnelle à partir desquelles des calendriers réalistes peuvent être déterminés et utilisés comme défense. |
Planification basée sur les activités basé sur la taille fonctionnelle
Planification de projets logiciels
Le facteur le plus critique pour déterminer la durée d’un projet est sa taille. Par taille, nous faisons référence à la taille fonctionnelle. La taille fonctionnelle est le moyen le plus fiable de dimensionner un projet logiciel. Contrairement aux story points (qui sont une estimation technique non linéaire et subjective de l'effort), la taille fonctionnelle est généralement cohérente, à quelques % près, quelle que soit la personne qui la dimensionne.
Pour déterminer dans quelle mesure chaque activité est appropriée pour notre projet, nous devons comprendre à la fois le portée de la mission (quelle capacité un individu peut gérer) et leur taux de production (quelle capacité ils peuvent gérer sur une période donnée). Ceux-ci sont présentés dans le tableau ci-dessous en fonction de la taille fonctionnelle du logiciel sur lequel on travaille dans Function Points.
Il existe deux normes principales pour la taille fonctionnelle : les points de fonction traditionnels (IFPUG) et les points de fonction COSMIC. Nous recommandons ce dernier principalement parce qu'il gère très bien les exigences incomplètes, vous n'avez pas besoin de connaître toutes les exigences pour dimensionner un logiciel (ce que vous faites généralement avec IFPUG).
Missions d'activité et productivité moyenne
Pour une planification basée sur les activités
Toutes ces activités ne sont pas nécessaires sur tous les projets. À titre indicatif, plus le projet est vaste, plus vous devrez en réaliser.
| Activité | Portée de l'affectation du personnel, FP | Production mensuelle, FP |
|---|---|---|
Exigences |
333 | 175 |
Prototypage |
500 | 150 |
Architecture |
1000 | 300 |
Plans de projet |
1000 | 500 |
Conception initiale |
250 | 175 |
La conception de détail |
250 | 150 |
Revues de conception |
200 | 225 |
Codage |
175 | 50 |
Réutilisation Acquisition |
500 | 600 |
Achat de forfait |
2000 | 400 |
Inspections des codes |
150 | 150 |
Vérification et validation indépendantes |
500 | 125 |
Gestion de la configuration |
1000 | 175 |
L'intégration |
1000 | 250 |
Documentation utilisateur |
1000 | 70 |
Tests unitaires |
200 | 150 |
Test fonctionel |
200 | 150 |
Tests d'intégration |
250 | 175 |
Test du système |
250 | 200 |
Tests sur le terrain (bêta) |
1000 | 250 |
Tests d'acceptation |
1000 | 350 |
Tests indépendants |
750 | 200 |
Assurance qualité |
1000 | 150 |
Installation et formation |
2000 | 350 |
Gestion de projet |
1000 | 100 |
Un tableau équivalent, basé sur la CFP, n'est pas disponible, néanmoins il est raisonnable de considérer FP et CFP comme étant à peu près équivalents lors de l'utilisation de ces données pour la planification basée sur les activités.
Une approche basée sur les activités est particulièrement utile car elle nous aide à identifier le personnel et les compétences nécessaires au cours du projet. Des outils tels que SRM® de Namcook Analytics SEER pour les logiciels de Galorath, MINCEUR de QSM ou Une véritable planification à l'unisson (anciennement Price Systems) peut également aider en fournissant un profil de personnel adapté à un projet donné au fil du temps.
Il s'agit d'une version condensée du tableau 11.4 publié dans « Estimating Software Costs, deuxième édition » par Capers Jones. Disponible à l'achat sur Amazon. Nb, ceci n'est qu'une illustration des activités et de leurs niveaux d'effectifs, des taux de productivité (coûts implicites). Vous constaterez que maintenir vos propres repères pour ces activités est une activité utile.
Estimation précoce
Si vous recherchez de l'aide pour estimer la taille, la durée et le personnel d'un projet avant de connaître les exigences, alors un outil approprié est Software Risk Manager (SRM) de Namcook Analytics. Il utilise des données historiques sur le projet et divers algorithmes pour donner des estimations de la taille, de la durée, du personnel et bien plus encore. Le MRS se trouve au Namcook site web.
Conclusion
Les principaux points à retenir de cet article sont :
- Il est possible de créer des estimations réalistes pour les projets logiciels qui sont raisonnablement cohérents avec ce qui se passera finalement.
- La taille (taille fonctionnelle) est le facteur le plus important affectant l’effort et la durée. La fiabilité de l'estimation de la taille dépend de nombreux facteurs.
- Une approche par activité basée sur la taille fonctionnelle peut produire une estimation raisonnable de l’effort (et donc du coût).
- Connaître l'effort et les taux de productivité typiques nous donne une estimation raisonnable de la durée.
- Les très grands projets bénéficieront également d’un outil de planification paramétrique capable de prévoir la taille de l’équipe et les compétences au fil du temps tout au long du projet.
