Tổng quan các mô hình phát triển phần mềm

Đây là một bài viết khá thú vị dành cho những người muốn tìm hiểu xem phần mềm được phát
triển như thế nào. Chỉ tiếc là PCWorld không có nhiều bài như thế này

-----------------------------------------------------------------------------------------------------
Nguồn: Thế Giới Vi Tính A số tháng 8/2005, trang 106
Thực hiện: Cao Đại Ân, Global CyberSoft Vietnam
artcawww.pcworld.com.vneretvv
-----------------------------------------------------------------------------------------------------

Cũng như mọi ngành sản xuất khác, qui trình là một trong những yếu tố cực kỳ quan trọng đem
lại sự thành công cho các nhà sản xuất phần mềm, nó giúp cho mọi thành viên trong dự án từ
người cũ đến người mới, trong hay ngoài công ty đều có thể xử lý đồng bộ công việc tương ứng
vị trí của mình thông qua cách thức chung của công ty, hay ít nhất ở cấp độ dự án.

Có thể nói qui trình phát triển/xây dựng phần mềm (Software Development/Engineering Process
- SEP) có tính chất quyết định để tạo ra sản phẩm chất luợng tốt với chi phí thấp và năng suất
cao, điều này có ý nghĩa quan trọng đối với các công ty sản xuất hay gia công phần mềm củng cố
và phát triển cùng với nền công nghiệp phần mềm đầy cạnh tranh.

Bài viết phần nào giúp bạn quyết định lựa chọn mô hình thích hợp khi xây dựng qui trình phát
triển phần mềm chung cho cấp tổ chức hay cấp dự án.

Qui trình là gì?

Qui trình có thể hiểu là phương pháp thực hiện hoặc sản xuất ra sản phẩm. Tương tự như vậy,
SEP chính là phương pháp phát triển hay sản xuất ra sản phẩm phần mềm.

Thông thường một qui trình bao gồm những yếu tố cơ bản sau:

• Thủ tục (Procedures)

• Hướng dẫn công việc (Activity Guidelines)

• Biểu mẫu (Forms/templates)

• Danh sách kiểm định (Checklists)

• Công cụ hỗ trợ (Tools)

Với các nhóm công việc chính:

• Đặc tả yêu cầu (Requirements Specification): chỉ ra những “đòi hỏi” cho cả các yêu cầu chức
năng và phi chức năng.

• Phát triển phần mềm (Development): tạo ra phần mềm thỏa mãn các yêu cầu được chỉ ra trong
“Đặc tả yêu cầu”.

• Kiểm thử phần mềm (Validation/Testing): để bảo đảm phần mềm sản xuất ra đáp ứng những
“đòi hỏi” được chỉ ra trong “Đặc tả yêu cầu”.

• Thay đổi phần mềm (Evolution): đáp ứng nhu cầu thay đổi của khách hàng.

Tùy theo mô hình phát triển phần mềm, các nhóm công việc được triển khai theo những cách
khác nhau. Để sản xuất cùng một sản phẩm phần mềm người ta có thể dùng các mô hình khác
nhau. Tuy nhiên không phải tất cả các mô hình đều thích hợp cho mọi ứng dụng.
Last edited by Nistelrooy; 07-12-2005 at 01:13 AM.

Nistelrooy

Thông tin chi tiết

Tìm kiếm các bài được viết bởi Nistelrooy

#2
07-12-2005, 12:45 AM
Ngày gia nhập: Jan 2004
Tuổi: 5
Nistelrooy Bài viết: 1,410
Quân Nhân Danh Dự Thanks: 1
Thanked 9 Times in 7 Posts
Downloads: 0
Uploads: 0

Các mô hình SEP

Mô hình SEP còn được gọi là chu trình hay vòng đời phần mềm (SLC - Software Life Cycle).
SLC là tập hợp các công việc và quan hệ giữa chúng với nhau diễn ra trong quá trình phát triển
phần mềm. Có khá nhiều mô hình SLC khác nhau, trong đó một số được ứng dụng khá phổ biến
trên thế giới:

Các mô hình một phiên bản (Single-version models)

• Mô hình Waterfall (Waterfall model)

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

• Các mô hình nhiều phiên bản (Multi-version models)

• Mô hình mẫu (Prototype)

• Mô hình tiến hóa (Evolutionary)

• Mô hình lặp và tăng dần (Iterative and Incremental)

• Mô hình phát triển ứng dụng nhanh (RAD)

• Mô hình xoắn (Spiral)

Mô hình Waterfall

Mô hình này bao gồm các giai đoạn xử lý nối tiếp nhau như được mô tả trong Hình 1.

Hình 1: Mô hình water fall

Phân tích yêu cầu và tài liệu đặc tả (Requirements and Specifications): là giai đoạn xác định
những “đòi hỏi” (“What”) liên quan đến chức năng và phi chức năng mà hệ thống phần mềm cần
có. Giai đoạn này cần sự tham gia tích cực của khách hàng và kết thúc bằng một tài liệu được
gọi là “Bản đặc tả yêu cầu phần mềm” hay SRS (software requirement specification), trong đó
bao gồm tập hợp các yêu cầu đã được duyệt (reviewed) và nghiệm thu (approved) bởi những
người có trách nhiệm đối với dự án (từ phía khách hàng). SRS chính là nền tảng cho các hoạt
động tiếp theo cho đến cuối dự án.

Phân tích hệ thống và thiết kế (System Analysis and Design): là giai đoạn định ra “làm thế
nào” (“How”) để hệ thống phần mềm đáp ứng những “đòi hỏi” (“What”) mà khách hàng yêu cầu
trong SRS. Đây là chính là cầu nối giữa “đòi hỏi” (“What”) và mã (Code) được hiện thực để đáp
ứng yêu cầu đó.

Hiện thực và kiểm thử từng thành phần (Coding and Unit Test): là giai đoạn hiện thực “làm
thế nào” (“How”) được chỉ ra trong giai đoạn “Phân tích hệ thống và thiết kế”.

Kiểm thử (Test): giai đoạn này sẽ tiến hành kiểm thử mã (code) đã được hiện thực, bao gồm
kiểm thử tích hợp cho nhóm các thành phần và kiểm thử toàn hệ thống (system test). Một khâu
kiểm thử cuối cùng thường được thực hiện là nghiệm thu (acceptance test), với sự tham gia của
khách hàng trong vai trò chính để xác định hệ thống phần mềm có đáp ứng yêu cầu của họ hay
không.

Cài đặt và bảo trì (Deployment and Maintenance): đây là giai đoạn cài đặt, cấu hình và huấn
luyện khách hàng. Giai đoạn này sửa chữa những lỗi của phần mềm (nếu có) và phát triển những
thay đổi mới được khách hàng yêu cầu (như sửa đổi, thêm hay bớt chức năng/đặc điểm của hệ
thống).

Thực tế cho thấy đến những giai đoạn sau mới có khả năng nhận ra sai sót trong những giai đoạn
trước và phải quay lại để sửa chữa. Đây chính là kiểu waterfall dạng lặp (Iterative Waterfall) và
được minh hoạ trong Hình 1.

Mô hình chữ V

Trong mô hình Waterfall, kiểm thử được thực hiện trong một giai đoạn riêng biệt. Còn với mô
hình chữ V, toàn bộ qui trình được chia thành hai nhóm giai đoạn tương ứng nhau: phát triển và
kiểm thử. Mỗi giai đoạn phát triển sẽ kết hợp với một giai đoạn kiểm thử tương ứng như được
minh họa trong Hình 2.
Hình 2: V model

Tinh thần chủ đạo của V-model là các hoạt động kiểm thử phải được tiến hành song song (theo
khả năng có thể) ngay từ đầu chu trình cùng với các hoạt động phát triển. Ví dụ, các hoạt động
cho việc lập kế hoạch kiểm thử toàn hệ thống có thể được thực hiện song song với các hoạt động
phân tích và thiết kế hệ thống.

Mô hình mẫu

Mô hình mẫu (prototype) được minh hoạ trong Hình 3. Trong đó, 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õ.

Hình 3: Mô hình mẫu

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 đó.
Last edited by Nistelrooy; 07-12-2005 at 01:14 AM.

Nistelrooy

Thông tin chi tiết

Tìm kiếm các bài được viết bởi Nistelrooy

#3
07-12-2005, 12:52 AM
Ngày gia nhập: Jan 2004
Tuổi: 5
Nistelrooy Bài viết: 1,410
Quân Nhân Danh Dự Thanks: 1
Thanked 9 Times in 7 Posts
Downloads: 0
Uploads: 0

Mô hình tiến hóa

Mô hình này thực sự cũng là một dạng dựa trên mô hình mẫu, tuy nhiên có sự khác biệt:

• mô hình tiến hóa xây dựng nhiều phiên bản prototype liên tiếp nhau.

• những phiên bản prototype trước sẽ được xây dựng với mục tiêu có thể tái sử dụng trong
những phiên bản sau.

Hình 4 minh họa mô hình tiến hóa, cho thấy một số phần của hệ thống phần mềm có thể đuợc
xây dựng sớm ngay từ giai đoạn thực hiện phân tích yêu cầu và thiết kế.
Hình 4: Mô hình tiến hóa

Mô hình lặp và tăng dần

Mô hình lặp và tăng dần có lúc được hiểu là một. Tuy nhiên, trong bài viết này, ta có thể phân
biệt ít nhiều sự khác biệt.

Trước tiên, hai mô hình này đều có điểm giống nhau là đều dựa trên tinh thần của mô hình tiến
hóa, và có thêm đặc điểm nhắm đến việc cung cấp một phần hệ thống để khách hàng có thể đưa
vào sử dụng trong môi trường hoạt động sản xuất thực sự mà không cần chờ cho đến khi toàn bộ
hệ thống được hoàn thành (trong mô hình mẫu hay tiến hóa, các phiên bản mẫu hay trung gian
đều không nhắm đến đưa vào vận hành thực sự cho khách hàng, trừ phiên bản cuối cùng). Để
khách hàng có thể sử dụng, mỗi phiên bản đều phải được thực hiện như một qui trình đầy đủ các
công việc từ phân tích yêu cầu với khả năng bổ sung hay thay đổi, thiết kế, hiện thực cho đến
kiểm nghiệm và có thể xem như một qui trình (chu trình) con. Các chu trình con có thể sử dụng
các mô hình khác nhau (thông thường là waterfall). Hình 5 minh họa hai mô hình này, trong đó
mỗi chu trình con là một waterfall nhỏ.
Hình 5

Mục tiêu của phiên bản đầu tiên là phát triển phần lõi và nhóm các chức năng quan trọng. Sau
mỗi phiên bản được đưa vào sử dụng, các kết quả đánh giá sẽ được phản hồi và lập kế hoạch cho
chu trình con của phiên bản tiếp theo để thực hiện:

• Những thay đổi cho phiên bản trước đó nhằm đáp ứng nhu cầu khách hàng tốt hơn

• Có thể thêm những chức năng hoặc đặc điểm bổ sung

• Sự khác nhau giữa hai mô hình tăng dần và lặp có thể được hiểu đơn giản như sau (so với sản
phẩm được hoàn thành trong chu trình con trước):

• Mô hình tăng dần (Incremental): thêm chức năng vào sản phẩm (xem minh hoạ Hình 6).

• Mô hình lặp (Iterative): thay đổi sản phẩm (xem minh họa Hình 6)

• Một SEP có thể kết hợp cả hai mô hình lặp lẫn tăng dần, chẳng hạn RUP (Rational Unified
Process).
Hình 6: 2 Mô hình phát triển
Last edited by Nistelrooy; 07-12-2005 at 01:33 AM.

Nistelrooy

Thông tin chi tiết

Tìm kiếm các bài được viết bởi Nistelrooy

#4
07-12-2005, 12:57 AM
Ngày gia nhập: Jan 2004
Tuổi: 5
Nistelrooy Bài viết: 1,410
Quân Nhân Danh Dự Thanks: 1
Thanked 9 Times in 7 Posts
Downloads: 0
Uploads: 0

Mô hình phát triển nhanh

Mô hình phát triển nhanh (RAD - Rapid Application Development) chính là mô hình tăng dần
với chu kỳ phát triển cực ngắn. Để đạt được mục tiêu này, RAD dựa trên phương pháp phát triển
trên cơ sở thành phần hóa hệ thống cùng với việc tái sử dụng các thành phần thích hợp. RAD
thích hợp cho những hệ thống quản lý thông tin.

Mô hình xoắn

Mô hình này được xây dựng bởi Barry Boehm, đặt trọng tâm phân tích rủi ro và xem xét kế
hoạch để giải quyết chúng, thông qua nhiều chu kỳ con nối tiếp được lặp liên tiếp dựa trên bản
chất của mô hình lặp.

Trong mô hình này, việc phân tích và giải quyết những vấn đề có rủi ro cao tập trung vào thiết
kế từng khía cạnh cụ thể chứ không dựa vào việc xử lý các vấn đề một cách chung chung.
Hình 7 minh họa mô hình này với các giai đoạn lặp theo chu kỳ xoay vòng, trong đó mỗi chu kỳ
bao gồm 4 giai đoạn con như sau:

1. Xác định mục tiêu chất lượng cho sản phẩm được thực hiện, đồng thời xác định sự lựa chọn
mua, tái sử dụng hay tự thiết kế và hiện thực các thành phần của hệ thống.

2. Phân tích sự lựa chọn và các rủi ro có thể xảy ra. Việc này được thực hiện bởi nhiều hoạt động
khác nhau thông qua làm mẫu hay mô phỏng.

3. Phát triển và kiểm định sản phẩm ở mức tiếp theo dựa trên kết quả định hướng được chỉ ra
trong giai đoạn con số 2 (phân tích rủi ro)

4. Kiểm duyệt tất cả các kết quả của các giai đoạn con xảy ra trước đó và lập kế hoạch cho chu
kỳ lặp tiếp theo.

Hình 7: Mô hình xoắn

Last edited by Nistelrooy; 07-12-2005 at 01:16 AM.
 Nistelrooy

Thông tin chi tiết

Tìm kiếm các bài được viết bởi Nistelrooy

#5
07-12-2005, 01:01 AM
Ngày gia nhập: Jan 2004
Tuổi: 5
Nistelrooy Bài viết: 1,410
Quân Nhân Danh Dự Thanks: 1
Thanked 9 Times in 7 Posts
Downloads: 0
Uploads: 0

SO SÁNH CÁC MÔ HÌNH

Bài này xin được tiếp tục nêu lên những ưu và nhược điểm của mỗi mô hình để giúp bạn có thể
lựa chọn mô hình phù hợp cho dự án phần mềm của mình.

Mô hình Waterfall

Ưu điểm:

Các giai đoạn được định nghĩa, với đầu vào và đầu ra rõ ràng. Mô hình này cơ bản dựa trên tài
liệu nhất là trong các giai đoạn đầu, đầu vào và đầu ra đều là tài liệu.

Sản phẩm phần mềm được hình thành thông qua chuỗi các hoạt động xây dựng phần mềm theo
trình tự rõ ràng.

Nhược điểm:

Đòi hỏi tất cả yêu cầu phần mềm phải được xác định rõ ràng ngay từ đầu dự án. Nhưng đa số dự
án thực tế cho thấy yêu cầu phần mềm thường ẩn chứa không nhiều thì ít những điểm không
chắc chắn.

Một thực tế là các dự án hiếm khi được thực hiện đầy đủ các bước trong suốt chu kỳ dự án. Đặc
biệt là giai đoạn kiểm thử khi gần đến ngày giao hàng chẳng hạn, nếu có trục trặc xảy ra do yêu
cầu phần mềm không rõ ràng hay thiết kế có lỗi, xu hướng là mã nguồn được sửa đổi trực tiếp
mà không qua các bước bổ sung theo đúng mô hình, nên dẫn đến bản đặc tả phần mềm cũng như
một số sản phẩm trung gian khác như bản thiết kế, cho dù có được cập nhật sau này cũng có thể
không phản ánh đầy đủ những gì đã được sửa đổi trong mã nguồn.

Người sử dụng không có cơ hội tham gia trong suốt thời gian của các giai đoạn trung gian từ
thiết kế cho đến kiểm thử. Đặc biệt với những dự án lớn, người sử dụng chỉ có thể nhận ra rằng
hệ thống phần mềm không phù hợp cho nhu cầu của họ vào thời điểm cuối dự án.

Nói chung, mô hình này thường ẩn chứa nhiều rủi ro mà chỉ có thể phát hiện ở giai đoạn cuối
cùng (được minh họa trong hình 1) và chi phí để sửa chữa có thể rất cao.

Ứng dụng:

Yêu cầu được định nghĩa rất rõ ràng, chi tiết và hầu như không thay đổi, thường xuất phát từ sản
phẩm đã đạt mức ổn định.

Yêu cầu mới bổ sung (nếu có) cũng sớm được xác định rõ ràng, đầy đủ từ đầu dự án.

Đội ngũ thực hiện quen thuộc và hiểu rõ tất cả yêu cầu của dự án, và có nhiều kinh nghiệm với
các công nghệ được dùng để phát triển sản phẩm.

Dự án được xác định hầu như không có rủi ro.

Mô hình chữ V

Ưu điểm:

Các hoạt động kiểm thử được chú trọng và thực hiện song song với các hoạt động liên quan đến
đặc tả yêu cầu và thiết kế. Hay nói cách khác, mô hình này khuyến khích các hoạt động liên
quan đến kế hoạch kiểm thử được tiến hành sớm trong chu kỳ phát triển, không phải đợi đến lúc
kết thúc giai đoạn hiện thực.

Nhược điểm:

Giống mô hình waterfall

Ứng dụng:

Tham khảo mô hình waterfall.

Mô hình mẫu

Ư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.

Mô hình tiến hóa

Ưu điểm:

Chú trọng việc tái sử dụng mẫu. Một phần của hệ thống có thể được phát triển ngay trong các
giai đoạn phân tích phát triển yêu cầu và thiết kế.

Cho phép thay đổi yêu cầu và khuyến khích người sử dụng tham gia trong suốt chu kỳ của dự
án.

Nhược điểm:

Làm chậm quá trình phát triển yêu cầu và có thể ảnh hưởng sự chú ý đến các công việc trung
gian như kiểm tra mã nguồn, thực hiện kiểm thử cấp thấp...

Dễ dẫn đến kết cấu của hệ thống kém.

Thường thì với mô hình này, tính chặt chẽ, minh bạch của qui trình kém.

Ứng dụng:

Hệ thống tương tác nhỏ và vừa; phần GUI của những hệ thống lớn; những hệ thống cần chu kỳ
phát triển ngắn.

Đội ngũ phát triển không quen thuộc với lĩnh vực của dự án.
Last edited by Nistelrooy; 07-12-2005 at 01:18 AM.

Nistelrooy

Thông tin chi tiết

 Tìm kiếm các bài được viết bởi Nistelrooy

#6
07-12-2005, 01:05 AM
Ngày gia nhập: Jan 2004
Tuổi: 5
Nistelrooy Bài viết: 1,410
Quân Nhân Danh Dự Thanks: 1
Thanked 9 Times in 7 Posts
Downloads: 0
Uploads: 0

Mô hình lặp và tăng dần

Ưu điểm:

Giảm rủi ro sớm trong chu kỳ phát triển phần mềm. Những yêu cầu quan trọng thường được
phát triển và chuyển đến người sử dụng sớm.

Phản hồi của nguời sử dụng về những vấn đề phát sinh trong phiên bản trước được dùng để cải
tiến và ngăn ngừa những vấn đề tương tự xảy ra trong những phiên bản tiếp theo.

Nhược điểm:

Tổng chi phí lập kế hoạch phát triển cho toàn hệ thống có thể cao hơn. Lưu ý, ở đây chỉ đề cập
chi phí lập kế hoạch ban đầu, không bao gồm tất cả chi phí phát sinh. Trong thực tế, nếu ứng
dụng hợp lý, toàn bộ chi phí và thời gian cho đến khi sản phẩm được nghiệm thu có thể thấp hơn
so với mô hình khác.

Các yêu cầu về kế hoạch và hoạt động trong qui trình cụ thể sẽ phức tạp hơn.

Ứng dụng:

Mô hình lặp:

Đội ngũ phát triển quen thuộc với lĩnh vực dự án nhưng không có nhiều kinh nghiệm, nhất là về
công nghệ được dùng phát triển dự án.

Có nhiều rủi ro về mặt kỹ thuật

Mô hình tăng dần:

Rủi ro được phân tích và xác định ngay từ đầu.

Giao tiếp giữa các module cũng được xác định rõ ràng từ đầu.
Đội ngũ phát triển quen thuộc với lĩnh vực của dự án và có nhiều kinh nghiệm.

Hệ thống lớn được phát triển trong thời gian dài, khách hàng cần triển khai sớm một số phần của
hệ thống.

Mô hình phát triển nhanh

Ưu điểm:

Cho phép giảm thời gian phát triển các ứng dụng CSDL và có nhiều giao diện người dùng hay
tích hợp các thành phần có sẵn.

Người sử dụng sẽ tham gia vào các hoạt động kiểm thử.

Nhược điểm:

Khó có sự nhất quán giữa những thành phần được phát triển bởi các nhóm khác nhau.

Không phù hợp cho những ứng dụng đòi hỏi hiệu suất vì thường phụ thuộc vào sự hỗ trợ của
môi trường phát triển và ngôn ngữ cấp cao.

Ứng dụng:

Hệ thống quản lý thông tin kiểu những ứng dụng dựa trên GUI và CSDL.

Có sự hỗ trợ của công cụ hay sử dụng ngôn ngữ cấp cao.

Hệ thống không yêu cầu khắt khe về hiệu suất.

Mô hình xoắn

Ưu điểm:

Phân tích đánh giá rủi ro được đẩy lên như một phần thiết yếu trong mỗi “spiral” để tăng mức độ
tin cậy của dự án.

Kết hợp những tính chất tốt nhất của mô hình waterfall và tiến hóa.

Cho phép thay đổi tùy theo điều kiện thực tế dự án tại mỗi “spiral”.

Đây chính là mô hình tổng quát nhất, tất cả các mô hình khác đều có thể xem là một hiện thực
của mô hình tổng quát này, hay cũng có thể xem nó là mô hình tổng hợp các mô hình khác. Đặc
biệt, nó được ứng dụng không chỉ trong phát triển phần mềm mà còn trong phát triển phần cứng.

Nhược điểm:
Phức tạp và không phù hợp cho dự án nhỏ với ít rủi ro.

Cần có kỹ năng tốt về phân tích rủi ro.

Ứng dụng:

Dự án lớn có nhiều rủi ro hay sự thành công của dự án không có được sự đảm bảo nhất định;
những dự án đòi hỏi nhiều tính toán, xử lý như hệ thống hỗ trợ
quyết định.

Đội ngũ thực hiện dự án có khả năng phân tích rủi ro.

Trên đây là một số so sánh giữa các mô hình, thực sự việc lựa chọn cụ thể mô hình nào không
phải dễ dàng và trên thực tế người ta thường dùng mô hình lai, kết hợp một số mô hình với nhau
sao cho phù hợp với dự án.

Việc cải tiến các mô hình phát triển phần mềm luôn là đề tài nghiên cứu hấp dẫn, với sự tham
gia tích cực không những từ các nhà sản xuất phần mềm mà còn từ các viện đại học khắp thế
giới. Riêng với các nhà phát triển phần mềm, họ luôn cố gắng cải tiến liên tục qui trình phát triển
của mình nhằm không ngừng đổi mới, nâng cao năng suất và chất lượng sản phẩm. Tuy nhiên,
một điều dễ thấy là việc lựa chọn, tùy biến mô hình phù hợp cho các dự án đã khó, nhưng việc
vận hành nó vào trong quá trình phát triển sản phẩm càng khó hơn. Đó chính là thách thức cho
các nhà phát triển phần mềm.