Software

Engineering
 CHAPTER - 02

05/21/23 2
 SW PROCESS MODELS

05/21/23 3
 THE SOFTWARE PROCESS:

• A common process framework is established by defining a

small no of framework activities that are applicable to all SW
projects regardless of their size of complexity.
• A no: of ‘task sets’ enables the framework activities to be
adapted to SW project and requirements those tasks are:
• Work Tasks
• Project Milestones
• SW Work Products and Deliverables
• SW Quality Assurance Points

05/21/23 4
 KEY PROCESS AREAS (KPAs):

– Goals: The overall objectives.

– Commitments: The requirements that must meet to
achieve goals.
– Abilities: The things that must be in place that will
enable the organization to meet commitments.
– Activities: The specific tasks those are required to
achieve.
– Methods of Monitoring Implementations: The
manner in which the activities are mentioned to place.
– Methods of Verifying Implementation: The manner
in which proper practice can be verified.

05/21/23 5
A COMMON PROCESS FRAME WORK:

COMMON PROCESS FRAME WORK:

FRAME WORK ACTIVITES TASK SETS

TASK MILESTONE, DELIVERABLE

SQA CHECKPOINTS

UMBRELLA ACTIVATES

05/21/23 6
 SOFTWARE PROCESS MODEL:

• To solve actual problems in industry, a Software

Engineer or team of engineers must incorporate a
development strategy that encompasses the process,
methods & tools, different generic phases combined in
one model called “Process Model” or “Software
Engineering Paradigm”.
• The model is selected according to the nature of the
project and application.
• All software developments can be characterized as a
problem solving loop as shown in figure as given below
in which 4 stages are encountered:

05/21/23 7
 SOFTWARE PROCESS MODEL:

1. Status Quo
2. Problem Definition
3. Technical Development
4. Solution Integration

05/21/23 8
 – Present the Current State of Affairs.

– Identifies the Specific Problem to be Solved.

– It gives the Solution of Problem by using some Technology.

– It delivers the solution to those who request for it.

• The problem-solving loop described here can be used at different

levels of resolving the problem. It can be used at Macro, middle
& even at code generating level. Therefore it represents the
idealized view of processes, in figure: gives a scenario of an
identical problem-solving loop, which contains another problem-
solving loop.

05/21/23 9
 SEQUENTIAL MODELS:
 THE LINEAR PROCESS MODEL:
 It is also called the “Waterfall Model” or “Life Cycle Model”.
 It suggests a systematic and sequential approach to SW development that
begins at the system level, progress through analysis, design, coding, testing
and maintenance in figure as shown below:

05/21/23 10
05/21/23 11
• ANALYSIS:
• To understand the nature of the program to be built, SW engineer
must understand the requirement, behavior, performance &
interfacing of the system. So the analysis for both the system and
SW are documented and reviewed with the customer.
• DESIGN:
• It focuses on data structure, SW architecture, interface
representation & algorithms. Design is documented to represent the
translation requirements into software representation.
• CODING:
• The design must be translated into code (machine readable form).
Therefore this step produces an implementation of collected
modules.

05/21/23 12
• TESTING:
• Once code has been generated it must be tested. It
focuses on the logical internals of the SW;
therefore it produces the tested assembly of
modules.
• MAINTENANCE:
• SW will must go under changes when it is
delivered to customer, so error will encountered.
Therefore it must be kept working and up-to-date
according to the requirements of customers.

05/21/23 13
 DISADVANTAGES:

– Real projects rarely follow this model, because it does

not accommodate iterations directly, so the changes
can cause confusion as team proceeds.
– It is difficult for a customer to state all the
requirements clearly but this model requires this.
– The customer must have patience – a work version of
the programs may change due to late in project and it
can be disastrous.
– Developers are often late unnecessarily. It may create
a ‘blocking state’ in which some members have to wait
for other to let them complete their section of project.

05/21/23 14
 ADVANTAGES:
 
– With all problems, it has a very important place in
software Engineering.

– It provides a template for methods for analysis,

design, coding and testing.

– It keeps the development process easy to monitor.

– It enforces to develop documents.

05/21/23 15
 PROTOTYPING MODEL:
 In some cases, customer remains unable to define his requirements and in
other cases designer remain unsure about the efficiency of algorithms,
ability of O.S etc. In all these situations Prototype Model is best to use. Fig:
show the model.

BUILD / REVISE
LISTEN TO MOCK-UP
CUSTOMER

BASIC
STARTING STRUCTURE
POINT

CUSTOMER TEST
DRIVERS MOCK UP

05/21/23 16
 IT HAS THE FOLLOWING
PHASES:
• GATHER REQUIREMENTS & DEFINE:
• Developers and customers meet and define the overall objectives for
the SW. Industry requirements and outline areas of work.
• QUICK DESIGN:
• It focuses the presentation of all aspects highlighted at phase 1, and
all aspects of SW that will be visible to customer/ user.
• BUILD PROTOTYPE:
• Phase II leads to this phase and it is build by customer + design
mutually.
• EVOLUTION:
• Evolution will be by customer and is used to refine requirements for
SW to be developed.

05/21/23 17
 REFINE PROTOTYPE:
Iteration occurs as the prototype is turned to satisfy the needs of the customer.
 ENGINEER PRODUCT:
All these steps will help the developer to enable to better understand what
needs to be done & on the behalf of that SW will be finally marketed.

05/21/23 18
 THEREFORE WE CAN SAY THAT
PROTOTYPE MODEL IS:

– Basically a code and fix approach model.

– Useful when requirements are vague or unknown.

– Creates user interface.

– Explores functionality needs.

05/21/23 19
 ADVANTAGES:

– Allows requirements to be quickly explored.

– Allows user feedback to be obtained.

– Allows risks to be assessed.

05/21/23 20
 DISADVANTAGES:
– Customer remains unsatisfied, due to changes
(even for betterment)

– Developer also makes compromises to get

prototype model function quickly.

– Documentation is completely absent.

– Product remains uncompleted all the time.

– Not a complete development methodology.

05/21/23 21
 PROTOTYPING PROCESS

ESTABLISH DEFINE DEVELOP EVALUATE

PROTOTYPE PROTOTYPE
PROTOTYPE PROTOTYPE
OBJECTIVES FUNCTIONAL
ITY

PROTOTYPING OUTLINE EXECUTABLE EVALUATION

PLANE DEFINITION PROTOTYPE REPORT

05/21/23 22
 THE RAD MODEL:

• It is a linear sequential Software development model.

This model was created to remove the disadvantages,
faults, and deficiencies of prototype model. This model
contain a time constrain property. It means that the
project will complete in given time at any cost. .

• It emphasizes extremely short development

cycle.

05/21/23 23
 TEAM #. 01
FUNCTIONAL SYSTEM CAN BE DEVELOPED
WITHIN 60 – 90 DAYS.
BUSINESS
MODELING
TEAM #. 02
DATA
BUSINESS MODELING
MODELING
PROCESS
TEAM #. 03 MODELING
DATA
MODELING APPLICATION
BUSINESS GENERATION

MODELING PROCESS TESTING &

MODELING TURNOVER

APPLICATION
DATA MODELING GENERATION

TESTING &
TURNOVER
PROCESS
MODELING

60 - 90 DAYS APPLICATION
GENERATION

TESTING &
TURNOVER
05/21/23 24
 • In this model maximum work will perform in minimum time.
RAD model means increasing the size of engineers than project
will complete in short time. In this model work will perform in
groups, subgroups, section, subsections to achieve given target.
This model given motivation.

• It is high-speed adoption of sequential model.

• It follows component based construction approach.

• If the requirements are clear and stop of project is targeted then

fully.

05/21/23 25
 RAD APPROACHES THE FOLLOWING
PHASES:
BUSINESS MODELING:
• This phase is about the queries of certain questions, which relates to
business modeling.
DATA MODELING:
• In this, attributes of each object are identified and relationships
between them are identified.
PROCESS MODELING:
• Data objects are transformed to achieve information flow necessary
to implement a business function.
APPLICATION GENERATION:
• It uses the existing programs or creates reusable components.
TESTING:
• As it emphasizes on reuse, many of program components have
already tested, this reduces time consumption.

05/21/23 26
 DISADVANTAGES:

– RAD requires sufficient human resources to create

a right no: of RAD teams.

– RAD require committed developers and customers

to complete their activities in due time, if no, then
RAD project will fail.

05/21/23 27
 EVOLUTIONARY SOFTWARE
PROCESS MODELS:
• Like all other complex systems, SW also evolves over a
period of time. Business and product requirements often
change, so in these conditions straight-line models are
not used (Linear sequential model) because the
evolutionary nature of SW is not considered in all
linear/ classis software engineering paradigms.

• Evolutionary models are iterative. They are

characterized in a manner that enables SWEs to develop
increasingly more complete versions of the Software

05/21/23 28
 Concurrent
Activities

SPECIFICATION INITIAL
VERSION

OUTLINE INTERMEDIATE
DESCRIPTION DEVELOPMENT
VERSIONS

VALIDATION FINAL
VERSION

05/21/23 29
 AN EVOLUTIONARY (SPIRAL) MODEL

PLANNING
RISK ANALYSIS

CUSTOMER
COMMUNICATION

ENGINEERING

CUSTOMER
EVALUATION CONSTRUCTION &
RELEASE

05/21/23 30
 SPIRAL MODEL:

05/21/23 31
 • It is an evolutionary SW process model that couples the iterative nature of prototyping
with the controlled and systematic aspects of the linear model.

• In the Spiral model SW is developed in a series of incremental releases. In early releases

it may be paper model or prototype but in later versions it may be more complete one.

• The spiral model is divided into a no: of ‘Framework’ activities also called ‘Task
Regions’, those are:

– Customer Communication

– Planning

– Risk Analysis

– Construction & Release

– Customer Evolution

05/21/23 32
 ­SPIRAL
SPIRAL MODEL OF THE SOFTWARE
PROCESS

05/21/23 33
 • Each of the regions is populated by a series of work tasks that are
adapted to the characteristics of the project to be under taken.

• Unlike classical process models that end when software is delivered,

the spiral model can be adopted to apply throughout the life of
computer Software.

• A ‘Project Entry Point’ axis is defined in fig:. Each cube placed along
the axis represents the starting point for a different type of project.

• A ‘concept development project’ starts at the core of the spiral and will
continue until concept development is completed.

• If the concept is to be developed into an actual product, the process

proceeds through the next cube and continue until the compressor of
all 4 cubes as given below.

05/21/23 34
1. Concept Development Projects.

2. New Product development Projects.

3. Product Enhancement Projects.

4. Product Maintenance Projects.

05/21/23 35
 • This model incorporates many of the characteristics of the Spiral
model. It is evolutionary in nature, demanding an iterative approach
to the creation of the SW.

• It is same as Spiral model but the only difference is at engineering

region.

• The engineering activity begins with the “identification of candidate

classes”. This is accomplished by examining the data that are to be
manipulated by the application and the algorithms that will be
applied for manipulation.

• Classes are called “components” and are always stored in ‘class

library’ or repository.

• Once candidate classes are identified, the class library is searched to

determine, if these classes already exists.

05/21/23 36
 THE SOFTWARE PROCESS:
• Finally the Umbrella activities overlay (spread over) the
process model. Software Engineering institute has developed a
comprehensive model called “Capability Maturity Model”
(CMM) that defines key activities required at different levels
of process, those levels are:
Software process is characterized as adhoc and
Level 0: Initial occasionally. Few processes are defined and success
depends on individual efforts.
The necessary process discipline is in place to repeat
Level 1: Repeatable earlier successes on projects with similar
applications.
All projects use documents and approved version of
Level 2: Defined the organizations processes developing and
maintaining software
Here detailed measures of the SW process and
Level 3: Managed
products are collected.
Continuous Software improvements are enabled by
Level 4: Optimizing
quantitative from the process.
05/21/23 37