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

CMM được thiết kế nhằm hướng dẫn các công ty phần mềm trong việc lựa chọn các chiến lược cải tiến quy trình bằng việc quyết định mô hình trưởng thành tiến trình hiện tại và xác định một

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ



Nguyễn Hoài Nam

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

Mục lục

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

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

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

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

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

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

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

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

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

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

3.4 Các mục tiêu……… 25

3.5 Các đặc điểm chung……… 25

3.6 Các thực hành then chốt……… 26

4 Tương lai của CMM……… 27

5 Kết luận……… 28

Chương 2 Tiến trình sử dụng lại được và các mức tăng trưởng của nó trong một tổ chức (RMM) 30 1 Tổng quan……… 30

2 Khía cạnh hiện nay: Kỹ nghệ tiến trình……… 30

3 Mô hình tăng trưởng tái sử dụng (RMM)……… 32

3.1 Các nhân tố tái sử dụng……… 33

3.2 Các hoạt động tái sử dụng……… 35

4 Kết luận……… 46

Chương 3 Áp dụng CMM, RMM vào hoạt động thực tiễn sản xuất phần mềm tại công ty CT-IN 47 1 Giới thiệu……… 47

2 Chi tiết các vùng thực hành then chốt……… 47

2.1 Quản lý yêu cầu……… 48

2.2 Quy trình phát triển kế hoạch dự án phần mềm……… 54

2.3 Quản Lý Cấu Hình……… 62

2.4 Quy trình đảm bảo chất lượng phần mềm……… 69

2.5 Quy trình kiểm tra……… 77

Chương 4 Xây dựng công cụ trợ giúp quản lý tiến trình 87 1 Giới thiệu……… 87

2 Mô tả phần mềm……… 88

3 Nhận xét……… 97

MỞ ĐẦU Vai trò của tổ chức và quản lý đối với chất lượng phần mềm (bên cạnh yếu

tố công nghệ, nhân lực)

Mô hình CMM/CMMi do Viện Kỹ Thuật SEI (Software Engineering Institute) liên kết với Đại Học Carnegie Mellon - Hoa Kỳ phát triển Mô hình CMM trước đây gồm có 5 mức: khởi đầu, lặp lại được, được định nghĩa, được quản lý và tối ưu Một điểm đặc biệt là mỗi doanh nghiệp có thể áp dụng mô hình CMM ở bất kỳ mức nào mà không cần tuân theo bất

kỳ một qui định nào, không cần phải đạt mức thấp trước rồi mới có thể đạt mức cao (có thể

đi thẳng lên mức cao, hoặc cũng có thể tự hạ xuống mức thấp hơn) Về nguyên tắc, SEI không chính thức đứng ra công nhận CMM mà thông qua các tổ chức tư vấn, các đánh giá trưởng được SEI ủy quyền và thừa nhận

Tuy nhiên, từ cuối 2005, SEI không tổ chức huấn luyện SW-CMM và chỉ thừa nhận các đánh giá theo mô hình CMMi mới từ tháng 12/2005 CMMi được tích hợp từ nhiều mô hình khác nhau, phù hợp cho cả những doanh nghiệp phần cứng và tích hợp hệ thống, chứ không chỉ đơn thuần áp dụng cho doanh nghiệp sản xuất phần mềm như CMM trước đây Có

4 mô hình áp dụng CMMi là CMMi-SW (dành cho công nghệ phần mềm), CMMi-SE/SW (dành cho công nghệ hệ thống và phần mềm), CMMi-SE/SW/IPPD (dành cho công nghệ hệ thống + công nghệ phần mềm với việc phát triển sản phẩm và quy trình tích hợp), CMMi-SE/SW/IPPD/SS (dành cho công nghệ hệ thống + công nghệ phần mềm với việc phát triển sản phẩm và quy trình tích hợp có sử dụng thầu phụ) Có 2 cách diễn đạt và sử dụng CMMi: Staged (phù hợp cho tổ chức có trên 100 người) và Continuos (phù hợp cho tổ chức dưới 40 người) CMMi cũng bao gồm 5 mức như CMM: khởi đầu, lặp lại được, được xác định, được quản lý và tối ưu hóa

Tuy nhiên, việc chuyển đổi từ mô hình CMM sang CMMi sẽ tùy thuộc vào từng doanh nghiệp/tổ chức cụ thể Có thể sẽ phải thay đổi rất nhiều và thực tế là áp dụng mô hình CMMi đòi hỏi nhiều sự đầu tư về công sức và tài chính hơn Kinh phí để tiến hành đánh giá theo

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

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

đó họ sẽ có đủ năng lực để áp dụng những mô hình này

Vấn đề về sử dụng lại phần mềm (software reuse) cũng rất quan trọng trong công nghệ phần mềm Khi được nghiên cứu tích hợp trong quá trình phát triển phần mềm, nó sẽ cung cấp cơ sở cho các cải tiến sâu sắc trong cách phát triển và bảo dưỡng các hệ thống phần mềm trong chu kỳ vòng đời Nó có những mục đích như sau:

 Tăng cường năng lực sản xuất

 Cải thiện chất lượng và độ tin cậy của các hệ thống phần mềm

 Cải thiện được sự tương tác qua lại của các hệ thống

 Xác định và kiểm soát được các rủi ro kỹ thuật

 Rút ngắn thời gian phát triển và bảo dưỡng

Mô hình tăng trưởng sử dụng lại được RMM (Reuse Maturity Model) đã được đưa ra nhằm giúp các doanh nghiệp áp dụng hiệu quả việc tái sử dụng lại phần mềm

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

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

Luận văn sẽ tập trung vào trình bày hai mô hình CMM và RMM, các khài niệm, thuật ngữ, các vấn đề cần quan tâm đối với hai mô hình này qua đó áp dụng thực tế trong hoạt động xuất khẩu phần mềm tại công ty CT-IN

Mô hình tăng trưởng năng lực (CMM) cho phần mềm là một tập các thành phần cơ bản của một quy trình phần mềm hiệu quả CMM miêu tả sự cải tiến không ngừng từ một quá trình sơ khai, chưa được thuần thục đến một quy trình thuần thục và theo quy định rõ ràng

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

Mô hình tăng trưởng sử dụng lại cũng có 5 mức:

 (1): Khởi tạo (Initial Chaotic)

 (2): Được giám sát (Monitored)

 (3): Được phối hợp (Coordinated)

 (4): Được lên kế hoạch (Planned)

Em cũng xin cảm ơn các thầy cô trường Đại Học Công Nghệ - Đại Học Quốc Gia Hà Nội đã tạo điều kiện và giúp đỡ em trong quá trình học tập và làm khóa luận tốt nghiệp

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

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

Nguyễn Hoài Nam

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

CMM

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

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

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

và các phản hồi rộng lớn từ cả phía các nghành công nghiệp và chính phủ

Mô hình trưởng thành năng lực cho phần mềm cung cấp các hướng dẫn cho các công

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

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

Phiên bản đầu tiên của CMM, v 1.0, được đưa ra và sử dụng bởi cộng đồng phần mềm trong khoảng thời gian 1991, 1992 Một hội nghị được tổ chức vào tháng 4 năm 1992

để bản về CMM v 1.0 với sự tham gia của hơn 200 chuyên gia phần mềm Phiên bản hiện nay của CMM, v 1.1 là kết quả của những phản hồi từ hội nghị đó và các phản hồi tiếp tục về sau này của cộng đồng phần mềm

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

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

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

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

tế được thực hiện Những tiến trình đã được định nghĩa này sẽ được cập nhật khi cần thiết,

và sự cải tiến được phát triển thông qua các việc kiểm thử trước có điều khiển và/hoặc các việc phân tích về lợi ích tài chính Vai trò và trách nhiệm trong một tiến trình xác định là rất

rõ ràng trong dự án và trong tổ chức

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

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

Một tiến trình phần mềm được định nghĩa là một tập các hành động, phương thức, các trải nghiệm thực tế và các biến đổi mà con người sử dụng để phát triển và bảo trì phần mềm

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

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

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

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

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

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

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

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

đó Các mức này cũng giúp cho một tổ chức thu xếp mức độ ưu tiên những cố gắng cải tiến của nó

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

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

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

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

2.1.1 Mức khởi đầu

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

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

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

Cho dù tiến trình ở mức 1 là khó xác định, thậm chí lộn xộn, các tổ chức ở mức 1 thường xuyên phát triển các sản phẩm làm việc được, cho dù nó có thể vượt quá ngân sách

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

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

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

án khác Một tiến trình hiệu quả có thể được phân biệt nhờ tiến trình đó được thực hành, tài liệu hóa, làm cho tuân thủ, đào tạo, đo đạc và có khả năng cải tiến

Các dự án trong các tổ chức mức 2 thường thiết lập được các điểu khiển quản lý phần mềm cơ bản Các cam kết dự án thực tế thường được dựa trên những kết quả quan sát

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

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

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

Năng lực tiến trình phần mềm trong các tổ chức ở mức 2 có thể được tổng kết thành quy luật do việc tạo kế hoạch và theo dõi dự án phần mềm là ổn định và các sự thành công

từ sớm có thể được lặp lại Tiến trình của dự án được đặt dưới sự kiểm soát có hiệu quả của một hệ thống quản lý dự án, tuân theo các kế hoạch thực tế dựa trên hiệu năng của các dự

án trước

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

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

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

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

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

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

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

đã được xác định của dự án Các tiến trình phần mềm được cung cấp các công cụ để đo đạc được xác đinh tốt và thống nhất tại mức 4 Các công cụ này đưa ra cơ sở về lượng cho việc đánh giá các tiến trình phần mềm của dự án và sản phẩm

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

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

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

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

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

và đưa ra các đề nghị thay đổi tiến trình phần mềm của tổ chức Sự năng động mà tìm ra những thực hành kỹ nghệ phần mềm tốt nhất được xác định và chuyển giao xuyên suốt tổ chức

Nhóm dự án phần mềm trong các tổ chức ở mức 5 thực hiện việc phân tích lỗi để tìm

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

án khác

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

Năng lực tiến trình phần mềm của các tổ chức ở mức 5 có thể được nhận ra là sự liên tục cải tiến do các tổ chức ở mức 5 luôn cố gắng không ngừng để cải tiến dải của năng lực tiến trình của họ, do vậy cải tiến hiệu năng tiến trình của các dự án Sự cải tiến xuất hiện do

cả sự tiến bộ không ngừng trong tiến trình hiện thời và bởi sự sáng tạo sử dụng các công nghệ và phương pháp mới Sự cải tiến về công nghệ và tiến trình được lên kế hoạch và quản

lý chặt chẽ như là các hoạt động kinh doanh bình thường

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

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

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

Thứ hai, khi độ trưởng thành tăng lên, khả năng thay đổi của kết quả thực tế xung quanh kết quả đích giảm đi Ví dụ, trong các tổ chức mức 1, ngày giao hàng cho các dự án

có cùng kích cỡ thường không đoán được và thay đổi rất nhiều Tuy nhiên, các dự án tương

tự trong tổ chức với mức trưởng thành cao hơn sẽ được giao hàng trong dải nhỏ (Điều này được thể hiện trong hình 2.4 bởi độ lớn của vùng phía dưới đường cong được tập trung gần đường đích)

Thứ ba, các kết quả đích được cải tiến khi mức độ trưởng thành của tổ chức tăng lên Điều này có nghĩa là, khi một tổ chức phần mềm trưởng thành, giá phần mềm sẽ giảm, thời gian phát triển trở nên ngắn hơn, năng suất và chất lượng sẽ tăng lên Trong một tổ chức ở mức 1, thời gian phát triển có thể rất dài do số lượng phải làm lại lớn để sửa lỗi Trái lại, các

tổ chức với mức trưởng thành cao hơn đã tăng độ hiệu quả của tiến trình và giảm việc làm lại liên quan đến giá, cho phép thời gian phát triển trở nên ngắn hơn (Điều này được thể hiện trong hình 2.4 bởi sự dịch chuyển ngang của đường đích từ vị trí ban đầu)

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

việc tăng cường thay đổi Thậm chí trong trường hợp của các hệ thống chưa có tiền lệ, đặc điểm thực hành quản lý và kỹ nghệ của các tổ chức trưởng thành hơn giúp cho việc xác định

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

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

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

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

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

Tại cùng một thời điểm, người ta nhận ra rằng các nỗ lực cải tiến tiến trình nên tập trung vào nhu cầu của tổ chức trong ngữ cảnh của môi trường kinh doanh của nó, và các thực hành ở mức cao hơn có thể giải quyết nhu cầu hiện tại của một tổ chức hoặc dự án Ví

dụ, khi miêu tả các bước mà một tổ chức nên thực hiện để chuyển từ mức 1 sang mức 2, một trong những gợi ý thường xuyên là tạo ra nhóm kỹ nghệ tiến trình phần mềm (SEPG),

mà nó là một thuộc tính của các tổ chức mức 3 Trong khi SEPG là một đặc tính chưa cần thiết của tổ chức mức 2, chúng có thể là một phần có ích của việc miểu tả để đạt được mức

2

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

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

 Các nhóm đánh giá sẽ sử dụng CMM để xác định điểm mạnh và điểm yếu trong tổ chức

 Các nhóm đánh giá sẽ sử dụng CMM để xác định các rủi ro của việc lựa chọn giữa các nhà thầu khác nhau để có được hợp đồng và giám sát các hợp đồng

 Mức quản lý cao hơn sẽ sử dụng CMM để hiểu được các hoạt động thiết yếu nhằm đưa ra chương trình cải tiến tiến trình phần mềm trong tổ chức của họ

 Nhân viên kỹ thuật và các nhóm cải tiến tiến trình như SEPG sẽ sử dụng CMM

để hướng dẫn giúp họ xác định và cải tiến tiến trình phần mềm trong tổ chức của họ

Do cách sử dụng đa dạng của CMM, nó phải được phân nhỏ ra thành những chi tiết

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

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

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

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

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

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

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

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

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

Tính từ “then chốt” ngụ ý rằng, có các vùng tiến trình (và tiến trình) mà không phải

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

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

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

3, như được miêu tả trong “Quản lý dự án tích hợp” (Integrated Software Management)

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

 Mục đích của Quản lý yêu cầu (Requirement Management) là tạo ra một sự hiểu biết chung giữa khách hàng và dự án phần mềm của yêu cầu khách hàng

mà sẽ được giải quyết bởi dự án phần mềm Sự đồng thuận này với khách hàng là cơ sở cho việc lên kế hoạch và quản lý dự án phần mềm

 Mục đích của Lên kế hoạch dự án phần mềm (Software Project Planning) là

để tạo ra một kế hoạch phù hợp cho việc thực hiện các kỹ nghệ phần mềm và cho việc quản lý dự án phần mềm Các kế hoạch này là cơ sở cần thiết cho việc quản lý dự án phần mềm

 Mục đích của Giám sát và trông trước dự án phần mềm (Software Project Tracking and Oversight) là để tạo ra cái nhìn chính xác vào tiến độ thực tế để cấp quản lý có thể thực hiện các hành động hiệu quả khi mà tiến độ thực tế của dự án phần mềm bị thay đổi đi so với kế hoạch

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

 Mục đích của Đảm bảo chất lượng phần mềm (Software Quality Assurance) là

để cung cấp cho cấp quản lý một cái nhìn thích hợp vào quy trình đang được

sử dụng bởi dự án và vào các sản phẩm đang được xây dựng

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

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

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

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

cơ chế như đào tạo

 Mục tiêu của Chương trình đào tạo (Training Program) là phát triển kỹ năng

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

 Mục đích của Quản lý phần mềm tích hợp (Integrated Software Management)

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

án

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

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

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

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

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

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

 Mục tiêu của Quản lý chất lượng phần mềm (Software Quality Management)

là phát triển một sự hiểu biết đinh lượng của chất lượng của sản phẩm phần mềm của dự án và đạt được các mục tiêu chất lượng cụ thể

Các vùng tiến trình then chốt ở mức 5 bao trùm các vấn đề ở cả mức tổ chức và dự

án cần phải giải quyết để thi hành việc cải tiến tiến trình phần mềm liên tục và đo đạc được

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

 Mục tiêu của Quản lý thay đổi công nghệ (Technology Change Management)

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

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

3.4 Các mục tiêu

Các mục tiêu tổng hợp các thực hành then chốt của một vùng tiến trình then chốt và

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

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

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

Cam kết

thực hiện

Cam kết thực hiện miêu tả các hành động mà một tổ chức phải thực hiện để đảm bảo rằng tiến trình được đưa ra và sẽ kéo dài lâu Việc cam kết thực hiện điển hình liên quan với đưa ra các chính sách ở mức tổ chức và sự đồng thuận của các cấp quản lý cao

Khả năng

thực hiện

Khả năng thực hiện miêu tả các điều kiện ban đầu mà phải tồn tại trong một

tổ chức hay dự án để thực hiện sự cạnh tranh tiến trình phần mềm Khả năng thực hiện điển hình bao gồm các nguồn lực, cấu trúc tổ chức, và đào tạo

Các thực hành trong đặc điểm chung “Các hoạt động được thực hiện” miêu tả cần phải thực hiện những gì để thiết lập được một khả năng tiến trình Các thực hành khác, được thực hiện như một tổng thể, hình thành một cơ sở nhờ nó mà tổ chức có thể kết hợp các thực hành được miêu tả trong đặc điểm chung “Các hoạt động được thực hiện”

3.6 Các thực hành then chốt

Mỗi một vùng tiến trình then chốt được miêu tả theo nghĩa của các thực hành then chốt mà đóng góp cho sự thỏa mãn các mục tiêu của nó Các thực hành then chốt miêu tả

cấu trúc hạ tầng và các hoạt động đóng góp cho sự thực hiện và kết hợp có hiệu quả của một vùng tiến trình then chốt

Mỗi một thực hành then chốt bao gồm một câu đơn, và sau đó thường là một giải thích rõ ràng hơn, có thể bao gồm ví dụ và giải thích kỹ lưỡng Các thực hành then chốt này, cũng được nhắc đến như là các thực hành then chốt mức cao nhất, chỉ ra các chính sách cơ bản, các thủ tục và các hoạt động cho một vùng tiến trình then chốt Các thành phần của giải thích chi tiết thường được nhắc đến như là các thực hành con Các thực hành then chốt miêu tả cái sẽ được thực hiện, nhưng chúng không được phiên dịch theo sự ủy thác là làm sao mà đạt được các mục tiêu đề ra Các thực hành thay thế có thể đạt được mục đích của một vùng tiến trình then chốt Các thực hành then chốt có thể được phiên dịch một cách vừa phải để đánh giá xem liệu các mục tiêu của một vùng tiến trình then chốt có thực sự hiệu quả, mặc dù có thể đạt được bằng cách khác Các thực hành then chốt có thể tìm thấy trong cuốn sách “Các thực hành then chốt trong mô hình trưởng thành năng lực, phiên bản 1.1” cùng với hướng dẫn cách thực hiện chúng

4 Tương lai của CMM

Việc đạt tới các mức cao hơn của sự trưởng thành tiến trình phần mềm là sự phát triển không ngừng và yêu cầu một sự cam kết dài hạn cho sự cải tiến tiến trình liên tục Các

tổ chức phần mềm thường mất đến 10 năm hoặc hơn để xây dựng nên cơ sở cho sự cải tiến tiến trình liên tục hướng văn hóa Mặc dù một chương trình cải tiến tiến trình kéo dài một thập kỷ được áp dụng chủ yếu cho các công ty Mỹ, mức độ công sức này là cần thiết để tạo

án, chúng vẫn chưa được tích hợp vào trong CMM

Trong các năm tiếp theo, CMM sẽ tiếp tục được đặt dưới sự kiểm thử toàn diện cho đến được sử dụng trong các đánh giá về tiến trình phần mềm, đánh giá năng lực phần mềm,

và các chương trình cải tiến tiến trình Các sản phẩm được phát triển từ CMM và các chương trình đào tạo sẽ được phát triển và điều chỉnh thích hợp CMM là một tài liệu sống có thể được cải tiến, nhưng dự tính rằng CMM phiên bản 1.1 sẽ là cơ sở cho đến ít nhất năm 1996

Nó cung cấp một sự cân bằng thích hợp và thực tế giữa nhu cầu về sự ổn định và trưởng thành liên tục Một cuốn sách về CMM đang trong quá trình biên soạn cho loạt sách của SEI được nhà xuất bản Addison – Wesley xuất bản

SEI cũng đang làm việc với tổ chức chuẩn hóa quốc tế, ISO trong một nỗ lực nhằm xây dựng các chuẩn quốc tế cho việc đánh giá tiến trình phần mềm, cải thiện và đánh giá khả năng Nỗ lực này sẽ tích hợp các khái niệm từ rất nhiều các phương thức cải tiến tiến trình khác nhau Sự phát triển của các chuẩn ISO (và các sự đóng góp của các phương thức khác) sẽ có ảnh hưởng đến CMM phiên bản 2.0, thậm chí các công việc tiến trình của SEI sẽ ảnh hưởng đến các hoạt động của ISO

5 Kết luận

CMM thể hiện cách tiếp cận “cảm nhận kỹ nghệ phần mềm chung” cho việc cải tiến tiến trình phần mềm Các mức trưởng thành, các vùng tiến trình then chốt, các đặc điểm chung, và các thực hành then chốt đã được thảo luận sâu rộng và được xem xét trong cộng đồng phần mềm Trong khi CMM chưa hoàn thiện, nó thể hiện một sự đồng thuận rộng rãi của cộng đồng phần mềm và là một công cụ hữu ích cho các nỗ lực hướng dẫn cải tiến tiến trình phần mềm

CMM cung cấp một cấu trúc khái niệm cho việc cải tiến quản lý và phát triển của các sản phẩm phần mềm theo một cách thống nhất và có quy tắc Nó không đảm bảo rằng các sản phẩm phần mềm sẽ được xây dựng thành công và các vấn đề trong kỹ nghệ phần mềm

sẽ được giải quyết một cách toàn diện Tuy nhiên, các báo cáo hiện thời từ các chương trình cải tiến dựa trên CMM đã chỉ ra rằng, nó có thể cải thiện được những khía cạnh mà với nó, các tổ chức phần mềm có thể đạt được mục đích về chi phí, chất lượng và mục tiêu năng suất

CMM cũng chỉ ra các thực hành cho một tiến trình phần mềm trưởng thành và cung cấp các ví dụ của trình độ phát triển của khoa học kỹ thuật (trong một vài trường hợp, nó là tiên tiến nhất, nhưng nó cũng không có nghĩa đã thấu đáo mọi vấn đề và độc đoán) CMM

chỉ chỉ ra các đặc tính của của một tiến trình phần mềm hiệu quả, nhưng một tổ chức trưởng thành phải giải quyết tất cả các vấn đề thiết yếu để có được dự án thành công, bao gồm con người và công nghệ, cũng như tiến trình

Chương 2 Tiến trình sử dụng lại được và các mức tăng trưởng

của nó trong một tổ chức (RMM)

1 Tổng quan

Phần này tập trung vào vấn đề tái sử dụng như là một hoạt động phụ trợ trong nhóm các tiến trình vòng đời phần mềm Tái sử dụng có thể được định nghĩa là tập các hành động được thực hiện Mỗi một hành động, tùy thuộc vào việc nó có được thực hiện hay không, có thể được điều khiển và đánh giá, cung cấp một ma trận để quyết định mức độ tăng trưởng tái sử dụng trong một tổ chức

2 Khía cạnh hiện nay: Kỹ nghệ tiến trình

Hiện nay, các bài toán về kỹ nghệ phần mềm, được biết đến như “Khủng hoảng phần mềm”, đang giải quyết tập trung vào các tiến trình Thông qua một tập các thủ tục, kỹ thuật

và các công cụ, những bài toán này đã đuợc giải quyết nhưng kết quả không như mong muốn Mặt khác, mức độ hiện tại của các môi trường làm việc, của công nghệ của các công

cụ phát triển phần mềm và của việc sử dụng phần cứng có độ phức tạp cao đòi hỏi việc tổ chức các tiến trình phần mềm trong kỹ nghệ hệ thống

Một tiến trình được định nghĩa là “một phương tiện trong đó con người, các thủ tục, các phương pháp, thiết bị và công cụ được tích hợp lại để tạo ra một kết quả mong muốn”

Tổ chức ISO gần đây đã đưa ra chuẩn “Tiến trình vòng đời phần mềm”, trong đó tất

cả các tiến trình tham gia vào trong vòng đời phần mềm được định nghĩa Trong cùng một khía cạnh đó, ISO cũng đưa ra một bản phác thảo cho chuẩn khác, “Đánh giá tiến trình phần mềm” là cơ sở để đánh giá các tiến trình phần mềm Mục đích của chuẩn này là để khuyến khích văn hóa cải tiến không ngừng thông qua kỹ nghệ tiến trình để phù hợp với yêu cầu kinh doanh của tổ chức

Một mặt khác, SEI cũng phát triển mô hình CMM, cũng là một mô hình khác tập trung vào kỹ nghệ tiến trình Thông qua mô hình này chúng ta có thể xác định được mức trưởng thành của một tổ chức Đó là chất lượng, năng suất, và rủi ro trong một tổ chức nắm giữ sự thành công của các dự án máy tính

Cộng đồng Châu Âu (EC) đã tiến một bước dài, thông qua các dự án ESPRIT, ACTS, v.v…nhằm đạt được sự tăng năng suất thông qua việc tái sử dụng các thành phần phần mềm như EUROWARE, REBOOT, RECYCLE, SCALE, ROBUST,…

Tuy nhiên, không có nghiên cứu nào của Châu Âu (ngoại trừ REBOOT), hoặc các công việc của tổ chức quốc tế ISO trong kỹ nghệ tiến trình, hoặc như mô hình được sử dụng rộng rãi CMM của SEI, coi tái sử dụng như một tiến trình

Chúng ta ủng hộ cách tiếp cận theo hướng tái sử dụng tiến trình và trong trường hợp này, các tác giả khác đã đề nghị các mô hình khác nhau để cấu trúc nên sự rộng rãi của bao

gồm tái sử dụng được cung cấp bởi tổ chức Đặc biệt có giá trị là các đề nghị của các tác giả Koltun và Hudson, được đưa ra ở Hội nghị nâng cao năng suất phần mềm và được sử dụng trong một dự án UE gọi là REBOOT (Reuse Based on Object Oriented Techniques)

Mặc dù tất cả các mô hình đều chung chung, mô hình chính xác nhất, theo cách hiểu

là có thể quyết định được các hành động cần phải thực hiện, là mô hình của Koltun và Hudson Trong mô hình này, 5 mức trưởng thành được định nghĩa để tái sử dụng:

1 Khởi đầu lộn xộn (Initial Chaotic)

2 Được giám sát (Monitored)

3 Được điều phối (Coordinated)

4 Được lên kế hoạch (Planned)

5 Sâu sắc (Ingrained)

Các tiêu chí được sử dụng để đánh giá các mức trưởng thành trong một tổ chức là: Động lực thúc đẩy, Kế hoạch tái sử dụng, Sự rộng rãi tái sử dụng, Trách nhiệm tạo cho việc tái sử dụng xảy ra, Tiến trình trong đó tái sử dụng được phân cấp, Kiểm kê tái sử dụng, hoạt động phân lớp, hỗ trợ kỹ thuật, các ma trận đánh giá và các vấn đề về pháp luật

3 Mô hình tăng trưởng tái sử dụng (RMM)

Mô hình tăng trưởng tái sử dụng cho phép xác định mức tăng trưởng mà một tổ chức

có để tái sử dụng Mô hình này được cấu trúc từ ba nhân tố tái sử dụng Mỗi một nhân tố được quyết định bởi một tập các hành động tái sử dụng Mỗi một hành động thể hiện một đơn vị đo lường để quyết định mức tái sử dụng sẵn có cho tổ chức đó

Trong mô hình RMM, người ta thường suy nghĩ rằng, việc tái sử dụng rộng rãi của tổ chức nên được đối phó một cách độc lập với khả năng của một dự án nhất định được thực hiện bởi tổ chức đó được tái sử dụng Trong thực tế, mức độ tái sử dụng qua việc thực hiện các dự án có thể được sử dụng như một tiêu chí khác để quyết đinh mức tăng trưởng tái sử dụng của tổ chức đó

Để xác định chất lượng của mức trưởng thành của một tổ chức, người ta thường sử dụng các yếu tố như các khía cạnh liên quan đến cấu trúc kỹ thuật, kiến trúc phần mềm của

tổ chức, và yếu tố quản lý tổ chức

Các nhân tố tái sử dụng

Cấu trúc của mô hình này dựa trên việc giám sát ba nhân tố tái sử dụng khác nhau

-Cấu trúc kho lưu trữ

 Biểu diễn thông tin

Một trong những yêu cầu quan trọng nhất làm cho việc tái sử dụng phần mềm xảy ra

là sự tồn tại của một kho lưu trữ dùng để lưu các thông tin có thể tái sử dụng Để đạt được điều này điều thiết yếu là phải có một cấu trúc biểu diễn thông tin cho phép sự phân loại và khôi phục trong tương lai như: Lập trình, Thiết kế, Phân tích, Kiểm thử, Lập tài liệu, Quản lý dự án, v.v… Việc đánh giá cấu trúc lưu trữ của tổ chức đang có không có nghĩa là tất cả các thành phần mà có thể được lưu trữ là tái sử dụng được hoàn toàn Vì lý do này nên cấu trúc lưu trữ được xem xét một cách độc lập với kiến trúc phát triển

 Sự phân lớp và kỹ thuật khôi phục

Việc phân lớp và kỹ thuật khôi phục thể hiện nền tảng của tái sử dụng:

o Trên khía cạnh đánh chỉ số thông tin, việc đánh chỉ số bằng tay cũng như

là được thực hiện thiếu sự trợ giúp chuyên nghiệp (một cách tự động) được xem xét

o Nói đến việc khôi phục, việc khôi phục thuộc tính trực tiếp (đặc tính nhận dạng) và việc hỏi được tài liệu hóa được đề nghị cho mỗi khái niệm

 Việc quản lý và các công cụ tự động

o Khả năng thực hiện việc cấp phép, loại bỏ, và thay đổi các thành phần được lưu trong kho lưu phải được cân nhắc

o Sự tồn tại của các kỹ thuật thông báo tự động sự hợp nhất hoặc thay đổi các thành phần mới (Các kỹ thuật nhóm : Groupware)

2 Kiến trúc phát triển phần mềm

 Ý tưởng là đánh giá kiến trúc phần mềm theo hướng tái sử dụng của nó Mặt khác, các phương pháp hướng đối tượng và hướng sự kiện và các phương pháp khác đều dựa trên các kỹ thuật cấu trúc, như các phương pháp ống (pipe) và lọc (filter) v.v… Tuy nhiên, do sự chiếm ưu thế của phương pháp GUI, khía cạnh này cũng được cân nhắc

 Yếu tố tái sử dụng được thu nhận có hệ thống bởi tổ chức hoặc dự án nhất định (Tái sử dụng các phân tích, thiết kế, các đoạn mã nguồn thực thi được, và/hoặc bất kỳ một thành phần nào của dự án phần mềm) Mức độ này tạo ra một mối quan hệ với sự hiển thị của thông tin của vùng lưu trữ, nhưng có thể được đánh giá độc lập do mặc dù có vẻ là không như thế, việc tái sử dụng của các thành phần mà không có kho lưu trữ được thực hiện bởi đơn giản là việc tích hợp các thành phần được biết là có thể tái sử dụng được (hoặc là do

kỹ sư phần mềm đơn lẻ tái sử dụng phân tích, thiết kế, lập trình, hoặc bất kỳ một lý do nào khác)

 Kiểm thử thành phần: Do tính đối ngẫu đã được đề nghị của phần mềm cho tái sử dụng và phần mềm với tái sử dụng, cấu trúc kiểm thử được áp dụng cho một tổ chức cần được xác định sao cho tương ứng với phần mềm cho tái

sử dụng

3 Quản lý hành chính

Có ba khía cạnh khác nhau được đề cập đến:

 Các khía cạnh hành chính của tái sử dụng hỗ trợ cho những nhân tố như nguồn nhân lực và vai trò của nó trong việc hoàn thiện tiến trình

 Động cơ thúc đẩy và kế hoạch để đạt được tái sử dụng

 Mức độ tái sử dụng của các dự án trước đây, được áp dụng theo chiều dài của mức độ cải tiến đạt được, mang đến bởi nỗ lực dự án

Các hoạt động tái sử dụng

Mỗi một nhân tố tái sử dụng bao gồm một nhóm các hành động phải được điều khiển Tùy theo mức độ trưởng thành của tổ chức hay là mức độ tái sử dụng của dự án được điều khiển, người ta sẽ chấp nhận các hành động khác nhau được đề nghị dưới đây

1 – Cấu trúc lưu trữ = r

1.1.1 Cấu trúc lưu trữ để lưu trữ các thành phần mã nguồn 0.5

1.1.2 Cấu trúc lưu trữ để lưu trữ các thành phần giao diện người dùng 0.5

1.1.3 Cấu trúc lưu trữ để lưu trữ các thành phần mã thực thi được 0.5

1.1.4 Cấu trúc lưu trữ để lưu trữ các thành phần phân tích & thiết kế 0.5

1.1.5 Cấu trúc lưu trữ để lưu trữ các thành phần tài liệu 0.5

1.1.6 Cấu trúc lưu trữ để lưu trữ các thành phần quản lý dự án 0.5

1-3 Các công cụ quản lý và tự động 3 điểm

1.3.1 Xác thực hệ thống, từ chối và thay đổi các thành phần 0.6

1.3.2 Sự tồn tại của môđun tính toán thống kê trên tái sử dụng thành

1.1.1 - Cấu trúc lưu trữ để lưu trữ các thành phần mã nguồn

 Cấu trúc mà không chỉ cho phép lưu trữ thuộc tính miêu tả bởi mã nguồn, mà lưu trữ luôn cả mã Sự kết hợp của các thành phần khác nhau cho phép trong kho lưu phải được định nghĩa rõ thông qua các luật nhất định của phương pháp luận sử dụng

1.1.2 - Cấu trúc lưu trữ để lưu trữ các thành phần giao diện người dùng

 Giao diện người sử dụng (GUI) thường được tái sử dụng Do đó, cần thiết phải xác định thành phần cơ bản tạo nên GUI Các thành phần này phải được quyết định bởi các luật của phương pháp luận sử dụng

1.1.3 - Cấu trúc lưu trữ để lưu trữ các thành phần mã thực thi được

 Các thành phần nhị phân thực thi được với đa giao diện, với các công nghệ COM của Microsoft, hoặc CORBA cho các hệ thống mở, hoặc gần đây công nghệ JAVA với applets, được sử dụng với mục đích cải tiến mức độ chung tái sử dụng của một số lượng lớn thông tin (chương trình, v.v…)

1.1.4 - Cấu trúc lưu trữ để lưu trữ các thành phần phân tích & thiết kế

 Việc định nghĩa phương pháp thể hiện các thành phần phân tích và thiết kế cũng phải được xác định bởi phương pháp luận sử dụng

1.1.5 - Cấu trúc lưu trữ để lưu trữ các thành phần tài liệu

dù tồn tại các kỹ thuật phân lớp tự động

1.2.2 - Khôi phục các thành phần thông qua việc nhận biết các thuộc tính

 Các thuộc tính nhận dạng, đã được miêu tả trước đây, thể hiện mức độ cơ bản nhất của sự phân lớp thông tin

 Vấn đề tương tự như 1.2.4 Nó phụ thuộc rất nhiều vào cấu trúc thông tin được lựa chọn để thể hiện các thành phần phân tích và thiết kế

1.2.6 - Khôi phục các thành phần bằng việc hỏi có tài liệu

 Việc hỏi có tài liệu hóa chuẩn bị cho việc khôi phục thành phần tốt cho phép cải tiến việc tách thông tin từ kho lưu

1.3.1 - Xác thực hệ thống, từ chối và thay đổi các thành phần

 Điều này thể hiện các công cụ bình thường của việc quản lý và xử lý thông tin được lưu trữ trong các cơ sở dữ liệu

1.3.2 - Sự tồn tại của môđun tính toán thống kê trên tái sử dụng thành phần

 Sự quyết định tự động của tỷ lệ tái sử dụng

1.3.3 - Tự động thông báo khi các thành phần được tích hợp hay thay đổi

 Trong các kho lưu lớn sử dụng thông tin có thể yêu cầu kho lưu đó có thể tích hợp thông tin trong các hệ thống thông điệp trong sự tham khảo đến các thay đổi trong kho lưu (các thành phần mới, thay đổi trong các cái đang tồn tại)

1.3.4 - Các kỹ thuật cho việc tạo tự động kho lưu từ các dự án trước

 Việc tự động hóa các kỹ thuật phân tích miền đang bắt đầu cho phép khởi tạo tự động cấu trúc thông tin thể hiện các kho lưu phần mềm

1.3.5 - Các kỹ thuật tích hợp tự động các thành phần trong các dự án mới

 Các kỹ thuật này cho phép các hệ thống kiểu CASE không chỉ khôi phục thông tin từ kho lưu, mà cũng cho phép tích hợp nó trong các môi trường phát triển hiện thời

theo cách mà các ứng dụng có thể được cài đặt tự động hay bán tự động, đơn giản bẳng việc tư vấn các kho lưu

Mô tả các hoạt động:

2.1.1 và 2.1.2 – Kiến trúc dựa trên các kỹ thuât cấu trúc hoặc hướng đối tượng

2 – Kiến trúc phát triển phần mềm = s 2-1 Kiến trúc phần mềm được sử dụng trong tổ chức 3 điểm

2.1.1 Kiến trúc dựa trên các kỹ thuật cấu trúc (không bao gồm

2.1.2)

0.3

2.1.2 Kiến trúc dựa trên các kỹ thuật hướng sự kiện và hướng đối

tượng (không bao gồm 2.1.1)

1.2

2.1.3 Sử dụng giao diện đồ họa người dùng (GUI) 0.75

2-2 Các kiểu tái sử dụng được áp dụng cho tổ chức 3 điểm

2.2.1 Tái sử dụng các thành phần dựa trên mã nguồn, kiểu, hàm,

v.v

0.5

2.2.2 Tái sử dụng các thành phần giao diện người dùng (đồ họa

hay không đồ họa)

0.5

2.2.3 Tái sử dụng các thư viện thực thi được và các đối tượng nhị

phân đa giao diện

0.5

2.2.4 Tái sử dụng các thành phần phân tích và thiết kế 0.5

2.2.5 Tái sử dụng các thành phần của tài liệu hóa 0.5

2.2.6 Tái sử dụng các thành phần thêm vào dự án phần mềm 0.5

2-3 Các kỹ thuật kiểm thử được sử dụng bởi tổ chức 3 điểm

Các hành động 2.1.1 và 2.1.2 được coi là độc quyền Chúng thể hiện sự bất lợi hoặc nhấn mạnh của việc tái sử dụng trong tổ chức, dựa trên kiểu kiến trúc phần mềm được sử dụng nhiều nhất Dựa trên xu hướng quản lý, hai kiểu độc quyền được đề nghị, đó là các kỹ thuật hướng cấu trúc hoặc hướng đối tượng Kỹ thuật hướng đối tượng được coi là gần với việc tái sử dụng do việc sử dụng rộng rãi của kỹ thuật đóng gói mà nó thường thể hiện Điều tất yếu là phải lựa chọn một trong hai kiến trúc thể hiện, dựa trên tần suất sử dụng nhiều hơn của nó

2.1.3 – Giao diện đồ họa người dùng

Điều này phản ánh việc tổ chức có hay không phát triển ứng dụng trong môi trường người dùng dựa trên các xử lý đồ họa

2.1.4 - Sử dụng các môi trường CASE

Việc sử dụng các môi trường CASE cho việc hỗ trợ vẽ biểu đồ và thiết kế được coi như các ưu điểm tiềm năng của việc tái sử dụng các thành phần được tạo ra

2.2.1 - Tái sử dụng các thành phần dựa trên mã nguồn, kiểu, hàm, v.v

Với sự ưu việt của việc tái sử dụng các thành phần, phần này phản ánh liệu tổ chức

có tái sử dụng bình thường các thành phần ở mức ngữ nghĩa thấp của tiến trình phần mềm Như đã được chỉ ra trước đây, việc miêu tả các thành phần tái sử dụng phải được định nghĩa trong miêu tả phương pháp

2.2.2 - Tái sử dụng các thành phần giao diện người dùng (đồ họa hay không đồ họa)

Giống như 2.2.1

2.2.3 - Tái sử dụng các thư viện thực thi được và các đối tượng nhị phân đa giao diện

Giống như 2.2.1