Le rendez-vous Q/R est fixé à jeudi 24/11, 13H devant le forum G.
Pour cause d'un conflit horaire avec le cours de stat, la séance Q/R est annulé. Elle sera reprogrammée plus tard dans la semaine. Les informations seront publiées le plus vite possible sur ce site.
Le rendez-vous Q/R est fixé demain à midi devant le forum D.
La phase 1 est disponible. L’énoncé vous laisse une grande liberté dans la mesure où le texte indique un minimum à fournir. Pour le reste (ce qui n'est pas spécifié), c'est à vous de choisir. Voici quelques informations utiles.
Une séance Q/R sera organisée mardi 22 novembre sur le temps de midi (local à déterminer). Pour que celle-ci se déroule bien, nous vous demandons de nous communiquer (sur l'adresse du projet) un mail par groupe avec les informations suivantes: * La liste des noms et adresse des membres du groupe. * Vos questions concernant l’énoncé du projet. * Deux suggestions de fonctions supplémentaires à ajouter au projet pour améliorer l'expérience de l'utilisateur. * Un titre sympathique pour votre projet. Comme annoncé, il vous faudra utiliser Git pour réaliser ce projet (obligatoire pour la phase 2 et 3). Nous vous demandons donc de vous inscrire sur la page https:/github.com/ et de nous communiquer dans l'e-mail également les pseudos github des membres du groupe. L'adresse utilisée pour cette communication sera l'adresse de référence pour les communications avec le groupe. La deadline pour ceci est fixé au dimanche 20 novembre à 23h59. Ceci donne une idée de la structure globale du SRD, elle peut être modifiée si besoin est.
Document de spécification des besoins (software requirements document): ———————————————————————————————————- 1 Introduction 1.1 But du projet Texte (d’une demi-page approximativement) décrivant les tenants et aboutissants du projet, et énumérant les différents types de personnes qui vont bénéficier de la réalisation du projet. 1.2 Glossaire Définition des termes, des acronymes et des abréviations utilisés dans le présent document. 1.3 Historique du document Tableau reprenant tous les changements effectués sur le document. Chaque ligne de celui-ci contiendra les champs suivants : numéro de version, auteur et date de la modification, description des changements. Le tableau sera trié de manière décroissante sur le numéro de version. 2 Besoins de l’utilisateur Cette deuxième section reprend les services que le système doit fournir aux utilisateurs, ainsi que les contraintes de fonctionnement du système. Elle doit être complète et consistante, et il faut qu’elle soit rédigée dans un langage spécialement compréhensible pour le client, c’est-à-dire en évitant entre autres tout terme ou détail techniques. 2.1 Exigences fonctionnelles Ce type d’exigences sera décrit en utilisant des diagrammes use case et en fournissant une description pour chacun d’entre eux (comme vu au cours théorique et aux exercices). 2.2 Exigences non fonctionnelles 2.3 Exigences de domaine 3 Besoins du système Cette troisième section décrit en détail les fonctionnalités du système (à partir de celles décrites à la section précédente), sans aborder (dans la mesure du possible) *comment* elles doivent être réalisées. 3.1 Exigences fonctionnelles Ce type d’exigences sera décrit en utilisant des diagrammes use case et en fournissant une description *plus détaillée* pour chacun d’entre eux (comme vu au cours théorique et aux exercices). 3.2 Exigences non fonctionnelles 3.3 Design et fonctionnement du système Cette partie sera décrite à l’aide des différents diagrammes UML vus au cours théorique et aux exercices. 4 Index des termes utilisés Contiendra, au moins, toutes les entrées du glossaire |
Assistants- Stéphane Fernandes Medeiros Archives
October 2017
Catégories
|