Développement d'une application web pour l'optimisation du processus d'archivage et d'accès aux données d'une entreprise. Cas de Bell Equipement.

CONCLUSION

L'étude préalable appelée techniquement ingénierie des exigences ou analyse et spécification des besoins, constitue une phase capitale dans le cas où toute la suite du projet dépend d'elle, elle doit être faite avec beaucoup de rigueur et plus d'attention pour que le projet réussisse avec un grand succès.

Dans ce chapitre, on a exposé les problèmes de la société et de l'existant, puis nous avons fait les critiques sur la façon actuelle d'archiver les données et enfin on a fait une approche de solution qui consiste à concevoir et à développer une application qui facilitera les services énumérés précédemment.

Après avoir fixé nos objectifs, pour atteindre notre but on doit suivre plusieurs étapes ces dernières constituent une partie du cycle de vie de tout projet informatique. Ainsi dans l'étape suivante on va se consacrer sur le choix des méthodes et outils de la réalisation.

Chapitre III. CONCEPTION

INTRODUCTION

La plupart des nouveaux langages sont orientés objet. Le passage de la programmation fonctionnelle à l'orienté objet n'était pas facile. L'un des soucis était d'avoir une idée globale en avance de ce qu'on doit programmer.

L'algorithmique qui était utilisé dans la programmation fonctionnelle ne pourrait pas suffire à lui seul. Le besoin d'avoir des méthodes ou langages pour la modélisation des langages orientés objet se faisait sentir. Ainsi plusieurs méthodes ou langages ont vu le jour. En occurrence UML qui nous a permis de faire la conception de notre application.

UML (Unified Modeling language) se définit comme un langage de modélisation graphique et textuel destiné à comprendre et décrire des besoins, spécifier et documenter des systèmes, esquisser des architectures logicielles, concevoir des solutions et communiquer des points de vue^15(*).

De nos jours UML2 possède treize diagrammes qui sont classés en deux catégories: les diagrammes structurels (dynamique) et les diagrammes comportementaux (statique). L'utilisation de ces treize diagrammes est laissée à l'appréciation de tout un chacun selon la méthode choisie, cela, même si le diagramme de classe est souvent considéré comme le point central dans un développement orienté objet^16(*).

Nous avons appliqué les principes de la méthode agile choisie en essayant de modéliser 80% du problème avec seulement 20% d'UML.

III.1. PRESENTATION DE LA METHODE UTILISEE

Pour l'analyse et la conception du nouveau système, nous avons fait recours à la démarche ou processus agile dite de 80/20, qui utilise la notation UML, c'est-à-dire modéliser 80% du problème en utilisant 20% d'UML.

La notion de méthode agile est née à travers un manifeste signé en 2001 par 17 personnalités du développement logiciel^17(*). Ce manifeste prône quatre valeurs fondamentales :

· « Personnes et interactions plutôt que processus et outils » : dans l'optique agile, l'équipe est bien plus importante que les moyens matériels ou les procédures.

· « Logiciel fonctionnel plutôt que documentation complète » : il est vital que l'application fonctionne. Le reste, et notamment la documentation technique, est secondaire, même si une documentation succincte et précise est utile comme moyen de communication.

· « Collaboration avec le client plutôt que la négociation du contrat » : le client doit être impliqué dans le développement. On ne peut se contenter de négocier un contrat au début du projet, puis de négliger les demandes du client.

· « Réagir au changement plutôt que suivre un plan » : la planification initiale et la structure du logiciel doivent être flexibles afin de permettre l'évolution de la demande du client tout au long du projet.

Cette méthode se situe à mi-chemin entre UP (Unified Processus «processus unifié»), un cadre générale très complet des processus de développement, et XP (eXtreme Programming), une approche minimaliste centrée sur le code.

Avec cette méthode, nous n'utilisons pas les treize types de diagrammes proposés par UML 2, mais seulement un tiers, en insistant particulièrement sur les diagrammes de classes et le diagramme de séquence. Cette limitation volontaire ne diminue en rien la puissance de la démarche, mais, elle nous permet une réduction significative du temps d'apprentissage de la modélisation avec UML, tout en restant largement suffisante pour une bonne modélisation de notre système.

Pour ce faire, on va commencer par les diagrammes de cas d'utilisation (Use Case) qui permet de donner une vue globale de l'application. Pas seulement pour un client non avisé qui aura l'idée de sa future application mais aussi le développeur s'en sert pour le développement des interfaces.

En deuxième lieu on va présenter la chronologie des opérations par les diagrammes de séquences.

Et finir par les diagrammes statiques, qui sont celles de classe de conception, de classe participantes et le modèle physique.

* ¹⁵ Pascal ROQUES, UML pour le web. P.4

* ¹⁶ Idem, P.5

* ¹⁷ Pascal Roque, op.cit., P.12