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