developpement de projet informatique
L'aboutissement d'un projet informatique est une opération complexe qui
mobilise des moyens importants en terme de temps et de personnel, donc de
budget. Si on y prend pas garde, on se retrouve facilement en dépassement de
délai et de coût. De plus, une mauvaise étude peut mener à un résultat non
conforme à la demande.
Il convient donc d'agir avec le plus d'efficacité possible. Pour cela, il
existe un certain nombre de règles simples qui permettent de gérer le projet de
façon optimale et maîtrisée.
II. Un peu de réflexion et du
bon sensLe bon sens est la chose la mieux partagée au monde
Il est un principe de base et de bon sens qui veut que
ce qui se
conçoit bien s'énonce clairement
Ce principe, énoncé par un poète français du 17ème siècle (Nicolas
Boileau), prend tout son sens dès qu'il s'agit de réaliser le
moindre projet. Il dit, en substance, que l'on ne peut réaliser quoique ce soit
de sérieux si on a pas pris la peine au préalable de définir ce que l'on veut
faire.
On peut y adjoindre les 4 préceptes du Discours de la Méthode de Descartes :
Ainsi, au
lieu de ce grand nombre de préceptes dont la logique est composée, je crus que
j'aurais assez des quatre suivants, pourvu que je prisse une ferme et constante
résolution de ne manquer pas une seule fois à les observer.
Le premier était de ne recevoir jamais aucune chose
pour vraie, que je ne la connusse évidemment être telle : c'est-à-dire,
d'éviter soigneusement la précipitation et la prévention ; et de ne comprendre
rien de plus en mes jugements, que ce qui se présenterait si clairement et si
distinctement à mon esprit, que je n'eusse aucune occasion de le mettre en
doute.
Le deuxième, de diviser chacune des difficultés que
j'examinerais , en autant de parcelles qu'il se pourrait, et qu'il serait
requis pour les résoudre.
Le troisième, de conduire par ordre mes pensées, en
commençant par les objets les plus simples et les plus aisés à connaître, pour
monter peu, comme par degrés, jusques à la connaissance des plus composés ; et
supposant même l'ordre entre ceux qui ne se précèdent point naturellement les
uns les autres.
II-D. VérificationEt le
dernier, de faire partout des dénombrements si entiers, et des revues si
générales, que je fusse assuré de ne rien omettre.
Ces longues
chaînes de raisons, toutes simples et faciles, dont les géomètres ont coutume
de se servir, pour parvenir à leurs plus difficiles démonstrations, m'avaient
donné occasion de m'imaginer que toutes les choses, qui peuvent tomber sous la
connaissance des hommes, s'entre-suivent en même façon et que, pourvu seulement
qu'on s'abstienne d'en recevoir aucune pour vraie qui ne le soit, et qu'on
garde toujours l'ordre qu'il faut pour les déduire les unes des autres, il n'y
en peut avoir de si éloignées auxquelles enfin on ne parvienne, ni de si
cachées qu'on ne découvre.
Qui se résument en :
Ne recevoir
aucune chose pour vraie tant que son esprit ne l'aura clairement et
distinctement assimilé préalablement
Trier ses
difficultés afin de mieux les examiner et les résoudre
Établir un
ordre de pensées, en commençant par les plus simples jusqu'aux plus complexes
et diverses, et ainsi de les retenir toutes et en ordre
Passer
toutes les choses en revue afin de ne rien omettre
Cette définition préalable (ou plus simplement "Définition")
prend différents noms selon les métiers :
·
objectifs ;
·
cahier des
charges ;
·
spécifications ;
·
document de définition.
Une fois que ce document est écrit, on va pouvoir concevoir le produit,
c'est à dire trouver les moyens de réaliser les objectifs décrits dans la
définition. On passe alors en phase d'analyse, ce qui se traduit par le
découpage du produit en unités de plus en plus petites selon une sorte
d'arborescence.
Les petits éléments deviennent alors des sortes de briques qu'il suffit de
réaliser puis d'assembler pour réaliser le projet.
Le cycle en V est une formalisation du cycle de développement mettant en
œuvre 5 étapes :
·
définition ;
·
conception ;
·
réalisation ;
·
intégration ;
·
validation.
Chaque étape est matérialisée par un document :
·
le document de
définition ;
·
le document de
conception ;
·
les fichiers sources et
les tests unitaires ;
·
le cahier de tests
d'intégration ;
·
le document de
validation.
Ce document décrit noir sur blanc le produit attendu en termes de :
·
environnement ;
·
interfaces ;
·
comportement ;
·
performances ;
·
coûts et délais.
Il répond à la question "Quoi ?"
Ce document est connu du client et signé par celui-ci.
III-B. Le document de conceptionCe document décrit noir
sur blanc les moyens mis en œuvre pour réaliser le produit :
·
découpage arborescent
en blocs fonctionnels ;
·
architecture
logicielle ;
·
comportement détaillé
(algorithmes, machines à états) ;
·
fonctions (interfaces
et comportement).
Il répond à la question "Comment ?"
Sauf indication contraire, ce document est interne.
C'est le résultat du codage des fonctions. L'organisation du source ainsi
que les interfaces des fonctions publiques (points d'entrées) découlent de
l'analyse résultant de la conception. Chaque bloc fonctionnel terminal (feuille
de l'arbre) est testé unitairement. Il est conçu pour être autonome, par
exemple sous la forme d'un composant logiciel (lire l'article Concevoir et réaliser un composant logiciel en C).
Si il a des sorties, celles-ci sont le plus souvent réalisées sous forme
d'appels à des fonctions externes via un pointeur de fonction, ce qui autorise
les tests unitaires sans connaître les détails de l'application.
Sauf indication contraire, ces documents sont internes.
L'intégration consiste à rassembler les composants logiciels dans le but de
réaliser le produit final. Une liste de tests extrêmement poussés permet de
valider la conception en fonctionnement normal, aux limites et au-delà.
L'ensemble de ces tests et leurs résultats sont consignés dans le cahier de
test d'intégration. C'est ici que se fait la mise au point du produit. Si un
composant logiciel doit être corrigé (modifications de spécifications
détaillées), le test unitaire est repassé (éventuellement complété) afin de
s'assurer qu'il n'y a pas de régression et que le nouvel objectif est bien
atteint.
Sauf indication contraire, ce document est interne.
Le document de validation est une liste de tests 'boite noire' (c'est à
dire que la conception est ignorée) tendant à prouver la conformité du produit
avec la demande du client. Il s'appuie bien sûr sur le document de définition.
On parle aussi de cahier de recette. Le fournisseur s'engage à réaliser les
tests mentionnés et à en indiquer les résultats. Il signe le document. C'est en
quelque sorte la garantie constructeur. En cas de litige, le client peut exiger
qu'un test réputé réussi ou présentant des résultats connus, soit repassé
devant lui à des fins de vérification.
Ce document est connu du client et signé par le fournisseur et par le
client.
Le terme « en V » est issu de la mise en regard de chaque
document et de leur portée :
·
la validation est en
regard de la spécification ;
·
l'intégration est en
regard de la conception ;
·
la spécification et la
validation sont du domaine du client.
Il en résulte le schéma suivant :
Sélectionnez
1 - Définition Validation - 5
\ / Domaine Client/Fournisseur
------------------------------------------------------------------
\ / Domaine Fournisseur
2 - Conception Intégration - 4
\ /
3 - Codage et TU
IV. Critique de la méthode du
cycle en V
Théoriquement, la méthode en V est parfaite. Elle décrit un processus bien
huilé qui transforme l'idée du client en produit fini.
Dans la pratique, l'expérience montre que, loi de Murphy aidant, rien ne se
passe comme prévu !
De nombreux facteurs s'acharnent à faire dériver le projet, que ce soit en
matière de coût et de délai, mais aussi, par exemple, en terme de faisabilité
de telle ou telle fonctionnalité ou d'erreur de conception grave (mauvais choix
technologique, par exemple).
Tout le problème est donc de trouver le moyen d'identifier rapidement les
obstacles et autres points bloquants. Il existe pour ça des méthodes dites
'agiles' qui permettent d'obtenir des résultats bien meilleurs que la méthode
en V classique appliquée brutalement.
Ceci dit, les principes de la méthode en V sont bons, mais ils ne doivent
pas être appliqués directement à la réalisation de gros projets, mais sont utilisés
d'une manière simplifiée mais rigoureuse pour la réalisation des itérations
courtes telles que les recommandent les méthodes dites « agiles ».
Les méthodes agiles sont basées sur l'expérience et le bon sens. Plusieurs
idées maîtresses régissent ces méthodes. Elles visent avant tout à obtenir un
résultat, et non à appliquer un formalisme rigide. La méthode est centrée sur
le produit. Elle n'est qu'un outil au service de la réalisation et non une fin
en soi.
Les principales caractéristiques sont :
·
les itérations
courtes ;
·
la conception par les
tests ;
·
la réécriture ;
·
le travail en
binôme ;
·
le travail en équipe.
Plus d'informations sur
les méthodes agiles :: Cours sur les Méthodes Agiles
C'est le point fort qui fait la différence avec les méthodes
traditionnelles. Il s'agit, à partir des spécifications générales, de définir
rapidement un projet aux fonctionnalités minimales mais essentielles et surtout
centrées sur les aspects innovants (vu du réalisateur), de façon à montrer
rapidement la faisabilité du projet (maquettage). Cela permet très rapidement
(en quelques semaines) de savoir si le projet est viable ou non.
Le Chef de Projet (CP) fixe des objectifs précis avec des délais réalistes
et un point d'avancement est fait chaque semaine. Si une dérive ou un point
bloquant est constaté, les compétences nécessaires sont mises à disposition
pour résoudre le problème (si c'est possible). On peut très bien tomber sur un
échec. Mais il vaut mieux le savoir au bout de trois semaines qu'au bout de
trois ans (des boites ont coulé pour moins que ça…)
D'autre part, c'est l'occasion de tester la spécification et de demander au
client des précisions sur les points qui auraient échappé à la rédaction du
cahier des charges. Là encore, il vaut mieux demander les précisions au début
du projet qu'au bout de 1 ou 2 ans. Question de crédibilité…
Dès qu'une itération est terminée (et même avant), le CP planifie
l'itération suivante selon les mêmes critères. On commence par le plus
difficile (ou le moins connu), et on laisse le code routinier pour la fin. (Les
risques de tomber sur des problèmes de conception et/ou de réalisation sont
moindres).
Ce principe s'applique à la réalisation d'une fonction ou d'un groupe de
fonction (classe gérant un objet, par exemple). Il est admis que lorsque l'on
réalise du code, celui-ci doit être testé unitairement. Les méthodes agiles
proposent d'aller plus loin en intégrant le test dans le conception :
1.
rédaction de la
spécification détaillée ;
2.
rédaction des tests
permettant de vérifier l'interface et le comportement nominal, aux limites,
hors limites ;
3.
codage de
l'environnement de test selon des méthodes simples et éprouvées (plus ou moins
automatisées) ;
4.
codage des tests avec
un emplacement pour le DUT (Device Under Test). L'appel doit se faire dans les
conditions d'une application ;
5.
codage de la ou des
fonctions dans des modules séparés, évidemment.
Le code n'est pas immuable. Plutôt que de le corriger à l'infini, il vaut
mieux parfois admettre qu'il faut réécrire une portion de code (refactoring).
Quand c'est possible, il est souhaitable que le codage se fasse en binôme.
L'un tient le clavier et ne fait que taper le code. L'autre tient le document
de spécification, guide le codeur dans les grandes lignes et vérifie ce qui est
tapé (conformité au langage, etc.) C'est comme ça qu'on élimine les problèmes
de comportement indéfini.
Quand c'est possible, il est souhaitable que l'équipe ne se spécialise pas
dans tel ou tel domaine du projet et qu'il y ait des rotations de façons à ce
que la connaissance soit partagée. C'est très utile en cas de défaillance d'un
des équipiers et chacun est obligé d'avoir le même niveau de compétence que son
voisin et inversement. Le niveau général augmente, ce qui est une Bonne Chose
(©).
Liste des
articles d'Emmanuel Delahaye
Projet de développement
informatique
Plan type d'un document d'aide à la conception d'un
projet informatique
·
Note de cadrage du projet : permet
de décrire les enjeux du projet, le périmètre de l'application, son intégration
éventuelle dans un ensemble plus vaste et le plan de développement du projet
·
à valider par le maitre d'ouvrage, à
transmettre aux participants du projet
·
Expression et analyse des besoins
·
Exigences fonctionnelles : permet
de décrire les exigences fonctionnelles de l'application sous forme de cas
d'utilisation
·
Conception interface utilisateur :
permet de décrire les exigences d'ergonomie-graphisme et de l'interface
utilisateur de l'application
Plan détaillé
A – Le PROJET
B – Objectifs
C – Description générale
D – Lots à réaliser
E – Exigences fonctionnelles
E-1 < Diagramme des
cas d'utilisation >
E-2 < Description
des Acteurs (rôles) et droits d'accès >
E-3 < Cas
d'utilisation >
1. Cas d’utilisation
type
Objectif
Acteurs principaux
Acteurs secondaires
Préconditions
Postconditions
Scénario nominal
1. Action
2. Action
Scénarios alternatifs
Variantes de
technologies et de données
Règles de gestion
Exigences
supplémentaires
Questions en suspend
F – Exigences non
fonctionnelles
F-1 Graphisme et
ergonomie
F-2 Statistiques
Statistiques d'accès
au site, au différents articles, volume et temps de consultation
F-3 Référencement
F-4 Accessibilité
G – Contraintes
Techniques
G-1 Environnement
technique
Environnement serveur
Volume(s)
Framework
Environnement client
G-2 Sécurité
Sauvegarde
FTP et upload
Tests
G-3 Documentation
Documentation
technique
Gestion des anomalies
Gestion des versions
Gérez vos projets informatiques avec
les méthodes agiles
Que se passe t-il en février 2001 lorsqu’un groupe de 17
passionnés du développement logiciel se réunit dans une station de ski de
l’UTAH aux États-Unis pour faire du brainstorming?
Et bien, il en ressort le manifeste du développement logiciel agile, une nouvelle manière de gérer les projets informatiques.
Ces hommes sont Kent Beck, Mike
Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler,
James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian
Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland et Dave
Thomas. Ils sont tous acteurs indépendants du développement logiciel, parfois
concurrents et ils ont mis leurs neurones en commun pour former l’alliance agile qui est à l’origine de nouvelles méthodes de gestion de projet
appliqués surtout aux projets informatiques.
Vous pouvez écouter cet article
sous forme de Podcast ou bien le lire ci-après.
Faites un clic droit sur le lien
ci-dessous et sélectionnez “enregistrer la Cible du lien sous” pour sauvegarder
le fichier MP3 sur votre ordinateur ou votre smartphone: Podcast de
l’article
Vous pouvez aussi écouter le
Podcast directement sur le blog:
Podcast: Lire dans une autre fenêtre | Télécharger
Les méthodes agiles sont une manière de réduire le cycle de développement des
projets informatiques, de répondre plus rapidement aux évolutions des demandes
de l’utilisateur final versatile. Les projets informatiques agiles sont gérés
de manière adaptative, incrémentale et itérative.
Aujourd’hui encore, dans le domaine
des projets de développement
logiciel, les méthodes agiles sont de plus en plus utilisées. Comme leurs noms
l’indiquent, ce sont des méthodes de gestion de projet dynamiques et réactives.
Les méthodes agiles visent à
intégrer au cours du projet de manière continue le client final, c’est à dire
le plus souvent l’utilisateur final à qui le nouveau logiciel est destiné. Les
méthodes agiles permettent une plus grande réactivité aux demandes du client.
Êtes-vous prêt à
travailler selon les valeurs des méthodes agiles?
Oui, vous êtes prêt à devenir
agile, si vous êtes prêt à privilégier les 4 valeurs suivantes…
·
Les
individus et leurs interactions plus que les processus et les outils
·
Des
logiciels opérationnels plus qu’une documentation exhaustive
·
La
collaboration entre les développeurs et les clients plus que la négociation
contractuelle
·
L’adaptation
au changement plus que le suivi d’un planning
Comment se
manifeste l’agilité au cours du cycle de développement informatique?
Les valeurs agiles se déclinent
en 12 principes communs aux méthodes agiles. On retrouve ces principes dans le fameux manifeste du
développement agile:
1 – La priorité numéro 1 est
la satisfaction du
client. Des versions fonctionnelles du
logiciel doivent être régulièrement livrées au client, de manière rapprochée
dans le temps. L’agilité vient de ce jeu de ping-pong entre le développeur et
le client jusqu’à ce que le client décide qu’il est satisfait avec la version
de test livrée.
2 – Les développeurs doivent bien
accueillir et de manière réactive des demandes d’évolution même s’ils sont déjà bien avancés dans le développement.
L’objectif est de permettre l’acquisition d’un réel avantage concurrentiel pour le client.
3 -Les développeurs doivent réduire les cycles de développement et livrer des versions opérationnelles aux clients dans un laps de temps le plus court possible, entre 2 semaines et 2 mois.
4 – Les utilisateurs métier
(clients du logiciel) et les développeurs doivent travailler ensemble quotidiennement. Le manifeste utilise la terminologie de “business people” pour
parler des utilisateurs du logiciel.
5 – Construisez votre projet
informatique avec des individus motivés, donnez-leur l’environnement de travail et le support dont ils ont besoin et surtout faites-leur confiancepour que le travail soit fait
6 – La méthode la plus efficace
pour communiquer des informations à une équipe projet et au sein d’une équipe
projet est la conversation en
face à face
7 – Le bon fonctionnement du
logiciel est la première mesure de progression
8 – Le processus de développement
agile s’inscrit dans un processus de développement durable. C’est à dire que
les développeurs et les sponsors du projet doivent pouvoir maintenir
indéfiniment un rythme de travail soutenable. Il faut donc trouver le bon
rythme de travail et s’y tenir.
9 – Il faut porter une attention
particulière à l’excellence technique et à une bonne conception, ce qui accroît
l’agilité.
10 – La simplicité est primordiale,
il s’agit de l’art d’éliminer le travail inutile et superflu. Il faut savoir
répondre au besoin exprimé par le client de manière informatiquement simple,
avec un développement qui peut facilement évoluer.
11 – Les meilleurs
architectures, spécifications et conceptions émanent des équipes qui
s’auto-organisent. Les responsabilités ne sont donc pas l’apanage d’un chef de
projet mais sont partagées par chaque membre de l’équipe agile.
12 – A intervalles réguliers,
l’équipe agile s’interroge sur la manière d’améliorer encore son efficacité, puis règle et ajuste son comportement en conséquence.
Les méthodes
agiles les plus utilisées
Les deux méthodes agiles les plus utilisées dans les pays francophones sont :
·
la
méthode Scrum (1996)
·
la
méthode Extreme Programming (1999) qu’on appelle aussi méthode XP
Ces deux méthodes feront l’objet
d’articles futurs.
http://aggouni.blogspot.com
