2015 Agile ConferenceDevelopment of Complex Softwarewith Agile MethodAlan BrazCecı́lia M. F. RubiraMarco VieiraIBM Research - BrazilAvenida Tutóia 1157, 04007-005São Paulo, SP, Brazilalanbraz@br.ibm.comInstitute of ComputingState University of CampinasP.O. Box 6176, 13083-852,Campinas, SP, Brazilcmrubira@ic.unicamp.brDepartment of InformaticsEngineeringUniversity of Coimbra3030, Coimbra, Portugalmvieira@dei.uc.ptAbstract—Agile Software Development (ASD) has been onmainstream through methodologies such as XP and Scrumenabling them to be applied in the development of complexand reliable software systems. This paper is the end result ofthe Master’s dissertation of the main author, and proposes asolution to guide the development of complex systems based oncomponents by adding exceptional behavior modeling practicesto Scrum, resulting in the Scrum CE method (Scrum withExceptional Behavior).This article proposes a solution named Scrum CE to guidethe development of robust component-based systems that addssome practices of MDCE to the Scrum framework. Thesepractices affect the Pregame and Game phases in the aspect ofdiscovering and modeling exceptional conditions in the formatof Exceptional Stories and more detailed Acceptance Tests.Scrum CE also inserts a required artifact of the High LevelArchitecture and the new role of Architecture Owner.In order to evaluate the proposed method, a synthetic controlled experiment was conducted with three groups.We compared the efﬁciency of the new process in relation to plain Scrumand the results were the production of a better quality softwarebut with less features implemented during the same amount oftime.The methodology used to validate the proposed solutionwas Synthetic Environment Experiments , where a smallerversion of Scrum and Scrum CE were executed. This reduction had to be made due to the availability of human resourcesand time to execute the experiment.The validation hypotheses were that using Scrum CEwould result in the delivery of (i) less Story Points, since therequirements are more detailed; and (ii) better quality of theﬁnal software in terms of less defects, once it will drive to amore robust exception handing code.Keywords—Agile Software Development, Scrum, ComponentBased Development, Reliability, Exception handling, Software EngineeringI.I NTRODUCTIONII.The Software Engineering has been suffering changes inits methods and practices due to the growing need to developsystems in shorter periods with lower costs and satisfying quality. By contrast, the complexity of these systems is increasingas well as the need for them to be reliable. Dependabilityis no longer a mere nonfunctional requirement just inherentto critical systems, such as a ﬂight controller or a ﬁnancialsystem, but of all software systems that require a certainrobustness to not expose sensitive information and maintaina service dependable as much as possible. To address theseissues, ideas like Component-Based Development (CBD) and Architecture-Centric Development  have been appliedwith relative success on developing more reliable software.WORKRadinger and Goeschka  proposed an approach to integrate the ASD and the CBD in small and large projectsby combining the technical and organizational issues of bothapproaches.Nord and Tomayko  explored the relationships and synergies between design and analysis focused on the architecturecentric method and XP Agile methodology, noting that thelatter emphasizes the rapid and ﬂexible while the ﬁrst priorityto the design and infrastructure.Behrouz  have discussed and shown that despite the different goals, a combination of Software Reliability Engineering(SRE) and the Agile practice of Test Driven Development(TDD) have improved the reliability of the developed software.In this case, we did not focus on TDD approach to increasedependability, but we achieved it by adding elements ofexception handling at early phases of development process.However, there is a trend of using “lighter” methods ofdevelopment and project management software. This set ofprinciples and practices called lightweight were named AgileMethods or Agile Software Development (ASD) methods byseveral professionals who met in 2001 to formalize what hadalready been doing for some years, as Extreme Programming(XP)  and Scrum , resulting in the Agile Manifesto .III.BACKGROUNDA. Agile MethodNevertheless, this simplicity is often confused with informality and lack of rigor, especially regarding the activitiesof modeling, documentation of functional and nonfunctionalrequirements and architectural design.978-1-4673-7153-7/15 31.00 2015 IEEEDOI 10.1109/Agile.2015.18R ELATEDAgile Software Development (ASD) is a set of methodologies guided by four values and twelve principles deﬁned bythe Agile Manifesto . These values are:97
" #Scrum is an agile software management framework, thatpromotes an iterative and incremental development. It wasintroduced in 1995 by Schwaber  proposing a processwith three phases: Pregame (Conception or Initiation), Game(Development) and Postgame (Closure or Rollout). Fig. 1.Despite the Scrum has evolved a lot since the Schwaber’s1995  paper in terms of removing the software engineering practices and focusing on team organization and projectmanagement, for the sake of this work, we choose to use theﬁrst academic reference due to the need to handle exceptionalbehavior at the architecture level. This decision was madebecause the High Level Architecture, in our proposed solution,must begin before the ﬁrst development Sprint, there is, at thePregame.ExceptionalBehavior TABLE I.PregameR ELATION BETWEEN MDCE Scrum EventsPlanningSystem architecture /high level designSprint PlanningGameDeﬁnitionSprintSprint ReviewPostgameBrito  extended MDCE deﬁning MDCE which aimsto systematize the modeling and implementation of exceptionalbehavior in the development of component-based systems.The emphasis on architecture has enabled a better analysisof the ﬂow of exceptions that occur between architecturalcomponents, resulting in efﬁcient handlers, and anticipatingthe correction of possible speciﬁcation faults.# MDCE practices affecting Scrum phases. Extended from Scrum PhasesFerreira  presented a methodology for building faulttolerant systems using techniques of exception handling.Thismethodology is named MDCE, acronym in Portuguese for“Methodology for the Deﬁnition of Exceptional Behavior”.It extends the Uniﬁed Modeling Language (UML) with newstereotypes.IV.& ! B. Scrum Methodologyfor % The twelve principles expand the values in more details bygiving more emphasis to the left items of values than the rightones.C. Methodology(MDCE ) Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan" 1)2)3)4)Integration testsWrappingClosureANDS CRUM PHASES .MDCE Phases1. Requirements speciﬁcation andanalysis2. Management aspects deﬁnition3. Architecture design1. Requirements speciﬁcation andanalysis3. Architecture design4. System analysis5. System design6. Components implementation7. Components integration1. Requirements speciﬁcation andanalysis8. User-acceptance release7. Components integration8. Production Release deployA. Pregame1) Planning: Besides the regular activities of the Planningphase of Scrum there were added the following activities (i)identify the exceptions and deﬁne the exceptional behavior inthe form of Exceptional Stories and (ii) describe the exceptional assertive in the form of Acceptance Tests either at thenormal behavior User Stories or at the introduced ExceptionalStories.T HE P ROPOSED SOLUTIONThe proposed solution is an adapted agile developmentprocess based on Scrum process that adds some MDCE practices and techniques to increase the robustness of the developed complex product. The name of this proposed processis Scrum CE (the CE comes from Exceptional Behavior inPortuguese) and it adds practices at the Pregame and Gamephases of Scrum in order to raise, detail and document theexceptional behavior in the format of Exceptional Storiesand Acceptance Tests more judicious inside the regular UserStories , and also reﬁnes and documents the architecturehighlighting the exceptional components.During the review of the Product Backlog, all stories shouldbe revisited in order to add extra Acceptance Tests, derivedfrom the Exceptional Stories, resulting in a formalization ofthe exceptional assertive and in consequence generating a morerobust test set.Figure 1 shows the phases of Scrum with the activitiesfrom MDCE in gray. Scrum CE doesn’t add new phases toScrum, therefore it still has Pregame, Game and Postgame.Table I shows the relation between the phases of Scrum andMDCE . Note that due to the iterative aspect of the Gamephase, composed by sprints, some MDCE phases will berepeated.3) System architecture / high level design: Just like Planning, this phase still formatted by the Scrum activities plusa new role, the Architecture Owner, and a new mandatoryartifact, the High Level Architecture document. Both additionshave brought the concepts of Architecture-Centric Development to Scrum CE. The architecture has to follow the conceptsof CBD and have at least a component-level architecture2) Deﬁnition of “Done”: Exceptional behavior should alsobe explicit regardless the deﬁnition agreed by the entire team.The Architecture Owner has the responsibility of adding thefollowing to it: “. . . and all exceptions were properly handled. . . ”.98
diagram, the most important architectural decisions, used technologies and frameworks, and an initial data model. It isrecommended to document it in a collaborative tool, like aWiki. This would allow the document to be highly available,ﬂexible and support the Agile Manifesto principle that states:“The best architectures, requirements, and designs emergefrom self-organizing teams”.The Pregame and Postgame phases were done by theauthor of this paper, while the Game phase was done bythe participants. The three implemented source-codes wereavailable to the execution of functional tests and the collectionof metrics used further in the result analysis.B. GameIn this phase it was deﬁned the product Vision and ProductBacklog with all stories prioritized and estimated in StoryPoints. The role of Architecture Owner of Scrum CE wasconducted by the author for the groups G2 and G3, as wellas the roles of Product Owner and Scrum Master for allthree groups. This participation was necessary to control thevariables, requirements, artifacts and adherence to processesby groups, thus, maintaining the validity of the experiment.Every artifact was presented to each group independently.A. Pregame executionScrum CE is also an iterative process in the format oftime-boxed sprints with length between two and four weeksthat repeat continuously until the implementation of everyrequirement of the Product Backlog or the Product Ownerdeclares that the current Increment is valuable as a ﬁnalproduct. With that, the Scrum events, structure and activitiesremain the same.The MDCE practices, highlighted at Figure 1, will affectthe Product Backlog with the addition of Exceptional Stories,and the Sprint Backlog, with the related tasks dedicated tothe implementation of exceptional behavior. Once inside thebacklogs, either exceptional stories or tasks will the treated bythe Development Team as ordinary ones.1) Scrum groups division: The participants were invited toparticipate in a “Scrum in Practice” training. they had to ﬁllout a registration form composed by knowledge and experiencequestions about Agile, Scrum and Java development and 12participants were selected. It was created a technical scorefor each participant. The scores were distributed among threegroups. The scores from G1 to G3 respectively were: 253(36%), 225 (32%) and 233 (33%). G1 had the highest relativescore so it was intentionally choose to be the control group.C. PostgameThe Postgame still with the wrapping and preproductionactivities to the end-user release and did not have any changein relation to Scrum.V.2) System architecture / high level design: The architectureof the system was presented for the three groups during theﬁrst Sprint Planning Meeting and followed a simple four layermodel as illustrated at Figure 2. In this case, the layers UserSession and System Services were uniﬁed and further layersof server side followed the MVC  design pattern. Thisarchitecture was used in Scrum CE groups G2 and G3. Evennot required in Scrum, the same diagram was given to thecontrol group G1, but without the two exceptional components.VALIDATIONIn order to validate the beneﬁts and applicability ofScrum CE, we designed a controlled experiment in whicha information-based software system, with dependability requirements relating to data consistency, were implemented.The experiment consists of an object (P1), that is, the softwaresystem in Java for the web platform along with its predeﬁnedarchitecture following the Model-View Controller (MVC) pattern, and three subjects, that is, three professional groups(G1, G2 and G3) with experience this technology that will bepart of the Development Team, as described by Table II; "##TABLE II. ! E XPERIMENT MODELING .ObjectG1G2G3P1O1: ScrumO2: Scrum CEO3: Scrum CE Using this format, G1 was the control group, and consequently G2 and G3 were the experimental groups. This kind ofexperiment followed a controlled method called Synthetic Environment Experiments  where a reduced version, in termsof duration time, of Scrum and Scrum CE were executed.So each Sprint will last 1 week (4 hours per day during 5coonsecutive days), with a 2-hour virtual work-day includinga 3-minute Daily Scrum meeting. Fig. 2.Component-based software architecture diagram exposing theexceptional components used by the experimental groups G2 and G3.From the CBD standpoint, each layer was treated as a component, and the goal of Game phase was the implementationof such components.B. Game executionAll the professionals selected to implement the project ofthe experiment have at least 3 years of working experiencedeveloping software in Java and basic training in Agile. Thefact that all participants were proﬁcient in Java and Scrum,helped to strengthen the internal validity of the experiment,that is, the results would be inﬂuenced by the developmentprocess instead of their previous knowledge.The experiment itself was implement in a format of a 40hour Scrum in Practice training. The time was divided in 2sprints of 20 hours, and each sprint was composed by 7 virtualdays of 2 hours each. With that, it was possible to simulaterigorously the Scrum and Scrum CE processes. The activitiesof the three groups were conducted in parallel with a difference99
of about ten minutes between a group and another due tomovement of the author between the rooms.was created several test cases, based on the Acceptance Tests,for each delivered story.1) Sprint 1: At the beginning of the experiment, all participants were gathered in the same room where they were notiﬁedabout their respective groups and directed to a exclusivemeeting room. After that the groups started the Sprint PlanningMeeting and then followed the schedule described at Table III.Since no initial code was provided, all groups selected onlytwo User Stories to be implemented in this ﬁrst Sprint.The metrics collected in this phase were divide in threecategories: (i) number of requirements; (ii) quality of requirements; and (iii) quality of code.1) Requirements delivered metrics: A User Story was onlyconsidered completed if it respected the Deﬁnition of “Done”.Table IV shows the entire Product Backlog with the storiesdelivered by each group and its correspondent Story Points.At the end of the ﬁfth day, playing the role of ProductOwner, the author made an individual Sprint Review Meetingwith each group when they demonstrated the features implemented during this sprint. Only G1 delivered both stories. Theother two groups, delivered only one story each.TABLE IV.Day12345S CHEDULE OF S PRINT 1.ActivityDurationReception and organizationPlanning MeetingDaily ScrumImplementation day 1Daily ScrumImplementation day 2Daily ScrumImplementation day 3Daily ScrumImplementation day 4Daily ScrumImplementation day 5Daily ScrumImplementation day 6Daily ScrumImplementation day 7Review 02112125132Total storiesTotal pointsSo at the end of this sprints the Product Backlog ofthe groups was different. At this point, G1 had two storiescompleted, and G2 and G3 only one.TABLE III.U SER S TORIES DELIVERED BY hourshoursG1G2G3 9497458472) Requirements quality metrics: Once the architecture wasdesigned to interact with the system using HTTP requests, itwas built a test suite to run the same set of tests against thedifferent codes automatically. Table V consolidates the resultsof the functional tests showing the number of tests executedagainst each group code, the amount of failed tests (defects)and the fail rate.TABLE V.2) Sprint 2: It had a slightly different schedule but followedthe same structure of Table III besides the ﬁrst and last days.Day 1 was composed by a Planning Meeting of 2 hours, aDaily Scrumof 3 minutes and the Implementation day 1 with2 hours. Day 5 had a Review Meeting with 3 hours and aRetrospective that took 1 hour.N UMBER OF TESTS EXECUTED AND DEFECTS FOUND BYGROUP.MetricG1G2G3Tests executedFailed testsFail rate1896635%1494430%1612113%3) Code quality metrics: The delivered codes were submitted to a static analysis in order to evaluate the code quality.It was used an automated and open-source toll called Sonar. Table VI shows some relevant metrics provided by thistool.In this sprint, the groups started the Sprint PlanningMeeting reviewing their own updated Product Backlog andselecting the stories that they would commit with the ProductOwner to deliver at the end of Sprint 2. At the last day, wegather all participants at the same room and made a collectiveSprint Review Meeting. Every group presented the results oftheir implementation and the author, again as Product Owner,validated them all. The list of the stories delivered by eachgroups is at Table IV.TABLE VI.C ODE QUALITY METRICS .MetricLines of Code (LOC)Number of ClassesNumber of ExceptionsNative catch blocksCreated catch blocksCyclomatic Complexity (CC) CC by classCC by methodThe Sprint Retrospective was a collective session where wediscussed how was the feeling of using an agile method withtime-boxed events to develop complex software. Then it wasreveled to the participants that the process used by the groupswere 23054.52.419503823362887.22.5R ESULTS ANALYSISDue to the size of the experiment it was not possibleto make a statistical analysis of the collected data. Thus, aquantitative analysis was performed comparing the controlgroup (G1) and each of the experimental groups (G2, G3),resulting in two sets of results: G1-G2 and G1-G3.C. Postgame executionThe ﬁrst activity of this phase was to build a set offunctional tests to run against each source code available. It100
A. Requirements delive
Abstract—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 .
1. The need for an agile way of working 6 2. The need for an agile way of working 9 3. Agile Core Values - Agile Project Management Vs. 10 Agile Event Management 4. Agile principles 12 _Agile Principles of Agile Project Management 13 _Agile Principles of VOK DAMS Agile Event Management 14 5. Agile Methods 16 _Scrum in Short 16 _Kanban in Short 18
Agile Estimating and Planning by Mike Cohn Agile Game Development with Scrum by Clinton Keith Agile Product Ownership by Roman Pichler Agile Project Management with Scrum by Ken Schwaber Agile Retrospectives by Esther Derby and Diana Larsen Agile Testing: A Practical Guide for Testers and Agile Teams by Lisa Crispin and .
The most popular agile methodologies include: extreme programming (XP), Scrum, Crystal, Dynamic Sys-tems Development (DSDM), Lean Development, and Feature Driven Development (FDD). All Agile methods share a common vision and core values of the Agile Manifesto. Agile Methods: Some well-known agile software development methods include: Agile .
1.1 Purpose of the Agile Extension to the BABOK Guide1 1.2 What is Agile Business Analysis?2 1.3 Structure6 Chapter 2:The Agile Mindset 2.1 What is an Agile Mindset?7 2.2 The Agile Mindset, Methodologies, and Frameworks8 2.3 Applying the Agile Mindset9 2.4 Agile Extension and the Agile Ma
Agile World View "Agility" has manydimensions other than IT It ranges from leadership to technological agility Today's focus is on organizational & enterprise agility Agile Leaders Agile Organization Change Agile Acquisition & Contracting Agile Strategic Planning Agile Capability Analysis Agile Program Management Agile Tech.
1. Agile methods are undisciplined and not measurable. 2. Agile methods have no project management. 3. Agile methods apply only to software development. 4. Agile methods have no documentation. 5. Agile methods have no requirements. 6. Agile methods only work with small colocated teams.-7. Agile methods do not include planning. 8.
The Agile Customer . 9/6/2012 6 Agile Development Team Agile Analyst . 9/6/2012 7 Agile Programmer Agile Tester . 9/6/2012 8 Agile Manager Agile Usability Designer . 9/6/2012 9 Kicking off a project The Inception Deck –Ten questions you’d be crazy not to ask before starting any
The Agile Customer. 9/4/2013 6 Agile Development Team Agile Analyst. 9/4/2013 7 Agile Programmer Agile Tester. 9/4/2013 8 Agile Manager Agile Usability Designer. 9/4/2013 9 Kicking off a project The Inception Deck –Ten questions you’d be crazy not to ask before starting any software