Tiểu luận môn kinh tế công nghệ phần mềm định nghĩa các khái niệm trong slide sorting out software advice

MỤC LỤC
1.
TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG
BÀI TẬP TUẦN 1
Kinh tế công nghệ phần mềm
Nhóm sinh viên thực hiện:
Trần Văn Bích
20080215
Nguyễn Chí Công
20080316
Nguyễn Khắc Hưng
20081281
Nguyễn Lan Anh
Lê Thị Thuỳ Linh
20080063
20086100
Giảng viên hướng dẫn: Huỳnh Quyết Thắng
Đề bài:
I Định nghĩa các khái niệm trong slide "sorting out software advice".
II.Tìm hiều các khái niệm liên quan đến CMM, CMM-I , vai trò trong tổ chức công ty
doanh nghiệp phần mềm.
MỤC LỤC
2.
I. Định nghĩa các khái niệm
1. Independent test team:một đội thực thi hệ thống và đưa ra kết quả kiểm tra một
cách độc lập với đội phát triển hệ thống hoặc ứng dụng. Đội thử nghiệm độc lập
này không bao gồm bất kỳ một thành viên nào của đội phát triển hệ thống
2. Chief programmer team: đội lập trình chính : Một đội lập trình mà trách nhiệm
thiết kế chương trình và thực hiện dựa hoàn toàn vào các thành viên có kỹ năng
cao nhất – những lập trình viên chính. Những thành viên khác trong đội sẽ hỗ trợ

những công việc khách nhau. Một đội điển hình bao gồm lập trình viên chính, lập
trình viên dự phòng, người viết tài liệu, người quản trị , thư ký… Lập trình viên
dự phòng hỗ trợ cho các lập trình viên chính và có thể đảm nhiệm vai trò thay thế
lập trình viên chính nếu cần thiết. Người viết tài liệu duy trì tất cả các tài liệu kỹ
thuật về dự án như tài liệu thiết kế, module nguồn và lịch sử kiểm thử. Người
quản trị làm nhiệm vụ quản lý hành chính về dự án. Các dịch vụ khác có thể cung
cấp từ các đội bên ngoài nếu cần thiết. Việc tổ chức đội lập trình như thế này có
thể sản xuất chương trình một cách nhanh chóng và đáng tin cậy hơn so với một
đội ngũ lập trình viên có kỹ năng ngang hàng nhau.
3. Do it top – down : Phương pháp phân tích từ trên xuống. Theo phương pháp này,
người thiết kế hệ thống chia các chức năng (hàm) chính của hệ thống thành các
chức năng nhỏ hơn, đến lượt mình, các chức năng nhỏ này lại được chia tiếp
thành các chức năng nhỏ hơn nữa cho đến khi được các khối (hàm) chương trình
đủ nhỏ. Việc phân tích này được thể hiện trực quan theo sơ đồ khối.
4. Automated aids
5. Early requirements baseline : Requirement baseline: đưa ra những định nghĩa rõ
ràng về những chức năng , những yêu cầu mà dự án cần thực thi.
Việc xác định những yêu cầu cơ sở sớm có thể thúc đẩy quá trình kiểm soát thay
đổi nhanh hơn. Chờ đợi quá lâu để thiết lập một requirement baseline có thể là
một dấu hiệu của tình trạng tê liệt phân tích. Có lẽ các nhà phân tích đang cố gắng
quá khó khăn để hoàn thiện bộ các yêu cầu trước khi bàn giao cho họ để đội ngũ
phát triển để thực hiện.
6. Design verification: Thẩm tra thiết kế là bước thiết yếu trong bất kỳ sản phẩm
được phát triển nào. Đây là bước kiểm tra chất lượng nhằm xác định xem tất cả
các kết quả đầu ra có đáp ứng được các thiết kế đầu vào hay không, có đáp ứng
được mong đợi của khách hàng hay không?
7. Project work authorizations: Ủy quyền công việc dự án là một phương pháp
làm việc được sử dụng kết hợp với quản lý dự án. Việc ủy quyền công việc của dự
án được người quản lý dự án giao cho cấp dưới để phê duyệt tất cả các công việc
dự án trong suốt quá trình dự án thực thi.

8. Unit development folders: (UDF)
công cụ chính để theo dõi tiến độ trong quá trình phát triển phần mềm và các hoạt
động thử nghiệm. Tất cả các UDFs được điều khiển bởi một kỹ sư dự án, kỹ sư
dự án chịu trách nhiệm để đảm bảo rằng các định dạng yêu cầu của UDF được
duy trì và cho phép đánh giá đầy đủ về tình trạng đơn vị được thực hiện.
Mục đích: Cung cấp cách tiếp cận có trật tự và nhất quán trong việc phát triển mỗi
đơn vị của chương trình, dự án. Cung cấp khả năng hiển thị quản lý cấp thấp và
kiểm sota quá trình phát triển. Người quản lý có thể dễ dàng truy nhập kiểm tra
trạng thái của từng đơn vị.
1 UDF có thể chứa các thành phần:
• Phần mở đầu (Introduction)
• Các yêu cầu (requirement)
• Giao diện bên trong (External Interfaces)
• Mô tả thiết kế (Design Description)
• Mã nguồn
• Kế hoạch kiểm thử đơn vị (Unit Test Plan)
• Kết quả kiểm thử (Test Results)
• Báo cáo vấn đề (Problems Reports)
• Ghi chú (Notes)
9. Structured programing : Lập trình cấu trúc là một tập con của lập trình thủ tục.
Trong một chương trình máy tính, các khối chức năng có thể được thực hiện
không chỉ theo trình tự mà còn có thể theo các tình huống và lặp lại nhiều lần.
Phương pháp lập trình cấu trúc được dựa trên các mô hình toán học của Bohm và
Guiseppe, theo đó, một chương trình máy tính có thể được viết dựa trên ba cấu
trúc: trình tự, quyết định và vòng lặp.Trình tự nghĩa là các câu lệnh được thực
hiện theo trình tự nhất định: trên xuống.Quyết định là sự qui định sẽ thực hiện
chương trình như thế nào phụ thuộc vào sự thoả mãn các điều kiện nhất
định.Vòng lặp thể hiện sự thực hiện có tính lặp một số đoạn lệnh của chương trình
khi các điều kiện nào đó vẫn được thỏa mãn.Thông qua các cấu trúc trên, mã
chương trình trở nên sáng sủa và dễ đọc.

Lập trình có cấu trúc dựa trên lý thuyết cho rằng mô-đun hóa làm cho chương
trình tốt hơn. Chia các thành phần, chức năng chương trình thành các module.
Điều này làm cho nó dễ dàng hơn để viết, gỡ lỗi, và hiểu về chương trình.
10. Prove everything correct : Chứng minh tất cả mọi thứ đều chính xác. Kiểm tra
tất cả thiết kế, mã nguồn, lên kế hoạch kiểm thử nhằm mục đích hạn chế tối đa lỗi
có thể xảy ra, đảm bảo chương trình đáp ứng đúng yêu cầu của khách hàng.
11. Thorough test planning: Lên kế hoạch kiểm thử một cách triệt để.
Một kế hoạch thử nghiệm là một tài liệu chi tiết thi hành một cách tiếp cận có hệ
thống để thử nghiệm một hệ thống như một máy tính hoặc phần mềm. Kế hoạch
này thường chứa một sự hiểu biết chi tiết về các công việc cuối cùng sẽ được.
Một kế hoạch kiểm tra tài liệu chiến lược sẽ được sử dụng để xác minh và đảm
bảo rằng một sản phẩm hay hệ thống đáp ứng các thông số kỹ thuật thiết kế và các
yêu cầu khác. Một kế hoạch thử nghiệm thường được chuẩn bị với các đầu vào
quan trọng từ các kỹ sư thử nghiệm.
Tùy thuộc vào sản phẩm và trách nhiệm của các tổ chức để có kế hoạch thử
nghiệm áp dụng.
12. Built it twice : Nếu bạn muốn xây dựng một Project, muốn Project đó thành công
hãy làm một cách thật kỹ càng. Đứng ở hai góc độ để xem xét lập dự án: góc độ
đạt tới thành công nhất và góc độ Project thất bại cao nhất để lường trước mọi
nguy hại để phòng tránh.
13. Use disciplined of reviews: Xây dựng dự án phải lường trước được sai xót, đưa
ra được những sai sót có thể mắc phải.
14. Do it out-side in:
15. Progamming standards: Khi lập trình chúng ta phải đưa ra một tiêu chuẩn cụ
thể, xuyên suốt thời gian xây dựng dự án. Một dự án mà thay đổi tiêu liên tục sẽ
khó thành công, nhưng cũng nên thay đổi tiêu chuẩn sao cho phù hợp với yêu cầu
người dùng, yêu cầu thị trường, yêu cầu xã hội, và phù hợp với công nghệ.
16. Measurable milestores: Lường trước được những sự kiện quan trọng như yêu
cầu của khách hàng thay đổi, công nghệ thay đổi, hay mọi ảnh hưởng từ bên ngoài
và bên trong khi xây dựng phần mềm nhằm đảm bảo thành công và đạt được lợi

ích.
17. Program library: Tạo một thư viện phần mềm để khi xây dựng một dự án mới
nên tận dụng tối đa những chương trình có sẵn.
18. Involve the user: Xác định tất cả cộng đồng người sử dụng để có thể và xác định
những lợi ích của họ.
Dành thời gian chất lượng với những người dùng của bạn. Hãy chắc chắn
rằng bạn biết những gì họ làm cho một cuộc sống và cách họ làm điều đó, thủ tục
kinh doanh không chính thức thường không có tài liệu nhưng được tuân thủ chặt
chẽ các quy trình tài liệu.
Hút sự tham gia của cộng đồng người sử dụng của bạn sớm và thường
xuyên. Sử dụng tạo mẫu nhanh, lặp đi lặp lại phân phôi, xoắn ốc phát triển bất cứ
điều gì từ thông dụng mà bạn muốn áp dụng. Sớm tham gia bởi người sử dụng
thường sẽ dẫn đến "sở hữu chung" ý tưởng rằng người đó "sở hữu" một phần của
hệ thống. Điều quan trọng là niềm tự hào của quyền sở hữu mở rộng cộng đồng
người sử dụng.
Đấu tranh cho ý kiến phản hồi có ý nghĩa. Một số người sử dụng có thể
được nhiều hơn sẵn sàng để được dẫn đến một kết luận đó là không nhất thiết phải
của riêng mình.
Hiện đang có là thời gian khi người sử dụng khác nhau của bạn có ý kiến
khác nhau, và bạn sẽ không thể hòa giải chúng. Xem xét việc hình thành nhóm
một người sử dụng tự quản để giải quyết sự khác biệt khó chữa, nó giúp bạn ra.
19. Configuration management: Quản lý cấu hình (CM) là một lĩnh vực quản lý tập
trung vào việc thiết lập và duy trì tính thống nhất của một hệ thống hoặc hiệu suất
của sản phẩm và các thuộc tính chức năng và vật lý của nó với yêu cầu, thiết kế
của nó, và thông tin hoạt động trong suốt cuộc đời của nó.
Để đảm bảo thông tin , CM có thể được định nghĩa là việc quản lý các tính
năng bảo mật và đảm bảo thông qua kiểm soát các thay đổi được thực hiện để tài
liệu hướng dẫn phần cứng, phần mềm, phần mềm, tài liệu hướng dẫn, kiểm tra, đồ
đạc kiểm tra, kiểm tra, trong suốt vòng đời của một hệ thống thông tin.
[2]

CM cho
đảm bảo thông tin, đôi khi được gọi là S ecureC anagement M onfiguration, dựa
vào hiệu suất, các thuộc tính chức năng và vật lý của nền tảng và các sản phẩm và
môi trường của họ để xác định các tính năng bảo mật thích hợp và đảm bảo được
sử dụng để đo lường một cấu hình hệ thống nhà nước .
20. End – item acceptance plan: dự án được chấp nhận khi đã rà soát từ đầu đến
cuối. Dự án chỉ được chấp nhận khi tất cả các mục được chấp nhận.
21. Automated aids: Khi xây dựng dự án cần tận dụng các công cụ hỗ trợ tự động.
22. Use walk through: Là một hình thức phản biện chuyên gia phần mềm trong đó
một nhà thiết kế hay lập trình dẫn các thành viên của nhóm phát triển và các bên
liên quan thông qua một sản phẩm phần mềm và các bên liên quan đặt câu hỏi và
đưa ra nhận xét về các lỗi có thể vi phạm các tiêu chuẩn phát triển và các vấn đề
khác.
II. Các khái niệm liên quan đến CMM/CMMI, vai trò của chúng trong
tổ chức công ty doanh nghiệp phần mềm
A. Tìm hiểu về CMM và CMMI.
1. Các khái niệm về CMM (CMM - Capability Maturity Model : Mô
hình thuần thục khả năng).
a. CMM là gì?
CMM là chuẩn quản lý quy trình chất lượng của các sảnphẩm phần mềm được áp dụng
cho từng loại hình công ty khác nhau. Hay nói cách khác đây là các phương pháp phát
triển hay sản xuất ra các sản phẩm phầm mềm.
b. Lịch sử phát triển
CMM là kết quả của một nghiên cứu được không quân Mỹ tài trợ, nghiên cứu này
được coi là một phương pháp đánh giá khách quan công việc của các nhà thầu phụ về
phần mềm. Bộ Quốc Phòng Mỹ cũng quan tâm tới việc chi phí phát triển phần mềm đang
leo thang và các vấn đề liên quan đến chất lượng của các phần mềm nên đã thành lập
viện SEI vào đầu những năm 80, và bắt đầu nghiên cứu mô hình CMM vào năm 1988.
Ban đầu, mô hình CMM được sử dụng như một công cụ để đánh giá khả năng của
các nhà thầu chính phủ khi họ tiến hành một dự án phần mềm theo hợp đồng. Mặc dù

CMM được thiết kế để đánh giá quá trình phát triển phần mềm nhưng nó đã và đang
được áp dụng như một mô hình chung cho kỳ hạn của các quá trình trong các công ty về
CNTT hay bất cứ công ty nào khác.
Các nhà phê bình cũng nhận thấy CMM luôn được gắn chặt trong một mô hinh
phát triển thác nước và không quan tâm tới các khía cạnh khác của quy trình phát triển
phẩn mềm như thiết kế và triển khai. CMM không phù hợp với các quy trình ngoại vi liên
quan đến việc phát triển phần mềm như là việc mua lại. CMM cũng bị phê phán là tạo ra
quá nhiều giấy tờ sổ sách và quá nhiều cuộc họp và nó cũng không phù hợp với nhiều
ngành công nghiệp.
Các ngành công nghiệp và chính phủ đã tìm ra giải pháp cho vấn đề này bằng
cách áp dụng CMM cho các lĩnh vực khác. Toàn bộ quy trình sẽ được giám sát bởi một
ban lãnh đạo bao gồm những người đại diện từ OSD, Không quân, Quân đội, Hải quân,
các bộ phận khác của chính phủ, SEI và ngành công nghiệp. Nhiệm vụ của ban lãnh đạo
này là hướng dẫn và giám sát quá trình phát triển dòng sản phẩm CMMI, đưa ra các sản
phẩm CMMI để thẩm tra và phát hành ra công chúng. Viện SEI phối hợp với các chuyên
gia đề tài phụ trách quản lý dự án ban đầu là phát triển phần mềm, xây dựng hệ thống,
phát triển quy trình và sản phẩm tích hợp. Các cổ đông/ các nhà phê bình đều có quyền
kiểm tra, phê bình và đưa ra những gợi ý để phát triển các sản phẩm CMMI. Trong số
những người này cũng có những đại diện từ ngành công nghiệp, chính phủ và viện SEI.
c. Tại sao phải sử dụng CMM trong công nghệ phần mềm.
• Một số khó khăn khi không sử dụng CMM:
- Các tiến trình phần mềm thường bị thay đổi cập nhật mà không có sự chuẩn bị
trước. Đặc tả một tiến trình phần mềm không chặt chẽ, dẫn đến sự khủng
hoảng khi thực hiện một dự án.
- Thiếu cơ sở để đánh giá chất lượng phần mềm, để đưa ra phương thức tiến
hành và cách giải quyết các vấn đề phát sinh.
• Một số thuận lợi khi sử dụng CMM:
- Dễ dàng quản lý phát triển phần mềm. Các tiến trình được cập nhật qua sự
điều khiển của các nhà phân tích kiểm thử.
- Vai trò, trách nhiệm cảu mỗi thành viên trong các tiến trình được phân tích rõ

ràng.
- Quản lý chất lượng của phần mềm, thỏa mãn các yêu cầu khách hang. Có cơ
sở chuẩn xác đánh giá chất lượng, thời gian, chi phí và phân tích dự an và các
tiến trình.
d.Các khái niệm cơ bản trong CMM.
 Tiến trình (Process).
Một tiến trình phần mềm là một tập hợp các hành động, phương thức, thực
hành, thay đổi mà người ta dùng để duy trì và phát triển phần mềm cũng như các
thành phần liên quan tới chúng.
 Khả năng tiến trình phần mềm.
Đây là khái niệm cho biết phạm vi kết quả có thể mong đợi của một tiến trình
phần mềm. Đồng thời nó còn dự đoán khả năng làm dự án phần mềm tiếp theo
của công ty.
 Thực thi tiến trình phần mềm (Software Process Performance).
Thực thi tiến trình phần mềm cho biết kết quả thực tế của một tiến trình phần
mềm. Như vậy nó hướng tới kết quả đạt được còn khả năng tiến trình phần mềm
cho thấy kết quả có thể mong đợi. Do phụ thuộc và đặc trưng của dự án và từng
trường hợp cụ thể, nên kết quả thực tế thường không phản ánh đầy đủ khả năng
tiến trình của một công ty.
 Thuần thục tiến trình phần mềm(Softwareprocess maturity ).
Chỉ rõ một tiến trình phần mềm được xác định, quản lý, đánh giá, điều khiển,
chỉ ra giá trị của tiến trình phần mềm, tính vững chắc của dự án.
e.Cấu trúc của CMM
Các level 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
Nói cách khác mỗi một level đều tuân theo một chuẩn ở mức độ cao hơn. Muốn đạt được
chuẩn cao hơn thì các chuẩn của các level trước phải thoả mãn. Mỗi level đều có đặc
điểm chú ý quan trọng của nó cần các doanh nghiệp phải đáp ứng được.

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 điểm đặc trưng(common feature).
Mô hình này xác định năm cấp độ của CMM đối với một công ty : Khởi đầu (lộn xộn,
không theo chuẩn) - Lặp (quản lý dự án, tuân thủ quy trình) - Xác lập (thể chế hóa) -
Kiểm soát (định lượng) - Tối ưu (cải tiến quy trình).
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 ( Tạm dịch là cam kết thực hiện)
(2) Ability to Perform (Khẳ năng thực hiện)
(3) Activities Peformed (Các hoạt động lâu dài)
(4) Measurement and Analysis (Khuân khổ và phân tích)
(5) Verifiying and Implementation
Level 1
Level 1 là bước khởi đầu của CMM, mọi doanh nghiệp, công ty phần mềm, cá
nhóm, cá nhân đều có thể đạt được. Ở lever này CMM chưa yêu cầu bất kỳ tính năng nào.
Ví dụ: không yêu cầu quy trình, không yêu cầu con người, miễn là cá nhân, nhóm, doanh
nghiệp… đều làm về phầm mềm đều có thể đạt tới CMM này.
Đặc điểm của mức 1:
Hành chính: Các hoạt động của lực lượng lao động được quan tâm hàng đầu
nhưng được thực hiện một cách vỗi vã hấp tấp.
Không thống nhất: Đào tạo quản lý nhân lực nhỏ lẻ chủ yếu dựa vào kinh nghiệp
cá nhân.
Quy trách nhiệm: Người quản lý mong bộ phận nhân sự điều hành và kiểm sóat

các hoạt động của lực lượng lao động.
Quan liêu: Các hoạt động của lực lượng lao động được đáp ứng ngay mà không
cần phân tích ảnh hưởng.
Doanh số thường xuyên thay đổi: Nhân viên không trung thành với tổ chức.
Level 2
Có 6 KPA nó bao gồm như sau:
- Requirement Management (Lấy yêu cầu khách hàng, quản lý các yêu cầu đó)
- Software Project Planning (Lập các kế hoạch cho dự án)
- Software Project Tracking (Theo dõi kiểm tra tiến độ dự án)
- Software SubContract Managent (Quản trị hợp đồng phụ phần mềm)
- Software Quality Assurance(Đảm bảo chất lượng sản phẩm)
- Software Configuration Management(Quản trị cấu hình sản phẩm=> đúng yêu cầu của
khách hàng không)
Khi ta áp dụng Level 2, KPA 2(Software Project Planning), ta sẽ có những
common feature(đặc điểm đặc trưng) như sau:
Mục tiêu(Goal): 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 đủ
Đề xuất/ Xem xét (Commitment): dự án phải tuân thủ theo các qui tắc của tổ chức
khi hoạch định
Khả năng(Ability): 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
Đo lường(Measument): 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
Kiểm chứng(Verification): Các hoạt động khi lập kế hoạch dự án phải được sự
reviewed của cấp senior manager
Để đạt được Level 2 thì người quản lý phải thiết lập được các nguyên tắc cơ bản
và quản lý các hoạt động diễn ra. Họ có trách nhiệm quản lý đội ngũ của mình
Các KPA(Key Process Areas) của nó chú trọng tới các thành phần sau :
+ Chế độ đãi ngộ

+ Đào tạo
+ Quản lý thành tích
+ Phân công lao động
+ Thông tin giao tiếp
+ Môi trường làm việc
Để từ level1 tiến tới level 2 cần có những gì:
Trước tiên nó phải thỏa mãn các điều kiện ở level1. Tiếp theo là phải chú trọng tới các
phần sau:
Môi trường làm việc:
- Đảm bảo điều kiện làm việc
- Tạo hứng thú trong công việc
- Không bị ảnh hưởng, mất tập trung bởi các nhân tố khác
Thông tin:
Xây dựng cơ chế truyền tin thông suốt từ trên xuống dưới và ngược lại nhằm
giúp cá nhân trong tổ chức chia sẽ thông tin, kiến thức, kinh nghiệm, các kỹ năng giao
tiếp phối hợp và làm việc hiệu quả
Xây dựng đội ngũ nhân viên:
Ngay từ khâu tuyển dụng, lựa chọn kỹ càng và định hướng, thể chế hóa quy trình
tuyển dụng
Quản lý thành tích:
Đẩy mạnh thành tích, công nhận năng lực, thành tích bằng cách thiết lập các
tiêu chí khách quan để đánh giá và liên tục khuyến khích khả năng làm việc, tập trung
phát triển sự nghiệp, xây dựng các mục tiêu tiếp theo.
Đào tạo:
Không chỉ đào tạo các kiến thức chuyên môn phục vụ cho dự án mà còn mở rộng
đào tạo các kỹ năng then chốt, cần thiết như kỹ năng làm việc đội, nhóm, kỹ năng quản
lý… nhằm tạo cơ hội cho người lao động phát huy khả năng, cơ hội học hỏi và phát triển
bản thân.
Chế độ đãi ngộ:
Hoạch định chiến lược đãi ngộ, thu thập ý kiến lực lượng lao động và công bố

công khai. Chế độ đãi ngộ cần tập trung vào việc trả lương cho công nhân viên dựa vào
vai trò, vị trí của họ (Position), Con người (Person) – thái độ và tác phong làm việc và
Thành tích (Performance) mà họ đạt được, cống hiến cho tổ chức. Đưa ra được chính
sách lương, thưỏng, phụ cấp các các quyền lợi khác để khuyến khích các cá nhân dựa trên
sự đóng góp của họ và cấp độ phát triển của toàn tổ chức.
Level 3
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).
Để đạt được level 3 thì người quản lý phải biến đổi cải tiến các hoạt động đang
diễn ra, cải tiến môi trường làm việc.
Lực lượng lao động sở hữu những kiến thức, kỹ năng cốt lõi
KPA chú trọng tới các yếu tố sau :
+ Văn hóa cá thể
+ Công việc dựa vào kỹ năng
+ Phát triển sự nghiệp
+ Hoạch định nhân sự
+ Phân tích kiến thức và kỹ năng
Từ Level 2 lên Level 3: Các KPA cần thực hiện
1. Phân tích kiến thức và kỹ năng:
Xác định những kỹ năng và kiến thức cần thiết để làm nền tảng cho hoạt
động nhân sự. Lĩnh vực phân tích này bao gồm: xác định quy trình cần thiết để
duy trì năng lực tổ chức, phát triển và duy trì các kỹ năng và kiến thức phục vụ
công việc, dự báo nhu cầu kiến thức và kỹ năng trong tương lai.
2. Hoạch định nguồn nhân lực:

Đây là lĩnh vực phối hợp hoạt động nhân sự với nhu cầu hiện tại và
trong tương lai ở cả các cấp và toàn tổ chức. Hoạch định nguồn nhân lực có tính
chiến lược cùng với quy trình theo dõi chặt chẽ việc tuyển dụng và các hoạt động
phát triển kỹ năng sẽ tạo nên thành công trong việc hình thành đội ngũ.
3. Phát triển sự nghiệp:
Tạo điều kiện cho mỗi cá nhân phát triển nghề nghiệp và có cơ hội thăng
tiến trong nghề nghiệp, nó bao gồm: thảo luận về lựa chọn nghề nghiệp với mỗi
cá nhân, xác định các cơ hội, theo dõi sự tiến bộ trong công việc, được động viên,
khuyến khích đạt mục tiêu công việc, giao quyền và khuyến khích thực hiện
những mục tiêu trong công việc.
4. Các hoạt động dựa trên năng lực:
Ngoài các kỹ năng, kiến thức cốt lõi còn có hoạch định nhân lực, tuyển
dụng dựa vào khả năng làm việc, đánh giá hiệu quả qua mỗi công việc và vị trí,
xây dựng chế độ phúc lợi, đãi ngộ dựa trên hiệu quả… giúp bảo đảm rằng mọi
hoạt động của tổ chức đều xuất phát từ mục đích phục vụ cho phát triển nguồn
nhân lực
5. Văn hóa cá thể:
Tạo lập được cơ chế liên lạc thông suốt, kênh thông tin hiệu quả ở mọi
cấp độ trong tổ chức, phối hợp được kinh nghiệm, kiến thức của mỗi người để hỗ
trợ lẫn nhau, giúp nhau cùng tiến bộ. Trao quyền thúc đẩy nhân viên tham gia ý
kiến, ra quyết định
Level 4
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).
Lực lượng lao động làm việc theo đội, nhóm và được quản lý một cách định
lượng.
Các KPA của level 4 chú trọng tới:
+ Chuẩn hóa thành tích trong tổ chức

+ Quản lý năng lực tổ chức
+ Công việc dựa vào cách làm việc theo nhóm
+ Xây dựng đội ngũ chuyên nghiệp
+ Cố vấn
Để đạt được level 4 thì phải đo lường và chuẩn hóa. Đo lường hiệu quả đáp ứng
công việc, chuẩn hóac phát triển các kỹ năng, năng lực cốt lõi.
Level 4 này sẽ chú trọng vào những người đứng đầu của một công ty, họ có khả
năng quản lý các công việc như thế nào
Level 5
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) Để đạt được level 4 thì phải đo lường và chuẩn hóa. Đo lường hiệu quả đáp
ứng công việc, chuẩn hóac phát triển các kỹ năng, năng lực cốt lõi.
Để đạt được Level 5 thì doanh nghiệp đó phải liên tục cải tiến hoạt động tổ
chức, tìm kiếm các phương pháp đổi mới để nâng cao năng lực làm việc của lực lượng
lao động trong tổ chức, hỗ trợ các nhân phát triển sở trường chuyên môn.
Chú trọng vào việc quản lý, phát triển năng lực của nhân viên.
Huấn luyện nhân viên trở thành các chuyên gia.
f. Khả năng quan sát tiến trình, khả năng tiến trình và dự đoán trong mô hình CMM.
 Khả năng quan sát tiến trình đối với từng mức của CMM : 5 levels
 Khả năng tiến trình và dự đoán theo các mức CMM.
 Khi mức độ thuần thục tăng, sự khai thác giữa kết quả đạt được và
kết quả dự tính giảm xuống.
 Khi mức độ thuần thục tăng, độ biến động của kết quả thực tế so
với kết quả đề ra giảm xuống.
 Khi mức độ thuần thục tăng thì các kết quả sẽ cải thiện . Đó là chi
phí giảm, thời gian phát triển ngắn hơn, chất lượng và năng suất
tăng.

g.Cách sử dụng mô hình CMM
- Định giá tiến trình phần mềm : xác định trạng thái của tiến trình phần mềm hiện
tại của tổ chức , xác định mức độ ưu tiên đối với các vấn đề có lien quan tới tiến trình
phần mềm khi xử lý chúng và xây dựng hệ thống hỗ trợ phát triển tiến trình phần mềm.
- Đánh giá khả năng phần mềm : Xác định các nhà thầu có đủ tư cách triển khai
một dự án phần mềm hoặc quản lý hiện trạng của một hệ thống phần mềm đã có sẵn.
2. Các khái niệm về CMMI.
a.CMMI là gì?
CMMI viết tắt cho Capability Maturity Model Integration - Mô hình trưởng thành năng
lực tích hợp - và là khuôn khổ cho cải tiến qui trình phần mềm. Nó dựa trên khái niệm về
các thực hành tốt nhất về kĩ nghệ phần mềm và giải thích kỉ luật mà các công ty có thể
dùng để cải tiến các qui trình của họ.
Mô hình CMMI là một khung các giải pháp tối ưu cho quá trình sản xuất phần mềm.
Phiên bản CMMI-DEV hiện nay (CMMI cho chuyên viên phát triển), mô tả những giải
pháp tốt nhất trong quá trình kiểm soát, đo lường và kiểm tra các quy trình phát triển
phần mềm. Mô hình CMMI không tập trung mô tả chính các quá trình mà chỉ mô tả đặc
điểm của các quá trình hiệu quả, vì vậy mô hình CMMI đưa ra chỉ dẫn cho các công ty để
họ có thể tự mình phát triển hoặc điều chỉnh chính các quá trình của họ.
Mô hình CMMI được mô tả trên trang web chính thức CMMI website: Dự án
CMMI là một nỗ lực chung nhằm cung cấp các mô hình để cải thiện nâng cấp các sản
phẩm và quy trình. Trọng tâm chính của dự án là tập trung xây dựng các công cụ hỗ trợ
việc cải thiện các quy trình dùng để phát triển và ổn định các hệ thống và sản phẩm. Kết
quả của dự án CMMI là một bộ các sản phẩm cung cấp một phương pháp tiếp cận tích
hợp trên toàn doanh nghiệp để cải thiện các quy trình sản xuất mà vẫn có thể giảm bớt
nhân công dư thừa, độ phức tạp, và chi phí từ việc sử dụng các mô hình CMM (quy trình
quản lý sản xuất phẩn mềm) riêng lẻ và nhiều mô hình CMM.
b.CMMI bắt nguồn từ đâu?
CMMI là phiên bản kế tiếp của CMM. Cả CMM và CMMI đều được Viện kỹ nghệ phần
mềm Mỹ SEI tại trường Đại học Carnegie Mellon ở Pittsburgh, PA phát triển. CMM đã
có mặt từ cuối những năm 80 và một thập kỷ sau nó bị CMMI thay thế. Năm 2000

CMMI phiên bản 1.02 được đưa ra thị trường. Phiên bản mới nhất hiện nay CMMI 1.2
được trình làng vào tháng 8 năm 2006.
Đôi nét về lịch sử Do cấu trúc của CMMI được thừa hưởng rất nhiều từ CMM,
chúng ta hãy xem xét lí do và nguồn gốc để có thể hiểu được cả hai mô hình này có ý
nghĩa như thế nào.
CMM là kết quả của một nghiên cứu được không quân Mỹ tài trợ, nghiên cứu này
được coi là một phương pháp đánh giá khách quan công việc của các nhà thầu phụ về
phần mềm. Bộ Quốc Phòng Mỹ cũng quan tâm tới việc chi phí phát triển phần mềm đang
leo thang và các vấn đề liên quan đến chất lượng của các phần mềm nên đã thành lập
viện SEI vào đầu những năm 80, và bắt đầu nghiên cứu mô hình CMM vào năm 1988.
Ban đầu, mô hình CMM được sử dụng như một công cụ để đánh giá khả năng của
các nhà thầu chính phủ khi họ tiến hành một dự án phần mềm theo hợp đồng. Mặc dù
CMM được thiết kế để đánh giá quá trình phát triển phần mềm nhưng nó đã và đang
được áp dụng như một mô hình chung cho kỳ hạn của các quá trình trong các công ty về
CNTT hay bất cứ công ty nào khác.
Các nhà phê bình cũng nhận thấy CMM luôn được gắn chặt trong một mô hinh
phát triển thác nước và không quan tâm tới các khía cạnh khác của quy trình phát triển
phẩn mềm như thiết kế và triển khai. CMM không phù hợp với các quy trình ngoại vi liên
quan đến việc phát triển phần mềm như là việc mua lại. CMM cũng bị phê phán là tạo ra
quá nhiều giấy tờ sổ sách và quá nhiều cuộc họp và nó cũng không phù hợp với nhiều
ngành công nghiệp.
Các ngành công nghiệp và chính phủ đã tìm ra giải pháp cho vấn đề này bằng
cách áp dụng CMM cho các lĩnh vực khác. Toàn bộ quy trình sẽ được giám sát bởi một
ban lãnh đạo bao gồm những người đại diện từ OSD, Không quân, Quân đội, Hải quân,
các bộ phận khác của chính phủ, SEI và ngành công nghiệp. Nhiệm vụ của ban lãnh đạo
này là hướng dẫn và giám sát quá trình phát triển dòng sản phẩm CMMI, đưa ra các sản
phẩm CMMI để thẩm tra và phát hành ra công chúng. Viện SEI phối hợp với các chuyên
gia đề tài phụ trách quản lý dự án ban đầu là phát triển phần mềm, xây dựng hệ thống,
phát triển quy trình và sản phẩm tích hợp. Các cổ đông/ các nhà phê bình đều có quyền
kiểm tra, phê bình và đưa ra những gợi ý để phát triển các sản phẩm CMMI. Trong số

những người này cũng có những đại diện từ ngành công nghiệp, chính phủ và viện SEI.
Vậy như ta có thể thấy, CMMI không phải hoàn toàn mới. Hơn thế nữa, CMMI là
một sự kết hợp và phù hợp của nhiều biến thể CMM đã phát triển cùng với những yêu
cầu của ngành công nghiệp. Hiểu được CMM và nguồn gốc của nó, ta sẽ biết được nền
tảng của CMMI. Và CMMI cũng được sử dụng ở hầu hết những nơi giống nhau – theo
nghĩa về sự phát triển, không phải là cách mạng. CMMI mang lại sự khôn ngoan của
nhiều ngành công nghiệp khác nhau đã giúp CMM phù hợp với những ngành công
nghiệp đó.
c. Khác biệt giữa ISO 9001:2000 và CMM/CMMI?
• ISO 9001 là một tiêu chuẩn quốc tế về quản lý, các điều khoản gọi là “yêu cầu” quy
định những điểm cần phải làm (what to do), không chỉ ra việc đó nên làm như thế nào
(how to do).
• CMM/CMMi là một mô hình, cung cấp các hướng dẫn và kinh nghiệm thực tế
dùng để phát triển, cải tiến và đánh giá năng lực của quy trình.
• CMMi không phải là một tiêu chuẩn, tùy vào từng tổ chức, cách thực hiện khác
nhau rất nhiều.
• Về nguyên tắc, ISO bao gồm (ở mức cao) hầu hết các quy trình chủ chốt của
CMM/CMMi, tuy nhiên ISO được dùng cho hầu hết mọi ngành nghề, do vậy không cụ
thể và gần gũi với công việc đặc thù có liên quan đến phần mềm như CMM/CMMi. ISO
không cung cấp các ví dụ và kinh nghiêm cụ thể như CMM/CMMi
d.SCAMPI là gì?
Phương pháp đánh giá chất lượng CMMI tiêu chuẩn để cải tiến quy trình (SCAMPI) cung
cấp các phương pháp đánh giá bằng cách sử dụng các mô hình CMMI. Các loại giấy phép
của SEI kết hợp với nhau để thực hiện các phương pháp đánh giá SCAMPI và đào tạo
những người đánh giá.
Có ba mức SCAMPI là: A, B và C. SCAMPI A xem xét các mức độ kỳ hạn và là
mức cơ bản để đánh giá trong khi đó mức độ B và C xem xét cách tiếp cận và quá trình
triển khai.
e.CMMI dùng để làm gì?
Các công ty thương mại và chính phủ sử dụng mô hình CMMI để hỗ trợ viêc xác định cải

tiến quy trình để xây dựng hệ thống, xây dựng phần mềm và phát triển quy trình và sản
phẩm tích hợp.
Công ty sử dụng quy trình này để phát triển, thu thập và duy trì các sản phẩm và
dịch vụ và để làm chuẩn cho chính họ chống lại các công ty khác. Các quy trình tốt hơn
cũng có thể là những quy trình có giá rẻ hơn và kết quả chất lượng tốt hơn, cũng như là
những quy trình này ước tính thời gian thực cho dự án chính xác hơn.
Tuy nhiên, cũng giống như tất cả các cơ cấu khác, CMMI không thể nhanh chóng
phù hợp với tất cả các công ty mà không ảnh hưởng đến sự phát triển của công ty đó. SEI
cho biết việc cải thiện các dự án sẽ được tính bằng tháng và năm chứ không phải chỉ tính
bằng ngày và tuần.Vì việc cải thiện dự án thường đòi hỏi phải có nhiều kiến thức và
nguồn lực nên các công ty lớn hơn có thể có được kết quả tốt hơn từ CMMI. Tuy nhiên,
việc thay đổi quy trình CMMI cũng có thể giúp ích cho các công ty nhỏ hơn.
SEI không cấp giấy chứng nhận cho bất cứ loại hình CMMI nào. Đơn giản là SEI
chỉ cấp giấy phép hoạt động và cho phép các nhà thẩm định hàng đầu tiến hành đánh giá.
f. Các level của CMMI
Tương tự như cấu trúc của CMM, CMMI cũng gồm có 5 level.
g.Sự khác nhau giữa CMM và CMMI
Hẵn những ai quan tâm tới CMM, cũng đã từng nghe hoặc biết qua CMMI . Và khi đã
nghe qua, tôi đoán không ít người thầm thắc mắc, hoặc tự hỏi rằng không biết CMM với
CMMI nó khác nhau ra sao nhỉ ???
Nếu đặc tả một các trực quan thì ta thấy CMM và CMMI chỉ khác nhau có một chữ “I”
(Integration). Nhưng một chữ “I” đó thôi cũng tạo ra sự khác biệt đáng kể giữa CMM và
CMMI rồi.
Trước tiên hãy xem qua nguồn gốc của hai thứ này một tí . Nếu nói rằng CMM ra đời
trước CMMI thì cũng đúng nhưng mà nói CMMI có trước từ khi CMM ra đời cũng
chẳng sai. Thật ra khi CMM được chính thức công bố vào cuối năm 1990 thì CMMI đã
được manh múng được nhắc đến từ nhiều năm trướcđó (chính xác hơn là từ 1979-
Crosby’s maturity grid (Quality is Free)) thông qua cấu trúc Continuous &Staged. Có
thể nói CMMI là một phiên bản cải thiện tất yếu của CMM.
Trong khi CMM được hoàn thiện và phát triển bởi viện SEI của Mỹ, thì CMMI là sản

phẩm của sự cộng tác giữa viện này và chính phủ Mỹ. Từ khi CMM được công nhận và
áp dụng trên thế giới thì tầm quan trọng của nó đã vượt qua giới hạn của một viện khoa
học. Với tốc độ phát triển không ngừng và đòi hỏi sự cải thiện liên tụctrong ngành công
nghệ thông tin, việc chính phủ Mỹ cùng với viện SEI kết hợp đểhoàn thiện CMM và cho
ra đời phiên CMMI là một hệ quả tất yếu.
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ênmứ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.
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 định nghĩa, được quản lý và tối ưu.
CMMI đưa ra cụ thể các mô hình khác nhau cho từng mục đích sử dụng có đặc riêng bao
gồm :
- CMMI-SW mô hình chỉ dành riêng cho phần mềm.
- CMMI-SE/SW mô hình tích hợp dành cho các hệ thống và kỹ sư phần mềm.
- CMMI-SE/SW/IPPD mô hình dành cho các hệ thống, kỹ sư phần mềm và việctích hợp
sản phẩm cùng quá trình phát triển nó.

Như vậy các đặc điểm khác nhau quan trọng nhất giữa CMM và CMMI là gì?
Thử nghía qua xem trong CMMI hiện nay có gì khác với thằng anh sinh ra trước nó
(CMM):
- CMMI đưa ra cụ thể hơn 2 khái niệm đối ứng stageds VS continuous
- Chu kỳ phát triển của CMMI được phát triển sớm hơn.
- Nhiều khả năng tích hợp (Integration) hơn
- Sự đo lường, định lượng được định nghĩa hẵn là một Process area (vùng tiến trình). Chứ
không hẵn chỉ là một đặc trưng cơ bản.
- Bao hàm nhiều Process Areas hơn.
- Đạt được thành quả dễ dàng hơn với mỗi Process area.
B. Vai trò của CMM/CMMI trong tổ chức công ty doanh nghiệp phần mềm
3. Lợi ích của CMM/CMMI đem lại cho doanh nghiệp
 Viễn cảnh mà CMM mang lại
- Ý nghĩa của việc áp dụng những nguyên tắc:
+ Quản lý chất lượng tổng thể
+ Quản lý nguồn nhân lực
+ Phát triển tổ chức
+ Tính cộng đồng
+ Phạm vi ảnh hưởng rộng: từ các nghành công nghiệp đến chính phủ
+ Hoàn toàn có thể xem xét và mở rộng tầm ảnh hưởng với bên ngoài
+ Chương trình làm việc nhằm cải tiến, nâng cao hoạt động của đội ngũ lao động
+ Đánh giá nội bộ
+ Các hoạt động của đội ngũ lao động được cải tiến
+ Các chương trình nhằm nâng cao năng lực, hiệu quả công việc luôn được tổ
chức
 Mục tiêu chiến lược
- Cải tiến năng lực của các tổ chức phần mềm bằng cách nâng cao kiến thức và kỹ năng
của lực lượng lao động
- Đảm bảo rằng năng lực phát triển phần mềm là thuộc tính của tổ chức không phải của
một vài cá thể

- Hướng các động lực của cá nhân với mục tiêu tổ chức
- Duy trì tài sản con người, duy trì nguồn nhân lực chủ chốt trong tổ chức
4. Vai trò trong tổ chức doanh nghiệp phần mềm Việt Nam.
Việt nam có các lợi thế về nhân lực cần cù, chăm chỉ, giá nhân công rẻ, hệ thống
giáo dục được đào tạo bài bản Việt Nam hiện là điểm sáng trên bản đồ thế giới. Tuy
nhiên, trong quá trình tiếp thị và giới thiệu tiềm năng với cộng đồng CNTT quốc tế, yêu
cầu đầu tiên được phía nuớc ngoài đặt câu hỏi là: Doanh nghiệp CNTT Việt Nam có tốc
độ phát triển ra sao ? Năng lực thế nào, và đặc biệt là ứng dụng hệ thống quản lý chất
lượng phần mềm đến đâu ?
Về cơ bản, quản lý chất lượng phần mềm là vấn đề không mới, nhưng lại là vấn
đề còn yếu của các công ty phần mềm Việt Nam. Một số công ty đã đạt chuẩn quốc tế
CMM/CMMI trong nâng cao năng lực và quản lý chất lượng phần mềm, song cũng chỉ
gói gọn trong vài công ty gia công cho nước ngoài.
Tuy nhiên, thông thường các công ty phải đầu tư ít nhất 40.000- 50.000 USD cho
chi phí tư vấn, đánh giá và khảo sát. Chi phí này thực tế còn cao hơn nhiều sau khi cộng
thêm các khoản vé máy bay, ăn ở , đi lại cho các chuyên gia tư vấn, giám sát, đào tạo
Thực tế đây là khoản đầu tư khá lớn đối với các công ty phần mềm VN.
Xét đến thời điểm này, chưa có số liệu chính xác về số lượng doanh nghiệp phần
mềm đang áp dụng mô hình đánh giá năng lực sản xuất phần mềm CMM/CMMi tại Việt
Nam, nhưng có thể nhắc đến những tên tuổi như PSV (CMMi mức 5: 2005), GCS
(CMMi mức 4: 2006), FPT Software (CMM mức 5: 2004) và SilkRoad (CMM mức 3).
Các công ty Việt Nam đua nhau lấy ISO và CMM có hai dạng: 1 là muốn cải tiến
quá trình quản lý trong việc phát triển phần mềm, còn 1 là đi theo nhu cầu khách hàng
hoặc để quảng cáo.
Với các công ty muốn cải tiến quy trình để phát triển thì việc lấy chứng chỉ hơi
lâu vì cần phải đào tạo, chỉ rõ cho tất cả nhân viên thấy được lợi ích của các quy trình này
để họ tự nguyện làm theo (vì thật sự thì nó sẽ làm cho nhân viên cảm thấy mình phải làm
nhiều hơn, phải lưu giữ đủ thứ giấy tờ, thủ tục, ). Khi tất cả đều nhận thức rõ được vấn
đề và thấy rằng ISO hay CMM thật sự sẽ mang lại lợi ích lâu dài cho họ thì lúc đó ISO
hay CMM mới góp phần cải tiến quy trình thật sự cho công ty. Dĩ nhiên khi có được ISO

hay CMM certification thì công ty cũng đem ra để quảng cáo, để làm lợi thế khi ký hợp
đồng. Nhưng thật sự thì ISO hay CMM giúp ích cho công tác quản lý rất nhiều, mọi việc
phải được cụ thể hoá thành văn bản chứ không làm việc cảm tính, nói miệng với nhau
như trước nữa.
Còn với những công ty lấy ISO hay CMM chỉ vì mục đích quảng cáo thì đâu lại
vào đấy thôi vì sau khi đạt được chứng chỉ xong họ lại cất những process đó vào tủ và lại
làm việc theo thói quen cũ, chẳng có thay đổi gì hết.