tmpa-2015: software engineering education: the messir approach

TMPA-2015-Keynote - Part:

1 / 157

Prove it !This is not anAntonov !

Nicolas Guelfi- Wednesday 11th November, 2015 (23:06) - University of Luxembourg, LU


2 / 157

My Name isGuelfi !Nicolas Guelfi

Software Engineering Education

TheMessirApproach

TMPA-2015(Invited Talk)



Presentation Parts

3 / 157

1: Warning ! (slide 4)2: Software Engineering Education (slide 10)3: An Experimental Remedy (slide 52)4: Illustration: The iCrashMessep Variant (slide 64)5: Conclusion (slide 139)


TMPA-2015-Keynote - Part: Warning !

Part I

Warning !

4 / 157Nicolas Guelfi- Wednesday 11th November, 2015 (23:06) - University of Luxembourg, LU


5 / 157

!! Warning !! on the Presentations Content

I Pragmatism & Objectivism

Useful, scalable but not universal Rigorous but mostly empirical Shared by some but not all

I Based on Experience . . . including: 25 years in education and knowledge

transfer (bachelor, master, doctorate,post-doctorate)

8 years as Software Engineering expertat Court of Justice for conformancequestions

400 trainees in the SE industrymanaged at bachelor and master levels



5 / 157




I Based on Experience . . . including: 25 years in theoretical and applied

research IEE

Efficient Verification of OccupantsClassification System



5 / 157





research Dassault Aviation - (Rafale)

Fault Tolerant Embedded System forOutside Temperature Monitoring



5 / 157





research Theoretical Computer Science

Algebraic theories applied to themathematical modeling of concurrentprocesses with advanced data structures



5 / 157





research Software Engineering & Dependable

SystemsEuropean & National Research Projects,Excellence networksSERENE(http://www.ercim.eu/activity/workgroup)


TMPA-2015-Keynote - Part: Software Engineering Education

Part II

Software Engineering Education


TMPA-2015-Keynote - Part: Software Engineering EducationIntroductory Quotes

7 / 157

Software Engineering Definition

I The application of a systematic, disciplined,quantifiable approach to the development,operation, and maintenance of software.(IEEE in [IEEE(1990)])



8 / 157

Software Engineering Definition

I Software engineering is the part of computerscience which is too difficult for the computerscientist.(Friedrich Bauer [Bauer(1971), 71])



9 / 157

Software Engineering EducationI Today, the majority of Engineers understand very little of the science of programming. On

the other side, the scientists who study programming understand very little about what itmeans to be an Engineer . . . the two fields have much to learn from each other and that themarriage of software and Engineering should be consummated.(David Lorge Parnas in [Parnas(1997)])

Prove it !This is not anAntonov !



10 / 157

Software Engineering EducationI Is it possible to have software engineers in the numbers in

which we need them, without formal software engineeringeducation ?(A.J. Perlis in [Naur and Randell(1969), 68])


TMPA-2015-Keynote - Part: Software Engineering EducationDo We Need SE Education ?

11 / 157

Do We (Really) NeedSoftware Engineering

Education ?



12 / 157

Computing Jobs: Proportions and Distributions ?(Science, Technology, Engineering and Mathematics)

(Science, Technology, Engineering and Mathematics)



13 / 157

Computing Jobs in 2022: Offers vs Grads ?


TMPA-2015-Keynote - Part: Software Engineering EducationWhat About SE in Industry ?

14 / 157

What aboutSE in Industry ?

(conjectures only !!)



15 / 157

I Capability Maturity Model

CMM [Paulk(1993)] and CMMI-DEV [SEI(2010)]

can be used as an observation tool

provides a subjective and relative evaluation of theSoftware Engineering practice in industry.



16 / 157

CCMI-DEV - Capability Maturity Model Integration forDevelopmentState of practice in industry [Bollinger and McGowan(2009)]

I Level 1 - InitialI Level 2 - RepeatableI Level 3 - DefinedI Level 4 - ManagedI Level 5 - Optimizing

0 10 20 30 40 50 60 70 80 90 100

Level 1Level 2Level 3Level 4Level 5

51.224.8

17.45.4

1.2

Percentage (%)



17 / 157

Agile Software Development - [Beck and al.(2001)]

I Represents a Software Engineering success storyfor the mass realistic w.r.t. SE maturity (theories, methods and tools) realistic w.r.t. ICT projects budgets

I Mainly focused on project management anddevelopment life cycle iterative and incremental design and development

I Promotes directly some SE areas1. Software Construction2. Software Testing3. Software Engineering Management4. Software Engineering Process5. Software Quality6. Software Engineering Professional Practice



18 / 157

Agile in Industry - [Stavru(2014)]

[Rodrguez and al.(2012)][VersionOne(2012)]

0 20 40 60 80 100

VersionOne

Rodriguez and al.

20

44.8

80

55.2

Rate of Agile inMethod Prone Projects (%)

No AgileAgile



19 / 157

Agile Methodologies Used - [VersionOne(2015)]

0 20 40 60 80 100

ScrumScrum & XP hybrid

Custom HybridScrumban

KanbanIterative Dev.

Agile ModelingFeature Driven Dev.

AgileUPXP

56108664

110.50.5

Percentage (%)



20 / 157

Agile Project Management Tools Used[VersionOne(2015)]



21 / 157

Model Driven Engineering Practice in industry[Hutchinson et al.(2011)Hutchinson, Whittle, Rouncefield, and Kristoffersen]

I 250 questionnaire answers from MDE practitioners

I 22 in-depth interviews of MDE professionals from 17different companies

I on-site observational studies with companiespracticing MDE



0 10 20 30 40 50 60 70 80 90 100

make use of UMLuse a DSL of their own designuse a DSL provided by a tool

use BPMNuse SysML and MATLAB/Simulink

8540

2525

10

Percentage (%)

22 / 157




23 / 157


0 20 40 60 80 100

Class DiagramActivity Diagram

Use Case DiagramSequence Diagram

State Machine DiagramDSL Diagram

Component DiagramFlow Diagram

Entity Relationship DiagramDeployment Diagram

Object DiagramComposite Structure Diagram

8756

3833

2388

53322

Percentage (%)

I 35 diagram types citedI inclusion min threshold of 2I diagrams below the threshold:

Abstract Syntax Graphs, ArrowDiagrams, UsiXML Stylistics andICONIX Robustness Diagrams,. . .



0 20 40 60 80 100

Use of models for team communication

Use of models for understanding a problem at an abstract level

Code generation

Use of models to capture and document designs

Use of model-to-model transformations

Use of domain-specific languages (DSLs)

Model simulation - Executable models

Use of models in testing

Percentage (%)

Productivity ImpactMaintainability Impact

24 / 157



TMPA-2015-Keynote - Part: Software Engineering EducationStatus of SE Education ?

25 / 157

What is the status ofSoftware Engineering

Education ?


TMPA-2015-Keynote - Part: Software Engineering EducationStatus of SE Education ?

26 / 157

Software Engineering Education Main Dates

1968 NATO conference [Naur and Randell(1969)]1976 Workshop on Software Engineering Education1978 Subcommittee on Model Curricula in SE (SMCSE)1989 SEI Graduate Curriculum report1990 N. Guelfi first SE lecture , !1993 IEEE CS/ACM Joint Steering Committee1998 SE Coordinating Committee (SWECC)1999 SE Code of Ethics & Professional Practice2004 SE2004 Undergraduate Curriculum Report2005 SWEBOK Certified [ISO/IEC(2005)]2009 Graduate Software Engineering 2009 (GSwE2009 published)2013 CS2013 Undergraduate Curriculum - submitted [Sahami and Roach(2014)]2014 SE2014 Undergraduate Curriculum - submitted [ACM/IEEE(2015)]2014 SWEBOK submitted for recognition [ISO/IEC(2014)]


TMPA-2015-Keynote - Part: Software Engineering EducationSE Body of Knowledge ?

27 / 157

What is theSoftware EngineeringBody of Knowledge ?



28 / 157

I SWEBOK IEEE/ISO Standard[ISO/IEC(2005)],[ISO/IEC(2014)]

I SE knowledge decomposed in: 15 Knowledge Areas 99 Topics 394 Sub-topics



29 / 157

Number Knowledge Area Names1 Software Requirements2 Software Design3 Software Construction4 Software Testing5 Software Maintenance6 Software Configuration Management7 Software Engineering Management8 Software Engineering Process9 Software Engineering Models and Methods10 Software Quality11 Software Engineering Professional Practice12 Software Engineering Economics13 Computing Foundations14 Mathematical Foundations15 Engineering Foundations

Figure: SWEBOK Knowledge Areas



30 / 157

Number Topic Names1 Modeling2 Types of Models3 Analysis of Models4 Software Engineering Methods

Figure: SWEBOK topics for (9) SoftwareEngineering Models and Methods

Number SubTopic Names1 Modeling Principles2 Properties and Expression of Models3 Syntax, Semantics, and Pragmatics4 Preconditions, Postconditions, and Invariants

Figure: SWEBOK topics for (9.1) Modeling

Number SubTopic Names1 Heuristic Methods2 Formal Methods3 Prototyping Methods4 Agile Methods

Figure: SWEBOK topics for (9.4) SoftwareEngineering Methods


TMPA-2015-Keynote - Part: Software Engineering EducationSWEBOK Coverage ?

31 / 157

What is the SWEBOKIntentional CoverageNG

Over the World ?



32 / 157

Group Countries According to:

I Culture

I Economy

I Location



33 / 157

MessirEducation Regions

10 Regions - 48 Institutions

N Region Name Qty1 North America 72 Western Europe 113 Japan 34 Oceania and South Africa 45 Eastern Europe 46 Latin America 37 North Africa and the Middle East 58 Main Africa 29 South and Southeast Asia 7

10 Centrally Planned Asia 2Figure: Messir Education Regions

I 3 samples Schangai Ranking - 48 ABET/SE - 27 Network - 14



34 / 157

International Standard Classificationof Education [UNE(2012)]

I Level 6: Bachelor 7: Master 8: Doctorate

I Category 4: Academic 5: Professional 6: Orientation unspecified

I SubCategory 5: First degree 6: Long first degree 7: Second or further degree

Exit

from

edu

catio

n sy

stem

/labo

ur m

arke

t ent

ry

Terti

ary

educ

atio

n

Pos

t-se

cond

ary

non-

terti

ary

educ

atio

nSe

cond

ary

educ

atio

nPr

imar

y ed

ucat

ion

Early

chi

ldho

od

educ

atio

n

Firs

t-tim

e sc

hool

ent

ry

01

02

1

2

3

4

8

667

766

767

5

666665

768

Figure: International Standard Classificationof Education Pathways DiagramNicolas Guelfi- Wednesday 11th November, 2015 (23:06) - University of Luxembourg, LU


35 / 157

Global CoverageNG ALL Institutions

Global:43,4%

KA Name Mean Min Max StdDev1 Software Requirements 64 33 80 212 Software Design 46 17 66 213 Software Construction 51 36 67 164 Software Testing 28 5 42 165 Software Maintenance 11 0 28 146 Software Configuration Management 6 0 17 87 Software Engineering Management 68 58 75 78 Software Engineering Process 35 33 40 39 Software Engineering Models and Methods 66 31 100 29

10 Software Quality 29 8 50 2011 Software Engineering Professional Practice 71 58 84 1312 Software Engineering Economics 24 8 60 2513 Computing Foundations 58 11 79 3214 Mathematical Foundations 56 19 75 2615 Engineering Foundations 38 18 65 20

Figure: Global KA Coverage (%)



36 / 157

Intentional CoverageNG by Institutions

Global:55%

Michigan State University - United States (US)Bachelor in Computer science

Number Knowledge Area Coverage (%)9 Software Engineering Models and Methods 10011 Software Engineering Professional Practice 7913 Computing Foundations 797 Software Engineering Management 711 Software Requirements 7014 Mathematical Foundations 693 Software Construction 6715 Engineering Foundations 6512 Software Engineering Economics 602 Software Design 544 Software Testing 4210 Software Quality 428 Software Engineering Process 335 Software Maintenance 06 Software Configuration Management 0

Figure: SWEBOK Coverage for Institution: 2 (55%)



37 / 157

Intentional CoverageNG by Institutions

Global:35%

Universit Libre de Bruxelles - Belgium (BE)Bachelor in Computer science

Number Knowledge Area Coverage (%)13 Computing Foundations 7714 Mathematical Foundations 637 Software Engineering Management 5811 Software Engineering Professional Practice 5810 Software Quality 5015 Engineering Foundations 413 Software Construction 361 Software Requirements 338 Software Engineering Process 339 Software Engineering Models and Methods 3112 Software Engineering Economics 212 Software Design 176 Software Configuration Management 64 Software Testing 55 Software Maintenance 0

Figure: SWEBOK Coverage for Institution: 5 (35%)


TMPA-2015-Keynote - Part: Software Engineering EducationLessons Learned ?

38 / 157

What are theLessons Learned ?



39 / 157

Software Engineering - Lessons Learned

1 Extremism Syndrome Professional Oriented Curriculums (largely) exclude

science and theory Academic Oriented Curriculums (largely) exclude

technology and industry

Prove it !

This is not anAntonov !


Prove it !



40 / 157


2 Shared 68 Crisis Syndrome

theories/methods/tools taught (mainly) inadequatew.r.t. industry needs

change rates too fast for SE education (& research) (very) poor availability/awareness/use of standards

in SE Education SWEBOK weakly covered GSwE2009/SE2014 weakly implemented

SE Education Maturity Level 1 - Initial Process is ad hoc, even chaotic Success depends on individual effort and heroics



41 / 157


Unfortunately, its just me.It is my passion.(Dr. Kristen Walcott-JusticeUniversity of Colorado)

3 Ugly Duckling Syndrome

SE is explicitly taught mostly:

as a block in Software Engineeringcourses and rarely in a full curriculum

by Software Engineering Heroes

by Nominated Volunteers



42 / 157


4 Ivory Towers City Syndrome

The majority of curriculums is made ofcourses which: are disciplinary (verticality) focused on teacher(s) expertise topics poorly consistent with each others (very) poorly cooperating

Cooperation with industry is (very) rare

Cooperation with SE tools industry is(very) poor



43 / 157


5 HyperTheoryTrophy Syndrome Most academic teachers have:

a scientific education oriented towards(fundamental) research

(very) poor industrial experience as engineer Hyper presence of theoretical computer

science and formal methods


Prove it !



44 / 157


6 Conservatism Syndrome courses contain old fashioned content even for

technology oriented courses



45 / 157


7 Forgotten Pragmatics Syndrome

SE Problems encountered by the industry

SE Problems addressed in education

SE Problems addressed in research



46 / 157


8 Infinity Fantasm Syndrom

Viewpoints on the costs of the solutions: Industry Education Research Customer


TMPA-2015-Keynote - Part: Software Engineering EducationSo What ?

47 / 157

So . . .What Can We Do ?


TMPA-2015-Keynote - Part: An Experimental Remedy

Part III

An Experimental Remedy


TMPA-2015-Keynote - Part: An Experimental RemedyProposal Main Idea ?

49 / 157

A Product Line of Software Engineering Project Courses



50 / 157

Messep learning toolSoftware Engineering Project Courses Product Line

I Variation points include: SWEBOK

Knowledge areas (KA) Topics (TP) Sub-topics (STP)

Application Domains ([Heiman(2010)]) Market (MK) Categories (CT) Sub-Categories (SCT)

Technologies

I not a one for all approach

I Flexibility: an as complete as consistent as wishedapproach for the targeted SE learning objectives



51 / 157

Messep : Domain ArtefactsI SE Project Course Definition

Commonalities none !

Variabilities process, schedule activities, workload evaluation

I SWEBOK Commonalities

Messir(KA1-REQ, KA4-TEST,. . . ) Excalibur (KA3.5-CONS.TOOLS)

Variabilities KA1-REQ topics & subtopics KA9-MOD potentially all KAs

I Application Domain Commonalities

Applications/Collaborative Applications/Team Collaborative Applications(iCrash Crisis Management Systems)

Variabilities none yet !

I Technologies Commonalities

Eclipse , Java , SQL , JavaFx ,. . .

Variabilities Eclipse plug-ins, Application Components HTML5, iOS, Android, . . .



52 / 157

Messep : Derivation ProcessesI Forward

Bind the variabilities Define Deltas

add/modify variation point, variant,constraint

Derive SE Project Variant SE Project Definition documents Realization artefacts (i.e. models, code, SE

tools,. . . )

I Back & Forth (if necessary)

Select a SE Project Variant from theProduct Line

Define Deltas (Optional) add/modify variation points, variants,

constraints

Derive Refined SE Project Variant(Optional) SE Project Definition documents Realization artefacts

(i.e. models, code, SE tools,. . . )


TMPA-2015-Keynote - Part: Illustration: The iCrashMessep Variant

Part IV

Illustration: TheiCrashMessep Variant


TMPA-2015-Keynote - Part: Illustration: The iCrashMessep VariantiCrash SEP Variant - Process

54 / 157

iCrash 4ME Variant - Process

I Back & Forth Select a SE Project Variant from the Product Line

iCrash v1.0 Define Deltas

add/modify variation points, variants, constraints

Derive Refined SE Project Variant SE Project Definition documents Realization artefacts (i.e. models, code, SE tools,. . . )


TMPA-2015-Keynote - Part: Illustration: The iCrashMessep VariantiCrash Variant Overview

55 / 157

Messep SE Project iCrash v1.0 CardFeatures

DetailsProject Name iCrash v 1.0ICSED Level BA 655 (Bachelor/Professional/First degree)Schedule 10 hours * 14 weeks * 2 periodsGroup Size 4 [2-4]Phases Per.1 [Pha.1/6w + Pha.2/8w]

Per.2 [Pha.1/8w + Pha.2/7w]Main SWEBOK KAs KA1/REQ + KA9/MOD + KA3/CONSMain Market Applications/Collaborative Applications/Team Collaborative ApplicationsMain Technologies

VirtualBox



56 / 157

iCrash v1.0 Domain Artefacts

Main Inputs Details

Requirements IMessir Standardized Requirements Artefacts Excalibur Requirements Specification Project Excalibur Requirements Documentation Project Excalibur Requirements Simulation Project

Construction I iCrash v1.0 Code Functionalities - Java GUI - JavaFx Data persistency - MySQL Distributed processing - Java RMI Versioning - SubVersioN



57 / 157

Effective CoverageNG by Variant

36%

Number Knowledge Area Coverage (%)1 Software Requirements 809 Software Engineering Models and Methods 757 Software Engineering Management 6711 Software Engineering Professional Practice 632 Software Design 463 Software Construction 398 Software Engineering Process 334 Software Testing 325 Software Maintenance 2814 Mathematical Foundations 1915 Engineering Foundations 1810 Software Quality 1713 Computing Foundations 1112 Software Engineering Economics 86 Software Configuration Management 0

Figure: SWEBOK Coverage iCrash v1.0 (36%)


TMPA-2015-Keynote - Part: Illustration: The iCrashMessep VariantiCrash SEP Commonalities - Requirement Analysis

58 / 157

What is theMessirInternal Standard ?



TheMessirRequirementsEngineering process (MevoP )is iterative and incremental.

59 / 157

Requirements Analyst

[Correct&Complete]

[Incorrect or Incomplete]

Use Cases

Concepts

Environment

Operations

Tests

IterationClosure

Figure: MessirMevoP DiagramNicolas Guelfi- Wednesday 11th November, 2015 (23:06) - University of Luxembourg, LU


60 / 157

Definition Specification Simulation

Use Case

Environment

Concept

Operation

TestFigure: MevoP Process - Model focus by Analysis Level



61 / 157

Categories ofMessirlanguages by Analysis levels.

Level msrd msr plDefinition +++ + -

Specification ++ +++ -Simulation + + +++

I Agile ( msrd)Messirdocumentation language template based natural language

I Rigorous ( msr)Messirspecification language structured object-oriented and constraint

oriented specification language

I Scientific ( pl)Messirsimulation language Prologmsr programming language



iCrash - Stakeholders

I The iCrash system is intended to support the ABC company for themanagement of crisis situations.

I the iCrash stakeholders are:1. Communication Company2. Humans3. Coordinators4. Administrator5. Creator6. Activator

62 / 157

iCrash v1.0 Stakeholders



iCrash - Use Case Model

63 / 157

iCrashUse Case Diagram View

Illustration




64 / 157

iCrashUse Case Specification

Illustration

1 use case system summary suDeployAndRun() {2 actor actAdministrator[primary,active]3 actor actMsrCreator[secondary,active]4 actor actCoordinator[secondary,active,multiple]5 actor actActivator[secondary,proactive]6 actor actComCompany[secondary,active]7

8 reuse oeCreateSystemAndEnvironment[1..1]9 reuse ugAdministrateTheSystem[1..*]10 reuse suGlobalCrisisHandling[1..*]11 reuse oeSetClock[1..*]12 reuse oeSollicitateCrisisHandling[0..*]13 reuse oeAlert[1..*]14

15 step a: actMsrCreator executesoeCreateSystemAndEnvironment

16 step b: actAdministrator executesugAdministrateTheSystem

17 step c: actComCompany executes oeAlert18 step d: actActivator executes oeSetClock19 step ^e: actActivator executes

oeSollicitateCrisisHandling20 step f: actCoordinator executes

suGlobalCrisisHandling21

22 ordering constraint23 "step (a) must be always the first step."24 ordering constraint25 "step (f) can be executed by different

actCoordinator actors."26 ordering constraint27 "if (e) then previously (d)."Nicolas Guelfi- Wednesday 11th November, 2015 (23:06) - University of Luxembourg, LU



65 / 157

iCrashUse Case Documentation

Illustration

2.3 Use Cases Model 17

2.3 Use Cases Model

This section contains the use cases elicited during the requirements elicitation phase. The use cases are textuallydescribed as suggested by the Messir method and inspired by the standard Cokburn template [?].

2.3.1 Use Cases

2.3.1.1 summary-suDeployAndRun

The goal is to install the iCrash system on its infrastructure and to exploit its capacities related to the secureadministration and efficient handling of car crash situations depending on alerts received.

Use-Case DescriptionName suDeployAndRunScope systemLevel summaryPrimary Actor1 actAdministrator[active]Secondary actor(s)1 actMsrCreator[active]2 actCoordinator[active, multiple]3 actActivator[proactive]4 actComCompany[active]Goal(s) descriptionThe goal is to install the iCrash system on its infrastructure and to exploit its capacities related to the secureadministration and efficient handling of car crash situations depending on alerts received.Reuse1 oeCreateSystemAndEnvironment2 ugAdministrateTheSystem [1..*]3 suGlobalCrisisHandling [1..*]4 oeSetClock [1..*]5 oeSollicitateCrisisHandling [*]6 oeAlert [1..*]Protocol condition(s)1 the iCrash system has never been deployed and usedPre-condition(s)1 noneMain post-condition(s)1 the iCrash system has been created and has handled the crisis situations for which it received alerts

through the communication company.Main Stepsa the actor actMsrCreator executes the oeCreateSystemAndEnvironment use caseb the actor actAdministrator executes the ugAdministrateTheSystem use casec the actor actComCompany executes the oeAlert use cased the actor actActivator executes the oeSetClock use casee the actor actActivator executes the oeSollicitateCrisisHandling use casef the actor actCoordinator executes the suGlobalCrisisHandling use caseSteps Ordering Constraints1 step (a) must be always the first step.2 step (f) can be executed by different actCoordinator actors.3 if (e) than previously (d).




66 / 157

iCrashUse Case Instance

Diagram ViewIllustration




68 / 157

1//----------------------------------------------------2 steve3 executed instanceof subfunction4 oeLogin("steve","pwdMessirExcalibur2017"){5 ieMessage('You are logged ! Welcome ...') returned to steve6 }7//----------------------------------------------------8 steve9 executed instanceof subfunction10 oeGetCrisisSet("pending"){11 ieSendACrisis("crisis with ID 1 details") returned to steve12 }13//----------------------------------------------------14 steve15 executed instanceof subfunction16 oeSetCrisisHandler("1"){17 ieSmsSend("+3524666445252","The handling of your alert by our services is in

progress !")18 returned to tango19 ieMessage("You are now considered as handling the crisis !")20 returned to steve21 }22//----------------------------------------------------



iCrash - Environment Model



iCrash - Environment Model

70 / 157

1 actor actCoordinator2 role rnactCoordinator3 cardinality [0..*]4 extends actAuthenticated{5

6 operation init():ptBoolean7

8 output interface outactCoordinator{9 operation oeInvalidateAlert(AdtAlertID:dtAlertID ):ptBoolean10 operation oeCloseCrisis(AdtCrisisID:dtCrisisID ):ptBoolean11 operation oeGetAlertsSet(AetAlertStatus:etAlertStatus ):ptBoolean12 operation oeGetCrisisSet(AetCrisisStatus:etCrisisStatus ):ptBoolean13 operation oeSetCrisisHandler(AdtCrisisID:dtCrisisID ):ptBoolean. . .1 input interface inactCoordinator{2 operation ieSendAnAlert(ActAlert:ctAlert ):ptBoolean3 operation ieSendACrisis(ActCrisis:ctCrisis ):ptBoolean4 }5 }



iCrash - Concept Model

71 / 157

Concept Model - ctAlert




72 / 157

Class types and associations




73 / 157

Primary Types/ Data Types




74 / 157

1 Concept Model {2

3 Primary Types{. . .1 class ctAlert role rnctAlert cardinality [0..*]{2 attribute id:dtAlertID3 attribute status: etAlertStatus4 attribute location:dtGPSLocation5 attribute instant:dtDateAndTime6 attribute comment:dtComment7

8 operation init( Aid:dtAlertID ,9 Astatus:etAlertStatus ,10 Alocation:dtGPSLocation ,11 Ainstant:dtDateAndTime ,12 Acomment:dtComment ):ptBoolean13 operation isSentToCoordinator(AactCoordinator:actCoordinator ):ptBoolean14

15 }



iCrash - Operation Model

MessirOperation Model

I The objective is to provide theproperties that "characterize" all valid"executions" for each system operation.

I Categories of semantic properties Pre-protocol Pre-functional Post-functional Post-Protocol

75 / 157

System

Environment

?

outputevent

inputevent

global_statei

Output event+Input event 1Input event 2.....

env@pre

system@pre

env@post

system@postglobal_statei+1




76 / 157

Operation Model atDefinition level (msrd file)

1@@Operation2icrash.environment.actAdministrator.outactAdministrator.oeAddCoordinator

1@description2"sent to add a new coordinator in the system's post state and environment

's post state."3

4//preProtocol descriptions5@preP6"the system is started"7@preP8"the actor logged previously and did not log out ! (i.e. the associated

ctAdministrator instance is considered logged)"9@endPreP10

11//preFunctional descriptions

1@postF2"the system's state has a new instance of ctCoordinator initialized with

the given values."3@postF4"the new actor instance and ctCoordinator instance are related."




77 / 157

Operation Model atSpecification level (mcl)

1operation: icrash.environment.actAdministrator.outactAdministrator.oeAddCoordinator(AdtCoordinatorID:dtCoordinatorID, AdtLogin:dtLogin,AdtPassword:dtPassword):ptBoolean

1postF:2 let TheSystem: ctState in3 self.rnActor.rnSystem = TheSystem4 self.rnActor.rnSystem = TheSystem5 and self.rnActor = TheActor6/* PostF01 */7 TheactCoordinator.init()8

9/* PostF02 */10 and ThectCoordinator.init(AdtCoordinatorID,AdtLogin,AdtPassword)11

12/* PostF03 */13 and [email protected] = ThectCoordinator14

15/* PostF04 */16 and [email protected] = TheactCoordinator17

18/* PostF05 */19 and TheActor.rnInterfaceIN^ieCoordinatorAdded()




78 / 157

Operation Model at Simulation level(Prologmsr code)

1msrop(outactAdministrator,2 oeAddCoordinator,3 [preProtocol,Self,4 AdtCoordinatorID,5 AdtLogin,6 AdtPassword7 ],8 []):-. . .1/* PostF03 */2 msrNav([TheactCoordinator],3 [msmAtPost,rnctCoordinator],4 [ThectCoordinator]),5/* PostF05 */6 msrNav([TheActor],7 [rnInterfaceIN,8 ieCoordinatorAdded,[]],9 [[ptBoolean,true]]),


TMPA-2015-Keynote - Part: Illustration: The iCrashMessep VariantiCrash - Test Model

MessirTest Model

I Defines test cases to:1. verify or validate the specification by inspection or

simulation2. verify or validate the delivered program

I A test case is a sequence of test steps Test message - system operation triggered Constraints - domain for the parameter values Oracle - defines acceptance conditions

79 / 157

System

Environment

?

outputevent

inputevent

global_statei

Output event+Input event 1Input event 2.....

env@pre

system@pre

env@post

system@postglobal_statei+1


TMPA-2015-Keynote - Part: Illustration: The iCrashMessep VariantiCrash - Test Model

80 / 157

1 test step ts12oeSetCrisisHandler order 12{2 variables{3 TheActor : actCoordinator4 AdtCrisisID : dtCrisisID5 }6 constraints{7 TheActor=TheSystem.rnactCoordinator8 ->select(a | a.rnctCoordinator.login.

value.eq('steve'))9 ->any2(true)10 AdtCrisisID.value= '1'11 }12 test message{13 out:TheActor sends to system

actCoordinator.outactCoordinator.oeSetCrisisHandler(AdtCrisisID)

14 }15 oracle{16 variables{17 AMessage:ptString

18 AdtPhoneNumber:dtPhoneNumber19 AdtSMS:dtSMS20 ActAlert:ctAlert21

22 TheComCompany: actComCompany23 TheCoordinator:actCoordinator24 }25 constraints{26 AMessage = 'You are now considered as

handling the crisis !'27 AdtSMS.value = 'The handling of your

alert by our services is in progress !'28 TheComCompany.inactComCompany.ieSmsSend

(AdtPhoneNumber,AdtSMS)29 TheCoordinator.inactCoordinator.

ieSendAnAlert(ActAlert)30 TheActor.inactAuthenticated.ieMessage(

AMessage)31 }


TMPA-2015-Keynote - Part: Illustration: The iCrashMessep VariantiCrash - Construction

81 / 157

What is the iCrash v1.0Implementation Artefact ?



82 / 157

iCrash .FX v1.0 Program - GUI

AdministratorCoordinators

Panel



83 / 157


AdministratorAuthentication

Panel



84 / 157


ComCompanyAlertPanel



85 / 157


CoordinatorAlertsPanel



86 / 157


CommunicationCompany

CrisisPanel



87 / 157


CoordinatorReportPanel



88 / 157


CoordinatorStatusPanel



89 / 157


CoordinatorAuthentication

Panel



90 / 157


ActivatorClockPanel



91 / 157

iCrash v1.0 Program - DB



92 / 157

iCrash v1.0 Program - DB


TMPA-2015-Keynote - Part: Illustration: The iCrashMessep VariantiCrash SEP Variant - Tools

93 / 157

What is theMessirSoftware Engineering Environment ?



94 / 157

Software Engineering Tools.

1 Requirements2 Design3 Construction4 Management5 Quality6 MaintenanceFigure: Tools Focus

I Type/Scope Tool: supports an individual Task

Unit belonging to the developmentlife cycle.

Workbench: combines in anintegrated way two or more tools tocover a sub-part of the software lifecycle.

Environment: combines tools andworkbenches in order to target themaximum coverage of the lifecycle.



Activities Tools/Technologies

RequirementsIExcalibur Eclipse SE

workbench

95 / 157

MessirSoftware engineering Environment




DesignI Eclipse UML Designer

96 / 157




Activities Tools/TechnologiesConstruction

I Functionalities - JavaI GUI - JavaFxI Data persistency - MySQLI Distributed processing -

Java RMI. . . Tomcat

97 / 157




Activities Tools/TechnologiesManagement

I Atlassian Confluence knowledge basecollaboration tool.

I SubVersioN versioning and revisioncontrol tool.

I Atlassian Bamboo andApache Maven continuous integrationserver for project builds.

mavenVirtualBox

98 / 157





QualityI Test based Verification &

ValidationMessir Excalibur

simulator SWTbot testing tool for

graphical user interface. JUnit unit testing framework EclEmma Java code coverage.

I Syntax validation tools

99 / 157




Activities Tools/TechnologiesMaintenance

I Atlassian JIRA issue tracking tool.I SubVersioN versioning and revision

control tool.I Atlassian Bamboo and

Apache Maven continuous integrationserver for project builds.

maven

100 / 157




101 / 157




102 / 157




103 / 157




104 / 157




105 / 157




106 / 157




107 / 157




108 / 157




109 / 157

iCrash v1.0 Requirements Documentation

iCrash :A Crisis Management Case StudyMessirAnalysis Document

- v 1.4 -(Report type: Simulation)

Laboratory for Advanced Software SystemsUniversity of Luxembourg

Thursday 5th November, 2015 - 08:12



110 / 157




111 / 157



TMPA-2015-Keynote - Part: Illustration: The iCrashMessep VariantiCrash SEP Variant - iCrash v1.ME

112 / 157

How to define my ownProject Variant ?



113 / 157

Messep - Variant Derivation Process1 Define Deltas for iCrash 4ME

Remove Unwanted features Requirements simulation level (Prolog)

Add new features Activity/Requirements

(a) Define an access rights policy depending on coordinators domain of expertise.(b) Update adequately the requirements artefacts (specification and report)

Activity/Construction(a) Update the iCrash v1.0 system to include your access rights policy

Modify selected features Project schedule . . .



114 / 157

Messep - Variant Derivation Process2 Define Deltas for iCrash v1. TCS



(a) Use Algebraic Petri Nets to model theiCrash system

(b) Verify using model checking with the AlPiNA[a]tools if an alert can stay unhandled infinitely




114 / 157

Messep - Variant Derivation Process

sendcrisis

[$cd]

Recording Crisis Data

[]

[system($cd)]

System

sendcrisisforvalidation

[system(getcrisistype($vcs), true)]

assigncrisisisvalidcrisis($sy=true)&

invalidsobs($sob, getcrisistype($sy)=true)

[$sy]

[assigncrisis($sob,$sy)]

Superobserver Ready

[$sob]

ExecutingCrisis[$sy]

sendreportblkrep($ec=true)

[$ec]

[]ExecutedCrisisReport

[rp($ec)]

[sobs(YK,Fire)sobs(NG,Blockage)]

[][system(getcrisistype($sy), false)]

ValdidatingCrisis

validatecrisis

[$vcs]

[Fire, Fire, Blockage,Blockage]3 Define Deltas for iCrash v1. TCS





Modify selected features Project schedule . . . [a] [Hostettler et al.(2011)Hostettler, Marechal, Linard, Risoldi, and Buchs]

[b] [Buchs and Guelfi(1991)][c] [Buchs and Guelfi(2000)]



114 / 157

Messep - Variant Derivation Process

sendcrisis

[$cd]

Recording Crisis Data

[]

[system($cd)]

System

sendcrisisforvalidation

[system(getcrisistype($vcs), true)]

assigncrisisisvalidcrisis($sy=true)&

invalidsobs($sob, getcrisistype($sy)=true)

[$sy]

[assigncrisis($sob,$sy)]

Superobserver Ready

[$sob]

ExecutingCrisis[$sy]

sendreportblkrep($ec=true)

[$ec]

[]ExecutedCrisisReport

[rp($ec)]

[sobs(YK,Fire)sobs(NG,Blockage)]

[][system(getcrisistype($sy), false)]

ValdidatingCrisis

validatecrisis

[$vcs]

[Fire, Fire, Blockage,Blockage]4 Define Deltas for iCrash v1. TCS





Modify selected features Project schedule . . . [a] [Hostettler et al.(2011)Hostettler, Marechal, Linard, Risoldi, and Buchs]

[b] [Buchs and Guelfi(1991)][c] [Buchs and Guelfi(2000)]



115 / 157

Messep - Variant Derivation Process1 Define Deltas for iCrash Eiffel [Meyer(2009)]

Remove Unwanted features iCrash Java Implementation

Add new features Activity/Construction

(a) Write an Eiffel implementation thatconforms to the iCrash program.

Activity/Code Generation(b) Use the Xtend and Xtext MDE tools togenerate Eiffel implementation fromMessir specification



TMPA-2015-Keynote - Part: Illustration: The iCrashMessep VariantMessepWhat do I concretely get ?

116 / 157

What do IConcretely Get ?



Actor DeliverablesInstructor

I Main Work Products Project Course Syllabus (source,pdf) Project Course Evaluation forms (source, pdf,

xls)I Main Benefits

Efficiency - rapid engineering of SE projectcourse

Quality - reuse of quality components Maintenability - standardized, generic,

modular & tool supported Stability in time in front of changing

instructors Flexibility - SE Coverage adapted to degree

or course objectives

117 / 157

Main Concrete UsableMessep Deliverables



Actor Deliverables

StudentsI Main Work Products

Specialized Project Definition Reusable projects inputs (documentation,

models, source, executables, . . . ) Software Engineering Environment

I Main Benefits Learnability - teaching material Accessibility - tools Maturity - soundness of reused components Adequacy - work vs resource Motivation - more results / more experience

/ less failures / less deadlocks

118 / 157

Main Concrete UsableMessep Deliverables


TMPA-2015-Keynote - Part: Illustration: The iCrashMessep VariantMessep Flexibility

119 / 157

Messep Usage & Flexibility

I Bachelor Level

UML modeling with class diagrams, use case diagrams andsequence diagrams

Requirements engineering with use cases

Practical development projects of with Java , JavaFx , MySQL .

Introduction to software engineering concepts

Introduction to development methods concepts

Introduction to product quality

Verification and Validation

. . .Nicolas Guelfi- Wednesday 11th November, 2015 (23:06) - University of Luxembourg, LU


120 / 157


I Master Level

Advanced Requirements Engineering

Model Driven Engineering

Domain Specific Languages: concepts and tools

Software Engineering Environments: use and development

Formal Methods

Operational and Axiomatic Semantics

Testing and Model checking

Constraint logic programming

. . .Nicolas Guelfi- Wednesday 11th November, 2015 (23:06) - University of Luxembourg, LU


121 / 157


I Doctorate Level

Theories, Methods and tools in the software engineering domain

Domain Specific Languages

Model Driven Engineering

Specification based testing

Dependability requirements

Simulation and verification of modeling languages

. . .


TMPA-2015-Keynote - Part: Conclusion

Part V

Conclusion


TMPA-2015-Keynote - Part: ConclusionMessirWho ?

123 / 157

I There is a (HUGE) need to improve SE Education !

IMessep SE Project Courses Product Line Allows for Rapid SE Course Definition & Evolution

Reconciliates Science & Engineering

Ensure Quality by Reuse

Eases Educators Collaboration

Improves SWEBOK Coverage



124 / 157

Messir& Excalibur ProducersIUniversity of Luxembourg

Nicolas Guelfi

Alfredo Capozucca

Benoit Ries



125 / 157

MessirProspective NetworkCat. Reg. RC CC Institution Contact(s)edu 01 NA CA McGill University Joerg Kienzleedu 01 NA US Carnegie Mellon University - Silicon Valley Ccile Praireedu 01 NA US Michigan State University Betty Chengedu 01 NA US University of Southern California George Edwards

Nenad Medvidovicedu 02 WE CH University of Geneva Didier Buchsedu 02 WE DE University of Hamburg Daniel Moldtedu 02 WE IT University of Turin Susanna Donatelliedu 02 WE IT University of Milan Lucia Pomelloedu 02 WE LU University of Luxembourg Nicolas Guelfiedu 02 WE UK University of Newcastle Maciej Koutnyedu 05 EE RU Saint Petersburg State Technical University Vladimir Itsykson

Evgeny Pyshkinind 02 WE LU iTrust Consulting Carlo Harpes

Figure: Messir Prospective Network



126 / 157

Know aSoftware Engineering

Hero ?



126 / 157

Being him . . .



126 / 157

Or him . . .



126 / 157

Know a Victim ?



126 / 157

Tell himto join ourdaily scrum !



127 / 157

Contact us !

[email protected]


TMPA-2015-Keynote - Part: ConclusionDiscussion

Questions, Ideas, Remarks



References[UNE(2012)] International Standard Classification of Education (ISCED) 2011.

UNESCO Institute for Statistics, 2012.doi: 10.15220/978-92-9189-123-8-en.URL http://dx.doi.org/10.15220/978-92-9189-123-8-en.

[ACM/IEEE(2015)] ACM/IEEE.Software engineering 2014 - curriculum guidelines for undergraduate degree programs in software engineering.2015.URL https://www.acm.org/education/SE2014-20150223_draft.pdf,https://www.acm.org/education/curricula-recommendations.

[Anderson et al.(2001)Anderson, Krathwohl, and Bloom] Lorin W Anderson, David R Krathwohl, and Benjamin Samuel Bloom.A taxonomy for learning, teaching, and assessing: A revision of Blooms taxonomy of educational objectives.Allyn & Bacon, 2001.

[Bauer(1971)] Friedrich L. Bauer.Software engineering.In 1. Foundations and systems., International Federation for Information Processing: IFIP congress series, pages 530538, August 1971.

[Beck and al.(2001)] Kent Beck and al.The agile manifesto, 2001.

[Bloom and Krathwohl(1956)] Benjamin Samuel Bloom and David R Krathwohl.Taxonomy of educational objectives: The classification of educational goals. handbook i: Cognitive domain.1956.

[Bollinger and McGowan(2009)] Terry Bollinger and Clement McGowan.A critical look at software capability evaluations: An update.Software, IEEE, 26(5):8083, 2009.


http://dx.doi.org/10.15220/978-92-9189-123-8-enhttps://www.acm.org/education/SE2014-20150223_draft.pdf, https://www.acm.org/education/curricula-recommendationshttps://www.acm.org/education/SE2014-20150223_draft.pdf, https://www.acm.org/education/curricula-recommendations


Title[Buchs and Guelfi(1991)] Didier Buchs and Nicolas Guelfi.

Co-opn: A concurrent object oriented petri net approach. in application and theory of petri nets.In 12th International Conference, Gjern, Denmark, pages 432454, 1991.

[Buchs and Guelfi(2000)] Didier Buchs and Nicolas Guelfi.A formal specification framework for object-oriented distributed systems.Software Engineering, IEEE Transactions on, 26(7):635652, 2000.

[Heer(2012)] Rex Heer.A model of learning objectivesbased on a taxonomy for learning, teaching, and assessing: a revision of blooms taxonomy of educationalobjectives.Center for Excellence in Learning and Teaching, Iowa State University. http://www. celt. iastate. edu/teaching/RevisedBlooms1. html, 2012.

[Heiman(2010)] R Heiman.Idcs software taxonomy 2010.International Data Corporation, Framingham, 2010.

[Hostettler et al.(2011)Hostettler, Marechal, Linard, Risoldi, and Buchs] Steve Hostettler, Alexis Marechal, Alban Linard, Matteo Risoldi, and DidierBuchs.High-level petri net model checking with alpina.Fundamenta Informaticae, 113(3-4):229264, August 2011.ISSN 0169-2968.

[Hutchinson et al.(2011)Hutchinson, Whittle, Rouncefield, and Kristoffersen] John Hutchinson, Jon Whittle, Mark Rouncefield, and SteinarKristoffersen.Empirical assessment of mde in industry.In Proceedings of the 33rd International Conference on Software Engineering, pages 471480. ACM, 2011.



Title

[IEEE(1990)] IEEE.Ieee standard glossary of software engineering terminology.Technical report, 1990.URL http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=159342.

[ISO/IEC(2005)] ISO/IEC.Software Engineering Guide to the Software Engineering Body of Knowledge (SWEBOK).International Organization for Standardization, 2005.ISO-IEC TR 19759-2005.

[ISO/IEC(2014)] ISO/IEC.Software Engineering Guide to the Software Engineering Body of Knowledge (SWEBOK).International Organization for Standardization, 2014.ISO-IEC TR 19759-2014.

[Meyer(2009)] Bertrand Meyer.Touch of Class: Learning to Program Well with Objects and Contracts.Springer Publishing Company, Incorporated, 1 edition, 2009.ISBN 3540921443, 9783540921448.

[Naur and Randell(1969)] P. Naur and B. Randell.Software engineering report of a conference sponsored by the nato science committee garmisch germany 7th-11th october 1968.1969.URL http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF.


http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=159342http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF


Title[Parnas(1997)] David Lorge Parnas.

Software engineering: An unconsummated marriage (extended abstract).In Mehdi Jazayeri and Helmut Schauer, editors, Software Engineering - ESEC/FSE 97, 6th European Software Engineering Conference Held Jointlywith the 5th ACM SIGSOFT Symposium on Foundations of Software Engineering, Zurich, Switzerland, September 22-25, 1997, Proceedings, volume 1301of Lecture Notes in Computer Science, pages 13. Springer, 1997.ISBN 3-540-63531-9.doi: 10.1145/267895.267897.URL http://doi.acm.org/10.1145/267895.267897.

[Paulk(1993)] Mark Paulk.Capability maturity model for software.Wiley Online Library, 1993.

[Rodrguez and al.(2012)] Pilar Rodrguez and al.Survey on agile and lean usage in finnish software industry.In Proceedings of the ACM-IEEE international symposium on Empirical software engineering and measurement, pages 139148. ACM, 2012.

[Sahami and Roach(2014)] Mehran Sahami and Steve Roach.Computer science curricula 2013 released.Commun. ACM, 57(6):55, June 2014.ISSN 0001-0782.doi: 10.1145/2610445.URL http://doi.acm.org.proxy.bnl.lu/10.1145/2610445.

[SEI(2010)] CMMI Product SEI.Cmmi for development (cmmi-dev).Technical report, CMU/SEI-2010-TR-033, Software Engineering Institute, Carnegie Mellon University, 2010.


http://doi.acm.org/10.1145/267895.267897http://doi.acm.org.proxy.bnl.lu/10.1145/2610445


Title

[Stavru(2014)] Stavros Stavru.A critical examination of recent industrial surveys on agile method usage.Journal of Systems and Software, 94:8797, 2014.

[VersionOne(2012)] Inc VersionOne.6th annual state of agile survey.Technical report, 2012.

[VersionOne(2015)] Inc VersionOne.9th annual state of agile survey.Technical report, 2015.


TMPA-2015-Keynote - Part: Conclusion

Glossary

engineering the practical application of scientific ideas and principles.. 13science a systematically organized body of knowledge on any subject.. 13


TMPA-2015-Keynote - Part: ConclusionAppendix

135 / 157

Effective CoverageNG by Variant

36%

Number Knowledge Area Coverage (%)1 Software Requirements 809 Software Engineering Models and Methods 757 Software Engineering Management 6711 Software Engineering Professional Practice 632 Software Design 463 Software Construction 398 Software Engineering Process 334 Software Testing 325 Software Maintenance 2814 Mathematical Foundations 1915 Engineering Foundations 1810 Software Quality 1713 Computing Foundations 1112 Software Engineering Economics 86 Software Configuration Management 0

Figure: SWEBOK Coverage iCrash v1.0 (36%)



136 / 157

I Problem: How to determine more precisely theSWEBOK topic cognitive acquisition provided by alecture ?

I Solution:1. associate a Focus Level (1,2 or 3) representing the

importance of the subject w.r.t. to the lectures mainconcern.

2. associate a Bloom Cognitive Level (1 to 6): representingthe output cognitive level supposed to be reached aftersuccessful completion of the lecture([Bloom and Krathwohl(1956)]).

3. compute an weighted average using quantified BloomCognitive Level and focus level



137 / 157

Bloom Education Levels[Bloom and Krathwohl(1956)],

[Anderson et al.(2001)Anderson, Krathwohl, and Bloom],

(3D model from [Heer(2012)])

Figure: Bloom 2001 Pyramid Model



1 Remembering2 Understanding3 Applying4 Analyzing5 Evaluating6 Creating

Figure: Bloom 2001 Levels

138 / 157

Bloom 2001 Education Levels[Anderson et al.(2001)Anderson, Krathwohl, and Bloom]



Focus LevelsBloom Levels 1 2 3

Creating 6 80 90 100Evaluating 5 60 70 80Analyzing 4 50 55 60Applying 3 35 40 45Understanding 2 20 25 30Remembering 1 5 10 15

Table: Acquisition Levels Scale (%)by Cognitive and Focus levels

139 / 157

MessirSWEBOK Acquisition Scale



1 Remembering1 Retrieving, recognizing, and recalling

relevant knowledge from long-term memory.2 Understanding

1 Constructing meaning from oral, written,and graphic messages through interpreting,exemplifying, classifying, summarizing,inferring, comparing, and explaining.

3 Applying1 Carrying out or using a procedure through

executing, or implementing.

Figure: Bloom 2001 Levels 1,2,3

4 Analyzing1 Breaking material into constituent parts,

determining how the parts relate to oneanother and to an overall structure orpurpose through differentiating, organizing,and attributing.

5 Evaluating1 Making judgments based on criteria and

standards through checking and critiquing.6 Creating

1 Putting elements together to form a coherentor functional whole; reorganizing elementsinto a new pattern or structure throughgenerating, planning, or producing.

Figure: Bloom 2001 Levels 4,5,6

140 / 157

Bloom Education Levels[Anderson et al.(2001)Anderson, Krathwohl, and Bloom]



141 / 157

Agile Techniques Used - [VersionOne(2015)]

0 20 40 60 80 100

Daily StandupPrioritized backlogs

Short IterationsIteration Planning

RetrospectivesRelease Planning

Unit TestingTeam-based estimation

TaskboardIteration reviews

807979

7169

6565

565353

Percentage (%)0 20 40 60 80 100

Dedicated Product OwnerSingle integrated team

Coding StandardsOpen Work area

RefactoringTest-driven development

KanbanStory Mapping

Collective Code OwnershipAutomated Acceptance Testing

Continuous DeploymentPair Programming

Agile GamesBehaviour Driven Development

484643

383634312927242421

139

Percentage (%)Nicolas Guelfi- Wednesday 11th November, 2015 (23:06) - University of Luxembourg, LU


142 / 157

Semiotics and the forgotten Pragmatics

semiotics

steve:Adminitrator

(pa,[1])

steve: Administrator

steve : Administrator

1

pa

syntactics semantics pragmatics



143 / 157

MessirBookNicolas Guelfi

Laboratory for Advanced Software SystemsUniversity of Luxembourg

Messir

A Scientific Method forthe Software Engineering Master

- v 0.63 -Thursday 14th May, 2015 - 16:26

Contents

Part I - Specification, Simulation and Documentation 1

I.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .