agile2015 short paper presentation: development of complex software with agile method

Development of Complex Software

with Agile Method

Alan Braz, Cecılia M. F. Rubira, Marco Vieira<[email protected]>,

<[email protected]>, <[email protected]>

Agile 2015 - Short Research paper@alanbraz Agile2015

August 5, 2015

Development of Complex Software with Agile Method

Agenda

1 Introduction and Motivation

2 Proposed solution

3 Controlled Experiment

4 Conclusion

2 / 23


Introduction and Motivation

Agenda


2 Proposed solution


4 Conclusion

3 / 23



Introduction

Dependability is no longer a mere nonfunctionalrequirement just inherent to critical systems

Known applied solutions:Component-Based Development (CBD) [1]Architecture-Centric Development [2]

4 / 23



Related work

Related work

2001 - Gisele R M Ferreira [3]Created the Methodology for the Definition ofExceptional Behavior (MDCE)

Methodology to build fault-tolerant systems usingtechniques of exception handlingExtends the UML with new stereotypesCase study appling it to Catalysis development process

2005 - Patrick Henrique da Silva Brito [4]Extended MDCE defining MDCE+ by systematizing themodeling and implementation of exceptional behavior

Focus on antecipate exceptional behavior at theArchitecture levelAdapted the UML Components process

5 / 23


Proposed solution

Agenda


2 Proposed solution


4 Conclusion

6 / 23


Proposed solution

Proposed solution

Adapted agile development process based

on Scrum [5] process that adds some

MDCE+ practices and techniques to

increase the robustness

Scrum+CE(CE comes from Exceptional Behavior in Portuguese)

Validation hypotheses: (i) less Story Points, and(ii) better quality of the final software in terms of less defects.

7 / 23


Proposed solution

Scrum+CE

Scrum+CE phases

Exception identification and definition of the exceptional behavior in the form

of exceptional stories

Components implementation and wrap creation for the reused components

Separation of concerns between normal and

exceptional components Analysis of the exceptional flow and catchers refinement

Connectors implementation

Pregame- Planning- System architecture/high level design

Postgame- Integration tests- Final wrap- Closure

Game

Sprints

Develo

p* Wrap

ReviewAdjust

* includes analysis,design and coding

Description of exceptional assertive

MDCE+ practices affecting Scrum phases.

Extended from Schwaber:95 [5] 8 / 23


Proposed solution

Scrum+CE

Relation between phases

Table : Relation between MDCE+ and Scrum phases.

Scrum Phases Scrum Events MDCE+ Phases

PregamePlanning

1. Requirements specification and analysis2. Management aspects definition

System architecture /high level design

3. Architecture design

Game

Sprint Planning

1. Requirements specification and analysis3. Architecture design4. System analysis5. System design

Sprint6. Components implementation7. Components integration

Sprint Review1. Requirements specification and analysis8. User-acceptance release

PostgameIntegration tests 7. Components integrationWrapping

8. Production Release deployClosure

9 / 23


Proposed solution

Phases affected

Pregame

Planning

Identify the exceptions and define the exceptionalbehavior in the form of Exceptional StoriesDescribe the exceptional assertive in the form ofAcceptance Tests either at the normal behavior UserStories [6] or at the introduced Exceptional Stories

Definition of “Done”

“. . . and all exceptions were properly handled. . . ”

System architecture / high level design

New role: Architecture OwnerNew mandatory artifact: High Level ArchitecturedocumentArchitecture-Centric Development to expose exceptionalcomponents“The best architectures, requirements, and designsemerge from self-organizing teams” [7]

10 / 23


Proposed solution

Phases affected

Game

Exceptional Stories will be prioritized andselected from the Product Backlog just like theUser Stories

Tasks dedicated to the implementation ofexceptional behavior should be created duringthe Sprint Planning meeting and added to theSprint Backlog

Architecture should be reviewed and updatedwhen new exceptions are discovered

11 / 23


Controlled Experiment

Agenda


2 Proposed solution


4 Conclusion

12 / 23



Methodology

Methodology

Designed a controlled experiment in which ainformation-based software system, withdependability requirements relating to dataconsistency, were implemented

Followed a controlled method called SyntheticEnvironment Experiments [8] (reduced version)

Format of “Scrum in Practice” training lasting2 weeks, composed by 3 teams of 4 participantseach.

13 / 23



Methodology

Architecture

DB2OpenJPARestlet

Browser

Mobile

Entities

ExceptionalPresentation

ExceptionalPersistence

User Interface User Session / System Services

Business Services Database

JSON

HTTP

14 / 23



Methodology

Agenda

Table : Schedule of Sprint 1.

Day Activity Duration

1Reception and organization 2 hoursPlanning Meeting 2 hours

2

Daily Scrum 3 minutesImplementation day 1 2 hoursDaily Scrum 3 minutesImplementation day 2 2 hours

3


4


5

Daily Scrum 3 minutesImplementation day 7 2 hoursReview Meeting 2 hours

Table : Schedule of Sprint 2.

Day Activity Duration

1Planning Meeting 2 hoursDaily Scrum 3 minutesImplementation day 1 2 hours

2


3


4


5Collective Sprint Review Meeting 3 hoursCollective Sprint Retrospective 1 hour

15 / 23



Results

Stories delivered

Product Backlog G1 G2 G30

10

20

30

40

50

60

7061

4945 47

139 7 8

Story Points

User Stories

Figure : Total of Stories and Points delivered.

Table : User Storiesdelivered by group

Story Points G1 G2 G3

1 20 • • •2 5 • • •3 8 • • •4 3 • • •5 3 • • •6 2 • •7 1 • • •8 3

9 5 • • •10 2 •11 2

12 5

13 2

Total stories 9 7 8

Total points 49 45 47

16 / 23



Results

Stories delivered

G2 delivered 22% less stories than G1.G3 delivered 11% less stories than G1.

User Stories Story Points-25.0%

-20.0%

-15.0%

-10.0%

-5.0%

-22%

-8%

-11%

-4%

G1-G2

G1-G3

Figure : Comparing implemented stories between G1 and G2, andbetween G1 and G3.

17 / 23



Results

Requirements quality metrics

Table : Number of testsexecuted and defects foundby group.

Metric G1 G2 G3

Tests executed 189 149 161Failed tests 66 44 21Fail rate 35% 30% 13%

Tests executed Failed tests Fail rate-80%

-70%

-60%

-50%

-40%

-30%

-20%

-10%

0%

-21%

-33%

-5%

-15%

-68%

-22%

G1-G2

G1-G3

Figure : Comparing defects between G1and G2, and between G1 and G3.

G2 failed 5% less than G1.

G3 failed 22% less than G1.

18 / 23



Results

Code quality metrics

Metric G1 G2 G3

Lines of Code (LOC) 2232 1984 1950Number of Classes 27 47 38Number of Exceptions 1 21 2Native catch blocks 53 18 33Created catch blocks 9 12 6Cyclomatic Complexity (CC) [9] 446 305 288CC by class 15.9 4.5 7.2CC by method 5.0 2.4 2.5

G2 and G3 produced 12% less lines of code than G1.

G2 and G3 designed a complexity 33% smaller than G1.

19 / 23


Conclusion

Agenda


2 Proposed solution


4 Conclusion

20 / 23


Conclusion

Consolidated results

Applying Scrum+CE resulted in:

Better code quality. Validated!

13.5% less defects on average!Complexity 33% smaller implies better code design!

Delivered less Story Points but with fewer defects.Validated!

Only 6% less due to the size of the experiment.Critic: The experiment does not scale!

It is possible to develop complex software if Agile!Adding Exceptional Behavior handling does not compromise the

agility.

21 / 23


Conclusion

Challenges

It is really complicated (and expensive) to make quantitativeexperiments in Software Engineering.

Despite the size of the experiment, in terms of number ofparticipants and duration, we couldn’t apply any statistical analysis.

The same experiment could be replicated with more groups or evenbigger groups (scale).

Applied to remodel software engineering practice courses.

Research is not Agile :(

22 / 23


Conclusion

ReferencesC. Szyperski, Component Software: BeyondObject-Oriented Programming. Boston, MA, USA:Addison-Wesley Longman Publishing Co., Inc.

I. Sommerville, Software Engineering, 9th ed. Harlow,England: Addison-Wesley, 2010.

G. R. M. Ferreira, “Tratamento de excecoes nodesenvolvimento de sistemas confiaveis baseados emcomponentes,” Master’s thesis, IC, Unicamp, Dec. 2001.

P. H. S. Brito, “Um Metodo para Modelagem de Excecoesem Desenvolvimento Baseado em Componentes,” Master’sthesis, IC, Unicamp, Oct. 2005.

K. Schwaber, “SCRUM Development Process,” inProceedings of the 10th Annual ACM Conference onObject Oriented Programming Systems, Languages, andApplications (OOPSLA), pp. 117–134.

M. Cohn, User Stories Applied: For Agile SoftwareDevelopment. Addison-Wesley, 2004.

K. Beck et al. (2001) Manifesto for Agile SoftwareDevelopment. Accessed: 17 Apr 2015. [Online]. Available:http://agilemanifesto.org

M. V. Zelkowitz and D. Wallace, “Experimental ValidationIn Software Engineering,” Information and SoftwareTechnology, vol. 39, pp. 735–743, 1997.

T. J. McCabe, “A Complexity Measure,” IEEE Trans.Software Eng., vol. 2, no. 4, pp. 308–320, 1976.

23 / 23

http://agilemanifesto.org

agile2015 short paper presentation: development of complex software with agile method

Engineering

agile development process

agile method introduction

solution proposed solution

agile method agenda

solution scrum ce relation

catalysis development

agile method alan braz

solution agenda