PROCESS
MODELS
PRESENTED BY KIANE CAMBA
PROCESS MODEL
WHAT IT IS? WHO DOES IT?
Provides a specific roadmap for soft- Software engineers and their
ware engineering work. It defines the managers adapt a process model to
flow of all activities, actions and their needs and then follow it. The
people who have requested the
tasks, the degree of iteration, the
software have a role to play in the
work products, and the organization
process of defining, building, and
of the work that must be done. testing it.
WHAT ARE THE STEPS & WORK WHY IS IT IMPORTANT?
PRODUCT?
The process model provides you with Process provides stability, control,
the “steps” you’ll need to perform and organization to an activity that
disciplined software engineering can, if left uncontrolled, become quite
work. the work product is a
chaotic. A modern software
customized description of the
activities and tasks defined by the engineering approach must be “agile.”
process.
PRESCRIPTIVE PROCESS
MODEL
Strives for structure and order in software development. Activities and
tasks occur sequentially with defi ned guidelines for progress
ORDER AND PROJECT CONSISTENCY
are dominant issues in the prescriptive process approach.
We call them “prescriptive” because they prescribe a set of process
elements—framework activities, software engineering actions, tasks,
work products, quality assurance, and change control mechanisms for
each project.
Each process model also prescribes a process flow (also called a work
flow)—that is, the manner in which the process elements are interrelated
to one another.
THE WATERFALL MODEL
The waterfall model, sometimes called the classic life cycle, suggests a
systematic, sequential approach 2 to software development that begins
with customer specification of requirements and progresses through
planning, modeling, construction, and deployment, culminating in
ongoing support of the completed software.
The waterfall model is the oldest paradigm for software engineering.
THE V MODEL
Depicts the relationship of quality
assurance actions to the actions
associated with communication,
modeling, and early construction
activities.
The V-model provides a way of
visualizing how verification and
validation actions are applied to
earlier engineering work.
INCREMENTAL PROCESS
MODELS
Combines the elements’
linear and parallel
process flows. The
incremental model
applies linear sequences
in a staggered fashion as
calendar time
progresses. Each linear
sequence produces
deliverable “increments”
of the software
EVOLUTIONARY
PROCESS
MODELS
PRESENTED BY KIANE CAMBA
THE PROTOTYPING
PARADIGM
Evolutionary models are iterative.
They are characterized in a manner
that enables you to develop
increasingly more complete versions
of the software.
PROTOTYPING
Often, a customer defi nes a set of
general objectives for software, but
does not identify detailed
requirements for functions and
features.
Can serve as “the first system.”
PROTOTYPING CAN BE PROBLEMATIC
FOR THE FOLLOWING REASONS:
FOR STAKEHOLDERS
Stakeholders see what appears to be a working version of the software,
unaware that the prototype is held together haphazardly, unaware that
in the rush to get it working you haven't considered overall software
quality or long-term maintainability.
FOR A SOFTWARE ENGINEER,
As a software engineer, you often make implementation compromises in
order to get a prototype working quickly. An inappropriate operating
system or programming language may be used simply because it is
available and known; an ineffi cient algorithm may be implemented
simply to demonstrate capability.
THE SPIRAL
MODEL.
Originally proposed by Barry Boehm.
It is an evolutionary software
process model that couples the
iterative nature of prototyping with
the controlled and systematic
aspects of the waterfall model. It
provides the potential for rapid
development of increasingly more
complete versions of the software.
is a risk-driven process model generator that is used to guide multi-
stakeholder concurrent engineering of software intensive systems.
TWO MAIN DISTINGUISHING FEATURES OF
THE SPIRAL MODEL.
CYCLIC APPROACH
for incrementally growing a system’s
degree of definition and
implementation while decreasing its
degree of risk.
ANCHOR POINT
MILESTONES
for ensuring stakeholder
commitment to feasible and
mutually satisfactory system
solutions.
for ensuring stakeholder commitment to feasible and mutually
satisfactory system solutions.
CONCURRENT MODELS
sometimes called concurrent
engineering, that allows a software
team to represent iterative and
concurrent elements of any of the
process models described in this
chapter.
Concurrent modeling defines a series of
events that will trigger transitions from
state to state for each of the software
engineering activities, actions, or tasks.
is applicable to all types of software
development and provides an accurate
picture of the current state of a project.
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.
WEAKNESSES OF PROCESS MODELS
[Link] prototyping [and other more sophisticatedevolutionary processes]
poses a problem to project planning because of the uncertain number of
cycles required to construct the product.
[Link], evolutionary software processes do not establish the maximum
speed of the evolution. If the evolutions occur too fast, without a period of
relaxation, it is certain that the process will fall into chaos. On the other
hand if the speed is too slow then productivity could be affected.
3.[evolutionary] software processes should be focused on flexibility and
extensibility rather than on high quality. This assertion sounds scary.
SPECIALIZED PROCESS MODELS
take on many of the characteristics of one or more of the traditional
models presented in the preceding sections.
COMPONENT-BASED DEVELOPMENT
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.
It is evolutionary in nature, demanding an iterative approach to the
creation of software.
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.
SPECIALIZED PROCESS MODELS
take on many of the characteristics of one or more of the traditional
models presented in the preceding sections.
COMPONENT-BASED DEVELOPMENT
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.
It is evolutionary in nature, demanding an iterative approach to the
creation of software.
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.
ASPECT-ORIENTED
SOFTWARE
DEVELOPMENT
Often referred to as aspect-
oriented programming
(AOP) or aspect-oriented
component engineering
(AOCE) [Gru02].
Often referred to as aspect-oriented programming (AOP) or aspect-
oriented component engineering (AOCE) [Gru02].
It 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”
SOFTWARE
TOOLS
PRESENTED BY KIANE CAMBA
THE UNIFIED PROCESS
an attempt to draw on the best features and characteristics of traditional
software process models, but characterize them in a way that implements
many of the best principles of agile software development.
it recognizes the importance of customer communication and streamlined
methods for describing the customer’s view of a system.
A BRIEF HISTORY
1990s
-James Rumbaugh [Rum91], Grady Booch, and Ivar Jacobson began working on a “unifi ed
method” that would combine the best features of each of their individual object oriented
analysis and design methods and adopt additional features proposed by other experts in
object-oriented modeling.
Unified Modeling Language(UML)
-contains a robust notation for the modeling and development of object- oriented systems.
By 1997, UML became a de facto industry standard for object-oriented software
development.
PHASES OF THE UNIFI ED PROCESS
INCEPTION PHASE
customer communication and
planning activities.
ELABORATION PHASE
communication and modeling activities
of the generic process model
CONSTRUCTION PHASE
identical to the construction activity
defined for the generic software
process.
TRANSITION PHASE
latter stages of the generic construction
activity and the first part of the generic
deployment
PRODUCTION PHASE
coincides with the deployment activity of the generic process.
PERSONAL SOFTWARE PROCESS
emphasizes personal measurement of both the work product that is
produced and the resultant quality of the work product.
PSP MODEL DEFI NES FIVE FRAMEWORK ACTIVITIES:
PLANNING
This activity isolates requirements and develops both size and resource estimates.
HIGH-LEVEL DESIGN.
External specifications for each component to be constructed are developed and a
component design is created.
HIGH-LEVELDESIGN REVIEW.
Formal verification methods are applied to uncover errors in the design.
DEVELOPMENT
The component-level design is refi ned and reviewed.
POSTMORTEM
Using the measures and metrics collected, the effectiveness of the process is determined.
TEAM SOFTWARE PROCESS
the goal of TSP is to build a “self-directed” project team that organizes itself to
produce high-quality software.
OBJECTIVES OF TSP:
• Build self-directed teams that plan and track their work, establish goals, and own their
processes and plans. These can be pure software teams or integrated product teams (IPTs)
of 3 to about 20 engineers.
• Show managers how to coach and motivate their teams and how to help them sustain
peak performance.
• Accelerate software process improvement by making CMM 18 level 5 behavior normal and
expected.
• Provide improvement guidance to high-maturity organizations.
• Facilitate university teaching of industrial-grade team skills.
TSP defi nes the following framework activities: project launch, high-level design, implementation,
integration and test, and postmortem.
“Scripts”
-define specific process activities and other more detailed work functionsthat are part of the team
process.
PROCESS
TECHNOLOGY TOOLS
developed to help software
organizations analyze their
current process, organize work
tasks, control and monitor
progress, and manage technical
quality.
tools allow a software
organization to build an
automated model of the process
framework, task sets, and
umbrella activities
THANK YOU
FOR LISTENING