Les Étapes du cycle d'un Projet Java réussi : Introduction Phase DEVELOPPEMENT

Après avoir fait un tour d’horizon de la modélisation notamment avec le langage UML, nous abordons maintenant un cycle d’articles concernant la phase de développement.
Dans cet article nous allons essayer de décrire la problématique du développement & les principales tâches qui s'y rapportent.
Cela nous permettra d'identifier les principales fonctionnalités que doit intégrer un atelier de développement « idéal ».

En cette période de rentrée, essayons de rendre ludique cet article en assimilant la phase de développement aux activités d'un joueur de jeux vidéos.

Avant de commencer un jeu, il convient d'en connaître les règles, d'en comprendre les objectifs & le but.
Dans le cadre d'un développement informatique, ces règles sont données par les spécifications.
Le développement consiste donc avant tout à lire ces spécifications (>> IL FAUT DONC QU'ELLES EXISTENT).

Mais cela ne suffit pas pour commencer à jouer. En effet, un jeu possède une interface (manette – clavier – écran) qui nous permet de réaliser les actions nécessaires pour atteindre le but assigné.
Dans le cadre d'un développement informatique, l'interface peut-être assimilée au langage de développement (qui permet bien de faire réaliser telle ou telle action par la machine).
L'utilisation de ce langage doit se faire dans le cadre de règles (Utilisation de telle fonction pour ceci – de telle autre pour cela – etc.) que l'on appelle les règles de développement en vigueur.

Nous sommes donc prêts pour jouer (donc développer).
Mais, cela serait trop facile. Nous le savons tous, les jeux nous proposent des pièges qu'il convient de contourner, des ennemis qu'il convient de combattre, qui sans aide (raccourci ou code caché que l'on peut trouver sur internet ou armes qu'il convient d'utiliser au bon moment) ne nous permet pas d'atteindre l'objectif facilement.
Dans le monde du développement, ces aides sont en fait des bibliothèques de composants ou des FrameWorks qui nous permettent d'éviter les pièges (Fuites mémoires – Transformation des données - etc.) ou d'atteindre l'objectif plus rapidement (Génération de code à partir des spécifications – Génération de code à partir d'outil RAD – Fonctions de Formatage – d'Internationalisation – etc.).

Nous connaissons les règles du jeu, nous maîtrisons les interfaces, nous savons que l'on peut utiliser tel ou tel code, telle ou telle arme et donc nous jouons.
Bien évidemment nous ne gagnons pas du premier coup. Nous testons tel ou tel moyen pour aller plus loin dans le jeu.
Dans le cadre d'un développement, il s'agit de tester unitairement les codes réalisés pour vérifier qu'il nous permettront d'aller plus loin dans le « jeu » de construction d'un système informatique.

Nous avons donc franchi une étape du jeu que nous nous empressons de sauvegarder pour ne pas avoir à tout refaire depuis le début. D'ailleurs, ces sauvegardes, nous pouvons les transmettre à nos amis pour qu'ils puissent reprendre le jeu dans l'état où nous l'avons laissé afin qu'ils puissent continuer le jeu à l'étape où nous étions arrivés.
Dans le monde du développement informatique, il s'agit donc de gérer ces codes en version puis d'en proposer des assemblages qui sont mis à disposition des autres développeurs.

Le jeu possédant un (ou des) objectif(s) « immuables », « invariants », cela lui permet de sanctionner sans « ambiguïté » la réussite ou l'échec.
Dans le domaine du développement informatique, l'idéal serait donc de pouvoir procéder de la même façon. Mais plusieurs facteurs empêchent d'atteindre cet idéal, parmi lesquels on peut citer :
  • La transcription littéraire des spécifications qui peuvent introduire des ambiguïtés d'interprétation de la part du développeur (rappelons que les langages de modélisation ont pour objectif, entre autres, de les minimiser).
    Ici, la sanction « You Win », « Game Over » passe donc par une étape humaine que l'on appelle la recette utilisateur qui induit, même si on cherche à la minimiser, une activité à part entière de gestion des erreurs (Il faut signaler l'erreur au développeur pour qu'il la corrige & qu'il remette à disposition de l'utilisateur la version corrigée)
  • Le monde réel change (réglementation – procédure – outillage – etc.) induisant des modifications des règles du jeu (des spécifications).
    Il s'agit alors d'établir des avenants aux spécifications qu'il convient de communiquer aux développeurs afin qu'ils puissent en tenir compte. On est alors dans une activité de maintenance applicative.
En tout état de cause, et c'est ici que s'arrêtera le parallélisme entre le jeu & les activités de développement, il conviendra de mettre à disposition des utilisateurs les réalisations faites afin qu'ils puissent vérifier la conformité de celles-ci à leurs exigences.

Enfin, et cela n'est pas négligeable, le jeu ne sanctionne « économiquement » pas le nombre d'essais, le temps qu'il a fallu au joueur pour atteindre l'objectif.

En résumé, les activités de développement sont :
  • La lecture & la compréhension des spécifications,
  • Le développement du système informatique dans le respect des spécifications fonctionnelles et des règles de développement en vigueur,
  • L'utilisation au bon moment des composants d'industrialisation (Bibliothèques & FrameWork),
  • Les test unitaires des codes réalisés,
  • L'assemblage des codes « unitaires »,
  • La mise à disposition sur un environnement de test des « codes » réalisés pour validation fonctionnelle.
  • La gestion des versions (unitaires mais également fonctionnelles) des codes pour tenir compte des évolutions & de la maintenance.
En conséquence, et en guise de conclusion, un atelier de développement idéal devra donc prendre en charge l'ensemble de ces activités, tout en permettant d'optimiser le temps de réalisation de celles-ci notamment à travers :
  • tout en un (Visualisation des versions de spécifications – Gestion de version – Atelier de développement à proprement dit – Intégration de FrameWork & Bibliothèques – Tests unitaires – Assemblage & Déploiement – Gestion des erreurs – etc.)
  • l'automatisation de tâches répétitives (Macros – Raccourcis claviers – etc.)
  • les Aides (en ligne – Code completion – etc.)
  • Tests et corrections en ligne (Hot Code Replace)
  • Génération de code « générique » (Wizard)
  • Interface « Wysiwyg » de création des composants (Rapid Application Developpement ou RAD)
  • Etc.

Olivier HEDIN

Fermer
Imprimer
Contacts / Site