Chapter Two

Software Processes and Models

 Introduction
What is a process?
• A process is an organized set of activities, which transforms inputs to
outputs.
 We can use synonyms of process such as: procedure, method, course
of action, etc.
• Software engineering as a discipline has many processes.
 In the context of software engineering, a process is an adaptable
approach that enables the people doing the work (the software team)
to pick and choose the appropriate set of work actions and tasks.
• The intent is always to deliver software in a timely manner and with
sufficient quality to satisfy those who have sponsored its creation and
those who will use it.
 What is it? Software process
• When you work to build a product or system, it’s important to go
through a series of predictable steps—a road map that helps you
create a timely, high-quality result.
• The road map that you follow is called a “software process.”
 Who does it?

 Software engineers and their managers adapt the process to

their needs and then follow it.
 In addition, the people who have requested the software have a role
to play in the process of defining, building, and testing it.
 Why is it important? Cont’d…
• Because it provides stability, control, and organization to an activity
that can, if left uncontrolled, become quite chaotic.

 What are the steps?

• At a detailed level, the process that you adopt depends on the software
that you’re building.

 What is the work product?

• From the point of view of a software engineer, the work products are
the programs, documents, and data that are produced as a
consequence of the activities and tasks defined by the process.
 Cont’d…
 How do you ensure that you have done it right?
• There are a number of software process assessment mechanisms that
enable organizations to determine the “maturity” of their software
process.
• However, the quality, timeliness, and long-term viability of the
product you build are the best indicators of the efficacy of the
process that you use.
 Cont’d…
 Software process: organizing a structured set of activities
to develop software systems.
• These processes help in performing different
software engineering activities in an organized manner.
 Characteristics of processes
• Produces intermediate and final products.
• Each process activity has entry and exit criteria
• Activities are organized in sequence, so timing is clear.
• Each process has guiding principles including goals of each
activity.
• Uses resources, subject to set of constraints (such
schedule,
as no. of people working )
• May be composed of sub-processes with hierarchy or links
 Cont’d…
 There are many different software processes but all
must include four activities.
I. Software specification: the functionality of the
software and constraints on its operation must be defined.
II. Software design and implementation: the
software to meet the specification must be produced.
III.Software validation: the software must be
validated to ensure that it does what the
customer wants.
IV. Software evolution: the software must evolve to
meet changing customer needs.
 Sequential Software Process models
• Sequential models such as Waterfall or V-Model rely on
intensive periods of collecting and refining requirements
for a product before design and development activity
can take place.
• Products developed using these models are intended to be
complete when released to customers.
• Central to the approach is an assumption that by adhering to
the requirements captured at the beginning, the product
will fulfil the wishes of those customers.
 Cont’d…

Source: www.richrtesting.com (Richard Rogers)

 Iterative Software Process Models
• Emphasis on delivering less complex products, often to test
customer response before making adjustments.
• The techniques encourage regular feedback from customers,
and rapid response to that feedback;
• refining ideas and revisiting design and development
activities with the intention of delivering products
which better reflect what customers want.
 Cont’d…

Source: www.richrtesting.com (Richard Rogers)

 Software Development Life Cycle (SDLC)
• A Software Development Life Cycle (SDLC) is a well-defined,
structured sequence of stages in software engineering to develop
the intended software product.
• It is a process used by the software industry to design, develop and
test a high quality software.
 It aims to produce a high quality software that meets or exceeds
customer expectations, reaches completion with in times and cost
estimates.
• It is also called Software Development Process.
 Cont’d…
• The software development lifecycle begins with the identification of a
requirement for software and ends with the formal verification of
the developed software against that requirement.
• So SDLC goes through a series of phases.
• Helps to understand the entire process
• Enables planning of resources in advance
• Enforces a structured approach to development
• Helps to track progress of the system
 Cont’d…
 The software development life-cycle can be divided into 5-9 phases:
• Project initiation and planning
• Project identification and selection
• Feasibility study
• Project analysis
• System design
• Coding
• Testing
• Implementation
• Maintenance
 Cont’d…
I. Problem definition
• It is the decision about problems in the existing system and the motivation
for system change.
• The need for changes in the existing system are identified and shortcomings
of the existing system are detected. which leads to Feasibility Study.
II. Feasibility Study is an analysis of the viability of an idea.
• Answer the essential question of “should we proceed with the proposed
project idea?”
• Used to identify how, where, and to whom you intend to sell a service or
product.
• Provides detail concept about your business.
• How and where the business is operate
• How can I succeed
 Cont’d…
 Organizational Feasibility: is how well a proposed information system
supports the objectives of the organization and is a strategic plan for an
information system.

 Economic feasibility (Cost/Benefits Analysis): how much start-up capital

is needed, sources of capital, returns on investment( profit ), etc.
• if a project can’t cover its development costs, it won’t be approved,

 Technical Feasibility

 Operational Feasibility

 Schedule Feasibility

 Political Feasibility
 Cont’d…
III. Project Analysis: a detailed study of the various operations
performed by a system and their relationships within and outside the
system.
• Examine and document the relevant aspects of the existing system,
its shortcomings and problems.
• Analyze the findings and record the results.
• Define and document the proposed system.
• Test the proposed design against the known facts.
• Produce a detailed report to support the proposals.
• Estimate the resources required to design and
implement the system.
• The objective is to provide solutionsCont’d…
to stated problems, usually in
the form of specifications to meet the users requirements and to make
recommendations for a new computer-based system.
•Analysis is iterative and progressive process.
IV. System Design: it is the most creative and challenging phase.
 Determining data required to produce the output
 Determining processing methods and using software
 Determining methods of data capture
 Defining detailed critical procedures
 Calculating timings of processing
 Cont’d…
V. Coding: the goal of the coding phase is to translate the
design of the system into code in a given
programming language.
• affects both testing and maintenance

VI. Testing: testing is the major quality-control measure used

during software development.
• Its basic function is to detect errors in the software
VII. Implementation: it is mainly concerned with
user training, site selection, and preparation and file
 Cont’d…
VIII.Maintenance: it is an important part of the SDLC.
 But it has some problems:
• Availability of a few maintenance tools.
• User may not accept the cost of maintenance.
• Standards and guidelines of project may be
poorly defined.
• A good test plan is lacking.
 There Classifications of SDLC Model
are a number of different models for software
development
lifecycles which describe the interrelationships between software
development phases.
 Waterfall model
 prototype model
 incremental model
 V-shaped model
 Spiral model
 Waterfall
 Organize the activities in linear fashion.
model
• Each phase is end up with expected output in the forms of document.
• Waterfall model is the simplest model.
• All the phases of SDLC will function one after another in
linear
manner.
• That is, when the first phase is finished then only the second phase
will start and so on.
Classical Waterfall Model
 Cont’d…
 Classical waterfall model is idealistic:
• Assumes that no defect is introduced
during any development activity.
• In practice developers commit errors:
• Defects do get introduced in almost every
phase of the life cycle.
Iterative Waterfall Model
 Cont’d…
 Defects usually get detected much later in the life cycle:

• For example, a design defect might go unnoticed till the coding

or testing phase.
 Once a defect is detected:

• The phase in which it occurred and parts of the work

already completed subsequent phases needs to be reworked.
 Therefore need feedback paths in the classical waterfall model.
 Cont’d…
Waterfall model Strengths
• Easy to understand, easy to use
• Provides a reference to inexperienced staff
• Provides requirements stability
• Facilitates strong management control (plan, staff, track)

Waterfall Deficiencies
• All requirements must be known upfront
• Does not accommodate any change.
• There is no risk analysis.
• Can give a false impression of progress.
• Little opportunity for customer to pre-view the system.
When to use the Waterfall Model
Cont’d…
• Requirements are very well known and stable
• Technology is understood
• Experienced Development team
• When it is possible to produce a stable design

E.g. a new version of an existing product

• E.g. porting an existing product to a new platform.
 Prototype process model
• It is model implementation of the project with limited
functionalities.
• The prototype model suggests that before development
of the actual software, a working prototype of the
system should be built first.
What is a Prototype?
• It is a quickly developed, easily modifiable and extendible
working model of the required application.
Reasons for prototyping
Cont’d…

• learning by doing: useful where requirements are only partially known

• improved communication

• improved user involvement

• reduces the need for documentation

• reduces maintenance costs i.e. changes after the application goes

live
Cont’d…
Prototyping: advantages Cont’d…
• The resulting software is more usable
• User needs are better accommodated
• The design is of higher quality
• The resulting software is easier to maintain
• Overall, the development incurs less effort

Prototyping Weaknesses
• Sometimes expensive
• Overall maintainability may be overlooked
• Process may continue forever (scope creep)
 Cont’d…
What is the main goal of prototyping model?
• To avoid early freezing of the requirements.

• Instead of freezing the requirement, prototype is built

to understand the requirement.

• To enable the client to better understand the requirement.

 Cont’d…
When to use the Prototyping Model?
• When requirements are not known at the beginning of
the project.
• When requirements are unstable and constantly changing.
• When quick demonstrations are required.
• When user requires proof of concept.
 Incremental
• Incremental development process
is dividing themodel
project in various
independent parts and developing these sub-parts at
the same rate/ different rate and integrating them when
ready.
 Steps
• Develop a system in smaller portions at a time.
• Then slowly add increased functionality.
• Each subsequent release of the system adds function to the
previous release, until all designed functionality has
been implemented.
Cont’d…
 Cont’d…
Incremental Model Strengths
• Develop high-risk or major functions first
• Each release delivers an operational product
• Customer can respond to each build
• Uses “divide and conquer” breakdown of
tasks
• Lowers initial delivery cost
• Initial product delivery is faster
• Customers get important functionality early
 Cont’d…
Incremental Model Weaknesses
⚫ Requires good planning and design
⚫ Requires early definition of a complete and fully functional system to
allow for the definition of increments
⚫ Well-defined module interfaces are required
⚫ Total cost of the complete system is not lower
When to use the Incremental Cont’d…
Model
⚫ Most of the requirements are known up-front but are expected
to evolve over time

⚫ A need to get basic functionality to the market early

⚫ On projects which have lengthy development schedules

 Spiral Model
• The spiral model is an evolutionary software process model that
couples the iterative feature of prototyping with the controlled
and systematic aspects of the linear sequential model.
• It implements the potential for rapid development of new versions of
the software.
• Using the spiral model, the software is developed in a series
of incremental releases.
• During the early iterations, the additional release may be a
paper model or prototype.
• During later iterations, more and more complete versions of
the engineered system are produced.
Cont’d…
 Cont’d…
 Each cycle in the spiral is divided into four parts:
 Objective setting: Each cycle in the spiral starts with the
identification of purpose for that cycle, the various alternatives that
are possible for achieving the targets, and the constraints that exists.
 Risk Assessment and reduction: The next phase in the cycle is to
calculate these various alternatives based on the goals and constraints.
• The focus of evaluation in this stage is located on the risk perception
for the project.
 Cont’d…
 Development and validation: The next phase is to develop strategies
that resolve uncertainties and risks.
• This process may include activities such as benchmarking, simulation,
and prototyping.
 Planning: Finally, the next step is planned.

• The project is reviewed, and a choice made whether to continue with a

further period of the spiral.
• If it is determined to keep, plans are drawn up for the next step of the
project.
 Cont’d…
 The development phase depends on the remaining risks.

• For example, if performance or user-interface risks are treated more essential

than the program development risks, the next phase may be an evolutionary
development that includes developing a more detailed prototype for solving
the risks.
 The risk-driven feature of the spiral model allows it to accommodate any
mixture of a specification-oriented, prototype-oriented, simulation-oriented,
or another type of approach.
• An essential element of the model is that each period of the spiral is
completed by a review that includes all the products developed during that
cycle, including plans for the next cycle.
• The spiral model works for development as well as enhancement projects.
 Cont’d…
Spiral Model Strengths
• Provides early indication of insurmountable risks, without much
cost

• Users see the system early because of rapid prototyping tools

• Critical high-risk functions are developed first

• The design does not have to be perfect

• Users can be closely tied to all lifecycle steps

• Early and frequent feedback from users

• Cumulative costs assessed frequently

 Cont’d…
Spiral Model Weaknesses
• Time spent for evaluating risks too large for small or low-
risk projects
• Time spent planning, resetting objectives, doing risk analysis and
prototyping may be excessive
• The model is complex
• Risk assessment expertise is required
• Spiral may continue indefinitely
• May be hard to define objective, verifiable milestones
that indicate readiness to proceed through the next iteration
 Cont’d…
When to use Spiral Model
• When creation of a prototype is appropriate
• When costs and risk evaluation is important
• For medium to high-risk projects
• Users are unsure of their needs
• Requirements are complex
• When changes may require at any time
• Large and high budget projects
• When deliverance is required to be frequent.
 V Model
• It is a variant of the Waterfall
• emphasizes verification and validation
• V&V activities are spread over the entire life cycle.
• Verification and validation (V & V) is intended to show that a
system conforms to its specification and meets the requirements of
the system customer.
• In every phase of development:
• Testing activities are planned in parallel with development.
Developers life cycle
Cont’d…
Testers life cycle
Verification: Cont’d…
• It involves a static analysis method (review) done without executing code.
• It is the process of evaluation of the product development process to find
whether specified requirements meet.
Validation:
• It involves dynamic analysis method (functional, non-functional), testing is
done by executing code.
• Validation is the process to classify the software after the completion of the
development process to determine whether the software meets the customer
expectations and requirements.
• Verification and Validation process is joined by coding phase in V-shape.
• Thus it is known as V-Model.
52
 Cont’d…
V. Shaped Steps
• Project and Requirements Planning – allocate resources
• Product Requirements and Specification Analysis –
specification of the software system
complete
• Architecture or High-Level Design – defines how software
functions fulfill the design
• Detailed Design – develop algorithms for each architectural component
• Coding – transform algorithms into software
• Unit testing – check that each module acts as expected
• Integration and Testing – check that modules interconnect correctly
• System and acceptance testing – check the entire software system in its
environment
• Production, operation and maintenance – provide for enhancement and
corrections
 Cont’d…
V model Strengths
• Emphasize planning for verification and validation of the product in
early stages of product development.
• Each deliverable must be testable
• Easy to use

V Model Weaknesses
• Does not support overlapping of phases

• Does not handle iterations or phases

• Does not easily handle later changes in requirements

• Does not support risk analysis activities

 Cont’d…
When to use V Model
• All requirements are known up-front
• Solution and technology are known
• Natural choice for systems requiring high reliability:

• Embedded control applications

Thank
You!
?
57