Mô hình thác nước (tiếng Anh: waterfall model) là một mô hình của quy trình phát triển phần mềm, trong
đó quy trình phát triển trông giống như một dòng chảy, với các pha được thực hiện theo trật tự nghiêm
ngặt và không có sự quay lui hay nhảy vượt pha là: phân tích yêu cầu, thiết kế, triển khai thực hiện, kiểm
thử, liên kết và bảo trì. Người ta thường dẫn bài báo được Winston W. Royce xuất bản vào năm 1970 để
giải thích nguồn gốc cho tên gọi "thác nước"; nhưng có điều thú vị là chính Royce đã dùng mô hình phát
triển lặp chứ không hề dùng thuật ngữ "mô hình thác nước".

[sửa]Nội
dung của mô hình
Vào năm 1970 trong bài báo của mình, Royce đã mô tả ở dạng khái niệm cái mà ngày nay được công
nhận với tên gọi "mô hình thác nước", đã bàn luận về những nhược điểm của mô hình này. Trong đó ông
cũng chỉ ra rằng mô hình này có thể sẽ được tu sửa thành mô hình lặp.
Mô hình Royce nguyên gốc có các pha theo đúng thứ tự sau:
1. Xác định yêu cầu
2. Thiết kế
3. Xây dựng (hay "triển khai", "mã hóa", "viết mã")
4. Liên kết
5. Kiểm thử và Chỉnh sửa (hay «kiểm nghiệm»)
6. Cài đặt
7. Bảo trì
Theo mô hình thác nước, người phát triển phải thực hiện từng giai đoạn theo thứ tự nghiêm ngặt. Trước
hết, giai đoạn "xác định yêu cầu" phải được hoàn tất, kết quả nhận được sẽ là danh sách các yêu cầu đối
với phần mềm. Sau khi các yêu cầu đã hoàn toàn được xác định, sẽ chuyển sang pha thiết kế, ở pha này
người ta sẽ tạo ra các tài liệu dành cho lập trình viên, trong đó mô tả chi tiết các phương pháp và kế
hoạch thực hiện các yêu cầu đã được làm rõ ở pha trước. Sau khi pha thiết kế hoàn tất, lập trình viên sẽ
triển khai thực hiện (mã hóa, viết mã) đồ án họ nhận được. Giai đoạn tiếp theo là liên kết các thành phần
riêng lẻ đã được những đội lập trình viên khác nhau thực hiện thành một sản phẩm hoàn chỉnh. Sau khi
pha triển khai và pha liên kết hoàn tất, sẽ diễn ra pha kiểm thử và chỉnh sửa sản phẩm; ở giai đoạn này
những khiếm khuyết ở các giai đoạn trước đó sẽ bị loại bỏ. Sau đó, sản phẩm phần mềm sẽ được đưa
vào sử dụng; phần bảo trì phần mềm cũng sẽ được bảo đảm bằng cách bổ sung chức năng mới và loại
trừ các lỗi.
Như vậy, mô hình thác nước ngụ ý rằng, việc chuyển từ pha phát triển này sang pha khác sẽ diễn ra chỉ
sau khi các pha trước đó đã kết thúc hoàn toàn thành công, và không thể quay lui về pha trước đó hay
nhảy vượt pha.
Tuy nhiên, tồn tại một số mô hình thác nước biến thể (bao gồm cả mô hình của Royce), trong đó quy
trình phát triển đã được mô tả ở trên bị biến đổi không nhiều hoặc cũng có thể bị biến đổi đáng kể.
Bài viết này trình bày những mô hình phát triển phần mềm cơ bản.
Một dự án phát triển phần mềm thường trải qua các hoạt động sau đây:
- Phân tích yêu cầu.
- Thiết kế và lập trình.
- Test.
- Bảo trì.
Mỗi mô hình phát triển phần mềm đưa ra một cách tổ chức sắp xếp khác nhau của các hoạt động này.
1. Mô hình thác nước (waterfall)
Đây là mô hình phát triển phần mềm cổ điển nhất. Mô hình này đề nghị các hoạt động được tiến
hành như các giai đoạn tách biệt, giai đoạn sau sẽ không bắt đầu chừng nào giai đoạn trước chưa
hoàn thành. Sản phẩm đầu ra của giai đoạn trước trở thành đầu vào của giai đoạn sau.
Những mũi tên ngược từ dưới lên trên cho thấy những sai lầm ở giai đoạn trước có thể được phát
hiện ở giai đoạn sau và đòi hỏi việc quay ngược lên để làm lại giai đoạn trước. Tuy nhiên ,hoạt động
quay lui này chỉ nên được coi là các ngoại lệ mà thôi.
Mô hình thác nước có ưu điểm là dễ quản lí. Đây chính là mô hình ưa thích của các nhà quản lí dự
án. Thời gian hoàn thành dự án thường được dự báo với độ chính xác hơn so với các mô hình khác.
Các tài liệu đầu ra của từng giai đoạn cũng được xây dựng đầy đủ và hệ thống hơn. Tuy nhiên mô
hình này có một số nhược điểm lớn là:
- Mô hình đòi hòi một bản yêu cầu (requirement) đầy đủ và chính xác từ phía khách hàng. Yêu cầu
này hiếm khi đạt được bởi khách hàng ít khi xác định được chính xác họ muốn gì ở ngay giai đoạn
đầu của dự án, sở thích của họ cũng thay đổi khá thường xuyên. Việc làm lại các giai đoạn ban đầu
để đáp ứng sự thay đổi của khách hàng thường mất rất nhiều công sức và phá vỡ cấu trúc của phần
mềm.
- Khách hàng cần phải kiên nhẫn. Họ chỉ được tham gia vào dự án ở giai đoạn phân tích yêu cầu và
test mà thôi. Ngoài ra, sản phẩm sẽ chỉ được bàn giao khi tất cả các công việc liên quan đã được
hoàn thành.
Mô hình thác nước chỉ nên được sử dụng khi đội dự án đã có kinh nghiệm, yêu cầu từ khách hàng
được xác định rõ ngay từ đầu và ít có khả năng thay đổi. Hiện nay, mô hình thác nước vẫn được sử
dụng rộng rãi do tính gần gũi với các mô hình phát triển trong các ngành kĩ thuật khác.
Waterfall model
From Wikipedia, the free encyclopedia
The waterfall model is a sequential design process, often used in software development processes, in which
progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception,
Initiation, Analysis, Design, Construction, Testing, Production/Implementation and Maintenance.
The unmodified "waterfall model". Progress flows from the top to the bottom, like a waterfall.
The waterfall development model originates in the manufacturing and construction industries: highly structured
physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal
software development methodologies existed at the time, this hardware-oriented model was simply adapted for
software development.[citation needed]
The first known presentation describing use of similar phases in software engineering was held by Herbert D.
Benington at Symposium on advanced programming methods for digital computers on 29 June 1956. [1] This
presentation was about the development of software for SAGE. In 1983 the paper was republished[2] with a
foreword by Benington pointing out that the process was not in fact performed in strict top-down, but depended
on a prototype.
The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce,[3] though
Royce did not use the term "waterfall" in this article. Royce presented this model as an example of a flawed,
non-working model (Royce 1970). This, in fact, is how the term is generally used in writing about software
development—to describe a critical view of a commonly used software practice.[4]

[edit]Model
In Royce's original waterfall model, the following phases are followed in order:
1.
Requirements specification
2.
Design
3.
Construction (AKA implementation or coding)
4.
Integration
5.
Testing and debugging (AKA Validation)
6.
Installation
7.
Maintenance
Thus the waterfall model maintains that one should move to a phase only when its preceding phase is
completed and perfected. However, there are various modified waterfall models (including Royce's final model)
that may include slight or major variations upon this process.
[edit]Supporting
arguments
Time spent early in the software production cycle can lead to greater economy at later stages. McConnell
shows that a bug found in the early stages (such as requirements specification or design) is cheaper in money,
effort, and time, to fix than the same bug found later on in the process. ([McConnell 1996], p. 72, estimates that
"...a requirements defect that is left undetected until construction or maintenance will cost 50 to 200 times as
much to fix as it would have cost to fix at requirements time.") To take an extreme example, if a program design
turns out to be impossible to implement, it is easier to fix the design at the design stage than to realize months
later, when program components are being integrated, that all the work done so far has to be scrapped
because of a broken design.
This is the central idea behind Big Design Up Front and the waterfall model: time spent early on making sure
requirements and design are correct saves you much time and effort later. Thus, the thinking of those who
follow the waterfall process goes, make sure each phase is 100% complete and absolutely correct before you
proceed to the next phase. Program requirements should be set in stone before design begins (otherwise work
put into a design based on incorrect requirements is wasted). The program's design should be perfect before
people begin to implement the design (otherwise they implement the wrong design and their work is wasted),
etc.
A further argument for the waterfall model is that it places emphasis on documentation (such as requirements
documents and design documents) as well as source code. In less designed and documented methodologies,
should team members leave, much knowledge is lost and may be difficult for a project to recover from. Should
a fully working design document be present (as is the intent of Big Design Up Front and the waterfall model)
new team members or even entirely new teams should be able to familiarize themselves by reading the
documents.
As well as the above, some prefer the waterfall model for its simple approach and argue that it is more
disciplined. Rather than what the waterfall adherent sees as chaos, the waterfall model provides a structured
approach; the model itself progresses linearly through discrete, easily understandable and explainable phases
and thus is easy to understand; it also provides easily markable milestones in the development process. It is
perhaps for this reason that the waterfall model is used as a beginning example of a development model in
many software engineering texts and courses.
It is argued that the waterfall model and Big Design up Front in general can be suited to software projects that
are stable (especially those projects with unchanging requirements, such as with shrink wrap software) and
where it is possible and likely that designers will be able to fully predict problem areas of the system and
produce a correct design before implementation is started. The waterfall model also requires that implementers
follow the well-made, complete design accurately, ensuring that the integration of the system proceeds
smoothly.
[edit]Criticism
Many argue the waterfall model is a bad idea in practice—believing it impossible for any non-trivial project to
finish a phase of a software product's lifecycle perfectly before moving to the next phases and learning from
them. For example, clients may not know exactly what requirements they need before reviewing a working
prototype and commenting on it. They may change their requirements constantly. Designers and programmers
may have little control over this. If clients change their requirements after the design is finalized, the design
must be modified to accommodate the new requirements. This effectively means invalidating a good deal of
working hours, which means increased cost, especially if a large amount of the project's resources has already
been invested in Big Design Up Front.
Designers may not be aware of future implementation difficulties when writing a design for an unimplemented
software product. That is, it may become clear in the implementation phase that a particular area of program
functionality is extraordinarily difficult to implement. In this case, it is better to revise the design than persist in a
design based on faulty predictions, and that does not account for the newly discovered problems.
Even without such changing of the specification during implementation, there is the option either to start a new
project from scratch, "on a green field", or to continue some already existing, "a brown field" (from construction
again). The waterfall methodology can be used for continuous enhancement, even for existing software,
originally from another team. As well as in the case when the system analyst fails to capture the customer
requirements correctly, the resulting impacts on the following phases (mainly the coding) still can be tamed by
this methodology, in practice: A challenging job for a QA team.
Steve McConnell, in Code Complete, (a book that criticizes widespread use of the waterfall model) refers to
design as a "wicked problem"—a problem whose requirements and limitations cannot be entirely known before
completion. The implication of this is that it is impossible to perfect one phase of software development, thus it
is impossible if using the waterfall model to move on to the next phase.
David Parnas, in A Rational Design Process: How and Why to Fake It, writes:[5]
“Many of the [system's] details only become known to us as we progress in the [system's] implementation.
Some of the things that we learn invalidate our design and we must backtrack.”
Expanding the concept above, the project stakeholders (non-IT personnel) may not be fully aware of the
capabilities of the technology being implemented. This can lead to what they "think is possible" defining
expectations and requirements. This can lead to a design that does not use the full potential of what the new
technology can deliver, or simply replicates the existing application or process with the new technology. This
can cause substantial changes to the implementation requirements once the stakeholders become more aware
of the functionality available from the new technology. An example is where an organization migrates from a
paper-based process to an electronic process. While key deliverables of the paper process must be
maintained, benefits of real-time data input validation, traceability, and automated decision point routing may
not be anticipated at the early planning stages of the project.
The idea behind the waterfall model may be "measure twice; cut once," and those opposed to the waterfall
model argue that this idea tends to fall apart when the problem constantly changes due to requirement
modifications and new realizations about the problem itself. A potential solution is for an experienced developer
to spend time up front on refactoring to consolidate the software, and to prepare it for a possible update, no
matter if such is planned already. Another approach is to use a design targeting modularity with interfaces, to
increase the flexibility of the software with respect to the design.
Due to the types of criticisms discussed above some organisations, such as the US Department of Defense,
now have a preference against waterfall type methodologies, starting with Mil-Std-498 "clearly encouraging
evolutionary acquisition and IID".[6]
The current DoD Standard 5000.2, released in 2000, states a clear preference against waterfall: "There are two
approaches, evolutionary and single step [waterfall], to full capability. An evolutionary approach is preferred. …
[In this] approach, the ultimate capability delivered to the user is divided into two or more blocks, with
increasing increments of capability...software development shall follow an iterative spiral development process
in which continually expanding software versions are based on learning from earlier development."
[edit]Modified
models
In response to the perceived problems with the pure waterfall model, many modified waterfall models have
been introduced. These models may address some or all of the criticisms of the pure waterfall model. [citation
needed]
Many different models are covered by Steve McConnell in the "lifecycle planning" chapter of his
book Rapid Development: Taming Wild Software Schedules.
While all software development models bear some similarity to the waterfall model, as all software development
models incorporate at least some phases similar to those used in the waterfall model, this section deals with
those closest to the waterfall model. For models that apply further differences to the waterfall model, or for
radically different models seek general information on the software development process.
[edit]See
also

Agile software development

Big Design Up Front

Chaos model

Iterative and incremental development

Iterfall development

Rapid application development

Software development process

Spiral model

System Development Methodology

V-model

Dual Vee Model

List of software development philosophies
[edit]References
1.
^ United States. Navy Mathematical Computing Advisory Panel. (29 June 1956), Symposium on advanced
programming methods for digital computers, [Washington, D.C.]: Office of Naval Research, Dept. of the
Navy, OCLC 10794738
2.
^ Benington, Herbert D. (1 October 1983). "Production of Large Computer Programs". IEEE Annals of the
History of Computing (IEEE Educational Activities Department) 5 (4): 350–
361.doi:10.1109/MAHC.1983.10102. Retrieved 2011-03-21.
3.
^ Wasserfallmodell > Entstehungskontext, Markus Rerych, Institut für Gestaltungs- und Wirkungsforschung,
TU-Wien. Accessed on line November 28, 2007.
4.
^ Conrad Weisert, Waterfall methodology: there's no such thing!
5.
^ "A Rational Design Process: How and Why to Fake It", David Parnas (PDF file)
6.
^ Iterative and Incremental Development: A Brief History, Craig Larman and Victor Basili, IEEE Computer,
June 2003
Waterfall Model
The waterfall model is a model for software development (a process for the creation of software), which
develop regularly flowing downwards (like a waterfall). The development runs through a number of
phases, namely: definition study / analysis, basic design, technical design / detailed design,
construction, testing, integration, management and maintenance. Previously, a large software
development, especially large cluttered knitting. With the advent of this new method, the computer
companies hoped to clarify in their projects.
Phases
The waterfall model is derived from the traditional way of working in large construction projects in
construction. The purpose of this way of working is that divides the project into phases. You start with
phase 1 and phase 2 to begin no earlier than when you have completed Phase 1. And when you’re in a
phase of an error you must do to correct back to that stage and the subsequent steps again.
History of the Waterfall Model - Phases - Pro’s and Con’s - New Waterfall Model
History of the Waterfall Model
On the origin of the term “waterfall” is often said that Winston Royce introduced it in 1970, but Royce
saw themselves more in the repeated approach to software development and even used the term
“waterfall”. Royce described the waterfall model as a method he ventured even an invitation to failure
occurred. In 1970 Royce was that the waterfall model should be seen as the first draft, he felt that the
method has flaws. He brought a document which examined how the initial concept to a recurrent
method could be developed, this new model in each phase was between a feedback to the previous
stage, as we now see in many current methods. Royce was just annoying for the initial focus method,
the criticism he had on this method was largely ignored Despite Royces intentions to the waterfall model
into a repeat method (iterative model), the use of this method is still very popular, but opponents of the
waterfall model see it as a naive and inappropriate method for use in the real world “.
The waterfall model consists of the following phases:
Definition study / analysis. Research is being conducted and to brainstorm about the software to get
clear what the purpose of the software. Basic design. It clearly worked out what happened during the
first phase unearthed. In this phase, the customer put on paper and has been given to the shape of the
program. This phase is set to deliver what it has to do. Technical design / detail design. Using the basic
design can be thought of an actual program. In this phase determines how the functionality defined in
the basic design will be realized. Now is also a place subdivision in engineering units such as programs,
modules and functions. Construction / implementation. Here is the source code of programs
written. Testing. It checks whether the software is built right to the designs. Also at this stage errors that
surfaced in earlier stages made. Integration. The system is ready and tested. It will however take the
company to be put into use. This is done in this phase. Management and maintenance. In order to
ensure that the system will continue to do maintenance to be performed. The waterfall model consists of
several stages. Each phase has its own level also determines the order. The highest level is performed
first and then the lower stages. This is equal to the natural functioning of a waterfall and hence the
name. Above clearly shows that the various phases from top to bottom.
Pro’s and Con’s
Advantages
If in the beginning of the project failures are detected, it takes less effort (and therefore time and money)
for this error. In the waterfall model phases to be properly sealed first before proceeding to the next
stage. It is believed that the phases are correct before proceeding to the next phase. In the waterfall
model lay the emphasis on documentation. In the newer software development methodologies makes it
less documentation. This means that when new people in the project, and people leave it is difficult to
transfer knowledge. This disadvantage is not the traditional waterfall model. It is a straightforward
method. The way of working ensures that there are specific phases. This tells you what stage it is. One
can use this method of milestones. Milestones can be used to monitor the progress of the project to
estimate. The waterfall model is well known. Many people have experienced, so there might be easy to
work. When frequent portions of the software product to be delivered this gives the customer
confidence, but also the software development team.
The waterfall model, as described above, offers numerousadvantages for software developers. First, the staged
development cycleenforces discipline: every phase has a defined start and end point, andprogress can be
conclusively identified (through the use of milestones) by bothvendor and client. The emphasis on
requirements and design before writing asingle line of code ensures minimal wastage of time and effort and
reduces therisk of schedule slippage, or of customer expectations not being met.
Getting the requirements and design out of the way firstalso improves quality; it's much easier to catch and
correct possible flaws atthe design stage than at the testing stage, after all the components have beenintegrated
and tracking down specific errors is more complex. Finally, becausethe first two phases end in the production
of a formal specification, thewaterfall model can aid efficient knowledge transfer when team members
aredispersed in different locations.
Disadvantages
There are some disadvantages of this way to develop software. Many software projects are dependent
on external factors. The client is a very important external factor. Often the requirements over the
course of the project change, because the client wants something different. It is a disadvantage that the
waterfall model assumes that the requirements will not change during the project. When a requirement
changes in the construction phase, a substantial number of phases made again. It is very difficult to
time and cost estimate. The phases are very large, it is therefore very difficult to estimate how much
each step cost. In a number of new methods are almost all aspects of a software development process
included. One can think of planning techniques, project management methods and how the project
should be organized. In many software projects, different people at different stages of the project. For
example: the designers and builders. They all have a different view of the project as designers look at
the project differently than the builders. Conversely, the builders often different from the design of the
designers look than the designers themselves. Frequently, the design will be adjusted again. Here is the
waterfall model is not made for that. Within the project the team members often specialized. One team
member will be only the first phase involved the design, while the only builders in construction helping to
build the project. This can lead to waste of different sources. The main source is the time. An example:
the designers are working on perfecting the design. The builders are in principle already start building,
but because they work with the waterfall model, they should wait until the first phase is complete. This is
a typical example of wasted time. Testing is done only in one of the last phases of the project. In many
other software development methods will be tested once a certain part and finished product is at last an
integration test. Because so much emphasis on documentation, the waterfall model is not efficient for
smaller projects. There’s too much effort to the project itself around in terms of documentation.
Renewed Waterfall Model
To maximize use of the benefits and minimize suffering from the disadvantages, some new models
have been developed. Here are the main ones:
Royce Model
Royce’s model describes that it is wrong that the waterfall model can not be returned to the previous
phase. Often in a stage show that in a previous stage something has gone wrong, it should be possible
to facilitate a return to the previous stage.
The “sashimi” model
Schematic overview of the sashimi waterfall model with overlapping phases … The sashimi model was
developed by Peter Degrace. The phases are the same as the traditional waterfall model, only now the
phases overlap each other. By using this method are much less resources wasted. The figure at right
shows how the phases overlap. This is an illustration and this may not reflect actual overlap in terms of
money again! The difference with the schematic overview of the standard waterfall model is that the
stage this time at the turnaround printed. This means, for example begins with the design while analysis
is in progress. This also means that one can fall back on the analysis in the design.
Aorta Lifecycle Model
The Aorta Lifecycle model works like the Waterfall Model. Feedback between each phase and stage
has an essential role in this model, as you can see in our article about the Aorta Lifecycle Model.
V Waterfall Model
The V waterfall model is a linear software development method in which main focus is balanced
development. We published our view about the V Waterfall Model earlier.
What is the Waterfall Model?
The waterfall model is a sequential software development model in which development is seen
as flowing steadily downwards (like a waterfall) through several phases.
History of the Waterfall Model
In 1970 Royce proposed what is now popularly referred to as the waterfall model as an initial
concept, a model which he argued was flawed (Royce 1970). His paper then explored how the
initial model could be developed into an iterative model, with feedback from each phase
influencing previous phases, similar to many methods used widely and highly regarded by many
today.
Despite Royce's intentions for the waterfall model to be modified into an iterative model, use of
the "waterfall model" as a purely sequential process is still popular, and, for some, the phrase
"waterfall model" has since come to refer to any approach to software creation which is seen as
inflexible and non-iterative.
Usage of the waterfall model
In Royce's original waterfall model, the following phases are followed perfectly in sequential
order:







Requirements specification
o Requirements are captured and set in stone.
Design
o A "blueprint" is drawn up for the developers to implement.
Implementation
Integration
Testing
Installation
Maintenance
The waterfall model maintains that one should move to a phase only when its preceding phase is
completed and perfected. Phases of development in the waterfall model are thus discrete, and
there is no jumping back and forth or overlap between them.
As many find this approach particularly rigid, modifications have been made over the years and
new variants of the model have emerged.
Criticism of the waterfall model
The waterfall model however is argued by many to be a bad idea in practice, mainly because of
their belief that it is impossible to get one phase of a software product's lifecycle "perfected"
before moving on to the next phases and learning from them. A typical problem is when
requirements change midway through, resulting in a lot of time and effort being invalidated due
to the "Big Design Up Front".
In summary, the criticisms of a non-iterative development approach (such as the waterfall model)
are as follows:



Poor flexibility; the majority of software is written as part of a contract with a client, and clients
are notorious for changing their stated requirements. Thus the software project must be
adaptable, and spending considerable effort in design and implementation based on the idea
that requirements will never change is neither adaptable nor realistic in these cases.
Unless those who specify requirements and those who design the software system in question
are highly competent, it is difficult to know exactly what is needed in each phase of the software
process before some time is spent in the phase "following" it.
Constant testing from the design, implementation and verification phases is required to validate
the phases preceding them. Users of the waterfall model may argue that if designers follow a
disciplined process and do not make mistakes that there is no need to constantly validate the




preceding phases.
Frequent incremental builds (following the "release early, release often" philosophy) are often
needed to build confidence for a software production team and their client.
It is difficult to estimate time and cost for each phase of the development process.
The waterfall model brings no formal means of exercising management control over a project
and planning control and risk management are not covered within the model itself.
Only a certain number of team members will be qualified for each phase, which can lead at
times to some team members being inactive.