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

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

La plupart (pour le pas dire toutes) des processus de conception et de réalisation définies en génie-logiciel se basent sur l'une des deux approches :

1. L'approche ascendante (ou l'approche bottom-up) :

En optant pour cette approche, vous procédez à construire votre système en partant de plusieurs parties plus petite. Cette approche peut être retrouvée, à titre exemple, dans :

1. La conception d'une base des données en se basant sur les dépendances fonctionnelles : dans ce cas, une dépendance fonctionnelle est vue comme une partie, le schéma global de la base des données est constuit en combinant, nettoyant et regroupant les différentes dépendances fonctionnelles. Le processus principal est l'algorithme de la couverture minimale (qui utilise, à son tour, l'algorithme de la fermeture transitive).
2. La programmation orientée composants : dans ce cas, un composant est vu comme une partie du système, l'application finale est le résultat d'une combinaison (couplage) entre les différents composants. Les composants sont, généralement, disponible dans un entrepôt des composants et il est possible de choisir un parmi les différents processus proposés pour procéder à la sélection des composants adéquats aux besoins visés par l'application.

Parmi les différentes approches basées sur les composants, nous trouvons l'approche des services web et ses annuaires UDDI qui permettent de localiser et d'invoquer des services web existants pour construire une nouvelle application (composition par orchestration ou par chorégraphie).

2. L'approche descendante (ou approche top-down) :

C'est la proche la plus utilsiée vu qu'il n'est pas possible (pour des raisons d'existance, d'incompatibilité, du coût ou pour autres raisons) d'obtenir les composants de base pour construire un système. Cette approche part de l'ensemble des besoins (fonctionnels et techniques) et tente de découper le système à des sous-systèmes qui seront à leur tour décupés à des sous-sous-sytème pour arriver, enfin, à un niveau où la réalisation est faisable. Cette approche était l'approche intuitive et logique au début de l'informatique et le premier processus proposé (le processus en cascade) n'est qu'une formalisation directe de cette approche. le processus en cascade commence par la définition des besoins, ensuite, chaque besoin est analysé pour donné lieu à une conception abstraite puis une conception détaillée (le nom dit tout !). Cette approche est très visible dans le cas des approches proposées aujourd'hui, surtout celles basées sur le langage UML (UP, XP, Y) : le diagramme des cas d'utilisation prémordial et utilisé par toutes ces approches n'est qu'un premier découpage du système à un ensemble de "processus ou modes d'utilisation".
Cette approche fait l'objet de cet article. En effet, les différents processus en génie-logiciel proposent des solutions pour les différents problèmes rencontrés au niveau des entreprises.
Les premiers processus itératifs proposées visaient à répondre à la problématique du changement des besoins fonctionnels du système à construire. L'environnement dynamique de l'entreprise ainsi que les changements nécessaires à sa survie rendent les besoins fonctionnels temporaire (en quelque sorte) : changements des procédures, adaptation à des nouvelles lois, apparition des besoins d'interopérabilité, ainsi que des dizaines de possibilités qui poussent les concepteurs à revoir leur conception et par la suite la partie à modifier du logiciel.
Les processus en prototypage visent à régler un autre type de problème : réduire au maximum le temps de livraison. Un système qui garantit plusieurs fonctionnalités peut être lourd à implémenter, ainsi, pourquoi en pas livrer une partie du système à la fois, par conséquent, les équipes de conception et de réalisation peuvent se concentrer sur cette partie ("petite" par rapport à la taille du système finale). Le processus est répété selon le nombre des fonctionnalités à implémenter et chaque itération donne naissance à une nouvelle partie du système et qui sera directement intégrée à l'application qui est déjà en cours d'utilisation.
Le processus en Y, partiellement itératif (ou semi-itératif) vise à régler un autre type de problème : la prise en compte de la dimension technique. Les premiers processus en génie-logiciel passaient par les quatre niveaux d'abstraction (vues extérieures, niveau conceptuel, niveau logique et niveau physique) du niveau le plus abstrait vers le niveau physique, ainsi, les choix techniques étaient généralement pris après la fin de la conception (ce qui permettait, d'ailleurs, de choisir les meilleures technologies pour la conception effectuée). Cette approche est encore possible lorsqu'il s'agit d'une première automatisation du système d'information, mais, elle devient lourde si le système (ou l'application) à construire doit respecter un ensemble de choix techniques déjà pris par les premiers systèmes développés dans l'organisation. Ainsi, pour une prise en compte explicite de ces besoins dits techniques nous devons faire recours au processus de développement en Y.
La question que nous devons poser à la fin de cette première partie est la suivante :
Qu'elle est le meilleure processus (ou approche) à utiliser pour développer une application dans le cadre d'un sujet de recherche ?


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

Enseigner l’algorithmique pour les débutants .. Deux solutions pour le même problème

Une analyse de la situation actuelle à l’université algérienne peut nous amener à conclure que l’enseigner l’algorithmique est une responsabilité. En effet, les étudiants en 1ère année universitaire n’ont pas encore tranché pour leur future, ils ont, seulement, choisi l’option MI : Mathématiques et Informatique. Ce tronc commun est destiné aux matheux ayant plus de 12 comme note de mathématiques en BAC. Avec l’invisibilité qui règne sur le future de tout jeune algérien, la plus part des étudiants en 1ère année hésitent encore entre suivre un parcours en Mathématiques ou opter pour une carrière en Informatique. L’Algorithmique peut être le module clé pour pousser l’étudiant à l’une des deux possibilités.

Prenons un exemple utilisé généralement pour aider les étudiants à comprendre et à travailler sur les matrices : la deuxième diagonale d’une matrice carrée. Cette diagonale peut être présentée dans différents exercices tels que le carré magique.

En se basant sur l’évolution du cours, nous allons probablement se trouver avec une analyse de passage entre les deux cellules voisines pendant le parcours de cette diagonale :

Ainsi, l’algorithme sera du genre (en prenant “i” comme indice de ligne, “j” comme indice de colonne et N la taille de la matrice) :

i := 1;

j := N;

TQ (i <= N) Faire

     {Notre traitement}

     {La cellule actuelle est accessible par M[i, j]}

     i := i + 1;

     j := j - 1;

FinTQ

Est ce la meilleure solution ? Si on prend le temps d’exécution et l’espace mémoire, la réponse sera Non. Nous pouvons proposer une deuxième solution en partant de l’affirmation suivante (ou de la remarque intuitive, si vous voulez) suivante :

“Lorsque i est incrémenté par 1, j est décrémenté par la même valeur”

Une petite adaptation rapide peut, vite, amener l’étudiant à proposer l’algorithme de la forme :

i := 1;

TQ (i <= N) Faire

    {Notre traitement}

    {La cellule actuelle est accessible par M[i, N - i + 1]}

    i := i + 1;

FinTQ

En d’autres termes, le j est écrit en fonction de i et on gagne deux (ou quatre) octets en mémoire centrale.

Pour un développeur, ou même un étudiant en 2ème année, cette solution paraît très simple et même la solution logique, mais pour un étudiante en 1ère année, les choses diffèrent.

Le problème ne réside pas dans la formule de j en fonction de i (le N - i + 1); une fois demandé, les étudiants arrivent souvent à la trouver facilement en partant du fait qu’on parle d’une symétrie par rapport au centre de la matrice :

(i + j) / 2 = (1 + N)/2

i + j = 1 + N

j = N - i + 1

Le vrai problème réside dans cette sensation qui pousse l’étudiant à penser qu’il est possible d’écrire j en fonction de i et de gagner quelques octets en mémoire centrale. Notre enseignant M. B. Chergou (page perso) faisait référence à cela par dire que c’est la partie “génie” dans “ingénieur”, une affirmation encourageante pour des étudiants qui ont déjà choisi “ingénieur en informatique” comme carrière. Cette même affirmation ne peut pas, forcément, avoir le même effet sur des étudiants 1) en licence, 2) n’ont pas encore fait leur choix et 3) se sentent dans l’insécurité.

Pendant une séance de Travaux Dirigés, on peut être amené à présenter l’une des deux solutions; pas seulement pour cet exemple, mais pour dans les différents cas les différents exercices un peu plus compliqué que le calcul de la somme de deux entiers. La solution présentée dépendra, probablement, des éléments les plus actifs pendant cette séance. Elas, un risque se présente : présenter la deuxième solution au problème, sans donner la possibilité aux étudiants, qui n’ont pas eu l’intuition de la détecter, de voir d’autres possibilités va les laisser derrière; répétez la même chose pendant deux à trois séances, et je peux vous garantir que vous aller continuer avec le même groupe qui a fait cette intuition pendant que les autres vont peu à peu abandonner le module en le voyant comme un module intuitive, non méthodique et même poétique (n’oubliant pas qu’il s’agit des matheux).

A mon avis, il est très important d’opter pour la première solution; la solution méthodique, sans ajouter les contraintes d’optimisation sur les étudiants et de présenter la deuxième solution par la suite comme un raccourcis qui peut être emprunté (ou pas). Ainsi, l’aspect “exacte” de l’algorithmique et de la programmation de manière générale restera préservé et les étudiants seront (pour le moment) protégés d’avoir l’impression que la programmation est basée des capacités d’observation particulières ou nécessite une intelligence spéciale.

P.S : Cet article est fait suite à un constat réel qui dépend (comme les sciences sociales le précisent) de l’échantillon des étudiants, la succession des évènements et le contenu du cours et des travaux dirigés présentés. Un tel problème ne sera pas, probablement, rencontré si les étudiants ont déjà fait des travaux de programmation (tous les étudiants) (Cours CS 106 - U. Stanford)

Enseigner et écrire pour maîtriser, et pourquoi pas le modèle chinois?

“Si vous n'arrivez pas à expliquer un concept à un enfant de 6 ans, c'est que vous ne maîtrisez pas ce concept.” - Albert Einstein.

Il nous arrive dans notre cursus d’ingénieur d’apprendre des tas de choses, de les comprendre et de les utiliser, sans pour autant les maîtriser. La maîtrise n’est confirmée si on les enseigne.

“Vous ne devez pas écrire un livre sur une thématique donnée si vous n’arrivez pas à en parler pendant une heure, sans préalable préparation, devant un publique.” - Tariq Suwaidane.

Encore plus difficile qu’enseigner, écrire un livre sur une thématique nécessite plus de connaissance et une meilleure maîtrise. Alors devons nous attendre d’atteindre ce niveau pour essayer d’enseigner ou bien d’écrire?

Heureusement, d’autres modèles peuvent être suivis pour atteindre la perfection, et en particulier le modèle chinois : et si on essaye de le faire, même si on ne le maîtrise pas? Et si on essaye d’apprendre et de maîtriser pendant qu’on le fait? Si on observe l’évolution de la production chinoise des produits de haute technologie et des voitures, nous allons apercevoir clairement l’application de ce modèle.

Le modèle n’est pas nouveau, il découle des théories pédagogiques constructives qui encouragent l’apprentissage par l’application et non pas par un passage passif de connaissances de l’enseignant vers l’apprenant. Dans ce contexte, l’apprenant est surveillé et supporté par son enseignant pour obtenir les résultats attendus; il effectue des activités d’apprentissage où l'échec n’est qu’une étape vers le succès. Néanmoins, son application dans la vie quotidienne et dans la vie professionnelle a donné des résultats très satisfaisants malgré que l’environnement professionnel oppose le milieu éducatif, il est très hostile, il n’offre aucun support ou encadrement et il ne donne des chances minimes pour retenter.

Quand je dis “enseigner” pour maîtriser, je ne parle pas d’enseigner dans une institution officielle; la préparation d’une formation gratuite donne la possibilité de vivre une expérience similaire et faire plusieurs tentatives pour perfectionner ses connaissances dans le domaine en question et dans le domaine pédagogique. Du même, “écrire” ne veut pas dire se plonger dans une aventure risquée de publication d’un livre, mais, rédiger et écrire des tutoriels et e-books gratuits sur Internet.

Je pense que nous avons, plus que jamais, la possibilité d’apprendre et de maîtriser par appliquer, enseigner et écrire grâce aux technologies d’internet qui nous permettent d’avoir un feedback de nos amis et des communautés spécialisées sur nos productions, et du coup, on peut voir la société remplace l’enseignant d’une manière positive.   

Mon niveau technique a baissé? Et un mot sur les frameworks.

Depuis presque cinq ans, je me suis orienté vers la vie académique. J’étais fortement inspiré par mon projet de fin d’étude qui portait sur l’application des techniques de Recherche d'information (RI) pour résoudre des problèmes liés à l’e-Learning. Il était déjà très clair dans ma tête que je veux continuer l’aventure académique.

Depuis, j’ai travaillé sur plusieurs aspects techniques et conceptuels touchant directement  à la problématique de l’apprentissage à distance. Au milieu de tout cela, j’ai ignoré un aspect important dans ma carrière comme étant informaticien, avant d’être un jeune-chercheur : c’est l’aspect technique, maintenant, je sens que mon niveau technique a baissé! Comment ça s’est arrivé?

Durant les cinq années, j’ai travaillé en Free-lance, c’est très pratique quand il est difficile d’occuper un poste à plein temps (parce que ça sera un sacrifice de la carrière académique). En Free-lance, on a la possibilité de garder un certain niveau de pratique technique, et je suis sûr que je garde le même niveau que j’ai eu depuis quatre à cinq ans alors où est le problème?

Le problème c’est le style de développement, les habitudes des développeurs et les techniques de développement. Il n’est plus possible de suivre le même rythme en commençant chaque fois “from scratch” ou de développer suivant un modèle MVC personnel, il est important de ne plus écrire un code personnel à 100%, il faut réfléchir à utiliser les frameworks disponibles. 

“Il n’y a plus de Javascript, il y a maintenant jQuery”, affirme Scott Hanselman, et de la même façon, dans quelques années, nous n’allons plus entendre de Java, PHP et C# sous la même forme d’aujourd’hui, les frameworks deviendront inséparable des projets de développement les plus simples. Mon niveau technique n’a pas baissé, il n’a pas évolué et c’est ça le problème.

Il est évident qu’il est difficile de suivre deux chemins au même temps, qu’il est impossible de tenter d’attraper deux lapins au même temps, mais, des fois il est amusant d’essayer. Ainsi, mon conseil à vous aussi : les habitudes de programmation changent, il faut que nous changions aussi, sinon, nous perdrons la bataille, tout comme les dinosaures. 

Bienvenue

Bonjour,

Je suis Tarek BOUTEFARA, titulaire d'un diplôme de Magistère en informatique, obtenu à l'Ecole nationale Supérieure d'Informatique (http://www.esi.dz), option Systèmes d'Information et de Connaissances. Actuellement, je prépare une thèse de doctorat dans la même école. La thèse entre dans le cadre des techniques d'apprentissage à distance, connu aussi sous le nom du "e-Learning".

Le e-Learning est un domaine très actif vu qu'il touche à l'une des activités les plus anciennes, à savoir l'apprentissage. Pour la même cause, le e-Learning est parmi les domaines les plus vastes, il couvre les différents aspects liés à sa problématique en commençant par les aspects purement techniques pour arriver aux aspects abstrait en liaison direct avec les sciences de l'éducation. Actuellement, je travaille sur une problématique liée aux "styles d'apprentissage" sous la direction de Mme. MEHDAOUI Latifa.

Au même, et comme toute enseignant chercheur, j'ai eu des expériences en enseignement et en encadrement des étudiants de fin cycle et de Master 2. Mes activité d'enseignement portaient essentiellement sur des modules techniques (J2SE, Pascal) et basiques (Introduction à l'Algorithmique), tant dit que mes activité d'encadrement se focalisaient sur des projets entrant dans le cadre de mes travaux de recherche mais portant sur des thématiques plus générales et moins compliquées pour être assimilées dans les délais (très courts) des projets.

Pour mieux apprendre sur mes expériences, je vous prie de visiter mes autres blogs dédiés:

• DZ-eLearning.
• DZ-Encadrement.
• t-boutefara-ens. (Nouveau)

Ce blog sera réservé pour les autres expériences ainsi que l'informatique de manière générale. J'espère que vous trouverez de la valeur et de l'importance entre les lignes des différents articles.