• Thứ Sáu, 10/02/2006 10:24 (GMT+7)

    Hoạt động kiểm tra - Sự sống còn của sản xuất phần mềm (phần 2)

    Trong phần trước chúng tôi đã giới thiệu tổng quan về các mức và loại kiểm tra phần mềm (KTPM) cơ bản. Thực tế đi sâu vào từng mức và loại kiểm tra, còn có rất nhiều kiểm tra đặc thù khác nữa, mang tính chuyên biệt cho từng vấn đề hoặc từng loại ứng dụng. Trong phần này, chúng tôi sẽ giới thiệu chi tiết về những bước cơ bản của một quy trình KTPM, làm thế nào để đánh giá và cải tiến năng lực KTPM của một tổ chức thông qua mô hình TMM (Testing Maturity Model), được các chuyên gia đánh giá khá tốt, dành riêng cho hoạt động KTPM.

    QUY TRÌNH KIỂM TRA PHẦN MỀM CƠ BẢN

    Trước khi tìm hiểu một quy trình kiểm tra phần mềm cơ bản, ta cần hiểu hai khái niệm sau: Test Case và Test Script.

    Test Case

    Một Test Case có thể coi nôm na là một tình huống kiểm tra, được thiết kế để kiểm tra một đối tượng có thỏa mãn yêu cầu đặt ra hay không. Một Test Case thường bao gồm 3 phần cơ bản:

    • Mô tả: đặc tả các điều kiện cần có để tiến hành kiểm tra.

    • Nhập: đặc tả đối tượng hay dữ liệu cần thiết, được sử dụng làm đầu vào để thực hiện việc kiểm tra.

    • Kết quả mong chờ: kết quả trả về từ đối tượng kiểm tra, chứng tỏ đối tượng đạt yêu cầu.

    Test Script

    Một Test Script là một nhóm mã lệnh dạng đặc tả kịch bản dùng để tự động hóa một trình tự kiểm tra, giúp cho việc kiểm tra nhanh hơn, hoặc cho những trường hợp mà kiểm tra bằng tay sẽ rất khó khăn hoặc không khả thi. Các Test Script có thể tạo thủ công hoặc tạo tự động dùng công cụ kiểm tra tự động. (Hình 04)

    Phần sau sẽ giải thích rõ hơn các bước cơ bản của một quy trình kiểm tra.


    Hình 04: Một quy trình kiểm tra cơ bản có thể áp dụng rộng rãi cho nhiều hệ thống PM với những đặc trưng khác nhau.

    Lập kế hoạch kiểm tra

    Mục đích: Nhằm chỉ định và mô tả các loại kiểm tra sẽ được triển khai và thực hiện. Kết quả của bước lập kế hoạch là bản tài liệu kế hoạch KTPM, bao gồm nhiều chi tiết từ các loại kiểm tra, chiến lược kiểm tra, cho đến thời gian và phân định lực lượng kiểm tra viên.

    Bản kế hoạch kiểm tra đầu tiên được phát triển rất sớm trong chu trình phát triển phần mềm (PTPM), ngay từ khi các yêu cầu đã tương đối đầy đủ, các chức năng và luồng dữ liệu chính đã được mô tả. Bản kế hoạch này có thể được coi là bản kế hoạch chính (master test plan), trong đó tất cả các kế hoạch chi tiết cho các mức kiểm tra và loại kiểm tra khác nhau đều được đề cập (hình 05).

    Lưu ý, tùy theo đặc trưng và độ phức tạp của mỗi dự án, các kế hoạch kiểm tra chi tiết có thể được gom chung vào bản kế hoạch chính hoặc được phát triển riêng.

    Sau khi bản kế hoạch chính được phát triển, các bản kế hoạch chi tiết lần lượt được thiết kế theo trình tự thời gian phát triển của dự án. (Hình 06 minh hoạ thời điểm phù hợp để thiết lập các kế hoạch kiểm tra, gắn liền với quá trình phát triển của dự án. Quá trình phát triển các kế hoạch kiểm tra không dừng lại tại một thời điểm, mà liên tục được cập nhật chỉnh sửa cho phù hợp đến tận cuối dự án.).

    Hình 05: Bản kế hoạch chính và các bản kế hoạch chi tiết


    Các bước lập kế hoạch:

    • Xác định yêu cầu kiểm tra: chỉ định bộ phận, thành phần của PM sẽ được kiểm tra, phạm vi hoặc giới hạn của việc kiểm tra. Yêu cầu kiểm tra cũng được dùng để xác định nhu cầu nhân lực.

    • Khảo sát rủi ro: Các rủi ro có khả năng xảy ra làm chậm hoặc cản trở quá trình cũng như chất lượng kiểm tra. Ví dụ: kỹ năng và kinh nghiệm của kiểm tra viên quá yếu, không hiểu rõ yêu cầu.

    • Xác định chiến lược kiểm tra: chỉ định phương pháp tiếp cận để thực hiện việc kiểm tra trên PM, chỉ định các kỹ thuật và công cụ hỗ trợ kiểm tra, chỉ định các phương pháp dùng để đánh giá chất lượng kiểm tra cũng như điều kiện để xác định thời gian kiểm tra.

    • Xác định nhân lực,vật lực: kỹ năng, kinh nghiệm của kiểm tra viên; phần cứng, phần mềm, công cụ, thiết bị giả lập... cần thiết cho việc kiểm tra.

    • Lập kế hoạch chi tiết: ước lượng thời gian, khối lượng công việc, xác định chi tiết các phần công việc, người thực hiện, thời gian tất cả các điểm mốc của quá trình kiểm tra.

    • Tổng hợp và tạo các bản kế hoạch kiểm tra: kế hoạch chung và kế hoạch chi tiết.

    • Xem xét các kế hoạch kiểm tra: phải có sự tham gia của tất cả những người có liên quan, kể cả trưởng dự án và có thể cả khách hàng. Việc xem xét nhằm bảo đảm các kế hoạch là khả thi, cũng như để phát hiện (và sữa chữa sau đó) các sai sót trong các bản kế hoạch.

    Thiết kế Test

    Mục đích: Nhằm chỉ định các Test Case và các bước kiểm tra chi tiết cho mỗi phiên bản PM. Giai đoạn thiết kế test là hết sức quan trọng, nó bảo đảm tất cả các tình huống kiểm tra "quét" hết tất cả yêu cầu cần kiểm tra.

    Hình 06 cho thấy việc thiết kế test không phải chỉ làm một lần, nó sẽ được sửa chữa, cập nhật, thêm hoặc bớt xuyên suốt chu kỳ PTPM, vào bất cứ lúc nào có sự thay đổi yêu cầu, hoặc sau khi phân tích thấy cần được sửa chữa hoặc bổ sung.

    Hình 06: Thời điểm phù hợp để thiết lập các kế hoạch kiểm tra


    Các bước thiết kế test bao gồm:

    • Xác định và mô tả Test Case: xác định các điều kiện cần thiết lập trước và trong lúc kiểm tra. Mô tả đối tượng hoặc dữ liệu đầu vào, mô tả các kết quả mong chờ sau khi kiểm tra.

    • Mô tả các bước chi tiết để kiểm tra: các bước này mô tả chi tiết để hoàn thành một Test Case khi thực hiện kiểm tra. Các Test Case như đã nói ở trên thường chỉ mô tả đầu vào, đầu ra, còn cách thức tiến hành như thế nào thì không được định nghĩa. Thao tác này nhằm chi tiết hóa các bước của một Test Case, cũng như chỉ định các loại dữ liệu nào cần có để thực thi các Test Case, chúng bao gồm các loại dữ liệu trực tiếp, gián tiếp, trung gian, hệ thống...

    • Xem xét và khảo sát độ bao phủ của việc kiểm tra: mô tả các chỉ số và cách thức xác định việc kiểm tra đã hoàn thành hay chưa? bao nhiêu phần trăm PM đã được kiểm tra? Để xác định điều này có hai phương pháp: căn cứ trên yêu cầu của phần mềm hoặc căn cứ trên số lượng code đã viết.

    • Xem xét Test Case và các bước kiểm tra: Việc xem xét cần có sự tham gia của tất cả những người có liên quan, kể cả trưởng dự án nhằm bảo đảm các Test Case và dữ liệu yêu cầu là đủ và phản ánh đúng các yêu cầu cần kiểm tra, độ bao phủ đạt yêu cầu, cũng như để phát hiện (và sữa chữa) các sai sót.

    Phát triển Test Script

    Mục đích: Bước này thường không bắt buộc trong các loại và mức kiểm tra, chỉ yêu cầu trong những trường hợp đặc thù cần thiết kế, tạo ra các Test Script có khả năng chạy trên máy tính giúp tự động hóa việc thực thi các bước kiểm tra đã định nghĩa ở bước thiết kế test.

    Các bước phát triển Test Script bao gồm:

    • Tạo Test Script: thủ công hoặc dùng công cụ hỗ trợ để phát sinh script một cách tự động (tuy nhiên trong hầu hết mọi trường hợp, ta vẫn phải chỉnh sửa ít hoặc nhiều trên các script được sinh tự động). Thông thường, mỗi bước kiểm tra được thiết kế trong phần thiết kế test, đòi hỏi ít nhất một Test Script. Các Test Script có khả năng tái sử dụng càng nhiều càng tốt để tối ưu hóa công việc.

    • Kiểm tra Test script: xem có "chạy" tốt không nhằm bảo đảm các Test Script hoạt động đúng yêu cầu, thể hiện đúng ý đồ của các bước kiểm tra.

    • Thành lập các bộ dữ liệu ngoài dành cho các Test Script: bộ dữ liệu này sẽ được các Test Script sử dụng khi thực hiện kiểm tra tự động. Gọi là "ngoài" vì chúng được lưu độc lập với các Test Script, tránh trường hợp vì dễ dãi, một số kiểm tra viên "tích hợp" luôn phần dữ liệu vào bên trong code của các script (thuật ngữ chuyên môn gọi là "hard-code"). Việc tách riêng dữ liệu cho phép dễ dàng thay đổi dữ liệu khi kiểm tra, cũng như giúp việc chỉnh sửa hoặc tái sử dụng các script sau này.

    • Xem xét và khảo sát độ bao phủ của việc kiểm tra: bảo đảm các Test Script được tạo ra bao phủ toàn bộ các bước kiểm tra theo yêu cầu.

    Thực hiện kiểm tra

    Mục đích: Thực hiện các bước kiểm tra đã thiết kế (hoặc thi hành các Test Script nếu tiến hành kiểm tra tự động) và ghi nhận kết quả.

    Hình 06 cho ta thấy, việc thực hiện kiểm tra cũng được làm rất nhiều lần trong suốt chu trình kiểm tra, cho đến khi kết quả kiểm tra cho thấy đủ điều kiện để dừng hoặc tạm dừng việc thực hiện.

    Quá trình thực hiện kiểm tra thường thông qua các bước sau:

    • Thực hiện các bước kiểm tra: thủ công hoặc thi hành các Test Script nếu là quy trình kiểm tra tự động. Để thực hiện kiểm tra, thao tác đầu tiên cần làm là xác lập và khởi động môi trường và điều kiện kiểm tra. Việc này nhằm bảo đảm tất cả các bộ phận liên quan (như phần cứng, phần mềm, máy chủ, mạng, dữ liệu...) đã được cài đặt và sẵn sàng, trước khi chính thức bắt đầu thực hiện kiểm tra.

    • Đánh giá quá trình kiểm tra: giám sát quá trình kiểm tra suôn sẻ đến khi hoàn thành hay bị treo và dừng giữa chừng, có cần bổ sung hay sữa chữa gì không để quá trình kiểm tra được tốt hơn.

    - Nếu quá trình diễn ra trơn tru, kiểm tra viên hoàn thành chu kỳ kiểm tra và chuyển qua bước "Thẩm định kết quả kiểm tra"

    - Nếu quá trình bị treo hoặc dừng giữa chừng, kiểm tra viên cần phân tích để xác định nguyên nhân lỗi, khắc phục lỗi và lập lại quá trình kiểm tra.

    • Thẩm định kết quả kiểm tra: sau khi kết thúc, kết quả kiểm tra cần được xem xét để bảo đảm kết quả nhận được là đáng tin cậy, cũng như nhận biết được những lỗi xảy ra không phải do PM mà do dữ liệu dùng để kiểm tra, môi trường kiểm tra hoặc các bước kiểm tra (hoặc Test Script) gây ra. Nếu thực sự lỗi xảy ra do quá trình kiểm tra, cần phải sửa chữa và kiểm tra lại từ đầu.

    Đánh giá quá trình kiểm tra

    Mục đích: Đánh giá toàn bộ quá trình kiểm tra, bao gồm xem xét và đánh giá kết quả kiểm tra, liệt kê lỗi, chỉ định các yêu cầu thay đổi, và tính toán các số liệu liên quan đến quá trình kiểm tra (chẳng hạn số giờ, thời gian kiểm tra, số lượng lỗi, phân loại lỗi...).

    Lưu ý, mục đích của việc đánh giá kết quả kiểm tra ở bước này hoàn toàn khác với bước thẩm định kết quả kiểm tra sau khi hoàn tất một vòng kiểm tra. Đánh giá kết quả kiểm tra ở giai đoạn này mang tính toàn cục và nhằm vào bản thân giá trị của các kết quả kiểm tra.

    Hình 06 cho thấy, việc đánh giá quá trình và kết quả kiểm tra được thực hiện song song với bất kỳ lần kiểm tra nào và chỉ chấm dứt khi quá trình kiểm tra đã hoàn tất.

     
    Hình 07: Cấu trúc của một mức trưởng thành trong mô hình TMM
    Đánh giá quá trình kiểm tra thường thông qua các bước sau:

    • Phân tích kết quả kiểm tra và đề xuất yêu cầu sửa chữa: Chỉ định và đánh giá sự khác biệt giữa kết quả mong chờ và kết quả kiểm tra thực tế, tổng hợp và gửi thông tin yêu cầu sửa chữa đến những người có trách nhiệm trong dự án, lưu trữ để kiểm tra sau đó.

    • Đánh giá độ bao phủ: Xác định quá trình kiểm tra có đạt được độ bao phủ yêu cầu hay không, tỷ lệ yêu cầu đã được kiểm tra (tính trên các yêu cầu của PM và số lượng code đã viết).

    • Phân tích lỗi: Đưa ra số liệu phục vụ cho việc cải tiến các qui trình phát triển, giảm sai sót cho các chu kỳ phát triển và kiểm tra sau đó. Ví dụ, tính toán tỷ lệ phát sinh lỗi, xu hướng gây ra lỗi, những lỗi "ngoan cố" hoặc thường xuyên tái xuất hiện.

    • Xác định quá trình kiểm tra có đạt yêu cầu hay không: Phân tích đánh giá để xem các Test Case và chiến lược kiểm tra đã thiết kế có bao phủ hết những điểm cần kiểm tra hay không? Kiểm tra có đạt yêu cầu dự án không? Từ những kết quả này, kiểm tra viên có thể sẽ phải thay đổi chiến lược hoặc cách thức kiểm tra.

    • Báo cáo tổng hợp: Tổng hợp kết quả các bước ở trên và phải được gửi cho tất cả những người có liên quan.

    Tóm lược: Trên đây là tóm tắt các bước cơ bản của một quy trình KTPM. Tùy theo đặc thù của dự án, loại kiểm tra và mức độ kiểm tra, quy trình kiểm tra trong thực tế có thể chi tiết hơn nhiều, tuy nhiên các bước trên là xương sống của bất kỳ quy trình kiểm tra nào.

    Sau đây, chúng tôi sẽ giới thiệu một mô hình giúp các tổ chức đánh giá và nâng cao năng lực KTPM của mình, đó là mô hình TMM (Testing Maturity Model).

    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ành

    Cá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ành

    5 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 đầu

    Mứ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ĩa

    KTPM 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:

       

    TMM Mức 2:
    Định nghĩa

         CMM Mức 2:
    Có thể lặp lại
     
        • Kỹ thuật và phương pháp kiểm tra cơ bản
    • Quy trình lập kế hoạch kiểm tra
    • Mục tiêu dò lỗi và kiểm tra phần mềm
        • Quản lý yêu cầu
    • Lập kế hoạch dự án
    • Giám sát và theo dõi dự án
    • Quản lý thầu phụ
    • Đảm bảo chất lượng
    • Quản lý cấu hình
     

    Mức trưởng thành 3: Tích hợp

    Mộ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:

     

    TMM Mức 3:
    Tích hợp

        CMM Mức 3:
    Được định nghĩa
     
      • Kiểm soát và giám sát quy trình kiểm tra
    • Tích hợp kiểm tra phần mềm
    • Thiết lập chương trình huấn luyện kỹ thuật
    • Thiết lập tổ chức kiểm tra phần mềm
        • Tập trung quy trình cấp tổ chức
    • Định nghĩa quy trình cấp tổ chức
    • Chương trình huấn luyện
    • Tích hợp quản lý phần mềm
    • Kỹ thuật phát triển sản phẩm
    • Điều phối liên nhóm
    • Xem xét ngang hàng
     

    Mức trưởng thành 4: Quản lý và đo lường

    Mộ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

     

    TMM Mức 4:
    Quản lý và đo lường

         CMM Mức 4:
    Được quản lý
     
      • Đánh giá chất lượng phần mềm
    • Đo lường việc kiểm tra phần mềm
    • Chương trình xem xét xuyên dự án
        • Quản lý quy trình theo lượng hóa
    • Quản lý chất lượng phần mềm
     

    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ượng

    Dữ 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:

      TMM Mức 5: Tối ưu hóa, phòng ngừa lỗi và kiểm soát chất lượng     CMM Mức 5:
    Tối ưu hóa
     
      • Phòng ngừa sai sót.
    • Kiểm soát chất lượng
    • Tối ưu hóa quy trình kiểm tra phần mềm
        • Phòng ngừa sai sót.
    • Quản lý thay đổi kỹ thuật/công nghệ
    • Quản lý thay đổi quy trình
     

    KẾT LUẬN

    KTPM 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.

    Hình 08: 5 mức độ trưởng thành trong TMM


    Ngô Văn Toàn
    Công ty Global CyberSoft Vietnam

    Tài liệu tham khảo:
    1. Practical Software Testing – A Process-Oriented Approach - Ilene Burnstein - 2003 Springer-Verlag New York, Inc.
    2. Software Process Maturity Model Study - Michael Grottke
    3. Rational Unified Process - Version 2001.03.00
    4. Using SW-TMM to Improve the Testing Process - Thomas C. Staab - Wind Ridge International
    5. Automated Web Testing Toolkit - Diane Stottlemyer – 2001 John Wiley & Sons, Inc.

    ID: A0601_96