Software Process and

Process Model

Aravindhraj Natarajan, AP/CSE, KEC

What is software engineering?
• Definition :
• (1) The application of systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of
software; that is, the application of engineering to software.
(2) The study of approaches as in (1) above
• Its a discipline that is concerned with all aspects of software
production.

• Software engineers should adopt

• Systematic and organized approach to their work
• Use appropriate tools and techniques depending on the
problem to be solved
• The development constraints and the resources available
• Apply Engineering Concepts to develop Software

• Challenge for Software Engineers is to produce high quality

software with finite amount of resources & within a predicted
schedule
 Software Process
• What? A software process – as a framework for the
tasks that are required to build high-quality software.
• Who? Managers, software engineers, and customers.
• Why? Provides stability, control, and organization to
an otherwise chaotic activity.
• Steps? A handful of activities are common to all
software processes, details vary.
• Work product? Programs, documents, and data.
Software Engineering – Layered Technology

Layered Technology

Tools: CASE preferred

Methods: technical “how to’s”

Process model: the “framework”

A quality focus: the “bedrock”

 Layered Technology
A quality Focus
• Every organization is rest on its commitment to quality.
• Total quality management, Six Sigma, or similar continuous
improvement culture and it is this culture ultimately leads to
development of increasingly more effective approaches to
software engineering.
• The bedrock that supports software engineering is a quality
focus.

Process:
• It’s a foundation layer for software engineering.
• It’s defined framework for a set of key process areas (KRA)
to effectively manage and deliver quality software in a cost
effective manner
• The processes define the tasks to be performed and the
order in which they are to be performed
 Layered Technology

Methods:
• It provide the technical how-to's for building software.
• Methods encompass a broad array of tasks that include
requirements analysis, design, program construction, testing, and
support.
• There could be more than one technique to perform a task and
different techniques could be used in different situations.
Tools:
• Provide automated or semi-automated support for the process,
methods and quality control.
• When tools are integrated so that information created by one tool
can be used by another, a system for the support of software
development, called computer-aided software engineering
(CASE)
 Software process model
• Process models prescribe a distinct set of activities,
actions, tasks, milestones, and work products required to
engineer high quality software.
• Process models are not perfect, but provide roadmap for
software engineering work.
• Software models provide stability, control, and
organization to a process that if not managed can easily
get out of control
• Software process models are adapted to meet the needs
of software engineers and managers for a specific project.
 Process
Why process :
framework
A process defines who is doing what, when and
how to reach a certain goal.
• To build complete software process.
• Identified a small number of framework activities
that are applicable to all software projects,
regardless of their size or complexity.
• It encompasses a set of umbrella activities that
are applicable across the entire software process.
 Generic Process Framework Activities
• Communication:
• Heavy communication with customers, stakeholders, team
• Encompasses requirements gathering and related activities
• Planning:
• Workflow that is to follow
• Describe technical task, likely risk, resources will require, work products to be
produced and a work schedule.
• Modeling:
• Help developer and customer to understand requirements (Analysis of
requirements) & Design of software
• Construction
• Code generation: either manual or automated or both
• Testing – to uncover error in the code.
• Deployment:
• Delivery to the customer for evaluation
• Customer provide feedback
 Umbrella Activities – Typical Specific Activities
• Software project tracking and control
• Assessing progress against the project plan.
• Take adequate action to maintain schedule.
• Formal technical reviews
• Assessing software work products in an effort to uncover and remove errors before goes
into next action or activity.
• Software quality assurance
• Define and conducts the activities required to ensure software quality.
• Software configuration management
• Manages the effects of change.
• Document preparation and production
• Help to create work products such as models, documents, logs, form and list.
• Reusability management
• Define criteria for work product reuse
• Mechanisms to achieve reusable components.
• Measurement
• Define and collects process, project, and product measures
• Assist the team in delivering software that meets customer’s needs.
• Risk management
• Assesses risks that may effect that outcome of project or quality of product (i.e. software)
Process Framework
Process Framework
•Each framework
activities is populated by
a set for software
engineering actions – a
collection of related
tasks.
• Each action has
individual work task.
 The Process Model: Adaptability
• The framework activities will always be applied on
every project ... BUT
• The tasks for each activity will vary based on:
• The type of project (an “entry point” to the model)
• Characteristics of the project
• Common sense judgment; concurrence of the project
team
Process Flow
 Prescriptive Model
• Prescriptive process models advocate an orderly approach to software
engineering
• Organize framework activities in a certain order
• Process framework activity with set of software engineering actions.
• Each action in terms of a task set that identifies the work to be
accomplished to meet the goals.
• The resultant process model should be adapted to accommodate the nature
of the specific project, people doing the work, and the work environment.
• Software engineer choose process framework that includes activities like;
• Communication
• Planning
• Modeling
• Construction
• Deployment
 Prescriptive Model

• Calling this model as “Prescribe” because it

recommend a set of process elements, activities,
action task, work product & quality.
• Each elements are inter related to one another
(called workflow).
Waterfall Model or Classic Life Cycle
 Waterfall Model or Classic Life Cycle
• Requirement Analysis and Definition: What - The systems services,
constraints and goals are defined by customers with system users.

• Scheduling tracking -
• Assessing progress against the project plan.
• Require action to maintain schedule.
• System and Software Design: How –It establishes and overall system
architecture. Software design involves fundamental system abstractions
and their relationships.
• Integration and system testing: The individual program unit or programs
are integrated and tested as a complete system to ensure that the
software requirements have been met. After testing, the software system is
delivered to the customer.
• Operation and Maintenance: Normally this is the longest phase of the
software life cycle. The system is installed and put into practical use.
Maintenance involves correcting errors which were not discovered in earlier
stages of the life-cycle.
 Limitations of the waterfall model
 The nature of the requirements will not change very much
During development; during evolution
 The model implies that you should attempt to complete a
given stage before moving on to the next stage
 Does not account for the fact that requirements
constantly change.
 It also means that customers can not use anything until
the entire system is complete.
 The model implies that once the product is finished, everything
else is maintenance.
 Surprises at the end are very expensive
 Some teams sit ideal for other teams to finish
 Therefore, this model is only appropriate when the
requirements are well-understood and changes will be
fairly limited during the design process.
 Limitations of the waterfall model
Problems:

1. Real projects are rarely follow the sequential model.

2. Difficult for the customer to state all the requirement explicitly.

3. Assumes patience from customer - working version of

program will not available until programs not getting change

fully.
 Incremental Process Model

C- Communication
P - Planning
M – Modeling
C - Construction
D - Deployment

Delivers software in small but usable

pieces, each piece builds on pieces
already delivered
 The Incremental 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.
• First Increment is often core product
• Includes basic requirement
• Many supplementary features (known & unknown) remain undelivered
• A plan of next increment is prepared
• Modifications of the first increment
• Additional features of the first increment
• It is particularly useful when enough staffing is not available for the whole
project
• Increment can be planned to manage technical risks.
• Incremental model focus more on delivery of operation product with each
increment.
 The Incremental Model
• 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.
• Customer value can be delivered with each increment so
system functionality is available earlier.
• Early increments act as a prototype to help elicit requirements
for later increments.
• Lower risk of overall project failure.
• The highest priority system services tend to receive more
testing.
 Evolutionary Process Model
• Produce an increasingly more complete version of
the software with each iteration.
• Evolutionary Models are iterative.
• Evolutionary models are:
• Prototyping
• Spiral Model
• Concurrent Development Model
Evolutionary Process Models :
Prototyping
 Software prototyping

• A prototype is an initial version of a system used to

demonstrate concepts and try out design options.
• A prototype can be used in:
• The requirements engineering process to help with requirements
elicitation and validation;
• In design processes to explore options and develop a UI design;
• In the testing process to run back-to-back tests.
 Benefits of prototyping

• Improved system usability.

• A closer match to users’ real needs.
• Improved design quality.
• Improved maintainability.
• Reduced development effort.
 Prototype development

• May be based on rapid prototyping languages or tools

• May involve leaving out functionality
• Prototype should focus on areas of the product that are not well-
understood;
• Error checking and recovery may not be included in the prototype;
• Focus on functional rather than non-functional requirements such as
reliability and security
 Throw-away prototypes

• Prototypes should be discarded after development as they are

not a good basis for a production system:
• It may be impossible to tune the system to meet non-functional
requirements;
• Prototypes are normally undocumented;
• The prototype structure is usually degraded through rapid change;
• The prototype probably will not meet normal organisational quality
standards.
 Prototyping cohesive
• Best approach when:
• Objectives defined by customer are general but does not have details
like input, processing, or output requirement.
• Developer may be unsure of the efficiency of an algorithm, O.S., or the
form that human machine interaction should take.
• It can be used as standalone process model.
• Model assist software engineer and customer to better understand what is to be
built when requirement are fuzzy.
• Prototyping start with communication, between a customer and software engineer
to define overall objective, identify requirements and make a boundary.
• Going ahead, planned quickly and modeling (software layout visible to the
customers/end-user) occurs.
• Quick design leads to prototype construction.
• Prototype is deployed and evaluated by the customer/user.
• Feedback from customer/end user will refine requirement and that is how iteration
occurs during prototype to satisfy the needs of the customer.
 Prototyping (cont..)
 Prototype can be serve as “the first system”.
 Both customers and developers like the prototyping paradigm.
 Customer/End user gets a feel for the actual system
 Developer get to build something immediately.

Problem Areas:
 Customer cries foul and demand that “a few fixes” be applied to make
the prototype a working product, due to that software quality suffers
as a result.
 Developer often makes implementation in order to get a prototype
working quickly without considering other factors in mind like OS,
Programming language, etc.

Customer and developer both must be agree that the prototype is built to
serve as a mechanism for defining requirement.
Evolutionary Model: Spiral Model
 Spiral Model
Couples iterative nature of prototyping with the controlled
and systematic aspects of the linear sequential model
• It provide potential for rapid development of increasingly
more complete version of the software.
• Using spiral, software developed in as series of evolutionary
release.
• Early iteration, release might be on paper or prototype.
• Later iteration, more complete version of software.
• Divided into framework activities (C,P,M,C,D). Each activity
represent one segment.
• Evolutionary process begins in a clockwise direction,
beginning at the center risk.
• First circuit around the spiral might result in development of
a product specification. Subsequently, develop a prototype
and then progressively more sophisticated version of
software.
• Unlike other process models that end when software is
delivered.
Spiral Model
 Spiral Model (cont.)
Concept Development Project:
• Start at the core and continues for multiple iterations until it is
complete.
• If concept is developed into an actual product, the process
proceeds outward on the spiral.
New Product Development Project:
• New product will evolve through a number of iterations around the
spiral.
• Later, a circuit around spiral might be used to represent a
“Product Enhancement Project”
Product Enhancement Project:
• There are times when process is dormant or software team not
developing new things but change is initiated, process start at
appropriate entry point.
• Spiral models uses prototyping as a risk reduction
mechanism but, more important, enables the developer to
apply the prototyping approach at each stage in the
evolution of the product.

• It maintains the systematic stepwise approach suggested

by the classic life cycle but also incorporates it into an
iterative framework activity.
• If risks cannot be resolved, project is immediately
terminated
Problem Area:
• It may be difficult to convince customers (particularly in
contract situations) that the evolutionary approach is
controllable.
• If a major risk is not uncovered and managed, problems
will undoubtedly occur.
Concurrent Development Model
 Concurrent Development Model
• It represented schematically as series of major
technical activities, tasks, and their associated states.
• It is often more appropriate for system engineering
projects where different engineering teams are
involved.
• The activity-modeling may be in any one of the states
for a given time.
• All activities exist concurrently but reside in different
states.
 Concurrent Development Model
E.g.
• The analysis activity (existed in the none state while
initial customer communication was completed) now
makes a transition into the under development state.
• Analysis activity moves from the under development
state into the awaiting changes state only if
customer indicates changes in requirements.
• Series of event will trigger transition from state to
state.
E.g. During initial stage there was inconsistency in design
which was uncovered. This will triggers the analysis
action from the Done state into Awaiting Changes
state.
 Concurrent Development (Cont.)
• Visibility of current state of project
• It define network of activities
• Each activities, actions and tasks on the network
exists simultaneously with other activities ,actions
and tasks.
• Events generated at one point in the process
network trigger transitions among the states.
Thank You….