Chapter 2

Software Processes & Models

Tadele M.
 Contents
 Software Processes
 Software Life Cycle and Process Models
 Code-and-fix
 Water fall model
 Spiral model
 Incremental development model
 Evolutionary development model
 Formal systems development
 Reus-oriented development
 Automated process support (CASE)

2
 Software Process
 Process is particular course of action intended to achieve a
result.
 Software Process [ software development life cycle (SDLC)] is
structured set of activities required to develop a software
system.
 Requirement Specification - what the system should do and its
development constraints
 Development (design and implementation (Coding)) - production of the
software system
 Testing (Validation) - checking that the software is what the customer
wants
 Maintenance (Evolution) - changing the software in response to changing
demands
3
 Software life cycle
 The time from the initial idea for a product until it is delivered
is the development life cycle.
 When the product is delivered, its real life begins.
 The product is in use or deployed until it is disposed of.
 The time from the initial idea for a product until it is disposed
of is called the product life cycle, or software life cycle, if
we focus on software products.
 Everything we do in software life seems to follow a few common
steps, namely:
 Requirements engineering, designing, coding, testing,
evolution.
4
 Software process models
 Software development projects are large and complex
 A phased approach to control it is necessary
 Software process model is an abstract description of the sequence
of activities carried out in a software engineering project, and
the relative order of these activities.
 One of the goals of software engineering is to provide models
and processes that lead to the production of well-documented
maintainable software in a manner that is predictable.
 There are hundreds of different process models
 They are usually grouped according to one of the following
concepts: Sequential, Iterative and Incremental models.

5
 Software process models...
 Examples of software process models
 The waterfall process model
 Code-and-Fix process model
 Spiral process Model
 Incremental development process model
 Evolutionary development process model
 Formal Transformation process model
 Reuse-based development process model
 Rational Unified Process model(RUP)
 Time Boxing (Reading Assignment)
 Rapid Application Development(RAD)
 Extreme programming (Reading Assignment)
 V-Model, W-Model etc

6
 Waterfall model
 Linear sequence of phases/stages
 Requirements – Resign-Code – Test – Deploy
 The following phase should not start until the previous
phase has finished: no/little feedback
 This model is only appropriate when the requirements are
well-understood,very well documented, and fixed.
Advantage Disadvantage
• Simple and easy to understand and • No working software is produced until
use late during the life cycle.
•Easy to manage due to the rigidity •Cannot accommodate changing
of the model requirements.
•Works well for smaller projects •Developers may have to wait due
to dependent tasks
7
Waterfall model…

Representation of the different phases of the Waterfall Model.

 Code-and-Fix process model
 Immediately start developing, fixing problems as they occur,
until the project is complete.
 It starts with little or no initial planning.
Advantage Disadvantage
•No administrative overhead •No visibility/control
•Signs of progress (code) early. •No resource planning
•Low expertise, anyone can use it! •No deadlines
•Useful for small projects. •Mistakes hard to
detect/correct
•Impossible for large projects: communication breakdown & Chaos

9
 Spiral process Model
 Extends waterfall model by adding iteration to explore/manage
risk.
 Important software projects have failed because project risks
were neglected & nobody was prepared when something
unforeseen happened.
 Barry Boehm recognized this and tired to incorporate the “project risk”
factor into a life cycle model.
 A spiral model is divided into a number of framework activities,
also called task regions. Typically, there are between 3-6 task
regions.
 Delivers the software in a series of incremental releases
 When risks are high and need to be resolved, it is reasonable to
use this approach

10
 Spiral process Model…

11
 Advantages (of Spiral Model) Disadvantages(of Spiral Model)
• Realism: the model accurately • Needs technical
reflects the iterative nature of expertise in risk
software development on projects analysis and risk
with unclear requirements. management to work
• Flexible: incorporates the advantages well.
of the waterfall and evolutionary • Model is poorly
methods. understood by non
• Comprehensive model to decreases technical management,
risk. hence not so widely
• Good project visibility. used.
• On each iteration, plans, costs, • Complicated model,
risks and schedules updated and needs competent
project manager get more accurate professional
estimate of number of required management.
iterations • High administrative
overhead.
12
 Incremental development model
 Rather than deliver the system as a single delivery, the development and
delivery is broken down into increments with each increment
delivering part of the required functionality.
 User requirements are prioritised and the highest priority requirements
are included in early increments.
 Once the development of an increment is started, the requirements are
frozen though requirements for later increments can continue to
evolve.

13
 Incremental development model...
Advantages Disadvantages
• Customer value can be delivered with • Increments may
each increment so system functionality be difficult to
is available earlier. define
• Client does not have to pay for entire • Software may
software together.
be difficult to
• Early increments act as a prototype to
help elicit requirements for later maintain
increments
• Lower risk of overall project failure.
• The highest priority system services
tend to receive the most testing.
When the “core” product is well understood and increments can be easily
defined, it is reasonable to use this approach.
14
 Evolutionary development model
 A combination of Iterative and Incremental models.
 Evolutionary development is based on the idea of
 developing an initially implementation,
 exposing this to user comment and
 refining this through many versions until an adequate system is developed.
 When requirements are not well understood, it may be reasonable to
use this approach.

15
 Evolutionary development model
 There are two types of evolutionary development
 Exploratory development
- Objective is to work with customers and to evolve a final system from an
initial outline specification.
- Should start with relatively well-understood requirements.
- The system evolves by adding new features as they are proposed by
customer.
 Throw-away prototyping
 Objective is to understand the system requirements. Should start with
poorly understood requirements, Develop “quick and dirty” system
quickly, Expose to user comment and refine until adequate system is
developed.
 Particularly suitable where detailed requirements not possible.
16
 Advantages (of evolutionary model) Disadvantages(of evolutionary model)

• The resulting system is easier • Lack of process visibility

to use • Systems are often poorly
• User needs are better structured
accommodated • Special skills (e.g. in
• Problems are detected earlier languages for rapid
• The design is of higher prototyping) may be
quality required
• The development incurs less
effort
Applicability,
• Use prototyping when the requirements are unclear.
• For small or medium-size interactive systems
• For parts of large systems (e.g. the user interface)
• For short-lifetime systems

17
 Rational Unified Process Model (RUP)
 The RUP is an iterative software development process
framework created by the Rational Software Corporation
 Is not a single concrete prescriptive process
 Is an adaptable process framework, intended to be tailored by the
development organizations and software project teams that will select
the elements of the process that are appropriate for their needs.
 RUP Process Made Practical
 Sustained development of quality software
 Delivered on-time and on-budget
 Requires more than “heroic” individuals
 Cohesive teamwork & common understanding of development tasks
 Ensures implementation is predictable and repeatable

18
 RUP – disciplines/workflows, Phases and Iterations
 There is total of five phases of the life cycle of RUP:

19
 Formal systems development
 Based on the transformation of a mathematical specification
through different representations to an executable program.
 Transformations are ‘correctness-preserving’ so it is
straightforward to show that the program conforms to its
specification.
 Embodied in the ‘Clean room’ approach to software
development

Requirements Formal Formal Integration and

definition specification transformation system testing

20
 Formal systems development...
 Problems
 Need for specialised skills and training to apply the technique
 Difficult to formally specify some aspects of the system such as
the user interface.
 Advantage
 The resulting software will have high quality
 Applicability
 Critical systems especially those where a safety or security case
must be made before the system is put into operation

21
 Reuse-oriented development
 Based on systematic reuse where systems are integrated
from existing components or COTS systems
 Process stages
 Component analysis
 Requirements modification
 System design with reuse
 Development and integration
 System Validation
 This approach is becoming more important but still there is
limited experience with it

22
 Automated process support (CASE)
 Computer-aided software engineering (CASE) is software to support
software development and evolution processes
 CASE examples: Graphical editors for system model development, Data
dictionary to manage design entities, GUI builder for user interface construction,
Debuggers to support program fault finding, Automated translators to generate
new versions of a program
 Case technology has led to significant improvements in the software
process though not the order of magnitude improvements that were
once predicted.
 Software engineering requires creative thought - this is not readily
automatable
 Software engineering is a team activity and, for large projects, much time
is spent in team interactions. CASE technology does not really support
these

23
 CASE classification
 Classification helps us understand the different types of CASE
tools and their support for process activities
 Functional perspective:
 Tools are classified according to their specific function
 Process perspective
 Tools are classified according to process activities that are supported
 Integration perspective
 Tools are classified according to their organisation into integrated units

 CASE Tools can also be classified into two

 Upper-CASE: Tools to support the early process activities of
requirements and design
 Lower-CASE: Tools to support later activities such as programming,
debugging and testing

24
 Functional tool classification
Tool type Examples
Planning tools PERT tools, estimation tools,
spreadsheets
Editing tools Text editors, diagram editors, word
processors
Change management tools Requirements traceability tools, change
control systems
Configuration management tools Version management systems, system
building tools
Prototyping tools Very high-level languages,
user interface generators
Method-support tools Design editors, data dictionaries, code
generators
Language-processing tools Compilers, interpreters
Program analysis tools Cross reference generators, static
analysers, dynamic analysers
Testing tools Test data generators, file comparators
Debugging tools Interactive debugging systems
Documentation tools Page layout programs, image editors
Re-engineering tools Cross-reference systems, program re-
structuring systems

25
 Process Activity-based classification
Reengineering tools

Testing tools

Debugging tools

Program analysis tools

Language-processing
tools

Method support tools

Prototyping tools

Configuration
management tools

Change management tools

Documentation tools

Editing tools

Planning tools

Specification Design Implementation Verification

and
26 Validation
 CASE integration
 Tools
 Support individual process tasks such as design consistency
checking, text editing, etc.
 Workbenches
 Support a process phase such as specification or design
 Environments
 Support all or a substantial part of an entire software process.
 Normally include several integrated workbenches

27 Software Engineering Fundamentals

 Tools, workbenches, environments
CASE
technology

Tools Workbenches Environments

File Integrated Process-centred

Editors Compilers
comparators environments environments

Analysis and
Programming Testing
design

Multi-method Single-method General-purpose Language-specific

workbenches workbenches workbenches workbenches

28 Software Engineering Fundamentals