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

Sở dĩ mô hình này được gọi là mô hình thác nước vì khi chúng ta nhìn vào hình ảnh trên có thể thấy nó rất giống một dòng thác, nước đổ từ trên xuống dưới và cũng chính vì vậy nên nó không bao giờ có chiều ngược lại, đây cũng là nhược điểm của mô hình này và ta sẽ nói ở đoạn sau. Mô hình này được nhắc tới vào năm 1970, trong một bài báo của Royce ông đã đưa ra các khái niệm đầu tiên về mô hình này. Nhìn chung mô hình này khá đơn giản nhưng nó lại theo một thứ tự khá nghiêm ngặt, các giai đoạn được chia ra một cách rõ ràng, hoàn toàn riêng biệt với nhau, kết thúc giai đoạn này mới chuyển sang giai đoạn khác. Đầu tiên là giai đoạn xác định và phân tích yêu cầu đặc tả, kết quả của giai đoạn này sẽ cho chúng ta một một danh sách các yêu cầu đối với phần mềm cần xây dựng. Sau đó là đến giai đoạn thiết kế, ở giai đoạn này sẽ tạo ra hàng loạt các tài liệu thiết kế chi tiết hơn nhằm cụ thể hóa các yêu cầu của khách hàng. Các tài liệu này sẽ dành cho các lập trình viên để nghiên cứu nó . Tiếp đến. các lập trình viên sẽ dựa vào các tài liệu thiết kế để lập trình theo các module, chức năng cho hệ thống. Xong giai đoạn này sẽ chuyển đến giai đoạn kiểm thử nhằm loại bỏ các lỗi và nâng cao chất lượng sản phẩm của mình. Cuối cùng phần mềm sẽ được deploy lên trên server thật của khách hàng.

Ưu điểm:

• Kiến trúc hệ thống hàng đợi ổn định.
• Mô hình này phát huy hiệu quả tốt nhất ở các dự án nhỉ vì đây là một mo hình đơn giản và dễ sử dụng.
• Vì các giai đoạn trong mô hình là rất rõ ràng nên rất thuận lợi cho việc bảo trì sau này.

Nhược điểm:

• Như đã đề cập ở trên mô hình này rất khó để có thể quay trở lại các giai đoạn trước khi có yêu cầu thay đổi hay lỗi lớn phát sinh.
• Chỉ có ở pha đầu tiên mới thực hiện việc tiếp xúc với khách hàng nên dễ xảy ra tình trạng phần mềm xây dựng xong không đáp ứng được nhu cầu của khách hàng.
• Mô hình này hầu như không được áp dụng vào các dự án lớn vì yếu tố rủi ro cao.

2. Mô hình V-model.

Chúng ta cùng đến với một mô hình có thể nói là một phiên bản cải tiến hơn, khắc phục được các nhược điểm của mô hình thác nước, đó là mô hình V-model. Mô hình này rất coi trọng yếu tố kiểm thử trong dự án. Nhìn trên hình vẽ ta có thể thấy được một nửa bên trái rất giống mô hình thác nước nhưng ở đây lại đi kèm với một nửa bên phải là các giai đoạn kiểm thử được tiến hành song song với các giai đoạn phát triển phần mềm. Cứ với mỗi giai đoạn phát triển là tương ứng luôn với một giai đoạn kiểm thử được thực hiện để có thể phát hiện sớm nhất các bug có thể có. Đây cũng là một điểm cộng của mô hình này khi có thể giảm thiếu tối đa các rủi ro cho phần mềm cần xây dựng. Vậy chúng ta hãy tìm hiểu cụ thể từng giai đoạn kiểm thử ở đây là gì nhé, tại sao lại có nhiều như vậy. Đầu tiên là giai đoạn kiểm thử đơn vị ứng với giai đoạn lập trình code bên phía phát triển. Ở giai đoạn này sẽ chủ yếu sử dụng đến kỹ thuật kiểm thử hộp trắng. Các dòng code, câu lệnh sẽ được review bằng mắt thường hoặc có thể sẽ có tool chuyên dụng để review trong giai đoạn này. Giai đoạn thứ hai là kiểm thử tích hợp ứng với giai đoạn thiết kế module bên phía phát triển. Ở giai đoạn này các tester sẽ kiểm thử từng module xem nó có cho kết quả đúng như mong đợi không. Các bug được phát hiện ra sẽ được ghi chép lại và theo dõi. Tiếp đến là giai đoạn kiểm thử hệ thống, ứng với giai đoạn phát triển thiết kế kiến trúc. Ở giai đoạn này ngoài việc thực hiện kiểm thử theo các Functional, các tester đã có thể thực hiện việc kiểm thử Non – Functional nhằm đảm bảo hệ thống vận hành được một cách tốt nhất khi được đưa vào sử dụng thực tế. Cuối cùng là kiểm thử chấp nhận, tương ứng với giai đoạn phân tích yêu cầu đặc tả, giai đoạn này có thể chia làm 2 phase: Alpha test và Beta test được thực hiện lần lượt để đảm bảo chất lượng một cách tốt nhất cho sản phẩm khi đưa ra thị trường thực tế.

Ưu điểm:

• Mô hình này phù hợp với các dự án vừa và nhỏ mà yêu cầu từ khách hàng là không rõ ràng.
• Chủ đông trong việc tìm bug
• Giảm thiểu được rủi ro trong quá trình phát triển phần mềm

Nhược điểm:

• Đối với các dự án mà phức tạp và khó hiểu thì việc thực hiện nhiều giai đoạn test như vậy tốn khá nhiều effort.
• Vẫn còn tồn tại sự cứng nhắc như mô hình thác nước.
• Mô hình vẫn chưa đưa ra được các hướng giải quyết rõ ràng khi tìm được các vấn đề qua các giai đoạn kiểm thử.
• Không thích hợp với các dự án mà có sự thay đổi về kỹ thuật nửa chừng.

3. Mô hình xoắn ốc.

Đúng như tên gọi của nó, mô hình này bao gồm các vòng tròn xoắn ốc đồng tâm, mỗi vòng tròn có thể được coi như một mô hình thác nước vậy, được phát triển lặp đi lặp lại cho đến khi kết thúc, được chia là 4 phase như sau:

• Định hướng mục tiêu: ở pha này chúng ta phải xác định được các mục tiêu ràng buộc và các giải pháp khác nhau để đạt được mục tiêu đó.
• Như ở mô hình V-model ta vừa tìm hiểu phía trên chú trọng vào các giai đoạn kiểm thử thì điểm nhấn ở mô hình này là gia đoạn phân tích và giảm thiểu rủi ro. Mô hình này để cao và chú trọng vào việc đánh giá đúng những rủi ro có thể gặp phải của dự án, thành công của dự án phụ thuộc rất nhiều vào giai đoạn này.
• Phát triển và kiểm thử: đây là giai đoạn bắt tay vào để hiện thực hóa các yêu cầu đã được đặt ra bao gồm các giai đoạn con như: thiết kế chi tiết, lập trình, tích hợp, kiểm thử và thực hiện.
• Cuối cùng là tiếp tục lên kế hoạch cho một xoắn ốc tiếp theo sẽ lại trải qua những giai đoạn đã nêu ở trên.

Ưu điểm:

• Thích hợp với các dự án lớn và quan trọng.
• Yếu tố rủi ro được chú trọng và đặt lên hàng đầu.
• Có thể linh động thay yêu cầu hay công nghệ qua từng vòng xoắn ốc,
• Giúp khách hàng có thể tiếp cận sớm với sản phẩm, nhìn thấy được các chức năng qua mỗi vòng xoắn ốc.

Nhược điểm:

• Khá tốn kém và phức tạp, không phù hợp với các dự án nhỏ.
• Cần yêu cầu nguồn nhân sự có kỹ năng tốt về quản trị rủi ro.
• Cần đưa ra được các tiêu chí kết thúc rõ ràng nếu không sẽ rơi vào tình trạng lập vô hạn.

4. Mô hình Agile phương pháp Scrum.

Mô hình này là một tập hợp các phương thức phát triển lặp và tăng dần trong đó các yêu cầu cũng như giải pháp được phát triển thông qua sự liên kết và cộng tác giữa các nhóm, giữa các chức năng. Agile chỉ là một mô hình trên lý thuyết mà để triển khai nó đến thực tế thì cần phải có phương pháp cụ thể, một trong các phương pháp được áp dụng rộng rãi là phương pháp Scrum. Theo phương pháp này dự án sẽ được chia thành từng nhóm phát triển bao gồm: Product Owner, Scrum Master và nhóm phát triển. Product Owner sẽ tạo ra một danh sách các hạng mục cần phải phát triển theo độ ưu tiên cho sản phẩm được gọi là Product Backlog. Dưa vào đó, một bản kế hoạch sẽ được lập để chia dự án thành các Sprint tương ứng là các Sprint Backlog. Mỗi Sprint được kéo dài từ 1 đến 4 tuần. Sau khi Sprint kết thúc kết quả sẽ được chuyển giao theo các hạng mục trong Sprint Backlog và phải thỏa mãn Định nghĩa hoàn thành đã được thống nhất trước đó. Cuối cùng là Sơ kết và Cải tiến Sprint sẽ được diễn ra nhằm thanh tra và thích nghi sản phẩm và quy trình làm việc, đưa ra phương pháp cải tiến để có được hiệu quả tốt hơn.

Ưu điểm:

• Là một mô hình hiện đại đang được ưa chuộng,
• Bàn giao sản phẩm một cách nhanh chóng liên tục cho khách hàng.
• Sư tương tác và yếu tố con người được nhấn mạnh.
• Đề cao tính thích nghi liên tục thay đổi và làm mới.

Nhược điểm:

• Mô hình này cần nguồn nhân lực có yếu tố chuyên mô kỹ thuật cao.
• Dự án dễ đi chệch hướng khi khách hang không đưa ra được kết quả mong muốn cuối cùng.
• Chưa có được sự tập trung cần thiết vào thiết kế và tài liệu cần thiết.

Link tham khảo: https://www.istqb.org/downloads/category/2-foundation-level-documents.html