Énoncé des TP
Objectifs généraux
Les TP visent à amener l'étudiant à acquérir compétences techniques de développement d'une
interface utilisateur et à mettre en pratique les notions de conception ergonomique,
d'interface tout en les intégrant dans le cycle de développement logiciel.
Les TP se divisent en quatre volets :
- Élaboration des exigences utilisateurs et planification du processus centré-utilisateur. (TP1, barème)
- Conception de l'interface. (TP2, barème)
- Version fonctionnelle de l'application. (TP3, barème)
- Tests utilisateurs. (TP4, barème)
Le travail peut être fait par équipe de trois ou quatre personnes.
Projet de session
Le travail de session est divisé en quatre TP qui correspondent à quatre phases du cycle de
développement logiciel, notamment la spécification des exigences, la conception,
l'implantation et l'évaluation. Ces étapes sont décrites plus loin.
Le projet consiste à réaliser une application pour programmer un système de domotique
pour l'éclairage et le chauffage domestique. Le contexte est le suivant :
Contexte du TP
Votre entreprise décide de développer un logiciel dédié au contrôle de l'éclairage et du
chauffage des pièces d'une maisons unifamiliale. Chaque prise électrique et
chaque caille électrique de la maison est contrôlé par un microprocesseur programmable
dont voici les principales caractéristiques :
- Activation/désactivation d'une prise électrique ou d'un caille électrique à une
heure précise.
- Contrôle à distance à partir d'une connection Internet; la configuration peut donc
se faire à distance (ne vous souciez pas des détails techniques; nous présumerons qu'il a
une interface programmatique en conséquence).
- Microprocesseur qui possède sa propre horloge et qui peut être configurée par
l'interface programmatique (présumer que l'horloge est toujours à l'heure sans besoin
d'intervention aucune)
- État de chaque porte disponible à travers l'interface programmatique. N.B. Nous
référons indiféremment à une prise ou une caille par une porte.
Le logiciel s'adresse évidemment aux résidents du domicile, mais il n'est pas exclu
qu'une partie du logiciel soit opérée par des spécialistes de l'entreprise, par exemple
pour saisir les données initiales d'une maison (c.-à-d. les portes de chaque
pièce). On pourrait même décider qu'un service de configuration soit offert par
l'entreprise en tout temps moyennant un coût qui serait basé sur environ 100$/h pour
l'opérateur. Évidemment on ne ne peut présumer que tous les clients utiliseront ce
service régulièrement. L'analyse du contexte doit déterminer ce qui est raisonnable de
présumer ici.
La clientèle est celle des foyers relativement aisés (5% de la population en
général) et des maisons de 10 à 20 pièces typiquement. On peut présumer
qu'ils sont tous connectés à Internet. Le prix envisagé du système varierait entre
3 000$ et 6 000$. On fera valoir que les économies d'énergie et d'assurances
lorsque l'éclairage durant l'absence des occupants est activé pourrait rentabiliser le
système en 5 ans.
Le logiciel doit rouler avec Java.
On s'attend à ce que les équipes posent des questions supplémentaires pour mieux
définir les exigences. Ces questions seront rendues publiques à toutes les équipes, à
l'instar d'un processus d'appel d'offre. Le fait de poser les bonnes questions pourra
être tenu en compte pour l'évaluation.
Travail à faire pour le TP1 (10%)
Le premier TP doit fournir :
- Le plan des activités centrées-utilisateurs : on doit définir les activités que l'on intègrerait dans
le plan de projet pour assurer un processus de conception centré utilisateur. Ce plan n'est pas à suivre pour le TP en
lui-même mais le contexte est qu'il serait soumis au directeur de projet pour approbation. Pour les besoins, nous
présumerons un projet d'une durée de 2 à 3 mois et d'un budget de ressources humaines d'environ
10 mois-personnes (nous ne nous soucions pas ici du budget matériel et des autres frais). En plus des activités
et de leur échéancier, vous devez aussi préciser le type de ressources nécessaires. Libre à vous de
spécifier quelle proportion des 25 mois-personnes sont alloués à ces activités. Il importe de bien justifier
votre plan d'activités.
- Les exigences utilisateurs : au meilleur de votre connaissance et selon les démarches que vous aurez
faites, dont on peut présumer que certaines soient justement planifiées dans votre plan d'activités, définissez le
contexte d'utilisation et les exigences utilisateurs.
Utilisez les articles suivants pour vous guider :
Seul un rapport est à remettre. Maximum de 15 pages
(sans les annexes au besoin).
Barème TP1
- Plan d'activités centrées-utilisateurs (10 points)
- Exigences utilisateurs (10 points)
Détails de l'évaluation du rapport :
- La procédure planifiée pour l'élaboration des besoins
utilisateurs est adéquate et intégrée à un cycle de
développement clairement défini. (8 points)
- La description du contexte utilisateur, des besoins et caractéristiques des utilisateurs anticipés
est complète et adéquate. Les exigences utilisateurs identifiés sont bien justifiées. (8 points)
- La présentation du rapport est soignée et claire de même que la qualité de la
langue. (4 points)
Travail à faire pour le TP2 (5%)
Avec un logicel de dessin ou de prototypage rapide de votre choix, vous devez fournir la conception de l'interface du
logiciel. La conception doit rencontrer les principes de conception ergonomique d'interface utilisateurs et répondre aux
exigences utilisateurs mentionnées dans votre TP1.
Barème TP2
- Les maquettes d'interfaces sont claires et donne une idée précise
de l'interactivité. Elles couvrent les
principales exigences utilisateurs. (10 points)
- Les heuristiques de conception conviviale d'interface sont respectés. (10 points)
Travail à faire pour le TP3 (20%)
Le TP3 consiste à développer avec Java Swing une interface concue
à l'étape 2 et devant répondre aux besoins et tâches identiés
au TP1.
Ce TP comporte un rapport et un logiciel en Java Swing.
Le rapport doit préférablement être un document Javadoc contenant les
éléments suivants:
- Description de l'architecture (structure de classes et autres
éléments d'architecture pertinent)
- Description des classes, méthodes, paramètres, etc. selon les
modèles Javadoc courants.
Le logiciel doit être en format de fichier .jar,
comportant le code source et les fichier .class,
et pouvant être exécuté avec la commande suivante:
java -jar <fichier jar>
Barème TP3
Rapport (6 pts.)
- Architecture clairement définie
- Classes adéquatement documentée
Vous pouvez vous inspirer de la description du rapport
technique de INF2700 comme base à ce rapport. Le rapport doit être en format
Javadoc.
Logiciel (14 pts.)
- Fonctionnalité opérationnelle et conforme à la conception (s'il y a des différences justifiez-les avec un document en annexe).
- Richesse de la fonctionnalité
- Usage adéquat des gadgets et librairies Swing
- Bonne allocation des priorités des fonctions choisies
- Minimum d'erreurs d'exécution.
Travail à faire pour le TP4 (10%)
Tests utilisateurs
Le TP4 vise à mettre en pratique les notions de tests utilisateurs de même qu'à évaluer
l'utilisabilité de l'application. Les tâches ou les cas d'utilisation les plus importants
sont sélectionnés pour ces tests.
Il faut tester avec de véritables utilisateurs. Ces tests seront coordonnés par l'équipe. Les tests doivent déterminer si
l'utilisation de votre application rencontre ou non les exigences utilisateurs qui ont été définis et
permettre d'identifier les problèmes d'utilisabilité.
Les tests ne doivent pas dépasser 20 minutes.
Un rapport de test d'utilisabilité devra être soumis. Les problèmes et les correctifs
doivent être clairement identifiés. Ils ne seront toutefois pas implantés.
Consultez les tâches à réaliser
Barème TP4
Le rapport de tests heuristiques et de tests d'utilisabilité sera évalué selon les critères suivants :
- Les principes de conception d'interface sont respectés (6 points)
- Les problèmes principaux sont correctement identifiés (6 points)
- Les corrections suggérées sont valables et complètes (6 points)
- La présentation du rapport est soignée et claire de même que la qualité de la langue (2 points)
|