Le développement logiciel
expliqué à votre patron
Yassine Chaouche
Décembre 2012
yacinechaouche@yahoo.com
http://ychaouche...
Combien de temps ça prends ?
Pour savoir combien de temps prends le développement d’un logiciel, il faut avoir
bien compri...
Comprendre ce qu’on cherche à faire
• Il existe une méthode rigoureuse pour s’assurer que l’on a bien compris les
besoins ...
Spécs fonctionnelles
• Une fois qu’on s’assure qu’on a bien compris le besoin et qu’on explique aux
utilisateurs rigoureus...
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 fa...
A quoi servent les spécs. techniques ?
• Les spécifications techniques vont permettre, par exemple, de savoir quelle seron...
Penser au maximum de choses
• En réalité, les spécs. techniques servent à beaucoup plus de choses que ça (fichiers
à impor...
Identifier, quantifier, analyser
La réalisation d'un tel planning nécessite la mise en œuvre de technique de
planification...
Rien n’est parfait
• Une fois les spécifications techniques établies, on aura une idée beaucoup plus
précise de ce qu’on d...
La réalité des choses…
Malgrès tous ces efforts
• Le planning d’un développeur comporte en général entre 10% à 20% d’erreur d’estimation;
• Le pl...
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’estimat...
Le cône d'incertitude
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 s...
Répartition de l’effort
• Bien que, a priori, le codage peut vous sembler
la chose la plus importante pour vous, il ne
rep...
Nous sommes des humains, pas
des robots
• Nous avons une famille, des parents, des enfants. Ces personnes naissent, meuren...
Adoptez une méthodologie de
développement
• Peu importe laquelle. Travaillez méthodiquement est toujours meilleur que de
t...
Méthodes iteratives
• Ce type de méthodologies ne
peuvent donner une estimation
sur la durée total du projet mais
uniqueme...
Placez l'utilisateur au centre
C’est l’utilisateur qui doit mener le processus de développement en :
• Confirmant et affin...
Evitez les principales causes de
retards (1/3)
• Baisse de motivation : plusieurs études ont montré qu’aucun facteur n’éta...
Evitez les principales causes de
retards (2/3)
• Pas de retour utilisateur : comme dit précédement, l’utilisateur doit êtr...
Evitez les principales causes de
retards (3/3)
• « Code-like-hell programming » : certaines organisations pensent que pour...
Happy coding !
Chosen links
Software developement at top speed (Steve McConnell – Code Complete)

http://www.stevemcconnell.com/articles...
Prochain SlideShare
Chargement dans…5
×

Le développement logiciel expliqué à votre patron en 24 slides

627 vues

Publié le

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.

Publié dans : Logiciels
0 commentaire
3 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
627
Sur SlideShare
0
Issues des intégrations
0
Intégrations
12
Actions
Partages
0
Téléchargements
15
Commentaires
0
J’aime
3
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Le développement logiciel expliqué à votre patron en 24 slides

  1. 1. Le développement logiciel expliqué à votre patron Yassine Chaouche Décembre 2012 yacinechaouche@yahoo.com http://ychaouche.wikispot.org/Planning
  2. 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. 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. 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. 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. 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. 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. 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. 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. 10. La réalité des choses…
  11. 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. 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. 13. Le cône d'incertitude
  14. 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. 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. 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. 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. 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. 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. 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. 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. 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. 23. Happy coding !
  24. 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

×