MAJORD HOME. Cahier des charges. 02 décembre 2011 K.BRETECHER - K.BERLAT - R.ESCUDIER - T.GARET - P.MANOT - L.CHAUVEL

Transcription

1 MAJORD HOME Cahier des charges 02 décembre 2011 K.BRETECHER - K.BERLAT - R.ESCUDIER - T.GARET - P.MANOT - L.CHAUVEL

2 Groupe: Nom du projet: Type de document : bretec_k berlat_k chauve_l garet_t escudi_r manot_p MAJORD HO ME Cahier des charges Version: 1.0 Référence: Statut du document : 2013_CDC4_FR_majordhome Terminé Résumé Ce document est le cahier des charges concernant le projet Majord Home. Vous trouverez tous les éléments nécessaires à l aboutissement de ce projet. En effet, dans un premier temps, nous détaillerons la nature du document et nous ferons une introduction, ensuite, nous décrirons la demande. Nous verrons également les contraintes et les verrous techniques, ensuite nous expliquerons les objectifs pour le bilan final, les tests «d acceptance» et le déroulement du projet. Vous trouverez enfin une conclusion. 1

3 SOMMAIRE 1. NATURE DU DOCUMENT OBJECTIF DU DOCUMENT PERIMETRE CE QUE COMPREND CE DOCUMENT CE QUE NE COMPREND PAS CE DOCUMENT INTRODUCTION CONTEXTE HISTORIQUE RAPPEL SUR NOTRE EIP OBJECTIF DE L EIP SUJET DE NOTRE EIP DESCRIPTION DE LA DEMANDE LES OBJECTIFS PRODUIT DU PROJET DESCRIPTION GENERALE LISTE DES FONCTIONNALITES ARCHITECTURE TECHNIQUE ARCHITECTURE TECHNIQUE DU SITE WEB CONTRAINTES ET VERROUS TECHNIQUES CONTRAINTES TECHNIQUES CONTRAINTES DES COUTS CONTRAINTES DE DELAIS AUTRES CONTRAINTES OBJECTIFS BILAN FINAL TESTS D ACCEPTANCE ACTIVER UN MODULE DESACTIVER UN MODULE LISTER LES MODULES ACTIFS LISTER LES MODULES INACTIFS LISTER LES MODULES INSTALLES CREER UN MODE PARAMETRER UN MODE SUPPRIMER UN MODE CHOISIR UN MODE CONTROLE VOCAL DEROULEMENT DU PROJET REPARTITION DES ROLES SUIVIS RECURRENTS

4 7.3. PLANIFICATION CONCLUSION ANNEXE TECHNOLOGIES UTILISEES SERVEUR CLIENT CLIENT MOBILE SITE WEB ILLUSTRATIONS Figure 1: schéma général... 8 Figure 2: Interface gestion de module Figure 3: Interface module lumière Figure 4: Détails Menu "fichier" Figure 5: déploiement Figure 6: cas d'utilisation Figure 7: etat d'avancement Figure 8: suivis récurrents

5 1. Nature du document 1.1. Objectif du document Ce document décrit l ensemble des éléments (programme, site web ) qui constitue notre projet. Il a pour objectif de décrire comment nous allons réaliser notre EIP et de définir les spécificités Périmètre Ce que comprend ce document les ressources disponibles ; le détail des technologies utilisées ; les objectifs de notre projet ; le sujet de l EIP Majord Home ; le principe de base de Majord Home ; les fonctionnalités de Majord Home ; l architecture technique de Majord Home et du site Web ; les contraintes ; le planning ; les dates de livrable ; le diagramme de Gantt. les objectifs de fin de Tech4 les tests d acceptation 4

6 Ce que ne comprend pas ce document les objectifs commerciaux ; les informations sur d éventuels sponsors et partenariats ; le protocole Serveur/Client. 2. Introduction 2.1. Contexte Majord Home est un EIP qui regroupe six membres: Kévin BRETECHER, Karim BERLAT, Romain ESCUDIER, Thomas GARET, Paul- Baptiste MANOT et Ludovic CHAUVEL. Un EIP est un projet innovant au sein d Epitech qui se déroule sur une période de trois ans et qui finalise le cursus. Au terme de cette période, le groupe présentera Majord Home au forum des innovations Ce projet s inscrit dans le domaine de la domotique et aura pour but de piloter différentes parties d une maison (portail, lumière, HIFI, alarmes, climatisation ). La domotique est l ensemble des techniques de l'électronique, de physique du bâtiment, d'automatismes, de l'informatique et des télécommunications utilisées dans les bâtiments. La domotique vise à apporter des fonctions de confort (optimisation de l'éclairage, du chauffage), de gestion d'énergie (programmation), de sécurité (comme les alarmes) et de communication (comme les commandes à distance ou l'émission de signaux destinés à l'utilisateur) que l'on peut retrouver dans les maisons, les hôtels, les lieux publics Historique L idée de développer Majord Home a grandi au sein d un groupe de six étudiants, passionnés par l informatique et les technologies innovantes. Le nom «Majord Home» rappelle le mot «majordome» «home» est un mot anglais se traduisant par «maison». Nous avons et 5

7 trouvé que le jeu de mots était intéressant Rappel sur notre EIP Objectif de l EIP Afin de mener notre projet à bien, nous nous sommes imposés comme objectif principal: la réalisation complète d une solution client-serveur. Comme objectifs secondaires: la réalisation de différents modules qui seront basés sur le protocole EIB / KNX. Ce protocole est respecté par une majorité des solutions du marché de la domotique, ce qui confirme notre choix ; la commercialisation de notre solution Sujet de notre EIP Majord Home est une solution qui s'inscrit dans la domotique, il pourra être piloté par une interface graphique, une interface vocale et une interface mobile. L utilisateur pourra utiliser différents types de solutions clients comme un Smartphone (ou une tablette électronique) sous Androïd ou ios, un ordinateur sous WINDOWS ou LINUX. Depuis l emplacement où est installé le système, il sera également possible de communiquer avec Majord Home via une interface vocale. Majord Home pourra intégrer différents modules tels que: la gestion de périphériques: HIFI, TV et informatique ; la gestion de lumière, climatisation et chauffage ; la gestion de portes et portails ; la gestion d'alarmes et caméras de surveillance. 6

8 Majord Home est innovant puisqu il intégrera une interface vocale et une interface mobile sous Androïd et ios. Certes il existe des solutions à contrôle vocale mais celles-ci ne sont pas compatibles avec des systèmes mobiles tels qu Androïd. Nous avons choisi de travailler sur un projet en rapport avec la domotique du fait que nous sommes convaincus que ce genre de solution deviendra indispensable. 3. Description de la demande 3.1. Les objectifs La réalisation complète d une solution client-serveur. La réalisation de différents modules (décrit dans le sujet) basés sur le protocole EIB/KNX. La commercialisation de notre solution Produit du projet Description générale À terme le but du projet est d avoir une solution client/serveur, capable d intégrer différents modules, visant à l automatisation complète d une maison. L utilisateur type serait un particulier désirant automatiser son domicile. Les professionnels pourraient être intéressés par Majord Home afin d automatiser des infrastructures légères. 7

9 FIGURE 1: SCHEMA GENERAL Liste des fonctionnalités Interaction vocale avec Majord Home. Interaction via une interface mobile Androïd ou ios. Activation et désactivation des différents modules (lumière, chauffage ). Gestion de différents profils basés sur plusieurs critères (économie d énergie ) Architecture technique Majord Home sera en plusieurs parties: une partie serveur (sous LINUX) ; une partie client (sous WINDOWS/LINUX) ; une partie client mobile (Androïd/iOS) ; une interface vocale. 8

10 La partie vocale: L'utilisateur parlera dans une pièce, transporter via les micros, le signal rejoindra un premier module du serveur. Ce module s'occupera de traduire le signal sonore en donnée traitable par le serveur via Julius. Julius prendra en entrée un signal sonore, en paramètre, une base de donnée de phonèmes et ressortira une série de mots permettant l'interprétation. Cette interprétation sera ensuite passée a un module qui décortiquera celle-ci pour en extraire les mots clé. Un troisième module reconnaitra les différents mots clé et permettra d'orienter les paramètres vers les modules de Majord Home afin de gérer les différents outils connecter au serveur. Apres le traitement de la requête, le module renverra un signal afin d'expliquer l'état de l'action. Le serveur enverra ce signal a un module qui se chargera de le traduire en réponse orale via Espeak. L'utilisateur pourra donc entendre le résultat de sa requête oralement. Le serveur: Le serveur sera relié au matériel vocal et au système de la domotique. Le client: Une API sera créée afin de pouvoir accueillir les différents modules rajoutés par de tierces personnes. Ce module modifiera le fichier de configuration, et ne nécessitera pas le redémarrage du serveur. La vue interagira avec le serveur via un des modules du serveur, le module de paramétrage (gestion des différents profils, rajout de module, etc...). 9

11 FIGURE 2: INTERFACE GESTION DE MODULE FIGURE 3: INTERFACE MODULE LUMIERE 10

12 FIGURE 4: DETAILS MENU "FICHIER" Le client mobile: La partie mobile sera sur un Smartphone ou une tablette électronique, il joindra le serveur par internet, permettant de gérer sa maison à distance. Une vue permettra de télécharger un fichier du serveur qui définira les différents outils disponibles et modules utilisables. Celle-ci sera créée en fonction de ce paramètre de configuration. 11

13 Diagrammes: FIGURE 5: DEPLOIEMENT 12

14 FIGURE 6: CAS D'UTILISATION 13

15 Architecture technique du site Web Le site web est composé de deux parties: une partie vitrine ; un intranet. La vitrine permettra de présenter notre EIP, et donnera un accès limité au forum, afin de se tenir au courant des dernières nouveautés L'intranet permettra à notre équipe de se concerter via un seul moyen, mieux organisé que les mails. Il comportera un forum, connecté à une base de données. Une autre partie permettra de gérer notre temps, à savoir définir le travail que l'on a effectué de manière précise, jour par jour. Une partie permettra de stocker des fichiers, version de logiciel, accessible partout, afin d'avoir un accès peu importe où l'on sera sur les différents livrables et documents nécessaires à la programmation de notre EIP. Et enfin une partie qui permettra toute la gestion du compte (adresse de messagerie, mot de passe etc...). 14

16 4. Contraintes et verrous techniques 4.1. Contraintes techniques Ce projet doit respecter des licences Open Sources. Notre serveur fonctionnera sous un system linux. Le client fonctionnera sous un system WINDOWS et LINUX Le client mobile fonctionnera sur un Smartphone ou une tablette électronique (sur Androïd ou ios) 4.2. Contraintes des couts Achat de deux Smartphones pour faire fonctionner le client mobile sous Androïd et ios. Achat d'un PC "all in one" touch screen pour faire fonctionner le serveur et le client. Achat de six PC pour développer Majord Home. Réservation d un nom de domaine pour héberger le site Web. Achat d un logo Contraintes de délais Finir le projet avant Février Autres contraintes Chaque membre du groupe est réparti dans différents pays du monde pendant la première année du projet, à cause des décalages horaires, l'utilisation de la visioconférence sera de rigueur. 15

17 5. Objectifs pour le bilan final Cahier des charges L objectif pour le bilan final de juillet 2012 est d avoir: un serveur à contrôle vocal opérationnel ; un client mobile tournant sur les plates-formes ios et Androïd ; un client tournant sur un PC Tablet Windows ; 6. Tests d acceptation 6.1. Activer un module Pré condition: Se situer sur l interface «gestion des modules» de l application ; Interactions: Le client doit sélectionner un module dans la liste, et choisir de l activer ; Résultats observables: Le module activé passe en couleur verte dans la liste Un message de confirmation est affiché à l écran 16

18 6.2. Désactiver un module Pré condition: Se situer sur l interface «gestion des modules» de l application ; Interactions: Le client doit sélectionner un module dans la liste, et choisir de le désactiver ; Résultats observables: Le module désactiver passe en couleur rouge dans la liste Un message de confirmation est affiché à l écran 6.3. Lister les modules actifs Pré condition: Se situer sur l interface «gestion des modules» de l application ; Interactions: Le client doit sélectionner le filtre «modules actifs» se trouvant sur la page; Résultats observables: Seuls les modules actifs seront listés ; 6.4. Lister les modules inactifs Pré condition: Se situer sur l interface «gestion des modules» de l application ; Interactions: Le client doit sélectionner le filtre «modules inactifs» se trouvant sur la page; Résultats observables: Seul les modules inactifs seront listés ; 17

19 6.5. Lister les modules installés Pré condition: Se situer sur l interface «gestion des modules» de l application ; Interactions: Le client doit sélectionner le filtre «modules installés» se trouvant sur la page; Résultats observables: Seul les modules installés seront listés ; 6.6. Créer un mode Pré condition: Se situer sur l interface «gestion des modes» de l application ; Interactions: Le client doit sélectionner «Créer un mode» ; Le client doit définir les paramètres du mode ; Le client finalise la création en sélectionnant le bouton «valider» ; Résultats observables: Le mode créé s ajoute à la liste des modes ; Un message de confirmation est affiché à l écran ; 18

20 6.7. Paramétrer un mode Pré condition: Se situer sur l interface «gestion des modes» de l application. Interactions: Le client doit sélectionner un mode dans la liste ; Le client doit sélectionner «paramétrer le mode» ; Le client finalise la modification en sélectionnant le bouton «valider» ; Résultats observables: Un message de confirmation est affiché à l écran ; 6.8. Supprimer un mode Pré condition: Se situer sur l interface «gestion des modes» de l application ; Interactions: Le client doit sélectionner un mode dans la liste; Le client doit sélectionner «supprimer le mode» ; Résultats observables: Le mode supprimé se retire de la liste des modes ; Un message de confirmation est affiché à l écran ; 19

21 6.9. Choisir un mode Pré condition: Se situer sur l interface «gestion des modes» de l application ; Interactions: Le client doit sélectionner un mode dans la liste ; Le client doit sélectionner «Utiliser le mode» ; Résultats observables: Le mode choisit apparait en vert dans la fenêtre de l application ; Un message de confirmation est affiché à l écran ; Contrôle vocal Pré condition: Se situer dans la maison à proximité d un micro; Interactions: Le client doit utiliser des mots clés pour contrôler les modules actifs; Résultats observables: Exécution de la commande ; Confirmation vocale du système à l utilisateur ; 20

22 7. Déroulement du projet 7.1. Répartition des rôles Nous sommes un groupe de six personnes, réparti en deux sous équipes de trois personnes. Il y aura une équipe chargée du développement du serveur et du client. La seconde équipe développera la partie client mobile. Durant la quatrième année, nous travaillerons de manière autonome. Néanmoins des réunions de pilotage seront organisées régulièrement afin d avoir un suivi interne. site Web. Les deux équipes travailleront ensemble sur le développement du Afin de visualiser le Gantt, allez dans le répertoire CDC puis visualisez le fichier 2013_GAN2_FR_majordhome.pdf 21

23 Début Fin Durée (Jours) Avancement Major d'home 28/02/ /10/ % Etude de l'existant 28/02/ /03/ % Etude détaillée 11/03/ /03/ % Draft du cahier des charges Cahier des charges et GANTT 30/03/ /04/ % 11/04/ /05/ % Logo 16/05/ /09/ % Réalisation 12/09/ /10/ % Conception 10/09/ /12/ % Client 13/10/ /12/ % Serveur 13/10/ /12/ % Protocole 12/09/ /10/ % Implémentation 13/12/ /06/ % Serveur 13/12/ /06/ % Module vocale 03/01/ /06/ % Diction 03/01/ /01/ % Reconnaissance vocale 24/01/ /06/ % Module BDD 13/02/ /03/ % Module de log 28/12/ /01/ % 22

24 Module de débogage 13/10/ /12/ % Module réseaux 13/12/ /02/ % Client Desktop 13/12/ /05/ % Vue 13/12/ /02/ % Contrôleur 13/02/ /05/ % Parseur XML 14/05/ /05/ % Client Mobile 13/12/ /06/ % Vue 13/12/ /03/ % Contrôleur 14/03/ /05/ % Réseaux 15/05/ /06/ % Parseur XML 14/05/ /05/ % Phase de tests 25/06/ /10/ % Site web 13/12/ /03/ % FIGURE 7: ETAT D'AVANCEMENT 23

25 7.2. Suivis récurrents Début Fin Description 6 octobre 2010 Cours présentation EIP (VisioConference) 19 novembre 2010 Forum EIP + 2e Cours + Validation QCM 30 janvier 2011 Fin validation Sujet 1 février février 2011 Passage en région Cours Documentations + Validation sujets 28 février 2011 Fin validation Groupes 11 mars 2011 Rendu etude de l'existant EDE + 50 Mots 30 mars 2011 Rendu Etude détaillée (ED) 11 avril 2011 Rendu Draft du Cahier des Charges 15 avril avril 2011 Passage en région 16 mai 2011 Rendu Cahier des Charges (CDC) + Gantt 6 juin juin 2011 Suivi CDC (visio conférence) 4 juillet juillet 2011 Bilan Architecture 12 septembre 2011 Rendu Logo Mots + Schemas 7 novembre décembre novembre décembre 2011 TECH4 Bilan Technique Bilan Documentations 5 janvier janvier 2012 Steering Comitee 6 février février 2012 Bilan Technique 5 mars mars 2012 Bilan Architecture + Documentations 2 avril avril 2012 Bilan Technique 24

26 2 mai mai 2012 Bilan Documentations + Steering Comitee 4 juin juin 2012 Bilan Technique Facultatif 2 juillet juillet 2012 Bilan Technique Final Tech4 15 août 2012 Jury + Demande Matériel Soutenances Finales 3 septembre 2012 Rendu Documents Forum 3 septembre septembre 2012 Soutenances Finales Tech4 TECH5 8 octobre novembre 2012 Bilan Forum 1 novembre décembre novembre novembre décembre 2012 Forum EIP Steering Comitee 3 Bilan Technique Facultatif 7 janvier février 2013 EIP - Final Technical Assessment Tech 5 1 février février 2013 EIP - Final Defense Tech 5 FIGURE 8: SUIVIS RECURRENTS 25

27 7.3. Planification Janvier 2011 Mai 2011: Réalisation de l étude de l existant, de l étude détaillée, du diagramme de Gantt et du Cahier des charges. Mai 2011 août 2011: Mise en place des outils de communication (choix du logo, création d un site Web vitrine et d un intranet). Août 2011: Définition d une charte graphique pour l interface utilisateur client/serveur. Août 2011: Mise en place du protocole de communication client/serveur. Septembre 2011 Novembre 2011: Conception du client/serveur. Décembre 2012 Novembre 2012: Implémentation client/serveur. 8. Conclusion Ce cahier des charges est vital puisqu il va définir les spécificités du projet, il nous a permis de rassembler dans un même document toutes les informations nécessaires à la réalisation de notre projet. Grâce à ce document, nous avons une meilleure visibilité sur la méthodologie à adopter pour mener à bien un projet de manière professionnelle. Nous pensons que ce projet constituera une réelle valeur ajoutée tant sur le plan personnel que professionnel. 26

28 9. Annexe 9.1. Technologies utilisées Serveur Concernant la conception nous opterons pour le langage UML sous Visio Pour la reconnaissance vocale nous allons utiliser Julius REV Pour la création des phonèmes nous utiliserons ESPEAK Pour la synthèse vocale nous utiliserons ESPEAK Pour ce qui est du stockage des phonèmes nous utiliserons des fichiers data. Pour réalisation du serveur nous utiliserons les langages C++ et XML. Pour ce qui est de l OS nous privilégierons une distribution basée sur UNIX. A ce jour nous n avons pas encore défini sous quel type de licence sera distribué Majord Home Client Concernant la conception, nous opterons pour le langage UML sous Visio Pour la partie réseau nous utiliserons le module QT NETWORK. Utilisation de QT 4.7 et QT SDK 1.1 pour toute la partie interface utilisateur. L environnement de développement sera essentiellement QT Creator. Pour réalisation du client nous utiliserons les langages C++ et XML. 27

29 Client mobile Concernant la conception, nous opterons pour le langage UML sous StartUML. Le client sera développé pour fonctionner sur la dernière plateforme Androïd 2.3. et compatible ios. Nous utiliserons le format XML utilisé par Androïd pour l interface graphique. Pour la réalisation du client sous Androïd, nous utiliserons Java (JDK) et pour la réalisation du client sous ios, nous utiliserons Objective C. L environnement de développement sera Eclipse Hélios Site Web Une partie intranet pour les communications de groupe. Une partie vitrine pour présenter notre projet. Les technologies utilisées seront: Html / PHP / MySQL / JAVASCRIPT 28