Các mô hình phát triển phần mềm phổ biến nhất

I. Mô hình phát triển phần mềm là gì

II. Các mô hình phát triển phần mềm phổ biến

Ngoài những mô hình kiểm thử phần mềm phổ biến như mô hình thác nước, mô hình Agile, mô hình chữ V đã được đề cập ở bài viết trước ta còn có thể thấy những mô hình khác như mô hình xoắn ốc ,mô hình Scrum, mô hình tiếp cận lặp và mô hình tăng trưởng cũng rất phổ biến hiện nay.

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

Mô hình xoắn ốc (Spiral Model) là một mô hình phát triển phần mềm kết hợp giữa các yếu tố của mô hình thác nước truyền thống và các phương pháp lặp lại. Được Barry Boehm giới thiệu vào năm 1986, mô hình xoắn ốc nhấn mạnh vào việc quản lý rủi ro và phát triển dần dần thông qua các vòng xoắn liên tiếp, mỗi vòng xoắn đại diện cho một giai đoạn trong quá trình phát triển phần mềm.

Trong mô hình này, quá trình phát triển phần mềm được chia thành các chu kỳ (hoặc vòng xoắn), mỗi chu kỳ bao gồm bốn giai đoạn chính:

+) Thiết lập mục tiêu: Ở giai đoạn này, các mục tiêu, yêu cầu và hạn chế của dự án được xác định. Đây là cơ sở để định hình các hoạt động tiếp theo trong chu kỳ.

+) Đánh giá và giảm thiểu rủi ro: Giai đoạn này tập trung vào việc giảm thiểu đến tối đa các rủi ro tiềm ẩn trong dự án, từ đó đưa ra các chiến lược để giảm thiểu hoặc loại bỏ những rủi ro này.

+) Phát triển và đánh giá: Sau khi đã xác định các mục tiêu và đánh giá rủi ro, phần mềm sẽ được thiết kế, mã hóa và kiểm thử trong giai đoạn này và kết thúc mỗi chu kỳ, sản phẩm sẽ được đánh giá, rút ra các bài học kinh nghiệm mà sẽ được sử dụng cho kế hoạch chu kì tiếp theo.

+) Lập kế hoạch: Chu kỳ mới sẽ bắt đầu với việc xác định các yêu cầu mới hoặc điều chỉnh các yêu cầu hiện tại.

Mô hình xoắn ốc rất phù hợp cho các dự án phức tạp, đòi hỏi quản lý rủi ro kỹ lưỡng và cần sự linh hoạt trong việc đáp ứng các yêu cầu thay đổi. Điểm mạnh của mô hình này là khả năng phát hiện và giải quyết các rủi ro sớm trong quá trình phát triển, từ đó giảm thiểu nguy cơ thất bại của dự án. Tuy nhiên, nó cũng đòi hỏi sự quản lý chặt chẽ và có thể phức tạp khi thực hiện, đòi hỏi các nhóm phát triển phải có kinh nghiệm và khả năng đánh giá rủi ro tốt.

Mô hình này sẽ phát huy tối đa hiệu quả khi được sử dụng trong trường hợp như sau :

+) Khi dự án có quy mô lớn.

+) Khi việc đánh giá các chi phí và các rủi ro là quan trọng.

+) Bất cứ lúc nào cũng có thể có yêu cầu thay đổi từ phía khách hàng.

+) Khi dự án được yêu cầu trả về thường xuyên.

+) Khi yêu cầu không rõ ràng và phức tạp.Đối với các dự án có độ rủi ro từ trung bình đến cao.

+) Những người sử dụng không chắc chắn về các nhu cầu của họ.

+) Các yêu cầu phần mềm phức tạp và lớn.

+) Cần phát triển một dòng sản phẩm mới.

+) Khi có các thay đổi quan trọng (cần nghiên cứu và khảo sát cẩn thận)

2. Mô hình Scrum

Mô hình Scrum là một phương pháp quản lý và phát triển phần mềm thuộc khung làm việc Agile, tập trung vào việc cung cấp các phần mềm chất lượng cao thông qua các chu kỳ phát triển ngắn gọi là “Sprint”. Scrum được thiết kế để giúp các nhóm làm việc hiệu quả hơn bằng cách tập trung vào sự cộng tác, khả năng thích ứng, và phản hồi liên tục.

Scrum hoạt động trên cơ sở các nguyên tắc sau:

+) Nhóm Scrum: Trong Scrum, một nhóm tự tổ chức và đa chức năng, thường bao gồm ba vai trò chính:

• Scrum Master: Người chịu trách nhiệm đảm bảo rằng nhóm tuân thủ các nguyên tắc của Scrum, loại bỏ các trở ngại và hỗ trợ nhóm hoạt động hiệu quả.
• Product Owner: Người đại diện cho khách hàng hoặc các bên liên quan, chịu trách nhiệm quản lý và ưu tiên các yêu cầu, đảm bảo rằng nhóm đang làm việc theo đúng hướng để đạt được giá trị tối đa.
• Nhóm phát triển (Development Team): Nhóm nhỏ, tự quản lý, chịu trách nhiệm xây dựng và cung cấp sản phẩm theo yêu cầu trong mỗi Sprint.

+) Sprint: Đây là một chu kỳ phát triển ngắn, thường kéo dài từ 1 đến 4 tuần, trong đó nhóm phát triển một phần nhỏ của sản phẩm. Mỗi Sprint bắt đầu với một cuộc họp lập kế hoạch Sprint, nơi các mục tiêu và công việc sẽ được xác định. Kết thúc Sprint là một phiên đánh giá, nơi nhóm xem xét kết quả và tiến hành cải tiến quy trình cho Sprint tiếp theo.

+) Backlog sản phẩm (Product Backlog): Danh sách ưu tiên của tất cả các yêu cầu và tính năng cần được thực hiện cho sản phẩm. Product Owner chịu trách nhiệm quản lý Product Backlog, đảm bảo rằng các mục quan trọng nhất được thực hiện trước.

+) Backlog Sprint (Sprint Backlog): Danh sách các công việc được chọn từ Product Backlog sẽ được hoàn thành trong Sprint hiện tại. Sprint Backlog là cam kết của nhóm phát triển để hoàn thành các nhiệm vụ trong thời gian Sprint.

+) Daily Scrum: Một cuộc họp ngắn (thường là 15 phút) được tổ chức mỗi ngày trong Sprint, nơi các thành viên nhóm chia sẻ về tiến độ, kế hoạch và những trở ngại gặp phải.

+) Review và Retrospective: Kết thúc mỗi Sprint, nhóm tiến hành hai cuộc họp quan trọng:

• Sprint Review: Nhóm trình bày sản phẩm đã hoàn thành với các bên liên quan để nhận phản hồi và điều chỉnh Product Backlog nếu cần.
• Sprint Retrospective: Nhóm đánh giá quá trình làm việc của mình, rút ra các bài học kinh nghiệm và đề xuất cải tiến cho Sprint tiếp theo.

Scrum đặc biệt phù hợp với các dự án phức tạp, yêu cầu sự linh hoạt cao và có khả năng thay đổi nhanh chóng. Nó cho phép các nhóm phát triển tập trung vào việc cung cấp giá trị liên tục cho khách hàng, với khả năng điều chỉnh nhanh chóng khi có thay đổi về yêu cầu hoặc môi trường kinh doanh.

3. Mô hình tiếp cận lặp

Mô hình tiếp cận lặp (Iterative Model) là một phương pháp phát triển phần mềm trong đó quy trình phát triển được chia thành nhiều chu kỳ lặp lại (iteration), mỗi chu kỳ bao gồm một loạt các hoạt động như lập kế hoạch, thiết kế, mã hóa, và kiểm thử. Thay vì phát triển toàn bộ sản phẩm trong một lần duy nhất, mô hình này cho phép sản phẩm được phát triển dần dần thông qua các phiên bản nhỏ hơn, cải thiện và mở rộng trong từng lần lặp.

Ta có thể nhận biết mô hình này qua các đặc điểm sau:

+) Phát triển theo chu kỳ lặp lại: Thay vì hoàn thành toàn bộ sản phẩm trong một lần, dự án được thực hiện qua nhiều chu kỳ lặp lại. Mỗi chu kỳ sản xuất một phiên bản hoàn chỉnh nhưng chưa phải là sản phẩm cuối cùng. Phiên bản này được cải thiện qua các chu kỳ lặp tiếp theo.

+) Phản hồi sớm và liên tục: Mô hình lặp cho phép nhận phản hồi sớm từ người dùng hoặc các bên liên quan sau mỗi chu kỳ. Điều này giúp nhóm phát triển có thể điều chỉnh hướng đi của dự án, bổ sung các tính năng mới hoặc khắc phục các vấn đề sớm.

+) Giảm rủi ro: Bằng cách phát triển phần mềm từng bước nhỏ, các rủi ro được giảm thiểu vì mỗi chu kỳ lặp lại là một cơ hội để xác định và giải quyết các vấn đề trước khi chúng trở thành vấn đề lớn.

+) Tập trung vào chức năng cốt lõi trước: Trong giai đoạn đầu, mô hình lặp thường tập trung phát triển các chức năng cốt lõi của phần mềm, sau đó mở rộng dần với các tính năng phức tạp hơn trong các lần lặp tiếp theo.

+) Linh hoạt và thích ứng: Mô hình lặp cho phép thay đổi yêu cầu hoặc điều chỉnh thiết kế trong quá trình phát triển dựa trên phản hồi từ người dùng hoặc các thay đổi trong môi trường kinh doanh.

Mô hình này sẽ phù hợp với các trường hợp dự án như sau :

+) Yêu cầu chính dự án đã được xác định tuy nhiên một số chức năng hoặc yêu cầu cải tiến có thể phát triển theo thời gian.

+) Một công nghệ mới đang được sử dụng và đang được học tập bởi nhóm phát triển trong khi làm việc trong dự án.

4. Mô hình tăng trưởng

Mô hình tăng trưởng (Incremental Model) là một phương pháp phát triển phần mềm mà ở đó phần mềm được phát triển và cung cấp thông qua các bản phát hành (increments) nhỏ, mỗi bản phát hành là một phần của sản phẩm hoàn chỉnh. Thay vì phát triển toàn bộ hệ thống phần mềm một lần, mô hình này chia quá trình phát triển thành nhiều phần nhỏ hơn, cho phép nhóm phát triển xây dựng, kiểm thử và triển khai từng phần của phần mềm trong từng giai đoạn.

Mô hình này có những đặc điểm như sau:

+) Phát triển từng phần: Mô hình tăng trưởng chia dự án thành nhiều phần nhỏ, mỗi phần có thể được phát triển, kiểm thử và cung cấp độc lập. Mỗi phần này thường bao gồm một tập hợp các chức năng hoặc tính năng cụ thể của sản phẩm cuối cùng.

+) Cung cấp giá trị sớm: Bằng cách phát triển và cung cấp phần mềm qua các bản phát hành nhỏ, khách hàng hoặc người dùng có thể bắt đầu sử dụng phần mềm ngay từ các giai đoạn đầu tiên, mang lại giá trị sớm cho doanh nghiệp.

+) Phản hồi liên tục: Sau mỗi bản phát hành, nhóm phát triển có thể nhận phản hồi từ người dùng hoặc khách hàng, giúp cải tiến các phần tiếp theo của phần mềm. Điều này giúp sản phẩm cuối cùng đáp ứng tốt hơn các yêu cầu và mong đợi của người dùng.

+) Giảm thiểu rủi ro: Mô hình tăng trưởng giúp giảm thiểu rủi ro bằng cách phát triển từng phần của hệ thống. Nếu có vấn đề xảy ra, nó sẽ chỉ ảnh hưởng đến một phần nhỏ của hệ thống thay vì toàn bộ sản phẩm.

+) Dễ dàng quản lý và kiểm soát: Việc chia nhỏ dự án thành các phần nhỏ giúp việc quản lý và kiểm soát quá trình phát triển trở nên dễ dàng hơn. Các bản phát hành nhỏ cho phép nhóm phát triển tập trung vào việc hoàn thành từng phần một cách chi tiết và hiệu quả.

Chính vì vậy mô hình này sẽ được áp dụng hiệu quả vào các dự án như sau :

+) Dự án yêu cầu cung cấp nhanh chóng: Khi khách hàng hoặc thị trường yêu cầu sản phẩm hoặc tính năng phải được cung cấp nhanh chóng, mô hình tăng trưởng cho phép phát triển và triển khai các phần chức năng chính sớm hơn.

+) Dự án phức tạp với rủi ro cao: Đối với các dự án phức tạp, việc chia nhỏ hệ thống thành các phần dễ quản lý giúp giảm thiểu rủi ro và tăng khả năng kiểm soát.

+) Dự án có yêu cầu không đầy đủ hoặc chưa rõ ràng: Mô hình tăng trưởng cho phép phát triển các phần quan trọng trước, trong khi yêu cầu cho các phần sau có thể được xác định và điều chỉnh dựa trên phản hồi từ người dùng.

+) Cần phản hồi nhanh: Khi sự tương tác với khách hàng và phản hồi nhanh là quan trọng, mô hình này cho phép nhóm phát triển đáp ứng yêu cầu của khách hàng trong quá trình phát triển mà không cần chờ đợi toàn bộ sản phẩm hoàn thành.

Mô hình tăng trưởng là một phương pháp hiệu quả để phát triển phần mềm theo cách tiếp cận từng bước, giúp cung cấp sản phẩm sớm, giảm thiểu rủi ro và đáp ứng tốt hơn nhu cầu của khách hàng và người dùng.

III. Kết luận

Các mô hình kiểm thử phần mềm thực sự hữu ích với các tester vì nó giúp tiết kiệm thời gian, công sức, nâng cao hiệu suất công việc. Tùy vào dự án cụ thể, tester có thể tham khảo những mô hình kiểm thử phần mềm mà chúng tôi chia sẻ trên đây và lựa chọn mô hình phù hợp nhất.

Tham khảo thêm : https://viblo.asia/p/mot-so-mo-hinh-phat-trien-phan-mem-pho-bien-gwd43Mg3LX9