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 3^rd 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

Although, in Vietnam, there are not much software companies at the similar level of CMM/CMMI, the start of processing field and software production in recent years, competition as well as the customers’ increasingly requirements have promoted the companies build the quality management systems according to the international models.

There are the remarkable differences between CMMI 1.1 and CMMI 1.2. We have tried to show the basest marks in the scope of a newspaper in order to help readers understanding generally. From that, it is easier for them to orient in the more detailed research about CMMI 1.2.

There is hundreds of companies, organizations in the world building the quality processes according to CMMI 1.1 version (Vietnam companies also), it is necessary to have the route with the suitable time framework to move CMMI 1.2. Wherefores, we firstly give a cursory expositon about SEI’s policies in transition between CMMI 1.1 and CMMI 1.2.

1. Policies in transition between CMMI 1.1 and CMMI 1.2

The transition time – framework

· The transition time starts from August, 25^th, 2006 and finishes August, 31^st, 2007.

The period of validity of CMMI 1.1:

· Because of having the new policies together with CMMI v1.2, the organizations having been valuated and achieved the level of CMMI will be recognized and maintained the validity of assessing results on SEI’s website in the maximum time of three years since finishing the rate.

· These policies also apply for the groups identifying about CMMI 1.1.

The period of validity for the formally training courses about CMM 1.1:

· SEI asks the companies participate the formally compulsory course about CMMI (Introduction to CMMI) recognized by SEI lecturers when they applying CMMI.

· The formally courses about CMMI 1.1 will not be identified after December, 31^st, 2006 due to the transition policies.

· In 2007, the formally courses about CMMI 1.2 are learnt by the recognized lecturers of SEI for CMMI 1.2. In means that lecturers for CMMI 1.1 are improved the level of CMMI 1.2 and identified by SEI from 2007.

Date of validity of evaluations according to CMMI 1.1

· All of evaluations in the period of onsite evaluation will not recognized if carrying out after August, 31^st, 2007 according to CMMI 1.1 (SCAMPI Class A v1.1).

· All of evaluations applying for connecting between CMMI 1.1 and 1.2 are regularly identified in the period of transition between CMMI 1.1 and 1.2 (August, 25^th, 2006 – August, 31^st, 2007)

· Evaluations for CMMI 1.1 or SCAMPI Class v1.1 are regularly identified like CMMI 1.1.

· SCAMPI, v1.1, or v1.2 evaluations in the period of onsite from November, 01^st, 2006 must use “Appraisal Disclosure Statement” – new version v1.2 (ADS v1.2).

2. The new policies to CMMI 1.2

· SCAMPI –Evaluations (class A – the period of onsite evaluation) will have valuation in the maximum period of three years. After three years, if the groups want to identify the level of CMMI, they must be reassessed.

· SCAMPI –Evaluation results of a group are only declared in public (newspapers, website of the groups achieving CMMI, website showing the list of the groups achieving SEI’s CMMI) or by SEI-authorized SACMPI Lead Appraiser. This person must be absolutely independent with the appraised organizations.

· SEI-certified High Maturity Appraiser will assess the high level CMMI (level four and five), it is different with SEI-certified High Maturity Appraiser for the level two, three. SEI will start to certify the senior- Appraisers from October, 2006.

· New version ADS has been remarkably expanded the sections in order to supply more insite information of the assessment. When the result of assessment is announced on SEI’s website, information on ADS report is also in public, apart from the emotional projects or the exclusive information.

3. Changes in CMMI v1.2

There are many changes and new marks in CMMI 1.2 but we only introduce the main marks in general.

Basically, CMMI 1.2 consists of three main improvements:

· Improvement about the models

· Improvement about the assess methods

· Improvement about trainings

Improvement about the models

· Two forms (Staged and Continuous) in CMMI 1.1 are separated by two individual documents, but they are in a document in CMMI 1.2.

· The concepts about “Basic and Advanced Practices” and “Common Feature” are destroyed.

· “Genetic goal” and “practices descriptions” are moved to the two sections.

· The expanding sections and examples about hardware are added.

· All of concepts are unified in the glossary.

· Practices about IPPD – Integrated Product and Process Development are merged and simplified. It is unessential to have “Process Development” for IPPD in the documents.

· “SAM – Supplier Agreement Management” and “SM – Integrated Supplier Management” are unified. The sections and added practices about Supplier Sourcing are also destroyed.

· “Genetic Practices” is explained better, some are added couple with information showing how for the processes helping to carry out these Genetic Practices.

· The necessary documents are added to ensure the opening of the processes when the projects start.

· Name of CMMI model is replaced by “CMMI for Development” (CMMI-DEV) to reflect the new structures of CMMI.

With CMMI 1.2, all of PA – Process Areas are changed a part. However, some of particular PAs are changed more than the other ones, in the box there are the more changed and clearest PAs.

You should read the added part “The detailed comparation between CMMI 1.1 and CMMI 1.2.” to understand clearer about the changes.

Improvement about the assess methods

· Reject the requirements about the supporting tools, for example: about the survey…

· Add the instructions about the changed practices.

· Establish the maximum time limit for the each assess

· Add the requirements for taking the models when evaluating

· Expand the scale for considering the ready, applying for the evaluated organizations, the evaluated groups, the tools and the together services

· Require the signature of the sponsors for “ADS”-“Appraisal Disclosure Statement”

· Restrict the validity of the assess result in the maximum period of three years

Basically, the improvements basing on the assess methods are in the main points as following:

· Minimize the complex and the obscure

· Supply more instructions in case they need

· Improve strongly the plans and the evaluations

· Improve strongly the reports and the evaluations

· Strengthen powerfully the requirements for the general appraiser

You should load the website to understand more: http://www.sei.cmu.edu/cmmi/adoption/pdf/v12-scampi-changes.pdf

Improvement about trainings

· Reform all of the training documents to suit for the changes and the new marks of CMMI 1.2 and the assess methods SCAMPI 1.2.

· Improve consistency and closely the training documents

· Upgrade the training courses:

- Introduction to CMMI

- Intermediate concepts of CMMI

- SCAMPI Lead Appraiser SM Training

- SCAMPISM B and C Team Leader Training

- Instructor Training

- CMMI v1.2 Upgrade Training

You can download the website: http://www.sei.cmu.edu/cmmi/adoption/pdf/v12-training-changes.pdf

4. CMMI 1.1 Vs CMMI 1.2

The organizations and individuals have spent many years on researching and applying CMMI 1.1, they should clearly understand the changes between CMMI 1.1 Vs CMMI 1.2 in order to make the obvious plans for improving or applying the new version 1.2, together with helping to save time in surveying the version 1.2 completely.

To get the detail changes about the different marks between CMMI 1.1 and CMMI 1.2, you can download the websites:

• http://www.sei.cmu.edu/cmmi/models/compare-v12-pas.pdf

• http://www.sei.cmu.edu/cmmi/adoption/pdf/v12-model-changes.pdf

The detailed documents are announced and allowed to download by SEI. 

Tinhvan group was founded in 1997. Now we have 4 member companies:

• Tinhvan Outsourcing Joint Stock Company (TVO): focusing on software outsourcing and IT services for clients in foreign markets.

• Tinhvan Information Technology: focusing on Vietnam market to provide Tinhvan well-known package software products and solutions.

• Ho Chi Minh City branch (TVS): focusing on the Southern market of Vietnam.

• Tinhvan ERP Joint Stock Company (TVE): focusing on Enterprise Resource Planning (ERP) and enterprise solution.

Tinhvan is a privately owned professional software company with a strong financial performance and stable business.

Currently, Tinhvan has 260 people with state-of-the-art and experienced technical talents, teams recruited from top universities, leaders educated from abroad with hand-on experiences in software development and outsourcing.

Main services: Software development and Outsourcing Services, system integration, IT consultancy, ERP deployment.

We provide integrated and complicated informatics solutions, especially in Content Management System, Information Security, Solutions to Managerial Matters and Online Services Systems.

With creative managers, experienced system experts and young talented programmers, we have been achieving remarkable successes. Sharing one common target and direction, Tinhvan’s members are restlessly working to contribute to the growth of company and the success of clients.

Inherited a rich background of experience and culture from Tinhvan in Vietnam IT market, TVO is always believed to be the best selection for enterprises in outsourcing their IT related jobs.