Software Engineering

Week 2 (Chapter 2)
Professor Tahir Sabtian Syed
 A Generic Process Model
• A process was defined as a collection of
work activities, actions, and tasks that are
performed when some work product is to
be created.
• Each of these activities, actions, and tasks
reside within a framework or model that
defines their relationship with the process
and with one another
 A Generic Process Model
• A generic process framework for software engineering
defines five framework activities
– communication, planning, modeling, construction, and
deployment.
– In addition, a set of umbrella activities—project tracking and
control, risk management, quality assurance, configuration
management, technical reviews, and others are applied
throughout the process.
• One important aspect of the software process has not yet
been discussed. This aspect—called process flow—
– describes how the framework activities and the actions and
tasks that occur within each framework activity are organized
with respect to sequence and time
Process Flow
Process Flow
 Process Patterns
• Every software team encounters problems as it moves
through the software process.
• It would be useful if proven solutions to these
problems were readily available to the team so that
the problems could be addressed and resolved quickly
• A process pattern describes a process-related problem
that is encountered during software engineering work.
• identifies the environment in which the problem has
been encountered, and suggests one or more proven
solutions to the problem
 Prescriptive Process Models
• Prescriptive process models were originally
proposed to bring order to the disorder of software
development.
• History has indicated that these traditional models
have brought a certain amount of useful structure
to software engineering work
• And have provided a reasonably effective road map
for software teams.
 The Waterfall Model
• The waterfall model, sometimes called the
classic life cycle, suggests a systematic,
sequential approach to software development
• that begins with customer specification of
requirements and progresses through
planning, modeling, construction, and
deployment
• A variation in the representation of the
waterfall model is called the V-model
The Waterfall Model
 Incremental Process Models
• There may be a need to provide a limited set of
software functionality to users quickly and then
refine and expand on that functionality in later
software releases.
• In such cases, you can choose a process model that
is designed to produce the software in increments.
• For example, word-processing software developed using the incremental
paradigm might deliver basic file management, editing, and document
production functions in the first increment; more sophisticated editing and
document production capabilities in the second increment; spelling and
grammar checking in the third increment; and advanced page layout
capability in the fourth increment.
The Incremental Model
 Incremental Process Models
• The incremental model combines elements of
linear and parallel process flows
• The incremental model applies linear sequences
in a staggered (unsteadily) fashion as calendar
time progresses.
• Each linear sequence produces deliverable
“increments” of the software.
• When an incremental model is used, the first increment is often a core
product.
• That is, basic requirements are addressed but many supplementary
features (some known, others unknown) remain undelivered. The core
product is used by the customer (or undergoes detailed evaluation).
 Incremental Process Models
• Incremental development is particularly useful
when staffing is unavailable for a complete
implementation by the business deadline that
has been established for the project.
• Early increments can be implemented with
fewer people. If the core product is well
received, then additional staff (if required) can
be added to implement the next increment.
• In addition, increments can be planned to
manage technical risks
 Evolutionary Process Models
• Software, like all complex systems, evolves over a period of
time. Business and product requirements often change as
development proceeds
• So making a straight line path to an end product is unrealistic;
tight market deadlines make completion of a comprehensive
software product impossible, but a limited version must be
introduced to meet competitive or business pressure.
• A set of core product or system requirements is well
understood, but the details of product or system extensions
have yet to be defined.
• In these and similar situations A process Model is needed that
has been explicitly designed to accommodate a product that
evolves over time.
 Prototyping
• Often, a customer defines a set of general
objectives for software, but does not identify
detailed requirements for functions and features.
• In other cases, the developer may be unsure of
the efficiency of an algorithm, the adaptability of
an operating system, or the form that human-
machine interaction should take.
• In these, and many other situations, a prototyping
paradigm may offer the best approach.
 Prototyping
• Although prototyping can be used as a stand-
alone process model, it is more commonly
used as a technique that can be
implemented within the context of any one
of the process models
• Regardless of the manner in which it is
applied, the prototyping paradigm assists
you and other stakeholders to better
understand what is to be built when
requirements are fuzzy.
 Prototyping
• While making the model, user keeps giving feedbacks
from time to time and based on it, a prototype is made.
• Completely built sample model is shown to user and
based on his feedback, the SRS(System Requirements
Specifications) document is prepared.
• After completion of this, a more accurate SRS is
prepared, and now development work can start
• Although some prototypes are built as “throwaways,”
others are evolutionary in the sense that the prototype
slowly evolves into the actual system.
Prototyping
 The Spiral Model
• Originally proposed by Barry Boehm the spiral
model couples the iterative nature of prototyping
with the controlled and systematic aspects of the
waterfall model.
• Using the spiral model, software is developed in a
series of evolutionary releases.
• During early iterations, the release might be a
model or prototype.
• During later iterations, increasingly more complete
versions of the engineered system are produced.
Spiral Model
 The Spiral Model
• Boehm describes the model in the following manner
• The spiral development model is a risk-driven process
model generator that is used to guide multi-stakeholder
concurrent engineering of software intensive systems.
• It has two main distinguishing features. One is a cyclic
approach for incrementally growing a system’s degree
of definition and implementation while decreasing its
degree of risk.
• The other is a set of anchor point milestones for
ensuring stakeholder commitment to feasible and
mutually satisfactory system solutions.
 The Spiral Model
• The first circuit around the spiral might result in the
development of a product specification; subsequent
passes around the spiral might be used to develop a
prototype and then progressively more sophisticated
versions of the software.
• Each pass through the planning region results in
adjustments to the project plan. Cost and schedule are
adjusted based on feedback derived from the customer
after delivery.
• In addition, the project manager adjusts the planned
number of iterations required to complete the
software.