18
Chapitre I : Cadre Général du Projet A cours de ce chapitre, nous allons étudier le cadre générale du projet. Cette étude comprend la présentation de l’entreprise dans laquelle s’est déroulé le stage ainsi qu’une petite présentation du projet.

Prototype rapport

Embed Size (px)

Citation preview

Chapitre I : Cadre Général du Projet A cours de ce chapitre, nous allons étudier le cadre générale du projet. Cette étude comprend la présentation de l’entreprise dans laquelle s’est déroulé le stage ainsi qu’une petite présentation du projet.

Chapitre I : Cadre Général du Projet

Titre projet Page 2

Introduction Au cours de ce premier chapitre, nous allons étudier le cadre générale du projet.

Dans un premier temps, une brève présentation de l’organisme d’accueil sera effectuée. Et

dans un second temps, nous décrivons le contexte du projet proposé ainsi que la

problématique et le travail demandé.

I- Présentation de l’organisme d’accueil

Media Plus imagine et construit

des sites web fonctionnels et attractifs

aux dernières technologies tels que le

responsive. Avec un effectif formé d’un

groupe solide et dynamique de

professionnel de l’infographie, du web

design et du développement web, l’agence Media Plus vous propose des services variés tel

que :

WEB DESIGN :

- La création d’un graphisme en adéquation avec votre identité visuelle actuelle

- Flash, Photoshop, Illustrator

INTEGRARTION WEB :

- La programmation de votre site avec HTML5, CSS3, JavaScript, jQuery

- L’hébergement de votre site en toute sécurité

COMMUNICATION PAPIER :

- Catalogue produits, magazine, Menu de restaurant ou de café, Couverture de livre

- Dépliant publicitaire, Flyers, affiches publicitaires

- Brochure publicitaire, carte de visite, papier à entête, Modèle de facture...

IDENTITE VISUELLE – CHARTE GRAPHIQUE :

- Création de logo, conception habillage, Enseigne

- Plaquette, Porte Document, Enveloppe

- Création ou refonte d’identité visuelle.

WEB MOBILE :

- Android, IPhone OS, Windows mobile

NOUVELLE ACTIVITE :

- Impression Numérique laser

Chapitre I : Cadre Général du Projet

Titre projet Page 3

Nous avons fait le compromis de vous satisfaire et de créer l’image la plus excitante

et attrayante de votre entreprise et de vous fournir les solutions informatiques les plus

adaptées à vos besoins pour vous aider à atteindre vos objectifs.

Que vous soyez un particulier ou une petite ou grande entreprise, nous vous invitons

à entendre notre manière de penser, nous proposons nos produits et solutions, collaborons

avec vous pour mener à bien vos projets.

Nous demeurons à votre entière disposition pour toute précision.

Dans l’attente de vous lire, nous vous prions d’agréer, chers partenaires, nos

salutations les plus sincères.

II- Présentation du projet

Présenter votre projet en quelques lignes.

Exemple :

L’évolution de la technologie de l’information et de la communication a contribué au

développement des systèmes d’information et de gestion au sein des entreprises. En effet

l’intégration de l’outil informatique dans le domaine de l’entreprise est devenue une

nécessité dont l’enjeu est déterminant face au processus d’amélioration des qualités de

service et des conditions de travail.

Le sujet de notre projet de fin d’études consiste à développer …

L'objectif de ce stage est de concevoir et développer …

III- Travail demandé

Présenter le travail demandé (les principales fonctionnalités à implémenter dans votre

application)

Conclusion C’est ainsi que nous sommes parvenus à définir le cadre général de ce stage et le

contexte large du projet à réaliser. Le prochain chapitre aura pour objectif la présentation

des solutions existantes, les insuffisances qu’elles apportent ainsi que la solution future.

Chapitre II : Etude de l’existant Ce chapitre représente une étude bien déterminée de l’existant, ses critiques et ses orientations futures favorables.

Chapitre II : Etude de l’existant

Titre projet Page 2

Introduction L’étape de l’étude de l’existant est une étape primordiale dans la réalisation de tout

projet informatique. Cette étape préalable fera l’objet de ce chapitre et permettra de décrire

le système existant, de dégager les insuffisances de l’état actuel et de proposer les

orientations de la solution future. Il est indispensable si c’est possible avant de se lancer

dans la réalisation de tout projet, de bien étudier et analyser des projets similaires s’il existe

pour profiter des avantages et éviter les malveillances dans le présent projet.

I- Description de l’existant

Si l’application à développer est pour un système non informatisé qui n’existe pas

déjà donc à décrire les fonctionnalités qui existe manuellement, ou à travers des

manipulations des fichiers Excel ou autres…

Si le système possède déjà une application mais qui contient des trous et des

insuffisances alors décrire ce qui existe en mettant en relief les points positifs et en citant

aussi les points négatives pour y remédier.

S’il existe des applications pareilles dans le même domaine alors décrivez les

applications existantes, leurs fonctionnalités, les avantages pour pouvoir les critiquer par la

suite. Vous pouvez mettre des imprimes écrans des applications qui existent et les décrire

selon leur contenus.

II- Critique de l’existant

III- Orientation de la solution future

Conclusion En se basant sur la critique de l’existant, nous allons déterminer les différentes

améliorations qui permettent de garantir le bon fonctionnement et la bonne gestion de

notre application. Après avoir mis le sujet dans son cadre théorique, il est temps d’identifier

les différents besoins afin de recenser la liste des fonctionnalités qui doivent être présentes

Chapitre III : Analyse & spécification des besoins Ce chapitre représente une vision approximative de la finalité du projet qui consiste à comprendre le contexte du système à réaliser en recensant à la fois les besoins fonctionnels et les besoins non fonctionnels. Et nous présentons la conception de notre projet avec les diagrammes de cas d’utilisations.

Chapitre III : Analyse & spécification des besoins

Titre projet Page 2

Introduction L’analyse, étant considérée comme une première ébauche du modèle de conception,

joue un rôle capital pour la démarche ergonomique. Cette analyse s’intéresse aux besoins et

aux attentes des utilisateurs en général. Il s’agit de modéliser les éléments et les

mécanismes principaux du nouveau système, ainsi que de livrer des spécifications pour

permettre de choisir la conception de la solution.

Une méthode d'analyse et de conception a pour objectif de permettre de formaliser

les étapes préliminaires du développement d'un système afin de rendre ce développement

plus fidèle aux besoins du client.

Ce modèle d’analyse permet d’avoir une spécification complète des besoins issus des

cas d’utilisation et les structures sous une forme (diagrammes d’activités, séquences, états

transitions, …etc.) qui facilite la compréhension, la préparation (définition de l’architecture),

la modification et la maintenance du système.

I- Langage et méthodologie utilisés

Modéliser un système avant sa réalisation permet de mieux comprendre le

fonctionnement du système. C’est également un bon moyen de maitriser sa complexité et

d’assurer sa cohérence. Un modèle est en effet un langage commun, précis, qui est connu

par tous les membres d’une équipe et il est donc un vecteur privilégié pour communiquer.

Dans le domaine de l’ingénierie du logiciel, ce modèle permet de mieux répartir les

tâches et d’automatiser certaines d’entre elles. C’est également un facteur de réduction des

coûts et des délais. Ce modèle est enfin indispensable pour assurer un bon niveau de qualité

et une maintenance efficace car, une fois mise en production, l’application va devoir être

maintenue, probablement par une autre équipe et pas nécessairement la même ayant créée

l’application.

Un processus de développement définit une séquence d’étapes, en partie ordonnée,

qui concoure à l’obtention d’un système logiciel ou à l’évolution d’un système existant pour

produire des logiciels de qualité, qui répondent aux besoins des utilisateurs dans des temps

et des coûts prévisibles.

1) Méthodologie de conception

Plusieurs méthodologie de conception et à vous de chercher quelle méthodologie adoptée.

Exemple de choix de méthodologie de conception : Processus Unifié (UP)

Les méthodes de développement dites « méthodes agiles » visent à réduire le cycle

de vie du logiciel (donc accélérer son développement) en développant une version minimale,

puis en intégrant les fonctionnalités par un processus itératif basé sur une écoute client et

des tests tout au long du cycle de développement. On peut citer parmi les méthodes agiles

Chapitre III : Analyse & spécification des besoins

Titre projet Page 3

l’UP (Unified Process) qui est en mesure de répondre directement ou indirectement à

diverse problématiques notamment financières ou temporelles.

Le processus unifié (UP) est un processus de développement logiciel « itératif et

incrémental, centré sur l’architecture, conduit par les cas d’utilisation et piloté par les

risques » :

Itératif et incrémental : Le projet est découpé en itérations de courte durée (environ

un mois et demi) qui aident à mieux suivre l’avancement global. À la fin de chaque

itération, une partie exécutable du système final est produite de façon incrémentale.

Centré sur l’architecture : Tout système complexe doit être décomposé en parties

modulaires afin de garantir une maintenance et une évolution facile. Cette

architecture (fonctionnelle, logique, matérielle, … etc.) doit être modélisée en UML et

pas seulement documentée en texte.

Conduit par les cas d’utilisation : Le projet est mené en tenant compte des besoins et

des exigences des utilisateurs. Les cas d’utilisation du futur système sont identifiés,

décrits avec précision et priorisés.

Piloté par les risques : Les risques majeurs du projet doivent être identifiés au plus

tôt, mais surtout levés le plus rapidement possible. Les mesures à prendre dans ce

cadre déterminent l’ordre des itérations.

Le processus que nous avons utilisé pour le développement de notre système,

comme c’est présenté dans la

figure ci-contre, est:

Itératif et conduit par les

cas d’utilisation, comme

UP mais beaucoup plus

simple ;

Relativement léger et

restreint, comme les

méthodes agiles, mais sans

négliger les activités de

modélisation en analyse et

conception ;

Fondé sur l’utilisation des

diagrammes du langage

UML 2.0 (Unified Modeling

Language), conformément

à la modélisation agile

(Agile Modeling).

Chapitre III : Analyse & spécification des besoins

Titre projet Page 4

2) Langage de conception

UML (Unified Modeling Language) est un langage de modélisation graphique apparu

dans le monde du génie logiciel dans le cadre de la conception orientée objet. C’est

l’accomplissement de la fusion de précédents langages de modélisation objet : Booch, OMT,

OOSE. UML est à présent un standard défini par l’OMG (Object Management Group). La

dernière version diffusée par l’OMG est la 2.4.1 depuis août 2011 *4+.

UML est utilisé pour spécifier, visualiser, modifier et construire les documents

nécessaires au bon développement d'un logiciel orienté objet. UML offre un standard de

modélisation, pour représenter l'architecture logicielle. Les différents éléments

représentables sont :

Activité d'un objet/logiciel,

Acteurs,

Processus,

Schéma de base de données,

Composants logiciels,

Réutilisation de composants.

Grâce aux outils de modélisation UML, il est également possible de générer

automatiquement une partie de code, par exemple Java, à partir des divers documents

réalisés.

UML 2.0 propose 14 types de diagrammes et comme n’étant pas une méthode, leur

utilisation est laissée à l’appréciation de chacun et la nature du projet. Par exemple, les

diagrammes utilisés pour un projet d’application mobile diffèrent de ceux utilisés pour un

site web.

Chapitre III : Analyse & spécification des besoins

Titre projet Page 5

II- Spécification des besoins

1) Les besoins fonctionnels

Dans cette section du chapitre, nous nous intéressons aux besoins des utilisateurs

traités dans notre projet c’est à dire l’inscription du client, le choix des produits, le

lancement des commandes enfin la confirmation et donc le payement en ligne à travers les

spécifications fonctionnelles et non fonctionnelles pour aboutir à un site de qualité qui

répond aux besoins des clients.

Selon le cahier de charge, les besoins changent d’un projet à un autre. Vous allez citer

dans cette partie les besoins fonctionnels de votre application.

Exemple :

Les besoins fonctionnels se présentent en huit grandes parties :

Exposition des produits ainsi que leurs prix et caractéristiques.

Inscription des clients.

Ajout des produits choisis au panier.

Choix du mode de livraison.

Choix de la boutique de livraison.

Confirmation de la commande.

Le payement en ligne.

Confirmation de l’opération d’achat et la réception de la facture.

a) L’EXPOSITION DES PRODUITS:

Notre site doit disposer d’une vitrine virtuelle à travers laquelle le client peut

consulter une grande variété des produits, il sera donc indispensable d’y présenter les prix et

les caractéristiques techniques de chaque produit pour faciliter la sélection du produit à

acheter.

b) L’INSCRIPTION DU CLIENT :

Jusqu’à ce stade, le client est toujours anonyme mais pour pouvoir passer à un stade

plus rigoureux, il faut qu’il s’inscrive, ce la se fait uniquement pour la première commande

mais après, notre client peut s’authentifier avec son E-mail et son mot de passe pour passer

d’autres commandes.

c) AJOUT DES PRODUITS AU PANIER :

Après le choix d’un produit le client doit mentionner la quantité qui s’ajoute

automatiquement à son panier avec le prix unitaire et le prix total.

Chapitre III : Analyse & spécification des besoins

Titre projet Page 6

d) MODE DE LIVRAISON :

Un client qui a déjà confirmé sa commande il est libre de choisir le mode de livraison

de sa marchandise soit à domicile ou chez une boutique selon une liste de chois mentionnée

sur notre site web.

e) BOUTIQUE DE LIVRAISON:

Si le mode de livraison choisi est la boutique il faut que le client indique cette

boutique avec une précision qui permet aux livreurs d’être sûrs que la marchandise sera

dans le bon lieu et dans les rendez-vous, ayant une panoplie de boutiques réelles, le client

pourra choisir la plus proche.

f) LA LIVRAISON A DOMICILE :

En choisissant cette option comme mode de livraison, le client devrait remplir

soigneusement un formulaire contenant les informations nécessaires telles que :

Le nom du destinataire qui peut être le client même ou une autre personne.

L’adresse précise de livraison.

Le numéro de la pièce d’identité du destinataire.

Le jour et l’heure de la livraison estimés.

g) LA CONFIRMATION DE LA COMMANDE :

Jusqu’à cette phase on a un client, une commande et une adresse de livraison le

chemin maintenant est plus clair, la commande ne passera qu’après la validation de toutes

les informations qui sont affichées dans une seule interface avant de passer à la phase de

payement.

h) LE PAYEMENT :

C’est une phase très sensible, pour cela il faut qu’elle soit très sécurisée, pour

terminer la procédure de payement avec succès le client doit choisir un mode de paiement

proposées sur notre site web (paiement par cheque, paiement contre remboursement,

paiement espèce, paiement chez la boutique…).

i) LA FIN DE L’OPERATION D’ACHAT:

La page finale représente un petit message de remerciement à nos clients avec une

idée sur l’adresse, la date, le temps de la livraison en question et bien sur la possibilité

d’imprimer la facture du client.

Chapitre III : Analyse & spécification des besoins

Titre projet Page 7

Il faut détailler les autres fonctionnalités, ce n’est qu’un exemple pour vous faire

comprendre quoi mettre.

2) Les besoins non fonctionnels

Les besoins non fonctionnels sont importants car ils agissent de façon indirecte sur le

résultat et sur le rendement de l’utilisateur, ce qui fait qu’ils ne doivent pas être négligés,

pour cela il faut répondre aux exigences suivantes :

Fiabilité: L’application doit fonctionner de façon cohérente sans erreurs et doit être

satisfaisante.

Les erreurs : Les ambigüités doivent être signalées par des messages d’erreurs bien

organisés pour bien guider l’utilisateur et le familiariser avec notre application.

Ergonomie et bonne Interface : L’application doit être adaptée à l’utilisateur sans

qu’il ne fournisse aucun effort (utilisation claire et facile) de point de vue navigation

entre les différents modules, couleurs et mise en textes utilisés.

Sécurité : Notre solution doit respecter surtout la confidentialité des données

personnelles des clients qui reste l’une des contraintes les plus importantes dans les

sites web.

Aptitude à la maintenance et la réutilisation : Le système doit être conforme à une

architecture standard et claire permettant sa maintenance et sa réutilisation.

Compatibilité et portabilité : Un site web quel que soit son domaine, son éditeur et

son langage de programmation ne peut être fiable qu’avec une compatibilité avec

tout les navigateurs web et tous les moyens que ce soit PC, IPAD ou Mobiles.

III- Identifications des acteurs

Définir les acteurs selon votre projet. Décrire chaque acteur à part et citer les

fonctionnalités de chacun si vous voulez dans un tableau.

Exemple :

Le visiteur : c’est un individu qui est entrain de fouiller sur le net, cherchant un

produit pour l’acheter ou pour avoir une idée sur les modèles et les prix. Jusqu’au ce stade

c’est un utilisateur inconnu donc il n’est pas encore un client.

Le Client : cette acteur est un visiteur ayant déjà créer un compte sur notre site, il

peut donc suivre le processus d’achat des produits en toute sécurité sachant que notre

système doit être l’unique responsable de la confidentialité des données personnelles de ses

clients.

Chapitre III : Analyse & spécification des besoins

Titre projet Page 8

L’administrateur : pour les sites web on l’appelle généralement « le webmaster ».

C’est celui qui assure le dynamisme du site et veille sur les mises à jour des produits, de leurs

prix, de leurs disponibilités, de la gestion des payements et la gestion des livraisons.

IV- Diagrammes de cas d’utilisation

Les cas d’utilisation sont très utiles en phase de recherche de besoin. L’approche

consiste à regarder le système à construire de l’extérieure, du point de vue de l’utilisateur et

des fonctionnalités afin de déterminer ses besoins fonctionnels c'est-à-dire ce qu’il attend du

système.

1) Diagramme de cas d’utilisation global

Mettre le diagramme de cas d’utilisation global de votre système.

Figure : Diagramme cas d’utilisation global

2) Diagramme de cas d ’utilisation Détaillé

Vous aller détailler les différents cas d’utilisation de votre système à mettre en

œuvre.

Chapitre III : Analyse & spécification des besoins

Titre projet Page 9

Mettre en relief surtout les fonctionnalités primordiales (Mettre le diagramme de cas

d’utilisation, écrire un petit paragraphe descriptif et mettre un tableau détaillant les

scénarios.)

a) Description scénario cas d’utilisation « Authentification »

Pour que l’utilisateur puisse bénéficier de n’importe quel service de l’application, il

doit avant tout s’authentifier avec son login et son mot de passe.

Figure : Diagramme de cas d’utilisation « Authentification »

Patron textuel du cas d’utilisation « Authentification»

Sommaire d’authentification

Nom : S’authentifier

Résumé : Le système vérifie l’identité de l’utilisateur en utilisant son

pseudo et son mot de passe.

Acteur : Citer les acteurs …

Pré-condition L’utilisateur doit être inscrit : possède un compte.

Description du scénario : 1) L’utilisateur introduit son login et son mot de passe.

2) L’utilisateur confirme son identification

3) Le système vérifie les informations fournit par

l’utilisateur

4) Le système autorise ou refuse l’accès à l’application

Exception : Affichage d’un message d’erreur dans le cas ou le mot de

Chapitre III : Analyse & spécification des besoins

Titre projet Page 10

passe ou le pseudo est incorrect ou invalide

Post-condition : Utilisateur authentifié

b) Description scénario cas d’utilisation « Gestion Discipline »

Exemple de cas d’utilisation détaillé de la gestion des disciplines.

Figure : Diagramme de cas d’utilisation « Gestion Discipline »

c) Description scénario cas d’utilisation « Gestion Compte »

L’administrateur est le responsable de la gestion des comptes, il peut :

Créer un nouveau compte : la création se fait après avoir fournir les données

nécessaires (nom, prénom, tél, email, adresse, login et mot de passe…)

Consulter un compte : la consultation se fait à travers certains critères spécifiques

pour chaque compte. L’utilisateur peut déjà consulter les paramètres de son compte.

Supprimer un compte : après la consultation des données relatives à un compte,

l’administrateur peut les supprimer.

Modifier les paramètres d’un compte : cette fonctionnalité consiste à modifier les

données du paramètres compte et les remplacer par des nouvelles données.

Exemple de cas d’utilisation détaillé de la gestion des disciplines.

Chapitre III : Analyse & spécification des besoins

Titre projet Page 11

Figure : Diagramme de cas d’utilisation « Gestion Compte »

Patron textuel du cas d’utilisation « Créer Compte »

Sommaire créer compte

Nom : Créer compte

Résumé : Création d’un nouveau compte

Acteur : Administrateur

Pré-condition Utilisateur authentifié

Description du scénario : 1. L’utilisateur choisit l’option « Créer compte » 2. L’utilisateur fournit les informations nécessaires du

compte approprié 3. L’utilisateur valide l’ajout 4. Le système vérifie les informations 5. Le système enregistre les informations fournies par

l’administrateur 6. Le système renvoie un message d’ajout effectué.

Exception : Si le compte (apprenant, tuteur) existe déjà, donc le système affiche un message d’utilisateur existant.

Post-condition : Compte créé

Chapitre III : Analyse & spécification des besoins

Titre projet Page 12

Patron textuel du cas d’utilisation « Modifier Compte »

Sommaire Modifier Compte

Nom : Modifier compte

Résumé : Modifier les paramètres du compte

Acteur : Acteur : Administrateur, Etudiant

Pré-condition Utilisateur authentifié

Description du scénario : 1. L’utilisateur sélectionne le paramètre de « Modification

paramètres » 2. L’utilisateur fournit les nouvelles données (Email, Tel,

Adresse, mot de passe…) 3. Le système vérifie les données 4. Le système enregistre les modifications 5. Le système renvoie un message pour informer

l’administrateur que la modification est effectuée avec succès.

Exception : Si les nouvelles données sont erronées donc le système affiche un message de saisie erronée.

Post-condition : Paramètres compte mis à jour

Patron textuel du cas d’utilisation « supprimer Compte »

Sommaire Supprimer Compte

Nom : supprimer compte

Résumer : Supprimer compte

Acteur : Acteur : Administrateur.

Pré-condition Utilisateur authentifié et compte existant

Description du scénario : 1. L’utilisateur sélectionne le compte à supprimer 2. L’utilisateur confirme la suppression 3. Le système supprime le compte en question. 4. Le système renvoie un message pour informer

l’administrateur que la suppression est effectuée avec succès

Chapitre III : Analyse & spécification des besoins

Titre projet Page 13

Exception : Pas d’exception

Post-condition : Compte supprimé

Patron textuel du cas d’utilisation « Consulter Compte »

Sommaire Consulter Compte

Nom : Consulter compte

Résumer : L’utilisateur peut consulter les paramètres du son compte.

Acteur : Administrateur, Etudiant

Pré-condition Utilisateur authentifié et compte existant

Description du scénario : 1. L’utilisateur accède à son espace de paramètre compte 2. Le système recherche les données du compte approprié 3. Le système affiche les informations du paramètre du

compte concerné.

Exception : Pas d’exception

Post-condition : Compte consulté

A compléter tout les diagrammes de cas d’utilisation primordial dans votre application.

Conclusion En se basant sur la critique de l’existant, nous allons déterminer les différentes

améliorations qui permettent de garantir le bon fonctionnement et la bonne gestion de

notre application. Après avoir mis le sujet dans son cadre théorique, il est temps d’identifier

les différents besoins afin de recenser la liste des fonctionnalités qui doivent être présentes