Có câu hỏi về ai chịu trách nhiệm về chất lượng phần mềm nhưng ít người có thể trả lời được nó.

Nếu bạn hỏi mười người, bạn có thể có mười hai câu trả lời khác nhau bởi vì một số người có thể có nhiều câu trả lời. Tại sao khó trả lời cho một câu hỏi đơn giản như thế này? Chúng ta hãy hỏi những người đang làm việc trong công nghiệp phần mềm: Một số người lập trình tin đảm bảo chất lượng (QA) là trách nhiệm về chất lượng, bởi vì họ có từ “chất lượng” ở tiêu đề. Người đảm bảo chất lượng tin người kiểm thử chịu trách nhiệm về chất lượng vì việc làm của họ là kiểm tra về chất lượng. Người kiểm thử tin người phát triển chịu trách nhiệm về chất lượng vì họ xây dựng phần mềm. Người phát triển tin kiến trúc sư chịu trách nhiệm về chất lượng vì họ chỉ thực hiện điều kiến trúc sư thiết kế cho phần mềm. Kiến trúc sư tin kĩ sư yêu cầu chịu trách nhiệm về chất lượng vì người đó cung cấp thông tin cho kiến trúc sư. Thông tin sai dẫn tới thiết kế sai. Kĩ sư yêu cầu tin khách hàng chịu trách nhiệm về chất lượng vì họ nói cho kĩ sư yêu cầu điều họ muốn. Nếu họ không giải thích rõ ràng điều họ muốn, đó là vấn đề của họ. Khách hàng tin người quản lí dự án chịu trách nhiệm về chất lượng vì người đó chịu trách nhiệm cho toàn thể sản phẩm phần mềm. Người quản lí dự án tin các giáo sư chịu trách nhiệm về chất lượng vì họ dạy phát triển phần mềm. Nếu họ không dạy về chất lượng thì không ai biết về nó. Về cơ bản, không ai muốn chịu trách nhiệm về chất lượng phần mềm.

Vấn đề chính là sự không tin cậy giữa các nhóm chức năng và vai trò cùng trách nhiệm không rõ ràng trong toàn thể qui trình phát triển. Mọi người chỉ hội tụ vào việc làm của họ, và điều họ phải làm bên trong khu vực giới hạn của họ. Bất kì cái gì bên ngoài khu vực của họ KHÔNG phải là mối quan tâm của họ. Không ai biết nhóm khác đang làm gì. Không ai muốn chịu trách nhiệm về sản phẩm cuối cùng. Không ai quan tâm về chất lượng phần mềm. Phần lớn không hiểu khái niệm qui trình phần mềm hay để thời gian để hiểu toàn thể việc phát triển phần mềm. Họ chỉ chăm nom về điều họ làm theo cách hạn chế. Sinh viên được dạy về lập trình cho nên họ biết cách viết mã và kiểm thử. Họ có thể học về vòng đời phần mềm nhưng nó chỉ là khái niệm mơ hồ chừng nào họ còn chưa thực sự thực hiện cái gì đó qua toàn thể vòng đời. Ngay cả sau vài năm làm việc, một số người đã học về kiến trúc rồi họ chỉ tập trung vào những khu vực đó. Khi mọi người được đề bạt làm người quản lí, họ học cách quản lí dự án bởi vì thiết kế, viết mã và kiểm thử là những thứ của quá khứ và việc làm của ai đó khác. Rất ít người quan tâm về toàn thể qui trình phần mềm hay bức tranh lớn hơn của phát triển phần mềm. Với họ chất lượng là khái niệm, không phải là trách nhiệm.

Khi vấn đề chất lượng xảy ra, tình huống điển hình có thể xảy ra giống thế này trong kịch bản sau:

“Người phát triển giải thích: “Vấn đề chất lượng được gây ra bởi các đặc tả yêu cầu phần mềm kém, đó là lỗi của kĩ sư yêu cầu.” Kĩ sư yêu cầu không đồng ý: “Không đấy không phải do tôi, đấy là do khách hàng cứ đổi ý hoài và người kiểm thử không kiểm điểm những thay đổi cho nên lỗi không được phát hiện ra.” Người kiểm thử phản đối: “Người làm cấu hình chưa bao giờ nói cho tôi cái gì về thay đổi cả, chúng không được làm tài liệu. Đấy là lỗi của người quản lí cấu hình.” Người kiểm thử khác than: “Điều đó thật đáng thất vọng. Không ai đánh giá cao điều chúng tôi làm, họ không biết rằng chúng tôi làm việc vất vả.” Kĩ sư yêu cầu nhảy vào: “Người kiểm thử là vấn đề, tôi không có ý tưởng về họ làm gì, họ không có kĩ năng, nhiều người chỉ mới tốt nghiệp từ trường ra mà không có kinh nghiệm.” Người kiểm thử phàn nàn: “Đấy là lỗi của người phát triển, họ xây dựng mã, họ phải sửa chúng cho nên chất lượng là lỗi của người phát triển.” Người phát triển tranh cãi: “Chúng tôi chỉ viết mã điều kiến trúc sư thiết kế ra, nếu thiết kế kém thì đó là lỗi của kiến trúc sư không phải chúng tôi.” Kiến trúc sư giận dữ: “Chất lượng là điều các anh xây dựng trong mã, không phải điều tôi thiết kế trên giấy. Người đảm bảo chất lượng phải kiểm mã cho nên chất lượng là trách nhiệm của họ.” Người đảm bảo chất lượng phản đối: “Tôi chưa bao giờ kiểm điểm mã cả, tôi chỉ kiểm tra tài liệu. Người kiểm thử kiểm mã cho nên trách nhiệm phải ở họ.” Người kiểm thử buộc tội: “Chất lượng là việc của anh, chức danh của anh là “Đảm bảo chất lượng” anh là vấn đề, anh lười thì có.” Người quản lí dự án bước vào: “Thế là đủ rồi, tôi không muốn bất kì biện luận nào trong tổ của tôi. Chúng ta có một tổ tốt ở đây. Vấn đề chất lượng tới từ ai đó bên ngoài dự án, không phải chúng ta. Chúng ta phải đi tới gốc rễ của vấn đề chính là ở khách hàng.” Tất nhiên, việc trách móc tiếp tục và vấn đề chất lượng phần mềm sẽ không bao giờ được giải quyết.

Câu hỏi là ai nên chịu trách nhiệm về chất lượng? Trong phát triển phần mềm, kiểm thử được dùng để nhận diện lỗi và ngăn ngừa chúng khỏi lọt vào sản phẩm cuối cùng. Việc kiểm thử KHÔNG tạo ra chất lượng và tổ kiểm thử KHÔNG chịu trách nhiệm về chất lượng. Việc kiểm thử chỉ cung cấp thông tin về chất lượng để cho nó có thể được cải tiến. Về cơ bản, tổ kiểm thử giúp tổ phát triển cải tiến chất lượng vì họ càng phát hiện lỗi sớm, tổ phát triển càng sửa chúng sớm. Tổ kiểm thử KHÔNG thay đổi chất lượng phần mềm, họ chỉ cung cấp kết quả kiểm thử cho tổ phát triển. Tuỳ tổ phát triển ra quyết định về cách giải quyết với các lỗi như sửa chúng hay bỏ qua chúng.

Để đảm bảo chất lượng và chắc chắn lỗi được sửa, có nhóm thứ hai tên là đảm bảo chất lượng phần mềm (SQA). Công việc của SQA là kiểm tra và chắc các lỗi đã được sửa và người phát triển tuân theo qui trình phần mềm. SQA hỗ trợ cho cải tiến chất lượng nhưng KHÔNG chịu trách nhiệm về chất lượng. Giống như người kiểm thử SQA chỉ cung cấp thông tin về chất lượng để cho nó có thể được cải tiến. SQA thu thập thông tin về qui trình và sản phẩm rồi chuyển điều này cho người phát triển và người quản lí để họ có thể sửa lỗi. Vậy SQA giúp giảm bớt các thể nghiệm của lỗi trong sản phẩm khi nó được dùng. SQA không thay đổi chất lượng mà chỉ chắc chắn nguồn của lỗi bị khử bỏ. Chính những người thực tế thực hiện thiết kế và dựng sản phẩm là người thực tế CÓ THỂ cải tiến chất lượng.

Người phát triển dựng mã tương ứng theo thiết kế và yêu cầu. Họ CHỊU trách nhiệm về chất lượng của mã của họ và phải tiến hành kiểm thử đơn vị riêng của họ để kiềm tra các lỗi. Nếu họ làm việc kém, lỗi sẽ xảy ra. Khi người kiểm thử thấy lỗi, họ sẽ thông báo cho người phát triển để sửa chúng. Người phát triển PHẢI sửa các lỗi này vì họ CHỊU trách nhiệm về chất lượng của mã. SQA cũng phải tham gia để chắc rằng chúng được sửa tương ứng bằng việc để cho người quản lí dự án biết điều sẽ xảy ra cho chất lượng nếu lỗi không được sửa.

Tuy nhiên, nếu thiết kế không đầy đủ hay thiếu thuộc tính chất lượng thì kiến trúc sư cũng chịu trách nhiệm về chất lượng. Công việc của kiến trúc sư là kiểm điểm yêu cầu của khách hàng một cách thấu đáo và đưa ra các thuộc tính chất lượng bổ sung để đảm bảo thiết kế là tốt cho nên người phát triển có thể thực hiện chúng. Không may là kiến trúc sư phần mềm hiếm khi được dạy trong trường ngày nay. Nhược điểm then chốt trong đào tạo hiện tại là thiếu tri thức và kĩ năng về một khu vực rất quan trọng trong phát triển phần mềm: Đào tạo về kiến trúc. Chức năng bị thiếu này là nguyên nhân chính gây ra trong chất lượng của phát triển phần mềm.

Tất nhiên, kiến trúc sư thiết kế phần mềm dựa trên đặc tả yêu cầu phần mềm của kĩ sư yêu cầu. Nếu kĩ sư yêu cầu KHÔNG làm tốt việc của họ trong khi làm việc với khách hàng, hiểu nhu cầu của họ và làm tài liệu chúng một cách kĩ lưỡng thì đó cũng là lỗi của họ. Không may là cũng giống như kiến trúc, kĩ nghệ yêu cầu hiếm khi được dạy trong trường. Nhược điểm then chốt trong đào tạo hiện thời là thiếu tri thức và kĩ năng trong khu vực quan trọng này của phát triển phần mềm: Đào tạo kĩ nghệ yêu cầu. Chức năng thiếu này cũng là nguyên nhân chính trong chất lượng của phát triển phần mềm.

Người quản lí dự án chung cuộc chịu trách nhiệm cho toàn thể dự án VÀ chất lượng của sản phẩm. Người quản lí phải đảm bảo rằng qui trình được tuân theo, mọi lỗi phải được sửa trước khi đưa ra cho khách hàng cũng như các yêu cầu được làm tài liệu tốt theo nhu cầu của khách hàng. Kiến trúc phần mềm được thiết kế với thuộc tính chất lượng đầy đủ. Về căn bản người quản lí dự án chịu trách nhiệm cho mọi thứ trong dự án. Điều không may là giống như kiến trúc và kĩ nghệ yêu cầu, quản lí dự án cũng hiếm khi được dạy trong trường. Nhược điểm then chốt trong đào tạo hiện thời là thiếu tri thức và kĩ năng trong khu vực quan trọng này của phát triển phần mềm: đào tạo về quản lí dự án phần mềm. Chức năng thiếu này có lẽ là yếu tố mấu chốt nhất trong chất lượng của phát triển phần mềm.

Nếu bạn nhìn vào chất lượng bạn sẽ thấy rằng vấn đề chính là thiếu hiểu biết về qui trình phần mềm và việc phân vai trò, trách nhiệm và thẩm quyền. Phân chia phát triển phần mềm hiện thời được chia thành các nhóm chức năng. Từng nhóm vận hành độc lập với nhau. Không ai biết nhóm khác đang làm gì. Không ai chịu trách nhiệm cho toàn thể qui trình. Mọi người chỉ tập trung vào việc làm của họ, và điều họ phải làm trong khu vực giới hạn của họ. Bất kì cái gì bên ngoài khu vực của họ KHÔNG phải là mối quan tâm của họ. Không ai muốn chịu trách nhiệm cho sản phẩm cuối cùng. Điều không may là qui trình phần mềm hiếm khi được dạy trong trường. Nhược điểm then chốt trong đào tạo hiện thời là thiếu tri thức và kĩ năng trong CÁI NHÌN TOÀN BỘ về phát triển phần mềm: Đào tạo qui trình phần mềm. Chức năng thiếu này có lẽ là lí do cho sau bao nhiêu năm, chất lượng của phát triển phần mềm đã KHÔNG được cải thiện.

Sinh viên phần mềm phải hiểu rằng lộ trình để xây dựng sản phẩm phần mềm chất lượng cao là qui trình phần mềm. Qui trình phần mềm phải được xác định sớm và được chấp nhận để đáp ứng cho nhu cầu của kĩ sư phần mềm khi họ tiến hành phát triển sản phẩm phần mềm. Qui trình phần mềm cung cấp khuôn khổ cho các hoạt động quản lí mà có thể rất dễ dàng mất kiểm soát. Các kiểu dự án khác nhau yêu cầu qui trình phần mềm khác nhau. Sản phẩm làm việc của kĩ sư phần mềm như chương trình, tài liệu và dữ liệu được tạo ra như hệ quả của hoạt động được xác định bởi qui trình phần mềm.

Đây có phải là lúc để nhìn vào những tri thức và kĩ năng này để sửa hệ thống giáo dục không? Đây có phải là lúc để hội tụ vào chất lượng và giảm chi phí không? Đây có phải là lúc nhìn vào đào tạo hiện thời và hỏi câu hỏi đúng không? Đây có phải là lúc cho công ti phần mềm học về qui trình phần mềm không? Đây có phải là lúc cho công nghiệp phần mềm hiểu mối quan hệ giữa qui trình và chất lượng không? Những chỉ báo tốt nhất về qui trình phần mềm đã làm việc tốt đến đâu là chất lượng, thời gian và chi phí của sản phẩm phần mềm.

 

—-English version—-

 

Software quality

There is a question about who is responsible for software quality but few can answer it. If you ask ten people, you may have twelve different answers because some people may have more than one answer. Why is it difficult for a simple question like this? Let’s ask people who are working in the software industry: Some programmers believe quality assurance (QA) is responsible for quality, because they have the word “Quality” in the title. Quality assurance people believe testers are responsible for quality because it is their job to check for quality. Testers believe developers are responsible for quality because they build the software. Developers believe architect is responsible for quality because they only implement what the architect designs for software. Architect believes the requirements engineer is responsible for quality because he provides information to the architect. Wrong information leads to wrong design. Requirement engineer believes customers are responsible for quality because they tell the requirements engineer what they want. If they did not clearly explain what they want, that is their problems. Customers believe the project manager is responsible for quality because he is responsible for the entire software product. Project managers believe professors are responsible for quality because they teach software development. If they do not teach about quality then nobody know about it. Basically, no one wants to be responsible for software quality.

The major issue is the distrust between functional groups and the unclear roles and responsibilities in the entire development process. People is only focusing on their jobs, and what they have to do within their limited area. Anything outside of their area is NOT their concern. No one know what other group is doing. No one want to be responsible for the final product. No one is concerned about software quality. Most do not understand the concept of software process or take time to understand the entire software development. They only care about what they do in a limited way. Students are taught about programming so they know how to code and test. They may learn about software life cycle but it is only a vague concept unless they really implement something across the entire life cycle. Even after few years of working, some learned about architect then they only focus on that areas. When people got promoted to managers, they learn how to manage projects because design, code and test are things of the past and jobs of somebody else. Very few are concern about the entire software process or the bigger picture of software development. To them quality is a concept, not a responsibility.

When quality problems happen, the typical situation may happen like this following scenario:

“The developer explains: “The quality problems are caused by bad software requirements specifications, it is the fault of the requirements engineer”. The requirements engineer disagrees: “No it is not me, it is the customers that keep changing their minds and testers do not review changes so defects are not detected”. Testers protest: “The configuration people never tell me anything about changes, they are not documented. It is the fault of configuration managers”. Another tester laments: “It is frustrating. no one appreciate what we do, they do not know that we work hard”. The requirement engineer jumps in: “Testers are the problem, I have no idea what they do, they do not have the skills, many are just graduating from school with no experience”. Tester complains: “It is the developer’s fault, they build the code, if they build bad code, they have to fix them so quality is the developers’ fault”. The developer argues: “We only code what the architect designs, if the design is bad then it is the architect’ fault not us”. The architect is angry: “Quality is what you build in code, not what I design on paper. Quality assurance people must check the code so quality is their responsible”.  The quality assurance protests: “I never review the code, I only check the documents. Testers test the code so it must be them”. The tester accuses: “Quality is your job, your title is “Quality assurance” you are the problem, you are lazy”. The project manager steps in: “That is enough, I do not want any arguments in my team. We have a good team here. Quality problems come from someone outside the project, not us. We have to go to the root of the problem which is the customers”. Of course, the blaming continue and software quality problem will never be solved.

The question is who should be responsible for quality? In software development, testing is used to identify defects and prevent them from getting to final product. Testing does NOT create quality and test team is NOT responsible for quality. Testing only provides information about the quality so it can be improved. Basically, test team helps development team to improve the quality because the earlier they find defects, the easier development team can fix them. Test team does NOT change the quality of the software, they only provide test result to the development team. It is up to development team to make decision on how to deal with the defects such as fix them or ignore them.

To ensure quality and make sure defects are fixed, there is a second group called software quality assurance (SQA). The job of SQA is to check and make sure defects are fixed and developers are following the software process. The SQA support the improvement of quality but NOT responsible for quality. Like testers SQA only provides information about the quality so it can be improved. SQA gathers information about processes and products then pass this to developers and managers so they can fix defects. Thus SQA helps reduce the instances of failure in a product as it is used. SQA does not change quality but only make sure the source of errors is eliminated. It is the people who actually implement the design and build of the products who actually CAN improve the quality.

Developer build the code according to the design and requirements. They ARE responsible for the quality of their code and must conduct their own unit tests to check on defects. If they do a bad job, defects will happen. When testers find defects, they will inform developers to fix them. Developers MUST fix these defects since they ARE responsible for the quality of the code. SQA must involve also to make sure that they are fixed accordingly by let project manager know what will happen to the quality if defects are not fixed.

However, if the design is not complete or missing quality attributes than the architect is also responsible for quality. The job of the architect is to review customer requirements thoroughly and derive addition quality attributes to ensure the design is good so developers can implement them. Unfortunately, software architect is rarely taught in school today. The key weakness in current training is the lack of knowledge and skills in one very important area in software development: The architecture training. This missing function in the main cause in the quality of software development.

Of course, architect designs the software based on requirements engineer’s software requirements specification. If the requirements engineer does NOT do a good job in working with customers, understand their needs and document them thoroughly than it is their fault also. Unfortunately like architecture, requirements engineering is rarely taught in schools also. The key weakness in current training is the lack of knowledge and skills in this important area of software development: The requirements engineering training. This missing function is also main cause in the quality of software development.

The project manager is ultimately responsible for the entire project AND the quality of the product. The manager must ensure that the process is being followed, all defects must be fixed before release to customers as well as the requirements are well documented according to customers’ needs. The software architect is designed accordingly with full quality attributes. Basically the project manager is responsible for everything in the project. Unfortunately like architecture and requirements engineering, project management is also rarely taught in schools. The key weakness in current training is the lack of knowledge and skills in this important area of software development: The software project management training. This missing function is probably the most critical factor in the quality of software development.

If you look at the quality you will see that the major problem is the lack of understand about the software process and the assignment of roles, responsibilities and authorities. The division of current software development is divided into functional groups. Each group operate independent of each others. No one know what other group is doing. No one is responsible for the entire process. People is only focusing on their jobs, and what they have to do within their limited area. Anything outside of their area is NOT their concern. No one want to be responsible for the final product. Unfortunately, software process is also rarely taught in schools. The key weakness in current training is the lack of knowledge and skills in this TOTAL VIEW of software development: The software process training. This missing function is probably the reason after so many years, the quality of software development has NOT been improved.

Software students must understand that the roadmap to building high quality software products is software process. Software processes must be defined early and adapted to meet the needs of software engineers as they undertake the development of a software product. A software process provides a framework for managing activities that can very easily get out of control. Different types of projects require different software processes. The software engineer’s work products such as programs, documentation, and data are produced as a consequence of the activities defined by the software process.

Is it time to look at these knowledge and skills are fix the education system? Is it time to focus on quality and reduce costs? Is it time to look at current trainings and ask the right questions? Is it time for software company to learn about software process? Is it time for the software industry to understand the relationship between process and quality? The best indicators of how well a software process has worked are the quality, timeliness, and costs of the software product.