Software Lifecycles

References
• MACIASZEK, L.A. and LIONG, B.L. (2005):
– Practical Software Engineering. A Case Study Approach, Chapter 1 (Software
Development Lifecycles)
– http://www.comp.mq.edu.au/books/pse/about_book/pdfpage.htm?Chapter%201=Ch1.pdf

• SOMMERVILLE, Ian
– Software Engineering 6th Edition (but also in 7th, 8th Edition), Chapter 3, pgs
42-55 (Software Processes)
• PFLEEGER, S.L.
– Software Engineering: Theory and Practice, Chapter 2, pgs 44-58,
(Modelling the process and lifecycles)

Software Engineering
• “Software engineering is the field of computer
science that deals with the building of software
systems that are so large or so complex that they
are built by a team or teams of engineers.” Ghezzi et
al.
• The job of a software engineer is to produce high
quality software products for practical uses
• Software engineering is about designing and
developing high quality software
 SE is more than programming
• Software engineering applies to complex problems that
cannot be solved by programming alone
– Complex systems must be designed before they can be
programmed
• Before a system can be designed, a software engineer must
understand its requirements
• Software engineer integrates components, programmers
code them
• Software engineering is a team activity
– Teams must be managed

Software Engineering
• Four things influence software quality:
– Stakeholders
– Product
– Process (The focus of this module)
– Language and Tools

Process
• Process: a series of steps to accomplish a set of
ordered tasks.
• Process quality and product quality are closely
related.
• A good process is usually required to produce a
good product.
 Process Elements
• The elements of a process:
– Use resources and produces intermediate and final
products
– May have sub-processes
– Prescribe all the major process activities
• Each activity has entry and exit criteria
• Activities are organised in a sequence
• Every activity has some goal to accomplish
• Constraints and controls may apply to an activity, resource, or
product

Process Process attributes

Description
characteristic
Understandability To what extent is the process explicitly defined and how easy is it t o
understand the process definition?
Visibility Do the process activities culminate in clear results so that the progress
of the process is externally visible?
Supportability To what extent can CASE tools be used to support the process
activities?
Acceptability Is t he defined process acceptable to and usable by the engineers
responsible for producing the software product?
Reliability Is the process designed in such a way that process errors are avoided or
trapped before they result in product errors?
Robustness Can the process continue in spite of unexpected problems?
Maintainability Can the process evolve to reflect changing organisational requirements
or identified process improvements?
Rapidity How fast can the process of delivering a system from a given
specification be completed?

Process classification
• Informal
– No detailed process model. Development team chose their own
way of working.
• Managed
– Defined process model which drives the development
process.
• Methodical
– Processes supported by some development method such as
the RUP.
• Supported
– Processes supported by automated CASE tools.
 Process choice
• Process used should depend on type of product which is
being developed
– For large systems, management is usually the principal problem
so you need a strictly managed process;
– For smaller systems, more informality is possible.
• There is no uniformly applicable process which should be
standardised within an organisation
– High costs may be incurred if you force an inappropriate
process on a development team;
– Inappropriate methods can also increase costs and lead to
reduced quality.

The software process

• A software development process determines activities and
organisational procedures to enhance collaboration in the
development team so that a quality product is delivered to the
customer
• A software process model is an abstract representation of a
process. It presents a description of a process from some
particular perspective.
• A software process is a structured set of activities required to
develop a software system.

What is included in a Software Process?

• Common activities:
– Requirements analysis and definition
– System design
– Program design
– Coding
– Unit testing
– Integration testing
– System testing
– System delivery
– Maintenance
 Definitions
• A System is a set of interrelated and interacting
component parts that, when combined, function to
achieve a predetermined goal
• A Model is a representation of the system that
serves to focus on the essential details while hiding
the non-essential ones

Definitions
• Analysis is resolution into simple elements
• Systems analysis is the process of analysing a
system with a view to modelling it and assessing the
feasibility of a computer solution
• Systems analysis concerns the problem space
– Involves interacting with the customer to work out what
needs to be done
– A complex activity
– The product of the systems analysis is a user requirement
specification and a software requirement specification

Definitions
• Design is the scheme of attack, or the adaptation of
means to ends
• Systems Design is the process of deciding how the
logical model is to be mapped onto the available
physical resources — the hardware and software
• System design concerns the solution space
– Decide how logical entities are to be represented and
manipulated
– Decide the time-ordering of activities
– The product of system design is a detailed specification of
modules and interactions
 Lifecycles
• Life cycle refers to a process that involves the
building of some product (software artefact)
• The software development process is called the
software development lifecycle

Waterfall lifecycle model

• The stages of software development are viewed as a
cascading waterfall from one to another
Requirements analysis

System design

Program design

Coding

Unit testing and integration

System testing

Acceptance testing

Operation and maintenance

Advantages of Waterfall model

• Provides milestones
– provides management with good basis for control
– The model gives the manager confidence in the progress
of the project
– there are clear stages through which the project proceeds
– there are clear milestones to assess progress
• Provides data for schedule planning
• Provides data for staff planning
• The process looks rational
 Drawbacks of Waterfall model
• No room for feedback
– Assume that the clients know everything
– Difficulty in client stating all requirements early
• Present a management framework, not suitable for software
development
– Doesn’t allow repetition
– Defined clear lines between stages
• Doesn’t allow change
– Some problems require an evolutionary approach
• Real projects rarely sequential — iteration required
• Working version of program not available until late in the life
cycle

Requirements Analysis
User
Waterfall
Systems Design
lifecycle with
feedback
Implementation

Integration and Deployment

Product

Operation and Maintenance

Waterfall model with prototyping

• Prototyping is a sub-process
• A prototype is a partially developed product
• To examine some aspects of the system
• To ensure the quality of the system

Analysis

Design
Prototyping
Coding

Prototyping
Testing

Integration
 User Requirements Analysis

Systems Design Prototyping

Implementation

Integration and Deployment Waterfall with

feedback,
Product
overlaps, and
prototypes
Operation and Maintenance

V Model
• Integrate testing activities into the waterfall
model
• Fold the waterfall model at the coding stage
• Explicit iteration and rework

V Model
Operation
Maintenance
Validate requirements
Requirement analysis Acceptance testing

Verify design
System design System testing

Verify program
Program design Unit & integration testing

Coding
 V model
• Validation refers to the set of activities that ensures
the software that has been built is traceable to
customer requirements
– “Are we building the right product?”
• Verification refers to the set of activities that ensure
that the software correctly implements a specific
function
– “Are we building the product right?”

Phased Development
• System requirements ALWAYS evolve in the course
of a project so process repetition where earlier
stages are reworked is always part of the process for
large systems.
• Phased development also known as iterative or
incremental development (this can be confusing
though)

Phased Development
• The time between when the requirements were
written and when the system was delivered is called
cycle time
• One way to reduce the cycle time is to use phased
development: system is delivered in pieces

Build Build Build

Release Release 2 Release3
1 developer
Time

Use Use
Release 1 Release 2
user
 Phased Development
• Rather than deliver the system as a single
delivery, the development and delivery is broken
down into releases with each release delivering
part of the required functionality.
• User requirements are prioritised and the highest
priority requirements are included in early
releases.
• Once the development of a release is started, the
requirements are frozen, though requirements for
later releases can continue to evolve.

Iterative Development
• Deliver a full system at the very beginning and
change the functionality of each sub-system with
each new release

Release 1 Release 2 Release 3

Incremental Development
• The releases are defined by beginning with a
functional sub-system and then adding functionality
with each new release

Release 1 Release 2 Release 3

 Phased development advantages
• Customer value can be delivered with each release
so system functionality is available earlier.
• Early releases act as a prototype to help elicit
requirements for later releases.
• Lower risk of overall project failure.
• The highest priority system services tend to receive
the most testing.

• Incorporate the practices of risk minimisation and

prototyping

Spiral
Model

Agile Software Development

• The agile software development process, proposed in 2001
by Agile Alliance – a non-profit organization of enthusiasts.
• In the Manifesto of Agile Alliance(2003), the spirit of the agile
development is captured in four recommendations:
– Individuals and interactions over processes and tools
– Working software over comprehensive documentation
– Customer collaboration over contract negotiation
– Responding to change over following a plan
• The agile development stresses that software production is a
creative activity that depends on people and team
collaboration far more than on processes, tools,
documentation, planning and other formalities.
 Agile Software Development
• “Conventional” requirements analysis is replaced in agile development by user
stories – features that the customer would like the system to support.
• “Conventional” system design and implementation are replaced in agile
development by a combination of acceptance tests, refactoring, and test-driven
development.
– test-driven development or intentional programming – the developer programs
his/her intent in an acceptance test before s/he implements it.
– frequent refactorings – improvements to the structure of the system without
changing its behavior.
• Agile development encourages other practices, such as pair programming and
collective ownership.
• “Conventional” integration and deployment is replaced in agile development by
continuous integration and short cycles.

Extreme programming
• An approach to development based on the
development and delivery of very small increments
of functionality.
• Relies on constant code improvement, user
involvement in the development team.
• Use pair programming, no individual allocation of
duties
• No hierarchy of authority
• No quarantining of activities
• Based on 13 practices done in small steps

13 XP practices
• whole team (no barriers between all stakeholders)
• metaphor (common language; “desktop metaphor”)
• the planning game (user stories)
• simple design
• small releases (two-week iterations)
• customer tests (acceptance tests)
• pair programming
• test-driven development (automated test first)
• design improvement (refactoring)
• collective code ownership
• continuous integration (builds many times per day)
• sustainable pace (no overtime)
• coding standards