Blel Marouane: avril 2015

Sera Vendu:

site de petites annonces voitures

réalisé en Drupal

Réalisé par:

Blel Marouane

Planification et architecture

Introduction

Dans cette partie, nous allons procédés à identifier les rôles des utilisateurs et dégager les fonctionnalités principales de notre application.

I. spécification des besoins

I.1. Identification des acteurs

a. Les acteurs

« Un acteur représente l'abstraction d'un rôle joué par des entités externes (utilisateur, dispositif matériel ou autre système) qui interagissent directement avec le système étudié. » [1]

Tout simplement un acteur est une entité physique (personne) ou abstraite (logiciel) capable d'utiliser le système afin de répondre à un besoin bien définit. Les acteurs de notre application sont:

L'administrateur: c'est le personne possédant le privilège de plus haut niveau. Cet acteur est capable de manipuler toutes les fonctionnalités proposées par l'application notamment l'ajout des autres acteurs, rôles, etc. Il s'agit principalement d'un personne qualifié en configuration de CMF Drupal.

Le webmaster: celui qui s'occupe de la gestion des annonces et des clients et d'autres fonctionnalités attribués par l'administration.

Le client: toute personne qui veut publier une annonce voiture sur le site.

La société: toute société qui veut publier des annonces sur le site avec différence à celui le client qu'elle est plus professionnel.

b. Diagramme d'organisation:

I.2. Les besoins fonctionnels:

Les besoins fonctionnels ou les cas d'utilisation en UML peuvent être définis comme suit: « Un cas d’utilisation (use case) représente un ensemble de séquences d’actions réalisées par le système et produisant un résultat observable intéressant pour un acteur particulier. » [2]

Une cas d'utilisation est une suite d'actions effectués par le système afin de répondre à une demande d'un utilisateur (acteur). Dans ce qui suit, nous décrivons les différents besoins fonctionnels de notre système:

Gestion des clients: Consiste à gérer tout les clients

Gestion des sociétés: Consiste à gérer toutes les sociétés

Gestion des annonces: Consiste à gérer tout les annonces de site.

Gestion des fabricants: Consiste à gérer toutes les marques de voitures et leurs modèles.

Gestion de site: Consiste à gérer les pages de site, thèmes, bandeau filant et réclamations des clients, etc.

I.1. Les besoins fonctionnels:

Les besoins non fonctionnels sont des besoins qui ont un aspect visible pour l'utilisateur, mais qui ne sont pas reliés directement au comportement du système. Les besoins non fonctionnels de notre système se décrivent comme suit:

Besoins de disponibilité: Il est disponible que l'application soit disponible à tout moment.

Besoins de sécurité: vu que cette application contient des données confidentielles, tels que le numéro de téléphone, l'email de client, tous les accès aux différents espaces doivent être protégés par un mot de passe et un privilège d'accès, aussi il faut protéger les emails et les numéros de téléphone contre les logiciels bots. Ainsi, il faut s'assurer des cryptages de données au niveau de la base.

Besoins de performance: Il s'agit d'optimiser le temps de chargements des pages par la création des index, optimisation des requêtes ainsi par des bonnes pratiques su développement.

Besoins de portabilité et de compatibilité: Notre application doit être portable sur tous les environnement logiciels et compatible avec les autres services développés.

Besoins de documentation: Lors de la livraison de l'application, nous devons fournir la documentation nécessaire pour les utilisateurs finaux ainsi que les futurs développeurs.

Besoins d'utilisation: Tous les standards d'ergonomies doivent être présents: interface utilisateur bien clair et simple dans l'utilisation.

II. Planning du traitement des cas d’utilisation

Après tout le travail d'identification des cas d'utilisation, nous devons maintenant les classifier. La classification des cas d'utilisation doit tenir compte de deux facteurs principaux qui sont la priorité et les risques. Cette technique est utilisée généralement lors de la conception des applications se basant sur le processus unifié, mais elle reste valable et intéressante pour notre cas.

II.1. Priorités

Généralement, on dit qu'un cas d'utilisation A est plus prioritaire que B, si sa réalisation accélère la stabilisation du système. Le choix des priorités dans cette section s'est basé sur la dépendance entre fonctionnalités de l'application. Par exemple, nous ne pouvons pas affecter les annonces tant que nous n'avons pas encore terminer la gestion des utilisateurs et celles des annonces et des marques. Par conséquent, nous pouvons dégager trois niveaux de priorité qui sont: haute, moyenne et faible.

I.1. Risques

Lors du pilotage d'un projet, l'identification des risques critiques présente une étape indispensable pour la réussite de ce dernier.

III. Prototypage des interfaces

Dans le domaine du web, une technique est apparue et prend une place très importante dans le développement des applications Web; il s'agit du prototypage. Cette technique consiste à préparer quelques interfaces graphiques de l’application en utilisant un outil de conception de prototypes afin de mesurer le degré de satisfaction du client par rapport à la compréhension du projet par le développeur. L’interaction qui se produit entre l’utilisateur final et le développeur, à la suite de la discussion sur ces interfaces, permet d’ajuster les besoins et de les concevoir de manière précise et exacte. En effet, les interfaces graphiques font que l’utilisateur final soit plus interactif, précis et le poussent à mieux s’exprimer quant à ses attentes. Ci-dessus quelques interfaces réalisées avec l’outil WireFrame.