1. Câu hỏi thứ 1: Ai được cấp chứng chỉ CMM ? Đó là SEI - Viện Công Nghệ Phần Mềm và cũng là nơi khai sinh ra CMM đặt tại Canergy Mellon University , USA. Và CMM được khai sinh với tiêu chí : "The right software is delivered defect free, on time and on cost, every time"

2. Câu hỏi thứ 3: CMM là gì ? Là một bộ khung (framework)những chuẩn đề ra cho một tiến trình sản xuất phần mềm hiệu quả, mà nếu như các tổ chức áp dụng nó sẽ mang lại sự khả dụng về mặt chi phí, thời gian biểu, chức năng và chất lượng sản phẩm phần mềm.

3. Cấu trúc của CMM:

CMM bao gồm 5 levels và 18 KPAs(Key Process Area)
5 levels của CMM như sau:
- 1: Initial, 2: Repeatable,3: Defined,4: Managed, 5: Optimising
Level 1 thì không có KPAs nào cả
Level 2 : có 6 KPAs
Level 3: có 7 KPAs
Level 4: có 2 KPAs
Level 5: có 3 KPAs

18 KPAs của CMM được đều có 5 thuộc tính(chức năng) chung trong đó có các qui định về key pratice là những hướng dẫn về các thủ tục(procedure), qui tắc(polities), và hoạt động (activites)của từng KPA.
Đầu tiên ta có cấu trúc của một KPA với 5 (common feature) như sau:
                                        -------
                                  KPA Goals
                                -------------------
                                            ||
                                            ||
1              2        3                  4                      5

Trong đó để thực hiện KPA này ta cần phải thực hiện theo những qui tắc sau để bảo đảm đạt được KPA đó:

(1) Commitment to Perform
(2) Ability to Perform
(3) Activities Peformed
(4) Measurement and Analysis
(5) Verifiying and Implementation

Tiếp đến ta có cấu trúc CMM như sau:

Maturity Level
                        KPAs
                                Common Features
                                                                      Key Practices

Diễn dịch: Một maturity level chứa nhiều KPAs, các KPAs  được gom chung thành những đặc tính chung, các common feature chứa các key pratices để các tổ chức có follow theo mà áp dụng.

Tôi sẽ phải nói ngắn gọn thôi không thì sẽ các bạn tẩu hoả mất :o), chi tiết về CMM các bạn có thể download các tài liệu tại trang web www.sei.cmu.edu của SEI

Ta đi vào một ví dụ:
Level 2 có 6 KPA
- Requirement Management
- Software Project Planning
- Software Project Tracking
- Software SubContract Managent
- Software Quality Assurance
- Software Configuration Management
Khi ta áp dụng Level 2, KPA 2(Software Project Planning), ta sẽ có những common feature như sau:

[b]Mục tiêu(Goal)[/b]: các hoạt động và những đề xuất của một dự án phần mềm  phải được lên kế hoạch và viết tài liệu đầy đủ

[b]Đề xuất/ Xem xét (Commitment[/b]): dự án phải tuân thủ theo các qui tắc của tổ chức khi hoạch định

[b]Khả năng(Ability): [/b] Việc thực hiện lập kế hoạch cho dự án phần mềm phải là bước thực hiện từ rất sớm khi dự án đưọc bắt đầu

[b]Đo lường(Measument): [/b] Sự đo lường luôn được thực thi và sử dụng chúng ta luôn có thể xác định và kiểm soát được tình trạng các hoạt động trong tiến trình thực hiện dự án

[b]Kiểm chứng(Verification[/b]): Các hoạt động khi lập kế hoạch dự án phải được sự reviewed của cấp senior manager

Câu hỏi được đặt ra ở đây là vậy thì vai trò của QA sẽ như thế nào trong việc thực hiện project plan, tôi không đề cập đến vai trò Project Manager vì anh ta phải biết về các nguyên tắc về estimates project theo Function Point, Line of Code v.v...

Nói đến software quality, ắt hẳn các bạn QA không thể không biết đến tam giác quỉ "Quality Triangle" (Cost,Functionality,Schedule) => đúng chức năng , đúng chi phí, và đúng thời hạn. Đẻ ra cái gọi là chất lượng phần mềm, thì phải có người review và kiểm chứng nó. Chúng tôi đặt ra các tiêu chuẩn của qui trình mà từ đó chúng tôi sản xuất được phần mềm tốt nhất, chúng tôi thực hiện và chúng tôi có những ngưòi kiểm chứng và theo sát các hoạt động của nhóm thực hiện project sao cho đúng qui trình. Vâng đó là QA Engineer, lâu nay vai trò của người QA trong các công ty phần mềm bị đồng hoá với vai trò của một tester hay còn gọi là QC - Quality Control.

Trong quá trình lập kế hoạch dự án, QA có vai trò như sau review project plan (nhưng không modified), nếu có sai sót hoặc vấn đề gì sẽ do Project Manager chỉnh sửa,  tham gia các giải pháp "dụ khị" khách hàng(chọn lựa các giải pháp khiến khách hàng cảm thấy hài lòng), cung cấp những tư vấn về chất lượng, chia xẻ những kinh nghiệm rút ra đưộc từ các project đã thực hiện để thực hiện các project sau càng tốt hơn.

Xin chào

Khi đọc các tài liệu về Agile Method và XP, tôi thấy sự tập trung chủ yếu vào khâu coding (đã bao gồm test). Vậy liệu CMM có được áp dụng xuyên các SE Process hay Method không ?

Bài trước, bạn đã cho rằng theo CMM level 2 thì có từ 30 - 50 người, vậy nếu theo CMM level 2 thì thường cần ít nhất là bao nhiều thời gian cho một project ?

Cảm ơn

Xin chào

Khi đọc các tài liệu về Agile Method và XP, tôi thấy sự tập trung chủ yếu vào khâu coding (đã bao gồm test). Vậy liệu CMM có được áp dụng xuyên các SE Process hay Method không ?

Bài trước, bạn đã cho rằng theo CMM level 2 thì có từ 30 - 50 người, vậy nếu theo CMM level 2 thì thường cần ít nhất là bao nhiều thời gian cho một project ?

Agile Method hay XP chỉ là những Software Developement method như Rational Unified Process, CMM là một framework bao gồm các tiêu chuẩn đánh giá giúp cho công ty bạn đã đang áp dụng 1 trong những method này một cách tốt hơn.

CMM level 2 không đưa ra method hay công cụ để giúp PM estimate thời gian dự án mà CMM chỉ đưa ra những KPAs trong quá trình Software Project Planning để bảo đảm rằng quá trình này được thực hiện một cách đầy đủ nhất và tốt nhất.

Như vậy không thể nói rằng ở CMM level2 thì cần bao nhiêu thời gian cho 1 project mà phải nói lại như sau: Ở CMM level 2 , KPA 2: Software Project Planning, Activity 9: CMM đưa ra rằng: Estimates for the size of software work product for changes to the size of software work product) are derived according to a documented procedure
The procedure typically specifies that: Size estimates are made for all major software work products and activities. Example of software size mesurement include:
- function points, feature point, line of code, number of requirements...
.....
về estimate theo function point của PM chẳng hạn, là PM là đương nhiên phải biết rồi :o)


Thân ái

xin hỏi ngoài lề một tí nha. huonghl có phải còn có biệt danh là kooz không vậy, ???, nói thật đọc bài của bạn thấy hay lắm, nhiều khi đọc tài liệu tiếng anh nhiều không bằng vào mấy cái forum để xem mấy bài viết ngắn, nhưng được đúc kết từ kinh nghiệm thực ra, và hơn nữa viết bằng tiếng việt nên dễ hiểu hơn.

Thấy mọi người cứ muốn đọc tại liệu CMM bằng tiếng Việt nên mạo muội post lên bài viết sau : (xin nói trước nội dung bài viết là có tham khảo thêm chứ không hoàn toàn tự viết ra)

Mô hình CMM (Capability Maturity Model)
Mô hình CMM cho phần mềm được đưa ra bởi Viện Kỹ nghệ Phần mềm (Software Engineering Institute - SEI) của Đại học tổng hợp Carnegie Mellon, đã được hỗ trợ quốc tế rộng rãi và là một chương trình tài trợ không hoàn lại, công khai cho bất kỳ công ty nào muốn tiếp nhận nó. Mô hình CMM mô tả các nguyên tắc và các thực tiễn nằm bên trong tính “thành thục ” quá trình phần mềm và chủ ý giúp đỡ các công ty phần mềm hoàn thiện khả năng thuần thục quá trình sản xuất phần mềm, đi từ tự phát, hỗn độn tới các quá trình phần mềm thành thục, có kỷ luật.
Bằng việc thưc hiện CMM các công ty thu được những lợi ích xác thực, giảm được rủi ro trong phát triển phần mềm và tăng được tính khả báo - do đó trở thành đối tác hay một nhà cung ứng hấp dẫn hơn đối với các khách hàng trên toàn thế giới. Tuy nhiên, CMM không phải không đòi hỏi chi phí. Những nguồn lực đáng kể của công ty phải được dành cho việc hướng tới các vùng tiến trình then chốt, cần thiết để lên từng bậc thang của chứng nhận CMM. CMM đưa ra một loạt các mức độ để biểu thị mức độ thành thục đã đạt được. Mức 1 ứng với mức độ thành thục thấp nhất và mức 5 ứng với mức độ thành thục cao nhất. Gần đây, SEI đã xúc tiến CMMi, một mô hình kế thừa CMM và các công ty cũng đang bắt đầu triển khai việc sử dụng mô hình này.


Giải thích thêm về CMM
Ngoại trừ mức 1, mỗi mức độ thành thục được phân tích thành các vùng tiến trình chủ chốt, biểu thị những khu vực mà một tổ chức nên tập trung vào để cải thiện tiến trình phần mềm của nó.
Những vùng tiến trình chủ chốt ở mức 2 tập trung vào những vấn đề của dự án phần mềm liên quan tới thiết lập kiểm soát cơ bản cho quản trị dự án. Đó là Quản trị yêu cầu (Requirements Management), Hoạch định Dự án phần mềm (Software Project Planning), Giám sát và theo dõi

dự án phần mềm (Software Project Tracking and Oversight), Quản trị hợp đồng phụ phần mềm (Software Quality Assurance), Bảo đảm chất lượng phần mềm (Software Quality Assurance), và Quản trị cấu hình phần mềm (Software Configuration Management).
Các vùng tiến trình chủ chốt ở mức 3 nhằm vào cả hai vấn đề về dự án và tổ chức, vì một tổ chức (công ty) tạo nên cấu trúc hạ tầng thể chế các quá trình quản lý và sản xuất phần mềm hiệu quả qua tất cả các dự án. Chúng gồm có Tập trung Tiến trình Tổ chức (Organization Process Focus), Phân định Tiến trình Tổ chức (Organization Process Definition), Chương trình Đào tạo (Training Program), Quản trị Phần mềm Tích hợp (Integrated Software Management), Sản xuất Sản phẩm Phần mềm (Software Product Engineering), Phối hợp nhóm (Intergroup Coordination), và Xét duyệt ngang hàng (Peer Reviews).
Các vùng tiến trình chủ yếu ở mức 4 tập trung vào thiết lập hiểu biết định lượng của cả quá trình sản xuất phần mềm và các sản phẩm phần mềm đang được xây dựng. Đó là Quản lý quá trình định lượng (Quantitative Process Management) và Quản lý chất lượng phần mềm (Software Quality Management)
Các vùng tiến trình chủ yếu ở mức 5 bao trùm các vấn mà cả tổ chức và dự án phải nhắm tới để thực hiện hoàn thiện quá trình sản xuất phần mềm liên tục, đo đếm được. Đó là Phòng ngừa lỗi (Defect Prevention), Quản trị thay đổi công nghệ (Technology Change Management), và Quản trị thay đổi quá trình (Process Change Management)
Mỗi vùng tiến trình chủ yếu được mô tả như các thực hành cốt yếu thỏa mãn các mục tiêu của nó. Các thực hành cốt yếu đó mô tả hạ tầng và các hoạt động có đóng góp chính cho việc thực hiện và thể chế hoá vùng tiến trình chủ yếu một cách hiệu quả.

Các đặc điểm của 5 mức thành thục CMM:
1/ Khởi đầu (Initial). Quá trình sản xuất phần mềm được đặc trưng tự phát, và có lúc thậm chí là hỗn độn. Một số quá trình đã được xác lập, và sự thành công phụ thuộc vào nỗ lực và anh hùng cá nhân
2/ Lặp lại (Repeatable). Các quá trình quản lý dự án cơ bản được thiết lập để theo dõi chi phí, thời gian biểu và chức năng. Đã có quy tắc tiến trình cần thiết để lặp lại các thành công trước đây của các dự án có ứng dụng tương tự.
3/ Xác lập (Defined). Quá trình sản xuất phần mềm cho cả hoạt động quản lý và kỹ thuật được văn bản hóa, được chuẩn hóa và được hòa nhập vào quá trình sản xuất phần mềm chuẩn đối với tổ chức. Tất cả các dự án sử dụng một phiên bản “may đo” được phê chuẩn của tiêu chuẩn xí nghiệp cho quá trình sản xuất phần mềm để phát triển và bảo trì phần mềm.
4/ Quản trị (Managed). Các biện pháp chi tiết của của quá trình sản xuất phần mềm và chất lượng sản phẩm được thu thập lại. Cả quá trình sản xuất phần mềm và các sản phẩm đều được hiểu và được kiểm tra một cách định lượng. 

5/ Tối ưu hóa (Optimizing). Cải tiến không ngừng quá trình sản xuất qua phản hồi có định lượng từ quá trình sản xuất và từ thử nghiệm các ý tưởng và công nghệ mới.

Khá lắm, mời bạn tiếp tục đưa ra những ý kiến khác về CMM. CÔng ty bạn đã làm CMM chưa, bạn đã trực tiếp tham gia vào xây dụng CMM chưa, hay là những cái này bạn chỉ đọc trên lý thuyết thôi :o)

cảm ơn bạn đã khen nhưng thật tình những kiến thức trên là mình thu thập được từ những kiến thức đã nghiên cứu thôi.
Công ty mình đã làm CMM, công ty của nước ngoài, và mình cũng đang ở nước ngoài. Mục tiêu chính của mình là cố gắng nghiên cứu về CMM, hiểu nó,  để có thể "lọt vào mắt xanh của xếp", rồi có thể được chọn vào ban dự án phát triển thành CMM5 của công ty. Nhưng dù sao cũng chỉ hy vọng thôi, bên đây, một nhân viên nước ngoài muốn được trọng dụng cũng khó lắm.

Như đã nói ở bài viết, tạm dịch Key Process Areas là tiến trình khung, và đã dịch ra tiếng Việt tên của các KPAs này, thế nhưng để hiểu rõ nó thật sự ứng dụng trong thật tế thì mình không nắm chắc, rất mong bạn chỉ bảo thêm ...,
tài liệu của công ty thì rất nhiều, toàn tiếng Nhật không, đọc để hiểu nó nói gì thôi cũng chảy mồ hôi hột rồi. :->, mình khoái đọc những tài liệu tiếng việt hoặc tiếng Anh hơn...
À quên hình như bạn chưa trả lời câu hỏi đầu tiên của mình thì phải, bạn có phải là kooz không, tui là tui nễ anh kooz này lắm đấy...

bạn nói là công ty bạn làm CMM rồi, vậy thì họ áp dụng CMM như thế nào có đúng theo những KPA mà CMM đề ra không vậy, và công ty bạn lại là một công ty Nhật và việc họ áp dụng CMM là một điều rất tiến bộ, thường thì tôi thấy họ dùng TQM khá nhiều. Tôi rất muốn biết công ty Nhật họ áp dụng CMM như thết nào ?

À, bạn làm công ty nào vậy, tôi cũng vừa ở Nhật về được vài tháng rồi. Hiện nay về làm vài dự án ở đây rồi sẽ lại sang Nhật.

bạn nói là công ty bạn làm CMM rồi, vậy thì họ áp dụng CMM như thế nào có đúng theo những KPA mà CMM đề ra không vậy

Tmình nghĩ đối chứng với các tài liệu lưu lại mà họ đưa cho mình tham khảo thì nhìn chung là áp dụng khá chuẩn với những KPAs đã đề ra , nhưng tất nhiên sẽ áp dụng linh hoạt hơn. Người Nhật nổi tiếng với các món chế biến mà :-).

, và công ty bạn lại là một công ty Nhật và việc họ áp dụng CMM là một điều rất tiến bộ, thường thì tôi thấy họ dùng TQM khá nhiều. Tôi rất muốn biết công ty Nhật họ áp dụng CMM như thết nào ?

Đúng là công ty tui trước đây dùng TQM, nhưng mới đổi qua CMM gần đây, tuy chỉ ở mức level 3 thôi.(theo tôi nghĩ thế là hay lắm rồi vì khi mới áp dụng CMM mà đạt chuẩn ấy ngay cũng không phải dễ dàng gì)
Còn chi tiết cụ thể họ áp dụng như thế nào tôi thực sự cũng rất muốn biết đây, vì thế mà mới tích cực nghiên cứu để ráng vào đội dành cho dự án CMM nè.( Chắc cũng chua lắm.!!!) lúc đó khi làm thực tế thì mới thấy họ áp dụng như thế nào.

À, bạn làm công ty nào vậy, tôi cũng vừa ở Nhật về được vài tháng rồi. Hiện nay về làm vài dự án ở đây rồi sẽ lại sang Nhật

Tôi làm ở công ty RS công ty cũng không phải lớn lắm nên tôi đoán chắc bạn cũng chưa nghe qua,mà tôi cũng chỉ là nhân viên mới (一年名)  mà thôi. Bạn vừa từ Nhật về à, thế bạn làm cho công ty nào vậy, kinh nghiệm chắc nhiều lắm rồi phải không??. Bạn sắp qua lại Nhật còn tôi thì lại sắp về đây. Tương lai có qua lại không thì cũng chưa rõ nữa....

Em hỏi chút nhé:
Đầu tiên ta có cấu trúc của một KPA với 5 (common feature) như sau:
-------
KPA Goals
-------------------
||
||
1 2 3 4 5
? Sao ko thấy anh chị giải thích j về cấu trúc của chúng cả.Nó có các kí hiệu lạ lạ. Chúng ta thừa nhận chúng như thế chứ ah? Có thể giải thích giúp em ko? em đang rất cần.Em xin chân thành cảm ơn!

Có ai có thể cho mình 1 ví dụ về việc chuẩn hoá theo CMM không? về mặt lý thuyết thì hiểu là chuẩn hoá dần theo các mức nhưng có ai cho 1 ví dụ đi, nhỏ nhỏ thôi cũng được