Quản Lý Quy Trình Phần Mềm Theo Mô Hình Cmm - Thực Tiễn Và Ứng Dụng Ở Việt Nam 6811962.Pdf

Output file 1 Chuyên ngành Công Nghệ Thông Tin Mã số 01 01 10 Hà Nội 2006 Hà Nội, 12/2005 ĐẠI HỌC QUỐC GIA HÀ NỘI ĐẠI HỌC CÔNG NGHỆ  Đỗ Việt Hùng QUẢN LÝ QUY TRÌNH PHẦN MỀM THEO MÔ HÌNH CMM – THỰC[.]

Chuyên ngành: Công Nghệ Thông Tin

QUẢN LÝ QUY TRÌNH PHẦN MỀM THEO MÔ HÌNH

CMM – THỰC TIỄN VÀ ỨNG DỤNG Ở VIỆT NAM

Luận văn Thạc sỹ

Người hướng dẫn:

PGS Nguyễn Quốc Toản

MỤC LỤC

MỤC LỤC 2

DANH MỤC HÌNH VẼ 5

LỜI MỞ ĐẦU 6

CHƯƠNG I 9

TỔNG QUAN CÁC MÔ HÌNH PHÁT TRIỂN PHẦN MỀM 9

1 Khái niệm quy trình 9

2 SEP, ISO, CMM/CMMI 11

3 Các mô hình SEP 12

3.1 Mô hình Thác nước (Waterfall) 13

3.2 Mô hình chữ V 14

3.3 Mô hình mẫu 15

3.4 Mô hình tiến hóa 15

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

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

3.7 Mô hình xoắn 17

CHƯƠNG 2 19

CMM VÀ KHÓ KHĂN TRONG PHÁT TRIỂN PHẦN MỀM 19

1 Lịch Sử Mô Hình CMM [1] 19

2 Tổng quan về mô hình CMM 20

2.1 Định nghĩa về CMM 24

2.2 Ích lợi của cải tiến theo mô hình CMM 25

2.4 Năm mức độ trưởng thành của mô hình CMM 26

2.5 Các lĩnh vực quy trình chốt (KPA) của mô hình CMM 29

2.6 Khả năng áp dụng CMM 30

3 Những Khó Khăn Thường Gặp Trong Phát Triển Phần Mềm [4] 31

3.1 Khó khăn mức Khởi Đầu 32

3.2 Khó khăn mức Lặp Lại 34

3.3 Khó khăn mức Xác Định 36

3.4 Khó khăn mức Quản Lý 37

3.5 Khó khăn mức Tối Ưu Hóa 39

CHƯƠNG 3 42

NĂM MỨC ĐỘ TĂNG TRƯỞNG CỦA CMM 42

1 MỨC 1: KHỞI ĐẦU 42

1.1 Hiểu mức tăng trưởng khởi đầu 1: 42

1.2 Thuộc tính của tổ chức mức 1 43

2 MỨC 2: LẶP LẠI ĐƯỢC 43

2.1 Hiểu mức tăng trưởng lặp lại 2 44

2.2 Các KPA cho mức lặp lại 2 45

3 MỨC 3: ĐƯỢC XÁC ĐỊNH 56

3.1 Hiểu mức độ tăng trưởng được xác định 3 57

4 MỨC 4: ĐƯỢC QUẢN LÝ 68

4.1 Hiểu mức tăng trưởng được quản lí 4 69

4.2 KPA cho mức được quản lí 4 69

5 MỨC 5: TỐI ƯU 72

5.1 Hiểu Mức Tăng Trưởng Tối Ưu 5 73

5.2 KPA cho mức tối ưu 5 74

CHƯƠNG 4 80

THỰC TIỄN VÀ ỨNG DỤNG Ở VIỆT NAM 80

1 Hiện trạng ứng dụng CMM ở Việt Nam 80

1.1 Các số liệu thống kê 80

1.2 Kinh nghiệm một số công ty đã đạt CMM 80

2 Một số giải pháp với CMM 86

2.1 Giải pháp kiểm định chất lƣợng thực chất mức độ CMM5 86

2.2 Giải pháp ứng dụng CMM hiệu quả 91

KẾT LUẬN 94

TÀI LIỆU THAM KHẢO 96

DANH MỤC HÌNH VẼ

Hình 1 1 Quy trình phát triển phần mềm 9

Hình 1 2 : Mô hình Waterfall 10

Hình 1 3 : V-model 13

Hình 1 4 : Mô hình Prototype 14

Hình 1 5: Mô hình tiến hóa 16

Hình 1 6: Mô hình phát triển 17

Hình 2 1 : Tỷ lệ dự án thành công 21

Hình 2 2 : Cấu trúc của CMM 25

Hình 2 3 : Cải thiện hiệu quả loại bỏ lỗi……… 26

Hình 2.4 : Phân loại 18 KPA của CMM theo mức tăng trưởng……… 29

Hình 2.5 : Cấu trúc của KPAs……….30

Hình 3 1 : Mức khởi đầu 42

Hình 3 2 : Mô tả mức khởi đầu 43

Hình 3 3 : Mức lặp lại được 44

Hình 3 4 : Mô tả mức lặp lại được 45

Hình 3 5 : Mức được xác định 57

Hình 3 6 : Mô tả mức được xác định 58

Hình 4 1 : Vòng đời dự án CMM 84

LỜI MỞ ĐẦU

Từ những năm 70 của thế kỷ 20 đến nay, trải qua hơn 3 thập kỷ nghiên cứu và phát triển phần mềm trên thế giới và ở Việt Nam, năng suất và chất lượng trong các hoạt động sản xuất phần mềm luôn là vấn đề quan tâm hàng đầu của những nhà nghiên cứu, những nhà sản xuất phần mềm và những người sử dụng các sản phẩm phần mềm Đã có nhiều phương pháp luận và công nghệ mới về sản xuất phần mềm được áp dụng nhưng không đáp ứng được nhu cầu của nền công nghiệp phần mềm:

Cơ sở nào để có được những sản phẩm phần mềm chất lượng cao và năng suất sản xuất ổn định Nền công nghiệp phần mềm và các tổ chức về phần mềm đã nhận ra

rằng vấn đề cơ bản nằm ở khả năng quản lý qui trình phần mềm Mô hình khả

năng trưởng thành cho phần mềm (Capability Maturity Model for Software– CMM) do Viện Công Nghệ Phần Mềm SEI (Software Engineering Institute – SEI) đưa ra vào đầu những năm 1990 đã được thừa nhận là hiệu quả và được áp dụng rộng rãi trong các hoạt động quản lý qui trình phần mềm trên thế giới Tuy nhiên việc áp dụng ở Việt Nam vẫn còn ít vì những yếu tố sau:

SW Tính chất và quy mô sản xuất phần mềm của các công ty còn nhỏ lẻ

- Khả năng quản lý nói chung và quản lý qui trình phần mềm nói riêng ở Việt Nam còn yếu

- Kinh nghiệm và hiểu biết về áp dụng SW-CMM vào thực tế hạn chế

Nhằm góp phần đẩy mạnh việc áp dụng SW-CMM vào thực tế, luận văn có mục đích trình bày tổng quan các mô hình phát triển phần mềm nói chung; những khó khăn thường gặp trong các hoạt động sản xuất phần mềm; năm mức phát triển khả năng cùng những thực hành then chốt (Key Practices) của SW-CMM nhằm giải quyết những khó khăn đó và đồng thời đưa ra một số đánh giá, kinh nghiệm áp dụng CMM thực tiễn tại một số công ty phần mềm Việt Nam Nội dung của luận văn bao gồm:

Chương 1: Tổng quan về các mô hình phát triển phần mềm

Chương đầu tiên của luận văn giới thiệu tổng quan về các mô hình phát triển phần mềm đã và đang được áp dụng trên thế giới Từ đó có cái nhìn tổng thể và đăc thù hơn về tính chất của mô hình CMM đang nghiên cứu Cụ thể hơn, chương 1 còn giới thiệu các vòng đời phần mềm quen thuộc như:

 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)

Chương 2: Giới thiệu về CMM và các khó khăn trong việc phát triển phần mềm

Từ chương một giới thiệu tổng thể các mô hình phát triển phần mềm, chương hai

đi sâu hơn về mô hình CMM

Trình bày về lịch sử mô hình trưởng thành khả năng CMM, qui trình phần mềm

và SW-CMM là gì.Về năm mức khó khăn thường gặp trong các hoạt động sản xuất phần mềm mà tương ứng với chúng là năm mức phát triển qui trình phần mềm của các tổ chức phần mềm theo SW-CMM

Năm mức trưởng thành khả năng theo mô hình SW-CMM bao gồm đặc tính, ý nghĩa của các bậc trưởng thành Giới thiệu cấu trúc của mỗi bậc trưởng thành: các lĩnh vực qui trình then chốt, các đặc điểm chung, các thực hành then chốt

Chương 3: Tính chất và các quy trình chủ chốt của các mức tăng trưởng của

mô hình CMM

Chương này trình bày chi tiết về đặc điểm, tính chất của 18 quy trình then chốt (xương sống của mô hình CMM) tương ứng 5 mức độ tăng trưởng và các hành động cần thiết để khi tuân thủ, tổ chức có thể chuyển lên một mức trưởng thành cao hơn

Chương 4: Thực tiễn và ứng dụng CMM tại Việt Nam

Chương này trình bày về thực trạng ứng dụng SW-CMM vào thực tế tại Việt Nam Một số kinh nghiệm và đánh giá cùng các giải pháp để có thể áp dụng CMM một cách hiệu quả hơn

Em xin chân thành cảm ơn các thầy cô giảng dạy tại Đại học Công nghệ- Đại học Quốc gia Hà Nội đã tạo điều kiện và giúp đỡ em trong suốt quá trình học tập

Xin gửi lời biết ơn về sự giúp đỡ, động viên nhiệt tình của gia đình và bạn bè trong quá trình học tập và làm luận văn

Hà Nội, ngày 28 tháng 12 năm 2005

Học viên

Đỗ Việt Hùng

CHƯƠNG I

TỔNG QUAN CÁC MÔ HÌNH PHÁT TRIỂN PHẦN MỀM

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

Trong chương này sẽ giới thiệu một cách tổng quát các mô hình áp dụng 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 [11]

1 Khái niệm quy trình

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:

Hình 1 1 Quy trình phát triển phần mềm

 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

Hình 1 2 : Mô hình Waterfall

2 SEP, ISO, CMM/CMMI

(CMM/CMMI-Capability Maturity Model/Integration- Mô hình trưởng thành khả năng)

Phần 2 này sẽ không đi sâu vào tìm hiểu các mô hình phát triển phần mềm mà chỉ cung cấp một cái nhìn tổng quát về chúng, cũng như mối quan hệ giữa SEP với ISO và CMM/CMMI để có thể mô tả kỹ hơn CMM ở chương sau Vấn đề được đặt ra là làm thế nào cải tiến qui trình để cải thiện chất lượng và năng suất? Câu trả lời chính là qui trình khung (Process Framework - PF) PF sẽ chỉ ra những yêu cầu mà một qui trình phải đáp ứng tùy theo mỗi mức độ PF không chỉ ra bất kỳ một qui trình cụ thể nào mà chỉ đưa ra những yêu cầu ở mỗi mức độ trưởng thành khác nhau của qui trình phải đạt được Đây chính là những hướng dẫn cho các hoạt động cải tiến để nâng mức độ trưởng thành từ thấp lên cao

Có nhiều PF, nhưng phổ biến nhất là ISO và CMM (Capability Maturity Model) được các tổ chức thế giới công nhận ISO nhắm chung đến nhiều loại tổ chức cả sản xuất lẫn dịch vụ, trong khi CMM được dành riêng cho các tổ chức phát triển phần mềm Đối với phần mềm, ISO chỉ ra mức độ chất lượng yêu cầu tối thiểu mà một SEP phải đạt (ISO certified) và việc cải tiến qui trình được thực hiện thông qua qui trình kiểm định, trong khi CMM bao gồm những thực tiễn tốt nhất (best practices) được tập hợp rút ra từ rất nhiều tổ chức phát triển phần mềm khác nhau và chúng được tổ chức thành 5 mức độ trưởng thành khác nhau (Level 1 - Initial, Level 2 - Repeatable, Level 3 - Defined, Level 4 - Managed, Level 5 - Optimizing) Ngày nay, phần mềm không đứng riêng một mình mà thường là một bộ phận trong

hệ thống hoàn chỉnh Do đó, CMMI (Capability Maturity Model Integration) ra đời hướng đến các qui trình cho việc xây dựng cả hệ thống, bao gồm cả việc tích hợp để xây dựng và bảo trì toàn bộ hệ thống

Sự khác nhau giữa ISO 9001 và CMM/CMMI:

• ISO 9001 là một tiêu chuẩn quốc tế về quản lý, các điều khoản gọi là "yêu cầu" quy định những điểm cần phải làm (what to do), không chỉ ra việc đó nên làm như thế nào (how to do)

• CMM/CMMI là một mô hình, cung cấp các hướng dẫn và kinh nghiệm thực tế dùng để phát triển, cải tiến và đánh giá năng lực của quy trình

• CMMI không phải là một tiêu chuẩn, tùy vào từng tổ chức, cách thực hiện khác

nhau rất nhiều

• Về nguyên tắc, ISO bao gồm (ở mức cao) hầu hết các quy trình chủ chốt của

CMM/CMMI, tuy nhiên ISO đƣợc dùng cho hầu hết mọi ngành nghề, do vậy không

cụ thể và gần gũi với công việc đặc thù có liên quan đến PM nhƣ CMM/CMMI ISO không cung cấp các ví dụ và kinh nghiệm cụ thể nhƣ CMM/CMMI

3 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)

Hình 1 3 : V-model 3.1 Mô hình Thác nước (Waterfall)

Mô hình này gồm các giai đoạn xử lý nối tiếp nhau như được mô tả trong Hình 1 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

3.2 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 1 4 : Mô hình Prototype

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

3.3 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õ

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 đó

3.4 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 1 5: Mô hình tiến hóa 3.5 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ỏ

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ình6)

 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 1 6: Mô hình phát triển 3.6 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

3.7 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

CHƯƠNG 2 CMM VÀ KHÓ KHĂN TRONG PHÁT TRIỂN PHẦN MỀM

1 Lịch Sử Mô Hình CMM [1]

Vào tháng 11 năm 1986, Viện Công Nghệ Phần Mềm SEI, với sự giúp đỡ của công ty Mitre, đã bắt đầu phát triển một khung việc về sự trưởng thành của qui trình cho phép giúp đỡ các tổ chức cải tiến qui trình phần mềm của họ Nỗ lực này nhằm đáp ứng yêu cầu cung cấp một phương pháp đánh giá khả năng của các nhà cung cấp phần mềm Vào tháng11 năm 1987, SEI phát hành một mô tả ngắn gọn về khung trưởng thành của qui trình và một bảng câu hỏi về sự trưởng thành SEI dự định rằng bảng câu hỏi sẽ là một công cụ đơn giản để nhận ra các vùng mà qui trình phần mềm của một tổ chức cần cải tiến Thật không may, bảng câu hỏi về sự trưởng thành này quá thiên về một “mô hình” hơn là một phương tiện khảo sát các vấn đề về sự trưởng thành của qui trình

Sau 4 năm trải nghiệm với khung trưởng thành qui trình phần mềm và phiên bản đầu tiên về bảng câu hỏi trưởng thành, SEI phát triển khung trưởng thành qui trình

phần mềm thành Mô Hình Trưởng Thành Khả Năng Cho Phần Mềm (SW SoftWare Capability Maturity Model) SW-CMM dựa trên kiến thức tích luỹ từ

CMM-đánh giá các qui trình phần mềm và các phản hồi rộng rãi từ phía nền công nghiệp

và chính phủ Bằng cách làm chi tiết khung trưởng thành, một mô hình đã xuất hiện

và cung cấp cho các tổ chức một hướng dẫn hiệu quả để thiết lập các chương trình cải tiến qui trình theo nhiều giai đoạn

Cấu trúc theo từng giai đoạn của SW-CMM dựa trên các nguyên tắc về chất lượng sản phẩm đã tồn tại từ những năm 30 của thế kỷ 20 Vào những năm 30 của thê kỷ 20, Walter Shewart đã công bố các nguyên tắc quản lý chất lượng dựa trên thống kê Các nguyên tắc của ông sau đó được phát triển tiếp và được áp dụng một cách thành công trong công việc của W Edwards Deming và Joseph Juran Các nguyên tắc này đã được biến đổi cho phù hợp bởi SEI thành một khung việc trưởng thành - thiết lập nền tảng công nghệ và quản lý dự án để kiểm soát có định lượng qui trình phần mềm, là cơ sở để liên tục cải tiến qui trình

Khung việc trưởng thành mà các nguyên tắc chất lượng đã được biến đổi cho phù hợp lần đầu tiên được tạo ra là bởi Philip Crosby trong cuốn sách "Quality is Free" Lưới trưởng thành quản lý chất lượng của Crosby mô tả năm giai đoạn phát triển của các thực tiễn chất lượng Khung việc trưởng thành này đã được biến đổi cho phù hợp với qui trình phần mềm bởi Ron Radice và các đồng nghiệp của anh, làm việc dưới sự chỉ đạo của Watts Humphrey tại IBM Humphrey đã đưa ý tưởng khung việc trưởng thành này về Software Engineering Institue vào năm 1986, thêm vào khái niệm các mức trưởng thành, và đã phát triển nền tảng đang được sử dụng trong nền công nghiệp phần mềm hiện nay

Phiên bản đầu tiên của SW-CMM, 1.0, đã được đánh giá và sử dụng bởi cộng đồng phần mềm trong khoảng 1991 và 1992 Một hội thảo đã được tổ chức vào tháng tư năm 1992 về SW-CMM v1.0, hội thảo này có khoảng 200 chuyên gia phần mềm tham dự Phiên bản sau của SW-CMM, v1.1 là kết quả từ những phản hồi trong hội thảo đó và những phản hồi tiếp theo trong cộng đồng phần mềm

SW-CMM là nền tảng cho việc xây dựng một cách có hệ thống một bộ công cụ, bao gồm cả một bảng câu hỏi về sự trưởng thành – hữu ích trong cải tiến qui trình phần mềm Điểm cơ bản cần nhớ là mô hình này là cơ sở để cải tiến qui trình phần mềm

2 Tổng quan về mô hình CMM

Qui trình phần mềm là một bộ các công cụ, phương pháp và các kinh nghiệm thực tiễn mà chúng ta sử dụng để sản xuất ra một sản phẩm phần mềm Các mục tiêu của quản lý qui trình phần mềm là sản xuất ra các sản phần mềm theo kế hoạch trong khi đó đồng thời cải tiến khả năng của tổ chức để sản xuất phần mềm tốt hơn Sau hai thập kỷ không thực hiện được những lời hứa tăng năng suất và chất lượng nếu áp dụng các phương pháp luận và công nghệ mới, các tổ chức phần mềm

đã nhận ra rằng vấn đề cơ bản của họ là thiếu khả năng quản lý qui trình phần mềm Lợi ích của các công cụ và phương pháp tốt hơn không thể đạt được từ vũng nước xoáy của một dự án hỗn độn, không có kỷ luật Ở nhiều tổ chức, các dự án thường

là quá chậm và thực chi thường gấp đôi so với dự kiến

Hình 2 1 : Tỷ lệ dự án thành công

Trong những trường hợp như vậy, tổ chức thường không cung cấp đầy đủ cơ sở

hạ tầng và hỗ trợ cần thiết để giúp cho các dự án tránh các vấn đề này

Mặc dù các kỹ sư phần mềm và các nhà quản lý phần mềm thường biết rõ vấn đề của họ rất chi tiết, họ có thể không đồng ý rằng cải tiến là quan trọng nhất Nếu không có một chiến lược cải tiến có tổ chức, sẽ khó mà đạt được sự đồng lòng giữa đội ngũ quản lý và các chuyên gia về các hoạt động cải tiến nào sẽ được thực hiện trước Để đạt được các kết quả kéo dài từ các công sức cải tiến qui trình, điều cần thiết là thiết kế một con đường phát triển để tăng sự trưởng thành qui trình phần mềm của tổ chức theo các giai đoạn Khung việc về sự trưởng thành qui trình phần mềm chỉ dẫn các giai đoạn này nhờ đó các cải tiến tại mỗi giai đoạn cung cấp nền tảng từ đó xây dựng các cải tiến cho giai đoạn tiếp theo Vì vậy một chiến lược cải tiến rút ra từ một khung việc về sự trưởng thành qui trình phần mềm cung câp một bản đồ chỉ đường để liên tục cải tiến qui trình Nó hướng dẫn sự tiến bộ và xác định các thiếu hụt trong tổ chức; nó không có ý định cung cấp một sự sửa chữa nhanh cho các dự án đang có trục trặc

Khi đưa một chương trình cải tiến qui trình vào thực hiện, đầu tiên chúng ta nên xem xét đặc tính của một qui trình phần mềm thực sự hiệu quả Một cách cơ bản, nó phải dự đoán được Nghĩa là, các ước tính chi phí và các cam kết thời hạn phải đúng với tính chắc chắn hợp lý, và các sản phẩm kết quả nói chung phải đáp ứng nhu cầu các mong đợi về chức năng và chất lượng của người sử dụng

Các nguyên tắc cơ bản là những nguyên tắc về kiểm soát qui trình theo thống kê, những nguyên tắc này đã được áp dụng thành công trong nhiều lĩnh vực khác Một qui trình được gọi là ổn định hoặc kiểm soát được về mặt thống kê nếu hiệu suất trong tương lai của nó là dự đoán được trong các giới hạn thống kê được thiết lập Khi một qui trình là kiểm soát được về mặt thống kê, việc lặp lại công việc theo cùng một cách gần giống nhau sẽ sản xuất ra kết quả gần giống nhau Để có được các kết quả tốt hơn ổn định cần cải tiến qui trình Nếu một qui trình là không kiểm soát được về mặt thống kê, sự tiến triển được duy trì liên tục là không thể đến khi nào ta kiểm soát được về mặt thống kê

Tiến sĩ W E Deming, trong công việc của ông với người Nhật sau thế chiến thứ

II, đã áp dụng các khái niệm của việc kiểm soát qui trình theo thống kê vào nhiều ngành công nghiệp của họ Trong khi có những khác biệt quan trọng, những khái niệm này là có thể áp dụng được vào phần mềm cũng như chúng đã được áp dụng

để sản xuất các hàng hoá tiêu dùng như là máy ảnh, ti vi, hoặc xe máy

Nguyên lý cơ bản đằng sau kiểm soát theo thống kê là đo đạc Như ngài Kelvin

đã nói một thế kỷ trước: “Khi bạn có thể đo đạc bạn đang nói về cái gì, và diễn tả chúng bằng những con số, nghĩa là bạn biết điều gì về nó; nhưng khi bạn không thể

đo đạc nó, khi bạn không thể diễn tả chúng bằng những con số, thì kiến thức của bạn là thuộc loại nghèo nàn và không tốt đẹp; có thể là sự bắt đầu của kiến thức, nhưng bạn có hầu như không trong những suy nghĩ tiến tới giai đoạn của khoa học.”

Có nhiều nhân tố để xem xét khi đo đạc qui trình lập trình Đầu tiên, một người không thể bắt đầu sử dụng ngay các con số để kiểm soát mọi việc Các con số phải diễn đạt qui trình được kiểm soát một cách thích hợp, và chúng phải được định nghĩa và kiểm chứng đủ tốt để cung cấp một cơ sở tin cậy cho các hành động Trong khi đo đạc là cơ bản để cải tiến theo từng bước, việc lập kế hoạch và chuẩn bị cẩn thận là bắt buộc nếu không các kết quả sẽ có thể là thất vọng

Điểm thứ hai cũng quan trọng ngang như thế Chỉ hành động đo đạc các qui trình của con người thay đổi chúng Từ khi các nỗi sợ hãi và động cơ của mọi người dính vào, các kết quả phải được xem trong một sự soi sáng khác từ dữ liệu trên các hiện tượng tự nhiên Vì vậy cơ bản là hạn chế các sự đo đạc trên những cái gì có mục đích sử dụng được định nghĩa trước Các sự đo đạc có thể là vừa đắt vừa đập gãy;

đo đạc quá hăng hái có thể làm giảm giá trị của qui trình chúng ta đang cố gắng cải thiện

Tuy nhiên thậm chí trong những tổ chức không có kỷ luật, vài dự án phần mềm đơn lẻ lại cho ra những kết quả tuyệt vời Khi những dự án như vậy thành công, đó thường là thành công nhờ công sức lớn của đội phát triển chứ không phải là nhờ sự lặp lại của những phương pháp đã được thử thách của một tổ chức có qui trình phần mềm thành thục Khi không có một qui trình phần mềm trên toàn tổ chức, việc lặp lại các kết quả tốt như ở một dự án phụ thuộc hoàn toàn vào việc có cùng những cá nhân của dự án trước trong dự án tiếp theo Thành công mà hoàn toàn phụ thuộc vào sự hiện diện của một số cá nhân riêng lẻ không thể tạo thành cơ sở để duy trì

và cải tiến chất lượng và năng suất lâu dài trên toàn tổ chức Các cải tiến liên tục chỉ

có thể xảy ra nhờ công sức bền bỉ và tập trung vào xây dựng một cơ sở hạ tầng qui trình bao gồm mô hình vòng đời sản phẩm hiệu quả, phương pháp luận cho các giai đoạn phát triển hiệu quả và các thực tiễn quản lý

Bước đầu tiên để giải quyết các vấn đề phần mềm là phải coi toàn bộ công việc phần mềm như là một qui trình có thể kiểm soát được, đo đạc được và cải tiến được

Vì mục đích này chúng ta có thể định nghĩa một qui trình là một tập các nhiệm vụ

mà, khi được thực hiện một cách chính xác, sẽ sinh ra kết quả mong đợi Một cách

rõ ràng, một qui trình phần mềm hoàn toàn hiệu quả phải xem xét quan hệ của tất cả các nhiệm vụ phải làm, các công cụ và các phương pháp được sử dụng, và kỹ năng, việc đào tạo, và động cơ của những người tham gia

Để cải tiến khả năng phần mềm của mình, các tổ chức phải thực hiện sáu bước:

1 Hiểu tình trạng hiện thời của qui trình hoặc các qui trình phát triển của mình

2 Phát triển một tầm nhìn về qui trình mong muốn

3 Thiết lập một danh sách các hành động cải tiến qui trình cần thiết theo thứ

tự ưu tiên

4 Lập một kế hoạch để thực hiện các hành động cần thiết

5 Dành tài nguyên để thực hiện kế hoạch

6 Bắt đầu lại tại bước một

Để cải tiến một tổ chức, sẽ là có ích nếu có một bức tranh rõ ràng về mục đích cuối cùng và cách nào đó để đo tiến triển trên con đường phát triển CMM là một khung việc được sử dụng cho mục đích này, nó gần song song với cấu trúc trưởng thành chất lượng được định nghĩa bởi Crosby Nó giải quyết sáu bước cải tiến bằng việc đặc tính hoá qui trình phần mềm vào mỗi trong năm mức độ trưởng thành Bằng cách thiết lập vị trí của tổ chức trong cấu trúc trưởng thành, các chuyên gia phần mềm và các nhà quản lý của họ có thể sẵn sàng hơn xác định những khu vực

mà các hành động cải tiến là có lợi nhất

2.1 Định nghĩa về CMM

“CMM là khuôn khổ mô tả các phần tử chủ chốt của quy trình phần mềm hiệu quả mà khi được tuân theo sẽ làm cải tiến khả năng của tổ chức để đáp ứng các mục đích về chi phí, lịch biểu, chức năng và chất lượng sản phẩm”

CMM do viện kỹ nghệ phần mềm SEI liên kết với đại học Carnegie Mellon phát triển

Nó mô hình hóa cho:

- Các trạng thái mà các tổ chức phần mềm tiến hoá khi họ xác định, thực hiện,

đo, kiểm soát, và cải tiến các qui trình phần mềm của mình

+ Kĩ nghệ hay kĩ thuật

+ Tổ chức

- KPA được tổ chức theo 5 “tính năng chung” (thuộc tính) có chứa những

“thực hành chốt” , thiết lập ra chính sách, thủ tục và hoạt động cho từng KPA

Hình 2 2 : Cấu trúc của CMM 2.2 Ích lợi của cải tiến theo mô hình CMM

- Thiết lập ra một ngôn ngữ chung

- Tiến tới một tầm nhìn chung giữa các dự án phần mềm

- Xây dựng trên một tập các qui trình (các khối xây dựng) và các thực hành được phát triển với cái vào từ một phạm vi lựa chọn rộng những người phát triển phần mềm

- Cung cấp một khuôn khổ cho việc ưu tiên hoá (cải tiến qui trình) các hành động và cho việc thực hiện đánh giá tin cậy và nhất quán

- Hỗ trợ cho việc so sánh ở mức cả ngành công nghiệp