Software quality assurance (SQA) is not a new issue but is a weak mark of Vietnam software companies according to some evaluations. Some of the domestic companies have achieved the international level of CMM/CMMI in improving the ability and software quality assurance, however, there are some companies processing for the foreign markets.
How can a company achieve the international level of software quality?
Each company has the particular characteristics but they commonly develop and maintain a software quality assurance.
What is software qualities assurance?
In the past, software quality (SQ) was considered as a matter to define SQ arise the fault and run on the requirements whether or not. Finally, testing software was an action with the main responsibility.
This may be right with the customers’ opinion because they do not care to act software development. They only care the company take the products for them on schedule and the products run well whether or not.
However, according to opinion of software developers, software testing is important but it is not enough to ensure the product complete on time and satisfy the requirement. Final testing to find the fault is right but it is late and takes much time to repair in many cases.
Practically, to grant two simple norms of customers, companies must hold not only work well software testing but also organize and maintain the harmonious action of systems. These systems consist of actions relating to a project, from that, “Software qualities assurance” (SQA). SQA concludes processes implemented during the development period of software project.
At present, there are many supplying-standard models as well as instructions to deploy “Software Quality Assurance System” (SQAS). ISO 9001-2000 and CMM/CMMi are two of the models which are broadly applied. While ISO 9001-2000 is quality assurance standard for all of sections with the concise and general provisions, CMM/CMMi is a remarkably huge collection consisting of the practiced experiences (about 450 pages with CMM and 700 pages with CMMI), it makes the inexperienced readers hard to what actions, and particular factor of SQAS is.
Throughout the added documents as well as the individual experiences when researching and applying ISO 9001-2000 and CMM/CMMi, we will introduce concepts, actions as well as the basic element of SQAS.
The basis about SQAS
A normal SQAS consists of two aims:
Firstly, companies should build quality for Software Assurance at the beginning timeof setting up. This is similar to ensure for Software Assurance from every different resources. Software Assurance (SA) must be defined, expressed, and understood in the right way between who take the requirements and who implement the requirements.
Secondly, companies ensure quality of SA during the developing process.
A completed SQAS consists of many actions and parts to create. They are different according to each group when deploying. However, we only introduce ten actions and the basest factors:
1. Standards
2. Planning
3. Reviewing
4. Testing
5. Defect analysis
6. Configuration Management
7. Security
8. Education/Training
9. Vendor Management
10. Risk Management
There is the relation between ten above basic factors and the stage of developing SA..
1. Standards
Now SA production is not only the sudden creation like before, it is becoming a field controlled closely according to the given standards. The standards can be experiences or the most effective methods which are proposed by Unions like IEEE (The Institute of Electrical and Electronics Engineers, Inc), the international groups like ISO (International Organization for Standardization) or the standardization rules to communicate between products together… or SA development organization has proposed to apply for themselves.
The standards may consist of all aspects of a period in developing SA and spreading all development processes. Any standard starts from all places, from inside or outside companies, it generally gets some points as following:
· The indispensable
· The realizable
· The measurable
The standards should be selected and shown to express that the essential technology aspects will be emphasized on avoiding misunderstanding or relating to the support trivial. For example, the standard formats for documents and aim of this standard is to ensure the quality aspect about technology of documents. However, in many cases, standards have been misunderstood and related to test parts about the form. A note is to ensure that if standards are seriously implemented, they are compulsory and becoming the rules in companies like a policy.
A compulsory normal form of standard is a system consisting of “processes,” together with the dependent parts like “procedures,” “instructions”, “templates”, “standards”… They have the relative names, for example, SA development process, quality controlling process, checking process… according to the support fields.
2. Planning
Planning is the classic requirement as well as the basic actions of almost SQAS. Result of this action is one or more documents called planning.
According to the modern management opinion, jobs relating closely to the short term or long term aims can consider as a project or a project chain. Planning for the project consists of the main points:
· Estimate the scale and the size of project, quantity of the done work.
· Define human resources, material resources, and cost
· Designate the method, way of access to implement the project
· Plan the detailed work
· Plan to cooperate and support the complete of project
This is planning relating to the participation of the very important people who affect on success or failure of project (stakeholders). These stakeholders consist of: the project generals, senior-managers, guests, the Board of managers, subcontractors, and suppliers. This planning must ensure the mechanism for stakeholders to participate the project in the suitable level and time in order to achieve the highest effects.
· Planning to manage the configurations and the risks
· The other plans
There may be the other plans, not only management but also technology, depending on the requirements for each project. Some plans are common: checking planning, product integration planning and training planning…
· Document and update the plans for project
3. Reviewing
The aim is to supply the visual in formations about status of actions during producing and installing SA.
Reviewing the products – reviewing the technology – consists of two kinds: official and unofficial. Unofficial reviewing is implemented in the production development process and official reviewing is implemented in the end of development periods.
The main differences between two kinds are at the restricted level of processes and the steps of development. For example, official reviewing must make plan, record all failures, and supervise until these failures are repaired. Unofficial reviewing is not compulsory.
Practically, there are many different concepts and kinds of reviewing. Generally, there are three kinds of reviewing according to IEEE:
• Review: The official meeting aims to present a problem, a document, a product… for users, customers…in order to collect the feedback opinions or gather the agreements approved on the above problem, document, or product.
• Walkthrough: With unofficial evaluation technology, the author about a problem, a product will explain about this problem, product for a colleague group. These colleagues will make questions or give the supporting opinions about some fields to ensure the technology quality of the documents or products.
• Inspection: With official evaluation technology, some people, not authors or not related to the document, product, will check detailed to find the errors, standard breach, or the other issues. Basically, inspection is held and implemented more restricted than walkthrough. Rules of participants are clearly delimited and the documents for reviewing are carefully prepared.
A note is to ensure reviewing effectively: main aim of reviewing is to find errors. One of the main reasons makes reviewing ineffective like we expect because that reviewing “sink” in discussing the methods to repair errors. Reparation requires the careful analysis as well as accepts the opponent based on the reparation methods and it is not suitable for the meeting about finding errors. When finding errors, these errors should be analyzed and solved by the group reviewing focuses on show the errors.
4. Testing
Testing is a very important action in software production. Aim of testing proves that requirements about software are satisfied. Testing actions consists of steps: planning, test designing, test implementing, and supporting the testing results. The detailed information about software testing is in The Computer World – A, December, 2005 (ID: A0512_110).
I want to stress on steps to plan testing from the period of receiving and developing requirements. Each requirement is relative to a suitable testing method. A requirement is not full-done if it is not tested. Testing plan is established in the period of developing requirements. Because requirements often change during the project, testing also changes together.
5. Analyzing defects
Practically, defect always appears in the software from the start of development to breaking down.
The software organizations often use the term “quality” to show zero or a little of defect on software production. Some connect closely the concept “quality” with the customers’ satisfactions. In customers’ opinions, when software does not “runs” well, not meet the expectation, software is also considered as having problems (due to wrong code, misunderstanding requirements, even a ….
Analyzing defect is implemented in all found defects in order to find the reason and trend causing defects together with orienting on repairing the current defects as well as preventing and annulling defects in the future. Analyzing defect is the main and most important way to reduce the appearance of defects.
Analyzing defect not only improves the defect situation of the building software but also makes us see the weak points needed to improve in the software development process. Information about defects of the past projects gave us a view to improve, change the software development process for the next projects better and unrepeated.
Defect in analyzing and repairing may be divided to create the suitable actions depending on the different characters.
6. Configuration management
Aim of configuration management (CM) is to establish and ensure the perfect of the intermediary products as well as the final products of a software project during the period of that project.
CM consists of many actions; however, there are four main actions: identification, control, accounting, and audit. CM will be different according to the largeness and the complexity of project, the scale, and the level of application. With the large and complex system, each CM action is undertaken by the detailed role people. Depending on requirements, some CM actions are informal and formal to well-manage the software development, particular in managing the changes in project.
Reference: “Configuration management…” (ID: A0506_122).
7. Security
Security is a stinging issue because it is not found until the system is broken. Security consists of three main aspects: data content security, data transmission security and physical security of data store. Security actions are applied for the data content and the physical data store.
The elements or reasons impacting on data or data center of software system are very diverts. That may be natural or unnatural, for example: natural calamity, burning, virus, hacker, and sabotage of the companies’ staff: stealing data and even appearing the terror actions. In some organizations, storing data and transmission data security is a “live or die” issue.
A reason often makes data fail that data are changed unintentionally and uncontrollably. When data are wrong, the software system using these data will give us the wrong results. With the users, that system is not good, even unusable.
A “good” software system must note all factors impacting on the data or action of system. A “good” system needs have ability to restore data and action when the system happen the issue.
8. Education / Training
Simply, training is to prepare for software developers as well as software users to have enough knowledge and skills in order to implement their work.
All management measures, production technology, and supporting tools in software production become unusable or have the restricted effect if developers and users are not enough the essential knowledge and skills. Relating to this reason, ISO and CMM/CMMI have established that ability, knowledge, and skills of software developers are one of the key requirements to ensure norms and aims about quality.
An aspect is considered as a less important issue but it shows the understanding ability to use software of users. Users often only have ideas about requirements with software and do not know use or wrong use, which makes software “run” wrongly. Therefore, training users is the basic step. In reality, software developers have no time and skills to implement seriously training, so training is carried out by a responsible part of company.
9. Vendor Management
In the software groups, it is common on buying or hiding a product or service from the 3rd supplier. “Buying” may consist of the simple goods such as computer, printer, and the software outwork services. Quality of “buying” product or service will greatly impact on product or service of the supplying groups for the customers if management is not good.
Because “buying” product or service is very diverts, organizations will have the relative measures and management level according to each kinds and complexity.
10. Risk management
Risk is an element lasting in each project. Opinion about the project assurance says “Good project managers are not surprised about the occurring event in the project.” It means that every hidden risks must be seen before and plan to solve the problems together.
Risk is an event which may appear anytime and it makes the project in a bad situation or even can become an accident preventing aims of project completely. There are some kinds of risks:
· Technology: The issue is the right and enough understanding about the given requirements for project and has the suitable method to solve that risk whether or not. The wrong understanding and the unsuitable method are the leading reason of failure.
· Management: Risks are related to management. They are diverts: plan, finance, human, changing requirement….
· Operation – run: Relating to run the system, consisting of:
o Training users – not enough
o Using wrongly the function of product – intentional or unintentional
o Maintaining the products deficiently
· Environment: Consisting of the environment about development, test, and use of product. There are risks outside, irrelativeness, virus…
· Testing: It is not enough time or wrong test, not clean out requirements.
The basic process of risk management consists of four steps:
· Defining the risks
· Surveying the level of effect if risks happen
· Finding the methods to solve risks
· Supervising risks and implementing the methods to solve risks
There are many different methods to solve or minimize the impact of risks. Practically, kinds of methods are as following:
- Rejecting: When cost to reject risk is low or risk will impact seriously.
- Preventing
- Minimizing loss: When it is unable to prevent or reject risks, we can implement the methods to minimize ability in happening or minimize cost to repair
- Accepting: If cost of rejecting, preventing, and minimizing is too much or effect of risk is unremarkable or ability of risk is very low, we must accept to “live together” with risks.
In reality, risk management is a complex process; however, it is not aim of this content.
Some important elements
Beside 10 elements above, some important elements also impact on software quality.
1. Software maintenance
Software maintenance is generally considered as the expanding and repeating part of a process in software development.
Software maintenance consists of two main actions: repairing errors and improve software according to the arising requirements.
Each maintenance action is implemented as an action in the development period and the changing requirement is requirement to leading the maintenance action.
2. Document
Due to misunderstanding or fearing to apply ISO or CMM/CMMI, many organizations will arise too much documents. It is essential that they must clearly understand meaning and aim of documents.
Aim of documents is to note requirements of software. How these requirements are being implemented and how to use, maintain, and improve software – it helps the project itself and stakeholders know all work of project.
3. Machine Management
Although how many the quality management methods are established, the suitable human and the fitting machine management are the key factor to the system effectiveness.
Virtually, there are many management models, the image 3 and 4 show that two of the normal models, each model have the particular advantages and disadvantages in accordance with the specific characteristic of each organization. So we can use the suitable model.
In image 3, management model show saving the cost, the project general leader will be responsible for quality not especial cost for staff. On the other hand, in reality, the cost is higher because it often arises when the project general leader spends on the one leading to the other one. Besides, the project general leader often spends much time on developing product, the other parts are inattentive even the quality testing is too.
In image 4, the quality responsibility part is independent and its reporting channel is also independent with the project. The report may be gone straight up the highest management level if it is necessary. With this model, success depends on the supporting, cooperation relationship between the quality part and the product development part. This relationship between these two parts is very close in the strong companies.
Machine management still conform the common principle although there are many models: If staff or the quality responsibility groups are in the lower position than the supervised group (production/development), that quality system is not strong and is considered as having the problems.
Conversely, a good management model together with the quality rules are not enough. It is important that in the strong Quality Management System, each member must implements well their roles.
4. Designing and running Quality Assurance System (QAS)
Designing and running Quality Assurance System (QAS) is firstly closed with defining clearly function and authority of all participants, actions, and detailed responsibilities for each position. The next is to plan, design, and apply the rules and processes of QAS.
There are 4 key rules and elements to ensure success of a QAS:
1. Making the quality culture: “Let do everything right for the first time”
2. Defining clearly responsibility and authority of participants
3. Describing clearly parts of QAS
4. Planning standards and processes for QAS
People using directed processes for QAS must participate sooner and better as well as complete. Their participation is the important element to make these processes be accepted and have the high use value in cooperation with minimizes the unpractical and unrealizable of process.
A very essential element is the adequate support and control of the senior management to progress on developing and applying QAS. Supervision and solution of the senior management help to solve the issues, improve the levels’ responsibilities, and promote the progress in order to understand obviously the quality culture in the total management.
Conclusion
A SQAS not only has process, testing, or order but also connects closely between many elements. The final aim of SQAS is that basing on results of elements forming, supplying information. The information is input for the right decisions about management together with bringing benefit when applying software development process.
(*) CMMI: Capability Maturity Model Integration
(**) SEI: Software Engineering Institude.
Ngô Văn Toàn
Global CyberSoft Việt Nam
