Pour les profanes, ce diaporama explique les différentes phases du développement professionnel de logiciel en utilisant la méthodologie BDUF qui, avec la vague agile/SCRUM très plébicité sur la toille, est souvent stigmatisé et considéré comme "ringarde". Ce n'est pourtant pas l'avis de certain seniors du développement logiciel tel que Steve McConnel auteur à succès de "Code Complete" 1 et 2, numéro 3 des ventes sur Amazon de la catégorie "Software Engineering". Il est destiné aux non-techniciens (chefs de projets, patrons d'entreprises) qui veulent en savoir plus sur le cycle de développement logiciel.

1. Le développement logiciel
expliqué à votre patron
Yassine Chaouche
Décembre 2012
yacinechaouche@yahoo.com
http://ychaouche.wikispot.org/Planning

2. Combien de temps ça prends ?
Pour savoir combien de temps prends le développement d’un logiciel, il faut avoir
bien compris les besoins des utilisateurs;

3. Comprendre ce qu’on cherche à faire
• Il existe une méthode rigoureuse pour s’assurer que l’on a bien compris les
besoins des utilisateurs, c’est de spécifier de manière formelle leurs besoins dans
des spécifications fonctionnelles et de les faire valider par ces derniers;

4. Spécs fonctionnelles
• Une fois qu’on s’assure qu’on a bien compris le besoin et qu’on explique aux
utilisateurs rigoureusement et dans le détail à quoi le logiciel va ressembler à
travers des spécs. fonctionnelles, on peut maintenant se demander combien de
temps ça prends pour développer un logiciel répondant à ces specs.

5. Spécs techniques
• Une fois qu’on a les idées claires, pour savoir combien de temps est-ce que le
codage va prendre, il faut au préalable, à l’instar d’un architecte qui veut
construire une maison, dessiner les plans de manière rigoureuse et précise;
• De même, un analyste va écrire dans des spécifications techniques les plans du
logiciel à développer;

6. A quoi servent les spécs. techniques ?
• Les spécifications techniques vont permettre, par exemple, de savoir quelle seront
les tables à ajouter, quelles colonnes y mettre, comment seront-elles mises en
relation;
• Entre autre, elles permettent de savoir quelles seront les fonctions, classes et
méthodes à écrire ainsi que les procédures nécessaires pour répondre à une
fonctionnalité spécifiée dans le spécs. fonctionnelles;

7. Penser au maximum de choses
• En réalité, les spécs. techniques servent à beaucoup plus de choses que ça (fichiers
à importer, fichiers à exporter, données à indexer etc.)
• L’idée est de savoir de manière général et aussi exhaustive que possible : qu’est-ce
que nous devons techniquement faire ?

8. Identifier, quantifier, analyser
La réalisation d'un tel planning nécessite la mise en œuvre de technique de
planification :
• les tâches doivent être identifiées;
• les tâches doivent être quantifiées en terme de délais, de coûts et de ressources;
• la logique de l'ensemble des tâches doit être analysée.

9. Rien n’est parfait
• Une fois les spécifications techniques établies, on aura une idée beaucoup plus
précise de ce qu’on devra développer et les estimations de planning ne seront que
plus justes (mais pas assez justes malheureusement);

10. La réalité des choses…

11. Malgrès tous ces efforts
• Le planning d’un développeur comporte en général entre 10% à 20% d’erreur d’estimation;
• Le planning du commanditaire (hiérarchie, client...) comporte en général entre 10% et 300%
d’erreur d’estimation.
• L'expert dans le domaine c'est vous, le développeur, pas votre hierarchie ou votre client.
Réflechissez-y un instant : ce n'est pas le client qui fixe des délais pour la construction de sa
maison, c'est l'entrepreneur qui les lui donne. Ce n'est pas le patient qui fixe la durée de son
traitement, c'est son médecin ou son pharmacien qui la fixe. Ce n'est toujours pas le client
qui fixe des délais pour une réponse à un crédit bancaire, c'est le banquier qui les annonce.
C'est toujours l'expert qui donne les délais de ses préstations de services, jamais son client.
• Tenter de compresser les délais annoncés par le développeur aboutit forcément à un
dépassement de délais

12. Le cône d'incertitude
• En phase de démarrage, quand on n’a qu’une vague idée de ce qui est demandé, les erreurs
d’estimations sont de l’ordre de 300 %
• La marge diminue à 100% quand tout le monde se met d’accord sur le produit à développer
• 50% quand le cahier des charges est validé
• 25% quand on se met d’accord sur l’interface utilisateur.
• Les estimations ne deviennent appréciables qu’au moment où les spécifications détaillées
sont établies, la marge descend alors à moins de 20% d’erreur.

13. Le cône d'incertitude

14. Quand s'engager sur des délais ?
• Il est imprudent de s’engager sur une date dès le début du projet car les estimations sont
trop larges et peuvent être jusqu’à 4 fois inférieurs au temps réel.
• Par exemple, si une estimation est donnée en phase de démarrage à 3 mois, le projet
pourrait très bien prendre entre 6 et 12 mois.
• On ne peut donc s'engager sur des délais qu'après avoir validé les spécs et les interfaces
utilisateurs (taux d’erreur inférieur à 20%).

15. Répartition de l’effort
• Bien que, a priori, le codage peut vous sembler
la chose la plus importante pour vous, il ne
représente même pas 50% du temps total du
projet;
• Plus vous passerez du temps dans la phase
d’analyse, moins vous perdez du temps dans la
phase de codage. Si vous le jugez nécessaire,
vous pouvez y allouer 30% du temps total du
projet;
• Quelque soit votre expertise et votre
diversification, vous aurez une phase
d’apprentissage (nouvelles librairies, nouveaux
formats de données, nouveaux systèmes etc.);
• Ne négligez pas le recettage et la mise en
production de la version final qui peut prendre
environ 20% du temps total du projet.
25%
10%
45%
20%
Répartition de l'effort
Analyse Apprentissage
Codage Finalisation

16. Nous sommes des humains, pas
des robots
• Nous avons une famille, des parents, des enfants. Ces personnes naissent, meurent, se
marient, partent en vacances et tombent malades. Un planning qui ne prends pas en
compte ces points est par définition irréaliste.
• Nous avons un mental, des pressions psychologiques, des fatigues nerveuses et des
périodes de manque de sommeil. Ne forcez pas trop fort sur vos ressources humaines
pour pouvoir les garder frais et dispos on the long run.
• Nous ne sommes pas tous nés égaux en talents, compétences et motivations. Les
délais de réalisation dépendent en grande partie du potentiel de votre équipe. Prenez
ceci en compte lors de vos évaluations.

17. Adoptez une méthodologie de
développement
• Peu importe laquelle. Travaillez méthodiquement est toujours meilleur que de
travailler sans aucune méthode.

18. Méthodes iteratives
• Ce type de méthodologies ne
peuvent donner une estimation
sur la durée total du projet mais
uniquement sur l’itération
actuelle.
• La durée d’une itération diffère
selon les méthodes utilisées
(Extreme Programming, RUP,
SCRUM).
• Par exemple, dans XP, les
itérations sont de l’ordre de
quelques semaines.

19. Placez l'utilisateur au centre
C’est l’utilisateur qui doit mener le processus de développement en :
• Confirmant et affinant régulièrement ses besoins ;
• Priorisant les fonctionnalités à implémenter. Le chef de projet à aussi le rôle de
reprioser les tâches en fonction de l’importance de la fonctionnalité demandée, de
l’urgence, des délais demandés par les développeurs, et du retard ou avance pris sur
le projet.
• validant ce qui a été développé ;

20. Evitez les principales causes de
retards (1/3)
• Baisse de motivation : plusieurs études ont montré qu’aucun facteur n’était plus
déterminant que le manque de motivation de l’équipe (Bohem 1981 cité par Steve
McConnell)
• Ajouter une personne à un projet déjà en retard : Brooks compare cela à ajouter de
l’huile sur le feu.
• Expectations irréalistes : il est très difficile de faire vite dans le business du software
sans altérer sa qualité ou augmenter son coût.

21. Evitez les principales causes de
retards (2/3)
• Pas de retour utilisateur : comme dit précédement, l’utilisateur doit être au centre.
• Planification insuffisante : si on ne planifie pas comment atteindre rapidement
l’objectif, on ne peut s’attendre à l’atteindre rapidement.
• Certains projets qui doivent être terminés rapidement essayent de couper court à
toute activité non essentielle. L’analyse des besoins, l’architecture et la modélisation
sont les cibles favorites puisqu’elles ne produisent pas de code. Cette situation de
« sauter directement au code » a des conséquences facilement prédictibles : cette
partie du travail qui doit être faite en amont va de toute façon un jour ou l’autre être
faite en aval, mais coûtera 10 à 100 fois plus chère (Fagan 1976; Boehm and
Papaccio 1988). Si on ne trouve pas les 2 mois pour faire l’étude maintenant, allons-
nous trouver les 20 mois nécessaires par la suite ?

22. Evitez les principales causes de
retards (3/3)
• « Code-like-hell programming » : certaines organisations pensent que pour aller plus
vite il faut « coder-comme-un-fou ». Leurs raisonnement est le suivant : avec un bon
développeur, n’importe quel obstacle sera contourné. En réalité, c’est simplement du
« code-and-fixe » déguisé (code-et-répare) combiné avec des délais ambitieux. Cette
combinaison ne marche pratiquement jamais.
• Marchander sur les tests : prendre des raccourcis en voulant éliminer ou raccourcir la
durée des tests est une pratique courante dans des projets qu’il faut livrer au plus
vite. Des études de cas ont montré que lorsqu’un projet atteint sont stade « feature
complete », c'est-à-dire ou toutes les fonctionnalités ont été codées, sans avoir passé
du temps à écrire et implémenter des tests, il était tellement truffé de bugs qu’il
fallait encore 5 mois supplémentaires avant de pouvoir le mettre en production. Ce
résultat est typique. Enlever 1 journée d’assurance qualité en amont aura pour
conséquence de payer 3 à 10 jours de réparation en aval (Jones 1994).

23. Happy coding !

24. Chosen links
Software developement at top speed (Steve McConnell – Code Complete)

http://www.stevemcconnell.com/articles/art04.htm
Classic mistakes enumerated (Steve McConnell – Code Complete)

http://www.stevemcconnell.com/rdenum.htm
How long would it take if everything went wrong ? (Jeff Atwood – coding horror)

http://www.codinghorror.com/blog/2006/06/how-long-would-it-take-if-everything-went-wrong.html
Epopée du développement logiciel

http://ychaouche.wikispot.org/PMHistoireVecue