1. International Journal of Advanced Research in Engineering and Technology (IJARET), ISSN 0976 –
6480(Print), ISSN 0976 – 6499(Online) Volume 5, Issue 6, June (2014), pp. 83-90 © IAEME
83
GRADUAL TRENDS IN SOFTWARE DEVELOPMENT AND SOFTWARE
IMPROVEMENT MODELS
Nomi Baruah1
, Annushree Kurmi2
, Sharbani Purkayastha3
, Paulomi Das4
1,2,3,4
Computer Science & Engineering Department, Dibrugarh University, Dibrugarh, India,
ABSTRACT
In today’s era to produce a quality product which satisfies the customer is the main goal of
software industries because then only they can survive in the current business environment. Different
researchers have proposed different software development models right from the beginning of
software development era. The different software development models acts as a guide to the software
developers which model to choose based on the type of projects they undertake. Each of these
models satisfies specific needs demanded by customer on the software product. This paper studies
the different trends of software development models starting from the messy model i.e. Build and Fix
Model and an analysis of the models are being made.
Keywords: Bootstrap, CMM, SPICE, Spiral Model, Waterfall Model
I.INTRODUCTION
The software and software development is being part of the society since 50 years. As the
software’s has become an important element in industry, organizations, etc. the number of companies
which produce different types of software products has been increased recently which as a result
became urge for the companies to produce quality products so that they can survive in the market.
Different types of models have been suggested by different researchers. The software developers can
select the model based on the type of the software product they are going to develop.
II. SOFTWARE DEVELOPMENT MODELS
The different types of software development models which are discussed in this paper are
given below:
INTERNATIONAL JOURNAL OF ADVANCED RESEARCH
IN ENGINEERING AND TECHNOLOGY (IJARET)
ISSN 0976 - 6480 (Print)
ISSN 0976 - 6499 (Online)
Volume 5, Issue 6, June (2014), pp. 83-90
© IAEME: http://www.iaeme.com/IJARET.asp
Journal Impact Factor (2014): 7.8273 (Calculated by GISI)
www.jifactor.com
IJARET
© I A E M E

2. International Journal of Advanced Research in Engineering and Technology (IJARET), ISSN 0976 –
6480(Print), ISSN 0976 – 6499(Online) Volume 5, Issue 6, June (2014), pp. 83-90 © IAEME
84
1.1 Build and Fix Model: The build and fix model is the first model in software development
methodology used to develop software product. In this model the software product is implemented
without any specification or design. The methodology works for projects with few hundred lines of
code [1].The methodology is very simple but the rework of the product is done until the customer is
satisfied.
1.2 Waterfall Model: The Waterfall model was the first software development life cycle model to
be used widely in Software Engineering to ensure success of the project[2].Although it has come
under attack in recent years for being too rigid and unrealistic when it comes to quickly meeting
customer needs ,the Waterfall model is still widely used[3].The different steps followed in waterfall
model to develop a software product are feasibility study, requirement gathering and analysis,
design, coding, testing and maintenance.
1.3 Spiral Model: The Spiral Model is a risk-driven process model generator. It is used to guide
multi-stakeholder concurrent engineering of software-intensive systems. It has two main
distinguishing features. One is cyclic approach and other is a set of anchor point milestones [4].The
spiral model is divided into four sectors: objectives setting, risk assessment and reduction,
development and validation and planning [5].
1.4 Capability Maturity Model (CMM): In order to have a proper management of the software
processes in an organization, the Software Engineering Institute (SEI) had created a Capability
Maturity Model (CMM) for developing and maintaining software. It elaborates how to evolve the
processes so that the organization maturity is being increased gradually. The SEI has developed a
five-level Capability Maturity Model for software that provides organizations with guidance for
measuring software process maturity and establishing process improvement plans. [10] The current
processes of an organization are being identified and modified or changed in order to improve the
quality of the software. [9] The CMM focuses on the organization’s work processes. The CMM
helps the organization by acting as a guide in selecting process improvement strategies by
determining current process maturity and identifies the issues which is critical to software quality
and process improvement.
1.5 Capability Maturity Model Integration (CMMI): CMMI is a process improvement model that
provides a set of best practices that addresses productivity, performance, costs and stakeholder
satisfaction. It is a model that consists of best practices for system and software development and
maintenance and is used as a framework for appraising the process maturity of the organization.
CMMI is the leading industry standard for measuring software development processes. The model is
introduced with a purpose to eliminate inconsistency, reduce duplication, increase the transparency
and intelligibility, provision of public terminology, etc.The continuous representation of CMMI is
designed to allow the user to focus on the specific processes that are considered important for the
organization's immediate business objectives, or those to which the organization assigns a high
degree of risk. Continuous representation suits well to SME’s, where short term goals are
emphasized highly. [8]
1.6 People-Capability Maturity Model (P-CMM): The P-CMM is developed to provide a
framework that continuously develops the human assets of the software or information systems
organization. The P-CMM is an organizational change model. It is through P-CMM that an
organization is able to identify the capabilities of current workforce practices and also able to evolve
the workforce practices with the help of maturity levels of P-CMM. The P-CMM is constructed from
workforce practices and process improvement techniques that have proven effective in many

3. International Journal of Advanced Research in Engineering and Technology (IJARET), ISSN 0976 –
6480(Print), ISSN 0976 – 6499(Online) Volume 5, Issue 6, June (2014), pp. 83-90 © IAEME
85
organizations. [9] The range of organisational processes that the P-CMM addresses is extensive and
covers areas of workforce management. The P-CMM model is divided into five maturity levels .Each
level in this model defines a new standard for people management practices. [10]
1.7 BOOTSTRAP: BOOTSTRAP is a software process improvement and assessment model. It is
basically developed for European industries. BOOTSTRAP methodology can be applied to small and
medium size software companies or software departments within a large organization. A new release
(Release 3.0) of the BOOTSTRAP methodology has been developed to assure conformance with the
emerging ISO standard for software process assessment and improvement. [11]
1.8 Software Process Improvement Capability determination (SPICE):SPICE is also known as
ISO/IEC 15504.SPICE was developed to provide a framework for software process assessment so
that the product can be delivered reliably .The main goal of software process improvement is to
provide the software industry with gains in productivity and quality. [12]Capability determination
reduces the risk associated with large projects and at the same time helps purchasers to get better
value for money. [13]
III. ANALYSIS OF SOFTWARE MODELS
The analysis of the models is done based on four different characteristics. They are
1.1 Based on Characteristics of Requirements
Table 1: Comparison of Different Software Development Models Based on Requirements
Requirements
Build and fix
model
Waterfall
model
Spiral model CMM CMMI P-CMM
Bootstrap
model
SPICE
Are
requirement
s easily
understanda
ble and
defined?
No(because
there is no
proper phase
for
requirement
analysis)
Yes(because
requirement
analysis and
specification
is done at the
early stage )
No(because
software is
built in a series
of incremental
releases which
might be a
paper model or
prototype but
during later
iterations more
complete
versions of the
s/w is
produced)
Yes
(but from
level 2-
repeatable)
Yes (because
there are
phases for
requirements
development
and
requirements
management)
No(since it
describes an
evolutionary
improvemen
t path from
ad-hoc to
mature
development
of
knowledge,
skills,
motivation
of
workforce)
Yes(the
re is
s/w
require
ment
analysis
phase in
this
model)
Yes
(But
from
level 2-
planned
and
tracked)
Do we
change
requirement
s quite
often?
Yes(because
requirements
are not fixed
and
documented
and are not
properly
understood)
No(because
requirements
once defined
are
documented)
Yes(because
requirements
are not fixed
and
documented
and are not
properly
understood )
Yes (but
depends on
feasibility
from the
developer
side and
customer
side)
No (but
changed when
required)
Yes(since
each
maturity
levels
increases a
level of
capability
for
developing
the talent of
the
organization
)
No(sinc
e
prototy
ping
activity
is not
done in
this
model)
Yes (but
depends
on
feasibilit
y from
the
develop
er side
and
custome
r side)

4. International Journal of Advanced Research in Engineering and Technology (IJARET), ISSN 0976 –
6480(Print), ISSN 0976 – 6499(Online) Volume 5, Issue 6, June (2014), pp. 83-90 © IAEME
86
Can we
define
requirement
s early in
the cycle?
No(because
developers
keep on
adding
requirements
until user is
satisfied )
Yes(because
requirement
analysis and
specification
is done at the
early stage)
No(since
customers
examine the
prototype and
provide
feedback and
using the
feedback both
specifications
and the
prototype is
improved)
Yes(since
requiremen
ts are
defined
during
level-2)
Yes(because
requirement
development
and
requirement
management
are done at
the proper
time)
No(since it
describes an
evolutionary
improvemen
t path from
ad-hoc to
mature
development
of
knowledge,
skills,
motivation
of
workforce)
Yes(bec
ause
require
ment
gatherin
g,
analyzi
ng, and
recordi
ng is
done at
the
early
stage)
Yes(req
uiremen
ts are
defined
in early
stage-
level 2)
Are
requirement
s indicating
a complex
system to
be built?
No (because
this model is
not suitable
for complex
projects )
No (because
this model is
not suitable
for complex
projects)
Yes(because
requirements
are complex
and need
evaluation to
get clarity and
hence end of
the project may
not be known
early)
Yes (but
not for
initial
level)
Yes(because
are stringent
requirements)
No(since p –
cmm
provides
organization
s with
guidelines
on how to
gain control
of their
processes for
developing
their
workforce)
Depend
s on
type of
project
and
enterpri
se
Yes (but
not for
initial
level)
1.2 Based on Status of Development Team
Table 2: Comparison of Different Software Development Models Based on Status of Development Team
Development
team
Build and
fix model
Waterfall
model
Spiral
model
CMM CMMI P-CMM Bootstrap model SPICE
Less
experience
on similar
projects
Yes(becaus
e
developers
are not
experts)
No(becau
se project
are
mostly
extension
of an
existing
version)
Yes(beca
use this
model is
suitable
for
complex
projects
but not
for some
existing
version or
low risk
projects)
No(but
depends on
the
requirement
s)
No
(but depends
on the
requirements)
No(since p-
cmm guides an
organization
through
sophisticated
practices an
techniques
which are
chosen from
experience for
developing its
workforce)
No(since this
model deals
with software
process
assessment and
improvement
method which
measures
capability and
value of
processes
No
(but from
level 2)
Less
domain
knowledge(
new to the
technology)
No(technol
ogy change
is not a
characterist
ic of this
model)
No(techn
ology
change is
not a
characteri
stic of
this
model)
Yes(beca
use
developer
s are not
experts)
No (since
strong
domain
knowledge
is required
for building
complex
systems)
No (up to the
4th
level)
Yes (For level
5)
No(since p-
cmm focuses
on instilling
basic
discipline into
workforce
activities like
training,
staffing, etc
which will not
be possible
with less
domain
knowledge)
No(since this
model provides
guidelines for
process
improvement
which is
supported with
computer based
tools, updated
database
,algorithms etc)
No( since
strong
domain
knowledge
is required
for
building
complex
systems)

5. International Journal of Advanced Research in Engineering and Technology (IJARET), ISSN 0976 –
6480(Print), ISSN 0976 – 6499(Online) Volume 5, Issue 6, June (2014), pp. 83-90 © IAEME
87
Less
experience
on tools to
be used
No(well
acquainted
tools are
used)
No(well
acquainte
d tools
are used)
Yes(beca
use
developer
s are not
experts)
No(since it
is used to
build
complex
systems)
No (up to the
4th
level)
Yes (For level
5)
No(since since
p-cmm
focuses on
instilling basic
discipline into
workforce
activities like
training,staffin
g,etc which
will not be
possible with
less domain
knowledge)
No(since this
model uses
computer based
assessor tools to
evaluate
processes)
No(well
versed
with tools
to be used)
Availability
of training
if required
No(there is
no phase
for
training)
No(there
is no
phase for
training)
No(there
is no
phase for
training)
Yes(training
is available
in level 3)
Yes(there is a
training phase)
Yes(there is a
training phase)
Yes(there is a
training phase)
Yes(trainin
g is
available
in level 3)
1.3 Based on User’s Participation
Table 3: Comparison of Different Software Development Models Based on User’s Participation
Involvement
of users
Build
and fix
model
Waterfall
model
Spiral
model
CMM CMMI P-CMM
Bootstrap
model
SPICE
User
involvement
in all phases
No(there
is no
facility
for this)
No(user
involvement
is only in the
requirement
analysis and
specification
phase)
Yes(since
s/w evolves
as the
process
progresses
developer
and
customer
better
understand
and reacts
to risks at
each
evolutionar
y level)
Should be
pre
defined
based on
type of
enterprise
No(users are
involved in
certain phases
only)
Yes(since it is
a maturity
framework
that focuses
on developing
and managing
the workforce
of an
organization
No(since this
model
provides
guidelines
for process
improvemen
t which is
supported
with
computer
based tools,
updated
database
,algorithms
etc
Should be
pre
defined
based on
type of
enterprise
Limited user
participation
Yes(num
ber of
users is
limited)
Yes(number
of users is
limited)
No(since
s/w evolves
as
the process
progresses
developer
and
customer
better
understand
and reacts
to risks at
each
evolutionar
y level)
Varies-
on type of
project
and type
of
enterprise
No(group of
users
participate)
No(since
without
sufficient user
participation
organizational
growth will
be
impossible)
Yes(because
some phases
of this model
does not
require
participation
of users
Varies- on
type of
project
and type
of
enterprise

6. International Journal of Advanced Research in Engineering and Technology (IJARET), ISSN 0976 –
6480(Print), ISSN 0976 – 6499(Online) Volume 5, Issue 6, June (2014), pp. 83-90 © IAEME
88
User have no
previous
experience of
participation
in similar
projects
Yes(as
users
haven’t
used
such
system
before)
No(as
system is
mostly
extension of
an existing
system)
Not defined Varies(
on type of
project
and
enterprise
)
No(users are
experienced)
Varies- on
type of
project and
type of
enterprise
Varies on
type of
project and
enterprise
Varies (on
type of
project
and
enterprise)
Users are
experts of
problem
domain
No(users
discover
more
problems
only
after
using the
first
build)
Yes(users
define and
document
requirements
early in the
cycle )
No(since
the process
and
managemen
t is very
complex
and it is
suitable for
high risk
projects )
Yes
(users
requireme
nts are
document
ed early
in the
cycle)
Yes( users
define and
document
requirements
early in the
cycle)
No(since this
model
addresses
issues like
career
development ,
communicatio
n, training,
coaching, etc)
No(since
users are not
experts)
Yes( since
user
requireme
nts are
document
ed early in
the cycle)
1.4 Based on Type of Project Associated Risk
Table 4: Comparison of Different Software Development Models Based on Type of Project
Associated Risk
Project type and
risk
Build and
fix model
Waterfall
model
Spiral model CMM CMMI P-CMM
Bootstrap
model
SPICE
Project is the
enhancement of
the existing
system
No(new,
small sized
projects
are build
using this
model)
Yes(it is
mostly used
for
enhancing an
existing
system)
No(since it
is suitable
for complex
,high risk
projects)
Depends
on type of
project and
enterprise
Depends on
type of
project and
enterprise
Yes(since it
guide
organizations
in selecting
activities for
improving
their
workforce
activities
based on the
current
maturity of
their
workforce
practices)
Yes(since
this model
is all about
improveme
nt of
existing
software
processes
with
different
organizatio
n types and
various
software
processes)
Depends on
type of
project and
enterprise
Funding is
stable for the
project
Yes(but
sometimes
it may
increase)
Yes(require
cost is
documented)
No(since
significant
changes are
expected in
the product
during the
developmen
t cycle)
Yes(cost
and time
should not
exceed the
documente
d limit)
Yes(cost and
time should
not exceed
the
documented
limit)
Yes No(since
sometimes
company
waste a lot
of resources
in keeping
up high
capability
processes
which
create a lot
of costs and
low value)
Yes(since
cost and time
should not
exceed the
documented
limit)

7. International Journal of Advanced Research in Engineering and Technology (IJARET), ISSN 0976 –
6480(Print), ISSN 0976 – 6499(Online) Volume 5, Issue 6, June (2014), pp. 83-90 © IAEME
89
High reliability
requirements
No(used
for small
projects
with less
risk)
No(used for
small
projects with
less risk)
Yes(require
ments
indicate that
the system
should be
reliable)
Yes(It
requires
complex
and
reliable
systems
are build)
Yes(because
complex and
reliable
systems are
build)
Yes(because
complex and
reliable
systems are
build)
Yes(becaus
e complex
and reliable
systems are
build)
Yes(because
complex and
reliable
system are
built)
Tight project
schedule
No(develo
pment time
may
exceed)
Yes(develop
ment time is
most often
fix)
No(since
end of
project may
not be
known early
and spiral
may go
indefinitely)
Yes (but
from
higher
level)
Yes(project
needs to be
completed
within
stipulated
time)
Yes No(since
sometimes
cost and
schedules
are not
predictable
in an
immature
software
organizatio
ns having
complex
processes)
Yes since
project
development
time is fixed)
Use of reusable
components
No(small
organizatio
ns do store
the
reusable
component
s)
Yes(some
components
of the
existing
system may
be used in
building the
enhanced
system)
Used in
large
enterprise
Yes(comp
onents are
re-used in
large
enterprise)
Yes(large
organization
s store the
reusable
components)
Used in large
enterprise
Yes(compo
nents of a
particular
process can
be re-used
for its
further
improveme
nt
Yes(compone
nts are re-
used in large
enterprise)
Are resources
(time, money,
people etc.)
scarce?
Yes(becau
se
developme
nt time and
cost are
not known
beforehand
)
No(mostly
these are not
scarce as
these are
fixed after
proper
analysis)
yes(since it
takes a lot
of strict
managemen
t to
complete
such
projects
under this
model)
Varies
with
organizati
on
No(resource
required do
not change
in most cases
as these are
fixed after
proper
analysis )
Varies with
organization
Varies with
organizatio
n
Varies with
organization
IV. CONCLUSION
In this paper, we have discussed different models and their characteristics with respect to
different types of situation a project may have and at that time which model is best described can be
determined based on the analysis given in the above tables. The perspective nature of CMMI and
BOOTSTRAP, and the associated characteristics is sufficient enough to implement software process
improvement programs are the main reasons for further researches in small and medium software
enterprises.

8. International Journal of Advanced Research in Engineering and Technology (IJARET), ISSN 0976 –
6480(Print), ISSN 0976 – 6499(Online) Volume 5, Issue 6, June (2014), pp. 83-90 © IAEME
90
V. REFERENCES
[1] http://www.csun.edu/~eugean/comp380/slides/ch2-4spp.pdf,accessed on 21 April, 2014.
[2] http://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm , accessed on 21 April, 2014.
[3] CTG. MFA – 003, "A Survey of System Development Process Models", Models for Action
Project: Developing Practical Approaches to Electronic Records Management and
Preservation, Center for Technology in Government University at Albany / Suny, 1998.
[4] Barry Boehm, "Spiral Development: Experience, Principles, and Refinements", edited by
Wilfred J. Hansen, 2000.
[5] Ian Sommerville, "Software Engineering", Addison Wesley, 7th edition, 2004.
[6] Mike konrad,Mary Beth Chrissis,Jack Ferguson,Suzanne Garcia,Bill Hefley,Dave Kitson and
Mark Paulk,”Capability Maturity Modelling SM® at the SEI”, Software Process
Improvement and Practice,vol. 2,no. 1,pp.21-34,1996.
[7] M.C. Paulk,B. Curtis,M.B. Chrissis, and C.V. Weber, “Capability Maturity Model”, Version
1.1,IEEE Software,vol. 10,no. 4,pp. 18-27,July 1993.
[8] L.G. Jones, Software Process Improvement and Product Line Practice: CMMI and the
Framework for Software Product Line Practice, US: SEI, Carnegie Mellon University, 2002.
[9] B. Curtis, W. Hefley and S. Miller, People Capability Maturity Model.Addison-Wesley:
Boston, MA, USA, 2001.
[10] Pasi Vakaslahti,”Process Improvement Frameworks-A Small Case Study with People
Capability Maturity Model”, Software Process improvement and Practice,vol. 3,no. 4,pp.225-
234,December 1997.
[11] V.M. Haase,”BOOTSTRAP: Fine tuning process assessment”, IEEE Software, vol. 11, no. 4,
pp.25-37, 1994.
[12] A. Dorling,”SPICE: Software Process Improvement and Capability Determination”, Software
Quality Journal, vol. 2, no. 4, pp. 209-224, December 1993.
[13] Rout and P. Terence, “SPICE: A Framework for Software Process Assessment”, Software
Process Improvement and Practice, vol. 1,no. 1,pp. 57-66,1995.
[14] S.Saira Thabasum, “Need For Design Patterns and Frameworks For Quality Software
Development” International journal of Computer Engineering & Technology (IJCET),
Volume 3, Issue 1, 2012, pp. 54 - 58, ISSN Print: 0976 – 6367, ISSN Online: 0976 – 6375.
[15] Dillip Kumar Mahapatra and Gopa Krishna Pradhan, “Selection Criterion and
Implementation of Case Tools In Gap Analysis Towards Distributed Software Development”
International journal of Computer Engineering & Technology (IJCET), Volume 4, Issue 3,
2013, pp. 389 - 409, ISSN Print: 0976 – 6367, ISSN Online: 0976 – 6375.
[16] Dillip Kumar Mahapatra, Tanmaya Kumar Das and Gopakrishna Pradhan, “Guidelines For
Managing Distributed Software Project Under Deployment” International journal of
Computer Engineering & Technology (IJCET), Volume 4, Issue 1, 2013, pp. 34 - 45, ISSN
Print: 0976 – 6367, ISSN Online: 0976 – 6375.