Agbaje7survey of softwar process

AmericanJournal of Research Engineering@2013, AJER,e-ISSN:2320-0847,p-2320-0936
A Survey of Software Process Models
J.V. Joshua, S.O. Okolie, O.D. Alao, M.O. Agbaje
Department of ComputerScience, Babcock University,Ilishan-Remo, Ogun State,Nigeria.
ABSRACT – A software Process model is a standardised format for planning, organising, and runninga new
software development project. The need to complete and deliver software projects faster require using a suitable
model.
There are several different kind of models being used which have evolved over the years, in this paper we
carried out survey on the following main types of model; waterfall model, V-model, Component assembly model,
Chaos model, Incremental model, Prototyping model, Spiral model, Rapid application development (RAD)
model, Agile model, rational unified process (RUP), Iconix process and Software ecosystem (SECO) model by
describing their characteristic features.
We concluded the study by listing the strengths and weaknesses of each of this models.
Keywords – Software, Software Process, Software Process Model, Software development
I. Introduction
Software is a major worldwide industry and demand is increasing exponentially [10]; [3]; [13]; [7]; [12].
Software pervades a multitude of products, in social, business and military human-machine systems. It includes
information technology systems, developed for gathering, processing, storing, retrieval and manipulation of
information, to meet organizational needs, and commercially-developed software products, sold to one, or more,
customers or end-users. Software offering functionality to an end-user is also called application software, and
might be a product on its own, or might be embedded in a larger system or machine. Figuratively speaking,
application software sits on top of system software, which are low-level programs, such as operating systems
and utilities for managing computer resources, which interact with the computer at a basic level.
Software Process is an organised set of activities aimed at building a software system. Software Process
Model is an abstract representation of a software process.
There are several software development models employed to develop this solution, some methodologies or
models are suitable for a particular domain.
In the next section, we give an insight to different development models that have evolves over years to the
present.
2. Software Development Models
2.1 Waterfall Model
The waterfall model is one of the earliest models in which phases are executed sequentially. The life cycle of
software development starts with the first stage and moves down through the various stages until the last stage:
implementing the software in a live environment. All stages in the waterfall model are cascaded so that each
stage will start only when all tasks identified in the previous stage are complete as shown in Fig.1. The phases in
the waterfall model do not overlap with each other, thereby making the model quite easy to use.

Fig.1. The waterfall model. [17]
2.2 V-Model
The V-model is a software development model in which testing activities are performed in parallel with
development activities. The phases of software development are placed on the left of the V-model and their
corresponding phases of testing are placed on the right. Similar to the waterfall model, in this model, the life
cycle of software starts with the requirement phase, except that an additional plan is created to check that
requirements are gathered properly. This helps to identify any issues in the requirement specification at an early
stage in the development life cycle. Similarly, different test plans are created during all of the phases until the
coding phase before moving on to the next phase.After the coding phase is complete, the cycle goes up the right
side where test plans created earlier are used. Fig.2 below shows the V-model phases.
Fig. 2. The V-model.[1]
2.3 Component Assembly Model
The component assembly model is a unique development model that uses existing components to build a new
system. Instead of writing code from scratch, existing code is analysed to verify whether it can be reused. The
identified components are then integrated into the new system (Fig. 3). This is mainly implemented when
systems are built using object-oriented technologies. These technologies provide the ideal platform for
developing systems using the component assembly model. They also enable you to build object-oriented classes
that can be reused across various systems and applications.

Fig. 3 Components from an existing system being reused in a new system. [17]
2.4 Chaos Model
The chaos model is an SDLC model that employs a chaotic and unstructured software development process. It
identifies different levels of problem solving in a software development project such as top levels, upper levels,
lower levels, and bottom levels of problem solving as shown in fig.4. The top levels involve the development
and maintenance of a whole system. The upper levels address the development and maintenance of individual
components. The lower levels focus on the development and maintenance of objects and functions. Finally, the
bottomlevels of problem solving involve the development and maintenance of individual lines of code
Fig. 4 The Chaos Model [15]
2.5 The Incremental Model
The incremental model is a software development model in which individual modules of the system are
developed and integrated in stages as shown in Fig. 5). Integration of two or more components is not dependent
on the rest of the components. In this model, however, modules once developed cannot be modified to
accommodate new requirements. Because modules are viewed independent of one another, feedback for one
module is not implemented in other modules.
Validate
increment
Develop system
increment
Design system
architecture
Integrate
increment
Validate
system
Define outline
requirements
Assign requirements
to increments
System incomplete
Final
system
Fig. 5. Incremental model [17]

2.6 Prototyping Model
Software Prototyping is the process of creating a system that is not complete in every respect but bears a
resemblance to the actual system. The incomplete system, called a prototype, typically simulates only certain
features of the actual system and sometimes can even be completely different from the system that will finally
be developed (Fig. 6). The main purpose of prototyping is to allow end users to evaluate the prototypes of the
eventual system. Prototyping provides an opportunity for the end user to list requirements that were not
identified earlier. The many variants of software prototyping include throwaway, evolutionary, incremental, and
extreme prototyping.
Fig. 6. Creation of the prototype of the actual system.[17]
2.7 The Spiral Model
The Spiral Model is an iterative software development model that involves creating an initial prototype of the
final software product, and then carrying out various cycles of adding new functionality and releasing
subsequent prototypes, with the prototype becoming larger with each iteration. It has four phases: planning, risk
analysis, engineering, and evaluation as shown in Fig. 7. One cycle of all four phases executed in sequence is
called a spiral and a prototype is created after the first spiral. This prototype goes through an evaluation process
for assessing its strengths, weaknesses, and risks. After the review of the previous spiral, the next prototype is
built by applying changes or adding new features as suggested by the client. The iteration continues until all of
the requirements are met and the final refined prototype is obtained.
Fig. 7. The spiral Model. [3]
2.8 The Rapid Application Model (RAD) Model
Rapid Application Development (RAD) is a software development model that uses iterations for software
development. It operates by building prototypes at the end of each iteration using automated tools that help not
only to expedite software development but also to ensure the highest quality of the software developed. It
compresses the linear steps in traditional models into short iterations during development (Fig. 8). It is flexible,

produces fewer errors, and involves users at every stage of development. The downside to this model is that it is
not suitable for every single project because it compromises on some of the features needed in large, mission-
critical projects. RAD is extensively used in projects with low scope and for tasks that can be broken down into
smaller chunks.
Fig. 8. The RAD model. [14]
2.9 The Agile Model
The Agile Model is a software development methodology that is based on iterative development, wherein teams
collaboratively work to implement various iterations in a project life cycle [5]. It divides project tasks into small
increments, and therefore involves only short-term planning. Each iteration consists of several phases, each of
which is completed in a short span of time ranging between one and four weeks. A complete project will consist
of a large number of these iterations as indicated in Fig. 9. At the end of each iteration, a functional, usable piece
of software is produced. At the core of its superiority over the other models lies its flexibility to incorporate
customer’s feedback right after an acceptance walkthrough of an increment, minimizing overall risks. A generic
agile model is composed of six phases: iteration-1, iteration-0, construction, release, production, and retirement.
Fig.9. The Agile model. [6].
2.10 The Rational Unified Process (RUP) Model
The Rational Unified Process (RUP) is an adaptable software development process used by both large
organizations and small teams to develop software. It is a form of iterative development process that can be
varied to suit the requirements of the organization where it is implemented. RUP mainly uses tools to create
models of software being developed, sparing developers the trouble of documenting the development on paper.
RUP's life cycle consists of four consecutive phases: inception, elaboration, construction, and transition as
shown in fig. 10. In the inception phase, the concept behind the process is reiterated and the boundaries of the
project are defined. In the elaboration phase, the problem domain is identified and architecture established. In
the construction phase, the software is developed. Finally, in the transition phase, the product is sent to the user
domain.

Fig. 10. The various phases in RUP. [16]
2.11 The Iconix Process Model
Iconix is a software development process that is mainly concerned with use case development process. Use
cases are interactions that are recorded between the user and the system as shown in fig. 11. The Iconixprocess
provides adequate documentation for requirements and design analysis carried out during the development
process.It uses a method called robustness analysis that overcomes the differences between design and analysis.
It is extremely efficient and helps in easier design, testing and estimation of use cases. The Iconix process
consists of four phases: Requirements, Preliminary Analysis, Detailed Design, and Implementation.
Fig. 11. The features of iconix process [8]
2.12 The Software Ecosystem(SECO) Model
A Software Ecosystem consists of set of software solutions that enables supports and automates the activities
and transactions by the actors in the associated social or business ecosystemand the organizations that provide
these solutions [4]. Fig. 12 illustrates the main actors in a Software Ecosystem Model. The supplier (keystone
organization) develops the product line. This development is guided by a strategy, which points out needs and
opportunities and main paths of development. Both the strategy and the development of the product line
are to some extent visible to external actors. These consist of (at least) customers and third parties, but can
also involve others such as suppliers. Third parties use the product line as a platform to serve customers with
additional solutions and services. Being a part of an ecosystem means that these actors learn about each other.
The supplier learns about requirements, needs, ideas, opportunities, and others. In re t u rn , external actors
learn about the development of the technology of common interest (the product line), and may even participate
actively in the development.

Fig. 12. A conceptual model of a software ecosystem[9]
3. Results
The tables below summarises the strengths and weaknesses of each of the models describe in this study.
Table 1:The Waterfall Model
Strength Weakness
 Planning and scheduling can be
done quite easily
 The start time and the completion
time of each phase can be clearly
defined.
 The system requirements are
identified long before
programming begins.
 Changes to the requirements are
minimised as the project
proceeds.
 Highly visible
 Project monitoring is easy.
 The scope for revising the system is limited
because we do not go back to a phase once it is
completed.
 It suffers lack of flexibility because once
requirements are collected and the system moves
on to the next phase, additions to the requirements
are not possible.
 New requirements has to be incorporated on to the
next version once requirements is not capture at
requirement phase therefore leading to project cost
and affecting profitability.
 Freezing the specification is difficult
Table 2:The V Model
Strength Weakness
 It allows planning to be done quite
early in the System Development
Life Cycle (SDLC) before
performing the testing.
 It is less complex and easier to use
and manage because test planning
is involved very early in the SDLC
 Each phase has a specific
deliverable, so it can be analysed
 The non-availability of a prototype until the
implementation phase is complete.
 It does not easily handle concurrent events.
 It does not contain risk analysis activities.
 Very rigid and least flexible.
 Software is developed during the implementation
phase, so no early prototypes of the software are
produced.
 If any changes happen in midway, then the test

separately.
 Emphasizes planning for
verification and validation of the
product in early stages of product
development phase.
 Project management can track
progress by milestones.
 It is easy to use
documents along with requirement documents has
to be updated.
Table 3:The Component Assemble Model
Strength Weakness
 The model is used where
technologies such as JavaScript
and AJAX play important role.
 It helps reduce development time
considerably.
 Facilitate widespread use of
frameworks by developer’s
community.
 It enable developers to focuses on
customer requirements.
 It leads to software reusability.
 It leads to reduction of production
cost and save production time.
 It increases systems reliability.
 Compatibility may arise if developers is not
careful enough in choosing components used
thereby negating reduce development time.
 If the framework of the component is different it
will only give the developer a hard time in
improving the system.
 A component created to answer a specific question
may not be easily integrated to a specific system
because of compatibility issues.
 There is no formal licensing scheme on using
components.
 Poor integration of architecture changes into
implementation process affected implementation
process and the architecture design negatively
 Less control over the system’s evolution
 Compromises in requirements are needed.
Table 4:The Chaos Model
Strength Weakness
 It identifies different levels of
problem solving in a software
development project such as top
levels, upper levels, lower levels,
and bottom levels of problem
solving.
 Faster development
 Less cost of project
 It is unstructured software development process.
 May require high level of expertise.
Table 5:The Incremental Model
Strength Weakness
 Provides better support for process
iteration
 Reduces rework in the software
construction process
 Some decisions on requirements
may be delayed
 Allows early delivery of parts of
the system
 Supports easier integration of sub-
systems
 Lower risk of project failure
 Increments need be relatively small
 Mapping requirements to increments may not be
easy
 Common software facilities may be difficult to
identify

 Delivery priorities can be more
easily set
Table 6:The Prototyping Model
Strength Weakness
 Developers can receive feedback
from users early in the project.
 It allows end users to compare
their requirements with the
developed prototype and identify
discrepancies.
 The final product would meet most
user expectations.
 It helps the developer to estimate
the time required for project
completion more accurately.
 Useful for obtaining user
requirements
 As the developer tends to focus more on the
prototype, he may actually lose sight of the
complete system, this may not meet prescribed
specifications
 It may incurred excessive development time.
 There may be user confusion of prototype and
finished system.
 If excessive time is devoted to developing a
prototype, it may bring down the productivity of
the project, thereby increasing the cost of the
project.
Table 7:The Spiral Model
Strength Weakness
 It ensures a very high quality
product because of prototyping at
each stage in systemdevelopment.
 Highly suitable for high risk
project.
 Project monitoring is more
effective.
 Provides early indication of
insurmountable risks, without
much cost.
 Users see the systemearly because
of rapid prototyping tools.
 Critical high-risk functions are
developed first.
 The design does not have to be
perfect.
 Users can be closely tied to all life-
cycle steps.
 Early and frequent feedback from
users.
 Cumulative costs can be assessed
frequently.
 Due to the numerous iterations, a high cost of
development is incurred.
 The success of the project is highly dependent on
the risk analysis phase.
 It is not suitable for low risk project.
 Time spent planning, resetting objectives, doing
risk analysis and prototyping may be excessive.
 The model is complex.
 Risk assessment expertise is required.
 Spiral may continue indefinitely.
 Developers must be reassigned during non-
development phase activities.
 It may be hard to define objective, verifiable
milestones that indicate readiness to proceed
through the next iteration.

Table 8:The Rapid Application Development (RAD) Model
Strength Weakness
 It breaks down the development
process into short iterations, making
development quicker.
 It enables active user involvement
in all stages of development and
also helps the user to see the end
product quickly.
 It reduces risk considerably and
ensures a high quality product at a
low cost.
 Reduced cycle time and improved
productivity with fewer people
means lower costs.
 Customer involved throughout the
complete cycle minimizes risk of
not achieving customer satisfaction
and business needs.
 Focus moves from documentation
to code.
 Uses modelling concepts to capture
information about business, data,
and processes.
 Due to repeated iterations, effective cost and time
management might prove to be a concern.
Because the model requires active user
involvement, user commitment at all times can be
difficult.
 Repeated iterations may result in the development
stage stretching beyond the schedule. Such time
overruns may in turn lead to the suboptimal use
of resources.
 It can’t be used in all situations.
 Accelerated development process must give
quick responses to the user.
 There is risk of never achieving closure.
 It is hard to use with legacy systems.
 It requires a systemthat can be modularized.
 Developers and customers must be committed to
rapid-fire activities in an abbreviated time frame.
Table 9:The Agile Model
Strength Weakness
 Fast turnaround and prompts delivery
of working software to the customer.
 Makes it very easy to address
changes suggested late in the life
cycle.
 Regular communication between
clients and developers ensures that
there are no mismatches between the
client requirement and what the
actual systemdoes.
 The fact that new requirements are
incorporated into the product
throughout the development process
contributes to the model's flexibility.
 Since testing is done at every phase
of the life cycle, the need for a
lengthy testing process at the end of
the life cycle is prevented.
 Since this model entails close collaboration
between developers and end users, a
representative of the end user is required to
spend a lot of time with the project team.
 It will be difficult to estimate and negotiate the
price of projects with the client, since
requirements keep changing in an agile model
driven project.
 Since the product is delivered in stages, user
acceptance testing needs to be done too
frequently, adding to time constraints for the end
user representative.

Table 10:The Rational Unified Process(RUP)
Strength Weakness
 It establish a Unified Modelling
Language (UML) as a common
language for process oriented
protocols.
 It reduces scrap or rework by using an
iterative process.
 Potential risks are identified and
removed effectively in early
development stages.
 It uses several tests to deliver a refined
and quality software product during
development.
 Software is modelled visually using
graphics instead of code to facilitate
better understanding.
 It uses various components which are
small modules that define a specific
function by themselves, to develop
architecture.
 It is development centric and focuses mainly on
the development aspect of software, as a result,
it neither extends beyond development level.
 It does not tackle issues at enterprise and
management levels.
 High degree of expertise may be require
Table 11:The Iconix Process Model
Strength Weakness
 It provides adequate documentation
for requirements and design analysis
carried out during the development
process.
 It uses a method called robustness
analysis that overcomes the
differences between design and
analysis.
 It is extremely efficient and helps in
easier design, testing and estimation
of use cases.
 It is a use case based development
process that is robust and simple.
 It avoids analysis paralysis, a
condition that occurs due to a lot of
analysis which might hinder the
process of decision making.
 It makes use of class and system
diagrams which aid clear
understanding of the concept for the
user.
 It involves a lot of Graphic User
Interfaces (GUIs) that enhance user
interaction with the system.
 Design of GUI may be time consuming.
 Developers need to understand best practice in
user interface design.
Table 12:Software Ecosystem(SECO)
Strength Weakness
 Promote self-regulation.
 It exhibit shared values such as
 Control moves toward the users
 It exist mainly through the use of Information

revenue from licenses and services.
 It comprises network of characters –
vendors, developers and users.
 It increases visibility
 Increases extensibility.
 It attracts mass following.
communication Technology (ICT).
 It is more complex, hence effective management
may be a key issues.
 It may not be very successful in a closed system.
4. Conclusion
This paper exposed the characteristics features of major software development models and try to identify the
merits and drawbacks of each of this models.
From the study, software process models can be categorised into three main types’ namely incremental model,
iterative model and sequential model, some model are hybrid of two or more models.
This study will assist practitioners in making choice of the best development model to adopt in software
development project they may be undertaken.
However, there is a paradigm shift to a new emerging development model call software ecosystem (SECO)
model, but the software industry is still elucidating to understand this concept, but literatures shows that
software development process is moving toward this concept.
References
[1] Andrew Ratcliffe (2011) SAS Software Development with the V-Model, Ratcliffe Technical Services
Limited (RTSL).eu, United Kingdom.
[2] Boehm, B.W., (1988). “A Spiral Model of Software Development and Enhancement.” IEEE Computer.
[3] Boehm, B.W., Sullivan, K.J., “Software Economics: A Roadmap”, ACM Press, 2000.
[4] Bosch, J. (2009). From Software Product Lines to Software Ecosystems. In proceedings of 13th
International Software Product Line Conference (SPLC'09), San Francisco, USA, 24-28 August. 111-119.
[5] Dybå, T., and Dingsoyr, T., (2008), ‘Empirical Studies of Agile Software Development: A Systematic Review’. Information and
Software Technology, 50, n.9-10, 833-859, August.
[6] Cockburn, A. (2002). Agile Software Development. Boston: Addison-Wesley.
[7] Fuggetta, A. (2000), “Software Process: A Roadmap”, in “The Future of Software Engineering”, ACM Press.
[8] Gomaa H. (2004) DesigningSoftware Product Lines with UML: From Use Cases to Pattern-Based Software Architectures. Addison
Wesley.
[9] Hanssen, G. (2011). A Longitudinal Case Study of an EmergingSoftware Ecosystem. Acceptedfor publicationin Journal of Systems
and Software, pages 1–24.
[10] Hoch, D.J, et al., “Secrets of Software Success: Management Insights from100SoftwareFirms Aroundthe World”, Harvard Business
Scoll Press, Boston, MA, 1999.
[11] Humphrey, W.S. (2001), “The Future of Software Engineering: I”, Column SEI, Vol. 4 (1), 2001.
[12] Humphrey, W.S. (2002), “Winning with Software: An Executive Strategy”, Addison-Wesley, 2002
[13] Littlewood, B., Strigini, L. (2000), “Software Reliability and Dependability: a Roadmap”,
Proceedings of the 22nd International Conference on Software Engineering.
[14] Pressman, R., S. (2001) Software Engineering: A Practitioner’s Approach, 5th Edition. McGraw-Hill International edition.
[15] Raccoon L. B. S (1994), Albuquerque, New Mexico
[16] Jacobson Ivar, Grady Booch, and Jim Rumbaugh (1999). Unified Software Development Process, Addison-Wesley.
[17] Sommerville Ian (2010). Software engineering 8th
. Edition. Pearson Addison-Wesley.

Agbaje7survey of softwar process

More Related Content

What's hot

Similar to Agbaje7survey of softwar process

More from Dr. Michael Agbaje

Recently uploaded

Agbaje7survey of softwar process