|
Dédicace
fi ,rait ?ère /4~,r~ss~ Laz4ae,
fi ,r~ ,rèee
c,r~e J~ititette,
fi ,rait leèee et ,res soues,
Puisse ee ,raceste
~?useu~e te~upee reee ti aes teu".
Remerciements
Je tiens à présenter mes remerciements à
Mr. Mahdi Walid mon encadreur à l'Institut Supérieur
d'Informatique et de Multimédia de Sfax (ISIMS) pour le soutien et
l'aide permanente qu'il n'a cessé de m'apporter. J'exprime envers lui
tous mes sentiments de gratitude et de reconnaissance.
Je tiens à présenter mes remerciements
également à mes encadreurs au département des produits et
d'assistance du Centre National d'Informatique de Tunis (CNI) Mr. Ben Atalah
Mohamed & Mr Sboui Fayçal pour m'avoir accueillie, veillé au
bon déroulement de mon stage, et les efforts qu'ils ont fournis pour la
réussite de ce projet. Ainsi, que tout le personnel de la CNI.
Mes vifs remerciements s'adressent également à tous
mes enseignants de l'ISIMS pour tous les services qu'ils m'ont rendus.
Merci enfin à tous mes collègues d'études de
l'ISIMS d'avoir donné un second souffle à mon travail.
Sommaire
Dédicaces
Remerciements
Introduction générale
1 Etude préalable 1
1.1 Introduction 1
1.2 Présentation du centre national d'informatique 1
1.2.1 Missions et services 2
1.2.2 Ressources 2
1.3 La problématique 3
1.4 Processus qualité 4
1.4.1 Système de Management de la Qualité 4
1.4.2 La démarche « Système de Management de
la Qualité » 4
1.4.3 Principes du Management de la Qualité 5
1.4.4 Les 5 « M » d'un processus Qualité 5
1.4.5 Les 3 types de processus qualité 6
1.5 Démarche de développement 7
1.5.1 Présentation d'UP 7
1.5.2 Les principes d'UP 7
1.5.3 Les phases d'UP 8
1.5.4 Démarche de développement adoptée
9
1.6 Conclusion
.........................................................................................................................................
11
2 Etude du processus « installation et livraison des
produits » 12
2.1 Modélisation métier 12
2.1.1 Elaboration du schéma de contexte du sous domaine
d'étude 12
2.1.2 Elaboration du diagramme d'activité 13
2.1.3 Elaboration du diagramme de classe métier 14
2.2 Exigences fonctionnelles 15
2.2.1 Elaboration du diagramme des cas d'utilisation
système 15
2.3 Analyse des cas d'utilisation 16
2.3.1 Raffinement du diagramme des cas d'utilisation
système 16
2.3.2 Description textuelles des cas d'utilisation 17
2.3.3 Elaboration du schéma de navigation
générale 23
2.4 Conception 24
2.4.1 Elaboration des diagrammes techniques 24
3 Etude du processus « Déploiement » 39
3.1 Modélisation métier 39
3.1.1 Elaboration du schéma de contexte du domaine
d'étude 39
3.1.2 Elaboration du diagramme d'activité 40
3.1.3 Elaboration du diagramme de classe métier 41
3.2 Exigences fonctionnelles 43
3.2.1 Elaboration du diagramme des cas d'utilisation
système 43
3.3 Analyse des cas d'utilisation 44
3.3.1 Raffinement du diagramme des cas d'utilisation 44
3.3.2 Description textuelles des cas d'utilisation 45
3.3.3 Elaboration du schéma de navigation
générale 49
3.4 Conception 50
3.4.1 Elaboration des diagrammes techniques 50
4 Synthèse de l'analyse 54
4.1 Diagramme de classe récapitulatif 54
4.2 Schéma de navigation de synthèse 55
4.3 Diagramme de déploiement 56
4.4 Technologie choisie 56
5 Réalisation 57
5.1 Environnement de réalisation 57
5.1.1 Environnement matériel 57
5.1.2 Environnement logiciel 57
5.2 Implémentation de la base de donnée 60
5.2.1 Modèle physique de données 61
5.3 Enchainement des interfaces graphiques 62
5.3.1 Connexion 62
5.3.2 Espace administrateur 63
5.3.3 Espace responsable application 66
5.3.4 Espace Equipe Mobile 71
5.4 Test de l'application 71
Conclusion
Bibliographie
URL utiles
Tables des figures
Figure 1- Schéma détaillé de la
démarche de développement
............................................................ 10
Figure 2 - Schéma de contexte du sous domaine
d'étude (processus installation et livraison) .............12
Figure
3 - Diagramme d'a ctivité
...........................................................................................................
13
Figure 4 - Diagramme de classe métier
.................................................................................................
14
Figure 5 - Diagramme des cas d'utilisation système
.............................................................................
15
Figure 6 - Diagramme des cas d'utilisation
...........................................................................................
16
Figure 7 - Schéma de navigation générale
............................................................................................
23
Figure 8 - Diagramme de séquence du CU Authentification
................................................................ 24
Figure 9 - Diagramme de classe du CU Authentification
..................................................................... 24
Figure 10 - Diagramme de séquence du CU Créer utilisateur
............................................................... 25
Figure 11 - Diagramme de classe du CU Créer utilisateur
.................................................................... 25
Figure 12 - Diagramme de séquence du CU Modifier utilisateur
......................................................... 26 Figure 13 -
Diagramme de classe du CU Modifier utilisateur
.............................................................. 26 Figure
14 - Diagramme de séquence du CU Supprimer Utilisateur
...................................................... 27 Figure 15 -
Diagramme de classe du CU Supprimer Utilisateur
........................................................... 27
Figure 16 - Diagramme de séquence du cas d'utilisation
saisir bon de commande interne................... 28
Figure 17 - Diagramme de classe du CU Saisir BCI
.............................................................................
28 Figure 18 - Diagramme de séquence du CU Modifier BCI
................................................................... 29
Figure 19 - Diagramme de classe du CU Modifier BCI
........................................................................
29 Figure 20 - Diagramme de séquence du CU Consulter BCI
................................................................. 30
Figure 21 - Diagramme de classe du CU Consulter BCI
......................................................................
30 Figure 22 - Diagramme de séquence du CU Vérifier Prés
requis ......................................................... 31
Figure 23 - Diagramme de classe du CU Vérifier Prés requis
.............................................................. 31 Figure
24 - Diagramme de séquence du CU Ajouter Formation
........................................................... 32 Figure 25
- Diagramme de classe du CU Ajouter Formation
................................................................ 32
Figure 26 - Diagramme de séquence du cas CU Modifier Formation
................................................... 33 Figure 27 -
Diagramme de classe du CU Modifier Formation
.............................................................. 33 Figure
28 - Diagramme de séquence du CU Consulter Formation
....................................................... 34 Figure 29 -
Diagramme de classe du CU Consulter Formation
............................................................ 34
Figure 30 - Diagramme de séquence du CU Suivre
l'installation des produits ..................................... 35
Figure 31 - Diagramme de classe du CU Suivre l'installation des produits
.......................................... 35 Figure 32 - Diagramme de
séquence du CU Ajouter bon de livraison
.................................................. 36 Figure 33 -
Diagramme de classe du CU Ajouter bon de livraison
....................................................... 36 Figure 34 -
Diagramme de séquence du CU Modifier BL
.................................................................... 37
Figure 35 - Diagramme de classe du CU modifier BL
..........................................................................
37
Figure 36 - Diagramme de séquence du CU Consulter bon de
livraison .............................................. 38
Figure 37
- Diagramme de classe du CU Consulter bon de livraison
................................................... 38
Figure 38 - Schéma de contexte du sous domaine
d'étude (Processus déploiement) .........................
39
Figure 39 - Diagramme d'activité
..........................................................................................................
40
Figure 40 - Diagramme de classe métier
...............................................................................................
41
Figure 41 - Diagramme des cas d'utilisation système
...........................................................................
43
Figure 42 - Diagramme des cas d'utilisation 44
Figure 43 - Schéma de navigation générale
49
Figure 44 - Diagramme de séquence du CU Gérer
convention 50
Figure 45 - Diagramme de classe du CU Gérer convention
50
Figure 46 - Diagramme de séquence du CU Gérer bon
d'Intervention 51
Figure 47 - Diagramme de classe du CU Gérer bon
d'intervention 51
Figure 48 - Digramme de séquence du CU Gérer fiche
mise en service 52
Figure 49 - Diagramme de classe du CU Gérer fiche mise en
service 52
Figure 50 - Diagramme de séquence du CU Gérer PV de
réception 53
Figure 51 - Diagramme de classe du CU Gérer PV de
réception 53
Figure 52 - Diagramme de classe récapitulatif 54
Figure 53 - Schéma de navigation de synthèse 55
Figure 54 - Diagramme de déploiement 56
Figure 55 - Modèle physique de données 61
Figure 56 - Interface Connexion 62
Figure 57 - Interface Erreur d'authentification 62
Figure 58 - Interface Ajout d'un nouvel utilisateur (1/2) 63
Figure 59 - Interface Ajout d'un nouvel utilisateur (2/2) 63
Figure 60 - Interface mise à jour d'un utilisateur (1/3)
64
Figure 61 - Interface mise à jour d'un utilisateur (2/3)
64
Figure 62 - Interface mise à jour d'un utilisateur (3/3)
64
Figure 63 - Interface Suppression d'utilisateurs (1/2) 65
Figure 64 - Interface Suppression d'utilisateurs (2/2) 65
Figure 65 - Interface Ajout bon de commande interne 66
Figure 66 - Interface consultation des bons de commande 66
Figure 67 - Interface Vérification des pré-requis
(1/2) 67
Figure 68 - Interface Vérification des pré-requis
(2/2) 67
Figure 69 - Interface Ajout d'une formation 68
Figure 70 - Interface Consultation des formations 68
Figure 71 - Interface suivie installation des applications (1/2)
69
Figure 72 - Interface suivie installation des applications (2/2)
69
Figure 73 - Interface ajout bon de livraison 70
Figure 74 - interface ajout d'une convention 70
Figure 75 - Interface espace équipe mobile 71
Introduction générale
Un processus métier est une séquence
ordonnée et chronologique des taches destinées à produire
un résultat à valeur ajoutée pour le client ainsi que les
employés de l'organisation. Cette notion a été toujours
présente quelque soit la taille de la structure organisationnelle de
l'entreprise.
L'objectif de la gestion des processus métiers est de
rendre l'entreprise efficace, flexible et compétitive tout en produisant
des biens et des services de qualité à moindre coût. Ainsi
l'intégration d'un système de gestion de la qualité a
comme objectif de proposer un moyen d'amélioration efficace et continue
des résultats produits en conformité aux attentes des clients. La
réussite de sa mise en oeuvre dépend essentiellement de la
flexibilité des processus opérationnel de l'organisation.
Dans ce contexte, et pour atteindre les objectifs
déjà recensés, le département des produits et
d'assistance du centre national d'informatique de Tunis, suite à la mise
en place d'un système de gestion de la qualité envisage
développer et mettre en place un système de suivi des processus
qualité.
Le projet consiste à faire le suivi de deux processus :
« processus installation et livraison des produits » et «
processus déploiement », et donc de développer une
application recouvrant toutes les activités de ces deux processus. Pour
ce faire, nous avons étudié et analysé chaque processus
à part en appliquant une méthodologie de développement
logiciel qui se base sur le processus unifié et sur le langage de
modélisation unifié « UML », ensuite nous avons
réalisé une synthèse de l'étude en choisissant J2EE
comme technologie, puis l'implémentation de la base de donnée en
utilisant MySQL comme système de gestion de base de données
relationnel et enfin le codage, l'implémentation et le test de
l'application.
Ce rapport de projet de fin d'études s'organise en cinq
chapitres : le premier chapitre intitulé « étude
préalable » englobe la présentation du centre national
d'informatique de Tunis, la notion du processus qualité, la
problématique et enfin la démarche de développement
logiciel adoptée.
Les chapitres 2 et 3 présentent une étude
complète des deux processus respectivement le processus installation et
livraison des produits et le processus déploiement en appliquant la
démarche de développement déjà décrit dans
le premier chapitre.
Le chapitre 4 est une synthèse de l'analyse de la
conception des deux processus. Le chapitre 5 couvre la phase de
réalisation de l'application.
1 Etude préalable
1.1 Introduction
Dans ce chapitre, nous présentons le Centre National
d'informatique, organisme d'accueil où s'est déroulé mon
stage, la problématique, ainsi que la notion des processus
qualité tout en mettant l'accent sur leur importance, et enfin, la
démarche de développement adoptée.
1.2 Présentation du centre national
d'informatique
Le Centre National d'Informatique CNI a été
créé le 30 décembre 1975 par la Loi n° 75- 83 du 30
décembre 1975- Articles 35 à 42, en tant qu'établissement
public à caractère industriel et commercial.
Le CNI est un établissement public à
caractère non administratif, doté de la personnalité
civile et de l'autonomie financière.
Il fut rattaché au premier ministère avant
d'être placé sous la tutelle du ministère des technologies
de la communication.
Etant un des principaux opérateurs publics dans la
concrétisation de la stratégie nationale du secteur de
l'informatique et le principal appui aux structures publiques dans la
réalisation, l'installation et l'exploitation des systèmes
d'information, le CNI n'a de cesse d'être au fait des dernières
innovations des technologies de l'information et de la communication et de s'en
servir dans sa démarche vers l'excellence.
Aussi, les nouvelles orientations nationales
stratégiques et technologiques et la stimulation de plus en plus
importante du secteur informatique privé, ont-elles amené le CNI
à développer et renforcer son partenariat avec ce secteur, un
partenariat qui permet de concrétiser les objectifs et les programmes
fixés notamment pour l'établissement d'une administration
électronique au service des citoyens et des entreprises.
1.2.1 Missions et services
n Adopter les systèmes d'informations (SI) et les
applications : hébergement, fourniture des moyens d'exploitation,
maintenance préventive et curative, garantie de la
sécurité et la continuité fonctionnelle des SI et garantie
de la complémentarité et de la cohérence entre les
applications ainsi qu'avec les systèmes sectoriels en relation.
n Garantir la continuité d'exploitation des SI et des
applications.
n Garantir l'exploitation et le développement du
réseau administratif.
n Avoir le rôle du titulaire délégué
d'ouvrage, et être un appui aux structures publiques dans la
réalisation, l'installation et l'exploitation des SI.
n Elaborer des études d'orientation et des études
d'utilité et des missions d'audit des systèmes d'information.
n Fixer et proposer des méthodes et des normes
d'ingénierie et techniques.
n Développer le partenariat avec le secteur privé
en vue de promouvoir des possibilités
d'exportation des produits
informatiques et des expertises nationales en la matière.
n Organiser des séminaires et des cycles de formation au
profit des utilisateurs des systèmes informatiques et des applications
publiques.
n Participer à la fourniture du service d'échanges
électroniques au profit des structures publiques.
n Participer à la fourniture des services administratifs
à distance au profit du public.
n Participer aux colloques et aux manifestations internationales
et promouvoir la coopération internationale en la matière.
1.2.2 Ressources
> Ingénieurs : 87 (experts, consultants, concepteurs
et développeurs)
> Techniciens spécialisés : 26
n Ressources humaines qualifiées et polyvalentes ayant
n Une grande expérience en matière
d'études, de développement, de maintenance soft et hard, de
sécurité, d'exploitation et de formation.
n Une expertise en matière de gestion de centres de
traitement de l'information et de sécurité des applicatifs et des
données.
n Une maîtrise parfaite des outils les plus récents
des technologies de l'information et de la communication.
n Ressources matérielles et environnement de travail
n Un centre d'hébergement et de traitement de
l'information équipé d'un ordinateur de grande puissance.
n Un Intranet de 150 postes de travail répartis sur
les différentes structures du Centre, permettant une circulation fluide
de l'information entre les différentes entités.
n Un laboratoire de tests et de simulation de différents
environnements et plates- formes
n Un centre de formation et de documentation constitué de
:
n 9 salles de formation équipées de micros
ordinateurs et de serveurs.
n Un amphithéâtre de 150 places.
n Une bibliothèque spécialisée en
informatique.
Un centre d'appel à l'écoute du client
1.3 La problématique
Soucieux d'être toujours plus efficace pour
répondre aux attentes de ses clients, le CNI a mis en place un
système de management de la qualité (SQM) qui se base sur divers
processus en s'appuyant sur les compétences de ses ingénieurs et
de ses techniciens ainsi que sur ses capacités et moyens
matériels.
Ces processus utilisés ne sont pas
informatisés, alors qu'aujourd'hui, on assiste à une
automatisation des différentes activités de l'entreprise suite
à l'évolution rapide des nouvelles technologies de l'information,
raison, exigeant à la CNI de mettre en place et de développer une
application permettant de gérer ces processus et ce dans le but de
diriger, coordonner et contrôler toutes les activités y
relatives.
Dans ce présent projet nous allons s'intéresser au
suivi de deux des ces processus à savoir :
n Processus installation et livraison des produits
n Processus déploiement
1.4 Processus qualité
Il désigne toute conjonction d'activités qui
utilise des ressources (humaines, matérielles, informationnelles, etc.)
pour convertir des éléments d'entrée en
éléments de sortie avec valeur ajoutée.
1.4.1 Système de Management de la
Qualité
Un Système de Management de la Qualité (SMQ)
est un système organisationnel permettant d'établir la politique
Qualité et les objectifs Qualité et d'atteindre les objectifs
Qualité fixés. Le SMQ est efficace s'il permet d'atteindre les
objectifs Qualité et efficient s'il permet d'atteindre les objectifs
Qualité en optimisant les ressources.
L'ISO 9001:2000 est une norme internationale qui fixe des
exigences auxquelles doit satisfaire le système de management de la
qualité («SMQ») d'une entreprise ou d'un organisme.
L'ISO 9001:2000 a pour objectif de préciser un
ensemble d'exigences qui, si elles sont réellement appliquées,
vous permettront d'avoir toute confiance que votre fournisseur peut, de
façon régulière, livrer des biens et services qui :
n correspondent à vos besoins et à vos
attentes,
n sont conformes à la réglementation en
vigueur.
1.4.2 La démarche « Système de
Management de la Qualité »
n Déterminer les besoins et attentes du client.
n Etablir la politique Qualité et les objectifs
Qualité de l'entreprise.
n Déterminer les processus et les responsabilités
nécessaires pour atteindre les objectifs Qualité.
n Déterminer et fournir les ressources nécessaires
pour atteindre les objectifs Qualité.
n Définir les méthodes de mesure de
l'efficacité de chaque processus Qualité et les mettre en
oeuvre.
n Déterminer les moyens permettant d'empêcher les
non-conformités et d'en éliminer les causes.
n Etablir et appliquer un processus d'amélioration
continue du Système de Management de la Qualité.
1.4.3 Principes du Management de la Qualité
n Orientation client.
n Implication du personnel.
n Approche processus (un résultat escompté est
atteint de façon plus efficiente lorsque les ressources et
activités afférentes sont gérées comme un
processus).
n Management par approche système (pour contribuer
à l'efficacité et à l'efficience de l'organisme :
identifier, comprendre et gérer ses processus et leurs interactions de
façon méthodique).
n Amélioration continue.
1.4.4 Les 5 « M » d'un processus
Qualité
n Main d'oeuvre : le personnel, la hiérarchie, toutes
les personnes qui concourent à la marche de l'organisme ainsi que tout
ce qui est relatif à l'action humaine : compétence, comportement,
formation, communication, motivation, etc.
n Matériel : tout ce qui nécessite un
investissement et qui est donc sujet à amortissement : locaux,
installations, machines, équipements et gros outillages, moyens de
production et de contrôle.
n Méthode : c'est la façon de faire, ce qui est
lié à l'organisation : procédures, spécifications,
modes opératoires, procédés, gammes, modes d'emploi,
consignes, notices, instructions.
n Matière : tout ce qui est consommable, donc non
investi : les fluides, les matières premières, l'énergie,
les composants, les sous-ensembles, les supports d'information.
n Milieu : ce qui est lié à l'environnement :
les conditions de travail (température, bruit, propreté,
éclairage, encombrement), l'ergonomie, les espaces verts, le parking,
l'ambiance de travail, les relations, les contacts, les clients, les
fournisseurs.
1.4.5 Les 3 types de processus qualité
n Processus Qualité de réalisation ou
opérationnel :
n Processus qui contribue directement à la
réalisation du produit (service).
n Processus dont les activités sont liées au cycle
de vie d'un produit (service), de l'élaboration de l'offre aux services
après-vente.
n Processus qui a un impact direct sur la satisfaction du
client.
n Processus qui est mis en oeuvre pour répondre aux
besoins du client et lui fournir le produit (service) attendu.
n Processus Qualité de support ou de soutien :
n Processus qui contribue au succès des processus de
réalisation, leur fournit les moyens d'un bon déroulement.
n Processus qui est lié aux ressources humaines, aux
infrastructures, à l'environnement de travail et à
l'information.
n Processus qui ne crée pas de valeur directement
perceptible par le client.
n Processus Qualité de pilotage ou de Management :
n Processus qui est sous la responsabilité de
l'équipe dirigeante.
n Processus qui a une action directe sur le fonctionnement de
l'organisme et sur sa dynamique d'amélioration.
n Processus lié au déploiement de la politique
Qualité, à l'amélioration de l'efficacité du
Système de Management de la Qualité, à l'accroissement de
la satisfaction client.
n Processus qui oriente et assure la cohérence des
processus de réalisation et support.
1.5 Démarche de développement
1.5.1 Présentation d'UP
Le Processus Unifié est un processus de
développement moderne, itératif, efficace sur des projets
informatiques de toutes tailles. Très complet, il couvre l'ensemble des
activités, depuis la conception du projet jusqu'à la livraison de
la solution.
Intégrant une organisation de projet type, une
méthodologie utilisant UML et un ensemble de bonnes pratiques
cohérentes entre elles, il permet de circonvenir aux problèmes
récurrents que rencontrent nombre de réalisations : dérive
des coûts et des délais, qualité insuffisante,
réponse incomplète aux attentes des utilisateurs.
Un point d'excellence de cette démarche est son
adaptabilité : UP peut se décliner en fonction de l'ampleur d'un
projet, de l'expérience de l'équipe qui l'assume, de la nature de
la solution à construire.
1.5.2 Les principes d'UP
n Le processus unifié est itératif : Une
itération est un mini-projet, c'est à dire un déroulement
plus ou moins complet des principaux enchaînements d'activités,
aboutissant à une version livrée en interne. 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. Une itération prend
en compte un certain nombre de cas d'utilisation et traite en priorité
les risques majeurs.
n Le processus unifié est centré sur
l'architecture : Le rôle de l'architecture logicielle est de
présenter une image complète du logiciel avant le début de
la construction. L'architecture d'un système logiciel peut être
décrite comme les différentes vues du système qui doit
être construit.
n Le PU est guidé par les cas d'utilisation d'UML : Le
but principal d'un système informatique est de satisfaire les besoins du
client. Le processus unifié montre que le système à
construire se définit d'abord avec les utilisateurs. Les cas
d'utilisation permettent d'illustrer ces besoins.
En effet, 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 futur système.
1.5.3 Les phases d'UP
n Lancement : il s'agit de l'initialisation du projet
où l'on mène une étude de faisabilité du futur
système. Afin de définir le périmètre du projet,
une identification des cas d'utilisation accompagnée d'une description
générale est modélisée dans un diagramme de cas
d'utilisation.
n Elaboration : Permet de créer l'architecture de
référence, d'estimer les coûts et les risques, de planifier
la construction. C'est la phase qui représente l'architecture du cycle
de vie.
Construction : La construction est le moment où l'on
construit le produit.
L'architecture de référence se
métamorphose en produit complet. Le produit contient tous les cas
d'utilisation que les chefs de projet, en accord avec les utilisateurs ont
décidé de mettre au point pour cette version.
n Transition : C'est la phase de livraison du produit dans sa
version béta pour une exploitation réelle et pour une validation
auprès des utilisateurs.
Les itérations : une phase peut être
répétée plusieurs fois. Chaque itération peut
être vue comme un circuit complet de développement aboutissant
à une livraison d'un produit exécutable. En effet chaque
itération effectuée au sein d'une phase va aboutir à une
livraison exécutable du système final.
1.5.4 Démarche de développement
adoptée
La démarche de développement ou encore la
méthodologie UML que nous allons utiliser tout au long de ce projet se
base et s'appui sur le processus unifié, ainsi étant
donnée que ce processus peut être adapté à divers
types de projet et d'après une démarche de développement
découverte lors de mes lectures déjà utilisée par
des experts dans le domaine(Joseph Gabay : directeur de projet informatique au
CNRS et David Gabay : ingénieur et chef de projet chez CapGemni), et qui
reflète leur expérience tirée de la réalisation en
entreprise de projets avec UML. Nous allons adopter partiellement leur
démarche qui est articulée suivant deux axes : les quatre phases
qui correspondent à celles d'UP et sept activités.
1.5.4.1 Description des activités de la
démarche
n Activité 1- Modélisation métier
Il s'agit de bien comprendre les processus dans lesquels va
s'intégrer le futur système informatique.
n Activité 2 - Exigences fonctionnelles
L'objectif de cette activité est de définir et
de recenser tout ce que le système doit faire d'un point de vue
métiers en interagissant avec les acteurs interne et externe du
système.
n Activité 3 - Analyse des cas d'utilisation
Cette activité a pour but de fournir une vue informatique
du système.
n Activité 4 - Conception
Cette activité répond à la question :
« Comment faire » elle a comme objectif de définir et mettre
en place les choix d'architecture technique.
n Activité 5 - Synthèse de l'analyse
Cette activité permet de préparer la
réalisation de l'application.
n Activité 6 - Réalisation
C'est la phase du codage des différents composants du
système.
Activité 7 - Test
La dernière activité de la démarche
consiste à tester l'application auprès des utilisateurs.
1.5.4.2 Schéma de la démarche de
développement
Le schéma de la démarche est
présenté à la figure ci-dessous.
Exigences fonctionnelles
n Elaboration du diagramme des cas d'utilisation
système
Test
n Test de l'application auprès des utilisateurs
Modélisation métier
n Elaboration du schéma de contexte du domaine
d'étude
n Elaboration du diagramme d'activité
n Elaboration du diagramme de classe métier
Analyse des cas d'utilisation
n Raffinement du diagramme de cas d'utilisation
système
n Description textuelles des cas d'utilisation
n Elaboration du schéma de navigation
générale
Conception
n Elaboration des diagrammes de séquence technique
n Elaboration des diagrammes de classe technique
Synthèse de l'analyse
n Diagramme de classe récapitulatif
n Schéma de navigation général
n Diagramme de déploiement
n Choix de la technologie
Réalisation
Implémentation de la base de données, interfaces
graphiques,
codage etc.
Figure 1- Schéma détaillé de la
démarche de développement
1.6 Conclusion
Nous avons présenté dans ce chapitre le centre
national d'informatique, la notion des processus qualité et le
système de management de la qualité et enfin la démarche
de développement adoptée.
Dans les chapitres qui suivent cette démarche sera
appliquée sur deux processus
respectivement : le processus
installation et livraison des produits et le processus déploiement.
2 Etude du processus « installation et livraison des
produits »
2.1 Modélisation métier
2.1.1 Elaboration du schéma de contexte du sous
domaine d'étude
Conformément à la démarche
adoptée, nous recommandons d'établir en premier un schéma
de contexte permettant de situer le sous domaine d'étude par rapport aux
autres processus de l'entreprise.
Ainsi, nous observons dans la figure ci-dessous que le sous
domaine d'étude est en étroite relation avec deux processus
traitant respectivement la formation et la facturation.
· Processus installation et
livraison des
produits
Formation
Commercial (Facturation)
Figure 2 - Schéma de contexte du sous domaine
d'étude (processus installation et livraison)
Le sous-ensemble mis en pointillé représente le
sous-ensemble à étudier.
2.1.2 Elaboration du diagramme d'activité
Figure 3 - Diagramme d'a ctivité
Cinq acteurs sont identifiés :
n Responsable application : Il gère les bons de
commande interne (création, modification, consultation), vérifie
la disponibilité des pré-requis pour l'installation de chaque
application, organise un cycle de formation sur l'exploitation du produit en
collaboration avec le responsable du Centre de Formation et de la Documentation
« CFD » et suit l'installation des produits.
n Responsable CFD : Il collabore avec le responsable
application afin d'organiser le cycle de formation relatif à la demande
du client. Il élabore une demande de prestation de service qui va
être envoyée au responsable application pour signature.
n Client : Il exprime ses demandes de formation par rapport aux
applications offertes par le Centre National d'informatique « CNI
».
n Equipe assistance : Elle Installe et livre les produits.
n Service Commercial : Cette entité correspond au
système de facturation interne de la CNI qui reçoit les bons de
commandes internes et les bons de livraison à la fin de l'installation
des applications pour la facturation.
2.1.3 Elaboration du diagramme de classe
métier
Figure 4 - Diagramme de classe métier
Définition des concepts du domaine :
n Utilisateur : Représente les acteurs utilisant
l'application.
n Profil : Les différents profits des utilisateurs de
l'application.
n BCI : Ce concept correspond aux bons de commandes internes qui
peuvent être passé par le client.
n BL : Bon de livraison relatif à un bon de commande
interne et qui liste les applications qui ont été
livrées.
n Client : représente les demandeurs d'un service
d'installation et livraison
d'applications fourni par le département
des produits et d'assistance « DPA ».
n Formation : Ce concept correspond à toutes les demandes
de formation des clients.
n Application : Ce concept englobe les applications
développées au compte du « DPA ».
n Pré-requis : Chaque application nécessite un
ensemble de pré-requis indispensables pour son installation.
2.2 Exigences fonctionnelles
2.2.1 Elaboration du diagramme des cas d'utilisation
système
A partir du diagramme d'activité et de la connaissance
des besoins des acteurs, nous élaborons une vision
générale des cas d'utilisation métiers du futur
système en produisant le diagramme de cas d'utilisation
système.
Figure 5 - Diagramme des cas d'utilisation système
La numérotation de chaque cas d'utilisation est
utilisée dans le diagramme des cas d'utilisation ci-dessus afin d'y
connaître les plus prioritaire à réaliser.
2.3 Analyse des cas d'utilisation
2.3.1 Raffinement du diagramme des cas d'utilisation
système
Nous allons raffiner le diagramme de cas d'utilisation
déjà élaboré dans la partie exigences
fonctionnelles. Ce diagramme est plus détaillé puisque nous
sommes passés à une phase d'analyse qui correspond à une
vison informatique du système.
Figure 6 - Diagramme des cas d'utilisation
Pour clarifier la lecture du diagramme, nous n'avons pas mis
sur le diagramme toutes les relations d'inclusion vers le cas d'utilisation
« authentification », en effet chaque cas d'utilisation
nécessite l'authentification pour pouvoir suivre son traitement.
2.3.2 Description textuelles des cas d'utilisation
Cas d'utilisation - Authentification
· Objectif : Sécuriser l'accès à
l'application.
· Acteur concerné : Responsable application,
Administrateur.
· Pré condition : L'interface d'authentification
s'est affichée à l'écran.
· Scénario nominal
1'- L'utilisateur saisit les informations d'authentification qui
lui correspond et les valide.
2'- L'application autorise l'accès de l'utilisateur
à son espace.
Cas d'utilisation - Créer utilisateur
· Objectif : Définir les utilisateurs de
l'application.
· Acteur concerné : Administrateur.
· Pré condition : L`administrateur s'est
authentifié correctement à l'application.
· Scénario nominal
1'- L'administrateur peut créer un utilisateur en
saisissant ses caractéristiques : nom prénom, identifiant et mot
de passe.
2'- L'application enregistre les informations saisies et affiche
un message de confirmation.
Cas d'utilisation - modifier utilisateur
· Objectif : mettre à jour les
caractéristiques des utilisateurs déjà
enregistrés.
· Acteur concerné : Administrateur.
· Pré condition : L`administrateur s'est
authentifié correctement à l'application.
· Scénario nominal
1'-L'administrateur sélectionne l'identifiant ID de
l'utilisateur dont il veut modifier les caractéristiques.
2'-L'application affiche les informations relatives à l'
ID de l'utilisateur.
3'-L'administrateur effectue les modifications
souhaitées.
4'-L'application met à jour les informations de
l'utilisateur, et affiche un message de confirmation.
Cas d'utilisation - Supprimer utilisateur
· Objectif : Supprimer les données relatives
à un utilisateur.
· Acteur concerné : Administrateur.
· Pré condition : L`administrateur s'est
authentifié correctement à l'application.
· Scénario nominal
1'- L'administrateur sélectionne un ou plusieurs
utilisateurs à supprimer. 2'-L'administrateur valide la suppression de
l'utilisateur.
3'- L'application affiche un message de confirmation de la
suppression. 4'-L'administrateur confirme la suppression.
5'- L'application effectue la surpression des utilisateurs.
Cas d'utilisation - Saisir bon de commande interne BCI
· Objectif : Saisir les données du bon de commande
interne.
· Acteur concerné : Responsable application.
· Pré condition : Le responsable application «
RA » s'est authentifié correctement à l'application.
· Scénario nominal
1'-Le système affiche le formulaire de saisie des
données du bon de commande interne. 2'-Le responsable application saisie
les informations nécessaires.
3'-Le système enregistre la saisie validée.
Cas d'utilisation - Modifier BCI
· Objectif : Permettre au responsable application de
modifier des données de bon de commande interne déjà
enregistré.
· Acteur concerné : Responsable application.
· Pré condition : Le responsable application s'est
authentifié correctement à l'application.
· Scénario nominal
1'- Le système affiche le formulaire de modification des
données du BCI.
2'- Le responsable application modifie les données.
3'- Le système enregistre la modification
validée.
Cas d'utilisation - Consulter BCI
· Objectif : permettre au responsable application de
consulter des données de bon de commande interne.
· Acteur concerné : Responsable application.
· Pré condition : Le responsable application s'est
authentifié correctement à l'application.
· Scénario nominal
1'- Le responsable application sélectionne le bon de
commande interne.
2'- Le système affiche les données
déjà enregistrées.
3'- Fin du cas d'utilisation.
Cas d'utilisation - Vérifier la disponibilité
des pré-requis
· Objectif : Permettre au responsable application de
vérifier et de suivre l'état de disponibilité des
pré-requis pour chaque application.
· Acteur concerné : Responsable application.
· Pré condition : Le responsable application s'est
authentifié correctement à l'application.
· Scénario nominal
1'- L'application affiche le formulaire de vérification
de la disponibilité des pré-requis.
2'- Le responsable application sélectionne un bon de
commande interne.
3'- L'application affiche une liste de toutes les applications
du bon de commande interne et une case à cocher pour chacune d'elle.
4'- Le responsable application coche les cases à cocher
selon l'état de disponibilité des pré- requis de chaque
application.
Cas d'utilisation - Ajouter formation
· Objectif : Saisir les données des demandes de
formation.
· Acteur concerné : Responsable application .
· Pré condition : Authentification correcte à
l'application.
· Scénario nominal
1'-Le système affiche le formulaire de saisie des
données de la demande de formation.
2'-Le responsable application saisit les informations
nécessaires. 3'-Le système enregistre la saisie
validée.
Cas d'utilisation - Modifier formation
· Objectif : Permettre au responsable application de
modifier des données d'une demande de formation.
· Acteur concerné : Responsable application.
· Pré condition : Le responsable application s'est
authentifié correctement à l'application.
· Scénario nominal
1'- Le système affiche le formulaire de modification des
données de la demande de formation.
2'- Le responsable application modifie les données et
confirme les modifications effectuées.
3'- Le système enregistre les modifications.
Cas d'utilisation - Consulter formation
· Objectif : permettre au responsable application de
visualiser les informations des formations.
· Acteur concerné : Responsable application.
· Pré condition : Le responsable application s'est
authentifié correctement à l'application.
· Scénario nominal
1'- Le responsable application sélectionne le bon de
commande interne.
2'- Le système affiche les applications du bon de
commande et les informations de chaque formation d'une application.
3'- Fin du cas d'utilisation.
Cas d'utilisation - Suivre l'état d'installation des
produits
· Objectif : savoir si l'installation d'un produit est
accomplie ou pas.
· Acteur concerné : Responsable application.
· Pré condition : Le responsable application s'est
authentifiée correctement à l'application.
· Scénario nominal
1'- Le responsable application sélectionne un bon de
commande interne déjà enregistré.
2'- Le système affiche toutes les applications
relatives au bon de commande interne, avec une case à cocher
située auprès de chaque application signifiant l'accomplissement
de l'installation de l'application.
3'- Le responsable application coche les cases à cocher
selon l'état d'installation des produits et valide enfin ses choix.
4'- Le système enregistre les états d'installation
de toutes les applications relatives au bon de commande
sélectionné.
Cas d'utilisation - Ajouter bon de livraison
· Objectif : Saisir les données du bon de
livraison.
· Acteur concerné : Responsable application.
· Pré condition : Le responsable application s'est
authentifiée correctement à l'application.
· Scénario nominal
1'-Le système affiche le formulaire de saisie des
données du bon de livraison.
2'-Le responsable application saisie les informations
nécessaires.
3'-Le système enregistre la saisie validée.
Cas d'utilisation - Modifier bon de livraison
· Objectif : Permettre au responsable application de
modifier des données d'un bon de livraison déjà
enregistré.
· Acteur concerné : Responsable application.
· Pré condition : Le responsable application s'est
authentifié correctement à l'application.
· Scénario nominal
1'- Le système affiche le formulaire de modification des
données du bon de livraison.
2'- Le responsable application modifie les données et
valide les modifications effectuées.
3'- Le système enregistre les modifications.
Cas d'utilisation - Consulter bon de livraison
· Objectif : Permettre au responsable application de
visualiser les données d'un bon de livraison.
· Acteur concerné : Responsable application.
· Pré condition : Le responsable application s'est
authentifié correctement à l'application.
· Scénario nominal
1'- Le responsable application sélectionne le bon de
livraison.
2'- Le système affiche les informations du bon de
livraison.
3'- Fin du cas d'utilisation.
Gérer formation
Saisir Formation
Modifier Formation
2.3.3 Elaboration du schéma de navigation
générale
La figure ci-dessous représente le schéma de
navigation générale relatif au processus installation et
livraison des produits.
Saisir BCI
Gérer Bon de command interne
Consulter BCI
Modifier BCI
Vérifier disponibilité des prés-requis
|
Installation et livraison des produits
|
Consulter Formation
Etat d'installation des produits
Saisir BL
Gérer Bon de livraison
Consulter BL
Modifier BL
Figure 7 - Schéma de navigation
générale
Suite à une authentification réussite,
l'utilisateur concerné peut avoir la possibilité d'accéder
aux fonctionnalités qui lui sont offertes par l'application.
2.4 Conception
2.4.1 Elaboration des diagrammes techniques
Dans cette partie, nous allons présenter les diagrammes
techniques pour chaque cas d'utilisation dégagé à partir
du digramme de cas d'utilisation raffiné.
ISIMS
24
Figure 9 - Diagramme de classe du CU Authentification
Figure 8 - Diagramme de séquence du CU Authentification
· Cas d'utilisation « authentification »
Figure 11 - Diagramme de classe du CU Créer utilisateur
Figure 10 - Diagramme de séquence du CU Créer
utilisateur
Cas d'utilisation « Créer Utilisateur »
ISIMS
26
Figure 13 - Diagramme de classe du CU Modifier utilisateur
Figure 12 - Diagramme de séquence du CU Modifier
utilisateur
Cas d'utilisation « Modifier Utilisateur »
Figure 14 - Diagramme de séquence du CU Supprimer
Utilisateur
Figure 15 - Diagramme de classe du CU Supprimer Utilisateur
Cas d'utilisation « Supprimer Utilisateur »
ISI MS
28
Figure 17 - Diagramme de classe du CU Saisir BCI
Figure 16 - Diagramme de séquence du cas d'utilisation
saisir bon de commande interne
Cas d'utilisation « Saisir BCI »
Figure 18 - Diagramme de séquence du CU Modifier BCI
Figure 19 - Diagramme de classe du CU Modifier BCI
Cas d'utilisation « Modifier BCI »
ISI MS
30
Figure 21 - Diagramme de classe du CU Consulter BCI
Figure 20 - Diagramme de séquence du CU Consulter BCI
Cas d'utilisation « Consulter BCI »
Figure 23 - Diagramme de classe du CU Vérifier Prés
requis
Figure 22 - Diagramme de séquence du CU Vérifier
Prés requis
Cas d'utilisation « Vérifier Prés requis
»
Figure 24 - Diagramme de séquence du CU Ajouter
Formation
Figure 25 - Diagramme de classe du CU Ajouter Formation
Cas d'utilisation « Ajouter Formation »
ISI MS
33
Figure 27 - Diagramme de classe du CU Modifier Formation
Figure 26 - Diagramme de séquence du cas CU Modifier
Formation
Cas d'utilisation « Modifier Formation »
Figure 28 - Diagramme de séquence du CU Consulter
Formation
Figure 29 - Diagramme de classe du CU Consulter Formation
Cas d'utilisation « Consulter Formation »
ISI MS
35
Figure 31 - Diagramme de classe du CU Suivre l'installation des
produits
Figure 30 - Diagramme de séquence du CU Suivre
l'installation des produits
Cas d'utilisation « Suivre l'installation des applications
»
Figure 32 - Diagramme de séquence du CU Ajouter bon de
livraison
Figure 33 - Diagramme de classe du CU Ajouter bon de livraison
Cas d'utilisation « Ajouter Bon de livraison »
ISIMS
37
Figure 35 - Diagramme de classe du CU modifier BL
Figure 34 - Diagramme de séquence du CU Modifier BL
Cas d'utilisation « modifier bon de livraison »
Figure 36 - Diagramme de séquence du CU Consulter bon de
livraison
Figure 37 - Diagramme de classe du CU Consulter bon de
livraison
Cas d'utilisation « consulter bon de livraison »
3 Etude du processus « Déploiement » 3.1
Modélisation métier
3.1.1 Elaboration du schéma de contexte du
domaine d'étude
Dans la figure ci-dessous, nous allons présenter le
schéma de contexte permettant de situer le sous domaine d'étude
(processus déploiement) par rapport aux autres processus de
l'entreprise.
Ainsi, nous remarquons que le sous domaine d'étude est en
étroite relation avec deux processus traitant respectivement la
formation et la facturation.
Formation
Processus déploiement
Commercial (Facturation)
Figure 38 - Schéma de contexte du sous domaine
d,étude (Processus déploiement)
Le sous-ensemble mis en pointillé représente le
sous-ensemble à étudier.
3.1.2 Elaboration du diagramme d'activité
Figure 39 - Diagramme d'activité
Trois acteurs sont identifiés :
n Service Commercial : Il signe les conventions de
déploiement des applications. De plus, cette entité correspond au
système de facturation interne de la CNI qui reçoit les ordres de
facturation après la fin des travaux de déploiement.
n Responsable application : Il gère les conventions
(création, modification, consultation) et planifie les interventions de
déploiement (formation, ouverture des ports de communication) en
collaboration avec le chef unité.
n Equipe mobile : se sont les intervenants qui vont
exécuter les travaux de déploiement et remplir les fiches de mise
en services relatives aux bons d'intervention.
3.1.3 Elaboration du diagramme de classe
métier
Le diagramme de classe métier est donné par la
figure ci-dessous.
Figure 40 - Diagramme de classe métier
Les concepts du domaine présentés dans le
diagramme de classe métier du processus déploiement sont
définis par la suite.
Définition des concepts du domaine :
n Convention: Représente les conventions signées
avec le client et qui listent l'ensemble des applications demandées pour
le déploiement.
n Application : Ce concept englobe les applications
développées au compte du « DPA » et qui peuvent
être déployées sur un ou plusieurs sites.
n BonIntervention: Ce concept correspond aux bons
d'intervention qui listent l'ensemble des interventions effectuées pour
accomplir le déploiement d'une ou plusieurs applications sur un ou
plusieurs sites.
n Intervention: Elle correspond aux interventions relatives
à un bon d'intervention et à une convention bien
déterminée.
n FicheMiseService : ce concept correspond aux fiches de mise en
service remplis
par une « équipe mobile » pointant les
applications déployées et mises en service.
n PVReception : Ce concept correspond à un procès
verbal de réception attestant la réception des travaux par le
client.
n Client : représente les demandeurs d'un service de
déploiement des applications offertes par le département des
produits et d'assistance « DPA » sur un ou plusieurs sites.
n Utilisateur : Représente les acteurs utilisant
l'application. Chaque utilisateur peut avoir un et un seul profil.
n Profil : Il désigne les différents profits des
utilisateurs de l'application. Un profit peut être affecté
à un ou plusieurs utilisateurs.
3.2 Exigences fonctionnelles
3.2.1 Elaboration du diagramme des cas d'utilisation
système
A partir du diagramme d'activité et de la connaissance
des besoins des acteurs, nous élaborons une vision
générale des cas d'utilisation métiers du futur
système en produisant le diagramme de cas d'utilisation
système.
Figure 41 - Diagramme des cas d'utilisation système
La numérotation de chaque cas d'utilisation est
utilisée dans le diagramme des cas d'utilisation ci-dessus afin d'y
connaître les plus prioritaire à réaliser.
3.3 Analyse des cas d'utilisation
3.3.1 Raffinement du diagramme des cas
d'utilisation
ISI MS
44
Figure 42 - Diagramme des cas d'utilisation
Nous allons raffiner le diagramme de cas d'utilisation
déjà élaboré dans la partie exigences
fonctionnelles. Ce diagramme est plus détaillé puisque nous
sommes passés à une phase d'analyse qui correspond à une
vision informatique du système.
3.3.2 Description textuelles des cas d'utilisation
Cas d'utilisation 1 - « Gérer convention »
· Objectif : Permettre au responsable application de
saisir, de consulter ou de modifier les données d'une convention.
· Acteur concerné : Responsable application.
· Pré condition : Le responsable application s'est
authentifiée correctement à l'application.
· Scénario nominal : saisie d'une nouvelle
convention
1'- Le système affiche le formulaire de saisie des
données d'une convention.
2'- Le responsable application saisit les informations
nécessaires et valide sa saisie.
3'- Le système vérifie la présence des
données obligatoires.
4'- Le système enregistre la saisie validée.
· Scénario alternatif :
2'a - Modification des données de la convention :
- Le système affiche le formulaire de saisie des
données de convention enregistrées.
- Le responsable application modifie les données.
- Le cas d'utilisation reprend à l'action 3 du
scénario nominal.
2'b - Consultation des données de la convention :
- Le système affiche les données de la convention
déjà enregistrées.
- Fin du cas d'utilisation.
3'a - Erreurs détectées dans la saisie :
- Le système réaffiche le formulaire de saisie en
indiquant les erreurs détectées.
- Le responsable application corrige les erreurs
détectées.
- Le cas d'utilisation reprend au point 3 du scénario
nominal.
Cas d'utilisation 2 - « gérer bon d'intervention
»
· Objectif : Permettre à l'équipe mobile de
saisir, de consulter ou de modifier les données des bons
d'intervention.
· Acteur concerné : Equipe mobile.
· Pré condition : Authentification correcte à
l'application
· Scénario nominal : saisie d'un nouveau bon
d'intervention
1'- Le système affiche le formulaire de saisie des
données d'un bon d'intervention.
2'- L'acteur « équipe mobile » saisit les
informations nécessaires et valide sa saisie.
3'- Le système vérifie la présence des
données obligatoires.
4'- Le système enregistre la saisie validée.
· Scénario alternatif :
2'a - Modification des données d'un bon d'intervention
:
- Le système affiche le formulaire de saisie des
données d'un bon d'intervention enregistrées.
- L'acteur « équipe mobile » modifie les
données.
- Le cas d'utilisation reprend à l'action 3 du
scénario nominal.
2'b - Consultation des données d'un bon d'intervention
:
- Le système affiche les données du bon
d'intervention déjà enregistrées.
- Fin du cas d'utilisation.
3'a - Erreurs détectées dans la saisie :
- Le système réaffiche le formulaire de saisie en
indiquant les erreurs détectées.
- L'acteur « équipe mobile » corrige les
erreurs détectées.
- Le cas d'utilisation reprend au point 3 du scénario
nominal.
Cas d'utilisation 3 - « Gérer fiche de mise en
service »
· Objectif : Permettre à l'équipe mobile de
saisir, de consulter ou de modifier les données des fiches de mise en
service.
· Acteur concerné : « équipe mobile
».
· Pré condition : Authentification correcte à
l'application.
· Scénario nominal : saisie d'une nouvelle fiche de
mise en service
1'- Le système affiche le formulaire de saisie des
données d'une fiche de mise en service.
2'- L'équipe mobile saisit les informations
nécessaires et valide sa saisie.
3'- Le système vérifie la présence des
données obligatoires.
4'- Le système enregistre la saisie validée.
· Scénario alternatif :
2'a - Modification des données d'une fiche de mise en
service :
- Le système affiche le formulaire de saisie des
données d'une fiche de mis en service déjà
enregistrée.
- L'acteur « équipe mobile » modifie les
données.
- Le cas d'utilisation reprend à l'action 3 du
scénario nominal.
2'b - Consultation des données d'une fiche de mise en
service :
- Le système affiche les données du fiche de mise
en service déjà enregistrées.
- Fin du cas d'utilisation.
3'a - Erreurs détectées dans la saisie :
- Le système réaffiche le formulaire de saisie en
indiquant les erreurs détectées.
- L'acteur « équipe mobile » corrige les
erreurs détectées.
- Le cas d'utilisation reprend au point 3 du scénario
nominal.
Cas d'utilisation 4 - « Gérer PV de
Réception »
· Objectif : Permettre à l'équipe mobile de
saisir, de consulter ou de modifier les données les PV de
réception.
· Acteur concerné : « équipe mobile
».
· Pré condition : Authentification correcte à
l'application.
· Scénario nominal : saisie d'un nouveau PV de
réception
1'- Le système affiche le formulaire de saisie des
données d'un PV de réception.
2'- L'équipe mobile saisit les informations
nécessaires et valide sa saisie.
3'- Le système vérifie la présence des
données obligatoires.
4'- Le système enregistre la saisie validée.
· Scénario alternatif :
2'a - Modification des données d'un PV de
réception:
- Le système affiche le formulaire de saisie des
données d'un PV de réception enregistrées.
- L'acteur « équipe mobile » modifie les
données.
- Le cas d'utilisation reprend à l'action 3 du
scénario nominal.
2'b - Consultation des données d'un PV de
réception :
- Le système affiche les données de la convention
déjà enregistrées.
3'a - Erreurs détectées dans la saisie :
- Le système réaffiche le formulaire de saisie en
indiquant les erreurs détectées.
- L'acteur « équipe mobile » corrige les
erreurs détectées.
- Le cas d'utilisation reprend au point 3 du scénario
nominal.
3.3.3 Elaboration du schéma de navigation
générale
La figure ci-dessous représente le schéma de
navigation générale relatif au processus déploiement.
CONVENTION
AJOUTER
MODIFICATION
CONSULTATION
Déploiement
BON D'INTERVENTION AJOUTER
MODIFICATION
CONSULTATION
|
|
FICHE DE MISE EN SERVICE
|
|
|
|
|
|
|
|
|
|
|
AJOUTER
|
|
|
|
|
|
|
|
|
|
|
MODIFICATION
|
CONSULTATION
PV DE RECEPTION
AJOUTER
MODIFICATION
CONSULTATION
Figure 43 - Schéma de navigation
générale
Suite à une authentification réussite,
l'utilisateur selon son profil, peut avoir la possibilité
d'accéder aux fonctionnalités qui lui sont offertes par
l'application.
3.4 Conception
3.4.1 Elaboration des diagrammes techniques
ISI MS
50
Figure 45 - Diagramme de classe du CU Gérer convention
Figure 44 - Diagramme de séquence du CU Gérer
convention
Cas d'utilisation « Gérer Convention »
Figure 47 - Diagramme de classe du CU Gérer bon
d'intervention
Figure 46 - Diagramme de séquence du CU Gérer bon
d'Intervention
Cas d'utilisation « Gérer bon
d'intervention»
ISI MS
52
Figure 49 - Diagramme de classe du CU Gérer fiche mise en
service
Figure 48 - Digramme de séquence du CU Gérer fiche
mise en service
Cas d'utilisation « Gérer fiche de mise en
service»
Figure 51 - Diagramme de classe du CU Gérer PV de
réception
Figure 50 - Diagramme de séquence du CU Gérer PV de
réception
Cas d'utilisation « Gérer PV de
réception»
4 Synthèse de l'analyse
4.1 Diagramme de classe récapitulatif
Le diagramme de classe récapitulatif ci-dessous est le
résultat de la fusion entre les deux diagrammes de classe métiers
des deux processus étudiés à savoir processus installation
et livraison des produits et processus déploiement. Ce digramme peut
être mis à jour en ajoutant d'autres attributs si
nécessaire. Les méthodes de chaque classe ont été
dégagées lors de la phase d'analyse.
Figure 52 - Diagramme de classe récapitulatif
4.2 Schéma de navigation de synthèse
Suite à une authentification correcte, et selon le
profil sélectionné, l'utilisateur sera redirigé vers son
espace de travail. L'application offre trois espaces : un pour
l'administrateur, un autre pour le responsable application et un pour
l'équipe mobile. Chaque espace de travail couvre les activités
déjà recensées dans les deux processus
étudiés.
Figure 53 - Schéma de navigation de synthèse
4.3 Diagramme de déploiement
Le diagramme de déploiement montre la disposition
physique des matériels qui composent le système et la
répartition des composants sur ces matériels. Les ressources
matérielles sont représentées sous forme de noeuds qui
sont connectés entre eux à l'aide d'un support de
communication.
Ce diagramme représente une architecture trois-tiers
sur laquelle notre futur système va être déployé.
Chaque noeud utilise les services du noeud plus supérieur. Ainsi le
serveur web représente la couche présentation, le serveur
d'application : la couche traitement et le serveur base de données : la
couche persistance des données.
Figure 54 - Diagramme de déploiement
4.4 Technologie choisie
Concernant la technologie pour cette architecture
(architecture 3 -tiers), J2EE sera mise en place. Il existe beaucoup d'autres
plates-formes de développement se basant sur d'autres langages, mais les
principaux avantages de java sont sa portabilité et son
indépendance.
Dans le chapitre suivant, l'application sera
développée en utilisant les Java Server Pages, les Servlets et
les JavaBeans.
5 Réalisation
5.1 Environnement de réalisation
En ce qui concerne l'environnement de réalisation nous
avons fait recours à certains matériaux et logiciels qui
permettent d'accomplir la réalisation de l'application.
5.1.1 Environnement matériel
Au cours de ce projet, nous avons effectué la
réalisation de cette application en utilisant un PC portable DELL
INSPIRON 1501 ayant les caractéristiques suivantes :
|
n Système d'exploitation : Microsoft Windows XP
Professionnel SP3.
n Processeur : AMD Turion 64 Mobile Technologie, 2 GHz.
n Mémoire physique : 1,5 GHz.
n Disque dur : 120 GO.
|
5.1.2 Environnement logiciel
|
IBM Rational Software Architect Standard Edition (RSA Standard
Edition 7.1) (Anciennement IBM Rational Systems Developers) : Un environnement
de développement intégré qui permet aux organisations de
maîtriser le processus métier de développement de
systèmes et de logiciels.
|
|
IBM Rational Software Architect Standard Edition exploite
toutes les capacités d'Eclipse et aide les équipes de
développement à utiliser le langage de modélisation UML 2
pour créer des applications en C/C++, Java (J2SE).
|
Eclipse IDE 3.4.2 (Ganymede) : Ec
lipse IDE est un environnement de développement
intégré libre extensible, universel et
polyvalent, permettant potentiellement de créer des
projets de développement mettant en oeuvre n'importe
quel langage de programmation. Eclipse IDE est principalement
écrit en Java.
Adobe Dreamweaver CS3 : Dreamweaver
est un éditeur WYSIWYG (what you see is what you get,
ce que vous voyez est ce que vous obtenez) destiné
à la conception, au codage et au développement
de sites, de pages et d'applications Web.
MySQL Server 5.1 : MySQL est un
serveur de bases de données relationnelles Open Source
(Standard Ouvert) signifie qu'il est possible à chacun
d'utiliser et de modifier le logiciel. Tout le monde peut
télécharger MySQL sur Internet, et l'utiliser
sans payer aucun droit.
Navicat 8.0 for MySQL : Navicat
(MySQL Gui) version 8.x est un outil pour gérer les
bases de données MySQL, et pour convertir des bases en
XML, CSV, MS (Excel et Access), et autres formats. Les autres
fonctions majeures du programme est l'import et
l'expo rt, un support unicode, le tunnel
HTTP/SSH, la synchronisation des données et bien
d'autres encore.
|
PowerAMC : est un outil intégré de conception et
de modélisation des Systèmes d'Entreprises. PowerAMC combine les
techniques standards de modélisation Merise (traitements et
données), UML, Data Warehouse et modélisation des processus
métiers. Bien plus qu'une simple offre multi-techniques, PowerAMC permet
de fédérer le travail de l'ensemble des intervenants dans un
projet, en création, en maintenance ou en réingénierie des
systèmes d'information.
|
|
Apache Tomcat 6.0 : Apache Tomcat est un conteneur libre de
servlet Java 2 Enterprise Edition. Issu du projet Jakarta, Tomcat est
désormais un projet principal de la fondation Apache. Tomcat
implémente les spécifications des servlets et des JSP de Sun
Microsystems.
|
5.2 Implémentation de la base de
donnée
Pour implémenter la base de données, noua avons
fait recours à Sybase PowerAMC qui nous a permis de créer le
diagramme de classe récapitulatif à partir duquel la
génération d'un modèle physique de données est
possible. Le modèle physique de données reflète le
schéma de la base de données relationnelles en fournissant la
structure de ses tables. Enfin, la génération d'un fichier
portant l'extension SQL afin que nous puissions l'exécuter pour
l'obtention de toutes les tables de la base de données.
De plus, l'utilisation de Navicat for MySQL nous a
facilité énormément la tache de génération
de la base de données MySQL puisque ce dernier joue le rôle d'une
interface de manipulation des tables, vues, requêtes etc. Ainsi, il
fournit un éditeur de requête SQL permettant l'exécution du
fichier SQL contenant les instructions nécessaires pour la
création de la base de données relationnelles.
La génération automatique d'un fichier SQL
contenant toutes les instructions de la création des tables, ainsi,
l'implémentation rapide de la base de données représente
un avantage majeur de Sybase PowerAMC raison de le choisir pour cette
tâche seulement et non comme méthode de conception. De plus cet
outil utilise le standard UML et donc utilise les notions orienté objet
ce qui nous a permis de créer le diagramme de classe puis
générer le modèle physique de données.
5.2.1 Modèle physique de données
Le modèle physique de donnée offre une vue
complète sur la structure des tables de la base de donnée, ainsi
il nous offre la possibilité de générer un fichier SQL
contenant toutes les instructions nécessaire pour la création de
la base de données relationnelles.
.
Figure 55 - Modèle physique de données
Les tables dont la couleur de remplissage est le bleu
représentent les tables résultat d'une relation un à
plusieurs entre deux classes.
L'orientation des flèches montre qu'il y a migration d'une
clé étrangère de la table destination vers la table
source.
5.3 Enchainement des interfaces graphiques
5.3.1 Connexion
Pour sécuriser l'accès à l'application
web, l'utilisateur, selon son profil, saisit son identifiant et son mot de
passe. Si les paramètres d'authentification envoyés
coïncident avec les paramètres enregistrés dans la base de
données, l'utilisateur sera redirigé vers son espace de travail.
En effet, l'application offre trois espaces de travail : « espace
administrateur », « espace responsable application » et «
espace équipe mobile ».
Figure 56 - Interface Connexion
Si les paramètres d'authentification sont incorrects, un
message d'erreur s'affiche à l'écran interdisant l'accès
aux fonctionnalités de l'application.
Figure 57 - Interface Erreur d'authentification
5.3.2 Espace administrateur
Pour la mise en marche de l'application, l'administrateur doit
ajouter les utilisateurs, les applications, les fiches pré-requis
relatives aux applications et les clients. Ces données sont primordiales
et nécessaires tout au long des deux processus. Un exemple d'ajout d'un
nouvel utilisateur est donné à la figure ci-dessous.
Figure 58 - Interface Ajout d'un nouvel utilisateur (1/2)
ISIMS
63
Figure 59 - Interface Ajout d'un nouvel utilisateur (2/2)
Après la validation de l'action d'ajout d'un nouvel
utilisateur, toutes les informations concernant l'utilisateur nouvellement
ajouté seront affichées.
L'administrateur peut mette à jour les données
d'un utilisateur déjà enregistré. Une liste
déroulante permet d'extraire, depuis la base de données, les
identifiants des utilisateurs enregistrés et les afficher pour la
sélection. La validation de la sélection permet de
récupérer les informations de l'utilisateur selon l'identifiant
choisi.
Figure 60 - Interface mise à jour d'un utilisateur (1/3)
L'administrateur peut alors effectuer les modifications nécessaires et
les valider.
Figure 61 - Interface mise à jour d'un utilisateur
(2/3)
Les informations de l'utilisateur seront affichées avec
prise en considération des diverses modifications effectuées par
l'administrateur.
Figure 62 - Interface mise à jour d'un utilisateur
(3/3)
L'administrateur a le droit aussi de supprimer un ou plusieurs
utilisateurs définitivement. Il coche les utilisateurs qu'il veut
supprimer et valide la suppression. Tous les utilisateurs cochés seront
supprimés de la base de données.
Figure 63 - Interface Suppression d'utilisateurs (1/2)
Figure 64 - Interface Suppression d'utilisateurs (2/2)
Si l'administrateur répète l'action de suppression
des utilisateurs, il voit bien que les utilisateurs supprimés n'existent
plus dans la base de données.
5.3.3 Espace responsable application
La première étape que le responsable application
doit prendre en charge est l'ajout des bons de commande interne. Il saisit les
informations du bon de commande qu'il veut ajouter et lui associe les
applications y relatives, puis valide l'action d'ajout.
Figure 65 - Interface Ajout bon de commande interne
ISIMS
66
Figure 66 - Interface consultation des bons de commande
Le responsable application peut consulter alors un bon de
commande déjà enregistré. Il voit bien les informations
ainsi les applications du bon de commande interne.
Après l'ajout du bon de commande interne, le
responsable application, selon le suivi du processus installation et livraison
des produits, doit vérifier les pré-requis de chaque application
relative à ce bon de commande interne. Par défaut lors de l'ajout
du bon de commande interne, l'état de disponibilité des
pré-requis est « NON VERIFIE », c'est au responsable
application de vérifier auprès du client l'état de
disponibilité des pré-requis pour chaque fiche de
pré-requis de chaque application du bon de commande interne.
Figure 67 - Interface Vérification des pré-requis
(1/2)
ISIMS
67
Figure 68 - Interface Vérification des pré-requis
(2/2)
Après l'enregistrement de l'état de
disponibilité des pré-requis, le responsable application, pour un
bon de commande interne donnée, peut encore répéter la
même action. Ainsi pour passer à l'étape suivante du
processus installation et livraison des produits, tous les pré- requis
de chaque application doivent être vérifiés.
Après la vérification de l'état de
disponibilité des pré-requis, le responsable application peut
ajouter une formation à une application du bon de commande. Il peut
ajouter tant de formation qu'il y a d'applications dans le bon de commande
interne.
Figure 69 - Interface Ajout d'une formation
Figure 70 - Interface Consultation des formations
Après l'ajout des formations, le responsable application
peut consulter les formations déjà enregistrées.
Le responsable application, pour suivre l'état
d'installation des applications, sélectionne les applications qui sont
installées soit dans les locaux de la CNI, soit dans les locaux du
client. Ainsi, pour passer à l'étape suivante du processus
installation et livraison de produits (Gestion des bons de livraison), toutes
les applications doivent être bien installées.
Figure 71 - Interface suivie installation des applications
(1/2)
Figure 72 - Interface suivie installation des applications
(2/2)
Après la validation de l'enregistrement de
l'état d'installation des applications, si le responsable application
consulte encore une autre fois le même bon de commande interne, il peut
connaitre et suivre l'état d'installation des applications.
La dernière étape du processus installation et
livraison des produits est l'élaboration d'un bon de livraison relatif
à un bon du commande interne déjà enregistré
dés la première étape du processus et qui a l'état
par défaut « NON TRAITE ». Le responsable application choisit
le bon de commande et valide sa sélection pour afficher les informations
y relatives, ensuite choisit un ou plusieurs applications (qui ont
été livrées) et enfin valide l'ajout du bon de livraison.
Un bon de commande passe à l'état « TRAITE » lorsque
toutes les applications sont livrées.
Figure 73 - Interface ajout bon de livraison
ISIMS
70
Figure 74 - interface ajout d'une convention
En ce qui concerne le processus déploiement, le
responsable application prend seulement en charge la gestion des conventions et
la consultation des fiches de mise en service, les PV de réception et
les bons d'intervention, les autres activités sont à la charge de
l'équipe mobile qui possède sa propre espace de travail pour
gérer les activités du processus déploiement.
5.3.4 Espace Equipe Mobile
Le processus déploiement demande la consultation des
conventions déjà élaborées par le responsable
application afin qu'il puisse démarrer. Après la consultation
d'une convention, « l'équipe mobile » peut gérer les
bon d'intervention, les fiches de mise en service des applications
nécessitant un déploiement et enfin les PV de
réception.
On remarque bien que les deux acteurs (responsable application et
équipe mobile) collaborent ensemble pour suivre les activités du
processus déploiement.
Figure 75 - Interface espace équipe mobile
5.4 Test de l'application
Pour tester l'application en intranet, nous avons
exporté le projet, en utilisant l'IDE eclipse ganymede en un fichier
portant l'extension WAR (Web ARchive). Ce fichier peut être
déployé en utilisant le conteneur libre de servlet apache
tomcat.
Pour faire les premiers tests, nous avons installé
apache Tomcat et Mysql sur une machine appartenant au réseau local du
département des produits et d'assistance de la CNI, importé le
Web Archive depuis Tomcat pour le déploiement de l'application web et
implémenté la base de donnée Mysql. Chaque poste
appartenant au réseau local peut accéder à l'application
par le biais d'un navigateur web en tapant l'adresse IP de la machine
hébergeant cette dernière. L'adresse IP est suivie du
numéro de port 8080 et bien sur utilise le protocole HTTP. L'adresse a
la forme suivante
http://192.168.1.3:8080/test
(test représente le nom de l'application web).
Conclusion
Le département des produits et de maintenance du centre
national d'informatique de Tunis gère ses divers processus
qualité d'une façon manuelle et non informatisée. Pour
cela, nous avons mené cette étude pour développer et
mettre en place un système de suivi des processus qualité en se
basant sur deux processus : processus installation et livraison des produits et
processus déploiement.
Pour atteindre nos objectifs, nous avons procédé
par la conception de l'application en faisant recours au processus
unifié « UP » comme méthodologie de
développement logiciel basée sur le langage unifié de
modélisation UML et à IBM Rational Software Architect version 7.0
« RSA » comme environnement de développement intégrant
une vue de modélisation UML2. De plus, étant donné que
nous avons deux processus à concevoir, nous avons essayé
d'étudier chacun d'eux à part en appliquant la
méthodologie déjà choisie, puis faire une synthèse
de leur analyse. Cette dernière a aboutit à choisir J2EE comme
technologie et à la création de la base de donnée MySQL.
Ensuite, nous sommes passés à la phase de réalisation en
moyennant diverses softs tels que Dreamweaver pour la création des
interfaces graphiques, eclipse ganymede pour le codage des pages Java Server
Pages « JSP », des servlets et des javabeans.
Les perspectives pour ce projet est d'utiliser un Framework
libre de développement d'application web J2EE comme Struts,
d'intégrer d'autres processus à l'application puisqu'elle est
extensible et étudier le niveau de sécurité en intranet de
l'application.
L'application dans sa forme actuelle a atteint une certaine
maturité. Les fonctions désirées à la base sont
parfaitement implémentées.
Ce projet de fin d'études m'a permis de gérer
des obstacles multiples, de prendre des initiatives, de reconnaitre une
hiérarchie, de la respecter, d'avoir une vision plus mûre d'un
vrai travail responsable, et ainsi, de m'intégrer complètement au
monde de l'entreprise.
Il m'a permis également de mettre en oeuvre des
capacités de communication, d'analyse, d'organisation et de gestion, et
d'acquérir, par une mise en situation réelle des
compétences dans le domaine de développement d'application
web.
Bibliographie
· UML 2 analyse et conception: Mise en oeuvre guidée
avec études de cas Par Joseph Gabay, David Gabay
Publié par Dunod, 2008
· UML 2 pour les bases de données: Avec 20 exercices
corrigés Par Christian Soutou
Publié par Eyrolles, 2007
· JSP avec Eclipse et Tomcat: Entraînez-vous à
concevoir des applications web en environnement J2EE
Par François-Xavier Sennesal
Publié par Editions ENI, 2007
URL utiles
UML
·
http://www.uml.org
·
http://uml.developpez.com/faq/
·
http://fdigallo.online.fr/cours/uml.pdf
Processus unifié
·
http://sabricole.developpez.com/uml/tutoriel/unifiedProcess/
·
http://www2.lifl.fr/~clerbout/coursIPINT/Cours4-ProcessusUnifie.pdfrocessus
unifié
J2EE
·
http://www.java2s.com
·
http://mbaron.developpez.com/javaee/jsp/
·
http://java.sun.com/javaee/
Outils
·
http://www-01.ibm.com/software/awdtools/modeler/swmodeler/
·
http://www-01.ibm.com/software/awdtools/architect/swarchitect/
·
http://www.sybase.fr/products/modelingdevelopment/poweramc
·
http://tomcat.apache.org/download-60.cgi
·
http://dev.mysql.com/downloads/
·
www.adobe.com/fr/products/dreamweaver/
·
http://www.eclipse.org/ganymede/
| 
