Développement, intégration Moodle : Engagements de délais

L’intégration LMS est un secteur particulier où l’innovation tient une grande place, soit technologique (nouveaux éditeurs, nouvelles solutions, nouvelles interopérabilités), soit en usages (nouveaux processes, nouvelles règles de gestion, nouveaux champs applicatifs, nouveaux besoins pédagogiques, nouveaux défis – performance, manoeuvrablté – induits par la généralisation de l’usage).

Il est donc nécessaire de se doter de modèles adéquats pour piloter la réalisation des délais de livraison, qui intègrent le facteur d’inconnu ou au contraire, de certitude des réalisation et objectifs fixés. ActiveProLearn propose un modèle de classement qui permet une évaluation rationnelle des risques en délai, et permet de donner des estimateurs réalistes sur les livraisons. Ce modèle présente par échelle d’incertitude croissante, les catégories suivantes :

Maîtrisé : L’objectif ne fait appel qu’à des manœuvres et tâches connues, répertoriées et répétées de nombreuses fois dans des configurations similaires ou comparables. L’aléa est peu probable, et s’il apparait, est en général d’ordre mineur. Son impact sur le délai est nul ou très faible. Un aléa majeur est de l’ordre de l’exception ou apparaître par des facteurs exogènes au projet.

Commun : L’objectif comporte des éléments nouveaux, des changements ou des adaptations sur un existant stable et maîtrisé. Les éléments nouveaux de présentent pas de facteur de faisabilité rédhibitoires, et peuvent être facilement isolés pour être résolus séparément sans effet global sur l’objectif. La nature des travaux est couramment supportée par les ressources techniques, avec les compétences technologiques dont elles disposent déjà. Les aléas mineurs sont ceux de toute pratique de développement. Ils peuvent constituer un risque sur les délais si leur nombre est important et consomme du temps de mise au point. Le risque d’aléa majeur est faible, il peut résulter exceptionnellement d’un problème technique non anticipé tel que l’apparition d’une complexité cachée.

Prototypal : L’objectif comporte principalement des éléments nouveaux, qui peuvent être éventuellement balisés par des implémentations similaires dans d’autres environnements et qui de ce fait permettent d’anticiper une faisabilité de principe. Cependant, l’environnement applicatif ne comporte pas à priori les ressources et données nécessaires à la réalisation de l’objectif, lequel doit être architecturé en plus pour pouvoir être correctement intégré à la solution. La réalisation s’oriente vers une première phase « prototype » qui pose les bases d’une architecture techniquement et fonctionnellement crédible, et englobe les développements destinés à supporter des extensions, consolidations ou finitions ultérieures. Les objectifs peuvent dans une certaine mesure faire appel à des technologies tierces, dont l’intégration dans le LMS doit être étudiée en amont de la réalisation.

Expérimental appliqué : Les technologies ou principes participant à la solution sont nouvelles, ou les problèmes posés entièrement nouveaux et sans exigences fonctionnelles précisées. Les technologies tierces raccordées à la solution sont elles-mêmes encore instables, faiblement documentées et nécessitent une validation et des essais approfondis. Cependant, des preuves d’intégration sont disponibles et consultables. Une étude de faisabilité amont a pu déterminer que la solution était « théoriquement et conceptuellement accessible », et que l’essentiel du travail consiste à concevoir une mise en œuvre appliquée viable du problème.

Expérimental prospectif : Les technologies envisagées constituent un champ de recherche et d’expérimentation nouveau pour le équipes, ce qui demande tout d’abord une phase de recherche de faisabilité par l’analyse du fonctionnement et de la réalité des APIs disponibles. Le risque d’aléa majeur est important : sortie du réalisme économique, promesses technologiques non tenues par les éléments à intégrer, découverte d’une complexité de modèle, ou d’administration. Incomplétude chronique des APIs, etc.

Retour à l'index du plan qualité