Software Engineering
Chapter Two
Software Process
Learning Outcomes
Appreciate the need for a defined software process
Be able to describe in detail the main software process models
Be able to compare software process models and choose between them
Know about alternative approaches – agile and reengineering
Dr D. Greer, Queens University Belfast (Email:[email protected]
Chapter Two
1
The software process




Structured set of activities required e.g. Specification, Design,
Validation, Evolution
Activities vary depending on the organisation and the type of
system being developed
Must be explicitly modelled if it is to be managed
Process Characteristics
•
•
•
•
•
•
•
Understandability
Visibility
Supportability
Acceptability
Reliability
Maintainability
Rapidity
Dr D. Greer, Queens University Belfast (Email:[email protected]
Chapter Two
2
Generic vs Software engineering process

Generic – building any product
•
•
•
•
•
•

Specification - set out requirements and constraints
Design - Produce a paper model of the system
Manufacture - build the system
Test - check the system meets the required specifications
Install - deliver system to customer and ensure it is operational
Maintain - repair faults in the system as they are discovered
Software
•
•
•
•
Normally, specifications are incomplete / anomalous
Very blurred distinction between specification, design and manufacture
No physical realisation of the system for testing
Software does not wear out - maintenance does not mean component
replacement
Dr D. Greer, Queens University Belfast (Email:[email protected]
Chapter Two
3
Software process models

Waterfall model
•


Prototyping Models
Incremental Models
•
•
•

Specification and development are interleaved
The Spiral model
Agile Methods
Formal transformation
•

Separate and distinct phases of specification and development
A mathematical system model is formally transformed to an
implementation
Reuse-based development
•
The system is assembled from existing components
Dr D. Greer, Queens University Belfast (Email:[email protected]
Chapter Two
4
Waterfall model
Requirements
definition
System and
software design
Implementation
and unit testing
Integr ation and
system testing
Operation and
maintenance
Dr D. Greer, Queens University Belfast (Email:[email protected]
Chapter Two
5
Prototyping Model

Prototyping is used: 2 types
•
Evolutionary prototyping
»
•
Throw-away prototyping
»


Objective is to work with customers and to evolve a final system from an
initial outline specification. Should start with well-understood requirements
Objective is to understand the system requirements. Starts with poorly
understood requirements
Requirements are difficult to capture accurately!
Prototype - a working model of part or all of the final system
» Use of high-level languages to create working programs quickly. Modern
4GLs are very suitable
» Prototype may be inefficient/ not as robust as final system/ less functionality
Dr D. Greer, Queens University Belfast (Email:[email protected]
Chapter Two
6
Requirements
Gathering
Design
Design
Implementation
Implementation
Testing
Testing
Maintenance
Dr D. Greer, Queens University Belfast (Email:[email protected]
Chapter Two
7

Problems with Prototyping
•
•
•

Documentation may get neglected
Effort in building a prototype may be wasted
Difficult to plan and manage
Advantages
•
•
•
Faster than the waterfall model
High level of user involvement from start
Technical or other problems discovered early - risk reduced
Dr D. Greer, Queens University Belfast (Email:[email protected]
Chapter Two
8
Evolutionary Strategies




main purpose of software process model is “to give risk-reducing
structure” [Ould, 1990].
growing recognition that in many cases software should be
developed in an evolutionary fashion [e.g. McConnell, 1993]
e.g. Microsoft Visual C++ is shipped every 4 months
Strategies
•
•
•
•
Evolutionary Prototyping
Incremental (Staged) Delivery
Design-to-Schedule
Evolutionary Delivery
Ould, M.A., Strategies for Software Engineering: The Management of Risk and Quality, John Wiley, NY, 1990.
McConnell, S., Rapid Development: Taming Wild Software Schedules, Microsoft Press, Redmond, WA, 1996
Dr D. Greer, Queens University Belfast (Email:[email protected]
Chapter Two
9
Evolutionary Prototyping
Initial
Concept
Design
and
implement
initial
prototype
Refine
prototype
until
acceptable
Complete
and
release
prototype
final
product
Build prototype and evolve software from it
Prototype typically the user interface, but may be any high-risk
area of the system.
Evolutionary prototyping especially useful
when requirements are changing rapidly
when the customer is reluctant to commit to a set of requirements
when there is a lack of understanding of what is required [
when the developer is unsure of which technical solution to use.
Dr D. Greer, Queens University Belfast (Email:[email protected]
Chapter Two
10

Problems with Evolutionary Prototyping
•
•
•
•

Difficult to plan as amount of effort is uncertain
Documentation may be neglected
Could degenerate into “Build and Fix” with poorly structured code
Languages which are good for prototyping not always best for final
product
Advantages
•
•
•
•
Effort of prototype is not wasted
Faster than the waterfall model
High level of user involvement from start
Technical or other problems discovered early - risk reduced
Dr D. Greer, Queens University Belfast (Email:[email protected]
Chapter Two
11
Incremental (staged) Delivery
Differs from
Evolutionary Prototyping
in that
requirements are
fully known at the start
Software
concept
Requirements
Analysis
Architectural
Design
Stage 1: Detailed design, code, debug, test
and delivery
Stage 2: Detailed design, code, debug, test
and delivery
Stage n: Detailed design, code, debug, test
and delivery
Dr D. Greer, Queens University Belfast (Email:[email protected]
Chapter Two
12

Mechanism
•
•
•
•

requirements gathered in initial stages
overall architectural design is determined
requirements met in successive stages of the project
users get part of the functionality delivered at an early stage (As in
evolutionary prototyping)
Problems
•
•
•
•
Needs careful planning - stages have interdependencies
If not planned well - extra effort in interfacing stages
Users may tire of constant changes
funding may be difficult to obtain for a succession of changes
Dr D. Greer, Queens University Belfast (Email:[email protected]
Chapter Two
13
Design-to-Schedule
Software
concept
Note: Variation on
Incremental Model
Requirements
Analysis
Architectural
Design
n
High Priority: Detailed design, code, debug,
test
Medium-High Priority: Detailed design,
code, debug, test
Release
run out of time/money
Medium Priority: Detailed design, code,
debug, test
Medium-Low Priority: Detailed design,
code, debug, test
Low Priority: Detailed design, code, debug,
test
Dr D. Greer, Queens University Belfast (Email:[email protected]
Stages prioritised
lower priority
last. Thus if
deadline or budget
is reached before
product finished
lowest priority
stages
can be omitted.
Chapter Two
14
Incremental and Iterative Delivery

(Tom Gilb, 1988 – he called
it “evolutionary”/ “evo”)
Each stage is VALUABLE!
Stage 1: Detailed design, code,
debug, test and delivery
Software
concept
evaluate &
feedback
Requirements
Analysis
Architectural
Design
Stage 2: Detailed design, code,
debug, test and delivery
evaluate &
feedback
Stage n: Detailed design, code,
debug, test and delivery
evaluate &
feedback
Architecture at each
stage Must be OPEN = easy
to change and add to
Gilb, T., Principles of Software Engineering Management, Addison-Wesley, 1988
Dr D. Greer, Queens University Belfast (Email:[email protected]
Chapter Two
15
Incremental and Iterative Delivery
CHANGE
Initial course
Initial
Objectives
New
Objectives
Revised
course
Dr D. Greer, Queens University Belfast (Email:[email protected]
Chapter Two
16
Agile Methods
http://agilemanifesto.org/
and
http://www.martinfowler.com/articles/newMethodology.html
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Candidates: XP (Extreme Programming), Cockburn's Crystal Family, Open Source,
Highsmith's Adaptive Software Development, Scrum, Feature Driven
Development, DSDM (Dynamic System Development Method)
Dr D. Greer, Queens University Belfast (Email:[email protected]
Chapter Two
17
What is Extreme Programming

Things we know from Software Engineering:
Software Eng. Practice
XP Principles
Code Reviews are good
Review code all the time
Testing is good
Everybody tests all the time
Design is good
Part of daily business
Simplicity is good
Always have the simplest
design that does the job
Architecture is important
Everybody works in refining
architecture
Integration Testing is
important
Continuously integrate and
test
Short Iterations are good
Make iterations really short
Dr D. Greer, Queens University Belfast (Email:[email protected]
Pair Programming
Unit and functional tests
Refactorin g
Simplest Design that
works
Use of a metaphor
Continuous Integration
The Planning Game
Chapter Two
18
What is XP?

A lightweight, efficient, low-risk, flexible,predictable, scientific
and fun way to develop software (Kent Beck)
‘lightweight’ being replaced by the term ‘agile’

4 Values

•
Communication
» Unit testing, pair programming, task estimation done with > 1 person
•
Simplicity
» XP coach asks “What is the simplest thing that could possibly work?”
•
Feedback
» Each task feeds back to the instigator, early deliverables
•
Courage
» E.g. Throwing code away, refactoring, trying out new ideas
Dr D. Greer, Queens University Belfast (Email:[email protected]
Chapter Two
19
XP – Overview of the 12 Practices

The Planning Game
•
•

Small Releases
•

Sensible but reduce cycle as much as possible
Metaphor
•

Business People: Scope, Priority, Composition of releases, Dates of
releases
Technical People: Estimates, Consequences of choices, Process, Detailed
Scheduling
Similar to ‘architecture ‘ but for non-technical too e.g see system as
contracts and customers
Simple Design
•
Runs all the tests, No duplicated logic, all the required bits, fewest
classes and methods
Dr D. Greer, Queens University Belfast (Email:[email protected]
Chapter Two
20

Collective Ownership
•

Continuous Integration
•
•

max
On site customer
•

Code integrated and tested after a few hours-1 day
Run the tests until they work
40 hour week
•

Everyone owns and can improve the code
(real) customer sits with team
Coding Standards
•
•
Same indentation, layout etc
Least amount of work possible
Dr D. Greer, Queens University Belfast (Email:[email protected]
Chapter Two
21

Testing
•
•
•

Pair Programming
•

Tests are written before the code
Test run (automated) frequently (after all changes)
Customers provide acceptance tests
One person has keyboard, other checks and suggests
Refactoring
•
XP teams improve the software throughout development process
Dr D. Greer, Queens University Belfast (Email:[email protected]
Chapter Two
22
Software Reengineering


What? - Re-structuring or re-writing part or all of a legacy system without
changing its functionality
When?
•
•

How?
•

When some but not all sub-systems of a larger system require frequent
maintenance
When hardware or software support becomes obsolete
The system may be re-structured and re-documented to make it easier to maintain
Why
•
Reduced risk
» New software development carries high risk.
•
Reduced cost
» The cost of re-engineering is often significantly less than the costs of developing new
software
Dr D. Greer, Queens University Belfast (Email:[email protected]
Chapter Two
23
Forward engineering and re-engineering
System
specification
Design and
implementation
Ne w
system
Understanding and
transformation
Re-engineered
system
Forward engineering
Existing
software system
Software re-engineering
Automated program conversion
Automated program restructuring
Manual Program and Data Restructuring
Restructuring plus Architectural Changes
Dr D. Greer, Queens University Belfast (Email:[email protected]
cost
Chapter Two
24
Reverse engineering





Analysing software to gain an understanding of its design and specification
May be part of a re-engineering process or to re-specify a system for reimplementation
Builds a program data base and generates information from this
Program understanding tools (browsers, cross-reference generators, etc.) may
be used in this process
Why?
•
•
•
Original code may have been written under limitations which no longer apply e.g.
memory needs, performance etc
Maintenance tends to corrupt the structure of a program. It becomes harder and
harder to understand
The program may be automatically restructured to remove unconditional
branches or complex conditional statements
Dr D. Greer, Queens University Belfast (Email:[email protected]
Chapter Two
25
Software Engineering
Chapter Two
Software Process
Learning Outcomes
Appreciate the need for a defined software process
Be able to describe in detail the main software process models
Be able to compare software process models and choose between them
Know about alternative approaches – agile and reengineering
Dr D. Greer, Queens University Belfast (Email:[email protected]
Chapter Two
26