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

HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG

Đồ án được thực hiện tại khoa CÔNG NGHỆ THÔNG TINHọ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ànthà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 KhoaCô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ếnthứ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ấtlượng (P&QA) của công ty Cổ phần Phần mềm Việt (VietSoftware) tạo điềukiệ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ôixin 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ạntrong 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

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 Areas323.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-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-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ả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)

 Á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.

MỖI LIÊN HỆ GIỮA CMMI VÀ QUY TRÌNH2.1 Khái niệm quy trình phần mềm

Phát triển phần mềm là một quy trình phức tạp, nó không chỉ đơn giản là tạo ra các ngôn ngữ lập trình và các công cụ hiệu quả mà còn bao gồm rất nhiều nỗ lực phức tạp Chất lượng của một sản phẩm phần mềm được quyết định bởi con người, tổ chức và các thủ tục để tạo nên và chuyển giao sản phẩm đó

Trong những năm 60 và 70, các nhà nghiên cứu chủ yếu tập trung vào các lĩnh vực:

Phát triển các ngôn ngữ lập trình cấu trúc (ví dụ Algol, Pascal, C)

Phát triển các nguyên tắc và phương pháp thiết kế (ví dụ như che giấu thông tin, phân rã chức năng)

Định nghĩa vòng đời phần mềm (Ví dụ như các mô hình thác nước, gia tăng, dựa trên bản mẫu)

Khái niệm vòng đời phần mềm ở trên có liên quan trực tiếp với khái niệm quy trình phần mềm Một vòng đời phần mềm định nghĩa các giai đoạn khác nhau trong suốt thời gian tồn tại của sản phẩm phần mềm Thông thường các giai đoạn đó bao gồm phân tích và đặc tả yêu cầu, thiết kế, viết code, kiểm tra và phê duyệt, triển khai, bảo trì Ngoài ra, vòng đời phần mềm còn đưa ra các quy tắc và chỉ dẫn để thực hiện các pha khác nhau Ví dụ trong mô hình thác nước, một pha chỉ được thực hiện khi pha trước nó đã được hoàn thành Ngược lại, ở mô hình xoắn ốc, trước tất cả các pha đều có hoạt động phân tích rủi ro Nói chung, một mô hình vòng đời phần mềm thường định nghĩa bộ khung và các chỉ dẫn mà quy trình phần mềm cần được tiến hành theo nó Tuy nhiên, nó không quy định chính xác thứ tự các hoạt động, tổ chức, công cụ, các thủ tục hoạt động, các chính sách phát triển và các ràng buộc Vì vậy vòng đời phần mềm là điểm bắt đầu quan trọng để xác định phần mềm sẽ được phát triển như thế nào Tuy nhiên, áp dụng một vòng đời phần mềm nhất định cũng chưa đủ để thực hiện và quản lý một dự án phần mềm.

Khái niệm quy trình phần mềm được xây dựng dựa trên khái niệm vòng đời Nó đưa ra một quan niệm sâu sắc để cấu trúc và tổ chức các các vấn đề liên quan tới hoạt động phát triển phần mềm Một quy trình phần mềm có thể được định nghĩa như sau:

Quy trình phần mềm là một tập các chính sách, cơ cấu tổ chức, các công nghệ, các thủ tục và các artifacts cần thiết để phát triển, triển khai và bảo trì một sản phẩm phần mềm Vì vậy, một quy trình phần mềm bao gồm rất nhiều khái niệm:

Công nghệ phát triển phần mềm (Software development technoloty): Là các

công nghệ được sử dụng trong quy trình Để thực hiện các hoạt động phát triển

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 developmentmethods 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ựctế và mối liên hệ giữa quy trình đó và CMMI

2.2.1 Mô hình RUP

2.2.1.1 RUP là gì

RUP là một quy trình phát triển lặp được xây dựng dựa trên “sáu quy cách làm việc tốt nhất” bao gồm:

 Phát triển lặp (Develop Iteratively)  Quản lý yêu cầu (Manage Requirement)

 Sử dụng kiến trúc thành phần (Use Component Architecture)  Mô hình trực quan (Model Visually)

 Kiểm điểm chất lượng (Verify Quality)  Kiểm soát các thay đổi (Control Changes) Các đặc điểm chính của RUP là:

 Quy trình dựa trên rủi ro: Trong RUP, quản lý rủi ro được tích hợp vào quy trình phát triển và việc lập kế hoạch các bước lặp dựa được trên các rủi ro có mức ưu tiên cao

 Phát triển dựa trên Usecase: Tất cả các pha và bước lặp trong RUP đều dựa trên use case Use case là mô hình thể hiện các yêu cầu chức năng và ngữ cảnh của hệ thống Nó được thiết kế cho một hệ thống nhất định và được sử dụng trong suốt quá trình phát triển hệ thống.

 Các hoạt động thiết kế dựa trên kiến trúc: Đối với mô hình RUP, tất cả các hoạt động thiết kế đều dựa trên kiến trúc Kiến trúc là artifact cơ bản để khái niệm hóa, xây dựng, quản lý và tạo nên hệ thống Kiến trúc bao gồm nhiều khung nhìn hoặc mô hình kết hợp với nhau.

Vòng đời phần mềm được chia thành nhiều chu trình, mỗi chu trình được áp dụng cho một thế hệ sản phẩm mới RUP chia một chu trình phát triển thành bốn pha liên tiếp:

 Inception (Khởi đầu)  Elaboration (Chuẩn bị)  Construction (Xây dựng)  Transition (Chuyển giao)

Một pha có thể được chia nhỏ thành nhiều bước lặp Mỗi pha được kết thúc bởi một mốc (milestone) xác định thời điểm phải tạo ra các quyết định quan trọng và đạt được các mục tiêu chính

Pha khởi đầu (Inception)

Trong pha này dự án cần phải được xác định, nghĩa là các tình huống nghiệp vụ (business case) của dự án phải được thiết lập và phạm vi của dự án cũng phải được vạch rõ Để hoàn thành điều đó bạn phải xác định tất cả các thực thể bên ngoài tương tác với hệ thống và xác định được bản chất của tương tác đó ở mức cao Điều này liên quan tới việc xác định tất cả các use case và mô tả một số use case tiêu biểu Business case bao gồm: tiêu chuẩn thành công, đánh giá rủi ro, ước lượng các tài nguyên cần thiết và pha lập kế hoạch để xác định thời điểm của các mốc chính Các kết quả của pha khởi đầu bao gồm:

Tài liệu tổng quan (Vision document )

Mô hình use case ban đầu (hoàn thành khoảng 10%-20% ) Tài liệu chú giải ban đầu của dự án (Initial project glossary ) Tình huống nghiệp vụ ban đầu (Initial business case)

Đánh giá rủi ro ban đầu (Initial risk assessment) Kế hoạch dự án (Project plan)

Mô hình hoạt động (Business model) Một hoặc một vài bản mẫu

Pha chuẩn bị (Elaboration)

Mục đích của pha này là phân tích vấn đề, thiết lập cơ sở kiến trúc, phát triển kế hoạch dự án và loại bỏ các thành phần có độ rủi ro cao trong dự án Kết quả của pha chuẩn bị bao gồm:

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

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

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)

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

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 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

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, Configuration and Change Management,

Analysis and Design, Deployment, Configuration and

Change Management, Analysis and Design

Thẩ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

2.2.2 Mô hình XP

2.2.2.1 XP là gì?

XP (eXtreme Programming) là một quy trình phát triển phần mềm được chứng nhận bởi rất nhiều công ty thuộc nhiều lĩnh vực và có quy mô khác nhau ở trên toàn thế giới XP thành công bởi nó đáp ứng được đúng nhu cầu khách hàng: chuyển giao đúng sản phẩm mà khách hàng cần vào đúng lúc mà họ cần nó.

a Các nguyên tắc Cơ Bản của XP

XP được thiếp lập dựa trên bốn nguyên tắc sau:

Trao đổi (Communication): XP chú trọng việc trao đổi thông tin một cách

‘trong suốt’ giữa các thành viên trong nhóm phát triển Đề cao việc trao đổi trực tiếp, giảm việc trao đổi gián tiếp hay hình thức thông qua các văn bản

 Với XP, khách hàng tham gia trực tiếp vào việc thực hiện dự án với tư cách là một thành viên chính thức của nhóm phát triển Khách hàng sẽ giúp nhóm phát triển hiểu và nắm bắt được và kịp thời các yêu cầu của người sử dụng (cũng như sự thay đổi về yêu cầu) trong suốt quá trình thực hiện dự án

 Tất cả các thành viên đều tham gia vào mọi hoạt động trong quá trình phát triển phần mềm Điều này sẽ nâng cao tính năng động của toàn bộ nhóm phát triển

Phản hồi (Feedback): phản hồi sớm và liên tục từ khách hàng cũng như từ

nhóm phát triển giúp cho dự án luôn đi theo đúng hướng XP đều đặn giao sản phẩm cho khách hàng để kiểm tra, theo đó khách hàng có thể ‘làm mịn’ và hoàn thiện yêu cầu sản phẩm dựa trên các kết quả cụ thể Với sự trợ giúp của khách hàng, XP xây dựng một tập các phép thử phục vụ cho việc kiểm định

(acceptation test) một cách liên tục trong suốt quá trình phát triển phần mềm.

Đơn giản (Simplicity): XP đảm bảo chỉ phát triển những chức năng mà

khách hàng yêu cầu Phần thiết kế và mã nguồn được thiết lập một cách đơn giản nhất, cho phép có được đặc tính ‘mở’ cao nhằm đáp ứng với các thay đổi liên tục và luôn duy trì được một tốc độ phát triển nhanh trong suốt quá trình phát triển phần mềm.

Dũng cảm (Courage): XP cho rằng phải có lòng dũng cảm thì mỗi thành

viên mới thực hiện được các nguyên tắc kể trên Tuy XP không chỉ ra một cách rõ ràng, nhưng cũng cần phải nhấn mạnh rằng tính kỷ luật là yêu cầu quan trọng để thực hiện có hiệu quả phương pháp phát triển phần mềm XP.

b 12 quy cách làm việc (practices) của XP

Phương pháp XP đã đề ra 12 quy cách (practices) làm việc để thực hiện các

nguyên tắc phát triển phần mềm đã nêu ở trên Theo các chuyên gia trong CNPM, các quy cách làm việc đề ra bởi XP không có gì là mới Thực chất, những quy cách này là những kinh nghiệm hay nhất thu được trong quá trình phát triển CNPM, đặc biệt là CNPM với công nghệ hướng đối tượng

Lập kế hoạch ( Planning process )

Với XP, khách hàng tham gia trực tiếp vào quá trình lập kế hoạch phát triển phần mềm Vai trò của khách hàng và nhóm phát triển được định ra một cách rõ ràng

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

 Mô tả tính năng phần mềm cần phát triển thông qua các ‘câu chuyện’

(user story) User story có ý nghĩa tương tự như use case trong UML

nhưng mức độ mô tả thì không chi tiết bằng

 Phân loại các user story theo mức độ quan trọng từ quan điểm người sửdụng (dựa trên giá trị kinh doanh-business value) Từ đó sẽ định ra tính

năng nào cần phải phát triển và phát triển theo thứ tự như thế nào  Định ra thời điểm và chu kỳ bàn giao sản phẩm.

Trách nhiệm của nhóm phát triển:

 Ước lượng yêu cầu kỹ thuật (để phát triển) cho từng user story (ước

lượng độ phức tạp).

 Ước lượng thời gian, nhân công cũng như giá thành để phát triển từng

user story.

Với sự phân công trách nhiệm như vậy, bản kế hoạch sẽ luôn thoả mãn được yêu cầu của khách hàng cũng như nhóm phát triển.

Bàn giao từng phần ( Small releases )

Theo quy cách này, nhóm phát triển sẽ phát triển dần dần phần mềm, từ đơn giản đến phức tạp Từng phần sẽ được chuyển giao cho khách hàng để có được ngay sự phản hồi của khách hàng Từ đó sẽ có thể điều chỉnh ngay được sản phẩm cho phù hợp với yêu cầu của khách hàng Khách hàng cũng có điều kiện để bổ sung hay thay đổi yêu cầu phần mềm

Tham gia trực tiếp của khách hàng ( On-site customer )

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

Lập trình đôi (Pair programming)

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

Thiết kế đơn giản ( Simple design )

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

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

Quan điểm của XP là chất lượng phần mềm được thể hiện bằng chất lượng

của mã nguồn (code) Một chương trình được viết rõ ràng, đơn giản thì sẽ dễ

bảo dưỡng và thay đổi XP khuyến khích tổ chức (viết) lại chương trình một

cách đều đặn để nâng cao tính sáng sủa của chương trình, dễ bổ sung các chức năng mới, nâng cao hiệu suất của chương trình.

Kiểm thử ( Testing )

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

Tích hợp liên tục ( Continuous integration )

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

Sở hữu tập thể ( Collective ownership )

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

Chuẩn lập trình ( Coding standards )

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

Metaphor ( Metaphor )

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

Không làm việc quá giờ ( 40-hour week )

Hiện tượng làm việc quá giờ rất phổ biến trong giới phát triển phần mềm Thực tế cho thấy khi người lao động làm việc quá giờ thường hay mệt mỏi, dẫn đến làm việc không hiệu quả, chất lượng sản phẩm giảm XP khuyến cáo không nên làm việc quá giờ, chỉ làm đúng giờ quy định để đảm bảo chất lượng sản phẩm.

c Điều kiện để áp dụng XP

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

Đị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

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

Đ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ẩ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.

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 SoftwareProcess.

Cuốn sách này của SEI đã đưa những nguyên lý được biết tới cách đây cả thập kỷ để áp dụng vào chu trình bất tận của việc cải tiến quy trình Giá trị của mô hình này đã được xác nhận bởi rất nhiều tổ chức Họ đã áp dụng CMM và đã tăng năng suất và chất lượng, cải tiến chu trình, kế hoạch và ngân sách được ước tính chính xác hơn

3.1.1.2 Sự xuất hiện của CMMI

Từ năm 1991, CMMs đã được áp dụng ở rất nhiều lĩnh vực (disciplines) Đáng chú ý nhất là các mô hình áp dụng cho kỹ nghệ hệ thống, kỹ nghệ phần mềm, software acquisition, quản lý và phát triển nguồn nhân lực, phát triển quy trình và sản phẩm tích hợp.

Mặc dù các mô hình này đã được chứng minh là rất hữu ích đối với rất nhiều tổ chức nhưng việc sử dụng nhiều mô hình cũng tạo ra những khó khăn nhất định Đó là khi nhiều tổ chức muốn đồng thời tập trung các nỗ lực cải tiến quy trình chất lượng trên nhiều lĩnh vực khác nhau trong tổ chức của mình Khi đó sự khác biệt giữa các lĩnh vực (discipline) – các mô hình chuyên biệt, bao gồm kiến trúc, nội dung và cách tiếp cận đã hạn chế khả năng của tổ chức đối với việc cải tiến quy trình Hơn thế nữa, việc áp dụng nhiều mô hình trong một tổ chức cũng khiến cho các hoạt động đào tạo, đánh giá và cải tiến quy trình trở nên tốn kém hơn Như vậy, cần có một bộ các mô hình đồng thời áp dụng được

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 (IPD-CMM) v 0.98

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

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

Trong quá trình phát triển CMMI, người ta cũng đã tính đến việc sẽ tích hợp thêm các mô hình CMMI mới cho các lĩnh vực khác trong tương lai Người ta cũng đã đặt mục tiêu đảm bảo rằng những sản phẩm được phát triển theo các mô hình CMMI sẽ thống nhất và tương thích với tiêu chuẩn ISO/IEC 15504 cho đánh giá qui trình phần mềm.

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

Như vậy là, việc thiết lập một quy trình quản trị chất lượng đang trở thành một yêu cầu không thể thiếu được cho sự tồn tại và phát triển của các đơn vị và tổ chức hoạt động trong lĩnh vực dịch vụ CNTT (cung cấp giải pháp tin học, tư vấn, phát triển, thu nhận phần mềm, v.v.) Trong xu thế toàn cầu hoá, các tổ chức đạt được các tiêu chuẩn chất lượng như ISO9001 hay CMM đã và đang có nhiều lợi thế trong việc thu hút khách hàng và thâm nhập thị trường Cùng với sự ra đời của CMMI và với sự hỗ trợ tuyệt đối của tổ chức sinh ra nó là SEI, các tổ chức đó đã, đang và sẽ chuyển dần sang việc áp dụng CMMI Còn những tổ chức chưa đạt được các tiêu chuẩn chất lượng như ISO9001, CMM có xu thế bắt đầu từ nghiên cứu và áp dụng CMMI.

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

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

3.1.2 Cấu trúc CMMI

3.1.2.1 Biểu diễn CMMI

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

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

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

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

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ực hiệ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 Deployment Organization Process & Technology Innovation

Defect Prevention

Level 4: Quản lý

Statistical Process Management Organization Process Performance Organization Software Asset Commonality

Level 3: Xác định

Peer Reviews

Project Interface Coordination Software Product Engineering Integrated Software Management Organization Training Program Organization Process Definition Organization Process Focus

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

Software Acquisition Management Software Project Control

Software Project Planning Requirements 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ải tiế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ình khô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ĩnh vự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ình liê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ển từ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ình riêng lẻ và được áp dụng với tất cả các PA Các practice này được nhóm vào các Capability level (CLs), mỗi mức cũng có định nghĩa tương đương với định nghĩ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ẽ được cả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ỉ ra mộ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ực quy 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ói cá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ác mứ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 CMMI trong đó các lĩnh vực quy trình được sắp xếp vào các mức tăng trưởng Trong mỗ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 practice riêng (Specific Goal) Các đặc điểm chung (Common features) được xếp vào trong 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ântầ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ên tục Các Specific practice được xếp vào trong các SG còn các GP được xếp vào các GG Mỗi practice tương ứng với một mức năng lực Các SG và SP được áp dụ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êntụ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 quy tắ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 quy trình bao gồm nhiều practice hoặc nhiều hoạt động cần được thực hiện cùng nhau để đạt được mục đich của lĩnh vực quy trình đó Ví dụ như PA quản lí yêu cầu ở Maturity Level 2, Requirements Development ở Maturity Level 3, Project Management ở 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 được goal của PA Goal gồm có Generic goal và Specific goal cũng như có generic practice và specific practice.

Mỗi Process Area có một số goal cần thực hiện để có thể đạt được mục đích của PA đó Có hai loại goal:

1 Specific goals (SG)2 Generic goals (GG)

Practices

Practices là các hoạt động cần thực hiện để đạt được goal của PA Mỗi practice 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ịch biể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 PA lạ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ân tầ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 generic goal, nhưng các practice này đều thuộc nhóm practice cơ sở hoặc nhóm practice nâng cao.

Các practice cơ sở là các practice ở mức năng lực 1 Các practice này liên quan 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ùy tiện không theo một kế hoạch hay một quy trình nào Mức độ thực hiện các practice 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âng cao 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 Quantitative Prọ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ình Requirements Management muốn đạt tới mức năng lực 2 thì phải thiết lập được chí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ới quy 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ăng lự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ên quan 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ánh cá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ức tăng trưởng 2 và 3 trong mô hình phân tầng đều được thực hiện Vì vậy, target profile 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 ty chuyê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 cho mình một target profile bao gồm các PA Project Planning, Project Monitoring and Control ở mức năng lực 2 còn PA Verification và Validation ở mức năng lự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ến quy 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ại cá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 quy trì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ác lĩ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ảo trì, 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ác thông tin về thành công cũng như những khó khăn mà họ gặp phải Những thô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ác nhau 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ệc quả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ệc tậ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ới mụ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 chung thuậ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 quy trì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ên quan 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ểm tra, đ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

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 ProcessDefinition

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

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

SG của OPD – tạo và duy trì các tài sản của quy trình tổ chức – được thực hiện bởi năm SP

SP1: Tạo ra các bản mô tả các mô hình vòng đời được sử dụng trong mỗi dự án

SP2: Tạo các quy trình chuẩn của tổ chức dựa trên các mô hình vòng đời SP3: Tạo ra các hướng dẫn và các mẫu cho các quy trình chuẩn, các hướng dẫn và các mẫu này sẽ được sử dụng trong pha lập kế hoạch dự

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ính sách.

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

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ên nhữ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ác thông tin này sẽ được sử dụng để đánh giá quy trình nhằm xác định các cải tiến cầ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ến nhấ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ằng cách kiểm tra cả các tiêu chuẩn (measures) thực thi và tiêu chuẩn đối với sản phẩ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ình chuẩ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 Innovationand 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ày cả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 thu thậ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ến cũ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ệu quả 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 định trá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