Spécif fication et IGL 301 t vérificati ion des exi igences
Transcription
Spécif fication et IGL 301 t vérificati ion des exi igences
Plan de cou urs IGL301 – Spécificaation et vérificaation des exigeences Été 2013 Département D d’informatiq que IGL 301 Spéciffication ett vérificatiion des exiigences Plan P de courrs Été 2013 Enseignan nt Benoît Fraikin Courrieel : Local : Télépho one : Site : Dispon nibilité : Benoiit.Fraikin@US Sherbrooke.ca D4-20 009 (819) 821-8000 postte 62013 http:///pages.usherbrooke.ca/bfraikkin/Cours/IGL3301 à déteerminer, à vériffier par courrieel Horaire Mardi Vendreedi 13h30 à 15h20 8h30 à 10h20 salle D3-2040 salle D3-2040 1 Descriptio on officielle dee l'activité péd dagogique Objectifs Spéciifier, valider et vérifier les exigences des cliients; en déduirre une architeccture technologgique Contenu Spéciifications foncttionnelles et no on fonctionnellles. Diagramme de flux de doonnées et modèèles de données. Spécification textuelle t des ex xigences. Cas dd'utilisation et scénario. Valiidation des exiggences. Génératiion de scénario os de tests d'accceptation. Élabboration de l'arcchitecture. Préésentation des nnormes de spéciffication IEEE. Crédits 3 Organisatio on 3 heu ures d’exposé magistral m par seemaine 6 heu ures de travail personnel p par semaine s Concomitaante IFT 232 2 1 http://ww ww.usherbrooke..ca/fiches-cours/igl301 Plan de cours 1 IGL301 – Spécification et vérification des exigences Été 2013 Introduction 1.1 Définitions DC DD DFD ERD IEEE IE IHM MCD OOA PDOA SA SADT SDD SRS SSADM SyRS UML 1.2 1.2.1 diagramme de contexte dictionnaire de donnée diagramme de flux de donnée (data flow diagram) entity relationship diagrams (diagramme entité-association) The Institute of Electrical and Electronics Engineers, inc. ingénierie des exigences interface homme-machine (HIM human machine interface) modèle conceptuel de donnée object-oriented analysis (analyse orientée-objet) problem domain oriented analysis (analyse dirigée par le domaine du problème) structured analysis (analyse structurée) structured analysis and design technique (analyse structuré et technique de conception) software design document (spécification de conception du logiciel) software requirement specification (spécification des exigences du logiciel) system structured analysis and design method (analyse structure de système et méthode de conception) system requirement specification (spécification des exigences du système) Unified Modeling Language Références Références obligatoires [IGL301] B. Fraikin Recueil de notes de cours pour IGL301 Disponible sur le site du cours. 1.2.2 Références du recueil de texte [IGL-1] Eric J. BRAUDE. Software Engineering : An Object-Oriented Perspective. Wiley, 2001. [IGL-2] Eric J. BRAUDE. Software Design : From Programming to Architecture. Wiley, 2003. [IGL-3] Jane CLELAND-HUANG. « Software Requirements ». Dans Software Engineering — Volume 1 : The Development Process [20], pages 113–123. [IGL-4] Alan M. DAVIS. « A Comparison of Techniques for the Specification of External System Behavior ». Commun. ACM, 31(9):1098–1115, 1988. 29-04-2013 Page 2 sur 9 Plan de cours IGL301 – Spécification et vérification des exigences Été 2013 [IGL-5] Joseph A. GOGUEN et Charlotte LINDE. « Techniques for Requirements Elicitation ». Dans Requirements Engineering, 1993., Proceedings of IEEE International Symposium on, pages 152–164, janvier 1993. [IGL-6] Jon G. HALL, Lucia RAPANOTTI et Michael JACKSON. « Problem Frame Semantics for Software Development ». Software and Systems Modeling, 4(2):189–198, mai 2005. [IGL-7] Michael A. JACKSON. Software Requirements & Specifications. Addison-Wesley, 1995. [IGL-8] Michael A. JACKSON. Problem Frames : Analysing and structuring software development problems. Addison-Wesley, 2001. [IGL-9] Jessica KEYES. Software Engineering Handbook. Auerbach Publications, 2003. [IGL-10] Gerald KOTONYA et Ian SOMMERVILLE. Requirements Engineering : Processes and Techniques. Wiley, 1998. [IGL-11] Soren LAUESEN. Software Requirements : Style and Techniques. Addison-Wesley, 2002. [IGL-12] Dean LEFFINGWELL et Don WIDRIG. Managing Software Requirements : A Use Case Approach. Addison-Wesley, 2e édition, 2003. [IGL-13] Patrick H. LOY. « A Comparison of Object-Oriented and Structured Development Methods ». Dans Software Requirements Engineering [21], pages 308–323. [IGL-14] Colin J. NEILL et Phillip A. LAPLANTE. « Requirements engineering : the state of the practice ». IEEE Software, 20(6):40–45, décembre 2003. [IGL-15] James D. PALMER. « Traceability ». Dans Software Engineering — Volume 1 : The Development Process [20], pages 141–150. [IGL-16] Mauro PEZZÈ et Michal YOUNG. Software Testing and Analysis : Process, Principles, and Techniques. Wiley, 2007. 29-04-2013 Page 3 sur 9 Plan de cours IGL301 – Spécification et vérification des exigences Été 2013 [IGL-17] Roger S. PRESSMAN. Software Engineering : A Practitioner’s Approach. McGraw-Hill, 6e édition, 2005. [IGL-18] Ian SOMMERVILLE. Software Engineering. Addison-Wesley, 8e édition, 2007. [IGL-19] Cyril P. SVOBODA. « Structured Analysis ». Dans Software Requirements Engineering [21], pages 255–274. [IGL-20] Richard H. THAYER et Mark J. CHRISTENSEN, éditeurs. Software Engineering — Volume 1 : The Development Process. Wiley, 3e édition, 2005. [IGL-21] Richard H. THAYER et Merlin DORFMAN, éditeurs. Software Requirements Engineering. IEEE Computer Society Press, 2e édition, 1997. [IGL-22] Axel VAN LAMSWEERDE. Requirements Engineering : From System Goals to UML Models to Software Specifications. Wiley, 2009. [IGL-23] Hans VAN VLIET. Software Engineering : Principles and Practice. Wiley, 3e édition, 2008. 1.2.3 Références importantes [Bray] Ian K. BRAY. An Introduction to requirements engineering. Addison-Wesley, 2002. ISBN 0-201-76792-9 ; UdeS QA 76.758 B744 2002. Disponible à la Coopérative étudiante de l'Université de Sherbrooke. [Davis2010] Alan M. DAVIS. Requirements Bibliography. http://www.reqbib.com/reqbib-abcd.htm (consulté le 2012-04-15) [GDT] Office québécois de la langue française. Grand dictionnaire terminologique. http://www.grandictionnaire.com/ (consulté le 2012-04-15). [GLOGUS] Luc LAVOIE. GLOGUS – recueil de modèles de documents pour le développement logiciel. http://pages.usherbrooke.ca/llavoie/glogus.php Département d’informatique, Faculté des sciences, Université de Sherbrooke, Sherbrooke, Canada, janvier 2009. 29-04-2013 Page 4 sur 9 Plan de cours IGL301 – Spécification et vérification des exigences Été 2013 [IEEE1233] IEEE Guide for Developing System Requirements Specifications. IEEE Std 1233-1998, IEEE, New York, 1998; [QA 76.76 S73I438 1998] [IEEE830] IEEE Recommended Practice for Software Requirements Specifications. IEEE Std 830-1998, IEEE, New York, 1998; [QA 76.76 S73I44 1998] [IEEE12207] Industry Implementation of International Standard ISO/IEC 12207-1995. IEEE 12207, IEEE, New York, 1995. [QA 76.76 S73I44 1998] [ISO12207] ISO/IEC 12207 - Information Technology—Software Life-Cycle Processes. 1995. [WOL] Wall-On-Line : l'e-gouvernement wallon, La boîte à outils : 15 méthodes d'implication des utilisateurs, disponible à l’adresse http://pages.usherbrooke.ca/llavoie/projets/GLOGUS/wall-on-line.pdf 2 2.1 Présentation Mise en contexte Le génie logiciel traite de la configuration d’une machine universelle (ordinateur) dans le but d’atteindre un objectif spécifique. Le logiciel de configuration peut lui aussi être vu comme une machine, mais il diffère des autres machines en ce sens qu’il est intangible. Le génie logiciel doit son nom et sa constitution comme un domaine de connaissance propre à la tenue d’un séminaire organisé par l’OTAN à Garmisch-Partenkirchen en Autriche en 1968. Le logiciel de configuration d’une machine universelle est désigné sous plusieurs appellations différentes, selon la caractéristique mise de l’avant : logiciel (intangibilité), programme (déterminisme), système (complexité). Puisqu’on construit généralement un système pour atteindre un but donné, il est préférable de déterminer et de détailler d’abord quel est ce but. Ce qui nous amène à l’ingénierie des exigences, la partie du génie logiciel qui permet de déterminer quel système sera développé. Note : L’expression « spécification des exigences » est parfois utilisée pour désigner l’ingénierie des exigences dans son ensemble ; nous préférerons la réserver pour désigner une activité précise au sein de celle-ci, à savoir l’activité par laquelle on déduit (on conçoit) et met en forme, selon des critères rigoureux, les exigences issues des activités préalables d’exploration et d’analyse. 2.2 Objectifs spécifiques Au terme de cette activité pédagogique, la personne l’ayant réussie sera capable de : appliquer le processus de spécification des exigences ; établir les relations entre le processus logiciel et la spécification des exigences ; établir la structure d’un document de spécification des exigences ; appliquer les techniques d’exploration des exigences ; appliquer les techniques de spécification des exigences ; vérifier les exigences ; générer des scénarios de test fonctionnel ; déduire une architecture technologique. 29-04-2013 Page 5 sur 9 Plan de cours 3 IGL301 – Spécification et vérification des exigences Été 2013 Contenu Les références à droite des sections ou des sous-sections du cours indiquent des sources d’informations complémentaires au cours. Une référence de la forme ID indique qu’il faut se référer à la publication [ID] de la section 1.3. Lorsqu’elle est suivie d’une indication entre parenthèses, il s’agit des chapitres ou des sections du livre correspondant à [ID]. Ainsi, Bray (1) indique que l’information est contenue dans le chapitre 1 de [Bray]. Finalement, si la référence est soulignée, c’est qu’elle est contenue dans le recueil de texte. 0. Introduction 0.1. Mise en contexte historique ...........................................................................Bray (1) ; IGL-3 ; IGL-14 ; IGL-18 (6) 0.2. Terminologie ..................................................................................................................... Bray (1, 2) ; IGL-7 ; GDT 1. Procédés et processus de développement logiciel ......................................................................................... IGL-23 (3) 1.1. Prédictifs (cascades, V, etc.) ..................................................................................................................... IGL-17 (2) 1.2. Itératifs (itératif simple, spirale, unifié, etc.) ........................................................................ IGL-17 (3), IGL-12 (3) 1.3. Agiles (XP, Scrum, etc.) ........................................................................................................................... IGL-17 (4) 1.4. Spécification : le matériel versus le logiciel .............................................................................................. IGL-12 (3) 1.5. Normes IEEE, ISO, militaires et aérospatiales .................................................... IEEE830 ; IEEE1233 ; IEEE12207 2. Procédés et processus d’ingénierie des exigences.............................................................................. Bray (2) ; IGL-11 2.1. Exploration .................................................................................................................................................... Bray (3) 2.2. Analyse – Étude du domaine .....................................................................................................Bray (4) ; IGL-17 (8) 2.3. Analyse – Spécification .............................................................................................................Bray (5) ; IGL-23 (4) 2.4. Validation ............................................................................................................. Bray (6) ; IGL-10 (4) ; IGL-16 (2) 2.5. Architecture et Conception interne ............................................................................................................ IGL-9 (12) 3. Documentation du processus d’IE 3.1. Document de vision, énoncé de portée et mandat ................................................................. IGL-12 (16), GLOGUS 3.2. Document de spécification des exigences .................................................................................................. GLOGUS 3.3. Glossaire ....................................................................................................................................... IGL-7 ; GLOGUS 3.4. Références ................................................................................................................................................. GLOGUS 3.5. Spécification ............................................................................................................................. IEEE830 ; IEEE1233 3.6. Traçabilité .................................................................................................................................. IGL-15 ; IGL-10 (4) 4. Techniques d’exploration/d’élicitation 4.1. Cartes d’acteurs ................................................................................................................................................. WOL 4.2. Entrevues et questionnaires ........................................................................................................... Bray (3, 9) ; WOL 4.3. Ateliers 4.3.1. Brain storming.............................................................................................. Bray (9), IGL-12 (12), WOL 4.3.2. Mind mapping et tri par cartes .......................................................................................................... WOL 4.3.3. Focus Group ..................................................................................................................................... WOL 4.3.4. Storyboarding ........................................................................................................................ IGL-12 (13) 4.3.5. Survol de quelques autres méthodes en atelier ........................................................... IGL-12 (11) ; WOL 4.4. Analyse de documents ..................................................................................................................... Bray 3, 9 ; WOL 4.5. Observation et analyse des tâches ................................................................................................... Bray 3, 9 ; WOL 5. Méthodes d’analyse 5.1. Analyse pilotée par le problème ..........................................................................................Bray (4.5) ; IGL-8 (2, 3) 5.1.1. Présentation 5.1.2. Quelques exemples avec les diagrammes de Jackson 5.1.3. Validation 29-04-2013 Page 6 sur 9 Plan de cours IGL301 – Spécification et vérification des exigences Été 2013 5.2. Analyse structurée .............................................................................................................. Bray (4.3, 13.1) ; IGL-19 5.2.1. Présentation 5.2.2. Quelques exemples avec SA, SADT et SSADM 5.2.3. Validation 5.3. Analyse orientée objet ..............................................................................................................Bray (4.4) ; IGL-1 (3) 5.3.1. Présentation 5.3.2. Quelques exemples avec UML 5.3.3. Validation 6. Techniques d’analyse et de spécification 6.1. Présentation ............................................................................................................................................... Bray (4, 5) 6.2. Langue naturelle ......................................................................................................................................... Bray (14) 6.3. Diagramme de contexte (DC)............................................................................................. Bray (13.1), IGL-17 (8.1) 6.4. Modèles conceptuels de données (MCD) ................................................................................................. Bray (13.3) 6.4.1. Diagramme entité-association (ERD) 6.4.2. Dictionnaire de données (DD) 6.5. Diagramme de flux de données (DFD) .............................................................................. Bray (13.1), IGL-17 (8.6) 6.6. Tables de décision ...................................................................................................................................... Bray (14) 6.7. Diagrammes état-transition ..................................................................................................................... Bray (12.6) 6.7.1. Automate 6.7.2. Machine à états 6.7.3. Diagramme à états (State Chart) 6.8. Pseudo-code ............................................................................................................................................... Bray (14) 6.9. Cas d’utilisation....................................................................................................................................... IGL-12 (14) 6.10. Diagrammes statiques d’UML................................................................................................................. IGL-2 (3) 6.11. Diagrammes dynamiques d’UML ........................................................................................................... IGL-2 (3) 6.12. Maquettage ................................................................................................................... Bray (11.2), IGL-18 (16.4) 6.13. Prototypage................................................................................................................... Bray (11.3), IGL-18 (17.4) 6.14. Diagrammes de Jackson (Jackson’s Frames) ...................................................................................IGL-8 ; IGL-6 7. Techniques de validation ..............................................................................................................Bray (6) ; IGL-10 (4) 4 Organisation 4.1 Modalités d’enseignement Les périodes de cours visent à expliquer la matière contenue dans les manuels de référence. L’étudiante, l’étudiant, est responsable d’effectuer préalablement les lectures correspondant au sujet de la semaine. Les travaux dirigés présentent des exercices individuels ou en groupe selon les exigences du programme et les besoins des étudiantes et des étudiants. Les travaux pratiques consistent en des prestations nécessitant l’utilisation de concepts, de méthodes et de techniques présentées en cours. Ces travaux ne comprennent pas de programmation. 4.2 Modalités d’évaluation L’évaluation porte sur : six tests en classe ; un travail de session en deux parties (TS1 et TS2); cinq notes de lectures ou des comptes-rendus d’activité ; un examen final. Les tests de lecture, d’une durée d’au plus 15 minutes, sont effectués au début d’une période de cours fixé dans le calendrier. La durée de l’examen final est de trois heures. Le travail de session est séparé en deux parties (TS1 et TS2). 29-04-2013 Page 7 sur 9 Plan de cours IGL301 – Spécification et vérification des exigences Été 2013 Durant les évaluations en classe (tests et examens) aucune documentation n’est permise et l’usage d’appareils informatiques, électroniques ou de communication (ordinateur, calculatrice, téléphone, etc.) est interdit. Tableau 1 – Sommaire des évaluations Évaluation Examen final Mini tests (6) Travail de session en deux parties (TS1 et TS2) Notes de lecture et compte rendu (5) Total Valeur 40 % 30 % 20 % 10 % 100% Commentaire Individuel Individuel En équipe Individuel La valeur totale des tests est répartie équitablement sur chacun des tests. Chaque test vaut donc cinq pourcents de la note finale. Il en est de même pour les notes de lecture et comptes-rendus d’activité. À moins d’une justification valable, tout travail qui n’est pas remis au moment prescrit par l'échéancier se verra sanctionné par la note de 0. Une note inférieure à 10 % à l’examen final entrainera automatiquement un échec au cours, quelque soit la moyenne cumulative. De même, une absence non justifiée à un mini test entraine automatiquement un 0 à celui-ci. Si une absence est prévue à un mini test, veuillez en avertir l’enseignant au plus tôt pour voir les alternatives possibles. L'évaluation est faite en tenant compte de la clarté des documents. Conformément aux articles 36, 37 et 38 du règlement facultaire d’évaluation des apprentissages2, l’enseignant peut retourner à l’étudiante ou à l’étudiant tout travail non conforme aux exigences quant à la qualité de la langue et aux normes de présentation. En cas de circonstances extraordinaires au-delà du contrôle de l’Université de Sherbrooke et sur décision de celle-ci, l’évaluation des apprentissages de cette activité est sujette à changement. 4.3 Dispositions relatives au plagiat Dispositions générales Toute situation de plagiat sera traitée en conformité, entre autres, avec l’article 8.1.2 du Règlement des études3 de l’Université de Sherbrooke. Dispositions particulières Un document dont le texte et la structure se rapportent à des textes intégraux tirés d’un livre, d’une publication scientifique ou même d’un site Internet, doit être référencé adéquatement. Lors de la correction de tout travail individuel ou de groupe, une attention spéciale sera portée au plagiat, défini dans le Règlement des études comme « le fait, dans une activité pédagogique évaluée, de faire passer indûment pour siens des passages ou des idées tirés de l’œuvre d’autrui ». Le cas échéant, le plagiat est un délit qui contrevient à l’article 8.1.2 du Règlement des études : « tout acte ou manœuvre visant à tromper quant au rendement scolaire ou quant à la réussite d’une exigence relative à une activité pédagogique ». À titre de sanction disciplinaire, les mesures suivantes peuvent être imposées : a) l’obligation de reprendre un travail, un examen ou une activité pédagogique et b) l’attribution de la note E ou de la note 0 pour un travail, un examen ou une activité évaluée. Tout travail suspecté de plagiat sera référé au Secrétaire de la Faculté des sciences. 2 http://www.usherbrooke.ca/accueil/documents/politiques/pol 2500-008/pol evaluation/sciences.html 3 http://www.usherbrooke.ca/programmes/etude 29-04-2013 Page 8 sur 9 Plan de cours 4.4 IGL301 – Spécification et vérification des exigences Été 2013 Calendrier approximatif du cours contenu indicatif No date 1 2013-04-30 cours 0 2 2013-05-03 cours 1 3 2013-05-07 cours 2 4 2013-05-10 cours 3 5 2013-05-14 atelier 1, 2, 4, 7 6 2013-05-17 atelier 1, 2, 4, 7 7 2013-05-21 cours 4, 7 8 2013-05-24 cours 4, 7 9 2013-05-28 cours 5 note de lecture 2, mini test 3 10 2013-05-31 étude de cas 5 énoncé de TS 11 2013-06-04 cours 5 note de lecture 3, mini test 4 12 2013-06-07 étude de cas 5 13 2013-06-11 cours 6 14 2013-06-14 étude de cas 6 du 15 au 22 juin activité semaine d’examen pas de cours 15 2013-06-25 pas de cours 16 2013-06-28 pas de cours 17 2013-07-02 cours 5-6 18 2013-07-05 étude de cas 5-6 19 2013-07-09 cours 5-6 20 2013-07-12 étude de cas 5-6 21 2013-07-16 cours 5-6 22 2013-07-19 étude de cas 5-6 23 2013-07-23 cours 5-6 24 2013-07-26 étude de cas 5-6 25 2013-07-30 pas de cours 26 2013-08-02 pas de cours note de lecture 1, mini test 1 compte-rendu, mini test 2 1ère remise de TS1, mini test 5 retour sur TS1 transmis note de lecture 4, remise finale de TS1 mini test 6, 1ère remise de TS2 retour sur TS2 transmis remise finale de TS2 du 6 au 16 août Examen final La Faculté des sciences détermine l’horaire de l’examen final. 29-04-2013 évaluation Page 9 sur 9 L’intégrité intellectuelle passe, notamment, par la reconnaissance des sources utilisées. À l’Université de Sherbrooke, on y veille! Extrait du Règlement des études 8.1.2 Relativement aux activités pédagogiques L'expression délit désigne d'abord tout acte ou toute manœuvre visant à tromper quant au rendement scolaire ou quant à la réussite d'une exigence relative à une activité pédagogique. Sans restreindre la portée générale de ce qui précède, est considéré comme un délit : a) la substitution de personnes ou l’usurpation d’identité lors d'une activité évaluée ou obligatoire; b) le plagiat, soit le fait, dans une activité évaluée, de faire passer indûment pour siens des passages ou des idées tirés de l'œuvre d'autrui; c) l'obtention par vol ou par toute autre manœuvre frauduleuse de document ou de matériel, la possession ou l'utilisation de tout matériel non autorisé avant ou pendant un examen ou un travail faisant l'objet d'une évaluation; d) le fait de fournir ou d'obtenir toute aide non autorisée, qu'elle soit collective ou individuelle, pour un examen ou un travail faisant l'objet d'une évaluation; e) le fait de soumettre, sans autorisation préalable, une même production comme travail à une deuxième activité pédagogique; f) la falsification d'un document aux fins d'obtenir une évaluation supérieure dans une activité ou pour l'admission à un programme. Par plagiat, on entend notamment : Copier intégralement une phrase ou un passage d’un livre, d’un article de journal ou de revue, d’une page Web ou de tout autre document en omettant d’en mentionner la source ou de le mettre entre guillemets Reproduire des présentations, des dessins, des photographies, des graphiques, des données… sans en préciser la provenance et, dans certains cas, sans en avoir obtenu la permission de reproduire Utiliser, en tout ou en partie, du matériel sonore, graphique ou visuel, des pages Internet, du code de programme informatique ou des éléments de logiciel, des données ou résultats d’expérimentation ou toute autre information en provenance d’autrui en le faisant passer pour sien ou sans en citer les sources Résumer ou paraphraser l’idée d’un auteur sans en indiquer la source Traduire en partie ou en totalité un texte en omettant d’en mentionner la source ou de le mettre entre guillemets Utiliser le travail d’un autre et le présenter comme sien (et ce, même si cette personne a donné son accord) Acheter un travail sur le Web ou ailleurs et le faire passer pour sien Utiliser sans autorisation le même travail pour deux activités différentes (autoplagiat) Autrement dit : mentionnez vos sources. Document informatif V.2 (juin 2012) Groupe de travail anti-plagiat