luận văn: nghiên cứu hướng áp dụng mô hình CMMI ở các doanh nghiệp phần mềm vừa và nhỏ

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
_____________

______________




HÀ MẠNH TUYẾN



NGHIÊN CỨU HƯỚNG ÁP DỤNG MÔ HÌNH CMMI
Ở CÁC DOANH NGHIỆP PHẦN MỀM VỪA VÀ NHỎ


Ngành: Công nghệ thông tin
Chuyên ngành: Kỹ thuật phần mềm
Mã số: 60480103


LUẬN VĂN THẠC SĨ KỸ THUẬT CÔNG NGHỆ THÔNG TIN



NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS.TS NGUYỄN NGỌC BÌNH

Hà Nội – 2014

i
LỜI CẢM ƠN
Để hoàn thành được luận văn này tôi đã nhận được sự giúp đỡ tận tình của các
thầy cô giáo trong trường Đại học Công nghệ - Đại họcQuốc gia Hà Nội, các chuyên
gia, các bạn bè đồng nghiệp và gia đình.
Tôi xin gửi lờicảm ơn tới thầy giáo PGS.TS Nguyễn Ngọc Bình, ngườiđã tận
tình hướng dẫn, truyền đạt cho tôi kiến thức và kinh nghiệm thực tiễn quý báu để tôi
hoàn thành luận văn này.
Xin chân thành cảm ơn sự giúp đỡ, động viên và chỉ bảo rất nhiệt tình của
ôngPhan Thế Đại (Trung tâm CNTT, chi nhánh Tập đoàn Điện lực Việt Nam), ông
Ngô Văn Toàn (Phó Tổng Giám đốc công ty Global Cybersoft Việt Nam), bà Hoàng A
Na (Công ty Cổ phần Giải pháp Phần mềm Tài chính - FSS), ông Nguyễn Thành Châu
(Chuyên gia tư vấn và đào tạo cấp tập đoàn ECCI Group)và sự cổ vũ động viên của
bạn bè, đồng nghiệp và người thân trong gia đình trong suốt thời gian thực hiện luận
văn.
Dù đã cố gắng trong việc nghiên cứu và hoàn thiện luận văn, song luận văn
không tránh khỏi những thiếu sót. Tôi rất mong nhận được ý kiến góp ý từ quý thầy cô
và các bạn.

ii
LỜI CAM ĐOAN

Tôi cam đoan việc nghiên cứuhướng áp dụng mô hình CMMI ở các doanh
nghiệp vừa và nhỏ được trình bày trong luận văn là do chính tôi thực hiện dưới sự
hướng dẫn của PGS.TS Nguyễn Ngọc Bình.
Các kết quả nêu trong luận văn là trung thực, các đề xuất trong luận văn là do
chính tôi thực hiện qua nghiên cứu thực nghiệm đưa ra và không sao chép tài liệu,

công trình nghiên cứu của người khác mà không chỉ rõ tài liệu tham khảo.

Hà Nội, ngày … tháng 12 năm 2014
Tác giả




Hà Mạnh Tuyến
iii
MỤC LỤC
LỜI CẢM ƠN i
LỜI CAM ĐOAN ii
MỤC LỤC iii
DANH MỤC CÁC BẢNG v
DANH MỤC HÌNH VẼ, ĐỒ THỊ vi
DANH MỤC CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT vii
MỞ ĐẦU 1
CHƯƠNG 1 GIỚI THIỆU TỔNG QUAN 3
1.1. Tổng quan về cải tiến quy trình phần mềm 3
1.1.1. Quy trình phát triển phần mềm 3
1.1.2. Cải tiến quy trình phần mềm 3
1.2. Doanh nghiệp có quy mô vừa và nhỏ 3
1.3. Vấn đề cải tiến quy trình phần mềm tại các doanh nghiệp vừa và nhỏ 4
1.4. Một số chu trình phát triển phần mềm cơ bản 4
1.5. Giới thiệu tổng quan về CMM/CMMI 7
1.5.1. Mô hình trưởng thành năng lực 7
1.5.2. Mô hình trưởng thành năng lực tích hợp 8
1.5.3. Hướng tiếp cận liên tục và mức năng lực quy trình 14
1.5.4. Hướng tiếp cận theo tầng và mức trưởng thành 16

1.5.5. Mối quan hệ giữa mức năng lực và mức trưởng thành 19
1.6. So sánh mô hình CMMI với ISO 9001 20
1.7. Phương pháp đánh giá SCAMPI 20
1.8. Tình hình áp dụng CMMI tại Việt Nam và nước ngoài 21
1.9. Một số mô hình cải tiến quy trình được đề xuất áp dụng đối với doanh
nghiệp vừa và nhỏ trên thế giới 23
CHƯƠNG 2 KINH NGHIỆM ÁP DỤNG CMM/CMMI TẠI VIỆT NAM VÀ NƯỚC
NGOÀI 26
2.1. Kinh nghiệm áp dụng tại một số công ty tại Việt Nam 26
2.1.1. Kinh nghiệm áp dụng tại FPT SOFTWARE (FSOFT) 26
2.1.2. Kinh nghiệm áp dụng tại công ty PSV 27
2.1.3. Kinh nghiệm cải tiến quy trình tại CMC SOFT 29
2.2. Kinh nghiệm áp dụng tại một số công ty nước ngoài 31
2.2.1. Kinh nghiệm áp dụng CMMI tại công ty công nghệ KoreaStore 31
2.2.2. Kinh nghiệm áp dụng CMMI tại RTI 33
CHƯƠNG 3 ĐỀ XUẤT HƯỚNG ÁP DỤNG MÔ HÌNH CMMI CHO DOANH
NGHIỆP TẠI VIỆT NAM 34
3.1. Xác định vùng quy trình "Cốt lõi" 34
3.2. Xây dựng mô hình áp dụng 38
3.2.1. Khởi động 40
iv
3.2.2. Lập kế hoạch 41
3.2.3. Định nghĩa quy trình 41
3.2.4. Triển khai 42
CHƯƠNG 4 TRIỂN KHAI ÁP DỤNG VÀ ĐÁNH GIÁ 44
4.1. Khởi động 44
4.2. Lập kế hoạch 45
4.3. Định nghĩa quy trình 45
4.4. Triển khai 51
4.5. Đánh giá kết quả triển khai CMMI tại EVNIT 51

KẾT LUẬN 53
TÀI LIỆU THAM KHẢO 54
PHỤ LỤC 1. MỘT SỐ LỢI ÍCH ĐẠT ĐƯỢC KHI ÁP DỤNG CMMI 57
TẠI EVNIT 57
PHỤ LỤC 2. MỘT SỐ CÔNG CỤ HỖ TRỢ CHO PHÁT TRIỂN PHẦN MỀM 59
PHỤ LỤC 3. ĐÁNH GIÁ NĂNG LỰC QUY TRÌNH CỦA EVNIT THEO CMMI
CẤP ĐỘ 2 60
PHỤ LỤC 4. MỘT SỐ CÂU HỎI THẢO LUẬN 62



v
DANH MỤC CÁC BẢNG

Bảng 1.1: Các cấp độ của mô hình CMM 8

Bảng 1.2: Mối liên quan giữa các vùng quy trình trong CMMI 11

Bảng 1.3: Các mục tiêu chung trong mô hình CMMI [27] 12

Bảng 1.4: Các mục tiêu cụ thể và quy tắc thực tiễn cụ thể của vùng quy trình lập
kế hoạch dự án [27] 13

Bảng 1.5: Bảng phân loại vùng quy trình theo hướng tiếp cận liên tục 15

Bảng 1.6: Danh sách các vùng quy trình theo cấp độ trưởng thành [27] 18

Bảng 1.7: So sánh giữa các cấp độ đánh giá của SCAMPI [6] 21

Bảng 2.1: Các công cụ được sử dụng CMMI tại KoreStone 31

Bảng 3.1: So sánh các mô hình cải tiến quy trình phát triển phần mềm được đề
xuất cho doanh nghiệp vừa và nhỏ trên thế giới 34

Bảng 3.2: Tần suất xuất hiện của các vùng quy trình của CMMI trong các mô
hình cải tiến quy trình được đề xuất áp dụng trên thế giới 35

Bảng 3.3: Số lần xuất hiện của các vùng quy trình của CMMI trong các mô hình
cải tiến quy trình được đề xuất áp dụng trên thế giới, phân theo nhóm 36

Bảng 3.4: Các vùng quy trình được sử dụng trong mô hình CMM-VSME 38

Bảng 3.5: Phân bổ các vùng quy trình theo nhóm 39

vi
DANH MỤC HÌNH VẼ, ĐỒ THỊ

Hình 1.1: Mô hình thác nước 5

Hình 1.2: Mô hình V 5

Hình 1.3: Mô hình bản mẫu [19] 6

Hình 1.4: Mô hình xoắn ốc 7

Hình 1.5: Các thành phần trong mô hình CMMI [25] 11

Hình 1.6: Hướng tiếp cận CMMI theo liên tục [25] 14

Hình 1.7: Hướng tiếp cận CMMI theo phân tầng [25] 16

Hình 1.8: Các cấp độ trưởng thành trong CMMI 17

Hình 1.9: Biểu đồ so sánh số lượng chứng chỉ CMMI của các quốc gia trong khu vực
Đông Nam Á còn hiệu lực đến 10/2014 22

Hình 1.10: Biểu đồ thống kê số lượng chứng chỉ CMMI tại Việt Nam từ năm 2007 –
2013 22

Hình 1.11: Biểu đồ thống kê số lượng chứng chỉ CMMI trên thế giới từ năm 2007 –
2013 23

Hình 1.12: Biểu đồ thống kê 10 quốc gia có số chứng chỉ CMMI cao nhất 23

Hình 2.1: Khung quy trình phát triển phần mềm của CMC 30

Hình 2.2: Mô hình triển khai CMMI tại KoreStone 32

Hình 3.1: Mối liên quan giữa bốn vùng quy trình "cốt lõi" với các vùng quy trình khác
của mô hình CMMI 37

Hình 3.2: Kiến trúc tổng quan của mô hình CMMI-VSME 39

Hình 3.3: Các bước thực hiện triển khai áp dụng mô hình CMMI-VSME 40

Hình 3.4: Mô hình tổ chức các bộ phận 40

Hình 3.5: Ví dụ về kế hoạch tổng thể 41

Hình 4.1: Mô hình tổ chức đề xuất cho EVNIT 44

Hình 4.2: Sơ đồ quy trình lập kế hoạch và quản lý dự án 46

Hình 4.3: Sơ đồ trạng thái yêu cầu 46

Hình 4.4: Quy trình đào tạo 47

Hình 4.5: Sơ đồ quy trình phân tích và thiết kế 48

Hình 4.6: Sơ đồ quy trình kiểm thử 49

Hình 4.7: Sơ đồ quy trình quản lý cấu hình 50

vii
DANH MỤC CÁC KÝ HIỆU VÀ CHỮVIẾT TẮT
Từ viết tắt/ Thuật ngữ Giải nghĩa
CMM (Capability Maturity
Model)
Mô hình trưởng thành năng lực
CMMI (Capability Maturity
Model Integration)
Mô hình trưởng thành năng lực tích hợp
CMMI-VSME (CMMI for
Vietnamese Small Medium
Enterprise)
Mô hình áp dụng CMMI cho doanh nghiệp vừa
và nhỏ do tác giả đề xuất
GG (Generic Goal) Mục tiêu chung (Mục tiêu tổng quát)
GP (Generic Practice) Quy tắc thực tiễn chung
ISO (International Organization

for Standardization)
Tổ chức tiêu chuẩn quốc tế, ISO
PA (Process Area) Vùng quy trình (Vùng tiến trình)
Process Quy trình (Tiến trình)
QA (Quality Assurance) Đảm bảo chất lượng
QC (Quality Control) Kiểm soát chất lượng
SCAMPI (Standard CMMI
Appraisal Method for Process
Improvement)
Phương pháp đánh giá năng lực quy trình của tổ
chức theo mô hình CMMI
SEI (Software Engineering
Institute)
Viện Công nghệ Phần mềm Mỹ
SEPG (Software Engineering
Process Group)
Nhóm xây dựng, cải tiến quy trình phần mềm
SG (Specific Goal) Mục tiêu cụ thể (Mục tiêu chuyên biệt)
SP (Specific Practice)
Quy tắc thực tiễn cụ thể (Quy tắc thực tiễn
chuyên biệt)
1
MỞ ĐẦU
Trong những năm gần đây, ngành công nghiệp phần mềm Việt Nam đã có sự
tăng trưởng mạnh về số lượng và quy mô của nhiều doanh nghiệp phần mềm.Theo số
liệu thống kê năm 2011, cả nước có 1.500 doanh nghiệp phần mềm với số lượng nhân
lực khoảng gần 79.000 người lao động. Tuy nhiên đa số các doanh nghiệp phần mềm
tại Việt Nam là các công ty vừa và nhỏ[20],theo Hiệp hội Doanh nghiệp Vừa và Nhỏ
Việt Nam (VINASME), có đến 96% doanh nghiệp đăng ký ở Việt Nam là doanh
nghiệp vừa và nhỏ. Các doanh nghiệp vừa và nhỏ với năng lực cạnh tranh còn hạn chế,

hệ thống quy trình sản xuất và quản lý chất lượng chưa được quan tâm đúng mức,
thiếu năng lực cạnh tranh[3].Ngành công nghiệp phần mềm Việt Nam vẫn còn nhiều
thách thức nội tại như quy mô còn nhỏ, khan hiếm nguồn nhân lực, chất lượng sản
phẩm không cao và năng lực tiếp thị còn kém.
Nhận thấy điểm yếu của mình, một số doanh nghiệp đã bắt đầu quan tâm tới
chất lượng và cải tiến hệ thống quy trình phát triển phần mềm, các doanh nghiệp đã tự
trang bị cho mình các chứng chỉ quốc tế như ISO 9001[15]hay CMMI[25]. Một trong
những mô hình được sử dụng phổ biến hiện nay phải kể đến là mô hình CMMI.
Trên thế giới, mô hình CMMI được áp dụng khá phổ biến ở các doanh nghiệp
sản xuất phần mềm, áp dụng CMMI thành cônggiúp tạo ra môi trường làm việc
chuyên nghiệp, cải tiến quy trình sản xuất, nâng cao hiệu quả công việc, hạn chế lỗi
xảy ra, giảm thời gian xử lý lỗi [18],[21], tăng chất lượng sản phẩm vàtối ưu hoá chi
phí. Theo số liệu thống kê trên trang Web của viện SEI, một số quốc gia dẫn đầu về số
lượng chứng chỉ CMMI như Trung Quốc, Mỹ, Ấn độ, Tây Ban Nha, Nhật Bản,
Ở Việt Nam,trong mấy năm qua, nhiều doanh nghiệp phần mềm đang nỗ lực
nâng cao quy trình đảm bảo chất lượng và trình độ công nghệ sản xuất. Tuy nhiên,
việc áp dụng các tiêu chuẩn quản lý chất lượng vẫn còn rất hạn chế. Chủ yếu là các
doanh nghiệp lớncó tiềm lực tài chính, hoặc doanh nghiệp có vốn đầu tư nước ngoài
mới quan tâm đúng mức đến việc đầu tư, xây dựng và triển khai các tiêu chuẩn quản lý
chất lượng quốc tế[3]. Một số doanh nghiệp đi đầu trong việc triển khai áp dụng
CMM/CMMI phải kể đến là: PSV, FPT, GCS Vietnam, Viettel, TMA, CMC Software,
Cácdoanh nghiệp phần mềmcó quy mô vừa và nhỏ, nguồnnhân lực và tài chính hạn
chếthường gặp khó khăn khi tự triển khai áp dụng mô hình CMM/CMMI mà không
được sự hỗ trợ từ tổ chức tư vấn [3],[13].
Một câu hỏi đặt ra: "Hướng áp dụng nào phù hợp cho các doanh nghiệp vừa và
nhỏ ở Việt nam trong quá trình triển khai áp dụng mô hình CMMI". Đề tài này nghiên
cứu tìm hiểu về mô hình CMMI đểđưa rahướng áp dụng triển khai mô hình CMMI-
DEV v1.3 cho doanh nghiệp phần mềm có quy mô vừa và nhỏ, và áp dụng thí điểm
đối với đơn vị hoạt động trong lĩnh vực phát triển phần mềmlàTrung tâm Công nghệ
thông tin – Chi nhánh Tập đoàn điện lực Việt nam.

Để giải quyết bài toán này, tác giả tiến hànhnghiên cứu một số mô hình được đề
2
xuất áp dụng cho doanh nghiệp vừa và nhỏ trên thế giới, bên cạnh đó kết hợp thông
qua các bài học kinh nghiệm triển khai của các doanh nghiệp ở Việt Nam đã áp dụng
thành công CMMI, tìm hiểu các khó khăn vướng mắc của các doanh nghiệp vừa và
nhỏ ở Việt Nam khi muốn cải tiến quy trình sản xuất. Từ đóđề xuất ra một hướng tiếp
cận cho việc cải tiến quy trình phát triển theo mô hình CMMI cho các doanh nghiệp
vừa và nhỏ tại Việt Nam.
Bố cục luận văn gồm các phần chính sau đây:
Chương 1: Giới thiệu một số khái niệm tổng quan về quy trình và cải tiến quy
trình phát triển phần mềm, các vấn đề gặp phải đối với doanh nghiệp vừa và nhỏ trong
cải tiến quy trình phát triển. Giới thiệu tổng quan về mô hình CMM/CMMI và tình
hình áp dụngtại một số đơn vị trong và ngoài nước.
Chương 2:Giới thiệu bài học kinh nghiệm triển khai áp dụng mô hình CMMI
của một số doanh nghiệp phần mềm tại Việt Nam và nước ngoài.
Chương 3: Đề xuất hướng áp dụng mô hình CMMI cho doanh nghiệp phần
mềm có quy mô vừa và nhỏ tại Việt Nam.
Chương 4: Triển khai áp dụng thử nghiệm theo hướng đề xuất cho Trung tâm
Công nghệ thông tin và đánh giá kết quả.
Kết luận: Tóm tắt các kết quả đã đạt được, chưa đạt được và định hướng
nghiên cứu tiếp theo.
3
CHƯƠNG 1

GIỚI THIỆUTỔNG QUAN
1.1. Tổng quan về cải tiến quy trình phần mềm
1.1.1. Quy trình phát triển phần mềm
Quy trình phát triển phần mềm (Software Development Process)bao gồm một
tập hợp các hoạt động, phương pháp, quy tắc thực tiễn được sử dụng bởi con người để
phát triển, bảo trì phần mềm cùng với các sản phẩm kèm theo[4]. Để xây dựng được

phần mềm,thông thường phải trải qua nhiều giai đoạn,trình tự thực hiện các giai đoạn
này được gọi là chu trình hay vòng đời phát triển phần mềm(SLC - Software Life
Cycle). Có nhiều chu trình phát triển phần mềm khác nhau, trong đó cómột số chu
trình phát triển phần mềm cơ bản như Mô hình thác nước, Mô hình V, Mô hình bản
mẫu, Mô hình xoắn ốc, .v.v Các mô hình này được giới thiệu chi tiết hơn tại mục 1.4.
Khi một tổ chức sản xuất phần mềm đạt mức độ trưởng thành cao, quy trình
phát triển phần mềm của họ được định nghĩa tốt hơn, được triển khai xuyên suốt trong
môi trường làm việc của họ. Chất lượng phần mềm phụ thuộc rất lớn vào chất lượng
của quy trình được sử dụng để phát triển và bảo trì phần mềm. Một quy trình phát triển
phần mềm hiệu quả sẽ tích hợp chặt chẽ con người, các công cụ hỗ trợ, và các phương
pháp được vận dụng[4].
1.1.2. Cải tiến quy trình phần mềm
Có một liên kết chặt chẽ giữa chất lượng của một quy trình phát triển và chất
lượng của các sản phẩm phát triển sử dụng quy trình đó.Nhiều tổ chức sản xuất phần
mềm đã chuyển sang cải tiến tiến trình làm phần mềm như một cách để nâng cao chất
lượng phần mềm của họ. Quy trình cải tiến có nghĩa là sự hiểu biết các quy trình hiện
có và thay đổi các quy trình này tăng để chất lượng sản phẩm làm giảm chi phí và thời
gian phát triển. Cải tiến qui trình không chỉ đơn giản là việc áp dụng các phương pháp
cụ thể, các công cụ hoặc sử dụng một số mô hình của một quá trình đã được sử dụng ở
nơi khác.Cải tiến qui trình là một hoạt động mang tính chu kỳ, nó liên quan đến ba giai
đoạn chính: (1) Quy trình đo lường; (2) Quy trình phân tích; (3) Quá trình thay đổi.
Các quá trình này là riêng biệt. Mỗi giai đoạn của quá trình này có thể kéo dài nhiều
tháng,cả quá trình cải tiến là một hoạt động lâu dài và liên tục[4].
1.2. Doanh nghiệp có quy mô vừa và nhỏ
Thuật ngữ "vừa" và "nhỏ" thường đượcđề cập đến số lượng lao động trong tổ
chức doanh nghiệp, tại các quốc gia khác nhau có quy định về số lượng khác nhau.
Các công ty có quy mô vừa và nhỏ tại các quốc gia thuộc khối liên minh Châu âu giới
hạn 250 lao động, ở Mỹ quy định tối đa là 500 lao động, còn một vài quốc gia khác thì
giới hạn con số 200 lao động [14]. Ở Việt Nam, theo Nghị định số 56/2009/NĐ-CP thì
doanh nghiệp nhỏ và vừa là những doanh nghiệp có số lượng lao động tối đa 300

4
người hoặc quy mô vốn tối đa 100 tỷ đồng. Cụ thể: số lượng lao động trung bình hàng
năm từ 10 người trở xuống được coi là doanh nghiệp siêu nhỏ, từ 10 đến dưới 200
người lao động hoặc quy mô vốn dưới 20 tỷ đồng được coi là doanh nghiệp nhỏ; từ
200 đến 300 lao động hoặc quy mô vốn từ trên 20 - 100 tỷ đồng là doanh nghiệp vừa.
1.3. Vấn đề cải tiến quy trình phần mềm tại các doanh nghiệp vừa và nhỏ
Theo một số nghiên cứu cho thấy việc cải tiến quy trình phát triển theo mô hình
CMMI trong doanh nghiệp thường gặp phải một số vấn đề như thiếu kinh phí, thiếu
nguồn lực, thiếu sự quyết tâm của lãnh đạo [5],[12],[13],[17]. Bên cạnh đó, các doanh
nghiệp cũng thiếu kinh nghiệm và các kỹ năng cần thiết để bắt đầu cuộc hành trình
"Cải tiến chất lượng"[5]. Mặc dù việc cải tiến là cần thiết và người quản lý cấp cao của
doanh nghiệp cũng nhận thức được điều này và họ sẵn sàng cải tiến quy trình sản xuất
hiện tại, tuy nhiên họ lại thiếuhướng dẫn và phương pháp tiếp cận cho các dự án cải
tiến quy trình sản xuất, dẫn đến hiệu quả áp dụng chưa cao.Một số doanh nghiệp chưa
muốn cải tiến quy trình theo mô hình CMMI, họ thường nghĩ rằng chi phí để cải tiến
quy trình theo CMMI là tốn kém và không thấy được hiệu quả rõ ràng mà CMMI
mang lại cho doanh nghiệp mình [12]. Những vấn đề thường gặp phải ở các doanh
nghiệp vừa và nhỏ khi cải tiến quy trình phát triển phần mềm[5]:
Nguồn lực bị giới hạn: Việc thực hiện đúng theo các yêu cầu kỹ thuật về công
nghệ nghệ phần mềm là nhiệm vụ khó khăn đối với các tổ chức, doanh nghiệp có
nguồn lực và thời gian hạn chế.
Các vấn đề văn hóa, nhận thức: Việc thay đổi văn hoá, nhận thức của lãnh đạo
và nhân viên thường rất khó khăn, tâm lý ngại đổi mới khiến cho việc cải tiến quy
trình gặp khó khăn.
Các ràng buộc về thời gian và chi phí: Với nguồn ngân sách hạn chế khiến cho
việc thực hiện cải tiến gặp khó khăn, đây là một hạn chế quan trọng ảnh hưởng tới việc
cải tiến quy trình.
1.4. Một số chu trình phát triển phần mềm cơ bản
Mô hình thác nước (Waterfall)[6]:Đây là mô hình phát triển phần mềm phổ
biến được dùng nhiều tại các tổ chức phát triển phần mềm. Tư tưởng của mô hình là

quá trình phát triển được thực hiện theo dòng chảy tuần tự và tuyến tính, giai đoạn sau
chỉ được thực hiện khi giai đoạn trước đó được hoàn thành. Mô hình thác nước trong
Hình 1.1, có 7 giai đoạn bao gồm: Xác định yêu cầu hệ thống, Xác định yêu cầu phần
mềm, Thiết kế căn bản, Thiết kế chi tiết, Lập trình, Kiểm thử, Vận hành bảo trì.
5
Xác định yêu
cầu hệ thống
Xác định yêu
cầu phần mềm
Thiết kế căn bản
Thiết kế chi tiết
Lập trình
Kiểm thử
Vận hành bảo trì

Hình 1.1: Mô hình thác nước
Ưu điểm của mô hình này dễ dàng sử dụng, dễ dàng sắp xếp công việc, định
nghĩa các giai đoạn rõ ràng và không bị chồng chéo. Điểm hạn chế của mô hình thác
nước nằm ở chỗ người dùng chỉ có thể đánh giá được chất lượng ở pha cuối cùng,
không cho phép người dùng thay đổi yêu cầu khi dự án đã bắt đầu thực hiện, có nhiều
rủi ro trong quá trình thực hiện. Điều đó có nghĩa là mô hình thác nước không thích
hợp sử dụng khi không thể xác định rõ ràng yêu cầu của khách hàng hoặc những yêu
cầu có thể thay đổi trong quá trình tiến hành dự án[19].
Mô hình V (V – Model): Mô hình V là phiên bản mở rộng của mô hình thác
nước, tư tưởng chủ đạo của mô hình này là hoạt động phát triển và kiểm thử phải được
tiến hành song song với nhau ngay từ những bước đầu cho đến khi kết thúc.
Đặc tả yêu cầu
Thiết kế kiến
trúc
Thiết kế chi tiết

Mã hóa
Kiểm thử đơn vị
Kiểm thử tích
hợp
Kiểm thử hệ
thống
Phát triển Kiểm thử

Hình 1.2: Mô hình V
Hình 1.2 minh họa các các bước thực hiện trong mô hình V, toàn bộ quy trình
được chia thành hai nhóm giai đoạn tương ứng nhau: giai đoạn phát triển và kiểm thử,
mỗi giai đoạn phát triển sẽ được kết hợp với một giai đoạn kiểm thử tương ứng.
6
Mô hình bản mẫu (Prototyping Model)[19]: Mô hình bản mẫu (prototype) được
minh hoạ trongHình 1.3,trong đó, quy 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.Sau đó, thực hiện thiết kế nhanh bản mẫu, xây dựng bản mẫu và trình
bày với khách hàng và lấy ý kiến về bản mẫu, tiếp theo đến bước chỉnh sửa bản mẫu
theo ý kiến của khách hàng. Tiếp theo sau giai đoạn làm bản mẫu có thể là một chu
trình theo mô hình thác nước hay cũng có thể là mô hình khác.
Lấy yêu cầu của
khách hàng
Khách kiểm tra
bản mẫu
Thiết kế nhanh
bản mẫu
Xây dựng bản
mẫu
Chỉnh sửa bản

mẫu
Bắt đầu
Kết thúc

Hình 1.3: Mô hình bản mẫu[19]
Ưu điểm của mô hình bản mẫu là đưa được người dùng cùng tham gia vào quá
trình phát triển, người dùng hiểu hơn về các yêu cầu của mình về các chức năng của
phần mềm qua đó có những đề xuất, sửa đổi sát với yêu cầu hơn, mô hình bản mẫu
giúp phát hiện sớm được các rủi ro tiềm ẩn từ đó làm giảm nguy cơ thất bại của dự án.
Bên cạnh đó mô hình bản mẫu cũng có một số hạn chế như gây tốn thời gian và tiền
bạc nếu bản mẫu không được khách hàng chấp nhận, có quá nhiều thay đổi từ phía
khách hàng khiến đội ngũ phát triển dễ bị xáo trộn [19]. Mô hình bản mẫu nên được áp
dụng trong các trường hợp sau: (1) Khi mới biết được mục tiêu chung chung của phần
mềm mà chưa biết rõ chi tiết đầu vào, đầu ra hay quy trình nghiệp vụ xử lý như thế
nào; (2) Khi muốn dùng như một phương pháp để thu thập yêu cầu khách hàng;
Mô hình xoắn ốc (Spiral Model) [6]:Mô hình xoắc ốc bao gồm các tính chất
của mô hình thác nước và mô hình nguyên mẫu. Mô hình xoắn ốc hữu ích đối với các
phần mềm được phát hành thành nhiều phiên bản.Trong mỗi lần lặp lại của mô hình
xoắn ốc tương đương một mô hình thác nước. Vào cuối phiên bản đầu tiên khách hàng
đánh giá phần mềm và cung cấp các thông tin phản hồi. Dựa trên thông tin phản hồi,
quá trình phát triển phiên bản tiếp theo sẽ dần hoàn thiện hơn,quá trình này lặp đi lặp
lại trong suốt vòng đời của phần mềm.
7
Lập kế hoạch
Phân tích rủi ro
Kỹ nghệ
Xây dựng và
xuất xưởng
Khách hàng
đánh giá

Giao tiếp
khách hàng
Khái niệm Làm mới
Nâng cấp Bảo trì

Hình 1.4: Mô hình xoắn ốc
Các pha của mô hình xoắn ốc được biểu diễn trongHình 1.4, bao gồm các pha
sau:
Giao tiếp khách hàng: Giữa người phát triển và khách hàng để tìm hiểu yêu cầu.
Lập kế hoạch: Xác lập tài nguyên, thời hạn và những thông tin khác.
Phân tích rủi ro: Xem xét mạo hiểm kỹ thuật và mạo hiểm quản lý.
Kỹ nghệ: Xây dựng một hay một số biểu diễn của ứng dụng.
Xây dựng và xuất xưởng: Xây dựng, kiểm thử, cài đặt và cung cấp hỗ trợ người
dùng.
Khách hàng đánh giá: Nhận các phản hồi của người sử dụng về biểu diễn phần
mềm trong giai đoạn kỹ nghệ và cài đặt.
Mô hình xoắn ốc áp dụng tốt trong trường hợp xây dựng hệ thống phần mềm có
quy mô lớn, vấn đề gặp phải của mô hình xoắn ốc đó là hoạt động xác định, đánh giá
rủi ro khó thực hiện.
1.5. Giới thiệu tổng quan vềCMM/CMMI
1.5.1. Mô hình trưởng thành năng lực
Mô hình trưởng thành năng lực (Capacity Maturity Model, viết tắt là
CMM)[26] được phát triển bởiViện công nghệ phần mềm (Software Engineering
Institute, viết tắt là SEI) thuộc trường Đại học Carnegie Mellon (Mỹ),là mô hình đánh
giá sự trưởng thành năng lực sản xuất phần mềm, mô hình quản lý chất lượng cho các
tổ chức sản xuất phần mềm. CMM là một bộ các hướng dẫn và kinh nghiệm thực tiễn
được chọn lọc của các chuyên gia và tổ chức hàng đầu trong lĩnh vực phát triển, cải
tiến hoặc đánh giá quy trình sản xuất phần mềm. CMM không đưa ra các quy trình cụ
8
thể, mà chỉ đưa ra các hướng dẫn để các công ty/ tổ chức phát triển phần mềm có thể

tự xây dựng và cải tiến hiệu quả các quy trình của mình
CMM bao gồm 5 cấp độ (Level) và 18vùng quy trình quan trọng (Key Process
Area - KPAs)[26], cụ thể có các cấp độ được mô tả tại Bảng 1.1
Bảng 1.1: Các cấp độ của mô hình CMM
Cấp độ Vùng quy trình
1 - Mức độ khởi động
(Initial level)
Không có KPAs nào cả
2 - M
ức độ có khả năng
lặp (Repeatable level)
 Quản lý các yêu cầu (Requirement Management)
 Lập kế hoạch cho dự án (Software Project Planning)
 Theo dõi kiểm tra tiến độ dự án (Software Project
Tracking)
 Quản trị hợp đồng phụ phần mềm (Software SubContract
Managent)
 Đảm bảo chất lượng sản phẩm (Software Quality
Assurance)
 Quản lý cấu hình sản phẩm (Software Configuration
Management)
3 - Mức độ được định
nghĩa (Defined level)
 Cải tiến quy trình dựa vào mục tiêu của tổ chức
(Organization Process Focus)
 Định nghĩa quy trình tổ chức (Organization Process
Definition)
 Đà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)
 Xét duyệt ngang hàng (Peer Reviews)
4 - Mức độ được quản
lý (Managed level)
 Quản lý quá trình định lượng (Quantitative Process
Management)
 Quản lý chất lượng phần mềm (Software Quality
Management)
5 - Mức độ tối ưu hóa
(Optimizing level)
 Phòng ngừa lỗi (Defect Prevention)
 Quản trị thay đổi công nghệ (Technology Change
Management)
 Quản trị thay đổi quá trình (Process Change Management)

1.5.2. Mô hình trưởng thành năng lực tích hợp
Mô hình trưởng thành năng lực tích hợp (Capability Maturity Model
Integration, viết tắt làCMMI)[25] là phiên bản cải tiến của mô hình CMM[26], CMMI
được tích hợp từ nhiều mô hình khác nhau, xuất phát từ ba mô hình nguồn[8],[25]: (1)
Mô hình SW-CMM draft C, đại diện cho hướng phần mềm; (2) Mô hình SECM, đại
diện cho hướng công nghệ hệ thống; (3) Mô hình IPD-CMM v0.98, đại diện cho
hướng phát triển tích hợp tiến trình và sản phẩm. CMMI phù hợp cho cảnhững doanh
nghiệp sản xuất phần cứng và tích hợp hệ
9
thống,chứkhôngchỉápdụngchodoanhnghiệpphầnmềmnhưCMM trước đây.
Tương tự CMM, CMMI cũng có 5 mức độ trưởng thành[25]:(1) Mức độ khởi
động (Initial level); (2) Mức độ có khả năng lặp (Repeatable level); (3) Mức độ được
định nghĩa (Defined level); (4) Mức độ được quản lý (Managed level); (5) Mức độ tối

ưu hóa (Optimizing level).
Tháng 10/2010,viện công nghệ phần mềm (SEI) thông báo phiên bản mới của
CMMI là CMMI v1.3, mô hình CMMI v1.3 có ba mô hình áp dụng bao gồm CMMI-
DEV (Dành cho chuyên viên phát triển sản phẩm),CMMI-ACQ (Dành cho các tổ chức
có hoạt động thuê ngoài, sáp nhập hay mua lại sản phẩm hoặc dịch vụ từ công ty khác)
và CMMI-SVC (Dành cho các tổ chức hoạt động trong lĩnh vực cung cấp dịch
vụ),trong đó có 16 vùng quy trình cơ bản chung cho cả 3 mô hình[25].
Trong luận vănnày tác giả chỉ tập trung vào nghiên cứu áp dụng đối với mô
hình CMMI-DEV v1.3 dành cho chuyên viên phát triển
Mô hình CMMI có haihướng tiếp cận áp dụng, hướng tiếp cận theo tầng
(Staged Representation) và tiếp cận theo hướng liên tục (Continuous
Representation)[25]. Tổ chức lựa chọn thực hiện theo mứcnăng lực của quy trình phần
mềm tương ứng với việc chọn áp dụng mô hình CMMI dạng trình bày liên tục, còn
nếu quyết định thực hiện theo mức độ trưởng thành của tổ chức tương ứng với chọn áp
dụng mô hình CMMI dạng phân tầng.
Các thành phần của mô hình CMMIđượcnhóm thành ba loại bao gồm[25]:
Thành phần bắt buộc,Thành phần cần thiết vàThành phần thông tin.
Thành phần bắt buộc (Required Components):Đây là thành phần cần thiết để
đạt được mục tiêu cải tiến của vùng quy trình cần áp dụng, các nội dung này cần phải
được nêu ra và thực hiện trong quy trình phát triển của tổ chức.Thành phần bắt buộc
trong mô hình CMMI là những phát biểu về mục tiêu cụ thể (Specific Goals) và mục
tiêu chung (Generic Goals)[25].
Thành phần cần thiết (Expected Components):Tùy từng trường hợp, một số nội
dung không bắt buộc phải được thực hiện để có thể áp dụng thành công mô hình,
những nội dung thuộc loại này cũng rất quan trọng trong quá trình cải tiến quy trình.
Thành phần cần thiết là những phát biểu về quy tắc thực tiễn cụ thể (Specific
Practices) vàthực tiễn chung (Generic Practices)[25].
Thành phần thông tin (Informative Components): Đây là thành phần chiếm số
lượng nhiều hơn cả, thành phần này cung cấp nhiều hướng dẫn chi tiết hơn để hiểu
được các thành phần bắt buộc và cần thiết.Có 3 nhóm nội dung khác nhau nhằm mục

đích hướng dẫn, giải thích, thông tin thêm cho người đọc, các nhóm thông tin này bao
gồm: Tên gọi (Names), Các ví dụ minh hoạ (Examples) và các tham chiếu
(References)[25].
Một khái niệm quan trọng trong CMMI là “Vùng quy trình” (Process Area),
CMMI chỉ chọn ra những khía cạnh quan trọng đối với việc cải tiến quy trình và nhóm
10
chúng lại thành từng vùng (Area), nên được gọi là vùng quy trình. Bên cạnh đó, trong
mỗi vùng quy trình còn mô tả tập hợp những kết quả sẽ đạt được nếu áp dụng thành
công vùng quy trình này.Trong mô hình CMMIDEV v1.3 có tất cả 22 vùng quy trình,
các vùng quy trình này được phân bổ vào các nhóm: Quản lý dự án (Project
Management), Quản lý quy trình (Process Management), Công nghệ (Engineering) và
Hỗ trợ (Support). Danh sách các vùng quy trình trong CMMI DEV v1.3 bao gồm[25]:
o Causal Analysis and Resolution (CAR)
o Configuration Management (CM)
o Decision Analysis and Resolution (DAR)
o Integrated Project Management (IPM)
o Measurement and Analysis (MA)
o Organizational Process Definition (OPD)
o Organizational Process Focus (OPF)
o Organizational Performance Management (OPM)
o Organizational Process Performance (OPP)
o Organizational Training (OT)
o Product Integration (PI)
o Project Monitoring and Control (PMC)
o Project Planning (PP)
o Process and Product Quality Assurance (PPQA)
o Quantitative Project Management (QPM)
o Requirements Development (RD)
o Requirements Management (REQM)
o Risk Management (RSKM)

o Supplier Agreement Management (SAM)
o Technical Solution (TS)
o Validation (VAL)
o Verification (VER)
Các thành phần chính trong mỗi vùng quy trình trong mô hình CMMI được mô
tả trong Hình 1.5.
11
Purpose
Statement
Introductory
Notes
Related
Process Area
Specific Goals Generic Goals
Specific Practices Generic Practices
Excample Work
Products
Subpractices
Subpractices
Generic
Practices
Elaborations
Process Area

Hình 1.5: Các thành phần trong mô hình CMMI[25]
Mục đích (Purpose Statement): mỗi vùng quy trình được bắt đầu trình bày
bằng những phát biểu ngắn gọn về mục đích chung của vùng quy trình này nhằm
làm gì.
Lời giới thiệu (Introductory Notes): tiếp theo phần mục đích là phần mở đầu
cho vùng quy trình, thường gồm phạm vi của vùng quy trình và tầm quan trọng của nó.

Các vùng quy trình liên quan (Related Process Areas): phần này sẽ liệt kê các
tham chiếu đến các vùng quy trình có liên quan khác. Trong mô hình CMMI không có
sơ đồ biểu diễn về sự liên quan của các vùng quy trình.Dựa trên các thông tin mô tả
các vùng quy trình liên quan của mỗi vùng quy trình để tổng hợp và thể sự liên quan
đó qua các con số được tổng hợp trongBảng 1.2, qua số liệu tổng hợp nhận cho thấy
vùng quy trình tích hợp sản phẩm (PI) có tham chiếu đến vùng quy trình khác nhiều
nhất.
Bảng 1.2:Mối liên quan giữa các vùng quy trình trong CMMI

Mục tiêu chung (Generic Goals, GG):các mục tiêu cần đạt được phát biểu
12
chung và có liên quan đến nhiều vùng quy trình khác, được gọi là mục tiêu chung.
Danh sách các mục tiêu chung được nêu ra tại Bảng 1.3.
Mục tiêu cụ thể (Specific Goals, SG): các mục tiêu cần đạt được phát biểu riêng
cho một vùng quy trình duy nhất, được gọi là mục tiêu cụ thể hay chuyên biệt.
Quy tắc thực tiễn chung (Generic Practices, GP):các quy tắc thực tiễnđược
phát biểu chung cho nhiều vùng quy trình, nó được gọi là quy tắc thực tiễn chung.
Quy tắc thực tiễncụ thể (Specific Practices, SP):các quy tắc thực tiễn được phát
biểu cho riêng một vùng quy trình nào đó, được gọi là quy tắc thực tiễn cụ thể hay
chuyên biệt. Ví dụ về các mục tiêu cụ thể và quy tắc thực tiễn cụ thể của vùng quy
trình Lập kế hoạch dự án được nêu tại Bảng 1.4.
Các sản phẩm công việc(Sample Work Products): Đây là nội dung đi kèm với
từng quy tắc thực tiễn, liệt kê các kết quả công việc tiêu biểu (hay còn gọi là sản phẩm
công việc) sẽ có được khi áp dụng quy tắc thực tiễn này.
Quy tắc thực tiễn con(Subpractices): Đã số các quy tắc thực tiễn trong mô hình
CMMI đều bao gồm những quy tắc thực tiễn con để giải thích chi tiết hơn về ý nghĩa
và các hoạt động của quy tắc thực tiễn đang đề cập.
Bảng 1.3:Các mục tiêu chung trong mô hình CMMI [25]
Mục tiêu chung (GG) Liên tục Phân tầng
GG 1. Đạt được mục tiêu cụ thể (Achieve Specific

Goals)
CL1
GP 1.1 .Thực hiện các thực hành cụ thể (Perform
Specific Practices)
GG 2. Thể chế hoá quy trình được quản lý
(Institutionalize a Managed Process)
CL2 ML2
GP 2.1.Thiết lập chính sách cho tổ chức (Establish an
Organizational Policy)
GP 2.2.Có kế hoạch quy trình (Plan the Process)
GP 2.3.Cung cấp nguồn lực (Provide Resources)
GP 2.4.Phân công trách nhiệm (Assign Responsibility)
GP 2.5.Đào tạo nhân sự (Train People)
GP 2.6.Kiểm soát các kết quả công việc (Control Work
Products)
GP 2.7.Xác định vai trò của các bên liên quan (Identify
and Involve Relevant Stakeholders)
GP 2.8.Giám sát và kiểm soát quy trình (Monitor and
Control the Process)
GP 2.9.Đánh giá sự tuân thủ (Objectively Evaluate
Adherence)
GP 2.10.Xem xét thực trạng với quản lý mức cao
(Review Status with Higher Level Management)
GG 3.Thể chế hoá quy trình được định nghĩa
(Institutionalize a Defined Process)
CL3
ML3, ML4,
ML5
13
Mục tiêu chung (GG) Liên tục Phân tầng

GP 3.1.Thiết lập quy trình được định nghĩa (Establish a
Defined Process)
GP 3.2.Tập hợp kinh nghiệm liên quan quy trình (Collect
Process Related Experiences)
Bảng 1.4:Các mục tiêu cụ thể và quy tắc thực tiễn cụ thể của vùng quy trình lập
kế hoạch dự án[25]
Vùng
quy trình

Mục tiêu cụ thể (SG)
Lập kế
hoạch dự
án
(Project
Planning)

SG 1. Thiết lập các ước lượng (Establish Estimates)
SP 1.1.Ước lượng phạm vi dự án (Estimate the Scope of the Project)
SP 1.2.Thiết lập các ước lượng cho các thuộc tính sản phẩm và công
việc (Establish Estimates of Work Product and Task Attributes)
SP 1.3.Xác định chu trình phát triển của dự án (Define Project Lifecycle
Phases)
SP 1.4.Ước lượng chi phí và nhân lực (Estimate Effort and Cost)
SG 2.Lập kế hoạch dự án (Develop a Project Plan)
SP 2.1.Ước lượng ngân sách và lịch biểu (Establish the Budget and
Schedule)
SP 2.2.Xác định rủi ro dự án (Identify Project Risks)
SP 2.3.Lên kế hoạch quản lý dữ liệu (Plan Data Management)
SP 2.4.Hoạch định nguồn lực dự án (Plan the Project’s Resources)
SP 2.5.Chuẩn bị kiến thức và kỹ năng cần thiết (Plan Needed

Knowledge and Skills)
SP 2.6.Chuẩn bị thông tin về các đối tác liênquan (Plan Stakeholder
Involvement)
SP 2.7.Thiết lập kế hoạch dự án (Establish the Project Plan)
SG 3.Thống nhất kế hoạch thực hiện (Obtain Commitment to the
Plan)
SP 3.1.Xem xét các kế hoạch có ảnh hưởng đến dự án (Review Plans
That Affect the Project)
SP 3.2.Cân đối nguồn lực và công việc (Reconcile Work and Resource
Levels)
SP 3.3.Thống nhất kế hoạch triển khai (Obtain Plan Commitment)
Mô hình CMM/CMMI có nhiều ưu điểm, việc cải tiến quy trình phần mềm theo
CMM/CMMI chứng tỏ rằng các tổ chức phần mềm có thể kiểm soát được chi phí và
đạt được các tiêu chí về năng suất, chất lượng[4], [27]. Bên cạnh đó, giúp tạo ra một
môi trường làm việc chuyên nghiệp, thay đổi tác phong, văn hóa làm việc và nâng cao
năng lực cho nhân viên. Tuy nhiên CMM/CMMI cũng có những hạn chế nhất định,
một trong số các hạn chế lớn của mô hình này có thể nhận thấy được đó là:Mô hình
CMM/CMMI không bao quát được hết các vấn đề cần thiết để dự án phần mềm thành
công. Ví dụ, mô hình này không tập trung vào các nghiệp vụ hay công nghệ cụ thể,
không có hướng dẫn cho tổ chức trong việc tuyển chọn, điều động nhân sự mặc dù đây
là khía cạnh quan trọng và có ảnh hưởng nhiều đến sự thành công của dự án[4]. Mô
14
hình CMM/CMMIkhông bảo đảm rằng các sản phẩm phần mềm luôn luôn được xây
dựng thành công, cũng không bảo đảm rằng các vấn đề phát sinh trong lĩnh vực công
nghệ phần mềm sẽ luôn được giải quyết thoả đáng.Mô hình CMM/CMMI phù hợp với
các dự án lớn, áp dụng đối với các dự án nhỏ thường gặp rủi ro cao hơn. Mô hình
CMM/CMMI có lượng thông tin lớn gây khó khăn cho doanh nghiệp vừa và nhỏ khi
áp dụng[9].
1.5.3. Hướng tiếp cận liên tục và mức năng lực quy trình
Hướng tiếp cận mô hình CMMI dạng liên tục là phương pháp tiếp cận cho phép

tổ chức lựa chọn một hoặc nhiều vùng quy trình cụ thể để cải tiến. Để đánh giá việc
cải tiến vùng quy trình người ta dùng khái niệm mức năng lực (Capability Level)[25].
Process Areas
Capability Levels
Specific
Practices
Generic
Practices
Generic GoalsSpecific Goals

Hình 1.6: Hướng tiếp cận CMMI theoliên tục[25]
Trong CMMI với hướng tiếp cận liên tục, mức năng lực có 4 cấp độ (được đánh
số từ 0 đến 3).Mức năng lực của một vùng quy trình nào đó càng cao càng thể hiện tổ
chức thực hiện các hoạt động thuộc vùng quy trình đó càng tốt.
Capability Level 0: Incomplete, một quá trình không hoàn thành là quá trình
không được thực hiện hoặc chỉ thực hiện một phần. Một hoặc nhiều mục tiêu cụ thể
(Specific goals) của vùng quy trình không được đáp ứng và mục tiêu chung (Generic
goals) không tồn tại. Mức 0 này tương đương với mức 1 trong dạng trình bày theo tầng
(Staged representation)[25].
Capability Level 1 (CL1): Performed,một vùng quy trình có Capability level 1
là 1 vùng quy trình được mong đợi sẽ thực hiện tất cả các thực hành cụ thể (SP) và
thực thành chung (GP) dành cho Capability level 1[25].
Ví dụ, để đạt được CL1 của vùng quy trình quản lý cấu hình CM thì cẩn phải
thực hiện các yêu cầu của GG1 trongBảng 1.3và các SP được yêu cầucủa vùng quy
trình CM (PA1), cụ thể[21]:
CL1.
{
PA1
}
= GG1.[PA1]

= SGi.[PA1] = SG1.[PA1]∧SG2.[PA1]∧SG3.[PA1]


= SP1.i.[PA1]∧ SP2.i.[PA1]


∧ SP3.i.[PA1]





(1)

15
Capability Level 2 (CL2): Managed, một quy trình quản lý được lên kế hoạch,
thực hiện, giám sát và kiểm soát cho các dự án cá nhân, các nhóm hoặc những quy
trình riêng lẻ để đạt được một mục tiêu chi phí, lịch trình, chất lượng, [25].
Ví dụ, để đạt được CL2thì cần phải đạt được CL1 và thoả mãn các yêu cầu của
GG2, cụ thể[21]:
CL2.
{
PA1
}
= CL1.
{
PA1
}
∧GG2.
{

PA1
}
= CL1.
{
PA1
}
∧ GP2.i.
{
PA1
}



(2)

Capability Level 3 (CL3): Defined,một vùng quy trình có Capability level 3
được mô tả như một quy trình được xác định (defined process). Một quy trình được
xác định là một quy trình được quản lý và được thiết kế từ tập hợp các quy trình chuẩn
của tổ chức[25].
Để đạt được CL3 cần phải đạt được CL1, CL2 và thoả mãn yêu cầu của GG3,
cụ thể[21]:
CL3.
{
PA1
}
= CL2.[PA1]∧GG3.[PA1]
= CL1.[PA1]∧ GP2.i.[PA1]


∧ GP3.i.[PA1]




(3)


Bảng 1.5:Bảng phân loại vùng quy trình theo hướng tiếp cận liên tục
Tên vùng quy trình Viết tắt Lĩnh vực
Tích hợp sản phẩm (Product Integration) PI
Kỹ nghệ
(Engineering)

Phát triển yêu cầu (Requirements Development) RD
Phát triển giải pháp kỹ thuật (Technical Solution) TS
Xác nhận (Validation) VAL
Kiểm tra (Verification) VER
Định nghĩa quy trình tổ chức (Organizational Process
Definition) OPD
Quản lý quy
trình (Process
Management)

Cải tiến quy trình dựa vào mục tiêu của tổ chức
(Organizational Process Focus) OPF
Đào tạo (Organizational Training) OT
Năng lực quy trình của tổ chức (Organizational Process
Performance) OPP
Quản lý hiệu quả của tổ chức (Organizational
Performance Management) OPM
Quản lý dự án dựa trên số liệu (Quantitative Project

Management) QPM
Quản lý dự
án (Project
Management)

Giám sát và kiểm soát dự án (Project Monitoring and
Control) PMC
Lập kế hoạch dự án (Project Planning) PP
16
Tên vùng quy trình Viết tắt Lĩnh vực
Quản lý yêu cầu (Requirements Management) REQM
Quản lý nhà cung cấp (Supplier Agreement
Management) SAM
Quản lý dự án tích hợp (Integrated Project
Management) IPM
Quản lý rủi ro (Risk Management) RSKM
Quản lý cấu hình (Configuration Management) CM
Hỗ trợ
(Support)
Đo lường và phân tích (Measurement and Analysis) MA
Đảm bảo chất lượng sản phẩm và quy trình (Process and
Product Quality Assurance) PPQA
Phân tích và lựa chọn giải pháp (Decision Analysis and
Resolution) DAR
Phân tích nguyên nhân và giải pháp (Causal Analysis
and Resolution) CAR
1.5.4. Hướng tiếp cận theotầng và mức trưởng thành
Hướng tiếp cận mô hình CMMIdạng phân tầng (Staged Representation) là
hướng tiếp cận cung cấp một lộ trình được xác định trước để xác định hướng cải tiến
cho một tổ chức, dựa trên việc gom nhóm và sắp xếp các vùng quy trình có sẵn. Để

đánh giá mức độ cải tiến thì ta dùng khái niệmmức độ trưởng thành (Maturity Level,
viết tắt ML).
Process Areas
Maturity Levels
Specific
Practices
Generic
Practices
Generic GoalsSpecific Goals

Hình 1.7: Hướng tiếp cận CMMI theo phân tầng[25]
Hướng tiếp cận mô hình CMMI theo tầng xem con đường phát triển củamột tổ
chức phần mềm gồm bước tiến lên từng bậc thang trưởng thành. Mỗi bậc thang đòi hỏi
tổ chức phần mềm phải tập trung nguồn lực để đạt được một tập các vùng quy trình
nhất định.
17
Initial
Managed
Defined
Quantitatively Managed
Optimized
5
4
3
2
1

Hình 1.8: Các cấp độ trưởng thành trong CMMI
Hình 1.8minhhọanăm cấpđộtrưởngthànhvàcácvùngquy trìnhtươngứngvới từng
mức độ trưởng thành. Các vùng quy trình mức 2 tập trung vào việc xây dựng nền tảng

vững chắc cho quản lý và kiểm soát hoạt động đề án. Trong khi đó, mức 3 không chỉ
chú trọng vào việc nội bộ riêng lẻ từng dự án được quản lý tốt mà khả năng này cần
phải được nhân rộng lên toàn tổchức, thống nhất giữa mọi đề án. Mức 4 chú trọng xây
dựng khả năng có thể định lượng được tiến trình phần mềm lẫn kết quả công việc.
Mức 5 tập trung vào khả năng có thể chủ động cải tiến liên tục các quy trình phát triển
phần mềm của tổ chức.
Mỗi mức độ trưởng thành bao gồm một số các vùng quy trình được xác định
trước, chi tiết các vùng quy trình ứng với các mức độ (level) được thể hiện trong Bảng
1.6. Mức độ trưởng thành được đo bằng việc đạt được các mục tiêu cụ thể (Specific
goals) và mục tiêu chung (Generic goals) áp dụng lên các vùng quy trình tương ứng.
Chi tiết của từng mức độ trưởng thành trong mô hình CMMI như sau[25]:
Cấp độ 1. Initial (Khởi đầu):Những tổ chức sản xuất phần mềm ở mức độ này chưa
có cácthủ tục, quy trình quản lý rõ ràng. Họ có thể thành công trong việc phát triển phần
mềm, nhưng không thể kiểm soát nổi chất lượng phần mềm, chi phí, thời hạn giao nộp,…
Sự thành công của dự án phụ thuộc nhiều vào những nhân sự giỏi, xuất sắc trong dự án. Tất
cả các tổ chức phát triển phần mềm đều được xếp cấp độ 1 (ML1).
Cấp độ 2. Managed (Được quản lý):Mức độ này muốn đề cập đến các tổ chức
sản xuất phần mềmđã có áp dụng quy trình sản xuất,đảm bảo rằng các yêu cầu được
quản lý và các quy trình được lên kế hoạch, thực hiện, đo lường và kiểm soát. Ở cấpđộ
2, yêu cầu, quy trình, các sản phẩm làm việc và các dịch vụ được quản lý. Có thể nhìn
thấy tình trạng sản phẩm và cung cấp các dịch vụ quản lý tại các thời điểm xác định,
tuy nhiênchưa có mô hình tổng quát của quy trình phát triển phần mềm.Để đạt được
cấp độ2 thì doanh nghiệp phải thoả mãn được các SG của 7 vùng quy trình (Từ PA1
đến PA7), và thực hiện các yêu cầu của GG2 của vùng quy trình từ PA1 đến PA7, cụ
thể[21]: