Cycle de développement idéal d'un logiciel du Terrier¶

Après plusieurs heures de réflexion autour de l'histoire des développements des logiciels du Terrier, nous avons tenté d'établir un cycle de développement intéressant pour les actuels et prochains logiciels du Terrier.

1. Genèse du logiciel¶

Une personne (développeur ou non) propose une idée de logiciel à créer, selon un modèle existant, un besoin, une idée...
Cette envie peut être discutée sur la liste dev@abuledu.org puis une fois éclaircie, déposée dans la forge (le wiki par exemple) pour en garder trace et échanger.

Moyens : liste dev@ et forge

2. Embryon et parrainage¶

Un développeur motivé s'empare du projet et décide d'en proposer un embryon : le "Proof of concept". Cette version fonctionnelle (mais bourrée de bugs) sert de proposition pour étayer la réflexion.
Un "parrain" s'approprie le projet et décide de le suivre pour aider le développeur en faisant le lien avec les utilisateurs. Il propose le sujet de discussion sur la liste dev@ et invite ceux qui souhaitent participer à ce projet à le soumettre aux usages pratiques.

Moyens :

• Parrain
• liste dev@
• projet déclaré sur la forge

3. Objectifs pédagogiques, usages¶

A partir de pistes pédagogiques, les utilisateurs proposent des scenarii pédagogiques à valider (quelle est la consigne, que doit faire l'utilisateur ?).
Ce temps primordial permet de fouiller et imaginer les pistes pédagogiques, scenarii d'utilisation du logiciel ainsi que des fonctionnalités qu'il serait possible de rajouter. Les instructions officielles peuvent être une base de réflexion sur les objectifs à atteindre (mais pas uniquement). Le débat peut s'engager.
Outil : liste dev@abuledu.org et Feature Request de la forge.

Moyens :

• pré-version postée sur la liste dev@,
• Réunion physique des membres du projet avec le parrain (hormis le développeur).

4. Discussions et réunion¶

Lors d'une réunion "physique" entre le développeur et le parrain, la liste des scenarii pédagogiques et des fonctionnalités à implanter ou non est listée. Il nous a semblé important de pouvoir décider ou non si ces fonctionnalités étaient à développer ou non.
Pour chaque fonctionnalité nouvelle, on décide d'une échéance approximative.
Ils évaluent selon le cahier de contraintes général établi pour la majeure partie des logiciels du Terrier, si elles doivent être développées ou non pour ce logiciel.
Ils établissent une Roadmap "cadre" pour fixer ce que sera la prochaine version du logicielle (version n), selon les envies et possibilités du développeur.
IMPORTANT : Un bilan de cette réunion est rédigé dans le wiki.

Moyen : forge et réunion physique

5. Utilisation de la forge : Roadmap¶

Les versions du logiciel sont fixées dans la forge (n, n+1...) et les fonctionnalités et tâches sont programmées par le développeur selon un calendrier.
Certains points peuvent rester en discussion lorsque le développeur souhaite avoir plus d'informations sur le comportement du logiciel pour mettre en place cette fonctionnalité.
La roadmap se crée automatiquement selon les fonctionnalités programmées.

Moyens : forge du projet

Aide : Description des états des demandes de la forge¶

• En cours : en cours d'implémentation. Le développeur travaille dessus.
• corrigé : fonctionnalité implémentée. Elle est utilisable dans la version du développeur.
• réflexion en cours : En attente de complément d'information.
• Rejeté : demande refusée
• Invalidé : bug non reproduit ou caduque
• En attente : fonctionnalité programmée dans une version future, non fixée.

6 Finalisation¶

La version "n" est disponible et proposée par le développeur.
Il reste alors à tester le logiciel, vérifier que les scenarii correspondant aux fonctionnalités intégrées soient valides.

Moyens : liste dev@

7 Tests et réclamations¶

Les testeurs passent le logiciel à la moulinette des tests et déposent des demandes ergonomiques pratiques. Des retours de bugs sont remontés sur la forge. Ceci permet de proposer une nouvelle version modifiée, par le développeur ou un patch d'un contributeur.

Moyens :

• liste dev@ pour échange
• forge pour remontée de bugs...

8. Documentation¶

Il faut alors produire du contenu pédagogique (des exemples, des exercices...), ainsi qu'une documentation pour l'aide à la mise en place dans un cadre scolaire par exemple et rédiger l'aide complète du logiciel.

Moyens : Forge pour aide, documentation, contenu

9. Mise à disposition du public¶

Il faut proposer des paquets utilisables sur les nombreuses plateformes et tester les fonctionnalités présentes.
Un test auprès d'un nouvel utilisateur peut être pertinent du point de vue ergonomique ou fonctionnel.

Moyens : Hébergement des paquets : forge et dépot

10. Version n+1¶

• Si de nouvelles fonctionnalités sont proposées, on peut repasser par la phase 3 et rediscuter avec les acteurs du projet si elles doivent être implémentées.
• Sinon, on revient à la phase 5, on s'assure que le comportement est clairement défini pour les fonctionnalités de la version n+1 et on recommence.

Pistes de logiciels¶

Différents types de logiciels éducatifs du Terrier :

• Logiciels d'apprentissage
• Exerciseurs
• Création
• Recherche