samedi 11 avril 2015

[new] Country state module

During developping of my car ads site (SeraVendu), i need a custom field to stores country/state data to each content type, so there is a dev module Country State witch creates new vocabulary where we're going to set and charge  our list of countries/states.


       manage field location field screenshot (example)

manage display location field screenshot (example)


setting location field screenshot
(example)


Link to code

dimanche 5 avril 2015

Recommendation de mon ancien chef de projet


Module "Facebook post node"

Facebook post node
facebook_post_node  the machine name of the new module.
It allows users to share any node on theirs facebook wall, you only have to create a facebook application and paste app id and secret key provided by facebook on your module configuration form. And as result a simple widget will show up under full screen node you only have to click and see your wall.



Lien git hub

vendredi 3 avril 2015

Projet Seravendu - Conception et réalisation de site de petites annonces voitures (Drupal)


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.
 





Figure 1 : Page d'accueil


                                                         Figure 2 : Page gestion des utilisateurs







                                            Figure 1 : Page gestions des annonces voitures







IV.  Histoires utilisateurs (Users story):

  1. Ajout client:

      2. Mettre à jour client:



     3. Suppression client:


4. Ajouter annonce voiture:

  
5. Supprimer annonce voiture:


6. Mettre à jour annonce voiture:


7. Lister et chercher annonce voiture:

8. Ajouter demande voiture:


 9. Supprimer demande voiture:


10. Mettre à jour demande voiture:


11. Lister et chercher demande voiture: