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

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

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

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

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

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

Hình 2.3 : Cải thiện hiệu quả loại bỏ lỗi

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

Mức độ tăng trưởng là bình diện tiến hoá được xác định rõ hướng tới việc đạt tới qui trình phần mềm tăng trưởng

Mỗi mức độ tăng trưởng cung cấp một tầng trong nền tảng cho sự cải tiến liên tục

Năm mức độ (bậc) trưởng thành của qui trình CMM sẽ được thảo luận nhiều hơn trong phần sau của luận văn này Chúng có những đặc tính chung sau:

1 Khởi đầu: Cho đến khi qui trình được kiểm soát theo thống kê, sự tiến triển theo thứ tự trong cải tiến qui trình là không thể Trong khi có nhiều

mức độ kiểm soát theo thống kê, bước đầu tiên là phải đạt được khả năng

dự đoán sơ bộ về lịch biểu và chi phí

thể lặp lại việc kiểm soát theo thống kê bằng cách bắt đầu quản trị dự án

chặt chẽ về các cam kết, các chi phí, các lịch biểu và các thay đổi

3 Đã được xác định: Tổ chức đã định nghĩa qui trình như là một cơ sở cho việc nhất quán thực thi và việc nhận thức được ý nghĩa tốt hơn Tại điểm

này công nghệ tiên tiến có thể được giới thiệu một cách có ích

trình tổng hợp Đó là khi những cải tiến chất lượng quan trọng nhất bắt

đầu

qui trình

Mức 1:Khởi đầu

- Những thực hành và kết quả phát triển ứng dụng là không nhất quán

- Các tiến trình phát triển hiếm khi được xác định,và việc thực hành tốt thường bị hi sinh để đáp ứng cho các lịch biểu không hợp lí

- Việc quản lí dự án kém và không bảo vệ người phát triển khỏi bị ngắt quãng bởi những cam kết không hợp lí haynhững thay đổi quá đáng

- Về bản chất, tổ chức phát triển ứng dụng ở Mức1 thiếu năng lực đáp ứng những cam kết một cách nhất quán

Mức 4: Được quản lí theo định lượng

- Tổ chức phát triển ứng dụng có thể phát triển tuyến cơ sở năng lực thống

kê đặc trưng cho kết quả trong đợi từ việc thực hiện các thủ tục này

- Hiểu biết sâu sắc, định lượng về năng lực của tiến trình phát triển và nguyên nhân của những biến thiên trong hiệu năng của họ

- Bằng việc quản lí hiệu năng của các tiến trình phát triển của mình một cáhc thống kê, tổ chức phát triển ứng dụng có thể dự đoán và kiểm soát kết quả của dự án dễ dàng hơn nhiều trong tiến trình dự án

- Quản lí định lượng cho phép làm mạnh tổ dự án lên nhiều lần và làm tăng tính dự đoán được về kết quả cho việc quản lí dự án

Mức 5: Tối ưu

- Tại mức chín chắn cao nhất,tổ chức phát triển ứng dụng liên tục đánh giá

về năng lực của các tiến trình của mình để chỉ ra các miền còn cần những cải tiến lớn nhất

- Những cải tiến liên tục có thể được phát triển theo cơ hội bằng việc triển khai các kết quả của bài học rút ra, hay chúng có thể được tạo ra một cách tiên phong bằng việc đánh giá các phương pháp phát triển mới,các tiến trình hay công nghệ mang tiềm năng chấp nhận được

- Tổ chức phát triển ứng dụng Mức5 thiết lập nên một kết cấu nền cho việc

hỗ trợ quản lí thay đổi liên tục xem như cấu phần tích hợp nền tảng của toàn thể tiến trình phát triển của nó

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

Phân loại 18 KPA của CMM theo mức tăng trưởng như sau:

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

Cấu trúc chung của các lĩnh vực quy trình chốt này có thể thấy trên hình sau:

Hình 2 5: Cấu trúc của KPAs

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

- Được đưa ra vào đầu những năm1990, từ Bộ quốc phòng Mĩ, CMM dần được các tổ chức phần mềm thế giới chấp nhận

- Được xem như phương tiện dẫn lái cho việc liên kết với khách hàng, quản

lí nhà cung cấp dịch vụ ngoài hay làm tăng kết quả năng suất

- Phần lớn người sử dụng cuối của CMM là các nhà cung cấp dịch vụ CNTT, người làm khoán ngoài

- Với người làm khoán ngoài, CMM có khả năng thiết lập nên sự tin cậy bằng việc đưa ra cách lập tỉ lệ mức chín chắn như một chỉ báo về năng lực phát triển ứng dụng

- Để đạt tới các năng lực tương đương với các nhà cung cấp dịch vụ,việc quản lí CNTT / phát triển ứng dụng bên thực hiện các chương trình cải tiến tiến trình nhằm tới cmm ít nhất ở mức 2

- Những năng lực này sẽ làm cho họ quản lí các dự án, kiểm soát yêu cầu và cấu hình, đảm bảo chất lượng và theo dõi tiến độ dự án

Vậy CMM là gì và không là gì?

- Người ta thường hiểu nhầm CMM là xác định ra phương pháp luận cho việc điều hành, gây vướng víu (tức là không cho phép đổi mới) Thực tế, CMM không xác định phương pháp luận nào cả

- CMM cung cấp các mục tiêu thiết lập nên nền tảng tiến trình cho các mức tăng trưởng dần

- Trong khi CMM hội tụ vào điều tổ chức nên làm, thì nó không xác định cách đạt tới những mục tiêu đó

- CMM cung cấp các hướng dẫn cho những nỗ lực cải tiến dài hạn và ngắn hạn Với các tổ phát triển hội tụ vào những miền đặc biệt, CMM nhận diện những thực hành tốt nhất và cung cấp hướng dẫn có ích về các hoạt động huấn luyện, đo đạc và kiểm chứng

- Việc thực hiện đúng vòng đời phát triển, như phát triển ứng dụng nhanh và lập trình cực đoan (XP), là nhất quán với các nền tảng tại trung tâm của CMM

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

Tại sao lại có kĩ nghệ phần mềm? Như chúng ta đã biết trước đây phần mềm do một số nhỏ người viết, trong vòng vài tháng Nhưng đến những hệ phần mềm lớn như hệ DOS của IBM hay hệ mềm dùng cho chương trình không gian của Mĩ, thì không phải vài người trong vài tháng nữa mà là hàng trăm người trong nhiều năm, trong mười năm Hệ mềm như chương trình điều khiển viễn thông thì một công ty quốc tế có thể có 3, 4 nhóm làm việc tại 3, 4 nước khác nhau, mỗi nhóm hai, ba trăm người Chương trình điều khiển tổng đài điện thoại hiện bán khắp nơi trên thế giới như vậy, nó được phát triển trong vòng 5 năm, bao gồm hàng chục nghìn đơn

vị người làm Số người tham gia phát triển đông tới vài trăm, thời gian phát triển lâu

và thời gian sử dụng sẽ lâu hơn Phần mềm không bao giờ giữ nguyên cả, bao giờ cũng thay đổi Nhu cầu của người sử dụng ngày càng tăng, điện tử ngày càng rẻ và ngày càng làm được nhiều chuyện Bởi vậy người ta thấy cần phải có phương pháp tương đối kỉ luật và nhất là cần có ngôn ngữ, quy trình chung để trao đổi Người

và quí Khi một người làm phần mềm thay đổi công việc thì sản phẩm họ để lại rất khó để người tiếp theo tiếp thu được Hay một người mới gia nhập vào dự án đang triển khai thì sẽ gặp khó khăn để thích nghi Thành ra phải có một ngôn ngữ, một

ngữ pháp chung, hay một quy trình chuẩn để làm sao sản phẩm độc lập với người

sản xuất và chúng ta có thể quản lý được quá trình làm phần mềm Có thể nói đó là một nguyên tắc tuyệt đối của kinh tế thị trường Sản phẩm và người sản xuất độc lập với nhau Làm việc tập thể vì không phải là chỉ làm việc năm hay mười người Người ta làm gì trong kĩ nghệ phần mềm? Người ta có một số phương pháp và những phương pháp đó hiện bây giờ đang trong quá trình chuẩn hoá Trong khuôn khổ luận văn này, chúng tôi chỉ xin được đề cập đến mô hình phát triển phần mềm với các quy trình đã được chuẩn hóa (CMM) chứ không đề cập đến ngôn ngữ chung

là UML

Theo Humphrey [4], những khó khăn thường gặp trong phát triển phần mềm có thể được chia thành 5 mức, tương ứng với 5 mức đó là 5 mức phát triển của mô hình CMM

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

Ban đầu các tổ chức có thể có qui trình tuỳ ý, không theo thể thức, và nó thường hỗn độn Tại giai đoạn này tổ chức thường hoạt động mà không có các thủ tục; các ước tính chi phí và các kế hoạch dự án một cách chính thức Các công cụ không được tích hợp tốt với qui trình và cũng không được áp dụng đồng bộ Quản lý thay đổi thì lỏng lẻo, và ít có chuyện quản lý cấp cao hiểu được các bài toán và các vấn

đề Vì nhiều vấn đề bị hoãn lại hoặc thậm chí bị bỏ quên, cài đặt phần mềm và bảo trì thường có nhiều vấn đề nghiêm trọng

Trong khi các tổ chức có thể có các thủ tục chính thức để lập kế hoạch và theo dõi công việc của họ, lại không có cơ chế quản lý để bảo đảm rằng chúng đã được

sử dụng Cách kiểm tra tốt nhất là quan sát những tổ chức như vậy xoay sở thế nào trong một cuộc khủng hoảng Nếu nó từ bỏ những thủ tục đã được thiết lập và về bản chất lại trở lại việc viết mã và kiểm thử, tổ chức đó có thể đang gặp những khó khăn ở mức khởi đầu Sau hết, nếu các kỹ thuật và phương pháp là thích hợp, khi đó chúng sẽ được dùng trong khủng hoảng; nếu chúng không thích hợp trong khủng hoảng, chúng sẽ không được dùng một chút nào

Một lý do mấu chốt tại sao các tổ chức cư xử theo cách thức này là họ không trải qua những lợi ích của một qui trình chín chắn và vì vậy không hiểu những hậu quả của các hành xử lộn xộn của họ Bởi vì nhiều hành động phần mềm hiệu quả (ví dụ thiết kế và soi mã hoặc phân tích dữ liệu kiểm thử) không có vẻ trực tiếp hỗ trợ việc tạo ra sản phẩm, chúng có vẻ như có thể bỏ đi được

Rất giống như lái một chiếc xe ô tô Vài người lái xe không một chút kinh nghiệm sẽ tiếp tục lái rất lâu khi đèn cảnh báo của động cơ sáng, bất kể sự vội vàng của họ Tương tự, hầu hết các lái xe bắt đầu một chuyến đi mới sẽ, bất kể sự vội vã của họ, dừng lại để xem bản đồ Họ đã học được sự khác nhau giữa tốc độ và sự tiến triển

Trong phần mềm, viết mã và kiểm thử có vẻ như là sự tiến tới, nhưng chúng thường chỉ là sự quay tròn của bánh xe Trong khi chúng phải được thực hiện, luôn luôn có những nguy hiểm nếu đi sai hướng Nếu không có một kế hoạch tốt và một phân tích kỹ càng các vấn đề, không có cách nào để biết

Các tổ chức gặp những khó khăn như vậy có qui trình ở mức khởi đầu trong mô hình CMM

Các tổ chức ở mức qui trình khởi đầu có thể cải tiến hiệu suất của họ bằng cách tiến hành các kiểm soát dự án cơ bản Quan trọng nhất là quản trị dự án, giám sát quản lý, bảo đảm chất lượng, và kiểm soát các thay đổi

Vai trò cơ bản của một hệ thống quản lý dự án là bảo đảm kiểm soát có hiệu quả các cam kết Điều này đòi hỏi sự chuẩn bị thích đáng, trách nhiệm rõ ràng, sự công

bố công khai và sự dành riêng (dedication) cho hiệu suất

Cho phần mềm, quản trị dự án bắt đầu bằng việc hiểu độ lớn của công việc Trong bất kỳ dự án nào ngoại trừ những cái đơn giản nhất, một kế hoạch phải được lập để quyết định lịch làm việc tốt nhất và các tài nguyên lường trước cần thiết Nếu thiếu một kế hoạch thứ tự như vậy, không có cam kết nào có thể tốt hơn một sự ước chừng được rèn luyện

Một tổ chức phát triển phần mềm có kỷ luật phù hợp phải có giám sát quản lý

cấp cao Điều này bao gồm xem xét lại và phê chuẩn tất cả các kế hoạch phát triển

chính trước khi cam kết thực hiện chính thức

Cũng như vậy, một sự xem lại hàng quý nên được dẫn dắt bao gồm sự làm đúng theo qui trình trong phạm vi toàn bộ các điều kiện (facility-wide), hiệu suất chất lượng đã được đặt, theo dõi lịch làm việc, các xu hướng chi phí, dịch vụ tính toán,

và mục tiêu năng suất và chất lượng theo dự án Thiếu những sự xem lại như vậy thường dẫn đến việc thực thi qui trình không đều và nói chung là không đủ cũng như là những sự cam kết quá đáng và những sự ngạc nhiên về chi phí cao

Một nhóm bảo đảm chất lượng có trách nhiệm bảo đảm việc quản lý công việc phần mềm được thực hiện theo cách mà nó được cho là phải được thực hiện Để có hiệu quả, tổ chức bảo đảm phải có một đường (line) báo cáo độc lập tới quản lý cấp cao và các tài nguyên đủ để giám sát hiệu suất của tất cả các hoạt động lập kế hoạch, thực thi và kiểm tra chủ chốt Nói chung điều này đòi hỏi ở một tổ chức khoảng 3 tới 6 phần trăm cỡ của tổ chức phần mềm

Kiểm soát thay đổi trong phần mềm là thiết yếu để mà kiểm soát được nghiệp vụ

và tài chính cũng như để nhắm tới sự ổn định về mặt kỹ thuật Để phát triển phần

mềm có chất lượng theo một lịch làm việc có thể dự đoán trước, các yêu cầu phải được củng cố và giữ với độ ổn định hợp lý trong suốt vòng phát triển Trong khi những thay đổi của các yêu cầu thường cần thiết, các bằng chứng lịch sử chứng minh rằng nhiều cái có thể bị hoãn lại và được kết hợp lại sau Những thay đổi về thiết kế và viết mã phải được thực hiện để sửa những vấn đề phát hiện trong phát triển và kiểm thử, nhưng những thay đổi này phải được đưa vào một cách cẩn thận Nếu các thay đổi không được kiểm soát, khi đó theo thứ tự thiết kế, thực thi, và kiểm thử là không thể và không kế hoạch chất lượng nào lại có thể hiệu quả được

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

Vượt qua các khó khăn mức trên, qui trình của tổ chức có một sức mạnh quan trọng mà trước đó nó không có: Nó cung cấp sự kiểm soát toàn bộ cách thức tổ chức thiết lập các kế hoạch và cam kết của nó Sự kiểm soát này cung cấp một sự cải tiến hơn so với trước ở chỗ con người trong tổ chức có xu hướng đã hiểu rõ vấn đề của phần mềm Họ đã đạt được một mức độ kiểm soát theo thống kê qua việc học để thực hiện và đạt được các kế hoạch và ước tính Sức mạnh này, tuy nhiên, có nguồn gốc từ kinh nghiệm trước của họ khi làm những công việc giống nhau Các tổ chức

ở mức có qui trình có thể lặp lại được vì vậy đối mặt với các rủi ro nguy hiểm khi

họ gặp phải các thách thức mới

Ví dụ các cơ hội có thể dẫn đển rủi ro cao ở mức độ này là:

 Nếu không được đưa ra với sự cẩn thận lớn, các công cụ mới và phương pháp mới sẽ ảnh hưởng đến qui trình, vì vậy phá huỷ sự thích hợp của các nền tảng mang tính lịch sử trực quan mà tổ chức dựa vào Nếu không có một khung làm việc về qui trình đã được định nghĩa ở đó để xử lý các rủi

ro này, một công nghệ mới có thể thậm chí sẽ gây hại hơn là làm lợi

 Khi tổ chức phải phát triển một loại sản phẩm mới, qui trình sẽ đi vào phạm vi mới Ví dụ, một nhóm phần mềm có kinh nghiệm phát triển các bộ dịch (compilers) sẽ có thể có các vấn đề về thiết kế, lập lịch, và ước tính khi được giao nhiệm vụ viết một chương trình điều khiển thời gian thực Tương tự một nhóm đã phát triển các chương trình nhỏ sẽ không hiểu các vấn đề giao diện và tích hợp dính líu trong các dự án qui mô lớn Những thay đổi này một lần nữa phá huỷ sự thích hợp của các nền tảng mang tính

lịch sử trực quan của qui trình của tổ chức

 Các thay đổi mang tính tổ chức quan trọng cũng có thể phá vỡ ở mức độ cao ở mức qui trình có thể lặp lại, một người quản lý mới không có tài liệu

để hiểu các hoạt động của tổ chức, và những thành viên một đội mới phải

học các tình hình điều kiện qua các lời nói miệng

Các hoạt động chủ chốt để tiến lên bậc tiếp theo, qui trình được định nghĩa, là thiết lập một đội qui trình, thiết lập một kiến trúc qui trình phát triển, và đưa ra một loạt các phương pháp kỹ nghệ phần mềm và kỹ thuật

Thiết lập một nhóm qui trình Một nhóm qui trình là một tài nguyên kỹ thuật tập

trung riêng biệt vào việc cải tiến qui trình phần mềm Trong các tổ chức phần mềm tại các mức độ trưởng thành trước, tất cả mọi người được dành cho công việc phát triển sản phẩm Cho đến khi một vài người được giao nhiệm vụ làm cả ngày trên qui trình, một chút tiến bộ theo thứ tự có thể được thực hiện để cải tiến qui trình Các trách nhiệm của các nhóm qui trình bao gồm định nghĩa qui trình phát triển, xác định các nhu cầu kỹ thuật và các cơ hội, góp ý các dự án, và dẫn dắt các buổi xem lại việc quản lý hàng quí về tình trạng của qui trình và hiệu suất của qui trình Trong khi không có dữ liệu nào được công bố tại điểm này, kinh nghiệm chỉ ra rằng nhóm qui trình nên chiếm khoảng 1 đến 3 phần trăm cỡ của một tổ chức phần mềm

hiệu quả hoàn toàn Các tổ chức nhỏ thiếu nền tảng kinh nghiệm để thành lập một nhóm qui trình nên xử lý những vấn đề này bằng cách sử dụng các uỷ ban đã được thiết lập một cách đặc biệt bao gồm các chuyên gia có kinh nghiệm hay bằng cách thuê các nhà tư vấn

Câu hỏi thường gặp liên quan đến trách nhiệm tương đối của các nhóm qui trình

và bảo đảm chất lượng Điều này được thảo luận chi tiết ở các phần sau, nhóm bảo đảm chất lượng tập trung vào việc áp dụng qui trình hiện tại, trong khi đó nhóm qui trình lại được hướng dẫn để cải tiến qui trình Có nghĩa là, chúng hầu như đối nghịch: bảo đảm bao gồm kiểm tra và sự tuân theo, và nhóm qui trình xử lý việc hỗ trợ và thay đổi

Thiết lập một kiến trúc qui trình phát triển phần mềm, hoặc vòng đời phát triển,

mà mô tả các hoạt động quản lý và kỹ thuật để chạy đúng qui trình phát triển Qui

trình này phải được làm cho hoà hợp với các nhu cầu cụ thể của tổ chức, và nó sẽ biến đổi theo kích cỡ và tầm quan trọng của dự án cũng như tự thân bản chất kỹ thuật của công việc Kiến trúc này là sự phân rã cấu trúc của vòng phát triển thành những nhiệm vụ, mỗi nhiệm vụ có một bộ được định nghĩa các điều kiện tiên quyết, các mô tả chức năng, các thủ tục thẩm tra, và các đặc tả sự hoàn thành nhiệm vụ Sự phân rã tiếp tục đến khi mỗi nhiệm vụ đã được định nghĩa được thực hiện bởi một

cá nhân hay một đơn vị quản lý đơn

Nếu chúng đã sẵn sàng, đưa ra một loạt các phương pháp kỹ nghệ phần mềm và

kỹ thuật Chúng bao gồm các soi mã và thiết kế, các phương pháp thiết kế chính thức, các hệ thống điều khiển thư viện, và các phương pháp kiểm thử tổng hợp Việc làm bản mẫu cũng nên được xem xét, cùng với sự chấp nhận của các ngôn ngữ lập trình hiện đại

của qui trình như thế nào Có những tranh cãi đáng kể về giá trị của các sự đo đạc qui trình phần mềm và những cái tốt nhất để sử dụng Điều không chắc chắn này nói chung xuất phát từ một sự thiếu định nghĩa qui trình và sự rối rắm mang tính kết quả về những mục cụ thể nào được đo đạc Với Qui trình mức này, chúng ta có thể tập trung vào sự đo đạc các nhiệm vụ cụ thể Kiến trúc qui trình vì vậy là điều kiện tiên quyết để đo đạc hiệu quả

Những bước mấu chốt để vượt qua các khó khăn này là:

1 Thiết lập một bộ cơ bản tối thiểu các phép đo qui trình để xác định các tham số chi phí và chất lượng của mỗi bước của qui trình Mục tiêu là định lượng các chi phí tương đối và các lợi ích của mỗi hoạt động qui trình chính, ví dụ như là chi phí và hiệu suất phát hiện lỗi và các phương pháp sửa sai

2 Thiết lập một cơ sở dữ liệu qui trình và tài nguyên để quản lý và bảo trì nó

Dữ liệu hiệu suất và chi phí nên được bảo trì tập trung để đảm bảo không bị mất, để nó luôn sẵn có cho tất cả các dự án, và để làm dễ dàng chất lượng qui trình và phân tích năng suất

3 Cung cấp đủ tài nguyên qui trình để thu thập và bảo trì dữ liệu qui trình và góp ý kiến cho các thành viên dự án sử dụng nó Giao nhiệm vụ cho các chuyên gia có kinh nghiệm giám sát chất lượng của dữ liệu trước khi đưa

và cơ sở dữ liệu và cung cấp các hướng dẫn về các phương pháp phân tích

và giải thích

4 Đánh giá chất lượng tương đối của mỗi sản phẩm và thông báo quản lý ở những nơi mà các mục tiêu chất lượng không đạt được Một nhóm bảo đảm chất lượng độc lập nên đánh giá các hành động của mỗi dự án và theo dõi tiến triển của nó theo kế hoạch chất lượng của nó Khi sự tiến triển này được so sánh với các kinh nghiệm lịch sử trong các dự án tương tự, một sự đánh giá am hiểu nói chung có thể được thực hiện

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

Tiến thêm một mức mới qua các khó khăn mức 3, các tổ chức phần mềm nên mong đợi để thực hiện các cải tiến chất lượng đáng kể Vấn để tiềm ẩn lớn nhất ở

cách tiềm tàng về qui trình phần mềm, nhưng dữ liệu như vậy là đắt khi thu thập và bảo trì

Do đó, cần thu thập dữ liệu với sự thận trọng và định nghĩa một cách chính xác mỗi mẩu dữ liệu trước Dữ liệu về năng suất về cơ bản là vô nghĩa nếu không được định nghĩa một cách tường minh Ví dụ, đo đạc cơ bản số dòng mã mỗi tháng phát triển có thể biến đổi 100 lần hoặc hơn, phụ thuộc vào sự hiểu các tham số Sự đếm

mã có thể bao gồm chỉ một vài mã mới hay mã bị sửa hoặc có thể là tất cả các dòng lệnh được chuyển đi Đối với các chương trình được sửa đổi, điều này có thể dẫn đến mức độ thay đổi của một thừa số là 10 Tương tự, các dòng không trống không phải chú thích, các chỉ thị chạy hoặc các chỉ thị hợp ngữ tương đương có thể được đếm với mức độ thay đổi lên tới 7 lần Nhân viên quản lý, kiểm thử, làm tài liệu, và

hỗ trợ có thể hoặc không được tính khi tính tháng làm việc đã tiêu Một lần nữa, mức độ biến đổi có thể ít nhất cao như một thừa số của 7

Khi nhiều nhóm khác nhau thu thập dữ liệu nhưng không dùng các định nghĩa giống nhau, các kết quả sẽ không thể so sánh với nhau được, thậm chí là có nghĩa

để so sánh chúng Khuynh hướng với những dữ liệu này là sử dụng chúng để so sánh nhiều nhóm và để phê bình chúng với những thứ hạng thấp nhất Đây là một

sự sử dụng sai đáng tiếc với dữ liệu qui trình Hiếm khi hai dự án được so sánh bởi bất kỳ một phép đo đơn giản nào Sự khác nhau trong độ phức tạp của công việc gây ra bởi các loại sản phẩm khác nhau có thể vượt quá năm lần Tương tự như vậy, chi phí cho mỗi dòng mã của những thay đổi nhỏ thường gấp 2 tới 3 lần chi phí cho những chương trình mới Mức độ thay đổi của yêu cầu có thể tạo ra một sự khác nhau to lớn, như có thể là tình trạng thiết kế của một chương trình ban đầu trong trường hợp nâng cao

Dữ liệu qui trình chắc chắn không được dùng để so sánh giữa các dự án hay cá nhân Mục đích của nó là để làm sáng tỏ sản phẩm sẽ được phát triển và để cung cấp nền tảng có hiểu biết cho việc cải tiến qui trình Khi những dữ liệu này được sử dụng bởi việc quản lý để định giá các cá nhân hay nhóm, tính đáng tin cậy của dữ liệu sẽ giảm giá trị

Hai yêu cầu cơ bản để vượt qua khó khăn mức này là:

1 Hỗ trợ tự động thu thập dữ liệu qui trình Tất cả dữ liệu là dễ bị lỗi, mất, vài dữ liệu không thể thu thập bằng tay, và độ chính xác của việc thu thập

dữ liệu bằng tay thường thấp

2 Dùng dữ liệu qui trình vừa để phân tích và sửa đổi qui trình để ngăn ngừa các vấn để và cải tiến hiệu quả

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

Việc cải tiến qui trình phải được tiếp tục tại mọi mức trưởng thành của qui trình

Đó là khó khăn duy nhất còn lại cho tổ chức khi đã vượt qua các khó khăn ở mức độ 4: Làm thế nào để liên tục cải tiến qui trình Tới mức này cần có một sự dịch chuyển về mô hình (paradigm) Đến tận điểm này các nhà quản lý phát triển phần mềm đã tập trung ở mức độ lớn vào sản phẩm của họ và thông thường sẽ thu thập

và phân tích chỉ những dữ liệu quan hệ trực tiếp tới cải tiến sản phẩm Đến mức này

dữ liệu còn có tác dụng để tự điều chỉnh qui trình Với một chút kinh nghiệm, việc quản lý sẽ chẳng mấy chốc thấy rằng tối ưu qui trình có thể đem lại chất lượng lớn

và những lợi ích về năng suất

Ví dụ, nhiều loại lỗi có thể được xác định và sửa trước rất nhiều về mặt kinh tế bằng những cuộc soi mã và soi thiết kế hơn là bằng việc kiểm thử Không may là, chỉ có một lượng giới hạn dữ liệu được công bố sẵn có về chi phí để tìm và sửa lỗi Tuy nhiên, từ kinh nghiệm, có một qui tắc bổ ích: sẽ mất 1 tới 4 giờ làm việc để tìm

và sửa một lỗi bằng cách soi và khoảng 5 tới 20 giờ làm việc để tìm và sửa một lỗi trong việc kiểm thử chức năng hoặc kiểm thử hệ thống Để mở rộng được, các tổ chức nhận thấy rằng những con số này áp dụng trong hoàn cảnh của họ, họ nên xem xét đặt ít lòng tin cậy hơn vào việc kiểm thử như là cách chính để tìm và sửa lỗi

Tuy nhiên, vài loại lỗi là hoặc không kinh tế hoặc không thể tìm thấy ngoại trừ dùng máy móc Ví dụ là những lỗi liên quan đến chính tả và cú pháp, giao diện, tốc

độ, các nhân tố con người, và hồi phục lỗi Sẽ là không thông minh khi loại bỏ việc kiểm thử hoàn toàn vì kiểm thử cung cấp một sự kiểm tra hữu ích những nhược điểm của con người

Dữ liệu sẵn có cho chúng ta một khía cạnh mới trong việc kiểm thử Đối với hầu hết các dự án, một phân tích nhỏ đã chỉ ra rằng có hai hoạt động riêng rẽ dính líu vào: sự loại bỏ các lỗi và sự đánh giá chất lượng của chương trình Để giảm chi phí loại bỏ lỗi, các sự soi nên được nhấn mạnh, cũng để thu thập với bất cứ kỹ thuật

hiệu quả về mặt chi phí khác Vai trò của kiểm thử chức năng và hệ thống khi đó nên được thay đổi thành một việc trong việc thu thập dữ liệu chất lượng về các chương trình Điều này dính líu đến việc nghiên cứu mỗi lỗi để xem liệu lỗi đó là một vấn để tách biệt hay nó chỉ ra một vấn đề thiết kế mà đòi hỏi phân tích tổng hợp nhiều hơn

Với qui trình để vượt qua khó khăn mức này, tổ chức có các phương tiện để xác định các thành phần yếu nhất của qui trình và sửa chúng Tại điểm này trong việc cải tiến qui trình, dữ liệu là sẵn có để biện hộ cho việc áp dụng kỹ thuật vào nhiều nhiệm vụ nguy cấp, và những bằng chứng số là sẵn có về tính hiệu quả mà qui trình

đã được áp dụng cho bất cứ một sản phẩm cho trước nào Chúng ta không cần hàng tập giấy để mô tả những gì đã xảy ra vì những chỗ quanh co về lợi nhuận và những biểu đồ thống kê cung cấp những chỉ thị chính xác và rõ ràng Khi đó sẽ có thể đảm bảo qui trình và vì vậy có tự tin về chất lượng của các sản phẩm kết quả

Các khái niệm cơ bản [1]

Qui trình - Theo từ điển Webster, một qui trình là "một hệ thống các thao tác để

tạo ra một chuỗi các hoạt động, các thay đổi, hoặc các chức năng để đạt tới đích hoặc kết quả" Viện Công Nghệ Điện Và Điện Tử IEEE định nghĩa một qui trình là

"một chuỗi tuần tự các bước được thực hiện nhằm một mục đích cho trước" Một qui trình phần mềm có thể được định nghĩa như là một tập các hoạt động, các phương pháp, các thực tiễn, các sự biến đổi mà người ta dùng để phát triển và bảo trì phần mềm và các sản phẩm liên quan (ví dụ: các kế hoạch dự án, các tài liệu thiết

kế, mã nguồn, các trường hợp kiểm thử (test cases), và các sổ tay người dùng) Khi một tổ chức trưởng thành, qui trình phần mềm của tổ chức đó được xác định tốt hơn

và được thực thi nhất quán hơn trong toàn bộ tổ chức

Khả năng qui trình phần mềm (software process capability) mô tả loại kết quả

mong đợi có thể đạt được bằng cách tuân theo một qui trình phần mềm Khả năng qui trình phần mềm của một tổ chức cung cấp một phương tiện để dự đoán kết quả gần như chính xác cho dự án phần mềm tiếp theo mà tổ chức sẽ thực hiện

Hiệu suất qui trình phần mềm (Software process performance) diễn tả các kết

quả thực sự đạt được nếu tuân theo một qui trình phần mềm Vì vậy, hiệu suất qui trình phần mềm tập trung vào các kết quả đạt được thực sự, trong khi đó khả năng qui trình phần mềm tập trung vào các kết quả có thể đạt được Dựa trên các thuộc