0% found this document useful (0 votes)
25 views9 pagesSoftware Process Models
Software Process Models
Uploaded by
Usman Faizyab KhanCopyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
0% found this document useful (0 votes)
25 views9 pagesSoftware Process Models
Software Process Models
Uploaded by
Usman Faizyab KhanCopyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
/ 9
co) (CAsiH er Cr’
Chapter Two
Software Process Model
Chapter Two
” Software Process Model”
: ase sks and
A topical process model covers the whole ofthe lifecycle and clearly defines each phase eas eet
activites tobe performed within that phase as well as those activities that are continuous throughe eal
cycle. In essence, each stage of the software process is identified and a model is then employe
the inherent activities associated within that stage.
Parties involved in Software Development:
Developer-who builds the software.
Client who pays for software.
User — Those who utilize the software.
Software Process Models:
BUILD-AND-FL
The product is built without proper specifications an design steps. In [aga
essence, the product is built and modified as many times as possible
‘until it satisfies the client. The cost of using this approach is greater L_ [rer
than if specifications are drawn up and a design is carefully developed.
Software engineers are strongly discouraged frum using this
development approach. May be adequate for short programming os
practices. == feet fa
IE WATERFALL
‘The waterfall model derives its name due to the
cascading effect from one phase to the other as is
illustrated in Figure. In this model each phase
welt defined starting and ending point, with
identifiable deliveries to the next phase. This ——————
model is sometimes referred to as the linear |_““sam
sequential model or the software life cycle Cie
The model consist of six distinct stages, namely:
1. In the requirements analysis phase
(a) The problem is specified along with the
desired service objectives (goals)
(©) The constraints are identified
2. In the specification phase the system
specification is produced from the detailed
definitions of (a) and (b) above. This document
should clearly define the product function.
‘Note that in some text, the requirements analysis
and specifications phases are combined and
represented as a single phase.
3.In the system and software design phase, the
system specifications are translated into a
software representation. The software engineer
at this stage is concemed with:
+ Data structure
* Software architecture
Software Engineering
Page 1 of 9
Scanned with CamScanner Chapter Two
Software Process Model
+ Algorithmic detail
+ _ Interface representa og determined at this stage along with a picture of the overall system
Te Ee easy this stage the software engineer should be able to identify the relationship
een er thcase, software and the associated interfaces. Any faults in the specification should
ideally not be passed ‘down stream”
ia oe apinmentation and testing Phase stage, the designs are translated into the software domain
- Detailed documentation from the design phase can significantly reduce the coding effort.
Testing at this stage focuses on making sure that any errors ate identified and that the
software meets its required specification,
5. Inthe integration and system testing phase all the program units are integrated and tested to ensure
that the complete system meets the software requirements. Adter this stage the software is delivered to the
customer [Deliverable - The software product is delivered to the client for acceptance testing.)
6 The maintenance phase is usually the longest stage of the software. In this phase the software is
updated to:
+ Meet the changing customer needs
‘+ Adapted to accommodate changes in the external environment
+ Correct errors and oversights previously undetected in the testing phases
‘+ Enhancing the efficiency of the software
Observe that feedback loops allow the corrections to be incorporated into the model. For example a
problem / update in the design phase requires a ‘revisit’ to the specifications phase. When changes are
made at any phase, the relevant documentation should be updated to reflect that change.
Advantages
+ Testing is inherent to every phase of the waterfall model
+ Itis an enforced disciplined approach.
‘+ It is documentation driven, that is, documentation is produced at every stage i.e. high
visibility.
Disadvantages
The waterfall model is the oldest ‘and the_~—most' widely used _ paradigm.
However, many projects rarely follow its sequential flow. This is due to the inherent problems associated
with its rigid format. Namely:
+ Itonly incorporates iteration indirectly, thus changes may cause considerable confusion as the
Project progresses.
+ As The client usually only has a vague idea of exactly what is required from the software
Product, this WM has difficulty accommodating the natural uncertainty that exists at the
beginning of the project,
* The customer only sees a working version of the product after it has been coded. This may
result in disaster if any undetected problems are precipitated to this stage.
PROTOTYPING MODEL:
Definition: A prototype is a working model that is functionally equivalent to a component of the product.
In many instances the client only has a general view of what is expected from the software product. In
such a scenario where there is an absence of detailed information regarding the input to the system, the
Processing needs and the output requirements, the prototyping model may be employed. This model
reflects an attempt to increase the flexibility of the development process by allowing the client to interact
and experiment with a working representation of the product. The developmental process only continues
once the client is satisfied with the functioning of the prototype. At that stage the developer determines
the specifications of the client's real needs,
The two (2) version of the prototyping model;
elon Reso Pate Pte ca cements cae
- ‘Peis used as the specifications or a major part thereof,
Software Engineering Page 2 of 9
Scanned with CamScanner Chapter Two
Software Process Model
This uses the prototype coed
as a means of quickly
determining the needs of nn
the client it is discarded =a
once the specifications va Tye cane
have been agreed on. The beens onto)
emphasis ofthe
Prototype ison
representing those
aspects of the software
that will be visible to the
dienvuser (eg. input
approaches and output
formats). Thus it does not
matter if the prototype
hardly works.
Note that if the first §=——>
version of the prototype
does not meet the client's
needs, then it must be
rapidly converted into a
second version.
‘Reuse of Prototype:
In this approach, the prototype
is actually used gs the
specifications for the design
phase. This advantage of this
approach is speed and accuracy,
4 not time is spent on drawing
up written specifications. The
inherent difficulties associated
with that phase (ie.
incompleteness, contradictions
and ambiguities) are then
avoided.
Disadvantages of prototyping
1. Often clients expect that a few minor changes to the
They fail to realise that no consideration was given to
to develop the prototype.
Prototype will more than suffice their needs.
the overall quality of the software in the rush
Software Engineering
a! Page 3 of 9
Scanned with CamScanner Chapter Two
Software Process Model
2, The developers may lose focus on the real purpose of the prototype and compromise the quality of
the product. For example, they may employ some of the inefficient algorithms or inappropriate
programming languages used in developing the profotyPe- This mainly due to laziness and an over
Pence on familiarity with seemingly easier methods.
3. A pootsiyya wil handy be acceptable in covst ia the cant that the SEs does not agree that the
developer has discharged his/her obligations. For this reason using the prototype as the software
specification is normally reserved for software development within an organisation,
To arid the above problems the developer and the client should both establish 2 protocol, which
indicates the deliverables to the client as well as contractual obligations.
In both versions the prototype is discarded early in the life cycle. However, one way of ensuing that the
product is propery designed and implemented is to implement the prototype in a different programming
Tanguage from that of the product.
Ral EL:
‘Rapid Application Development (RAD) is an incremental software development process model that
emphasises a very short development cycle [typically 60-90 days}.” The RAD model, shown in Fig, 1.5, is a
high-speed adaptation of the waterfall model, where the results of each cycle a fully functional system.
oman
tee emuast
Team #1 Bosinese _
ee Bate —
Mods | eae
60.90 days
RAD is used primarily for information ications;
filging phasee ‘ion systems applications; the RAD approach encompasses the
Bu: fe
The information flow among business functions i ;
questions: tions is modeled in a way that answers the following
‘+ Whatinformation drives the business process?
+ What information is generated?
+ Who generates it?
‘© Where does the information go?
+ Who processes it?
Software Engineering
Page 4 of 9
Scanned with CamScanner Chapter Two
Software Process Model
Data modeling obj
The information flow defined as part of the business modeling phase is refined into a set of eed
that are needed to support the business. The characteristics (called attributes) of each object are ¥
and the relationships between these objects are defined.
Process modeling i i tion flow
The data objects defined in the data-modeling phase are transformed to achieve the informatio®
necessary to implement a business function. Processing descriptions are created for adding, modifying,
deleting, or retrieving a data object.
Application generati
ication generation like VB, VC+, Delphi ete,
RAD assumes the use of the RAD fourth generation techniques and tools, lik —
rather than creating software using conventional third generation programming languages. The
works to reuse existing program components (when possible) or create reusable components (when
necessary), In all cases, automated tools are used to facilitate construction of the software.
Testing and turnover
Since the RAD process emphasizes reuse, many cf th. program components have already been tested.
This minimizes the testing and development time. | | ‘thin th
If a business application can be modularized so that each major function can be completed within the
development cycle then it is a candidate for the RAD model. In this case, each team can be assigned a
model, which is then integrated to form a whole.
Disadvantages :
«For Large (but scalable) projects, RAD requires sufficient resources to create the right number of
RAD teams
RAD projects will fail if there is no commitment by the developers or the clients to ‘rapid-fire’
activities necessary to get a system complete in a much abbreviated time frame.
If. system cannot be properly modularized, building components for RAD will be problematic
RAD is not appropriate when technical risks are high, e.g. this occurs when a new application
makes heavy use of new technology.
EVOLUTIONARY PROCESS MODELS:
It is characterised in a manner that enables software engineers to develop more complete versions of
‘software. It includes:
a, Incremental Model
b, Iterative Model
© Spiral model
a. Incremental Model (IM)
This model derives its name from the way in which the software is built. More specifically, the model is
designed, implemented and tested as a series of incremental builds until the product is finished. A build
consists of pieces of code from various modules that interact together to provide a specific function.
At each stage of the IM a new build is coded and then integrated into the structure, which is tested as a
whole. Note that the product is only defined as finished when it satisfies all of its requirements,
This model combines the elements of the waterfall model with the iterative philosophy of Prototyping,
However, unlike prototyping the IM focuses on the delivery of an operational product at the end of each
increment.
An example of this incremental approach is observed in the developm: i icati
where the following services are provided on subsequent builds. of word processing applications
1. Basic file management, editing and document production functions
2, Advanced editing and document production functions
3. Spell and grammar checking
4. Advance page layout
Software Engineerin;
oftwe "gi 1S Page 5 of 9
Scanned with CamScanner Chapter Two
Software Process Model
irements of the system. This
th ce proc ih ds ec develop la fr them
Hen or tot the cove product (0 better meet the needs of the
increment. THs plan 38 ana fanctonality. More specifically at exch stage
co eign sign value to each build not yet implemented
3} The developer estimates costoof developing each build fo
ice oe rein to-enst sat isthe criterion used for selecting which build is delivered next
tially the build with the highest valwe-to-cost ratio is the one that provides the client with the most
Esse ue forthe least est Using this method the cient has a usable product at all of the
insti is usually
‘The first increment is
maybe either be used by the «
development stages.
b. Iterative Development oo
erative model is used to develop a product that has not been fully defined. Here, the project is divided
into small parts. This allows the development team to demonstrate results earlier on in the process and
obtain valuable feedback from system users. Often, each iteration is actually a mini-Waterfall process
with the feedback from one phase providing vital information for the design of the next phase. In a
variation of this model, the software products which are produced at the end of each step (or series of
steps) can go into production immediately as incremental releases. This is in contrast with the Incremental
model, where it was desired to implement in increments, a product that has known requirements and
definition. This model is used where it is required to begin the development quickly and creates a very
early version that will demonstrate the look and feel of the product.
B challenges associated with the Iterative Model
While the Iterative Model addresses many of the problems associated with the Waterfall Model, it does
present new challenges,
The user community needs to be actively involved throughout the project. While this involvement
is a positive for the project, itis demanding on the time of the staff and can add project delay.
Communication and coordination skills take center stage in project development.
Informal requests for improvement after each phase may lead to confusion — a controlled
mechanism for handling substantive requests needs to be developed.
‘The Iterative Model can lead to “scope creep,” since user feedback follow:
to increased customer demands. As users see the system develop,
other system capabilities which would enhance their work,
*
ng each phase may lead
they may realize the potential of
¢. The Spiral Model
The spiral model combines the iterative nature
of prototyping with the controlled and
systematic aspects of the waterfall model, cont? ion
therein providing the potential for rapid
development of incremental versions of the
software. In this model the software is
developed in a series of incremental releases
with the early stages being either paper models
or prototypes. Later iterations become
increasingly more complete versions of the
product.
Consivcton& Falones
As illustrated in Figure, the model is divided i ions,
toan ji
eee into a number of task regions.
aa cht may have 3-6 task regions (frameworW/actvities) above is a
These regions are:
Software Engineering
“G-task region’
Page 6 of 9
Scanned with CamScanner Chapter Two
Software Process Model
ive communication between developer and
1, The customer communication task ~ to establish effect!
customer. P f
‘The planning task - to define resources, time lines and other project related informal
The risk analysis task to assess both technical and management risks
“The engineering task to build one or more representations of the applicatlo™ | (og
The construction and release task - to construc, test, install and prov
documentation and training). .¢ evaluation of the
6. The customer evaluation task - to obtain customer feedback based on Se aieae ian
software representation created during the engineering stage and impleme!
stage. : wise direction. Each traversal
The evolutionary process begins atthe centre postion and moves in a clockwise dissin, Toe NT
ofthe spiral typically results in a deliverable, For example, the iret and second spira) Hever a
in the production of a product specification and a jroto.ype, respectively. Subsea:
sroduce more sophisticated versions of the software, : hed
an important eninetion between the spiral model and other software models is the explicit consideration
of risk. There are no fixed phases such as specification or design phases in the model 7 ic encompasses
ther process models. For example, prototyping may be used in one spiral to resolve Hautema
luncertainties and hence reduce risks. This may then be followed by @ conventional waters
velopment. .
rote that each passage through the planning stage results in an adjustment to the project plan (e.g.
cost and schedule are adjusted based on the feedback from the customer, project manager may adjust the
number of iterations required to complete the software...)
2 Each of the regions is populated by a set of work tasks called a task set that are adapted to
characteristics of the project to be undertaken. For small projects the number of tasks and their formality
is low. Conversely, for large projects the reverse is true,
Advantages of the Spiral Model
«The spiral model is a realistic approach to the development of large-scale software products
because the software evolves as the process progresses. In addition, the developer and the client
better understand and react to risks at each evolutionary level.
«The model uses prototyping as a risk reduction mechanism and allows for the development of
prototypes at any stage of the evolutionary development.
+ It maintains a systematic stepwise approach, like the classic life cycle model, but incorporates it
into an iterative framework that more reflect the real world.
+ If employed correctly, this model should reduce risks before they become problematic, as
consideration of technical risks are considered at all stages.
Di Spi
72 Demands considerable risk-assessment expertise
2 Ithasnot been employed as much proven models (eg. the WF model) and hence may prove difficult
to sell’ to the client (especially where a contract is involved) that this model is controllable and efficient.
res)
CAPABILITY MATURITY MODEL (CMM)
Points to Remember
* CMM is NOT Software Process Model,
* CMM provides a means of asses
manage software projects.
Introduction
* Put forward in 1986 (called as Process Maturity Model) by
Camegie Melon University.
Not a software Process Model as it does not tell you how to make a
Process model needs to be used for a given project.
Software Engineering
ing how well an organization's process allows to complete and
'Y Software Engineering Institute (SED) at
Product. Neither it specifies what
Page 7 of 9
Scanned with CamScanner Chapter Two
Software Process Model
well an organization's process allows to complete and manage s/w
ow
gh
Provides a means of asses
je i i heir s/w funding.
projects. init DOD for selecting the right manufacturer for thei
—_— Sanna process of an organization on a 5-point Grading Seale.
ve maturity
a Terates th
Hivelevels,
Level 1: Initial
Level2: Repeatable
Level3: Defined
Level 4: Managed
Level: Optimized
Levelt: Initial
(Unpredictable S/W Process).
Ad-hoc and Chaotic Software Process.
thave effective management procedures project plans or cost estimates.
+ Organization does no!
. that they are used consistently.
«Even if formal procedures exist, there is no mechanism to ensure
‘Tools are neither well-integrated with the process nor uniformly applied.
‘+ Senior management does not understand key issues.
The organization may be able to develop software successfully, but the characteristics of the S/W
(quality etc) and the process (budget, schedule etc) will be unpredictable.
‘+ Vast majority of organizations aze at this level.
The best test is to observe how such an organization behaves in a crisis. If it abandons established
procedures and reverts to merely coding and testing, it is likely to be at the Initial Process Level. After
all, if the techniques and Methods are appropriate, they should be applied in times of crisis and if
they are not appropriate, they should not be used at all.
+ Key challenges for Level 1; Project Management, Project Planning, S/W quality Assurance, Change
Control.
Level 2: Repeatable
+ Organization has formal management, Quality Assurance and configuration control procedures in
place.
+ This level is called Repeatable because the organization can successfully repeat projects of the same
type. However, there is lack of a formal process model.
+ Project success is dependent on individual managers motivating a team.
+ Examples of the changes that represent the highest risk at this level are:
+ New tools and methods will likely affect how the process is performed, thus destroying the
relevance of the intuitive historical base on which the organization relies.
+ When the organization must develop a new kind of product, it is entering a new territory. For
example, a software group that has experience developing compilers will likely have design,
scheduling, and estimation problems if assigned to write a control program. Similarly, a group
that has developed small, self-contained programs will not understand the interface and
integration issues involved in large-scale projects,
+ Key Actions Required to advance from the Repeatable Process to the Defined Process:
+ Establish a process group - A process group is a technical group that focuses exclusively on
improving the Software development process,
+ The responsibilities of process groups include defining the development process, identifying
technology needs and opportunities, advising the projects, and conducting quarterly management
reviews of process status and performance,
Page 8 of 9
Scanned with CamScanner
Software Engineering Chapter Two
Software Process Model
Hey are not already in place, introduce a family of Software Engineering methods and
logies. These include design and code inspections, formal design methods, library-