Quản lý chất lượng phần mềm – Phần đầu

Quản lý chất lượng phần mềm là vấn đề không mới nhưng theo một số đánh giá là còn yếu của các công ty phần mềm Việt Nam. Một số công ty trong nước hiện đã đạt các 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 chỉ đếm được trên đầu ngón tay, và hiện cũng chỉ gói gọn trong vài công ty gia công cho thị trường nước ngoài. Làm thế nào để một công ty này đạt được chuẩn quốc tế về chất lượng phần mềm? Mỗi công ty đều có đặc thù riêng, tuy nhiên điều chung nhất là họ đều phải phát triển và duy trì một Hệ thống quản lý chất lượng phần mềm.

QUẢN LÝ CHẤT LƯỢNG PHẦN MỀM LÀ GÌ ?

Lâu nay, nói đến chất lượng phần mềm (PM), không ít người nghĩ ngay đến vấn đề là xác định xem PM đó có phát sinh lỗi hay không, có “chạy” đúng như yêu cầu hay không và cuối cùng thường quy về vai trò của hoạt động kiểm tra phần mềm (testing) như là hoạt động chịu trách nhiệm chính.

Với quan điểm của khách hàng, điều này có thể đúng, họ không cần quan tâm nội tình của hoạt động phát triển PM, điều họ cần quan tâm là liệu sản phẩm cuối cùng giao cho họ có đúng hạn hay không và làm việc đúng như họ muốn hay không.

Tuy nhiên theo quan điểm của người phát triển PM, thực tế cho thấy hoạt động kiểm tra PM là quan trọng, nhưng không đủ để đảm bảo sản phẩm sẽ được hoàn thành đúng hạn và đúng yêu cầu. Kiểm tra sau cùng để phát hiện lỗi là điều tất nhiên phải làm, nhưng trong rất nhiều trường hợp, điều đó thường quá trễ và sẽ phải mất rất nhiều thời gian để sửa chữa.

Đăng ký ngay

Đăng ký ngay

Thực tế cho thấy, để đảm bảo được hai tiêu chí “đơn giản” trên của khách hàng, đòi hỏi tổ chức không chỉ vận hành tốt khâu kiểm tra PM, mà phải tổ chức và duy trì sự hoạt động nhịp nhàng của cả một hệ thống các công việc liên quan đến một dự án PM, từ đây xuất hiện một khái niệm có tên là “hệ thống quản lý chất lượng phần mềm” (HTQLCLPM), bao gồm các quy trình được thực thi xuyên suốt chu kỳ phát triển của dự án PM.

Hiện có nhiều mô hình cung cấp các tiêu chuẩn cũng như hướng dẫn để triển khai HTQLCLPM. Hai trong số những mô hình được áp dụng rộng rãi hiện nay là ISO 9001-2000 và CMM/CMMi. Trong khi ISO 9001-2000 là tiêu chuẩn quản lý chất lượng dành cho tất cả các ngành nghề với những điều khoản ngắn gọn và mang tính tổng quát, thì CMM/CMMi là một bộ tập hợp khá đồ sộ các kinh nghiệm thực hành (gần 450 trang với CMM, và gần 700 trang với CMMi) có thể làm người đọc chưa có kinh nghiệm khó biết được các hoạt động và yếu tố đặc trưng cơ bản của HTQLCLPM là gì.

Qua một số tài liệu tham khảo, cũng như bằng kinh nghiệm bản thân khi nghiên cứu và ứng dụng ISO 9001-2000 và CMM/CMMi, chúng tôi sẽ trình bày các khái niệm, hoạt động cũng như yếu tố cơ bản cấu thành HTQLCLPM.

CĂN BẢN VỀ HTQLCLPM

Một HTQLCLPM thường có 2 mục tiêu (hình 1):

Một HTQLCLPM hoàn chỉnh bao gồm rất nhiều hoạt động và bộ phận cấu thành, chúng khác nhau tùy theo từng tổ chức khi triển khai. Tuy nhiên, theo kinh nghiệm, chúng tôi chỉ giới thiệu 10 hoạt động và yếu tố cơ bản nhất thường gặp:

(Để đơn giản, từ đây, “10 hoạt động và yếu tố” được gọi tắt là “10 yếu tố”)

Có mối liên hệ giữa 10 yếu tố cơ bản trên và các giai đoạn hay pha phát triển PM. Hình 2 cho thấy sơ đồ liên hệ trong mô hình phát trình waterfall. Ký hiệu “x” giao nhau giữa một yếu tố và một pha biểu thị yếu tố được thực hiện tại pha đó. Phần sau đây sẽ làm rõ ý nghĩa của 10 yếu tố cơ bản.

1. Các tiêu chuẩn

Sản xuất PM ngày nay không còn đơn thuần mang tính sáng tạo ngẫu hứng như trước đây, mà đang trở thành một lĩnh vực được kiểm soát chặt chẽ, theo những tiêu chuẩn nhất định. Các tiêu chuẩn có thể là các kinh nghiệm hoặc các phương pháp hiệu quả nhất, được đề xuất từ các hiệp hội nghề nghiệp như IEEE (The Institute of Electrical and Electronics Engineers, Inc – Học viện các kỹ sư điện và điện tử), từ các tổ chức quốc tế như ISO (International Organization for Standardization), hoặc các quy tắc chuẩn hóa để giao tiếp giữa sản phẩm với nhau… hoặc đơn giản do chính tổ chức phát triển PM đề ra để áp dụng cho chính họ.

Các tiêu chuẩn có thể bao gồm tất cả các khía cạnh của một chu kỳ phát triển PM, trải dài suốt mọi pha phát triển. Bất kể tiêu chuẩn xuất phát từ đâu, từ nội bộ công ty, hoặc từ ngoài, nó đều phải có một số đặc điểm sau:

Các tiêu chuẩn nên được chọn và thể hiện sao cho khi sử dụng, các khía cạnh kỹ thuật cần thiết sẽ được nhấn mạnh, tránh trường hợp hiểu sai hoặc sa vào những tiểu tiết phụ trợ. Một ví dụ thường thấy là tiêu chuẩn định dạng cho tài liệu, mục đích của tiêu chuẩn là để bảo đảm khía cạnh chất lượng về kỹ thuật của tài liệu. Tuy nhiên, trong rất nhiều trường hợp tiêu chuẩn đã bị hiểu sai và sa đà vào việc kiểm tra các chi tiết về mặt hình thức. Lưu ý là để bảo đảm các tiêu chuẩn được nghiêm túc thực hiện, chúng phải mang tính bắt buộc và được quy định ở chính sách cấp công ty.

Một dạng phổ biến bắt buộc phải có của tiêu chuẩn là hệ thống các “quy trình”, kèm theo các bộ phận phụ thuộc như “thủ tục” “hướng dẫn” “mẫu biểu” “tiêu chuẩn” v.v. Tùy theo lĩnh vực hỗ trợ mà chúng có các tên tương ứng, chẳng hạn: quy trình sản xuất PM, quy trình kiểm soát chất lượng, quy trình kiểm tra…

2. Lập kế hoạch

Lập kế hoạch là yêu cầu kinh điển cũng như thao tác cơ bản của hầu hết các HTQLCLPM. Kết quả của hoạt động này thường là một (hoặc nhiều) tài liệu gọi là bản kế hoạch.

Theo quan điểm quản lý hiện đại, các công việc gắn liền với những mục tiêu, ngắn hạn hoặc dài hạn, đều có thể xem như là một dự án hoặc chuỗi các dự án. Kế hoạch cho dự án thường bao gồm những điểm chính sau:

Đây là kế hoạch liên quan đến sự tham gia của những người có ảnh hưởng quan trọng đến sự thành công hay thất bại của dự án (thuật ngữ chuyên môn gọi là stakeholders). Những người nầy thường bao gồm: trưởng dự án, quản lý cấp cao, khách hàng, ban giám đốc, thầu phụ, nhà cung cấp. Kế hoạch nầy phải bảo đảm cơ chế để các stakeholders có thể tham gia vào dự án ở các mức độ và thời điểm mang lại hiệu quả cao nhất.

3. Xem xét, xem lại

Mục đích là để cung cấp thông tin trực quan về tình trạng của các hoạt động xảy ra trong suốt quá trình sản xuất và cài đặt PM.

Xem xét trên sản phẩm – thường được gọi là xem xét kỹ thuật – bao gồm hai loại: chính thức hoặc không chính thức. Xem xét không chính thức thường được thực hiện trong quá trình phát triển sản phẩm, còn xem xét chính thức thường được thực hiện tại thời điểm kết thúc các chặng phát triển.

Điểm khác nhau chính về mặt kỹ thuật giữa xem xét chính thức và không chính thức là ở mức độ nghiêm ngặt của quy trình và các bước thực hiện. Chẳng hạn, xem xét chính thức buộc phải lên kế hoạch, ghi nhận tất cả các lỗi phát hiện và giám sát đến khi tất cả lỗi đã được sửa chữa, xem xét không chính thức thì không bắt buộc.

Trong thực tế, có khá nhiều định nghĩa và nhiều loại xem xét khác nhau. Về tổng quan, IEEE định nghĩa có ba loại:

Một điểm cần hết sức lưu ý để bảo đảm việc xem xét mang lại hiệu quả là: mục tiêu chính của việc xem xét nhằm để tìm ra lỗi. Một trong những lý do chính khiến cho rất nhiều cuộc xem xét không mang lại hiệu quả như mong muốn là các cuộc xem xét đó bị “lún” vào việc thảo luận các giải pháp để sửa chữa lỗi. Sửa lỗi thường yêu cầu phải có sự phân tích kỹ lưỡng cũng như phải chấp nhận các phản biện trên các phương pháp sửa lỗi, công việc nầy hoàn toàn không phù hợp cho một buổi xem xét tìm lỗi. Một khi tìm thấy lỗi, nó nên được giao cho một/nhóm người phân tích và giải quyết, việc xem xét chỉ nên chú tâm vào việc chỉ ra các sai sót.

4. Kiểm tra lỗi

Kiểm tra lỗi (testing) là một hoạt động sống còn trong sản xuất PM. Kiểm tra lỗi nhằm mục đích chứng minh rằng các yêu cầu đối với PM là được thỏa mãn. Các hoạt động kiểm tra bao gồm các bước: lập kế hoạch, thiết kế test, thi hành test, và báo cáo kết quả kiểm tra. Chi tiết về kiểm tra PM chúng tôi đã trình bày trong TGVT A số tháng 12/2005 (ID: A0512_110).

Ở đây tôi muốn nhấn mạnh đến bước lập kế hoạch kiểm tra bắt đầu từ giai đoạn nhận và phát triển yêu cầu. Tương tứng với mỗi yêu cầu là một phương pháp kiểm tra thích hợp. Một yêu cầu không thể coi là hoàn chỉnh nếu như nó không thể kiểm tra được. Kế hoạch kiểm tra được thiết lập ngay từ chặng phát triển yêu cầu. Do yêu cầu thường thay đổi xuyên suốt dự án, kế hoạch kiểm tra do đó cũng phải thay đổi theo.

5. Phân tích lỗi

Trong thực tế, lỗi là phần “luôn hiện diện” trong mọi PM từ giai đoạn phát triển sơ khởi đến khi nó không còn được sử dụng.

Các tổ chức PM thường dùng thuật ngữ “chất lượng” để chỉ zero, hay một lượng nhỏ các lỗi trên sản phẩm PM, một số khác lại gắn liền khái niệm “chất lượng” với sự hài lòng của khách hàng. Trên quan điểm khách hàng, bất kể lúc nào, hễ PM “chạy” không tốt, không đáp ứng sự mong đợi đều được xem là có lỗi, bất kể do code sai, hoặc do hiểu nhầm yêu cầu, thậm chí là một chức năng “nên có” nhưng hiện thời chưa sẵn sàng.

Phân tích lỗi được thực hiện trên tất cả lỗi được tìm thấy, nhằm mục đích tìm hiểu nguyên nhân và xu hướng gây ra lỗi, định hướng cho việc sửa chữa các lỗi hiện hành cũng như phòng ngừa, triệt tiêu khả năng xảy ra lỗi trong tương lai. Phân tích lỗi là con đường chính yếu phục vụ cho việc giảm sự xuất hiện lỗi.

Phân tích lỗi không chỉ nhằm mục đích cải thiện tình trạng lỗi của phần mềm đang xây dựng, xa hơn nó cho ta thấy được những điểm yếu cần cải tiến của quy trình phát triển PM. Thông tin về lỗi của các dự án trong quá khứ sẽ cho ta thấy được nên cải tiến, thay đổi quy trình phát triển PM như thế nào để các dự án trong tương lai tránh đi vào “vết xe đổ” của các dự án trước.

Số liệu phục vụ cho việc phân tích lỗi có thể đến từ nhiều nguồn khác nhau. Mỗi tổ chức tuỳ theo nhu cầu và đặc điểm riêng, tự định nghĩa và thu thập các số liệu nầy.

Lỗi trong quá trình phân tích và sửa chữa có thể được phân loại để có hành động phù hợp, tuỳ theo các đặc tính khác nhau mà chúng thể hiện. Các đặc tính trong Bảng: “Các thuộc tính của lỗi.” thường được sử dụng trong nhiều hệ thống phân tích lỗi.

Chú thích:
(*) CMMI: Capability Maturity Model Integration
(**) SEI: Software Engineering Institude.

Ngô Văn Toàn
Global CyberSoft Việt Nam

(theo PC World VN)

FPT Aptech – Hệ Thống Đào Tạo Lập Trình Viên Quốc Tế