Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Agile2015 short paper presentation: Development of Complex Software with Agile Method

•
•
Alan Braz
Alan Braz

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 of 23
Download to read offline
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
Development of Complex Software with Agile Method Agenda 1 Introduction and Motivation 2 Proposed solution 3 Controlled Experiment 4 Conclusion 2 / 23
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
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
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
Development of Complex Software with Agile Method Proposed solution Agenda 1 Introduction and Motivation 2 Proposed solution 3 Controlled Experiment 4 Conclusion 6 / 23
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
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
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
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
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
Development of Complex Software with Agile Method Controlled Experiment Agenda 1 Introduction and Motivation 2 Proposed solution 3 Controlled Experiment 4 Conclusion 12 / 23
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
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
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
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
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
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
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
Development of Complex Software with Agile Method Conclusion Agenda 1 Introduction and Motivation 2 Proposed solution 3 Controlled Experiment 4 Conclusion 20 / 23
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
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
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

More Related Content

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