Soutenance mémoire
HISTORIQUE ET SITUATION GEOGRAPHIQUE
Djago-International est une société de services informatiques burkinabé créée en 1999. Spécialisée dans la mise en œuvre de solutions de gestion informatisées, Djago-I est une société à responsabilité limitée avec un capital de 22.000.000 F CFA. Elle est située au secteur 30, lot 28, section PD, à la rue 30.21 côté Nord de Ouagarinter, derrière la Zone à Activités Diverses (ZAD). Djago-International a des représentations au Gabon, en Angola et en Guinée équatoriale. Depuis sa création, elle a développé des partenariats avec les prestigieux éditeurs mondiaux de logiciels dont le groupe SAGE et GB Concept.
Présentation d’UML
Historique et définition : Langage de modélisation visuel le plus utilisé pour construire les systèmes Orientés Objet, UML est le résultat en 1997 de la fusion des Concepts de trois méthodes:
• OMT (Object Modeling Technic) de Rumbaugh, 1991;
• OOD (Object Oriented Design) de G Booch, 1991 ;
• OOSE (Object Oriented Software Engineering) de Jacobson, 1991.
Sa première réussite fut d’être retenue comme norme de modélisation par l’OMG (Object Management Group), après avoir reçu le soutien de plusieurs grands constructeurs informatiques et éditeurs de logiciels. UML (Unified Modeling Language) est un langage pour visualiser, spécifier, construire et documenter les éléments d’un système logiciel.
Les diagrammes UML : Les diagrammes UML sont les éléments qui permettent de décrire les différents aspects d’un système. Ces diagrammes sont au nombre de treize10 (13) :
• le diagramme de classe : montre les classes du système avec leurs attributs et méthodes ainsi que les relations et dépendances;
• le diagramme d’objet : montre des graphes d’instances (objets) qui peuvent exister pendant l’exécution du système. Il sert à illustrer des structures de classes compliquées ; Pour une description commentée, voir [Bouzeghoud, 1997].
• les diagrammes de package : pour organiser les éléments de modélisation en groupe avec pour objectif de rendre les diagrammes plus simples et plus faciles à comprendre ;
• les diagrammes de structure composite : pour explorer les instances des classificateurs collaborant à travers des liens de communication ;
• les diagrammes de cas d’utilisation : montrent les utilisateurs et leurs interactions avec le système. Ils structurent les fonctionnalités offertes par le système ;
• les diagrammes de séquence : montrent les exemples d’historiques de communication entre les objets ou les utilisateurs ;
• les diagrammes de communication (collaboration) : sont une forme spéciale de diagramme d’objets enrichis avec des informations sur le flot des messages entre objets et sur la création /destruction des objets ;
• le diagramme global d’interaction (overview interaction) : une variante du diagramme d’activité qui donne une vue globale d’un flot de contrôle ;
• le diagramme de temps (timing diagram) : utilisé pour explorer le comportement d’un ou plusieurs objets pendant une période de temps donnée ;
• les diagrammes d’états des classes : utilisés pour modéliser l’état des données et leurs changements durant le cycle de vie des objets instances des classes du diagramme de classe ;
• les diagrammes d’activités : une forme spéciale du diagramme de transition d’états utilisés pour modéliser l’état du contrôle ;
• les diagrammes des composants : montrent la structure du code et son partitionnement en composants ;
• les diagrammes de déploiement : montre la structure de l’implémentation en exécution et la distribution des objets et des composants sur les nœuds physiques.
Avantage et inconvénient d’UML
De nombreuses raisons conduisent à préconiser l’utilisation d’UML. En effet UML présente l’avantage d’être le standard de la modélisation objet universellement reconnu. Il est un langage visuel. Sa notation graphique permet d’exprimer visuellement des solutions objet facilitant ainsi la comparaison et l’évaluation de celles-ci. C’est un langage formel et normalisé doté d’un gain de précision et d’un gage de stabilité. Il est aussi un support de communication performant car il cadre l’analyse tout en facilitant la compréhension des représentations abstraites complexes. En outre UML sert à formaliser tous les documents techniques d’un projet et permet d’affiner les détails de l’analyse au fur et à mesure de l’avancée du projet. Il est possible d’utiliser le même atelier de génie logiciel, depuis l’expression des besoins jusqu’à la génération de tout ou partie du code. Enfin il est indépendant des langages de programmation et des processus de développement. Cependant sa mise en pratique nécessite un apprentissage et passe par une période d’adaptation. De plus son intégration dans un processus n’est pas triviale et améliorer un processus est une tâche complexe et longue.
Caractéristique du processus unifié
Le processus unifié est un processus itératif, centré sur l’architecture, piloté par des cas d’utilisation et orienté vers la diminution des risques.
UP est itératif et incrémental L’itération est une répétition d’une séquence d’instructions ou d’une partie de programme un nombre de fois fixé à l’avance ou tant qu’une condition définie n’est pas remplie, dans le but de reprendre un traitement sur des données différentes. Elle qualifie un traitement ou une procédure qui exécute un groupe d’opérations de façon répétitive jusqu’à ce qu’une condition bien définie soit remplie. Chaque itération comporte des activités :
• l’expression des besoins : comme son nom l’indique, permet de définir les différents besoins :
– inventorier les besoins principaux et fournir une liste de leurs fonctions;
– recenser les besoins fonctionnels (du point de vue de l’utilisateur) qui conduisent à l’élaboration des modèles de cas d’utilisation ;
– appréhender les besoins non fonctionnels (techniques) et livrer une liste des exigences.
• l’analyse : son objectif est d’accéder à une compréhension des besoins et des exigences du client. Il s’agit de livrer des spécifications pour permettre de choisir la conception de la solution. Un modèle d’analyse livre une spécification complète des besoins issus des cas d’utilisation, et les structure sous une forme qui facilite la compréhension (scénarios), la préparation (définition de l’architecture), la modification et la maintenance du futur système. Il s’écrit dans le langage des développeurs et peut être considéré comme une première ébauche du modèle de conception ;
• la conception : permet d’acquérir une compréhension approfondie des contraintes liées au langage de programmation, à l’utilisation des composants et au système d’exploitation. Elle détermine les principales interfaces et les transcrit à l’aide d’une notation commune. Elle constitue un point de départ à l’implémentation car décompose le travail d’implémentation en sous-système et créée une abstraction transparente de l’implémentation ;
• l’implémentation : est le résultat de la conception pour implémenter le système sous forme de composants, c’est-à-dire, de code source, de scripts, de binaires, d’exécutables et d’autres éléments du même type. Les objectifs principaux de l’implémentation sont de planifier les intégrations des composants pour chaque itération, et de produire les classes et les sous-systèmes sous forme de codes sources.
• les Tests : permettent de vérifier des résultats de l’implémentation en testant la construction. Pour mener à bien ces tests, il faut les planifier pour chaque itération, les implémenter en créant des cas de tests, effectuer ces tests et prendre en compte le résultat de chacun.
UP est centré sur l’architecture : Une architecture adaptée est la clé de voûte du succès d’un développement. Elle décrit des choix stratégiques qui déterminent en grande partie les qualités du logiciel (adaptabilité, performances, fiabilité…).
• la vue logique : décrit les aspects dynamiques et statiques d’un système en termes de classes et d’objets et se concentre sur l’abstraction, l’encapsulation et l’uniformité. Elle identifie les éléments de domaine ainsi que les relations et interactions entre eux.
• la vue des processus : montre la décomposition du système en terme de tâches, les interactions entre les processus ;
• la vue de réalisation : est une vue de bas niveau appelée aussi vue des composants qui montre l’allocation des éléments de modélisation dans des modules (fichiers sources, bibliothèque dynamiques, bases de données, interfaces, etc.) ;
• la vue de déploiement : décrit les différentes ressources matérielles et la répartition du logiciel dans ces ressources ;
• la vue des cas d’utilisation : guide toutes les autres. Elle définit les besoins des clients du système et centre la définition de l’architecture du système sur la satisfaction (la réalisation) de ces besoins. A l’aide de scénarios et de cas d’utilisation, cette vue conduit à la définition d’un modèle d’architecture pertinent et cohérent.
UP est piloté par les cas d’utilisation : Le but principal d’un système informatique est de satisfaire les besoins du client. Le processus de développement sera donc axé sur l’utilisateur. Les cas d’utilisation permettent d’illustrer ces besoins. Ils détectent puis décrivent les besoins fonctionnels (du point de vue de l’utilisateur), et leur ensemble constitue le modèle de cas d’utilisation qui dicte les fonctionnalités complètes du système.
|
Table des matières
INTRODUCTION
CHAPITRE 1 PRESENTATION DU STAGE
1.1 PRESENTATION DE LA STRUCTURE D’ACCUEIL
1.1.1 HISTORIQUE ET SITUATION GEOGRAPHIQUE
1.1.2 L’ORGANISATION DE DJAGO-I
1.1.2.1 Le directeur général
1.1.2.2 Le directeur technique
1.1.2.3 La comptabilité
1.1.2.4 La gestion administrative du personnel
1.1.2.5 Le secrétariat
1.1.2.6 Le service marketing
1.1.3 LES RESSOURCES INFORMATIQUES EXISTANTES
1.2 PRESENTATION DU THEME
1.2.1 PROBLEMATIQUE
1.2.2 RESULTATS ATTENDUS
1.3 METHODE D’ANALYSE
1.3.1 PRESENTATION D’UML
1.3.1.1 Historique et définition
1.3.1.2 Les diagrammes UML
1.3.1.3 Avantage et inconvénient d’UML
1.3.2 PROCESSUS DE DEVELOPPEMENT
1.4 LES ACTEURS DU PROJET
1.4.1 LE GROUPE DE PILOTAGE
1.4.2 LE GROUPE DE PROJET
1.4.3 LE GROUPE DES UTILISATEURS
1.5 PLANNING PREVISIONNEL
CHAPITRE 2 ETUDE DE L’EXISTANT
2.1 EXPRESSION DES BESOINS
2.1.1 COMPTE RENDU DES INTERVIEWS
2.1.2 BESOINS EXPRIMES
2.2 ANALYSE
2.2.1 DIAGRAMME DE CAS D’UTILISATION
2.2.2 DIAGRAMME DE SEQUENCE
2.2.3 DIAGRAMME DE COLLABORATION
2.2.4 DIAGRAMMES DE CLASSE
2.3 BILAN CRITIQUE
CHAPITRE 3 ETUDE DES SCENARII
3.1 OBJECTIF DU FUTUR SYSTEME
3.2 RECONFIGURATION DU SYSTEME D’INFORMATION
3.3 ETUDE COMPARATIVE DES LOGICIELS PROPOSES
3.3. 1 LE SYSTEME DE GESTION DES BASES DE DONNEES RELATIONNELLES
3.3. 2 LANGAGES DE PROGRAMMATION
3. 3.3 ATELIER DE GENIE LOGICIEL (AGL)
3.3. 4 LES ANTI-VIRUS
3.4. ARCHITECTURE
3.4.1 SYMBOLES UTILISES
3.4.2 Architecture existante
3.5 METHODE DE CALCUL DU COUT DE REALISATION
3.5.1 PROJET DE MODE ORGANIQUE
3.5.2 PROJET DE MODE SEMI DETACHE
3.5.3 PROJET DE MODE EMBARQUE
3.6 PREMIER SCENARIO
3.6. 1 BESOINS MATERIELS
3.6. 2 BESOINS EN LOGICIELS
3.6. 3 EVALUATION DES COUTS
3.6. 4 CRITIQUE DU SCENARIO
3.7 DEUXIEME SCENARIO
3.7. 1 BESOINS MATERIELS
3.7. 2 BESOINS EN LOGICIELS
3.7. 3 EVALUATION DES COUTS
3.7. 4 CRITIQUE DU SCENARIO
3.8 SCENARIO RETENU
CHAPITRE 4 ETUDE DU FUTUR SYSTEME D’INFORMATION
4.1 PHASE D’ELABORATION
4.1.1 ACTIVITE D’EXPRESSION DES BESOINS
4.1.1.1 Diagramme de cas d’utilisation
4.1.1.2 Diagrammes de séquence
4.1.2 ACTIVITE D’ANALYSE
4.1.2.1 Diagramme de collaboration
4.1.2.2 Diagramme de classes
4.1.3 ACTIVITE DE CONCEPTION
4.1.3.1 Diagrammes d’activités
4.2 PROCEDURES TRANSITOIRES
4.3 POLITIQUE DE SECURITE
4.3.1 PROTECTION CONTRE LES CATASTROPHES
4.3.2 PROTECTION CONTRE LES VIRUS
4.3.3 PROTECTION CONTRE LES COUPURES D’ELECTRICITE
4.3.4 CONFIDENTIALITE DES DONNEES
4.4 PROCEDURES DE SECOURS
4.4.1 POSTE DE TRAVAIL INDISPONIBLE
4.4.2 PANNE DU SERVEUR
4.4.3 INDISPONIBILITE GENERALISEE DU SYSTEME
CHAPITRE 5 REALISATION
5.1 ENVIRONNEMENT TECHNIQUE
5.1.1 Enterprise Architect
5.1.2 Windev 10
5.2 PRESENTATION DES FONCTIONNALITES
5.2.1 LES FONCTIONNALITES DEVELOPPEES
5.2.2 LES INTERFACES
CHAPITRE 6 BILAN DU STAGE
6.1 ACQUIS PROFESSIONNELS
6.2 PERFECTIONNEMENTS TECHNIQUES
CONCLUSION
ANNEXES
7.1 LE PROCESSUS UNIFIE (UP)
7.1.1 DEFINITION
7.1.2 CARACTERISTIQUE DU PROCESSUS UNIFIE
7.1.3 LES PHASES DU PROCESSUS UNIFIE (UP)
7.1.4 LES AVANTAGES DU PROCESSUS UNIFIE
7.2 ORGANIGRAMMES
7.3 DIAGRAMME DES CAS D’UTILISATION
7.4 DIAGRAMME DE SEQUENCE
7.5 DIAGRAMME DE COLLABORATION
7.6 DIAGRAMME DE CLASSE
7.7 DIAGRAMME D’ACTIVITE
7.8 LA FISCALITE
7.9 IMPOT UNIQUE SUR LES TRAITEMENTS DE SALAIRE (IUTS)
7.9.1 CHAMP D’APPLICATION
7.10 TAXE SUR LA VALEUR AJOUTEE (TVA)
7.11 TAXE PATRONALE ET D’APPRENTISSAGE
7.11.1 CHAMP D’APPLICATION
7.11.1.1 Les rémunérations et les personnes soumises à la taxe
7.11.1.2 Les exonérations totales ou partielles
7.11.2 BASE D’IMPOSITION – LIQUIDATION – OBLIGATIONS ET SANCTIONS
7.11.2.1 Base d’imposition et Liquidation
7.11.2.1 Obligations et Sanctions
7.12 LES REGIMES D’IMPOSITION
7.12.1 REGIME DU REEL SIMPLIFIE D’IMPOSITION (RSI) ART. 23. DU CODE DES IMPOTS
7.12.2 REGIME NORMAL D’IMPOSITION (RNI)
7.13 METHODES D’ANALYSE
BIBLIOGRAPHIE
WEBOGRAPHIE
Télécharger le rapport complet
