5 Mô Hình Phát Triển Phần Mềm Bạn Cần Biết

Các mô hình phát triển phần mềm (SDLC) là công cụ quan trọng để kỹ sư, lập trình viên có thể quản lý dự án của mình thật hiệu quả. Yêu cầu kỹ thuật, thời gian, kinh phí và kỳ vọng của nhà đầu tư là những yếu tố góp phần quyết định đâu là mô hình SDLC phù hợp nhất. 

Hiện nay có hơn 50 mô hình phát triển phần mềm đang được sử dụng. Không có lựa chọn nào là giải pháp hiệu quả 100%, mỗi loại đều có ưu/nhược điểm riêng cho từng phần mềm, đội ngũ lập trình khác nhau. Bài viết đã chọn ra 8 mô hình đặc thù để so sánh các đặc điểm cốt lõi, cần được cân nhắc khi lựa chọn một mô hình SDLC cho những dự án.

Không có lựa chọn nào là giải pháp hiệu quả 100%, mỗi loại đều có ưu/nhược điểm riêng cho từng phần mềm, đội ngũ lập trình khác nhau.

1. Tổng quan về những mô hình phát triển phần mềm phổ biến

Các mô hình này có thể được xếp vào một số nhóm dựa trên phương thức làm việc được đề ra, ví dụ như tuyến tính hoặc phi tuyến tính, hay yêu cầu giao tiếp giữa đội ngũ phát triển và khách hàng của họ. Trong muôn vàn các loại SDLC, chúng ta cần biết dự án cho phép bao nhiêu sự linh hoạt hay yêu cầu theo sát quy trình chuẩn chỉ. Cũng như khách hàng yêu cầu được đóng góp ý kiến vào bao nhiêu giai đoạn phát triển phần mềm. Nhờ vậy mới có thể đưa ra lựa chọn mô hình phát triển phù hợp nhất. 

2. Các mô hình phát triển phần mềm và loại dự án phù hợp tương đương

2.1. Waterfall

Waterfall, hay “thác nước”, như cái tên gợi ra ám chỉ đến phương thức chú trọng vào sự theo sát các quy trình: phân tích, thiết kế, lập trình, thử nghiệm và triển khai. Mỗi bước sẽ được làm và ghi chép cẩn thận, một khi đã chuyển giai đoạn thì không thể quay lại. Sản phẩm cũng chỉ có thể được thử nghiệm trong các giai đoạn sau cùng của dự án, từ đó có thể dẫn đến nhiều rủi ro và sự khó đoán về chất lượng phần mềm. Công đoạn sửa lỗi cũng vì vậy mà tốn nhiều chi phí hơn. 

Khi nào bạn nên dùng Waterfall

• Các dự án nhỏ, hoặc trung bình với thông số và công năng đề ra rõ ràng (những doanh nghiệp nhỏ)
• Các dự án có ngân sách và thời gian cố định (dự án cho chính phủ)
• Các dự án cần tuân theo nhiều quy định nghiêm ngặt (dự án y tế)
• Dự án sử dụng những công nghệ lập trình phổ biến, dễ nắm bắt 

2.2. Mô Hình Phát Triển Phần Mềm V-model (Validation & Verification)

Đây là một mô hình tuyến tính với mỗi giai đoạn dự án đều có một bước kiểm tra sản phẩm. Chất lượng phần mềm rất được chú trọng, tuy nhiên V-model cũng là một trong những phương thức tốn kém và đòi hỏi thời gian nhất. Dù việc phát hiện lỗi có thể thực hiện dễ dàng, đưa thêm những bản sửa xen kẽ trong quá trình đó vẫn là một việc khó khăn. Và giống như Waterfall, các thông số cần thiết cho dự án sẽ được thu thập ở thời gian đầu và không thể thay đổi. 

Khi nào bạn nên dùng V-model 

Những dự án có yêu cầu nghiêm ngặt về yếu tố thời gian và chất lượng, độ chính xác (phần mềm y tế, hệ thống quản lý hàng không).

2.3. Incremental & Iterative 

Mô Hình Phát Triển Phần Mềm Incremental & Iterative sử dụng những “cấu kiện”, hay module phần mềm thêm vào nhau qua mỗi giai đoạn phát triển.Trình tự này có thể được ví như những bậc thang xếp chồng bước và tạo thêm các lớp cập nhật cần thiết cho sản phẩm. Công việc lập trình diễn ra theo mô hình cuốn chiếu như vậy giúp đẩy nhanh tốc độ phần mềm có thể ra đến thị trường, tuy nhiên nếu lặp bước quá nhiều có thể dẫn đến phát sinh thời gian và chi phí không cần thiết.

Với Mô Hình Phát Triển Phần Mềm này, từng cấu kiện của phần mềm sẽ được chia nhỏ, tập trung phát triển, mỗi phiên bản sau là sự cải tiến của bản trước và vẫn đảm bảo duy trì được cốt lõi thiết kế. Khi làm việc theo từng phần như vậy, dự án không yêu cầu phải có đủ thông số ngay từ lúc lên kế hoạch và người làm hay khách hàng đều có thể đưa ra một số thay đổi nhỏ xen kẽ. 

Khi nào bạn nên dùng Mô Hình Phát Triển Phần Mềm Incremental & Iterative

Những dự án lớn quan trọng nhưng vẫn cần sự linh động trong thiết kế (dịch vụ web, thanh toán trực tuyến)

Trọng tâm của mô hình xoắn ốc là đánh giá rủi ro, yêu cầu người làm phải tương tác với nhóm chuyên gia có kinh nghiệm.

2.4. Mô hình Spiral (xoắn ốc)

Trọng tâm của mô hình xoắn ốc là đánh giá rủi ro, yêu cầu người làm phải tương tác với nhóm chuyên gia có kinh nghiệm. Quá trình áp dụng phương pháp này có thể diễn ra trong vòng 6 tháng với 4 hoạt động chính: lên kế hoạch, phân tích rủi ro, tạo nguyên mẫu, đánh giá từng phần của cấu kiện. Tùy vào quy trình “vòng xoắn” được lặp lại trong bao lâu mà thời gian dự án sẽ ảnh hưởng theo. 

Mô hình phát triển phần mềm này cần nhiều tương tác giữa nhóm chuyên môn và kỹ sư nên sự can thiệp của khách hàng cũng sẽ nhiều hơn đáng kể. Họ có quyền tham gia vào giai đoạn lên ý tưởng, nhận định chất lượng công việc qua mỗi lần giám sát nguyên mẫu. Tất nhiên khi nhóm kỹ sư đang phát triển phần mềm thì khách hàng vẫn không được can thiệp,

Khi nào bạn nên dùng Spiral

• Những dự án có yêu cầu phức tạp
• Dự án phát triển (R&D) hướng đến đưa ra giải pháp, sản phẩm mới cho doanh nghiệp

2.5. Rational Unified Process (RUP)

RUP là sự kết hợp giữa những framework quản lý lập trình theo phương pháp tuyến tính và lặp bước. Tại đây Mô Hình Phát Triển Phần Mềm được chia làm 4 giai đoạn: lên ý tưởng, hoàn thiện, triển khai và chuyển dịch. Các bước ngoại trừ phần lên ý tưởng thường được làm theo vài hướng song song.để đạt nhiều giải pháp linh hoạt trong một thời gian ngắn. Tuy nhiên RUP vẫn chưa có khả năng tùy biến cao như nhóm mô hình Agile mà bài viết sẽ đề cập ngay sau đây (Scrum, Kanban, XP, v.v.). 

Khi nào bạn nên dùng RUP

Dự án lớn và có tính chất phức tạp, được nghiên cứu, phân tích cụ thể và yêu cầu cho ra những phần mềm chất lượng cao trong thời gian ngắn 

3. Nhóm mô hình phát triển phần mềm Agile

Những mô hình SDLC còn lại được lựa chọn làm nội dung bài viết thuộc vào nhóm Agile. Phương thức Agile hiện đang được hơn 70% doanh nghiệp sử dụng trong mảng phát triển phần mềm. Với đặc điểm chính nằm ở tốc độ làm việc, giao tiếp hiệu quả và phản hồi tích cực với góp ý của khách hàng. 

Mỗi giai đoạn phát triển sản phẩm bằng phương pháp Agile sẽ diễn ra trong vòng vài tuần và cho ra một sản phẩm hoàn chỉnh. Các mô hình SDLC trong nhóm này tập trung vào việc hoàn thiện từng cấu kiện của phần mềm qua những khung thời gian đã định, ít tập trung vào việc ghi chép thông số, cấu hình mà hướng đến việc thử nghiệm nhiều hơn. Cách làm này cải thiện thời gian tạo ra phần mềm nhưng có thể khiến công đoạn bảo trì, chuyển giao tới bộ phận hỗ trợ lâu hơn, bởi vì không có ghi chép cụ thể cũng đồng nghĩa với việc phát hiện lỗi sẽ trở nên khó khăn.

Ở cuối giai đoạn phát triển một hay nhiều phần sản phẩm, đội ngũ kỹ sư và các nhà đầu tư sẽ cùng ngồi lại để đánh giá và trao đổi, tìm ra ưu tiên tiếp theo trọng dự án sao cho lợi nhuận từ phần mềm sẽ đạt mức tối ưu nhất, đồng thời đảm bảo sự hài lòng cho người tiêu dùng, phù hợp với trọng tâm kinh doanh. 

Phần mềm được làm theo mô hình Agile thường tung ra những bản cập nhật rất nhanh chóng do đặc thù linh hoạt, dễ chỉnh sửa và bổ sung tính năng. Song điều này có thể khiến việc xác định chi phí, thời gian và nhân lực cần thiết  phức tạp hơn và không có sự cố định. 

Khi nào bạn nên áp dụng Mô Hình Phát Triển Phần Mềm Agile 

• Các dự án startup chú trọng vào phản hồi của người dùng
• Dự án tầm trung mà chưa xác định yêu cầu và thông số cụ thể của phần mềm vì yêu cầu linh hoạt
• Dự án lớn cho phép chia nhỏ thành các giai đoạn làm việc song song

Một số Mô Hình Phát Triển Phần Mềm phổ biến trong nhóm Agile sẽ được nhắc đến tiếp theo là Scrum, Extreme Programming và Kanban.

Lập trình Cực hạn là Mô Hình Phát Triển Phần Mềm cũng theo các vòng lặp bước kéo dài khoảng 1-2 tuần.

3.1. Scrum

Scrum có lẽ là mô hình Agile phổ biến nhất, với vòng lặp bước phát triển phần mềm (sprint) thường diễn ra từ 2 đến 4 tuần và kèm theo đó là việc lên kế hoạch, đánh giá các giai đoạn trước rất kỹ càng. Sửa đổi phần mềm là không thể một khi hoạt động sprint tiếp theo đã được đề ra. 

3.2. Extreme Programming (XP)

Extreme Programming, hay Lập trình Cực hạn là Mô Hình Phát Triển Phần Mềm cũng theo các vòng lặp bước kéo dài khoảng 1-2 tuần. Các thay đổi phần mềm vẫn được phép thêm vào miễn là đội ngũ chưa đi vào bước hoàn thiện sau cùng. Mức độ linh hoạt này có thể làm phức tạp việc triển khai sản phẩm. Để hạn chế rủi ro, XP sẽ yêu cầu thêm các tác vụ lập trình đôi, kiểm tra tăng cường, cập nhật liên tục theo từng phần nhỏ để đảm bảo chất lượng. 

3.3. Kanban

Trọng tâm của mô hình Kanban là việc lên kế hoạch chi tiết, còn vòng lặp lập trình, phát triển sản phẩm như đối với Scrum hay XP sẽ diễn ra theo quy mô nhỏ hơn, có thể tính theo đơn vị hàng ngày. Công cụ chính ở đây là chiếc bảng Kanban mô tả rõ các hoạt động, tiến độ và nhân sự liên quan trong dự án. 

Bằng việc theo dõi sát sao kế hoạch làm việc, Kanban đảm bảo tính minh bạch trong sự phân công và giao tiếp, nhất là đối với những tác vụ quan trọng. Dự án đi theo hướng Kanban sẽ không có giai đoạn lên kế hoạch cụ thể riêng từ ban đầu nên mọi thay đổi có thể được thêm vào bất kỳ lúc nào.

Giao tiếp với khách hàng, nhà đầu tư cũng là một cốt lõi khác của Kanban. Mọi người có quyền theo dõi tiến độ theo ý muốn và việc họp sẽ diễn ra thường xuyên hơn. Đặc thù của Kanban sẽ phù hợp với những dự án hỗ trợ phát triển, cập nhật phần mềm lâu dài. 

Tổng Kết

Đây chỉ là một vài trong số rất nhiều mô hình phát triển phần mềm mà chúng ta có thể áp dụng. Từ các phương thức truyền thống cho đến mô hình Kanban, mỗi lựa chọn đều có thế mạnh và nhược điểm riêng để cân nhắc. Trước khi đưa ra quyết định, hãy xét đến mức độ linh hoạt mà dự án cho phép, cũng như thời gian, chi phí và rủi ro có thể chấp nhận để có giải pháp tốt nhất cho chiến lược kinh doanh công nghệ của bạn.