Espoir de la Jeunesse Congolaise

Dans cet exposé, on suppose que l'on connait déjà MERISE

INTRODUCTION

Un système d’information est un ensemble constitué d’éléments unis par des relations, ces éléments et ces relations étant munis de propriétés. La conception d'un système d'information n'est pas évidente car il faut réfléchir à l'ensemble de l'organisation que l'on doit mettre en place pour fidéliser les besoins du client. Une méthode d'analyse et de conception a donc pour objectif de permettre de formaliser les étapes préliminaires du développement d'un système d’information afin de rendre ce développement plus fidèle aux besoins du client. Il existe plusieurs méthodes d'analyse qui sont : Méthodes agiles, Hoom, UP, OOSE... ainsi que MERISE la méthode la plus utilisée en France. MERISE (Méthode d’Etude et de Réalisation Informatique pour les Systèmes d’Entreprise) est une méthode d'analyse et de réalisation des systèmes d'information qui est élaborée en plusieurs étapes: schéma directeur, étude préalable, étude détaillée et la réalisation.

En plus, Le projet d’analyse et de conception des systèmes d’information est cependant géré par différents types de méthodes dites méthodes Agiles. Les méthodes Agiles sont un style de méthode de développement logiciel itératif centré sur les personnes et qui met l'accent sur la satisfaction du client à travers l'intégration continue d'un logiciel entièrement fonctionnel. Elles visent la satisfaction réelle du besoin du client et non les termes d'un contrat de développement. Parmi ces méthodes on trouve la toute première appelée RAD (Rapid Applications Development) créée en 1991, Scrum créée en 1996, XP (Extreme Programming) créée en 1999, ASD (Adaptiv Software Development ) créée en 2000. De toutes les méthodologies Agile, Scrum est unique parce qu'elle introduit le concept de " contrôle empirique des processus". Ce qui signifie que Scrum utilise le progrès réel d'un projet plutôt qu'une estimation ou une prévision mal informée afin de planifier les livrables. Scrum est un processus léger permettant de gérer et de contrôler le développement de produits logiciels. Mettant en œuvre des pratiques itératives et incrémentales. Scrum est en soi, une méthode efficace. Elle peut néanmoins être associée à d’autres pratiques d'ingénierie, notamment Extreme Programming et d’autres méthodes de développement logiciel itératif. C’est l’une des méthodes agiles les plus employées, car elle permet d’améliorer notablement la productivité tout en accélérant le retour sur investissement. L’objectif de cette étude est de présenter et de comparer les méthodes d’analyse et de conception des systèmes d’information MERISE et l’une des méthodes Agile de gestion des projets de développement informatique Scrum.

1. PRESENTATION DES METHODES AGILES : SCRUM

1. Définition

Scrum est une méthode agile pour la gestion de projets basée sur des multiples petites équipes travaillant intensément et indépendamment. Scrum maximise sa productivité facile à adapter à son cycle de développement et nécessite la saisie et le suivi d'une liste de fonctionnalités pour l'ensemble du projet et d'une liste de tâches pour chaque itération. Elle demande également la production de tableaux de bords (c'est-à-dire rapports graphiques). Bien sûr, un simple fichier Excel peut suffire, mais l'accès partagé à un fichier Excel par toute l'équipe, en écriture et en consultation, est toujours problématique.

1. Historique

Le terme Scrum est emprunté au rugby et signifie mêlée. Ce processus s'articule en effet autour d'une équipe soudée, qui cherche à atteindre un but, comme c'est le cas en rugby pour avancer avec le ballon pendant une mêlée. En 1986, Hirotaka Takeuchi et Ikujiro Nonaka décrivent une nouvelle approche holistique qui augmenterait la vitesse et la flexibilité dans le développement commercial de nouveaux produits. Dans celle-ci les phases se chevauchent fortement et l'ensemble du processus est réalisé par une équipe aux compétences croisées à travers différentes phases. Ils ont comparé cette nouvelle approche au rugby, où l'équipe essaye d'avancer unie, en faisant circuler la balle. En 1991, DeGrace et Stahl font référence à cette approche comme Scrum (mêlée, en anglais), un terme de rugby mentionné dans l'article de Takeuchi et Nonaka. Dans le début des années 1990, Ken Schwaber a utilisé une approche qui a conduit à Scrum au sein de son entreprise. En même temps, Jeff Sutherland, John Scumniotales et Jeff McKenna développent une approche similaire à Easel Corporation et sont les premiers à appeler cela. En 1995, Sutherland et Schwaber ont présenté conjointement un document décrivant Scrum. Schwaber et Sutherland ont collaboré au cours des années suivantes pour fusionner les publications, leurs expériences et les meilleures pratiques du secteur en ce qui est maintenant connu comme Scrum. En 2001, Schwaber fait équipe avec Mike Beedle pour décrire la méthode dans le livre "Agile Software Development With Scrum". En France, le premier livre français entièrement consacré à Scrum est publié en février 2010 : "SCRUM : Le guide pratique de la méthode agile la plus populaire".

1. Méthodologie Scrum et Cycle de développement

Scrum utilise le progrès réel d'un projet et les projets sont divisés en parties succinctes de travail, appelées "sprints", qui sont généralement d'une durée de 1 à 4 semaines. À la fin de chaque sprint, les membres de l'équipe ainsi que les autres gens impliqués se rencontrent afin d'évaluer les progrès du projet et planifier les prochaines étapes. Ceci permet d'ajuster ou réorienter un projet selon l'évolution du travail et non des spéculations ou des prédictions. Chaque Sprint possède un but à atteindre, défini par le Directeur de produit, à partir duquel sont choisies les fonctionnalités à implémenter dans ce sprint, et dure au plus quatre semaines. Un sprint aboutit toujours sur la livraison d'un produit partiel fonctionnel. Pendant ce temps, le Scrum Master a la charge de réduire au maximum les perturbations extérieures et de résoudre les problèmes non techniques de l'équipe. Pendant un Sprint, des réunions quotidiennes de moins de 15 minutes (appelées Scrum) permettent à toute l'équipe de faire le point sur le travail accompli par chacun depuis la dernière réunion Scrum, les obstacles rencontrés, et le travail prévu d'ici la prochaine réunion. La méthodologie Scrum Agile apporte des rôles, responsabilités et réunions qui assurent le bon déroulement d'un projet.

1. Rôles

• Le propriétaire: Communique la vision du produit aux membres de l'équipe. Représente les intérêts du client via les besoins et la priorisation de ceux-ci. Il Possède la plus haute autorité des 3 rôles et aussi le plus de responsabilité. Lorsqu'un projet tourne mal, c'est vers lui que l'on pointe.
• Le Scrum Master : fait le pond entre l'équipe et le propriétaire. Il Ne gère pas l'équipe mais fait tout pour enlever les recueilles sur la route de l'équipe de développement afin d'atteindre les buts du sprint, aide l'équipe à demeurer productive et montre l'avancement au propriétaire. Indique aussi au propriétaire les façons d'optimiser le retour sur investissement pour l'équipe.
• Les membres de l'équipe : l'équipe idéale consiste de 7 membres provenant de disciplines différentes et plus ou moins 2 autres individus. Pour un projet d'application une équipe typique sera composée d'un amalgame d'ingénieurs, architectes, programmeurs, analystes, experts AQ, testeurs et designers d’Users Interface. À chaque sprint, l'équipe est responsable de déterminer comment s’accomplira le travail. Ceci offre une grande autonomie mais aussi la responsabilité d'atteindre ces buts pour le sprint. Durant chaque réunion, l'équipe et le propriétaire discutent de priorisation et des items en attente de développement. Les membres de l'équipe s'entendent sur le travail à faire et se crée une liste des tâches à effectuer durant le sprint.

1. COMPARAISON DE LA METHODE MERISE ET LES METHODES AGILES : SCRUM

Quand à Merise, son approche fonctionnelle propose une approche descendante où le système réel est décomposé en activités, elles-mêmes déclinées en fonctions. Les fonctions sont composées de règles de gestion, elles-mêmes regroupées en opérations. Ces règles de gestion au niveau conceptuel génèrent des modules décomposés en modules plus simples et ainsi de suite jusqu'à obtenir des modules élémentaires... Les limites d'une telle approche résident dans le fait que les modules sont difficilement extensibles et exploitables pour de nouveaux systèmes.

Mais par contre, Scrum utilise une approche fonctionnelle pour récolter les besoins des utilisateurs. L'objectif est d'établir une liste de fonctionnalités à réaliser, que l'on appelle backlog de produit (Le terme backlog peut être traduit par cahier, liste ou carnet de commandes, qui ne colle pas bien avec l'esprit du terme anglais qui évoque aussi une réserve, un retard accumulé ; aussi ce terme a été gardé tel quel). À chaque item de backlog sont associés deux attributs : une estimation en points arbitraires et une valeur client, qui est définie par le directeur de produit (retour sur investissement par exemple). Ce dernier définit dans quel ordre devront être réalisés ces items. Il peut changer cet ordre en cours de projet et même ajouter, modifier ou supprimer des items dans le backlog. La somme des points des items du backlog de produit constitue le reste à faire au reste du projet. Cela permet de produire un release burndown chart qui montre les points restant à réaliser au fur et à mesure des sprints.

En plus, Le schéma entité/association de Merise est un diagramme pour des descriptions de haut niveau de modèles conceptuels de données (MCD). L'entité est une association d'objets traduisant un réseau de relations de dépendance. Et une association est définie comme un lien sémantique de même nature reliant les occurrences de plusieurs entités donc elle définit des liens entre des types d'entité. Les associations sont caractérisées par des cardinalités. Le choix des cardinalités est essentiel et est aussi parfois discutable, et constitue donc l'aspect le plus délicat de la modélisation. Les cardinalités sont notées par deux chiffres. Le chiffre de droite est la cardinalité maximale, et celui de gauche est la cardinalité minimale. Mais cette dernière est moins importante que la cardinalités maximales.

Mais Scrum est un processus agile permettant de gérer et de contrôler le travail de développement et peut être utilisé pour intégrer des pratiques de génie logiciel existantes.

Enfin, il faut savoir qu’ils travaillent tous deux sur des concepts différents : Merise travaille sur un concept relationnel tandis que Scrum travail sur le concept de la qualité de l'environnement de travail de l'équipe.

1. Démarche de développement des systèmes d’information

1. Merise

La démarche de développement d un système d’information de Merise doit être conduite suivant trois axes appelés cycles dont le degré de prise en compte par les différentes méthodes oriente le choix de l’une d’entre elles en fonction des objectifs de l’étude : le cycle de vie : Il se situe sur une échelle de temps qui nous mène du point de départ à l’exploitation du système, en passant par sa création, sa maturité et sa maintenance. Le cycle de décision : Il représente l’ensemble des choix qui doivent être fait durant le déroulement du cycle de vie. Le cycle d’abstraction : C’est le découpage en ensembles homogènes de préoccupations. Il contient : le niveau conceptuel qui détermine les choix de gestion ; le niveau organisationnel qui détermine les choix d’organisation ; le niveau technique qui détermine les contraintes techniques ; la réalisation d’un système d’information est conduite au travers d’un projet décomposé en étapes s’appuyant sur les trois cycles définis précédemment :

• Le schéma directeur informatique : est un plan d’action à moyens termes reprenant l’ensemble des activités devant être menées dans le cadre de la mise en œuvre et du développement d’un système d’information.

• L’étude préalable par domaine : après avoir découpé le système d’information en domaines, la présente étape aboutit à la présentation générale du futur système de gestion en indiquant les principales motivations par rapport au système en vigueur, le coût, les avantages et les moyens matériels à mettre en œuvre.
• L’étude détaillée par projet : consiste à élaborer un cahier des charges qui est un document dans lequel le maitre d’ouvrages décrit les spécificités d’un travail, tout en y définissant les conditions techniques, financières et autres.
• La réalisation : qui consiste à mettre à la disposition des utilisateurs des programmes fonctionnant sur un jeu d’essai approuvé par ces derniers, en ajoutant à cela : la mise en œuvre et la maintenance.[1]

Les trois premières étapes correspondent à la partie conception du cycle de vie et les suivantes concernent la réalisation du système et son lancement. La méthodologie Merise s’intéresse plus particulièrement à cette partie conception.

1. Scrum

Le cycle de développement de Scrum repose sur une théorie moderne du contrôle des processus et permet d’élaborer de façon systématique les meilleurs logiciels possibles à partir des ressources disponibles, à un niveau de qualité acceptable et dans le respect des délais de livraison. Le cycle de vie Scrum s’articule en brèves itérations de développement appelées «Sprints». Scrum synchronise étroitement les exigences logicielles avec toute une série de prototypes itératifs. À la fin de chaque sprint, les membres de l'équipe ainsi que les autres gens impliqués se rencontrent afin d'évaluer les progrès du projet et planifier les prochaines étapes. Ceci permet d'ajuster ou réorienter un projet selon l'évolution du travail et non des spéculations ou des prédictions. Ci-dessous les étapes à suivre durant un Scrum : Création d'un carnet de commandes du produit: Le propriétaire et l'équipe se rencontrent afin de prioriser les items du carnet de commandes du produit. Le propriétaire doit être en mesure de formuler sa vision du produit. Réunion de planification de sprint. Création de la planification du sprint. Séparation et distribution des items du carnet entre les membres de l'équipe selon leur disponibilité. Début du sprint pour une durée de 1 à 4 semaines. Aucune autre tâche ne peut être ajoutée. Scrum journalier. Revue du sprint. Redémarrage du cycle. Ses projets sont contrôlés par la mise en place, l’actualisation et le suivi de paramètres de contrôle essentiels, qui forment l’ossature du processus Scrum.[2]

1. Les acteurs

Les acteurs d’un système sont les entités externes à ce système qui interagissent (saisie de données, réception d’information…) avec lui. Les acteurs sont donc à l’extérieur du système et dialoguent avec lui. Ces acteurs permettent de cerner l’interface que le système va devoir offrir à son environnement. Oublier des acteurs ou en identifier de faux conduit donc nécessairement à se tromper sur l’interface et donc la définition du système à produire.

Trois acteurs sont essentiels à un projet Scrum : Le product owner représente le client, disponible pour orienter l'équipe, il ordonne le travail en mettant à jour le product backlog. Le Scrum master protège de toutes perturbations la dynamique de l'équipe en solutionnant ses problèmes non techniques. L'équipe s'autogère sans hiérarchie interne. Il faut faire attention à ne pas confondre acteurs et utilisateurs (utilisateur avec le sens de la personne physique qui va appuyer sur un bouton) d’un système. D’une part parce que les acteurs inclus les utilisateurs humains mais aussi les autres systèmes informatiques ou hardware qui vont communiquer avec le système. D’autre part parce qu’un acteur englobe tout une classe d’utilisateur. Ainsi, plusieurs utilisateurs peuvent avoir le même rôle, et donc correspondre à un même acteur, et une même personne physique peut jouer des rôles différents vis-à-vis du système, et donc correspondre à plusieurs acteurs.

A l’opposé de Scrum, en Merise on distingue deux types d’acteurs : acteurs externes : éléments externes avec lesquels le système échange des flux d’information. Ex : clients, fournisseurs... Acteurs internes : acteurs faisant partie du système d’information étudié. Ex : guichet, service informatique... Ils sont représentés dans le MCC (Modèle Conceptuel de Communication) et dans le MCT (Modèle Conceptuel de Traitement).

1. Présentation des cycles d’abstraction de Merise et Scrum

1. Merise

Système d’information manuel

Expression des besoins

Modèle conceptuel de données

Modèle logique de données

Modèle physique des données

Système d’information automatisé

L’expression des besoins est une étape consistant à définir ce que l’on attend du système d’information automatisé, il faut pour cela : faire l’inventaire des éléments nécessaires au système d’information et délimiter le système en s’informant auprès des futurs utilisateurs.

Cela va permettre de créer le modèle conceptuel de la communication qui définit les flux d’informations à prendre en compte. L’étape suivante consiste à mettre au point le modèle conceptuel de données et le modèle conceptuel de traitement décrivant les règles et les contraintes à prendre en compte. Le modèle organisationnel consiste à définir le modèle organisationnel de traitement décrivant les contraintes dues à l’environnement. Le modèle logique de données représente un choix logiciel pour le système d’information.

Le modèle physique de données reflète un choix matériel pour le système d’information.[3

1. Scrum

Comme le montre le graphique ci-dessus, Scrum s'impose comme un modèle d'efficacité, prônant l'expression : "aller à l'essentiel". Voici donc ce qu'il faut pour mettre en place correctement une méthodologie Scrum efficace :

1. Equipe responsable, en auto-organisation : l'équipe de développement se doit d'être autonome pour palier aux éventuels changements d'un client trop indécis.
2. Avancement du produit par une série de « sprints » : les itérations sont courtes, 2 à 4 semaines au plus, pour permettre des interventions rapides en cas de problèmes.
3. Exigences définies : en fait d'exigences, on parlera surtout d'éléments à mettre en œuvre. Ces éléments sont regroupés sous l'appellation de "Backlog du produit".
4. Pas de prescription de pratiques d’ingénierie : on reste dans un esprit d'autonomie de développement.
5. Utilisation de règles génériques : on permet l'établissement d'un environnement agile propre au projet.[4]

2.4. Les points forts et faibles de deux méthodes

a) Les points forts et faibles de Merise

Pour petites bases de données, limitées à la troisième forme normale est généralement l’une des meilleures solutions du point de vue de l’architecture de base de données, mais pour les grandes bases de données, ce n’est pas toujours le cas. Il s’agit de choisir la balance entre deux options.

En d’autres termes, il ressort clairement de ces avantages et les inconvénients que l’arbitrage sera effectué sur le niveau de la normalisation sur la base des tables de la base de données sont priés de lire ou d’écrire plus. Si une table (base de données) est écrite plus en détail que de lire, il est préférable de normaliser autant que possible. Inversement, si une table (base de données) est plus largement lue et écrite, il peut être sage d’être moins strict sur le respect des normes afin d’améliorer les performances d’accès aux données.

Il faut être prudent lorsqu’on renonce à la forme normale. Il n’ya aucune garantie qu’une forme dénormalisée améliore le temps d’accès. En fait, la redondance peut provoquer une explosion des volumes de données qui peuvent réduire le rendement ou de saturer les disques durs.

La normalisation des modèles de données a été popularisé notamment par la méthode Merise. La principale limitation de la normalisation est que les données doivent être dans la même base de données (en un seul diagramme).

Même si les échanges et la consultation entre concepteurs et utilisateurs sont formellement organisés, on a aussi reproché à Merise d'utiliser un formalisme jugé complexe (surtout pour les modèles de données), qu'il faut d'abord apprendre à manier, mais qui constitue ensuite un véritable langage commun, puissant et rigoureux pour qui le maîtrise.

En outres, les limites de Merise sont telles que : elle est bien adaptée pour l’automatisation des tâches séquentielles de gestion pure. Toutefois, il est peu adapté pour les environnements distribués où plusieurs applications sont externes à un domaine d’interagir avec le modèle d’application. En d’autres termes, elle n’est pas en mesure de modéliser les données à caractère sémantique.

1. Les points forts et faibles de SCRUM

L'avantage des Méthodes Agiles réside avant tout dans le fait qu'elles mettent en avant une démarche plus pragmatique que les démarches traditionnelles, en impliquant au maximum le client, et en privilégiant la réalisation d'un produit véritablement opérationnel, et tout cela à moindre coût. Répondre au changement plutôt que suivre un plan préétabli, prendre en compte le fait que les conditions et les objectifs d'une entreprise puissent évoluer avec le temps, même pendant que se déroule le projet, correspond tout à fait à la vision de l'innovation, inhérente au développement des Méthodes Agiles. Un principe fort en Scrum est la participation active du client pour définir les priorités dans les fonctionnalités du logiciel, et pour choisir celles qui seront réalisées dans chaque sprint. Il peut à tout moment compléter ou modifier la liste des fonctionnalités à réaliser, mais jamais celles qui sont en cours de réalisation pendant un sprint.

Il est entièrement développé et testé pour de courtes itérations. Ses processus de développement sont très simples. Ses règles sont définies clairement. Augmentation de productivité. Organisation personnelle. Chaque équipe a son lot de responsabilité. Amélioration de la communication. Combinaison possible avec XP.

Ses points faibles sont tels que : il a peu, voire pas, de documentation écrite. Le gros problème réside bien souvent dans l'aspect documentation du projet. Comme la méthode privilégie le fonctionnel, on se retrouve rapidement avec des projets non-documentés. La mise en œuvre du développement n'est pas précisée, seule la gestion des ressources humaines qui compte. L'équipe ne se prête pas au Scrum. Il est clair que si l'équipe ne prend pas le temps de remplir correctement les indicateurs comme le Scrum Board et les Burndow Chart, le suivi n'est pas correctement assuré. D'autres parts on remarque bien souvent que dans la gestion du SCRUM, les manager sont tentés de passer outre les responsabilités hiérarchiques pour aller remonter le problème au sommet. On constate bien souvent ce problème dans des équipes ou un développeur requiert directement le client plutôt que son propre Scrum master, ou directeur de produit.

1. CONCLUSION

En définitive, nous avons vu comment modéliser un développement de systèmes d’information à l’aide de la méthode Merise. En effet, la méthode Merise nécessite une démarche par étape qui favorise la qualité de chaque modèle avec ses différents niveaux de validations. Par contre, Scrum est un processus de développement logiciel, introduit dont des règles pour suivre un processus itératif empirique permettant d'obtenir un produit très proche de besoins qui évoluent et ainsi de maximiser la valeur pour les clients. Mais aussi, Scrum est un processus idéal pour de petites équipes et tout le monde dans l’équipe est surveillé par un Scrum Master qui se doit non seulement d’interagir avec le projet mais aussi d’être réellement investie dans sa bonne réalisation.

En plus Scrum est une méthode à utiliser pour gérer le projet tandis que Merise est une méthode à utiliser pour analyser et concevoir le projet.

La différence principale est que Merise est une méthode d'analyse néanmoins Scrum aide l’équipe à détecter et à éliminer les obstacles entravant le développement et la livraison des produits et améliore la communication. Le développement de produits logiciels fait naître un chaos considérable qui se traduit par une grande incertitude et des comportements imprévisibles. Donc Scrum optimise la coopération et permet de contrôler le chaos dérivant d’intérêts et de besoins divergents.

[1] MISSWAY KINDIA J, support de cours de Technique de Base de données, cours de 3ème graduat, ISC/BDD, 2015-2016, (inédit)

[2] http://docplayer.fr/1637318-Introduction-3-iv-comparaison-merise-uml-scrum-14-1-approche-fonctionnelle-14-2-schema-entité-association-14-3-methodologie.html

[3] IBWAYO M’BEL A, Méthode d’Analyse Informatique II, cours de 3ème graduat, ISC-BDD, 2015-2016

[4] http://www.img.univ-mlv.fr/~dr/XPOSE2008/SCRUM/refs.php