Agile2015 short paper presentation: Development of Complex Software with Agile Method
1 like756 views
This document presents an adaptation of the agile software development process with a focus on managing exceptional behavior through a methodology called Scrum+CE. A controlled experiment demonstrated that while fewer story points were delivered, the quality improved with a reduction in defects and better code design. The findings suggest that incorporating robust handling of exceptional cases can be achieved without compromising agility.
![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](https://image.slidesharecdn.com/agile2015slides-150805153025-lva1-app6892/85/Agile2015-short-paper-presentation-Development-of-Complex-Software-with-Agile-Method-4-320.jpg)
![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](https://image.slidesharecdn.com/agile2015slides-150805153025-lva1-app6892/85/Agile2015-short-paper-presentation-Development-of-Complex-Software-with-Agile-Method-5-320.jpg)
![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](https://image.slidesharecdn.com/agile2015slides-150805153025-lva1-app6892/85/Agile2015-short-paper-presentation-Development-of-Complex-Software-with-Agile-Method-7-320.jpg)
![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](https://image.slidesharecdn.com/agile2015slides-150805153025-lva1-app6892/85/Agile2015-short-paper-presentation-Development-of-Complex-Software-with-Agile-Method-8-320.jpg)
![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](https://image.slidesharecdn.com/agile2015slides-150805153025-lva1-app6892/85/Agile2015-short-paper-presentation-Development-of-Complex-Software-with-Agile-Method-10-320.jpg)
![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](https://image.slidesharecdn.com/agile2015slides-150805153025-lva1-app6892/85/Agile2015-short-paper-presentation-Development-of-Complex-Software-with-Agile-Method-13-320.jpg)
![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](https://image.slidesharecdn.com/agile2015slides-150805153025-lva1-app6892/85/Agile2015-short-paper-presentation-Development-of-Complex-Software-with-Agile-Method-19-320.jpg)
![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](https://image.slidesharecdn.com/agile2015slides-150805153025-lva1-app6892/85/Agile2015-short-paper-presentation-Development-of-Complex-Software-with-Agile-Method-23-320.jpg)
Agile2015 short paper presentation: Development of Complex Software with Agile Method
- 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