nghiên cứu việc áp dụng cmmi mức 3 tại vietsoftware

BỘ GIÁO DỤC VÀ ĐÀO TẠO TỔNG CÔNG TY BƯU CHÍNH VIỄN THÔNG
VIỆT NAM
HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG


ĐỒ ÁN
TỐT NGHIỆP ĐẠI HỌC
Chuyên ngành Công nghệ thông tin


Đề tài:
Nghiên cứu việc áp dụng CMMI mức 3
tại VietSoftware



Sinh viên thực hiện:


ĐẶNG THỊ HUYỀN LINH
Lớp D2001CNTT
Giáo viên hướng dẫn:

Ths. BÙI TRƯỜNG SƠN




HÀ NỘI – 11/2005

BỘ GIÁO DỤC VÀ ĐÀO TẠO TỔNG CÔNG TY BƯU CHÍNH VIỄN THÔNG
VIỆT NAM
HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG


ĐỒ ÁN
TỐT NGHIỆP ĐẠI HỌC
Chuyên ngành Công nghệ thông tin


Đề tài:
Nghiên cứu việc áp dụng CMMI mức 3
tại VietSoftware


Sinh viên thực hiện:


ĐẶNG THỊ HUYỀN LINH
Lớp D2001CNTT
Giáo viên hướng dẫn:

Ths. BÙI TRƯỜNG SƠN

Ngày nhận đề tài: 01/8/2005
Ngày hoàn thành: 10/11/2005
Đồ án được thực hiện tại khoa CÔNG NGHỆ THÔNG TIN
Học viện công nghệ bưu chính viễn thông

Đồ án tốt nghiệp Đại học Lời cảm ơn


- ii -

LỜI CẢM ƠN
Tôi xin bày tỏ lòng biết ơn sâu sắc tới ThS. Bùi Trường Sơn, người thầy
đã trực tiếp tận tình hướng dẫn chỉ bảo tôi trong quá trình nghiên cứu và hoàn
thành luận văn.
Tôi xin chân thành cảm ơn sự động viên, giúp đỡ, tạo điều kiện của Khoa
Công nghệ Thông tin I, Học viện Công nghệ Bưu chính Viễn thông. Tôi xin cảm
ơn các thầy cô giáo trong Khoa đã tận tình giảng dạy giúp tôi có những kiến
thức để hoàn thành đồ án này.
Trong quá trình làm đồ án, tôi đã được phòng Quy trình và Đảm bảo Chất
lượng (P&QA) của công ty Cổ phần Phần mềm Việt (VietSoftware) tạo điều
kiện thuận lợi và cung cấp những thông tin tài liệu hữu ích. Nhân dịp này, tôi
xin bày tỏ lòng biết ơn tới những sự giúp đỡ quý báu đó.
Tôi xin cảm ơn sự giúp đỡ và những ý kiến đóng góp quý báu của các bạn
trong lớp D2001CNTT trong thời gian hoàn thành đồ án này.
Cuối cùng, tôi xin cảm ơn gia đình, bạn bè và người thân đã luôn động viên,
giúp đỡ tôi trong suốt thời gian học tập và hoàn thành đồ án.


Hà Nội, tháng 10 năm 2005

Đồ án tốt nghiệp Đại học Mục lục


- iii -

MỤC LỤC
1. TỔNG QUAN ĐỀ TÀI 1
2. KHÁI NIỆM QUY TRÌNH SẢN XUẤT PHẦN MỀM VÀ MỖI LIÊN HỆ GIỮA CMMI VÀ
QUY TRÌNH 3
2.1. Khái niệm quy trình phần mềm 3
2.2. Một số quy trình phần mềm được áp dụng trong thực tế và mối liên hệ giữa
quy trình đó và CMMI 4
2.2.1. Mô hình RUP 4
2.2.2. Mô hình XP 9
3. MÔ HÌNH CMMI 16
3.1. Khái niệm CMMI 16
3.1.1. Tổng quan về CMMI 16
3.1.2. Cấu trúc CMMI 19
3.1.3. Ưu điểm của CMMI 25
3.2. Các lĩnh vực quy trình (PAs) trong CMMI 26
3.2.1. Các PAs về quản lý quy trình (Process Management Process Areas) 26
3.2.2. Các lĩnh vực quy trình về quản lý dự án - Project Management Process Areas
32
3.2.3. Các lĩnh vực quy trình kỹ nghệ - Engineering Process Areas 40
3.2.4. Các lĩnh vực quy trình hỗ trợ - Support Process Areas 49
3.2.5. Mối quan hệ giữa các lĩnh vực quy trình 55
4. ÁP DỤNG CMMI LEVEL 3 TẠI VIETSOFTWARE 57

4.1. Thực trạng quy trình sản xuất phần mềm tại VietSoftware 57
4.1.1. Sơ lược về tổ chức và hoạt động của VSI 57
4.1.2. Thực trạng sản xuất phần mềm tại VSI 59
4.2. Các KPAs cần thực hiện để áp dụng CMMI Level 3 tại VSI 65
4.2.1. Các lĩnh vực quy trình ở CMMI mức 2 65
4.2.2. Các lĩnh vực quy trình ở CMMI mức 3 111
5. KẾT LUẬN 139
PHỤ LỤC A. TỪ VIẾT TẮT 140
PHỤ LỤC B. MỘT SỐ THUẬT NGỮ ĐƯỢC DÙNG TRONG CMMI 142
PHỤ LỤC C. TÀI LIỆU THAM KHẢO 146



DANH MỤC HÌNH VẼ

Hình 2-1: Cấu trúc RUP 7
Hình 3-1: Ba tiêu chuẩn quan trọng đối với một quy trình 16
Hình 3-2: Các bước của mô hình CMM cho phần mềm 19
Hình 3-3: Sơ lược các mức năng lực 21
Hình 3-4: Các thành phần của mô hình CMMI trong cách biểu diễn phân tầng 22
Hình 3-5: Các thành phần của mô hình CMMI trong cách biểu diễn liên tục 23
Hình 3-6: Các PA trong nhóm Process Management 27
Hình 3-7: Định nghĩa quy trình tổ chức 28
Hình 3-8: Tập trung vào quy tình tổ chức 29
Hình 3-9: Phát triển vào cải tiến tổ chức 30
Hình 3-10: Đào tạo trong tổ chức 31
Hình 3-11: Các PA trong nhóm Project Management 33
Hình 3-12: Lập kế hoạch dự án 34
Hình 3-13: Kiểm soát và theo dõi dự án 35
Hình 3-14: Quản lý dự án tích hợp 36

Hình 3-15: Quản lý dự án tích hợp trong IPPD 37
Hình 3-16: Quản lý định lượng dự án 38
Hình 3-17: Quản lý thỏa thuận với nhà thầu phụ 39
Hình 3-18: Quản lý rủi ro 40
Hình 3-19: Quản lý yêu cầu 42
Hình 3-20: Phát triển yêu cầu 43
Hình 3-21: Giải pháp kỹ thuật 45
Hình 3-22: Tích hợp sản phẩm 46
Hình 3-23: Thẩm định (Verification) 48
Hình 3-24: Phê duyệt (Validation) 49
Hình 3-25: Quản lý cấu hình 51
Hình 3-26: Đảm bảo chất lượng quy trình và chất lượng sản phẩm 52
Hình 3-27: Đo lường và phân tích 53
Hình 3-28: Phân tích quyết định và giải pháp 54
Hình 3-29: Phân tích nguyên nhân và giải pháp 55
Hình 4-1: Mô hình quy trình quản lý yêu cầu 66
Hình 4-2: Sơ đồ tổng quát của qui trình Lập kế hoạch dự án (Project Planning) 74
Hình 4-3: Sơ đồ tổng quát của qui trình Giám sát và Kiểm soát dự án 88
Hình 4-4: Sơ đồ tổng quát của quy trình Đo lường và Phân tích 92
Đồ án tốt nghiệp Đại học Danh mục hình vẽ


- v -

Hình 4-5: Sơ đồ tổng quát của quy trình đảm bảo chất lượng quy trình và chất lượng sản
phẩm 99
Hình 4-6: Sơ đồ tổng quát của qui trình Quản lý cấu hình 103
Hình 4-7: Mô hình quy trình tích hợp sản phẩm 114
Hình 4-8: Mô hình quy tình thẩm định (Verification) 117
Hình 4-9: Mô hình quy trình đào tạo của tổ chức 124

Hình 4-10: Mô hình quy trình quản lý rủi ro 132
Hình 4-11: Mô hình quy trình Phân tích quyết định và Giải pháp (DAR) 135








Đồ án tốt nghiệp Đại học Tổng quan đề tài


Đặng Thị Huyền Linh −1− Lớp 2001CNTT
TỔNG QUAN ĐỀ TÀI
Để sản xuất được sản phẩm có chất lượng thì cần phải có một quy trình sản
xuất có chất lượng. Đó là điều mà từ lâu nay không còn cần tranh cãi nữa.
Trong công nghệ phần mềm (CNPM) hay cũng như trong các ngành công nghệ
khác, một quy trình sản xuất có chất lượng thường phải đạt được các mục tiêu
sau:
• Sản xuất được sản phẩm đạt yêu cầu chất lượng: có nghĩa là phải đạt
được các yêu về chức năng, kỹ thuật và chất lượng theo yêu cầu của
khách hàng hay thị trường;
• Hoàn thành sản phẩm theo đúng tiến độ và kinh phí: có nghĩa là phải
cho ra được sản phẩm theo đúng kế hoạch và kinh phí đã xác định
trước;
• Đáp ứng được nhu cầu của người sản xuất: một quy trình nếu không
đáp ứng nhu cầu của người lao động trong dây chuyền sản xuất thì khó
có thể được áp dụng và tuân theo một cách đúng đắn.
Đó là những mục tiêu mà tổ chức nào cũng mong muốn, cho nên thiết lập và

nâng cao chất lượng của qui trình sản xuất là điều người ta buộc phải làm. Để
làm điều đó, người ta không thể không nghiên cứu, học hỏi và áp dụng những
mô hình thiết lập và cải tiến qui trình tiên tiến trên thế giới. Trong ngành
CNPM, những tên tuổi như vậy hiện có như ISO9001, CMM, và CMMI.
Trong đó, CMM và CMMI – mô hình nâng cao từ CMM là các mô hình đã
và đang được áp dụng phổ biến và được quốc tế hoá mạnh mẽ, chính do hiệu
quả sử dụng của chúng trong thực tế.
Tuy nhiên, việc áp dụng CMMI thực sự không hề dễ dàng vì mỗi tổ chức là
một hệ thống bao gồm rất nhiều các quy trình phức tạp, đồng thời và có tương
tác với nhau. Để cải tiến các quy trình này cần phải có những thay đổi mang
tính hệ thống đối với tổ chức mà việc thay đổi thường là rất khó khăn đối với
hầu hết các tổ chức và cá nhân. Một quy trình có thể kém hiệu quả và có nhiều
sai sót nhưng không hẳn tất cả mọi người đều có mong muốn thay đổi để cải
tiến quy trình, đơn giản chỉ vì họ không muốn thay đổi những thói quen hay
cách thức làm việc mà họ vẫn thường làm. Chính vì vậy, để áp dụng CMMI các
tổ chức phải đầu tư rất nhiều thời gian, chi phí và nhân lực.
Mặt khác, CMMI không phải là quy trình, nó không đưa ra các bước cụ thể
để thực hiện các hoạt động trong tổ chức. CMMI 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. Nó tập trung vào
những điều mà tổ chức nên làm, chứ không xác định cách đạt tới những mục
tiêu đó.
Trong đồ án này, em tập trung vào hai vấn đề chính:
• Kiến thức cơ bản về CMMI: Phần này trình bày các khái niệm cơ bản
về quy trình và mô hình cải tiến quy trình (CMMI)
Đồ án tốt nghiệp Đại học Tổng quan đề tài


Đặng Thị Huyền Linh −2− Lớp 2001CNTT
• Áp dụng CMMI mức 3 tại một tổ chức phát triển phần mềm cụ thể là
Vietsoftware: Trong phần này, căn cứ vào điều kiện và thực trạng sản

xuất phần mềm tại Vietsoftware để đưa ra quy trình cụ thể bao gồm:
các hoạt động (các bước) cần thực hiện, vai trò (roles) thực hiện các
hoạt động đó, các tài liệu và sản phẩm đầu vào/đầu ra (input/output)
cho một số các lĩnh vực quy trình (Process Areas) ở CMMI mức 2 và
mức 3.

Đồ án tốt nghiệp Đại học CMMI và Quy trình sản xuất phần mềm


Đặng Thị Huyền Linh −3− Lớp 2001CNTT
2. KHÁI NIỆM QUY TRÌNH SẢN XUẤT PHẦN MỀM VÀ
MỖI LIÊN HỆ GIỮA CMMI VÀ QUY TRÌNH
2.1. Khái niệm quy trình phần mềm
Phát triển phần mềm là một quy trình phức tạp, nó không chỉ đơn giản là tạo
ra các ngôn ngữ lập trình và các công cụ hiệu quả mà còn bao gồm rất nhiều nỗ
lực phức tạp. Chất lượng của một sản phẩm phần mềm được quyết định bởi con
người, tổ chức và các thủ tục để tạo nên và chuyển giao sản phẩm đó.
Trong những năm 60 và 70, các nhà nghiên cứu chủ yếu tập trung vào các
lĩnh vực:
- Phát triển các ngôn ngữ lập trình cấu trúc (ví dụ Algol, Pascal, C)
- Phát triển các nguyên tắc và phương pháp thiết kế (ví dụ như che giấu
thông tin, phân rã chức năng)
- Định nghĩa vòng đời phần mềm (Ví dụ như các mô hình thác nước, gia
tăng, dựa trên bản mẫu)
Khái niệm vòng đời phần mềm ở trên có liên quan trực tiếp với khái niệm
quy trình phần mềm. Một vòng đời phần mềm định nghĩa các giai đoạn khác
nhau trong suốt thời gian tồn tại của sản phẩm phần mềm. Thông thường các
giai đoạn đó bao gồm phân tích và đặc tả yêu cầu, thiết kế, viết code, kiểm tra
và phê duyệt, triển khai, bảo trì. Ngoài ra, vòng đời phần mềm còn đưa ra các
quy tắc và chỉ dẫn để thực hiện các pha khác nhau. Ví dụ trong mô hình thác
nước, một pha chỉ được thực hiện khi pha trước nó đã được hoàn thành. Ngược
lại, ở mô hình xoắn ốc, trước tất cả các pha đều có hoạt động phân tích rủi ro.
Nói chung, một mô hình vòng đời phần mềm thường định nghĩa bộ khung và
các chỉ dẫn mà quy trình phần mềm cần được tiến hành theo nó. Tuy nhiên, nó
không quy định chính xác thứ tự các hoạt động, tổ chức, công cụ, các thủ tục
hoạt động, các chính sách phát triển và các ràng buộc. Vì vậy vòng đời phần

mềm là điểm bắt đầu quan trọng để xác định phần mềm sẽ được phát triển như
thế nào. Tuy nhiên, áp dụng một vòng đời phần mềm nhất định cũng chưa đủ để
thực hiện và quản lý một dự án phần mềm.
Khái niệm quy trình phần mềm được xây dựng dựa trên khái niệm vòng đời.
Nó đưa ra một quan niệm sâu sắc để cấu trúc và tổ chức các các vấn đề liên
quan tới hoạt động phát triển phần mềm. Một quy trình phần mềm có thể được
định nghĩa như sau:
Quy trình phần mềm là một tập các chính sách, cơ cấu tổ chức, các công
nghệ, các thủ tục và các artifacts cần thiết để phát triển, triển khai và bảo trì một
sản phẩm phần mềm. Vì vậy, một quy trình phần mềm bao gồm rất nhiều khái
niệm:
Công nghệ phát triển phần mềm (Software development technoloty): Là các
công nghệ được sử dụng trong quy trình. Để thực hiện các hoạt động phát triển
Đồ án tốt nghiệp Đại học CMMI và Quy trình sản xuất phần mềm


Đặng Thị Huyền Linh −4− Lớp 2001CNTT
phần mềm chúng ta cần phải có công cụ, cơ sở hạ tầng và môi trường kỹ thuật.
Chúng ta cần có công nghệ thích hợp để có thể tạo ra các sản phẩm phần mềm
phức tạp đáp ứng được nhu cầu của xã hội.
Phương pháp và kỹ thuật phát triển phần mềm (Software development
methods and techniques): Là các chỉ dẫn về cách sử dụng công nghệ và cách
thực hiện các hoạt động phát triển phần mềm. Sự hỗ trợ về mặt phương pháp
luận này rất cần thiết để khai thác công nghệ một cách hiệu quả.
Các hoạt động tổ chức (Organizational behavior): Là tri thức về tổ chức và
con người. Nói chung, hoạt động phát triển phần mềm được thực hiện bởi một
nhóm phát triển và nhóm phát triển này cần được quản lý dưới một cơ cấu tổ
chức hiệu quả.
Tiếp thị và kinh tế (Marketing and economy): Phát triển phần mềm không
thể tự mình nỗ lực. Cũng như các sản phẩm khác, phần mềm cũng phải xác định

nhu cầu thực sự của khách hàng trên thị trường. Vì vậy khi hình thành các pha
khác nhau của phát triển phần mềm (Ví dụ như đặc tả yêu cầu, phát triển, triển
khai) cần phải tính đến ngữ cảnh mà sản phẩm phần mềm đó được bán và sử
dụng.
2.2. Một số quy trình phần mềm được áp dụng trong thực
tế và mối liên hệ giữa quy trình đó và CMMI
2.2.1. Mô hình RUP
2.2.1.1. RUP là gì
RUP là một quy trình phát triển lặp được xây dựng dựa trên “sáu quy cách
làm việc tốt nhất” bao gồm:
• Phát triển lặp (Develop Iteratively)
• Quản lý yêu cầu (Manage Requirement)
• Sử dụng kiến trúc thành phần (Use Component Architecture)
• Mô hình trực quan (Model Visually)
• Kiểm điểm chất lượng (Verify Quality)
• Kiểm soát các thay đổi (Control Changes)
Các đặc điểm chính của RUP là:
• Quy trình dựa trên rủi ro: Trong RUP, quản lý rủi ro được tích hợp vào
quy trình phát triển và việc lập kế hoạch các bước lặp dựa được trên các rủi
ro có mức ưu tiên cao
• Phát triển dựa trên Usecase: Tất cả các pha và bước lặp trong RUP đều
dựa trên use case. Use case là mô hình thể hiện các yêu cầu chức năng và
ngữ cảnh của hệ thống. Nó được thiết kế cho một hệ thống nhất định và
được sử dụng trong suốt quá trình phát triển hệ thống.
Đồ án tốt nghiệp Đại học CMMI và Quy trình sản xuất phần mềm


Đặng Thị Huyền Linh −5− Lớp 2001CNTT
• Các hoạt động thiết kế dựa trên kiến trúc: Đối với mô hình RUP, tất cả
các hoạt động thiết kế đều dựa trên kiến trúc. Kiến trúc là artifact cơ bản để

khái niệm hóa, xây dựng, quản lý và tạo nên hệ thống. Kiến trúc bao gồm
nhiều khung nhìn hoặc mô hình kết hợp với nhau.
Vòng đời phần mềm được chia thành nhiều chu trình, mỗi chu trình được áp
dụng cho một thế hệ sản phẩm mới. RUP chia một chu trình phát triển thành
bốn pha liên tiếp:
• Inception (Khởi đầu)
• Elaboration (Chuẩn bị)
• Construction (Xây dựng)
• Transition (Chuyển giao)
Một pha có thể được chia nhỏ thành nhiều bước lặp. Mỗi pha được kết thúc
bởi một mốc (milestone) xác định thời điểm phải tạo ra các quyết định quan
trọng và đạt được các mục tiêu chính.
Pha khởi đầu (Inception)

Trong pha này dự án cần phải được xác định, nghĩa là các tình huống
nghiệp vụ (business case) của dự án phải được thiết lập và phạm vi của dự án
cũng phải được vạch rõ. Để hoàn thành điều đó bạn phải xác định tất cả các
thực thể bên ngoài tương tác với hệ thống và xác định được bản chất của tương
tác đó ở mức cao. Điều này liên quan tới việc xác định tất cả các use case và mô
tả một số use case tiêu biểu. Business case bao gồm: tiêu chuẩn thành công,
đánh giá rủi ro, ước lượng các tài nguyên cần thiết và pha lập kế hoạch để xác
định thời điểm của các mốc chính. Các kết quả của pha khởi đầu bao gồm:
- Tài liệu tổng quan (Vision document )
- Mô hình use case ban đầu (hoàn thành khoảng 10%-20% )
- Tài liệu chú giải ban đầu của dự án (Initial project glossary )
- Tình huống nghiệp vụ ban đầu (Initial business case)
- Đánh giá rủi ro ban đầu (Initial risk assessment)
- Kế hoạch dự án (Project plan)
- Mô hình hoạt động (Business model)
- Một hoặc một vài bản mẫu

Pha chuẩn bị (Elaboration)

Mục đích của pha này là phân tích vấn đề, thiết lập cơ sở kiến trúc, phát
triển kế hoạch dự án và loại bỏ các thành phần có độ rủi ro cao trong dự án. Kết
quả của pha chuẩn bị bao gồm:
- Hoàn thành 80% mô hình Use-case
- Tài liệu yêu cầu bổ sung (supplementary requirement) bao gồm các yêu
Đồ án tốt nghiệp Đại học CMMI và Quy trình sản xuất phần mềm


Đặng Thị Huyền Linh −6− Lớp 2001CNTT
cầu phi chức năng và các yêu cầu không gắn với một use case riêng biệt
nào
- Mô tả kiến trúc phần mềm
- Bản mẫu kiến trúc có thể thực hiện được
- Danh sách rủi ro đã được duyệt lại và business case
- Kế hoạch phát triển cho toàn bộ dự án bao gồm kế hoạch dự án sơ bộ chỉ
ra các bước lặp và tiêu chuẩn ước lượng cho mỗi bước lặp
- Một trường hợp phát triển đã cập nhật (development case) chỉ rõ quy
trình được sử dụng
- Hướng dẫn sử dụng ban đầu
Pha xây dựng

Trong pha xây dựng, tất cả các thành phần và đặc tính của ứng dụng cần
phải được phát triển và tích hợp vào sản phẩm, đồng thời tất cả các đặc tính này
đều phải được kiểm thử kỹ lưỡng. Kết quả của pha xây dựng là một sản phẩm
đã sẵn sàng để trao tận tay cho người sử dụng cuối. Kết quả của pha xây dựng
phải tối thiểu bao gồm:
- Sản phẩm phần mềm được tích hợp trên một nền tương ứng
- Hướng dẫn sử dụng

- Bản mô tả phiên bản hiện thời
- Sản phẩm của pha xây dựng thường được gọi là phiên bản “beta”
Pha chuyển giao
Mục đích của pha chuyển giao là đưa sản phẩm phần mềm tới người sử
dụng.Trong pha này cần thực hiện các hoạt động:
- Chỉnh sửa lại một số đặc điểm
- Hoàn thành các đặc tính bị hoãn lại
- Thực hiện “beta-testing” để đảm bảo hệ thống mới đáp ứng được các yêu
cầu người dùng
- Chạy hệ thống mới song song với hệ thống sẽ bị thay thế
- Chuyển dữ liệu hoạt động
- Đào tạo cán bộ bảo trì
- Đưa sản phẩm ra tiếp thị và phân phối.
- Kết quả của pha chuyển giao
RUP bao gồm 9 workflow chính:
Đồ án tốt nghiệp Đại học CMMI và Quy trình sản xuất phần mềm


Đặng Thị Huyền Linh −7− Lớp 2001CNTT
Hình 2-1: Cấu trúc RUP

1. Mô hình hóa nghiệp vụ (Business modeling)
Business modeling được thực hiện trong pha khởi đầu và pha chuẩn bị.
Trong workflow này, cần viết tài liệu quy trình hoạt động, sử dụng use case để
đảm bảo sự thống nhất giữa tất cả các stakeholder về những gì cần hỗ trợ cho
quy trình hoạt động.
Mục đích của workflow này là mô tả những gì mà hệ thống phải làm, tạo ra
sự thống nhất giữa lập trình viên và khách hàng về những yêu cầu của hệ thống.
Để đạt được điểu này chúng ta cần viết tài liệu về các chức năng và ràng buộc,
theo dõi và ghi lại các quyết định.

2. Thu thập yêu cầu (Requirement)
Mục tiêu của workflow này nhằm mô tả những gì mà hệ thống cần thực hiện
và tạo sự thống nhất giữa các lập trình viên và khách hàng về những yêu cầu
này.
3. Phân tích và thiết kế (Analysis and Design)
Mục đích của workflow phân tích và thiết kế là chỉ ra hệ thống sẽ được thực
hiện như thế nào trong pha cài đặt
4. Cài đặt (Implementation)
Mục đích của pha cài đặt là viết mã và kiểm thử hệ thống
Đồ án tốt nghiệp Đại học CMMI và Quy trình sản xuất phần mềm


Đặng Thị Huyền Linh −8− Lớp 2001CNTT
5. Kiểm thử (Test)
Workflow này tạo ra và mô tả các test case, các phương pháp test
6. Triển khai (Deployment)
Đóng gói phần mềm và cài đặt phần mềm cho người sử dụng cuối
7. Quản lý cấu hình và thay đổi (Configuration and Change Management)
Giám sát và quản lý những thay đổi trong các artifact của dự án nhằm đảm
bảo sự nhất quán với các yêu cầu của hệ thống
8. Quản lý dự án (Project Management)
Quản lý dự án bao gồm: cân bằng lại các mục tiêu có mâu thuẫn với nhau,
quản lý rủi ro, khắc phục các ràng buộc để chuyển giao thành công sản phẩm,
đáp ứng được nhu cầu của cả khách hàng lẫn người sử dụng cuối.
9. Environment
Mục tiêu của workflow này là cung cấp cho tổ chức một môi trường phát
triển phần mềm – bao gồm các quy trình và công cụ cần để thiết hỗ trợ cho
nhóm phát triển.
2.2.1.2. Liên hệ giữa CMMI và RUP
Bảng 2-1 dưới đây chỉ ra mối liên hệ giữa các lĩnh vực quy trình của CMMI

với các work flow trong RUP
Bảng 2-1: Liên hệ giữa CMMI và RUP

CMMI RUP
Process management

Tập trung vào quy trình tổ chức Environment
Work flow
Định nghĩa quy trình tổ chức Environment
Đào tạo trong tổ chức Ngoài phạm vi của RUP
Thực hiện quy trình tổ chức Ngoài phạm vi của RUP
Triển khai và đổi mới tổ chức Ngoài phạm vi của RUP
Project management
Lập kế hoạch dự án
Project Management,
Environment
Theo dõi và giám sát dự án Project Management
Quản lý các thỏa thuận với nhà thầu
phụ
Ngoài phạm vi của RUP
Quản lý dự án tích hợp
Project Management,
Đồ án tốt nghiệp Đại học CMMI và Quy trình sản xuất phần mềm


Đặng Thị Huyền Linh −9− Lớp 2001CNTT
Environment
Quản lý rủi ro Project Management
Quản lý định lượng dự án Environment
Engineering

Quản lý yêu cầu Requirements
Phát triển yêu cầu
Requirement, Configuration and
Change Management, Analysis
and Design, Implementation,
Test
Giải pháp kỹ thuật
Analysis and Design,
Implementation, Deployment,
Project Management
Tích hợp sản phẩm
Implementation, Test,
Deployment, Configuration and
Change Management, Analysis
and Design
Thẩm định
Test, Implementation,
Environment
Phê duyệt
Project Management,
Deployment
Support
Quản lý cấu hình
Configuration and Change
Management
Đảm bảo chất lượng quy trình và chất
lượng sản phẩm
Project Management
Đo lường và phân tích Project Management
Phân tích quyết định và giải pháp Ngoài phạm vi của RUP

Phân tích nguyên nhân và giải pháp Project Management
2.2.2. Mô hình XP
2.2.2.1. XP là gì?
XP (eXtreme Programming) là một quy trình phát triển phần mềm được
chứng nhận bởi rất nhiều công ty thuộc nhiều lĩnh vực và có quy mô khác nhau
ở trên toàn thế giới. XP thành công bởi nó đáp ứng được đúng nhu cầu khách
hàng: chuyển giao đúng sản phẩm mà khách hàng cần vào đúng lúc mà họ cần
nó.
a. Các nguyên tắc Cơ Bản của XP
Đồ án tốt nghiệp Đại học CMMI và Quy trình sản xuất phần mềm


Đặng Thị Huyền Linh −10− Lớp 2001CNTT
XP được thiếp lập dựa trên bốn nguyên tắc sau:
Trao đổi (Communication)
: XP chú trọng việc trao đổi thông tin một cách
‘trong suốt’ giữa các thành viên trong nhóm phát triển. Đề cao việc trao đổi trực
tiếp, giảm việc trao đổi gián tiếp hay hình thức thông qua các văn bản.
• Với XP, khách hàng tham gia trực tiếp vào việc thực hiện dự án với tư
cách là một thành viên chính thức của nhóm phát triển. Khách hàng sẽ
giúp nhóm phát triển hiểu và nắm bắt được và kịp thời các yêu cầu của
người sử dụng (cũng như sự thay đổi về yêu cầu) trong suốt quá trình
thực hiện dự án
• Tất cả các thành viên đều tham gia vào mọi hoạt động trong quá trình
phát triển phần mềm. Điều này sẽ nâng cao tính năng động của toàn bộ
nhóm phát triển
Phản hồi (Feedback): phản hồi sớm và liên tục từ khách hàng cũng như từ
nhóm phát triển giúp cho dự án luôn đi theo đúng hướng. XP đều đặn giao sản
phẩm cho khách hàng để kiểm tra, theo đó khách hàng có thể ‘làm mịn’ và hoàn
thiện yêu cầu sản phẩm dựa trên các kết quả cụ thể. Với sự trợ giúp của khách

hàng, XP xây dựng một tập các phép thử phục vụ cho việc kiểm định
(acceptation test) một cách liên tục trong suốt quá trình phát triển phần mềm.
Đơn giản (Simplicity): XP đảm bảo chỉ phát triển những chức năng mà
khách hàng yêu cầu. Phần thiết kế và mã nguồn được thiết lập một cách đơn
giản nhất, cho phép có được đặc tính ‘mở’ cao nhằm đáp ứng với các thay đổi
liên tục và luôn duy trì được một tốc độ phát triển nhanh trong suốt quá trình
phát triển phần mềm.
Dũng cảm (Courage)
: XP cho rằng phải có lòng dũng cảm thì mỗi thành
viên mới thực hiện được các nguyên tắc kể trên. Tuy XP không chỉ ra một cách
rõ ràng, nhưng cũng cần phải nhấn mạnh rằng tính kỷ luật là yêu cầu quan trọng
để thực hiện có hiệu quả phương pháp phát triển phần mềm XP.
b. 12 quy cách làm việc (practices) của XP
Phương pháp XP đã đề ra 12 quy cách (practices) làm việc để thực hiện các
nguyên tắc phát triển phần mềm đã nêu ở trên. Theo các chuyên gia trong
CNPM, các quy cách làm việc đề ra bởi XP không có gì là mới. Thực chất,
những quy cách này là những kinh nghiệm hay nhất thu được trong quá trình
phát triển CNPM, đặc biệt là CNPM với công nghệ hướng đối tượng.
Lập kế hoạch (Planning process)

Với XP, khách hàng tham gia trực tiếp vào quá trình lập kế hoạch phát triển
phần mềm. Vai trò của khách hàng và nhóm phát triển được định ra một cách rõ
ràng
Trách nhiệm của khách hàng:
Đồ án tốt nghiệp Đại học CMMI và Quy trình sản xuất phần mềm


Đặng Thị Huyền Linh −11− Lớp 2001CNTT
• Mô tả tính năng phần mềm cần phát triển thông qua các ‘câu chuyện’
(user story). User story có ý nghĩa tương tự như use case trong UML

nhưng mức độ mô tả thì không chi tiết bằng.
• Phân loại các user story theo mức độ quan trọng từ quan điểm người sử
dụng (dựa trên giá trị kinh doanh-business value). Từ đó sẽ định ra tính
năng nào cần phải phát triển và phát triển theo thứ tự như thế nào.
• Định ra thời điểm và chu kỳ bàn giao sản phẩm.
Trách nhiệm của nhóm phát triển:
• Ước lượng yêu cầu kỹ thuật (để phát triển) cho từng user story (ước
lượng độ phức tạp).
• Ước lượng thời gian, nhân công cũng như giá thành để phát triển từng
user story.
Với sự phân công trách nhiệm như vậy, bản kế hoạch sẽ luôn thoả mãn được
yêu cầu của khách hàng cũng như nhóm phát triển.
Bàn giao từng phần (Small releases)
Theo quy cách này, nhóm phát triển sẽ phát triển dần dần phần mềm, từ đơn
giản đến phức tạp. Từng phần sẽ được chuyển giao cho khách hàng để có được
ngay sự phản hồi của khách hàng. Từ đó sẽ có thể điều chỉnh ngay được sản
phẩm cho phù hợp với yêu cầu của khách hàng. Khách hàng cũng có điều kiện
để bổ sung hay thay đổi yêu cầu phần mềm.
Tham gia trực tiếp của khách hàng (On-site customer)

Với XP, khách hàng sẽ tham gia một cách trực tiếp trong suốt quá trình phát
triển phần mềm. Sự tham gia này sẽ giúp cho nhóm phát triển có điều kiện tham
khảo trực tiếp ý kiến của khách hàng, trao đổi về hệ thống cần phát triển, trách
được nhầm lẫn trong cách hiểu về hệ thống cần phát triển. Mục tiêu cuối cùng
là sản phẩm làm ra phù hợp với yêu cầu của khách hàng.
Lập trình đôi (Pair programming)

Tất cả các phần chương trình do một hay nhiều nhóm hai người viết. Hai
người này sẽ sử dụng chung một máy tính, cùng đồng thời viết chương trình.
Quy cách này sẽ giúp cho có được giải pháp lập trình tốt hơn, chương trình sẽ

có chất lượng và hiệu quả hơn.
Thiết kế đơn giản (Simple design)

XP khuyến khích tìm kiếm giải pháp đơn giản nhất khi thiết kế phần mềm.
Chỉ thiết kế phần mềm thỏa mãn yêu cầu hiện tại của khách hàng, không nên
tìm kiếm một giải pháp cho một hệ thống tương lai. Theo đó, chỉ cần một thiết
kế làm sao cho chương trình chạy được vào thỏa mãn yêu cầu của khách hàng.
Tổ chức lại chương trình (Refactoring)
Đồ án tốt nghiệp Đại học CMMI và Quy trình sản xuất phần mềm


Đặng Thị Huyền Linh −12− Lớp 2001CNTT
Quan điểm của XP là chất lượng phần mềm được thể hiện bằng chất lượng
của mã nguồn (code). Một chương trình được viết rõ ràng, đơn giản thì sẽ dễ
bảo dưỡng và thay đổi. XP khuyến khích tổ chức (viết) lại chương trình một
cách đều đặn để nâng cao tính sáng sủa của chương trình, dễ bổ sung các chức
năng mới, nâng cao hiệu suất của chương trình.
Kiểm thử (Testing)

XP yêu cầu rất cao trong khâu kiểm thử và kiểm định chương trình. Với mỗi
phần của chương trình, lập trình viên phải viết chương trình kiểm thử cho phần
đó trước khi thực sự bắt đầu khi viết chương trình (cho phần đó). Khách hàng
sẽ chịu trách nhiệm thực hiện kiểm định sản phẩm.
Tích hợp liên tục (Continuous integration)

Việc tích hợp sẽ được tiến hành một cách liên tục. Khi một đoạn chương
trình mới được phát triển, đã vượt qua phần kiểm thử, thì sẽ được tích hợp ngay
vào hệ thống. Điều này sẽ giúp cho việc phát hiện và sửa lỗi tích hợp nhanh hơn
và rẻ hơn. Trong một ngày có thể thực hiện nhiều lần tích hợp hệ thống.
Sở hữu tập thể (Collective ownership)

Tất cả mã nguồn đều thuộc quyền sở hữu của mọi thành viên trong nhóm
phát triển. Theo đó, mã nguồn có thể được sửa đổi ngay khi cần. Với cách quản
lý thông thường, mỗi phần mã nguồn thường do một người quản lý, nên khi cần
sửa đổi thì phải cần sự thông qua của chủ sở hữu, đôi khi điều này gây mất
nhiều thời gian.
Chuẩn lập trình (Coding standards)

Để chương trình (mã nguồn) có thể hiểu được một cách dễ dàng, nhất là đối
với các quy cách lập trình đôi và sở hữu tập thể, nhóm phát triển phải thống
nhất cách viết chương trình. Cần phải có một quy định cụ thể, rõ ràng về cách
viết (ví dụ, cách đặt tên biến, cách bổ sung chú thích, v.v.) để làm sao tất cả đều
hiểu được.
Metaphor (Metaphor)

Nhóm phát triển XP dùng chung một hệ thống các thuật ngữ để biểu diễn hệ
thống cần phát triển. Các thuật ngữ này sẽ được dùng trong khi trao đổi giữa
các thành viên trong nhóm cũng như khi trao đổi với khách hàng.
Không làm việc quá giờ (40-hour week)

Hiện tượng làm việc quá giờ rất phổ biến trong giới phát triển phần mềm.
Thực tế cho thấy khi người lao động làm việc quá giờ thường hay mệt mỏi, dẫn
đến làm việc không hiệu quả, chất lượng sản phẩm giảm. XP khuyến cáo không
nên làm việc quá giờ, chỉ làm đúng giờ quy định để đảm bảo chất lượng sản
phẩm.
c. Điều kiện để áp dụng XP
Đồ án tốt nghiệp Đại học CMMI và Quy trình sản xuất phần mềm


Đặng Thị Huyền Linh −13− Lớp 2001CNTT

Nhóm phát triển nhỏ hơn 10 người
XP có thể áp dụng một cách có hiệu quả trong các nhóm phát triển có số
lượng nhỏ hơn 10 người (quá 10 người thì việc trao đổi giữa các thành viên sẽ
rất khó thực hiện được một cách hữu hiệu). XP đặc biệt có hiệu quả trong việc
phát triển các phần mềm có yêu cầu luôn thay đổi, khách hàng không định trước
được một cách rõ ràng yêu cầu phần mềm.
Đối với các dự án lớn, người ta có thể phân chia công việc cho từng nhóm
nhỏ XP. Tuy nhiên, cho đến nay các tác giả của XP chưa đưa ra phương án nào
để quản lý, phối hợp hoạt động của các nhóm này. Theo chúng tôi, trong trường
hợp này, có thể dựa vào ISO9001 hay CMM để thiết lập một quy trình quản lý
hoạt động của các nhóm nhỏ XP.
Làm việc theo nhóm
XP đòi hỏi phải có tính làm việc tập thể rất cao. Mọi thành viên phải có thái
độ hợp tác trong quá trình làm việc bởi vì mọi hoạt động của XP đều mang tính
tập thể.
Tính kỷ luật

Mọi thành viên phải tự giác chấp hành các quy định của nhóm phát triển. Ví
dụ, tất cả đều phải viết chương trình theo một quy định đã thống nhất. Có như
vậy thì chương trình (mã nguồn) mới có thể trong suốt và dễ hiểu với tất cả
nhóm, dẫn đến dễ sửa đổi và thêm chức năng mới vào chương trình.
Trình độ thành viên

Với XP, mọi thành viên sẽ tham gia vào mọi hoạt động trong quá trình phát
triển phần mềm. Do vậy, các thành viên cần phải được trang bị kiến thức tốt về
nhiều mặt và cần có nhiều kinh nghiệm trong nhiều lĩnh vực khác nhau.
Vai trò của khách hàng

Sự tham gia trực tiếp của khách hàng trong suốt quá trình thực hiện dự án
phần mềm là một yếu tố không thể thiếu cho sự thành bại của dự án. Khách

hàng tham gia với tư cách là một thành viên biên chế của nhóm phát triển sẽ
giúp cho nhóm luôn phát triển sản phẩm theo đúng yêu cầu của khách hàng
cũng như thoả mãn được các yêu cầu khác của khách hàng (ví dụ như thời điểm
bàn giao sản phẩm, giá thành sản phẩm, v.v.).
2.2.2.2. Liên hệ giữa CMMI và XP
Bảng 2-2 dưới đây chỉ ra quan hệ giữa các lĩnh vực quy trình của CMMI với
các quy cách làm việc (practices) trong XP

Bảng 2-2: Liên hệ giữa CMMI và XP

Đồ án tốt nghiệp Đại học CMMI và Quy trình sản xuất phần mềm


Đặng Thị Huyền Linh −14− Lớp 2001CNTT
CMMI XP
Process management

Tập trung vào quy trình tổ chức Sustainable Pace
XP Practices
Định nghĩa quy trình tổ chức
Coding Standard, Pair
Programing
Đào tạo trong tổ chức
Coding Standards, Pair
Programing
Thực hiện quy trình tổ chức Ngoài phạm vi của XP
Triển khai và đổi mới tổ chức Ngoài phạm vi của XP
Project management
Lập kế hoạch dự án Planning Game
Theo dõi và giám sát dự án Planning Game

Quản lý các thỏa thuận với nhà thầu
phụ
Ngoài phạm vi của XP
Quản lý dự án tích hợp Onsite Customer
Quản lý rủi ro Ngoài phạm vi của XP
Quản lý định lượng dự án Ngoài phạm vi của XP
Engineering
Quản lý yêu cầu Planning Game, Small Release
Phát triển yêu cầu
Metaphor, Refactoring, Onsite
Customer
Giải pháp kỹ thuật
Metaphor, Simple Design,
Refactoring
Tích hợp sản phẩm Continuos Integrated
Thẩm định Testing
Phê duyệt Testing, Onsite Customer
Support
Quản lý cấu hình
Small Release, Collective
Ownership, Continuos
Integration
Đảm bảo chất lượng quy trình và chất
lượng sản phẩm
Pair Programing
Đo lường và phân tích Ngoài phạm vi của XP
Đồ án tốt nghiệp Đại học CMMI và Quy trình sản xuất phần mềm


Đặng Thị Huyền Linh −15− Lớp 2001CNTT

Phân tích quyết
định và giải pháp
Ngoài phạm vi của XP
Phân tích nguyên nhân và giải pháp Ngoài phạm vi của XP
Đồ án tốt nghiệp Đại học Mô hình CMMI


Đặng Thị Huyền Linh −16− Lớp 2001CNTT
3. MÔ HÌNH CMMI
3.1. Khái niệm CMMI
3.1.1. Tổng quan về CMMI
3.1.1.1. Mô hình tăng trưởng năng lực (Capacity Matuirity Model)
SEI đã đưa ra một số tiêu chuẩn mà một tổ chức cần phải tập trung vào đó
để cải thiện hiệu quả hoạt động của mình. Hình 3-1 minh họa ba tiêu chuẩn
quan trọng là : con người, thủ tục và phương pháp, công cụ và thiết bị.


Hình 3-1: Ba tiêu chuẩn quan trọng đối với một quy trình

Nhưng làm thế nào để kết hợp tất cả các tiêu chuẩn này? Đó chính là các
quy trình được dùng trong các tổ chức. Quy trình cho phép đưa hoạt động của
tổ chức theo một hướng nhất định. Nó cũng cho phép bạn có thể theo dõi hoạt
động của tổ chức, đưa ra cách thức kết hợp các tri thức để tổ chức hoạt động tốt
hơn và tận dụng được hết các nguồn lực của tổ chức.
Như vậy không có nghĩa là con người và công nghệ không quan trọng.
Chúng ta đang sống trong thế giới mà công nghệ thay đổi liên tục. Cũng như
vậy các nhân viên cũng thường làm việc cho rất nhiều công ty trong suốt cuộc
đời của mình. Chúng ta đang sống trong một thế giới năng động. Việc tuân theo
quy trình sẽ tạo ra cơ sở hạ tầng cần thiết để giải quyết những thay đổi đồng
thời tăng tính cạnh tranh của đội ngũ nhân viên và công nghệ một cách tối đa.

Ngày nay, rất nhiều tổ chức hoạt động trong lĩnh vực sản xuất và dịch vụ đã
nhận thấy tầm quan trọng của các quy trình hiệu quả. Quy trình giúp mọi người
đáp ứng được mục đích hoạt động của tổ chức bằng cách giúp họ làm việc hiệu
quả hơn (chứ không phải là làm việc chăm chỉ hơn) và tăng cường tính nhất
Đồ án tốt nghiệp Đại học Mô hình CMMI


Đặng Thị Huyền Linh −17− Lớp 2001CNTT
quán. Các quy tình hiệu quả cũng đưa ra cách thức để giới thiệu và sử dụng
công nghệ mới nhằm đáp ứng một cách hiệu quả nhất đối với mục đích hoạt
động của tổ chức.
Trong những năm 1930, Walter Shewhart bắt đầu làm việc trong lĩnh vực
cải tiến quy trình và với các nguyên lý về kiểm soát chất lượng. Các nguyên lý
này sau đó đã được W.Edwards Deming và Joseph Juran cải tiến. Watts
Humphrey, Ron Radice và một số người khác đã tiếp tục mở rộng các nguyên
lý này và áp dụng chúng vào công việc của họ trong lĩnh vực phần mềm tại
IBM và SEI.
Sau đó SEI cũng bắt đầu tiến hành nghiên cứu và đưa ra các tiền đề cho lĩnh
vực quản lý quy trình, “Chất lượng của quy trình sẽ ảnh hưởng rất lớn tới chất
lượng của hệ thống hay sản phẩm được phát triển và bảo trì trên quy trình đó”,
và định nghĩa các mô hình tăng trưởng năng lực tiêu biểu cho tiền đề đó.
Các mô hình tăng trưởng năng lực (CMMs) đều tập trung vào cải tiến các
quy trình trong một tổ chức. Chúng bao gồm các thành phần chủ chốt của các
quy trình hiệu quả đối với một hoặc nhiều lĩnh vực hoạt động (discipline), mô tả
con đường phát triển từ các quy trình còn hỗn loạn tới các quy trình đã trưởng
thành với chất lượng và hiệu quả được nâng cao.
Mark Paulk và một số người khác tại SEI đã tạo ra mô hình tăng trưởng
năng lực đầu tiên cho các tổ chức phần mềm và công bố nó trong một cuốn
sách: The Capability Maturity Model: Guidelines for Improving the Software
Process.

Cuốn sách này của SEI đã đưa những nguyên lý được biết tới cách đây cả
thập kỷ để áp dụng vào chu trình bất tận của việc cải tiến quy trình. Giá trị của
mô hình này đã được xác nhận bởi rất nhiều tổ chức. Họ đã áp dụng CMM và
đã tăng năng suất và chất lượng, cải tiến chu trình, kế hoạch và ngân sách được
ước tính chính xác hơn.
3.1.1.2. Sự xuất hiện của CMMI
Từ năm 1991, CMMs đã được áp dụng ở rất nhiều lĩnh vực (disciplines).
Đáng chú ý nhất là các mô hình áp dụng cho kỹ nghệ hệ thống, kỹ nghệ phần
mềm, software acquisition, quản lý và phát triển nguồn nhân lực, phát triển quy
trình và sản phẩm tích hợp.
Mặc dù các mô hình này đã được chứng minh là rất hữu ích đối với rất
nhiều tổ chức nhưng việc sử dụng nhiều mô hình cũng tạo ra những khó khăn
nhất định. Đó là khi nhiều tổ chức muốn đồng thời tập trung các nỗ lực cải tiến
quy trình chất lượng trên nhiều lĩnh vực khác nhau trong tổ chức của mình. Khi
đó sự khác biệt giữa các lĩnh vực (discipline) – các mô hình chuyên biệt, bao
gồm kiến trúc, nội dung và cách tiếp cận đã hạn chế khả năng của tổ chức đối
với việc cải tiến quy trình. Hơn thế nữa, việc áp dụng nhiều mô hình trong một
tổ chức cũng khiến cho các hoạt động đào tạo, đánh giá và cải tiến quy trình trở
nên tốn kém hơn. Như vậy, cần có một bộ các mô hình đồng thời áp dụng được
Đồ án tốt nghiệp Đại học Mô hình CMMI


Đặng Thị Huyền Linh −18− Lớp 2001CNTT
cho nhiều lĩnh vực. Bộ các mô hình đó đã được SEI cho ra đời với tên CMMI
(CMM Integration).
Dự án CMM Integration
SM
được tiến hành nhằm giải quyết các vấn đề khi
sử dụng nhiều mô hình CMM. Nhiệm vụ của nhóm dự án là phải kết hợp 3 mô
hình:

1. The Capability Maturity Model for Software (SW-CMM) v2.0 draft C
2. The Systems Engineering Capability Model (SECM)
3. The Integrated Product Development Capability Maturity Model (IPD-
CMM) v 0.98
Ba mô hình trên được chọn vì đó là các mô hình được sử dụng rộng rãi
trong lĩnh vực phần mềm, kỹ nghệ hệ thống và mỗi mô hình có cách tiếp cận
khác nhau đối với việc cải tiến quy trình trong một tổ chức.
Tuy nhiên, CMMI không phải chỉ là kết quả của sự cộng gộp đơn giản từ
các mô hình gốc nêu trên. Nó đã được phát triển để là một khuôn dạng chuẩn -
framework cho rất nhiều lĩnh vực khác nhau, và nó có thể được áp dụng rất linh
hoạt với 2 hình thức: phân đoạn (staged representation) và liên tục (continuous
representation). CMMI có thể được áp dụng cho những tổ chức đã sử dụng các
mô hình CMM, cũng có thể được áp dụng cho các tổ chức chưa từng biết đến
CMM.
Trong quá trình phát triển CMMI, người ta cũng đã tính đến việc sẽ tích hợp
thêm các mô hình CMMI mới cho các lĩnh vực khác trong tương lai. Người ta
cũng đã đặt mục tiêu đảm bảo rằng những sản phẩm được phát triển theo các
mô hình CMMI sẽ thống nhất và tương thích với tiêu chuẩn ISO/IEC 15504 cho
đánh giá qui trình phần mềm.
Tất cả những điều đó, cộng với việc SEI nhận được vô vàn ý kiến góp ý từ
nhiều nơi trên thế giới qua từng phiên bản CMMI, đã làm cho CMMI trở thành
một mô hình thiết lập và cải tiến qui trình tiên tiến, xứng đáng là xu thế lựa
chọn gần như tất yếu trong CNPM, và đã được SEI quyết định hoàn toàn thay
thế cho CMM từ sau năm 2005.
Như vậy là, việc thiết lập một quy trình quản trị chất lượng đang trở thành
một yêu cầu không thể thiếu được cho sự tồn tại và phát triển của các đơn vị và
tổ chức hoạt động trong lĩnh vực dịch vụ CNTT (cung cấp giải pháp tin học, tư
vấn, phát triển, thu nhận phần mềm, v.v.). Trong xu thế toàn cầu hoá, các tổ
chức đạt được các tiêu chuẩn chất lượng như ISO9001 hay CMM đã và đang có
nhiều lợi thế trong việc thu hút khách hàng và thâm nhập thị trường. Cùng với

sự ra đời của CMMI và với sự hỗ trợ tuyệt đối của tổ chức sinh ra nó là SEI, các
tổ chức đó đã, đang và sẽ chuyển dần sang việc áp dụng CMMI. Còn những tổ
chức chưa đạt được các tiêu chuẩn chất lượng như ISO9001, CMM có xu thế
bắt đầu từ nghiên cứu và áp dụng CMMI.
Thiết nghĩ, nền CNPM nước ta hiện nay đang hướng mục tiêu vào xuất khẩu
phần mềm và xây dựng những hệ thống thông tin lớn có độ phức tạp cao, do
Đồ án tốt nghiệp Đại học Mô hình CMMI


Đặng Thị Huyền Linh −19− Lớp 2001CNTT
vậy các tổ chức sản xuất phần mềm đang có nhu cầu bức thiết về việc tuân theo
một qui trình sản xuất có chất lượng, thì cũng nên xem xét và đầu tư vào việc
phổ biến và cài đặt các mô hình CMMI.
3.1.2. Cấu trúc CMMI
3.1.2.1. Biểu diễn CMMI
3.1.2.1.1. Mô hình phân tầng (Staged model)
Mô hình phân tầng (Staged model) đưa ra một lộ trình xác định cho việc cải
tiến tổ chức dựa trên việc nhóm và sắp xếp các quy trình và các mối quan hệ
liên kết về mặt tổ chức giữa các quy trình đó. Mô hình được mô tả trong lộ trình
này là một chuỗi các bước (stages) hay còn gọi là các mức độ tăng trưởng
(matuirity level). Mỗi mức tăng trưởng bao gồm một tập các lĩnh vực quy trình
chỉ ra các lĩnh vực mà tổ chức cần phải tập trung vào đó để cải tiến quy trình
của tổ chức. Mỗi lĩnh vực quy trình lại bao gồm các practices (quy cách làm
việc) mô tả cơ sở hạ tầng và các hoạt động nhằm góp phần đạt được mục đích
của lĩnh vực quy trình đó. Khi đã đạt được mục tiêu của tất cả các lĩnh vực quy
trình trong một mức tăng trưởng thì quy trình của tổ chức cũng có sự tiến bộ rõ
rệt.
CMM cho lĩnh vực phần mềm là một ví dụ cơ bản đối với mô hình phân
tầng. Hình 3-2 là CMM cho lĩnh vực phần mềm với năm bước và bảng 3-1 là
các KPAs trong mỗi bước.

Hình 3-2: Các bước của mô hình CMM cho phần mềm
Các KPA ở mức 2 của CMM-sw tập trung vào các vấn đề của dự án phần
mềm liên quan tới việc thiết lập các kiểm soát cơ bản đối với quản lý dự án.
Mức 3 tập trung vào các vấn đề ở cả mức dự án và tổ chức, ví dụ như việc thiết
lập một cơ sở hạ tầng để thực hiện kỹ nghệ phần mềm hiệu quả và các quy trình
quản lý trong tất cả các dự án. Các KPA ở mức 4 lại tập trung vào việc thiết lập
một sự hiểu biết rộng rãi đối với cả quy trình phần mềm và các sản phẩm phần