Comparison between five process models of software engineering

IJCSI International Journal of Computer Science Issues, Vol. 7, Issue 5, September 2010 ISSN (Online): 1694-0814

A Comparison Between Five Models Of Software Engineering
Nabil Mohammed Ali Munassar1 and A. Govardhan2

Ph.D Student of Computer Science & Engineering

Jawahrlal Nehru Technological University
Kuktapally, Hyderabad- 500 085, Andhra Pradesh, India

Professor of Computer Science & Engineering
Principal JNTUH of Engineering College, Jagityal, Karimnagar (Dt), A.P., India

This research deals with a vital and important issue in computer world. It is concerned with the software management processes that examine the area of software development through the development models, which are known as software development life cycle.

It represents five of the development models namely, waterfall, Iteration, V-shaped, spiral and Extreme programming. These models have advantages and disadvantages as well.

Therefore, the main objective of this research is to represent different models of software development and make a comparison between them to show the features and defects of
each model.
Keywords: Software Management Processes, Software Development, Development Models, Software Development Life Cycle, Comparison between five models of Software Engineering.

Get quality help now
Marrie pro writer
Marrie pro writer
checked Verified writer

Proficient in: Comparison

star star star star 5 (204)

“ She followed all my directions. It was really easy to contact her and respond very fast as well. ”

avatar avatar avatar
+84 relevant experts are online
Hire writer

increased recently which results in the difficulty of enumerating such companies. During the previous four decades, software has been developed from a tool used for analyzing information or solving a problem to a product in itself. However, the early programming stages have created a number of problems turning software an obstacle to software development particularly those relying on computers. Software consists of documents and programs that contain a collection that has been established to be a part of software engineering procedures.

Get to Know The Price Estimate For Your Paper
Number of pages
Email Invalid email

By clicking “Check Writers’ Offers”, you agree to our terms of service and privacy policy. We’ll occasionally send you promo and account related email

"You must agree to out terms of services and privacy policy"
Write my paper

You won’t be charged yet!

Moreover, the aim of software engineering is to create a suitable work that construct programs of high quality.

1. Introduction
Computer Science

No one can deny the importance of computer in our life, especially during the present time. In fact, computer has become indispensible in today’s life as it is used in many fields of life such as industry, medicine, commerce, education and even agriculture. It has become an important element in the industry and technology of advanced as well as developing countries. Now a days, organizations become more dependent on computer in their works as a result of computer technology. Computer is considered a time- saving device and its progress helps in executing complex, long, repeated processes in a very short time with a high speed. In addition to using computer for work, people use it for fun and entertainment. Noticeably, the number of companies thatproduce software programs for the purpose of facilitating works of offices, administrations, banks, etc, has


Computer Function



The Software engineering

Tools and techniques to solve problems

Fig. 1 Explanation of software engineering conception.

IJCSI International Journal of Computer Science Issues, Vol. 7, Issue 5, September 2010 ISSN (Online): 1694-0814


2. Software Process Models


A software process model is an abstract representation of a
process. It presents a description of a process from some
particular perspective as:

The pure waterfall lifecycle consists of several nonoverlapping stages, as shown in the following figure. The model begins with establishing system requirements and software requirements and continues with architectural design, detailed design, coding, testing, and maintenance.
The waterfall model serves as a baseline for many other lifecycle models.



General Software Process Models are
1. Waterfall model: Separate and distinct phases of
specification and development.
2. Prototype model.
3. Rapid application development model (RAD).
4. Evolutionary
development and validation are interleaved.
5. Incremental model.
6. Iterative model.
7. Spiral model.
8. Component-based software engineering : The system
is assembled from existing components.

System Requirements
Software Requirements

Architectural Design

Detailed Design


There are many variants of these models e.g. formal
development where a waterfall-like process is used, but
the specification is formal that is refined through several
stages to an implementable design[1].



Fig. 2 Waterfall Model[4].

3. Five Models
A Programming process model is an abstract
representation to describe the process from a particular
perspective. There are numbers of general models for
software processes, like: Waterfall model, Evolutionary
development, Formal systems development and Reusebased development, etc. This research will view the following five models :
1. Waterfall model.
2. Iteration model.
3. V-shaped model.
4. Spiral model.
5. Extreme model.
These models are chosen because their features
correspond to most software development programs.


System and
Software Design

and Unit Testing

Integration and
System Testing

3.1 The Waterfall Model
The waterfall model is the classical model of software engineering. This model is one of the oldest models and is widely used in government projects and in many major companies. As this model emphasizes planning in early stages, it ensures design flaws before they develop. In addition, its intensive document and planning make it work well for projects in which quality control is a major

Operation and
Fig. 3 Waterfall model[2].

The following list details the steps for using the waterfall

IJCSI International Journal of Computer Science Issues, Vol. 7, Issue 5, September 2010 ISSN (Online): 1694-0814

1 System requirements: Establishes the components for building the system, including the hardware requirements, software tools, and other necessary components. Examples include decisions on hardware, such as plug-in boards (number of channels, acquisition speed, and so on), and decisions on external pieces of software, such as databases or libraries.


Software requirements: Establishes the expectations for software functionality and identifies which system requirements the software affects. Requirements analysis includes determining interaction needed with other applications and databases, performance requirements, user interface requirements, and so on.

Architectural design: Determines the software framework of a system to meet the specific requirements. This design defines the major components and the interaction of those components, but it does not define the structure of each component. The external interfaces and tools used in the project can be determined by the designer.


Detailed design: Examines the software components defined in the architectural design stage and produces a specification for how each component is implemented.







starting coding. There is no overlap between stages. In real-world development, however, one can discover issues during the design or coding stages that point out errors or
gaps in the requirements.

The waterfall method does not prohibit returning to an earlier phase, for example, returning from the design phase to the requirements phase. However, this involves costly rework. Each completed phase requires formal review and extensive documentation development. Thus, oversights made in the requirements phase are expensive to correct later.
Because the actual development comes late in the process, one does not see results for a long time. This delay can be disconcerting to management and customers. Many people also think that the amount of documentation is excessive and inflexible.
Although the waterfall model has instructive because it emphasizes project development. Even if one model, he must consider each of relationship to his own project [4].



Testing: Determines whether the software meets the specified requirements and finds any errors present in the code.
Maintenance: Addresses problems and enhancement requests after the software releases.

In some organizations, a change control board maintains the quality of the product by reviewing each change made in the maintenance stage. Consider applying the full waterfall development cycle model when correcting problems or implementing these enhancement requests.

In each stage, documents that explain the objectives and describe the requirements for that phase are created. At the end of each stage, a review to determine whether the project can proceed to the next stage is held. Your prototyping can also be incorporated into any stage from the architectural design and after.
Many people believe that this model cannot be applied to all situations. For example, with the pure waterfall model, the requirements must be stated before beginning the design, and the complete design must be stated before





its weaknesses, it is important stages of does not apply this these stages and its

Advantages :
Easy to understand and implement.
Widely used and known (in theory!).
Reinforces good habits:
define-before- design,
Identifies deliverables and milestones.
Document driven, URD, SRD, … etc. Published
documentation standards, e.g. PSS-05.
Works well on mature products and weak teams.
Disadvantages :
Idealized, doesn’t match reality well.
Doesn’t reflect iterative nature of exploratory
3. Unrealistic to expect accurate requirements so
early in project.
Software is delivered late in project, delays discovery
of serious errors.
Difficult to integrate risk management.
Difficult and expensive to make changes to
documents, ”swimming upstream”.
Significant administrative overhead, costly for small
teams and projects [6].
Pure Waterfall

This is the classical system development model. It consists
of discontinuous phases:

Architectural design.

IJCSI International Journal of Computer Science Issues, Vol. 7, Issue 5,
September 2010 ISSN (Online): 1694-0814


Detailed design.
Coding and development.
Testing and implementation.
Table 1: Strengths & Weaknesses of Pure Waterfall


Minimizes planning overhead since it can
be done up front. Structure minimizes wasted effort, so it works well for technically weak or inexperienced staff.

Risk reduction spirals can be added to the top of the waterfall to reduce risks prior to the waterfall phases. The waterfall can be further modified using options such as prototyping, JADs or CRC sessions or other methods of requirements gathering done in overlapping phases [5].


3.2 Iterative Development


Only the final phase produces a nondocumentation deliverable.

Backing up to
address mistakes is

The problems with the Waterfall Model created a demand for a new method of developing systems which could provide faster results, require less up-front information, and offer greater flexibility. With Iterative Development, 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.

 Pure Waterfall Summary
The pure waterfall model performs well for products with clearly understood requirements or when working with well understood technical tools, architectures and infrastructures. Its weaknesses frequently make it inadvisable when rapid development is needed. In those cases, modified models may be more effective.


Modified Waterfall

The modified waterfall uses the same phases as the pure waterfall, but is not based on a discontinuous basis. This enables the phases to overlap when needed. The pure waterfall can also split into subprojects at an appropriate phase (such as after the architectural design or detailed

Table 2: Strengths & Weaknesses of Modified Waterfall


More flexible than the pure waterfall model.
If there is personnel continuity between the phases, documentation can be substantially
reduced. Implementation of easy areas does not need to wait for the hard ones.


Modified Waterfall Summary

Milestones are more ambiguous than the pure waterfall.
Activities performed in parallel are subject to miscommunication and mistaken assumptions.
Unforeseen interdependencies can create problems.

Fig. 4 Iterative Development.

3.3 V-Shaped Model
Just like the waterfall model, the V-Shaped life cycle is a sequential path of execution of processes. Each phase must be completed before the next phase begins. Testing is emphasized in this model more than the waterfall model. The testing procedures are developed early in the life cycle before any coding is done, during each of the phases preceding implementation. Requirements begin the life cycle model just like the waterfall model. Before

IJCSI International Journal of Computer Science Issues, Vol. 7, Issue 5, September 2010 ISSN (Online): 1694-0814

development is started, a system test plan is created. The
test plan focuses on meeting the functionality specified in
requirements gathering.



The high-level design phase focuses on system architecture and design. An integration test plan is created in this phase in order to test the pieces of the software systems ability to work together. However, the low-level design phase lies where the actual software components are designed, and unit tests are created in this phase as well.

System Test

High Level

Low Level

The implementation phase is, again, where all coding takes place. Once coding is complete, the path of execution continues up the right side of the V where the test plans developed earlier are now put to use.

Simple and easy to use.
Each phase has specific deliverables.
Higher chance of success over the waterfall model due to the early development of test plans during the life cycle.
Works well for small projects where requirements are easily understood.

Unit Test









Fig. 6 V-Shaped Life Cycle Model[7].

3.4 Spiral Model
The spiral model is similar to the incremental model, with more emphases placed on risk analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A software project repeatedly passes through these phases in iterations (called Spirals in this model). The baseline spiral, starting in the planning phase, requirements are gathered and risk is assessed. Each subsequent spiral builds on the baseline spiral. Requirements are gathered during the planning phase. In the risk analysis phase, a process is undertaken to identify risk and alternate solutions. A prototype is produced at the end of the risk analysis phase. Software is produced in the engineering phase, along with testing at the end of the phase. The evaluation phase allows the customer to evaluate the output of the project to date before the project continues to the next spiral.

In the spiral model, the angular component represents progress, and the radius of the spiral represents cost.

Fig. 5 V-Model [3]



Very rigid like the waterfall model.
Little flexibility and adjusting scope is difficult and expensive. Software is developed during the implementation phase, so no early prototypes of the software are produced.
This Model does not provide a clear path for problems found during testing phases [7].



High amount of risk analysis.
Good for large and mission-critical projects.
Software is produced early in the software life cycle.


Can be a costly model to use.
Risk analysis requires highly specific expertise.
Project’s success is highly dependent on the risk analysis phase.
Doesn’t work well for smaller projects [7].


IJCSI International Journal of Computer Science Issues, Vol. 7, Issue 5, September 2010 ISSN (Online): 1694-0814


Spiral model sectors
Objective setting :Specific objectives for the phase are
2. Risk assessment and reduction: Risks are assessed and
activities are put in place to reduce the key risks.
3. Development and validation: A development model
for the system is chosen which can be any of the
general models.
4. Planning: The project is reviewed and the next phase
of the spiral is planned [1].


under which the system would produce win-lose or loselose outcomes for some stakeholders. 3. Identify and Evaluate Alternatives: Solicit suggestions from stakeholders, evaluate them with respect to stakeholders’ win conditions, synthesize and negotiate candidate win-win alternatives, analyze, assess, resolve win-lose or lose-lose risks, record commitments and areas to be left flexible in the project’s design record and life cycle plans.
4. Cycle through the Spiral: Elaborate the win conditions evaluate and screen alternatives, resolve risks, accumulate appropriate commitments, and develop and execute downstream plans [8].

3.5 Extreme Programming
An approach to development, based on the development and delivery of very small increments of functionality. It relies on constant code improvement, user involvement in the development team and pair wise programming . It can be difficult to keep the interest of customers who are involved in the process. Team members may be unsuited to the intense involvement that characterizes agile methods. Prioritizing changes can be difficult where there are multiple stakeholders. Maintaining simplicity requires extra work. Contracts may be a problem as with other approaches to iterative development.

Fig. 7 Spiral Model of the Software Process[1].

 WinWin Spiral Model
The original spiral model [Boehm 88] began each cycle of the spiral by performing the next level of elaboration of the prospective system’s objectives, constraints and alternatives. A primary difficulty in applying the spiral model has been the lack of explicit process guidance in determining these objectives, constraints, and alternatives. The Win-Win Spiral Model [Boehm 94] uses the theory W (win-win) approach [Boehm 89b] to converge on a system’s next-level objectives, constraints, and alternatives. This Theory W approach involves identifying the system’s stakeholders and their win conditions, and using negotiation processes to determine a mutually satisfactory set of objectives, constraints, and alternatives for the stakeholders. In particular, as illustrated in the figure, the nine-step Theory W process translates into the following spiral model extensions:
1. Determine Objectives: Identify the system life-cycle stakeholders and their win conditions and establish initial system boundaries and external interfaces.
2. Determine Constraints: Determine the conditions

Fig. 8 The XP Release Cycle

 Extreme Programming Practices
Incremental planning: Requirements are recorded on
Story Cards and the Stories to be included in a release are
determined by the time available and their relative priority. The developers break these stories into development
Small Releases: The minimal useful set of functionality
that provides business value is developed first. Releases of the system are frequent and incrementally add
functionality to the first release.

IJCSI International Journal of Computer Science Issues, Vol. 7, Issue 5, September 2010 ISSN (Online): 1694-0814

Simple Design: Enough design is carried out to meet the current requirements and no more.
Test first development: An automated unit test framework is used to write tests for a new piece of functionality before functionality itself is implemented. Refactoring: All developers are expected to re-factor the code continuously as soon as possible code improvements are found. This keeps the code simple and maintainable. Pair Programming: Developers work in pairs, checking each other’s work and providing support to do a good job. Collective Ownership: The pairs of developers work on all areas of the system, so that no islands of expertise develop and all the developers own all the code. Anyone can change anything.

Continuous Integration: As soon as work on a task is complete, it is integrated into the whole system. After any such integration, all the unit tests in the system must pass. Sustainable pace: Large amounts of over-time are not considered acceptable as the net effect is often to reduce code quality and medium term productivity. On-site Customer: A representative of the end-user of the system (the Customer) should be available full time for the use of the XP team. In an extreme programming process, the customer is a member of the development team and is responsible for bringing system requirements to the team for implementation.



XP and agile principles
Incremental development is supported through small, frequent system releases.
Customer involvement means full-time customer engagement with the team.
People not process through pair programming, collective ownership and a process that avoids long
working hours.
Change supported through regular system releases. Maintaining simplicity through constant refactoring of code [1].


Lightweight methods suit small-medium size projects.
Produces good team cohesion.
Emphasises final product.
Test based approach to requirements and quality


Difficult to scale up to large projects where
documentation is essential.
Needs experience and skill if not to degenerate into
Programming pairs is costly.




Test case construction is a difficult and specialized
skill [6].

4. Conclusion and Future Work
After completing this research , it is concluded that :
1. There are many existing models for developing
systems for different sizes of projects and
2. These models were established between 1970 and
3. Waterfall model and spiral model are used commonly
in developing systems.
4. Each model has advantages and disadvantages for the
development of systems , so each model tries to
eliminate the disadvantages of the previous model
Finally, some topics can be suggested for future works:



Suggesting a model to simulate advantages that are
found in different models to software process
Making a comparison between the suggested model
and the previous software processes management
Applying the suggested model to many projects to
ensure of its suitability and documentation to explain
its mechanical work.

[1] Ian Sommerville, “Software Engineering”, Addison
Wesley, 7th edition, 2004.
[2] 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 .
[3] Steve Easterbrook, “Software Lifecycles”, University
of Toronto Department of Computer Science, 2001.
[4] National Instruments Corporation, “Lifecycle Models”,
2006 ,
[5] JJ Kuhl, “Project Lifecycle Models: How They Differ
and When to Use Them”,2002
[6] Karlm, “Software Lifecycle Models’, KTH,2006 .
[7] Rlewallen, “Software Development Life Cycle
Models”, 2005 ,
[8] Barry Boehm, “Spiral Development: Experience,
Principles, and Refinements”, edited by Wilfred J.
Hansen, 2000 .
Nabil Mohammed Ali Munassar was born in Jeddah, Saudi
Arabia in 1978. He studied Computer Science at University of Science and Technology, Yemen from 1997 to 2001. In 2001 he

IJCSI International Journal of Computer Science Issues, Vol. 7, Issue 5, September 2010 ISSN (Online): 1694-0814
received the Bachelor degree. He studied Master of Information Technology at Arab Academic, Yemen, from 2004 to 2007. Now
he Ph.D. Student 3 year of CSE at Jawaharlal Nehru
Technological University (JNTU), Hyderabad, A. P., India. He is working as Associate Professor in Computer Science &
Engineering College in University Of Science and Technology, Yemen. His area of interest include Software Engineering, System Analysis and Design, Databases and Object Oriented
Dr.A.Govardhan: received Ph.D. degree in Computer Science
and Engineering from Jawaharlal Nehru Technological University in 2003, M.Tech. from Jawaharlal Nehru University in 1994 and B.E. from Osmania University in 1992. He is Working as a
Principal of Jawaharlal Nehru Technological University, Jagitial. He has published around 108 papers in various national and
international Journals/conferences. His research of interest includes Databases, Data Warehousing & Mining, Information
Retrieval, Computer Networks, Image Processing, Software
Engineering, Search Engines and Object Oriented Technologies.


Cite this page

Comparison between five process models of software engineering. (2016, Apr 15). Retrieved from

Comparison between five process models of software engineering

👋 Hi! I’m your smart assistant Amy!

Don’t know where to start? Type your requirements and I’ll connect you to an academic expert within 3 minutes.

get help with your assignment