Một số mô hình phát triển phần mềm
Mô hình phát triển phần mềm là một thể hiện trừu tượng của quy trình phần mềm. Nó biểu diễn các đặc tả về quy trình từ những khía cạnh cụ thể; do đó, nó chỉ cung cấp một phần thông tin về quy trình phần mềm. Phần sau đây sẽ trình bày năm mô hình phát triển phần mềm phổ biến thường được sử dụng:
- Mô hình thác nước
- Mô hình xây dựng tiến triển
- Công nghệ phần mềm dựa thành phần
- Mô hình phát triển lặp lại, tăng thêm
- Mô hình xoắn ốc Mục tiêu
- Phải hiểu rõ năm mô hình phát triển phần mềm cơ bản.
- Phân biệt được sự khác nhau giữa các mô hình; ưu và nhược điểm của từng mô hình.
- Biết rõ đối với loại hệ thống nào thì nên áp dụng mô hình phát triển nào cho phù hợp.
Mô hình thác nước
Các pha của mô hình thác nước bao gồm:
- Phân tích và xác định các yêu cầu
- Thiết kế hệ thống và phần mềm
- Cài đặt và kiểm thử đơn vị
- Tích hợp và kiểm thử hệ thống
- Vận hành và bảo trì.
Trong mô hình thác nước, năm pha trên phải được thực hiện một cách tuần tự; kết thúc pha trước, rồi mới được thực hiện pha tiếp theo. Do đó, nhược điểm chính của mô hình thác nước là rất khó khăn trong việc thay đổi các pha đã được thực hiện. Giả sử, pha phân tích và xác định yêu cầu đã hoàn tất và chuyển sang pha kế tiếp, nhưng lúc này lại có sự thay đổi yêu cầu của người sử dụng; thì chỉ còn cách là phải thực hiện lại từ đầu. Cho nên, mô hình này chỉ thích hợp khi các yêu cầu đã được tìm hiểu rõ ràng và những thay đổi sẽ được giới hạn một cách rõ ràng trong suốt quá trình thiết kế. Tuy nhiên, trong thực tế có rất ít những hệ thống nghiệp vụ có các yêu cầu ổn định.
Mô hình xây dựng tiến triển
Mô hình xây dựng tiến triển dựa trên ý tưởng xây dựng một mẫu thử ban đầu và đưa cho người sử dụng xem xét; sau đó, tinh chỉnh mẫu thử qua nhiều phiên bản cho đến khi thoả mãn yêu cầu của người sử dụng thì dừng lại. Có hai phương pháp để thực hiện mô hình này:
- Phát triển thăm dò: mục đích của nó là để làm việc với khách hàng và để đưa ra hệ thống cuối cùng từ những đặc tả sơ bộ ban đầu. Phương pháp này thường bắt đầu thực hiện với những yêu cầu được tìm hiểu rõ ràng và sau đó, bổ sung những đặc điểm mới được đề xuất bởi khách hàng. Cuối cùng, khi các yêu cầu của người sử dụng được thoả mãn thì cũng là lúc chúng ta đã xây dựng xong hệ thống.
- Loại bỏ mẫu thử: mục đích là để tìm hiểu các yêu cầu của hệ thống. Phương pháp này thường bắt đầu với những yêu cầu không rõ ràng và ít thông tin. Các mẫu thử sẽ được xây dựng và chuyển giao tới cho người sử dụng. Từ đó, ta có thể phân loại những yêu cầu nào là thực sự cần thiết và lúc này mẫu thử không còn cần thiết nữa. Như vậy, mẫu thử chỉ có tác dụng để làm sáng tỏ yêu cầu của người sử dụng. Tuy nhiên, nhược điểm của mô hình xây dựng tiến triển là: thiếu tầm nhìn của cả quy trình; các hệ thống thường hướng cấu trúc nghèo nàn; yêu cầu các kỹ năng đặc biệt [Ví dụ: các ngôn ngữ để tạo ra mẫu thử nhanh chóng]. Mô hình xây dựng tiến triển chỉ nên áp dụng với những hệ thống có tương tác ở mức độ nhỏ hoặc vừa; trên một phần của những hệ thống lớn; hoặc những hệ thống có thời gian chu kỳ tồn tại ngắn.
Công nghệ phần mềm dựa thành phần
Mô hình này dựa trên kỹ thuật tái sử dụng một cách có hệ thống; trong đó hệ thống được tích hợp từ nhiều thành phần đang tồn tại hoặc các thành phần thương mại COTS [Commercial-off-the-shelf]. Các trạng thái chính của quy trình bao gồm:
- Phân tích thành phần sẵn có
- Điều chỉnh yêu cầu
- Thiết kế hệ thống với kỹ thuật tái sử dụng
- Xây dựng và tích hợp hệ thống
Mô hình phát triển lặp lại, tăng thêm
Mô hình này được đề xuất dựa trên ý tưởng thay vì phải xây dựng và chuyển giao hệ thống một lần thì sẽ được chia thành nhiều vòng, tăng dần. Mỗi vòng là một phần kết quả của một chức năng được yêu cầu. Các yêu cầu của người sử dụng được đánh thứ tự ưu tiên. Yêu cầu nào có thứ tự ưu tiên càng cao thì càng ở trong những vòng phát triển sớm hơn. Từ đó, chúng ta có thể thấy rõ một số ưu điểm của mô hình phát triển tăng vòng:
- Sau mỗi lần tăng vòng thì có thể chuyển giao kết quả thực hiện được cho khách hành nên các chức năng của hệ thống có thể nhìn thấy sớm hơn.
- Các vòng trước đóng vai trò là mẫu thử để giúp tìm hiểu thêm các yêu cầu ở những vòng tiếp theo.
- Những chức năng của hệ thống có thứ tự ưu tiên càng cao thì sẽ được kiểm thử càng kỹ.
Mô hình xoắn ốc
Trong mô hình xoắn ốc, quy trình phát triển phần mềm được biểu diễn như một vòng xoắn ốc. Các pha trong quy trình phát triển xoắn ốc bao gồm:
- Thiết lập mục tiêu: xác định mục tiêu cho từng pha của dự án.
- Đánh giá và giảm thiểu rủi ro: rủi ro được đánh giá và thực hiện các hành động để giảm thiểu rủi ro.
- Phát triển và đánh giá: sau khi đánh giá rủi ro, một mô hình xây dựng hệ thống sẽ được lựa chọn từ những mô hình chung.
- Lập kế hoạch: đánh giá dự án và pha tiếp theo của mô hình xoắn ốc sẽ được lập kế hoạch.
Xem công nghệ mới nhất tại: //www.facebook.com/hauisoftware
Mô hình phát triển phần mềm hay quy trình phát triển phần mềm xác định các pha/ giai đoạn trong xây dựng phần mềm. Hôm nay, Techacademy.edu.vn giới thiệu các mô hình phát triển phần mềm thông dụng và hiệu quả nhất hiện nay.
1. Định nghĩa
Mô hình phát triển phần mềm hay quy trình phát triển phần mềm xác định các pha/ giai đoạn trong xây dựng phần mềm. Có nhiều loại mô hình phát triển phần mềm khác nhau ví dụ như:
- Mô hình thác nước [ Waterfall model]
- Mô hình xoắn ốc [ Spiral model]
- Mô hình agile
- Mô hình tiếp cận lặp [ Iterative model]
- Mô hình tăng trưởng [ Incremental model]
- Mô hình chữ V [ V model]
- Mô hình Scrum
- RAD model [ Rapid Application Development]
Bài viết này sẽ giúp bạn giải đáp thắc mắc về các mô hình trong phát triển phần mềm được sử dụng trong khóa học Tester – Kiểm thử phần mềm tại Techacademy Việt Nam.
2. Các mô hình được sử dụng trọng khóa học Tester Kiểm thử phần mềm
2.1. Mô hình thác nước [ Waterfall model]
Đây được coi như là mô hình phát triển phần mềm đầu tiên được sử dụng. Mô hình này áp dụng tuần tự các giai đoạn của phát triển phần mềm. Đầu ra của giai đoạn trước là đầu vào của giai đoạn sau. Giai đoạn sau chỉ được thực hiện khi giai đoạn trước đã kết thúc. Đặc biệt không được quay lại giai đoạn trước để xử lý các yêu cầu khi muốn thay đổi.
Phân tích mô hình
- Requirement gathering: Thu thập và phân tích yêu cầu được ghi lại vào tài liệu đặc tả yêu cầu trong giai đoạn này.
- System Analysis: Phân tích thiết kế hệ thống phần mềm, xác định kiến trúc hệ thống tổng thể của phần mềm.
- Coding: Hệ thống được phát triển theo từng unit và được tích hợp trong giai đoạn tiếp theo. Mỗi Unit được phát triển và kiểm thử bởi dev được gọi là Unit Test.
- Testing: Cài đặt và kiểm thử phần mềm. Công việc chính của giai đoạn này là kiểm tra và sửa tất cả những lỗi tìm được sao cho phần mềm hoạt động chính xác và đúng theo tài liệu đặc tả yêu cầu.
- Implementation: Triển khai hệ thống trong môi trường khách hàng và đưa ra thị trường.
- Operations and Maintenance: Bảo trì hệ thống khi có bất kỳ thay đổi nào từ phía khách hàng, người sử dụng.
Ứng dụng
Mô hình thường được áp dụng cho các dự án phần mềm như sau:
- Các dự án nhỏ , ngắn hạn.
- Các dự án có ít thay đổi về yêu cầu và không có những yêu cầu không rõ ràng.
Ưu điểm
- Dễ sử dụng, dễ tiếp cận, dễ quản lý.
- Sản phẩm phát triển theo các giai đoạn được xác định rõ ràng.
- Xác nhận ở từng giai đoạn, đảm bảo phát hiện sớm các lỗi.
Nhược điểm
- Ít linh hoạt, phạm vi điều chỉnh hạn chế.
- Rất khó để đo lường sự phát triển trong từng giai đoạn.
- Mô hình không thích hợp với những dự án dài, đang diễn ra, hay những dự án phức tạp, có nhiều thay đổi về yêu cầu trong vòng đời phát triển.
- Khó quay lại khi giai đoạn nào đó đã kết thúc.
Tham khảo: Các phương pháp kiểm thử phần mềm
2.2.Mô hình chữ V[ V model]
Mô tả Mô hình V là một phần mở rộng của mô hình thác nước và được dựa trên sự kết hợp của một giai đoạn thử nghiệm cho từng giai đoạn phát triển tương ứng. Điều này có nghĩa là đối với mỗi giai đoạn trong chu kỳ phát triển, có một giai đoạn thử nghiệm liên quan trực tiếp. Đây là một mô hình có tính kỷ luật cao và giai đoạn tiếp theo chỉ bắt đầu sau khi hoàn thành giai đoạn trước.
Với V model thì công việc test được tham gia ngay từ đầu, từ lúc lấy yêu cầu là có thể “test” bằng cách review tài liệu yêu cầu, rồi cho tới review đặc tả chi tiết, các bản thiết kế, review code rồi cuối cùng là test ở mức thấp nhất – từng module, chức năng, màn hình, đến test tích hợp rồi kiểm thử hệ thống. So với mô hình khác thì ở mô hình này, công việc test đi sát hơn và ngay từ đầu khi bắt đầu phát triển.
Chắc chắn chất lượng dự án sẽ tốt hơn. Nhưng tại sao người ta vẫn tiếp tục đưa ra mô hình phát triển khác? Vì ở mô hình chữ V này người ta vẫn phát triển cùng lúc cả hệ thống [nhiều yêu cầu, chức năng cùng lúc] mà rủi ro về thay đổi yêu cầu là rất lớn. Nên mô hình này vẫn có thể gặp rắc rối khi khách hàng thường xuyên thay đổi yêu cầu
Ứng dụng Ứng dụng mô hình V- Model gần giống như mô hình thác nước , vì cả hai mô hình đều thuộc loại tuần tự. Yêu cầu phải rất rõ ràng trước khi dự án bắt đầu, bởi vì nó thường đắt tiền để quay trở lại và thực hiện thay đổi. Mô hình này được sử dụng trong lĩnh vực phát triển y tế, vì nó là một lĩnh vực xử lý kỷ luật nghiêm ngặt. Sau đây là một số kịch bản phù hợp nhất để sử dụng ứng dụng V-Model.
Yêu cầu được xác định rõ ràng, được ghi chép và cố định rõ ràng:
- Xác định sản phẩm ổn định.
- Công nghệ không thay đổi và được hiểu rõ bởi nhóm dự án.
- Không có yêu cầu không rõ ràng hoặc không xác định.
- Dự án ngắn.
Ưu điểm
- Đây là một mô hình có tính kỷ luật cao và các giai đoạn được hoàn thành cùng một lúc.
- Hoạt động tốt cho các dự án nhỏ, khi các yêu cầu được hiểu rất rõ.
- Đơn giản và dễ hiểu và dễ sử dụng.
- Dễ quản lý. Mỗi giai đoạn có phân phối cụ thể và quy trình đánh giá.
Nhược điểm
- Khó quản lý kiểm soát rủi ro, rủi ro cao
- Không phải là một mô hình tốt cho các dự án phức tạp và hướng đối tượng.
- Mô hình kém cho các dự án dài và đang diễn ra.
- Không thích hợp cho các dự án có nguy cơ thay đổi yêu cầu trung bình đến cao.
- Khi ứng dụng đang ở giai đoạn thử nghiệm, rất khó để quay lại và thay đổi chức năng.
2.3.Mô hình mẫu
Trong mô hình mẫu [prototype], qui trình được bắt đầu bằng việc thu thập yêu cầu với sự có mặt của đại diện của cả phía phát triển lẫn khách hàng nhằm định ra mục tiêu tổng thể của hệ thống phần mềm sau này, đồng thời ghi nhận tất cả những yêu cầu có thể biết được và sơ luợc những nhóm yêu cầu nào cần phải được làm rõ.
Sau đó, thực hiện thiết kế nhanh tập trung chuyển tải những khía cạnh thông qua prototype để khách hàng có thể hình dung, đánh giá giúp hoàn chỉnh yêu cầu cho toàn hệ thống phần mềm. Việc này không những giúp tinh chỉnh yêu cầu, mà đồng thời giúp cho đội ngũ phát triển thông hiểu hơn những gì cần được phát triển. Tiếp theo sau giai đoạn làm prototype này có thể là một chu trình theo mô hình waterfall hay cũng có thể là mô hình khác.
Chú ý, prototype thường được làm thật nhanh trong thời gian ngắn nên không được xây dựng trên cùng môi trường và công cụ phát triển của giai đoạn xây dựng phần mềm thực sự sau này. Prototype không đặt ra mục tiêu tái sử dụng cho giai đoạn phát triển thực sự sau đó.
Ưu điểm
- Người sử dụng sớm hình dung ra chức năng và đặc điểm của hệ thống.
- Cải thiện sự liên lạc giữa nhà phát triển và người sử dụng.
Nhược điểm
- Khi mẫu [prototype] không chuyển tải hết các chức năng, đặc điểm của hệ thống phần mềm thì người sử dụng có thể thất vọng và mất đi sự quan tâm đến hệ thống sẽ được phát triển.
- Prototype thường được làm nhanh, thậm chí vội vàng, theo kiểu “hiện thực – sửa” và có thể thiếu sự phân tích đánh giá một cách cẩn thận tất cả khía cạnh liên quan đến hệ thống cuối cùng.
- Nói chung mô hình này vẫn chưa thể cải thiện được việc loại trừ khoảng cách giữa yêu cầu và ứng dụng cuối cùng.
Ứng dụng
- Hệ thống chủ yếu dựa trên giao diện người dùng [GUI]
- Khách hàng, nhất là người sử dụng cuối, không thể xác định rõ ràng yêu cầu.
2.4.Mô hình Agile
Agile là một phương pháp phát triển phần mềm linh hoạt để làm sao đưa sản phẩm đến tay người dùng càng nhanh càng tốt và được xem như là sự cải tiến so với những mô hình cũ như mô hình “Thác nước [waterfall]” hay “CMMI”. Phương thức phát triển phần mềm Agile 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 và giải pháp được phát triển thông qua sự liên kết cộng tác giữa các nhóm tự quản và liên chức năng.
Mô tả
- Dựa trên mô hình iterative and incremental.
- Các yêu cầu và giải pháp phát triển dựa trên sự kết hợp của các function.
- Trong Agile, các tác vụ được chia thành các khung thời gian nhỏ để cung cấp các tính năng cụ thể cho bản phát hành cuối.
Ứng dụng
- Có thể được sử dụng với bất kỳ loại hình dự án nào, nhưng cần sự tham gia và tính tương tác của khách hàng.
- Sử dụng khi khách hàng yêu cầu chức năng sẵn sàng trong khoảng thời gian ngắn.
Ưu điểm
- Tăng cường tình thần làm việc nhóm và trao đổi công việc hiệu quả.
- Các chức năng được xây dựng nhanh chóng và rõ ràng, dế quản lý.
- Dễ dàng bổ sung, thay đổi yêu cầu.
- Quy tắc tối thiểu, tài liệu dễ hiểu, dễ sử dụng.
Nhược điểm
Mô hình Agile được sử dụng rộng rãi trên thế giới nhưng cũng không đồng nghĩa với phù hợp với tất cả các dự án phần mềm.
- Không thích hợp để xử lý các phụ thuộc phức tạp.
- Có nhiều rủi ro về tính bền vững, khả năng bảo trì và khả năng mở rộng.
- Cần một team có kinh nghiệm.
- Phụ thuộc rất nhiều vào sự tương tác rõ ràng của khách hàng.
- Chuyển giao công nghệ cho các thành viên mới trong nhóm có thể khá khó khăn do thiếu tài liệu.
2.5. Mô hình xoắn ốc
Mô tả
- Là mô hình kết hợp giữa các tính năng của mô hình prototyping và mô hình thác nước.
- Mô hình xoắn ốc được ưa chuộng cho các dự án lớn, đắt tiền và phức tạp.
- Mô hình này sử dụng những giai đoạn tương tự như mô hình thác nước, về thứ tự, plan, đánh giá rủi ro, …
- Phân tích mô hình
Các pha trong quy trình phát triển xoắn ốc bao gồm:
- Objective identification- Thiết lập mục tiêu: xác định mục tiêu, đối tượng cho từng pha của dự án.
- Alternate evaluation- Đánh giá và giảm thiểu rủi ro: đánh giá rủi ro và thực hiện các hành động để giảm thiểu rủi ro.
- Product development- Phát triển sản phẩm: Lựa chọn mô hình phù hợp để phát triển hệ thống.
- Next phase planning- Lập kế hoạch: đánh giá dự án và lập kế hoạch cho pha tiếp theo.
Ứng dụng
Mô hình này thường được sử dụng cho các ứng dụng lớn và các hệ thống được xây dựng theo các giai đoạn nhỏ hoặc theo các phân đoạn.
Ưu điểm
- Tốt cho các hệ phần mềm quy mô lớn.
- Dễ kiểm soát các mạo hiểm ở từng mức tiến hóa.
- Đánh giá thực tế hơn như là một quy trình làm việc, bởi vì những vấn đề quan trọng đã được phát hiện sớm hơn.
Nhược điểm
- Manager cần có kỹ năng tốt để quản lý dự án, đánh giá rủi ro kịp thời.
- Chi phí cao và mất nhiều thời gian để hoàn thành dự án.
- Phức tạp và không thích hợp với các dự án nhỏ và ít rủi ro.
- Yêu cầu thay đổi thường xuyên dẫn đến lặp vô hạn.
- Chưa được dùng rộng rãi.
2.6 Mô hình Scrum
Mô tả
Chia các yêu cầu ra làm theo từng giai đoạn. Mỗi 1 giai đoạn[sprint] chỉ làm 1 số lượng yêu cầu nhất định.
Mỗi một sprint thường kéo dài từ 1 tuần đến 4 tuần [ ko dài hơn 1 tháng].
Đầu sprint sẽ lên kế hoạch làm những yêu cầu nào. Sau đó, sẽ thực hiện code và test. Cuối sprint là 1 sản phẩm hoàn thiện cả code lẫn test có thể demo và chạy được.
Hoàn thành sprint 1, tiếp tục làm sprint 2, sprint… cho đến khi hoàn thành hết các yêu cầu.
Trong mỗi 1 sprint thì sẽ có họp hàng ngày – daily meeting từ 15 – 20 phút. Mỗi thành viên sẽ báo cáo: Hôm qua tôi đã làm gì? Hôm nay tôi sẽ làm gì? Có gặp khó khăn gì không?
Các nhân tố tạo nên quy trình Scrum
Có 3 thành tố quan trọng cấu thành nên SCRUM:
+ Tổ chức [Organization]
- Tổ chức nhóm dự án và Roles: Vài trò.
- Product Owner: Người sở hữu sản phẩm.
- ScrumMaster: Người điều phối.
- Development Team: Nhóm phát triển.
+ Tài liệu [Atifacts]: đó chính là các kết quả đầu ra.
- Product Backlog: Danh sách các chức năng cần phát triển của sản phẩm.
- Sprint Backlog: Danh sách các chức năng cần phát triển cho mỗi giai đoạn.
- Estimation:Kết quả ước lượng của team.
+ Qui trình[Process]: Qui định cách thức vận hành của SCRUM.
- Sprint Planning meeting: Hoạch định cho mỗi giai đoạn.
- Review: Tổng kết cho mỗi giai đoạn.
- Daily Scrum Meeting: Review hàng ngày.
Tổ chức dự án
+ Product Owner
Product Owner là người sở hữu sản phẩm, người quyết định sản phẩm có những chức năng nào và là người quyết định Product Backlog.
Thông thường Role này được khách hàng hoặc người đại diện cho khách hàng đảm nhận.
+ ScrumMaster
Scrum Master là người đảm bảo các qui trình của Scrum được thực hiện đúng và thuận lợi.
+ Development Team
Một nhóm từ 4-7 kỹ sư phần mềm chịu trách nhiệm phát triển sản phẩm.
Nhóm dự án phải làm việc với Product Owner để quyết định những gì sẽ làm trong Sprint [giai đoạn ]này và kết quả sẽ ra sao. Thảo luận để đưa ra các giải pháp, ước lượng thời gian thực hiện công việc, họp đánh giá kết quả công việc.
+ Product Backlog
Product Backlog là danh sách các chức năng cần được phát triển của sản phẩm.
Danh sách này do Product Owner quyết định.Thường xuyên được cập nhật để đáp ứng được nhu cầu thay đổi của khách hàng và dự án.
Ưu điểm
- Một người có thể thực hiện nhiều việc ví dụ như dev có thể test.
- Phát hiện lỗi sớm.
- Có khả năng áp dụng được cho những dự án mà yêu cầu khách hàng không rõ ràng ngay từ đầu.
Nhược điểm
- Trình độ của nhóm cần có một kỹ năng nhất định.
- Phải có sự hiểu biết về mô hình aglie.
- Khó khăn trong việc xác định ngân sách và thời gian.
- Luôn nghe ý kiến phản hồi từ khách hàng và thay đổi theo nên thời gian sẽ kéo dài.
- Vai trò của PO rất quan trọng, PO là người định hướng sản phẩm. Nếu PO làm không tốt sẽ ảnh hưởng đến kết quả chung.
2.7 Mô hình RAD
Mô tả
Mô hình RAD là một phương pháp phát triển phần mềm sử dụng quy hoạch tối thiểu có lợi cho việc tạo mẫu nhanh. Các mô-đun chức năng được phát triển song song như nguyên mẫu và được tích hợp để tạo ra sản phẩm hoàn chỉnh để phân phối sản phẩm nhanh hơn.
Đảm bảo rằng các nguyên mẫu được phát triển có thể tái sử dụng được.