Chapitre 2 : Phase d’Elaboration

Chapitre 2 : Phase de Création

1. Introduction

D
ans ce chapitre, je présente la première phase du processus unifié, il s’agit
d’étudier la faisabilité globale du futur système. Pour ce faire, la phase de
création doit répondre à ces questions :

 Que doit offrir le système pour l’utilisateur ?

 Quels sont les besoins fonctionnels et non fonctionnels ?

 Comment va être l’architecture du système ?

2. Présentation de la phase de création

Le but de la phase de création est de collecter assez d’informations pour établir une
vision initiale commune des objectifs du projet et de décrire suffisamment des cas
d’utilisation pour pouvoir décider le démarrage du projet.

3. Cahier de charge

Les stocks représentent les biens achetés qui interviennent dans le cycle d’exploitation
de l’entreprise ou aux termes d’un processus de production à venir. Dans notre cas, on tend à
créer une application web qui fait la gestion de parc informatique de la société «Attijari
Leasing» tout en assurant un suivi complet de tous les matériaux et leurs emplacements et
situations.

Il s’agit non seulement de recenser les différents types de matériel informatique

présents dans l’entreprise, leur nombre, leur localisation et les logiciels qui y sont installé
mais aussi de connaitre l’acquisition de ces matériels.

20
 Chapitre 2 : Phase d’Elaboration

3.1 Besoins

Attijari Leasing possède un nombre conséquent d’outils Informatique de toute sorte

qu’il faut connaitre et dont il faut suivre et maitriser les évolutions. D’ou le besoin d’un tel
projet qui a pour but d’inventorier le parc informatique avec tous ses matériels déjà installé
ou stockés (imprimantes, scanners,...), et les marques ainsi que le suivie de maintenance.
Aussi le système doit pouvoir assurer la gestion des utilisateurs (personnes, département,
permissions…). Suivie et gestion des comptes utilisateur.

3.2 Objectifs

Il s’agit de mettre en œuvre une base de donnés, ainsi qu’une interface graphique
associe, qui rend transparent pour l’utilisateur la gestion de cette base. Cette interface devra
être la plus simple, fiable, intuitive et contenant toutes les fonctionnalités demandés.

La base de données doit être une base SQL, compatible avec un serveur disponible à la
société. La gestion de cette base doit se faire par l’intermédiaire d’une interface graphique
réalisée en langage PHP et HTML.

Ainsi que les fonctionnalités de base que doit fournir tout outil de gestion de parc
Informatique digne de ce nom :

 Pouvoir suivre le contenu de stock en temps réel.

 Générer une statistique complète permettant de dégager de l’information utile pour
l’utilisateur.

 Pouvoir interroger la base des requêtes prédéfinies.

 Eviter la redondance des éléments stockés.

 Gérer la diversité du matériel et des caractéristiques.

 Suivre la maintenance des matériels.

 Gestion des comptes utilisateurs.

20
 Chapitre 2 : Phase d’Elaboration

4. Spécifications des besoins

Le système doit être opérationnel, évolutif, convivial et offrant les informations
nécessaires en temps réel. Pour ceci, le système à réaliser doit satisfaire les exigences de la
totalité des utilisateurs. Nous présentons dans ce qui suit tous les besoins fonctionnels et non
fonctionnels de notre travail.

4.1 Besoin fonctionnel

Les besoins fonctionnels sont les services que doit offrir le système, on peut regrouper ces
besoins en cinq parties :
Gesti Gestion
Gesti Gestion
on
on
Dépa Matérie
Dépa Matérie
rtem l
rtem l
ent
ent

GEST
GEST
ION
ION
DE
DE
PARC
PARC
INFO
INFO
RMA
Gestion RMA
Gestion TIQU Gestion
TIQU Gestion
E
E
Utilisat
Inventaire Utilisat
Inventaire eurs
s eurs
s Gestion
Gestion
Deman
Deman
de de
de de
travail
travail

Figure4 : Les Besoins Fonctionnels

20
 Chapitre 2 : Phase d’Elaboration

Dans ce paragraphe nous exposons l’ensemble des besoins aux quels devraient répondre
l’application de notre projet :

Gestion des utilisateurs : permet à l’Administrateur de gérer tous les utilisateurs de

système.
Gestion des Départements : Attijari Leasing contient plusieurs départements,
chacune possède une spécialité. Cette partie permet de gérer ces différents
départements.

Gestion matériel : c’est l’élément de base de la gestion du parc informatique, il nous

fournis des fiches détaillées par matériel contenant.

Gestion des Inventaires : représente des statistiques, permettant d’avoir des

informations sur le stock, les matériels installés, les demandes de travail, les
départements et les différents utilisateurs.

Gestion Demande de travail : permet à l’administrateur de système de traiter les

différentes demande de travail.

4.2 Besoins non Fonctionnel

A part les besoins fondamentaux, notre futur système doit répondre aux critères
suivants :

La rapidité de traitement  : En effet, vu le nombre important des transactions

quotidiennes, il est impérativement nécessaire que la durée d’exécution des
traitements s’approche le plus possible du temps réel.
La performance  : Un logiciel doit être avant tout performant c’est-à-dire à
travers ses fonctionnalités, répond à toutes les exigences des usages d’une
manière optimale.

La convivialité  : Le futur logiciel doit être facile à utiliser. En effet, les

interfaces utilisateurs doivent être conviviales c’est-à-dire simples,
ergonomiques et adaptées à l’utilisateur.

20
 Chapitre 2 : Phase d’Elaboration

5. Méthodologie de travail

L’objectif de toute approche de conduite de projet est d’obtenir des résultats fiables.
En fait, la fiabilité d’un système dépend de l’approche utilisée. Cette section est consacrée à
la présentation de la méthodologie adoptée pour mener à bien notre projet de fin d’étude.

5.1 Le cycle de vie adopté  

Comme processus de développement logiciel, nous avons adopté pour le processus

unifié offrant un cycle de vie logiciel itératif et incrémental. Le processus Unifié est un
processus particulièrement adapté pour le développement logiciel basé sur UML. C’est une
méthode générique, itératif et incrémentale, centrée sur l’architecture et pilotée par les cas
d’utilisation d’UML. « Bib1 »Ce processus peut être adopté à une large classe des systèmes
logiciels à différents domaines d’application, types, niveaux de compétences et tailles
d’entreprises. « Net2 »

Le processus unifié gère le processus de développement selon deux axes :

 L’axe vertical : représente les principaux enchainements d’activités au sein

d’une itération.
 L’axe horizontal : représente le déroulement dans le temps du processus en
termes d’itération et de phases.

20
 Chapitre 2 : Phase d’Elaboration

Figure5  : Cycle de vie de Processus Unifié «  Bib1  »

Le cycle de vie est composé de quatre phases : lancement, élaboration, construction et

transition.

 Phase de lancement :

La création est la phase au cours de laquelle on décide de l’opportunité de réaliser ou

non le projet.

Les objectifs principaux de la phase de création sont :

 Définir une vision partagée du projet, avec ce que contient ou non le produit, et
les critères d’acceptation.
 Déterminer les cas d’utilisation les plus critiques du système, les scénarii
donnant lieu aux principaux points d’interrogation sur la conception.

 Montrer, voir, démontrer, au moins une architecture qui se plie à ces différents
scénarii.

 Estimer les risques potentiels (les sources de l’imprévisibilité).

20
 Chapitre 2 : Phase d’Elaboration

 Estimer globalement les coûts et les délais du projet. 

 Phase d’Elaboration :

L’élaboration est la phase au cours de laquelle on vise à obtenir une architecture

stable du système pour avoir une base solide de l’effort de conception et d’implémentation
en phase de Construction.

L’architecture dépend :

 Des exigences qui ont le plus d’impact sur l’architecture du système.

 De l’évaluation des risques.

La stabilité de l’architecture est démontrée au moyen d’un ou plusieurs prototypes

d’architecture.

Les objectifs principaux de la phase d’élaboration sont :

 S’assurer l’architecture (à partir de scénarii significatifs), les exigences et les

plans sont assez stables, que les risques significatifs du point de vue de
l’architecture sont suffisamment atténués pour qu’on puisse élaborer des
prévisions fiables pour les coûts et la durée du développement restant.
 Produire un prototype évolutif avec des composants de qualité, de même qu’un
ou plusieurs prototypes ‘‘exploratoires ’’ jetables pour atténuer les risques
(changements de conception, d’exigences, réutilisation de composants,
faisabilité du produit).

 Démontrer que l’architecture supportera les exigences du système

 Phase de Construction :

La construction est la phase au cours de laquelle on réalise le système à partir de

l’architecture stabilisée. La phase de construction est en un sens l’étape de production, où
l’accent est mis sur la gestion des ressources et le contrôle des opérations pour optimiser les
coûts, les délais et la qualité.

20
 Chapitre 2 : Phase d’Elaboration

Les objectifs principaux de la phase de construction sont de :

 Minimiser des coûts de développement par l’optimisation des ressources. Il est

essentiel de disposer d’une architecture robuste si l’on veut atteindre un haut
degré de parallélisme de ces ressources.
 Atteindre la qualité adéquate rapidement.

 Produire des versions utilisables (alpha, bêta, et autres versions de test) aussi
vite que possible.

 Compléter l’analyse, la conception, le développement et le test de toutes les

fonctionnalités.

 Développer itérativement et de façon incrémentale un produit complet prêt à la

transition vers les utilisateurs.

 Décider si le logiciel, les sites et les utilisateurs sont prêts au déploiement de

l’application.

 Phase de transition :

Lors de la phase de Transition on s’assure que le logiciel est disponible pour les
utilisateurs finaux. La phase de transition peut s’étaler sur plusieurs itérations, inclure le test
du produit avant sa sortie et les ajustements mineurs basés sur les remarques faites par les
utilisateurs (pour de petites améliorations de la configuration, l’installation et les problèmes
d’utilisation).

A la fin de la phase de transition, les objectifs doivent avoir été atteints et le projet doit
être sur le point d’être clos.

Les objectifs principaux de la phase de transition sont :

20
 Chapitre 2 : Phase d’Elaboration

 L’accord des intervenants sur le fait que le déploiement de la version de

référence est terminé et conforme aux critères d’acceptation du produit.
 Le bêta test pour valider le nouveau système en fonction des attentes des
utilisateurs.

 L’installation des bases de données opérationnelles.

 La formation des utilisateurs et responsables de la maintenance.

 La correction des bugs, l’amélioration des performances et de l’utilisation.

 Il est aussi important d’atteindre l’autonomie de l’utilisateur sur le logiciel.

5.2 Langage de modélisation UML 

UML (Unified Modeling Language) est un méta- langage de modélisation orienté

objet unifiant les modèles utilisés dans les méthodes proposés en Génie Logiciel. Les
créateurs de ce langage sont Grady Booch, Ivar Jacobson et Jim Rummbaugh. « Bib4 »

C’est un langage standard en termes de modélisation objet, c’est un langage semi-

formel et normalisé. Il est reconnu pour sa polyvalence et sa performance.

En fait, UML définie neuf types de diagrammes, à savoir :

 Les diagrammes de classes

 Les diagrammes de séquence

 Les diagrammes de collaborations

 Les diagrammes d’objets

 Les diagrammes d’états- transitions

20
Chapitre 2 : Phase d’Elaboration

 Les diagrammes d’activités

 Les digrammes cas utilisation

 Les diagrammes de composants

 Les diagrammes de déploiement

Statique

Diagramme de Classes

Diagramme d’Objets

Diagramme de Composants

Diagramme de Déploiement

Diagramme de Use Case

20
 Chapitre 2 : Phase d’Elaboration

Fonctionnel

Diagramme de Use Case Dynamique

Diagramme d'Etats-Transitions

Diagramme d'Activités

Diagramme de Séquences

Diagramme de Collaborations

Figure6 : Axe de modélisation d’UML  «  Bib4  »

6. Diagrammes de cas Utilisation :

6.1 Définitions :

Les diagrammes de cas d'utilisation représentent les cas utilisation, les acteurs, et les

relations entre les cas utilisation et les acteurs. « Bib2 »

a. Un Acteur :

Les acteurs se représentent sous la forme de petits personnages ou via un symbole de

classe avec le mot clé « acteur ». Un acteur représente un rôle joué par une personne ou une
chose qui interagit avec un système. Ils se déterminent en observant les utilisateurs directs de
système. « Bib2 »

b. Un cas Utilisation :

Un cas d’utilisation est un classificateur qui modélise une fonctionnalité d’un

système ou d’une classe. L’instanciation d’un cas utilisation se traduit par l’échange de
message entre le système et ses acteurs. La relation entre un acteur et cas utilisation est une
association représentée par une ligne. 

20
 Chapitre 2 : Phase d’Elaboration

Dans un diagramme de cas d’utilisation un cas d’utilisation est symbolisé comme suit :

Use case

Figure 7  : cas d’utilisation

Pour mieux détailler les cas d’utilisation, UML définit trois types de relations
standards :

Relation d’inclusion (include) : Dans une relation d’inclusion entre cas d’utilisation
une instance du cas utilisation source comprend également le comportement décrit par
le cas utilisation destination. L’inclusion a un caractère obligatoire la source spécifiant
à quel endroit le cas utilisation cible doit être inclus.
Relation d’extension (extend) : Dans une relation d’extension entre cas d’utilisation,
les cas utilisation source ajoute son comportement au cas d’utilisation destination.
L’extension peut être soumise à une condition. Le comportement ajouté est inséré au
niveau d’un point d’extension défini dans le cas d’utilisation destination. « Bib2 »

Relation de généralisation : Dans une relation de généralisation entre deux cas

d’utilisation, le cas utilisation enfant est une spécialisation de cas d’utilisation parent.
Le cas d’utilisation parent peut être abstrait. « Bib2 »

6.2 Identification des acteurs :

20
 Chapitre 2 : Phase d’Elaboration

Gestionnaire de parc Service Demandeur

Administrateur

Figure 8  : Listes des acteurs

 L’Administrateur de système : Un Administrateur avec des privilèges

supérieurs lui permettant de gérer les comptes utilisateurs et contrôler le
fonctionnement de l’application, il est chargé de déployer et de dépanner le
système.
 Le Gestionnaire de parc : est une personne ayant un compte sur le site qui lui permet
acquérir les informations nécessaire sur l’application, possédant un identifiant et un
mot de passe.

 Le service Demandeur : c’est un utilisateur ayant un accès limité à

l’application, dont la tache est de saisir des demandes interne.

6.3 Diagramme de cas d’Utilisation global :

Le modèle de cas d’utilisation a servis pour formaliser les différents acteurs et leurs
différentes utilisations de système.

20
 Chapitre 2 : Phase d’Elaboration

Gestion
Utilisateurs

Remplir une formulaire

de bon_dem_travail

Gestionnaire Parc Gestion Matériel <<Include>>

Etablir Demande de
Travail
Gestion Demande de Service Demandeur
Travail

Administrateur
Gestion
Départements

Gestion Inventaire

Figure 9  : «  Diagramme de cas Utilisation Global  » 

6.4 Raffinement des cas d’Utilisation :

A. Cas utilisation «  Authentification »

20
 Chapitre 2 : Phase d’Elaboration

<<Include>> Introduire
Login

Gestionnaire Parc <<Include>>

S'authentifier
Introduire mot
de passe

<<Include>>

Introduire
Grade

Administrateur

Figure 10 : Diagramme cas utilisation «  Authentification  »

S’Authentifier : En tapant son grade, son login et son mot de passe, l’administrateur
de système peut accéder à l’application pour effectuer des traitements, et le gestionnaire de
parc peut accéder à l’application avec un droit d’accès limité, L’utilisateur qui se connecte
doit être reconnu du système. L’authentification est le mécanisme qui protège le système des
intrusions externe.

20
 Chapitre 2 : Phase d’Elaboration

B. Cas utilisation « Gestion Utilisateur »

Rechercher
Utilisateur

Ajouter Utilisateur
Gérer Utilisateur
Administrateur

Mise à jour
Utlisateur Modifier Utilisateur

<<Extend>> Supprimer Utilisateur

Imprimer Liste
Utlisateur

Figure  11 : Diagramme cas utilisation <<Gestion utilisateur>>

Gérer compte utilisateur : L’Administrateur de système a tous les droits d’accès, il

gère tous les utilisateurs, il peut Ajouter/Rechercher, Modifier /Supprimer les comptes
utilisateurs.

20
 Chapitre 2 : Phase d’Elaboration

C. Cas utilisation « Gestion Demande De Travail »

Rechercher
Demande

Gestionnaire Parc

Traiter Demande de
Travail

Créer Demande

Mise à jour
Demande
Modifier Demande

Administrateur

<<Extend>> Annuler Demande

Imprimer Liste
Demande

Figure 12  : Diagramme cas utilisation  «  Gestion Demande de travail  »

 Etablir une demande de travail : donne la possibilité aux services demandeurs d’exprimer
leurs besoins envers l’Administrateur de système

 Remplir Formulaire de bon de demande de travail  : pour exprimer leurs besoins, le service
demandeur doit remplir une formulaire qui s’appelle bon de demande de travail, contenant
un ensemble des éléments concernant cette Demande de travail.

20
Chapitre 2 : Phase d’Elaboration

 Traiter une demande de travail  : Permet à l’Administrateur d'effectuer des opérations sur
les commandes internes. Ces opérations concernent : l'ajout, la modification, la recherche,
l’enregistrement, et l’annulation.

 Ajouter une demande de travail : Lorsqu'un demandeur se présente à l’Administrateur

muni d’une demande de travail signé, un bon de demande de travail lui est établi.

 Modifier une demande de travail : Un bon de demande de travail doit être modifiable,
l’Administrateur peut se tromper en remplissant les informations communiquées, la
modification de l'erreur est envisagée.

 Rechercher une demande de travail:  Toute opération de mise à jour (modification ou

suppression) d'un bon de sortie doit être précédée par une opération de recherche. Le
critère de recherche demandé est le numéro de bon de demande de travail.

 Annuler une demande de travail: Le système doit offrir à l’Administrateur la possibilité

d’annuler un bon de demande de travail lorsque le demandeur remet les articles qui lui
étaient déjà installé.

20
 Chapitre 2 : Phase d’Elaboration

D. Cas utilisation «  Gestion matériel  »

Rechercher
Matériel

Gestionnaire Parc
Gérer Matériel

Ajouter Matériel

Mise à jour
Matériel
Modifier Matériel

Administrateur

Imprimer Liste
Matériel
Supprimer Matériel

Figure 13: Diagramme cas utilisation  << Gestion matériel >>

 Gérer matériel : Permet à l’Administrateur d'effectuer des opérations sur les matériels de
parc informatique. Ces opérations concernent : l'ajout, la modification, la suppression et la
recherche.

 Ajouter un matériel : Ce cas d'utilisation donne à l’Administrateur la possibilité d'ajouter

un matériel qui s’enregistre comme un entré en stock de parc informatique.

 Modifier un matériel : Un matériel doit être modifiable, l’Administrateur peut se tromper
en remplissant les informations communiquées, la récupération de l'erreur est envisagée.

20
 Chapitre 2 : Phase d’Elaboration

 Rechercher un matériel : Toute opération de mise à jour (modification ou suppression)

d'un matériel doit être précédée par une opération de recherche.

 Supprimer un matériel : Ce cas d’utilisation donne à l’Administrateur la possibilité de

supprimer un matériel qui s’enregistre comme une sortie de stock de parc informatique.

E. Cas d’utilisation : Gestion des Départements

Rechercher
département

Ajouter
Gérer Département
Gesttionnaire de parc
Département

Modifier
<<Extend>> Mise à jour département
département

Administrateur
Supprimer
Imprimer Liste département
département

Figure 14: Diagramme cas utilisation  «  Gestion Départements  »

20
 Chapitre 2 : Phase d’Elaboration

F. Cas d’utilisation «  Gestion Inventaire »

Rechercher
inventaire

Gérer
Gestionnaire de prac Inventaire
<<Extend>>

Imprimer Liste
Inventaire

Administrateur

Figure15  : Diagramme cas d’utilisation   «  Gestion Inventaire  »

 Gérer Inventaire : Ce cas utilisation Donne la possibilité d’avoir des

informations sur le stock des matériels informatique.

20
 Chapitre 2 : Phase d’Elaboration

4. Conclusion

Durant la phase de création, nous avons établi une mission approximative de la

finalité du projet et nous avons effectué des investigations pour avoir une opinion
rationnelle et justifiable de la finalité globale et de la faisabilité du système, et pour
décider qu’il mérite une étude approfondie en phase d’élaboration.

20