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

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

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

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

Đồ á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

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 1

2 KHÁI NIỆM QUY TRÌNH SẢN XUẤT PHẦN MỀM VÀ MỖI LIÊN HỆ GIỮA CMMI VÀ QUY TRÌNH 3

2.1 Khái niệm quy trình phần mềm 3

2.2 Một số quy trình phần mềm được áp dụng trong thực tế và mối liên hệ giữa quy trình đó và CMMI 4

2.2.1 Mô hình RUP 4

2.2.2 Mô hình XP 9

3 MÔ HÌNH CMMI 16

3.1 Khái niệm CMMI 16

3.1.1 Tổng quan về CMMI 16

3.1.2 Cấu trúc CMMI 19

3.1.3 Ưu điểm của CMMI 25

3.2 Các lĩnh vực quy trình (PAs) trong CMMI 26

3.2.1 Các PAs về quản lý quy trình (Process Management Process Areas) 26

3.2.2 Các lĩnh vực quy trình về quản lý dự án - Project Management Process Areas 32 3.2.3 Các lĩnh vực quy trình kỹ nghệ - Engineering Process Areas 40

3.2.4 Các lĩnh vực quy trình hỗ trợ - Support Process Areas 49

3.2.5 Mối quan hệ giữa các lĩnh vực quy trình 55

4 ÁP DỤNG CMMI LEVEL 3 TẠI VIETSOFTWARE 57

4.1 Thực trạng quy trình sản xuất phần mềm tại VietSoftware 57

4.1.1 Sơ lược về tổ chức và hoạt động của VSI 57

4.1.2 Thực trạng sản xuất phần mềm tại VSI 59

4.2 Các KPAs cần thực hiện để áp dụng CMMI Level 3 tại VSI 65

4.2.1 Các lĩnh vực quy trình ở CMMI mức 2 65

4.2.2 Các lĩnh vực quy trình ở CMMI mức 3 111

5 KẾT LUẬN 139

PHỤ LỤC A TỪ VIẾT TẮT 140

PHỤ LỤC B MỘT SỐ THUẬT NGỮ ĐƯỢC DÙNG TRONG CMMI 142

PHỤ LỤC C TÀI LIỆU THAM KHẢO 146

Hình 2-1: Cấu trúc RUP 7

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

Hình 3-2: Các bước của mô hình CMM cho phần mềm 19

Hình 3-3: Sơ lược các mức năng lực 21

Hình 3-4: Các thành phần của mô hình CMMI trong cách biểu diễn phân tầng 22

Hình 3-5: Các thành phần của mô hình CMMI trong cách biểu diễn liên tục 23

Hình 3-6: Các PA trong nhóm Process Management 27

Hình 3-7: Định nghĩa quy trình tổ chức 28

Hình 3-8: Tập trung vào quy tình tổ chức 29

Hình 3-9: Phát triển vào cải tiến tổ chức 30

Hình 3-10: Đào tạo trong tổ chức 31

Hình 3-11: Các PA trong nhóm Project Management 33

Hình 3-12: Lập kế hoạch dự án 34

Hình 3-13: Kiểm soát và theo dõi dự án 35

Hình 3-14: Quản lý dự án tích hợp 36

Hình 3-15: Quản lý dự án tích hợp trong IPPD 37

Hình 3-16: Quản lý định lượng dự án 38

Hình 3-17: Quản lý thỏa thuận với nhà thầu phụ 39

Hình 3-18: Quản lý rủi ro 40

Hình 3-19: Quản lý yêu cầu 42

Hình 3-20: Phát triển yêu cầu 43

Hình 3-21: Giải pháp kỹ thuật 45

Hình 3-22: Tích hợp sản phẩm 46

Hình 3-23: Thẩm định (Verification) 48

Hình 3-24: Phê duyệt (Validation) 49

Hình 3-25: Quản lý cấu hình 51

Hình 3-26: Đảm bảo chất lượng quy trình và chất lượng sản phẩm 52

Hình 3-27: Đo lường và phân tích 53

Hình 3-28: Phân tích quyết định và giải pháp 54

Hình 3-29: Phân tích nguyên nhân và giải pháp 55

Hình 4-1: Mô hình quy trình quản lý yêu cầu 66

Hình 4-2: Sơ đồ tổng quát của qui trình Lập kế hoạch dự án (Project Planning) 74

Hình 4-3: Sơ đồ tổng quát của qui trình Giám sát và Kiểm soát dự án 88

Hình 4-4: Sơ đồ tổng quát của quy trình Đo lường và Phân tích 92

Hình 4-5: Sơ đồ tổng quát của quy trình đảm bảo chất lượng quy trình và chất lượng sản

phẩm 99

Hình 4-6: Sơ đồ tổng quát của qui trình Quản lý cấu hình 103

Hình 4-7: Mô hình quy trình tích hợp sản phẩm 114

Hình 4-8: Mô hình quy tình thẩm định (Verification) 117

Hình 4-9: Mô hình quy trình đào tạo của tổ chức 124

Hình 4-10: Mô hình quy trình quản lý rủi ro 132

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

Để 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ảnxuấ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êusau:

 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ủakhá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ảicho ra được sản phẩm theo đúng kế hoạch và kinh phí đã xác địnhtrướ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ànhCNPM, 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ệuquả 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ươngtác với nhau Để cải tiến các quy trình này cần phải có những thay đổi mangtí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ớihầ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ềusai sót nhưng không hẳn tất cả mọi người đều có mong muốn thay đổi để cảitiến quy trình, đơn giản chỉ vì họ không muốn thay đổi những thói quen haycá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ếtlậ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àonhữ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ụctiê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)

 Á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ảnxuấ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áchoạ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.

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 conngườ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áclĩ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ấuthô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, giată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ệmquy trình phần mềm Một vòng đời phần mềm định nghĩa các giai đoạn khácnhau 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ácgiai đ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ácquy tắc và chỉ dẫn để thực hiện các pha khác nhau Ví dụ trong mô hình thácnước, một pha chỉ được thực hiện khi pha trước nó đã được hoàn thành Ngượclạ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ụchoạ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ầnmề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ênquan 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ôngnghệ, 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ộtsả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áiniệ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ềmphứ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ápluậ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ộtnhó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ácpha 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áchlà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àoquy 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 đềudựa trên use case Use case là mô hình thể hiện các yêu cầu chức năng vàngữ cảnh của hệ thống Nó được thiết kế cho một hệ thống nhất định vàđược sử dụng trong suốt quá trình phát triển hệ thống

 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ồmnhiề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 ápdụng cho một thế hệ sản phẩm mới RUP chia một chu trình phát triển thànhbố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úcbởi một mốc (milestone) xác định thời điểm phải tạo ra các quyết định quantrọ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ốngnghiệp vụ (business case) của dự án phải được thiết lập và phạm vi của dự áncũng phải được vạch rõ Để hoàn thành điều đó bạn phải xác định tất cả cácthự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ươngtá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áttriể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ếtquả của pha chuẩn bị bao gồm:

Hoàn thành 80% mô hình Use-case

Tài liệu yêu cầu bổ sung (supplementary requirement) bao gồm các yêu 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

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ầnphả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ựngphả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êucầ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:

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ợ choquy 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ầunà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ựchiệ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)

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 đảmbả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áttriển phần mềm – bao gồm các quy trình và công cụ cần để thiết hỗ trợ chonhó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 CMMIvới các work flow trong RUP

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

t 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

Quản lý các thỏa thuận với nhà thầu

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

Phát triển yêu cầu

Requirement, Configurationand Change Management,Analysis and Design,Implementation, Test

Giải pháp kỹ thuật Implementation, Deployment,Analysis and Design,

Project Management

Tích hợp sản phẩm

Implementation, Test,Deployment, Configuration andChange Management, Analysis

and DesignThẩm định Test, Implementation,Environment

Phê duyệt Project Management,Deployment

Quản lý cấu hình Configuration and ChangeManagement

Đảm bảo chất lượng quy trình và

Đ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

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ựctiế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ủangười sử dụng (cũng như sự thay đổi về yêu cầu) trong suốt quá trìnhthự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ìnhphá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ảnphẩm cho khách hàng để kiểm tra, theo đó khách hàng có thể ‘làm mịn’ và hoànthiệ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áchhà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 đơngiản nhất, cho phép có được đặc tính ‘mở’ cao nhằm đáp ứng với các thay đổiliên tục và luôn duy trì được một tốc độ phát triển nhanh trong suốt quá trìnhphá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 trongCNPM, 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ìnhphá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ểnphần mềm Vai trò của khách hàng và nhóm phát triển được định ra một cách rõràng

Trách nhiệm của khách hàng:

 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

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ừ đơngiản đến phức tạp Từng phần sẽ được chuyển giao cho khách hàng để có đượcngay sự phản hồi của khách hàng Từ đó sẽ có thể điều chỉnh ngay được sảnphẩ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áttriể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 thamkhả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 Haingườ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êntìm kiếm một giải pháp cho một hệ thống tương lai Theo đó, chỉ cần một thiết

kế làm sao cho chương trình chạy được vào thỏa mãn yêu cầu của khách hàng

Tổ chức lại chương trình ( Refactoring )

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ứcnă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ỗiphầ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ươngtrình mới được phát triển, đã vượt qua phần kiểm thử, thì sẽ được tích hợp ngayvà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ómphá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ầnsử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ấtnhiề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à đốivớ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ốngnhấ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áchviế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ả đềuhiể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ữacá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ôngnên làm việc quá giờ, chỉ làm đúng giờ quy định để đảm bảo chất lượng sảnphẩ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ệcphá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ómnhỏ 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ườnghợ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ínhtậ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áttriể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ự ánphầ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áchhà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àngcũ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ểmbà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ớicác quy cách làm việc (practices) trong XP

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

Định nghĩa quy trình tổ chức Coding Standard, PairPrograming

Đào tạo trong tổ chức Coding Standards, PairPrograming

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

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

Quản lý dự án tích hợp Onsite Customer

Quản lý định lượng dự án Ngoài phạm vi của XP

Quản lý yêu cầu Planning Game, Small Release

Phát triển yêu cầu Metaphor, Refactoring, OnsiteCustomer

Giải pháp kỹ thuật Metaphor, Simple Design,Refactoring

Đ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

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ẩnquan 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ácquy 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ốthơ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 theoquy trình sẽ tạo ra cơ sở hạ tầng cần thiết để giải quyết những thay đổi đồngthời tăng tính cạnh tranh của đội ngũ nhân viên và công nghệ một cách tối đa.Ngày nay, rất nhiều tổ chức hoạt động trong lĩnh vực sản xuất và dịch vụ đãnhận thấy tầm quan trọng của các quy trình hiệu quả Quy trình giúp mọi ngườiđáp ứng được mục đích hoạt động của tổ chức bằng cách giúp họ làm việc hiệu

quả hơn (chứ không phải là làm việc chăm chỉ hơn) và tăng cường tính nhấtquán Các quy tình hiệu quả cũng đưa ra cách thức để giới thiệu và sử dụngcô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ựccả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 WattsHumphrey, 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ạiIBM 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ĩnhvự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ấtlượ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ácquy 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ácquy 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ưởngnă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ầnmềm, software acquisition, quản lý và phát triển nguồn nhân lực, phát triển quytrì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ấtnhiề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ănnhấ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ếnquy 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, baogồ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 đốivới việc cải tiến quy trình Hơn thế nữa, việc áp dụng nhiều mô hình trong một

tổ chức cũng khiến cho các hoạt động đào tạo, đánh giá và cải tiến quy trình trởnên tốn kém hơn Như vậy, cần có một bộ các mô hình đồng thời áp dụng được

cho nhiều lĩnh vực Bộ các mô hình đó đã được SEI cho ra đời với tên CMMI(CMM Integration).

Dự án CMM IntegrationSM được tiến hành nhằm giải quyết các vấn đề khi sửdụng nhiều mô hình CMM Nhiệm vụ của nhóm dự án là phải kết hợp 3 môhình:

1 The Capability Maturity Model for Software (SW-CMM) v2.0 draft C

2 The Systems Engineering Capability Model (SECM)

3 The Integrated Product Development Capability Maturity Model CMM) v 0.98

(IPD-Ba mô hình trên được chọn vì đó là các mô hình được sử dụng rộng rãitrong lĩnh vực phần mềm, kỹ nghệ hệ thống và mỗi mô hình có cách tiếp cậnkhác nhau đối với việc cải tiến quy trình trong một tổ chức

Tuy nhiên, CMMI không phải chỉ là kết quả của sự cộng gộp đơn giản từcác mô hình gốc nêu trên Nó đã được phát triển để là một khuôn dạng chuẩn -framework cho rất nhiều lĩnh vực khác nhau, và nó có thể được áp dụng rất linhhoạt với 2 hình thức: phân đoạn (staged representation) và liên tục (continuousrepresentation) CMMI có thể được áp dụng cho những tổ chức đã sử dụng các

mô hình CMM, cũng có thể được áp dụng cho các tổ chức chưa từng biết đếnCMM

Trong quá trình phát triển CMMI, người ta cũng đã tính đến việc sẽ tích hợpthêm các mô hình CMMI mới cho các lĩnh vực khác trong tương lai Người tacũng đã đặt mục tiêu đảm bảo rằng những sản phẩm được phát triển theo các

mô hình CMMI sẽ thống nhất và tương thích với tiêu chuẩn ISO/IEC 15504 chođánh giá qui trình phần mềm

Tất cả những điều đó, cộng với việc SEI nhận được vô vàn ý kiến góp ý từnhiều nơi trên thế giới qua từng phiên bản CMMI, đã làm cho CMMI trở thànhmột mô hình thiết lập và cải tiến qui trình tiên tiến, xứng đáng là xu thế lựachọn gần như tất yếu trong CNPM, và đã được SEI quyết định hoàn toàn thaythế cho CMM từ sau năm 2005

Như vậy là, việc thiết lập một quy trình quản trị chất lượng đang trở thànhmột yêu cầu không thể thiếu được cho sự tồn tại và phát triển của các đơn vị và

tổ chức hoạt động trong lĩnh vực dịch vụ CNTT (cung cấp giải pháp tin học, tưvấn, phát triển, thu nhận phần mềm, v.v.) Trong xu thế toàn cầu hoá, các tổchức đạt được các tiêu chuẩn chất lượng như ISO9001 hay CMM đã và đang cónhiều lợi thế trong việc thu hút khách hàng và thâm nhập thị trường Cùng với

sự ra đời của CMMI và với sự hỗ trợ tuyệt đối của tổ chức sinh ra nó là SEI,các tổ chức đó đã, đang và sẽ chuyển dần sang việc áp dụng CMMI Còn những

tổ chức chưa đạt được các tiêu chuẩn chất lượng như ISO9001, CMM có xu thếbắt đầu từ nghiên cứu và áp dụng CMMI

Thiết nghĩ, nền CNPM nước ta hiện nay đang hướng mục tiêu vào xuất khẩuphần mềm và xây dựng những hệ thống thông tin lớn có độ phức tạp cao, dovậy các tổ chức sản xuất phần mềm đang có nhu cầu bức thiết về việc tuân theo

một qui trình sản xuất có chất lượng, thì cũng nên xem xét và đầu tư vào việcphổ biến và cài đặt các mô hình CMMI.

3.1.2 Cấu trúc CMMI

3.1.2.1 Biểu diễn CMMI

3.1.2.1.1. Mô hình phân tầng (Staged model)

Mô hình phân tầng (Staged model) đưa ra một lộ trình xác định cho việc cảitiến tổ chức dựa trên việc nhóm và sắp xếp các quy trình và các mối quan hệliên kết về mặt tổ chức giữa các quy trình đó Mô hình được mô tả trong lộ trìnhnày là một chuỗi các bước (stages) hay còn gọi là các mức độ tăng trưởng(matuirity level) Mỗi mức tăng trưởng bao gồm một tập các lĩnh vực quy trìnhchỉ ra các lĩnh vực mà tổ chức cần phải tập trung vào đó để cải tiến quy trìnhcủa tổ chức Mỗi lĩnh vực quy trình lại bao gồm các practices (quy cách làmviệc) mô tả cơ sở hạ tầng và các hoạt động nhằm góp phần đạt được mục đíchcủa lĩnh vực quy trình đó Khi đã đạt được mục tiêu của tất cả các lĩnh vực quytrình trong một mức tăng trưởng thì quy trình của tổ chức cũng có sự tiến bộ rõrệt

CMM cho lĩnh vực phần mềm là một ví dụ cơ bản đối với mô hình phântầng Hình 3-2 là CMM cho lĩnh vực phần mềm với năm bước và bảng 3-1 làcác KPAs trong mỗi bước

Hình 3-3: Các bước của mô hình CMM cho phần mềm

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

mềm Mức 5 nhằm giải quyết các vấn đề của cả tổ chức và các dự án, đó là thựchiện cái tiến quy trình phần mềm liên tục và có thể đo được (measurable)

Bảng 3-3: Các PA trong CMM - sw

Level 5: Tối ưu Cải tiến quy trình

lien tục

Organization Improvement DeploymentOrganization Process & Technology Innovation

Defect Prevention

Level 4: Quản lý

Statistical Process ManagementOrganization Process PerformanceOrganization Software Asset Commonality

Level 3: Xác định

Peer ReviewsProject Interface CoordinationSoftware Product EngineeringIntegrated Software ManagementOrganization Training ProgramOrganization Process DefinitionOrganization Process Focus

Level 2: Mức lặp Quản lý dự án cơ bản Software Configuration Management

Software Quality AssuranceSoftware Acquisition ManagementSoftware Project Control

Software Project PlanningRequirements Management

3.1.2.1.2. Mô hình liên tục (Contiunous model)

Các mô hình liên tục không đưa ra nhiều các chỉ dẫn về thứ tự mà việc cảitiến quy trình cần phải tuân theo Chúng được gọi là liên tục vì trong mô hìnhkhông có các bước gắn với sự trưởng thành về mặt tổ chức EIA 731 là một ví

dụ về mô hình liên tục

Cũng giống như staged model, các mô hình liên tục cũng bao gồm các lĩnhvực quy trình, mỗi lĩnh vực quy trình lại bao gồm nhiều practices Tuy nhiên,không giống như trong staged models, các practice trong một PA của mô hìnhliên tục được sắp xếp sao cho thuận lợi nhất đối với việc cải tiến và phát triểntừng PA riêng biệt Hầu hết các practices liên quan tới cải tiến quy trình đều cóđặc điểm chung giống nhau, chúng đều ở bên ngoài mỗi lĩnh vực quy trìnhriêng lẻ và được áp dụng với tất cả các PA Các practice này được nhóm vàocác Capability level (CLs), mỗi mức cũng có định nghĩa tương đương với địnhnghĩa mức tăng trưởng trong mô hình phân tầng Các lĩnh vực quy trình sẽ đượccải tiến nếu thực hiện các practice trong các lĩnh vực quy trình đó

Trong một mô hình liên tục như EIA 731, các mục tiêu không được chỉ ramột cách cụ thể Các mức năng lực (Capabality level) của tất cả các lĩnh vựcquy trình sẽ quyết định sự cải tiến của tổ chức, và một tổ chức có thể biển đổi

mô hình liên tục và chỉ thực hiện một số PA nhất định để cải tiến quy trình Nóicách khác, họ đã tạo ra thứ tự của các PA cho chính tổ chức của mình

Hình 3-4: Sơ lược các mức năng lực

3.1.2.2 Cấu trúc

CMMI được cấu trúc như sau:

 Các mức tăng trưởng - Maturity Levels (staged representation) hoặc cácmức năng lực - Capability Levels (continuous representation)

 Các lĩnh vực quy trình (Process Areas)

 Goals: Generic and Specific

 Common Features

 Practices: Generic and Specific

Hình 3-4 là mô hình cấu trúc đối với cách biểu diễn phân tầng của CMMItrong đó các lĩnh vực quy trình được sắp xếp vào các mức tăng trưởng Trongmỗi lĩnh vực quy trình đều có mục tiêu chung (Generic Goal) và mục tiêu riêng(Specific Goal) cũng như các practice chung (Generic Practice) và các practiceriêng (Specific Goal) Các đặc điểm chung (Common features) được xếp vàotrong các Generic practice

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

Hình 3-5 thể hiển mô hình kiến trúc đối với CMMI biểu diễn theo cách liêntục Các Specific practice được xếp vào trong các SG còn các GP được xếp vàocác GG Mỗi practice tương ứng với một mức năng lực Các SG và SP được ápdụng vào các lĩnh vực quy trình cụ thể

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

3.1.2.2.1. Mô hình cấu trúc đối với cách biểu diễn phân tầng

Các mức tăng trưởng (Maturity Levels)

Mỗi mức tăng trưởng thể hiện mức độ thực hiện quy trình của một tổ chức

Ví dụ, ở Maturity Level 1 tổ chức chỉ có các quy trình lộn xộn không theo quytắc thì đến Maturity Level 2 tổ chức đã có hệ thống quản lý dự án cơ bản Có tất

cả 5 mức tăng trưởng

Các lĩnh vực quy trình - Process Areas (PAs)

Mỗi mức tăng trưởng bao gồm một số lĩnh vực quy trình Một lĩnh vực quytrình bao gồm nhiều practice hoặc nhiều hoạt động cần được thực hiện cùngnhau để đạt được mục đich của lĩnh vực quy trình đó Ví dụ như PA quản lí yêucầu ở Maturity Level 2, Requirements Development ở Maturity Level 3, ProjectManagement ở Maturity Level 4

Mối liên hệ giữa Goals và Practices

Mỗi PA đều có một vài goal cần phải đạt được Mỗi goal lại có các practices

đi kèm với nó Practices là các tác vụ đặc biệt cần phải thực hiện để đạt đượcgoal của PA Goal gồm có Generic goal và Specific goal cũng như có genericpractice và specific practice

Practices là các hoạt động cần thực hiện để đạt được goal của PA Mỗipractice chỉ liên quan tới duy nhất một goal Có hai loại practice:

1 Specific practices (SP): Liên quan tới các specific goal (SP)

2 Generic practices (GP): Gắn với các generic goals (GG)

Ví dụ, một trong số các practice của Project Planning PA là viết kế hoạch dự

án Một practice khác là ước tính số lượng người tham gia dự án và tạo lịchbiểu

Các đặc điểm chung - Common Features

Common Features chỉ đơn giản là nhóm các generic practice trong một PAlại với nhau, tùy theo chức năng của practice Có 4 Common Feature:

1 Cam kết thực hiện - Commitment to Perform (CO)

2 Khả năng thực hiện - Ability to Perform (AB)

3 Thực hiện trực tiếp - Directing Implementation (DI)

4 Thực hiện thẩm định - Verifying Implementation (VE)

3.1.2.2.2. Mô hình cấu trúc với cách biểu diễn liên tục

CMMI biểu diễn liên tục cũng sử dụng cùng một cấu trúc với mô hình phântầng những có thêm một số các gợi ý Cần nhắc lại là các specific practices thìliên quan tới các specific goal còn các generic practice lai liên quan tới genericgoal, nhưng các practice này đều thuộc nhóm practice cơ sở hoặc nhóm practicenâng cao

Các practice cơ sở là các practice ở mức năng lực 1 Các practice này liênquan tới việc xác định phạm vi công việc và thực hiện quy trình một cách tùytiện không theo một kế hoạch hay một quy trình nào Mức độ thực hiện cácpractice có thể khác nhau đối với mỗi người Một mức năng lực không phải làmột mức tăng trưởng Mức năng lực 1 chỉ đơn giản nghĩa là các pratice cơ sở đãđược thực hiện trong tổ chức của bạn Các practice nâng cao là các practice thểhiện mức độ tinh vi và kỷ luật hơn trong một lĩnh vực quy trình Pracice nângcao có thể được xây dựng dựa trên các practice cơ bản hoặc không

Goals và Practices

Các SG và practice liên quan tới các lĩnh vực quy trình và tác vụ nhất định

Ví dụ, Project Planning cần phải có một bản kế hoach dự án còn QuantitativePrọect Management lại cần có ranh giới thực thi dự án Như vậy các SG vàpractice có thể liên quan tới nhiều lĩnh vực quy trình Nếu lĩnh vực quy trìnhRequirements Management muốn đạt tới mức năng lực 2 thì phải thiết lập đượcchính sách của tổ chức, lập kế hoạch quy trình, và đào tạo nhân viên Nếu muốnđạt tới mức năng lực 3, RM phải thực hiện tất cả các hoạt động như ở mức 2đồng thời phải xác định quy trình và thu thập các thông tin cải tiến liên quan tớiquy trình Vì vậy các SG và practices có thể áp dụng ở tất cả các lĩnh vực quy

trình Cả SG, SP và GG, GP đều phải thực hiện để có thể đạt được mức nănglực (Capability Level)

Generic Goals và Practices

Mỗi mức năng lực chỉ có một GG gắn với nó Mỗi GP chỉ duy nhất liênquan tới một GG

Target Profile

Target profile là một danh sách các PA cùng với các mức năng lực tươngứng của chúng thể hiện mục tiêu của việc thực hiện quy trình.Ví dụ, khi so sánhcác mức tăng trưởng với các mức năng lực, mức năng lực 3 có thể được coi làtương đương với mức tăng trưởng 3 nếu tất cả các goal của tất cả các PA ở mứctăng trưởng 2 và 3 trong mô hình phân tầng đều được thực hiện Vì vậy, targetprofile 3 sẽ bao gồm bảy PA ở mức tăng trưởng 2 và 14 PA ở mức tăng trưởng

3 Một tổ chức có thể tự quyết định target profile của mình Ví dụ, một công tychuyên cung cấp các dịch vụ kiểm điểm và kiểm duyệt độc lập có thể chọn chomình một target profile bao gồm các PA Project Planning, Project Monitoringand Control ở mức năng lực 2 còn PA Verification và Validation ở mức nănglực 3

Target Staging

Target staging là một dãy tuần tự các target profile mô tả quá trình cải tiếnquy trình mà tổ chức cần phải thực hiện Đó chính là nơi mà tổ chức ghi lại(document) các PA mà nó tập trung vào để cải tiến quy trình, điều chỉnh lạicách tiếp cận và giám sát các PA theo mục đích hoạt động của tổ chức

3.1.3 Ưu điểm của CMMI

CMMI bao trùm toàn bộ vòng đời sản phẩm hơn bất kì mô hình cải tiến quytrình riêng lẻ nào Ví dụ, chỉ riêng các lĩnh vực quy trình thuộc về kỹ nghệ(Engieering) trong CMMI vượt quá những gì có trong Software CMM còn cáclĩnh vực quy trình thuộc nhóm quản lý quy trình cũng có nhiều hơn nhưng gìtrong SECM

CMMI kết hợp rất nhiều bài học rút ra trong suốt quá trình phát triển, bảotrì, và sử dụng 3 mô hình tạo nên CMMI Vì vậy CMMI đã giải quyết được một

số vấn đề còn tồn tại ở cả CMM lẫn SECM

Các tổ chức đạt được CMM mức 4 hoặc mức 5 đã cung cấp cho SEI cácthông tin về thành công cũng như những khó khăn mà họ gặp phải Nhữngthông tin này được sử dụng để tạo ra các best practices trong CMMI Vì vậy,CMMI xác định được các nhu cầu của tổ chức ở mức tăng trưởng cao hơn.CMMI giúp hạn chế các rào cản vẫn thường tồn tại trong các phần khácnhau của tổ chức mà các mô hình cải tiến quy trình khác không giải quyết được.Việc kết hợp các thông tin hữu ích trong sản xuất sản phẩm và các practice đã

được chứng minh đã tạo ra một tập các mô hình tích hợp thuận tiện cho việcquản lý dự án và cái tiến quy trình phát triển.

CMMI là một công cụ quý giá đối với rất nhiều tổ chức CMMI đẩy mạnh

sự kết hợp giữa kỹ nghệ hệ thống và kỹ nghệ phần mềm, do đó thúc đẩy việctập trung vào sản phẩm cuối và các quy trình liên quan tới nó Hơn nữa, việcđào tạo và đánh giá CMMI được thực hiện đơn giản và hiệu quả hơn

CMMI cho phép người sử dụng chọn cách biểu diễn mô hình phù hợp vớimục đích hoạt động của mình nhất Các thành phần linh hoạt trong CMMI hỗtrợ cả cách tiếp cận phân tầng và liên tục trong việc cải tiến quy trình với chungthuật ngữ, kiến trúc và phương pháp đánh giá

CMMI được thiết kế cho nhiều lĩnh vực, vì vậy nó hỗ trợ việc cải tiến quytrình trong toàn tổ chức

3.2 Các lĩnh vực quy trình (PAs) trong CMMI

3.2.1 Các PAs về quản lý quy trình (Process Management

Process Areas)

Process Management gồm có 5 lĩnh vực quy trình với các practices liênquan tới việc xác định, lập kế hoạch, triển khai, cài đặt, giám sát, quản lý, kiểmtra, đo và cải tiến quy trình Các lĩnh vực quy trình đó là:

 Định nghĩa quy trình tổ chức - Organizational Process Definition(OPD)

 Tập trung vào quy trình tổ chức - Organizational Process Focus (OPF)

 Thực hiện quy trình tổ chức-Organizational Process Performance(OPP)

 Triển khai và đổi mới tổ chức-Organizational Innovation andDeployment (OID)

 Đào tạo trong tổ chức - Organizational Training (OT)

Hình 3-7: Các PA trong nhóm Process Management

3.2.1.1 Định nghĩa quy trình tổ chức-Organizational Process Definition

Lĩnh vực quy trình ODP nhằm thiết lập và duy trì một tập các tài sản(assets) của quy trình tổ chức ODP và OPF hoạt động cùng với nhau trong đóODP đưa ra các chỉ dẫn cho tổ chức trong việc tạo các quy trình và các phần hỗtrợ cho các quy trình đó còn OPF lại đưa ra các chỉ dẫn để xác định và lập kếhoạch cải tiến quy trình

Dữ liệu trong kho chứa sẽ được sử dụng để làm cơ sở cho việc ước lượng dự

án Các dữ liệu này bao gồm các mẫu tài liệu, các ví dụ, work products, chínhsách

3.2.1.2 Tập trung vào quy trình tổ chức -Organizational Process Focus

Mục đích của OPF là lập kế hoạch và thực hiện cải tiến quy trình dựa trênnhững hiểu biết về điểm mạnh và yếu của các quy trình trong tổ chức OPF sửdụng hai SP để đạt được mục đích đó:

SG1: Xác định các khả năng cải tiến

SG2: Lập kế hoạch và thực thi những cải tiến đó

Hình 3-8 chỉ ra các SP tương ứng với hai SG trên

Hình 3-9: Tập trung vào quy tình tổ chức

Đối với mục tiêu thứ nhất – Xác định các khả năng để cải tiến quy trình – tổchức cần thiết lập và duy trì các mục tiêu và nhu cầu đối với quy trình Cácthông tin này sẽ được sử dụng để đánh giá quy trình nhằm xác định các cải tiếncần thiết đối với quy trình tổ chức Sau đó tổ chức sẽ lựa chọn một số cải tiếnnhất định để tiến hành thực hiện

Mục tiêu thứ hai – lập kế hoạch và thực thi các hoạt động cải tiến quy trình– được thực hiện bởi bốn SPs Tổ chức sử dụng các cải tiến đã chọn để thiết lập

kế hoạch hành động Sau đó kế hoạch này sẽ được thực thi và đưa lại kết quả làcác tài sản quy trình Các tài sản quy trình này sẽ được triển khai một cách tuần

tự và được đưa vào thư viện tài sản quy trình

Các quy trình và quy trình con đã chọn sẽ được phân tích, có thể là bằngcách kiểm tra cả các tiêu chuẩn (measures) thực thi và tiêu chuẩn đối với sảnphẩm (ví dụ như chất lượng) Sau đó các ranh giới thực thi quy trình và các môhình sẽ được thiết lập Các ranh giới này đo việc thực thi của các quy trìnhchuẩn trong tổ chức ở các mức chi tiết khác nhau Việc may đo (tailoring) vàcác nhân tố khác (ví dụ như dòng sản phẩm, độ phức tạp, lĩnh vực áp dụng hoặc

số lượng của nhóm phát triển) có ảnh hưởng lớn tới các ranh giới này Vì vậy,

tổ chức có thể cần tới một vài ranh giới (baseline) thực thi

3.2.1.3 Triển khai và đổi mới tổ chức-Organizational Innovation and Deployment

Mục đích của OID là chọn ra và thực hiện những cải tiến có tính nâng cao

và đổi mới đối với các quy trình và công nghệ của tổ chức Những cải tiến nàycải thiện chất lượng tổ chức và các mục tiêu của việc thực hiện quy trình OIDđược thực hiện bởi hai SG:

SG1: Chọn ra các cải tiến

SG2: Triển khai các cải tiến đó

Hình 3-10: Phát triển vào cải tiến tổ chức

Mục tiêu thứ nhất của OID – chọn ra các cải tiến – liên quan tới việc thuthập và phân tích các đề xuất cho cải tiến quy trình và kỹ thuật Các sáng kiếncũng được thu thập, phân tích và đánh giá thông qua các dự án thử nghiệm Sau

đó, một số đề xuất và sáng kiến sẽ được chọn để triển khai Các cải tiến có thểmang tính nâng cao hoặc đổi mới.

Mục tiêu thứ hai – thực hiện các cải tiến – bao gồm lập kế hoạch, triển khai

và đánh giá hiệu quả của quy trình và công nghệ mới cũng như đánh giá hiệuquả của chúng đối với các mục tiêu quản lý khác

3.2.1.4 Đào tạo trong tổ chức - Organizational Training

Mục tiêu của OT là phát triển kĩ năng và kiến thức của mọi người trong tổchức để họ có thể thực hiện vai trò của mình một cách hiệu quả OT có hai SG:

SG1: Thiết lập năng lực đào tạo tổ chức

SG2: Cung cấp các khóa đào tạo cần thiết

Lĩnh vực quy trình này không dựa trên mức năng lực của bất kỳ PA quản lýquy trình nào mà tập trung vào các nhu cầu đào tạo mang tính chiến lược của tổchức

Hình 3-11: Đào tạo trong tổ chức

Mục tiêu thứ nhất – thiết lập năng lực đào tạo của tổ chức - bao gồm bốn

SG Đầu tiên cần phải thiết lập các nhu cầu đào tạo mang tính chiến lược đểđịnh hướng cho các hoạt động đào tạo trong toàn tổ chức Tiếp theo xác địnhtrách nhiệm của tổ chức và dự án đối với mỗi nhu cầu đào tạo SP thứ ba là tạo