Télécharger le fichier original (Mémoire de fin d’études)
METHODE D’ANALYSE ET DE CONCEPTION D’ UN SYSTEME D’INFORMATION
LE SYSTEME D’INFORMATION
Le système d’information est la partie du réel constituée d’informations organisées, d’évènement ayant un effet sur ces informations, etd’acteurs qui agissent sur ces informations ou à partir de ces informations, selon des processu s visant une finalité de gestion et utilisant les technologies d’informations.
Le système d’informatique est un ensemble organisé technique, matériel, logiciel, applicatifs dont la mise en œuvre réalise l’infrast ructure d’un système d’information et lui permet de fonctionner. [3] Figure 4 : Le système d’information et le système informatique
LES PRINCIPES DE BASE POUR MODELISER UN SYSTEME D’INFORMATION:
Trois principes généraux fondent le système d’information.
LE DECOUPAGE EN DOMAINES
Ce premier principe structure le cadre à l’intérieur duquel on va modéliser.
Décrire un système d’information d’entreprise revient à représenter son fonctionnement et son organisation sous l’angle des informations que l’on choisit de gérer et sur lesquelles qu’on s’appuie. Quand le système d’information est vaste, avec un nombre élevé de type d’informations et un nombre élevé d’acteurs ayant des rôles différents, il est nécessaire de le concevoir de façon modulaire :
• Pour mieux le comprendre;
• Pour maîtriser son développement;
• Pour permettre des évolution partielles, sans impact sur le reste.
L’APPROCHE PAR NIVEAU
Ce deuxième principe répartir les rôles, en ce qui concerne la modélisation, entre la maîtrise d’ouvrage et la maîtrise d’œuvre.
Ce principe â été étendu à la modélisation des systèmes d’information. On peut aussi distingués trois niveau de préoccupation :
• Le niveau conceptuel organisationnel est celui auquel on conçoit le système de gestion et d’organisation, c’est-à-dire ce que va f aire le système et comment on va l’utiliser.
• Le niveau logique est celui où l’on conçoit la solu tion informatique.
• Le niveau physique est celui où l’on développe la solution informatique dans un environnement donné.
LA DIVERSITE DU POINT DE VUE
Ce troisième principe aide pour gérer la complexité.
Un système d’information est souvent complexe, dans le sens où des éléments de natures différentes y sont entremêlés. Une des caractéristiques de la complexité d’un système est qu’on ne peut pas en rendre compte par une représentation unique ; on a besoin de plusieurs angles de vue, complémentaires et non disjoint.
Pour modéliser un système d’information, on recourt donc à plusieurs type de représentation : chacune est partielle et rend compte d’un aspect particulier. On adopte notamment un point de vue sur la structure statique du système, exposant les entités gérées, ainsi que d’autres points de vue montrant la structure dynamique, c’est-à-dire le fonctionnement du système.
LE ROLE DU MAITRE D’OUVRAGE
LE MAITRE D’OUVRAGE/ MAITRISE D’OUVRE
Les fonctions de maître d’ouvrage et de maître d’oeuvre sont liées à la volonté de contractualiser les relations dans le développement des projets systèmes d’information. Ces fonctions ne représentent pas des entités organisationnelles (services, directions, etc.), mais les rôles de ces entités dans le développement d’un projet.
La fonction de maître d’ouvrage peut être remplie directement par les directions fonctionnelles, les utilisateurs qui commandent l’ouvrage, ou bien par une maîtrise d’ouvrage dite « déléguée » qui assure l’interface entre l’utilisateur et le maître d’œuvre. Fréquemment, et notamment dans le cas où l’utilisateur assure lui-même la maîtrise d’ouvrage, une assistance à maîtrise d’ouvrage est sollicitée auprès d’un prestataire interne ou externe à l’entreprise. La responsabilité du maître d’ouvrage est totale du début du projet. [4]
En terme de collaborations, si le maître d’œuvre es t totalement autonome pour les étapes purement techniques du cycle de vie du projet (étude technique, réalisation, tests d’intégration, etc.), le maître d’ouvrage doit avoir l’assistance du maître d’oeuvre pour tout ce qui touche à l’aspect informatique (existant automatisé, solutions d’architecture technique, mais aussi mise en place d’environnement de recette, etc.).
LA VISION CONTRACTUELLE
La contractualisation des relations entre la maîtrise d’œuvre et la maîtrise d’ouvrage passe par l’établissement de règles concernant lesfournitures, les validations et le suivi des travaux.
Les fournitures peuvent être regroupées en trois catégories:
• Le plan des livraisons, qui est élaboré lors de lapassation du marché et affiné par la suite. I1 décrit 1es engagements réciproquesentre le client et le fournisseur en termes de produit à livrer où d’information à fournir ;
• Les fournitures relatives au domaine cible, qui sont celles pour lesquelles le client paie réellement (tout ou partie d’un applicatif d’études, documentation, plan de formation, etc.) ;
• Les fournitures relatives au domaine projet, qui permettent au client d’avoir une visibilité sur l’avancement des travaux.
L’EXPRESSION DES BESOINS :
Depuis plusieurs années, les méthodes incitent à dissocier les choix de gestion et d’organisation des choix techniques. L’expression des besoins est de ce fait du ressort du maître d’ouvrage. Elle passe par plusieurs étapes :
• Le recueil des besoins auprès des utilisateurs.
• L’établissement et le choix d’une solution globale.
• La mise en forme des besoins, afin qu’ils soient suffisamment précis et compréhensibles par le maître d’œuvre.
CHOIX DE METHODE UTILISEE ET PRESENTATION DE LA METHODE UML 2
LE CHOIX DE METHODE D’ANALYSE
Les méthodes d’analyse et de conception fournissent une méthodologie et des notations standard qui aident à concevoir des logic iels de qualité. Il existe différentes manières pour classer ces méthodes, dont :
• La distinction entre composition et décomposition :
Elle met en opposition d’une part les méthodes ascendantes qui consistent à construire un logiciel par composition à partir de modules exi stants, et, d’autre part, les méthodes descendantes qui décomposent récursivement le système jusqu’à arriver à des modules programmables simplement.
• La distinction entre fonctionnel (dirigée par le traitement) et orientée objet :
Dans la stratégie fonctionnelle (également qualifiée de structurée) un système est vu comme un ensemble hiérarchique d’unités en interaction, ayant chacune une fonction clairement définie. Les fonction disposent d’un éta local, mais le système a un état partagé, qui est centralisé et accessible par l’ensemble des fonctions. Les stratégies orientées objet considèrent qu’un système est un ensemble d’objets interagissant. Chaque objet dispose d’un ensemble d’attributs décrivant son état et l’état ud système est décrit (de façon décentralisée) par l’état de l’ensemble.
HISTORIQUE DES MODELISATIONS PAR OBJETS
Les méthodes utilisées dans les années 1980 pour ganiseror la programmation impérative (notamment MERISE) étaient fondées sura lmodélisation séparée des données et des traitements. Lorsque la programmation par objets prend de l’importance au début des années 1990, la nécessité d’une méthode qui lui soit adaptée devient évidente. Plus de cinquante méthodes apparaissent entre 1990 et 1995 (Booch, Classe-Relation, Fusion, OOSE, etc.).[5]
En 1994, le consensus se fait autour de trois méthodes :
OMT de James Rumbaugh (General Electric) fournit une représentation graphique des aspects statique, dynamique et fonctionnel d’un système;
OOD de Grady Booch, définie pour le Department of Defense, introduit le concept de paquetage (package);
OOSE d’Ivar Jacobson (Ericsson) fonde l’analyse sur la description des besoins des utilisateurs (cas d’utilisation, ou use case).
Unified Modeling Language est né par les efforts deconvergence de ces trois gourous qui régnaient chacun sur l’une des trois méthodes es mirent d’accord pour définir une méthode commune qui fédérerait leurs apports respectifs. En effet, et comme son nom l’indique, l’UML n’a pas l’ambition d’être exactement une méthode : c’est un langage.
LA DEMARCHE DE LA METHODE
La description de la programmation par objets a fait ressortir l’étendue du travail conceptuel nécessaire : définition des classes, deleurs relations, des attributs et méthodes, des interfaces. [6]
Pour programmer une application, il ne convient pas de se lancer tête baissée dans l’écriture du code : il faut d’abord organiser ses idées, les documenter, puis organiser la réalisation en définissant les modules et étapes dela réalisation. C’est cette démarche antérieure à l’écriture que l’on appelle modélisation ; son produit est un modèle.
Les spécifications fournies par la maîtrise d’ouvrage en programmation impérative étaient souvent floues : les articulations conceptuelles (structures de donnée, algorithmes de traitement) s’exprimant dans le vocabulaire de l’in formatique, le modèle devait souvent être élaboré par celle-ci. L’approche objet permet en principe à la maîtrise d’ouvrage de s’exprimer de façon précise selon un vocabulaire qui, tout en transcrivant les besoins du métier, pourra être immédiatement compris par lesnformaticiens.
UML 2.0 comporte ainsi treize diagrammes représentant autant de vues distinctes pour représenter des concepts particuliers du système d’information. Ils se répartissent en deux grands groupes :
Les diagrammes structures ou diagrammes statiques (UML Structure) :
• Diagramme de classes (Class diagram) ;
• Diagramme d’objets (Object diagram) ;
• Diagramme de composants (Component diagram) ;
• Diagramme de déploiement (Deployment diagram) ;
• Diagramme de paquetages (Package diagram) ;
• Diagramme de structures composites (Composite structure diagram).
• Diagramme comportementaux ou diagrammes dynamiques (UML Behavior) :
• Diagramme de cas d’utilisation (Use case diagram) ;
• Diagramme d’activité (Activity diagram) ;
• Diagramme d’état transitions (State machine diagram) ;
• Diagramme d’interaction (Interaction diagram) :
• Diagramme de séquence (Sequence diagram) ;
• Diagramme de communication (Communication diagram) ;
• Diagramme global d’interaction (Interaction overview diagram) ; Diagramme de temps (Timing diagram).
Ces diagrammes, d’une utilité variable selon les cas, ne sont pas nécessairement tout produits à l’occasion d’une modélisation. Les plus utiles pour la maîtrise d’ouvrage sont les diagrammes de cas d’utilisation, d’activités, de classes, d’objets, de séquence et d’états transitions. Les diagrammes de composants, de déploiement et de communication sont surtout utiles pour la maîtrise d’œuvre à qui ils permetten t de formaliser les contraintes de la réalisation et la solution technique.
LE CYCLE DE VIE D’UN LOGICIEL
Le « cycle de vie d’un logiciel » (en anglais software life cycle), désigne toutes les étapes du développement d’un logiciel, de sa conception à sa disparition. L’objectif d’un tel découpage est de permettre de définir des jalons intermédiaires permettant la validation du développement logiciel, c’est-à-dire il a conformité du logiciel avec les besoins exprimés, et la vérificationdu processus de développement, c’est-à-dire l’adéquation des méthodes mises en œuvre.
L’origine de ce découpage provient du constat que esl erreurs ont un coût d’autant plus élevé qu’elles sont détectées tardivement dans lerocessusp de réalisation. Le cycle de vie permet de détecter les erreurs au plus tôt et ainsi de maîtriser la qualitédu logiciel, les délais de sa réalisation et les coûts associés.
Le cycle de vie du logiciel comprend généralement minima les activités suivantes :
• Définition des objectifs, consistant à définir la finalité du projet et son inscription dans une stratégie globale.
• Analyse des besoins et faisabilité, c’est-à-dire l’expression, le recueil et la formalisation des besoins du demandeur (le client) et de l’ensemble des contraintes.
• Conception générale. Il s’agit de l’élaboration des spécifications de l’architecture générale du logiciel.
• Conception détaillée,consistant à définir précisément chaque sous-ensemble du logiciel.
• Codage (Implémentation ou programmation), soit la traduction dans un langage de programmation des fonctionnalités définies lors de phases de conception.
• Tests unitaires, permettant de vérifier individuellement que chaque sous-ensemble du logiciel est implémentée conformémentuxa spécifications.
• Intégration, dont l’objectif est de s’assurer de l’interfaçage des différents éléments (modules) du logiciel. Elle fait l’objet edtests d’intégrationconsignés dans un document.
• Qualification (ou recette), c’est-à-dire la vérification de la conformité du logiciel aux spécifications initiales.
• Documentation, visant à produire les informations nécessaires pour l’utilisation du logiciel et pour des développements ultérieurs.
• Mise en production,
• Maintenance, comprenant toutes les actions correctives (maintenance corrective) et évolutives (maintenance évolutive) urs le logiciel.
Nous allons voir les différents modèles de cycle devie d’un logiciel :
Le cycle de vie en cascade ; Le cycle de vie en V ;
Le cycle de vie en spirale. Et modèle par incrément.
LE CYCLE DE VIE EN CASCADE
Dans ce modèle de principe est très simple : chaque phase se termine à une date précise par la production de certains documents ou logiciels. Les résultats sont définis sur la base des interactions entre étape, ils sont soumis à une revue approfondie et on passe à la phase suivante que s’ils sont jugés satisfaisant.
LE CYCLE DE VIE EN SPIRALE
Ce modèle met l’accent sur l’activité d’analyse des risque : chaque cycle en spirale se déroule en quatre phases :
• La détermination, à partir des résultats des cycles précédents, ou l’analyse préliminaire des besoins, des objectifs du cycle, des alternatives pour les atteindre et des contraintes ;
• L’analyse des risques, évaluation des alternatives et, éventuellement maquettage ;
• Le développement et vérification de la solution retenue, un modèle
« classique »peut être utilisé ici ;
• La revue des résultats et vérification du cycle suivant.
LE MODELE PAR INCREMENT
Dans les modèles par incrément un seul ensemble decomposant est développé à la fois : des incréments viennent s’intégrer à un noyau de logiciel développé préalable. Chaque incrément est développé selon l’un des modèles prédentsc.
Les risques de ce type de modèle sont les suivants :
• Remettre en cause les incréments précédents ou pirele noyau ;
• Ne pas pourvoir intégrer de nouveaux incréments.
Les noyaux, les incréments ainsi que leurs interactions doivent donc être spécifiés globalement, au début du projet. Les incréments doivent être aussi indépendants que possibles, fonctionnellement mais aussi sur le plan du calendrier du développement.
Table des matières
INTRODUCTION
PREMIERE PARTIE: GENERALITE DU MINISTERE SANTE ET LE SERVICE DE DISTRICT DE LA SANTE PUBLIQUE A TOAMASINA
CHAPITRE I : LE MINISTERE DE LA SANTE PUBLIQUE ET LE SERVICE DE DISTRICT DE LA SANTE PUBLIQUE A TOAMASINA I
SECTION I : LE MINISTERE DE LA SANTE
§1 : LES 7 PRIORITES DU MINISTERE DE LA SANTE PUBLIQUE
§2- L’ORGANIGRAMME DU MINISTERE DE LA SANTE PUBLIQUE
A. A L’ECHELON CENTRAL
1) Cabinet du Ministre
a) Directeur de Cabinet
b) Membre de Cabinet
c) Structures rattachées
2) Secrétariat Générale (SG)
a) Institut, Organisme et Etablissement Publics spéciaux rattachés
b) Directions rattachées
c) Services spécialement rattachés
3) Direction Générale de la Santé (DGS)
a) Directions rattachées
b) Services spécialement rattachés
B. A L’ECHELON DES REGIONS ET DES DISTRICTS
1) Direction Régionale de la Santé Publique (DRSP)
a) Service Composants
b) Centre Rattaché
c) Institut rattaché
2) Service de District de la Santé Publique (SDSP)
a) Bureau de Santé de District (BSD) :
b) Centre rattachés
SECTION II : L’HISTORIQUE DU SERVICE DE DISTRICT DE LA SANTE PUBLIQUE DE TOAMASINA I
§1-L’HISTORIQUE
§2-LOCALISATION
A. LOCALISATION GEOGRAPHIQUE
B. PLAN DE MASSE
C. LES FONCTIONS DE SDSP
1) Le Médecin inspecteur
2) L’adjoint administratif
3) L’adjoint technique
4) L’EMAD
D. LES NOMINATIONS ET LES DIRECTEURS SUCCESSEURS
E. L’ORGANIGRAMME DE SDSP A TOAMASINA I
F. LA GESTION DES MATERIELS AU SDSP ET LA COMPTABILITE MATIERE
1) La définition de la comptabilité des matières
2) Les Objectifs de la Comptabilité des matières
3) Le Principe fondamental de la tenue de la comptabilité des matières
4) La tenue de la comptabilité matières
5) Les documents de comptabilité matières
6) Les acteurs de la comptabilité matières
a) L’ordonnateur en matières
b) Le comptable en matières
c) Le comptable auxiliaire
d) Les diverses commissions
SECTION III : L’ETUDE PREALABLE
§1-L’ETUDE DE L’EXISTANT
A. LA PRESENTATION GENERALE DU DOMAINE
B. LA PROBLEMATIQUE
§2-LE CRITIQUE DE L’EXISTANT
A. LA DEFINITION DES OBJECTIFS
B. LA CONFIGURATION DE MATERIEL INFORMATIQUE
C. LE RECUEIL DES INFORMATIONS
CHAPITRE II : METHODE D’ANALYSE ET DE CONCEPTION D’UN SYSTEME D’INFORMATION
SECTION I : LE SYSTEME D’INFORMATION
§1-LE SYSTEME D’INFORMATION
§2-LES PRINCIPES DE BASE POUR MODELISER UN SYSTEME D’INFORMATION
A. LE DECOUPAGE EN DOMAINES
B. L’APPROCHE PAR NIVEAU
C. LA DIVERSITE DU POINT DE VUE
§3-LE ROLE DU MAITRE D’OUVRAGE
A. LE MAITRE D’OUVRAGE/ MAITRISE D’OUVRE
B. LA VISION CONTRACTUELLE
C. L’EXPRESSION DES BESOINS
SECTION II : CHOIX DE METHODE UTILISEE ET PRESENTATION DE LA METHODE UML 2
§1-LE CHOIX DE METHODE D’ANALYSE
§2-HISTORIQUE DES MODELISATIONS PAR OBJETS
§3-LA DEMARCHE DE LA METHODE
§4-LE CYCLE DE VIE D’UN LOGICIEL
A. LE CYCLE DE VIE EN CASCADE
B. LE CYCLE DE VIE EN V
C. LE CYCLE DE VIE EN SPIRALE
D. LE MODELE PAR INCREMENT
§5-LES AVANTAGES ET INCONVENIENTS DE LA METHODE UML
A. LES AVANTAGES
B. LES INCONVENIENTS
§6-OUTILS D’ANALYSE ET CONCEPTION
A. WIN DESIGN
B. RATIONAL ROSE
C. VISUAL PARADIGM
DEUXIEME PARTIE LE SYSTEME D’INFORMATION SUR LA GESTION DES MATERIELS TECHNIQUES ET DE BUREAUX
CHAPITRE I : LA CONCEPTION DETAILLEE
SECTION I: DIAGRAMME DE CAS D’UTILISATION
§1-INTRODUCTION
§1-LES CONCEPTS DE BASE
A. LES ELEMENTS DE DIAGRAMME DE CAS D’UTILISATION
1) L’acteur
2) Le cas d’utilisation
B. LES RELATIONS DANS LE DIAGRAMMES DE CAS D’UTILISATION
1) Relation entre acteur et cas d’utilisation
a) Relation entre cas d’utilisation
2) Relation entre acteur
C. LES REGLES DE GESTION DES MATERIELS
D. LA CONSTRUCTION DU DIAGRAMME DE CAS D’UTILISATION
1) L’Identification des acteurs
2) La description textuelle de cas d’utilisation
SECTION II : LE DIAGRAMME DE CLASSES (Class Diagram)
§1-L’INTRODUCTION
§2-LES CONCEPTS DE BASE
A. LES ELEMENTS DES DIAGRAMMES DE CLASSES
1) Les classes
2) Les relations entre classes
a) Notion d’association
b) Terminaison d’association
c) Association binaire et n-aire
d) Multiplicité ou cardinalité
e) Navigabilité
f) Qualification
g) Classe association
h) Agrégation et composition
i) Généralisation et héritage
j) Dépendance
3) L’implémentation en SQL
a) Classe avec attributs
b) Association 1 vers 1
c) Association 1 vers plusieurs
d) Association plusieurs vers plusieurs
e) Class association plusieurs vers plusieurs
4) Diagramme d’objets
5) Elaboration et implémentation d’un diagramme de classes
B. LA CONSTRUCTION DU DIAGRAMME DE CLASSE
SECTION III : LE DIAGRAMME D’ETAT-TRANSITION (State machine diagram)
§1- INTRODUCTION
§2- LE CONCEPT DE BASE
A. LE FORMALISME
B. L’ETAT
C. LA TRANSITION
D. LA CONSTRUCTION DU DIAGRAMME D’ETAT-TRANSITION
SECTION IV : LE DIAGRAMME D’ACTIVITES (Activity diagram)
§1-L’INTRODUCTION
§2-LE CONCEPT DE BASE
A. LE FORMALISME
B. L’ACTIVITE ET LA TRANSITION :
1) Les actions
2) Une activité
3) Les noeuds d’activités
4) Les noeuds de contrôles
5) La transition
C. LES REGLES D’ORGANISATION
D. LA CONSTRUCTION DU DIAGRAMME D’ACTIVITE
SECTION V : LE DIAGRAMME DE SEQUENCE
§1-LA REPRESENTATION DES LIGNES DE VIE
§2-LA REPRESENTATION DES MESSAGES
§3-LA REPRESENTATION GRAPHIQUE DU DIAGRAMME DE SEQUENCE
CHAPITRE II : L’IMPLEMENTATION ET LA REALISATION
SECTION I : L’IMPLEMENTATION (LE CHOIX DU SYSTEME DE GESTION DE BASE DE DONNEES : MySQL)
§1-DEFINITION DU SYSTEME DE GESTION DE BASE DE DONNEES
§2-LA PRESENTATION DU SGBD
§3-LE FONCTIONNALITE DU SGBD
§4-LA COMPOSITION DE LA SGBD
SECTION II : LA REALISATION
§1-ETAPE DE CREATION D’UNE BASE DE DONNEES AVEC PHP MYADMI
A. LA DEFINITION DE LANGAGE DE SCRIPT (PHP)
1) SQL est un langage de définition des données
2) SQL est un langage de manipulation de données
3) SQL est un langage de protection d’accès
B. LA CREATION DE LA BASE DE DONNEES
C. LES CARACTERISTIQUE DU PHP
1) L’interprétation du code
2) Les commentaires
3) La typologie
D. L’IMPLEMENTATION DU CODE PHP
1) L’interprétation du code par le serveur
2) L’implantation au sein du code HTML
§2-CONNEXION A LA BASE DE DONNEES DEPUIS PHP
§3-PRESENTATION DE LA BASE DE DONNEES
A. L’ARCHITECTURE DU MENU GENERAL
B. LA PRESENTATION DE L’APPLICATION
SECTION III : L’AMELIORATION MENEE APRES LA REALISATION D’AUTOMATISATION DE GESTION DES MATERIELS
§1-EVALUATION DES COUTS
§2-EVALUATIONS DES AVANTAGES
A. LA FIABILITE SUR LA REALISATION DES TACHES
B. LA RECHERCHE DES INFORMATIONS CONSERNANT LES MATERIELS RAPIDE
C. LA SIMPLIFICATION DU TRAVAIL
1) Les améliorations physiologiques
2) Les améliorations technologiques
CONCLUSION
BIBLIOGRAPHIE
ANNEXE I : ENCEINTE DE SDSP TOAMASINA
ANNEXE II : CODE EN PHP POUR AFFICHER LA SAISIE MOUVEMENT DE MATERIELS
ANNEXE III : ORDRE D’ENTREE
ANNEXE IV : ORDRE SORTIE
ANNEXE V : INVENTAIRE DU MOBILIER ET DES OBJETS
ANNEXE VI : INVENTAIRE DE MATERIEL
LISTE DES FIGURES ET DES TABLEAUX
