But de cette introduction à la gestion de projets

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
Under 20%
21 - 50%
51 - 100%
101 - 200%
201 - 400%
Over 400%
% of Responses
15.5%
31.5%
29.6%
10.2%
8.8%
4.4%
Time Overruns
Under 20%
21 - 50%
51 - 100%
101 - 200%
201 - 400%
Over 400%
% of Responses
13.9%
18.3%
20.0%
35.5%
11.2%
1.1%
Project Success Factors
% of Responses
1. User Involvement
2. Executive Management Support
3. Clear Statement of Requirements
4. Proper Planning
5. Realistic Expectations
6. Smaller Project Milestones
7. Competent Staff
8. Ownership
9. Clear Vision & Objectives
10. Hard-Working, Focused Staff
Other
15.9%
13.9%
13.0%
9.6%
8.2%
7.7%
7.2%
5.3%
2.9%
2.4%
13.9%
Project Impaired Factors
% of Responses
1. Incomplete Requirements
2. Lack of User Involvement
3. Lack of Resources
4. Unrealistic Expectations
5. Lack of Executive Support
6. Changing Requirements & Specifications
7. Lack of Planning
8. Didn't Need It Any Longer
9. Lack of IT Management
10. Technology Illiteracy
Other
13.1%
12.4%
10.6%
9.9%
9.3%
8.7%
8.1%
7.5%
6.2%
4.3%
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
* FAST
* APTE
* Merise
méthodes non spécifiques à l'informatique
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
* ASD (Adaptive Software Development)
Crystal
* FDD (Feature-driven design)
* DSDM (Dynamic Systems Development Method)
* Unified Process : RUP, AUP, XUP, 2TUP
* eXtreme Programming
* ......
méthodes agiles
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.
Modèle incrémental
Le modèle incrémental est un modèle itératif.
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
Unité de traitement
Données
de sortie
Exemple de décomposition
Dico
Entrées
utilisateur
Dico
Lire et
préparer
Dico
A1
Entrées utilisateur
Dico enrichi
Analyser
la syntaxe
Affichage
écran
Dico préparé
Traiter info et
compléter
Dico
A2
Afficher écran
Dico enrichi
Sauver
Dico
A3
A0
Dico enrichi et sauvé
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.