SDLC là gì? Các mô hình Software Development Life Cycle phổ biến

Viết bởi Huong Le
Jul 13, 2024

Vòng đời phát triển phần mềm (Software Development Life Cycle - SDLC) là một quy trình có cấu trúc và định hướng để phát triển phần mềm. SDLC cung cấp một quy trình chặt chẽ và có hệ thống để xây dựng phần mềm, giúp đảm bảo chất lượng, giảm rủi ro và tối ưu hóa tài nguyên.

27 min reads

SDLC là gì? Các mô hình Software Development Life Cycle phổ biến

1. SDLC là gì?

Vòng đời phát triển phần mềm (Software Development Life Cycle - SDLC) là quá trình toàn diện từ khi bắt đầu xây dựng một phần mềm cho đến khi nó được triển khai và duy trì. SDLC bao gồm các giai đoạn và hoạt động để đảm bảo rằng sản phẩm được phát triển một cách hiệu quả và chất lượng.

2. Các giai đoạn hoạt động của SDLC

Quy trình phát triển để tạo ra một phần mềm có thể được điều chỉnh theo quy mô, hình thức hoạt động và nhu cầu của từng công ty nhưng về cơ bản sẽ bao gồm các giai đoạn sau:

2.1 Lập kế hoạch và phân tích

Giai đoạn này tập trung vào việc xác định yêu cầu, mục tiêu cụ thể, lập lịch và ngân sách cho dự án.

Các thông tin từ khách hàng, bộ phận bán hàng, khảo sát thị trường và các chuyên gia lĩnh vực trong ngành sau khi được thu thập sẽ dùng để lập kế hoạch cơ bản cho dự án và tiến hành nghiên cứu tính khả thi của sản phẩm. Bên cạnh đó, việc xác định các nguồn lực để đáp ứng yêu cầu của dự án và tính toán các chi phí liên quan cũng là điều cần thiết trong giai đoạn này.

2.2 Xác định yêu cầu

Đây là một giai đoạn quan trọng để hiểu rõ mong muốn và nhu cầu của khách hàng, từ đó xây dựng các yêu cầu nghiệp vụ và kỹ thuật cho sản phẩm. Thông qua việc thảo luận với khách hàng có thể xác định, hoàn thiện các yêu cầu và chúng sẽ được ghi lại dưới dạng tài liệu SRS (đặc tả yêu cầu phần mềm). Tài liệu này được sử dụng trong suốt vòng đời.

2.3 Thiết kế

Giai đoạn này là quá trình thiết kế kiến trúc tổng thể của phần mềm dựa trên yêu cầu và thông tin được thu thập ở bước phân tích. Thiết kế cũng bao gồm việc lập trình cụ thể, định dạng dữ liệu, giao diện người dùng, và các tính năng khác của hệ thống.

2.4 Xây dựng hoặc phát triển sản phẩm

Bước này là giai đoạn thực hiện mã hóa và xây dựng các thành phần phần mềm dựa trên các thiết kế đã được xác định trước đó. Nhóm sẽ tập trung vào việc viết mã, tích hợp các thành phần, và xây dựng hệ thống dựa trên các hướng dẫn từ bước thiết kế.

2.5 Kiểm thử và tích hợp

Trong giai đoạn này, nhà phát triển sẽ kiểm tra các thành phần của phần mềm để đảm bảo rằng chúng hoạt động đúng và tương thích với nhau. Nếu có lỗi nào phát hiện sẽ được báo cáo, theo dõi và sửa chữa. Sau khi các lỗi đã khắc phục, các thử nghiệm sẽ được thực hiện lại để đảm bảo phần mềm hoạt động đúng như mong đợi.

2.6 Triển khai và bảo trì

Sau khi quá trình kiểm thử và tích hợp hoàn tất với kết quả đảm bảo chất lượng, phần mềm sẽ được chính thức phát hành ra thị trường. Tùy theo chiến lược kinh doanh của tổ chức, phần mềm có thể được triển khai ở một phân khúc thị trường giới hạn để tiến hành thử nghiệm người dùng (UAT).

Dựa trên phản hồi từ người dùng, phần mềm có thể được phát hành như dự kiến hoặc có thể cần chỉnh sửa và cải tiến để phù hợp hơn với thị trường mục tiêu.

Sau khi triển khai, nhà phát triển sẽ tiến hành duy trì và nâng cấp sản phẩm. Công việc bảo trì bao gồm sửa lỗi, cập nhật và bổ sung tính năng mới để đáp ứng nhu cầu của người dùng và thay đổi của môi trường hoạt động.

3. Các mô hình SDLC phổ biến

3.1 Mô hình thác nước (Waterfall model)

Mô hình thác nước (Waterfall model) là một phương pháp phát triển phần mềm theo tuyến tính, chia dự án thành các giai đoạn riêng biệt, tuần tự, giống như dòng nước chảy từ trên xuống dưới. Mỗi giai đoạn phải được hoàn thành hoàn toàn trước khi chuyển sang giai đoạn tiếp theo.

Các giai đoạn của mô hình thác nước gồm:

Phân tích yêu cầu (Requirement): Xác định rõ ràng mục tiêu, chức năng và yêu cầu của dự án.
Thiết kế (Design): Lập kế hoạch chi tiết về kiến trúc, giao diện và logic của phần mềm.
Phát triển (Implementation): Viết code và xây dựng phần mềm theo thiết kế.
Kiểm thử (Testing): Kiểm tra phần mềm để đảm bảo nó hoạt động theo yêu cầu.
Triển khai (Deployment): Cài đặt và đưa phần mềm vào sử dụng.
Bảo trì (Maintenance): Sửa lỗi, cập nhật và nâng cấp phần mềm sau khi triển khai.

💡

VÍ DỤ: Dự án xây dựng ứng dụng học tiếng Anh

Giai đoạn: Yêu cầu và phân tích

Tiến hành tìm hiểu, nghiên cứu để hiểu đầy đủ, chính xác, nhất quán và rõ ràng nhất những yêu cầu của khách hàng.
Xác định các tính năng và chức năng của ứng dụng:

- Các tính năng cơ bản (đăng kí/ đăng nhập tài khoản, tìm kiếm, giỏ hàng, khóa học, kiểm tra đánh giá trình độ, theo dõi tiến độ học tập….

- Các tính năng nâng cao (tùy chỉnh lộ trình học tập dựa trên trình độ và mục tiêu của người dùng; tích hợp trò chuyện video với giáo viên …)

Phát triển tài liệu yêu cầu chi tiết phác thảo phạm vi, chức năng và thông số kỹ thuật.

Giai đoạn: Thiết kế

Tạo wireframe và mô hình mô phỏng để trực quan hóa bố cục ứng dụng.
Thiết kế các thành phần giao diện người dùng (UI), đảm bảo tính nhất quán và thân thiện với người dùng.
Phát triển luồng trải nghiệm người dùng (UX) để tương tác mượt mà.
Xác định kiến trúc kỹ thuật và thiết kế hệ thống để tích hợp back-end.

Giai đoạn: Thực hiện

Lựa chọn ngôn ngữ lập trình, framework
Tích hợp front-end (giao diện người dùng) với back-end (cơ sở dữ liệu, máy chủ).
Phát triển API
Thực hiện các biện pháp bảo mật để bảo vệ dữ liệu người dùng.

Giai đoạn: Kiểm thử

Tiến hành kiểm tra đơn vị (Unit testing).
Thực hiện kiểm tra tích hợp (Integration testing).
Tiến hành kiểm tra hệ thống (System testing).
Tiến hành kiểm tra sự chấp nhận của người dùng (UAT) với người dùng thực để thu thập phản hồi và xác định vấn đề.
Sửa bất kỳ lỗi hoặc khiếm khuyết nào được tìm thấy trong quá trình thử nghiệm.

Giai đoạn: Triển khai

Triển khai ứng dụng lên App Store/Google Play.
Thiết lập quy trình giám sát và bảo trì.

Giai đoạn: Bảo trì

Giải quyết các lỗi hoặc sự cố do người dùng báo cáo.

Chú ý: Tài liệu ở các giai đoạn trước phải chi tiết và đầy đủ cho giai đoạn tiếp theo.

3.1.1 Ưu điểm

Quản lý đơn giản: mỗi giai đoạn đều có quy trình xác định, tài liệu đầy đủ, các tiêu chí đầu vào và đầu ra rõ ràng nên thuận lợi cho việc kiểm tra chất lượng.
Tài liệu ở các giai đoạn đều rõ ràng.
Phù hợp với dự án vừa và nhỏ, yêu cầu rõ ràng, ít thay đổi.

3.1.2 Nhược điểm

Cứng nhắc, không dễ dàng thay đổi, nếu cần chỉnh sửa thì phải quay lại giai đoạn đầu tiên.
Rủi ro cao: Người dùng chỉ được tiếp cận và sử dụng sản phẩm sau khi hoàn thành toàn bộ chu trình phát triển nên.
Không thích hợp với các dự án lớn và dài ngày.

3.1.3 Khi nào sử dụng mô hình thác nước (waterfall)?

Phù hợp với các dự án quy mô vừa và nhỏ với yêu cầu rõ ràng và ít thay đổi (ví dụ: dự án phát triển website công ty nhỏ…).
Các dự án có ngân sách và tiến độ cố định (ví dụ: dự án chính phủ…).
Dự án tuân thủ nhiều quy định (ví dụ: dự án y tế, chăm sóc sức khỏe…).
Sử dụng công nghệ ổn định.

3.2 Mô hình chữ V (V-shaped model)

Ở mô hình thác nước (Waterfall) việc kiểm thử chỉ bắt đầu sau khi mã nguồn được triển khai xong. Điều này có thể dẫn đến những rủi ro lớn, đặc biệt là trong các dự án lớn và phức tạp.

💡

Ví dụ: Bạn đang phát triển một hệ thống quản lý kho hàng. Trong giai đoạn phân tích yêu cầu, bạn xác định rằng hệ thống cần có chức năng theo dõi số lượng hàng tồn kho theo thời gian thực. Tuy nhiên, sau khi mã nguồn được triển khai, bạn phát hiện ra rằng chức năng này không hoạt động chính xác. Trong những trường hợp như vậy, bạn có thể phải bắt đầu lại dự án hoặc sẽ phải thiết kế lại toàn bộ phần mềm để sửa lỗi. Điều đó làm tốn kém nhiều thời gian và công sức.

Mô hình chữ V được tạo ra để giải quyết vấn đề của mô hình thác nước. Thay vì chỉ kiểm thử khi quá trình phát triển mã nguồn kết thúc, mô hình chữ V cung cấp một quá trình kiểm thử song song cho mỗi bước trong quá trình phát triển.

💡

Trong ví dụ về hệ thống quản lý kho hàng, nếu bạn sử dụng mô hình chữ V, bạn có thể kiểm thử chức năng theo dõi số lượng hàng tồn kho theo thời gian thực trước khi bắt đầu viết mã. Điều này sẽ giúp bạn phát hiện lỗi sớm hơn và sửa lỗi trước khi mã nguồn được triển khai.

Mô hình chữ V là một mô hình phát triển phần mềm tập trung vào việc đảm bảo chất lượng sản phẩm thông qua việc xác minh và xác nhận (Verification and Validation) ở mỗi giai đoạn của vòng đời phát triển phần mềm (SDLC).

Câu hỏi then chốt: "Sản phẩm có được xây dựng đúng theo thông số kỹ thuật và tiêu chuẩn?"

Xác minh (Verification) là quá trình đánh giá một sản phẩm hoặc hệ thống để xác định xem nó có đáp ứng các yêu cầu phát triển đã đặt ra hay không.

Câu hỏi then chốt: "Sản phẩm có giải quyết được vấn đề của người dùng và đáp ứng kỳ vọng của họ?"

Xác nhận (Validation) là quá trình đánh giá một sản phẩm hoặc hệ thống để xác định xem nó có đáp ứng các nhu cầu của người dùng hay không.

💡

Hãy tưởng tượng xác minh (verification) như việc kiểm tra xem một chiếc bánh có được làm theo công thức hay không, trong khi, xác nhận (validation) là kiểm tra xem việc bánh ngon và đáp ứng được nhu cầu của khách hàng.

Giai đoạn xác minh (Verification Phase) trong mô hình chữ V gồm:

Phân tích yêu cầu kinh doanh (Business Requirement Analysis):

Giai đoạn này bao gồm việc trao đổi chi tiết với khách hàng để hiểu kỳ vọng và yêu cầu chính xác của họ. Đây là một hoạt động rất quan trọng và cần được quản lý tốt, vì hầu hết khách hàng không chắc chắn về những gì họ thực sự cần. Việc lập kế hoạch thiết kế thử nghiệm chấp nhận được thực hiện ở giai đoạn này vì các yêu cầu kinh doanh có thể được sử dụng làm đầu vào cho thử nghiệm chấp nhận.

Thiết kế hệ thống (System Design):

Dựa trên phân tích yêu cầu, kiến trúc tổng thể và các thành phần của hệ thống được thiết kế. Giai đoạn này xác định phần cứng, phần mềm, giao diện và luồng dữ liệu của hệ thống. Kế hoạch kiểm tra hệ thống được phát triển để đảm bảo hệ thống đáp ứng các yêu cầu thiết kế.

Thiết kế kiến trúc (Architectural Design)

Giai đoạn này tập trung vào việc thiết kế chi tiết kiến trúc hệ thống, bao gồm các thành phần phần cứng và phần mềm, giao thức truyền thông và các biện pháp bảo mật. Sự tương tác và giao tiếp giữa các mô-đun cũng được xác định rõ ràng. Kế hoạch kiểm tra tích hợp được phát triển để đảm bảo các mô-đun hoạt động cùng nhau một cách hiệu quả.

Thiết kế mo-đun (Module Design)

Giai đoạn này tập trung vào việc thiết kế chi tiết từng mô-đun hoặc thành phần của hệ thống. Cấu trúc nội bộ, thuật toán và cấu trúc dữ liệu cho mỗi mô-đun được xác định. Kế hoạch kiểm tra đơn vị được phát triển để đảm bảo mỗi mô-đun hoạt động chính xác theo thiết kế.

Mã hóa (Coding)

Giai đoạn này tập trung vào việc chuyển đổi các thông số kỹ thuật thiết kế thành mã thực tế. Mã được phát triển, đánh giá và kiểm tra đơn vị để đảm bảo chất lượng và hiệu suất.

Giai đoạn xác nhận (Validation Phase) trong mô hình chữ V gồm:

Kiểm thử đơn vị (Unit Testing)

Các bài kiểm tra đơn vị được thiết kế trong giai đoạn thiết kế mô-đun được thực hiện trên mã trong giai đoạn xác thực này. Kiểm tra đơn vị là kiểm tra ở cấp độ mã và giúp loại bỏ lỗi ở giai đoạn đầu, mặc dù không thể phát hiện ra tất cả các lỗi bằng kiểm tra đơn vị.

Kiểm thử tích hợp (Integration Testing)

Kiểm thử tích hợp liên quan đến giai đoạn thiết kế kiến trúc. Kiểm thử tích hợp được thực hiện để kiểm tra sự đồng tồn tại và giao tiếp của các mô-đun nội bộ trong hệ thống.

Kiểm thử hệ thống (System Testing)

Kiểm thử hệ thống có liên quan trực tiếp đến giai đoạn thiết kế hệ thống. Kiểm thử hệ thống kiểm tra toàn bộ chức năng của hệ thống và giao tiếp của hệ thống đang phát triển với các hệ thống bên ngoài

Kiểm thử chấp nhận (Acceptance Testing)

Kiểm thử chấp nhận liên quan đến giai đoạn phân tích yêu cầu kinh doanh và bao gồm việc kiểm thử sản phẩm trong môi trường người dùng. Kiểm thử chấp nhận phát hiện ra các vấn đề về khả năng tương thích với các hệ thống khác có sẵn trong môi trường người dùng.

3.2.1 Ưu điểm

Phát hiện nhanh sai sót và tìm ra nguyên nhân sớm
Chữa lỗi hiệu quả do kiểm thử chặt chẽ
Dễ quản lý, thích hợp cho các dự án nhỏ, khi các yêu cầu được hiểu rất rõ

3.2.2 Nhược điểm

Tốn nhiều thời gian và chi phí
Khó thích ứng với những thay đổi về yêu cầu hoặc công nghệ.

3.2.3 Khi nào sử dụng mô hình chữ v (v-shaped model)?

Dự án có yêu cầu rõ ràng và ít thay đổi.
Dự án công nghệ ổn định, không yêu cầu nhiều cải tiến.
Dự án quy mô nhỏ, thời gian thực hiện ngắn.
Dự án đòi hỏi chất lượng cao, kiểm thử nghiêm ngặt, không chấp nhận sai sót (ví dụ: quản lý bệnh viện, hàng không, giao dịch…)

3.3 Mô hình lặp (Iterative model)

Mô hình lặp (Iterative model) là một phương pháp phát triển phần mềm chia dự án thành các chu kỳ nhỏ, lặp đi lặp lại. Mỗi chu kì lặp lại tạo ra một phiên bản hoàn chỉnh của sản phẩm. Sau mỗi chu kỳ, chúng được đánh giá và phản hồi để điều chỉnh, cải thiện cho chu kỳ tiếp theo.

Mỗi chu kỳ bao gồm các giai đoạn tương tự như mô hình thác nước

💡

Ví dụ: Dự án xây dựng ứng dụng học tiếng Anh

Lần lặp 1 (Iteration 1):

Sau khi nhận được yêu cầu của khách hàng (có thể chưa đầy đủ), nhóm tiến hành xây dựng các tính năng chính, cơ bản nhất của ứng dụng (như Đăng ký/đăng nhập tài khoản, giỏ hàng, khóa học, kiểm tra đánh giá trình độ…)

Lần lặp đầu tiên này cũng sẽ trải qua các giai đoạn tương tự như mô hình thác nước (Waterfall) bao gồm: yêu cầu, phân tích, thiết kế, phát triển, kiểm thử. Tuy nhiên, thay vì triển khai ra thị trường, nhóm sẽ nhận phản hồi về sản phẩm để cải thiện chúng.

Lần lặp 2 (Iteration 2):

Dựa vào những phản hồi, đánh giá của khách hàng, nhóm phát triển sẽ bổ sung những tính năng cần thiết trong phiên bản mới và loại bỏ những thứ khách hàng không mong muốn.

Quá trình này sẽ lặp lại cho đến khi sản phẩm được hoàn thiện hoàn toàn và sẵn sàng để phát hành ra thị trường.

3.3.1 Ưu điểm

Tạo ra giá trị kinh doanh sớm trong vòng đời phát triển.
Dễ dàng thích ứng với những thay đổi về yêu cầu, kế hoạch và phạm vi dự án
Sản phẩm đáp ứng đúng nhu cầu của khách hàng và tăng khả năng thành công của dự án.
Cải thiện chất lượng sản phẩm nhờ có phản hồi liên tục từ khách hàng

3.3.2 Nhược điểm

Yêu cầu quản lý dự án phức tạp hơn
Các vấn đề về thiết kế hoặc kiến trúc hệ thống có thể phát sinh bất cứ lúc nào
Cần có sự phản hồi thường xuyên và chi tiết của khách hàng
Có thể khó ước tính chi phí và thời gian

3.3.3 Khi nào sử dụng mô hình lặp (iterative model) ?

Yêu cầu chính phải được xác định rõ ràng, nhưng một số chức năng hoặc yêu cầu cải tiến có thể được xác định và thêm vào trong quá trình phát triển.
Phù hợp cho các dự án lớn

3.4 Mô hình xoắn ốc (Spiral model)

Spiral model (Mô hình xoắn ốc) là quy trình phát triển định hướng rủi ro cho các dự án phần mềm. Mô hình chú trọng vào phân tích rủi ro dự án, bắt đầu với yêu cầu và kết thúc với việc khách hàng kiểm tra tiến độ của từng giai đoạn

Mỗi vòng xoắn ốc bao gồm các bước sau:

	Hoạt động chính	Kết quả
Lập kế hoạch (Planning phase)	Tìm hiểu, nghiên cứu khách hàng và các bên liên quan để thu thập yêu cầu. Phân tích yêu cầu để xác định phạm vi dự án, chức năng của hệ thống và các ràng buộc. Ước lượng chi phí và lập lịch trình thực hiện dự án dựa trên phạm vi và yêu cầu. Xác định số lượng nhân lực cần thiết cho từng vai trò trong dự án. Xác định môi trường làm việc cần thiết, bao gồm phần cứng, phần mềm và các công cụ phát triển. Tạo tài liệu đặc tả yêu cầu kinh doanh (BRS) và tài liệu đặc tả yêu cầu hệ thống (SRS) để phục vụ cho việc trao đổi giữa khách hàng và phân tích hệ thống.	Tài liệu BRS và SRS. Kế hoạch dự án bao gồm ước lượng chi phí, lịch trình và yêu cầu về nhân lực. Môi trường làm việc được thiết lập.
Phân tích rủi ro (Risk analysis phase)	Sử dụng các kỹ thuật phân tích rủi ro để xác định các rủi ro tiềm ẩn. Đánh giá mức độ nghiêm trọng và khả năng xảy ra của mỗi rủi ro. Lập kế hoạch giảm thiểu rủi ro, bao gồm các biện pháp phòng ngừa và các phương án dự phòng. Tạo mẫu (prototype) để kiểm tra tính khả thi của các giải pháp thay thế.	Danh sách các rủi ro tiềm ẩn. Kế hoạch giảm thiểu rủi ro. Prototype
Thực thi kỹ thuật (Engineering phase)	Phát triển mã nguồn theo thiết kế hệ thống. Kiểm thử hệ thống để phát hiện lỗi và đảm bảo chất lượng. Triển khai hệ thống trên môi trường sản xuất. Cung cấp tài liệu hướng dẫn sử dụng cho khách hàng.	Hệ thống phần mềm hoàn chỉnh. Tài liệu hướng dẫn sử dụng.
Đánh giá (Evaluation phase)	Thực hiện đánh giá hệ thống để xác định xem nó có đáp ứng các yêu cầu của khách hàng hay không. Thu thập phản hồi từ khách hàng về hệ thống. Thực hiện các thay đổi cần thiết dựa trên phản hồi của khách hàng. Cung cấp hỗ trợ kỹ thuật cho khách hàng. Đây là giai đoạn quan trọng vì cần có sự phản hồi của khách hàng về sản phẩm trước khi sản phẩm được phát hành ra thị trường.	Hệ thống phần mềm đáp ứng các yêu cầu của khách hàng.

💡

VÍ DỤ: Dự án xây dựng ứng dụng học tiếng Anh kết hợp trí tuệ nhân tạo

	Vòng lặp 1	Vòng lặp 2
Lập kế hoạch (Planning phase)	Xác định các *chức năng cốt lõi* của ứng dụng (như tạo tài khoản, lựa chọn lộ trình, cung cấp các bài học, theo dõi tiến độ học tập) Ước tính chi phí và thời gian phát triển Xác định các nguồn lực và thành viên nhóm cần thiết.	Thiết kế và *phát triển các tính năng* hỗ trợ bởi AI cho việc học được cá nhân hóa, chẳng hạn như: + Điều chỉnh độ khó thích ứng dựa trên hiệu suất của người dùng. + Lộ trình học được cá nhân hóa dựa trên mục tiêu và sở thích của người dùng. + Phản hồi theo thời gian thực về phát âm, ngữ pháp và vốn từ vựng. + Tạo nội dung hấp dẫn bằng AI.
Phân tích rủi ro (Risk analysis phase)	Xác định các rủi ro tiềm ẩn liên quan đến phát triển (như thách thức kỹ thuật, việc áp dụng của người dùng và cạnh tranh.) Phát triển các chiến lược giảm thiểu rủi ro đã xác định. Tạo một mẫu (prototype) để kiểm tra tính khả thi của các tính năng và chức năng chính.	Đánh giá các rủi ro liên quan đến việc triển khai AI (như quyền riêng tư dữ liệu và độ chính xác…) Phát triển các chiến lược để giảm thiểu những rủi ro này
Thực thi kỹ thuật (Engineering phase)	Tiến hành phát triển các chức năng cốt lõi của ứng dụng	Tích hợp các mô hình AI vào ứng dụng để cung cấp năng lượng cho các tính năng học được cá nhân hóa. Triển khai các biện pháp bảo mật và quyền riêng tư dữ liệu để bảo vệ dữ liệu người dùng. Thực hiện kiểm tra nghiêm ngặt để đảm bảo độ chính xác và hiệu quả của các mô hình AI.
Đánh giá (Evaluation phase)	Thực hiện kiểm tra người dùng để đánh giá khả năng sử dụng và hiệu quả của ứng dụng. Thu thập phản hồi từ người dùng và xác định các vấn đề cần cải thiện. Tinh chỉnh ứng dụng dựa trên đánh giá của người dùng và phân tích dữ liệu.	Đánh giá hiệu quả của các tính năng hỗ trợ bởi AI trong việc cải thiện mức độ tương tác của người dùng và kết quả học tập. Thu thập phản hồi của người dùng về trải nghiệm học được cá nhân hóa. Tinh chỉnh các mô hình AI và thuật toán cá nhân hóa dựa trên dữ liệu và phản hồi.

Lưu ý:

Mỗi vòng lặp có thể được điều chỉnh và mở rộng dựa trên nhu cầu cụ thể của dự án.
Quá trình này sẽ được lặp đi lặp lại cho đến khi ứng dụng đạt được chất lượng và đáp ứng đầy đủ các yêu cầu của khách hàng, sau đó, ứng dụng sẽ được triển khai ra thị trường

3.4.1 Ưu điểm

Tạo bản mẫu sớm
Cho phép người dùng tham gia vào các giai đoạn
Ưu tiên thực hiện trước những chức năng quan trọng
Quản lý rủi ro hiệu quả
Kiểm soát tài liệu chặt chẽ
Phần mềm sẽ được sản xuất sớm và có thể bổ sung hoặc thay đổi chức năng vào giai đoạn sau

3.4.2 Nhược điểm

Đòi hỏi chuyên gia có chuyên môn cao để thực hiện phân tích
Thời gian và chi phí cho dự án có thể vô hạn
Rủi ro có thể không đáp ứng được tiến độ dự án

3.4.3 Khi nào sử dụng mô hình xoắn ốc (spiral model)?

Dự án có quy mô lớn
Dự án có độ rủi ro từ trung bình đến cao
Yêu cầu phức tạp (ví dụ: dự án phát triển một hệ điều hành mới…)
Khi cần phát triển một dòng sản phẩm mới

3.5 Mô hình linh hoạt (Agile model)

Mô hình Agile là một cách tiếp cận linh hoạt và lặp đi lặp lại, nhấn mạnh việc liên tục thích ứng với các yêu cầu thay đổi để mang lại giá trị cho khách hàng.

Mô hình Agile tập trung vào việc phát triển phần mềm theo các chu kỳ ngắn gọi là “sprint”, thường kéo dài từ 2 đến 4 tuần. Mỗi sprint kết thúc với một phần mềm có thể sử dụng được, và phạm vi cùng hướng đi của dự án có thể thay đổi dựa trên phản hồi từ khách hàng.

Bằng cách sử dụng quản lý dự án Agile, nhóm sẽ chia dự án thành các nhiệm vụ nhỏ hơn, dễ quản lý hơn hoặc “user story” có thể hoàn thành trong vòng hai tuần (two-week sprint)

Sprint 1: Xây dựng “user story”+ phát triển + thử nghiệm + phát hành
Sprint 2: Xem lại sprint 1 + xây dựng “user story” (chức năng mới) + phát triển + thử nghiệm + phát hành
Sprint 3: Xem lại sprint 2 + xây dựng “user story” (chức năng mới) + phát triển + thử nghiệm + phát hành
Sprint n ...

Trong cuộc họp lập kế hoạch, nhóm sẽ ưu tiên các “user story” dựa trên nhu cầu của khách hàng và ước tính để hoàn thành từng nhiệm vụ.

Sau đó, nhóm sẽ làm việc cùng nhau trong suốt sprint và tổ chức các cuộc họp độc lập hàng ngày để thảo luận về tiến độ, thách thức và bất kỳ điều chỉnh nào cần thiết đối với kế hoạch.

Khi kết thúc sprint, nhóm sẽ trình bày các “user story” đã hoàn thành cho khách hàng để xem xét và phản hồi. Sau đó, khách hàng sẽ cung cấp phản hồi và nhóm sẽ sử dụng phản hồi đó để điều chỉnh kế hoạch cho sprint tiếp theo.

Quá trình lặp lại này tiếp tục cho đến khi dự án hoàn thành, nhóm liên tục thích ứng với các yêu cầu thay đổi và mang lại giá trị cho khách hàng ở mỗi bước.

3.5.1 Ưu điểm

Tinh thần làm việc nhóm được nâng cao và hiệu quả được cải thiện.
Sản phẩm được đưa ra thị trường nhanh chóng
Có tính linh hoạt, đáp ứng nhanh các thay đổi
Cho phép phản hồi nhanh chóng từ khách hàng
Giảm thiểu rủi ro bằng cách phát triển sản phẩm theo từng chu kỳ nhỏ.

3.5.2 Nhược điểm

Đòi hỏi kỹ năng cao của nhóm phát triển.
Có thể khó khăn trong việc quản lý dự án.
Có thể dẫn đến thiết kế không nhất quán.

3.5.3 Khi nào sử dụng mô hình linh hoạt (agile model) ?

Nhu cầu của khách hàng thường thay đổi
Các dự án chú trọng vào phản hồi của người dùng
Khi khách hàng yêu cầu sản phẩm trong khoảng thời gian ngắn

Mô hình	Thác nước (Waterfall)	Chữ V (V-shaped)	Lặp (Iterative)	Xoắn ốc (Spiral)	Linh hoạt (Agile)
Độ linh hoạt	Cố định		Linh hoạt
Các giai đoạn	1 lần		Lặp lại cho đến khi đạt yêu cầu
Bàn giao sản phẩm	Giao 1 lần		Giao 1 lần		Giao nhiều lần các phần sản phẩm
Mục đích	Đảm bảo ổn định chi phí	Đảm bảo chất lượng sản phẩm bằng cách phát hiện và sửa lỗi sớm	Đảm bảo độ chính xác của giải pháp	Quản lý rủi ro	Đảm bảo giá trị đem đến cho khách hàng thông qua giao hàng và phản hồi thường xuyên

4. Xu hướng trong tương lai của các mô hình SDLC

Tăng cường tự động hóa: Các công cụ tự động hóa như kiểm thử tự động, CI/CD, tạo mã và phân tích/tối ưu hóa bởi AI sẽ giúp tăng tốc và hiệu quả các quy trình trong SDLC.
Ứng dụng AI và Machine Learning: Các công nghệ này sẽ định hình lại các giai đoạn của SDLC, từ thu thập yêu cầu đến mã hóa, kiểm thử và triển khai, thông qua tự động hóa các tác vụ lặp đi lặp lại và phân tích dữ liệu để cải thiện quy trình.
Chuyển sang DevOps và DevSecOps: Việc tích hợp phát triển, vận hành và bảo mật (DevOps và DevSecOps) sẽ tiếp tục đóng vai trò quan trọng trong SDLC. Thực tiễn DevOps thúc đẩy sự cộng tác, giao tiếp và tự động hóa giữa các nhóm phát triển và vận hành, dẫn đến chu kỳ phân phối nhanh hơn và chất lượng phần mềm được cải thiện.
Ứng dụng Low-code và No-code: Các nền tảng này cho phép những người không có chuyên môn về lập trình tham gia vào quá trình xây dựng ứng dụng. Điều này mở rộng tập người tham gia phát triển phần mềm, không chỉ dành riêng cho các lập trình viên chuyên nghiệp.
Chuyển sang phát triển Cloud-Native: Các phương pháp phát triển dựa trên đám mây, tận dụng tài nguyên điện toán đám mây và kiến trúc microservices, đang ngày càng trở nên phổ biến. SDLC có thể phát triển để hỗ trợ các yêu cầu riêng của các ứng dụng gốc đám mây, chẳng hạn như khả năng mở rộng, khả năng phục hồi và triển khai phân tán.

5. Kết luận

Mô hình SDLC được xem là công cụ không thể thiếu với những nhà phát triển. Các mô hình Vòng đời Phát triển Phần mềm khác nhau có các ưu và nhược điểm riêng, vì vậy để lựa chọn mô hình tốt nhất cho dự án cần xác định được các yếu tố của dự án như yêu cầu (rõ ràng hay không rõ ràng), độ phức tạp của hệ thống, quy mô, chi phí, giới hạn kỹ năng,… Ngoài ra, các mô hình SDLC trong tương lai sẽ ngày càng linh hoạt, tự động hóa và tích hợp sâu rộng các công nghệ mới để đáp ứng tốt hơn nhu cầu phát triển phần mềm ngày càng phức tạp.

Các bài viết liên quan: