But de cette introduction à la gestion de projets : Présenter quelques méthodes de conception logicielle. Replacer la conception de bases de données dans un contexte plus vaste. Présenter quelques méthodes de gestion de projets car certaines notions, certaines démarches peuvent être utilisées en dehors de l'informatique.
Un aperçu des Problèmes : le rapport Chaos du Standish Group 1995 (extraits) 31.1% of projects will be cancelled before they ever get completed. 52.7% of projects completed and operational but over-budget and/or over the time. The average cost overrun is 189% of their original estimates. On the success side, the average is only 16.2% for software projects that are completed on-time and on-budget. In the larger companies, the news is even worse: only 9% of their projects come in on-time and on-budget.
Parmi les projets hors délai/hors budget Cost Overruns % of Responses Under 20% 15.5% 21-50% 31.5% 51-100% 29.6% 101-200% 10.2% 201-400% 8.8% Over 400% 4.4% Time Overruns % of Responses Under 20% 13.9% 21-50% 18.3% 51-100% 20.0% 101-200% 35.5% 201-400% 11.2% Over 400% 1.1%
Project Success Factors % of Responses 1. User Involvement 15.9% 2. Executive Management Support 13.9% 3. Clear Statement of Requirements 13.0% 4. Proper Planning 9.6% 5. Realistic Expectations 8.2% 6. Smaller Project Milestones 7.7% 7. Competent Staff 7.2% 8. Ownership 5.3% 9. Clear Vision & Objectives 2.9% 10. Hard-Working, Focused Staff 2.4% Other 13.9%
Project Impaired Factors % of Responses 1. Incomplete Requirements 13.1% 2. Lack of User Involvement 12.4% 3. Lack of Resources 10.6% 4. Unrealistic Expectations 9.9% 5. Lack of Executive Support 9.3% 6. Changing Requirements & Specifications 8.7% 7. Lack of Planning 8.1% 8. Didn't Need It Any Longer 7.5% 9. Lack of IT Management 6.2% 10. Technology Illiteracy 4.3% Other 9.9%
Pour compléter ce bilan de satisfaction de l'informatisation, évoquons les bugs informatiques : Le célèbre bogue de l'an 2 000 (en France, 500 milliards de francs) : la donnée "année" était codée sur deux caractères. Perte de la sonde Mars Climate Orbiter, (septembre 1999) : confusion entre pieds et mètres. Destruction de la sonde Mariner 1 (juillet 1962, coût : 80 M$) : un trait d union oublié dans un programme Fortran. Résultats électoraux mathématiquement impossibles à Liège (octobre 2006). Surdosage des rayons à l'hôpital d'epinal (mai 2004-août 2005) "mauvaise ergonomie d'un logiciel obsolète". 4 décès. etc, etc, etc... Personnellement testé (août 2008) : le formulaire d'inscription d'un fournisseur d'accès internet affiche une page vide et bloque l'inscription. Erreur : incapacité à gérer les accents dans le nom de famille, impossible de générer l'adresse mail correspondante.
Mais il faut reconnaître que les problèmes sont complexes, les problèmes mettent en oeuvre plusieurs services, domaines, compétence... objectifs exacts sont rarement bien connus, bien définis au début du projet le matériel et les logiciels évoluent vite
Objectifs de qualité d'une application Validité : aptitude d'un produit logiciel à remplir exactement ses fonctions, définies par le cahier des charges et les spécifications. Fiabilité (ou robustesse) : aptitude d'un produit logiciel à fonctionner dans des toutes les conditions. Ne plante pas Extensibilité : facilité avec laquelle un logiciel se prête à une modification ou à une extension des fonctions qui lui sont demandées. Réutilisabilité : aptitude d'un logiciel à être réutilisé, en tout ou en partie, dans de nouvelles applications. Compatibilité : facilité avec laquelle un logiciel peut être combiné avec d'autres logiciels. Efficacité : Utilisation optimale des ressources matérielles (temps et espace). Portabilité : facilité avec laquelle un logiciel peut être transférée sous différents environnements matériels et logiciels. Vérifiabilité : facilité de préparation des procédures de test. Intégrité : aptitude d'un logiciel à protéger son code et ses données contre des accès non autorisés. Facilité d'emploi : facilité d'apprentissage, d'utilisation, de préparation des données, d'interprétation des erreurs et de rattrapage en cas d'erreur d'utilisation. Pérennité (facilité de la maintenance)
Comment y arriver?? Adopter une méthode d'analyse et de conception d'un logiciel qui définit des étapes, des buts intermédiaires Formaliser / Décomposer / Utiliser des modèles, des schémas Les étapes définissent le cycle de vie du logiciel : de l'énoncé du problème jusqu'à l'arrêt de l'utilisation du logiciel.
Cycle de vie des logiciels Vision très simplifiée de la vie du logiciel mais qui fait bien apparaître la maintenance dans la vie d'un logiciel
Etapes du cycle de vie d'une application Il existe une norme ISO (12207) qui définit précisément les différentes activités rencontrées lors du développement et de la maintenance d un logiciel. Elle contient 23 processus, 95 activités, 325 tâches, 224 résultats. Définition des objectifs finalité du projet et inscription dans une stratégie globale. Analyse des besoins et faisabilité recueil et formalisation des besoins du demandeur (client) et des contraintes du système. estimation de la faisabilité. cahier des charges. Conception générale élaboration des spécifications de l'architecture (structure) générale du logiciel. décomposition en modules indépendants (si possible). Conception architecturale et détaillée description précise de chaque module du logiciel. Implémentation (Développement, codage ou programmation) traduction dans un langage de programmation des fonctionnalités définies lors des phases de conception.
Vérification - Tests unitaires vérification individuelle de l'implémentation de chaque module. conformité aux spécifications. Intégration - assemblage/interfaçage des différents modules du logiciel. tests d'intégration. Validation - Qualification (ou recette) test dans les conditions normales d'utilisation. vérification de la conformité du logiciel aux spécifications initiales. Documentation Elle vise à produire les informations nécessaires pour l'utilisation du logiciel et pour des développements ultérieurs. Mise en production Maintenance Elle comprend toutes les actions correctives (maintenance corrective) et évolutives (maintenance évolutive) sur le logiciel. Cela définit une terminologie, des documents types, décrit des activités... cela ne donne pas une méthode.
Méthodes d'analyse et de conception Organiser ces étapes du cycle de vie du logiciel : comment les enchaîner et comment les garantir. => modèles de cycle de vie (en cascade, en V,...). L'évolution des méthodes : évolutions de logiciels Les méthodes fonctionnelles (SADT...) ont pour origine la programmation structurée. Conception descendante ; décomposer un problème en fonctions. Solutions spécifiques aux problèmes. Les méthodes objet (OMT...) ont pour origine la programmation objet. Conception descendante ; décomposer un problème en modules. Raffinements successifs. Notion de composants et réutilisation. Possibilité de maquettage, de prototypage. évolution des mentalités Les méthodes «agiles» privilégient les besoins des utilisateurs, la livraison de fonctionnalités utiles au client plutôt que la production de documentation, collaboration... Le Manifeste Agile ne définit pas une méthode mais une philosophie de travail. Tout simplement, les méthodes évoluent parce que l'informatique n'est pas une science exacte.
Quelques méthodes d'analyse et de conception * SADT méthodes non spécifiques à l'informatique * FAST * APTE * Merise méthode très répandue en France * HERMES modèle en V * Booch, OMT (Object Modeling Technique), OOSE méthodes objets * MBASE modèle itératif de Boehm * SCRUM méthodes agiles * ASD (Adaptive Software Development) Crystal * FDD (Feature-driven design) * DSDM (Dynamic Systems Development Method) * Unified Process : RUP, AUP, XUP, 2TUP * extreme Programming *...
Modèle en cascade Le modèle de cycle de vie en cascade a été mis au point dès 1966, puis formalisé aux alentours de 1970. Les phases se succèdent séquentiellement. A la fin de la phase, des documents sont produits pour vérifier et certifier la validité de la phase. Caractéristiques principales : succession des étapes calendrier de livraisons validation de chaque étape test, documents...
Modèle en V Le modèle de cycle de vie en V est plus réaliste. Chaque étape définit ses procédures de tests. En phase de spécification, on définit des procédures de qualification. En phase de conception globale, on définit des procédures d'intégration. En phase de conception détaillée, on définit les tests unitaires.
Le modèle incrémental est un modèle itératif. Modèle incrémental Le logiciel est spécifié et conçu dans son ensemble : maquette/prototype. La réalisation se fait par incréments (petit nombre de fonctionnalités à chaque itération). Chaque incrément fait l'objet des activités de conception architecturale jusqu'aux tests, puis est intégré à l'ensemble des précédents. Permet une utilisation progressive de l'application.
Modèle en spirale Modèle itératif, dans lequel la planification de la version se fait selon une analyse de risques. Idée : S attaquer aux risques les plus importants assez tôt, afin que ceux-ci diminuent rapidement. 1 détermination des objectifs, alternatives pour les atteindre. 2 analyse des risques, évaluation des alternatives, maquettage 3 développement et vérification 4 résultats et planification du cycle suivant.
QUELQUES MÉTHODES Méthode SADT Méthode d'analyse hiérarchique et descendante ; 1977 (1982 en Europe). formalisme graphique et textuel facile à apprendre, initialement pour systèmes automatisés, vise plus les traitements que les données (langages procéduraux). Première partie du cycle de vie logicielle. But : modéliser le problème posé (informatique, automatique ou autre), avant de chercher à en extraire une solution, et d'autre part d'assurer une communication efficace entre les intervenants. Utilise des entrées, sorties, mécanismes (flèche du bas), contrôle, actigramme et datagramme.
Actigramme (pour le datagramme, inverser activité/donnée) Données de contrôle Données d'entrée AGIR Données de sortie Unité de traitement
Exemple de décomposition Dico Entrées utilisateur Analyser la syntaxe Dico enrichi Affichage écran Dico Entrées utilisateur Lire et préparer Dico A1 Dico préparé Traiter info et compléter Dico A2 Dico enrichi Sauver Dico A3 Afficher écran Dico enrichi et sauvé A0
Dico (Sous forme texte) Lire le Dico A11 catégories Transformer catégories en liste A12 expression s Transformer en liste de listes A13 A1 Dico préparé (en liste de listes)
Méthode Merise Méthode franco-française. Séparation des données et des traitements. Démarche descendante sur trois niveaux ; elle peut être assimilée (approximativement) à un cycle en cascade. Conceptuel Logique Physique
Unified Process Méthode générique, itérative et incrémentale ; Centrée sur l'architecture 4+1 ; guidée par les besoins de l'utilisateur. Adaptée aux langages orientés objets, utilisant UML.
Extreme Programming Méthode agile de gestion de projet informatique, adaptée aux équipes réduites avec des besoins changeants. Méthode itérative centrée sur les besoins de l'utilisateur.
Quatre valeurs : communication, simplicité, retour d'information (feedback), courage. Treize Pratiques : Client sur le Site (On-Site Customer) Séance de Planification (Planning Game) Intégration Continue (Continuous Integration) Livraisons Fréquentes (Frequent Releases) Rythme Soutenable (Forty-hour Week) Tests de Recette (Acceptance Tests) Tests Unitaires (Unit Tests) Conception Simple (Simple Design) Métaphore(Metaphor) Remaniement Continu (refactorisation) du Code Convention de Code (Coding Standard) Programmation En Binome (Pair Programming) Propriété Collective du Code (Collective Code Ownership)
Mise en évidence des phases dans le cycle de vie :
Méthode DSDM Méthode de la famille des méthodes «agiles», environnement RAD (Développement Rapide d'applications) Utilisation de prototypes : un prototype noyau initial auquel on ajoute des fonctionnalités de manière itérative. Principes de DSDM appliqués au cours des différentes étapes : * Implication active des utilisateurs. * Autonomie - pouvoir de décision des équipes DSDM. * Livraison fréquente de produits. * Adéquation aux besoins (critère essentiel d'acceptation du produit). * Développement itératif et incrémental (basée sur le feedback) * Réversibilité de toutes les modifications. * Synthèse - les besoins sont définis, initialement, à un niveau global. * Tests intégrés à toutes les étapes du cycle de vie. * Coopération et collaboration.
CONCLUSION tendance des méthodes actuelles Manifeste des méthodes agiles - 2001 Les méthodes «agiles» privilégient les besoins des utilisateurs, la livraison de fonctionnalités utiles au client plutôt que la production de documentation... Le Manifeste ne définit pas une méthode mais une philosophie de travail. Manifeste Agile signée par des développeurs, concepteurs de méthodes : 4 Valeurs L'équipe, les individus, les interactions doivent primer sur les processus et les outils Le développement logiciel doit primer sur la documentation exhaustive La collaboration avec le client doit primer sur la négociation contractuelle L ouverture au changement doit primer sur le suivi d un plan rigide 12 principes # Notre priorité est de satisfaire le client par des livraisons rapides et continues de logiciel utile. # Intégrer les changements aux exigences même s ils arrivent tard dans le processus de développement. Les méthodes Agiles intègrent rapidement les changements de façon à offrir un avantage compétitif au client.
# Livrer fréquemment du logiciel opérationnel (quelques semaines ou quelques mois en visant des délais courts). # Les clients et les développeurs doivent travailler main dans la main quotidiennement tout au long du projet. # Élaborer des projets autour d individus motivés. Leur procurer l environnement et le support nécessaire et leur faire confiance pour réaliser le travail. # La façon la plus efficace de transmettre l information à une équipe et entre les membres est par des conversations en face à face. Le logiciel opérationnel est la principale mesure de progrès # Agile favorise le développement à rythme "normal". # Les gestionnaires, développeurs et utilisateurs devraient être en mesure de maintenir un rythme constant et ce, indéfiniment. # Porter une attention continue à l excellence technique et à un bon design améliore l agilité. # La simplicité - l art de maximiser la quantité de travail non fait - est essentielle. # Les meilleures architectures, exigences et designs prennent naissance dans des équipes qui se gèrent elles-mêmes. # Régulièrement, l équipe fait une réflexion sur les façons de devenir plus efficace, s ajuste et modifie son comportement en conséquence.
D'après Scott W. Ambler, les méthodes agiles suivent un cycle itératif et incrémental.