BUS ROUTE

Presentation du projet

Le « projet DTC » est une application mobile qui aide les gens à trouver les
lignes de bus jusqu'à leur destination souhaitée et le tarif.

Le système du projet DTC est composé de deux composants principaux : une

application côté client qui fonctionnera sur les téléphones Android et une
application côté serveur qui prendra en charge et interagira avec les
requêtes côté client.

Les utilisateurs propriétaires fournissent leurs informations de destination à

l'aide du portail Web.

Le portail Web vérifie les connexions en tant que passager ou administrateur

et gère les informations utilisateur. Les données seront conservées dans une
base de données Access sur le serveur DTC.

Un administrateur de DTC se connecte pour télécharger des informations sur

les lignes de bus ou créer une nouvelle entrée de base de données, mettre à
jour une entrée de base de données existante ou gérer les plaintes et
requêtes formulées par les passagers.

L'application doit être téléchargeable gratuitement à partir d'un magasin

d'applications pour téléphone mobile ou de services similaires

Perspective du produit

Toutes les informations du système sont conservées dans une base de

données, qui se trouve sur un serveur Web. Cela comprend les informations
sur les utilisateurs et les administrateurs ainsi que les informations sur les
bus, c'est-à-dire leurs itinéraires et leurs tarifs.

Une connexion Internet est nécessaire pour accéder au système, pour

récupérer et afficher les résultats et pour s'inscrire et se connecter.

Comme il s'agit d'un produit centré sur les données, il faudra un endroit pour
stocker les données.

Pour cela, une base de données sera utilisée. L'application mobile et le portail
Web communiqueront avec la base de données, mais de manière légèrement
différente.
L'application mobile utilisera uniquement la base de données pour obtenir
des données tandis que le portail Web ajoutera et modifiera également des
données.

Toutes les communications de la base de données passeront par Internet.

L'application mobile a certaines restrictions concernant l'allocation des

ressources. Pour éviter les problèmes de surcharge du système
d'exploitation, l'application n'est autorisée à utiliser que 20 mégaoctets de
mémoire lors de l'exécution de l'application.

La quantité maximale d'espace disque dur est également de 20 mégaoctets.

CAHIER DE CHARGE

Cahier des Charges - Système de Consultation des

Itinéraires de Bus

1. Introduction

Ce document spécifie le projet pour développer une application mobile et un

portail web permettant aux utilisateurs de :

 Consulter les itinéraires des bus, les tarifs et les horaires.

 Gérer les données des itinéraires de bus pour l'administration.

Le produit est conçu pour le Transport Corporation et vise à simplifier la

gestion et l'accès aux informations des transports publics.

2. Objectifs du Projet

1. Améliorer l'accès à l'information pour les passagers :

a. Trouver facilement les itinéraires et tarifs des bus pour leur
destination.
2. Faciliter la gestion pour l'administration :
a. Mettre à jour et consulter les informations sur les itinéraires des
bus via un portail sécurisé.
 3. Optimiser l'expérience utilisateur :
a. Offrir une application intuitive et un service en ligne fiable.

3. Fonctionnalités Principales

Pour les utilisateurs :

 Recherche des itinéraires selon le point de départ et de destination.

 Affichage des tarifs et des numéros de bus.
 Enregistrement et connexion sécurisés.
 Soumission des requêtes et plaintes.

Pour les administrateurs :

 Gestion des itinéraires des bus (ajout, modification, suppression).

 Consultation et traitement des requêtes et plaintes des utilisateurs.

4. Description Technique

 Environnement :
o Application mobile compatible Android (5.0 et versions
ultérieures).
o Portail web accessible via les navigateurs courants.
o Serveur hébergé sur Linux avec base de données MySQL.
 Contraintes :
o Limitation à 20 Mo de mémoire pour l'application mobile.
o Temps de chargement des pages web inférieur à 5 secondes.

5. Modules

1. Inscription et Connexion :
a. Inscription des utilisateurs avec des informations personnelles.
 Collecte des informations personnelles : nom, e-mail, numéro de
téléphone (facultatif), et mot de passe.
 Validation des données saisies pour éviter les doublons et garantir leur
exactitude.
 Création d'un identifiant unique pour chaque utilisateur dans la base de
données.

b. Connexion sécurisée avec vérification des identifiants.

 Vérification des identifiants fournis (e-mail/nom d'utilisateur et mot de
passe).
 Utilisation de protocoles sécurisés (HTTPS) pour la transmission des
données de connexion.
 Déconnexion automatique après une période d'inactivité pour protéger
les comptes utilisateurs.

2. Recherche d'itinéraires :
a. Interface intuitive pour saisir les points de départ et d'arrivée.
 Champs pour saisir les points de départ et d'arrivée.
 Suggestions automatiques basées sur les données disponibles dans la
base de données

b. Résultats incluant les numéros de bus et les tarifs.

 Affichage des numéros de bus, des itinéraires, et des tarifs associés.
 Indication des itinéraires alternatifs si disponible.
 Message d'erreur clair si aucun itinéraire ne correspond à la requête.

3. Gestion Administrative :
a. Tableau de bord pour ajouter, modifier et supprimer des
itinéraires.
 Affichage des données actuelles des itinéraires de bus, incluant les
numéros, tarifs, et trajets.
 Fonctions pour ajouter, modifier, ou supprimer des itinéraires via un
formulaire interactif.
 Historique des modifications pour assurer la traçabilité.

b. Consultation des requêtes et plaintes des passagers.

 Consultation des plaintes soumises par les utilisateurs.
 Réponse directe via l'interface administrative ou exportation des
requêtes pour un traitement externe.
 Statut de suivi pour informer les passagers (en cours, résolu, etc.).
6. Diagrammes

 Diagramme de flux de données (DFD) :

o Illustre les interactions entre les utilisateurs, l'application mobile,
le portail web et la base de données.
o

 Complexité Cyclomatique :
o Calculée à 8 chemins indépendants pour garantir une couverture
complète des tests.
 o

7. Exigences Non Fonctionnelles

 Performance :
o Les requêtes serveur doivent répondre en moins de 2 secondes.
o Calcul des tarifs optimisé pour un temps d'exécution inférieur à
une seconde.
 Sécurité :
o Cryptage des mots de passe et des données sensibles.
o Déconnexion automatique après une période d'inactivité.

8. Estimations et Planification

 Taille du projet : 153 points de fonction (FP).

 Efforts estimés : 4,53 mois-personnes.
 Calendrier :
o Analyse des besoins : 2 semaines.
o Conception : 3 semaines.
o Développement : 4 semaines.
o Tests et déploiement : 2 semaines.
9. Conclusion

Le projet est conçu pour améliorer la gestion des transports publics et

l'expérience des utilisateurs. Des évolutions futures pourraient inclure :

 Suivi en temps réel des bus.

 Génération et gestion des abonnements.

Si tu veux une autre section plus détaillée ou adaptée, précise la partie à

développer !

Consultant

Dans la phase du cahier des charges, un consultant joue un rôle clé pour
s'assurer que les besoins et les objectifs du projet sont bien définis, alignés
avec les attentes des parties prenantes, et techniquement faisables. Voici les
principales responsabilités et contributions d'un consultant à cette étape :

1. Identification des Besoins

Le consultant aide à :

 Comprendre les attentes des parties prenantes (clients, utilisateurs

finaux, équipes techniques).
 Analyser les processus existants pour identifier les lacunes ou
inefficacités.
 Traduire les besoins métiers en exigences fonctionnelles claires et
compréhensibles.

2. Définition des Objectifs

 Assister dans la formulation des objectifs du projet pour qu'ils

soient précis, mesurables et réalistes.
 Prioriser les fonctionnalités en fonction des besoins critiques et des
contraintes du projet (temps, budget, etc.).
3. Analyse des Contraintes

 Identifier les contraintes techniques, organisationnelles ou

réglementaires qui pourraient influencer le projet.
 Proposer des alternatives pour gérer ou contourner ces contraintes.

4. Validation Technique

 Vérifier la faisabilité technique des exigences listées dans le cahier des

charges.
 Conseiller sur les technologies, outils, et méthodologies les mieux
adaptés au projet.

5. Coordination et Communication

 Jouer le rôle d’intermédiaire entre les parties prenantes non techniques

(clients) et les équipes techniques.
 S'assurer que tout le monde a une compréhension partagée du
projet.

6. Prévention des Risques

 Identifier les risques potentiels liés à la portée, à la conception ou à

l'implémentation du projet.
 Recommander des plans d'atténuation pour réduire l'impact des
risques identifiés.

7. Validation du Cahier des Charges

 Relire et valider le document final pour s'assurer qu'il :

o Est complet et clair.
o Décrit précisément les livrables attendus.
o Contient toutes les exigences fonctionnelles et non fonctionnelles
nécessaires.
o Respecte les standards de qualité attendus.
Un consultant agit donc comme un expert et un guide pour orienter le
projet dans la bonne direction dès le départ, évitant ainsi des erreurs
coûteuses ou des incompréhensions.

Diagramm de gantt

Tâche Début Fin Durée (jours)

Analyse des besoins 01/11/2024 14/11/2024 14
Conception 15/11/2024 28/11/2024 14
Développement 29/11/2024 20/12/2024 22
Tests 21/12/2024 05/01/2025 15
Déploiement 06/01/2025 10/01/2025 5

2. Tableau pour le Diagramme PERT

Tâche Nom Durée (jours) Prédécesseurs
A Analyse des besoins 14 -
B Conception 14 A
C Développement 21 B
D Tests 15 C
E Déploiement 5 D

City bus 2eme partie

ANALYSE DES BESOINS

Besoins fonctionnels

1. Enregistrement et connexion des utilisateurs :

a. Les utilisateurs doivent pouvoir créer un compte, fournir un nom
d'utilisateur, un mot de passe et des informations de contact.
b. Les administrateurs et les utilisateurs doivent se connecter pour
accéder aux fonctionnalités spécifiques.
2. Recherche d'itinéraires de bus :
a. Les utilisateurs doivent entrer leur point de départ et leur
destination pour obtenir des informations sur les itinéraires, y
compris le numéro de bus et le tarif.
3. Gestion des informations des bus :
a. Les administrateurs doivent pouvoir ajouter, modifier ou
supprimer des informations sur les itinéraires de bus via un
portail web.
4. Gestion des requêtes et plaintes :
a. Les utilisateurs peuvent soumettre des demandes ou des plaintes
via l'application mobile.
b. Les administrateurs gèrent ces requêtes via le portail web.
5. Notifications :
a. L'application doit notifier les utilisateurs des mises à jour ou des
changements dans les itinéraires.

Besoins non fonctionnels

1. Performance :
 a. Les requêtes serveur doivent être rapides, avec un délai minimal
pour afficher les résultats.
b. L'algorithme de calcul des tarifs doit être optimisé pour fournir
des réponses instantanées.
2. Compatibilité :
a. L'application mobile doit être compatible avec les appareils
Android version 5.0 et plus.
3. Sécurité :
a. Les mots de passe des utilisateurs ne doivent pas être affichés en
clair ni stockés sans cryptage.
b. Les sessions doivent expirer après une période d'inactivité pour
garantir la sécurité.
4. Fiabilité :
a. Le serveur doit avoir un taux de disponibilité d'au moins 98 %
pour éviter les interruptions.
5. Facilité d'utilisation :
a. L'interface utilisateur doit être intuitive et conviviale, adaptée à
des utilisateurs non techniques.
6. Portabilité :
a. L'application mobile doit pouvoir être utilisée sur différents
appareils Android sans configuration complexe.
7. Documentation :
a. Une documentation en ligne ainsi qu’un tutoriel vidéo doivent
être fournis pour aider les utilisateurs.

Ces exigences couvrent les aspects nécessaires pour le développement et

l'exploitation efficace du système.

Étude de faisabilité

1. Technique :
a. Plateformes prises en charge : Android (version 5.0 et plus),
serveurs web basés sur Linux avec base de données MySQL.
b. Technologies utilisées : Android SDK, PHP pour les interactions
serveur, HTTP et TCP/IP comme protocoles principaux.
 c. Limites : L'application est conçue pour des mobiles avec 20 Mo
de mémoire disponible.
2. Opérationnelle :
a. Utilisateurs cibles : Passagers de bus pour rechercher des
trajets et des tarifs, administrateurs pour gérer les données.
b. Accessibilité : L'application sera intuitive et nécessite une
connexion Internet.
c. Objectif : Réduire les frictions liées à la recherche de trajets et à
la gestion des données de transport.
3. Économique :
a. Coût estimé : 4.53 mois-personne (PM).
b. Points fonctionnels estimés : 153 FP, ce qui indique un projet
de taille modérée.

Rôle du consultant

 Analyse initiale :
o Identifier les exigences spécifiques des utilisateurs (passagers et
administrateurs).
o S'assurer que les contraintes techniques, comme la capacité du
serveur et la compatibilité API, sont respectées.
 Conception :
o Valider le design des interfaces utilisateur (pages de connexion,
recherche, gestion).
o Proposer des fonctionnalités futures, comme le suivi en temps
réel des bus ou la génération de passes.
 Suivi et optimisation :
o Aider dans la mise en œuvre des tests fonctionnels (boîte noire)
et structurels (boîte blanche).
o Gérer les risques identifiés : perte de données, délais serrés,
cohésion de l'équipe.

Diagramme de sequense
CONCEPTION

1. Concepteur

Le concepteur est responsable de planifier, structurer et superviser le

développement du système. Voici un résumé des responsabilités :

 Analyse des exigences : Traduire les besoins des utilisateurs en

spécifications techniques.
 Modélisation UML : Concevoir les diagrammes nécessaires (classes,
objets, séquences, etc.).
 Documentation : Assurer la clarté des conceptions pour l'équipe de
développement.
Diagramme de classe
Diagramme d’objet
Développement : Techniques et Technologies

Techniques Utilisées

1. Développement Orienté Objet (OOP)

a. Modélisation avec des classes pour Utilisateur, Bus, Requete,
et Reclamation.
b. Réutilisation et modularité du code.
2. Architecture en Couches
a. Frontend (Couche présentation) : Interface utilisateur.
b. Backend (Couche logique métier) : Traitement des données
et règles métier.
c. Base de données (Couche données) : Stockage des
informations.
3. API RESTful
a. Communication entre l’application Android et le serveur via HTTP.
b. Méthodes : GET, POST, PUT, DELETE.
4. Approche Agile
a. Découpage du développement en sprints pour une meilleure
organisation.

Langages et Technologies

1. Frontend :
a. XML : Conception de l’interface utilisateur.
b. Android Studio : IDE principal pour le développement mobile.
2. Backend :
a. PHP : Développement des API backend.
b. MySQL : Base de données pour stocker les utilisateurs,
itinéraires, requêtes, et réclamations.
3. Communication :
a. Retrofit : Bibliothèque pour interagir avec les API REST.

Structure de la Base de Données

 Table Utilisateur : Stocke les informations des utilisateurs.

o Attributs : idUtilisateur, nom, email, motDePasse.
 Table Bus : Contient les itinéraires et tarifs.
 o Attributs : numeroBus, itineraire, tarif.
 Table Requete : Enregistre les demandes des utilisateurs.
o Attributs : idRequete, description, date.
 Table Reclamation : Gère les réclamations.
o Attributs : idReclamation, contenu, statut.

Fonctionnalités Clés

1. Inscription et Connexion :
a. Formulaire pour créer ou accéder à un compte utilisateur.
b. Hachage des mots de passe avec bcrypt.
2. Recherche d’Itinéraires :
a. Entrée : Point de départ et destination.
b. Résultat : Numéro de bus et tarif affichés à l’utilisateur.
3. Soumission de Réclamations :
a. Formulaire pour envoyer une réclamation.
b. Stockage des réclamations dans la base de données.

Exemples de Code

1. Insertion d’un utilisateur (PHP) :

$query = "INSERT INTO Utilisateur (email, motDePasse) VALUES

('$email', '$hashedPassword')";
mysqli_query($conn, $query);

2. Requête SQL pour les itinéraires :

SELECT numeroBus, tarif FROM Bus WHERE itineraire LIKE

'%pointDepart%' AND itineraire LIKE '%destination%';

3. Structure XML pour l’écran de recherche :

<Spinner android:id="@+id/source" ... />

<Spinner android:id="@+id/destination" ... />
<Button android:id="@+id/findRoute" ... />

Sécurité

 Authentification via tokens (JWT).

 Hachage des mots de passe.
 Requêtes SQL paramétrées pour éviter les injections.