Vous trouverez ci-dessous en exemple certains éléments caractéristiques d'un Portfolio. L'étudiante fait le bilan des connaissances qu'elle a acquises et développées dans le cadre du cours "Analyse et modèles de conception" durant les semestres 2015 et 2016. Il s'agit ici de faire un récapitulatif des notions comprises et intégrées et de celles qui restent encore à atteindre. La juxtaposition d'expériences permet de comparer, et de montrer la progression dans la compréhension du problème.
Note: La présentation choisie ici par l'étudiante permet de mettre en relation une même démarche appliquée à trois sujets. Cette présentation est une des manières de présenter l'information, mais il y a de multiples façons d'organiser un Portfolio, selon les objectifs visés et les sensibilités de chacun.
Merci à Lora Joliquin d'avoir bien voulu partager une partie de son travail.
SkEasier
SkEasier est le nom de l'application que j'ai dû imaginer pour le deuxième semestre de ce cours. Ci-dessus, je décris ce qui a été fait pour parvenir à réaliser ce travail.
(De plus, durant le premier semestre, un travail similaire a été effectué, la différence est que les étapes et questionnements se basaient sur un logiciel déjà existant. J'avais choisi d'observer PONS.)
Les étapes de ce travail étaient de :
- Réfléchir à une application réalisable et ayant un concept qui n'existe pas encore. Le but est de présenter une idée de logiciel/application qu'on pourrait ensuite présenter à un développeur, donc si d'autres applications présentent déjà les fonctionnalités qu'on propose, il risque de ne pas être intéressé par le projet. Faire preuve d'imagination et trouver un concept qui lie l'utile à l'agréable, sans oublier une touche de nouveauté.
- Chercher ce qui existe déjà, avant de se lancer plus loin dans la conception d'un projet d'application/logiciel. Observer la concurrence et définir les fonctionnalités qui sont déjà proposées aux utilisateurs, relever les points qui paraissent insuffisants et qui pourraient être améliorés. Grâce à cette démarche, on évite de proposer une application redondante et qui n'intéressera pas les développeurs.
- Pouvoir définir le tout plus précisément, après avoir trouvé une idée/ un concept. Lister correctement les différentes fonctionnalités, commencer à réfléchir comment les présenter et comment elles vont fonctionner, déterminer les possibilités et limites de chacune d'entre elles.
- Ecrire une description générale de l'application. Trouver un nom.
- Utiliser un logiciel (Visualparadigm) pour faire une analyse textuelle, après avoir fait une description de l'application, pour mettre en évidence les différents acteurs. On peut ensuite faire les diagrammes de cas d'utilisation qui montrent les diverses fonctionnalités possibles pour chaque acteur et les diagrammes d'activités qui expliquent un peu comment se déroulent les interactions entre l'utilisateur et l'application.
- Grâce à l'analyse textuelle, il est possible de déterminer plus précisément quels acteurs ont quels besoins. On sait qui propose quelles fonctionnalités, cependant il reste à trouver les besoins de tous pour le bon fonctionnement de l'application. Ces besoins peuvent être aussi bien fonctionnels que non-fonctionnels.
- Et finalement, de créer une maquette de l’application. Balsamiq permet de faire cette démarche. Il faut alors imaginer l’interface et la mettre sur pied. Il faut travailler avec la perspective que cette maquette va être testée. Elle doit être claire et il faut donc présenter l’application de la meilleure façon afin de convaincre les testeurs et hypothétiquement un développeur. Il est donc bon de penser à tous les détails !
En résumé, les différentes tâches qui ont été réalisées sont:
- Rechercher une idée d'application
- Chercher la concurrence et comparer
- Décider/fixer les fonctionnalités de son application
- Définir les acteurs et créer les diagrammes
- Définir les besoins des différents acteurs
- Imaginer une interface et créer la maquette
Ce travail requiert plusieurs compétences :
- Faire des recherches sur internet
- Décider d'un thème de logiciel à trouver
- Argumenter
- Faire preuve de créativité
- Être à l'écoute des idées et conseils des autres
- Rechercher des logiciels concurrents
- Trouver un logiciel qui corresponde à mes attentes
- Observer le logiciel choisi et relever les lacunes
- Evaluer
- Développer un avis critique
- Faire preuve de créativité
- Modifier certaines de mes attentes
- Faire preuve de créativité
- Modifier certaines de mes attentes
- Délimiter les fonctionnalités de mon logiciel
- Organiser ces fonctionnalités
- Imaginer une description générale
- Rédiger
- Faire une analyse textuelle
- Déterminer quels sont les acteurs et leurs fonctions
- Faire des diagrammes de cas d'utilisation
- Faire des diagrammes d'activités
- Prendre du recul
- Déterminer les besoins de l'utilisateur
- Déterminer les besoins de l'application
- Etre capable de trouver les contraintes, etc.
- Etre capable de modéliser son idée en créant une maquette
- Rechercher les meilleures solutions
- Réfléchir et se remettre en question
Si on fait le bilan des compétences dont j’ai fait preuve pour ces tâches, on constate que :
- Je peux faire preuve d'imagination, même si trouver une idée n'est pas du tout simple car il y a actuellement beaucoup d'offres au niveau de la technologie. Pas facile d'avoir une idée innovante.
- C'est plutôt intéressant d'observer des applications déjà existantes et de déterminer quelles fonctionnalités sont manquantes. Déceler les lacunes demande un sens critique.
- Le fait d’amener d'autres nouveautés demande aussi une part de créativité et d'imagination. C’est quelque chose que j’aime particulièrement faire. Imaginer de nouveaux concepts, de nouvelles possibilités, etc. Je trouve cela enrichissant. De plus, le fait d'imaginer sa propre application est vraiment motivant surtout quand on est libre de décider de la direction dans laquelle on souhaite partir. On a pour ainsi dire carte blanche.
- C'est important d'avoir une idée très claire des fonctionnalités que l'on veut proposer pour pouvoir faire une description de l'application.
- J’ai appris que le fait de faire un diagramme de cas d'utilisation permet de fixer définitivement les fonctionnalités de notre application. On attribue à chaque acteur ce qu'il fait/peut faire. On y voit plus clair. Si le cours n’avait pas présenté cette notion, je n’aurais jamais effectué cette étape pour ce genre de travail. Avec les cours, j’ai découvert une marche à suivre à respecter si je désire pouvoir présenter une application plausible et complète.
- Le diagramme d'activité permet d'approfondir et de comprendre le fonctionnement. On ne reste plus seulement à la surface. Grâce à cette notion, j’ai dû me demandé « comment ça va marcher derrière l’écran ? » et c’est une notion importante que j’aurais omise. Elle est importante et complexe, mais j’ai particulièrement aimé cette étape.
- J’ai particulièrement apprécier le maquettage. Balsamiq a été facile à comprendre et j’ai adoré créer l’interface de ma propre application car je visualisais parfaitement ce que je souhaitais réaliser. L’avis des autres m’a aussi beaucoup aidée, je n’ai pas hésité à demander aux autres ce qu’ils en pensaient et écouter leurs critiques afin d’améliorer mon prototype.
Cependant, en prenant du recul, je me rends compte qu’il me reste encore ces objectifs à atteindre :
- Définir une idée d'application/logiciel n'est pas facile pour moi ! J'ai tendance à me perde parfois.. Soit dans les détails, soit parce que je veux faire des choses trop compliquées. Il m'est compliqué de mettre des limites à un concept.
- Il m’est encore difficile de trouver des solutions pour améliorer les fonctionnalités des applications déjà existantes. Je retiens le fait qu'il ne faut pas hésiter à demander l'avis des autres. Certainement que l'entourage peut apporter des conseils très intéressants ou des idées auxquelles nous n'aurions pas pensé.
- La principale difficulté a été de comprendre comment fonctionne les diagrammes et comment ils doivent être représentés pour être corrects. Je ne suis pas sûre d’avoir encore tout-à-fait compris comment ils sont censés fonctionner. C’est une notion très importante et qu’il me faut encore approfondir.
- Ce n'est pas facile de se familiariser avec un logiciel tel que "VisualParadigm". Il faut prendre le temps de comprendre comment il marche et ce qu'il est possible de faire. J’ai encore de nombreuses lacunes avec ce logiciel.
- Je ne suis pas encore capable de définir correctement les besoins fonctionnels et/ou non-fonctionnels. Je suis consciente que cela reste encore quelque chose de flou pour moi !
Cahiers de spécifications
La rédaction d’un cahier de spécifications a été effectuée à deux reprises (une pour chaque semestre) pour ce cours. Ces deux documents écrits consistaient à regrouper les différentes étapes et analyses, faites lors de l’analyse ou de la création d’un logiciel/d’une application (voir la section « SkEasier »).
Les étapes de la REDATION DU CAHIER DE SPECIFICATIONS étaient de :
- Rédiger une description générale. C’est une introduction qui sert à expliquer en quoi consiste l’application/le logiciel. On trouve les diverses fonctionnalités, on y présente aussi la concurrence et les éléments qu’on a déduit en comparant et analysant les fonctionnalités, déjà existantes ou non.
- Présenter brièvement le matériel utilisé pour les différentes étapes du travail. Soit, ici, Visualparadigm et Balsamiq qui sont les logiciels utilisés pour le bon déroulement du projet.
- Présenter les différents modèles de conceptions, soit l’analyse textuelle, le diagramme de cas d’utilisation et les diagrammes d’activités. Au travers de cette présentation, il faut aussi décrire et expliquer comment fonctionnent et comment sont pensés tous ces éléments.
- Ajouter le maquettage. Expliquer comment l’interface a été pensée et quels étaient les objectifs désirés, visés.
- Intégrer le résultat des tests de prototypes. Observer les résultats et en tirer des conclusions en expliquant ce que les testeurs ont pensé de l’application, des fonctionnalités et de l’interface. Lister les ajouts et améliorations qui sont à faire ou qui pourraient être faits par la suite.
- Lister les besoins fonctionnels et non-fonctionnels des acteurs. Expliquer de manière claire de quoi il s’agit, donner des détails.
- Imaginer ce qui se cache derrière l’application. Donner les informations de maintenance, qu’est-ce qu’il faudrait faire pour que l’application/le logiciel puisse encore évoluer par la suite. Quels sont les choses qui doivent être mises à jour, quelles modifications pourrait-on apporter avec le temps, etc. Toute cette réflexion sur l’avenir de l’application doit être mise par écrit.
- Pour finir, ajouter un glossaire où on donne une définition claire des termes utilisés dans le dossier et pouvant être mal interprétés ou incompris par le lecteur.
En résumé, les différentes tâches qui ont été réalisées sont:
- Rédiger un cahier décrivant les différentes étapes de la réflexion
- Respecter une certaine hiérarchie structurelle
- Expliquer les étapes de façon à ce qu’un lecteur extérieur soit en mesure de tout comprendre
- S’exprimer de manière claire et en un langage technique
- Donner tous les points fondamentaux vus dans la section « SkEasier »
Ce travail requiert plusieurs compétences :
- Rédiger de manière compréhensible
- Suivre la structure demandée
- Ne pas oublier de détails
- Utiliser un vocabulaire clair et technique
- Garder un fil rouge tout au long du dossier
- Expliquer de manière claire les illustrations
- Intéresser le lecteur
- Argumenter ses choix
- Défendre ses idées
- Garder un avis critique sur ce que l'on écrit
- Accepter la critique des relecteurs
Si on fait le bilan des compétences dont j’ai fait preuve pour ces tâches, on constate que :
- J’arrive à garder un fil rouge tout au long de mon texte, même s’il est divisé. J’aime expliquer les choses telles que je les ai pensées et j’argumente. Je suis consciente que ce dossier pourrait être, hypothétiquement, donné à un potentiel développeur. Il faut donc être convaincante et avoir pensé à tous les détails. C’est un travail long, mais qui me plaît.
- Je suis capable de respecter la structure qu’on m’impose et de présenter toutes les étapes demandées.
- Il est aussi important de demander l’avis des autres. C’est un service que je n’ai pas peur de demander et que j’ai l’habitude de faire. Les conseils de lecteurs extérieurs sont bons et je modifie mon dossier au fur et à mesure que j’avance.
- J’écris le cahier de spécification petits bouts par petits bouts. Je fais en sorte de suivre et écrire parallèlement au développement et aux recherches faites sur/pour l’application. Cela me permet de ne pas perdre d’informations importantes ou réflexions qui pourraient servir d’arguments.
Cependant, en prenant du recul, je me rends compte qu’il me reste encore ces objectifs à atteindre :
- Je ne suis parfois pas capable de m’exprimer de manière succincte. Je rédige des phrases trop longues et je perds le lecteur.
- Certaines notions comme les digrammes de cas d’utilisation ou d’activités sont durs à créer pour moi car je n’ai pas encore compris tout ce qui se cache derrière. Par conséquent, en expliquer leur fonction dans mon cahier de spécifications me semble parfois difficile.
- C’est très compliqué d’écrire en langage technique et de ne pas rédiger son texte en langage académique lorsqu’on y est habitué.
- J’ai souvent l’impression que des phrases sont présentes, mais finalement pour ne rien dire.
Test de prototypes
Avant de remettre un projet à un développeur, il faut s’assurer de la pertinence de toute l’application. Est-ce que tout fonctionne, est-ce que tout a été réglé dans les détails. Il faut donc faire passer toute une série de tests à son application pour s’assurer de son bon fonctionnement et n'offrir que de très faibles possibilités de critique de la part du développeur. Un de ces tests consiste à faire tester son application par des testeurs anonymes.
Les étapes du TEST DU PROTOTYPE étaient de :
- Prendre du recul par rapport à son projet et de se demander quels seraient les aspects qui pourraient ne pas plaire ou qui pourraient restés incompris par le public.
- Formuler des questions et créer un questionnaire cohérent avec la maquette testable qu'on propose aux testeurs. Il a fallu décider quelle forme doivent prendre les questions... les laisser ouvertes ou chercher à ce que le testeur ne puisse répondre que par une appréciation, variant entre "pas du tout" et "oui totalement".
- Recueillir les réponses et prendre connaissances des critiques et conseils qui sont donnés par les différents testeurs.
- Faire une synthèse et pointer les fonctionnalités ou aspects qui doivent être rapidement modifiés. Les conseils d'amélioration ou de développement des nouvelles fonctionnalités peuvent aussi être pris en compte et retenus pour des ajouts futurs à l'application. Une façon de déjà prévoir son évolution.
En résumé, les différentes tâches qui ont été réalisées sont:
- Se demander ce qu’on aimerait que les testeurs testent
- Lister les fonctionnalités ou aspects de l’application pour lesquels on désire un avis qui corresponde au scénario proposé par la maquette
- Faire tester sa maquette, récolter et analyser les résultats des questionnaires
- Faire les changements nécessaires sur son application
Ce travail requiert plusieurs compétences :
- Prendre du recul
- Cibler ses questions
- Créer un questionnaire qui corresponde au scénario proposé par la maquette
- Faire passer les questionnaires aux testeurs
- Récolter et comptabiliser les résultats
- Analyser les résultats
- Accepter la critique des testeurs
- Modifier les aspects qui semblent nécessaires
- Envisager certaines futures retouches
Si on fait le bilan des compétences dont j’ai fait preuve pour ces tâches, on constate que :
- Il faut être prêt à se remettre en question et à accepter les critiques des testeurs même si elles sont négatives. Je modifie volontiers dans la mesure du possible les choses que les testeurs me le conseillent. Par contre, je n'ai pas hésité à prendre parfois quelques risques en laissant certaines choses comme je les avais conçues et perçues.
- J'ai trouvé enrichissant le fait de partager et tester nos prototypes entre élèves du même cours. Les idées des autres sont très intéressantes et toutes divergent. Aucune ne ressemble à une autre, cette diversité montre à quel point nous avons tous des attentes différentes au quotidien et qu'il est difficile de plaire ou satisfaire tout le monde.
- Le défi pour la création d'un logiciel ou d'une application est d'être capable de sentir et suivre les attentes du public et de savoir évoluer en conséquence. Le questionnaire permet donc ainsi de voir quelles fonctionnalités semblent manquer pour certains testeurs et de pouvoir envisager de les ajouter par la suite pour couvrir un public toujours plus large. Mes questions m'ont pu aidées à trouver des nouvelles ouvertures pour le futur.
Cependant, en prenant du recul, je me rends compte qu’il me reste encore cet objectif à atteindre :
- Je trouve difficile de cibler les aspects pour lesquels on souhaite recevoir un avis. Les questions n'ont pas été simples à trouver pour moi. Je ne savais pas quoi demander aux testeurs.
Ci-dessus, on trouve le questionnaire ainsi que les résultats et la synthèse de cette étape essentielle dans la conception et création d'une application.
Questionnaire
Résultats du questionnaire
Synthèse des résultats
La maquette de SkEasier (présentée au haut de la page) a été testée par des utilisateurs et évaluées. Les testeurs ont rempli un questionnaire composé de questions ciblées. Il en ressort que l’interface de SkEasier plaît et semble être clair pour tous.
La page de recherche par canton ou par entrée directe dans la barre de recherche convient à la plupart des testeurs. La simplicité et le gain de temps sont des éléments très appréciés. En ce qui concerne la page d’accueil de la station sélectionnée, elle ne suscite pas non plus de problème. SkEasier peut visiblement facilement convenir à tous types d’utilisateurs.
Grâce au questionnaire, la nécessité de pouvoir accéder à cette application depuis l’ordinateur a été soulignée. D’autres fonctionnalités qui pourraient être envisageables pour la suite ont aussi été proposées tels que :
- Une section de contact afin que l’utilisateur puisse directement communiquer avec les responsables de l’application.
- La possibilité d’acheter son abonnement directement depuis SkEaiser.
- L’amélioration de la page « quantité de neige » en y ajoutant le danger d’avalanches.
- La possibilité de mettre des stations en favoris dans une rubrique personnelle.
- Une fonctionnalité de comparaison entre stations. L’utilisateur choisit et entre certains critères (comme par exemple : l’altitude, la région, le budget, la difficulté de pistes, etc.). Ensuite, SkEasier lui propose les deux stations qui correspondent le plus à sa demande.
Toutes ces fonctionnalités sont possibles et peuvent être ajoutées petit à petit. Le test du prototype a donc montré que SkEaiser est une application déjà assez complète, simple, utilisable par tous et qu’elle peut être améliorée au niveau de ce qu’elle propose. Elle satisfait déjà la grande majorité des testeurs.