Chapter 2
Process Models
4 April 2021
Prepared By: Najaf Ali Khan Balouch
1
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 chaotic. 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 April 2021
Prepared By: Najaf Ali Khan Balouch
2
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.
3
4 April 2021
Prepared By: Najaf Ali Khan Balouch
• As we discussed before, 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.
• Next question is: how the framework activities and the actions and
tasks that occur within each activity are organized with respect to
sequence and time? See the process flow for answer.
4
4 April 2021
Prepared By: Najaf Ali Khan Balouch
Process Flow
• 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 and is illustrated in Figure 2.2.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
5
Process Flow…..
• A linear process flow executes each of the five framework activities in
sequence, beginning with communication and culminating with deployment .
• An iterative process flow repeats one or more of the activities before
proceeding to the next .
• An evolutionary process flow executes the activities in a “circular” manner.
Each circuit through the five activities leads to a more complete version of the
software.
• A parallel process flow executes one or more activities in parallel with other
activities
4 April 2021
Prepared By: Najaf Ali Khan Balouch
6
Process Flow
4 April 2021
Prepared By: Najaf Ali Khan Balouch
7
Small project
• For a small software project requested by one person (at a remote location) with simple,
straightforward requirements, the communication activity might encompass little more than a
phone call with the appropriate stakeholder. Therefore, the only necessary action is phone
conversation, and the work tasks (the task set) that this action encompasses are:
• Make contact with stakeholder via telephone.
. Discuss requirements and take notes.
• Organize notes into a brief written statement of requirements.
. E-mail to stakeholder for review and approval.
• If the project was considerably more complex with many stakeholders, each with a different set
of (sometime conflicting) requirements, the communication activity might have six distinct
actions (described in Chapter 5):
• inception,
• elicitation,
• Elaboration
• , negotiation,
• specification,
• and validation.
• Each of these software engineering actions would have many work tasks and a number of
distinct work products.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
8
Identifying a Task Set
• A task set defines the actual work to be done to accomplish the
objectives of a software engineering action.
• Each software engineering action (e.g., elicitation, an action associated
with the communication activity) 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.
• A list of the task to be accomplished(Choose a task set that best accommodates the
needs of the project and the characteristics of team)
• A list of the work products to be produced
• A list of the quality assurance filters to be applied
4 April 2021
Prepared By: Najaf Ali Khan Balouch
9
• A task set defines the actual work to be done to accomplish the objectives of
a software engineering action. For example, elicitation (more commonly
called “requirements gathering”) is an important software engineering
action that occurs during the communication activity.
• The goal of requirements gathering is to understand what various
stakeholders want from the software that is to be built. For a small, relatively
simple project, the task set for requirements gathering might look like this:
• 1. Make a list of stakeholders for the project.
• 2. Invite all stakeholders to an informal meeting.
• 3. Ask each stakeholder to make a list of features and functions required.
• 4. Discuss requirements and build a final list.
• 5. Prioritize requirements.
• 6. Note areas of uncertainty.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
10
Large Project
• For a larger, more complex software project, a different task set would be required. It
might encompass the following work tasks:
• 1. Make a list of stakeholders for the project.
• 2. Interview each stakeholder separately to determine overall wants and needs.
• 3. Build a preliminary list of functions and features based on stakeholder input.
• 4. Schedule a series of facilitated application specification meetings.
• 5. Conduct meetings.
• 6. Produce informal user scenarios as part of each meeting.
• 7. Refine user scenarios based on stakeholder feedback.
• 8. Build a revised list of stakeholder requirements.
• 9. Use quality function deployment techniques to prioritize requirements.
• 10. Package requirements so that they can be delivered incrementally.
• 11. Note constraints and restrictions that will be placed on the system.
• 12. Discuss methods for validating the system. Both of these task sets achieve
“requirements gathering,” but they are quite different in their depth and formality. The
software team chooses the task set that will allow it to achieve the goal of each action and
still maintain quality and agility.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
11
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 pattern1 describes a process-related problem that is
encountered during software engineering work
• identifies the environment in which the problem has been
encountered.
• 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. By combining
patterns, a software team can solve problems and construct a
process that best meets the needs of a project.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
12
• Patterns can be defined at any level of abstraction.2 In some cases, a
pattern might be used to describe a problem (and solution)
associated with a complete process model (e.g., prototyping).
• In other situations, patterns can be used to describe a problem (and
solution) associated with a framework activity (e.g., planning) or an
action within a framework activity (e.g., project estimating).
• Ambler [Amb98] has proposed a template for describing a process
pattern:
4 April 2021
Prepared By: Najaf Ali Khan Balouch
13
◼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.
◼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. There are three types:
4 April 2021
Prepared By: Najaf Ali Khan Balouch
14
Process Pattern Types
• Stage Pattern . Defines a problem associated with a framework
activity for the process. Since a framework activity encompasses
multiple actions and work tasks, a stage pattern incorporates multiple
task patterns (see the following) that are relevant to the stage
(framework activity)..
◼An example of a stage pattern might be Establishing Communication. This
pattern 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. (An example of a phase pattern might be Spiral Model or Prototyping)
4 April 2021
Prepared By: Najaf Ali Khan Balouch
15
Process Assessment and Improvement
• Software process cannot guarantee that software will be delivered
on time, meet the needs, or has the desired technical
characteristics. However, the process can be assessed to ensure that
it meets a set of basic process criteria that have been shown to be
essential for a successful software engineering.
• In addition, the process itself can be assessed to ensure that it
meets a set of basic process criteria that have been shown to be
essential for a successful software engineering.
• A number of different approaches to software process assessment
and improvement have been proposed over the past few decades:
4 April 2021
Prepared By: Najaf Ali Khan Balouch
16
Process Assessment and Improvement
• Standard CMMI Assessment Method for Process Improvement (SCAMPI) —
provides a five step process assessment model that incorporates five phases:
initiating, diagnosing, establishing, acting and learning.
• CMM-Based Appraisal for Internal Process Improvement (CBA IPI)—provides a
diagnostic technique for assessing the relative maturity of a software organization;
uses the SEI CMM as the basis for the assessment
• —The SPICE (ISO/IEC15504) standard defines a set of requirements for software
process assessment. The intent of the standard is to assist organizations in
developing an SPICEobjective evaluation of the efficacy of any defined software
process.
• ISO 9001:2000 for Software—a generic standard that applies to any organization
that wants to improve the overall quality of the products, systems, or services that
it provides. Therefore, the standard is directly applicable to software organizations
and companies.
Prepared By: Najaf Ali Khan Balouch
4 April 2021
17
Prescriptive Process Models
• Prescriptive process models advocate an orderly approach to
software engineering
That leads to a few questions …
• If prescriptive process models strive for structure and order, are they
inappropriate for a software world that thrives on change?
• Yet, if we reject traditional process models (and the order they imply)
and replace them with something less structured, do we make it
impossible to achieve coordination and coherence in software work?
4 April 2021
Prepared By: Najaf Ali Khan Balouch
18
1. The Waterfall Model
Communication
project init iat ion
requirement gat hering
4 April 2021
Planning
estimating
scheduling
tracking
Modeling
analysis
design
Prepared By: Najaf Ali Khan Balouch
Construction
code
test
Deployment
delivery
support
f eedback
19
The Waterfall Model…..
• There are times when the requirements for a problem are well understood—
when work flows from communication through deployment in a reasonably
linear fashion. This situation is sometimes encountered when well-defined
adaptations or enhancements to an existing system must be made (e.g., an
adaptation to accounting software that has been mandated because of
changes to government regulations). It may also occur in a limited number of
new development efforts, but only when requirements are well defined and
reasonably stable.
• 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, culminating in ongoing support of the completed software .
• The waterfall model is the oldest paradigm for software engineering. However Among
the problems that are sometimes encountered when the waterfall model is applied
are:
4 April 2021
Prepared By: Najaf Ali Khan Balouch
20
The Waterfall Model…..
1.The main drawback of the waterfall is the difficulty of accommodating change after the process is
underway.
2. Real projects rarely follow the sequential flow that the model proposes. Although the
linear model can accommodate iteration, it does so indirectly. As a result, changes can
cause confusion as the project team proceeds.
3. It is often difficult for the customer to state all requirements explicitly. The
waterfall model requires this and has difficulty accommodating the natural
uncertainty that exists at the beginning of many projects.
4. The customer must have patience. A working version of the program(s) will
not be available until late in the project time span. A major blunder, if undetected
until the working program is reviewed, can be disastrous.
The waterfall model is mostly used for large system engineering project where a system is
developed at several sites
4 April 2021
Prepared By: Najaf Ali Khan Balouch
21
• The classic life cycle leads to “blocking states” in which some project team
members must wait for other members of the team to complete
dependent tasks. In fact, the time spent waiting can exceed the time spent
on productive work.
• Today, software work is fast-paced and subject to a never-ending stream of
changes (to features, functions, and information content). The waterfall
model is often inappropriate for such work.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
22
Waterfall Model - Application
• Every software developed is different and requires a suitable SDLC
approach to be followed based on the internal and external factors.
Some situations where the use of Waterfall model is most
appropriate are −
• Requirements are very well documented, clear and fixed.
• Product definition is stable.
• Technology is understood and is not dynamic.
• There are no ambiguous requirements.
• Ample resources with required expertise are available to support the
product.
• The project is short.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
23
Waterfall Model - Advantages
• The advantages of waterfall development are that it allows for departmentalization and
control. A schedule can be set with deadlines for each stage of development and a product
can proceed through the development process model phases one by one.
• Development moves from concept, through design, implementation, testing, installation,
troubleshooting, and ends up at operation and maintenance. Each phase of development
proceeds in strict order.
• Some of the major advantages of the Waterfall Model are as follows −
• Simple and easy to understand and use
• Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a
review process.
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements are very well understood.
• Clearly defined stages.
• Well understood milestones.
• Easy to arrange tasks.
• Process and results are well documented.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
24
Waterfall Model - Disadvantages
• The disadvantage of waterfall development is that it does not allow much
reflection or revision. Once an application is in the testing stage, it is very
difficult to go back and change something that was not well-documented or
thought upon in the concept stage.
• The major disadvantages of the Waterfall Model are as follows −
• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high risk
of changing. So, risk and uncertainty is high with this process model.
• It is difficult to measure progress within stages.
• Cannot accommodate changing requirements.
• Adjusting scope during the life cycle can end a project.
• Integration is done as a "big-bang. at the very end, which doesn't allow
identifying any technological or business bottleneck or challenges early.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
25
The V-Model
• A variation in the representation of the waterfall model is called the V-model. Represented
in Figure 2.4, the V-model [Buc99] depicts the relationship of quality assurance actions to
the actions associated with communication, modeling, and early construction activities.
• As a software team moves down the left side of the V, basic problem requirements are
refined into progressively more detailed and technical representations of the problem and
its solution.
• Once code has been generated, the team moves up the right side of the V, essentially
performing a series of tests (quality assurance actions) that validate each of the models
created as the team moved down the left side.
• In reality, there is no fundamental difference between the classic life cycle and the Vmodel. The V-model provides a way of visualizing how verification and validation actions
are applied to earlier engineering work.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
26
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.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
27
• The V-model is an SDLC model where execution of processes
happens in a sequential manner in a V-shape. It is also known
as Verification and Validation model.
• The V-Model is an extension of the waterfall model and is based on
the association of a testing phase for each corresponding
development stage.
• This means that for every single phase in the development cycle,
there is a directly associated testing phase.
• This is a highly-disciplined model and the next phase starts only after
completion of the previous phase.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
28
Business Requirement Analysis
• This is the first phase in the development cycle where the product
requirements are understood from the customer’s perspective. This
phase involves detailed communication with the customer to
understand his expectations and exact requirement. This is a very
important activity and needs to be managed well, as most of the
customers are not sure about what exactly they need.
The acceptance test design planning is done at this stage as business
requirements can be used as an input for acceptance testing.
• System Design
• Once you have the clear and detailed product requirements, it is time
to design the complete system. The system design will have the
understanding and detailing the complete hardware and
communication setup for the product under development. The
system test plan is developed based on the system design. Doing this
at an earlier stage leaves more time for the actual test execution
later.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
29
Architectural Design
• Architectural specifications are understood and designed in this
phase. Usually more than one technical approach is proposed and
based on the technical and financial feasibility the final decision is
taken. The system design is broken down further into modules taking
up different functionality. This is also referred to as High Level Design
(HLD).
• The data transfer and communication between the internal modules
and with the outside world (other systems) is clearly understood and
defined in this stage. With this information, integration tests can be
designed and documented during this stage.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
30
Module Design
• In this phase, the detailed internal design for all the system modules
is specified, referred to as Low Level Design (LLD). It is important that
the design is compatible with the other modules in the system
architecture and the other external systems. The unit tests are an
essential part of any development process and helps eliminate the
maximum faults and errors at a very early stage. These unit tests can
be designed at this stage based on the internal module designs.
• Coding Phase
• The actual coding of the system modules designed in the design
phase is taken up in the Coding phase. The best suitable
programming language is decided based on the system and
architectural requirements.
• The coding is performed based on the coding guidelines and
standards. The code goes through numerous code reviews and is
optimized for best performance before the final build is checked into
the repository.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
31
Validation Phases
• The different Validation Phases in a V-Model are explained in detail
below.
• Unit Testing
• Unit tests designed in the module design phase are executed on the
code during this validation phase. Unit testing is the testing at code
level and helps eliminate bugs at an early stage, though all defects
cannot be uncovered by unit testing.
• Integration Testing
• Integration testing is associated with the architectural design phase.
Integration tests are performed to test the coexistence and
communication of the internal modules within the system.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
32
System Testing
• System testing is directly associated with the system design phase.
System tests check the entire system functionality and the
communication of the system under development with external
systems. Most of the software and hardware compatibility issues can
be uncovered during this system test execution.
• Acceptance Testing
• Acceptance testing is associated with the business requirement
analysis phase and involves testing the product in user environment.
Acceptance tests uncover the compatibility issues with the other
systems available in the user environment. It also discovers the nonfunctional issues such as load and performance defects in the actual
user environment.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
33
V- Model ─ Application
• V- Model application is almost the same as the waterfall model, as
both the models are of sequential type. Requirements have to be
very clear before the project starts, because it is usually expensive to
go back and make changes. This model is used in the medical
development field, as it is strictly a disciplined domain.
• The following pointers are some of the most suitable scenarios to use
the V-Model application.
• Requirements are well defined, clearly documented and fixed.
• Product definition is stable.
• Technology is not dynamic and is well understood by the project
team.
• There are no ambiguous or undefined requirements.
• The project is short.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
34
V-Model - Pros and Cons
• The advantage of the V-Model method is that it is very easy to
understand and apply. The simplicity of this model also makes it
easier to manage. The disadvantage is that the model is not flexible
to changes and just in case there is a requirement change, which is
very common in today’s dynamic world, it becomes very expensive to
make the change.
• The advantages of the V-Model method are as follows −
• This is a highly-disciplined model and Phases are completed one at a
time.
• Works well for smaller projects where requirements are very well
understood.
• Simple and easy to understand and use.
• Easy to manage due to the rigidity of the model. Each phase has
specific deliverables and a review process.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
35
The disadvantages of the V-Model method are as follows −
• High risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate
to high risk of changing.
• Once an application is in the testing stage, it is difficult to go back and
change a functionality.
• No working software is produced until late during the life cycle.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
36
2. The Incremental Model
4 April 2021
Prepared By: Najaf Ali Khan Balouch
37
Incremental Model
• Incremental Model is a process of software development where
requirements divided into multiple standalone modules of the
software development cycle.
• In this model, each module goes through the requirements, design,
implementation and testing phases.
• Every subsequent release of the module adds function to the
previous release.
• The process continues until the complete system achieved.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
38
Diagram
4 April 2021
Prepared By: Najaf Ali Khan Balouch
39
The Incremental Model
• When initial requirements are reasonably well defined, but the
overall scope of the development effort preclude 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.
• Early increments are stripped-down versions of the final product, but
they do provide capability that serves the user and also provide
platform for evaluation by the user.
•
4 April 2021
Prepared By: Najaf Ali Khan Balouch
40
The Incremental Model
• 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.
.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
41
The various phases of incremental model are as follows:
• 1. Requirement analysis: In the first phase of the incremental model,
the product analysis expertise identifies the requirements. And the
system functional requirements are understood by the requirement
analysis team. To develop the software under the incremental model,
this phase performs a crucial role.
• 2. Design & Development: In this phase of the Incremental model of
SDLC, the design of the system functionality and the development
method are finished with success. When software develops new
practicality, the incremental model uses style and development
phase.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
42
The various phases of incremental model are as follows:
• 3. Testing: In the incremental model, the testing phase checks the
performance of each existing function as well as additional
functionality. In the testing phase, the various methods are used to
test the behavior of each task.
• 4. Implementation: Implementation phase enables the coding phase
of the development system. It involves the final coding that design in
the designing and development phase and tests the functionality in
the testing phase. After completion of this phase, the number of the
product working is enhanced and upgraded up to the final system
product
4 April 2021
Prepared By: Najaf Ali Khan Balouch
43
When we use the Incremental Model?
• When the requirements are superior.
• A project has a lengthy development schedule.
• When Software team are not very well skilled or trained.
• When the customer demands a quick release of the product.
• You can develop prioritized requirements first.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
44
Advantage and Disadvantage
• Errors are easy to be recognized.
• Easier to test and debug
• More flexible.
• Simple to manage risk because it handled during its iteration.
• The Client gets important functionality early.
• Disadvantage of Incremental Model
• Need for good planning
• Total Cost is high.
• Well defined module interfaces are needed.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
45
3. Evolutionary Models: Prototyping
p l an
Q u i ck
Quick
Co m m u n icat io n
plan
communication
e lin g
Mo dModeling
d e si g n
Q u i ck
Quick
design
Deployment
Deployment
y
live r &
D edelivery
Fe e d b ack
& feedback
Co n st r u ct io n
Construction
Construction
of
of prototype of prototype
p r o t o t yp e
4 April 2021
Prepared By: Najaf Ali Khan Balouch
46
What is Prototyping Model?
• Prototyping Model is a software development model in which
prototype is built, tested, and reworked until an acceptable
prototype is achieved. It also creates base to produce the final system
or software. It works best in scenarios where the project's
requirements are not known in detail. It is an iterative, trial and error
method which takes place between developer and client.
• Prototyping Model has following six SDLC phases as follow:
4 April 2021
Prepared By: Najaf Ali Khan Balouch
47
Evolutionary Models
• Software system evolves over time as requirements often change as
development proceeds. Thus, a straight line to a complete end product is not
possible. However, a limited version must be delivered to meet competitive
pressure.
• Usually a set of core product or system requirements is well understood, but
the details and extension have yet to be defined.
• You need a process model that has been explicitly designed to accommodate
a product that evolved over time.
• It is iterative that enables you to develop increasingly more complete version
of the software.
• Two types are introduced, namely Prototyping and Spiral models.
48
4 April 2021
Prepared By: Najaf Ali Khan Balouch
Evolutionary Models: Prototyping
• When to use: Customer defines a set of general objectives but does not identify
detailed requirements for functions and features. Or Developer may be unsure of the
efficiency of an algorithm, the form that human computer interaction should take.
• What step: Begins with communication by meeting with stakeholders to define the
objective, identify whatever requirements are known, outline areas where further
definition is mandatory. A quick plan for prototyping and modeling (quick design) occur.
Quick design focuses on a representation of those aspects the software that will be
visible to end users. ( interface and output). Design leads to the construction of a
prototype which will be deployed and evaluated. Stakeholder’s comments will be used
to refine requirements.
• Both stakeholders and software engineers like the prototyping paradigm. Users get a
feel for the actual system, and developers get to build something immediately.
However, engineers may make compromises in order to get a prototype working
quickly. The less-than-ideal choice may be adopted forever after you get used to it.
49
4 April 2021
Prepared By: Najaf Ali Khan Balouch
Step 1: Requirements gathering and analysis
• A prototyping model starts with requirement analysis. In this phase,
the requirements of the system are defined in detail. During the
process, the users of the system are interviewed to know what is
their expectation from the system.
• Step 2: Quick design
• The second phase is a preliminary design or a quick design. In this
stage, a simple design of the system is created. However, it is not a
complete design. It gives a brief idea of the system to the user. The
quick design helps in developing the prototype.
• Step 3: Build a Prototype
• In this phase, an actual prototype is designed based on the
information gathered from quick design. It is a small working model
of the required system.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
50
Step 4: Initial user evaluation
• In this stage, the proposed system is presented to the client for an
initial evaluation. It helps to find out the strength and weakness of
the working model. Comment and suggestion are collected from the
customer and provided to the developer.
• Step 5: Refining prototype
• If the user is not happy with the current prototype, you need to
refine the prototype according to the user's feedback and
suggestions.
• This phase will not over until all the requirements specified by the
user are met. Once the user is satisfied with the developed
prototype, a final system is developed based on the approved final
prototype.
• Step 6: Implement Product and Maintain
• Once the final system is developed based on the final prototype, it is thoroughly
tested and deployed to production. The system undergoes routine maintenance
for minimizing downtime and prevent large-scale failures.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
51
Types of Prototyping Models
• Four types of Prototyping models are:
• Rapid Throwaway prototypes
• Evolutionary prototype
• Incremental prototype
• Extreme prototype
4 April 2021
Prepared By: Najaf Ali Khan Balouch
52
Types of Prototyping Models
• Rapid Throwaway Prototype
• Rapid throwaway is based on the preliminary requirement. It is quickly
developed to show how the requirement will look visually. The
customer's feedback helps drives changes to the requirement, and the
prototype is again created until the requirement is baselined.
• In this method, a developed prototype will be discarded and will not be a
part of the ultimately accepted prototype. This technique is useful for
exploring ideas and getting instant feedback for customer requirements.
• Evolutionary Prototyping
• Here, the prototype developed is incrementally refined based on
customer's feedback until it is finally accepted. It helps you to save time
as well as effort. That's because developing a prototype from scratch for
every interaction of the process can sometimes be very frustrating.
• This model is helpful for a project which uses a new technology that is
not well understood. It is also used for a complex project where every
functionality must be checked once. It is helpful when the requirement is
not stable or not understood clearly at the initial stage.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
53
Types of Prototyping Models
• Incremental Prototyping
• In incremental Prototyping, the final product is decimated into different
small prototypes and developed individually. Eventually, the different
prototypes are merged into a single product. This method is helpful to
reduce the feedback time between the user and the application
development team.
• Extreme Prototyping:
• Extreme prototyping method is mostly used for web development. It is
consists of three sequential phases.
• Basic prototype with all the existing page is present in the HTML format.
• You can simulate data process using a prototype services layer.
• The services are implemented and integrated into the final prototype.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
54
Best practices of Prototyping
• Here, are a few things which you should watch for during the prototyping
process:
• You should use Prototyping when the requirements are unclear
• It is important to perform planned and controlled Prototyping.
• Regular meetings are vital to keep the project on time and avoid costly delays.
• The users and the designers should be aware of the prototyping issues and
pitfalls.
• At a very early stage, you need to approve a prototype and only then allow the
team to move to the next step.
• In software prototyping method, you should never be afraid to change earlier
decisions if new ideas need to be deployed.
• You should select the appropriate step size for each version.
• Implement important features early on so that if you run out of the time, you
still have a worthwhile system
4 April 2021
Prepared By: Najaf Ali Khan Balouch
55
Advantages of the Prototyping Model
• Users are actively involved in development. Therefore, errors can be
detected in the initial stage of the software development process.
• Missing functionality can be identified, which helps to reduce the risk
of failure as Prototyping is also considered as a risk reduction activity.
• Helps team member to communicate effectively
• Customer satisfaction exists because the customer can feel the
product at a very early stage.
• There will be hardly any chance of software rejection.
• Quicker user feedback helps you to achieve better software
development solutions.
• Allows the client to compare if the software code matches the
software specification.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
56
Advantages of the Prototyping Model
• It helps you to find out the missing functionality in the system.
• It also identifies the complex or difficult functions.
• Encourages innovation and flexible designing.
• It is a straight forward model, so it is easy to understand.
• No need for specialized experts to build the model
• The prototype serves as a basis for deriving a system specification.
• The prototype helps to gain a better understanding of the customer's
needs.
• Prototypes can be changed and even discarded.
• A prototype also serves as the basis for operational specifications.
• Prototypes may offer early training for future users of the software
system.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
57
Disadvantages of the Prototyping Model
• Here, are important cons/drawbacks of prototyping model:
• Prototyping is a slow and time taking process.
• The cost of developing a prototype is a total waste as the prototype is
ultimately thrown away.
• Prototyping may encourage excessive change requests.
• Some times customers may not be willing to participate in the
iteration cycle for the longer time duration.
• There may be far too many variations in software requirements when
each time the prototype is evaluated by the customer.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
58
Disadvantages of the Prototyping Model
• Poor documentation because the requirements of the customers are
changing.
• It is very difficult for software developers to accommodate all the
changes demanded by the clients.
• After seeing an early prototype model, the customers may think that
the actual product will be delivered to him soon.
• The client may lose interest in the final product when he or she is not
happy with the initial prototype.
• Developers who want to build prototypes quickly may end up
building sub-standard development solutions.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
59
The Spiral Model
• Spiral model is one of the most important Software Development Life
Cycle models, which provides support for Risk Handling. In its
diagrammatic representation, it looks like a spiral with many loops. The
exact number of loops of the spiral is unknown and can vary from project
to project. Each loop of the spiral is called a Phase of the software
development process. The exact number of phases needed to develop
the product can be varied by the project manager depending upon the
project risks. As the project manager dynamically determines the
number of phases, so the project manager has an important role to
develop a product using the spiral model.
• The Radius of the spiral at any point represents the expenses(cost) of the
project so far, and the angular dimension represents the progress made
so far in the current phase.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
60
Evolutionary Models: The Spiral
•
It couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall
model and is a risk-driven process model generator that is used to guide multi-stakeholder concurrent
engineering of software intensive systems.
•
Two main distinguishing features: one is 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.
•
A series of evolutionary releases are delivered. During the early iterations, the release might be a model
or prototype. During later iterations, increasingly more complete version of the engineered system are
produced.
•
The first circuit in the clockwise direction might result in the 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 results in adjustments to the project plan. Cost and schedule are
adjusted based on feedback. Also, the number of iterations will be adjusted by project manager.
•
Good to develop large-scale system as software evolves as the process progresses and risk should be
understood and properly reacted to. Prototyping is used to reduce risk.
•
However, it may be difficult to convince customers that it is controllable as it demands considerable risk
assessment expertise.
61
4 April 2021
Prepared By: Najaf Ali Khan Balouch
Evolutionary Models: The Spiral
planning
estimation
scheduling
risk analysis
communication
modeling
analysis
design
start
deployment
delivery
feedback
4 April 2021
Prepared By: Najaf Ali Khan Balouch
construction
code
test
62
• Each phase of the Spiral Model is divided into four quadrants as
shown in the above figure. The functions of these four quadrants are
discussed above-
4 April 2021
Prepared By: Najaf Ali Khan Balouch
63
• Objectives determination and identify alternative solutions: Requirements are
gathered from the customers and the objectives are identified, elaborated, and
analyzed at the start of every phase. Then alternative solutions possible for the
phase are proposed in this quadrant.
• Identify and resolve Risks: During the second quadrant, all the possible solutions
are evaluated to select the best possible solution. Then the risks associated with
that solution are identified and the risks are resolved using the best possible
strategy. At the end of this quadrant, the Prototype is built for the best possible
solution.
• Develop next version of the Product: During the third quadrant, the identified
features are developed and verified through testing. At the end of the third
quadrant, the next version of the software is available.
• Review and plan for the next Phase: In the fourth quadrant, the Customers
evaluate the so far developed version of the software. In the end, planning for
the next phase is started.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
64
Risk Handling in Spiral Model
•
A risk is any adverse situation that might affect the successful
completion of a software project. The most important feature of the
spiral model is handling these unknown risks after the project has
started. Such risk resolutions are easier done by developing a prototype.
The spiral model supports coping up with risks by providing the scope to
build a prototype at every phase of the software development.
• The Prototyping Model also supports risk handling, but the risks must be
identified completely before the start of the development work of the
project. But in real life project risk may occur after the development
work starts, in that case, we cannot use the Prototyping Model. In each
phase of the Spiral Model, the features of the product dated and
analyzed, and the risks at that point in time are identified and are
resolved through prototyping. Thus, this model is much more flexible
compared to other SDLC models.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
65
Why Spiral Model is called Meta Model?
•
The Spiral model is called a Meta-Model because it subsumes all the
other SDLC models. For example, a single loop spiral actually
represents the Iterative Waterfall Model. The spiral model
incorporates the stepwise approach of the Classical Waterfall Model.
The spiral model uses the approach of the Prototyping Model by
building a prototype at the start of each phase as a risk-handling
technique. Also, the spiral model can be considered as supporting the
evolutionary model – the iterations along the spiral can be
considered as evolutionary levels through which the complete system
is built.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
66
Advantages of Spiral Model:
Below are some advantages of the Spiral Model.
• Risk Handling: The projects with many unknown risks that occur as the
development proceeds, in that case, Spiral Model is the best development model
to follow due to the risk analysis and risk handling at every phase.
• Good for large projects: It is recommended to use the Spiral Model in large and
complex projects.
• Flexibility in Requirements: Change requests in the Requirements at later phase
can be incorporated accurately by using this model.
• Customer Satisfaction: Customer can see the development of the product at the
early phase of the software development and thus, they habituated with the
system by using it before completion of the total product.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
67
Disadvantages of Spiral Model:
Below are some main disadvantages of the spiral model.
• Complex: The Spiral Model is much more complex than other SDLC
models.
• Expensive: Spiral Model is not suitable for small projects as it is
expensive.
• Too much dependability on Risk Analysis: The successful completion
of the project is very much dependent on Risk Analysis. Without very
highly experienced experts, it is going to be a failure to develop a
project using this model.
• Difficulty in time management: As the number of phases is unknown
at the start of the project, so time estimation is very difficult.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
68
Evolutionary Models: Concurrent
4 April 2021
Prepared By: Najaf Ali Khan Balouch
69
Still Other Process Models
• Component based development—the process to apply when
reuse is a development objective
• Formal methods—emphasizes the mathematical specification of
requirements
• AOSD—provides a process and methodological approach for
defining, specifying, designing, and constructing aspects
• Unified Process—a “use-case driven, architecture-centric,
iterative and incremental” software process closely aligned with
the Unified Modeling Language (UML)
4 April 2021
Prepared By: Najaf Ali Khan Balouch
70
The Unified Process (UP)
4 April 2021
Prepared By: Najaf Ali Khan Balouch
71
UP Phases
UP Phases
Incept ion
Elaborat ion
Const ruct ion
Transit ion
Product ion
Workflows
Requirements
Analysis
Design
Implementation
Test
Support
Iterations
4 April 2021
#1
#2
Prepared By: Najaf Ali Khan Balouch
#n-1
#n
72
UP Work Products
Incept ion phase
Vision document
Init ial use-case model
Init ial project glossary
Init ial business case
Init ial risk assessment .
Project plan,
phases and it erat ions.
Business model,
if necessary .
One or more prot ot y pes
I nc e pt i o
n
4 April 2021
Elaborat ion phase
Use-case model
Supplement ary requirement s
including non-funct ional
Analy sis model
Soft ware archit ect ure
Descript ion.
Execut able archit ect ural
prot ot y pe.
Preliminary design model
Rev ised risk list
Project plan including
it erat ion plan
adapt ed workflows
milest ones
t echnical work product s
Preliminary user manual
Prepared By: Najaf Ali Khan Balouch
Const ruct ion phase
Design model
Soft ware component s
Int egrat ed soft ware
increment
Test plan and procedure
Test cases
Support document at ion
user manuals
inst allat ion manuals
descript ion of current
increment
Transit ion phase
Deliv ered soft ware increment
Bet a t est report s
General user feedback
73
Personal Software Process (PSP)
• Planning. This activity isolates requirements and develops both size and resource estimates. In
addition, a defect estimate (the number of defects projected for the work) is made. All metrics
are recorded on worksheets or templates. Finally, development tasks are identified and a
project schedule is created.
• High-level design. External specifications for each component to be constructed are developed
and a component design is created. Prototypes are built when uncertainty exists. All issues are
recorded and tracked.
• High-level design review. Formal verification methods (Chapter 21) are applied to uncover
errors in the design. Metrics are maintained for all important tasks and work results.
• Development. The component level design is refined and reviewed. Code is generated,
reviewed, compiled, and tested. Metrics are maintained for all important tasks and work
results.
• Postmortem. Using the measures and metrics collected (this is a substantial amount of data
that should be analyzed statistically), the effectiveness of the process is determined. Measures
and metrics should provide guidance for modifying the process to improve its effectiveness.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
74
Team Software Process (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 (IPT) of three 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 Level
5 behavior normal and expected.
• The Capability Maturity Model (CMM), a measure of the effectiveness of a
software process, is discussed in Chapter 30.
• Provide improvement guidance to high-maturity organizations.
• Facilitate university teaching of industrial-grade team skills.
4 April 2021
Prepared By: Najaf Ali Khan Balouch
75