• Have any questions?
  • info.zbook.org@gmail.com

Lecture 5 Agile Software Development - Jjcao's Homepage

4m ago
1.15 MB
54 Pages
Last View : 18d ago
Last Download : 1m ago
Upload by : Fiona Harless

Software EngineeringLecture 5 – Agile Software DevelopmentJJCAOMostly based on the presentation of Software Engineering, 9ed

ExerciseDescribe the main activities in the software designprocess and the outputs of these activities. Using adiagram, show possible relationships between theoutputs of these activities.

Explain why systems developed as prototypes should notnormally be used as production systems Prototypes should be discarded afterdevelopment as they are not a good basis fora production system:1. It may be impossible to tune the system to meetnon-functional requirements;2. Prototypes are normally undocumented;3. The prototype structure is usually degradedthrough rapid change;4. The prototype probably will not meet normalorganizational quality standards.

Topics covered Agile methodsPlan-driven and agile developmentExtreme programmingAgile project managementScaling agile methodsChapter 3 Agile software development4

Rapid software development Rapid development & delivery is now often the mostimportant requirement for software systems– Businesses operate in a fast –changing requirement and it ispractically impossible to produce a set of stable softwarerequirements– Software has to evolve quickly to reflect changing businessneeds. Rapid software development– Specification, design and implementation are inter-leaved– System is developed as a series of versions withstakeholders involved in version evaluation– User interfaces are often developed using an IDE andgraphical toolset.Chapter 3 Agile software development5

Agile methods Dissatisfaction with the overheads involved in softwaredesign methods of the 1980s & 1990s led to the creation ofagile methods. These methods:– Focus on the code rather than the design– Are based on an iterative approach to software development– Are intended to deliver working software quickly and evolve thisquickly to meet changing requirements. The aim of agile methods is to reduce overheads in thesoftware process (e.g. by limiting documentation) and to beable to respond quickly to changing requirements withoutexcessive rework.Chapter 3 Agile software development6

Chapter 3 Agile software development7

The principles of agilemethodsPrincipleDescriptionCustomer involvementCustomers should be closely involved throughout the developmentprocess. Their role is provide and prioritize new system requirementsand to evaluate the iterations of the system.Incremental deliveryThe software is developed in increments with the customer specifying therequirements to be included in each increment.People not processThe skills of the development team should be recognized andexploited. Team members should be left to develop their own ways ofworking without prescriptive processes.Embrace changeExpect the system requirements to change and so design the system toaccommodate these changes.Maintain simplicityFocus on simplicity in both the software being developed and in thedevelopment process. Wherever possible, actively work to eliminatecomplexity from the system.Chapter 3 Agile software development8

Agile method applicability1. Product development where a software company is developinga small or medium-sized product for sale.2. Custom system development within an organization, wherethere is a clear commitment from the customer to becomeinvolved in the development process and where there are not alot of external rules and regulations that affect the software. Because of their focus on small, tightly-integrated teams, thereare problems in scaling agile methods to large systems.Chapter 3 Agile software development9

Problems with agile methods1. It can be difficult to keep the interest of customers who areinvolved in the process.2. Team members may be unsuited to the intense involvement thatcharacterises agile methods.3. Prioritising changes can be difficult where there are multiplestakeholders.4. Maintaining simplicity requires extra work.5. Contracts may be a problem as with other approaches to iterativedevelopment.Chapter 3 Agile software development10

Agile methods and software maintenance Most organizations spend more on maintainingexisting software than they do on new softwaredevelopment. So, if agile methods are to be successful,they have to support maintenance as well as originaldevelopment. Two key issues:– Are systems that are developed using an agile approachmaintainable, given the emphasis in the developmentprocess of minimizing formal documentation?– Can agile methods be used effectively for evolving asystem in response to customer change requests? Problems may arise if original development teamcannot be maintained.Chapter 3 Agile software development11

Plan-driven and agile development Plan-driven development– A plan-driven approach to software engineering is basedaround separate development stages with the outputs tobe produced at each of these stages planned in advance.– Not necessarily waterfall model – plan-driven, incrementaldevelopment is possible– Iteration occurs within activities. Agile development– Specification, design, implementation and testing areinter-leaved and the outputs from the developmentprocess are decided through a process of negotiationduring the software development process.Chapter 3 Agile software development12

Plan-driven and agile specificationChapter 3 Agile software development13

Technical, human, organizational issues Most projects include elements of plan-driven and agileprocesses. Deciding on the balance depends on:– Is it important to have a very detailed specification anddesign before moving to implementation? If so, you probablyneed to use a plan-driven approach.– Is an incremental delivery strategy, where you deliver thesoftware to customers and get rapid feedback from them,realistic? If so, consider using agile methods.Chapter 3 Agile software development14

Technical, human, organizational issues– How large is the system that is being developed? Agilemethods are most effective when the system can bedeveloped with a small co-located team who cancommunicate informally. This may not be possible forlarge systems that require larger development teams soa plan-driven approach may have to be used.Chapter 3 Agile software development15

Technical, human, organizational issues– What type of system is being developed? Plan-driven approaches may be required for systems that require alot of analysis before implementation (e.g. real-time system withcomplex timing requirements).– What is the expected system lifetime? Long-lifetime systems may require more design documentation tocommunicate the original intentions of the system developers to thesupport team.– What technologies are available to support systemdevelopment? Agile methods rely on good tools to keep track of an evolving design– How is the development team organized? If the development team is distributed or if part of the developmentis being outsourced, then you may need to develop designdocuments to communicate across the development teams.Chapter 3 Agile software development16

Technical, human, organizational issues– Are there cultural or organizational issues that may affect the systemdevelopment? Traditional engineering organizations have a culture of plan-baseddevelopment, as this is the norm in engineering.– How good are the designers and programmers in the developmentteam? It is sometimes argued that agile methods require higher skill levels thanplan-based approaches in which programmers simply translate a detaileddesign into code– Is the system subject to external regulation? If a system has to be approved by an external regulator (e.g. the FAA approvesoftware that is critical to the operation of an aircraft) then you will probablybe required to produce detailed documentation as part of the system safetycase.Chapter 3 Agile software development17

Extreme programming Perhaps the best-known and most widelyused agile method. Extreme Programming (XP) takes an ‘extreme’approach to iterative development.– New versions may be built several times per day;– Increments are delivered to customers every 2weeks;– All tests must be run for every build and the buildis only accepted if tests run successfully.Chapter 3 Agile software development19

XP and agile principles Incremental development is supported through small,frequent system releases. Customer involvement means full-time customerengagement with the team. People are supported through pair programming, collectiveownership and a process that avoids long working hours. Change supported through regular system releases. Maintaining simplicity through constant refactoring of code.Chapter 3 Agile software development20

The extreme programming releasecycleChapter 3 Agile software development21

Extreme programming practices (a)Principle or practiceDescriptionIncremental planningRequirements are recorded on story cards and the stories to beincluded in a release are determined by the time available andtheir relative priority. The developers break these stories intodevelopment ‘Tasks’. See Figures 3.5 and 3.6.Small releasesThe minimal useful set of functionality that provides businessvalue is developed first. Releases of the system are frequentand incrementally add functionality to the first release.Simple designEnough design is carried out to meet the current requirementsand no more.Test-first developmentAn automated unit test framework is used to write tests for anew piece of functionality before that functionality itself isimplemented.RefactoringAll developers are expected to refactor the code continuouslyas soon as possible code improvements are found. This keepsthe code simple and maintainable.Chapter 3 Agile software development22

Extreme programming practices (b)Pair programmingDevelopers work in pairs, checking each other’s work andproviding the support to always do a good job.Collective ownershipThe pairs of developers work on all areas of the system, so thatno islands of expertise develop and all the developers takeresponsibility for all of the code. Anyone can changeanything.Continuous integrationAs soon as the work on a task is complete, it is integrated intothe whole system. After any such integration, all the unit testsin the system must pass.Sustainable paceLarge amounts of overtime are not considered acceptable asthe net effect is often to reduce code quality and medium termproductivityOn-site customerA representative of the end-user of the system (the customer)should be available full time for the use of the XP team. In anextreme programming process, the customer is a member ofthe development team and is responsible for bringing systemrequirements to the team for implementation.Chapter 3 Agile software development23

Requirements scenarios In XP, a customer or user is part of the XP team and isresponsible for making decisions on requirements. User requirements are expressed as scenarios or userstories. These are written on cards and the development teambreak them down into implementation tasks. Thesetasks are the basis of schedule and cost estimates. The customer chooses the stories for inclusion in thenext release based on their priorities and the scheduleestimates.Chapter 3 Agile software development24

A ‘prescribing medication’ storyPrescribing MedicationKate is a doctor who wishes to prescribe medication for a patient attending a clinic. The patient record isalready displayed on her computer so she clicks on the medication field and can select ‘current medication’,‘new medication’ or ‘formulary’.If she selects ‘current medication’, the system asks her to check the dose. If she wants to change the dose,she enters the dose and then confirms the prescription.If she chooses ‘new medication’, the system assumes that she knows which medication to prescribe. Shetypes the first few letters of the drug name. The system displays a list of possible drugs starting with theseletters. She chooses the required medication and the system responds by asking her to check that themedication selected is correct. She enters the dose and then confirms the prescription.If she chooses ‘formulary’, the system displays a search box for the approved formulary. She can thensearch for the drug required. She selects a drug and is asked to check that the medication is correct. Sheenters the dose and then confirms the prescription.The system always checks that the dose is within the approved range. If it isn’t, Kate is asked to change thedose.After Kate has confirmed the prescription, it will be displayed for checking. She either clicks ‘OK’ or ‘Change’.If she clicks ‘OK’, the prescription is recorded on the audit database. If she clicks on ‘Change’, she reentersthe ‘Prescribing medication’ process.Chapter 3 Agile software development25

Examples of task cards for prescribingmedicationChapter 3 Agile software development26

Each task generates one or more unit teststhat check the implementation described inthat task.

XP and change Conventional wisdom in software engineeringis to design for change. It is worth spendingtime and effort anticipating changes as thisreduces costs later in the life cycle. XP, however, maintains that this is notworthwhile as changes cannot be reliablyanticipated. Rather, it proposes constant codeimprovement (refactoring) to make changeseasier when they have to be implemented.Chapter 3 Agile software development28

Refactoring Programming team look for possible softwareimprovements and make these improvements evenwhere there is no immediate need for them. This improves the understandability of the softwareand so reduces the need for documentation. Changes are easier to make because the code is wellstructured and clear. However, some changes requires architecturerefactoring and this is much more expensive.Chapter 3 Agile software development29

Examples of refactoring Re-organization of a class hierarchy to removeduplicate code. Tidying up and renaming attributes andmethods to make them easier to understand. The replacement of inline code with calls tomethods that have been included in aprogram library.Chapter 3 Agile software development30

Key points Agile methods are incremental development methods that focus onrapid development, frequent releases of the software, reducingprocess overheads and producing high-quality code. They involvethe customer directly in the development process. The decision on whether to use an agile or a plan-driven approachto development should depend on the type of software beingdeveloped, the capabilities of the development team and theculture of the company developing the system. Extreme programming is a well-known agile method that integratesa range of good programming practices such as frequent releasesof the software, continuous software improvement and customerparticipation in the development team.Chapter 3 Agile software development31

Chapter 3 – Agile SoftwareDevelopmentLecture 6Chapter 3 Agile software development32

Testing in XP Testing is central to XP and XP hasdeveloped an approach where the programis tested after every change has been made. XP testing features:1. Test-first development.2. Incremental test development fromscenarios.3. User involvement in test development andvalidation.4. Automated test harnesses are used to run allcomponent tests each time that a newrelease is built.Chapter 3 Agile software development33

Test-first development Writing tests before code clarifies therequirements to be implemented. Tests are written as programs rather than data sothat they can be executed automatically. The testincludes a check that it has executed correctly.– Usually relies on a testing framework such as Junit. All previous and new tests are run automaticallywhen new functionality is added, thus checkingthat the new functionality has not introducederrors.Chapter 3 Agile software development34

Customer involvement The role of the customer in the testing process is to helpdevelop acceptance tests for the stories that are to beimplemented in the next release of the system. The customer who is part of the team writes tests asdevelopment proceeds. All new code is therefore validatedto ensure that it is what the customer needs. However, people adopting the customer role have limitedtime available and so cannot work full-time with thedevelopment team. They may feel that providing therequirements was enough of a contribution and so may bereluctant to get involved in the testing process.Chapter 3 Agile software development35

Test case description for dose checkingChapter 3 Agile software development36

Test automation Test automation means that tests are written as executablecomponents before the task is implemented– These testing components should be stand-alone, shouldsimulate the submission of input to be tested and should checkthat the result meets the output specification. An automatedtest framework (e.g. Junit) is a system that makes it easy towrite executable tests and submit a set of tests for execution. As testing is automated, there is always a set of tests thatcan be quickly and easily executed– Whenever any functionality is added to the system, the testscan be run and problems that the new code has introduced canbe caught immediately.Chapter 3 Agile software development37

XP testing difficulties Programmers prefer programming to testing andsometimes they take short cuts when writing tests. Forexample, they may write incomplete tests that do notcheck for all possible exceptions that may occur. Some tests can be very difficult to write incrementally.For example, in a complex user interface, it is oftendifficult to write unit tests for the code thatimplements the ‘display logic’ and workflow betweenscreens. It difficult to judge the completeness of a set of tests.Although you may have a lot of system tests, your testset may not provide complete coverage.Chapter 3 Agile software development38

Pair programming In XP, programmers work in pairs, sitting together to develop code. This helps develop common ownership of code and spreadsknowledge across the team. It serves as an informal review process as each line of code islooked at by more than 1 person. It encourages refactoring as the whole team can benefit from this.Chapter 3 Agile software development39

Pair programming Pairs are created dynamically so that all team members work with each otherduring the development process. The sharing of knowledge that happens during pair programming is very importantas it reduces the overall risks to a project when team members leave. Pair programming is not necessarily inefficient and there is evidence that a pairworking together is more efficient than 2 programmers working separately.Chapter 3 Agile software development40

Advantages of pair programming It supports the idea of collective ownership andresponsibility for the system.– Individuals are not held responsible for problems with thecode. Instead, the team has collective responsibility forresolving these problems. It acts as an informal review process because each lineof code is looked at by at least two people. It helps support refactoring, which is a process ofsoftware improvement.– Where pair programming and collective ownership areused, others benefit immediately from the refactoring sothey are likely to support the process.Chapter 3 Agile software development41

Agile project management The principal responsibility of software project managers isto manage the project so that the software is delivered ontime and within the planned budget for the project. The standard approach to project management is plandriven. Managers draw up a plan for the project showingwhat should be delivered, when it should be delivered andwho will work on the development of the projectdeliverables. Agile project management requires a differen

Software Engineering Lecture 5 –Agile Software Development JJCAO Mostly based on the presentation of Software Engineering, 9ed. . –A plan-driven approach to software engineering is based . Chapter 3 Agile software de