SE-200 SOFTWARE

ENGINEERING
Software Process Models - 1

Instructor: Asst Prof Mobeena Shahzad

BESE 28 (A,B,C)

1
The Software Process
■ A structured set of activities required to develop a software system.

■ Many different software process models but all involve:

– Specification – defining what the system should do;
– Design and implementation – defining the organization of the system and
implementing the system;
– Validation – checking that it does what the customer wants
– Evolution – changing the system in response to changing customer needs.

■ A software process model is an abstract representation of a process. It presents

a description of a process from some particular perspective.
2
Variety of Software Processes
■ Software products are very varied...
■ Therefore, there is no standard process for all software
engineering projects

■ BUT successful software development projects all need

to address similar issues.

■ This creates a number of process steps that should be

part of all software projects.

3
What is a Software Process Model?

A simplified representation of a software process, presented

from a specific perspective

Workflow Perspective  sequence of activities

Examples of process Data flow Perspective  information flow
perspectives are Role/action Perspective  who does what

4
 Process Activities
■ Real software processes are inter-leaved sequences of technical, collaborative
and managerial activities with the overall goal of specifying, designing,
implementing and testing a software system.

■ The four basic process activities of specification, development, validation and

evolution are organized differently in different development processes.

5
Basic Process Steps in all Software Development

1. Feasibility and
2. Requirements *
planning

3. System and * *
4. Implementation
program design

*
5. Acceptance 6. Operation and
and release maintenance

*These steps may be repeated many times during the development cycle.
6
Process Step: Feasibility

■ A feasibility study precedes the decision to begin a

project.

– What is the scope of the proposed project?

– Is the project technically feasible?
– What are the projected benefits?
– What are the costs?
– Are the resources available?
– What are the risks and how can they be managed?

■ A feasibility study leads to a decision: go or no-‐go.

7
Process Step: Requirements
■ Requirements define the function of the system
from the client's viewpoint

■ The requirements establish the system's functionality,

constraints, and goals by consultation with the client,
customers, and users.

■ They must be developed in a manner that is understandable

by both the client and the development staff.

8
Process Step: Requirements
■ This step is sometimes divided into:
– Requirements analysis
– Requirements definition
– Requirements specification

■ The requirements may be developed in a self-contained-study

or may emerge incrementally.

■ Failure to agree on the requirements and define them

adequately is one of the biggest cause of software projects
failing.

9
The Requirements Engineering Process

10
Process Step: System Design
■ Design describes the system from the software
developers' viewpoint
■ System design:
– Establish a system architecture, both hardware and
software, that matches the requirements
■ Program design:
– Represent the software functions in a form that can be
transformed into one or more executable programs

■ Preliminary user testing is often carried out as part of the

design step

■ Models are used to represent the requirements, system

architecture, and program design. 11
A General Model Of The Design Process

12
Design Activities
Architectural design, where you identify the overall structure of the system, the principal
components (sometimes called sub-systems or modules), their relationships and how they are
distributed.

Interface design, where you define the interfaces between system components.

Component design, where you take each system component and design how it will operate.

Database design, where you design the system data structures and how these are to be
represented in a database.

13
Process Step: Implementation
Implementation (coding)
■ The software design is realized as a set of programs or
program units.
■ These software components may be written by the
development team, acquired from elsewhere, or modified
from existing components.

Program testing
■ Program testing by the development staff is an integral part
of implementation.
■ Individual components are tested against the design
■ The components are integrated and tested against the design
as a complete system.
14
Process Step: Acceptance and
Release
Testing
■ The system is tested against the requirements by the client ,
often with selected customers and users.

Delivery And Release

■ After successful acceptance testing, the system is delivered to
the client and released into production or marketed to
customers.

15
Stages of Testing

16
Testing Stages

Development Or System Testing Acceptance Testing

Component Testing
Individual components are Testing of the system as a Testing with customer data to
tested independently; whole. check that the system meets the
Components may be functions Testing of emergent properties customer’s needs.
or objects or coherent groupings is particularly important.
of these entities.

17
Process Step: Operation and
Maintenance
■ Operation:
– The system is put into practical use.
■ Maintenance:
– Errors and problems are identified and fixed.
■ Evolution:
– The system evolves over time as requirements change,
to add new functions, or adapt to a changing technical
environment.
■ Phase out:
– The system is withdrawn from service.

18
Software Evolution
■ Software is inherently flexible and can change.

■ As requirements change through changing business circumstances, the software that supports the
business must also evolve and change.

19
Plan-Driven and Agile Processes
■ Plan-driven Processes are processes where all the process activities are planned in advance and
progress is measured against this plan.

■ In Agile Processes, planning is incremental, and it is easier to change the process to reflect
changing customer requirements.

■ In practice, most practical processes include elements of both plan-driven and agile approaches.

■ There are no right or wrong software processes.

20
Software 1. The Waterfall Model
Process Models
– Plan-driven model.
– Separate and distinct phases of
specification and development.

21
The Waterfall Model

22
The Waterfall Model

23
 Waterfall Model Phases
■ There are separate identified phases in the waterfall model:
– Requirements analysis and definition
– System and software design
– Implementation and unit testing
– Integration and system testing
– Operation and maintenance

■ The main drawback of the waterfall model is the difficulty of accommodating

change after the process is underway.

■ In principle, a phase must be completed before moving onto the next phase.

24
 ■ Advantages
Waterfall – Process visibility

Model – Separation of tasks

– Quality control at each step
– Cost monitoring at each step

■ Disadvantages
■ In practice, each stage in the process reveals new understanding of
the previous stages, which often requires the earlier stages to be
revised.

■ The Waterfall Model is not flexible enough.

25
 Water Fall Model - Discussion
■ A pure sequential model is impossible
■ Examples:
– A feasibility study cannot create a proposed budget and schedule without a
preliminary study of the requirements and a tentative design.
– Detailed design and implementation reveal gaps in the requirements
specification.
– Requirements and/or technology may change during the development.

■ In Waterfall model, very less customer interaction is involved during the

development of the product.
■ Once the product is ready then only it can be demonstrated to the end users.
■ Once the product is developed and if any failure occurs then the cost of fixing
such issues are very high, because we need to update everything from document
till the logic.

■ The plan must allow for some form of iteration. 26

Waterfall Model - Discussion
■ Inflexible partitioning of the project into distinct stages makes it difficult to
respond to changing customer requirements.
– Therefore, 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.

■ The waterfall model is mostly used for large systems engineering projects
where a system is developed at several sites.
– In those circumstances, the plan-driven nature of the waterfall model helps
coordinate the work.

27
Sequential ■ Sequential processes work best when the requirements are well
understood, and the design is straightforward
Development
■ Examples:
– Conversions of manual data processing systems where the
requirements were well understood and few changes were made
during the development (e.g., electricity billing).

– New models of a product where the functionality is closely

derived from an earlier product (e.g. automatic braking system
for a car).

– Portions of a large system where some components have clearly

defined requirements and are clearly separated from the rest of
the system.

28
Software 1. The Waterfall Model

Process Models
■ Plan-driven model.
■ Separate and distinct phases of specification
and development.

2. Incremental Model
■ Specification, development and validation are
interleaved.
■ May be plan-driven or agile.

29
Incremental Development
■ In Incremental Development,
– You have all the requirements
– you design the complete product first. You only leave out details that you can
safely decide later
– Then you slice it up into chunks and build each separately
– When you finish a chunk (module) you integrate it with previously
completed parts, so they work as a whole

30
Incremental Development

31
32
Example

33
Incremental Development and
Delivery
Incremental Development
■ Develop the system in increments and evaluate each increment
before proceeding to the development of the next increment;
■ Normal approach used in agile methods;
■ Evaluation done by user/customer proxy.

Incremental Delivery
■ Deploy an increment for use by end users
■ More realistic evaluation about practical use of software;
■ Difficult to implement for replacement systems as increments
have less functionality than the system being replaced.

34
Incremental Delivery

35
 Incremental Delivery
■ 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 prioritized, 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.

36
Advantages and Disadvantages of Incremental
Model
Advantages Disadvantages

The software will be generated quickly during the It requires a good planning designing
software life cycle
Problems might cause due to system architecture as
It is flexible and less expensive to change such not all requirements collected up front for the
requirements and scope entire software lifecycle

Throughout the development stages changes can be

Each iteration phase is rigid and does not overlap
done
each other

This model is less costly compared to others

Rectifying a problem in one unit requires correction
A customer can respond to each building in all the units and consumes a lot of time

Errors are easy to be identified

37
When to use Incremental Model?
Requirements of the system are clearly understood

Major requirements must be defined; however, some details can evolve with time.

When demand for an early release of a product arises

When software engineering team are not very well skilled or trained

When high risk features and goals are involved

A new technology is being used

Such methodology is more in use for web application and product-based companies

38
Software 1. The Waterfall Model

Process Models ■ Plan-driven model.

■ Separate and distinct phases of specification and
development.

2. Incremental Model
■ Specification, development and validation are
interleaved.
■ May be plan-driven or agile.

3. Iterative Model
■ the repetitive application of the core development
activities
39
Iterative Development
■ Iterative development is a lot like inventing discovering what
and how you need as you go

■ You start with a fair idea of what you want the product to
accomplish, and you use a process of successive
approximation to design and build it

■ You begin by designing, building, and testing the tiniest

version of what you have in mind When you’re happy, you
show it and collect feedback from everybody with a stake in
the product
■ If what you created was well received, you keep it and
expand on it in the next iteration If what you created got the
thumbs down, you discard it and go back to the drawing
board
40
41
Iteration - Definition
■ Iteration
– A self-contained mini project , with a well-defined result , that results in a stable, integrated
and tested release

■ An iteration consists of
– distinct set of activities
– conducted according to a dedicated (iteration ) plan
– With a set of objective , measurable evaluation criteria
– That provides business value

■ The release may be either an internal release or an external release

42
Iterative Model

43
Iterative Model - Advantages
In iterative model we can only create a high-level design of the application before we begin
to build the product and define the design solution for the entire product. Later on, we can
design and built a skeleton version of that, and then evolved the design based on what had
been built.

In iterative model we are building and improving the product step by step. Hence, we can
track the defects at early stages. This avoids the downward flow of the defects.

In iterative model we can get the reliable user feedback. When presenting sketches and
blueprints of the product to users for their feedback, we are effectively asking them to
imagine how the product will work.

In iterative model less time is spent on documenting and more time is given for designing.

44
Iterative Model - Disadvantages

Each phase of an iteration is rigid with no overlaps

Costly system architecture or design issues may arise because not all requirements are
gathered up front for the entire lifecycle

45
When to use Iterative Model?

There is a need to get a Resources with needed There are some high-risk
product to the market skill set are not available features and goals.
early.

46
Difference between Incremental and Iterative

One important difference is whether you specify the requirements upfront

(Incremental) or discover them as you build your product (iterative)

Another important difference is the focus on separating parts of the product Modular
design is a core characteristic of incremental development, but not of iterative
development

47
48
References

– “Software Engineering” by Ian Summerville

■ Chapter 2: Software Processes

– “Software Engineering : A Practitioners Approach” by Roger S. Pressman

■ Chapter 2: Process Models

49