Agile Software Development (ASD) has been on mainstream through methodologies such as XP and Scrum enabling them to be applied in the development of complex and reliable software systems. This paper is the end result of the Master’s dissertation of the main author, and proposes a solution to guide the development of complex systems based on components by adding exceptional behavior modeling practices to Scrum, resulting in the Scrum+CE method (Scrum with Exceptional Behavior). In order to evaluate the proposed method, a synthetic controlled experiment was conducted with three groups.We compared the efficiency of the new process in relation to plain Scrum and the results were the production of a better quality software but with less features implemented during the same amount of time.

1. Development of Complex Software
with Agile Method
Alan Braz, Cec´ılia M. F. Rubira, Marco Vieira
<alanbraz@br.ibm.com>,
<cmrubira@ic.unicamp.br>, <mvieira@dei.uc.pt>
Agile 2015 - Short Research paper
@alanbraz Agile2015
August 5, 2015

2. Development of Complex Software with Agile Method
Agenda
1 Introduction and Motivation
2 Proposed solution
3 Controlled Experiment
4 Conclusion
2 / 23

3. Development of Complex Software with Agile Method
Introduction and Motivation
Agenda
1 Introduction and Motivation
2 Proposed solution
3 Controlled Experiment
4 Conclusion
3 / 23

4. Development of Complex Software with Agile Method
Introduction and Motivation
Introduction
Dependability is no longer a mere nonfunctional
requirement just inherent to critical systems
Known applied solutions:
Component-Based Development (CBD) [1]
Architecture-Centric Development [2]
4 / 23

5. Development of Complex Software with Agile Method
Introduction and Motivation
Related work
Related work
2001 - Gisele R M Ferreira [3]
Created the Methodology for the Definition of
Exceptional Behavior (MDCE)
Methodology to build fault-tolerant systems using
techniques of exception handling
Extends the UML with new stereotypes
Case study appling it to Catalysis development process
2005 - Patrick Henrique da Silva Brito [4]
Extended MDCE defining MDCE+ by systematizing the
modeling and implementation of exceptional behavior
Focus on antecipate exceptional behavior at the
Architecture level
Adapted the UML Components process
5 / 23

6. Development of Complex Software with Agile Method
Proposed solution
Agenda
1 Introduction and Motivation
2 Proposed solution
3 Controlled Experiment
4 Conclusion
6 / 23

7. Development of Complex Software with Agile Method
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

8. Development of Complex Software with Agile Method
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
D
evelop*
W
rap
Review
A
djust
* includes analysis,
design and coding
Description of
exceptional assertive
MDCE+ practices affecting Scrum phases.
Extended from Schwaber:95 [5] 8 / 23

9. Development of Complex Software with Agile Method
Proposed solution
Scrum+CE
Relation between phases
Table : Relation between MDCE+ and Scrum phases.
Scrum Phases Scrum Events MDCE+ Phases
Pregame
Planning
1. Requirements specification and analysis
2. Management aspects definition
System architecture /
high level design
3. Architecture design
Game
Sprint Planning
1. Requirements specification and analysis
3. Architecture design
4. System analysis
5. System design
Sprint
6. Components implementation
7. Components integration
Sprint Review
1. Requirements specification and analysis
8. User-acceptance release
Postgame
Integration tests 7. Components integration
Wrapping
8. Production Release deploy
Closure
9 / 23

10. Development of Complex Software with Agile Method
Proposed solution
Phases affected
Pregame
Planning
Identify the exceptions and define the exceptional
behavior in the form of Exceptional Stories
Describe the exceptional assertive in the form of
Acceptance Tests either at the normal behavior User
Stories [6] or at the introduced Exceptional Stories
Definition of “Done”
“. . . and all exceptions were properly handled. . . ”
System architecture / high level design
New role: Architecture Owner
New mandatory artifact: High Level Architecture
document
Architecture-Centric Development to expose exceptional
components
“The best architectures, requirements, and designs
emerge from self-organizing teams” [7]
10 / 23

11. Development of Complex Software with Agile Method
Proposed solution
Phases affected
Game
Exceptional Stories will be prioritized and
selected from the Product Backlog just like the
User Stories
Tasks dedicated to the implementation of
exceptional behavior should be created during
the Sprint Planning meeting and added to the
Sprint Backlog
Architecture should be reviewed and updated
when new exceptions are discovered
11 / 23

12. Development of Complex Software with Agile Method
Controlled Experiment
Agenda
1 Introduction and Motivation
2 Proposed solution
3 Controlled Experiment
4 Conclusion
12 / 23

13. Development of Complex Software with Agile Method
Controlled Experiment
Methodology
Methodology
Designed a controlled experiment in which a
information-based software system, with
dependability requirements relating to data
consistency, were implemented
Followed a controlled method called Synthetic
Environment Experiments [8] (reduced version)
Format of “Scrum in Practice” training lasting
2 weeks, composed by 3 teams of 4 participants
each.
13 / 23

14. Development of Complex Software with Agile Method
Controlled Experiment
Methodology
Architecture
DB2
OpenJPARestlet
Browser
Mobile
Entities
Exceptional
Presentation
Exceptional
Persistence
User Interface User Session /
System Services
Business Services Database
JSON
HTTP
14 / 23

15. Development of Complex Software with Agile Method
Controlled Experiment
Methodology
Agenda
Table : Schedule of Sprint 1.
Day Activity Duration
1
Reception and organization 2 hours
Planning Meeting 2 hours
2
Daily Scrum 3 minutes
Implementation day 1 2 hours
Daily Scrum 3 minutes
Implementation day 2 2 hours
3
Daily Scrum 3 minutes
Implementation day 3 2 hours
Daily Scrum 3 minutes
Implementation day 4 2 hours
4
Daily Scrum 3 minutes
Implementation day 5 2 hours
Daily Scrum 3 minutes
Implementation day 6 2 hours
5
Daily Scrum 3 minutes
Implementation day 7 2 hours
Review Meeting 2 hours
Table : Schedule of Sprint 2.
Day Activity Duration
1
Planning Meeting 2 hours
Daily Scrum 3 minutes
Implementation day 1 2 hours
2
Daily Scrum 3 minutes
Implementation day 2 2 hours
Daily Scrum 3 minutes
Implementation day 3 2 hours
3
Daily Scrum 3 minutes
Implementation day 4 2 hours
Daily Scrum 3 minutes
Implementation day 5 2 hours
4
Daily Scrum 3 minutes
Implementation day 6 2 hours
Daily Scrum 3 minutes
Implementation day 7 2 hours
5
Collective Sprint Review Meeting 3 hours
Collective Sprint Retrospective 1 hour
15 / 23

16. Development of Complex Software with Agile Method
Controlled Experiment
Results
Stories delivered
Product Backlog G1 G2 G3
0
10
20
30
40
50
60
70
61
49
45 47
13
9 7 8
Story
Points
User
Stories
Figure : Total of Stories and Points delivered.
Table : User Stories
delivered 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

17. Development of Complex Software with Agile Method
Controlled Experiment
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, and
between G1 and G3.
17 / 23

18. Development of Complex Software with Agile Method
Controlled Experiment
Results
Requirements quality metrics
Table : Number of tests
executed and defects found
by group.
Metric G1 G2 G3
Tests executed 189 149 161
Failed tests 66 44 21
Fail 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 G1
and G2, and between G1 and G3.
G2 failed 5% less than G1.
G3 failed 22% less than G1.
18 / 23

19. Development of Complex Software with Agile Method
Controlled Experiment
Results
Code quality metrics
Metric G1 G2 G3
Lines of Code (LOC) 2232 1984 1950
Number of Classes 27 47 38
Number of Exceptions 1 21 2
Native catch blocks 53 18 33
Created catch blocks 9 12 6
Cyclomatic Complexity (CC) [9] 446 305 288
CC by class 15.9 4.5 7.2
CC 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

20. Development of Complex Software with Agile Method
Conclusion
Agenda
1 Introduction and Motivation
2 Proposed solution
3 Controlled Experiment
4 Conclusion
20 / 23

21. Development of Complex Software with Agile Method
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

22. Development of Complex Software with Agile Method
Conclusion
Challenges
It is really complicated (and expensive) to make quantitative
experiments in Software Engineering.
Despite the size of the experiment, in terms of number of
participants and duration, we couldn’t apply any statistical analysis.
The same experiment could be replicated with more groups or even
bigger groups (scale).
Applied to remodel software engineering practice courses.
Research is not Agile :(
22 / 23

23. Development of Complex Software with Agile Method
Conclusion
References
C. Szyperski, Component Software: Beyond
Object-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 exce¸c˜oes no
desenvolvimento de sistemas confi´aveis baseados em
componentes,” Master’s thesis, IC, Unicamp, Dec. 2001.
P. H. S. Brito, “Um M´etodo para Modelagem de Exce¸c˜oes
em Desenvolvimento Baseado em Componentes,” Master’s
thesis, IC, Unicamp, Oct. 2005.
K. Schwaber, “SCRUM Development Process,” in
Proceedings of the 10th Annual ACM Conference on
Object Oriented Programming Systems, Languages, and
Applications (OOPSLA), pp. 117–134.
M. Cohn, User Stories Applied: For Agile Software
Development. Addison-Wesley, 2004.
K. Beck et al. (2001) Manifesto for Agile Software
Development. Accessed: 17 Apr 2015. [Online]. Available:
http://agilemanifesto.org
M. V. Zelkowitz and D. Wallace, “Experimental Validation
In Software Engineering,” Information and Software
Technology, 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