1°/ Objectif
Le but de ce rapport est de préciser le contexte et l'architecture logicielle/matérielle de l'application envisagée.
Le premier point correspond en gros à une synthèse d'un besoin client, alors que le deuxième point correspond au résultat de l'analyse de ces besoins, mais sans aborder les côtés fonctionnels. Cela correspond à une situation courante où une entreprise utilise une infrastructure logicielle et matérielle connue et maîtrisée et se débrouille pour la faire cadrer avec les besoins fonctionnels du client.
Ce n'est pas forcément une bonne idée, mais comme dans cette SAÉ, vous êtes à la fois les clients et les développeurs, vous êtes à même d'exprimer des besoins qui cadreront avec les contraintes de structuration qui vous sont imposées. Cependant, comme vous êtes à priori novices dans la programmation micro-contrôleurs et client/serveur, il est possible que vous imaginiez des fonctionnalités qui seront en définitive impossibles à réaliser. Cela n'est pas un problème et ne doit pas vous freiner dans la recherche d'idées pour votre sujet et leur synthèse dans ce rapport.
2°/ Contenu
À part la page principale donnant le titre de votre SAÉ et les membres du groupe, ce rapport prend plutôt la forme d'un compte-rendu de réunion, avec un format court de 4-5 pages. Il est découpé en 2 parties principales, détaillées ci-dessous
2.1°/ Synthèse des "besoins fonctionnels" (c.a.d. ceux demandés par le client)
Cette partie commence par présenter en quelques paragraphes quel est le cadre général de l'application, à quoi elle sert et qui sont les différents acteurs qui vont l'utiliser.
Ensuite, le principal scénario d'utilisation doit être présenté, de façon textuelle et/ou graphique. Ce scénario doit permettre de comprendre quelles vont être les interactions possibles des utilisateurs et quelles informations vont être visualisées/échangées/stockées/.... Comme la SAÉ vous impose d'avoir une partie front-end, il faut bien entendu que le scénario inclue cette partie
Si d'autres scénarios sont possibles/envisagés, il est également possible d'en présenter un ou deux, s'ils ont un réel intérêt pour mieux comprendre les besoins.
Enfin, cette partie ce termine sur une description "rapide" des différents types d'information qui vont être capturés, quels traitements certaines vont subir (par ex, détection de visages) et quelles sont les possibilités de visualisation des données stockées (types graphiques, statistiques, ...)
|
BIG WARNING Cette partie NE DOIT PAS se baser sur le fait que vous allez utiliser une architecture logicielle/matérielle quasi imposée. Par exemple, aucune mention de micro-contrôleurs, mobile, serveurs, api, java, node, etc ne doit être faite. Un vrai client ne se préoccupe pas de ça en général. Il compte sur les dev. pour trouver les solutions informatiques adaptées aux besoins. Par exemple, si on prend le prototype de maison intelligente qui sert de base à la SAÉ, un scénario minimal possible serait : "Un propriétaire qui achète notre solution de maison intelligente peut choisir un panel de boîtiers alimentés par pile et/ou réseau électrique domestique, qui vont mesurer différentes grandeurs : consommation eau/électrique, température, pression, ... Un installateur viendra installer et configurer ces boîtiers en fonction des besoins du propriétaire. Ces boîtiers enverront des informations à un boîtier central avec des communications sans fil, la contrainte étant qu'il soit alimenté en permanence et connecté au réseau informatique de la maison. Ce boîtier central permet de stocker sur plusieurs années les données envoyées par les autres boîtiers. Le propriétaire peut également interroger le boîtier central via un navigateur, et ainsi visualiser les données sous forme de graphiques, les filtrer, faire des statistiques" |
2.2°/ Structuration logicielle et matérielle
Grâce à une figure du même type que celle utilisée dans l'article sur le sujet de type 1, vous devez décrire les éléments matériels et logiciels qui vont être nécessaires pour implémenter l'application. Vous êtes libres d'ajouter des éléments pourvu que les contraintes données soient respectées.
Cette figure DOIT ETRE décrite et commentée, notamment pour préciser le rôle et éventuellement les choix technologiques liés à chacun des éléments (par ex, langage d'implémentation, bibliothèques utilisées, référence de capteurs, ...). A noter que la description du rôle doit faire le lien avec les scénarios et fonctionnalités donnés dans la partie 2.1.
Remarque : comme dit en introduction, il est possible que votre choix de structuration soit au final infaisable, notamment à cause de votre méconnaissance des micro-contrôleurs. Cela n'a aucune importance pour ce rapport préliminaire et n'aura aucun impact sur son évaluation. S'il y a besoin de modifications, vos référents SAÉ se chargeront de vous les transmettre après lecture de votre rapport.
Ce descriptif peut être éventuellement complété par des informations en lien direct, comme par des liens web vers les capteurs envisagés, des bibliothèques d'analyse de média, etc.
3°/ Planning
Le rapport doit être envoyé à sdomas@univ-fcomte.fr pour le dimanche 6 octobre, 23h59 dernier délai.