Khi dự án phần mềm trở nên lớn hơn và phức tạp hơn, vai trò của Đảm bảo chất lượng phần mềm – Software Quality Assurance (SQA) trở nên gay gắt hơn.

Ngay cả ngày nay, các phương pháp để đảm bảo chất lượng phần mềm vẫn thường không được nhiều người quản lí dự án hiểu rõ. Đảm bảo chất lượng phần mềm yêu cầu rằng tri thức và kỉ luật kĩ nghệ phải được áp dụng trong MỌI pha của vòng đời phát triển, KHÔNG phải là những pha cuối cùng của kiểm thử hay đưa ra như nhiều người vẫn hiểu lầm. Người kĩ sư đảm bảo chất lượng phần mềm được yêu cầu có nhiều năm phát triển phần mềm và tri thức miền đủ để đánh giá tính đầy đủ và tính đúng đắn của yêu cầu hệ thống, và họ phải có khả năng xác định liệu thiết kế có tổ hợp mọi yêu cầu một cách chính xác không. Cuối cùng, người kĩ sư SQA chịu trách nhiệm về quản lí thông báo liệu sản phẩm phần mềm có tin cậy không và có đáp ứng chuẩn chất lượng không. Với loại công việc này, người kĩ sư SQA phải là người có kinh nghiệm nhất trong tổ chức. Họ phải làm việc như người phát triển phần mềm trong nhiều năm và đi lên người lãnh đạo kĩ thuật hay kiến trúc sư và thực hiện công việc này trong nhiều năm trước khi trở thành kĩ sư SQA.

Cuốn “Sổ tay của Đảm bảo chất lượng phần mềm,” định nghĩa SQA là: “Tập các hoạt động có hệ thống cung cấp bằng chứng về khả năng của qui trình phần mềm tạo ra sản phẩm phần mềm khớp với việc sử dụng. Do đó hội tụ của SQA là giám sát liên tục trong toàn thể vòng đời phát triển phần mềm để đảm bảo chất lượng của sản phẩm được chuyển giao. Điều này yêu cầu giám sát cả qui trình và sản phẩm. Trong đảm bảo qui trình, SQA cung cấp việc quản lí với phản hồi khách quan liên quan tới tuân thủ các kế hoạch, thủ tục, chuẩn và phân tích đã được chấp thuận. Các hoạt động đảm  bảo sản phẩm hội tụ vào mức độ thay đổi của chất lượng sản phẩm bên trong từng pha của vòng đời, như yêu cầu, thiết kế, viết mã và kế hoạch kiểm thử. Mục tiêu là nhận diện và khử bỏ khiếm khuyết trong toàn bộ vòng đời sớm nhất có thể được, do vậy giảm chi phí kiểm thử và bảo trì.

Viện các kĩ sư điện và điện tử (IEEE) định nghĩa chất lượng là “mức độ mà hệ thống, cấu phần, hay qui trình đáp ứng cho các yêu cầu xác định, và nhu cầu hay mong đợi của khách hàng hay người dùng.” Trong khi định nghĩa này dường như rõ ràng và không mơ hồ, nhiều người quản lí phần mềm vẫn phàn nàn rằng chất lượng là “khó định nghĩa, không thể đo được, khó nhận ra” và do đó bỏ qua nó. Sau đây là định nghĩa chi tiết khác về chất lượng phần mềm như được định nghĩa trong “Sổ tay của Đảm bảo chất lượng phần mềm” chuẩn.

Tính đúng đắn: mức độ mà dự án hoàn thành các đặc tả của nó.

Tính hiệu quả: dùng tài nguyên trong thực hiện và lưu giữ.

Tính linh hoạt: dễ làm thay đổi được yêu cầu do thay đổi trong môi trường vận hành.

Tính toàn vẹn: bảo vệ dự án khỏi truy nhập không được phép.

Tính liên tác: nỗ lực được yêu cầu để tích hợp hệ thống vào hệ thống khác.

Tính bảo trì: nỗ lực được yêu cầu để định vị và sửa lỗi trong dự án trong môi trường vận hành của nó.

Tính khả chuyển: nỗ lực được yêu cầu để truyền dự án từ môi trường này sang môi trường khác.

Tính tin cậy: khả năng không hỏng.

Tính tái dụng: dễ dùng lại phần mềm trong hoàn cảnh khác.

Tính kiểm thử được: dễ dàng kiểm thử dự án để đảm bảo rằng nó không lỗi và đáp ứng đặc tả.

Tính khả dụng: dễ dùng phần mềm.

Tất nhiên, trong một thế giới hoàn hảo tất cả những tiêu chí này sẽ được đáp ứng, nhưng trong thực tế việc bù trừ là một phần của mọi dự án phát triển. Thường phần mềm hiệu quả nhất lại không khả chuyển, vì tính khả chuyển sẽ yêu cầu mã phụ thêm, làm giảm tính hiệu quả. Tính khả dụng là chủ quan và thay đổi tuỳ theo kinh nghiệm của người dùng. Khi dùng các tiêu chí này để xác định mục tiêu đảm bảo của hệ thống phần mềm, mục đích và việc dùng hệ thống phải được tính tới. Trong thế giới thực của phát triển phần mềm, tiêu chí về chất lượng được nhận diện và áp dụng cho mức độ khác biệt xem như kết quả của các quyết định bù trừ.

Với toàn cầu hoá, khi nhiều công ti làm kinh doanh qua các biên giới quốc gia, yêu cầu về chất lượng sản phẩm đang trở nên quan trọng hơn. Thực tế đã chứng minh rằng việc có SQA là đảm bảo rằng có kỉ luật và kiểm soát trong qui trình phát triển phần mềm thông qua đánh giá độc lập do đó SQA sẽ xác định liệu một sản phẩm sẽ được chấp nhận ở chỗ nào đó hay không. Có hai mô hình phổ biến để kiểm điểm và đảm bảo chất lượng phần mềm: ISO 9000 và CMMI. Tổ chức tiêu chuẩn quốc tế (ISO 9000) cung cấp một cách để thu được việc uỷ nhiệm bên ngoài cho hệ thống quản lí chất lượng. Nhiều công ti đã dùng ứng dụng của ISO cho phần mềm, nhưng vấn đề là ở chỗ nó hội tụ phần lớn vào thủ tục thay vì qui trình. Mô hình kia là Tích hợp mô hình trưởng thành năng lực (CMMI) của Viện kĩ sư phần mềm hội tụ trên cơ sở rằng chất lượng của sản phẩm phần mềm chủ yếu được xác định bởi chất lượng của qui trình phát triển và bảo trì phần mềm được dùng để xây dựng nó.

Đảm bảo chất lượng là mấu chốt cho mọi doanh nghiệp tương lai. Có SQA có kinh nghiệm là bản chất cho doanh nghiệp nhưng ngay cả ngày nay, nhiều công ti phần mềm hiếm khi đầu tư đủ ngân quĩ để thực hiện công việc SQA. Một số người tin họ có thể tránh được nó nhiều nhất có thể được. Thái độ “cắt giảm chi phí” và có sản phẩm chất lượng kém là không thể chấp nhận được trong thế giới cạnh tranh cao. Nhiều công ti sẽ KHÔNG sống sót lâu được vì nhiều khách hàng đang đòi hỏi sản phẩm chất lượng tốt hơn với an toàn và tin cậy tốt nhất.

—-English version—-

Software Quality Assurance

As software project is becoming larger and more complex, the role of Software Quality Assurance (SQA) is becoming more critical. Even today, methods for assuring software quality are often not well understood by many project managers. Assuring software quality requires that engineering knowledge and discipline be applied at ALL phases of the development life cycle, NOT the last phases of test or release as many people misunderstood. Software Quality Assurance engineers are required to possess many years of software development and sufficient domain knowledge to evaluate the completeness and correctness of system requirements, and they must have the ability to determine whether the design has incorporated all requirements accurately. Ultimately, SQA engineers are responsible for advising management whether a software product is reliable and meet quality standards. For this kind of works, SQA engineers probably should be the most experience persons in the organization. They should work as software developers for many years and move up to technical leader or architect and perform this work for years before becoming SQA engineers.

The “Handbook of Software Quality Assurance”, define SQA as: “The set of systematic activities providing evidence of the ability of the software process to produce a software product that is fit to use. The focus, therefore, of SQA is to monitor continuously throughout the software development life cycle to ensure the quality of the delivered product. This requires monitoring both the processes and the products. In process assurance, SQA provides management with objective feedback regarding compliance to approved plans, procedures, standards, and analyses. Product assurance activities focus on the changing level of product quality within each phase of the life cycle, such as the requirements, design, code, and test plan. The objective is to identify and eliminate defects throughout the life cycle as early as possible, thus reducing test and maintenance costs.

The Institute of Electrical and Electronics Engineers’ (IEEE) defines quality as “the degree to which a system, component, or process meets specified requirements, and customer or user needs or expectations While this definition seems to be clear and unambiguous, many software project managers still complains that quality is “hard to define, impossible to measure, difficult to recognize” and therefore ignore it. Following is another detailed definition of software quality as defined in the standard “Handbook of Software Quality Assurance”.

Correctness: extent to which a project fulfills its specifications.

Efficiency: use of resources execution and storage.

Flexibility: ease of making changes required by changes in the operating environment.

Integrity: protection of the project from unauthorized access.

Interoperability: effort required to integrate the system to another system.

Maintainability: effort required to locate and fix a fault in the project within its operating environment.

Portability: effort required to transfer a project from one environment to another.

Reliability: ability not to fail.

Reusability: ease of re-using software in a different context.

Testability: ease of testing the project to ensure that it is error-free and meets its specification.

Usability: ease of use of the software.

Of course, in a perfect world all of these criteria would be met, but in reality tradeoffs are a part of all development projects. Often the most efficient software is not portable, as portability would require additional code, decreasing the efficiency. Usability is subjective and varies depending on the experience of users. When using the criteria to define the assurance objectives of a software system, the purpose and use of the system must be taken into account. In the real work of software development, criteria for quality are identified and applied to differing extents as a result of trade-off decisions.

With globalization, as many companies are doing business across national borders, the requirement for a quality product is becoming more important. It has been proven that having SQA is to ensure that there is discipline and control in the software development process via independent evaluation therefore SQA will determine whether a product will be accepted in certain places or not. There are two popular models of reviewing and assuring software quality: The ISO 9000 and the CMMI. The International Standard Organization (ISO 9000) provided a way to gain external accreditation for a quality management system. Many companies have used the application of ISO to software, but the issue is that it focuses mostly on procedures rather than process. The other is the Software Engineering Institute’s Capability Maturity Mode Integration (CMMI) focuses on the basis that the quality of the software product is largely determined by the quality of the software development and maintenance processes used to build it.

To ensure quality is critical for all future business. Having experienced SQA is essential for the business but even today, many software companies rarely invest or have sufficient funds to perform SQA works. Some believe they can avoid it as much as possible. The attitude of “Cutting costs” and having poor quality product are unacceptable in the highly competitive world. Many will NOT survive for long as more customers are demanding better quality product with the best safety, and reliability.