Luận Văn Thạc Sĩ Về Quản Lý Quy Trình Phần Mềm Theo Mô Hình CMM Tại Việt Nam

Luận văn thạc sĩ VNU UET về quản lý quy trình phần mềm theo mô hình CMM, thực tiễn và ứng dụng tại Việt Nam trong công nghệ thông tin.

• Tác giả: Đỗ Việt Hùng
• Người hướng dẫn: PGS. Nguyễn Quốc Toản
• Trường học: Đại học quốc gia Hà Nội
• Chuyên ngành: Công nghệ thông tin
• Đề tài: Quản Lý Quy Trình Phần Mềm Theo Mô Hình CMM – Thực Tiễn Và Ứng Dụng Ở Việt Nam
• Loại tài liệu: Luận văn thạc sỹ
• Năm xuất bản: 2006
• Địa điểm: Hà Nội

Mục lục chi tiết

• LỜI MỞ ĐẦU
• 1. CHƯƠNG 1: TỔNG QUAN CÁC MÔ HÌNH PHÁT TRIỂN PHẦN MỀM
• 1.1. Khái niệm quy trình
• 1.2. SEP, ISO, CMM/CMMI
• 1.3. Các mô hình SEP
• 1.3.1. Mô hình Thác nước (Waterfall)
• 1.3.2. Mô hình chữ V
• 1.3.3. Mô hình mẫu
• 1.3.4. Mô hình tiến hóa
• 1.3.5. Mô hình lặp và tăng dần
• 1.3.6. Mô hình phát triển nhanh
• 1.3.7. Mô hình xoắn
• 2. CHƯƠNG 2: GIỚI THIỆU VỀ CMM VÀ CÁC KHÓ KHĂN TRONG PHÁT TRIỂN PHẦN MỀM
• 2.1. Lịch sử mô hình CMM
• 2.2. Tổng quan về mô hình CMM
• 2.3. Định nghĩa về CMM
• 2.4. Ích lợi của cải tiến theo mô hình CMM
• 2.5. Năm mức độ trưởng thành của mô hình CMM
• 2.6. Các lĩnh vực quy trình chốt (KPA) của mô hình CMM
• 2.7. Khả năng áp dụng CMM
• 2.8. Những khó khăn thường gặp trong phát triển phần mềm
• 2.8.1. Khó khăn mức Khởi Đầu
• 2.8.2. Khó khăn mức Lặp Lại
• 2.8.3. Khó khăn mức Xác Định
• 2.8.4. Khó khăn mức Quản Lý
• 2.8.5. Khó khăn mức Tối Ưu Hóa
• 3. CHƯƠNG 3: TÍNH CHẤT VÀ CÁC QUY TRÌNH CHỦ CHỐT CỦA CÁC MỨC TĂNG TRƯỞNG CỦA MÔ HÌNH CMM
• 3.1. Mức 1: Khởi đầu
• 3.1.1. Hiểu mức tăng trưởng khởi đầu
• 3.1.2. Thuộc tính của tổ chức mức 1
• 3.2. Mức 2: Lặp lại được
• 3.2.1. Hiểu mức tăng trưởng lặp lại
• 3.2.2. Các KPA cho mức lặp lại
• 3.3. Mức 3: Được xác định
• 3.3.1. Hiểu mức độ tăng trưởng được xác định
• 3.4. Mức 4: Được quản lý
• 3.4.1. Hiểu mức tăng trưởng được quản lý
• 3.4.2. KPA cho mức được quản lý
• 3.4.3. Hiểu mức tăng trưởng tối ưu
• 3.4.4. KPA cho mức tối ưu
• 4. CHƯƠNG 4: THỰC TIỄN VÀ ỨNG DỤNG Ở VIỆT NAM
• 4.1. Hiện trạng ứng dụng CMM ở Việt Nam
• 4.2. Các số liệu thống kê
• 4.3. Kinh nghiệm một số công ty đã đạt CMM
• 4.4. Một số giải pháp với CMM
• 4.4.1. Giải pháp kiểm định chất lượng thực chất mức độ CMM5
• 4.4.2. Giải pháp ứng dụng CMM hiệu quả
• TÀI LIỆU THAM KHẢO

Tóm tắt

I. Tổng Quan Về Quản Lý Quy Trình Phần Mềm Theo Mô Hình CMM

Quản lý quy trình phần mềm theo mô hình CMM (Capability Maturity Model) đã trở thành một tiêu chuẩn quan trọng trong ngành công nghiệp phần mềm tại Việt Nam. Mô hình này không chỉ giúp cải thiện chất lượng sản phẩm mà còn nâng cao năng suất làm việc của các tổ chức phát triển phần mềm. CMM cung cấp một khung để đánh giá và cải tiến quy trình phát triển phần mềm, từ đó giúp các công ty đạt được những sản phẩm chất lượng cao hơn với chi phí hợp lý hơn. Việc áp dụng mô hình CMM tại Việt Nam vẫn còn nhiều thách thức, nhưng cũng mở ra nhiều cơ hội cho sự phát triển bền vững của ngành công nghiệp phần mềm.

1.1. Khái Niệm Về Mô Hình CMM Và Lợi Ích Của Nó

Mô hình CMM được phát triển bởi Viện Công Nghệ Phần Mềm SEI nhằm cải thiện quy trình phát triển phần mềm. Mô hình này chia thành 5 mức độ trưởng thành, từ mức khởi đầu đến mức tối ưu hóa. Mỗi mức độ đều có những yêu cầu và thực hành cụ thể giúp tổ chức nâng cao khả năng quản lý quy trình phần mềm. Lợi ích của việc áp dụng CMM bao gồm cải thiện chất lượng sản phẩm, giảm thiểu rủi ro và tăng cường sự hài lòng của khách hàng.

1.2. Tình Hình Áp Dụng Mô Hình CMM Tại Việt Nam

Tại Việt Nam, việc áp dụng mô hình CMM còn hạn chế do nhiều yếu tố như quy mô công ty nhỏ, thiếu kinh nghiệm và hiểu biết về mô hình này. Tuy nhiên, một số công ty đã thành công trong việc áp dụng CMM và đạt được chứng nhận CMMI, từ đó nâng cao vị thế cạnh tranh trên thị trường. Việc chia sẻ kinh nghiệm và thực hành tốt giữa các công ty sẽ giúp thúc đẩy việc áp dụng mô hình này rộng rãi hơn.

II. Những Thách Thức Trong Quản Lý Quy Trình Phần Mềm Tại Việt Nam

Mặc dù mô hình CMM mang lại nhiều lợi ích, nhưng việc áp dụng nó tại Việt Nam gặp phải nhiều thách thức. Các công ty phần mềm thường phải đối mặt với vấn đề thiếu hụt nguồn lực, kinh nghiệm và sự hỗ trợ từ lãnh đạo. Ngoài ra, sự khác biệt về văn hóa làm việc và cách tiếp cận giữa các tổ chức cũng tạo ra rào cản trong việc triển khai mô hình CMM.

2.1. Thiếu Nguồn Lực Và Kinh Nghiệm

Nhiều công ty phần mềm tại Việt Nam còn thiếu nguồn lực và kinh nghiệm trong việc áp dụng mô hình CMM. Điều này dẫn đến việc không thể thực hiện đầy đủ các quy trình và thực hành cần thiết để đạt được các mức độ trưởng thành cao hơn. Việc đào tạo và phát triển nhân lực là rất cần thiết để khắc phục vấn đề này.

2.2. Khó Khăn Trong Việc Thay Đổi Văn Hóa Làm Việc

Việc thay đổi văn hóa làm việc trong các tổ chức để phù hợp với mô hình CMM là một thách thức lớn. Nhiều nhân viên có thể không quen với các quy trình và tiêu chuẩn mới, dẫn đến sự kháng cự trong việc áp dụng. Cần có sự hỗ trợ từ lãnh đạo và các chương trình đào tạo để giúp nhân viên hiểu rõ hơn về lợi ích của việc áp dụng mô hình CMM.

III. Phương Pháp Cải Tiến Quy Trình Phát Triển Phần Mềm Theo Mô Hình CMM

Để cải tiến quy trình phát triển phần mềm theo mô hình CMM, các công ty cần thực hiện một số phương pháp cụ thể. Những phương pháp này không chỉ giúp nâng cao chất lượng sản phẩm mà còn cải thiện hiệu suất làm việc của đội ngũ phát triển. Việc áp dụng các thực hành tốt nhất từ mô hình CMM sẽ giúp các tổ chức đạt được những kết quả tích cực.

3.1. Đánh Giá Quy Trình Hiện Tại

Đánh giá quy trình hiện tại là bước đầu tiên trong việc cải tiến quy trình phát triển phần mềm. Các công ty cần xác định các điểm mạnh và điểm yếu trong quy trình hiện tại để từ đó đưa ra các giải pháp cải tiến phù hợp. Việc sử dụng các công cụ đánh giá quy trình sẽ giúp tổ chức có cái nhìn rõ ràng hơn về tình hình hiện tại.

3.2. Áp Dụng Các Thực Hành Tốt Nhất

Áp dụng các thực hành tốt nhất từ mô hình CMM là một trong những cách hiệu quả nhất để cải tiến quy trình phát triển phần mềm. Các công ty nên tham khảo và học hỏi từ những tổ chức đã thành công trong việc áp dụng CMM để có thể áp dụng những thực hành này vào quy trình của mình.

IV. Ứng Dụng Thực Tiễn Mô Hình CMM Tại Một Số Công Ty Phần Mềm

Nhiều công ty phần mềm tại Việt Nam đã áp dụng mô hình CMM và đạt được những kết quả tích cực. Việc chia sẻ kinh nghiệm và kết quả từ các công ty này sẽ giúp các tổ chức khác có thêm động lực và hướng đi trong việc áp dụng mô hình CMM. Các nghiên cứu điển hình từ những công ty này sẽ cung cấp những bài học quý giá cho ngành công nghiệp phần mềm.

4.1. Kinh Nghiệm Từ Công Ty A

Công ty A đã áp dụng mô hình CMM và đạt được chứng nhận CMMI cấp 3. Qua đó, công ty đã cải thiện đáng kể chất lượng sản phẩm và giảm thiểu thời gian phát triển. Kinh nghiệm từ công ty A cho thấy việc đầu tư vào đào tạo nhân lực và cải tiến quy trình là rất quan trọng.

4.2. Kinh Nghiệm Từ Công Ty B

Công ty B đã áp dụng mô hình CMM để nâng cao năng lực quản lý dự án. Kết quả là công ty đã tăng cường khả năng đáp ứng nhu cầu của khách hàng và cải thiện sự hài lòng của khách hàng. Việc chia sẻ kinh nghiệm từ công ty B sẽ giúp các tổ chức khác có thêm thông tin hữu ích trong việc áp dụng mô hình CMM.

V. Kết Luận Về Tương Lai Của Quản Lý Quy Trình Phần Mềm Tại Việt Nam

Quản lý quy trình phần mềm theo mô hình CMM tại Việt Nam đang trên đà phát triển. Mặc dù còn nhiều thách thức, nhưng với sự nỗ lực từ các công ty và sự hỗ trợ từ các tổ chức, mô hình CMM có thể trở thành một tiêu chuẩn quan trọng trong ngành công nghiệp phần mềm. Tương lai của quản lý quy trình phần mềm tại Việt Nam sẽ phụ thuộc vào khả năng áp dụng và cải tiến mô hình CMM trong thực tiễn.

5.1. Triển Vọng Phát Triển Ngành Công Nghiệp Phần Mềm

Ngành công nghiệp phần mềm tại Việt Nam đang có nhiều triển vọng phát triển. Việc áp dụng mô hình CMM sẽ giúp các công ty nâng cao chất lượng sản phẩm và năng suất làm việc. Điều này sẽ tạo ra cơ hội lớn cho sự phát triển bền vững của ngành công nghiệp phần mềm.

5.2. Đề Xuất Các Giải Pháp Hỗ Trợ

Để thúc đẩy việc áp dụng mô hình CMM, cần có các giải pháp hỗ trợ từ chính phủ và các tổ chức liên quan. Các chương trình đào tạo, hội thảo và chia sẻ kinh nghiệm sẽ giúp nâng cao nhận thức và khả năng áp dụng mô hình CMM trong ngành công nghiệp phần mềm tại Việt Nam.

Nội dung chính

Tổng quan nghiên cứu

Theo các báo cáo thống kê trong ngành công nghệ thông tin vào đầu những năm 2000, có hơn 70% dự án phát triển phần mềm gặp tình trạng chậm tiến độ và chi phí thực tế phát sinh thường vượt quá 100% đến 200% so với ngân sách dự kiến ban đầu. Nguyên nhân cốt lõi không nằm ở sự thiếu hụt công nghệ hay năng lực lập trình cá nhân, mà xuất phát từ sự yếu kém trong khả năng quản trị quy trình sản xuất phần mềm. Tại Việt Nam giai đoạn 2005 - 2006, hầu hết doanh nghiệp phần mềm hoạt động với quy mô nhỏ lẻ, sản xuất mang tính tự phát và đối mặt với rủi ro biến động nhân sự rất lớn khi chuyển giao dự án.

Xuất phát từ thực tiễn cấp bách đó, luận văn tập trung nghiên cứu toàn diện mô hình năng lực trưởng thành phần mềm SW-CMM do Viện Kỹ nghệ Phần mềm SEI thuộc Đại học Carnegie Mellon ban hành. Mục tiêu cụ thể của đề tài là phân tích cấu trúc 5 cấp độ trưởng thành, làm rõ 18 vùng quy trình then chốt, đồng thời đánh giá thực trạng năng lực quản lý quy trình tại các doanh nghiệp Việt Nam. Phạm vi nghiên cứu được triển khai tập trung tại các tổ chức sản xuất và gia công phần mềm trong nước trong mốc thời gian hoàn thành vào tháng 12 năm 2005.

Ý nghĩa nghiên cứu thể hiện qua việc cung cấp giải pháp chuẩn hóa quy trình, giúp các đơn vị cắt giảm từ 60% đến 75% chi phí khắc phục lỗi sai, ổn định năng suất lao động và rút ngắn độ trễ lịch biểu. Đây là nền tảng quản trị vững chắc giúp doanh nghiệp công nghệ thông tin Việt Nam nâng cao uy tín thương hiệu và mở rộng năng lực cạnh tranh trong thị trường gia công phần mềm quốc tế.

Cơ sở lý thuyết và phương pháp nghiên cứu

Khung lý thuyết áp dụng

Luận văn xây dựng trên nền tảng lý thuyết kiểm soát chất lượng bằng thống kê của Walter Shewhart, kết hợp các nguyên lý quản trị chất lượng toàn diện của W. Edwards Deming và Joseph Juran. Cùng với đó, nghiên cứu kế thừa mô hình lưới trưởng thành quản lý chất lượng gồm 5 giai đoạn do Philip Crosby đề xuất trong các công trình nghiên cứu quản trị kinh điển.

Khung lý thuyết trung tâm là Mô hình Trưởng thành Năng lực Phần mềm SW-CMM phiên bản 1.1 do Viện Kỹ nghệ Phần mềm SEI công bố. Mô hình này thiết lập lộ trình tiến hóa gồm 5 mức độ trưởng thành: Mức 1 - Khởi đầu, Mức 2 - Lặp lại được, Mức 3 - Được xác định, Mức 4 - Được quản lý định lượng, và Mức 5 - Tối ưu hóa. Đi kèm với đó là hệ thống 18 vùng quy trình then chốt (KPA) được phân bổ theo 3 nhóm trụ cột gồm Quản lý, Kỹ thuật và Tổ chức. Mỗi KPA được cấu trúc hóa qua 5 đặc trưng chung chứa đựng các thực hành then chốt. Ngoài ra, đề tài so sánh đối chiếu CMM với tiêu chuẩn quản lý chất lượng ISO 9001 và các mô hình vòng đời phát triển phần mềm phổ biến như Thác nước (Waterfall), Chữ V (V-model), Mô hình mẫu (Prototype), Mô hình tiến hóa, Mô hình xoắn ốc của Barry Boehm và Mô hình phát triển ứng dụng nhanh RAD.

Phương pháp nghiên cứu

Nghiên cứu sử dụng nguồn dữ liệu thứ cấp chuẩn mực từ các ấn phẩm của Viện SEI, Đại học Carnegie Mellon, tiêu chuẩn kỹ thuật của Viện Kỹ nghệ Điện và Điện tử IEEE, kết hợp nguồn dữ liệu sơ cấp thu thập trực tiếp từ các doanh nghiệp phần mềm tại Hà Nội và Thành phố Hồ Chí Minh. Cỡ mẫu nghiên cứu bao gồm 25 doanh nghiệp công nghệ thông tin đang hoạt động tại Việt Nam.

Phương pháp chọn mẫu được áp dụng là chọn mẫu phi xác suất kết hợp giữa chọn mẫu định mức và chọn mẫu thuận tiện có mục đích. Tiêu chí chọn mẫu ưu tiên các đơn vị gia công phần mềm xuất khẩu, các công ty quy mô từ 20 đến 500 nhân sự đang áp dụng hệ thống quản lý ISO 9001 hoặc định hướng xây dựng tiêu chuẩn CMM từ Mức 2 đến Mức 5. Lý do lựa chọn phương pháp phân tích so sánh đối chiếu kết hợp tổng hợp định lượng chỉ số kỹ thuật là nhằm đánh giá chính xác khoảng cách giữa lý thuyết chuẩn quốc tế với thực trạng nguồn lực đặc thù của doanh nghiệp Việt Nam. Toàn bộ quá trình nghiên cứu, khảo sát thực tế và phân tích tổng hợp dữ liệu được tiến hành liên tục trong khung thời gian 12 tháng, từ tháng 1 năm 2005 đến tháng 12 năm 2005.

Kết quả nghiên cứu và thảo luận

Những phát hiện chính

Thứ nhất, kết quả khảo sát chỉ ra rằng có tới hơn 85% doanh nghiệp phần mềm tại Việt Nam trong giai đoạn nghiên cứu vẫn dừng lại ở Mức 1 (Khởi đầu). Quy trình làm việc tại các đơn vị này mang tính tự phát, hoàn toàn phụ thuộc vào nỗ lực cá nhân của một vài lập trình viên chủ chốt, khiến tỷ lệ dự án bị trễ hạn chiếm khoảng 65% và sự hài lòng của khách hàng đạt mức rất thấp.

Thứ hai, nghiên cứu định lượng rõ nét hiệu quả vượt trội của việc phát hiện lỗi sớm. Dữ liệu thực nghiệm chứng minh rằng việc phát hiện và khắc phục một lỗi thông qua hoạt động rà soát thiết kế và soi mã nguồn chỉ tiêu tốn từ 1 đến 4 giờ làm việc. Ngược lại, nếu lỗi đó lọt qua giai đoạn kiểm thử chức năng hoặc kiểm thử hệ thống, thời gian xử lý tăng vọt lên mức 5 đến 20 giờ làm việc, tức chi phí khắc phục tăng gấp 5 lần.

Thứ ba, sự hình thành hai bộ phận chuyên trách đóng vai trò then chốt giúp tổ chức chuyển dịch từ Mức 1 lên Mức 2 và Mức 3. Đó là Nhóm quy trình phần mềm với quy mô tối ưu từ 1% đến 3% tổng nhân sự công ty (khoảng 4 chuyên gia nòng cốt) và Nhóm đảm bảo chất lượng QA độc lập chiếm từ 3% đến 6% quy mô tổ chức.

Thứ tư, việc thiếu hụt định nghĩa chuẩn hóa trong đo lường năng suất lập trình tạo ra sai số rất lớn. Việc đếm dòng mã (LOC) có thể biến thiên từ 7 đến 10 lần và chi phí bảo trì mỗi dòng mã cho các thay đổi nhỏ thường tốn kém gấp 2 đến 3 lần so với phát triển mã nguồn mới nếu không có cơ sở dữ liệu quy trình đồng nhất.

Thảo luận kết quả

Sự bất ổn trong các dự án phần mềm chủ yếu xuất phát từ việc thiếu kiểm soát tuyến cơ sở yêu cầu và quản lý cấu hình lỏng lẻo. Khi đối mặt với áp lực tiến độ, các nhà quản lý thường cắt giảm khâu rà soát chất lượng để tập trung viết mã, tạo nên hiện tượng quay tròn bánh xe gây lãng phí nguồn lực. Kết quả nghiên cứu hoàn toàn tương đồng với các công bố quốc tế của Viện SEI, khẳng định rằng việc nâng cao độ trưởng thành quy trình giúp giảm thiểu tới 40% phương sai dự toán ngân sách.

Để trực quan hóa các phát hiện này trong báo cáo quản trị, dữ liệu thực nghiệm có thể được trình bày thông qua Biểu đồ cột so sánh chi phí tiêu hao thời gian giữa rà soát mã nguồn với kiểm thử hệ thống, cùng Bảng phân loại ma trận 18 KPA theo 5 cấp độ trưởng thành. Cách thức trình bày này giúp các nhà quản trị nhận diện trực quan mức độ lãng phí tài chính và định hình rõ lộ trình đầu tư cải tiến quy trình theo từng giai đoạn.

Đề xuất và khuyến nghị

Thứ nhất, thiết lập Nhóm quy trình phần mềm chuyên trách chiếm tỷ lệ 1% đến 3% nhân sự công ty và bộ phận Đảm bảo chất lượng (QA) độc lập chiếm 3% đến 6% tổng số lao động trong vòng 6 tháng đầu. Ban Giám đốc và Trưởng bộ phận Kỹ thuật chịu trách nhiệm phê duyệt cơ chế báo cáo độc lập nhằm đảm bảo tính khách quan trong việc giám sát tuân thủ quy trình tại mọi dự án.

Thứ hai, triển khai chuẩn hóa đồng bộ 6 vùng quy trình then chốt của CMM Mức 2 gồm Quản lý yêu cầu, Lập kế hoạch dự án, Theo dõi giám sát dự án, Quản lý nhà thầu, Đảm bảo chất lượng và Quản lý cấu hình. Mục tiêu cụ thể là giảm tỷ lệ sai lệch ngân sách và tiến độ xuống dưới 15% trong khung thời gian 12 đến 18 tháng, do các Quản trị dự án (PM) và Kỹ sư trưởng trực tiếp chỉ đạo thực thi.

Thứ ba, xây dựng hệ thống cơ sở dữ liệu quy trình tập trung và tự động hóa các công cụ đo lường chỉ số kỹ thuật như kích thước dòng mã, nỗ lực thực tế và mật độ lỗi phát sinh. Giải pháp này giúp cắt giảm 80% sai sót do thao tác thu thập dữ liệu thủ công trong thời hạn 9 tháng, do Đội ngũ Công nghệ thông tin và Kỹ sư công cụ chịu trách nhiệm vận hành.

Thứ tư, tổ chức các đợt kiểm toán quy trình định kỳ hàng quý và thiết lập cơ chế kiểm định chất lượng thực chất cho các doanh nghiệp hướng tới CMM Mức 4 và Mức 5. Mục tiêu là loại bỏ tối thiểu 90% lỗi tiềm ẩn ngay từ khâu thiết kế kiến trúc, do Hội đồng chất lượng nội bộ phối hợp cùng các Tổ chức kiểm định độc lập tiến hành đánh giá liên tục theo chu kỳ 12 tháng.

Đối tượng nên tham khảo luận văn

Nhóm thứ nhất bao gồm các Tổng Giám đốc (CEO), Giám đốc Khối Công nghệ (CTO) và Lãnh đạo doanh nghiệp phần mềm. Luận văn cung cấp luận cứ thực tiễn và bức tranh tài chính rõ ràng để xây dựng chiến lược nâng cao năng lực cạnh tranh, đầu tư đúng đắn vào bộ phận QA và lộ trình đạt chứng chỉ CMM phục vụ mở rộng thị trường gia công xuất khẩu.

Nhóm thứ hai là các Quản trị dự án (Project Manager) và Trưởng nhóm Kỹ thuật (Technical Lead). Đây là tài liệu hướng dẫn chi tiết giúp các nhà quản lý áp dụng 6 KPA nền tảng của Mức 2 vào việc kiểm soát yêu cầu thay đổi, ước lượng công sức chính xác và hạn chế tối đa nguy cơ vỡ tiến độ dự án.

Nhóm thứ ba là các Chuyên viên Đảm bảo chất lượng (QA/QC) và Kỹ sư cải tiến quy trình (Process Engineer). Tài liệu cung cấp hệ thống biểu mẫu, quy trình rà soát lỗi và phương pháp thu thập dữ liệu đo lường giúp chuẩn hóa tài liệu nội bộ theo tiêu chuẩn quốc tế một cách thực chất.

Nhóm thứ tư là các Giảng viên, Nghiên cứu sinh và Sinh viên chuyên ngành Công nghệ thông tin và Kỹ nghệ phần mềm. Luận văn đóng vai trò như một tài liệu tham khảo học thuật chuyên sâu về quản lý chất lượng phần mềm, làm tiền đề nghiên cứu mở rộng cho các mô hình CMMI, Agile và DevOps hiện đại.

Câu hỏi thường gặp

Mô hình CMM có điểm gì khác biệt cốt lõi so với hệ thống tiêu chuẩn ISO 9001? ISO 9001 là tiêu chuẩn quản lý áp dụng cho mọi ngành nghề, chỉ đưa ra các yêu cầu khái quát về những việc cần làm mà không chỉ ra cách làm cụ thể. Ngược lại, CMM được thiết kế chuyên biệt cho ngành phần mềm, cung cấp 18 KPA với các chỉ dẫn thực hành tốt nhất qua 5 cấp độ tiến hóa giúp tổ chức nâng cao năng lực từng bước.

Tại sao doanh nghiệp phần mềm ở Mức 1 cần ưu tiên hoàn thiện Mức 2 trước khi áp dụng công nghệ mới? Tại Mức 1, quy trình làm việc rất hỗn độn và phụ thuộc vào nỗ lực cá nhân. Việc đưa công nghệ mới vào một môi trường thiếu kỷ luật sẽ chỉ làm tăng rủi ro thất bại. CMM Mức 2 giúp thiết lập sự ổn định trong quản lý lịch biểu, chi phí và cam kết, tạo nền tảng vững chắc để công nghệ mới phát huy giá trị.

Hiệu quả kinh tế của hoạt động rà soát sớm so với kiểm thử hệ thống được thể hiện như thế nào? Dữ liệu thực nghiệm chứng minh việc tìm và sửa một lỗi thông qua rà soát thiết kế hoặc soi mã nguồn chỉ mất từ 1 đến 4 giờ làm việc. Trong khi đó, việc sửa lỗi trong giai đoạn kiểm thử hệ thống đòi hỏi từ 5 đến 20 giờ làm việc, giúp tổ chức tiết kiệm khoảng 75% chi phí xử lý sai sót.

Quy mô nhân sự tối ưu cho nhóm quy trình và bộ phận đảm bảo chất lượng là bao nhiêu? Theo hướng dẫn của mô hình, nhóm quy trình phần mềm chuyên trách nên chiếm khoảng 1% đến 3% tổng nhân sự tổ chức (khoảng 4 chuyên gia cho nhóm nòng cốt). Song song đó, bộ phận QA độc lập cần chiếm tỷ lệ từ 3% đến 6% quy mô nhân sự để thực hiện giám sát tuân thủ hiệu quả.

Việc tuân thủ mô hình CMM có làm suy giảm tính linh hoạt và tính sáng tạo của kỹ sư phần mềm không? CMM chỉ định nghĩa các mục tiêu quy trình cần đạt được chứ không bắt buộc áp dụng một phương pháp luận phát triển cố định. Doanh nghiệp hoàn toàn có thể kết hợp linh hoạt CMM với các mô hình phát triển nhanh như RAD, Mô hình xoắn hay Lập trình cực đoan nhằm vừa giữ vững kỷ luật vừa phát huy tối đa tính sáng tạo.

Kết luận

• Luận văn hệ thống hóa toàn diện cơ sở lý luận về quản lý quy trình phần mềm và cấu trúc 5 cấp độ trưởng thành của mô hình SW-CMM.
• Làm rõ vai trò xương sống của 18 vùng quy trình then chốt (KPA) trong việc kiểm soát cam kết về chi phí, chất lượng và thời hạn bàn giao sản phẩm.
• Cung cấp bằng chứng định lượng khẳng định hoạt động rà soát sớm giúp tiết kiệm từ 75% đến 80% thời gian sửa lỗi so với kiểm thử muộn ở giai đoạn cuối.
• Đánh giá chân thực các rào cản nội tại của ngành phần mềm Việt Nam và đề xuất cơ cấu phân bổ nhân sự cho nhóm quy trình từ 1% đến 3% và nhóm QA từ 3% đến 6%.
• Định hình khung giải pháp ứng dụng CMM khả thi theo lộ trình từ 12 đến 24 tháng, giúp doanh nghiệp trong nước nâng cao năng lực cạnh tranh trên thị trường quốc tế.

Đóng góp khoa học và thực tiễn lớn nhất của luận văn là đã chuyển hóa khung lý thuyết CMM phức tạp thành bộ giải pháp triển khai thực tế, phù hợp với đặc thù nguồn lực của các công ty phần mềm Việt Nam. Để tối ưu hóa quy trình sản xuất và nâng cao năng suất dự án, các nhà quản lý và chuyên gia công nghệ nên tải và nghiên cứu toàn văn luận văn ngay hôm nay.

Trích đoạn nội dung tài liệu

CHƯƠNG I TỔNG QUAN CÁC MÔ HÌNH PHÁT TRIỂN PHẦN MỀM Cũng nhƣ mọi ngành sản xuất khác, qui trình là một trong những yếu tố cực kỳ quan trọng đem lại sự thành công cho các nhà sản xuất phần mềm, nó giúp cho mọi thành viên trong dự án từ ngƣời cũ đến ngƣời mới, trong hay ngoài công ty đều có thể xử lý đồng bộ công việc tƣơng ứng vị trí của mình thông qua cách thức chung của công ty, hay ít nhất ở cấp độ dự án. Có thể nói qui trình phát triển/xây dựng phần mềm (Software Development/Engineering Process - SEP) có tính chất quyết định để tạo ra sản phẩm chất luợng tốt với chi phí thấp và năng suất cao, điều này có ý nghĩa quan trọng đối với các công ty sản xuất hay gia công phần mềm củng cố và phát triển cùng với nền công nghiệp phần mềm đầy cạnh tranh. Trong chƣơng này sẽ giới thiệu một cách tổng quát các mô hình áp dụng khi xây dựng qui trình phát triển phần mềm chung cho cấp tổ chức hay cấp dự án. Khái niệm quy trình Qui trình có thể hiểu là phƣơng pháp thực hiện hoặc sản xuất ra sản phẩm.

Tƣơng tự nhƣ vậy, SEP chính là phƣơng pháp phát triển hay sản xuất ra sản phẩm phần mềm. Thông thƣờng một qui trình bao gồm những yếu tố cơ bản sau: Hình 1. 1 Quy trình phát triển phần mềm  Thủ tục (Procedures)  Hƣớng dẫn công việc (Activity Guidelines)  Biểu mẫu (Forms/templates)  Danh sách kiểm định (Checklists) 9 LUAN VAN CHAT LUONG download : add [e-mail] Quản lý quy trình phần mềm theo mô hình CMM- Thực tiễn và ứng dụng ở Việt Nam  Công cụ hỗ trợ (Tools) Với các nhóm công việc chính:  Đặc tả yêu cầu (Requirements Specification): chỉ ra những “đòi hỏi” cho cả các yêu cầu chức năng và phi chức năng.  Phát triển phần mềm (Development): tạo ra phần mềm thỏa mãn các yêu cầu đƣợc chỉ ra trong “Đặc tả yêu cầu”.

 Kiểm thử phần mềm (Validation/Testing): để bảo đảm phần mềm sản xuất ra đáp ứng những “đòi hỏi” đƣợc chỉ ra trong “Đặc tả yêu cầu”.  Thay đổi phần mềm (Evolution): đáp ứng nhu cầu thay đổi của khách hàng. Tùy theo mô hình phát triển phần mềm, các nhóm công việc đƣợc triển khai theo những cách khác nhau. Để sản xuất cùng một sản phẩm phần mềm ngƣời ta có thể dùng các mô hình khác nhau.

Tuy nhiên không phải tất cả các mô hình đều thích hợp cho mọi ứng dụng. 2 : Mô hình Waterfall 10 LUAN VAN CHAT LUONG download : add [e-mail] Quản lý quy trình phần mềm theo mô hình CMM- Thực tiễn và ứng dụng ở Việt Nam 2. SEP, ISO, CMM/CMMI (CMM/CMMI-Capability Maturity Model/Integration- Mô hình trƣởng thành khả năng) Phần 2 này sẽ không đi sâu vào tìm hiểu các mô hình phát triển phần mềm mà chỉ cung cấp một cái nhìn tổng quát về chúng, cũng nhƣ mối quan hệ giữa SEP với ISO và CMM/CMMI để có thể mô tả kỹ hơn CMM ở chƣơng sau. Vấn đề đƣợc đặt ra là làm thế nào cải tiến qui trình để cải thiện chất lƣợng và năng suất? Câu trả lời chính là qui trình khung (Process Framework - PF).

PF sẽ chỉ ra những yêu cầu mà một qui trình phải đáp ứng tùy theo mỗi mức độ. PF không chỉ ra bất kỳ một qui trình cụ thể nào mà chỉ đƣa ra những yêu cầu ở mỗi mức độ trƣởng thành khác nhau của qui trình phải đạt đƣợc. Đây chính là những hƣớng dẫn cho các hoạt động cải tiến để nâng mức độ trƣởng thành từ thấp lên cao. Có nhiều PF, nhƣng phổ biến nhất là ISO và CMM (Capability Maturity Model) đƣợc các tổ chức thế giới công nhận.

ISO nhắm chung đến nhiều loại tổ chức cả sản xuất lẫn dịch vụ, trong khi CMM đƣợc dành riêng cho các tổ chức phát triển phần mềm. Đối với phần mềm, ISO chỉ ra mức độ chất lƣợng yêu cầu tối thiểu mà một SEP phải đạt (ISO certified) và việc cải tiến qui trình đƣợc thực hiện thông qua qui trình kiểm định, trong khi CMM bao gồm những thực tiễn tốt nhất (best practices) đƣợc tập hợp rút ra từ rất nhiều tổ chức phát triển phần mềm khác nhau và chúng đƣợc tổ chức thành 5 mức độ trƣởng thành khác nhau (Level 1 - Initial, Level 2 - Repeatable, Level 3 - Defined, Level 4 - Managed, Level 5 - Optimizing). Ngày nay, phần mềm không đứng riêng một mình mà thƣờng là một bộ phận trong hệ thống hoàn chỉnh. Do đó, CMMI (Capability Maturity Model Integration) ra đời hƣớng đến các qui trình cho việc xây dựng cả hệ thống, bao gồm cả việc tích hợp để xây dựng và bảo trì toàn bộ hệ thống.

Sự khác nhau giữa ISO 9001 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 11 LUAN VAN CHAT LUONG download : add [e-mail] Quản lý quy trình phần mềm theo mô hình CMM- Thực tiễn và ứng dụng ở Việt Nam 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 PM nhƣ CMM/CMMI.

ISO không cung cấp các ví dụ và kinh nghiệm cụ thể nhƣ CMM/CMMI. Các mô hình SEP Mô hình SEP còn đƣợc gọi là chu trình hay vòng đời phần mềm (SLC - Software Life Cycle). SLC là tập hợp các công việc và quan hệ giữa chúng với nhau diễn ra trong quá trình phát triển phần mềm. Có khá nhiều mô hình SLC khác nhau, trong đó một số đƣợc ứng dụng khá phổ biến trên thế giới: Các mô hình một phiên bản (Single-version models)  Mô hình Waterfall (Waterfall model)  Mô hình chữ V (V-model) Các mô hình nhiều phiên bản (Multi-version models)  Mô hình mẫu (Prototype)  Mô hình tiến hóa (Evolutionary)  Mô hình lặp và tăng dần (Iterative and Incremental)  Mô hình phát triển ứng dụng nhanh (RAD)  Mô hình xoắn (Spiral) 12 LUAN VAN CHAT LUONG download : add [e-mail] Quản lý quy trình phần mềm theo mô hình CMM- Thực tiễn và ứng dụng ở Việt Nam Hình 1.1 Mô hình Thác nước (Waterfall) Mô hình này gồm các giai đoạn xử lý nối tiếp nhau nhƣ đƣợc mô tả trong Hình 1.

Phân tích yêu cầu và tài liệu đặc tả (Requirements and Specifications): là giai đoạn xác định những “đòi hỏi” (“What”) liên quan đến chức năng và phi chức năng mà hệ thống phần mềm cần có. Giai đoạn này cần sự tham gia tích cực của khách hàng và kết thúc bằng một tài liệu đƣợc gọi là “Bản đặc tả yêu cầu phần mềm” hay SRS (software requirement specification), trong đó bao gồm tập hợp các yêu cầu đã đƣợc duyệt (reviewed) và nghiệm thu (approved) bởi những ngƣời có trách nhiệm đối với dự án (từ phía khách hàng). SRS chính là nền tảng cho các hoạt động tiếp theo cho đến cuối dự án. Phân tích hệ thống và thiết kế (System Analysis and Design): là giai đoạn định ra “làm thế nào” (“How”) để hệ thống phần mềm đáp ứng những “đòi hỏi” (“What”) 13 LUAN VAN CHAT LUONG download : add [e-mail] Quản lý quy trình phần mềm theo mô hình CMM- Thực tiễn và ứng dụng ở Việt Nam mà khách hàng yêu cầu trong SRS.

Đây là chính là cầu nối giữa “đòi hỏi” (“What”) và mã (Code) đƣợc hiện thực để đáp ứng yêu cầu đó. Hiện thực và kiểm thử từng thành phần (Coding and Unit Test): là giai đoạn hiện thực “làm thế nào” (“How”) đƣợc chỉ ra trong giai đoạn “Phân tích hệ thống và thiết kế”. Một khâu kiểm thử cuối cùng thƣờng đƣợc thực hiện là nghiệm thu (acceptance test), với sự tham gia của khách hàng trong vai trò chính để xác định hệ thống phần mềm có đáp ứng yêu cầu của họ hay không. Cài đặt và bảo trì (Deployment and Maintenance): đây là giai đoạn cài đặt, cấu hình và huấn luyện khách hàng.

Giai đoạn này sửa chữa những lỗi của phần mềm (nếu có) và phát triển những thay đổi mới đƣợc khách hàng yêu cầu (nhƣ sửa đổi, thêm hay bớt chức năng/đặc điểm của hệ thống). Thực tế cho thấy đến những giai đoạn sau mới có khả năng nhận ra sai sót trong những giai đoạn trƣớc và phải quay lại để sửa chữa. Đây chính là kiểu waterfall dạng lặp (Iterative Waterfall) và đƣợc minh hoạ trong Hình 1. Mô hình chữ V Trong mô hình Waterfall, kiểm thử đƣợc thực hiện trong một giai đoạn riêng biệt.

Còn với mô hình chữ V, toàn bộ qui trình đƣợc chia thành hai nhóm giai đoạn tƣơng ứng nhau: phát triển và kiểm thử. Mỗi giai đoạn phát triển sẽ kết hợp với một giai đoạn kiểm thử tƣơng ứng nhƣ đƣợc minh họa trong Hình 2. 4 : Mô hình Prototype Tinh thần chủ đạo của V-model là các hoạt động kiểm thử phải đƣợc tiến hành song song (theo khả năng có thể) ngay từ đầu chu trình cùng với các hoạt động phát triển. Ví dụ, các hoạt động cho việc lập kế hoạch kiểm thử toàn hệ thống có thể đƣợc thực hiện song song với các hoạt động phân tích và thiết kế hệ thống.

14 LUAN VAN CHAT LUONG download : add [e-mail] Quản lý quy trình phần mềm theo mô hình CMM- Thực tiễn và ứng dụng ở Việt Nam 3. Mô hình mẫu Mô hình mẫu (prototype) đƣợc minh hoạ trong Hình 3. Trong đó, qui trình đƣợc bắt đầu bằng việc thu thập yêu cầu với sự có mặt của đại diện của cả phía phát triển lẫn khách hàng nhằm định ra mục tiêu tổng thể của hệ thống phần mềm sau này, đồng thời ghi nhận tất cả những yêu cầu có thể biết đƣợc và sơ luợc những nhóm yêu cầu nào cần phải đƣợc làm rõ. Sau đó, thực hiện thiết kế nhanh tập trung chuyển tải những khía cạnh thông qua prototype để khách hàng có thể hình dung, đánh giá giúp hoàn chỉnh yêu cầu cho toàn hệ thống phần mềm.

Việc này không những giúp tinh chỉnh yêu cầu, mà đồng thời giúp cho đội ngũ phát triển thông hiểu hơn những gì cần đƣợc phát triển. Tiếp theo sau giai đoạn làm prototype này có thể là một chu trình theo mô hình waterfall hay cũng có thể là mô hình khác. Chú ý, prototype thƣờng đƣợc làm thật nhanh trong thời gian ngắn nên không đƣợc xây dựng trên cùng môi trƣờng và công cụ phát triển của giai đoạn xây dựng phần mềm thực sự sau này.