Volume 2, Spl.

Issue 2 (2015) e-ISSN: 1694-2329 | p-ISSN: 1694-2345

Proposed Model to Overcome the Problems

in Waterfall Model
Deeksha Datyal
Department ofsoftware engineering,
Baddi University of Emerging Sciences and Technology,Baddi
[email protected]

ABSTRACT-- In this paper, I have reviewed the modifications

in waterfall model for software development. Waterfall model 1. Software Specification:-
is a basic software development model which is mostly used to Where customers and engineers define the software that is
develop a software in software development organization. In to be produced and the constraints on its operation.
this paper the brief definition of waterfall model and various 2. Software Development:-
problems that were faced by software companies by using this Where the software is designed and programmed.
model are discussed or mentioned. So, the main objective of 3. Software Validation:-
this paper is to represent some modifications to the model in
Where the software is checked to ensure that it is what
order to solve most of the problems related to with the
the customer requires.
waterfall model. Commonly accepted problems are for
example to cope up with change and that defects all too often 4. Software evolution:-
are detected too late in the software development process. Where the software is modified to reflect changing
Another problem related to prototype that is user can only customer and market requirements.
view the proposed system after testing. If the users are not
satisfied with the developed system then it is too late to 1.2 Layers of SE
redesign it and the time and cost for implementation and Software engineering is a layered technology, that means
testing is totally wasted on selected design. to develop software one will have to go from one layer to
another .The layers are related and each layer demands the
Keywords: software engineering (SE), software process,
fulfillment of the previous. Figure below is the flowchart
software development model, software development, SDLC
(software development life cycle), layers of SE. of the layers of software engineering.

I. INTRODUCTION
1.1 Introduction to software engineering
Software engineering (SE) is the computer science
concerned with developing large applications.SE covers
not only the technical aspects of building software systems
but also management issues, such as directing
programming teams, scheduling, and budgeting.SE is an Fig 1:
engineering discipline that is concerned with all aspects of 1.2.1 Quality Focus
software production from the early stages of system Software engineering must rest on an organizational
specification through to maintaining the system after it has commitment to quality. Total quality management and
gone into use. similar philosophies foster a continuous process
improvement culture and it is this culture that ultimately
IEEE (IEE93) has developed a more comprehensive leads to thedevelopment of increasingly more effective
definition: approaches to SE.
“Software engineering is defined as the application of a
systematic, disciplined, quantifiable approach to the 1.2.2 Process
development, operation, and maintenance of software; that The foundation for software engineering is the process
is, the application of engineering of software.” layer. Process defines the set of key process area(KPA)
The systematic approach that is used in SE is sometimes that must be established for effective delivery of software
called a software process. A software process is a sequence engineering technology.
of activities that leads to the production of a software
product. There are four fundamental activities that are 1.2.3 Methods
common to all software processes. These activities are: SE methods include requirements analysis, design, coding,
testing, and support. Thhis rely on a set of basic principles

29 BUEST, Baddi RIEECE -2015

Volume 2, Spl. Issue 2 (2015) e-ISSN: 1694-2329 | p-ISSN: 1694-2345

that govern each area of the technology and include perform it efficiently and correctly. Furthermore, each of
modelling activities and other descriptive activities. the basic activities itselfmaybe so large that it cannot be
handled in single step and must be broken into smaller
1.2.4 Tools steps.
SE tools provide automated or semi-automated support for
the process and the methods. When tools are integrated so II. INTRODUCTION TO WATERFALL
thar information created by one tool can be used by MODEL
another, a system for the support of software development Waterfall model was the first process model to be introduced.
called computer-aided software engineering is established. It is also referred as a sequential life cycle model. Waterfall
model is very simple to understand and use. In a waterfall
1.3 Software Development Life cycle model, each phase must be completed before the next phase
SDLC in software engineering is the process of creating or can begin and there is no overlapping in the phases. The
altering systems, and the models and methodologies that basic idea behind the phases is that each phase deals with a
people use to develop these systems.Any SDLC should distinct and separate set of concerns. By doing this, the large
result in a high quality system that meets customer and complex task of building the software is broken into
expectations, reaches completion within time and cost smaller tasks. Splitting the project into different phases gives
estimates, works effectively and efficiently in the current a better handle to engineers and managers in dealing with the
and planned Information technology infrastructure and is complexity of the problem. Linear ordering of activities has
inexpensive to maintain and cost-effective to enhance. The some important consequences like, to clearly identify the end
SDLC framework provides a sequence of activities for of a phase and the beginning of the next, some certification
system designers and developers to follow. mechanism has to be employed at the end of each phase. It is
usually done by verification and validation which will ensure
1.3.1 Phases of SDLC that the output of a phase is consistent with its input. There is
1. Planning and requirement analysis a need for certification because each phase must have some
2. Defining requirement defined output that can be evaluated and certified. In
Waterfall model the whole process of software development
is divided into different phases.

2.1 Phases of Waterfall model

1. Requirement analysis and definition
2. System and Software design
3. Implementation and Unit testing
4. Integration and system testing
5. Operation and Maintenance
Fig 2:Software Development Life Cycle
1. Requirement analysis and definition
3. Designing Building and developing product In this phase all possible requirements of the system to be
4. Testing developed are stated. The system’s services,constraints
5. Deployment in the market and maintenance. and goals are established by consultation with system
users. Requirements are a set of functions and constraints
There are various software development life cycle models that the end user expects from the system. The
defined and designed which are followed during software requirements are gathered from the end user, and are
development process. E.g. waterfall model. Each process analysed for their validity and the possibility of
model follows a series of steps unique to its type, in order incorporating them. Requirements are gathered,analyzed
to ensure success in process of software development. and then proper documentation is prepared which helps
further in the development process.
Problem solving in software consists of these activities:
2. System and Software Design
1. Understanding the problem In this phase the system and software design is prepared
2. Deciding a plan for a solution from the requirement analysis and definition phase. The
3. Coding the planned solution systems design process allocates the requirements to either
4. Testing the actual program hardware or software sytems by establishing an overall
system architecture. The design phase consists of two
For large systems, each activity can be extremely sections: system design and component design. The
complex and methodologies and procedures are needed to system design contains details and specifications of the

BUEST, Baddi RIEECE-2015 30

Volume 2, Spl. Issue 2 (2015) e-ISSN: 1694-2329 | p-ISSN: 1694-2345

whole system and explains how each component of the solved after its deployment. Not all the problems come into
system will interact with others. The component design picture directly, but they arise from time to time and need
contains specifications as to how each component will to be solved; hence this process is referred to as
work separately and how results from one component will maintenance. This phase mainly focuses on modifying
travel to another.Software design involves identifying and software, correcting errors, and improving the performance
describing the fundamental software system abstractions of the software.
and relationships.
2.2 Shortcomings in Waterfall Model: When the
3. Implementation and Testing waterfall model is tested number of problems has occurred
During this phase, the software design is realized as a set in large extent.
of programs or program units and the program is divided 1. Difficulty in changing requirement:
into modules/units and actual coding starts. The system is Once an application is in the testing stage, it is very
first elaboratedinto small programs called units, which are difficult to go back and change something that was not
integrated in the next phase. Each unit is developed and well-thought out in the concept stage.
tested for its functionality, this is known as unit testing.
Unit testing involves verifying that each unit meets its 2. Impossible to view the model :
specification. The design generated in the above phase is User can only view the system after implementation. User
converted into machine language that the computers can involvement and working version of the system is not
actually understand and process. seen until late in the project’s life.

4. Integration and system testing 3. Too expensive:

In this phase, the individual program units are integrated Since requirement inconsistencies and missing components
to form a complete system and tested to ensure that the are discovered during design and coding phases,
software requirements have been met. Inengineering, increasing the development needs and therefore costs.
system integration is defined as the process of bringing
together the component subsystems into one system and 4. Not suitable for complex projects:
ensuring that the subsystems function together as a Waterfall model is not suitable for object oriented projects
system.[1] In information technology system integration is and ongoing projects. It is not suitable for projects where
the process of linking together different computing requirements are at a moderate to high risk of changing.
systems and software applications physically or Due to these weaknesses, the application of waterfall
functionally,to act as a coordinated whole. System model are limited to situations where the requirements and
integration is also about adding value to the system, their implementation are well understood. There is also a
capabilities that are possible because of interactions widely voiced opinion that the idea of Requirement Fixing
between subsystems. before the design and coding starts is too idealistic and
therefore impractical.

III. PROPOSED WATERFALL MODEL

The basic concept of proposed waterfall model is to eliminate
the use of well-defined project requirements. Projects are
allowed to grow as the customer needs and request grow.
Projects are initially designed according to basic requirements
and are refined as requirement become more refined. This
process allows customer to feel their way around the
application to ensure that they are developing exactly what
they want in the application. This model also works well for
determining the feasibility of certain approaches in regards to
an application. Prototypes allow for quickly developing
Fig 3: Waterfall Model
examples of implementing specific functionality based on
certain techniques. Because the working prototype has been
5. Operation and Maintenance:
evaluated by the customer, it is reasonable to expect that the
This phase delivers fully functioning operational software
resulting specification document will be correct. When the
to the user and this phase of the model is virtually never-
prototype is created, it is reviewed by the customer. This
ending. Generally, problems with the system (which are
review gives feedback to the developers that helps to remove
not found during the development cycle) come up after its
uncertainties in the requirements of the software and starts an
practical use starts, so the issues related to the system are
iteration of refinement on order to further clarify
31 BUEST, Baddi RIEECE -2015
Volume 2, Spl. Issue 2 (2015) e-ISSN: 1694-2329 | p-ISSN: 1694-2345

requirements. The prototype may be a usual program but is problematic situation for the development team. Generally,
not suitable as the final software product. The reason may be a prototype model has great advantage over other SDLC
poor performance, maintainability or overall quality. The models since it doesn’t rely on what is supposed to happen
code for the prototype is thrown away however the in written documentation. Instead it goes directly to the
experience gathered from developing the prototype helps in users and asking them what they really want from a
developing the actual system.This type of System software. Slowly the product is developed by
Development Method is employed when it is very difficult to professionals, catering to the needs of the users.
obtain exact requirements from the customer. The prototyping
approach is used in the requirement gathering and in the REFERENCES
analysis phase to capture the exact requirement of the 1. Ian Somerville, ”Software Engineering”, Pearson Ninth Edition,2011.
2. Roger S Pressman, ”Software Engineering A practitioners Approach”
proposed system. After the requirements are frozen, the
Sixth Edition 2010.
remaining phases of the development process needs to be 3. Stephen R Schach, “Software Engineering” Seventh Edition.
executed to complete the development of the software system. 4. International Journal of Engineering Research & Technology (IJERT):
“New Idea In Waterfall Model For Real Time Software Development”
Unnati A. Patel ,Niky K. Jain. ISSN: 2278-0181, Vol. 2 Issue 4, April –
Strengths of Proposed waterfall model
2013.
This modified waterfall model has the following strengths: 5. International Journal of Scientific & Engineering Research(IJSER),
1. One of the key advantages a proposed waterfall modeled Software Engineering Methodologies: A Review of the Waterfall
software has is the time frame of development. Instead of Model and Object Oriented Approach: Adetokunbo A.A. Adenowo,
Basirat A. Adenowo . , Volume 4, Issue 7, July-2013, ISSN 2229-
concentrating on documentation, more effort is placed in
5518.
creating the actual software. This way, the actual software
could be released in advance.
2. The work on this model could also be spread to others
since there are practically no stages of work in this model.
Everyone has to work on the same thing and at the same
time, reducing man hours in creating a software. The work
will even be faster and efficient if developers will
collaborate more regarding the status of a specific function
and develop the necessary adjustments in time for the
integration.
3. Another advantage of having a prototype modeled
software is that the software is created using lots of user
feedbacks. In every prototype created, users could give
their honest opinion about the software. If something is
unfavorable, it can be changed. Slowly the program is
created with the customer in mind.

Fig 4: Proposed Waterfall Model

CONCLUSION
After analysis of waterfall model, it has beenfound that the
original water fall model is used by various big companies
for their internal projects. Since in the big companies, most
of the time clients may change requirements at later phase
after partial development of the system, this is the
BUEST, Baddi RIEECE-2015 32