School of Electronic Engineering and Computer Science EBU6304 : 02
EBU6304 – Software Engineering
Software Processes and Agile
• Topics
1. What is software process?
2. Traditional models
• Waterfall
• Evolutionary development (Incremental)
• The Rational Unified Process (RUP)
3. Modern models
• Agile software development
1
School of Electronic Engineering and Computer Science EBU6304 : 02
Software process
• A software process is a set of structured activities that
leads to the production of the software.
• Many different software processes but all involve:
– Requirement specification
– Development
• Analysis
• Design
• Implementation
– Validation (Testing/Deployment)
– Evolution (Maintenance)
2
School of Electronic Engineering and Computer Science EBU6304 : 02
Requirement specification
• Defining what the system should do;
• Aim: a complete description of the problem and of the
constraints imposed by/on the environment
• Description may contain:
– Functions of the system
– Future extensions
– Amount of documentation required
– Response time and performance
– Acceptance criteria
• Result: Requirements specification
3
School of Electronic Engineering and Computer Science EBU6304 : 02
Analysis
• Aim: analyse requirements to create a conceptual
model of the software system.
– Data modelling
– Functional modelling and information/control flow
– Behavioural modelling and state
– User interface modelling
• Result: a set of Analysis Models
4
School of Electronic Engineering and Computer Science EBU6304 : 02
Design
• Aim: an implementable model of the software system.
– Sufficient information to allow system to be built.
• Architecture is defined.
• System is decomposed to components within the
architecture.
• Design decisions dramatically impact system quality.
• Result: Detailed Design Documentation
5
School of Electronic Engineering and Computer Science EBU6304 : 02
Implementation
• Aim: implementation of all design elements.
• Starts from the component specifications developed
during design.
– Interfaces defined in the design should be respected by
the implementation of the component.
• Code should be well documented and easy to read,
flexible, correct, reliable AND fully tested.
• Result: working software.
6
School of Electronic Engineering and Computer Science EBU6304 : 02
Testing
• Checking that it does what the customer wants;
– Unit testing
– Functional testing
– Integration testing
– System testing
– Acceptance testing
– Testing and implementation should run in parallel.
• Result: Fully tested software
7
School of Electronic Engineering and Computer Science EBU6304 : 02
Deployment
• Implement a strategy to avoid outages
• Package software ready to install on a computer
system/device or deploy to servers
• Actually installing/ deploying the software.
• Live testing in real environment.
• Documentation and manuals.
• Training.
• Result: Working software in real environment
8
School of Electronic Engineering and Computer Science EBU6304 : 02
Evolution
• Aim: keeping the system operational after delivery to
the customer; changing the system in response to
changing customer needs.
– Corrective: identification and removal of faults.
– Adaptive: modifications needed to achieve
interoperability with other systems and platforms.
– Perfective: incorporation of new features, improved
performance and other modifications.
– Preventive: modifications to mitigate possible
degradation of usability, maintainability, etc.
9
School of Electronic Engineering and Computer Science EBU6304 : 02
Software process models
• Depends on the system; the activities can be:
– organised in sequence
– organised as interleaved
– organised concurrently
• Must be modelled in order to be managed.
• Software Process model
– A simplified representation of a software process – an
abstract representation.
10
School of Electronic Engineering and Computer Science EBU6304 : 02
Generic models (classic)
1. The waterfall model
– Separate and distinct phases.
2. Evolutionary development
– Activities are interleaved.
3. RUP (The Rational Unified Process)
– Four phases
There are many other software process models, e.g.
Spiral Model, V Model, Prototyping Model, Formal
Model…
11
School of Electronic Engineering and Computer Science EBU6304 : 02
Waterfall model and its phases
Cascade from one phase to another:
Requirements Sequential approach.
definition
System and
software design
Implementation
and unit testing
In principle, one phase Delivered
has to be complete
before moving onto the Integration and
next phase. system testing
Live
Operation and
maintenance
12
School of Electronic Engineering and Computer Science EBU6304 : 02
Waterfall model benefits
• Easy to monitor the progress
– After a small number of iterations, freeze parts of the
development and continue with later phases.
• Documentation is well produced at each stage.
• Structured approach.
• Specialised teams can be used at each stage of the
lifecycle.
13
School of Electronic Engineering and Computer Science EBU6304 : 02
Waterfall model problems
• Inflexible
– Difficulty of accommodating change after the process is
underway.
• Time consuming
– Real projects rarely follow the sequential flow.
– A working version of the system will not be available until
late in the project time-span.
• Minimises impact of global understanding over the
lifecycle of a project.
• Not realistic.
14
School of Electronic Engineering and Computer Science EBU6304 : 02
Waterfall model – suitable projects
• This model is only appropriate when the requirements
are well-understood and changes will be fairly limited
during the design process.
– Few business systems have stable requirements!
• Adaptation or enhancement of existing system.
• In high risk, safety critical systems e.g. air traffic control,
quality is key.
Examples:
aircraft systems, space systems, nuclear power
systems, and business critical systems, e.g.
power and telecommunications
15
School of Electronic Engineering and Computer Science EBU6304 : 02
Evolutionary development
Concurrent
activities
Initial version
Specification
Outline Intermediate
Intermediate
Development Intermediate
description versions
versions
versions
Final
Validation version
16
School of Electronic Engineering and Computer Science EBU6304 : 02
Evolutionary development
• Activities are interleaved
• Rapid feedback
• Refining through many versions, evolves over time
– Completion of a comprehensive product is impossible.
– Deliver core functions to meet competitive or business
pressure.
– Core requirements are well understood but not the detailed
extension.
17
School of Electronic Engineering and Computer Science EBU6304 : 02
Evolutionary development benefits
• Effective
– Concurrency, several members of the team may be
working on different increments or releases
• Can meet the immediate needs
– Requirements … no longer fixed
– Refining versions
• Specification can be developed incrementally
– Users feedback
– Planned feature, new feature?
18
School of Electronic Engineering and Computer Science EBU6304 : 02
Evolutionary development problems
• Lack of process visibility
– Not cost-effective to produce documents that reflect
every version.
– Lack of deliverable documents to measure progress.
• Systems are often poorly structured
– Continual change
– Rush work
• Special skills may be required
– E.g. in languages for rapid prototyping.
– What is the burden on the end user/client?
19
School of Electronic Engineering and Computer Science EBU6304 : 02
Evolutionary development – suitable projects
• Suitable for:
– small or medium-size interactive systems
– parts of large systems, e.g. the user interface
• For short-lifetime systems.
• Project with multiple features and therefore releases.
Examples:
Social networking, communication, phone apps
20
School of Electronic Engineering and Computer Science EBU6304 : 02
The Rational Unified Process
Core Workflows Inception Elaboration Construction Transition
Business Modeling
Requirements
Analysis
Design
Implementation
Test
Deployment
Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1
Iterations
[11] “The Unified Software Development Process” by Ivar Jacobson et al, 1999, Addison-Wesley, pg. 11
21
School of Electronic Engineering and Computer Science EBU6304 : 02
The Rational Unified Process (RUP)
• Inception – ends with commitment to go ahead, business case
for the project and its feasibility and feature scope identified.
• Elaboration ends with
– Basic architecture of the system in place.
– A plan for construction agreed.
– All significant risks identified.
– Major risks understood enough not to be too worried.
• Construction (iterative) – ends with beta-release of the system.
• Transition – the process of introducing the system to its users.
22
School of Electronic Engineering and Computer Science EBU6304 : 02
RUP benefits and problems
• Benefits:
– Generic process
– Separation of phases and workflows
• Dynamic
• With goals
• Problems
– Overhead
• Documents
• Diagrams
23
School of Electronic Engineering and Computer Science EBU6304 : 02
Modern software process
• Scrum (1995)
• Crystal Clear, Extreme Programming (1996)
• Adaptive Software Development, Feature Driven
Development (1997)
• Dynamic Systems Development Method (DSDM)
These are now collectively referred to as
Agile Software Development
24
School of Electronic Engineering and Computer Science EBU6304 : 02
Agile Software Development Overview
Agile will be used throughout this module
25
School of Electronic Engineering and Computer Science EBU6304 : 02
Problems of Traditional Development
• Problems:
– Poor quality
– This feature can not be tested
– Usability and User experience is
bad
– Can not meet the schedule
– Cost too high • How to:
– The team does not communicate – Do the right things?
and cooperate
– Do the right things
– Too many newcomers and lack of
right?
skills
– Know when you are
– Too many documents
done?
– Is not well maintained
26
School of Electronic Engineering and Computer Science EBU6304 : 02
Rapid software development
• The needs of Rapid Software Development:
– Rapidly changing business environments.
• No stable, consistent set of system requirements.
• It is essential that software is developed quickly to
take advantage.
– Rapid development and delivery is Critical.
• Rapid development and delivery is now often the most
important requirement for software systems
– Businesses may be willing to accept lower quality software if
rapid delivery of essential functionality is possible.
27
27
School of Electronic Engineering and Computer Science EBU6304 : 02
The Agile Process
• The processes of specification, design, implementation
and testing are concurrent, referred to as an iteration:
– no detailed specification;
– design documentation is minimised.
• The system is developed in a series of increments
– End users evaluate each increment and make
proposals for later increments.
• End users are involved
– System user interfaces are usually developed using
an interactive development system.
28
School of Electronic Engineering and Computer Science EBU6304 : 02
What is Agile?
• To address the dissatisfaction with the overheads
involved.
• Agile is a set of best practices in software
development based on Scrum, Extreme
Programming, Crystal Clear, DSDM, Lean and others.
• The set includes:
– Iteration, TDD, continuous integration, refactoring,
pair programming, story card/wall, automation test,
feedback, stand up, retrospective and showcase.
29
School of Electronic Engineering and Computer Science EBU6304 : 02
Focus of Agile
• The focus of Agile:
– Focus on the code rather than the analysis/design.
– Are based on an iterative approach to software
development.
– Are intended to deliver working software quickly and
evolve this quickly to meet changing requirements.
Lightweight, highly iterative, short iterations,
test-driven, focus on value to customer,
frequent releases, ability to cope with change
30
School of Electronic Engineering and Computer Science EBU6304 : 02
No model
Muddle through and hope for the best...
31
School of Electronic Engineering and Computer Science EBU6304 : 02
Which do you trust?
Good News,
we have finished
the design!
Waterfall
Agile
Good News,
we have completed
20% of the stories!
32
32
School of Electronic Engineering and Computer Science EBU6304 : 02
The 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
33
School of Electronic Engineering and Computer Science EBU6304 : 02
Agile team
• Agile focuses on developers (programmers) but need other
roles…
– business analyst, project manager, tester, …
34
School of Electronic Engineering and Computer Science EBU6304 : 02
Agile team
• Small, co-located, multi-disciplinary team, members are usually
working around a table
– Easy communication
• Collective code ownership
• Common vision of system (‘metaphor’)
• Sustainable pace and common coding standard
35
School of Electronic Engineering and Computer Science EBU6304 : 02
Dos and Do NOTs
• Agile needs necessary documentation
– BUT need to ensure that every document has an
audience.
• Agile encourages good practices
– BUT need to ensure that every practice solves a
problem.
• Drop anything without value.
• Don’t over design the system.
36
School of Electronic Engineering and Computer Science EBU6304 : 02
Principles of Agile (Brief)
• Customer involvement
– Closely involved throughout the development
• Incremental delivery
– Customer specifies each increment
• People, not process
– Skills, the own way
• Embrace change
– Expect change
• Maintain simplicity
– Both the system and the process
37
School of Electronic Engineering and Computer Science EBU6304 : 02
Principles of Agile (more detail)
1. Our highest priority is to satisfy the 6. The most efficient and effective method of
customer through early and conveying information to and within a
continuous delivery of valuable development team is face-to-face
software. conversation.
2. Welcome changing requirements, 7. Working software is the primary measure of
even late in development. Agile progress.
processes harness change for the 8. Agile processes promote sustainable
customer's competitive advantage. development. The sponsors, developers, and
3. Deliver working software frequently, users should be able to maintain a constant
from a couple of weeks to a couple of pace indefinitely.
months, with a preference to the 9. Continuous attention to technical excellence
shorter timescale. and good design enhances agility.
4. Business people and developers must 10. Simplicity – the art of maximizing the amount
work together daily throughout the of work not done – is essential.
project. 11. The best architectures, requirements, and
5. Build projects around motivated designs emerge from self-organizing teams.
individuals. Give them the environment 12. At regular intervals, the team reflects on how
and support they need, and trust them to become more effective, then tunes and
to get the job done. adjusts its behaviour accordingly.
38
School of Electronic Engineering and Computer Science EBU6304 : 02
Agile overview
Typically
2 weeks
Typically
2 weeks
39
School of Electronic Engineering and Computer Science EBU6304 : 02
Planning
• Emphasis on steer, rather than precise prediction.
• Release planning
– “Customer priorities” and “programmer estimates of
feature difficulty” together determine release
content.
• Iteration planning
– Two week delivery cycles
• Goal: visible progress.
40
School of Electronic Engineering and Computer Science EBU6304 : 02
Requirements (user stories)
• User requirements are expressed as user stories.
• These are written on cards and the development team
break them down into implementation tasks.
– These tasks are the basis of schedule and cost
estimates.
• The customer chooses the stories for inclusion in the
next release, based on their priorities and the schedule
estimates.
41
School of Electronic Engineering and Computer Science EBU6304 : 02
Requirements (story wall)
42
42
School of Electronic Engineering and Computer Science EBU6304 : 02
Design Improvement
• Emphasis on simple design and refactoring, i.e.
improving existing code.
• Removing duplication:
– this will inevitably creep in with incremental
development.
• Increasing cohesion.
• Reducing coupling.
43
School of Electronic Engineering and Computer Science EBU6304 : 02
Extreme programming
• Perhaps the best-known and most widely used 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 2 weeks.
– All requirements are expressed as user stories.
– Programmers work in pairs.
– Develop tests before writing code.
– All tests must be run for every build and the build is
only accepted if tests run successfully.
44
School of Electronic Engineering and Computer Science EBU6304 : 02
Pair programming
• Programmers work in pairs, sitting
together to develop code:
– 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
this.
– Measurements suggest that development productivity with pair
programming is similar to (or more efficient than) that of two
people working independently.
45
School of Electronic Engineering and Computer Science EBU6304 : 02
Test Driven Development (TDD)
• Define both an interface and a specification.
• Writing tests before code clarifies the requirements to
be implemented.
• Incremental test development from scenarios
– short cycles of adding tests then making them
work.
• Automated test harnesses are used to run all
component tests each time that a new release is built
• User involvement in test development and validation
– both programmer (unit) tests and customer
(acceptance) tests.
46
School of Electronic Engineering and Computer Science EBU6304 : 02
Integration and release
• Frequent integration:
– multiple builds per day;
– everyone involved;
– automated tool support.
• Small & Frequent Releases:
– Team releases running, tested software
delivering business value, as determined by the
customer, at every iteration.
47
School of Electronic Engineering and Computer Science EBU6304 : 02
The Release Cycle
Select user stories Break down Plan
for this release stories to tasks release
Evaluate Release Develop/integrate/
system software test software
Typically
2 weeks
Typically
2 weeks
48
School of Electronic Engineering and Computer Science EBU6304 : 02
Agile Problems (1/2)
• Problems
– It can be difficult to keep the interest of
customers who are involved in the process.
– Team members may be unsuited to the intense
involvement that characterises agile methods.
49
School of Electronic Engineering and Computer Science EBU6304 : 02
Agile Problems (2/2)
• Problems
– Prioritising changes can be difficult where there are
multiple stakeholders.
– Maintaining simplicity requires extra work.
– Contracts may be a problem as with other
approaches to iterative development.
50
School of Electronic Engineering and Computer Science EBU6304 : 02
Agile requires…
• Experience
– Has experienced leadership
– Hire an experienced team
• Working environment
– Motivated stable teams
– Supportive management
– Team dynamics is critical
• Value thinking
• Effective and Efficient communication
• Information sharing
• Tools and Automation
51
School of Electronic Engineering and Computer Science EBU6304 : 02
Agile – suitable projects
• Small or medium-sized product.
• Requirement is not clear and/or keep changing.
• Rapid delivery.
• A clear commitment from the customer to become
involved in the development process
• Not a lot of external rules and regulations that affect the
software
52
School of Electronic Engineering and Computer Science EBU6304 : 02
Summary
• Classic Software Processes Models
– Waterfall
– Evolutionary development (Incremental)
– The Rational Unified Process
• Modern Software Processes
– Agile
53
School of Electronic Engineering and Computer Science EBU6304 : 02
References
• Chapter 3 – “Software Engineering” textbook by Ian
Sommerville
• Introduction to Agile by Sondra Ashmore
• http://en.wikipedia.org/wiki/Agile_software_development
• Chapter 2 – “Software Engineering” textbook by Ian
Sommerville
• Chapter 12 – “Head First Software Development textbook
by Dan Pilone et al
54
