2023-12-06

Introduction to Software Engineering Chapter 3 – Agile Software Development

Associate Professor Lecture 4

Hasan Abdulkader
COMPUTER SCIENCE AND TELECOMMUNICATIONS, PhD

Chapter 3 Agile software development 1 Chapter 3 Agile software development 2

1 2

Objectives Topics covered

 The objective of this chapter is to introduce you to agile  Agile methods

software development methods. When you have read  Extreme programming
the chapter, you will:
 understand the rationale for agile software development  Agile project management
methods, the agile manifesto, and the differences between agile  Scaling agile methods
and plan-driven development;
 know about important agile development practices such as user  Plan-driven and agile development
stories, refactoring, pair programming and test-first development;
 understand the Scrum approach to agile project management;
 understand the issues of scaling agile development methods and
combining agile approaches with plan-driven approaches in the
development of large software systems.

Chapter 3 Agile software development 3 Chapter 3 Agile software development 4

3 4
 2023-12-06

Rapid software development Agile methods

 Rapid development and delivery is now often the most  Dissatisfaction with the overheads involved in software
important requirement for software systems design methods of the 1980s and 1990s led to the
 Businesses operate in a fast –changing requirement and it is creation of agile methods. These methods:
practically impossible to produce a set of stable software  Focus on the code rather than the design
requirements
 Are based on an iterative approach to software development
 Software has to evolve quickly to reflect changing business needs.
 Are intended to deliver working software quickly and evolve this
 Rapid software development quickly to meet changing requirements.
 Specification, design and implementation are inter-leaved  The aim of agile methods is to reduce overheads in the
 System is developed as a series of versions with stakeholders software process (e.g. by limiting documentation) and to
involved in version evaluation be able to respond quickly to changing requirements
 User interfaces are often developed using an IDE and graphical without excessive rework.
toolset.

Chapter 3 Agile software development 5 Chapter 3 Agile software development 6

5 6

The principles of agile methods Agile method applicability

Principle Description  Product development where a software company is

Customer involvement Customers should be closely involved throughout the developing a small or medium-sized product for sale.
development process. Their role is provide and prioritize new
system requirements and to evaluate the iterations of the  Custom system development within an organization,
system.
where there is a clear commitment from the customer to
Incremental delivery The software is developed in increments with the customer
specifying the requirements to be included in each increment. become involved in the development process and where
there are not a lot of external rules and regulations that
People not process The skills of the development team should be recognized and
exploited. Team members should be left to develop their own affect the software.
ways of working without prescriptive processes.
 Because of their focus on small, tightly-integrated teams,
Embrace change Expect the system requirements to change and so design the
system to accommodate these changes. there are problems in scaling agile methods to large
Maintain simplicity Focus on simplicity in both the software being developed and
systems.
in the development process. Wherever possible, actively work
to eliminate complexity from the system.

Chapter 3 Agile software development 7 Chapter 3 Agile software development 8

7 8
 2023-12-06

Problems with agile methods Agile methods and software maintenance

 It can be difficult to keep the interest of customers who  Most organizations spend more on maintaining existing
are involved in the process. software than they do on new software development. So,
 Team members may be unsuited to the intense if agile methods are to be successful, they have to
involvement that characterises agile methods. support maintenance as well as original development.
 Two key issues:
 Prioritising changes can be difficult where there are
multiple stakeholders.  Are systems that are developed using an agile approach
maintainable, given the emphasis in the development process of
 Maintaining simplicity requires extra work. minimizing formal documentation?
 Can agile methods be used effectively for evolving a system in
 Contracts may be a problem as with other approaches to
response to customer change requests?
iterative development.
 Problems may arise if original development team cannot
be maintained.
Chapter 3 Agile software development 9 Chapter 3 Agile software development 10

9 10

Extreme programming XP and agile principles

 Perhaps the best-known and most widely used agile  Incremental development is supported through small,
method. frequent system releases.
 Extreme Programming (XP) takes an ‘extreme’ approach  Customer involvement means full-time customer
to iterative development. engagement with the team.
 New versions may be built several times per day;
 Increments are delivered to customers every 2 weeks;  People not process through pair programming, collective
 All tests must be run for every build and the build is only ownership and a process that avoids long working hours.
accepted if tests run successfully.
 Change supported through regular system releases.
 Maintaining simplicity through constant refactoring of
code.

Chapter 3 Agile software development 11 Chapter 3 Agile software development 12

11 12
 2023-12-06

The extreme programming release cycle Extreme programming practices (a)

Principle or practice Description

Incremental planning Requirements are recorded on story cards and the stories to be
included in a release are determined by the time available and
their relative priority. The developers break these stories into
development ‘Tasks’. See Figures 3.5 and 3.6.

Small releases The minimal useful set of functionality that provides business
value is developed first. Releases of the system are frequent
and incrementally add functionality to the first release.

Simple design Enough design is carried out to meet the current requirements
and no more.
Test-first development An automated unit test framework is used to write tests for a
new piece of functionality before that functionality itself is
implemented.
Refactoring All developers are expected to refactor the code continuously as
soon as possible code improvements are found. This keeps the
code simple and maintainable.
Chapter 3 Agile software development 13 Chapter 3 Agile software development 14

13 14

Extreme programming practices (b) Requirements scenarios

 In XP, a customer or user is part of the XP team and is

Pair programming Developers work in pairs, checking each other’s work and
providing the support to always do a good job.
responsible for making decisions on requirements.
Collective ownership The pairs of developers work on all areas of the system, so that  User requirements are expressed as scenarios or user
no islands of expertise develop and all the developers take
responsibility for all of the code. Anyone can change anything. stories.
Continuous integration As soon as the work on a task is complete, it is integrated into  These are written on cards and the development team
the whole system. After any such integration, all the unit tests in
the system must pass. break them down into implementation tasks. These tasks
Sustainable pace Large amounts of overtime are not considered acceptable as are the basis of schedule and cost estimates.
the net effect is often to reduce code quality and medium term
productivity  The customer chooses the stories for inclusion in the
On-site customer A representative of the end-user of the system (the customer) next release based on their priorities and the schedule
should be available full time for the use of the XP team. In an
extreme programming process, the customer is a member of estimates.
the development team and is responsible for bringing system
requirements to the team for implementation.
Chapter 3 Agile software development 15 Chapter 3 Agile software development 16

15 16
 2023-12-06

Examples of task cards for prescribing

A ‘prescribing medication’ story
medication

Chapter 3 Agile software development 17 Chapter 3 Agile software development 18

17 18

XP and change Refactoring

 Conventional wisdom in software engineering is to  Programming team look for possible software
design for change. It is worth spending time and effort improvements and make these improvements even
anticipating changes as this reduces costs later in the life where there is no immediate need for them.
cycle.
 This improves the understandability of the software and
 XP, however, maintains that this is not worthwhile as
changes cannot be reliably anticipated. so reduces the need for documentation.

 Rather, it proposes constant code improvement  Changes are easier to make because the code is well-
(refactoring) to make changes easier when they have to structured and clear.
be implemented.  However, some changes requires architecture
 In principle, when refactoring is part of the development refactoring, and this is much more expensive.
process, the software should always be easy to
understand and change as new requirements are
proposed.
Chapter 3 Agile software development 19 Chapter 3 Agile software development 20

19 20
 2023-12-06

Examples of refactoring Testing in XP

 Re-organization of a class hierarchy to remove duplicate  Testing is central to XP and XP has developed an
code. approach where the program is tested after every
 Tidying up and renaming attributes and methods to make change has been made.
them easier to understand.  XP testing features:
 The replacement of inline code with calls to methods that  Test-first development.
have been included in a program library.  Incremental test development from scenarios.
 User involvement in test development and validation.
 Automated test harnesses are used to run all component tests
each time that a new release is built.

Chapter 3 Agile software development 21 Chapter 3 Agile software development 22

21 22

Test-first development Customer involvement

 Writing tests before code clarifies the requirements to be  The role of the customer in the testing process is to help
implemented. develop acceptance tests for the stories that are to be
 Tests are written as programs rather than data so that implemented in the next release of the system.
they can be executed automatically. The test includes a  The customer who is part of the team writes tests as
check that it has executed correctly.
development proceeds. All new code is therefore
 Usually relies on a testing framework such as Junit.
validated to ensure that it is what the customer needs.
 All previous and new tests are run automatically when
new functionality is added, thus checking that the new  However, people adopting the customer role have limited
functionality has not introduced errors. time available and so cannot work full-time with the
development team. They may feel that providing the
requirements was enough of a contribution and so may
be reluctant to get involved in the testing process.

Chapter 3 Agile software development 23 Chapter 3 Agile software development 24

23 24
 2023-12-06

Test case description for dose checking Test automation

 Test automation means that tests are written as

executable components before the task is implemented
 These testing components should be stand-alone, should
simulate the submission of input to be tested and should check
that the result meets the output specification. An automated test
framework (e.g. Junit) is a system that makes it easy to write
executable tests and submit a set of tests for execution.
 As testing is automated, there is always a set of tests
that can be quickly and easily executed
 Whenever any functionality is added to the system, the tests can
be run and problems that the new code has introduced can be
caught immediately.

Chapter 3 Agile software development 25 Chapter 3 Agile software development 26

25 26

XP testing difficulties Pair programming

 Programmers prefer programming to testing and  In XP, programmers work in pairs, sitting together to
sometimes they take short cuts when writing tests. For develop code.
example, they may write incomplete tests that do not  This helps develop common ownership of code and
check for all possible exceptions that may occur. spreads knowledge across the team.
 Some tests can be very difficult to write incrementally.  It serves as an informal review process as each line of
For example, in a complex user interface, it is often code is looked at by more than 1 person.
difficult to write unit tests for the code that implements  It encourages refactoring as the whole team can benefit
the ‘display logic’ and workflow between screens. from this.
 It difficult to judge the completeness of a set of tests.  Measurements suggest that development productivity
Although you may have a lot of system tests, your test with pair programming is similar to that of two people
set may not provide complete coverage. working independently.

Chapter 3 Agile software development 27 Chapter 3 Agile software development 28

27 28
 2023-12-06

Pair programming Advantages of pair programming

 In pair programming, programmers sit together at the  It supports the idea of collective ownership and
same workstation to develop the software. responsibility for the system.
 Pairs are created dynamically so that all team members  Individuals are not held responsible for problems with the code.
Instead, the team has collective responsibility for resolving these
work with each other during the development process.
problems.
 The sharing of knowledge that happens during pair  It acts as an informal review process because each line
programming is very important as it reduces the overall of code is looked at by at least two people.
risks to a project when team members leave.
 It helps support refactoring, which is a process of
 Pair programming is not necessarily inefficient and there software improvement.
is evidence that a pair working together is more efficient
 Where pair programming and collective ownership are used,
than 2 programmers working separately. others benefit immediately from the refactoring so they are likely
to support the process.
Chapter 3 Agile software development 29 Chapter 3 Agile software development 30

29 30

Project management Agile Project Management : Scrum

 The principal responsibility of software project managers  The Scrum approach is a general agile method but its
is to manage the project so that the software is delivered focus is on managing iterative development rather than
on time and within the planned budget for the project. specific agile practices.
 The standard approach to project management is plan-  There are three phases in Scrum.
driven. Managers draw up a plan for the project showing  The initial phase is an outline planning phase where you
what should be delivered, when it should be delivered establish the general objectives for the project and design the
and who will work on the development of the project software architecture.
deliverables.  This is followed by a series of sprint cycles, where each cycle
develops an increment of the system.
 Agile project management requires a different approach,  The project closure phase wraps up the project, completes
which is adapted to incremental development and the required documentation such as system help frames and user
particular strengths of agile methods. manuals and assesses the lessons learned from the project.

Chapter 3 Agile software development 31 Chapter 3 Agile software development 32

31 32
 2023-12-06

Scrum terminology -1 Scrum terminology -2

Chapter 3 Agile software development 33 Chapter 3 Agile software development 34

33 34

Scrum benefits The Scrum process

 The product is broken down into a set of manageable

and understandable chunks.
 Unstable requirements do not hold up progress.
 The whole team have visibility of everything and
consequently team communication is improved.
 Customers see on-time delivery of increments and gain
feedback on how the product works.
 Trust between customers and developers is established
and a positive culture is created in which everyone
expects the project to succeed.

Chapter 3 Agile software development 35 Chapter 3 Agile software development 36

35 36
 2023-12-06

The Sprint cycle The Sprint cycle

 Sprints are fixed length, normally 2–4 weeks. They  Once these are agreed, the team organize themselves to
correspond to the development of a release of the develop the software. During this stage the team is
system in XP. isolated from the customer and the organization, with all
 The starting point for planning is the product backlog, communications channelled through the so-called
‘Scrum master’.
which is the list of work to be done on the project.
 The role of the Scrum master is to protect the
 The selection phase involves all of the project team who
development team from external distractions.
work with the customer to select the features and
functionality to be developed during the sprint.  At the end of the sprint, the work done is reviewed and
presented to stakeholders. The next sprint cycle then
begins.

Chapter 3 Agile software development 37 Chapter 3 Agile software development 38

37 38

Teamwork in Scrum Scaling agile methods

 The ‘Scrum master’ is a facilitator who arranges daily  Agile methods have proved to be successful for small
meetings, tracks the backlog of work to be done, records and medium sized projects that can be developed by a
decisions, measures progress against the backlog and small co-located team.
communicates with customers and management outside
 It is sometimes argued that the success of these
of the team.
methods comes because of improved communications
 The whole team attends short daily meetings where all which is possible when everyone is working together.
team members share information, describe their  Scaling up agile methods involves changing these to
progress since the last meeting, problems that have
cope with larger, longer projects where there are multiple
arisen and what is planned for the following day.
development teams, perhaps working in different
 This means that everyone on the team knows what is going on locations.
and, if problems arise, can re-plan short-term work to cope with
them.

Chapter 3 Agile software development 39 Chapter 3 Agile software development 40

39 40
 2023-12-06

Distributed Scrum Large system development

 Large systems and their development processes are

often constrained by external rules and regulations
limiting the way that they can be developed.
 Large systems have a long procurement and
development time. It is difficult to maintain coherent
teams who know about the system over that period as,
inevitably, people move on to other jobs and projects.
 Large systems usually have a diverse set of
stakeholders. It is practically impossible to involve all of
these different stakeholders in the development process.

Chapter 3 Agile software development 41 Chapter 3 Agile software development 42

41 42

Scaling up to large systems Plan-driven Versus agile development

 For large systems development, it is not possible to focus only  Plan-driven development
on the code of the system. You need to do more up-front  A plan-driven approach to software engineering is based around
design and system documentation separate development stages with the outputs to be produced at
 Cross-team communication mechanisms have to be designed each of these stages planned in advance.
and used. This should involve regular phone and video  Not necessarily waterfall model – plan-driven, incremental
conferences between team members and frequent, short development is possible
electronic meetings where teams update each other on  Iteration occurs within activities.
progress.  Agile development
 Continuous integration, where the whole system is built every  Specification, design, implementation and testing are inter-
time any developer checks in a change, is practically leaved and the outputs from the development process are
impossible. However, it is essential to maintain frequent decided through a process of negotiation during the software
system builds and regular releases of the system. development process.

Chapter 3 Agile software development 43 Chapter 3 Agile software development 44

43 44
 2023-12-06

Technical, human, organizational issues Technical, human, organizational issues

 Most projects include elements of plan-driven and agile  What type of system is being developed?
processes. Deciding on the balance depends on: • Plan-driven approaches may be required for systems that require a lot
of analysis before implementation (e.g. real-time system with complex
 Is it important to have a very detailed specification and design timing requirements).
before moving to implementation? If so, you probably need to use  What is the expected system lifetime?
a plan-driven approach.
• Long-lifetime systems may require more design documentation to
 Is an incremental delivery strategy, where you deliver the software communicate the original intentions of the system developers to the
to customers and get rapid feedback from them, realistic? If so, support team.
consider using agile methods.  What technologies are available to support system development?
 How large is the system that is being developed? Agile methods • Agile methods rely on good tools to keep track of an evolving design
are most effective when the system can be developed with a small  How is the development team organized?
co-located team who can communicate informally. This may not be
• If the development team is distributed or if part of the development is
possible for large systems that require larger development teams
being outsourced, then you may need to develop design documents to
so a plan-driven approach may have to be used. communicate across the development teams.

Chapter 3 Agile software development 45 Chapter 3 Agile software development 46

45 46

Technical, human, organizational issues Key points

 Are there cultural or organizational issues that may affect the  Agile methods are incremental development methods that focus on
system development? rapid development, frequent releases of the software, reducing
• Traditional engineering organizations have a culture of plan-based process overheads and producing high-quality code. They involve
development, as this is the norm in engineering. the customer directly in the development process.
 How good are the designers and programmers in the  The decision on whether to use an agile or a plan-driven approach
development team? to development should depend on the type of software being
• It is sometimes argued that agile methods require higher skill levels developed, the capabilities of the development team and the culture
than plan-based approaches in which programmers simply translate of the company developing the system.
a detailed design into code
 Is the system subject to external regulation?  Extreme programming is a well-known agile method that integrates
a range of good programming practices such as frequent releases of
• If a system has to be approved by an external regulator (e.g. the
the software, continuous software improvement and customer
FAA approve software that is critical to the operation of an aircraft)
then you will probably be required to produce detailed
participation in the development team.
documentation as part of the system safety case.

Chapter 3 Agile software development 47 Chapter 3 Agile software development 48

47 48
 2023-12-06

Key points Further reading

 A particular strength of extreme programming is the  I. K. Kirpitsas and T. P. Pachidis, “Evolution towards
development of automated tests before a program Hybrid Software Development Methods and Information
feature is created. All tests must successfully execute Systems Audit Challenges,” Software, vol. 1, no. 3, pp.
when an increment is integrated into a system. 316–363, Aug. 2022, doi: 10.3390/software1030015.
 The Scrum method is an agile method that provides a https://www.mdpi.com/2674-113X/1/3/15
project management framework. It is centred round a set
of sprints, which are fixed time periods when a system
increment is developed.
 Scaling agile methods for large systems is difficult. Large
systems need up-front design and some documentation.

Chapter 3 Agile software development 49 Chapter 3 Agile software development 50

49 50