La conduite de projet dans le génie logiciel

Résumé du document

Cours de génie logiciel (format PowerPoint) relatif à la conduite de projet et aux risques de développement.

Extraits

[...] Caractéristiques objectif précis, unique et mesurable budget prédéterminé durée limitée : délai Contrairement au génie civil Chaque projet informatique est un cas nouveau, il y a peu de références standards, développer un logiciel s'apparente plus à une activité de recherche qu'à une routine. Le CC n'est presque jamais complet et figé : il s'élabore et s'adapte au mesure de l'avancement du projet parce que les systèmes informatiques sont trop complexes pour être maîtrisés par des êtres humains Il ne suffit pas de mettre de l'argent et de la technique , la qualité et la motivation des hommes sont prépondérants La conduite et la gestion de projet Projet de SI : Ensemble des activités de développement (conception et réalisation) d'un logiciel de mise en œuvre dans le SI de l'organisation Pilotage d'un projet : 2 niveaux de responsabilités Un niveau de décision : la conduite de projet Un niveau aide à la décision : consiste à apporter des éléments techniques ou de gestion (suivi des coûts, des délais . [...]

[...] Pour maîtriser les coûts : Utiliser des techniques d'industrialisation comme pour l'exemple des calculettes à 10F, ou des micros à moins de 6000F Concevoir chaque logiciel comme une brique d'un projet Les aspects d'évaluation des coûts et métrologie sont fondamentaux Définition d'un projet Un projet est un ensemble l'étapes et l'actions destinées à réaliser un but. C 'est un ensemble de travaux qui concourent à la réalisation l'un objectif unique et mesurable. [...]

[...] Les besoins du projet changent continuellement, mais ces changements peuvent être facilement incorporés parce que le logiciel est flexible Réalité Une définition insuffisante des besoins des usagers est la cause majeure d'un logiciel de mauvaise qualité et en retard Les coûts d'un changement pour corriger une erreur augmente dramatiquement dans les dernières phases de la vie d'un logiciel Les mythes du développeur Mythe Une fois que le programme est écrit, et marche, le travail du développeur est terminé Tant qu'un programme ne fonctionne pas, il n'y a aucun moyen d'en mesurer la qualité Pour le succès d'un projet, le bien livrable le plus important est un programme fonctionnel Réalité 50%-70% de l'effort consacré à un programme se produit après qu'il a été livré à l'usager Les revues de logiciel peuvent êre plus efficaces pour détecter les erreurs que les jeux d'essais pour certaines classes d'erreurs Les mythes du gestionnaire Mythe L'entreprise possède des normes, le logiciel développé devrait être satisfaisant Les ordinateurs et les outils logiciels que l'entreprise possède sont suffisants Si le projet prend du retard, on ajoutera des programmeurs Réalité Une configuration de logiciel inclut de la documentation, des fichiers de régénération, des données d'entrée pour des tests, et les résultats des tests sur ces données La qualité en génie logiciel? Le coût de correction d'une erreur est à chaque étape multiplié par 10 Il faut s'imposer des processus formels de développement : processus d'assurance qualité, existence de points de contrôle, la méthode doit être structurée, phasée avoir des produits finis en fin de phase : inspection et validation après chaque phase du développement être automatisée, être adaptable, avec un processus formel et exhaustif de tests technologie à jour (objets, Java, AGL ) La qualité en génie logiciel? [...]

[...] Du point de vue du génie logiciel : Objectif Moyen Délai Risques du développement logiciel Défaillance humaine Calendrier et Budget irréaliste Développement de fonctions inappropriées Développement IHM inapproprié Produit plaqué-or Volatilité des besoins Composants externes manquants Problèmes de performances . Les mythes du logiciel Mythes du client ou usager Mythes du développeur Mythes des gestionnaires Les mythes de l'usager Mythe Un énoncé général des objectifs est suffisant pour commencer. [...]

[...] retour à la phase antérieure) La structure linéaire de production des documents est artificielle Approuver un document est long et difficile On ne peut résoudre tous les problèmes en appliquant scrupuleusement un tel modèle Un modèle basé sur le risque Le modèle en spirale de Boehm met en œuvre une évaluation régulière des risques liés au projet permettant la mise en œuvre de solutions techniques pour contrer ces risques Cette évaluation englobe le autres approches, en permettant qu'un cycle de la spirale utilise un modèle de développement en cascade quand un risque d'intégration est identifié ou bien le prototypage quand le risque est lié à l'acceptation de l'interface utilisateur par le client, par exemple D'un cycle à l'autre Chaque cycle de la spirale donne lieu à la rédaction d'un document qui renseigne les rubriques suivantes : objectifs contraintes alternatives risques résolution des risques résultats plans conséquences pour la suite du projet La Gestion de Projet Cours_GL GL 2.2 La conduite de projets M. [...]