La démarche projet 2TUP

La démarche 2TUP est proposée pour le développement des logiciels fournissant les services sur Internet.

2TUP

2 Tracks Unified Process est un processus unifié (c’est-à-dire construit sur UML, itératif, centré sur l’architecture et conduit par les cas d’utilisation). Le principe fondateur du 2TUP est que toute évolution imposée à un logiciel peut se décomposer et se traiter parallèlement, suivant un axe fonctionnel et un axe technique. A l’issue des évolutions du modèle fonctionnel et de l’architecture technique, la réalisation du logiciel consiste à fusionner les résultats de ces deux branches du processus.

Le schéma ci-dessus décrit le processus 2TUP adapté au contexte des développements de logiciels chez CatchU avec, en bleu les livrables de la phase d’étude, et en rouge les livrables de la phase d’incubation.

Il est conseillé de créer les documents suivants :

  • l’ébauche, qui contient une description du service en quelques lignes, et les cas d’utilisation principaux du service, c’est une première version de la spécification générale décrite ci-après.
  • la spécification, qui définie le quoi faire,
    • la spécification générale décrit le service à développer d’un point de vue fonctionnel, on y trouve la liste les exigences fonctionnelles, les cas d’utilisation du service, l’architecture logique, le modèle de données macro et/ou le diagramme de classes métier. Le contenu de la spécification générale reste valide quelque soit le choix d’implémentation technique en conception ;
    • la spécification détaillée, qui précise, pour chaque scénario des cas d’utilisation présent en spécification générale, les éléments suivants : enchaînements de traitements, maquettes d’écrans, règles de gestion, liste de valeurs énumérées, etc. Si le service est complexe, il est conseillé de découper la spécification détaillée par modules ou grandes fonctions.
  • la conception, qui définie le comment faire,
    • la conception générale liste les exigences techniques à partir de l’ébauche, définie l’architecture technique et les choix d’implémentation technique ;
    • la conception détaillée précise l’implémentation technique de l’application. Elle consiste en la fusion de la spécification détaillée et de la conception générale, pour déterminer comment faire le quoi faire dans le détail. On y trouve le schéma de base de données, les diagrammes de classes et les diagrammes de séquence supplémentaires qui détaillent les interactions entre les composants du logiciel pour les scénarios les plus complexes.

    Note : Les documents de conception détaillée ne doivent pas traiter l’exhaustivité des fonctionnalités de l’application. Il en résulterait un ensemble documentaire volumineux, lourd à maintenir; Une conception détaillée doit couvrir les aspects trop complexes que le développeur ne peu facilement déduire à la lecture des documents de spécifications détaillées et de conception générale. La conception détaillée aide le développeur à écrire le logiciel en apportant des informations pertinentes et non superflues par rapports aux informations disponibles dans les documents de spécifications détaillées et de conception générale.
  • le dossier de fabrication, qui est un document décrivant comment est réalisé le livrable destinée à être ensuite installé sur un environnement d’exécution. On y trouve également les documentations techniques d’aide à la maintenance corrective et évolutive du logiciel ;
  • le dossier de validation, un document qui décrit comment est validé le logiciel. On y trouve la stratégie de validation, le dossier des cas de test, les campagnes de test planifié. Il est ensuite complété à la fin de chaque campagne de test par un bilan de campagne de tests et une liste d’anomalies restant à corriger ;
  • le dossier d’installation, un document qui décrit comment est installé le logiciel sur un environnement d’exécution. On y trouve également les informations de configuration du logiciel et son exploitation (arrêt/démarrage, vérification de bon fonctionnement, liste des URL et aide à l’analyse des logs, données à sauvegarder quotidiennement, etc);

Cette démarche ne s’oppose pas aux méthodes agiles comme SCRUM et eXtreme Programming, elle encadre leur mise en oeuvre. Les méthodes agiles sont utilisables à partir de la 1ère conception détaillée sur un périmètre fonctionnel minimal utilisable pour l’utilisateur final.

démarche itérative et incrémentale

Pour la feuille de route de réalisation du logiciel une démarche itérative et incrémentale est conseillée :

  1. une première version sur un périmètre minimal utilisable gratuitement par un utilisateur final (itération « Minimal Usable Project » Fremium) ;
  2. une 2nde version sur un périmètre minimal pour une viabilité du projet avec un abonnement ou des options payantes (itération « Minimal Viable Project » Premium) avec d’éventuelles adaptation quant aux besoins et usages des utilisateurs déterminés dans l’itération précédente ;
  3. les versions suivantes sont définies en fonction des besoins et des usages des utilisateurs déterminés dans l’itération précédente.