Appropriation d’un logiciel éducatif pour alphabétiser

Dans un précédent travail, nous avons proposé un modèle de qualité pour systèmes interactifs informatifs, basé sur la norme internationale ISO/IEC 25010, qui considère une caractéristique supplémentaire de communicabilité. Cette caractéristique est composée de 4 sous-caractéristiques : l’attractivité, l’intérêt, la crédibilité et l’informativité. Nous considérons que ces attributs de qualité sont à leur tour des critères d’appropriation de logiciels éducatifs. Il serait alors nécessaire que les logiciels éducatifs soient conçus et développés en tenant compte de ces caractéristiques.

Dans ce but, nous avons analysé le jeu de Candy Crush (CC), et avons dégagé quelques unes des stratégies utilisées par ses concepteurs pour le rendre informatif, attractif, intéressant et crédible.

Nous avons alors appliqué ces stratégies pour concevoir un logiciel éducatif dirigé à des adultes analphabètes pour les motiver à apprendre à lire et écrire. L’intérêt de la démarche n’est donc pas tant de savoir si les élèves apprennent avec ces logiciels mais, si les professeurs trouvent cet outil utile et les élèves se l’approprieront-ils au point de l’utiliser de manière autonome.

Cette démarche comprend alors les suivantes étapes:

1. Analyse de CC en termes d’informativité, attractivité, intérêt et crédibilité

• Informativité

Bien qu’un jeu n’ait pas la vocation de transmettre de l’information à ses utilisateurs mais de les divertir, il est nécessaire de leur transmettre et expliquer ses règles et techniques. Mais il est surtout nécessaire de leur apprendre à construire les stratégies qui leur permettront de gagner. Pour cela, CC est un jeu structuré de manière linéaire autour d’une histoire et l’information est distillée de manière graduelle au fil des étapes.

• Attractivité

Le jeu est attractif depuis le premier instant, grâce aux formes des bonbons, leur couleurs et surtout aux explosions spectaculaires qui dérivent des assemblages des divers objets.

• Intérêt

Pour maintenir l’intérêt des joueurs, chaque étape du jeu présente un nouveau défi. Afin de le résoudre, il est nécessaire de construire de nouvelles stratégies.

• Crédibilité

La crédibilité est offerte par le réalisme des objets, des bonbons de tout genre et leur mouvements qui respectent les différentes lois de la physique.

2. Conception du logiciel d’alphabétisation

Le logiciel que l’on veut concevoir fera partie de la campagne nationale d’alphabétisation. Dans une première phase, il sera utilisé par les instructeurs pour alphabétiser et, postérieurement, par les analphabètes de manière indépendante.

Les usagers du logiciel sont donc, en premier lieu, des instructeurs qui doivent y trouver un instrument utile et, en deuxième lieu, les analphabètes qui doivent avoir été suffisamment séduits et intéressés par le logiciel pour continuer tout seuls. Il est donc bien question de chercher comment professeurs et élèves peuvent s’approprier d’un logiciel éducatif. Nous partons de l’hypothèse qu’afin de faciliter l’appropriation, le logiciel devrait être informatif, attractif, intéressant et crédible. Sa conception doit alors prendre en compte ces caractéristiques et, dans ce but, nous avons utilisé les stratégies utilisées dans CC et les avons détournées afin de créer notre concept de logiciel éducatif.

Quelques unes des stratégies utilisées sont les suivantes:

• Histoire linéaire structurée par niveaux, lesquelles se divisent à leur tour en étapes. Chaque étape est constituée par un jeu dont la difficulté augmente de manière graduelle.
• Pour les analphabètes, c’est également leur premier contact avec une tablette, un ordinateur. Le jeu doit donc être attractif par les objets, couleurs et différentes interactions.
• Les défis proposés par chaque jeu doivent maintenir l’intérêt de l’usager tout en lui offrant la satisfaction de pouvoir le dominer
• Les objets que les usagers auront à manipuler sont réels et utiles : recettes, factures, formulaires, etc.

C’est sur ses bases que le concept créatif du logiciel a été formulé et, avant son développement, un prototype a été construit incluant les éléments à évaluer.

3. Développement et évaluation d’un prototype

Le prototype a pour but d’évaluer avec les usagers si le logiciel répond aux expectatives et mesurer son degré d’appropriation. Cette évaluation se réalise de manière quantitative et qualitative. L’évaluation quantitative est mesurée à travers le temps passé par les usagers dans chaque jeu, les clics effectués et le nombre d’erreurs. Cela permet de mesurer l’intérêt et la difficulté des défis présentés et sa compréhension des différentes interfaces.. L’évaluation qualitative se réalise à travers un questionnaire dont le but est de ratifier ou corriger les résultats de l’évaluation quantitative ainsi que reconnaitre son utilité.

Positionnement scientifique

Le travail présenté s’inscrit dans le champ du Génie Logiciel ou Software Engineering en anglais. Il prétend apporter des éléments de réponse à la problématique de concevoir des logiciels dont les besoins exprimés se réfèrent à des caractéristiques de qualité telles que informatif, attractif, intéressant et crédible.

Pour répondre à ce questionnement, nous nous sommes intéressés à la manière dont sont conçus les jeux, lesquels doivent forcément répondre à ces caractéristiques de qualité pour atteindre le succès. D’après Callele [3], dans l’industrie des jeux vidéo, il existe deux étapes différentiées: la pré-production et la production. La première phase a pour but de produire le Document de Jeu (DJ) et la deuxième de le produire suivant un processus de génie logiciel. C’est donc l’analyse du DJ qui permet d’exprimer les besoins du logiciel.

Une fois le DJ établi, nous proposons de réaliser un prototype qui permette d’évaluer si les besoins (informativité, attractivité, intérêt et crédibilité) sont atteints. Cette évaluation se réalise avec les usagers de manière quantitative et qualitative. Une fois le prototype évalué, le DJ est corrigé et sa formulation finale permet d’établir les besoins fonctionnels et non-fonctionnels du système et procéder à sa réalisation.

Références

• “ISO/IEC 25010:2011, Systems and software engineering. Systems and software Quality Requirements and Evaluation (SQuaRE). System and software quality models”, 2011.
• Callele Davide, Neufeld and Schneider, “Emotional Requirements,” IEEE Software, January/February 2008.
• Callele, Davide, “Requirements Engineering and the Creative Process in the Video Game Industry”, 13^th IEEE International Conference on Requirements Engineering. Computer Society, 2005.
• Colomo-Palacios R., Casado-Lumbreras C., Soto-Acosta P. and García-Crespo A, “A Study of Emotions in Requirements Engineering”, Organizational, Business, and Technological Aspects of the Knowledge Society, 2010.
• Colomo-Palacios R., Casado-Lumbreras C., Soto-Acosta P. and García-Crespo A., “Using the Affect Grid to Measure Emotions in Software Requirements Engineering”, Journal of Universal Computer Science, 2011.
• Friedmann, Anthony, “Writing for Visual Media”, Focal Press, 3rd Edition, April 16th, 2010.
• Glinz M., “On Non-Functional Requirements”, 15th IEEE International Requirements Engineering Conference, pages 21-26, 15-19, October 2007.
• Jung H. T., Lee G, “A Systematic Software Development Process for Non-Functional Requirements”, Information and Communication Technology Convergence (ICTC), 17-19 Nov, 2010.
• K. Khatter and A. Kalia, “Impact of Non-functional Requirements on Requirements Evolution”, 6th International Conference on Emerging Trends in Engineering and Technology, 2013.
• Levy, Sylviane, “Metodología de Análisis y Desarrollo para Sistemas Multimedia Interactivos Informativos desde la Perspectiva de la Ingeniería de Software” Posgrado en Ciencia e Ingeniería de la Computación, Universidad Nacional Autónoma de México, Octubre 2013.
• Levy, Sylviane, Gamboa, Fernando, Quality Requirements for Multimedia Interactive Informative Systems, Journal of Software Engineering and Applications, 2013, 6, 416-425 doi:10.4236/jsea.2013.68051 Published Online August 2013 (http://www.scirp.org/journal/jsea)
• Mairiza D., Zowghi D. and Nurmuliani N., “An Investigation into the Notion of Non-Functional Requirements”, SAC’10, Sierre, Switzerland. March 22-26, 2010.
• Roto V., Law E., Vermeeren A. and J. Hoonhout, “User experience white paper. Bringing clarity to the concept of user experience”, disponible en: http://www.allaboutux.org/files/UX-WhitePaper.pdf, 2011. Fecha de consulta: 20 de Enero de 2015.
• Sommerville, Ian, “Ingeniería de Software”, Addison Wesley, Pearson Educación 2011.
• Sutcliffe A., “Emotional Requirements Engineering”, IEEE 19th International Requirements Engineering Conference, 2011.
• Tokkonen H. and Saariluoma P., “How User Experience is Understood?”, Science and Information Conference, London, UK, October 7-9, 2013.
• Ferreiro, Emilia, Alfabetización, Teoría y práctica,Siglo XXI Editores, 5° Edición 2002

Plus d’infos sur la programme du colloque scientifique sur www.ludovia.org/2015/colloque-scientifique

A propos de l’auteur Sylviane Levy