Mô hình kiểm tra phần mềm TMM

MÔ HÌNH KIỂM TRA PHẦN MỀM TMM (TESTING MATURITY MODEL)Mặc dù không ít người trong cũng như ngoài ngành biết hoặc đã từng nghe về mô hình CMM/CMMi (Capability Maturity Model/Intergration) của SEI (Software Engineering Institute – Viện công nghệ phần mềm của Mỹ) dùng để đánh giá và nâng cao năng lực PTPM, song có lẽ ít người biết về TMM - mô hình được các chuyên gia đánh giá là khá tốt – được dùng để đánh giá và nâng cao năng lực KTPM của một tổ chức.

TMM thực ra không mới, phần lớn nội dung của mô hình này đã được phát triển từ năm 1996, tuy nhiên chúng không được chấp nhận rộng rãi. Một trong những lý do chính đó là tài liệu về TMM rất ít. Các bài báo, sách về nó thường được viết dưới dạng nặng về lý thuyết. Một lý do nữa là phần lớn các tổ chức đều “say mê” mô hình CMM/CMMi và nghĩ rằng quá đủ cho qui trình PTPM của mình.

Thực tế cho thấy không hoàn toàn như vậy.

KTPM là một bộ phận sống còn của quy trình PTPM, sự hỗ trợ quan trọng để đảm bảo chất lượng của PM. Nhiều tổ chức PM trong thực tế vẫn chưa nhận thấy tính non nớt yếu kém trong quy trình cũng như năng lực KTPM của họ. Các mô hình hàng đầu hiện nay như CMM/CMMi/ISO9000 thực tế vẫn không chú tâm đầy đủ vào các vần đề của KTPM.

TMM được phát triển tại IIT (Illinois Institute of Technology – Viện công nghệ Illinois) vào giữa thập niên 90 trong bối cảnh hầu như chưa có quy trình PM nào đề cập một cách toàn diện vấn đề kiểm tra trong PTPM. Tương tự SW-CMM, nó có một cấu trúc cơ bản bao gồm 5 mức trưởng thành. Vì TMM là mô hình chuyên biệt cho lĩnh vực KTPM, các mức trưởng thành này trực tiếp mô tả các mục tiêu trưởng thành của một quy trình KTPM. Trong một tổ chức PM, TMM không mâu thuẫn mà có thể dùng độc lập hoặc phối hợp với CMM/CMMi.

Mục đích của TMM là hỗ trợ tổ chức PM đánh giá và cải tiến các quy trình và năng lực PM của mình, mục tiêu cuối cùng là giúp tổ chức có thể:

• Hoàn thành sản phẩm đúng hạn và trong phạm vi ngân sách đã định.

• Tạo ra sản phẩm phần mềm có chất lượng cao hơn.

• Xây dựng nền tảng cho việc cải tiến quy trình ở phạm vi rộng trong một tổ chức.

TMM bao gồm hai thành phần chính:1. Tập hợp 5 mức độ trưởng thành, định nghĩa năng lực KTPM của một tổ chức. Mỗi mức độ bao gồm:

a. Mục tiêu

b. Hoạt động để hiện thực các mục tiêu

c. Công việc và phân công trách nhiệm

2. Mô hình đánh giá năng lực KTPM của một tổ chức, bao gồm:

a. Bảng câu hỏi đánh giá

b. Thủ tục tiến hành đánh giá

c. Hướng dẫn để chọn lựa và huấn luyện nhóm đánh giá.

Phần sau ta sẽ khảo sát rõ hơn về các mức độ trưởng thành của TMM

Cấu trúc của một mức trưởng thànhCác mức trưởng thành cấu thành TMM, vậy bản thân một mức trưởng thành là gì và cấu trúc của nó ra sao? (Hình 07).

Mỗi mức độ, ngoại trừ mức độ thấp nhất là 1, có cấu trúc bao gồm các thành phần sau:

• Mục tiêu trưởng thành: Xác định các mục tiêu cần phải đạt trong việc cải tiến quy trình KTPM. Để đạt một mức trưởng thành, tổ chức phải đạt tất cả các mục tiêu của mức trưởng thành đó.

• Mục tiêu con: Các mục tiêu trưởng thành đã nói ở trên có tầm bao quát rộng. Do vậy để làm rõ hơn phạm vi cũng như những công việc cần làm để đạt được một mục tiêu, mỗi mục tiêu lại được mô tả rõ hơn thông qua những mục tiêu con, dễ hiểu và cụ thể hơn. Nếu ta đạt được tất cả mục tiêu con của một mục tiêu nghĩa là ta đã đạt được mục tiêu đó.

• Công việc và trách nhiệm: Mô tả rõ hơn các công việc cần làm, cũng như ai trong dự án (trưởng dự án, lập trình viên, kiểm tra viên…) sẽ thực hiện các công việc đó. Nghĩa là, để đạt được một mục tiêu con, ta cần thực hiện tất cả các công việc được đề nghị cho mục tiêu con đó.

• Sự tham gia của các nhóm khác nhau: TMM cho rằng có 3 nhóm người quan trọng với cách nhìn và quan điểm khác nhau ảnh hưởng đến công việc KTPM, đó là người quản lý/quản lý dự án, lập trình viên/kiểm tra viên, và khách hàng/người sử dụng. Do vậy mô hình TMM yêu cầu các công việc phải được phân trách nhiệm cho 3 nhóm người này.Ý nghĩa và tổ chức của các mức trưởng thành5 mức độ trưởng thành do TMM quy định được xác định như hình 08.

Mức trưởng thành 1: Khởi đầuMức khởi đầu của đa số tổ chức PM, không có mục tiêu nào đặt ra cho mức này. Quy trình KTPM hoàn toàn hỗn độn. KTPM được thực hiện một cách không dự tính và phi thể thức sau khi code được viết xong; không có kế hoạch, không có quy trình. Nói chung ở mức này KTPM đồng nghĩa với tìm lỗi (debugging). Một lập trình viên viết code và sau đó tìm lỗi, sửa chữa, dò lỗi… cho đến khi tin rằng mọi thứ đạt yêu cầu. Kiểm tra viên không được huấn luyện, tài nguyên cần thiết cũng không đầy đủ.

Do hầu như chỉ có lập trình viên làm mọi thứ, chi phí kiểm tra hầu như không biết trước hoặc được bao gồm trong chi phí PTPM.

Mức trưởng thành 2: Định nghĩaKTPM là một quy trình riêng biệt, là một chặng của toàn bộ chu trình PTPM và hoàn toàn phân biệt với công việc dò tìm lỗi (debug). Mục tiêu của kiểm tra nhằm chứng minh PM hoặc hệ thống đáp ứng được các yêu cầu.

KTPM được lập kế hoạch chi tiết và được theo dõi chặt chẽ. Quy trình kiểm tra có thể được sử dụng lặp lại trong các dự án khác nhau. Kế hoạch kiểm tra thường được hoàn thành sau khi đã xong giai đoạn viết code. Kỹ thuật và phương pháp kiểm tra cơ bản được thiết lập và đưa vào sử dụng. Các mục tiêu của mức 2 bao gồm:

• Phát triển các mục tiêu dò lỗi và kiểm tra phần mềm

• Quy trình lập kế hoạch kiểm tra

• Thể chế hóa các kỹ thuật và phương pháp kiểm tra cơ bản

So sánh mức 2 giữa TMM và CMM:

Mức trưởng thành 3: Tích hợpMột nhóm kiểm tra viên được thành lập như một bộ phận trong công ty. Kiểm tra viên được huấn luyện kỹ và đặc biệt. KTPM không còn là một chặng, mà được thực hiện xuyên suốt toàn bộ chu kỳ PTPM. Việc sử dụng công cụ kiểm tra tự động bắt đầu được tính đến. Kế hoạch kiểm tra được thực hiện sớm hơn nhiều so với mức trưởng thành 2. Quy trình kiểm tra được giám sát, tiến độ và hiệu quả kiểm tra được kiểm soát chặt chẽ. Mục tiêu của mức 3 bao gồm:

• Thiết lập bộ phận KTPM

• Thiết lập chương trình huấn luyện kỹ thuật

• Tích hợp KTPM vào chu kỳ PTPM

• Kiểm soát và giám sát quy trình kiểm tra

So sánh mức 3 giữa TMM và CMM:

Mức trưởng thành 4: Quản lý và đo lườngMột chương trình xem xét cấp công ty được thành lập với mục tiêu loại bỏ sai sót trong sản phẩm kể cả sản phẩm trung gian bằng kỹ thuật xem xét ngang hàng (peer review – kỹ thuật phổ biến để phát hiện lỗi sớm trên các sản phẩm và sản phẩm trung gian không thi hành được như yêu cầu khách hàng, bản thiết kế, mã nguồn, kế hoạch kiểm tra… được thực hiện bởi một nhóm người cùng làm việc).

Quy trình kiểm tra là một quy trình định lượng. Các chỉ số liên quan đến KTPM được định nghĩa và thu thập nhằm phân tích, khảo sát chất lượng và hiệu quả của quy trình kiểm tra. Một số ví dụ về các chỉ số này như: tỷ lệ lỗi trên một đơn vị kích thước PM, số lượng lỗi do kiểm tra viên tìm thấy trên tổng số lỗi của PM (bao gồm lỗi do khách hàng phát hiện), thời gian trung bình để sửa chữa một lỗi… Mục tiêu của mức 4 bao gồm:

• Thiết lập chương trình xem xét xuyên suốt các dự án trong công ty

• Thiết lập chương trình đo lường việc KTPM

• Đánh giá chất lượng PM

So sánh mức 4 giữa TMM và CMM

Mức trưởng thành 5: Tối ưu hóa, phòng ngừa lỗi và kiểm soát chất lượngDữ liệu liên quan đến các sai sót đã thu thập (ở mức 4) được phân tích để tìm ra nguyên nhân gốc phát sinh các sai sót đó. Căn cứ vào các nguyên nhân này, hành động phòng ngừa được thiết lập và thi hành. Các phép thống kê được dùng để ước lượng tính tin cậy của phần mềm, cũng như làm cơ sở cho các quyết định liên quan đến xác định các mục tiêu về độ tin cậy của phần mềm. Chi phí và tính hiệu quả của KTPM được giám sát chặt chẽ, công cụ kiểm tra tự động được sử dụng rộng rãi.

Mặt khác, ở mức 5, quy trình KTPM phải được cải tiến một cách liên tục, nhằm khắc phục những yếu kém của quy trình, cũng như hướng đến những mục tiêu xa hơn. Mục tiêu của mức 5 bao gồm:

• Sử dụng dữ liệu thu thập để phòng ngừa sai sót.

• Kiểm soát chất lượng

• Tối ưu hóa quy trình KTPM

So sánh mức 5 giữa TMM và CMM:

KẾT LUẬNKTPM là một lĩnh vực rất quan trọng trong hoạt động sản xuất cũng như gia công PM. Các mức kiểm tra và loại kiểm tra rất phong phú, phục vụ mục tiêu đảm bảo chất lượng toàn diện cho một PM hoặc một hệ thống. Trong thực tế, để triển khai tất cả các mức và loại kiểm tra đã liệt kê cho một dự án PM đòi hỏi sự đầu tư rất lớn cả về thời gian lẫn công sức. Các tổ chức “còn non” trong quy trình kiểm tra thường cố gắng tiết kiệm tối đa đầu tư vào KTPM, thường lờ việc lập kế hoạch kiểm tra đến khi hoàn thành việc viết code, bỏ qua một vài hoặc hầu hết các chặng kiểm tra. PM giao cho khách hàng trong điều kiện như thế thường nghèo nàn về chất lượng. Kết quả thường là sự đột biến về chi phí bỏ ra cho việc sữa chữa lỗi, hoặc bảo trì PM, tuy nhiên sự mất mát lớn nhất là sự thất vọng của khách hàng hoặc những người dùng cuối.

Năm mức độ trưởng thành trong TMM

Mẫu quy trình kiểm thử phần mềm:

1.1 Mục đích

Tài liệu này mô tả các bước công việc, trình tự thực hiện việc kiểm tra hệ thống phần mềm từ khi có yêu cầu kiểm tra cho đến khi sản phẩm được thông báo phát hành, nhằm mục đích:

• Đảm bảo chất lượng phần mềm đúng theo yêu cầu và tiêu chuẩn thiết kế, chuyển giao cho khách hàng những sản phẩm đạt chất lượng.

• Chuẩn hóa và chuyên nghiệp hóa quá trình đảm bảo chất lượng phần mềm.

• Giảm rủi ro và chi phí trong quá trình phát triển phần mềm.

1.2 Phạm vi áp dụng

Áp dụng cho nhóm đảm bảo chất lượng phần mềm trong quá trình thực hiện việc kiểm tra hệ

thống phần mềm.

1.3 Tài liệu liên quan

• MTQT: Quy trình phát triển phần mềm ESDM.

• HDCV: Thuật ngữ ESDM.

• MTSP: Mô tả tài liệu sản phẩm phần mềm.

• MTCV: Các mô tả công việc của nhóm đảm bảo chất lượng (PQA).

• Biểu mẫu: Kế hoạch kiểm tra phần mềm.

• Biểu mẫu: Tình huống kiểm tra phần mềm.

• Biểu mẫu: Kết quả kiểm tra hệ thống phần mềm.

• Biểu mẫu: Thông báo phát hành phần mềm.

• Biểu mẫu: Tài liệu hướng dẫn sử dụng

• Biểu mẫu : Biên bản ghi nhận môi trường kiểm tra

• Biểu mẫu – Kế hoạch công việc, báo cáo công việc, biên bản họp…

1.4 Định nghĩa, thuật ngữ

DMS (Defect Management System): Hệ thống/công cụ quản lý lỗi

PQA (Product Quality Asurrance): Đảm bảo chất lượng sản phẩ

3 Thông tin chung

3.1 Điều kiện bắt đầu/kết thúc

3.1.1 Đ i ều kiện b ắ t đầu

Khi có yêu cầu kiểm tra hệ thống phần mềm

3.1.2 Đ i ều kiện k ế t thúc

Thông báo phát hành sản phẩm phần mềm

3.2 Thông tin đầu vào/kết quả

3.2.1 Thông tin đ ầ u v ào

• Kế hoạch dự án

• Tài liệu SRS

• Tài liệu HLD

• Prototype

• Tài liệu mô tả nghiệp vụ

• Các tài liệu khác liên quan

3.2.2 Kết q uả chính

• Kế hoạch kiểm tra

• Kịch bản kiểm tra

• Tình huống kiểm tra

• Thông báo phát hành phần mềm

• Tài liệu hướng dẫn sử dụng

• Các báo cáo công việc

3.3 Chỉ tiêu chất l ư ợng

• Tỷ lệ thời gian thực hiện/thời gian kế hoạch

• Tỷ lệ nguồn lực thực tế/nguồn lực kế hoạch

• Tỷ lệ lỗi/tổng số chức năng kiểm tra

• Vòng đời trung bình của lỗi (thời gian từ khi phát hiện lỗi cho đến khi lỗi được sửa)