CHƯƠNG 2: CƠ SỞ LÝ THUYẾT
2.2 Tổng quan mô hình phát triển truyền thống
SDLC còn được gọi là chu trình hay vòng đời phát triển phần mềm (SDLC – Software Development Life Cycle). SDLC là tập hợp các công việc và quan hệ giữa chúng với nhau diễn ra trong quá trình phát triển phần mềm. Có khá nhiều mô hình SDLC khác nhau, trong đó một số được ứng dụng khá phổ biến trên thế giới như bên dưới
2.2.1 Mô hình thác nước (Waterfall)
Là một mô hình của quy trình phát triển phần mềm cổ điển nhất, Royce (1970) đã định nghĩa quá trình phát triển có cấu trúc và tuần tự 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, bao gồm các giai đoạn 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ì.
Hình 2-2: Mô hình thác nước (Waterfall) 1. Phân tích các yêu cầu:
Phân tích hệ thống dịch vụ, khó khăn và mục tiêu về sản phẩmmà người dùng mong muốn, được hình thành bởi sự gợi ý về hệ thống của chuyên gia phân tích và hiểu biết người dùng. Sau đó các yếu tố này được định nghĩa sao cho có thể hiểu được bởi cả người phát triển và người sử dụng.
2. Thiết kế phần mềm và hệ thống
Thiết kế hệ thống các quá trình, các bộ phận và các yêu cầu về cả phần mềm lẫn phần cứng. Hoàn tất hầu như tất cả kiến trúc của các hệ thống này. Thiết kế phần mềm tham gia vào việc biểu thị các chức năng hệ thống phần mềm mà có thể được chuyển dạng thành một hay nhiều chương trình khả thi.
3. Thực hiện và thử nghiệm đơn vị:
Trong giai đoạn này, thiết kế phần mềm phải được chứng thực như là một tập hợp nhiều chương trình hay nhiều đơn vị nhỏ. Thử nghiệm đơn vị bao gồm xác minh rằng mỗi đơn vị thỏa mãn đặc tả của nó.
4. Tổng hợp và thử nghiệm toàn bộ:
Các đơn vị chương trình riêng lẻ hay các chương trình được tích hợp lại và thử nghiệm như là một hệ thống hoàn tất và chứng tỏ được các yêu cầu của phần mềm được thỏa mãn. Sau khi thử nghiệm phần mềm được cung ứng cho người tiêu dùng.
5. Cài đặt và bảo trì:
Thông thường (nhưng không bắt buộc) đây là giai đoạn lâu nhất của chu kỳ sống (của sản phẩm). Phần mềm được cài đặt và được dùng trong thực tế. Bảo trì bao gồm điều chỉnh các lỗi mà chưa được phát hiện trong các giai đọan trước của chu kì sống, nâng cấp sự thực hiện của hệ thống các đơn vị và nâng cao hệ thống dịch vụ cho là các phát hiện vê yêu cầu mới.
Mô hình thác nước tinh khiết thực hiện tốt cho các sản phẩm với các yêu cầu được hiểu rõ ràng ngay từ đầu dự án và các công cụ kỹ thuật, kiến trúc và cơ sở hạ tầng. Điểm yếu của nó là không giao tiếp thường xuyên với khách hàng cũng như ít giao tiếp trong đội dự án làm cho nó không linh hoạt khicần có thay đổi hoặc sản phẩm cần sự phát triển một cách nhanh chóng khi yêu cầu chưa rõ ràng ngay từ đầu.
Nhận thấy những điểm yếu đó, năm 1981, Boehm có mở rộng và sửa đổi mô hình thác nước tinh khiết thành mô hình thác nước sửa đổi sử dụng các giai đoạn tương tự như cácthác nước tinh khiết nhưng cho phép các giai đoạn chồng lên nhau khi cần thiết. Thác nước tinh khiết khi đó có thể chia thành các tiểu dự án ở giai đoạn thích hợp.
Điểm yếu của mô hình này là nó không linh hoạt, rất nhiều các tài liệu phải tạo ra trong suốt quá trình phát triền của dự án như tài liệu đặc tả, tài liệu thiết kế kiến trúc, tài liệu thiết kế chi tiết, các báo cáo kiểm tra chất lượng, các báo cáo của trưởng dự án, nhân viên kiểm tra chất lượng,...Các bộ phận của dự án chia ra thành những bộ phận riêng theo giai đoạn. Hệ thống khi cài đặt đôi khi không dùng được vì không thỏa mãn được yêu cầu của khách hàng. Mặc dù vậy mô hình này phản ảnh thực tế công nghệ, đây vẫn là mô hình cơ sở cho đa số các hệ thống phát triển phần mềm.
2.2.2 Những thất bại của mô hình truyền thống
Một nghiên cứu thú vị được thực hiện bởi Standish Group trong 8,380 dự án từ năm 2002 đến năm 2010 cho 2 phương pháp truyền thống và linh hoạt. Người trả lời đại diện cho các công ty phần mềm lớn cho thấy chỉ có một tỷ lệ nhỏ các dự án (14%) với các phương pháp truyền thống đã được hoàn thành đúng thời gian và kinh phí với tất cả các tính năng và chức năng yêu cầu. 29% số dự án đã được hoàn thành vượt ngân sách, vượt quá thời gian cho phép và cung cấp ít tính năng hơn,57% số dự án đã bị hủy bỏ tại một số điểm trong chu kỳ phát triển hoặc thử thách (Standish Group, 2010). Hình bên dưới hiển thị kết quả của nghiên cứu. Nghiên cứu này cũng cho thấy một tỷ lệ khả quan hơn thuộc về các dự án linh hoạt, có 42% các dự án công đã được hoàn thành đúng thời gian, về ngân sách và với tất cả các tính năng và chức năng ban đầu được xác định. Hơn nữa, nghiên cứu cho thấy tỷ lệ thất bại là 9% thấp hơn 3 lần so với mô hình truyền thống là 29%.
Hình 2-3: Độ phân tán của dự án Một số điểm mạnh của mô hình truyền thống
- Tạo ra một hình ảnh chung về hệ thống trước khi phát triển - Dễ dàng cho các nhà phát triển hiểu hệ thống và làm theo Một số vấn đề chính (điểm yếu) của mô hình truyền thống
- Thay đổi yêu cầu thì không được chào đón, việc thay đổi yêu cầu chỉ được phép trong quá trình thu thập và phân tích yêu cầu
- Việc xác nhận thì không được thực hiện đầy đủ, lỗi của giai đoạn trước có thể bị ẩn giấu và gia tăng trong các giai đoạn tiếp theo. Trong hấu hết các trường hợp thì lỗi được phát hiện trễ trong giai đoạn kiểm nghiệm nên chi phí sửa lỗi và làm lại là rất cao
- Nhận phản hồi của khách hàng chậm trễ dẫn đến làm không đúng yêu cầu, không thỏa mãn được những thay đổi khách hàng.
Để giải quyết một số những sai phạm của các phương pháp truyền thống , phương pháp linh hoạt đã được đề xuất (Beck và cộng sự 2001).