Modèles, méthodes et approches issus de l’ingénierie pédagogique

Modèles, méthodes et approches issus de l’ingénierie pédagogique

L’expression ingénierie pédagogique, autrefois design pédagogique est la traduction en langue française de l’expression anglaise Instructional Engineering (Basque, 2011).
Des experts en pédagogie ont défini le design pédagogique comme étant une discipline éducationnelle qui concerne la conception de stratégies définissant des situations pédagogiques (Sauvé, 1992) ou comme étant un processus systématique permettant la création d’activités d’apprentissage et de matériel d’enseignement (Smith & Ragan, 1999). L’expression design pédagogique fait aussi souvent référence au processus de conception des systèmes d’enseignement et d’apprentissage ainsi qu’au modèle descriptif des composantes faisant partie d’un système d’enseignement et d’apprentissage (Willis, 1995). Cette expression est aussi définie comme étant ce qui concerne l’élaboration de solutions d’apprentissage (Basque, 2011).

D’une part l’avènement et l’intégration des technologies de l’information et de la communication dans le processus du design pédagogique et d’autre part la prise en compte d’une démarche scientifique et systémique et l’emprunt d’outils au domaine de l’ingénierie logicielle entraîne la requalification du design pédagogique en ingénierie pédagogique.
Nous retenons de cet exercice de définition que l’expression ingénierie pédagogique fait référence à l’ensemble des méthodes permettant de savoir représenter les situations pédagogiques par des formalismes de telle sorte qu’elles puissent être réutilisées dans d’autres contextes.

Le concept patron

Le concept patron trouve son origine dans le domaine de l’architecture (Avgeriou & Zdun, 2005; Devedzic & Harrer, 2005). Il y a été introduit par l’architecte Christopher Alexander dans son livre intitulé The timeless way of building. Selon Christopher Alexander, chaque patron décrit un problème récurrent dans notre environnement, et décrit la solution de ce problème de telle sorte que cette solution soit réutilisable autant de fois qu’on le souhaite (Gamma, 1995).
Cette définition, ou plutôt cette description, est la plus répandue aujourd’hui dans la littérature scientifique et relayée par un grand nombre de chercheurs tels (Beck & Johnson, 1994; Schmidt, 1995; Buschmann et al. , 1996; Tešanovic, 2004). Il s’agit bien d’une description du concept de patron, car ainsi que l’admettront Winn et Calder (Winn & Calder, 2002), définir de façon absolue et exhaustive ce concept est difficile voire impossible.

Les patrons doivent s’intégrer parfaitement à l’environnement dans lequel ils sont importés, et peuvent dans certains cas former des chaînes de patrons, c’est-à-dire des langages de patrons, avec des patrons pré-existants dans le milieu d’accueil.

Les patrons doivent correspondre à la fois à des caractéristiques fonctionnelles et non fonctionnelles :
caractéristiques fonctionnelles : un patron possédant une caractéristique fonctionnelle constitue un outil d’aide à la décision (Winn & Calder, 2002). Dans le cas d’un langage de patrons par exemple, les patrons doivent être structurés suivant les idées et principes qu’ils véhiculent. Le caractère fonctionnel des patrons s’exprime ici par le fait qu’ils documentent une solution à un problème.
caractéristiques non fonctionnelles : un patron possédant une caractéristique non fonctionnelle constitue un outil d’évaluation de la faisabilité de la solution documentée (Winn & Calder, 2002). Dans ce cas, les patrons doivent répondre à certaines exigences :
cibler les problèmes importants en s’intéressant à «comment faire» et non à «pourquoi faire» ;
être génériques pour s’adapter, par définition, à des problèmes récurrents ;
avoir la capacité d’évoluer en étant ouverts et extensibles ;
avoir un pouvoir d’expression.

Le paquetage Validation

Il permet d’établir la preuve documentée que les spécifications et exigences ont été respectées. Il permet pour cela de tester la nouvelle plateforme, afin d’y déceler d’éventuels problèmes et de ce fait procéder aux changements conséquents avant la phase de déploiement.

Le paquetage Validation a pour objectif la vérification du respect des spécifications et exigences implémentées durant la phase précédente d’implémentation dans un langage de programmation. Elle permet de vérifier la compatibilité du nouveau système avec chacune des spécifications et exigences déterminées pendant tout le processus de conception. Pour cela, des tests de conformité, de performance et de robustesse sont effectués après l’assemblage des différents composants développés de façon isolée, du nouveau logiciel, et doivent être tous passés avec succès.

L’approche IMS Learning Design

La spécification IMS  est un système d’apprentissage issu de l’implémentation des standards du groupe de travail international dénommé IMS Global Learning Consortium et présenté dans plusieurs travaux (Lindner, 2006; Stracke, 2006; Moreno Ger et al. , 2007).Dans cet outil, l’aspect technologique semble avoir été privilégié au détriment des aspects pédagogiques, fait qui constitue une faiblesse qui ne passe pas inaperçue. Sa grande capacité à s’adapter à plusieurs cas d’utilisation fait d’IMS un outil très apprécié dans les domaines techniques, ce qui par la même occasion fait oublier aux spécialistes de l’éducation que l’outil a été conçu pour le domaine de l’éducation (Lindner, 2006).

Place du concept patron dans les processus d’ingénierie pédagogique

Les résultats de l’analyse des neuf modèles, méthodes et approches d’ingénierie pédagogique présentés précédemment permettent de constater le fait que les experts en pédagogie définissent l’ingénierie pédagogique comme étant un processus constitué d’étapes permettant de concevoir des systèmes d’enseignement et d’apprentissage et prévoient même pour la plupart une étape dite de conception logicielle, lorsqu’une solution logicielle est préconisée. La contribution scientifique de cette thèse se situe précisément au niveau de cette étape de conception logicielle faisant partie intégrante du processus d’ingénierie pédagogique.

Il existe plusieurs façons de concevoir des logiciels parmi lesquelles les approches dites traditionnelles et les approches dites émergentes (Hachani, 2006; Agarwal et al. , 2012; Enard, 2013; Vyatkin, 2013). Les approches dites traditionnelles sont composées des approches par conception, par aspects, orientées-objet, et orientées-agent, dans le cadre desquelles le processus de conception part du néant et nécessite la réinvention perpétuelle des parties de logiciels (Hachani, 2006). Les approches par réutilisation de composants, quant à elles, sont basées notamment sur les patrons et permettent de réutiliser des composants d’analyse, architecture ou de code existants.

Table des matières

1.Introduction 
1.1 Contexte 
1.2 Motivations 
1.3 Questions et objectifs de recherche 
1.4 Méthodologie 
1.5 Résultats et contributions
1.6 Plan de la thèse
2.Etat de l’art 
2.1 Modèles, méthodes et approches issus de l’ingénierie pédagogique 
2.1.1 Modèle ADDIE
2.1.2 Modèle proposé par Walter Dick et Lou Carey
2.1.3 Modèle RAPID
2.1.4 Modèle proposé par Kemp, Morrison et Ross
2.1.5 Modèle R2D2
2.1.6 L’approche MOCA
2.1.7 La méthode MISA
2.1.8 L’approche LTSA
2.1.9 L’approche IMS Learning Design
2.1.10 Place du concept patron dans les processus d’ingénierie pédagogique
2.2 Utilisations du concept patron pour concevoir des LEA 
2.2.1 Les patrons proposés par Randriamalaka
2.2.2 Les patrons proposés par Derntl
2.2.3 Les patrons proposés par Goodyear, Avgeriou, Baggetun, Bartoluzzi, Retalis, Ronteltap et Rusman
2.2.4 Les patrons proposés par Avgeriou, Retalis et Papasalouros
2.2.5 Les patrons proposés par Coutinho Anacleto, Talarico Neto et Paula de Neris
2.2.6 Les patrons proposés par Zeid et Salah
2.2.7 Les patrons proposés par Turani et Calvo
2.2.8 Les patrons proposés par Retalis, Georgiakakis et Dimitriadis
2.2.9 Les patrons proposés par Iacob
2.2.10 Les patrons proposés par De Moura Filho
2.2.11 Les patrons proposés par Hadjerrouit
2.3 Analyse comparative des modèles basés sur le concept patron 
2.3.1 Comparaison selon les critères fonctionnels
2.3.2 Comparaison selon les critères non fonctionnels
2.3.3 Comparaison selon la nature de la solution proposée
2.4 Problématique et objectifs de recherche 
2.4.1 Définition de la problématique
2.4.2 Objectifs de recherche
2.5 Conclusion
3.Approche de conception des LEA basée sur les patrons 
3.1 Méthodologie pour la définition de notre approche de conception 
3.1.1 Le concept patron
3.1.1.1 Définitions
3.1.1.2 Représentation des patrons
3.1.1.3 Classification
3.1.1.4 Exemples
3.1.2 Formalisme choisi pour la représentation des patrons
3.1.2.1 Processus d’identification des patrons
3.1.2.2 Format textuel choisi
3.1.2.3 Formalisme graphique choisi
3.2 Description de l’approche de conception proposée 
3.2.1 Les différentes phases de l’approche proposée
3.2.1.1 Des phases chronologiques et itératives
3.2.1.2 Des phases observées et analysées
3.2.1.3 Des phases restructurées par une approche écologique
3.2.1.4 Niveaux d’abstraction proposés
3.2.2 Guide de recherche de patrons
3.3 Conclusion
4.Répertoire des patrons regroupés en paquetages 
4.1 Le paquetage Pédagogique 
4.1.1 Représentation textuelle
4.1.2 Diagramme des exigences
4.1.2.1 Patrons recensés
4.1.2.2 Exemple : le patron Nouveaux enjeux technologiques
4.1.2.3 Exemple : le patron Réseaux de concepts
4.1.3 Diagramme de définition de blocs
4.2 Le paquetage Architecture logicielle 
4.2.1 Représentation textuelle
4.2.2 Diagramme des exigences
4.2.2.1 Patrons recensés
4.2.2.2 Exemple : le patron Interopérabilité
4.2.2.3 Exemple : le patron Performance
4.2.3 Diagramme de définition de blocs (page suivante)
4.2.3.1 Patrons recensés
4.2.3.2 Exemple : le patron Architecture logicielle : :Interface
4.2.3.3 Exemple : le patron Modèle d’intégration des données
4.3 Le paquetage Interface utilisateur 
4.3.1 Représentation textuelle
4.3.2 Diagramme des exigences
4.3.2.1 Patrons recensés
4.3.2.2 Exemple : le patron Systèmes natifs
4.3.3 Diagramme de définition de blocs
4.3.3.1 Patrons recensés
4.3.3.2 Exemple : le patron Personnalisation
4.3.3.3 Exemple : le patron Contrôleur d’application
4.4 Le paquetage Choix technologiques
4.4.1 Représentation textuelle
4.4.2 Diagramme des exigences
4.4.2.1 Patrons recensés
4.4.2.2 Exemple : le patron Portabilité
4.4.3 Diagramme de définition de blocs
4.4.3.1 Patrons recensés
4.4.3.2 Exemple : le patron Elaboration des règles des choix technologiques
4.5 Le paquetage Implémentation 
4.5.1 Représentation textuelle
4.5.2 Diagramme des exigences
4.5.2.1 Patrons recensés
4.5.2.2 Exemple : le patron Optimisation du code
4.5.2.3 Exemple : le patron Résilience et tolérance aux fautes
4.5.3 Diagramme de définition de blocs
4.5.3.1 Patron recensé
4.5.3.2 Exemple : le patron Programmation des modules logiciels
4.6 Le paquetage Validation 
4.6.1 Représentation textuelle
4.6.2 Diagramme des exigences
4.6.2.1 Patrons recensés
4.6.2.2 Exemple : le patron Utilisabilité
4.6.3 Diagramme de définition de blocs
4.6.3.1 Patrons recensés
4.6.3.2 Exemple : le patron Test_exig_architecture
4.6.3.3 Exemple : le patron Test_exig_utilisateur
4.7 Le paquetage Déploiement 
4.7.1 Représentation textuelle
4.7.2 Diagramme des exigences
4.7.2.1 Patrons recensés
4.7.2.2 Exemple : le patron Plan du site d’accueil
4.7.3 Diagramme de définition de blocs
4.7.3.1 Patrons recensés
4.7.3.2 Exemple : le patron Configuration
4.7.3.3 Exemple : le patron Aspect sécuritaires
4.8 Le paquetage Evolution 
4.8.1 Représentation textuelle
4.8.2 Diagramme des exigences
4.8.2.1 Patrons recensés
4.8.3 Diagramme de définition de blocs
4.8.3.1 Patrons recensés
4.8.3.2 Exemple : le patron Veille technologique
4.8.3.3 Exemple : le patron Dépannage
4.9 Conclusion 
5.Cadre de validation de la démarche de conception des LEA basée sur les patrons 
5.1 Etude de cas 1 : conception d’un module logiciel d’analyse et d’évaluation de la participation estudiantine
5.1.1 Contexte
5.1.1.1 Existant
5.1.1.2 Besoin de l’équipe du centre de recherche TACT
5.1.1.3 Résultat escompté
5.1.2 Approche de conception
5.1.2.1 Méthode de sélection des patrons
5.1.2.2 Phase d’analyse et de spécification des exigences pédagogiques
5.1.2.3 Phase de conception de l’architecture logicielle
5.1.2.4 Phase de conception de l’interface
5.1.2.5 Phase des choix technologiques
5.1.2.6 Phase d’implémentation
5.1.2.7 Phase de validation
5.1.2.8 Phase de déploiement
5.2 Etude de cas 2 : conception d’un forum de discussion pédagogique
5.2.1 Contexte
5.2.1.1 Besoin
5.2.1.2 Résultats attendus
5.2.2 Approche de conception
5.2.2.1 Méthode de sélection des patrons
5.2.2.2 Phase d’analyse et de spécification des exigences pédagogiques
5.2.2.3 Phase de conception de l’architecture logicielle
5.2.2.4 Phase de conception de l’interface utilisateur
5.2.2.5 Phase des choix technologiques
5.2.2.6 Phase d’implémentation
5.2.2.7 Phase de validation
5.2.2.8 Phase de déploiement
5.3 Conclusion 
6.Discussion et conclusion 
6.1 Résumé 
6.2 Discussion des résultats 
6.3 Avantages et limites 
6.4 Perspectives de recherche 
Liste des publications

Télécharger le rapport complet