2008-04-111719686909nghien cuu so luoc ve cmm va cmmi
DESCRIPTION
fafasgsgasggsgsgTRANSCRIPT
Tài liệu v1.0
Đề tài: Nghiên cứu sơ lược về CMM và CMMi
Người xây dựng tài liệu
Hà Hữu Cường
Hà Nội, 01-01-2008
1
Tài liệu v1.0
MẢNG GHI NHẬN THAY ĐỔI TÀI LIỆU
*T – Thêm mới S - Sửa đổi X - Xoá
Ngày hiệu
lực
Mục, bảng, sơ đồ được
thay đổi
T*
S, X
Mô tả thay đổi Phiên
bản
mới
01.11.2007Phân tích khả thi của đề
tàiT Tạo tài liệu 1.0
07.11.2007Xong phần phân tích khả
thi của đề tàiS
Sửa đổi giao diện và chỉnh sủa cho
phù hợp vớsi yêu cầu của đề tài1.0
07.11.2007 Nghiên cứu các level TĐọc và biên dịch tài liệu chia đều cho
các thành viên trong nhóm1.0
25.11.2007Nghiệm thu quá trình
nghiên cứuX
Sai hướng đi, tập trung quá nhiều vào
phần quy trình chưa nêu được ý nghĩa
của các level. Và các giai đoạn phát
triển từ các level thấp lên các level
cao
1.0
25.11.2007 Nghiên cứu lại S
Đi sâu vào các giai đoạn phát triển
của các level. Điều kiện phát triển
chúng
1.0
15.12.2007 Nghiệm thu TTập hợp tài liệu, thu gọn một số vấn
đề chính của đề tài1.0
15.12.2007 Tìm hiểu về việc áp dụng
CMM và CMMi ở Việt
Nam
T Tìm tài liệu trên mạng liên quan tới
việc áp dụng CMM và CMMi ở Việt
Nam
1.0
30.12.2007 Tổng hợp tài liệu T Viết và đóng gói tài liệu 1.0
2
Tài liệu v1.0
TRANG KÝ
Người lập:
Hà Hữu Cường
3
Tài liệu v1.0
MỤC LỤC
1 GIỚI THIỆU..........................................................................................4
1.1Mục tiêu của CMM & CMMi..............................................................................4
1.2Phạm vi...........................................................................................................5
1.3Khái niệm, thuật ngữ......................................................................................6
1.4Tài liệu tham khảo..........................................................................................7
1.5Mô tả tài liệu...................................................................................................8
2 TÌM HIỂU CHUNG VÀ ĐÔI NÉT SO SÁNH GIỮA CÁC PHIÊN BẢN.........................9
2.1Tổng quan về mô hình phần mềm..................................................................9
2.2Cấu trúc của CMM.........................................................................................19
2.3So sánh giữa CMM và CMMi..........................................................................29
2.4Tìm hiểu sơ lược về phiên bản CMMi 1.2.......................................................31
2.5Lợi ích của CMM đem lại cho doanh nghiệp..................................................37
3 VIỆT NAM ÁP DỤNG CMM VÀ CMMI TRONG LĨNH VỰC PHẦN MỀM...................39
3.1Tình hình áp dụng CMM và CMMi ở Việt Nam................................................39
3.2Chúng ta có cần CMM hay không?................................................................40
3.3Ý kiến cá nhân..............................................................................................43
3.4Tài liệu tham khảo........................................................................................43
3.5Lời cảm ơn....................................................................................................44
4
Tài liệu v1.0
1 GIỚI THIỆU
1.1 Mục tiêu của CMM & CMMi
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 tỉa
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.
Mục tiêu chiến lược xuyên suốt trong CMM là:
- Nâng cao khả năng của các tổ chức phần mềm bằng cách phát
triển kỹ năng cho nhân viên của họ
5
Tài liệu v1.0
- Đảm bảo rằng khả năng phát triển phần mềm là thuộc tính của
tổ chức hơn là một vài cá thế.
-Tạo động lực thúc đẩy nhân viên hoạt động cho tổ chức
- Và giữ các tài sản (tài sản ở đây bao gồm con người và các kỹ
năng, khả năng của họ) trong tổ chức
CMM bao gồm các practices:
- Nhân lực (bao gồm, thành viên mới, đã được chọn và sẽ chọn)
- Quản lý thành tích, hiệu suất công việc
- Đào tạo
- Môi trường làm việc
- Phát triển nghề nghiệp
- Cạnh tranh cá nhân và tổ chức
- Tư vấn và huấn luyện
- Phát triển nhóm làm việc và văn hóa nhóm
Nói tóm lại CMM & CMMi như là một giấy thông hành cho các doanh
nghiệp phần mềm
1.2 Phạm vi
Đề tài cung cấp sự hiểu biết cho các bạn sinh viên về CMM và
CMMi.
Phạm vi hoạt động của CMM & CMMi là áp dụng cho tất cả các
doanh nghiệp phần mềm . Nếu doanh nghiệp nào đủ yêu cầu đáp ứng nào
của CMM và CMMi có thể tham gia để đánh giá năng lực của doanh nghiệp
mình.
Làm sáng tỏ một số định nghĩa và thuộc tính cơ bản của CMM và
CMMi trong mối quan hệ sản xuất phầm mềm
Cải tiến quy trình quản lý trong việc sản xuất phầm mềm
6
Tài liệu v1.0
Ta có thể khẳng định CMM là bước phát triển tất yếu của các tổ
chức trong thời đại kinh tế tri thức, bởi vì nó là việc kết hợp qui chuẩn và
sáng tạo cho cách hoạt động của tổ chức, không cứng nhắc mà linh hoạt
thay đổi theo thực tế. Mô hình về tiến hoá của tổ chức khẳng định điều này.
Chúng ta cũng hiểu được vì sao bất kì thời đại, nền văn minh nào cũng có
thời kì huy hoàng rồi bị sa sút và diệt vong. Mọi tổ chức không thực hiện
việc đổi mới, đưa hiểu biết mới của các lớp trẻ vào, tất yếu sẽ bị diệt vong,
đây là điều các cấp lãnh đạo cần nhận rõ. Ngày xưa diệt vong của từng
triều đại là hàng trăm năm. Ngày nay sự diệt vong của các tổ chức chỉ là
hàng chục năm hoặc chưa đến thế.
1.3 Khái niệm, thuật ngữ
CMM và CMMi là gì?
CMM và CMMi là chuẩn quản lý quy trình chất lượng của các sản
phẩm phần mềm được áp dụng cho từng loại hình công ty khác nhau. Hay
nói cách khác đây là các phương pháp phát triển hay sản xuất ra các sản
phẩm phầm mềm.
Tháng 8/ 2006, SEI (Software Engineering Institute – Viện Công Nghệ Phần
Mềm Mỹ) - tổ chức phát triển mô hình CMM/CMMI đã chính thức thông báo
về phiên bản mới CMMI 1.2. Như vậy là sau gần 6 năm ban hành và sử
dụng thay thế cho CMM (từ tháng 12/2001), CMMI phiên bản 1.1 (CMMI
1.1) đã được chính thức thông báo với lộ trình thời gian chuyển tiếp lên
phiên bản mới CMMI 1.2.
Mặc dù số lượng các công ty phần mềm tại Việt Nam đạt được CMM/CMMI
đến nay vẫn chưa nhiều, nhưng với sự khởi sắc trong lĩnh vực gia công và
sản xuất phần mềm vài năm trở lại đây, sự cạnh tranh cũng như yêu cầu
ngày càng cao của khách hàng, đã thúc đẩy các công ty xây dựng hệ thống
quản lý chất lượng theo các mô hình quốc tế.
7
Tài liệu v1.0
Có những khác biệt đáng kể giữa CMMI 1.1 và CMMI 1.2, trong khuôn khổ
một bài viết chúng tôi cố gắng nêu những nét cơ bản nhất, nhằm giúp bạn
đọc có cái nhìn tổng quát, từ đó dễ dàng định hướng cho việc nghiên cứu
chi tiết hơn về CMMI 1.2.
CMM và CMMi là một bộ khung (framework)những chuẩn đề ra cho
một tiến trình sản xuất phần mềm hiệu quả, mà nếu như các tổ chức áp
dụng nó sẽ mang lại sự khả dụng về mặt chi phí, thời gian biểu, chức năng
và chất lượng sản phẩm phần mềm.
Mô hình CMM và mô tả các nguyên tắc và các thực tiễn nằm bên
trong tính “thành thục ” quá trình phần mềm và chủ ý giúp đỡ các công ty
phần mềm hoàn thiện khả năng thuần thục quá trình sản xuất phần mềm, đi
từ tự phát, hỗn độn tới các quá trình phần mềm thành thục, có kỷ luật.
Bằng việc thưc hiện CMM các công ty thu được những lợi ích xác
thực, giảm được rủi ro trong phát triển phần mềm và tăng được tính khả
báo - do đó trở thành đối tác hay một nhà cung ứng hấp dẫn hơn đối với
các khách hàng trên toàn thế giới. Tuy nhiên, CMM không phải không đòi
hỏi chi phí. Những nguồn lực đáng kể của công ty phải được dành cho việc
hướng tới các vùng tiến trình then chốt, cần thiết để lên từng bậc thang của
chứng nhận CMM. CMM đưa ra một loạt các mức độ để biểu thị mức độ
thành thục đã đạt được. Mức 1 ứng với mức độ thành thục thấp nhất và
mức 5 ứng với mức độ thành thục cao nhất. Gần đây, SEI đã xúc tiến
CMMi, một mô hình kế thừa CMM và CMMi hiện nay các công ty cũng đang
bắt đầu triển khai việc sử dụng mô hình này
1.4 Tài liệu tham khảo
TÊN TÀI LIỆU NGUỒN GHI CHÚ
•http://www.sei.cmu.edu/cmmi/models/compare-
v12-pas.pdf
•http://www.sei.cmu.edu/ cmm i/models/compare-
Website Để nắm rõ đầy đủ tất
cả chi tiết về các thay
đổi, các điểm khác
8
Tài liệu v1.0
v12-gps.pdf
•http://www.sei.cmu.edu/ cmm i/models/compare-
v12-glossary.pdf
•http://www.sei.cmu.edu/ cmm i/adoption/pdf/v12-
model-changes.pdf
nhau giữa hai phiên
bản CMMI v1.1 và
v1.2, bạn đọc có thể
tải về các tài liệu tại
địa chỉ trên.
Các tài liệu so sánh
chi tiết này do SEI
công bố và cho phép
tải về. Khi đọc tài liệu,
bạn lưu ý các quy ước
của nó
1.5 Mô tả tài liệu
Giới hạn tài liệu: Tài liệu chỉ đưa ra các khái niệm cơ bản về CMM & CMMi
và cũng có thể do khả năng hiểu biết của sinh viên không được thường
xuyên tiếp xúc và cũng mới trực tiếp tiếp xúc trong thời gian nghiên cứu
ngắn.
Cấu trúc tài liệu: phân cấp theo mô hình topdown.
9
Tài liệu v1.0
2 TÌM HIỂU CHUNG VÀ ĐÔI NÉT SO SÁNH GIỮA CÁC PHIÊN BẢN
2.1 Tổng quan về mô hình phần mềm
Hình 2.0: Mô hình
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 chúng ta 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.
10
Tài liệu v1.0
2.1.1 Qui trình là gì?
Hình 2.1: Quy trình cơ bản
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.
11
Tài liệu v1.0
Hình 2.2: Mô hình Waterfall
2.1.2 SEP, ISO, CMM/CMMI
Phần 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.
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
12
Tài liệu v1.0
CMM bao gồm những thực tiễn tốt nhất (best practices) được tập hợp rút tỉa
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.
Hình 2.3: V-model
2.1.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)
13
Tài liệu v1.0
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 2.2
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 đó.
14
Tài liệu v1.0
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.
2.1.4 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.3
15
Tài liệu v1.0
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.
Hình 2.4: Mô hình Prototype
2.1.5 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
16
Tài liệu v1.0
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 đó.
Hình 2.5: Mô hình tiến hóa
2.1.6 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 2.5 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ế.
2..1.7 Mô hình lặp và tăng dần
17
Tài liệu v1.0
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 2.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ình 2.6).
18
Tài liệu v1.0
Mô hình lặp (Iterative): thay đổi sản phẩm (xem minh họa Hình 2.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 2.6: 2 Mô hình phát triển
2.1.7 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.
2.1.8 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 2.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:
19
Tài liệu v1.0
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.
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.
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)
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.
2.2 Cấu trúc của CMM
2.2.1 Các level của CMM
CMM bao gồm 5 levels và 18 KPAs(Key Process Area)
5 levels của CMM như sau:
- 1: Initial, 2: Repeatable,3: Defined,4: Managed, 5: Optimising
Nói cách khác mỗi một level đều tuân theo một chuẩn ở mức độ cao hơn.
Muốn đạt được chuẩn cao hơn thì các chuẩn của các level trước phải thoả
mãn. Mỗi level đều có đặc điểm chú ý quan trọng của nó cần các doanh
nghiệp phải đáp ứng được
Level 1 thì không có KPAs nào cả
Level 2 : có 6 KPAs
Level 3: có 7 KPAs
Level 4: có 2 KPAs
Level 5: có 3 KPAs
18 KPAs của CMM được đều có 5 thuộc tính(chức năng) chung trong đó có
các qui định về key pratice là những hướng dẫn về các thủ tục(procedure),
qui tắc(polities), và hoạt động (activites)của từng KPA.
20
Tài liệu v1.0
Đầu tiên ta có cấu trúc của một KPA với 5 điểm đặc chưng(common
feature) như sau:
-------
KPA Goals
-------------------
||
||
1 2 3 4 5
Trong đó để thực hiện KPA này ta cần phải thực hiện theo những qui tắc
sau để bảo đảm đạt được KPA đó:
(1) Commitment to Perform ( Tạm dịch là cam kết thực hiện)
(2) Ability to Perform (Khẳ năng thực hiện)
(3) Activities Peformed (Các hoạt động lâu dài)
(4) Measurement and Analysis (Khuân khổ và phân tích)
(5) Verifiying and Implementation
Tiếp đến ta có cấu trúc CMM như sau:
Maturity Level
KPAs
Common Features
Key Practices
21
Tài liệu v1.0
Diễn dịch: Một maturity level chứa nhiều KPAs, các KPAs được gom chung
thành những đặc tính chung, các common feature chứa các key pratices để
các tổ chức có follow theo mà áp dụng
Hình 2.6
2.2.2 Các level của CMM
Level 1
Level 1 là bước khởi đầu của CMM, mọi doanh nghiệp, công ty phần
mềm, cá nhóm, cá nhân đều có thể đạt được. Ở lever này CMM chưa
yêu cầu bất kỳ tính năng nào. Ví dụ: không yêu cầu quy trình, không yêu
cầu con người, miễn là cá nhân, nhóm, doanh nghiệp… đều làm về
phầm mềm đều có thể đạt tới CMM này.
Đặc điểm của mức 1:
22
Tài liệu v1.0
Hành chính: Các hoạt động của lực lượng lao động được quan tâm
hàng đầu nhưng được thực hiện một cách vỗi vã hấp tấp
Không thống nhất: Đào tạo quản lý nhân lực nhỏ lẻ chủ yếu dựa
vào kinh nghiệp cá nhân
Quy trách nhiệm: Người quản lý mong bộ phận nhân sự điều hành
và kiểm sóat các hoạt động của lực lượng lao động
Quan liêu: Các hoạt động của lực lượng lao động được đáp ứng
ngay mà không cần phân tích ảnh hưởng
Doanh số thường xuyên thay đổi: Nhân viên không trung thành
với tổ chức
Level 2
Có 6 KPA nó bao gồm như sau
- Requirement Management ( Lấy yêu cầu khách hàng, quản lý các
yêu cầu đó)
- Software Project Planning ( Lập các kế hoạch cho dự án)
- Software Project Tracking (Theo dõi kiểm tra tiến độ dự án)
- Software SubContract Managent ( Quản trị hợp đồng phụ phần
mềm)
- Software Quality Assurance (Đảm bảo chất lượng sản phẩm)
- Software Configuration Management (Quản trị cấu hình sản
phẩm=> đúng yêu cầu của khách hàng không)
Khi ta áp dụng Level 2, KPA 2(Software Project Planning), ta sẽ có
những common feature(đặc điểm đặc trưng) như sau:
Mục tiêu(Goal): các hoạt động và những đề xuất của một dự án
phần mềm phải được lên kế hoạch và viết tài liệu đầy đủ
23
Tài liệu v1.0
Đề xuất/ Xem xét (Commitment): dự án phải tuân thủ theo các qui
tắc của tổ chức khi hoạch định
Khả năng(Ability): Việc thực hiện lập kế hoạch cho dự án phần
mềm phải là bước thực hiện từ rất sớm khi dự án đưọc bắt đầu
Đo lường(Measument): Sự đo lường luôn được thực thi và sử
dụng chúng ta luôn có thể xác định và kiểm soát được tình trạng các hoạt
động trong tiến trình thực hiện dự án
Kiểm chứng(Verification): Các hoạt động khi lập kế hoạch dự án
phải được sự reviewed của cấp senior manager
Câu hỏi được đặt ra ở đây là vậy thì vai trò của QA sẽ như thế nào
trong việc thực hiện project plan, tôi không đề cập đến vai trò Project
Manager vì anh ta phải biết về các nguyên tắc về estimates project theo
Function Point, Line of Code v.v...
Nói đến software quality, ắt hẳn các bạn QA không thể không biết
đến tam giác quỉ "Quality Triangle" (Cost,Functionality,Schedule) => đúng
chức năng , đúng chi phí, và đúng thời hạn. Đẻ ra cái gọi là chất lượng
phần mềm, thì phải có người review và kiểm chứng nó. Chúng tôi đặt ra
các tiêu chuẩn của qui trình mà từ đó chúng tôi sản xuất được phần mềm
tốt nhất, chúng tôi thực hiện và chúng tôi có những ngưòi kiểm chứng và
theo sát các hoạt động của nhóm thực hiện project sao cho đúng qui trình.
Vâng đó là QA Engineer, lâu nay vai trò của người QA trong các công ty
phần mềm bị đồng hoá với vai trò của một tester hay còn gọi là QC -
Quality Control.
24
Tài liệu v1.0
Để đạt được Level 2 thì người quản lý phải thiết lập được các
nguyên tắc cơ bản và quản lý các hoạt động diễn ra. Họ có trách
nhiệm quản lý đội ngũ của mình
Các KPA( Key Process Areas) của nó chú trọng tới các thành phần
sau :
+ Chế độ đãi ngộ
+ Đào tạo
+ Quản lý thành tích
+ Phân công lao động
+ Thông tin giao tiếp
+ Môi trường làm việc
Sẽ có người hỏi để từ level1 tiến tới level 2 cần có những gì:
Trả lời:
Trước tiên nó phải thỏa mãn các điều kiện ở level1
Tiếp theo là phải chú trọng tới các phần sau
1. Môi trường làm việc:
- Đảm bảo điều kiện làm việc
- Tạo hứng thú trong công việc
- Không bị ảnh hưởng, mất tập trung bởi các nhân tố khác
2. Thông tin:
Xây dựng cơ chế truyền tin thông suốt từ trên xuống dưới và ngược
lại nhằm giúp cá nhân trong tổ chức chia sẽ thông tin, kiến thức, kinh
nghiệm, các kỹ năng giao tiếp phối hợp và làm việc hiệu quả
3. Xây dựng đội ngũ nhân viên:
Ngay từ khâu tuyển dụng, lựa chọn kỹ càng và định hướng, thể chế
hóa quy trình tuyển dụng
25
Tài liệu v1.0
4. Quản lý thành tích:
Đẩy mạnh thành tích, công nhận năng lực, thành tích bằng cách
thiết lập các tiêu chí khách quan để đánh giá và liên tục khuyến khích khả
năng làm việc, tập trung phát triển sự nghiệp, xây dựng các mục tiêu tiếp
theo.
5. Đào tạo:
Không chỉ đào tạo các kiến thức chuyên môn phục vụ cho dự án mà
còn mở rộng đào tạo các kỹ năng then chốt, cần thiết như kỹ năng làm việc
đội, nhóm, kỹ năng quản lý… nhằm tạo cơ hội cho người lao động phát huy
khả năng, cơ hội học hỏi và phát triển bản thân.
6. Chế độ đãi ngộ:
Hoạch định chiến lược đãi ngộ, thu thập ý kiến lực lượng lao động
và công bố công khai. Chế độ đãi ngộ cần tập trung vào việc trả lương cho
công nhân viên dựa vào vai trò, vị trí của họ (Position), Con người (Person)
– thái độ và tác phong làm việc và Thành tích (Performance) mà họ đạt
được, cống hiến cho tổ chức. Đưa ra được chính sách lương, thưỏng, phụ
cấp các các quyền lợi khác để khuyến khích các cá nhân dựa trên sự đóng
góp của họ và cấp độ phát triển của toàn tổ chức.
Level 3
Các vùng tiến trình chủ chốt ở mức 3 nhằm vào cả hai vấn đề về
dự án và tổ chức, vì một tổ chức (công ty) tạo nên cấu trúc hạ tầng thể chế
các quá trình quản lý và sản xuất phần mềm hiệu quả qua tất cả các dự án.
Chúng gồm có Tập trung Tiến trình Tổ chức (Organization Process Focus),
Phân định Tiến trình Tổ chức (Organization Process Definition), Chương
trình Đào tạo (Training Program), Quản trị Phần mềm Tích hợp (Integrated
Software Management), Sản xuất Sản phẩm Phần mềm (Software Product
Engineering), Phối hợp nhóm (Intergroup Coordination), và Xét duyệt ngang
hàng (Peer Reviews).
26
Tài liệu v1.0
Để đạt được level 3 thì người quản lý phải biến đổi cải tiến các hoạt
động đang diễn ra, cải tiến môi trường làm việc.
Lực lượng lao động sở hữu những kiến thức, kỹ năng cốt lõi
KPA chú trọng tới các yếu tố sau :
+ Văn hóa cá thể
+ Công việc dựa vào kỹ năng
+ Phát triển sự nghiệp
+ Hoạch định nhân sự
+ Phân tích kiến thức và kỹ năng
Từ Level 2 lên Level 3: Các KPA cần thực hiện
1. Phân tích kiến thức và kỹ năng:
Xác định những kỹ năng và kiến thức cần thiết để làm nền tảng
cho hoạt động nhân sự. Lĩnh vực phân tích này bao gồm: xác định quy
trình cần thiết để duy trì năng lực tổ chức, phát triển và duy trì các kỹ năng
và kiến thức phục vụ công việc, dự báo nhu cầu kiến thức và kỹ năng
trong tương lai.
2. Hoạch định nguồn nhân lực:
Đây là lĩnh vực phối hợp hoạt động nhân sự với nhu cầu hiện tại
và trong tương lai ở cả các cấp và toàn tổ chức. Hoạch định nguồn nhân
lực có tính chiến lược cùng với quy trình theo dõi chặt chẽ việc tuyển
dụng và các hoạt động phát triển kỹ năng sẽ tạo nên thành công trong
việc hình thành đội ngũ.
3. Phát triển sự nghiệp:
27
Tài liệu v1.0
Tạo điều kiện cho mỗi cá nhân phát triển nghề nghiệp và có cơ
hội thăng tiến trong nghề nghiệp, nó bao gồm: thảo luận về lựa chọn nghề
nghiệp với mỗi cá nhân, xác định các cơ hội, theo dõi sự tiến bộ trong
công việc, được động viên, khuyến khích đạt mục tiêu công việc, giao
quyền và khuyến khích thực hiện những mục tiêu trong công việc.
4. Các hoạt động dựa trên năng lực:
Ngoài các kỹ năng, kiến thức cốt lõi còn có hoạch định nhân lực,
tuyển dụng dựa vào khả năng làm việc, đánh giá hiệu quả qua mỗi công
việc và vị trí, xây dựng chế độ phúc lợi, đãi ngộ dựa trên hiệu quả… giúp
bảo đảm rằng mọi hoạt động của tổ chức đều xuất phát từ mục đích phục
vụ cho phát triển nguồn nhân lực
5. Văn hóa cá thể:
Tạo lập được cơ chế liên lạc thông suốt, kênh thông tin hiệu quả
ở mọi cấp độ trong tổ chức, phối hợp được kinh nghiệm, kiến thức của
mỗi người để hỗ trợ lẫn nhau, giúp nhau cùng tiến bộ. Trao quyền thúc
đẩy nhân viên tham gia ý kiến, ra quyết định
Level 4
Các vùng tiến trình chủ yếu ở mức 4 tập trung vào thiết lập hiểu
biết định lượng của cả quá trình sản xuất phần mềm và các sản phẩm phần
mềm đang được xây dựng. Đó là Quản lý quá trình định lượng (Quantitative
Process Management) và Quản lý chất lượng phần mềm (Software Quality
Management)
Lực lượng lao động làm việc theo đội, nhóm và được quản lý một
cách định lượng.
Các KPA của level 4 chú trọng tới:
+ Chuẩn hóa thành tích trong tổ chức
+ Quản lý năng lực tổ chức
28
Tài liệu v1.0
+ Công việc dựa vào cách làm việc theo nhóm
+ Xây dựng đội ngũ chuyên nghiệp
+ Cố vấn
Để đạt được level 4 thì phải đo lường và chuẩn hóa. Đo lường hiệu
quả đáp ứng công việc, chuẩn hóac phát triển các kỹ năng, năng lực cốt lõi
Level 4 này sẽ chú trọng vào những người đứng đầu của một công
ty, họ có khả năng quản lý các công việc như thế nào
Level 5
Các vùng tiến trình chủ yếu ở mức 5 bao trùm các vấn mà cả tổ
chức và dự án phải nhắm tới để thực hiện hoàn thiện quá trình sản xuất
phần mềm liên tục, đo đếm được. Đó là Phòng ngừa lỗi (Defect
Prevention), Quản trị thay đổi công nghệ (Technology Change
Management), và Quản trị thay đổi quá trình (Process Change
Management) Để đạt được level 4 thì phải đo lường và chuẩn hóa. Đo
lường hiệu quả đáp ứng công việc, chuẩn hóac phát triển các kỹ năng,
năng lực cốt lõi
Để đạt được Level 5 thì doanh nghiệp đó phải liên tục cải tiến hoạt
động tổ chức, tìm kiếm các phương pháp đổi mới để nâng cao năng lực làm
việc của lực lượng lao động trong tổ chức, hỗ trợ các nhân phát triển sở
trường chuyên môn.
Chú trọng vào việc quản lý, phát triển năng lực của nhân viên
Huấn luyện nhân viên trở thành các chuyên gia
29
Tài liệu v1.0
2.3 So sánh giữa CMM và CMMi
Hẵn những ai quan tâm tới CMM, cũng đã từng nghe hoặc biết qua
CMMI . Và khi đã nghe qua, tôi đoán không ít người thầm thắc mắc, hoặc tự
hỏi rằng không biết CMM với CMMI nó khác nhau ra sao nhỉ ???
Nếu đặc tả một các trực quan thì ta thấy CMM và CMMI chỉ khác
nhau có một chữ “I” (Integration). Nhưng một chữ “I” đó thôi cũng tạo ra sự
khác biệt đáng kể giữa CMM và CMMI rồi.
Trước tiên hãy nghía qua nguồn gốc của hai thứ này một tí . Nếu
nói rằng CMM ra đời trước CMMI thì cũng đúng nhưng mà nói CMMI có
trước từ khi CMM ra đời cũng chẳng sai. Thật ra khi CMM được chính thức
công bố vào cuối năm 1990 thì CMMI đã được manh múng được nhắc đến
từ nhiều năm trước đó (chính xác hơn là từ 1979- Crosby’s maturity grid
(Quality is Free)) thông qua cấu trúc Continuous & Staged. Có thể nói
CMMI là một phiên bản cải thiện tất yếu của CMM.
Trong khi CMM được hoàn thiện và phát triển bởi viện SEI của Mỹ,
thì CMMI là sản phẩm của sự cộng tác giữa viện này và chính phủ Mỹ. Từ
khi CMM được công nhận và áp dụng trên thế giới thì tầm quan trọng của
nó đã vượt qua giới hạn của một viện khoa học. Với tốc độ phát triển không
ngừng và đòi hỏi sự cải thiện liên tục trong ngành công nghệ thông tin, việc
chính phủ Mỹ cùng với viện SEI kết hợp để hoàn thiện CMM và cho ra đời
phiên CMMI là một hệ quả tất yếu.
Mô hình CMM trước đây gồm có 5 mức: khởi đầu, lặp lại được,
được định nghĩa, được quản lý và tối ưu. Một điểm đặc biệt là mỗi doanh
nghiệp có thể áp dụng mô hình CMM ở bất kỳ mức nào mà không cần tuân
theo bất kỳ một qui định nào, không cần phải đạt mức thấp trước rồi mới có
thể đạt mức cao (có thể đi thẳng lên mức cao, hoặc cũng có thể tự hạ
xuống mức thấp hơn). Về nguyên tắc, SEI không chính thức đứng ra công
30
Tài liệu v1.0
nhận CMM mà thông qua các tổ chức tư vấn, các đánh giá trưởng được
SEI ủy quyền và thừa nhận.
Từ cuối 2005, SEI không tổ chức huấn luyện SW-CMM và chỉ thừa
nhận các đánh giá theo mô hình CMMi mới từ tháng 12/2005. CMMi được
tích hợp từ nhiều mô hình khác nhau, phù hợp cho cả những doanh nghiệp
phần cứng và tích hợp hệ thống, chứ không chỉ đơn thuần áp dụng cho
doanh nghiệp sản xuất phần mềm như CMM trước đây. Có 4 mô hình áp
dụng CMMi là CMMi-SW (dành cho công nghệ phần mềm), CMMi-SE/SW
(dành cho công nghệ hệ thống và phần mềm), CMMi-SE/SW/IPPD (dành
cho công nghệ hệ thống + công nghệ phần mềm với việc phát triển sản
phẩm và quy trình tích hợp), CMMi-SE/SW/IPPD/SS (dành cho công nghệ
hệ thống + công nghệ phần mềm với việc phát triển sản phẩm và quy trình
tích hợp có sử dụng thầu phụ). Có 2 cách diễn đạt và sử dụng CMMi:
Staged (phù hợp cho tổ chức có trên 100 người) và Continuos (phù hợp
cho tổ chức dưới 40 người). CMMi cũng bao gồm 5 mức như CMM: khởi
đầu, lặp lại được, được định nghĩa, được quản lý và tối ưu.
CMMI đưa ra cụ thể các mô hình khác nhau cho từng mục đích sử
dụng có đặc riêng bao gồm :
- CMMI-SW mô hình chỉ dành riêng cho phần mềm.
- CMMI-SE/SW mô hình tích hợp dành cho các hệ thống và kỹ sư
phần mềm.
- CMMI-SE/SW/IPPD mô hình dành cho các hệ thống, kỹ sư phần
mềm và việc tích hợp sản phẩm cùng quá trình phát triển nó.
Như vậy các đặc điểm khác nhau quan trọng nhất giữa CMM và
CMMI là gì?
Thử nghía qua xem trong CMMI hiện nay có gì khác với thằng anh
sinh ra trước nó (CMM):
- CMMI đưa ra cụ thể hơn 2 khái niệm đối ứng stageds VS
continuous
- Chu kỳ phát triển của CMMI được phát triển sớm hơn.
31
Tài liệu v1.0
- Nhiều khả năng tích hợp (Integration) hơn
- Sự đo lường, định lượng được định nghĩa hẵn là một Process
area (vùng tiến trình). Chứ không hẵn chỉ là một đặc trưng cơ bản.
- Bao hàm nhiều Process Areas hơn.
- Đạt được thành quả dễ dàng hơn với mỗi Process area.
Trên đây chỉ là những nhận xét sơ bộ về CMMI mà thôi, còn để
nhận biết rõ bộ "mặt" cùng bộ “lòng” của anh chàng CMMI là gì cùng với
việc khác nhau cụ thể với CMM như thế nào xin mời bà con tiếp tục nghiên
cứu và cho ý kiến thêm.
2.4 Tìm hiểu sơ lược về phiên bản CMMi 1.2
2.4.1. Chính sách chuyển tiếp từ CMMI 1.1 đến CMMI 1.2
Khung thời gian chuyển tiếp:
• Thời gian chuyển tiếp bắt đầu từ 25/08/2006 và kết thúc 31/08/2007.
Thời gian hiệu lực của CMMI 1.1:
• Với chính sách mới đi kèm CMMI v1.2, những tổ chức đã được đánh giá
và đạt CMMI, hiệu lực của kết quả đánh giá sẽ được công nhận và duy trì
trên trang web của SEI trong vòng tối đa 3 năm kể từ ngày kết thúc đánh
giá.
• Chính sách này cũng được áp dụng cho các tổ chức đã được công nhận
CMMI v1.1.
Thời gian hiệu lực cho các khóa huấn luyện chính thức về CMMI 1.1:
• SEI yêu cầu tổ chức áp dụng CMMI phải tham gia một khóa học bắt buộc
chính thức về CMMI (Introduction to CMMI) do giảng viên được SEI công
nhận.
• Với chính sách chuyển tiếp, những khóa huấn luyện chính thức về CMMI
1.1 sẽ không được công nhận sau ngày 31/12/2006.
32
Tài liệu v1.0
• Từ 2007, những khóa huấn luyện chính thức về CMMI 1.2 phải được
giảng dạy bởi giảng viên do SEI công nhận cho CMMI 1.2. Điều này đồng
nghĩa với việc từ 2007, các giảng viên cho CMMI 1.1 phải được nâng cấp
lên CMMI 1.2 và được SEI công nhận.
Ngày hiệu lực của các đánh giá theo CMMI 1.1:
• Tất cả các đánh giá mà giai đoạn đánh giá onsite (giai đoạn thực hiện
ngay tại tổ chức áp dụng CMMI) thực hiện sau ngày 31/08/2007 theo CMMI
1.1 (SCAMPI Class A v1.1) sẽ không được công nhận.
• Trong thời gian chuyển tiếp giữa CMMI 1.1 và 1.2 (25/08/2006-
31/08/2007), các đánh giá áp dụng cho sự kết hợp giữa 2 mô hình CMMI
1.1 và 1.2 đều được công nhận.
• Các đánh giá cho CMMI 1.1 hoặc dùng phương pháp SCAMPI v1.1 đều
được ghi nhận là cho CMMI 1.1.
• Các đánh giá SCAMPI, v1.1 hay v1.2, với giai đoạn onsite kể từ
01/11/2006 phải sử dụng "Bản công bố kết quả thẩm định" (Appraisal
Disclosure Statement) phiên bản mới v1.2 (ADS v1.2).
Ghi chú: ADS là một bản báo cáo bắt buộc, trong đó nêu rõ bộ phận nào
của tổ chức hay những dự án nào đã được thẩm định, cũng như những ai
đã tham gia vào quá trình thẩm định (tuy nhiên, các tổ chức được thẩm định
không buộc phải công bố bản báo cáo đó rộng rãi). Bản báo cáo ADS được
đánh giá viên gửi thẳng cho SEI để thẩm định.
2.4.2. Chính sách mới đối với CMMI 1.2
• Các đánh giá SCAMPI-A (lớp A, là giai đoạn đanh giá onsite) sẽ có giá trị
tối đa trong vòng 3 năm. Sau 3 năm, tổ chức muốn công nhận đạt CMMI
phải được đánh giá lại.
33
Tài liệu v1.0
Hình 1: Các khái niệm về thông lệ cơ sở và nâng cao đã bị loại bỏ
• Kết quả đánh giá SCAMPI-A của một tổ chức chỉ được công bố đại chúng
(báo chí, web site của tổ chức đạt CMMI, web site công bố danh sách các
tổ chức đạt CMMI của SEI) thông qua hoặc bởi một đánh giá viên trưởng
được SEI công nhận (SEI-authorized SACMPI Lead Appraiser), và người
này phải độc lập hoàn toàn với tổ chức được đánh giá.
• Đối với CMMI mức cao (mức 4 và 5), việc đánh giá phải do một đánh giá
trưởng cao cấp đứng đầu được SEI chứng nhận (SEI-certified High Maturity
Appraiser, khác với SEI-authorized SACMPI Lead Appraiser cho CMMI các
mức 2, 3). SEI sẽ bắt đầu chứng nhận các chuyên gia đánh giá cao cấp này
từ tháng 10/2006.
• "Bản công bố kết quả thẩm định" (ADS) phiên bản mới được mở rộng
đáng kể các mục để cung cấp nhiều thông tin nội bộ của đợt đánh giá. Khi
kết quả đánh giá được công bố trên website của SEI, các thông tin trong
bản công bố ADS cũng được công khai, trừ các dự án nhạy cảm hoặc
mang tính độc quyền (tổ chức phải cung cấp thông tin bổ sung cần thiết nếu
có nhu cầu).
2.4.3. Những thay đổi trong CMMI v1.2
34
Tài liệu v1.0
Hình 2: Các khái niệm về đặc điểm chung cũng được loại bỏ
Những thay đổi và điểm mới trong CMMI 1.2 rất nhiều, chúng tôi chỉ đưa ra
những điểm chính mang tính tổng quát.
Về cơ bản, CMMI 1.2 bao gồm ba nhóm cải tiến chính:
• Cải tiến về mô hình
• Cải tiến về phương pháp đánh giá
• Cải tiến về huấn luyện.
Cải tiến về mô hình:
• Cả hai dạng trình bày (Staged và Continuous), trước đây (CMMI 1.1) được
tổ chức tách biệt bằng 2 tài liệu riêng lẻ, nay được gom chung trong một tài
liệu.
• Loại bỏ các khái niệm về “Thông lệ cơ sở và thông lệ nâng cao” (base and
advanced pratices) và “Đặc điểm chung” (common feature). Xem hình vẽ
bên dưới bạn đọc sẽ dễ hình dung hơn.
• Các phần về “Mục tiêu chung” (generic goal) và “Các mô tả về thông lệ”
(practice descriptions) được di dời sang phần 2.
• Thêm các phần mở rộng và ví dụ về phần cứng.
• Tất cả định nghĩa được hợp nhất lại trong phần từ khóa (glossary)
• Các thông lệ (practices) về phát triển sản phẩm và quy trình tích hợp
(IPPD - Integrated Product and Process Development) được hợp nhất và
đơn giản hóa. Trong tài liệu, không còn phần quy trình riêng biệt (Process
Area) cho IPPD nữa
35
Tài liệu v1.0
Hình 3: Sơ đồ tổng quát các khóa huấn luyện (có thay đổi)
• "Quản lý nhà cung cấp" (SAM - Supplier Agreement Management) và
"Quản lý Nhà cung cấp tích hợp" (ISM - Integrated Supplier Management)
được hợp nhất. Các phần và thông lệ bổ sung về thầu phụ (Supplier
Sourcing) cũng được loại bỏ
• "Thông lệ chung" (generic practices) được giải thích tốt hơn, một số thông
lệ chung được bổ sung đồng thời cùng với các thông tin giải thích làm thế
nào để các quy trình hỗ trợ việc thực hiện các thông lệ chung đó
• Các tài liệu cần thiết được bổ sung để bảo đảm triển khai được các quy
trình khi dự án bắt đầu
• Tên của mô hình CMMI được rút gọn là “CMMI for Development” (CMMI-
DEV) để phản ánh kiến trúc mới của CMMI.
Với CMMI 1.2, tất cả các vùng quy trình (PA - Process Area) đều bị thay
đổi, không ít thì nhiều, tuy nhiên một số PA đặc biệt được thay đổi nhiều
hơn những PA khác, các PA được thay đổi nhiều và rõ nét nhất được nêu
rõ trong bảng.
Để nắm rõ đầy đủ chi tiết về các thay đổi, bạn đọc tham khảo phần “So
sánh chi tiết CMMI 1.1 và CMM v1.2”.
Cải tiến về phương pháp đánh giá:
• Loại bỏ các yêu cầu về công cụ hỗ trợ, chẳng hạn yêu cầu về khảo sát...
• Bổ sung hướng dẫn về thông lệ thay thế
• Xác lập giới hạn thời gian tối đa cho các đợt đánh giá
• Bổ sung yêu cầu cho việc lấy mẫu khi đánh giá
36
Tài liệu v1.0
• Mở rộng phạm vi của việc xem xét tính sẵn sàng, áp dụng cho cả tổ chức
được đánh giá, các nhóm được đánh giá, thiết bị và dịch vụ đi kèm
• Yêu cầu chữ ký của người bảo trợ cho đợt đánh giá trên "Bản công bố kết
quả thẩm định" (ADS)
• Giới hạn hiệu lực của kết quả đánh giá trong vòng tối đa 3 năm
Về cơ bản, những cải tiến trên phương pháp đánh giá có thể đúc kết theo
các chủ điểm chính sau:
• Giảm thiểu sự phức tạp và tối nghĩa
• Cung cấp nhiều hướng dẫn khi cần thiết
• Củng cố mạnh mẽ các chặng lên kế hoạch và tiến hành một đợt đánh giá
• Củng cố mạnh mẽ vấn đề báo cáo đánh giá
• Xác định thời gian hiệu lực của kết quả đánh giá
• Tăng cường mạnh mẽ các yêu cầu cho đánh giá trưởng.
Để nắm rõ đầy đủ chi tiết về các thay đổi, bạn đọc có thể tải về tài liệu mô tả
tại địa chỉ http://www.sei.cmu.edu/cmmi/adoption/pdf/v12-scampi-
changes.pdf
Các cải tiến về huấn luyện:
• Sửa đổi tất cả tài liệu huấn luyện để phù hợp với những thay đổi và những
điểm mới của mô hình CMMI 1.2 và phương pháp đánh giá SCAMPI 1.2
• Cải thiện tính nhất quán và chặt chẽ của tài liệu huấn luyện
• Cụ thể, các khóa huấn luyện sau đã được nâng cấp (hình 3)
- Giới thiệu CMMI (Introduction to CMMI)
- Các khái niệm cấp trung về CMMI (Intermediate concepts of CMMI)
- Huấn luyện cho đánh giá trưởng (SCAMPI Lead Appraiser SM Training)
- Huấn luyện trưởng nhóm đánh giá (SCAMPISM B and C Team Leader
Training)
- Huấn luyện cho người hướng dẫn (Instructor Training)
- Huấn luyện nâng cấp kiến thức CMMI 1.2 (CMMI v1.2 Upgrade Training).
37
Tài liệu v1.0
Để nắm rõ chi tiết về các thay đổi, bạn đọc có thể download tài liệu mô tả tại
địa chỉ sau: http://www.sei.cmu.edu/cmmi/adoption/pdf/v12-training-
changes.pdf
2.5 Lợi ích của CMM đem lại cho doanh nghiệp
1. Viễn cảnh mà CMM mang lại
- Ý nghĩa của việc áp dụng những nguyên tắc:
+ Quản lý chất lượng tổng thể
+ Quản lý nguồn nhân lực
+ Phát triển tổ chức
+ Tính cộng đồng
+ Phạm vi ảnh hưởng rộng: từ các nghành công nghiệp đến chính
phủ
+ Hoàn toàn có thể xem xét và mở rộng tầm ảnh hưởng với bên
ngoài
+ Chương trình làm việc nhằm cải tiến, nâng cao hoạt động của
đội ngũ lao động
+ Đánh giá nội bộ
+ Các hoạt động của đội ngũ lao động được cải tiến
+ Các chương trình nhằm nâng cao năng lực, hiệu quả công việc
luôn được tổ chức
2. Mục tiêu chiến lược
- Cải tiến năng lực của các tổ chức phần mềm bằng cách nâng cao kiến
thức và kỹ năng của lực lượng lao động
38
Tài liệu v1.0
- Đảm bảo rằng năng lực phát triển phần mềm là thuộc tính của tổ chức
không phải của một vài cá thể
- Hướng các động lực của cá nhân với mục tiêu tổ chức
- Duy trì tài sản con người, duy trì nguồn nhân lực chủ chốt trong tổ chức
3. Lợi ích CMM mang lại cho Doanh nghiệp gói gọn trong 4 từ: Attract,
Develop, Motivate và Organize
4. Lợi ích CMM mang lại cho người lao động:
- Môi trường làm việc, văn hóa làm việc tốt hơn
- Vạch rõ vai trò và trách nhiệm của từng vị trí công việc
- Đánh giá đúng năng lực, công nhận thành tích
- Chiến lược, chính sách đãi ngộ luôn được quan tâm
- Có cơ hội thăng tiến
- Liên tục phát triển các kỹ năng cốt yếu.
39
Tài liệu v1.0
3 VIỆT NAM ÁP DỤNG CMM VÀ CMMI TRONG LĨNH VỰC PHẦN MỀM
3.1 Tình hình áp dụng CMM và CMMi ở Việt Nam
Khi Việt Nam chính thức gia nhập WTO, thì cũng là lúc các doanh
nghiệp CNTT trong nước phải cạnh tranh trực tiếp với doanh nghiệp nước
ngoài. Muốn cạnh tranh thành công, ngoài việc tăng cường năng lực, tạo
thế cạnh tranh, thì hình thành sự khác biệt là điều tối cần thiết. Tuy nhiên sự
khác biệt này, có được cộng đồng quốc tế công nhận và được chứng nhận
về chất lượng hay không lại là điều mà nhiều doanh nghiệp CNTT chưa đạt
được.
Chính phủ đã thông qua chiến lược phát triển CNTT đến năm 2010
và tầm nhìn 2020. Theo đó, công nghiệp phần mềm Việt Nam(yếu tố chủ
lực phát triển CNTT) sẽ có tốc độ tăng trưởng bình quân 40%/năm, và đạt
tổng doanh thu 1,2 tỷ USD vào năm 2010. Tuy nhiên để đạt con số 1,2 tỷ
USD còn nhiều rào cản phải sớm được giải quyết. Đó là nguồn nhân lực
phần mềm Việt Nam thiếu về số lượng
Chưa đạt con số 50.000 chuyên gia phần mềm chuyên nghiệp,
tổng mức đầu tư cho ngành công nghiệp phần mềm còn thấp
Theo thống kê mới đây của Hội tin học VN, hiện 80- 90% doanh thu
của nhiều doanh nghiệp phần mềm VN chủ yếu nhờ vào xuất khẩu. Vì vậy
gia công phần mềm có thể coi là hướng đi chủ đạo cho ngành công nghiệp
phần mềm nước ta trên con đường đạt mục tiêu 1,2 tỷ USD. Nói cách khác
làm thế nào marketing hiệu quả ngành công nghiệp phần mềm chính là
công việc cần làm ngay lúc này
Việt nam có các lợi thế về nhân lực cần cù, chăm chỉ, giá nhân
công rẻ, hệ thống giáo dục được đào tạo bài bản.... Việt Nam hiện là điểm
sáng trên bản đồ thế giới. Tuy nhiên, trong quá trình tiếp thị và giới thiệu
tiềm năng với cộng đồng CNTT quốc tế, yêu cầu đầu tiên được phía nuớc
ngoài đặt câu hỏi là: Doanh nghiệp CNTT Việt Nam có tốc độ phát triển ra
40
Tài liệu v1.0
sao ? Năng lực thế nào, và đặc biệt là ứng dụng hệ thống quản lý chất
lượng phần mềm đến đâu ?
Về cơ bản, quản lý chất lượng phần mềm là vấn đề không mới,
nhưng lại là vấn đề còn yếu của các công ty phần mềm Việt Nam. Một số
công ty đã đạt chuẩn quốc tế CMM/CMMI trong nâng cao năng lực và quản
lý chất lượng phần mềm, song cũng chỉ gói gọn trong vài công ty gia công
cho nước ngoài
Tuy nhiên, thông thường các công ty phải đầu tư ít nhất 40.000-
50.000 USD cho chi phí tư vấn, đánh giá và khảo sát. Chi phí này thực tế
còn cao hơn nhiều sau khi cộng thêm các khoản vé máy bay, ăn ở , đi lại
cho các chuyên gia tư vấn, giám sát, đào tạo...
Thực tế đây là khoản đầu tư khá lớn đối với các công ty phần mềm
VN. Do vậy, mơi đây tập đoàn TƯ- tổ chức quốc tế cung cấp các giải pháp
về chất lượng và kỹ thuât, đã liên kết với DEG(Viện tài chính hỗ trợ phát
triển của CHLB Đức) công bố triển khai dự án tài trợ nâng cao năng lực
ngành CNTT- viễn thông liên lạc- kỹ thuật công nghệ của Việt Nam. Dự án
này sẽ bắt đầu từ tháng 12/2006
Xét đến thời điểm này, chưa có số liệu chính xác về số lượng
doanh nghiệp phần mềm đang áp dụng mô hình đánh giá năng lực sản xuất
phần mềm CMM/CMMi tại Việt Nam, nhưng có thể nhắc đến những tên tuổi
như PSV (CMMi mức 5: 2005), GCS (CMMi mức 4: 2006), FPT Software
(CMM mức 5: 2004) và SilkRoad (CMM mức 3).
3.2 Chúng ta có cần CMM hay không?
Vẫn biết, mọi người đều nói CMM là vấn đề mới của các tổ chức
làm phần mềm và nó đã được thừa nhận trên thế giới. Nhưng ở Việt
Nam chúng ta có thể dùng được nó không, dùng như thế nào? Như hoạt
động thường ngày của tôi, mọi sự vẫn ổn cả, việc gì phải làm rối tung lên
41
Tài liệu v1.0
bởi CMM? Vậy chăng chúng ta hãy cứ biết CMM là hay, còn chưa sử
dụng nó vội, chúng ta vẫn cứ theo cách thức mọi tổ chức hiện đang hoạt
động? Điều này có ảnh hưởng quyết định lên thái độ học tập CMM của
mọi người.
Cần xác định rõ mục đích và ý nghĩa của việc học và hành những
tri thức mới về CMM. Nếu nó mới quá mà chúng ta không áp dụng được,
thì có lẽ cũng chưa cần học làm gì, hay học chỉ để biết, khi hết khoá học
lại giả lại chữ cho thầy. Nếu nhìn vào thực tế hoàn cảnh hiện nay của
chúng ta thì đúng là chưa có ích lợi mấy, chưa thể áp dụng rộng rãi
được.
Vì vậy chúng ta phải lấy một góc nhìn, một viễn cảnh rộng hơn để
thấy cái tất yếu của đường đi, của xu hướng phát triển thực tế, từ đó định
hướng cho hành động chuẩn bị cho tương lai của mình. Có như vậy
chúng ta mới có thể kiên trì và thực hiện được thành công việc triển khai
CMM trong hoàn cảnh thực tế. Nếu chúng ta không có cái nhìn chiến
lược, toàn diện, lâu dài, thì những khó khăn và ràng buộc thực tế hiện
nay rất có thể sẽ đẩy lùi chúng ta lại.
Thứ nhất phải khẳng định CMM là bước phát triển tất yếu của các
tổ chức trong thời đại kinh tế tri thức, bởi vì nó là việc kết hợp qui chuẩn
và sáng tạo cho cách hoạt động của tổ chức, không cứng nhắc mà linh
hoạt thay đổi theo thực tế. Mô hình về tiến hoá của tổ chức khẳng định
điều này. Chúng ta cũng hiểu được vì sao bất kì thời đại, nền văn minh
nào cũng có thời kì huy hoàng rồi bị sa sút và diệt vong. Mọi tổ chức
không thực hiện việc đổi mới, đưa hiểu biết mới của các lớp trẻ vào, tất
yếu sẽ bị diệt vong, đây là điều các cấp lãnh đạo cần nhận rõ. Ngày xưa
diệt vong của từng triều đại là hàng trăm năm. Ngày nay sự diệt vong của
các tổ chức chỉ là hàng chục năm hoặc chưa đến thế.
42
Tài liệu v1.0
Nếu đó đã là qui luật chung thì các tổ chức của Việt Nam cũng
không ngoại lệ. Do đó càng đưa sớm CMM vào thực tế càng tốt và thúc
đẩy sự phát triển ở Việt Nam. Nhưng điều thứ hai cần khẳng định là chỉ
có thể thực hiện được CMM nếu đấy là nỗ lực của toàn tổ chức, và trong
đó cam kết của lãnh đạo là quyết định. Vì vậy việc huấn luyện về CMM
phải là huấn luyện cho toàn tổ chức, không phải chỉ là huấn luyện cho đội
ngũ kĩ thuật, tuy rằng ban đầu chúng ta vẫn phải xuất phát từ phía kĩ
thuật. Các cấp lãnh đạo, có quyền lực cần được học về CMM theo góc
độ bảo đảm sự phát triển tiến hoá của tổ chức.
Và thứ ba, chúng ta cần có được một đội ngũ những người am
hiểu về CMM để giới thiệu cho nhiều tổ chức thực hiện. Đội ngũ này phải
có khả năng dạy cho mọi loại người trong tổ chức, không chỉ cho các
chuyên viên kĩ thuật, người đã sẵn sàng học cái mới. Chúng ta phải đủ
khả năng để đối diện với mọi cấp lãnh đạo và cung cấp cho họ những tri
thức mới về cách làm việc mới, nhưng phải biết nói theo ngôn ngữ của
họ.
Từ đây rõ ràng có yêu cầu lớn để chúng ta học CMM cho tương lai,
học được điều bản chất của nó, học luôn cả về môi trường của chúng ta
và cách chúng ta đưa CMM vào thực tế.
Nói rộng ra, mọi việc học đều phải gồm hai phần: học của thế giới,
và thực hành trong việc áp dụng cái mới vào thực tế của chúng ta. Học
của thế giới đã có bài bản, cứ việc theo. Thực hành áp dụng cái học mới
chính là thách thức và sự khẳng định chân giá trị của chúng ta. Nó đòi hỏi
chúng ta phải vượt lên hơn rất nhiều so với việc học thuần tuý lí thuyết.
Nó chính là sáng tạo mà chúng ta đem lại cho cuộc sống này
43
Tài liệu v1.0
3.3 Ý kiến cá nhân
Các công ty Việt Nam đua nhau lấy ISO và CMM có hai dạng: 1 là
muốn cải tiến quá trình quản lý trong việc phát triển phần mềm, còn 1 là đi
theo nhu cầu khách hàng hoặc để quảng cáo.
Với các công ty muốn cải tiến quy trình để phát triển thì việc lấy
chứng chỉ hơi lâu vì cần phải đào tạo, chỉ rỏ cho tất cả nhân viên thấy được
lợi ích của các quy trình này để họ tự nguyện làm theo (vì thật sự thì nó sẽ
làm cho nhân viên cảm thấy mình phải làm nhiều hơn, phải lưu giữ đủ thứ
giấy tờ, thủ tục,...). Khi tất cả đều nhận thức rỏ được vấn đề và thấy rằng
ISO hay CMM thật sự sẽ mang lại lợi ích lâu dài cho họ thì lúc đó ISO hay
CMM mới góp phần cải tiến quy trình thật sự cho công ty. Dĩ nhiên khi có
được ISO hay CMM certification thì công ty cũng đem ra để quảng cáo, để
làm lợi thế khi ký hợp đồng. Nhưng thật sự thì ISO hay CMM giúp ích cho
công tác quản lý rất nhiều, mọi việc phải được cụ thể hoá thành văn bản
chứ không làm việc cảm tính, nói miệng với nhau như trước nữa.
Còn với những công ty lấy ISO hay CMM chỉ vì mục đích quảng
cáo thì đâu lại vào đấy thôi vì sau khi đạt được chứng chỉ xong họ lại cất
những process đó vào tủ và lại làm việc theo thói quen cũ, chẳng có thay
đổi gì hết.
Tuy nhiên, theo đánh giá của riêng cá nhân tôi thì ISO hay CMM
đều không khuyến khích sáng tạo, mọi thứ đều có template, guideline hết,
cứ theo đó mà làm, chẳng có chút gì thúc đẩy sự sáng tạo trong quản lý cả.
Tuy nhiên, thì nếu áp dụng đúng với những template hay guideline đó thì
người quản lý biết chắc mình đang đi đúng hướng, giảm được độ rủi ro.
3.4 Tài liệu tham khảo
+ Addison Wesley - CMMI Distilled - A Practical Introduction to Integrated
Process Improvement, 2nd Ed - 2003.chm
+ CBA - IPI - CMM Intro - Session 1.1.ppt (các phiên bản từ 1 tới 5)
44
Tài liệu v1.0
http://www.sei.cmu.edu/cmmi/models/compare-v12-pas.pdf
http://www.sei.cmu.edu/cmmi/models/compare-v12-gps.pdf
http://www.sei.cmu.edu/cmmi/models/compare-v12-glossary.pdf
http://www.sei.cmu.edu/cmmi/adoption/pdf/v12-model-changes.pdf
45