COS 315

1
COS 315 SOFTWARE ENGINEERING 2. Process
Models The phases of software development
2
Conventional Software Development! - Not
Recommended!
3
Software engineering has been recognized as an
engineering discipline with the same status as
mechanical, electrical engineering, etc. It is
still a relatively young discipline compared to
mechanical, civil, electrical, engineering.
The software development process is not
standardized - computer scientists are still
devising newer and better software development
processes. Many software projects are
one-off projects
4
A Layered Technology
The software engineering umbrella
Software Engineering
Software Engineering
tools
methods
process model
a quality focus
5
What makes software engineering projects
different from other engineering
projects? Answer The Software Process - How we
describe the process of building some software
the phases or set of steps or stages
involved. The software process is - the
structured set of activities (or phases) required
to develop a software system Specification
Inception Elaboration Design
Analysis Validation Design Evolution
Development/Implementation Test
Deployment Maintenance
6
Testing Phase?

• Testing is actually an activity that should be
  performed throughout the software production
• E.g. during the analysis phase, software
  engineers may determine if product to be built is
  the right one in terms of user requirements.
• Verification
• Asks question Are we building product right?
• Validation
• Ask question Are we building the right product

7

• Every phase should be fully documented before
  starting the next phase.
• Why?
• Postponed documentation may never be completed
• The person responsible may leave
• The product is constantly changing - we need the
  documentation to make these changes
• The design (for example) will be probably be
  modified during development, but the original
  designers may not be available to ask, so the
  original design must be documented.

8
A Common Process Framework
Common process framework Framework
activities - Work tasks - Work products -
Milestones deliverables - QA checkpoints Ancil
lary Activities
9
Umbrella Activities

• Various activities
• Project tracking, formal reviews
• Quality assurance
• Configuration management
• Documentation
• Reusability management
• Measurement / testing
• Risk management

10
Why is Process Important in Software Development?

• Allows division of labour
• easier for each team member to know what to do

• Promotes teamwork/individual work/communication
• understand what others are doing (over time,
  among projects, etc.)
• Eases project management
• supervisors/managers can understand what is
  happening
• Allows expertise reuse/reassignment
• transfer among projects more easily
  (developers, managers, etc.)
• Eases training
• can be standardized (E.g. courses)
• Promotes productivity/better development
• development becomes repeatable (E.g.
  schedule/cost estimates)

11
Software Development Process
A Management View
An Engineering View

• Definition phase ? focus is on WHAT
• project planning
• requirements gathering
• analysis
• Development phase ? ?focus is on HOW
• design testing
• coding deployment
• Maintenance phase ? focus is on CHANGE
• bug fixes adaptation
• enhancements
• Plus ? deliverables, reviews, change control, . .
  .

• Methods (activities)
• provide technical know how for building
  software
• Methodology (workflow)
• sequence in which methods will be applied
• deliverables required
• controls needed to ensure quality and coordinate
  change
• milestones to assess progress
• Tools (support)
• provide automated or semi-automated support for
  methods

12
The step-by-step breakdown of the software
development process into a set of activities is
known as - the Software Lifecycle Essentially,
the software lifecycle is a management and
technical concept for - organizing -
planning - scheduling and - controlling the
activities of the software development and
maintenance effort.
13

• A software process model is an abstract
  representation
• of the software process.
• It presents a description of the software
  process from some particular perspective.
• It is a model used to explain and help us
  understand a software development and maintenance
  process
• Many models have been proposed to deal with the
  problems of defining software development
  activities and associating them with each other

14
Models
15

• Some common software development models are
• - Build-and-fix model
• - Waterfall model
• - Rapid Prototyping model
• - Incremental model
• - Spiral model

There are lots of others! We will examine some
of these.
16
Software Lifecycle The general lifecycle phases
are Inception Elaboration Analysis
Design Development/Implementation Test
Deployment Maintenance Look at each one in
turn.
17
Inception and Elaboration - Possible
Activities First phase in the software
lifecycle General requirements for the
software are first collected - form problem
statement Proposal put forward Market
research done Business case put forward -
Cost and benefit analysis performed Pilot
project to test feasibility, technology -
prototype
This phase is essentially a feasibility study
18
Initial project plan devised - Time and
costs of entire development gtgt
Investigation gtgt Development gtgt Test gtgt
Anything else - Risks may be assessed Result ?
feasibility report ? Go or No Go decision
19
Analysis - Possible Activities Concerned with
WHAT? Analysis - concerned with thoroughly
understanding and modeling the application.
Initial input is the problem statement which
describes the problem and provides a conceptual
overview. Output is a description that captures
the essential aspects of the system from a number
of different viewpoints (models) often called
the specification Full requirements are
gathered from users - may only be from a
representative portion of users Note Nowadays
the process of gathering requirements and their
analysis is also called requirements analysis or
requirements engineering. (Combined with first
phase)
20
Two general forms of requirements 1.
Functional E.g. the system will allow a user to
search for a product online 2. Non-functional
(Constraints) E.g. the system will handle at
least 1 million search hits per day
Requirements can be expressed in written form or
using some other notation (e.g. UML Use Case
diagrams) Scenarios (UML) can be used to help
elaborate requirements This phase most often
not done properly - with consequent problems and
costs!
21
Importance of gathering requirements -
Everyone should know what is going to be
built gtgt Users especially should sign-off on
the requirements - Testing can be done to
verify that the product will do what it is
supposed to Other tasks during analysis -
Object model (UML) determined gtgt This relates
to the entities in the system (also any
database) Technical Architecture may also be
determined during this phase - What
infrastructure will be used (Web-based interface,
programming language, database, etc.)
22
The steps in Requirements Engineering
23
Design - Possible Activities Concerned with
HOW? Design - analysis models are elaborated,
refined and then optimized to produce a practical
design. Emphasis is more on practicalities. Basic
algorithms are chosen to implement each major
function of the system, and data structures are
optimized for efficient implementation. More
detailed workings of all of the objects in the
system Determine the way this will work using
the chosen programming tools and
infrastructure Determine User Interface (UI)
design - Prototype the User Interface - Show
users
24
Detailed specifications are produced of the
design based on the analysis specifications -
UML may be used again Other aspects may be
agreed at this time (e.g. coding standards)
25
(No Transcript)
26
Development - Possible Activities Implementation
- algorithms and data structures are translated
into a programming language. Developers start
writing code to implement design Testers write
tests to verify functionality of code - For
functional correctness (does it do what it is
supposed to?) - For robustness and
reliability - For scale and performance
Developers may use source code control (SCC)
system to keep different source code versions
27
Software may be built using a build system
(E.g. Unix make) - Perhaps run every night -
Builds are tested automatically - Builds can
then be used by people for various purposes
Metrics gathered to measure progress against plan
28
Test - Possible Activities Testing - the
resultant software is thoroughly tested to make
sure it conforms to the specification.
Different types of tests - Unit tests gtgt Test
the code - Black box or White box -
Functional tests - Build tests - Stress
tests Mostly automated
29
Bugs are recorded in a bug tracking system
(e.g. Bugzilla) - Allows everyone to see status
of bugs Developers fix bugs - Hopefully
without causing more Early releases given to
users - Dogfood software in-house users. -
alpha, beta versions of software customers.
30
(No Transcript)
31
Bug fixing
32
Deployment - Possible Activities Final goal
RTM (Release To Manufacturing) Internally,
software can be rolled out Deployment needs
to be planned Deployment software critical -
Installers Integration Upgrades
Side-by-side installation old with new
33
Users need training Business process may
need to be altered at the same time
34
Maintenance - Possible Activities New
requirements - Design Change Requests (DCRs) -
Unimplemented features New bugs found -
Report back to developers to fix How do you
release updates? - Service Packs - Hot fixes -
Version upgrades Where the design really gets
tested!
35
Software Lifecycle Activities with UML
36
Software Process Models

• Models - strategies encompassing process,
  methods, tools and generic steps
• Cycle - from status quo, to new problem
  definition, to new technical development, to
  solution integration

37
The Process Model Adaptability

• The process framework activities will always be
  applied on every project, but
• The tasks (and degree of rigour) for each
  activity will vary based on
• the type of project
• characteristics of the project
• commonsense judgment concurrence of the project
  team

38
Some Models
39
Build-and-Fix Model

• Product constructed without specifications or
  design!!
• Works for 100 lines or less programs.
• Total cost far greater than expected.

40
Build-and-Fix Model
41
Build-and-Fix Model

• Process write code, fix errors, enhance
  functionality

• Many changes ? code structure becomes messy, hard
  to fix
• Not suitable for large system development because
• turnover of personnel
• difficult to fix code
• user requirements can easily be unmatched
• Development becomes
• unpredictable
• uncontrollable
• over schedule, over budget, low quality
• A more rigorous software development process
  needed!

42
Instead of this model, an overall plan must be
chosen, giving rise to a lifecycle model -
phases, milestones, documentation, Real
lifecycle models will be described next
43
The Linear Model

• Steps
• System engineering - software usually only part
  of a larger system - first establish requirements
  for all system elements
• Requirements analysis - focus on the software
  must do
• Design - design a software structure based on
  analysis
• Code generation
• Testing
• Maintenance

44
Linear Model

• Challenges
• Real projects rarely follow a sequential flow and
  any requirement changes may cause confusion.
• Difficult for customer to state all requirements
  explicitly at beginning of development. Model
  does not allow for this!
• Customer must have patience - no working model
  until late in project time span.
• Developers sometimes delayed unnecessarily - they
  are held up or blocked waiting for other team
  members to complete some dependent task.

45
Waterfall Model Extension of Linear Model -
allows feedback to earlier phases, i.e. problems
identified in later stages may be returned to
appropriate earlier stage for fixing. Again
separate and distinct phases of specification and
development. Previous phase documentation feeds
into successive phase - assumes previous phase is
frozen. Because of the allowance of
feedback, process is sequence of iterations of
development activities. The Traditional
Lifecycle Model
46
Waterfall Model
Information flows from one stage to next
Feedback or changes
47
Waterfall Model
produces a requirements specification document
Analysis
produces a design specification document
Design
produces an implementedcollection of modules
Coding
produces a testedassembly of modules
Testing
Maintenance
keeps the system working and up-to-date

• Plus reviews (correctness, standards),
  deliverables (documentation, code), training
  materials, . . .

48
Waterfall model problems The drawback of the
waterfall model is the difficulty of
accommodating change after the process is
underway. Inflexible partitioning of the
project into distinct stages - This makes it
difficult to respond to changing customer
requirements - Therefore, this model is only
appropriate when the requirements are
well-understood Traditionally done because it
allows the separation of tasks with different
people (analysts, designers, programmers, testers)
49
(No Transcript)
50
Real Waterfall Model
Financial penalties if problems are discovered
late in the lifecycle
51
Iterative Models
Prototyping
RAD
Next two models are iterative models - iterate
to final system.
52
Prototyping Model

• Steps
• Listen to customers known requirements
• Build prototype - quick design
• Customer test drives prototype and provides
  feedback to developers
• Challenges
• Throw-away phenomenon - prototype should be
  discarded, and the next version engineered more
  robustly.
• Prototypes can set unrealistic expectations for
  customer
• Compromises that solidify into integral part of
  the final system.

53
Prototyping
1
2
3
Designed to assist customer and developer
understand requirements.
54
Prototyping activities
55
Prototyping
56
Prototyping in the software process

• Throw-away prototyping
• A prototype, which is usually a practical
  implementation of the system, is produced to help
  discover requirements problems and then
  discarded. The system is then developed using
  some other development process
• The objective of throw-away prototyping is to
  validate or derive the system requirements. The
  prototyping process starts with those
  requirements which are poorly understood.
• Evolutionary prototyping
• An approach to system development where an
  initial prototype is produced and refined through
  a number of stages to the final system
• The objective of evolutionary prototyping is to
  deliver a working system to end-users. The
  development starts with those requirements which
  are best understood.

57
RAD Model

• Rapid Application Development
• High-speed adaptation of linear sequential, with
  short cycle (60-90 days) using component-based
  construction.
• Steps
• Business modeling
• Data modeling
• Process modeling
• Application generation
• Testing and turnover

To achieve such a short development cycle, each
major software function can be addressed by
separate RAD team and then integrated to form a
whole.
58
RAD
59
RAD Model

• Challenges
• For large projects, sufficient human resources
  are needed for rapid development cycle
• Strong commitment from developers and customers
  to complete development in short time period.
• Presupposes modular solution use of software
  components
• Reusability sometimes implies loss of performance

60
Features of the Iterative Approach Continuous
integration - Not done in one lump near the
delivery date Frequent, executable
releases - Some internal some delivered
Attack risks through demonstrable progress -
Progress measured in products, not documentation,
or engineering estimates
61
Risk Profile of Development
62
Evolutionary Models
Software, like other complex systems, evolves
over time E.g. changing requirements Next few
models try to capture the need to deal with this
evolutionary nature - iterative models that
allow developer to produce increasingly more
complete versions of the software.
63
version 1
lessons learnt
version 2
lessons learnt
version 3
design
code
test
integrate
reqts
Evolutionary development (each new version
incorporates new requirements)
64
The Incremental Model

• Linear (sequential) model (applied repetitively),
  but combined with iterative philosophy of
  prototyping
• Linear sequence applied in a staggered fashion
  over time.
• Core product (first increment includes basic
  requirements) with incremental enhancements over
  time.
• Each increment operational with extra
  functionality
• User supplies feedback about each increment
• Useful when human/machine resources are limited

65
The Incremental Model
66
The Spiral Model

• Iterative prototyping, with set of framework
  activities or regions within each loop of the
  spiral
• Each circuit or loop around the spiral addresses
  certain lifecycle activities
• First circuit around spiral specification
• Second circuit prototype
• Third circuit product release
• Includes development and maintenance

Spiral with 4 regions
?
67
An Evolutionary (Spiral) Model
?
Spiral with 6 regions
68
?
A simplified spiral model approach - 3 regions
with lifecycle activities for each loop
69
?
All-singing, all-dancing spiral model
70
Spiral development

• Software development process is represented as a
  spiral rather than as a sequence of activities
  with backtracking.
• Each loop in the spiral represents a phase in the
  process.
• Risks are explicitly assessed and resolved
  throughout the process

71
The Spiral Model

• Challenges
• Hard to show controllability(size and timing of
  each circuit)
• Risk assessment is fundamental
• Model relatively new (less experience)

A Key Point of the Spiral Model

• If all risks cannot be resolved, the project is
  immediately terminated

72
Full Spiral Model

• Precede each phase by
• Alternatives
• Risk analysis
• Follow each phase by
• Evaluation
• Planning of next phase
• Radial dimension cumulative cost to date
• Angular dimension progress through the process

73
Spiral model sectors

• 1. Objective setting
• Specific objectives for the phase are identified
• 2. Risk assessment and reduction
• Risks are assessed and activities put in place to
  reduce the key risks. Key distinction of this
  model - explicit consideration of risk.
• 3. Development and validation
• A development model for the system is chosen
  which can be any of the generic models
• 4. Planning
• The project is reviewed and the next phase of the
  spiral is planned

74
Variation - WINWIN Spiral

• A variation of the standard Spiral Model
• Identify key stakeholders, e.g. customer, users
• Determine stakeholders win conditions
• Negotiation phase at start of each cycle
  determines what will satisfy the majority of the
  stakeholders requirements balanced with the
  developers requirements to keep project within
  time and cost budgets.
• Reconcile win conditions into a set of win-win
  conditions for the whole project
• Win for stakeholders and win for developers

75
?
WINWIN Spiral model
76
Variation - Component Assembly Model

• Spiral Model, plus object-oriented reusability
  (component-based)
• Challenges
• Reusability requires careful planning
• Most existing programs are not reusable
• More suitable for particular application
  domains(with significant patterns of reuse)

77
?
78
Extreme programming - XP New 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 and pairwise
programming Two crucial design heuristics -
never duplicate code - use simplest design
possible Continuous Testing - write the tests
before you design the code
79
Extreme Programming
Part of what is called Agile Development

• Somewhat controversial new approach - based on
  incremental model
• Stories - features that client wants in software.
• Estimate duration and cost of each story
• Client selects stories for next build
• Each build is divided into tasks
• Test cases for a task are drawn up first
• Pair programming on one/few task(s) in parallel.
• Continuous integration of tasks with current
  version of product.

80
Unusual Features of XP

• Computers are put in the center of a large room
  lined with cubicles - egoless environment
• A client representative is always present
• No individual allowed to work overtime for two
  successive weeks
• No specialization of tasks - everyone does
  everything
• Design modified as product is built - called
  refactoring

http//www.extremeprogramming.org/rules.html has
short, simple explanations.
81
(No Transcript)
82
Documentation XP does support documentation of
all phases! We're Extreme, not stupid! We
document what needs documenting, in the most
effective form we can find. http//c2.com/cgi/wi
ki?ExtremeDocuments http//c2.com/cgi/wiki?XpHasW
rittenDocuments
83
(No Transcript)
84
(No Transcript)
85
(No Transcript)
86
Unified Software Development Process (UP)
Selects from best practices to

• Provide a generic process framework
• instantiate/specialize for specific application
  areas, organizations, project sizes, etc.
• Define a set of activities (workflows)
• transforms users requirements into a software
  system
• Define a set of models
• from abstract (user-level) to concrete (code)
• Allow component-based development
• software components interconnected via
  well-defined interfaces

• use-case (UML) and risk driven
• architecture-centric
• iterative and incremental

87
Unified Process - Milestones
Milestone a management decision point in a
project that determines whether to authorize
movement to the next iteration/phase
Inception phase - agreement among
customers/developers on the systems life cycle
objectives Elaboration phase - agreement on the
viability of the life cycle architecture,
business case and project plan Construction phase
- agreement on the acceptability of the software
product both operationally and in terms of
cost Transition phase - final agreement on the
acceptability of the software product
88
What is RUP?

• Acronym for Rational Unified Process
• Commercial product of Rational Software (now
  owned by IBM) of UP i.e. UML modelling
• RUP describes a complete software development
  lifecycle for a variety of types of projects
• Knowledge is encapsulated within a web site
• Provides templates, instructions, how-to guides,
  ...

Also helps to sell their software product -
Rational Rose
89
Rational Unified Process (RUP)
90

• RUP is an excellent example of a formal,
  controlled development methodology
• Demonstrates how different types of projects can
  emphasize different processes
• Most methodologies (proprietary or not) contain
  elements inspired by RUP

91
Synchronize and Stabilize Model

• Microsofts lifecycle model
• Requirements analysis - interview potential
  customers
• Draw up specifications
• Divide project into 3 or 4 builds
• Each build is carried out by small teams working
  in parallel.
• At the end of the day - synchronize (test and
  debug)
• At the end of the build - stabilize (freeze
  build)
• Components of build always work together
• ? Get early insights into the operation of the
  product

92
Microsoft model - successful for very large
projects - More than 3000 developers and
testers worked on Windows 2000 Small parallel
teams of 3-8 developers and 3-8
testers Individuals allowed latitude to design
and implement a specification but - Code must
be integrated on a daily basis - If your code
prevents compilation, then it must be fixed
immediately But Microsoft is more than
Synchronize and Stabilize. - Their success is
based on a strong corporate culture
93
Introduction To Agile Processes Heavy-weight
Processes E.g. USDP (RUP) Up-front Analysis
Design documentation Strict phases Large
teams, long iteration cycles, long release
times Feature intensive Light-weight
Processes E.g. XP No up-front Analysis
Design documentation Test-first coding
Small teams, short iteration cycles, short
release times Change intensive
94
Waterfall Iterative XP
95
Questions?
96
Reading Bruegge and Dutoit Chapter 1
Introduction to Software Engineering Chapter 15
Software Life Cycle Pressman Chapter 2 -
The Process