0% found this document useful (0 votes)
190 views4 pages

Modifications to the Waterfall Model

This document summarizes a proposed model to overcome problems in the waterfall software development model. The waterfall model is a basic sequential model where each phase must be completed before the next begins. However, it faces problems with accommodating changes late in the process and detecting defects too late. The proposed model discusses modifications to address these issues, such as allowing for prototyping and user feedback earlier to catch issues prior to implementation. It also acknowledges the need for flexibility to allow for changes based on user needs and requirements that may evolve over time.

Uploaded by

Tripti Sagar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
190 views4 pages

Modifications to the Waterfall Model

This document summarizes a proposed model to overcome problems in the waterfall software development model. The waterfall model is a basic sequential model where each phase must be completed before the next begins. However, it faces problems with accommodating changes late in the process and detecting defects too late. The proposed model discusses modifications to address these issues, such as allowing for prototyping and user feedback earlier to catch issues prior to implementation. It also acknowledges the need for flexibility to allow for changes based on user needs and requirements that may evolve over time.

Uploaded by

Tripti Sagar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

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
[Link]@[Link]

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 [Link] covers
not only the technical aspects of building software systems
but also management issues, such as directing
programming teams, scheduling, and [Link] 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 [Link] 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 [Link] 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 [Link] 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

Common questions

Powered by AI

The Waterfall model is described as a 'sequential life cycle model' because of its linear and successive phase progression, where each phase depends on the completion of the preceding one. This sequential nature implies strict phase boundaries in project management, enforcing discipline and a structured timeline. However, it also reduces flexibility, making handling changes mid-process cumbersome and often costly. This characteristic necessitates a well-defined set of requirements at the project's outset, with minimal opportunity for revisions, posing risks in dynamic environments or projects with evolving requirements .

Verification and validation mechanisms at the end of each phase in the Waterfall model ensure that outputs are accurate and consistent with inputs. These mechanisms include thorough documentation reviews, requirement inspections, design examinations, code testing through unit tests, and system testing during integration. These checks serve as certification points to confirm each phase meets defined standards before moving to the next phase, ensuring that any discrepancies are addressed early, maintaining the project's integrity and continuity .

The primary phases of the Waterfall model are Requirement Analysis and Definition, System and Software Design, Implementation and Unit Testing, Integration and System Testing, and Operation and Maintenance. These phases address the complexity of software development by breaking down the project into smaller, manageable tasks, each focusing on a distinct area of concern. This linear and sequential approach allows for thorough verification and validation, ensuring the output of each phase is consistent with its input. By having a clear sequence, it helps engineers and managers efficiently manage the complexity and ensure a well-structured development process .

In handling complex projects with changing requirements, the Waterfall model's rigid sequential structure becomes a key shortcoming. It's difficult to modify requirements after the testing phase, leading to inflexible project paths. Changes necessitate revisiting earlier phases, which can be cumbersome and costly. Furthermore, the delayed user engagement until the late stages limits timely feedback, increasing the risk of developing features that do not meet user needs or expectations. This inflexibility also escalates costs and stifles adaptability in dynamic project environments where requirements frequently evolve .

The System and Software Design phase contributes to the overall structure and functionality by transitioning requirements into a detailed chronological layout of both system architecture and component design. It allocates requirements between hardware and software, ensuring all elements are coherently integrated for functionality. This phase involves significant modeling and descriptive activities, facilitating a comprehensive blueprint guiding subsequent phases. By defining these details, it sets a foundation for coherent implementation and eventual integration, ensuring that the software's architecture aligns with user expectations and system constraints .

The Waterfall model is unsuitable for projects where requirements are prone to change, including object-oriented or ongoing projects, due to its linear and rigid structure. Its inability to accommodate requirement changes after the testing phase makes it challenging to address evolving user needs. Additionally, user involvement and feedback occur only towards the end of the project’s life, potentially leading to requirements mismatches and costly modifications. These limitations can result in increased development costs and project delays, making the Waterfall model less viable for dynamic environments .

User involvement in the Waterfall model is typically limited, often occurring primarily during the early requirement analysis and late acceptance testing phases. This limited engagement can significantly affect the development process, as infrequent user feedback may lead to the development of a solution that misaligns with user needs or expectations, increasing the potential for costly post-deployment modifications. Without ongoing input, developers risk proceeding with flawed assumptions, which only come to light once the system is nearly complete, thereby hindering the model's effectiveness in rapidly adapting to user-driven changes or insights .

The introduction of a prototype in the 'proposed waterfall model' addresses traditional Waterfall shortcomings by allowing iterative interaction and feedback between developers and users throughout the development cycle. This interaction facilitates dynamic requirement refinement, helping to minimize the risk of requirement mismatches. Prototyping provides means to validate requirements early, making the process adaptive to changes rather than strictly sequential. This reduces the likelihood of costly post-testing revisions and aligns final specifications more accurately with user expectations, thus overcoming rigidity and enhancing user involvement across all stages .

The integration and system testing phase is critical for verifying that software requirements are met by evaluating the system as a cohesive entity. Key activities include integrating individual program units into one system and conducting extensive testing to ensure interoperability and functional compliance. This phase validates that each component and subsystem work in unison, identifying discrepancies against user requirements. The process involves executing test cases derived from requirements to detect defects, consequently ensuring that integration provides a fully functional system conforming to expected outcomes .

Integrating CASE tools within the Waterfall model potentially offers advantages such as automation of repetitive tasks, enhanced documentation management, and seamless cross-phase data consistency. These tools can aid in maintaining transitional outputs, ensuring each phase commences with accurate inputs. However, challenges arise due to the rigidity of the Waterfall model, which can lead to resistance in adapting to tool outputs that might suggest phase revisits. Furthermore, significant upfront resource investment is needed for tools setup and integration, which may not align with the linear nature if phase review loops increase due to tool diagnostics .

You might also like