Waterfall model of SDLC
The stages of "The Waterfall Model" are:
Requirement Analysis & Definition: All possible requirements of the
system to be developed are captured in this phase. Requirements are
set of functionalities and constraints that the end-user (who will be
using the system) expects from the system. The requirements are
gathered from the end-user by consultation, these requirements are
analyzed for their validity and the possibility of incorporating the
requirements in the system to be development is also studied.
Finally, a Requirement Specification document is created which
serves the purpose of guideline for the next phase of the model.
System & Software Design: Before a starting for actual coding, it
is highly important to understand what we are going to create
and what it should look like? The requirement specifications
from first phase are studied in this phase and system design is
prepared. System Design helps in specifying hardware and system
requirements and also helps in defining overall system architecture.
The system design specifications serve as input for the next phase
of the model.
Implementation & Unit Testing: On receiving system design
documents, the works divided in modules/units and actual coding
is started. The system is first developed in small programs called
units, which are integrated in the next phase. Each unit is developed
and tested for its functionality; this is referred to as Unit Testing.
Unit testing mainly verifies if the modules/units meet
their specifications.
Integration & System Testing: As specified above, the system is
first divided in units which are developed and tested for their
functionalities. These units are integrated into a complete system
during Integration phase and tested to check if all modules/units
coordinate between each other and the system as a whole behaves
as per the specifications. After successfully testing the software, it
is delivered to the customer.
Operations & Maintenance: This phase of "The Waterfall Model" is
virtually never ending phase (Very long). Generally, problems with
the system developed (which are not found during the development
life cycle) come up after its practical use starts, so the issues related
to the system are solved after deployment of the system. Not all
the problems come in picture directly but they arise time to time
and needs to be solved; hence this process is referred as Maintenance.
Advantages and Disadvantages of Waterfall Model
Advantages
The advantage of waterfall development is that it allows for
departmentalization and managerial control. A schedule can be
set with deadlines for each stage of development and a product
can proceed through the development process like a car in a
carwash, and theoretically, be delivered on time. Development
moves from concept, through design, implementation, testing,
installation, troubleshooting, and ends up at operation and
maintenance. Each phase of development proceeds in strict
order, without any overlapping or iterative steps.
Disadvantages
The disadvantage of waterfall development is that it does
not allow for much reflection or revision. Once an application
is in the testing stage, it is very difficult to go back and change
something that was not well-thought out in the concept stage.
Alternatives to the waterfall model include joint application
development (JAD), rapid application development (RAD)
synch and stabilize, build and fix, and the spiral model.
Common Errors in Requirements Analysis
In the traditional waterfall model of software development
the first phase of requirements analysis is also the most
important one. This is the phase which involves gathering
information about the customer's needs and defining, in the
clearest possible terms, the problem that the product is
expected to solve. This analysis includes understanding the
customer's business context and constraints, the functions
the product must perform, the performance levels it must
adhere to, and the external systems it must be compatible
with. Techniques used to obtain this understanding include
customer interviews, use cases, and "shopping lists" of
software features. The results of the analysis are typically
captured in a formal requirements specification, which
serves as input to the next step. Well, at least that's the
way it's supposed to work theoretically. In reality, there
are a number of problems with this theoretical model, and
these can cause delays and knock-on errors in the rest of
the process. This article discusses some of the more
common problems that project managers experience during
this phase, and suggests possible solutions.
Problem 1: Customers don't (really) know what they want
Possibly the most common problem in the requirements
analysis phase is that customers have only a vague idea of
what they need, and it's up to you to ask the right questions
and perform the analysis necessary to turn this amorphous
vision into a formally-documented software requirements
specification that can, in turn, be used as the basis for both
a project plan and an engineering architecture.
To solve this problem, you should:
• Ensure that you spend sufficient time at the start of the
project on understanding the objectives, deliverables
and scope of the project.
• Make visible any assumptions that the customer is using
and critically evaluate both the likely end-user benefits
and risks of the project.
• Attempt to write a concrete vision statement for the project
which encompasses both the specific functions or user benefits
it provides and the overall business problem it is expected
to solve.
• Get your customer to read, think about and sign off on the
completed software requirements specification, to align
expectations and ensure that both parties have a clear
understanding of the deliverable.
Problem 2: Requirements change during the course of the project
The second most common problem with software projects
is that the requirements defined in the first phase change as
the project progresses. This may occur because as development
progresses and prototypes are developed, customers are able to
more clearly see problems with the original plan and make
necessary course corrections; it may also occur because changes
in the external environment require reshaping of the original
business problem and hence necessitates a different
solution than the one originally proposed. Good project managers
are aware of these possibilities and typically already have
backup plans in place to deal with these changes.
To solve this problem, you should:
• Have a clearly defined process for receiving, analyzing and
incorporating change requests, and make your customer
aware of his/her entry point into this process.
• Set milestones for each development phase beyond which certain
changes are not permissible -- for example, disallowing major
changes once a module reaches 75 percent completion.
• Ensure that change requests (and approvals) are clearly
communicated to all stakeholders, together with their rationale
and that the master project plan is updated accordingly.
Problem 3: Customers have unreasonable timelines
• It's quite common to hear a customer say something like
"it's an emergency job and we need this project completed
in X weeks". A common mistake is to agree to such timelines
before actually performing a detailed analysis and understanding
both of the scope of the project and the resources necessary to
execute it. In accepting an unreasonable timeline without discussion
you are, in fact, doing your customer a disservice: it's quite likely
that the project will either get delayed (because it wasn't possible
to execute it in time) or suffer from quality defects (because it was
rushed through without proper inspection).
• To solve this problem, you should:
• Convert the software requirements specification into a project plan
detailing tasks and resources needed at each stage and modeling
best-case, middlecase and worst-case scenarios.
• Ensure that the project plan takes account of available resource
constraints and keeps sufficient time for testing and quality inspection.
• Enter into a conversation about deadlines with your customer, using the
figures in your draft plan as supporting evidence for your statements.
Assuming that your plan is reasonable, it's quite likely that the ensuing
negotiation will be both productive and result in a favorable outcome for both
Problem 4: Communication gaps exist between customers, engineers and project
managers
• Often, customers and engineers fail to communicate clearly with each other
because they come from different worlds and do not understand technical
terms in the same way. This can lead to confusion and severe
miscommunication, and an important task of a project manager, especially
during the requirements analysis phase, is to ensure that both parties have a
precise understanding of the deliverable and the tasks needed to achieve it.
• To solve this problem, you should:
• Take notes at every meeting and disseminate these throughout the
project team.
• Be consistent in your use of words. Make yourself a glossary of the
terms that you're going to use right at the start, ensure all stakeholders
have a copy, and stick to them consistently
Problem 5: The development team doesn't understand the politics of the
customer's organization
The scholars Bolman and Deal suggest that an effective manager is one
who views the organization as a "contested arena" and understands the
importance of power, conflict, negotiation and coalitions. Such a manager
is not only skilled at operational and functional tasks, but he or she also
understands the importance of framing agendas for common purposes,
building coalitions that are united in their perspective, and persuading
resistant managers of the validity of a particular position. These skills
are critical when dealing with large projects in large organizations, as
information is often fragmented and requirements analysis is hence
stymied by problems of trust, internal conflicts of interest and
information inefficiencies.
To solve this problem, you should:
• Review your existing network and identify both the information you
need and who is likely to have it.
• Cultivate allies, build relationships and think systematically about
your social capital in the organization.
• Persuade opponents within your customer's organization by framing
issues in a way that is relevant to their own experience.
• Use initial points of access/leverage to move your agenda forward.
Please visit http://www.onestopqa.com/resources/SDLC%20Models.pdf for complete description of SDLC models.
