Xem thêm

Mô hình thác nước

CEO Hùng PV
Mô hình thác nước là một mô hình tuyến tính (không lặp lại) được sử dụng đặc biệt cho việc phát triển phần mềm và được tổ chức theo các giai đoạn dự án kế...

Stufen des Wasserfallmodells (Beispiel)

Mô hình thác nước là một mô hình tuyến tính (không lặp lại) được sử dụng đặc biệt cho việc phát triển phần mềm và được tổ chức theo các giai đoạn dự án kế tiếp nhau. Tương tự như nước thác với nhiều bậc thang, kết quả của mỗi giai đoạn rơi xuống giai đoạn tiếp theo và trở thành yêu cầu bắt buộc ở đó.

Trên mô hình thác nước, mỗi giai đoạn có các điểm bắt đầu và kết thúc được xác định trước với các kết quả được xác định rõ ràng. Thông thường, mô hình cũng mô tả các hoạt động cụ thể cần được thực hiện để tạo ra các kết quả. Tại các cột mốc cụ thể và cuối giai đoạn, các tài liệu phát triển được thông qua quy định trong quản lý dự án.

Tên "thác nước" xuất phát từ cách biểu thị đồ họa thường được chọn để sắp xếp các giai đoạn dự án thành một loạt các bậc thang. Trong thực tế kinh doanh, nó là một mô hình phổ biến, có nhiều biến thể.

Các biến thể của mô hình đơn giản (mô hình thác nước với thụt lùi) giới thiệu các khía cạnh lặp lại và cho phép một tiến trình bước chạy lên bậc thang. Sự thay đổi từ nguyên tắc liên quan trực tiếp đến khi cần phải điều chỉnh trong giai đoạn hiện tại, đòi hỏi phân phối lại vào giai đoạn trước, ví dụ như điều chỉnh trong thiết kế hệ thống hoặc hướng dẫn người dùng dựa trên thông tin từ quá trình thử nghiệm.

Mô hình thác nước được áp dụng phổ biến trong trường hợp yêu cầu, hiệu suất và quy trình có thể được mô tả tương đối chính xác trong giai đoạn lập kế hoạch.

Lịch sử

Mô hình thác nước ban đầu xuất phát từ quy trình xây dựng và sản xuất, các quy trình được cấu trúc cao cho các nhiệm vụ trong đó việc thay đổi muộn là đắt đỏ hoặc thậm chí không thể. Sau khi không có quy trình phát triển phần mềm chính thức vào thời điểm mô hình thác nước được miêu tả lần đầu tiên, các quy trình được sử dụng trong xây dựng và sản xuất đã được chỉ định đơn giản để áp dụng vào phát triển phần mềm.

Mô hình thác nước trong phát triển phần mềm được biết đến lần đầu tiên qua bài thuyết trình về việc phát triển phần mềm cho SAGE của Herbert D. Benington tại Hội nghị về phương pháp lập trình tiên tiến cho máy tính kỹ thuật số vào ngày 29 tháng 6 năm 1956. Năm 1983, bài thuyết trình được tái xuất bản với lời giới thiệu của Benington, trong đó ông mô tả rằng quá trình không được thực hiện theo cách thẳng từ đầu đến cuối, mà dựa trên một nguyên mẫu.

Mô hình thác nước được ghi nhận lần đầu tiên thông qua công trình của Winston W. Royce, mặc dù ông không sử dụng tên "thác nước" trong bài viết của mình năm 1970. Ông đã mô tả mô hình như là một mô hình cần được cải tiến và đề xuất các thay đổi sau:

  • Thêm giai đoạn thiết kế trước giai đoạn phân tích, trong đó một mô phỏng sớm (nguyên mẫu) của sản phẩm cuối cùng cũng được triển khai và tài liệu hóa bằng cùng mô hình.
  • Quy hoạch, đo lường và theo dõi quá trình kiểm thử để đảm bảo rằng kiểm thử đáp ứng mục tiêu của mình.
  • Liên tục tham gia của khách hàng dưới dạng đánh giá.

Các giai đoạn

  1. Phân tích và xác định yêu cầu dẫn đến bảng yêu cầu.
  2. Thiết kế hệ thống và xác định dẫn đến kiến trúc phần mềm.
  3. Lập trình và kiểm tra đơn vị dẫn đến phần mềm thực sự.
  4. Kiểm tra hợp nhất và hệ thống.
  5. Giao hàng, triển khai và bảo trì phần mềm.

Một biến thể khác giới thiệu sáu bước:

  1. Lập kế hoạch (bao gồm việc tạo lập bảng yêu cầu, ước tính dự án và lập kế hoạch dự án) (Kỹ thuật hệ thống).
  2. Xác định (bao gồm việc xác định bảng yêu cầu, mô hình sản phẩm, mô hình giao diện và có thể đã có tài liệu người dùng).
  3. Thiết kế (UML, lưu đồ) (Thiết kế).
  4. Triển khai (lập trình).
  5. Kiểm thử (Báo cáo kiểm thử).
  6. Triển khai và bảo trì (Bảo trì).

"Xác định và thiết kế" tương đối tương đồng với cơ sở phân loại "Thiết kế hệ thống và xác định" trong biến thể đầu tiên, trong khi biến thể thứ hai tổng hợp hai mức kiểm tra phần mềm (kiểm tra đơn vị và kiểm tra toàn diện).

Đặc điểm

  1. Các hoạt động phải được thực hiện theo thứ tự và toàn bộ chiều rộng được xác định.
  2. Kết thúc của mỗi hoạt động là một tài liệu hoàn chỉnh, có nghĩa là mô hình thác nước là một mô hình "dựa vào tài liệu".
  3. Quá trình phát triển là tuần tự; nghĩa là mỗi hoạt động phải hoàn thành trước khi hoạt động tiếp theo bắt đầu.
  4. Nó dựa trên phương pháp từ trên xuống.
  5. Nó đơn giản và dễ hiểu.
  6. Sự tham gia của người dùng dự định được dự định trong giai đoạn ban đầu, sau đó thiết kế và triển khai không liên quan đến người dùng hoặc bên trao đổi. Những thay đổi tiếp theo là các yêu cầu mới.

Lợi ích

  1. Rõ ràng về phân loại giai đoạn.
  2. Dễ dàng lập kế hoạch và kiểm soát.
  3. Ước tính rõ ràng về chi phí và phạm vi với yêu cầu ổn định.

Vấn đề và nhược điểm

  1. Vấn đề phân loại: Các giai đoạn rõ ràng phân tách thường không thực tế - sự chuyển tiếp giữa các giai đoạn là mờ nhạt: Một số phần của hệ thống có thể vẫn đang trong giai đoạn lập kế hoạch trong khi các phần khác đã được triển khai hoặc sử dụng.
  2. Vấn đề tuần tự: Các giai đoạn được thực hiện theo thứ tự trong lý thuyết, nhưng trong thực tế, việc quay lại bước trước là không thể tránh khỏi.
  3. Không linh hoạt đối với thay đổi và tiến trình (các giai đoạn phải được thực hiện theo thứ tự tuần tự).
  4. Xác định yêu cầu sớm thường gặp vấn đề, vì nó có thể dẫn đến các thay đổi đắt đỏ (quá trình lặp lại nhiều lần qua cùng quá trình với các thay đổi).
  5. Sự triển khai của hệ thống vào thời gian sau khi chu kỳ phát triển đã bắt đầu, vì vậy đòi hỏi đầu tư trễ trên vốn đầu tư.
  6. Đưa ra hệ thống hoàn chỉnh vào một thời điểm nhất định (Big Bang) có thể dẫn đến việc phát hiện lỗi muộn và yêu cầu công sức lớn để khắc phục.

Vì khó khăn để định rõ từ đầu tất cả và chi tiết, có nguy cơ rằng kết quả cuối cùng (ví dụ: phần mềm) không phù hợp với yêu cầu thực tế. Để đối phó với vấn đề này, thường phải đầu tư một số công việc không cân xứng trong giai đoạn phân tích và thiết kế. Ngoài ra, mô hình thác nước không cho phép hoặc rất hạn chế việc thay đổi trong quá trình dự án. Kết quả cuối cùng do đó không phản ánh yêu cầu hiện tại mà phản ánh yêu cầu ban đầu vào dự án. Vì dự án phần mềm lớn thường có thời gian vận hành dài, có thể xảy ra tình trạng phần mềm mới đã lỗi thời ngay từ khi được triển khai.

Các mô hình phương pháp khác

Do các bất lợi nghiêm trọng của mô hình thác nước với những hậu quả kinh tế đáng kể, ngành công nghiệp CNTT đã phát triển nhiều phương pháp, công nghệ, đề xuất và công cụ tương thích hoặc bổ sung. Ví dụ điển hình bao gồm:

  • Spiral model (Phát triển tiếp theo)
  • Rational Unified Process
  • Extreme Programming
  • Agile Software Development
  • Qui trình thử nghiệm lặp và Qui trình thử nghiệm tiến hóa
  • Sử dụng phần mềm tiêu chuẩn có thể cấu hình được, ví dụ: quản lý quy trình làm việc hoặc quản lý người dùng
  • Quản lý thay đổi mở rộng đến giai đoạn phát triển
  • Giao cho người dùng cuối các nhiệm vụ ít được ưu tiên, xem thêm về End-user Computing
  • Phân mảnh đáng kể, thậm chí chia nhỏ các dự án lớn thành các dự án nhỏ hơn, dễ quản lý hơn và có thời gian chạy ngắn hơn
  • V-Model

Xem thêm

  • Vorgehensmodell zur Softwareentwicklung (Cách thức phát triển phần mềm)
  • Danh sách quy trình phát triển phần mềm

Tài liệu

  • Karl Pfetzing, Adolf Rohde: Ganzheitliches Projektmanagement. 5. Ausgabe. Gießen 2014, ISBN 978-3-921313-90-9.

Liên kết

  • Mô tả mô hình thác nước Viện Nghiên cứu Thiết kế và Hiệu ứng
  • Winston W. Royce: Quản lý việc phát triển các hệ thống phần mềm lớn. (PDF; 436 kB)

Tham khảo

  1. Herbert D. Benington: Production of Large Computer Programs. In: IEEE Educational Activities Department (Hrsg.): IEEE Annals of the History of Computing. Band 5, Nr. 4, 1. Oktober 1983, S. 350-361.
  2. United States Navy Mathematical Computing Advisory Panel (Hrsg.): Symposium on advanced programming methods for digital computers. 26. Juni 1956.
  3. Herbert D. Benington: Production of Large Computer Programs. In: IEEE Annals of the History of Computing. Band 5, Nr. 4. IEEE Educational Activities Department, 1. Oktober 1983, S. 350-361.
  4. Winston Royce: Managing the Development of Large Software Systems. Hrsg.: Proceedings, IEEE WESCON. 26. Auflage, Institute of Electrical and Electronics Engineers, August 1970, S. 328-338.
1