Ch#2

Process Models
 PROCESS MODELS
• Help in the software development
• Guide the software team through a set of
framework activities
• Process Models may be linear, incremental or
evolutionary

2
 Social Learning Process
• Software is alive knowledge that is initially dispersed,
implicit and incomplete.

• In order to convert knowledge into software, dialogues

are needed between users and designers, between
designers and tools to bring knowledge into software.

• Software development is essentially an iterative social

learning process, and the outcome is “software
capital”.

3
 What / who / why is Process Models?
 What: Go through a series of predictable steps--- a road map that helps you
create a timely, high-quality results.
 Who: Software engineers and their managers, clients also. People adapt the
process to their needs and follow it.
 Why: Provides stability, control, and organization to an activity that can if left
uncontrolled, become quite disordered. However, modern software
engineering approaches must be agile and demand ONLY those activities,
controls and work products that are appropriate.
 What Work products: Programs, documents, and data
 What are the steps: The process you adopt depends on the software that
you are building. One process might be good for aircraft avionic system, while
an entirely different process would be used for website creation.
 How to ensure right: A number of software process assessment mechanisms
that enable us to determine the maturity of the software process. However,
the quality, timeliness and long-term viability of the software are the best
indicators of the efficacy of the process you use.

4
 Definition of Software Process
• A framework for the activities, actions, and tasks that
are required to build high-quality software.

• SP defines the approach that is taken as software is

engineered.

• Is not equal to software engineering, which also

encompasses technologies that populate the
process– technical methods and automated tools.

5
A Generic Process Model

6
 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.
7
 Defining a Framework Activity
• A software team would need significantly more
information before it could properly execute any one
of these activities as part of the software process.
• Therefore, you are faced with a key question: “What
actions are appropriate for a framework activity,
given the nature of the problem to be solved, the
characteristics of the people doing the work, and the
stakeholders who are sponsoring the project?”
Process Flow
 Process Flow
 Linear process flow executes each of the
five activities in sequence.
 An iterative process flow repeats one or
more of the activities before proceeding to
the next.
Process Flow
 Process Flow
 An evolutionary process flow executes
the activities in a circular manner. Each
circuit leads to a more complete version
of the software.
 A parallel process flow executes one or
more activities in parallel with other
activities ( modeling for one aspect of the
software in parallel with construction of
another aspect of the software.

12
 Identifying a Task Set
 Before you can proceed with the process model, a
key question: what actions are appropriate for a
framework activity given the nature of the problem,
the characteristics of the people and the
stakeholders?
 A task set defines the actual work to be done to
accomplish the objectives of a software engineering
action.
 A list of the task to be accomplished
 A list of the work products to be produced
 A list of the quality assurance filters to be applied

13
 Identifying a Task Set
 For example, a small software project requested
by one person with simple requirements, the
communication activity might encompass little
more than a phone all with the stakeholder.
Therefore, the only necessary action is phone
conversation, the work tasks of this action are:
1. Make contact with stakeholder via telephone.
2. Discuss requirements and take notes.
3. Organize notes into a brief written statement of
requirements.
4. E-mail to stakeholder for review and approval.
14
 Identifying a Task Set
• Each software engineering action can be represented by
a number of different task sets—each a collection of
software engineering work tasks, related work products,
quality assurance points, and project milestones.
• You should choose a task set that best accommodates
the needs of the project and the characteristics of your
team.
• This implies that a software engineering action can be
adapted to the specific needs of the software project and
the characteristics of the project team.
 Process Patterns
• 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.
• Stated in more general terms, a process pattern provides you
with a template [Amb98]—a consistent method for describing
problem solutions within the context of the software process.
( defined at different levels of abstraction)
1. Problems and solutions associated with a complete
process model (e.g. prototyping).
2. Problems and solutions associated with a framework
activity (e.g. planning) or
3. an action with a framework activity (e.g. project
estimating).

16
 Process Patterns
• Ambler [Amb98] has proposed a template for describing a
process pattern:
• Pattern Name
– The pattern is given a meaningful name describing it within the
context of the software process (e.g., TechnicalReviews).
• Forces
– The environment in which the pattern is encountered and the
issues that make the problem visible and may affect its solution.
• Type
– The pattern type is specified. Ambler [Amb98] suggests three
types:
 Process Pattern Types
• Stage patterns—defines a problem associated with a framework
activity for the process. It includes multiple task patterns as
well. For example, Establishing Communication would
incorporate the task pattern Requirements Gathering and others.

• Task patterns—defines a problem associated with a software

engineering action or work task and relevant to successful
software engineering practice. (e.g., Requirements Gathering is a
task pattern).

• Phase patterns—define the sequence of framework activities

that occur with the process, even when the overall flow of
activities is iterative in nature. Example includes Spiral Model or
Prototyping.
18
 Process Patterns
• Initial context
– Describes the conditions under which the pattern applies. Prior to the initiation of
the pattern:
(1) What organizational or team-related activities have already occurred?
(2) What is the entry state for the process?
(3) What software engineering information or project information already exists?
• For example, the Planning pattern (a stage pattern) requires that
(1) customers and software engineers have established a collaborative communication;
(2) successful completion of a number of task patterns [specified] for the Communication
pattern has occurred; and
(3) the project scope, basic business requirements, and project constraints are known.
• Problem.
– The specific problem to be solved by the pattern.
• Solution.
– Describes how to implement the pattern successfully. This section describes how the
initial state of the process is modified as a consequence of the initiation of the
pattern.
– It also describes how software engineering information or project information that is
available before the initiation of the pattern is transformed as a consequence of the
successful execution of the pattern.
 Process Patterns
• Resulting Context.
– Describes the conditions that will result once the pattern has been successfully
implemented. Upon completion of the pattern:
(1) What organizational or team-related activities must have occurred?
(2) What is the exit state for the process?
(3) What software engineering information or project information has been developed?
• Related Patterns.
– Provide a list of all process patterns that are directly related to this one. This may
be represented as a hierarchy or in some other diagrammatic form. For example, the
stage pattern Communication encompasses the task patterns: ProjectTeam,
CollaborativeGuidelines, ScopeIsolation, RequirementsGathering,
ConstraintDescription, and ScenarioCreation.
• Known Uses and Examples.
– Indicate the specific instances in which the pattern is applicable. For example,
Communication is mandatory at the beginning of every software project, is
recommended throughout the software project, and is mandatory once the
deployment activity is under way.
 Process Patterns
• Process patterns provide an effective mechanism for addressing
problems associated with any software process.
• The patterns enable you to develop a hierarchical process
description that begins at a high level of abstraction (a phase
pattern).
• The description is then refined into a set of stage patterns that
describe framework activities and are further refined in a
hierarchical fashion into more detailed task patterns for each
stage pattern.
• Once process patterns have been developed, they can be reused
for the definition of process variants—that is, a customized
process model can be defined by a software team using the
patterns as building blocks for the process model.
 An Example of Process Pattern
• Describes an approach that may be applicable when stakeholders have a general idea of what
must be done but are unsure of specific software requirements.
• Pattern name. Requirements Unclear
• Intent. This pattern describes an approach for building a model that can be assessed
iteratively by stakeholders in an effort to identify or solidify software requirements.
• Type. Phase pattern
• Initial context. Conditions must be met (1) stakeholders have been identified; (2) a
mode of communication between stakeholders and the software team has been
established; (3) the overriding software problem to be solved has been identified by
stakeholders ; (4) an initial understanding of project scope, basic business
requirements and project constraints has been developed.
• Problem. Requirements are hazy or nonexistent. stakeholders are unsure of what they
want.
• Solution. A description of the prototyping process would be presented here.
• Resulting context. A software prototype that identifies basic requirements. (modes of
interaction, computational features, processing functions) is approved by
stakeholders. Following this, 1. This prototype may evolve through a series of
increments to become the production software or 2. the prototype may be discarded.
• Related patterns. CustomerCommunication, IterativeDesign, IterativeDevelopment,
CustomerAssessment, RequirementExtraction.

22
 The Waterfall Model

It is the oldest paradigm for SE. When requirements are well defined and
reasonably stable, it leads to a linear fashion.
(problems: 1. rarely linear, iteration needed. 2. hard to state all requirements explicitly. Blocking state.
3. code will not be released until very late.)

The waterfall model (some times called classic life cycle) suggests a
systematic, sequential approach to software development.
23
The Waterfall Model
The Waterfall Model
The Waterfall Model
 The Waterfall Model
• 1.Requirements analysis and definition:
• The system’s services, constraints, and goals are established by
consultation with system users. They are then defined in detail and serve
as a system specification.
• 2. System and software design:
• The systems design process allocates the requirements to either
hardware or software systems. It establishes an overall system
architecture. Software design involves identifying and describing the
fundamental software system abstractions and their relationships.
• 3. Implementation and unit testing:
• During this stage, the software design is realized as a set of programs or
program units. Unit testing involves verifying that each unit meets its
specification.
 The Waterfall Model
• 4.Integration and system testing:
• The individual program units 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.
• 5.Operation and maintenance :
• Normally, this is the longest life-cycle phase. The system is
installed and put into practical use. Maintenance involves
correcting errors that were not discovered in earlier stages of the
life cycle, improving the implementation of system units, and
enhancing the system’s services as new requirements are
discovered.
The V-Model

•A variation of waterfall model

depicts the relationship of quality
assurance actions to the actions
associated with communication,
modeling and early code
construction activates.

•Team first moves down the left side

of the V to refine the problem
requirements. Once code is
generated, the team moves up the
right side of the V, performing a
series of tests that validate each of
the models created as the team
moved down the left side.

29
The Waterfall Model
 The Incremental Model
• When initial requirements are reasonably well defined, but
the overall scope of the development effort prevent a purely
linear process. A compelling need to expand a limited set of
new functions to a later system release.
• It combines elements of linear and parallel process flows.
Each linear sequence produces deliverable increments of the
software.
• The first increment is often a core product with many
supplementary features. Users use it and evaluate it with
more modifications to better meet the needs.
• This process is repeated following the delivery of each
increment, until the complete product is produced.
The Incremental Model
The Incremental Model
The Incremental Model
The Incremental Model

35
 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 process model focuses on the delivery
of an operational product with each increment.
 Evolutionary Process Models
• Software, like all complex systems, evolves over a period of time.
• Business and product requirements often change as development
proceeds, making a straight line path to an end product 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.
• In these and similar situations, a process model is needed that has been
explicitly designed to accommodate a product that evolves over time.
• Evolutionary models are iterative. They are characterized in a manner
that enables you to develop increasingly more complete versions of the
software.
• Types of evolutionary models
• Prototyping
• Spiral model
• Concurrent development model
 Prototyping
• A prototyping paradigm may offer the best
approach in following situations:
1. Often, a customer defines a set of general
objectives for software, but does not identify
detailed requirements for functions and features.
2. 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.
The prototyping paradigm
 STEPS IN PROTOTYPING
• Begins with requirement gathering
– Identify whatever requirements are known
– Outline areas where further definition is mandatory
• A quick design occur
• Quick design leads to the construction of prototype
• Prototype is evaluated by the customer
• Requirements are refined
• Prototype is turned to satisfy the needs of customer
 Prototyping
• But what do you do with the prototype when it has served
the purpose described earlier? Brooks [Bro95] provides one
answer:
– In most projects, the first system built is barely usable. It may be too
slow, too big, awkward in use or all three. There is no alternative but
to start again, smarting but smarter, and build a redesigned version
in which these problems are solved.
• The prototype can serve as “the first system.”
• The one that Brooks recommends you throw away. But this
may be an idealized view. Although some prototypes are built
as “throwaways,” others are evolutionary in the sense that
the prototype slowly evolves into the actual system.
 LIMITATION OF PROTOTYPING
• In a rush to get it working, overall software
quality or long term maintainability are
generally overlooked
• Use of inappropriate OS
• Use of inefficient algorithm
 According to Sommerville:
Rapid Prototyping Model
• The Rapid Prototyping Model is used to overcome issues related to
understanding and capturing of user requirements.
• In this model a mock-up application is created “rapidly” to demand feedback
from the user.
• Once the user requirements are captured in the prototype to the satisfaction
of the user, a proper requirement specification document is developed and
the product is developed from scratch.
• An essential aspect of rapid prototype is embedded in the word “rapid”. The
developer should make an effort to construct the prototype as quickly as
possible to speedup the software development process.
• It must always be kept in mind that the sole purpose of the rapid prototype is
to capture the client’s needs; once this has been determined, the rapid
prototype is effectively discarded. For this reason, the internal structure of
the rapid prototype is not relevant.
 Integrating the Waterfall & Rapid
Prototyping Models
• Despite the many successes of the waterfall model,
it has a major drawback in that the delivered
product may not fulfill the client’s needs.
• One solution to this is to combine rapid prototyping
with the waterfall model.
• In this approach, rapid prototyping can be used as a
requirement gathering technique which would then
be followed by the activities performed in the
waterfall model.
 THE SPIRAL MODEL
• Originally proposed by Barry Boehm
• An evolutionary software process model that
couples the iterative nature of prototyping with
the controlled and systematic aspects of the
waterfall model.
• Include new element : Risk element
• Starts in middle and continually visits the basic
tasks of communication, planning, modeling,
construction and deployment
 THE SPIRAL MODEL
• Boehm [Boe01a] 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.
1. One is a cyclic approach for incrementally growing a system’s
degree of definition and implementation while decreasing its
degree of risk.
2. The other is a set of anchor point milestones for ensuring
stakeholder commitment to feasible and mutually satisfactory
system solutions.
A Typical Spiral Model
Evolutionary process: Spiral Model
• As this evolutionary process begins, the software team
performs activities that are implied by a circuit around
the spiral in a clockwise direction, beginning at the
center.
• Anchor point milestones—a combination of work
products and conditions that are attained along the path
of the spiral—are noted for each evolutionary pass.
• 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.
 THE SPIRAL MODEL
• Realistic approach to the development of large
scale system and software
• Software evolves as process progresses
• Better understanding between developer and
customer
• The first circuit might result in the concept
development of a product specification
• Subsequent circuits develop a prototype
• And sophisticated version of software
 The Spiral Model:Sommerville
• A Spiral Model has two
dimensions.
• Radial dimension represents
the cumulative cost to date
and the angular dimension
represents the progress
through the spiral.
• Each phase begins by
determining objectives of
that phase and at each
phase a new process model
may be followed.
Full Version of Spiral Model
General weaknesses of evolutionary model

• 1-Protyping process a problem to project

planning because of the uncertain number of
iterations require to construct the product.
• 2-Evolutionary development model do not
established the maximum speed of the
evolution
• If too fast, then the process will fall into chaos.
• If too slow productivity could be affected.
 Concurrent Models
• The concurrent development model, sometimes
called concurrent engineering, allows a software
team to represent iterative and concurrent
elements of any of the process models.
• For example, the modeling activity defined for
the spiral model is accomplished by invoking one
or more of the following software engineering
actions: prototyping, analysis, and design
 Concurrent Models
• Concurrent modeling is applicable to all types of
software development and provides an accurate
picture of the current state of a project.
• Rather than confining software engineering activities,
actions, and tasks to a sequence of events, it defines a
process network.
• Each activity, action, or task on the network exists
simultaneously with other activities, actions, or tasks.
• Events generated at one point in the process network
trigger transitions among the states.
One element of Concurrent Model
 A Final Word on Evolutionary Processes
• Modern computer software is characterized by continual change, by very tight
time lines, and by an emphatic need for customer–user satisfaction.
• In many cases, time-to-market is the most important management requirement.
If a market window is missed, the software project itself may be meaningless.
• Evolutionary process models were conceived to address these issues, and yet, as
a general class of process models, they too have weaknesses. As follows:
1. Difficult in project planning
2. Speed of evolution is not known
3. Does not focus on flexibility and extensibility (more emphasis on high quality)
• The intent of evolutionary models is to develop high-quality software in an
iterative or incremental manner. However, it is possible to use an evolutionary
process to emphasize flexibility, extensibility, and speed of development.
• The challenge for software teams and their managers is to establish a proper
balance between these critical project and product parameters and customer
satisfaction.
 SPECIALIZED PROCESS MODELS
• Specialized process models take on many of
the characteristics of one or more of the
traditional models.
 Component-Based Development
• Commercial off-the-shelf (COTS) software components,
developed by vendors who offer them as products, provide
targeted functionality with well-defined interfaces that enable
the component to be integrated into the software that is to be
built.
• The component-based development model incorporates many
of the characteristics of the spiral model.
• It is evolutionary in nature, demanding an iterative approach to
the creation of software.
• However, the component-based development model constructs
applications from prepackaged software components.
 Component-Based Development
• Modeling and construction activities begin
with the identification of candidate
components.
• These components can be designed as either
conventional software modules or object-
oriented classes or packages of classes.
• Regardless of the technology that is used to
create the components.
 Component-Based Development
• The component-based development model
incorporates the following steps (implemented using an
evolutionary approach):
1. Available component-based products are researched and
evaluated for the application domain in question.
2. Component integration issues are considered.
3. A software architecture is designed to accommodate the
components.
4. Components are integrated into the architecture.
5. Comprehensive testing is conducted to ensure proper
functionality.
 Component-Based Development
• The component-based development model
leads to software reuse, and reusability
provides software engineers with a number of
measurable benefits.
• Your software engineering team can achieve a
reduction in development cycle time as well as
a reduction in project cost if component reuse
becomes part of your culture.
 The Formal Methods Model
• The formal methods model encompasses a set
of activities that leads to formal mathematical
specification of computer software.
• Formal methods enable you to specify, develop,
and verify a computer-based system by applying
a rigorous, mathematical notation.
• A variation on this approach, called cleanroom
software engineering, is currently applied by
some software development organizations.
 The Formal Methods Model
• Ambiguity, incompleteness, and inconsistency can be
discovered and corrected more easily—not through ad hoc
review, but through the application of mathematical
analysis.
• When formal methods are used during design, they serve
as a basis for program verification and therefore enable
you to discover and correct errors that might otherwise go
undetected.
• Although not a mainstream approach, the formal methods
model offers the promise of defect-free software.
 The Formal Methods Model
• Concern about its applicability in a business
environment has been voiced:
• The development of formal models is currently quite
time consuming and expensive.
• Because few software developers have the necessary
background to apply formal methods, extensive
training is required.
• It is difficult to use the models as a communication
mechanism for technically unsophisticated customers.
 Aspect-Oriented Software Development
• Regardless of the software process that is chosen, the builders
of complex software invariably implement a set of localized
features, functions, and information content.
• These localized software characteristics are modeled as
components (e.g., object oriented classes) and then constructed
within the context of a system architecture.
• As modern computer-based systems become more sophisticated
(and complex), certain concerns—customer required properties
or areas of technical interest—span the entire architecture.
• Some concerns are high-level properties of a system (e.g.,
security, fault tolerance). Other concerns affect functions (e.g.,
the application of business rules), while others are systemic
(e.g., task synchronization or memory management).
 Aspect-Oriented Software Development
Crosscutting concerns
• When concerns cut across multiple system functions, features, and
information, they are often referred to as crosscutting concerns.
• Aspectual requirements define those crosscutting concerns that
have an impact across the software architecture.
Aspect-oriented software development (AOSD)
• Often referred to as aspect-oriented programming (AOP), is a
relatively new software engineering paradigm that provides a
process and methodological approach for defining, specifying,
designing, and constructing aspects—“mechanisms beyond
subroutines and inheritance for localizing the expression of a
crosscutting concern”
 Aspect-Oriented Software Development
Grundy [Gru02] discuss aspects in the context of what he calls aspect-oriented
component engineering (AOCE):
• AOCE uses a concept of horizontal slices through vertically-decomposed software
components, called “aspects,” to characterize cross-cutting functional and non-
functional properties of components.
• Common, systemic aspects include user interfaces, collaborative work,
distribution, memory management, transaction processing, security, integrity and
so on.
• Components may provide or require one or more “aspect details” relating to a
particular aspect, such as a viewing mechanism, extensible affordance and
interface kind (user interface aspects); event generation, transport and receiving
(distribution aspects); data store/retrieve and indexing (persistency aspects);
authentication, encoding and access rights (security aspects); transaction
atomicity, concurrency control and logging strategy (transaction aspects); and so
on.
• Each aspect detail has a number of properties, relating to functional and/or non-
functional characteristics of the aspect detail.