Agile Software Development

Session 9
 Rapid Software Development
• Rapid development and delivery is the most
important requirement for software systems
– Businesses now operate in a global, rapidly
changing environment
• changing requirement and it is practically impossible to
produce a set of stable software requirements
• Software has to evolve quickly to reflect changing
business needs.
– To take advantage of new opportunities and to respond to
competitive pressure
• Businesses may be willing:
– To trade off software quality
– To compromise on requirements if they can
deploy essential new software quickly.
2
Advanced Software Engineering - MSCSE 25, Session 9
 Rapid Software Development
• Plan-driven development:
– Completely specify the requirements design,
build, and test a system are not geared to
rapid software development.
• Essential for some types of system (as safety-
critical control systems) but does not meet rapidly
changing business needs.
• Agile development methods:
– Emerged in the late 1990s whose aim was to
radically reduce the delivery time for working
software systems
3
Advanced Software Engineering - MSCSE 25, Session 9
 Plan-driven and Agile development
• Essential distinctions between plan-driven and
agile approaches to system specification.

• iteration occurs across activities, requirements and the design are 4

developed together
 Plan-driven and Agile development
• Plan-driven development approach:
– Based around separate development stages with
the outputs to be produced at each of these
stages planned in advance.
• Not necessarily waterfall model – plan-driven,
incremental development is possible
– Iteration occurs within activities.
• Agile development approach:
– Specification, design, implementation and testing
are inter-leaved
– The outputs from the development process are
decided through a process of negotiation during
the software development process.

5
Advanced Software Engineering - MSCSE 25, Session 9
 Heavyweight Methodologies
• considered to be the traditional way of
developing software.
– These methodologies are based on a sequential
series of steps
– require defining and documenting a stable set of
requirements at the beginning
• E.g. Waterfall, Spiral and Unified Process (RUP)
– Predictive approach (plan predicts the task
delegation, Schedule, Budget etc)
– Comprehensive Documentation (big design
upfront (BDUF) process.
– Process Oriented (well defined tasks)
– Tool Oriented (PM Tools, Code editors, compilers)
6
Advanced Software Engineering - MSCSE 25, Session 9
 Lightweight Methodologies
• Faster software development processes
• Some Agile Methodologies includes:
– eXtreme Programming (XP)
– Scrum
– Feature Driven Development (FDD)
– Adaptive Software Development (ASD)

7
Advanced Software Engineering - MSCSE 25, Session 9
 Agile Methods
• These methods:
– Focus on the code rather than the design
– Based on an iterative approach to software
development
– Intended to deliver working software quickly and
evolve this quickly to meet changing
requirements.
• The aim of agile methods:
– To reduce overheads in the software process
(e.g. by limiting documentation)
– To be able to respond quickly to changing
requirements without excessive rework.
Advanced Software Engineering - MSCSE 25, Session 9
8
 Agile Methods
• Agile methods are incremental development
methods:
– Increments are small,
• New releases of the system are created and made
available to customers every two or three weeks.
– Involve customers in the development process
• Rapid feedback on changing requirements.
– Minimize documentation
– Use informal communications
• No formal meetings with written documents.
– Design and implementation to be the central
activities in the software process

9
Advanced Software Engineering - MSCSE 25, Session 9
 Agile Methods Common Characteristics
• Program specification, design and implementation
are inter-leaved
• The system is developed as a series of versions or
increments
– Stakeholders involved in version specification and
evaluation
• Frequent delivery of new versions for evaluation
• Extensive tool support
– Tools include automated testing tools, tools to support
configuration management, system integration and
tools to automate user interface production
• Minimal documentation – focus on working code
10
Advanced Software Engineering - MSCSE 25, Session 9
 Difference between Plan Driven and Agile
• The fundamental difference between Plan
driven development and Agile
development:
– Plan driven model the team will deploy one
increment of software at the end of the project.
• Sequential activity
• A process starts after successful completion of
another.
– Agile, the team will deploy a very small change
of the software or more frequently.
• Concurrent activity.
• Plan all the time.
11
Advanced Software Engineering - MSCSE 25, Session 9
 Agile Manifesto
• Individuals and interactions over processes and
tools
• Working software over comprehensive
documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

12
Advanced Software Engineering - MSCSE 25, Session 9 (http://agilemanifesto.org)
 Principles of the Agile Software development
• Highest priority to satisfy the customer
– through early and continuous delivery of valuable
software.
• Welcome changing requirements,
– even late in development.
– harness change for the customer's competitive
advantage.
• Deliver working software frequently,
– from a couple of weeks to a couple of months,
with a preference to the shorter timescale.
• Business people and developers must work
together daily throughout the project.

13
Advanced Software Engineering - MSCSE 25, Session 9
 Principles of the Agile Software development
• Build projects around motivated individuals.
– Give them the environment and support they
need, and trust them to get the job done.
• Face-to-Face conversation
– The most efficient and effective method of
conveying information to and within a
development team.
• Working software
– the primary measure of progress.
• Promote sustainable development.
– The sponsors, developers, and users should be
able to maintain a constant pace indefinitely.

14
Advanced Software Engineering - MSCSE 25, Session 9
 Principles of the Agile Software development
• Technical excellence
– Continuous attention to and good design
enhances agility.
• Simplicity
– The art of maximizing the amount of work not
done--is essential.
• The best architectures,
– requirements, and designs emerge from self-
organizing teams.
• At regular intervals,
– the team reflects on how to become more
effective, then tunes and adjusts its behavior
accordingly
15
Advanced Software Engineering - MSCSE 25, Session 9
 Agile method applicability
• Product development where a software
company is developing a small or medium-
sized product.
– Virtually all software products and apps are now
developed using an agile approach
• Custom system development within an
organization,
– where there is a clear commitment from the
customer to become involved in the development
process
– where there are few external rules and regulations
that affect the software.
16
Advanced Software Engineering - MSCSE 25, Session 9
 Agile development techniques
• Extreme Programming (XP)
– The XP process can be characterized by:
• Short development cycles, incremental planning,
continuous feedback, reliance on communication,
and evolutionary design
• Programmers respond to changing environment
– Most of the times in a day team members
spend on
• Programming,
• Project management,
• Design,
Extreme level of practices
• Feedback,
• Team building
17
Advanced Software Engineering - MSCSE 25, Session 9
 Agile development techniques
• 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 2
weeks;
– All tests must be run for every build and the build
is only accepted if tests run successfully.

extreme programming release cycle

18
Advanced Software Engineering - MSCSE 25, Session 9
 XP- Terms and Practices
• Incremental Planning:
– Estimates the effort needed for implementation of
customer stories by The programmer
– Scope and timing of releases based on estimates, by the
customer.
• Small/short releases
– An application is developed in a series of small, frequently
updated versions.
– New versions are released anywhere from daily to
monthly.
• Simple Design
– The emphasis is on designing the simplest possible
solution that is implemented
– unnecessary complexity and extra code are removed
immediately.

19
Advanced Software Engineering - MSCSE 25, Session 9
 XP- Terms and Practices
• Refactoring
– Involves restructuring the system by
• removing duplication,
• improving communication,
• simplifying and adding flexibility but without changing the
functionality of the program
• Pair programming
– All production code are written by two programmers on
one computer.
• Collective ownership
– No single person owns or is responsible for individual code
segments rather anyone can change any part of the code
at any time.
• 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.
20
Advanced Software Engineering - MSCSE 25, Session 9
 XP- Terms and Practices
• Continuous Integration
– A new piece of code is integrated with the current
system as soon as it is ready.
– When integrating, the system is built again and all
tests must pass for the changes to be accepted.
• 40-hour week
– A maximum of 40-hour working week otherwise it is
treated as a problem.
• On-site customer
– Customer must be available at all times with the
development team.
• Coding Standards
– Coding rules exist and are followed by the
programmers so as to bring consistence and improve
communication among the development team.
21
Advanced Software Engineering - MSCSE 25, Session 9
 XP and agile principles
• Incremental development is supported through small,
frequent system releases.
• Customer involvement means full-time customer
engagement with the team.
• People not process through pair programming
• Collective ownership and a process that avoids long
working hours.
• Change supported through regular system releases.
• Maintaining simplicity through constant refactoring of
code.
• Key practices
– User stories for specification
– Refactoring
– Test-first development
– Pair programming
22
Advanced Software Engineering - MSCSE 25, Session 9
 XP- Lifecycle
• Six phases:
– Exploration: customer writes the story cards
– Planning: a priority order is set to each user story,
schedule of the first release
– Iterations to Release: first iteration is to create a
system with the architecture of the whole system
then continuously integrating and testing
– Production: Extra testing, Performance checks,
– Maintenance: documenting leftovers for next
iteration
– Death: when the customer have no more stories
to be implemented
23
Advanced Software Engineering - MSCSE 25, Session 9
 Influential XP practices
• User requirements as user stories or scenarios.
• Pair Programming
– Develop common ownership of code and spreads
knowledge
– informal review process
• Refactoring
– (constant code restructuring and improvement, improved
understandability etc)
• Testing of the code after every change
– Test First Development
• Writing tests before code to clarifies the requirements to be
implemented
• Involvement of user in testing for V&V

24
Advanced Software Engineering - MSCSE 25, Session 9
 Scrum
• An agile method/ Framework that focuses on
managing iterative development rather than
specific agile practices.
• There are three phases in Scrum.
– The initial phase:
• An outline planning phase where:
– The general objectives for the project are stablished
– Software architecture is designed.
– This is followed by a series of sprint cycles:
• Each cycle develops an increment of the system.
– The project closure phase:
• wraps up the project, completes required documentation
and assesses the lessons learned from the project.
31
Advanced Software Engineering - MSCSE 25, Session 9
 Scrum
Scrum term Definition
Development team A self-organizing group (7 people) of software developers.
Responsible for developing the software and other
essential project documents.
Potentially The software increment that is delivered from a sprint.
shippable product
increment
Product backlog This is a list of ‘to do’ items (software requirements) which
the Scrum team must tackle..

Product owner An individual (or possibly a small group) whose job is to

identify product features or requirements, prioritize these
for development and continuously review the product
backlog to ensure that the project continues to meet
critical business needs.

32
Advanced Software Engineering - MSCSE 25, Session 9
 Scrum
Scrum term Definition
Scrum • A daily meeting of the Scrum team that reviews
progress and prioritizes work to be done that day.
• A short face-to-face meeting that includes the whole
team.

ScrumMaster • The ScrumMaster is responsible for ensuring that the

Scrum process is followed and guides the team in the
effective use of Scrum.
Sprint • A development iteration. Sprints are usually 2-4 weeks
long.
Velocity • An estimate of how much product backlog effort that a
team can cover in a single sprint.
• Understanding a team’s velocity helps them estimate
what can be covered in a sprint and provides a basis for
measuring improving performance.

33
Advanced Software Engineering - MSCSE 25, Session 9
 Scrum

34
Advanced Software Engineering - MSCSE 25, Session 9
 Distributed Scrum

35
Advanced Software Engineering - MSCSE 25, Session 9
 Agile methods and software maintenance
• Most organizations spend more on maintaining
existing software than they do on new software
development.
– If agile methods are to be successful, they have to
support maintenance as well as original development.
• Two key issues:
– Are systems that are developed using an agile
approach maintainable, given the emphasis in the
development process of minimizing formal
documentation?
– Can agile methods be used effectively for evolving a
system in response to customer change requests?
• Problems may arise if original development team
cannot be maintained.

36
Advanced Software Engineering - MSCSE 25, Session 9
 Agile maintenance
• Key problems are:
– Lack of product documentation
– Keeping customers involved in the development
process
– Maintaining the continuity of the development
team
• Agile development relies on the development
team knowing and understanding what has to
be done.
• For long-lifetime systems, this is a real
problem as the original developers will not
always work on the system.

37
Advanced Software Engineering - MSCSE 25, Session 9
 Agile and plan-driven methods
• Most projects include elements of plan-driven
and agile processes.
• Deciding on the balance depends on:
– Is it important to have a very detailed
specification and design before moving to
implementation?
• If so, you probably need to use a plan-driven approach.
– Is an incremental delivery strategy, where you
deliver the software to customers and get rapid
feedback from them, realistic?
• If so, consider using agile methods.

38
Advanced Software Engineering - MSCSE 25, Session 9
 Agile and plan-driven methods
• Deciding on the…..:
– How large is the system that is being
developed?
• Agile methods are most effective when the system
can be developed with a small co-located team
who can communicate informally.
• This may not be possible for large systems that
require larger development teams so a plan-driven
approach may have to be used.

39
Advanced Software Engineering - MSCSE 25, Session 9
 System issues
• How large is the system being developed?
– Agile methods are most effective a relatively small co-
located team who can communicate informally.
• What type of system is being developed?
– Systems that require a lot of analysis before implementation
need a fairly detailed design to carry out this analysis.
• What is the expected system lifetime?
– Long-lifetime systems require documentation to
communicate the intentions of the system developers to the
support team.
• Is the system subject to external regulation?
– If a system is regulated you will probably be required to
produce detailed documentation as part of the system safety
case.

40
 People and teams
• How good are the designers and programmers
in the development team?
– It is sometimes argued that agile methods require
higher skill levels than plan-based approaches in
which programmers simply translate a detailed
design into code.
• How is the development team organized?
– Design documents may be required if the team is
dsitributed.
• What support technologies are available?
– IDE support for visualisation and program analysis
is essential if design documentation is not
available.
41
 Organizational issues
• Traditional engineering organizations have a
culture of plan-based development, as this is the
norm in engineering.
– Is it standard organizational practice to develop a
detailed system specification?
– Will customer representatives be available to provide
feedback of system increments?
– Can informal agile development fit into the
organizational culture of detailed documentation?

42
 Agile methods for large systems
• Large systems are usually collections of separate,
communicating systems, where separate teams develop each
system. Frequently, these teams are working in different
places, sometimes in different time zones.
• Large systems are ‘brownfield systems’, that is they include
and interact with a number of existing systems. Many of the
system requirements are concerned with this interaction and
so don’t really lend themselves to flexibility and incremental
development.
• Where several systems are integrated to create a system, a
significant fraction of the development is concerned with
system configuration rather than original code development.

43
 Agile methods for large systems
• Large systems are usually collections of separate,
communicating systems:
– separate teams develop each system.
– Frequently, these teams are working in different places,
sometimes in different time zones.
• Large systems include and interact with a number of
existing systems (Brownfield)
– Many of the system requirements are concerned with this
interaction hence problem of flexibility and incremental
development.
• Large systems usually have a diverse set of
stakeholders.
– It is practically impossible to involve all of these different
stakeholders in the development process.
44
Factors in large systems

45
 Quiz 2

Time 15 mins
 Quiz #2
• Why it is important to make a distinction
between developing the user requirements
and developing system requirements in the
requirements engineering process
• Michael Jackson has proposed a conception
of requirements engineering that
distinguishes machine domain phenomena
from application domain phenomena:
– Explain the distinction Jackson makes between
Requirements, and Specifications.
– What additional properties should a Specification
have in order to distinguish it from Requirements?
52
Advanced Software Engineering - MSCSE 25, Session 9
Solution
 Question 1
• There is a fundamental difference between
the user and the system requirements that
mean they should be considered separately.
– The user requirements are intended to describe
the system’s functions and features from a user
perspective and it is essential that users
understand these requirements.
• They should be expressed in natural language and may
not be expressed in great detail, to allow some
implementation flexibility.
• The people involved in the process must be able to
understand the user’s environment and application
domain.

54
Advanced Software Engineering - MSCSE 25, Session 9
 Question 1
– The system requirements are much more
detailed than the user requirements and are
intended to be a precise specification of the
system that may be part of a system contract.
• They may also be used in situations where
development is outsourced and the development
team need a complete specification of what should
be developed.
• The system requirements are developed after user
requirements have been established.

55
Advanced Software Engineering - MSCSE 25, Session 9
 Question 2
• Requirements are any properties of phenomena in
the application domain that a stakeholder would
like to be made true by some new system.
– Requirements may refer to any phenomena, whether
accessible to the machine or not.
– Specifications are a subset of requirements, covering
only phenomena that are shared between the
application domain and the machine.
• To distinguish it from requirements, a specification
must be expressed only in terms of inputs and
outputs to the machine,
– i.e. phenomena that are shared between the machine
and the application domain.

56
Advanced Software Engineering - MSCSE 25, Session 9
 Reference

• Software Engineering by Ian Sommerville

• Literature on Agile Software Development
for Agile platform

57
Advanced Software Engineering - MSCSE 25, Session 9