DENOMINATION DU DOCUMENT : CAHIER DES CHARGES DENOMINATION DU PROJET
« MONITORING DOMOTIQUE »
MOA : LAURENT AUDIBERT
MOE : GROUPE 6
(SANOGO, AFFANE, DIALLO, N’GOUAN, DJIMERA)
EQUIPE DE SUIVI :
LIONEL POURNIN & TOMEH NADI
Cahier des charges Page 2
SOMMAIRE
A. ANALYSE DE L'EXISTANT ... 4
B. ANALYSE DU BESOIN ... 4
II. LES OBJECTIFS ... 5
III. REPONSE QUALITATIVE ... 5
A. FONCTIONNALITES DU LOGICIEL ... 5
B. DIAGRAMME DES CAS D’UTILISATION ... 6
1. Hiérarchisation des cas d'utilisation ... 6
C. ARCHITECTURE ET INTEGRATION AU SI CLIENT ... 8
D. EXIGENCES OPERATIONNELLES ... 10
2. Performances ... 10
3. Mode de gestion des erreurs ... 10
4. Volumétrie de la base données ... 10
5. Moyens matériels et logiciels ... 10
a. PostgreSQL : ... 10
i. Caractéristiques : ... 11
ii. Pourquoi PostgreSQL ? ... 11
b. PHP ... 11
i. Comment ? ... 11
c. JavaScript ... 11
d. HTML/CSS ... 12
e. Highcharts ... 12
i. La facilité d’emploi ... 12
ii. Paramétrable à souhait avec un objet JSON ... 12
iii. Le rendu est vraiment beau ... 12
iv. Les types de graphique ... 12
v. Le module d’export intégré (JPEG, PDF, SVG, PNG) ... 13
vi. Cross navigateur (fonctionne en VML et en SVG) ... 13
6. Moyens humains et organisationnel ... 13
7. Moyens fournisseurs ... 13
a. Moyens techniques ... 13
i. L’environnement de développement ... 13
b. Les moyens humains ... 14
i. Compétences techniques ... 14
ii. Compétences managériales ... 14
IV. REPONSE QUANTITATIVE ... 14
A. MOYENS MATERIELS ET LOGICIEL... 14
Cahier des charges Page 3
B. MOYENS ORGANISATIONNELS ET HUMAINS ... 14
C. MOYENS FOURNISSEURS ... 14
1. Premier plan de charge ... 14
D. ORGANISATION ... 16
1. Répartition des taches/Jours ... 16
2. Jours moyens ... 16
Cahier des charges Page 4
LE CAHIER DES CHARGES
I. CONTEXTE
Le projet « monitoring domotique » est un projet académique qui consiste à mettre au point un logiciel pour « monitorer » des données enregistrées par différents capteurs. Le monitoring domotique permet la surveillance et l'analyse de l'activité des différents capteurs qui constituent le système domotique.
A. ANALYSE DE L'EXISTANT
Le client a mis en place un système domotique constitué de capteurs (détecteurs de mouvements, des thermomètres, des détecteurs de luminosité, des détecteurs d'ouverture de porte, des compteurs d’eau…). Ces capteurs pilotés par un petit serveur qui est dotée d’une interface web d’administration et d'une base de données relationnelle dans laquelle sont stockés les relevés horo- datés (timestamp) de sources et de natures diverse (température, luminosité, détection, compteur…).
Les relevés que la base de données va devoir stocker sont particuliers et sont caractérisés par au moins :
Un horodatage (timestamp)
Une source permettant d’identifier l’origine de la mesure
Une métrique permettant, entre autres, de caractériser la nature de la mesure
Une valeur
B. ANALYSE DU BESOIN
La domotique mettant en œuvre un nombre important de capteurs et d’actionneurs, il est intéressant de monitorer sous forme de graphes les changements d’états de tous ces modules pour rendre compte de l’évolution de la température, de la consommation électrique, du nombre de détection d’un détecteur de mouvements etc. Les graphes générés permettent de voir l’impact de votre mode de vie sur votre consommation d’énergie par exemple, premier pas pour réaliser des économies dans ce domaine.
Ces graphes peuvent donc permettre de prendre des décisions pour faire évoluer le système domotique ou alors d’optimiser l’utilisation de certains appareils énergivores pour effectuer par exemple une économie d'énergie (savoir quel est le bon moment pour éteindre le chauffage quand on sort de la maison pour éviter du gaspillage) et une économie au niveau financier (cela permet de diminuer la facture à payer). Certains logiciels spécialisés appelés TSDB (time series data base) permettent déjà de réaliser ce type de courbes. Mais leur utilisation n’est pas aisée et nécessite, pour réaliser certaines courbes, des connaissances pointues de l’utilisateur sur les bases de données et le langage SQL. C’est notamment le cas de Influxdb (TSDB) et son outil graphique Grafana qui
Cahier des charges Page 5 permettent d’afficher le résultat de requêtes sous forme de graphe avec des courbes. Ce qui n’est pas pratique pour réaliser du monitoring car la plupart de ces requêtes vont être répétées donc on peut les présenter d’une manière plus facilement accessible pour l’utilisateur et surtout moins difficile à mettre en oeuvre.
II. LES OBJECTIFS
Les objectifs principaux de ce projet sont de :
Construire une interface utilisateur agréable, intuitive et facile à utiliser. Elle doit être facilement utilisable même si l’utilisateur n’a aucune qualification en informatique. L’utilisateur doit donc pouvoir explorer toutes les données enregistrées dans la base de données sans jamais saisir par exemple de requête SQL (donc sans programmer). Notre client ne veut pas avoir à chercher et trouver la bonne requête à chaque fois qu’il souhaite voir l’évolution des températures sur le mois, l’année car cela peut être fastidieux.
Il faut que la base de données sous-jacente soit une base de données relationnelle car la plupart des micro-serveurs comportent généralement un SGBDR déjà en service, ce qui est le cas de notre client. D'autre part, il est parfois complexe voire impossible d'installer un TSDB sur ce type de machine (NAS, Raspberry, ...)
III. REPONSE QUALITATIVE
A. FONCTIONNALITES DU LOGICIEL
Les fonctionnalités du logiciel sont :
Concevoir une page : permet de créer une page de graphique. Une page de graphique contient un ou plusieurs graphes.
Sauvegarder une page de graphique : permet de sauvegarder une page de graphique déjà conçue.
Ajouter un graphe : permet d’ajouter un graphe dans une page de graphique tout en spécifiant l’échelle et la plage de temps. L’échelle peut être la seconde, l’heure ou, le jour.
Quant à la plage de temps, deux possibilités s’offrent à l’utilisateur. Il peut soit spécifier une date de début et une date de fin soit intervalle de temps jusqu'à l'instant présent. Dans ce deuxième cas, la courbe sera représentée une première fois, ensuite elle sera régénérée à chaque fois que l’intervalle de temps précisé sera atteint. L’utilisateur peut par exemple choisir de voir l’évolution des températures depuis le 05/04/2013 à maintenant et préciser l’intervalle de 5 minutes. Donc, une première courbe sera dessinée d’abord, ensuite chaque cinq minute, la courbe sera redessinée en prenant en compte les données enregistrées les cinq dernières minutes. On peut ajouter autant de graphe qu’on veut dans une page de graphique.
Supprimer un graphe : permet de supprimer un graphe d’une page de graphique
Ajouter une courbe : il s’agit ici d’ajouter une courbe à dessiner dans le graphe. Pour chaque capteur, en fonction de son type, il y a différents types de courbes qu’on peut visualiser. Et pour chaque capteur, chaque type de courbe a un nom. Il suffit donc de choisir ce nom pour visualiser ce type de courbe pour le capteur. Par exemple : on a un détecteur d’ouverture de la porte du garage qui s’appelle Détecteur_ouverture_porte_garage. On peut visualiser soit la courbe classique (créneaux) des déclenchements nommée :
« Détecteur_ouverture_porte_garage»
Soit une courbe du nombre d’activation qu’on va nommer :
Cahier des charges Page 6
« Détecteur_ouverture_porte_garage _Nombre_activation » Soit une courbe de proportion de haut qu’on va nommer :
« Détecteur_ouverture_porte_garage _Proportion_de_haut »
Lorsque l’utilisateur veut visualiser la courbe classique (créneaux) des déclenchements du détecteur d’ouverture de la porte du garage, il lui suffira par exemple de choisir la courbe
« Détecteur_ouverture_porte_garage »
On peut ajouter autant de courbe qu’on veut dans un graphe. On peut aussi filtrer les courbes à afficher en fonction du type de capteur, de la nature des métriques et de la localisation afin de faciliter la recherche à l’utilisateur.
Supprimer une courbe : permet de supprimer une courbe du graphe
Visualiser une page : permet de visualiser une page qu’on avait sauvegardée
Charger une page à visualiser : permet ouvrir une page déjà enregistrée.
B. DIAGRAMME DES CAS D’UTILISATION
Figure 1:DIAGRAMME DES CAS D'UTILISATION
1. Hiérarchisation des cas d'utilisation
Concevoir une page :
• Excellente couverture de l'application.
• Oblige à mettre en place une architecture web.
Cahier des charges Page 7
• Demander en priorité.
Ajouter un graphe :
• Fait partie du cas précédent pour qu’il ait un sens.
• Faire des choix d’implémentations cruciaux
• Mise en place du graphe de visualisation.
Définir l’échelle et la plage de visualisation :
• Fait partie du cas précédent
• Choisir des technologies pour avoir les dates dans un calendrier
Ajouter une courbe :
• Etend le cas Ajouter graphe qui ne sert à rien sans les courbes qui doivent y être affichées
• Risque technologique : utilisation de Highchart
• Mis en œuvre de calcul complexe et de requête SQL avancées
Supprimer une courbe :
• Utilisé pour créer de la clarté sur un graphe ou alors pour une gestion du graphe
• Va de pair avec le cas précédent Sauvegarder page :
Une fois la page conçue la sauvegarder pour un usage ultérieur Visualiser page :
Permet de revoir quand on le souhaite une page de graphique générée auparavant.
Charger une page :
pour de récupérer une page de graphique enregistrer
Description détaillée des cas d'utilisation prioritaire :
Concevoir une page :
C'est un cas d'utilisation résumé et il permet d’implémenter les cas suivant :
• Ajouter un graphe
• Sauvegarder une page
• Supprimer un graphe
Ajouter un graphe :
Nom: Ajouter un graphe.
Acteur : Acteur principal (utilisateur).
Objectif : L'utilisateur doit pouvoir ajouter des graphes sur la page de visualisation.
Précondition: Il faut que la de visualisation existe.
Résultat : Un graphe doit être affiché Scenario principal :
1 L'utilisateur clique sur un bouton ajouter graphe.
2 Le système lui de demande de définir une échelle et une plage de temps.
3 L'utilisateur définit une échelle et une plage de temps.
4 Le système dessine le graphe correspondant au choix de l'utilisateur.
Extension : Echelle et plage non définies.
2a- L’échelle et la plage ne sont pas renseignées. Le système envoie un message d'erreur.
Scénario alternatif : Nouvelle échelle ou nouvelle plage de temps 3a- L'utilisateur modifie l’échelle et la plage de temps.
Cahier des charges Page 8 Définir une échelle et une plage :
Nom: Définir une échelle et une plage.
Acteur : Acteur principal (utilisateur).
Objectif: Définir une échelle une plage de temps pour créer ajouter un graphe.
Précondition: Il faut que la page de visualisation existe.
Résultat : Affichage d'un graphe par rapport à l’échelle et à la plage choisies Scenario principal :
1 L'utilisateur définit une échelle et une plage de temps.
2 Le système dessine le graphe correspondant au choix de l'utilisateur.
Extension : Echelle et plage non définies.
1a- L’échelle et la plage ne sont pas renseignées. Le système envoie un message d'erreur.
Scénario alternatif : Nouvelle échelle ou nouvelle plage de temps 2a- L'utilisateur modifie l’échelle et la plage de temps.
Ajouter une courbe : Sur le même graphe, on peut ajouter autant de courbe.
Nom: Ajouter une courbe sur un graphe Acteur : Acteur principal (utilisateur).
Objectif : Ajouter des courbes sur un graphe autant de fois que l'utilisateur le souhaite.
Précondition: Il faut que le graphe existe.
Données entrées: le capteur.
Résultat : Une ou plusieurs courbes doivent être affichée sur le graphe.
Scenario principal :
1 L'utilisateur sélectionne le ou les courbes qu’il veut visualiser.
2 Le système lui affiche le ou les courbes correspondant aux choix du capteur.
Supprimer une courbe : Sur le même graphe avec autant de courbe on choisir d'en supprimer Nom: Supprimer une courbe sur le graphe
Acteur : Acteur principal (utilisateur).
Objectif : Enlever des courbes sur un graphe autant de fois que l'utilisateur le souhaite.
Précondition: Il faut que le graphe existe et qu'une ou plusieurs courbes soient dessinées.
Données entrées: la courbe.
Résultat : la courbe sélectionnée ne doit plus exister sur le graphe.
Scenario principal :
1 L'utilisateur sélectionne la courbe à supprimer.
2 Le système enlève la courbe du graphe.
Extension : Courbe non sélectionnée.
1a- La courbe à supprimer n'est pas renseignée.
Le système envoie un message d'erreur Scénario alternatif : Nouveau courbe à supprimer
1a- L'utilisateur sélectionne une autre courbe à supprimer.
C. ARCHITECTURE ET INTEGRATION AU SI CLIENT
Notre système doit se greffer sur le système domotique du client qui comprend une base de données et permettre l’exploration des données stockées. Nous allons utiliser une architecture 3-tiers comme le montre la figure 1. Il s'agit d'un modèle logique d'architecture applicative qui vise à modéliser
Cahier des charges Page 9 une application comme un empilement de trois couches logicielles (étages, niveaux) dont le rôle est clairement défini :
la présentation des données : correspondant à l'affichage, la restitution sur le poste de travail, le dialogue avec l'utilisateur. Elle correspond à la partie de l'application visible et interactive avec les utilisateurs. On parle d'interface homme machine (IHM). Dans notre cas, elle sera représentée en HTML pour être exploitée par un navigateur web. La couche
présentation (IHM) relaie les requêtes de l'utilisateur à destination de la couche métier, et en retour lui présente les informations renvoyées par les traitements de cette couche;
le traitement métier des données : Elle correspond à la partie fonctionnelle de l'application, celle qui implémente la « logique », et qui décrit les opérations que
l'application opère sur les données en fonction des requêtes des utilisateurs, effectuées au travers de la couche présentation (IHM). Les différentes règles de gestion et de contrôle du système sont mises en œuvre dans cette couche. La couche métier offre des services
applicatifs et métier à la couche présentation. Pour fournir ces services, elle s'appuie, le cas échéant, sur les données du système, accessibles au travers des services de la couche inférieure. En retour, elle renvoie à la couche présentation les résultats qu'elle a calculés;
et enfin l'accès aux données persistantes : Elle consiste en la partie gérant l'accès aux données du système. Ces données sont propres au système et stockées dans une base de données. Les services sont mis à disposition de la couche métier et les données renvoyées sont issues des données du système. La base de donnée sera mise à jour (surtout les vues de synthèse), chaque fois qu’une échelle (heure, jour) sera atteinte.
Figure 2:architecture globale du système
Cahier des charges Page 10
D. EXIGENCES OPERATIONNELLES
2. PerformancesLe système que nous devons développer doit être performant (temps de réponse minimum). C’est pourquoi nous avons prévu de faire au préalable tous les calculs nécessaires pour les requêtes qui permettent de visualiser les courbe et de les stocker dans des tables dédiées (vues de synthèse). En effet, pour chaque échelle de temps qui peut être choisie par l’utilisateur, on va créer une vue de synthèse dans laquelle sera stockée et mis à jour les valeurs provenant d’un calcul préalable à partir de la table contenant tous les relevés des capteurs chaque fois que cette échelle sera atteinte.
Par exemple, pour l’échelle « jour », il y aura une « Vue_Jour » qui sera créée et ensuite mis à jour chaque jour. Tous ses attributs, sauf un, seront identiques à celles de la table initiale. L’attribut qui diffère sera la valeur du relevé qui sera obtenu par un calcul dans le cas de la « Vue_Jour ». Cette approche permet d’éviter de faire tous ces calculs qui peuvent prendre beaucoup de temps au moment où l’utilisateur souhaite voir une courbe qui nécessite ce type de calcul. On aura juste a interroger la vue de synthèse au lieu de la table contenant les relevés non traités. Ce qui va faire gagner un temps considérable dans le traitement de certaines requêtes complexes (courbe de proportion de haut par jour sur une période de dix années d’un détecteur de mouvement par exemple).
3. Mode de gestion des erreurs
Pour la gestion des erreurs, nous utiliserons les gestionnaires d’erreurs que proposent les langages de programmation que nous utiliserons à savoir PHP et Java Script. Une fois qu’une erreur sera détectée, elle sera remontée jusqu’à la fonction appelante qui devra la traiter et afficher explicitement un message d’erreur intelligible par l’utilisateur. Afin de prévenir certains types d’erreurs (erreur de saisie ou de valeur erronée), nous allons mettre en place une interface utilisateur qui propose des choix prédéfinis à l’utilisateur (ou apparaissent que des propositions qui ont un sens pour l’application). Il ne pourra donc rien saisir, ce qui limitera fortement la survenue de certaines erreurs.
4. Volumétrie de la base données
Les relevés vont produire une grande quantité de données immuables qui seront enregistrées dans la base de données. Par exemple, une centaine de capteurs avec en moyenne une mesure toutes les dix minutes vont produire plus de 5 millions de relevés par an. En principe, ces données ne sont jamais modifiées après insertion. Ce qui nous amène parfois à réduire la résolution de ces relevés chronologiques pour les afficher. Or cette réduction n’est pas triviale et fait intervenir des fonctions mathématiques pour produire des comptages, des moyennes, des interpolations, des lissages, des maximums, des minimums…Il faut aussi, et cela dans un souci d’obtenir les performances souhaitées, faire des synthèses des valeurs mesurées.
5. Moyens matériels et logiciels
Pour ce logiciel, aucun moyen matériel particulier n’est nécessaire. Le client n’a à fournir aucun matériel particulier.
Les outils logiciels de développement que nous allons utiliser sont : a. PostgreSQL :
C'est un SGBD relationnel très complet et ce depuis. Ses performances en lecture sont globalement
Cahier des charges Page 11 légèrement inférieures à celle de MySQL mais largement suffisantes pour la plupart des
applications.
i. Caractéristiques :
Il possède l'avantage d’être réellement complet: requêtes imbriquées, transaction, gestion des clés étrangères, union, triggers, procédure stockée, jointure complet, traitement des séries
chronologiques, contraintes, curseurs, langage procédural (PL, pgSQL, PL/PHP), etc.
ii. Pourquoi PostgreSQL ?
La première raison est que la base de données du système existant est une base de données
PostgreSQL. La deuxième raison est qu'il est open source, et possède une grande communauté de de développeurs. En plus, il y a des fonctions intégrées pour traiter les séries chronologiques plus facilement. Le choix de PostgreSQL pour PHP est un bon choix en toute circonstance.
b. PHP
Nous allons adopter le langage de programmation PHP en tant que principale technologie derrière nos systèmes de contenu et ce, pour plusieurs raisons. La plus importante est que nos clients bénéficieront de nombreux avantages qui se traduisent en économie et ce, sans compromis sur la qualité.
i. Comment ?
Tout d'abord, PHP est gratuit et ne nécessite aucune licence d'utilisation PHP est le langage de programmation Web le plus utilisé. Il existe une communauté de développeurs très active qui rend disponibles des dizaines de milliers de librairies PHP de grande qualité ainsi qu'une vaste quantité de documentation et tutoriels pour le bénéfice de chacun. Ces ressources facilitent notre travail et réduisent notre temps d'exécution.
En termes de rapidité et d’efficacité, PHP n'a rien à envier aux autres langages. Plusieurs portails très populaires et nécessitants beaucoup de performance l'utilisent. Nous avons qu'à penser à Facebook, Yahoo, le réseau CBC, Canoë pour ne nommer que ceux-là. PHP est un langage facile à apprendre. Il a été spécifiquement conçu pour le Web donc ça rime bien avec les technologies du Web tel que le XML, les API, les services distants, les divers navigateurs.
c. JavaScript
Une grande difficulté́ sera de gérer un code JavaScript relativement gros et qui se voudra
modulable pour répondre à l’objectif de flexibilité́, malgré́ le côté particulier de la gestion des objets en Javascript. En effet, le Javascript ne permet pas nativement d’étendre les objets. Il permet en revanche de copier les fonctions d’un objet à un autre. Ceci présente l’avantage d’avoir un
mécanisme d’héritage mais pas d’étendre une fonction puisque celle-là même de l’objet parent sera remplacée par celle de l’enfant.
Pour combler ces manquements du Javascript, nombreux sites ont recours à un framework. J’ai porté mon choix sur jQuery [28] car il permet d’accéder facilement à des éléments de la page web, d’en modifier le contenu, de les animer, et facilite grandement la gestion de l’AJAX... Environ 45%
des 100 000 cites les plus populaires du monde utilisent un framework, et 28% de ceux-ci utilisent jQuery.
L’utilisation de jQuery permet aussi d’assurer la compatibilité des instructions sur un très grand nombre d’appareils car certaines instructions se comportent différemment d’un navigateur à l’autre et jQuery s’assure d’utiliser les bonnes méthodes. Techniquement, jQuery n’ajoute évidemment aucune fonctionnalité à Javascript, mais il permet de faire beaucoup plus en beaucoup moins de lignes de code et moins de temps.
Cahier des charges Page 12 Pour les graphiques, c’est la librairie Highcharts qui a attiré notre attention. Elle n’est cependant pas libre (mais gratuite pour un usage limité non commercial. Il existe de très nombreuses librairies, mais Highcharts était une des rares comprenant toutes les fonctionnalités que nous desirons.
d. HTML/CSS
L’HTML n’est plus à présenter. Sa version 5 apporte cependant son lot de nouveautés permettant d’envisager les fonctionnalités de l’interface sans recours à un plugin dans le navigateur tel que le flash ou les applets Java.
e. Highcharts
Nous allons vous parler d’Highcharts, une librairie Javascript vraiment bonne pour faire des graphiques. Cette librairie a été construite et maintenu par la compagnie Norvégienne Highslide Software. Elle est gratuite pour des projets personnels et coûte quelques euros pour un usage commercial.
Nous l’avons choisi pour plusieurs raisons :
i. La facilité d’emploi
En effet Highcharts est très simple d’utilisation. On est en plein dans le plug&play ! Il suffit d’ajouter le script Javascript et la feuille de style pour commencer à apercevoir la puissance de l’outil. Vous verrez dans la suite de ce tutoriel complet sur Highcharts (partie 2/3) comment faire un premier graphique. Vous allez vite comprendre que ce n’est pas sorcier !
ii. Paramétrable à souhait avec un objet JSON
Le paramétrage de Highcharts s’effectue à l’aide d’un objet JSON. Les paramètres sont assez larges et permettent de configurer tout ce qui peut être utile dans un graphique. Le type de graphe, la légende, les échelles, les labels, les axes … On peut aussi ajouter des évènements comme onClick, onMouseOver …
iii. Le rendu est vraiment beau
C’est toujours une question de goût mais je dois dire que j’ai testé quelques librairies Javascript dans ce type et que celle-ci m’a tapé dans l’oeil. Les transitions au chargement du graphique sont vraiment belles et fluides. On peut également paramétrer les couleurs et tous les éléments des graphiques ce qui permet de l’adapter facilement dans sa charte graphique. Parlez-en à votre graphiste, il comprendra ;)
iv. Les types de graphique
Vous retrouvez dans Highcharts de quoi faire n’importe quel type de graphique : Bar, pie, don-ut, scatter, bubble, line, stacked, spline, area, timeline. Il est aussi possible de combiner plusieurs type de graph sur un même canvas avec des axes différents, ce qui se révèle être l’arme ultime de la librairie. Un mode permet aussi d’updater un graphique en temps réel.
Cahier des charges Page 13 v. Le module d’export intégré (JPEG, PDF, SVG, PNG) Highcharts propose un module d’export (fait en java) qu’il est possible d’utiliser depuis une API (à partir de leur serveur) ou que l’on peut installer en local. Encore une fois, c’est vraiment simple, si l’on active le mode d’export, le graphique se verra ajouté un petit combo-box permettant de choisir le type d’export souhaité : JPEG, PDF, SVG, PNG. Cette fonctionnalité peut paraître futile, mais je peux vous assurer que si un jour on vous demande un export, c’est un sacré gain de temps de ne pas avoir à le coder.
vi. Cross navigateur (fonctionne en VML et en SVG)
Encore une fois, Highcharts marque des points puisque la librairie fonctionne sur tous les
navigateurs modernes à savoir Firefox, Chrome, Safari, Opera mais aussi Internet Explorer 6, 7, 8 et 9. Les navigateurs mobiles basés sur Web kit permettent aussi d’afficher ces graphes, ce qui inclue Ipod, Iphone et Ipad, samsung, etc....
6. Moyens humains et organisationnel
Le client qui nous a demandé ce logiciel est un informaticien chevronné, très à l’aise avec des dernières technologies du domaine et en veille technologie permanente. La prise en main du logiciel que nous allons développer ne devrait à priori lui poser aucun problème. Ce qui nous fait penser qu’on n’aura pas à consacrer du temps pour la formation de l’utilisateur ni à mettre en place un organe de support aux utilisateurs. L’installation du logiciel sur le site du client ne devrait poser aucun problème non plus (le client à un terminal sur lequel doit être installé le logiciel).
7. Moyens fournisseurs
a. Moyens techniques
i. L’environnement de développement Nous allons utiliser plusieurs technologies à savoir déjà décrites plus haut :
Highcharts : pour l’affichage des courbes
PostgreSQL : c’est le Système de Gestion de Base de Données que nous allons utiliser pour la gestion de la base de données étant donné que c’est le même système qui utilisé par le système domotique sur lequel doit se greffer cette application.
Apache server : pour la gestion de la page web générée.
Nous allons également utiliser plusieurs langages de programmation :
PHP : pour les interactions entre la base de données et la couche application ou les interactions entre la couche application et l’interface graphique.
Java Script : pour les affichages de graphique
HTML & CSS pour représenter l’interface graphique
Cahier des charges Page 14 b. Les moyens humains
i. Compétences techniques
Les compétences techniques nécessaires sont : développeurs qualifiés (PHP, java script, HTML &
CSS), architecte logiciel, architecte système, expert en base de données, intégrateur/testeur.
ii. Compétences managériales
Il faut un chef de projet pour effectuer le suivi des équipes de conception, de développement, d’intégration et de test.
IV. REPONSE QUANTITATIVE
A. MOYENS MATERIELS ET LOGICIEL
Nous utiliserons que des logiciels libres ou open source. Le développement ne nécessite pas l’achat de matériel particulier ou de licence de logiciels.
B. MOYENS ORGANISATIONNELS ET HUMAINS
Le client étant un informaticien qui désire monitorer son système domotique, nous ne préconisons aucun support utilisateur. Le manuel utilisateur sera suffisamment clair et précis pour lui permettre d’utiliser le logiciel.
C. MOYENS FOURNISSEURS
1. Premier plan de charge ADC : analyse du contexte, cette étape contient trois tâches internes (24 JH):
· AS : analyse du sujet (11 JH)
· AE : analyse de l’existant (6 JH)
· AB : analyse des besoins utilisateur (7 JH)
· AF : architecture fonctionnelle, cette étape se divise en trois tâches internes (14 JH):
· A1 : réalisation du diagramme de cas d’utilisation (2 JH)
· A2 : hiérarchisation des cas d’utilisation (3 JH)
· A3 : description détaillée des cas d’utilisation, description textuelle des cas prioritaire et des scénarios possibles (4 JH)
Cahier des charges Page 15
· A4 : description détaillée de tous les cas d’utilisation, description textuelle de tous les cas et des scénarios possibles (3 JH)
· AG : architecture globale, cette étape se divise en trois tâches internes (47 JH) :
· B1 : conception, lister les différentes composantes du système (internes, externes) et leurs interactions (2 JH)
· B2 : prototype, réalisation d’une version (initial, intermédiaire, final) du logiciel (26 JH)
· B3 : intégration des cas prioritaire, après la conception et le développement des cas priori- taire on les intégrés au logiciel (3 JH)
· B4 : intégration de tous les cas d’utilisation, après la conception et le développement de tous les cas on les intégrés au logiciel (4 JH)
· AD : architecture détaillée (implémentation des cas d’utilisation) (35 JH)
· C1 : conception des cas prioritaires (4 JH)
· C2 : développement des cas prioritaires (11 JH)
· C3 : conception et développement de tous les cas (16 JH)
· DPL : déploiement, test d’intégration et installation en environnement client (2 JH)
Compétences Evaluation de la charge de
travail nécessaire en jour/homme
Commentaires
Développeur 30 Charger du développement de
tous les cas d’utilisation et de l’interface graphique
Architecte logiciel 10 Doivent faire la conception des
cas d’utilisations
Architecte système 5 Doit concevoir l’architecture
du système
Intégrateur /testeur 10 Son travail commence après le
développement des cas d’utilisation prioritaires qu’il doit donc intégrer et tester
Expert en base de données 10 Doit réaliser des requête
avancées, des triggers pour les mises à jour automatiques, prendre les mesures nécessaire pour diminuer le temps de réponse
Chef de projet 70 Son travail dure tout le long du
projet
Cahier des charges Page 16
D. ORGANISATION
1. Répartition des taches/Jours
2. Jours moyens
: Tache interne : Mise à jour du cahier des charges : Date de remise du cahier des charges
: Date de présentation du projet
ADC : analyse du contexte, cette étape contient trois tâches internes :
AS : analyse du sujet
AE : analyse de l’existant
AB : analyse des besoins utilisateur
AF : architecture fonctionnelle, cette étape se divise en trois tâches internes :
A1 : réalisation du diagramme de cas d’utilisation
Cahier des charges Page 17
A2 : hiérarchisation des cas d’utilisation
A3 : description détaillée des cas d’utilisation, description textuelle des cas prioritaire et des scénarios possibles
A4 : description détaillée de tous les cas d’utilisation, description textuelle de tous les cas et des scénarios possibles
AG : architecture globale, cette étape se divise en trois tâches internes :
B1 : conception, lister les différentes composantes du système (internes, externes) et leurs interactions
B2 : prototype, réalisation d’une version (initial, intermédiaire, final) du logiciel
B3 : intégration des cas prioritaire, après la conception et le développement des cas prioritaire on les intégrés au logiciel
B4 : intégration de tous les cas d’utilisation, après la conception et le développement de tous les cas on les intégrés au logiciel
AD : architecture détaillée (implémentation des cas d’utilisation)
C1 : conception des cas prioritaires
C2 : développement des cas prioritaires
C3 : conception et développement de tous les cas
DPL : déploiement, test d’intégration et installation en environnement client
Ressources Nom rôles
1 Patricia Architecte logiciel, intégrateur/testeur
2 Souleymane Développeur qualifié PHP, JavaScript,
intégrateur
3 Diallo Architecte système, développeur PHP,
intégrateur/testeur
4 Sarra AFFANE Architecte logiciel, experte en base
de données, intégrateur/testeur
5 Sanogo Chef de projet, développeur, architecte système,
Expert en base de données
