Une approche pour le développement des "petits" projets scientifiques (part. 3)

Au sommaire :

• Introduction ; les différentes approches
• Entre les approches pour entreprise et les projets de recherche
• L'approche la plus adéquate pour les projets de recherche
• Un peu plus loin : un peu de biologie
• Exemple et conclusion

Dans le premier article de cette série nous avons posé une question à laquelle tout (jeune) chercheur doit répondre lorsqu'il entame la concrétisation de sa proposition. Dans le deuxième article, nous avons cité quelques caractéristiques des applications développées dans le cadre des sujets de recherche (thèse de doctorat et mémoire de Master II). Dans cette article, nous allons essayer de répondre à cette question et pourquoi pas pousser les choses un peu plus loin pour faire une autre proposition (qui peut être, comme toute autre hypothèse, vraie ou fausse).
En procédons à un raisonnement par élimination, nous pouvons dire que :

1. Pour un projet de recherche, une approche itérative n'est pas importante, sauf si la proposition concerne cette approche. Choisir une approche complexe tel que UP, RUP ou XP pour n'exécuter qu'une seule itération, sans avoir de risques qui sont considérés comme le critère de pilotage pour ces approches, sans avoir de complexes cas d'utilisation qui sont considérés comme le centre de ces approches, ne revient qu'à alourdir sans un gain clair le processus de développement.
2. Pour un projet de recherche, une approche en Y ne peut être appliquée que si on s'amuse à gonfler les besoins et à proposer des besoins marginaux pour l'hypothèse effectuée comme des besoins principaux.
3. Le prototypage se trouve, à son tour, écarté. Il n'est pas nécessaire de proposer une application insuffisante pour les expérimentations envisagées comme il est important de n'inviter les gens à faire une expérimentation que pour une seule ou deux fois; si vous vous amusez de faire une expérimentation avec chaque prototype proposé , vous allez vous retrouver seul durant l'expérimentation finale (qui est la plus essentielle parce qu'elle utilise l'application complète).

Ainsi, il est justifiable d'opter pour la solution la plus simple et la plus intuitive : le processus en cascade. Cet processus est la forme la plus proche du principe de base qu'est l'approche top-down (l'approche descendante). Ce processus ne fixe aucune règle supplémentaire pour la gestion des équipes, la collaboration, la synchronisation, les problèmes liés aux technologies, les changements des besoins de base et les notions de gestion des projets. Néanmoins, ces notions ne sont pas d'une importance particulière dans le cadre d'un sujet de recherche menée dans le cadre d'une thèse de doctorat ou moins encore dans un projet de fin d'étude en Master II.

Poussons notre raisonnement un peu plus loin. L'approche en cascade reste toujours destinée pour des projets d'une taille remarquable. La richesse des modèles de description utilisée permet de garantir une communication correcte et efficace entre les différentes équipes impliquées dans le projet, elle peut aussi inclure une dimension décisionnelle. Nous posons ainsi la question : peut on simplifier encore le processus de développement pour ne prendre que la définition de base de l'approche top-down d'une manière suffisante pour les applications relativement petite ?

(Pour plus d'informations sur l'auteur et le blog, c'est par ici)