Mô Hình Thác Nước – Wikipedia Tiếng Việt

Bài viết này cần thêm chú thích nguồn gốc để kiểm chứng thông tin. Mời bạn giúp hoàn thiện bài viết này bằng cách bổ sung chú thích tới các nguồn đáng tin cậy. Các nội dung không có nguồn có thể bị nghi ngờ và xóa bỏ.
Một phần của loạt bài về
Phát triển phần mềm
Hoạt động cốt lõi
  • Mô hình hóa dữ liệu
  • Quy trình
  • Yêu cầu
  • Thiết kế
  • Xây dựng
  • Công nghệ
  • Thử nghiệm
  • Gỡ lỗi
  • Triển khai
  • Bảo trì
Mô hình và hình mẫu
  • Linh hoạt
  • Phòng sạch
  • Tăng dần
  • Nguyên mẫu
  • Xoắn ốc
  • Mô hình V
  • Thác nước
Phương pháp và framework
  • ASD
  • DevOps
  • DAD
  • DSDM
  • FDD
  • IID
  • Kanban
  • Lean SD
  • LeSS
  • MDD
  • MSF
  • PSP
  • RAD
  • RUP
  • SAFe
  • Scrum
  • SEMAT
  • TDD
  • TSP
  • OpenUP
  • UP
  • XP
Các ngành hỗ trợ
  • Quản lý cấu hình
  • Tài liệu
  • Đảm bảo chất lượng phần mềm
  • Quản lý dự án
  • Trải nghiệm người dùng
Thực hành
  • ATDD
  • BDD
  • CCO
  • CI
  • CD
  • DDD
  • PP
  • SBE
  • Đứng
  • TDD
Công cụ
  • Trình biên dịch
  • Trình gỡ lỗi
  • Hồ sơ
  • Trình thết kế GUI
  • Mô hình hóa UML
  • IDE
  • Tự động hóa xây dựng
  • Tự động hóa phát hành
  • Cơ sở hạ tầng dưới dạng mã
Tiêu chuẩn và khối kiến thức
  • CMMI
  • Tiêu chuẩn IEEE
  • ISO 9001
  • Tiêu chuẩn ISO/IEC
  • PMBOK
  • SWEBOK
  • ITIL
  • IREB
  • OMG
Bảng thuật ngữ
  • Trí tuệ nhân tạo
  • Khoa học máy tính
  • Kỹ thuật điện và điện tử
Sơ lược
  • Sơ lược về phát triển phần mềm
  • x
  • t
  • s
Mô hình thác nước.

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".

Nội dung mô hình thác nước

[sửa | sửa mã nguồn]

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ể.

Sự phê bình mô hình thác nước và các giải pháp phương pháp học lai

[sửa | sửa mã nguồn]

Xem thêm

[sửa | sửa mã nguồn]
  • Phương pháp học mềm dẻo của việc phát triển
  • Phát triển lặp
  • Mô hình xoắn ốc

Tham khảo

[sửa | sửa mã nguồn]
  • Royce, Winston (1970), Managing the Development of Large Software Systems Lưu trữ 2016-03-15 tại Wayback Machine (tiếng Anh)
Bài viết này vẫn còn sơ khai. Bạn có thể giúp Wikipedia mở rộng nội dung để bài được hoàn chỉnh hơn.
  • x
  • t
  • s

Đọc thêm

[sửa | sửa mã nguồn]
  • McConnell, Steve (2006). Software Estimation: Demystifying the Black Art. Microsoft Press. ISBN 0-7356-0535-1.
  • McConnell, Steve (2004). Code Complete, 2nd edition. Microsoft Press. ISBN 1-55615-484-4.
  • McConnell, Steve (1996). Rapid Development: Taming Wild Software Schedules. Microsoft Press. ISBN 1-55615-900-5.
  • Parnas, David, A rational design process and how to fake it (PDF) An influential paper which criticises the idea that software production can occur in perfectly discrete phases.
  • Royce, Winston (1970), “Managing the Development of Large Software Systems” (PDF), Proceedings of IEEE WESCON, 26 (August): 1–9, Bản gốc (PDF) lưu trữ ngày 15 tháng 3 năm 2016, truy cập ngày 2 tháng 1 năm 2011.
  • "Why people still believe in the waterfall model"
  • The standard waterfall model for systems development NASA webpage, archived on Internet Archive ngày 10 tháng 3 năm 2005.
  • Parametric Cost Estimating Handbook Lưu trữ 2010-01-20 tại Wayback Machine, NASA webpage based on the waterfall model, archived on Internet Archive ngày 8 tháng 3 năm 2005.

Liên kết ngoài

[sửa | sửa mã nguồn] Wikimedia Commons có thêm hình ảnh và phương tiện truyền tải về Mô hình thác nước.
  • Understanding the pros and cons of the Waterfall Model of software development
  • "Waterfall model considered harmful" Lưu trữ 2010-04-16 tại Wayback Machine
  • Project lifecycle models: how they differ and when to use them
  • Going Over the Waterfall with the RUP by Philippe Kruchten
  • CSC and IBM Rational join to deliver C-RUP and support rapid business change
  • x
  • t
  • s
Công nghệ phần mềm
Các lĩnh vựcPhân tích yêu cầu • Phân tích hệ thống • Thiết kế phần mềm • Lập trình máy tính • Các phương pháp hình thức • Kiểm thử phần mềm • Triển khai phần mềm • Bảo trì phần mềm
Các khái niệmMô hình hóa dữ liệu • Kiến trúc doanh nghiệp • Chi tiết hóa chức năng • Ngôn ngữ mô hình hóa • Mô hình lập trình • Phần mềm • Kiến trúc phần mềm • Phương pháp học phát triển phần mềm • Quy trình phát triển phần mềm • Chất lượng phần mềm • Bảo đảm chất lượng phần mềm • Khảo cổ học phần mềm • Phân tích có cấu trúc
Các định hướngĐịnh hướng khía cạnh • Định hướng đối tượng • Ontology • Định hướng dịch vụ • Vòng đời phát triển hệ thống
Các mô hình
Các mô hình phát triểnLinh hoạt • Mô hình lặp • RUP • Scrum • Mô hình xoắn ốc • Mô hình thác nước • XP • V-Model • Mô hình tăng tiến • Mô hình nguyên mẫu
Các mô hình khácAutomotive SPICE • CMMI • Mô hình dữ liệu • Mô hình hàm • Mô hình thông tin • Mô hình hóa meta • Mô hình đối tượng • Mô hình hệ thống • Mô hình quan sát
Các ngôn ngữ mô hình hóaIDEF • UML
Các kỹ sư phần mềmKent Beck • Grady Booch • Fred Brooks • Barry Boehm • Ward Cunningham • Ole-Johan Dahl • Tom DeMarco • Martin Fowler • C. A. R. Hoare • Watts Humphrey • Michael A. Jackson • Ivar Jacobson • Craig Larman • James Martin • Bertrand Meyer • David Parnas • Winston W. Royce • Colette Rolland • James Rumbaugh • Niklaus Wirth • Edward Yourdon • Victor Basili
Các lĩnh vực liên quanKhoa học máy tính • Kỹ nghệ máy tính • Kỹ nghệ doanh nghiệp • Lịch sử • Quản lý • Toán học • Quản lý dự án • Quản lý chất lượng • Công thái học phần mềm • Kỹ nghệ hệ thống

Từ khóa » Sơ đồ Thác Nước