Nghiên cứu việc áp dụng CMMI.doc

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

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
MỤC LỤC
1. TỔNG QUAN ĐỀ TÀI ................................................................................................................. 6
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 ............................................................................................................................................. 8
2.1. Khái niệm quy trình phần mềm ....................................................................................... 8
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 ...................................................................................................................... 9
2.2.1. Mô hình RUP ............................................................................................................... 9
2.2.2. Mô hình XP ................................................................................................................ 14
3. MÔ HÌNH CMMI ........................................................................................................................ 21

3.1. Khái niệm CMMI .............................................................................................................. 21
3.1.1. Tổng quan về CMMI .................................................................................................. 21
3.1.2. Cấu trúc CMMI ........................................................................................................... 24
3.1.3. Ưu điểm của CMMI .................................................................................................... 30
3.2. Các lĩnh vực quy trình (PAs) trong CMMI ..................................................................... 31
3.2.1. Các PAs về quản lý quy trình (Process Management Process Areas) ..................... 31
3.2.2. Các lĩnh vực quy trình về quản lý dự án - Project Management Process Areas ...... 37
3.2.3. Các lĩnh vực quy trình kỹ nghệ - Engineering Process Areas ................................... 45
3.2.4. Các lĩnh vực quy trình hỗ trợ - Support Process Areas ............................................ 54
3.2.5. Mối quan hệ giữa các lĩnh vực quy trình ................................................................... 59
4. ÁP DỤNG CMMI LEVEL 3 TẠI VIETSOFTWARE .................................................................. 61
4.1. Thực trạng quy trình sản xuất phần mềm tại VietSoftware ....................................... 61
4.1.1. Sơ lược về tổ chức và hoạt động của VSI ................................................................ 61
4.1.2. Thực trạng sản xuất phần mềm tại VSI ..................................................................... 63
4.2. Các KPAs cần thực hiện để áp dụng CMMI Level 3 tại VSI ........................................ 69
4.2.1. Các lĩnh vực quy trình ở CMMI mức 2 ...................................................................... 69
4.2.2. Các lĩnh vực quy trình ở CMMI mức 3 .................................................................... 116
5. KẾT LUẬN .............................................................................................................................. 143
6. PHỤ LỤC A. TỪ VIẾT TẮT .................................................................................................... 144
7. PHỤ LỤC B. MỘT SỐ THUẬT NGỮ ĐƯỢC DÙNG TRONG CMMI .................................... 146
8. PHỤ LỤC C. TÀI LIỆU THAM KHẢO .................................................................................... 149
Đồ án tốt nghiệp Đại học Mục lục
DANH MỤC HÌNH VẼ
Hình 2-1: Cấu trúc RUP..............................................................................................................12
Hình 3-2: Ba tiêu chuẩn quan trọng đối với một quy trình....................................................21
Hình 3-3: Các bước của mô hình CMM cho phần mềm..........................................................24
Hình 3-4: Sơ lược các mức năng lực.......................................................................................26
Hình 3-5: Các thành phần của mô hình CMMI trong cách biểu diễn phân tầng .................27
Hình 3-6: Các thành phần của mô hình CMMI trong cách biểu diễn liên tục.......................28
Hình 3-7: Các PA trong nhóm Process Management.............................................................32

Hình 3-8: Định nghĩa quy trình tổ chức....................................................................................33
Hình 3-9: Tập trung vào quy tình tổ chức................................................................................34
Hình 3-10: Phát triển vào cải tiến tổ chức...............................................................................35
Hình 3-11: Đào tạo trong tổ chức.............................................................................................36
Hình 3-12: Các PA trong nhóm Project Management.............................................................38
Hình 3-13: Lập kế hoạch dự án.................................................................................................39
Hình 3-14: Kiểm soát và theo dõi dự án...................................................................................40
Hình 3-15: Quản lý dự án tích hợp...........................................................................................41
Hình 3-16: Quản lý dự án tích hợp trong IPPD........................................................................42
Hình 3-17: Quản lý định lượng dự án.......................................................................................43
Hình 3-18: Quản lý thỏa thuận với nhà thầu phụ....................................................................44
Hình 3-19: Quản lý rủi ro............................................................................................................45
Hình 3-20: Quản lý yêu cầu........................................................................................................47
Hình 3-21: Phát triển yêu cầu....................................................................................................48
Hình 3-22: Giải pháp kỹ thuật....................................................................................................50
Hình 3-23: Tích hợp sản phẩm..................................................................................................51
Hình 3-24: Thẩm định (Verification)..........................................................................................52
Hình 3-25: Phê duyệt (Validation).............................................................................................53
Hình 3-26: Quản lý cấu hình......................................................................................................55
Hình 3-27: Đảm bảo chất lượng quy trình và chất lượng sản phẩm....................................56
Hình 3-28: Đo lường và phân tích.............................................................................................57
Hình 3-29: Phân tích quyết định và giải pháp..........................................................................58
Hình 3-30: Phân tích nguyên nhân và giải pháp......................................................................59
- iii -
Đồ án tốt nghiệp Đại học Mục lục
Hình 4-31: Mô hình quy trình quản lý yêu cầu.........................................................................70
Hình 4-32: Sơ đồ tổng quát của qui trình Lập kế hoạch dự án (Project Planning).............78
Hình 4-33: Sơ đồ tổng quát của qui trình Giám sát và Kiểm soát dự án..............................92
Hình 4-34: Sơ đồ tổng quát của quy trình Đo lường và Phân tích.....................................100
Hình 4-35: 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...................................................................................................................................105
Hình 4-36: Sơ đồ tổng quát của qui trình Quản lý cấu hình...............................................109
Hình 4-37: Mô hình quy trình tích hợp sản phẩm..................................................................119
Hình 4-38: Mô hình quy tình thẩm định (Verification)...........................................................122
Hình 4-39: Mô hình quy trình đào tạo của tổ chức...............................................................128
Hình 4-40: Mô hình quy trình quản lý rủi ro...........................................................................136
Hình 4-41: Mô hình quy trình Phân tích quyết định và Giải pháp (DAR)............................139
- iv -

1. 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
• Á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.
Đặng Thị Huyền Linh −7− 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:
Đồ án tốt nghiệp Đại học CMMI và Quy trình sản xuất phần
mề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
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ữ
Đặng Thị Huyền Linh −9− Lớp 2001CNTT
Đồ án tốt nghiệp Đại học CMMI và Quy trình sản xuất phần
mềm
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.
• 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:
Đặng Thị Huyền Linh −10− Lớp 2001CNTT
Đồ án tốt nghiệp Đại học CMMI và Quy trình sản xuất phần
mề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
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:
Đặng Thị Huyền Linh −11− Lớp 2001CNTT
Đồ án tốt nghiệp Đại học CMMI và Quy trình sản xuất phần
mềm

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
5. Kiểm thử (Test)
Đặng Thị Huyền Linh −12− Lớp 2001CNTT
Đồ án tốt nghiệp Đại học CMMI và Quy trình sản xuất phần
mềm
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
Đị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
Lập kế hoạch dự án
Project Management,
Environment
Đặng Thị Huyền Linh −13− Lớp 2001CNTT
Đồ án tốt nghiệp Đại học CMMI và Quy trình sản xuất phần
mềm
Project management
Wo
rk
flo
w
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,
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 ở
Đặng Thị Huyền Linh −14− Lớp 2001CNTT
Đồ án tốt nghiệp Đại học CMMI và Quy trình sản xuất phần
mềm
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
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
Đặng Thị Huyền Linh −15− Lớp 2001CNTT
Đồ án tốt nghiệp Đại học CMMI và Quy trình sản xuất phần
mềm

Trách nhiệm của khách hàng:
• 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.
Đặng Thị Huyền Linh −16− Lớp 2001CNTT
Đồ án tốt nghiệp Đại học CMMI và Quy trình sản xuất phần
mềm
Tổ chức lại chương trình ( Refactoring )
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.
Đặng Thị Huyền Linh −17− Lớp 2001CNTT
Đồ án tốt nghiệp Đại học CMMI và Quy trình sản xuất phần
mềm
c. Điều kiện để áp dụng XP
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
Đặng Thị Huyền Linh −18− Lớp 2001CNTT
Đồ án tốt nghiệp Đại học CMMI và Quy trình sản xuất phần
mềm

CMMI XP
Process management
Tập trung vào quy trình tổ chức Sustainable Pace
Đị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
Đặng Thị Huyền Linh −19− Lớp 2001CNTT
Đồ án tốt nghiệp Đại học CMMI và Quy trình sản xuất phần
mềm
XP
Pra
ctic
es
Đả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
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
Đặng Thị Huyền Linh −20− 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-2: 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.
Đồ án tốt nghiệp Đại học Mô hình CMMI
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
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
Đặng Thị Huyền Linh −22− Lớp 2001CNTT