_  le système a étudié est le superviseur ou le segway dans son ensemble ?
le système étudié est bien le superviseur. Une premiere partie du support presente le segway et comment il fonctionne mais dans un second temps, vous vous concentrez sur un sous système du segway, le système de supervision et contrôle, appelé superviseur.
il s’agit d’un module logiciel, qui assure l’asservissement et le contrôle (accélération, sécurité du pilote..) du segway.
Il s’exécutera sur une carte raspberry, sur laquelle s'exécute Xenomai, le système d’exploitation temps réel qui permettra a votre application de respecter les contraintes de multitâche et de temps. Sur la carte STM32 sera simulé le comportement physique du système (envoi de commande vers les moteurs et actionneurs, et reception des informations sur l’état et le comportement du segway).

_ Faut il produire un diagramme de contexte par cas d'utilisation ou un seul diagramme en prenant en compte tous les cas d'utilisation ?
vous ne faites qu’un seul diagramme de contexte, faisant apparaitre le superviseur comme une boite noire, les parties prenantes externes, et les interfaces, ainsi que les échanges de contrôles et de données qui transitent sur ces interfaces. l’étape d’analyse fonctionnelle consistera a identifier les fonctions assurées par cette boite noire et a les organiser de façon a relier les entrées et sorties de chacune. l’analyse organique aura pour objectif de proposer une solution (une architecture logicielle) qui permettra la bonne exécution de ces fonctions par une ensemble de taches que vous caractériserez.

_ Dans la question 2 de template, qu'entendez vous par "éliciter » ?
élicitation est un terme consacré en ingénierie des exigences …

Le processus d’élicitation des exigences implique un ensemble d’activités de communication, négociation et collaboration avec les parties prenantes. 

L’élicitation (élucider) des exigences est le processus de recherche, découverte, acquisition et élaboration des exigences d’un système. En effet, les exigences doivent être élicitées et non juste capturées. Eliciter nécessite de comprendre le domaine de l’application, d'identifier les sources des exigences, d'analyser les besoins des parties prenantes, de choisir des techniques, approches et outils les plus appropriés. 

l’Ingénierie des exigences comprend l’élicitation, la spécification, l’analyse, la vérification, la validation, la gestion, des exigences…

pour plus de précisions, 

Dans le cas du TP, l’licitation est assez simple, il suffit de bien lire le sujet… 
Vous devez par contre :
- spécifier ces exigences (les exprimer clairement dans un tableau, voir s’il faut les raffiner en exigences dérivées) (voir mémo sous moodle)
- les classer (cela permet aussi de voir si vous n’avez pas oublié certaines catégories d’exigences), voir mémo sous moodle
- les vérifier (sont-elles précises, non ambiguës, cohérentes, complètes… voir mémo sous moodle)
pour la gestion, vous assurerez ultérieurement la traçabilité avec la suite de l’analyse.


Modifié le: mardi 17 mars 2020, 16:19