2.4. Năm mức độ trưởng thành của mô hình CMM
Mức độ tăng trƣởng là bình diện tiến hoá đƣợc xác định rõ hƣớng tới việc đạt tới qui trình phần mềm tăng trƣởng.
Mỗi mức độ tăng trƣởng cung cấp một tầng trong nền tảng cho sự cải tiến liên tục.
Năm mức độ (bậc) trƣởng thành của qui trình CMM sẽ đƣợc thảo luận nhiều hơn trong phần sau của luận văn này. Chúng có những đặc tính chung sau:
1. Khởi đầu: Cho đến khi qui trình được kiểm soát theo thống kê, sự tiến triển theo thứ tự trong cải tiến qui trình là không thể. Trong khi có nhiều
mức độ kiểm soát theo thống kê, bƣớc đầu tiên là phải đạt đƣợc khả năng dự đoán sơ bộ về lịch biểu và chi phí.
2. Có thể lặp lại: Tổ chức đã đạt được một qui trình ổn định với mức độ có thể lặp lại việc kiểm soát theo thống kê bằng cách bắt đầu quản trị dự án
3. Đã được xác định: Tổ chức đã định nghĩa qui trình như là một cơ sở cho việc nhất quán thực thi và việc nhận thức đƣợc ý nghĩa tốt hơn. Tại điểm
này công nghệ tiên tiến có thể đƣợc giới thiệu một cách có ích.
4. Đã được quản lý: Tổ chức đã khởi đầu được việc đo đạc và phân tích qui trình tổng hợp. Đó là khi những cải tiến chất lƣợng quan trọng nhất bắt
đầu.
5. Tối ưu hoá: Tổ chức bây giờ có một nền tảng để tiếp tục cải tiến và tối ưu qui trình.
Mức 1:Khởi đầu
- Những thực hành và kết quả phát triển ứng dụng là không nhất quán.
- Các tiến trình phát triển hiếm khi đƣợc xác định,và việc thực hành tốt thƣờng bị hi sinh để đáp ứng cho các lịch biểu không hợp lí.
- Việc quản lí dự án kém và không bảo vệ ngƣời phát triển khỏi bị ngắt quãng bởi những cam kết không hợp lí haynhững thay đổi quá đáng.
- Về bản chất, tổ chức phát triển ứng dụng ở Mức1 thiếu năng lực đáp ứng những cam kết một cách nhất quán.
Mức 2: Được quản lí
- Môi trƣờng ổn định tạo điều kiện thuận lợi cho việc lặp lại các thực thành thành công.
- Hội tụ vào việc phát triển năng lực của ngƣời quản lí dự án để lập kế hoạch cho những cam kết đạt đƣợc và thiết lập việc kiểm soát tuyến cơ sở yêu cầu và cấu hình sản phẩm.
- Dự án có thể dùng các phƣơng pháp hay thực hành khác nhau, nhƣng môi trƣờng là ổn định để hỗ trợ cho hiệu năng của chúng.
- Các tổ chức phát triển ứng dụng với năng lực Mức2 chuyển giao ứng dụng của họ theo lịch không phải phụ thuộc vào các nhân vật và làm việc thêm thƣờng xuyên
Mức 3: Được định nghĩa
- Tổ chức phát triển ứng dụng nhận diện những thực hành tốt nhất từ các dự án khác nhau.
- Các thủ tục đƣợc tích hợp vào tiến trình phát triển ứng dụng chung và đƣợc triển khai qua toàn bộ tổ chức phát triển ứng dụng.
- Văn hoá tổ chức mạnh nổi lên ở Mức 3 dựa trên tiến trình chung bao quát tất cả các yếu tố quan trọng cuả việc phát triển ứng dụng.
- Tổ chức phát triển ứng dụng có thể bắt đầu ƣớc lƣợng từ dữ liệu lịch sử nảy sinh từ các tiến trình chung.
- Dễ dàng hơn cho việc đạt tới các mục tiêu về chi phí, chức năng và lịch biểu
Mức 4: Được quản lí theo định lượng
- Tổ chức phát triển ứng dụng có thể phát triển tuyến cơ sở năng lực thống kê đặc trƣng cho kết quả trong đợi từ việc thực hiện các thủ tục này.
- Hiểu biết sâu sắc, định lƣợng về năng lực của tiến trình phát triển và nguyên nhân của những biến thiên trong hiệu năng của họ.
- Bằng việc quản lí hiệu năng của các tiến trình phát triển của mình một cáhc thống kê, tổ chức phát triển ứng dụng có thể dự đoán và kiểm soát kết quả của dự án dễ dàng hơn nhiều trong tiến trình dự án.
- Quản lí định lƣợng cho phép làm mạnh tổ dự án lên nhiều lần và làm tăng tính dự đoán đƣợc về kết quả cho việc quản lí dự án
Mức 5: Tối ưu
- Tại mức chín chắn cao nhất,tổ chức phát triển ứng dụng liên tục đánh giá về năng lực của các tiến trình của mình để chỉ ra các miền còn cần những cải tiến lớn nhất.
- Những cải tiến liên tục có thể đƣợc phát triển theo cơ hội bằng việc triển khai các kết quả của bài học rút ra, hay chúng có thể đƣợc tạo ra một cách tiên phong bằng việc đánh giá các phƣơng pháp phát triển mới,các tiến trình hay công nghệ mang tiềm năng chấp nhận đƣợc.
- Tổ chức phát triển ứng dụng Mức5 thiết lập nên một kết cấu nền cho việc hỗ trợ quản lí thay đổi liên tục xem nhƣ cấu phần tích hợp nền tảng của toàn thể tiến trình phát triển của nó.
2.5. Các lĩnh vực quy trình chốt (KPA) của mô hình CMM
Phân loại 18 KPA của CMM theo mức tăng trƣởng nhƣ sau:
Hình 2. 4 : Phân loại 18 KPA của CMM theo mức tăng trưởng
Hình 2. 5: Cấu trúc của KPAs
2.6. Khả năng áp dụng CMM
- Đƣợc đƣa ra vào đầu những năm1990, từ Bộ quốc phòng Mĩ, CMM dần đƣợc các tổ chức phần mềm thế giới chấp nhận.
- Đƣợc xem nhƣ phƣơng tiện dẫn lái cho việc liên kết với khách hàng, quản lí nhà cung cấp dịch vụ ngoài hay làm tăng kết quả năng suất.
- Phần lớn ngƣời sử dụng cuối của CMM là các nhà cung cấp dịch vụ CNTT, ngƣời làm khoán ngoài.
- Với ngƣời làm khoán ngoài, CMM có khả năng thiết lập nên sự tin cậy bằng việc đƣa ra cách lập tỉ lệ mức chín chắn nhƣ một chỉ báo về năng lực phát triển ứng dụng.
- Để đạt tới các năng lực tƣơng đƣơng với các nhà cung cấp dịch vụ,việc quản lí CNTT / phát triển ứng dụng bên thực hiện các chƣơng trình cải tiến tiến trình nhằm tới cmm ít nhất ở mức 2.
- Những năng lực này sẽ làm cho họ quản lí các dự án, kiểm soát yêu cầu và cấu hình, đảm bảo chất lƣợng và theo dõi tiến độ dự án.
Vậy CMM là gì và không là gì?
- Ngƣời ta thƣờng hiểu nhầm CMM là xác định ra phƣơng pháp luận cho việc điều hành, gây vƣớng víu (tức là không cho phép đổi mới). Thực tế, CMM không xác định phƣơng pháp luận nào cả.
- CMM 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.
- Trong khi CMM hội tụ vào điều tổ chức nên làm, thì nó không xác định cách đạt tới những mục tiêu đó.
- CMM cung cấp các hƣớng dẫn cho những nỗ lực cải tiến dài hạn và ngắn hạn. Với các tổ phát triển hội tụ vào những miền đặc biệt, CMM nhận diện những thực hành tốt nhất và cung cấp hƣớng dẫn có ích về các hoạt động huấn luyện, đo đạc và kiểm chứng.
- Việc thực hiện đúng vòng đời phát triển, nhƣ phát triển ứng dụng nhanh và lập trình cực đoan (XP), là nhất quán với các nền tảng tại trung tâm của CMM.
3. Những Khó Khăn Thường Gặp Trong Phát Triển Phần Mềm [4]
Tại sao lại có kĩ nghệ phần mềm? Nhƣ chúng ta đã biết trƣớc đây phần mềm do một số nhỏ ngƣời viết, trong vòng vài tháng. Nhƣng đến những hệ phần mềm lớn nhƣ hệ DOS của IBM hay hệ mềm dùng cho chƣơng trình không gian của Mĩ, thì không phải vài ngƣời trong vài tháng nữa mà là hàng trăm ngƣời trong nhiều năm, trong mƣời năm. Hệ mềm nhƣ chƣơng trình điều khiển viễn thông thì một công ty quốc tế có thể có 3, 4 nhóm làm việc tại 3, 4 nƣớc khác nhau, mỗi nhóm hai, ba trăm ngƣời. Chƣơng trình điều khiển tổng đài điện thoại hiện bán khắp nơi trên thế giới nhƣ vậy, nó đƣợc phát triển trong vòng 5 năm, bao gồm hàng chục nghìn đơn vị ngƣời làm. Số ngƣời tham gia phát triển đông tới vài trăm, thời gian phát triển lâu và thời gian sử dụng sẽ lâu hơn. Phần mềm không bao giờ giữ nguyên cả, bao giờ cũng thay đổi. Nhu cầu của ngƣời sử dụng ngày càng tăng, điện tử ngày càng rẻ và ngày càng làm đƣợc nhiều chuyện. Bởi vậy ngƣời ta thấy cần phải có phƣơng pháp
và quí. Khi một ngƣời làm phần mềm thay đổi công việc thì sản phẩm họ để lại rất khó để ngƣời tiếp theo tiếp thu đƣợc. Hay một ngƣời mới gia nhập vào dự án đang triển khai thì sẽ gặp khó khăn để thích nghi. Thành ra phải có một ngôn ngữ, một ngữ pháp chung, hay một quy trình chuẩn để làm sao sản phẩm độc lập với ngƣời sản xuất và chúng ta có thể quản lý đƣợc quá trình làm phần mềm. Có thể nói đó là một nguyên tắc tuyệt đối của kinh tế thị trƣờng. Sản phẩm và ngƣời sản xuất độc lập với nhau. Làm việc tập thể vì không phải là chỉ làm việc năm hay mƣời ngƣời.. Ngƣời ta làm gì trong kĩ nghệ phần mềm? Ngƣời ta có một số phƣơng pháp và những phƣơng pháp đó hiện bây giờ đang trong quá trình chuẩn hoá. Trong khuôn khổ luận văn này, chúng tôi chỉ xin đƣợc đề cập đến mô hình phát triển phần mềm với các quy trình đã đƣợc chuẩn hóa (CMM) chứ không đề cập đến ngôn ngữ chung là UML.
Theo Humphrey [4], những khó khăn thƣờng gặp trong phát triển phần mềm có thể đƣợc chia thành 5 mức, tƣơng ứng với 5 mức đó là 5 mức phát triển của mô hình CMM
3.1. Khó khăn mức Khởi Đầu
Ban đầu các tổ chức có thể có qui trình tuỳ ý, không theo thể thức, và nó thƣờng hỗn độn. Tại giai đoạn này tổ chức thƣờng hoạt động mà không có các thủ tục; các ƣớc tính chi phí và các kế hoạch dự án một cách chính thức. Các công cụ không đƣợc tích hợp tốt với qui trình và cũng không đƣợc áp dụng đồng bộ. Quản lý thay đổi thì lỏng lẻo, và ít có chuyện quản lý cấp cao hiểu đƣợc các bài toán và các vấn đề. Vì nhiều vấn đề bị hoãn lại hoặc thậm chí bị bỏ quên, cài đặt phần mềm và bảo trì thƣờng có nhiều vấn đề nghiêm trọng.
Trong khi các tổ chức có thể có các thủ tục chính thức để lập kế hoạch và theo dõi công việc của họ, lại không có cơ chế quản lý để bảo đảm rằng chúng đã đƣợc sử dụng. Cách kiểm tra tốt nhất là quan sát những tổ chức nhƣ vậy xoay sở thế nào trong một cuộc khủng hoảng. Nếu nó từ bỏ những thủ tục đã đƣợc thiết lập và về bản chất lại trở lại việc viết mã và kiểm thử, tổ chức đó có thể đang gặp những khó khăn ở mức khởi đầu. Sau hết, nếu các kỹ thuật và phƣơng pháp là thích hợp, khi đó chúng sẽ đƣợc dùng trong khủng hoảng; nếu chúng không thích hợp trong khủng hoảng, chúng sẽ không đƣợc dùng một chút nào.
Một lý do mấu chốt tại sao các tổ chức cƣ xử theo cách thức này là họ không trải qua những lợi ích của một qui trình chín chắn và vì vậy không hiểu những hậu quả của các hành xử lộn xộn của họ. Bởi vì nhiều hành động phần mềm hiệu quả (ví dụ thiết kế và soi mã hoặc phân tích dữ liệu kiểm thử) không có vẻ trực tiếp hỗ trợ việc tạo ra sản phẩm, chúng có vẻ nhƣ có thể bỏ đi đƣợc.
Rất giống nhƣ lái một chiếc xe ô tô. Vài ngƣời lái xe không một chút kinh nghiệm sẽ tiếp tục lái rất lâu khi đèn cảnh báo của động cơ sáng, bất kể sự vội vàng của họ. Tƣơng tự, hầu hết các lái xe bắt đầu một chuyến đi mới sẽ, bất kể sự vội vã của họ, dừng lại để xem bản đồ. Họ đã học đƣợc sự khác nhau giữa tốc độ và sự tiến triển.
Trong phần mềm, viết mã và kiểm thử có vẻ nhƣ là sự tiến tới, nhƣng chúng thƣờng chỉ là sự quay tròn của bánh xe. Trong khi chúng phải đƣợc thực hiện, luôn luôn có những nguy hiểm nếu đi sai hƣớng. Nếu không có một kế hoạch tốt và một phân tích kỹ càng các vấn đề, không có cách nào để biết.
Các tổ chức gặp những khó khăn nhƣ vậy có qui trình ở mức khởi đầu trong mô hình CMM.
Các tổ chức ở mức qui trình khởi đầu có thể cải tiến hiệu suất của họ bằng cách tiến hành các kiểm soát dự án cơ bản. Quan trọng nhất là quản trị dự án, giám sát quản lý, bảo đảm chất lƣợng, và kiểm soát các thay đổi.
Vai trò cơ bản của một hệ thống quản lý dự án là bảo đảm kiểm soát có hiệu quả các cam kết. Điều này đòi hỏi sự chuẩn bị thích đáng, trách nhiệm rõ ràng, sự công bố công khai và sự dành riêng (dedication) cho hiệu suất.
Cho phần mềm, quản trị dự án bắt đầu bằng việc hiểu độ lớn của công việc. Trong bất kỳ dự án nào ngoại trừ những cái đơn giản nhất, một kế hoạch phải đƣợc lập để quyết định lịch làm việc tốt nhất và các tài nguyên lƣờng trƣớc cần thiết. Nếu thiếu một kế hoạch thứ tự nhƣ vậy, không có cam kết nào có thể tốt hơn một sự ƣớc chừng đƣợc rèn luyện.
Một tổ chức phát triển phần mềm có kỷ luật phù hợp phải có giám sát quản lý cấp cao. Điều này bao gồm xem xét lại và phê chuẩn tất cả các kế hoạch phát triển chính trƣớc khi cam kết thực hiện chính thức.
Cũng nhƣ vậy, một sự xem lại hàng quý nên đƣợc dẫn dắt bao gồm sự làm đúng theo qui trình trong phạm vi toàn bộ các điều kiện (facility-wide), hiệu suất chất lƣợng đã đƣợc đặt, theo dõi lịch làm việc, các xu hƣớng chi phí, dịch vụ tính toán, và mục tiêu năng suất và chất lƣợng theo dự án. Thiếu những sự xem lại nhƣ vậy thƣờng dẫn đến việc thực thi qui trình không đều và nói chung là không đủ cũng nhƣ là những sự cam kết quá đáng và những sự ngạc nhiên về chi phí cao.
Một nhóm bảo đảm chất lƣợng có trách nhiệm bảo đảm việc quản lý công việc phần mềm đƣợc thực hiện theo cách mà nó đƣợc cho là phải đƣợc thực hiện. Để có hiệu quả, tổ chức bảo đảm phải có một đƣờng (line) báo cáo độc lập tới quản lý cấp cao và các tài nguyên đủ để giám sát hiệu suất của tất cả các hoạt động lập kế hoạch, thực thi và kiểm tra chủ chốt. Nói chung điều này đòi hỏi ở một tổ chức khoảng 3 tới 6 phần trăm cỡ của tổ chức phần mềm
Kiểm soát thay đổi trong phần mềm là thiết yếu để mà kiểm soát được nghiệp vụ và tài chính cũng nhƣ để nhắm tới sự ổn định về mặt kỹ thuật. Để phát triển phần
mềm có chất lƣợng theo một lịch làm việc có thể dự đoán trƣớc, các yêu cầu phải đƣợc củng cố và giữ với độ ổn định hợp lý trong suốt vòng phát triển. Trong khi những thay đổi của các yêu cầu thƣờng cần thiết, các bằng chứng lịch sử chứng minh rằng nhiều cái có thể bị hoãn lại và đƣợc kết hợp lại sau. Những thay đổi về thiết kế và viết mã phải đƣợc thực hiện để sửa những vấn đề phát hiện trong phát triển và kiểm thử, nhƣng những thay đổi này phải đƣợc đƣa vào một cách cẩn thận. Nếu các thay đổi không đƣợc kiểm soát, khi đó theo thứ tự thiết kế, thực thi, và kiểm thử là không thể và không kế hoạch chất lƣợng nào lại có thể hiệu quả đƣợc.
3.2. Khó khăn mức Lặp Lại
Vƣợt qua các khó khăn mức trên, qui trình của tổ chức có một sức mạnh quan trọng mà trƣớc đó nó không có: Nó cung cấp sự kiểm soát toàn bộ cách thức tổ chức