CP5046: Week 2

Software processes, Agile processes

jcu.edu.au
 Topics
• What is a software process?
• What are software process models?
• What is process improvement?

• What are agile methods?

• What are agile techniques?
• What is agile project management?

jcu.edu.au
 A software process is collection of technical,
collaborative, and managerial activities

With the overall goal of specifying, designing,

coding, testing, and delivering a software system

Activity Activity Activity

jcu.edu.au
 Common software process activities are:

• Specification – defining what the software should do;

• Development – design the software and coding the software;

• Validation – checking that it does what the customer wants;

• Evolution – changing the software in response to changing needs

jcu.edu.au
 There are two types of software process

• Plan-based - all activities are planned first - progress is measured

against this plan

• Agile - planning is progressive - change is possible for the plan over

time – reflecting changing customer requirements

jcu.edu.au
 A software process model is used to describe
how software process activities work together
Three common software processes models are:
• The waterfall model
• Plan-based only. Separate and distinct phases of specification and development

• The incremental development process model

• Specification, development and validation are interleaved. Plan-based or agile.
The software is developed in a series of increments

• The integration and configuration process model

• Software is assembled from existing configurable components. Plan-based or
agile
jcu.edu.au
 Activities in the waterfall model are “phases”
that get performed in sequential order

jcu.edu.au
 The waterfall model works when software
requirements won't change quickly

• An important option to waterfall are “formal methods”

• These are used when developing software with stringent safety,

reliability, and/or security requirements

• This is not a focus in CP5046

jcu.edu.au
 In waterfall, each activity should
be completed before moving on

• It costs time and money to redo previous

activities if necessary…

• “made-to-order” projects from the

business world are quick to change

• Hence, using waterfall might not work

jcu.edu.au
 The incremental development model
interleaves and cycles over some activities

jcu.edu.au
 Please note: “incremental” is sometimes
confused with “iterative”

• E.g. “incremental” and “iterative” are used interchangeably throughout

the Sommerville textbook
• In software engineering, the meaning of incremental and iterative are
similar but are not the same thing!

• Creating software incrementally happens when it’s divided into parts

that are fully functional
• Whereas, creating software iteratively happens when functionality is
progressive build up, understood, and refined over time
jcu.edu.au
 Incremental development has benefits over
the waterfall model
• The cost of accommodating changing customer requirements is
reduced

• It is easier to get customer feedback about the development work

• Customers see demonstrations of the software and so they understand how
much has been implemented

• It’s likely that useful software gets to the customer more quickly
• Customers gain value from the software earlier than is possible with a
waterfall process
jcu.edu.au
 However, Incremental development has some
drawbacks:
• Managers need regular deliverables to measure progress - but
progress might be hard to see
• Because - it’s not cost-effective to produce documents that reflect every
incremental version of the software as it’s being developed

• Software design is prone to degrade as new increments are added

• Incorporating further software changes becomes increasingly difficult and
costly
• Unless time and money are spent on refactoring and documenting the
software development…

jcu.edu.au
 Integration and configuration is described
in terms of software systems reuse

• The software is produced by integrating existing components or

application systems
• These are called COTS - Commercial-off-the-shelf systems

• Reused elements are configured – this adapts their behaviour and

functionality to the project goals
• Reuse is a standard approach for building many types of business
software systems
jcu.edu.au
 Software process activities

jcu.edu.au
 Activities are organized differently in
different software processes
• For example, in the waterfall model, they are organized in sequence,
whereas in incremental development they are interleaved

Here again are the four common activities in a software process:

1. Specification
2. Development
3. Validation
4. Evolution

jcu.edu.au
 1) Software specification is captured in the
form of software requirements

• A “software requirement” is a statement about some aspect of the

software
• They are typically a broad and abstract statement about:
• A service the software must provide (a functional requirement)
• Or constraint on how the software must behave (a non-functional
requirement)

jcu.edu.au
 A plan-based software specification is created by
a rigorous “requirements engineering” process

jcu.edu.au
 Agile software specification is much simpler
and less rigorous
• Agile methods incrementally refine software requirements in the
form of user stories

• More about user stories later!

jcu.edu.au
 2) Software development consists of
software design and software implementation

• Software development converts the software specification into

executable software

• Software design - the structure, data, and UX of the software

• Software implementation - translate the software design into an

executable program

jcu.edu.au
 Plan-based development behaves like this:

jcu.edu.au
 Agile development is simpler than plan-based
development

jcu.edu.au
 Here’s how plan-based software design
works

jcu.edu.au
 The common software design activities are:

• Architectural design - identify the overall structure of the software,

and its principal components and relationships

• Database design – determine how data is captured in a database

• Interface design - define how each component can be used without

depending too much on other components

• Component selection - search for reusable components

jcu.edu.au
 Software implementation follows naturally
from software design
• These are closely related and may be interleaved

• Debugging helps a developer find and correct coding mistakes as they

implement the design

jcu.edu.au
 3) Software validation demonstrates how well
software meets customer requirements

• Sometimes called “Verification and Validation” (V & V)

• Software testing is the most commonly used V & V activity

• But also involves other types of checking and review

processes – e.g. pair-programming, formal code reviews

jcu.edu.au
 It’s possible to split up software testing

jcu.edu.au
 Stages of testing
• Component testing
• Individual components are tested independently. May be functions or objects
or a collection of related code

• System testing
• Testing of the system as a whole. Testing of emergent properties is
particularly important

• Acceptance testing
• Testing with customer data to check that the system meets the customer’s
needs
jcu.edu.au
 In a plan-based software process, testing* is
necessarily more involved…

* In agile processes, testing is handled differently…

jcu.edu.au
 4) Software evolution happens after* the
software is delivered and actively in use

* This is possible because software is inherently flexible and can change

jcu.edu.au
 Thoughts about software evolution

• As requirements change through changing business circumstances,

the software that supports the business must also evolve and change

• There is a distinction between development and evolution – but this

is increasingly irrelevant
• Because fewer new software systems are completely new…

jcu.edu.au
 Process improvement

jcu.edu.au
 Process improvement is a way of enhancing
the quality of software and the process

Two quite different approaches exist:

• The maturity approach – a set of additional activities that focus on
improving good software engineering practices

• The agile approach – incorporate good software engineering practices

into existing agile activities – more on this later!

jcu.edu.au
 The maturity approach is cyclic:

jcu.edu.au
 Measurement Analysis Change

Measure attributes The current process Changes are

of the software is assessed, and proposed that
process -these form weaknesses and address some of the
a baseline that bottlenecks are identified
helps you decide if identified weaknesses and
previous bottlenecks
improvements were
effective

jcu.edu.au
 Metrics are useful in the maturity approach:

• The time taken for process activities to be completed

• E.g. Calendar time or effort to complete an activity or process

• The resources required for the process or specific activities within it

• E.g. Total effort in person-days

• The number of occurrences of a particular event

• E.g. Number of defects discovered

jcu.edu.au
 Now it’s time to talk about
agile processes…

jcu.edu.au
 A dissatisfaction with the overheads of plan-based
software processes led to the agile manifesto
• Agile methods focus on the code rather than the design
• They are related to the incremental* approach discussed previously
• But are improved to deliver working software that evolves to meet
changing requirements

• Agile methods aim to:

• Reduce overheads in the software process (e.g. limiting documentation)
• Respond quickly to changing requirements without excessive rework

jcu.edu.au
 Agile processes are applicable in these
situations:
• Small or medium-sized software

• Where there is a clear commitment from the customer to get involved

in the development process
• Where there are few external rules and regulations that affect the
software development

• Virtually all consumer products and apps are now developed using an
agile processes

jcu.edu.au
 Okay, let’s introduce you to an important
agile process called XP

A simple way manage a software project

jcu.edu.au
 Extreme programming (XP)
• A very influential agile process, developed in the late 1990s, that
introduced a range of agile development techniques

• Extreme Programming (XP) takes an ‘extreme’ approach to incremental

development
• Increments are delivered to customers every 1-2 weeks
• All tests must be run for every build
• The build is only accepted if tests run successfully

jcu.edu.au
 XP operates on a release cycle

jcu.edu.au
 The XP process is based on several agile
principles

• Incremental development is supported through small, frequent

software 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 software releases
• Maintaining simplicity through constant refactoring of code
jcu.edu.au
 Drawbacks of XP
• Extreme programming has a technical focus and is not easy to
integrate with management practice in most organizations

• Consequently, while agile development uses practices from XP, the

method as originally defined is not widely used

• We focus on it in CP5046 because it is easy to understand and use –

and we adjust it to include a less technical focus

jcu.edu.au
 XP has several important practices
• System metaphor for shared understanding

• User stories for specification

• Refactoring to prevent design degradation

• Test-first development

• Pair programming
jcu.edu.au
 Key practice: User stories for requirements
• In XP, a customer or user is part of the XP team and is responsible for
making decisions on requirements

• Software requirements are expressed as user stories using this

template:
As an <actor> I want <some action> so that I get <some value>

jcu.edu.au
 User stories are written on cards (physical or
virtual), for example:

jcu.edu.au
 And here is a more sophisticated user story
with more elements:

jcu.edu.au
 Other user story elements are:
• The stub – the “title” of the user story, short version of the value
statement
• Acceptance criteria – these written by the customer and allow them
to see when all the tasks that implement a user story have been
completed
• Story size – is one type of “story estimation” (more about this later)

• Customer priority – this is how important this user stories to the

customer – how important it is to implement this story

jcu.edu.au
 Thoughts about user stories:
• Each one only captures a single, self-contained software requirement

• Initially, a user story should be kept intentionally brief – this helps

foster collaboration and conversations with the customer
• Which helps the project team discover and clarify software
requirements

• Individual tasks can be used to capture the additional

insights discovered when talking with the customer
jcu.edu.au
 The project team breaks each
user story into tasks
• Tasks are assigned to team members to
implement

• These tasks are the basis of development

schedule and cost estimates

• Stories are selected based on customer

priority and the project team’s cost
estimates
jcu.edu.au
 E.g. an “epic” user story about ‘prescribing
medication’ from the Mentcare case study

jcu.edu.au
 And here that epic user story is split into
more focused tasks (or simpler stories…)

jcu.edu.au
 Conventional wisdom in software
engineering is to design for change
• Spending time and effort anticipating changes should reduce costs
later in the life cycle – but this is generally not true

• However, in XP this is not worthwhile – since changes cannot be

reliably anticipated

• Rather, XP proposes refactoring - constant code improvements that

are expected to make dealing with change easier

jcu.edu.au
 Thoughts about refactoring
• The project team looks for possible improvements and make these
improvements even where there is no immediate need for them
• This improves the understandability of the software and so reduces the need
for documentation!

• Changes are easier to make because the code is well-structured and

clearer

• However, some changes requires architecture refactoring and this is

much more expensive
jcu.edu.au
 Examples of refactoring
• Re-organization of a class hierarchy to remove duplicate code

• Tidying up and renaming attributes and methods to make them easier

to understand

• The replacement of inline code with calls to methods that have been
included in a program library

jcu.edu.au
 Testing in XP
• Testing is central to XP - the software is tested after every change has
been made

• XP testing features:
• Test-first development
• 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

jcu.edu.au
 An example test case description for dose
checking from the Mentcare case study

jcu.edu.au
 In test-first development, tests are executable
components made before tasks are 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

• As testing is automated, whenever functionality is added to the

software, tests can be run and problems that new code introduced
can be caught immediately!

jcu.edu.au
 Problems with test-first development
• Some developers prefer programming to testing so they take short
cuts when writing tests. E.g. write incomplete tests that do not check
for all possible exceptions that may occur

• Some tests can be very difficult to write incrementally. E.g. in a

complex user interface, it’s often difficult to write unit tests for the
code that implements the ‘display logic’ and workflow between
screens

jcu.edu.au
 Pair programming involves programmers
working in pairs, developing code together

• This helps develop common ownership of code

and spreads knowledge across the team

• It serves as an informal review process as each

line of code is looked at by more than 1 person

• It encourages refactoring as the whole team

can benefit from improving the system code

jcu.edu.au
 Thoughts about Pair programming
• Pairs should be created dynamically - so that all team members work
with each other during the development process

• Sharing knowledge happens during pair programming – this is very

important - it reduces project risk – e.g. team member leave / get sick

• There is some evidence that suggests a pair working together is more

efficient than 2 programmers working separately

jcu.edu.au
 Key points
• Software processes are the activities involved in producing a software
system. Software process models are abstract representations of
these processes
• General process models describe the organization of software
processes
• Examples of these general models include the ‘waterfall’ model, incremental
development, and reuse-oriented development
• Requirements engineering is the process of developing a software
specification – used by plan-based processes

jcu.edu.au
 Key points
• Design and implementation processes are concerned with
transforming a requirements specification into an executable software
system.
• Software validation is the process of checking that the system
conforms to its specification and that it meets the real needs of the
users of the system.
• Software evolution takes place when you change existing software
systems to meet new requirements. The software must evolve to
remain useful

jcu.edu.au
 Key points
• The principal approaches to process improvement are agile
approaches, geared to reducing process overheads, and maturity-
based approaches based on better process management and the use
of good software engineering practice

jcu.edu.au
 Key points
• Agile development practices include
• User stories for system specification
• Frequent releases of the software,
• Continuous software improvement
• Test-first development
• Customer participation in the development team.

jcu.edu.au