MÔ HÌNH TRƯỞNG THÀNH KHẢ NĂNG, MÔ HÌNH TRƯỞNG THÀNH TÁI SỬ DỤNG VÀ ÁP DỤNG THỰC TIẾN TRONG HOẠT ĐỘNG SẢN XUẤT PHẦN MỀM TẠI CÔNG TY CT-IN

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ




Nguyễn Hoài Nam





MÔ HÌNH TRƯỞNG THÀNH KHẢ NĂNG, MÔ HÌNH
TRƯỞNG THÀNH TÁI SỬ DỤNG VÀ ÁP DỤNG THỰC TIẾN
TRONG HOẠT ĐỘNG SẢN XUẤT PHẦN MỀM TẠI CÔNG TY
CT-IN.





Ngành: Công Nghệ Thông Tin

Mã số: 1.01.10


LUẬN VĂN THẠC SỸ








Người hướng dẫn:
PGS. TS. Nguyễn Văn Vỵ



Hà Nội - 2007

2


Mục lục

MỞ ĐẦU
3
Chương 1. Mô hình trưởng thành khả năng cho phần mềm - CMM
7
1.1. Tổ chức phần mềm chưa trưởng thành và trưởng thành……………………………………
8

1.2. Các khái niệm cơ bản trên khía cạnh trưởng thành tiến trình……………………………….
9
2. Năm mức trưởng thành tiến trình phần mềm………………………………………………………
10
2.1. Đặc tính cư xử của các mức trưởng thành………………………………………………………….
11
2.2. Năng lực tiến trình và dự báo hiệu năng…………………………………………………………….
15
2.3. Bỏ qua các mức trưởng thành…………………………………………………………………………
17
3. Định nghĩa theo kiểu hoạt động của mô hình CMM………………………………………………
18
3.1. Cấu trúc bên trong của các mức trưởng thành……………………………………………………
19
3.2. Các mức trưởng thành……………………………………………………………………………………
19
3.3. Các vùng tiến trình then chốt……………………………………………………………………………
20
3.4. Các mục tiêu…………………………………………………………………………………………………
25
3.5. Các đặc điểm chung…………………………………………………………………………………………
25
3.6. Các thực hành then chốt………………………………………………………………………………….
26
4. Tương lai của CMM…………………………………………………………………………………………….
27
5. Kết luận…………………………………………………………………………………………………………….
28
Chương 2. Tiến trình sử dụng lại được và các mức tăng trưởng của nó trong
một tổ chức (RMM)

30
1. Tổng quan…………………………………………………………………………………………………………
30
2. Khía cạnh hiện nay: Kỹ nghệ tiến trình…………………………………………………………………
30
3. Mô hình tăng trưởng tái sử dụng (RMM)……………………………………………………………….
32
3.1. Các nhân tố tái sử dụng…………………………………………………………………………………
33
3.2. Các hoạt động tái sử dụng……………………………………………………………………………….
35
4. Kết luận…………………………………………………………………………………………………………….
46
Chương 3. Áp dụng CMM, RMM vào hoạt động thực tiễn sản xuất phần mềm
tại công ty CT-IN
47
1. Giới thiệu…………………………………………………………………………………………………………
47
2. Chi tiết các vùng thực hành then chốt………………………………………………………………….
47
2.1. Quản lý yêu cầu………………………………………………………………………………………………
48
2.2. Quy trình phát triển kế hoạch dự án phần mềm………………………………………………….
54
2.3. Quản Lý Cấu Hình……………………………………………………………………………………………
62
2.4. Quy trình đảm bảo chất lượng phần mềm………………………………………………………….
69
2.5. Quy trình kiểm tra……………………………………………………………………………………………
77

Chương 4. Xây dựng công cụ trợ giúp quản lý tiến trình
87
1. Giới thiệu…………………………………………………………………………………………………………
87
2. Mô tả phần mềm………………………………………………………………………………………………
88
3. Nhận xét……………………………………………………………………………………………………………
97
KẾT LUẬN
98
Tài liệu tham khảo
99
Phụ lục
100
1. actorlist_template.doc
101
2. usecase_template.doc
104
3. feature_list.doc
107
4. risk_list_template.doc
111
5. software_development_plan_template.doc
114
6. qa_plan_template.doc
124
7. test_plan_template.doc
129
8. test_case_template.doc
137

3


MỞ ĐẦU

Vai trò của tổ chức và quản lý đối với chất lượng phần mềm (bên cạnh yếu
tố công nghệ, nhân lực)
Mô hình CMM/CMMi do Viện Kỹ Thuật SEI (Software Engineering Institute) liên kết
với Đại Học Carnegie Mellon - Hoa Kỳ phát triển. 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 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.
Tuy nhiê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 xác định, được
quản lý và tối ưu hóa.
Tuy nhiên, việc chuyển đổi từ mô hình CMM sang CMMi sẽ tùy thuộc vào từng doanh
nghiệp/tổ chức cụ thể. Có thể sẽ phải thay đổi rất nhiều và thực tế là áp dụng mô hình CMMi
đòi hỏi nhiều sự đầu tư về công sức và tài chính hơn. Kinh phí để tiến hành đánh giá theo

mô hình CMM/CMMi có thể lên đến vài chục hay vài trăm ngàn đô-la Mỹ và đây có thể là bài
toán nan giải đối với các doanh nghiệo phần mềm nhỏ. Có thể xem CMM/CMMi là "giấy
thông hành" giúp doanh nghiệp phần mềm tạo lợi thế trong quá trình cạnh tranh giành hợp
đồng từ phía đối tác nước ngoài. Tuy nhiên yếu tố quan trọng bậc nhất vẫn là chất lượng
sản phẩm mà doanh nghiệp thể hiện.
4


Để một doanh nghiệp phần mềm nhỏ có thể đạt được đánh giá và áp dụng thành
công mô hình CMM/CMMi thì trước hết các doanh nghiệp này cần "tự mình lớn lên" và qua
đó họ sẽ có đủ năng lực để áp dụng những mô hình này.

Vấn đề về sử dụng lại phần mềm (software reuse) cũng rất quan trọng trong công
nghệ phần mềm. Khi được nghiên cứu tích hợp trong quá trình phát triển phần mềm, nó sẽ
cung cấp cơ sở cho các cải tiến sâu sắc trong cách phát triển và bảo dưỡng các hệ thống
phần mềm trong chu kỳ vòng đời. Nó có những mục đích như sau:
 Tăng cường năng lực sản xuất
 Cải thiện chất lượng và độ tin cậy của các hệ thống phần mềm.
 Cải thiện được sự tương tác qua lại của các hệ thống
 Xác định và kiểm soát được các rủi ro kỹ thuật
 Rút ngắn thời gian phát triển và bảo dưỡng.
Mô hình tăng trưởng sử dụng lại được RMM (Reuse Maturity Model) đã được đưa ra
nhằm giúp các doanh nghiệp áp dụng hiệu quả việc tái sử dụng lại phần mềm.

Trong quá trình hoạt động thực tiễn tại công ty CT-IN, do nhu cầu của công việc
(xuất khẩu phần mềm cho nước ngoài) nên việc áp dụng các mô hình CMM và RMM trở
thành một nhu cầu cấp thiết và hết sức hiệu quả.

* Nội dung của đề tài, các vấn đề giải quyết:

Luận văn sẽ tập trung vào trình bày hai mô hình CMM và RMM, các khài niệm, thuật
ngữ, các vấn đề cần quan tâm đối với hai mô hình này qua đó áp dụng thực tế trong hoạt
động xuất khẩu phần mềm tại công ty CT-IN.
Mô hình tăng trưởng năng lực (CMM) cho phần mềm là một tập các thành phần cơ
bản của một quy trình phần mềm hiệu quả. CMM miêu tả sự cải tiến không ngừng từ một
quá trình sơ khai, chưa được thuần thục đến một quy trình thuần thục và theo quy định rõ
ràng.
5


CMM chứa đựng các kinh nghiệm thực tế từ việc ra kế hoạch, quản lý về mặt kỹ
thuật quá trình phát triển và bảo dưỡng phần mềm. Khi tuân theo các quy định này, nó sẽ
giúp các doanh nghiệp cải thiện được khả năng sản xuất với chi phí tối ưu, đảm bảo chức
năng, kế hoạch và chất lượng sản phẩm.
CMM có 5 mức:
 (1): Khởi tạo
 (2): Lặp lại được
 (3): Xác định
 (4): Quản lý
 (5): Tối ưu

Mô hình tăng trưởng sử dụng lại cũng có 5 mức:
 (1): Khởi tạo (Initial Chaotic)
 (2): Được giám sát (Monitored)
 (3): Được phối hợp (Coordinated)
 (4): Được lên kế hoạch (Planned)
 (5): Sâu sát (Ingrained)
Luận văn sẽ tập trung vào trình bày chi tiết 5 mức của hai mô hình trên qua đó rút ra
các kinh nghiệm thực tế áp dụng tại công ty CT-IN.

Cuối cùng, em xin chân thành cảm ơn sự hướng dẫn tận tình của phó giáo sư, tiến sỹ
Nguyễn Văn Vỵ - Đại Học Quốc Gia Hà Nội – Trường Đại Học Công Nghệ trong quá trình
thực hiện luận văn.
Em cũng xin cảm ơn các thầy cô trường Đại Học Công Nghệ - Đại Học Quốc Gia Hà
Nội đã tạo điều kiện và giúp đỡ em trong quá trình học tập và làm khóa luận tốt nghiệp.

Xin cảm ơn sự giúp đỡ của các bạn lớp K10T3 trong quá trình học tập vừa qua.

6







Hà Nội, ngày 02 tháng 09 năm 2006
Học viên



Nguyễn Hoài Nam

7


Chương 1. Mô hình trưởng thành khả năng cho phần mềm -
CMM.

Sau hàng thập kỷ với những thất bại trong việc cải thiện năng suất và chất lượng từ
việc áp dụng các phương pháp luận và công nghệ mới trong việc sản xuất phần mềm, các
doanh nghiệp phần mềm nhận ra rằng vấn đề cơ bản là việc không thể quản lý được các tiến
trình làm phần mềm. Trong rất nhiều doanh nghiệp, các dự án thường rất muộn và vượt quá
ngân sách cho phép, và những lợi ích của việc áp dụng các phương pháp và công cụ tiên
tiến thường không được nhận thấy nếu áp dụng cho một dự án không tuân theo các quy
định chặt chẽ.

Vào tháng 11 năm 1986, học viện Kỹ Nghệ Phần Mềm (SEI), với sự trợ giúp của tập
đoàn Mitre, đã bắt đầu phát triển một mô hình trưởng thành tiến trình nhằm giúp cho các
công ty cải thiện chất lươngh làm phần mềm. Tháng 9 năm 1987, SEI đã đưa ra một miêu tả
ngắn gọn cho mô hình trưởng thành tiến trình. Hai phuơng pháp là đánh giá tiến trình phần
mềm và đánh giá khả năng của phần mềm và một phương pháp đặt câu hỏi trưởng thành

được phát triển để đánh giá sự trưởng thành của tiến trình phần mềm.

Sau bốn năm kinh nghiệm phát triển mô hình trưởng thành tiến trình phần mềm và
phiên bản khởi đầu của mô hình đặt câu hỏi trưởng thành, SEI đã kết hợp mô hình trưởng
thành vào trong Mô Hình Trưởng Thành Năng Lực cho Phần Mềm (CMM). CMM thể hiện các
tập các thực tế được gợi ý trong nhiều vùng tiến trình chính (KPA) được sử dụng để cải thiện
năng lực phần mềm. CMM được dựa trên kiến thức từ việc đánh giá các tiến trình phần mềm
và các phản hồi rộng lớn từ cả phía các nghành công nghiệp và chính phủ.

Mô hình trưởng thành năng lực cho phần mềm cung cấp các hướng dẫn cho các công
ty phần mềm làm thế nào để kiểm soát được các tiến trình phát triển và bảo dưỡng phần
mềm và làm sao để phát triển theo đúng hướng kỹ nghệ phần mềm và quản lý tốt của tương
lai. CMM được thiết kế nhằm hướng dẫn các công ty phần mềm trong việc lựa chọn các
chiến lược cải tiến quy trình bằng việc quyết định mô hình trưởng thành tiến trình hiện tại và
xác định một số vấn đề quan trọng nhất cho chất lượng phần mềm và cải tiến quy trình.
8


Bằng việc tập trung vào một số hoạt động giới hạn và làm việc nghiêm tức để đạt được
chúng, một công ty có thể dễ dàng cải tiến tiến trình làm phần mềm trong phạm vi rộng
khắp cho phép sự trưởng thành liên tục của năng lực tiến trình phần mềm.

Phiên bản đầu tiên của CMM, v 1.0, được đưa ra và sử dụng bởi cộng đồng phần
mềm trong khoảng thời gian 1991, 1992. Một hội nghị được tổ chức vào tháng 4 năm 1992
để bản về CMM v 1.0 với sự tham gia của hơn 200 chuyên gia phần mềm. Phiên bản hiện
nay của CMM, v 1.1 là kết quả của những phản hồi từ hội nghị đó và các phản hồi tiếp tục về
sau này của cộng đồng phần mềm.

1.1. Tổ chức phần mềm chưa trưởng thành và trưởng thành

Việc đặt ra các mục tiêu cơ bản cho cải tiến việc cải tiến quy trình đòi hỏi một mức hiểu
biết về sự khác nhau giữa tổ chức phần mềm chưa trưởng thành và trưởng thành. Trong
một tổ chức phần mềm chưa trưởng thành, các quy trình phần mềm nói chung được tùy
biến bởi các những người thực hiện và sự quản lý của họ trong quá trình làm dự án. Thậm
chí nếu một quy trình phần mềm đã được xác định, nó không được mọi người làm theo có
hiệu quả. Các hoạt động trong một tổ chức phần mềm chưa trưởng thành được ví như là làm
lấy lệ, và các nhà quản lý thường tập trung vào giải quyết các vấn đề tức thời (ví như dập tắt
các ngọn lửa bùng phát mà không giải quyết tận gốc). Kế hoạch và tài chính của phần mềm
thì thường xuyên bị vượt quá, vì chúng không được dựa trên các ước lượng thực tế. Khi mà
hạn định kết thúc cận kề, chức năng và chất lượng của sản phẩm được dàn xếp để đạt
hoạch định.

Trong một tổ chức phần mềm chưa trưởng thành, không có cơ sở mục tiêu cho việc điều
chỉnh chất lượng sản phẩm hay cho việc giải quyết vấn đề về sản phẩm hay tiến trình. Do
vậy, chất lượng sản phẩm rất khó đoán. Các hoạt động nhằm cải tiến chất lượng như là xem
xét hay kiểm thử thường bị bỏ qua hay rất hạn chế khi dự án chưa bị thúc ép.

Một mặt khác, một tổ chức phần mềm trưởng thành sở hữu một khả năng rộng khắp tổ
chức cho việc quản lý phát triển phần mềm và bảo trì tiến trình. Một tiến trình phần mềm
thường được trao đổi một cách thường xuyên và thích hợp giữa các nhân viên hiện thời và
những nhân viên mới vào và các hoạt động công việc được thực hiện theo tiến trình đã được
lên kế hoạch từ trước. Tiến trình thực hiện rất có ích và phù hợp với cách mà công việc thực
9


tế được thực hiện. Những tiến trình đã được định nghĩa này sẽ được cập nhật khi cần thiết,
và sự cải tiến được phát triển thông qua các việc kiểm thử trước có điều khiển và/hoặc các
việc phân tích về lợi ích tài chính. Vai trò và trách nhiệm trong một tiến trình xác định là rất
rõ ràng trong dự án và trong tổ chức.

Trong một tổ chức trưởng thành, các nhà quản lý giám sát chât lượng sản phẩm và tiến
trình tạo ra chúng. Có cơ sở về mục tiêu, lượng hóa cho việc điều chỉnh chất lượng sản
phẩm và phân tích vấn đề với sản phẩm và tiến trình. Lịch làm việc và ngân sách thường
được dựa trên các năng lực từ quá khứ và rất thực tế; kết quả mong muốn về giá cả, khung
thời gian, chức năng, và chất lượng sản phẩm thường xuyên đạt được. Nói chung, một tiến
trình cơ bản được tuân theo một cách thống nhất bởi vì tất cả mọi người tham gia đều hiểu
giá trị của việc làm như vậy, và tồn tại một cấu trúc hạ tầng thích hợp để hỗ trợ các tiến
trình đó.

1.2. Các khái niệm cơ bản trên khía cạnh trưởng thành tiến trình

Một tiến trình phần mềm được định nghĩa là một tập các hành động, phương thức, các
trải nghiệm thực tế và các biến đổi mà con người sử dụng để phát triển và bảo trì phần mềm
và các sản phẩm liên quan (như kế hoạch dự án, tài liệu thiết kế, mã, ca kiểm thử, hướng
dẫn sử dụng…) Khi một tổ chức trưởng thành, tiến trình phần mềm được xác định tốt hơn và
được thực hiện chuẩn xác và nhất quán hơn xuyên suốt tổ chức đó.

Khả năng tiến trình phần mềm miêu tả một dải các kết quả mong muốn có thể đạt được
bằng việc tuân theo tiến trình phần mềm. Khả năng tiến trình phần mềm của một tổ chức
cung cấp một công cụ dự đoán chính xác các công việc cần làm và các kết quả sẽ đạt được
của dự án tiếp theo mà tổ chức đang chuẩn bị thực hiện.

Hiệu năng tiến trình phần mềm thể hiện kết quả thực tế đạt được nhờ việc tuân theo
tiến trình phần mềm. Do vây, hiệu năng tiến trình phần mềm tập trung vào kết quả đạt được,
trong khi khả năng tiến trình phần mềm tập trung vào kết quả mong muốn và kế hoạch dự
kiến.

Sự trưởng thành tiến trình phần mềm là một kết quả mà khi một tiến trình nhất định
được xác định, quản lý, đo đạc, điểu khiển rõ ràng và hiệu quả. Trưởng thành ngụ ý tiềm
10

năng phát triển của tổ chức về mặt năng lực tổ chức và quản lý và chỉ ra cả sự đầy đủ của
tiến trình phần mềm được lập kế hoạch và sự thống nhất trong việc áp dụng trong các dự án
xuyên suốt tổ chức.

Khi một tổ chức phần mềm đạt được sự trưởng thành trong tiến trình phần mềm, nó sẽ
kết hợp tiến trình phần mềm của nó thông qua các chính sách, chuẩn mực, và cấu trúc tổ
chức. Sự kết hợp này bao gồm việc xây dựng cơ sở hạ tầng và văn hóa doanh nghiệp mà hỗ
trợ các phương thức, thực hành, và các thủ tục của doanh nghiệp do đó chúng tồn tại mãi
mãi sau khi người thiết lập nên chúng đã ra đi.

2. Năm mức trưởng thành tiến trình phần mềm

Việc cải tiến tiến trình liên tiếp được dựa trên rất nhiều các bước nhỏ, tiến hóa hơn là
một sáng tạo tiến hóa. Cấu trúc theo từng giai đoạn của CMM được đưa ra theo nguyên tắc
chất lượng sản phẩm đưa ra bởi Walter Shewart, W. Edwards Deming, Joseph Juran và Philip
Crosby. CMM cung cấp một bộ khung để sắp xếp các bước tiến hóa này thành năm mức
trưởng thành mà dựa trên cơ sở thành công cho việc cải tiên tiến trình liên tiếp. Năm mức
trưởng thành này xác định một thước đo thứ tự để đo đạc mức độ trưởng thành của tiến
trình phần mềm của tổ chức và cho việc đánh giá năng lực tiến trình phần mềm của tổ chức
đó. Các mức này cũng giúp cho một tổ chức thu xếp mức độ ưu tiên những cố gắng cải tiến
của nó.

Một mức trưởng thành là một trạng thái ổn định mang tính tiến hóa được định nghĩa
đầy đủ hướng tới việc đạt được tiến trình phần mềm trưởng thành. Mỗi một mức trưởng
thành bao gồm một tập các mục tiêu tiến trình mà khi nó được thỏa mãn, sẽ làm ổn định
một thành phần quan trọng của tiến trình phần mềm. Đạt tới một mức của khung trưởng
thành sẽ tạo ra các thành phần khác nhau trong tiến trình phần mềm, và kết quả là làm tăng
khả năng tiến trình của tổ chức.

Việc tổ chức CMM thành năm mức được thể hiện trong hình 2.1 sắp xếp ưu tiên các
hành động cải tiến cho việc tăng cường sự trưởng thành tiến trình phần mềm. Các mũi tên
được gán nhãn trong hình 2.1 thể hiện kiểu khả năng tiến trình được kết hợp lại bởi tổ chức
tại mỗi bước của khung trưởng thành.

11




2.1. Đặc tính cư xử của các mức trưởng thành

Các mức trưởng thành từ 2 đến 5 có thể được phân biệt thông qua các hành động thực
hiện mà tổ chức đưa ra hoặc cải tiến tiến trình phần mềm, bằng các hành động thực hiện
trong mỗi dự án và bằng khả năng tiến trình đạt được thông qua các dự án. Đặc tính cư xử
của một mức đưa ra một cơ sở cho việc so sánh việc cải tiến tiến trình ở mức độ trưởng
thành cao hơn.

2.1.1. Mức khởi đầu

Tại mức khởi đầu, tổ chức không cung cấp một môi trường ổn định cho việc phát
triển và bảo trì phần mềm. Các tổ chức như vậy thường xuyên có khó khăn trong việc cam
kết rằng nhân viên có thể thỏa mãn các tiến trình kỹ nghệ yêu cầu, và kết quả là hàng chuỗi
12


các khủng hoảng. Trong một cuộc khủng hoảng, các dự án thường không theo các thủ tục
được lên kế hoạch trước và thường bị quay lại giai đoạn lập trình và kiểm thử. Việc thành
công của dự án phụ thuộc phần lớn vào việc có một người quản lý giỏi ngoại lệ, và có nhóm

phát triển hiệu quả và dạn dày kinh nghiệm. Một tình trạng khá thường xuyên là, người quản
lý phần mềm tài ba và quyền lực có thể trụ vững trước áp lực phải làm tắt tiến trình phần
mềm; nhưng khi họ đã rời khỏi dự án, độ ổn định của dự án cũng đồng nghĩa rời đi. Thậm
chí một tiến trình kỹ nghệ tốt cũng không thể vượt qua được sự không ổn định tạo ra bởi sự
thiếu vắng của các thực tiễn quản lý hợp lý.

Cho dù tiến trình ở mức 1 là khó xác định, thậm chí lộn xộn, các tổ chức ở mức 1
thường xuyên phát triển các sản phẩm làm việc được, cho dù nó có thể vượt quá ngân sách
và khung lịch làm việc. Sự thành công của các tổ chức ở mức 1 phụ thuộc rất nhiều vào
năng lực và yếu tố cá nhân của con người trong tổ chức và không thể được lặp lại trừ khi có
người với cùng năng lực được đưa vào các dự án tiếp theo. Do vậy, tai mức 1, năng lực là
đặc điểm của các cá nhân chứ không phải của tổ chức.

2.1.2. Mức lặp lại được

Tại mức lặp lại được, các chính sách để quản lý dự án phần mềm và các thủ tục để
thực hiện các chính sách đó được đưa ra. Việc lên kế hoạch và quản lý các dự án mới
thường dựa vào kinh nghiệm từ các dự án tương tự trong quá khứ. Năng lực tiến trình được
cải thiện nhờ việc đưa ra quy tắc quản lý tiến trình cơ bản dựa trên cơ sở dự án này qua dự
án khác. Một tiến trình hiệu quả có thể được phân biệt nhờ tiến trình đó được thực hành, tài
liệu hóa, làm cho tuân thủ, đào tạo, đo đạc và có khả năng cải tiến.

Các dự án trong các tổ chức mức 2 thường thiết lập được các điểu khiển quản lý
phần mềm cơ bản. Các cam kết dự án thực tế thường được dựa trên những kết quả quan sát
từ những dự án trước và dựa trên các yêu cầu của dự án hiện tại. Các nhà quản lý dự án
phần mềm theo dõi các chi phí phần mềm, ước lịch và chức năng; các vấn đề trong các cuộc
họp cam kết được xác định khi chúng xuất hiện. Yêu cầu phần mềm và các sản phẩm công
việc được phát triển theo đúng mốc đã định, và sự tích hợp của chúng được quản lý. Các
chuẩn dự án phần mềm được xác định, và tổ chức đảm bảo chúng được tuân theo một cách
thích đáng. Dự án phần mềm làm việc với các nhà thầu phụ, nếu có, sẽ tạo được mối quan

hệ khách hàng – nhà cung cấp bền vững.
13



Các tiến trình có thể khác nhau giữa các dự án trong tổ chức ở mức 2. Yêu cầu về
mặt tổ chức để đạt được mức 2 là có chính sách hướng dẫn dự án trong việc tạo ra các tiến
trình quản lý hợp lý.

Năng lực tiến trình phần mềm trong các tổ chức ở mức 2 có thể được tổng kết thành
quy luật do việc tạo kế hoạch và theo dõi dự án phần mềm là ổn định và các sự thành công
từ sớm có thể được lặp lại. Tiến trình của dự án được đặt dưới sự kiểm soát có hiệu quả của
một hệ thống quản lý dự án, tuân theo các kế hoạch thực tế dựa trên hiệu năng của các dự
án trước.

2.1.3. Mức đã được xác định

Tại mức đã được xác định, một tiến trình chuẩn cho việc phát triển và bảo dưỡng
phần mềm được làm tài liệu cho toàn bộ tổ chức, bao gồm cả các tiến trình kỹ nghệ phần
mềm và tiến trình quản lý, và những tiến trình này được tích hợp thành một tổng thể chặt
chẽ thống nhất. Tiến trình chuẩn này được tham chiếu đến CMM như là tiến trình phần mềm
chuẩn của tổ chức. Các tiến trình được đưa ra trong CMM mức 3 được sử dụng (và thay đổi,
khi thích hợp) để trợ giúp các nhà quản lý phần mềm và nhân viên kỹ thuật làm việc có hiệu
quả hơn. Tổ chức khám phá các thực hành kỹ nghệ phần mềm hiệu quả khi chuẩn hóa các
tiến trình phần mềm của nó. Có một nhóm có trách nhiệm về các hoạt động tiến trình phần
mềm của tổ chức, ví dụ nhóm tiến trình kỹ nghệ phần mềm (SEPG : Software Engineering
Process Group). Một chương trình đào tạo rộng khắp tổ chức được thực hiện nhằm đảm bảo
rằng tất cả nhân viên và quản lý có đủ trí thức và kỹ năng yêu cầu để đáp ứng các vị trí
được giao.

Các dự án làm thay đổi tiến trình phần mềm chuẩn của tổ chức để phát triển tiến
trình phần mềm xác định của nó, cung cấp những đặc tính duy nhất của dự án. Tiến trình
được chỉnh sửa này được tham khảo đến trong CMM như là tiến trình phần mềm đã được
xác định của dự án. Một tiến trình phần mềm đã được xác định bao gồm một tập hợp các kỹ
nghệ phần mềm được định nghĩa tốt và các tiến trình quản lý tích hợp và thống nhất chặt
chẽ với nhau. Một tiến trình được định nghĩa tốt có thể được nhận ra bao gồm các chỉ tiêu
sẵn sàng, các đầu vào, các chuẩn mực và các thủ tục để thực hiện công việc, có cơ chế xác
minh (như xem xét ngang cấp), các đầu ra, và các chỉ tiêu hoàn thành. Bởi vì tiến trình phần
14


mềm được định nghĩa tốt, nên cấp quản lý có cái nhìn thực tế vào trong tiến trình kỹ thuật
của tất cả các dự án.

Năng lực tiến trình phần mềm của các tổ chức mức 3 có thể được tổng kết lại là
chuẩn và thống nhất bởi vì cả kỹ nghệ phần mềm và các hoạt động quản lý rất ổn định và có
thể lặp lại được. Trong đó các dải sản phẩm được đưa ra, giá cả, lịch hoàn thành, và các
chức năng được đặt dưới sự kiểm soát, và chất lượng phần mềm được theo dõi chặt chẽ.
Năng lực tiến trình này được sự hiểu biết chung, rộng khắp tổ chức của các hoạt động, các
vai trò, trách nhiệm trong một tiến trình phần mềm đã được xác định.

2.1.4. Mức được quản lý

Tại mức đã được quản lý, tổ chức đặt mục tiêu chất lượng phần mềm được lượng
hóa cho cả sản phẩm phần mềm và các tiến trình. Năng suất và chất lượng được đo đạc cho
các hoạt động tiến trình phần mềm quan trọng xuyên suốt tất cả các dự án như là một phần
của chương trình đánh giá tổ chức. Một cơ sở dứ liệu tiến trình phần mềm xuyên suốt tổ
chức được sử dụng để thu thập và phân tích các dữ liệu có sẵn từ các tiến trình phần mềm
đã được xác định của dự án. Các tiến trình phần mềm được cung cấp các công cụ để đo đạc
được xác đinh tốt và thống nhất tại mức 4. Các công cụ này đưa ra cơ sở về lượng cho việc

đánh giá các tiến trình phần mềm của dự án và sản phẩm.

Dự án đạt được những điều khiển thông qua các sản phẩm của nó và các tiến trình
bằng việc thu hẹp lại thay đổi trong hiệu năng tiến trình của chúng để rơi vào giới hạn về
lượng cho phép. Các sự thay đổi có ý nghĩa trong hiệu năng tiến trình có thể được phân biệt
nhờ các thay đổi ngẫu nhiên (nhiễu), đặc biệt là trong dòng sản phẩm đã được đưa ra. Các
rủi ro liên quan đến việc điều chỉnh lên cao việc học miền ứng dụng mới được biết đến và
quản lý chặt chẽ.

Năng lực tiến trình phần mềm của các tổ chức mức 4 có thể được tổng kết là có thể
được lượng hóa và dự đoán trước bởi vì các tiến trình được đo đạc và hoạt động trong giới
hạn lượng hóa. Mức năng lực tiến trình này cho phép một tổ chức có thể dự đoan được xu
hướng trong tiến trình và chất lượng sản phẩm trong một biên lượng hóa của các giới hạn
này. Bởi vì tiến trình là cả ổn định và đo đạc được, cho nên khi một vài trường hợp ngoại lệ
xuất hiện, “nguyên nhân đặc biệt” của sự biến đổi có thể được xác định và xử lý. Khi giới
15


hạn được biết đến của tiến trình bị vượt qua, hành động sẽ được thực hiện để khắc phục
tình huống. Sản phẩm phần mềm được coi là có chất lượng cao và dự đoán được.

2.1.5. Mức 5 – Mức tối ưu

Tại mức tối ưu, toàn bộ tổ chức tập trung vào việc cải tiến tiến trình không ngừng. Tổ
chức sẽ có công cụ để xác định điểm yếu và nâng cao tiến trình một cách chủ đông linh hoạt,
với mục tiêu là ngăn ngừa sự xuất hiện của lỗi. Dữ liệu của độ hiệu quả của tiến trình phần
mềm được sử dụng để thực hiện việc phân tích giá trị và lợi nhuận của các công nghệ mới
và đưa ra các đề nghị thay đổi tiến trình phần mềm của tổ chức. Sự năng động mà tìm ra
những thực hành kỹ nghệ phần mềm tốt nhất được xác định và chuyển giao xuyên suốt tổ
chức.

Nhóm dự án phần mềm trong các tổ chức ở mức 5 thực hiện việc phân tích lỗi để tìm
ra nguyên nhân của chúng. Các tiến trình phần mềm được đánh giá để ngăn ngừa những
loại lỗi đã được biết đến xuất hiện lại, và các bài học kinh nghiệm được phổ biến cho các dự
án khác.

Có một sự lãng phí kinh niên, theo kiểu làm lại, trong bất kỳ một hệ thống nào đơn
giản là vì sự thay đổi ngẫu nhiên. Lãng phí là không chấp nhận được, những nỗ lực được tổ
chức để loại bỏ sự lãng phí dẫn đến kết quả là hệ thống thay đổi, ví dụ cải tiến một tiến trình
bằng việc thay đổi “các nguyên nhân chung” của sự không hiệu quả để ngăn chặn sự lãng
phí xuất hiện. Trong khi điều này là đúng với tất cả các mức trưởng thành, nó được tập
trung tại mức 5.

Năng lực tiến trình phần mềm của các tổ chức ở mức 5 có thể được nhận ra là sự liên
tục cải tiến do các tổ chức ở mức 5 luôn cố gắng không ngừng để cải tiến dải của năng lực
tiến trình của họ, do vậy cải tiến hiệu năng tiến trình của các dự án . Sự cải tiến xuất hiện do
cả sự tiến bộ không ngừng trong tiến trình hiện thời và bởi sự sáng tạo sử dụng các công
nghệ và phương pháp mới. Sự cải tiến về công nghệ và tiến trình được lên kế hoạch và quản
lý chặt chẽ như là các hoạt động kinh doanh bình thường.

2.2. Năng lực tiến trình và dự báo hiệu năng

16


Sự trưởng thành của một tiến trình phần mềm của tổ chức giúp cho việc dự báo khẳ
năng của dự án thỏa mãn các mục tiêu của nó. Dự án trong các tổ chức mức 1 trải qua rất
nhiều sự thay đổi lớn trong việc đạt được giá cả, lịch biểu, chức năng, và các mục tiêu chất
lượng. Như được thể hiện trong hình 2.4, ba sự cải tiến trong việc đạt đến các mục tiêu đích
được mong đợi như là sự trưởng thành tiến trình phần mềm của tổ chức. Những sự mong

đợi này được dựa trên các kết quả lượng hóa việc cải tiến tiến trình mà đã đạt được trong
các ngành công nghiệp khác, và chúng thống nhất với các kết quả trường hợp ban đầu được
báo cáo bởi các tổ chức phần mềm.

Thứ nhất, khi độ trưởng thành tăng lên, sự chênh lệch giữa kết quả đích và kết quả
thực tế giảm đi qua các dự án. Ví dụ, các tổ chức ở mức 1 thường để lỡ ngày giao hàng theo
lịch biểu ban đầu với một độ chênh lệch lớn, trong khi các tổ chức ở mức độ trưởng thành
cao hơn có khả năng đạt được ngày đích với độ chính xác cao. (Điều này được thể hiện
trong hình 2.4 bởi độ lớn của vùng phía dưới đường cong nằm ở bên phải của đường đích).

Thứ hai, khi độ trưởng thành tăng lên, khả năng thay đổi của kết quả thực tế xung
quanh kết quả đích giảm đi. Ví dụ, trong các tổ chức mức 1, ngày giao hàng cho các dự án
có cùng kích cỡ thường không đoán được và thay đổi rất nhiều. Tuy nhiên, các dự án tương
tự trong tổ chức với mức trưởng thành cao hơn sẽ được giao hàng trong dải nhỏ. (Điều này
được thể hiện trong hình 2.4 bởi độ lớn của vùng phía dưới đường cong được tập trung gần
đường đích).

Thứ ba, các kết quả đích được cải tiến khi mức độ trưởng thành của tổ chức tăng lên.
Điều này có nghĩa là, khi một tổ chức phần mềm trưởng thành, giá phần mềm sẽ giảm, thời
gian phát triển trở nên ngắn hơn, năng suất và chất lượng sẽ tăng lên. Trong một tổ chức ở
mức 1, thời gian phát triển có thể rất dài do số lượng phải làm lại lớn để sửa lỗi. Trái lại, các
tổ chức với mức trưởng thành cao hơn đã tăng độ hiệu quả của tiến trình và giảm việc làm
lại liên quan đến giá, cho phép thời gian phát triển trở nên ngắn hơn. (Điều này được thể
hiện trong hình 2.4 bởi sự dịch chuyển ngang của đường đích từ vị trí ban đầu).

Sự cải tiến trong việc dự báo kết quả của một dự án được thể hiện trong hình 2.4.
Giả thiết rằng đầu ra của dự án phần mềm trở nên dễ đoán hơn là nhiễu, thường là trong
khuôn dạng làm lại, bị loại khỏi từ tiến trình phần mềm. Các hệ thống chưa có tiền lệ làm
phức tạp bức tranh do các công nghệ và ứng dụng mới làm giảm khả năng tiến trình bằng
17

việc tăng cường thay đổi. Thậm chí trong trường hợp của các hệ thống chưa có tiền lệ, đặc
điểm thực hành quản lý và kỹ nghệ của các tổ chức trưởng thành hơn giúp cho việc xác định
và giải quyết các vấn đề trong giai đoạn sớm của vòng đời phát triển hơn là chúng được
phát hiện trong các tổ chức ở mức trưởng thành thấp hơn. Trong một vài trường hợp, một
tiến trình trưởng thành có nghĩa là dự án “thất bại” được xác định sớm trong vòng đời phần
mềm và sự đầu tư mất mát được tối thiểu hóa.

Các trường hợp được ghi lại của việc cải tiến tiến trình phần mềm chỉ ra rằng, có sự
cải tiến đáng kể trong cả chất lượng lẫn năng suất như là kết quả của nỗ lực cải tiến. Tỷ lệ
tái đầu tư điển hình từ trong dải 5:1 đến 8:1 cho các nỗ lực cải tiến tiến trình thành công.



2.3. Bỏ qua các mức trưởng thành

18


Việc cố gắng bỏ qua các mức trưởng thành là không hiệu quả vì mỗi một mức trưởng
thành trong mô hình CMM hình thành một cơ sở cần thiết để từ đó có thể đạt được mức tiếp
theo. Mô hình CMM chỉ ra các mức mà thông qua đó một tổ chức nên liên đới tạo ra một văn
hóa kỹ nghệ phần mềm hoàn hảo. Các tổ chức có thể tập hợp các cải tiến tiến trình nhất
định tại bất cứ thời điểm nào họ chọn, thậm chí là trước khi chúng được chuẩn bị để đạt
được mức mà tại đó các thực hành nhất định được đề nghị. Tuy nhiên, các tổ chức nên hiểu
rằng, sự ổn định của các cải tiến đó sẽ có độ rủi ro cao hơn do cơ sở của sự tập hợp thành
công của chúng vẫn chưa được hoàn thiện. Các tiến trình mà thiếu đi cơ sỏ thích hợp sẽ
không thành công tại chính điểm mà chúng được cần đến nhất – dưới áp lực – và chúng
không cung cấp cơ sở gì cho sự cải tiến trong tương lai.

Ví dụ, một tiến trình phần mềm được định nghĩa tốt là đặc điểm của các tổ chức ở
mức 3, có thể được thay thế ở mức rủi ro lớn hơn nếu mức quản lý cam kết một lịch biểu
được lên kế hoạch nghèo nàn hoặc không điều khiển được các thay đổi đối với các yêu cầu
dòng cơ bản. Tương tự như vậy, rất nhiều các tổ chức đã thu thập đặc điểm dữ liệu chi tiết
của mức 4, chỉ để tìm ra rằng dữ liệu không thể hiểu được bởi vì sự không thống nhất trong
các tiến trình phát triển phần mềm.

Tại cùng một thời điểm, người ta nhận ra rằng các nỗ lực cải tiến tiến trình nên tập
trung vào nhu cầu của tổ chức trong ngữ cảnh của môi trường kinh doanh của nó, và các
thực hành ở mức cao hơn có thể giải quyết nhu cầu hiện tại của một tổ chức hoặc dự án. Ví
dụ, khi miêu tả các bước mà một tổ chức nên thực hiện để chuyển từ mức 1 sang mức 2,
một trong những gợi ý thường xuyên là tạo ra nhóm kỹ nghệ tiến trình phần mềm (SEPG),
mà nó là một thuộc tính của các tổ chức mức 3. Trong khi SEPG là một đặc tính chưa cần
thiết của tổ chức mức 2, chúng có thể là một phần có ích của việc miểu tả để đạt được mức
2.

3. Định nghĩa theo kiểu hoạt động của mô hình CMM

CMM là một bộ khung thể hiện con đường của việc cải tiến, gợi ý cho các tổ chức
phần mềm muốn tăng cường khả năng tiến trình phần mềm của họ. Việc sáng tạo hoạt động
này của CMM được thiết kế để hỗ trợ rất nhiều cách mà nó có thể sẽ được sử dụng. Hiện
nay người ta hỗ trợ ít nhất là 4 cách sử dụng của CMM:

19


 Các nhóm đánh giá sẽ sử dụng CMM để xác định điểm mạnh và điểm yếu
trong tổ chức.
 Các nhóm đánh giá sẽ sử dụng CMM để xác định các rủi ro của việc lựa chọn

giữa các nhà thầu khác nhau để có được hợp đồng và giám sát các hợp đồng.
 Mức quản lý cao hơn sẽ sử dụng CMM để hiểu được các hoạt động thiết yếu
nhằm đưa ra chương trình cải tiến tiến trình phần mềm trong tổ chức của họ.
 Nhân viên kỹ thuật và các nhóm cải tiến tiến trình như SEPG sẽ sử dụng CMM
để hướng dẫn giúp họ xác định và cải tiến tiến trình phần mềm trong tổ chức
của họ.

Do cách sử dụng đa dạng của CMM, nó phải được phân nhỏ ra thành những chi tiết
đủ nhỏ mà những gợi ý tiến trình thực tế có thể được biến đổi từ cấu trúc của các mức
trưởng thành. Sự phân chia này cũng chỉ ra rằng, các tiến trình then chốt và cấu trúc của nó
làm nên đặc điểm của sự trưởng thành tiến trình phần mềm và khả năng tiến trình phần
mềm.

3.1. Cấu trúc bên trong của các mức trưởng thành

Mỗi một mức trưởng thành lại được phân chia thành các phần nhỏ hợp thành. Với
ngoại lệ mức 1, việc phân chia của mỗi mức trưởng thành nằm trong dải từ các tổng kết
trừu tượng của mỗi mức đến định nghĩa hoạt động của chúng trong các thực hành then chốt,
như được thể hiện trông hình 3.1. Mỗi một mức trưởng thành bao gồm nhiều vùng tiến trình
then chốt. Mỗi một vùng tiến trình then chốt được tổ chức thành 5 phần gọi là các đặc điểm
chung. Những đặc điểm chung này xác định các thực hành then chốt mà khi được giải quyết
tập trung, nó sẽ đạt được mục tiêu của vùng tiến trình then chốt.

3.2. Các mức trưởng thành

Một mức trưởng thành là một trạng thái ổn định tiến hóa được xác định tốt với mục
đích đạt được tiến trình phần mềm trưởng thành. Mỗi một mức trưởng thành chỉ ra một mức
của khả năng tiến trình, như được thể hiện trong hình 2.1. Ví dụ, tại mức 2 năng lực tiến
trình của một tổ chức đã được chuyển từ tình trạng lộn xộn lên có quy tắc bằng việc đưa ra
các điều khiển quản lý dự án hợp lý.

20




3.3. Các vùng tiến trình then chốt

Ngoại trừ mức 1, mỗi một mức trưởng thành được kết hợp từ các vùng tiến trình
then chốt chỉ ra chỗ tổ chức nên tập trung để cải tiến tiến trình phần mềm của nó. Các vùng
tiến trình then chốt xác định các vấn đề cần phải giải quyết để đạt được một mức trưởng
thành.

Một vùng tiến trình then chốt xác định chuỗi các hoạt động liên quan đến nhau, mà
khi được thực hiện tập trung, sẽ đạt được một tập các mục tiêu quan trọng đáng kể cho việc
cải thiện khả năng tiến trình. Các vùng tiến trình then chốt đã được định nghĩa để tạo ra một
mức trưởng thành đơn như được thể hiện trong hình 3.2. Một con đường đạt được mục tiêu
của một vùng tiến trình then chốt có thể khác nhau qua các dự án dựa trên sự khác nhau
21


của các lĩnh vực ứng dụng cũng như môi trường. Tuy nhiên, để thỏa mãn một vùng tiến
trình then chốt thì phải đạt được tất cả các mục tiêu của nó trong trong tổ chức.

Tính từ “then chốt” ngụ ý rằng, có các vùng tiến trình (và tiến trình) mà không phải
là then chốt để đạt được một mức trưởng thành. Mô hình CMM không miêu tả chi tiết tất cả
các vùng tiến trình mà có liên quan đến trong việc phát triển và bảo trì phần mềm. Các vùng
tiến trình nhất định đã được xác định như là nhân tố quyết định chủ yếu của khả năng tiến
trình; chúng là các vùng được miêu tả trong CMM.

Các vùng tiến trình then chốt có thể được coi là yêu cầu để đạt được một mức trưởng
thành. Để đạt được một mức trưởng thành, các vùng tiến trình then chốt của mức đó phải
được thỏa mãn.


22



Các thực hành đặc biệt được thi hành trong mỗi vùng tiến trình then chốt sẽ liên đới
khi tổ chức đạt đến mức cao hơn của sự trưởng thành tiến trình. Ví dụ, rất nhiều khả năng
ước tính phần mềm được miêu tả trong vùng tiến trình then chốt Lên kế hoạch dự án phần
mềm (Software Project Planning) phải liên đới để quản lý dữ liệu dự án thêm sẵn có tại mức
3, như được miêu tả trong “Quản lý dự án tích hợp” (Integrated Software Management).

Các vùng tiến trình then chốt tại mức 2 tập trung giải quyết các quan tâm về dự án
phần mềm liên quan đến việc thiết lập các điều khiển quản lý dự án cơ sở.

 Mục đích của Quản lý yêu cầu (Requirement Management) là tạo ra một sự
hiểu biết chung giữa khách hàng và dự án phần mềm của yêu cầu khách hàng
mà sẽ được giải quyết bởi dự án phần mềm. Sự đồng thuận này với khách
hàng là cơ sở cho việc lên kế hoạch và quản lý dự án phần mềm.

 Mục đích của Lên kế hoạch dự án phần mềm (Software Project Planning) là
để tạo ra một kế hoạch phù hợp cho việc thực hiện các kỹ nghệ phần mềm và
cho việc quản lý dự án phần mềm. Các kế hoạch này là cơ sở cần thiết cho
việc quản lý dự án phần mềm.

 Mục đích của Giám sát và trông trước dự án phần mềm (Software Project
Tracking and Oversight) là để tạo ra cái nhìn chính xác vào tiến độ thực tế để

cấp quản lý có thể thực hiện các hành động hiệu quả khi mà tiến độ thực tế
của dự án phần mềm bị thay đổi đi so với kế hoạch.

 Mục đích của Quản lý thầu phụ phần mềm (Software Subcontract
Management) là để chọn lựa được các nhà thầu phụ phần mềm chất lượng và
quản lý họ một cách hiệu quả.

 Mục đích của Đảm bảo chất lượng phần mềm (Software Quality Assurance) là
để cung cấp cho cấp quản lý một cái nhìn thích hợp vào quy trình đang được
sử dụng bởi dự án và vào các sản phẩm đang được xây dựng.

23


 Mục đích của Quản lý cấu hình phần mềm (Software Configuration
Management) là thiết lập và duy trì sự tích hợp của các sản phẩm của dự án
phần mềm xuyên suốt vòng đời dự án phần mềm.

Các vùng tiến trình then chốt ở mức 3 giải quyết các vấn đề ở các mức dự án và tổ
chức, khi mà tổ chức thiết lập nên một cấu trúc hạ tầng mà kết hợp kỹ nghệ phần mềm hiệu
quả và các tiến trình quản lý xuyên suốt tất cả các dự án.

 Điểm tập trung của tiến trình tổ chức (Organization Process Focus) là thiết lập
trách nhiệm của tổ chức cho các hoạt động tiến trình phần mềm nhằm cải
tiến tổng thể khả năng tiến trình phần mềm của tổ chức.

 Xác định nghĩa tiến trình tổ chức (Organization Process Definition) là phát
triển và duy trì một tập các đánh giá tiến trình phần mềm có ích để cải tiến
hiệu năng tiến trình xuyên suốt các dự án và cung cấp một cơ sở cho việc xác
định dữ liệu có nghĩa cho việc quản lý tiến trình một cách định lượng. Các

đánh giá này cung cấp một cơ sở ổn định mà có thể kết hợp lại thông qua các
cơ chế như đào tạo.

 Mục tiêu của Chương trình đào tạo (Training Program) là phát triển kỹ năng
và kiến thức của các cá nhân để họ thực hiện vai trò của họ một cách hiệu
quả và năng suất. Đào tạo là trách nhiệm của tổ chức, nhưng các dự án phần
mềm cần phải xác định các kỹ năng cấn thiết của nó và cung cấp đào tạo cần
thiết khi yêu cầu của dự án là cần thiết.

 Mục đích của Quản lý phần mềm tích hợp (Integrated Software Management)
là tích hợp kỹ nghệ phần mềm và các hoạt động quản lý thành một tiến trình
phần mềm thống nhất, được xác định mà được thay đổi từ tiến trình phần
mềm chuẩn của tổ chức và các đánh giá phần mềm liên quan. Sự thay đổi
này dựa trên môi trường kinh doanh và các yêu cầu về mặt kỹ thuật của dự
án.

 Mục đích của Kỹ nghệ sản phẩm phần mềm “Software Product Engineering” là
thực hiện thống nhất tiến trình kỹ nghệ được định nghĩa tốt mà tích hợp tất
24


cả các hoạt động kỹ nghệ phần mềm để sản xuất ra các sản phẩm phần mềm
chính xác, thống nhất, hiệu quả và có tác dụng. Kỹ nghệ sản phẩm phần mềm
miêu tả các hoạt động kỹ thuật của dự án, như phân tích yêu cầu, thiết kế,
lập trình, kiểm thử.

 Mục đích của Điều phối giữa các nhóm (Intergroup Coordination) là thiết lập
các công cụ cho nhóm kỹ nghệ phần mềm tham gia một cách chủ động với
các nhóm kỹ nghệ khác do đó dự án thỏa mãn tốt hơn yêu cầu khách hàng
một cách hiệu quả và tác dụng.

 Mục đích của rà soát ngang cấp (Peer Reviews) là loại bỏ các lỗi ra khỏi sản
phẩm công việc phần mềm từ sớm và hiệu quả. Hệ quả tất yếu quan trọng là
phát triển một sự hiểu biết tốt hơn của các sản phẩm công việc phần mềm và
của các lỗi mà có thể ngăn ngừa. Xem xét ngang cấp là một phương thức kỹ
nghệ hiệu quả và quan trọng mà có thể được thi hành thông qua việc kiểm
tra, xem xét cấu trúc hoặc các phương thức xem xét đồng nghiệp khác.

Các vùng tiến trình then chốt ở mức 4 tập trung vào việc thiết lập nên một sự hiểu
biết lượng hóa về cả tiến trình phần mềm và các sản phẩm công việc phần mềm đang được
xấy dựng.

 Mục đích của Quản lý tiến trình định lượng (Quantitative Process
Management) là điều khiển hiệu năng tiến trình của dự án phần mềm một
cách định lượng. Hiệu năng tiến trình phần mềm thể hiện kết quả thực tế đạt
được từ việc tuân theo tiến trình phần mềm. Sự tập trung là ở chỗ xác định
các nguyên nhân đặc biệt của sự thay đổi trong một tiến trình ổn định đo đạc
được và sửa lỗi khi thích hợp, các hoàn cảnh làm cho những biến đổi nhất
thời xuất hiện.

 Mục tiêu của Quản lý chất lượng phần mềm (Software Quality Management)
là phát triển một sự hiểu biết đinh lượng của chất lượng của sản phẩm phần
mềm của dự án và đạt được các mục tiêu chất lượng cụ thể.

25


Các vùng tiến trình then chốt ở mức 5 bao trùm các vấn đề ở cả mức tổ chức và dự
án cần phải giải quyết để thi hành việc cải tiến tiến trình phần mềm liên tục và đo
đạc được.

 Mục tiêu của Ngăn ngừa khiếm khuyết (Defect Prevention) là xác định nguyên
nhân của lỗi và ngăn chúng tái xuất hiện. Dự án phần mềm phân tích lỗi, xác
định nguyên nhân của chúng, và thay đổi tiến trình phần mềm đã được định
nghĩa của nó.

 Mục tiêu của Quản lý thay đổi công nghệ (Technology Change Management)
là xác định các công nghệ mới đem lại lợi ích (như công cụ, phương thức, tiến
trình ) và chuyển giao chúng vào trong tổ chức theo một trật tự hợp lý. Việc
tập trung vào Quản lý thay đổi công nghệ đang được thực hiện sáng tạo hiệu
quả trong một thế giới thay đổi hàng ngày.

 Mục tiêu của Quản lý thay đổi tiến trình (Process Change Management) là sự
cải tiến liên tục của các tiến trình phần mềm được sử dụng trong tổ chức với ý
định cải tiến chất lượng phần mềm, tăng năng suất, và giảm thời gian vòng
đời của việc phát triển sản phẩm.

3.4. Các mục tiêu

Các mục tiêu tổng hợp các thực hành then chốt của một vùng tiến trình then chốt và
có thể được sử dụng để quyết định xem liệu một tổ chức hay dự án có thi hành được một
vùng tiến trình then chốt một cách hiệu quả hay không. Các mục tiêu cụ thể hóa phạm vi,
ranh giới và mục đích của mỗi một vùng tiến trình then chốt. Sự thỏa mãn một vùng tiến
trình then chốt (KPA) được quyết định bởi sự đạt được của các mục tiêu.

3.5. Các đặc điểm chung

Để cho thuận tiện, các thực hành miêu tả các vùng tiến trình then chốt được tổ chức
thành các đặc tính chung. Các đặc tính chung này là các thuộc tính mà chỉ ra rằng, liệu sự
thi hành và kết hợp của một vùng tiến trình then chốt là có hiệu quả, lặp lại được và kéo dài

hay không. Có năm đặc điểm chung như sau: