# Étapes de développement d'une application web

Il est temps que je vous dévoile un peu ce que je vais faire ces prochains mois. Je ne suis probablement pas habilité à vous livrer les détails donc je vais rester assez évasif (pour le moment ?) mais l'objectif est de développer une application web qui sera utilisée dans les laboratoires. C'est un domaine très vaste donc les contraintes de flexibilité sont énormes, chaque laboratoire ayant son propre mode de fonctionnement. C'est aussi ce qui rend cette aventure passionnante :-).

Puisque je pars quasiment de rien, il y a bien une application existante en Java mais nous avons décidé de réaliser une nouvelle application plutôt qu'une refonte, il va falloir repartir de zéro. Voici les étapes retenues pour l'avant projet :

- capitalisation de l'expérience acquise : même si l'écriture est « from scratch », il ne faut pas sous-estimer le travail déjà réalisé et en tirer les bonnes conclusions relatives à chacune des étapes de la conception, de la vente, de l'intégration, de l'utilisation,... Il s'agit de faire un bilan pour pouvoir ensuite décider des orientations à chacun de ces niveaux.
- définition du logiciel : l'étape la plus importante. À partir de la capitalisation, arriver à établir les objectifs du logiciel à chacun des niveaux. Tenir compte de l'analyse de la concurrence faite préalablement pour identifier la clientèle à approcher et les besoins utilisateurs. Ne pas oublier de tenir compte des contraintes inhérentes au domaine couvert, au budget et au planning.
- prioritisation des fonctionnalités : établir la liste ordonnée des fonctionnalités à implémenter pour être opérationnel au plus tôt, planifier les différentes releases. Cette étape est réalisée en parallèle de l'étude des concepts fondamentaux.
- étude des concepts fondamentaux : se concentrer sur le métier et sur les concepts qui lui sont propres pour arriver à une vision claire de la modelisation de l'application dans sa globalité.
- réalisation des scénarios d'utilisation : chaque action courante est scénarisée avec les écrans ergonomiques associés, c'est ce qui tient lieu de cahier des charges pour la suite. Il faut donc que ce soit relativement détaillé. De plus, ce sont ces écrans qui seront utiles au graphiste pour qu'il réalise les maquettes. Il est important d'avoir le design le plus tôt possible car dans le cas d'une application web il est intimement lié au développement (même avec un modèle MTV).
- définition des itérations de développement : chaque cycle itératif se déroule en 3 ou 4 semaines, la dernière semaine étant consacrée aux tests et à la documentation. Exemple : gestion des utilisateurs.

Une fois ce travail réalisé, j'estime 80% du travail fait (attention pas du temps). Il ne reste plus qu'à coder tout ça avec Django ;-). Bon concrêtement je dois avoir terminé ces étapes fin mars et j'ai peu d'expérience dans ce domaine (d'ailleurs il faudra que je relise Getting Real) donc si vous avez des suggestions/remarques à ce sujet elles sont les bienvenues (je tiens à préciser que je suis attaché aux méthodes de développement agile donc certaines solutions sont écartées d'office).

### Articles peut-être en rapport

- Le développement web se porte bien
- ★ Résolutions : rediriger, économiser et débattre
- ★ Résolutions : découvrir, concrétiser et transmettre

### Commentaires

NiCoS le 12/01/2007 :

Disclaimer : Je n'ai pas lu en détail getting real, seulement quelques passages donc mon point de vue n'est pas forcément le plus pertinent.
Pour ce que j'en ai lu (ainsi que du bouquin de Rails), c'est vrai que c'est très séduisant et qu'il y a de bonnes idées. Toutefois, je pense que c'est valable pour des projets pas trop gros et surtout au sein d'une équipe qui se connait parfaitement bien. J'ai pas dit non plus qu'il fallait faire 10.000 pages de specs hein, cela a aussi ses travers ;-)
Je pense que tu as cité le principal et qu'avec du bon sens, tu devrais t'en sortir :-)
ah oui et si tu fais "chef de projet" et dev à la fois, pense à relever la tête pour anticiper et voir si tu tiens tes délais & co ;-)

Christian Fauré le 13/01/2007 :

Je te propose d'essayer de commencer sans plan ni méthode, juste en tournant autour du sujet et en prenant des notes très courtes (pense à ces amateurs d'art qui tournent autour d'une statue dans les musées).
Laisse toi l'occasion de suivre tes propres pensées dans la façon dont tu aborde la conception. Ainsi, n'hésite pas à passer du coq à l'âne si tu en éprouve le besoin.
Au bout d'un certain temps (vu ton planning pas plus de 10 j) le besoin de structurer la démarche se fera sentir car tu commenceras à tourner en rond et à revenir sur des sentiers que tu as déjà emprunté.
C'est à ce moment là que l'aspect méthodologique se posera avec acuité ; et pour cause tu en auras vraiment besoin pour avancer !
Définir des méthodes et des cycles de conception avant de s'être plongé réellement dans le sujet est pour moi le meilleur moyen de perdre tout plaisir pour la suite d'un projet.
Et le plaisir, c'est quand même ce qui motive sur un projet non ? ;-)

Clément Pillias le 13/01/2007 :

Une chose n'est pas claire : à quel moment comptes-tu rencontrer l'utilisateur ?
Je vois bien des scénarii d'utilisation, et je suppose que leur validation se ferra lors de la dernière étape (itérative), comme cela se fait souvent. Mais si c'est bien cela que tu as prévu, la consultation des utilisateurs arrive trop tard : elle doit être faite à chaque étape depuis la définition du logiciel.
D'autre part, « Il ne reste plus qu'à coder tout ça avec Django » est une autre erreur : on ne choisit les outils à utiliser que tardivement dans le processus de développement, sinon tu risques de faire des choix motivés non pas par la qualité du programme, mais par la facilité de les réaliser avec les outils choisis. Particulièrement en fin de développement quand tu serra pressé par le temps...
Sinon, bon courage !

Eftarjin le 13/01/2007 :

Que signifie "méthodes de développement agiles" ?
PS: je n'ai pas lu Getting Real, mais je devrais peut être ...

David, biologeek le 13/01/2007 :

@NiCoS : merci pour tes conseils et tes encouragements :-).
@Christian Fauré : en fait j'ai commencé le projet depuis le 2 janvier donc c'est déjà un peu le résultat de cette réflexion préalable (je suis dedans jusqu'au cou ! ;-)).
@Clément Pillias : excellente remarques.
> à quel moment comptes-tu rencontrer l'utilisateur ?
À plusieurs niveaux mais c'est effectivement une bonne chose de programmer ces rencontres. La première étape de capitalisation doit initier cette relation.
> D'autre part, « Il ne reste plus qu'à coder tout ça avec Django » est une autre erreur
C'est vrai. Officiellement je choisirais le framework juste avant d'avoir défini les cycles itératifs mais officieusement je dois bien avouer que Django part avec un avantage certain : je connais très bien le framework et le langage.
@Eftarjin : ça demande un billet à part entière, il y a pas mal de documentation sur le net là-dessus en attendant, la page de Wikipédia à ce sujet est bien faite : fr.wikipedia.org/wiki/M%C...

Aguillem le 15/01/2007 :

En lisant ce post, toute cette démarche et cette façon de faire me faisait penser à XP (eXtreme Programming), méthode de dev sur laquelle il faut que je me penche depuis un petit moment. Et c'est grâce à ton lien vers wikipedia que j'ai pu voir que XP faisait parti des différentes méthodes agiles.
Est-ce à ce méthode-même que tu t'appliques ? ou est-ce à une autre ?
N'ayant pas lu Getting Real non plus, je ne connais pas encore grand chose à tout ça.
En tout cas bonne chance pour la suite ;)
PS : Voici un lien vers un dossier sur l'eXtreme Programming si y en a que ça intéresse : www.design-up.com/article...

NiCoS le 15/01/2007 :

"Django part avec un avantage certain : je connais très bien le framework et le langage."
Pfff prétentieux - si tu le connaissais tant et si bien que ça, tu aurais résolu mon souci depuis des lustes ;-)
Pour revenir à l'utilisateur, faut pas non plus tomber dans l'excès inverse à savoir lui présenter toutes les possibilités et à te mettre dans la mouise. Je pense qu'il faut privilégier une bonne prise en compte du/des besoins et ensuite lui proposer une réponse. C'est cette réponse qu'il faut éventuellement aménager avec l'utilisateur. Si tu commences à lui présenter toutes les possibilités, tu es cuit et ça va te bouffer tout ton temps.

David, biologeek le 16/01/2007 :

@Aguillem : bon il faut vraiment que je fasse un billet là-dessus :-)
@NiCoS : oui je sais tu es todoisé ;-)
Pour les utilisateurs tout dépend du projet je pense et de l'importance du client sur l'application, enfin la modération a toujours du bon.

bob la mouche le 16/01/2007 :

J'ai l'impression désagréable que tu cumules le chef de projet et le développement, le tout par une approche type XP.
Est-ce que l'entreprise où tu es a l'expérience de ce type de développement? Si non c'est une lourde responsabilité pour toi. Il y a donc un risque important de dérapage lorsque l'on est pionnier, et surtout de problèmes techniques "time consuming" si tu es seul. Mais d'un autre côté s'il y a risque et que cela se passe bien cela peut être très favorable pour toi dans cette entreprise.
J'espère au moins qu'il y a d'autres développeurs dans cette boite.

David, biologeek le 16/01/2007 :

> Si non c'est une lourde responsabilité pour toi.
Oui, je sais bien, mais c'est aussi une grande liberté que j'apprécie chaque jour. Après il faut faire attention à beaucoup de choses pour pas déraper en s'imposant une certaine rigueur.
> J'espère au moins qu'il y a d'autres développeurs dans cette boite.
C'est le cas.

Christian Fauré le 18/01/2007 :

Pense aussi que ta stratégie de recette devra se faire AVANT les développements.

David, biologeek le 19/01/2007 :

Ok c'est noté, merci pour toutes vos remarques :-).

Ghouti le 25/01/2007 :

Bonjour étant informaticien, je me demande exactement l'étape developpement,
Essayer UWE,

Québecoicoicoi le 26/01/2007 :

">Si non c'est une lourde responsabilité pour toi.
Oui, je sais bien, mais c'est aussi une grande liberté que j'apprécie chaque jour"
Salut,
Je suis un peu pessimiste devant tout cela car présentement c'est une situation où tu apprends seul et où il n'y a pas de procédure de développement mise en place (c'est ce qui sort de ton texte) et malheureusement je ne pense pas que cela est un bon environnement de travail.
Bonne journée

Steevy from Mars le 27/02/2007 :

Alors, comment cela se passe? Tout se déroule comme attendu?

David, biologeek le 27/02/2007 :

Pas exactement... il faudra que je fasse un nouveau billet là-dessus d'ailleurs ;-)

Création sites web le 18/05/2007 :

Article intéressant !
Merci pour cette méthodologie