Vous voilà enfin prêt : vous savez écrire des pages PHP, manipuler des classes, générer des commandes SQL, dessiner de beaux schémas UML. Et maintenant, il faut écrire une application... Par où commencer ? Faut-il s'occuper de la base de données ? Choisir un framework ? Réaliser une belle analyse UML, et si oui, comment l'aborder ?
Bref, pas évident de se mettre en route... Pas de panique, nous allons dérouler les différentes étapes, et essayer d'éviter les pièges les plus classiques !
On développe rarement pour rien (quoique...) : il vaut mieux que notre travail serve à quelque chose. La première étape consiste à cerner le besoin du demandeur.
Vous risquez d'avoir un cahier des charges qui, parfois, fera 2 lignes (si elles sont écrites!). Le plus facile, c'est de commencer à réaliser des diagrammes de cas d'utilisation. Ils vont vous permettre d'identifier d'une part les différents intervenants (très important pour la gestion des droits, par la suite), et d'autre part les différentes briques dont vous aurez besoin.
Vous créerez autant de schémas que vous aurez de « volets » dans votre application. Dernièrement, j'ai réalisé une application qui a trois usages :
Dans cet exemple, nous avons eu donc trois schémas de cas d'utilisation, chaque schéma pouvant posséder plusieurs cas ; par exemple, le dernier schéma comprenait un cas concernant l'import des données, et un cas pour la consultation.
Chaque cas doit être documenté : il ne suffit pas de faire un joli schéma, encore faut-il dire à quoi il sert. Et là, seul le recours au français, c'est à dire à la rédaction de ce que doit faire chaque cas, comment il fonctionne, à qui il est destiné, etc. vous permettra d'être assez précis.
Dans les schémas, n'oubliez pas d'indiquer les différents types d'intervenants : ils vous permettront de préparer la matrice des droits d'accès (tout le monde n'a pas forcément accès à tout).
Le document que vous allez produire est destiné principalement au demandeur de l'application : comme les schémas sont assez simples, et les cas documentés, ils doit être compréhensible par toute personne concernée par le projet. Le demandeur va pouvoir ainsi valider votre vision des choses et, le cas échéant, vous apporter des précisions complémentaires. Il est plus facile de commenter un texte existant que de partir de zéro : tout le monde n'est pas écrivain !
Vous pouvez compléter ce document par une petite analyse technique, par exemple un calcul rapide de la taille de la base de données, ou une estimation des ressources physiques nécessaires (si 10 personnes doivent utiliser le logiciel, ce n'est pas tout à fait la même chose que 10 000 connexions simultanées, en terme de dimensionnement de la plate-forme technique). Vous pouvez également mettre en garde par rapport à des demandes certes légitimes, mais qui peuvent être coûteuses à développer : si on vous demande de réaliser une application de saisie sur le terrain qui doit fonctionner en mode déconnecté sur des terminaux de différents systèmes d'exploitation (IOS, ANDROID, etc.), il est probable que le coût ou le temps de développement total sera plus important qu'on aurait pu le penser initialement. Vous préparez ainsi la phase suivante : la définition des priorités.
Maintenant que vous avez un aperçu de l'application à réaliser, vous allez pouvoir définir, avec le demandeur, les cas d'utilisation qu'il semble pertinent de faire en priorité. Demandez également au demandeur s'il a des exigences calendaires fortes (pour éviter la réponse du type : c'est pour demain matin, alors que la saisie ne doit commencer effectivement que dans trois mois), et sur quels cas d'utilisation elles portent.
Définissez également avec le demandeur les différentes versions à produire. Même si vous livrez chaque semaine un module différent, cela ne fait pas une version : il faut, à un moment donné, fournir un ensemble fonctionnel. Avec une livraison de versions successives, vous permettrez au demandeur de tester au fur et à mesure et, au besoin, de commencer à travailler en attendant que la suite arrive.
Ainsi, vous allez pouvoir organiser le déroulement du développement dans le temps.
Il y a quelques années de cela, quand j'attaquais une application, je commençais par faire une analyse pendant plusieurs jours ou semaines, puis passais à la base de données, et enfin au codage. J'ai eu des stagiaires qui, grâce à cette approche, finissait leur stage sans rien avoir produit de fonctionnel : dommage...
Aujourd'hui, les méthodes dites « agiles » permettent d'appréhender le développement de façon beaucoup plus efficace. Si vous êtes intégré au sein d'une équipe de développeurs, avec de la chance, vous travaillerez selon la méthode Scrum (http://fr.wikipedia.org/wiki/Scrum_(m%C3%A9thode)). Si vous êtes tout seul, ce qui est mon cas (et probablement le votre aussi), mettre en place une méthode Scrum ne rime pas à grand chose. Par contre, vous pouvez en retenir certains points, qui me paraissent essentiels :
Voilà, on a fait le tour. Votre application va se monter petit à petit, et vous aurez la fierté de la présenter aux utilisateurs au fur et à mesure que les différentes versions seront mises en production !
Bon, c'est vrai, il faut qu'on rentre maintenant dans le détail du codage...