Quality Assurance

There are three kinds of changes in the revision of CMMi Version 1.1 to CMMi Version 1.2:

- Wording changes in the practices, sub practices, and examples.
- Restructuring of some information into different chapters.
- There are about few major changes.

Major changes are:

1. CMMI for Development – name of model changed to CMMI for Development. Although name changed, but maintenance activities still remains the same. Maintenance also requires developing requirements, managing changes, planning and monitoring activities, ensuring quality etc.

2. Common features are eliminated.

3. More information is added relating to amplifications, GP (Generic Practices), examples, and hardware engineering.

4. Both the staged and continuous representations are now in one document.

5. Merge the supplier sourcing in the Supplier Agreement Management (SAM) process area. Also, Integrated Supplier Management (ISM) is removed and its concepts incorporated into SAM.

6. Advanced practices used in the continuous representation are eliminated. However, in some cases, base practices and advanced practices are combined into specific practices.

7. The numbering system for specific practices follows that of the staged representation, not that of the continuous representation.

8. Integrated Product and Process Development (IPPD) material is simplified and consolidated. IPPD is considered an “addition,” not reflected as separate process areas. Two Process areas are removed:

- Organizational Environment for Integration
- Integrated Teaming were removed

9. IPPD concepts like work environment material etc. are added to

- Organizational Process Definition (OPD)
- Integrated Project Management (IPM)

10. Guidelines for declaring a process area as “not applicable” is now clarified. Supplier Agreement Management is the only process area that can be considered “not applicable.”

11. The overview and glossary is now changed. New definitions are added to the glossary.

ISO 9001:2008 is an international standard published by the International Organization for Standardization. First time, it was published in 1987 and later revised in 1994, 2000 and in year 2008. In this year 2008, it went through revision in order to accommodate current needs. Hence, it is now referred to as ISO 9001:2008.

ISO 9001:2008 is a standard for the implementation of a quality management system. It provides a benchmarking for organizational performance in terms of product quality.

In ISO 9001, the term “product” refers to both tangible and intangible products. It is applicable to all kinds of organization, whether public, private or non-governmental. It contains eight sections or clauses:

1. Scope
2. Normative reference
3. Terms and definitions
4. Quality management system
5. Management responsibility
6. Resource management
7. Product realization
8. Measurement, analysis and improvement

ISO 9001:2008 Documentation Requirements: The ISO 9001 is not focused on documentation. Basically, it views documentation as a medium that supports QMS (Quality Management System) in terms of providing evidence of implementation and conformity to specified requirements.

To fullfill, ISO 9001:2008 documentation requirements, you must establish the following documents, and if you know and understand their functions you will see why:

1. Documented statements of a quality policy and quality objectives

2. A quality manual

3. Below documented procedures required by this International Standard:

– Control of documents
– Control of records
– Control of non-conformances
– Internal audit
– Corrective action
– Preventive action

4. Documents needed by the organization to ensure the effective planning, operation and control of its processes.

5. Records required by your quality management system and this International Standard

Manuals, procedures, work instructions, guidelines, annexures and forms or formats etc. are methods to control a process effectively. They promote uniformity and consistency in the way things are done. They also provide a basis for future reference. They can also be used as a training tool in terms bringing new employees up to speed of the organization’s operations.

Another important part of documentation is Records. These are generated as a result of the implementation of processes. They may exist throughout the quality management system. Records management is a process of ensuring the proper creation, maintenance, use and disposal of records in order to achieve efficient, transparent and accountable management.

A strong and effective records management programme is advantageous because:

1. A well-organized indexing system enables an organization to find information easily.

2. The orderly and efficient flow of information enables the organization to perform its functions successfully and efficiently.

3. Authoritative and reliable records are created and maintained in an accessible, intelligent and usable manner to support the business and accountability requirements of the organization.

4. Efficiency and economy are ensured by eliminating unnecessary duplication of records.

5. A retention and disposal programme ensures that the organization maintains only those records it really needs for functional purposes.

6. Controls are exercised to ensure that only authorized persons have access to the information, thus preventing information and / or the records themselves from being stolen or damaged. This ensures the protection of privacy and confidentiality, and prevents the inappropriate disclosure of information that could harm the organization or infringe the privacy rights of individuals.

Organizations can only be effective and efficient if records management is considered a business process designed to support business objectives, a resource and utilized effectively to achieve business objectives. The organization needs to create and maintain a culture which will promote effective and efficient records management to facilitate efficient and timely decision-making.

Also See:

• Management Principles in ISO 9001:2000
• Revision of ISO 9001:2000 to ISO 9001:2008

Q1. Malcolm Baldrige National Quality Award (MBNQA) defines one of the roles of a leader as establishing a vision. You know that a vision must be expressed in terms external to the organization, and define the organization ideally would like to accomplish. You have asked your IT director to develop a vision for the function. He tells you that the IT-function already has a mission, and his vision is to accomplish that mission. How do you explain to your director the difference between a vision and a mission?

Q2. ‘Zero defects’ Do you agree? Explain with examples and reasons.

Q3. Your operational department encounters production defect at the rate of 3 defects pre 1000 lines of code. During a vendor meet you come across another company ABC that is of the same size of yours and in the same industry. This company’s production defect is 2 defects per 1000 lines of code. Can you conclude that the ABC operation department is better that yours? Can you use this for benchmarking?

Q4. Dr. Deming’s 11th principle states no numerical goals. To abide the law your company has to pay tax and payroll charges every year. Does this contradict 11th principle? Explain it.

Q5. You are appointed QA Manager and your Director / Management wants you to do the testing and QC review. How would you convince your IT Director / Management that this is not your responsibility as a QA Manager.

Q6. You are a QA manager in the Software Quality Assurance team that has prescribed a set of processes and procedures to be followed by the project team whenever a modified code / patch / application is released to the client.

Project Manager informs you that a release is required urgently by an important client. He says, all the steps in the procedure prescribed have been followed but due to time constraints each step is covered only to the extent of 35-40%. And, the client needs the release in the next 2 hours itself.

What will be your decision. Allow or not to allow the release? Explain it with proper reason.

Also See:

• CSQA Subjective questions sample paper – 1
• CSQA Subjective questions sample paper – 2

In continuation to my previous post Software Quality Attributes, I’m here writing some of the formulas of the various Software Quality Attributes:

1. Correctness: Extent to which a program satisfies its specifications and fulfills the user’s mission objectives. It can be calculated as

= (No. of non-conformance to requirements / Total no. of requirements)*100

Correctness can also be calculated as

= (No. of requirements fulfilled) / (Total no. of requirements) * 100

2. Reliability: Extent to which a program can be expected to perform its intended function with required precision. The formula of reliability is

= (Mean Time To Failure) / (Total Run Time) * 100

It can also be calculated as

= (Mean Time Between Failure) / (Total Run Time) * 100

3. Efficiency: The amount of computing resources and code required by a program to perform a function.

Efficiency = (Memory Usage) / (Total Memory) * 100

4. Integrity: Extent to which access to software or data by unauthorized persons can be controlled.

Integrity = (No. of successful attempts) / (Total no. of attempts) * 100

5. Usability: Effort required learning, operating, preparing input, and interpreting output of a program.

Usability = (Total Training Time) / (Total development time) * 100

6. Maintainability: Effort required locating and fixing an error in an operational program.

Maintainability = (Time spent to fix a bug) / (Total development time) * 100

7. Testability: Effort required testing a program to ensure that it performs its intended function. Testability can be calcluated as

= (Time spent in testing the functionality) / (Total development time) * 100

8. Flexibility: Effort required modifying an operational program.

Flexibility = (Time spent to fix a bug) / (Total development time) * 100

9. Portability: Portability is the software codebase feature to be able to reuse the existing code instead of creating new code when moving software from an environment to another.

Portability = (No. of successful ports) / (Total no. of ports) * 100

10. Reusability: Extent to which a program can be used in other applications. It is related to the packaging and scope of the functions that programs perform.

Reusability = (No. of reusable components) / (Total no. of components) * 100

11. Interoperability: Effort required to couple one system with another.

Interoperability = (Time spent in coupling the system) / (Installation Time) * 100

Also see:

• Software Quality Attributes

Quality Guru Philip Crosby has developed 14 steps for an organization to follow in building an effective quality program:

1. Management is committed to quality – and this is clear to all: Clarify where management stands on quality. It is necessary to consistently produce conforming products and services at the optimum price. The device to accomplish this is the use of defect prevention techniques in the operating departments:

- Engineering
- Manufacturing
- Quality Control
- Purchasing
- Sales and others.

2. Create quality improvement teams – with representatives from all workgroups and functions: These teams run the quality improvement program. Since every function of an operation contributes to defect levels, every function must participate in the quality improvement effort. The degree of participation is best determined by the particular situation that exists. However, everyone has the opportunity to improve.

3. Measure processes to determine current and potential quality issues: Communicate current and potential nonconformance problems in a manner that permits objective evaluation and corrective action. Basic quality measurement data is obtained from the inspection and test reports, which are broken down by operating areas of the plant. By comparing the rejection data with the input data, it is possible to know the rejection rates. Since most companies have such systems, it is not necessary to go into them in detail. It should be mentioned that unless this data is reported properly, it is useless. After all, their only purpose is to warn management of serious situations. They should be used to identify specific problems needing corrective action, and the quality department should report them.

4. Calculate the cost of (poor) quality: Define the ingredients of the COQ and explain its use as a management tool.

5. Raise quality awareness of all employees: Provide a method of raising the personal concern felt by all personnel in the company toward the conformance of the product or service and the quality reputation of the company. By the time a company is ready for the quality awareness step, they should have a good idea of the types and expense of the problems being faced. The quality measurement and COQ steps will have revealed them.

6. Take actions to correct quality issues: Provide a systematic method of permanently resolving the problems that are identified through previous action steps. Problems that are identified during the acceptance operation or by some other means must be documented and then resolved formally.

7. Monitor progress of quality improvement – establish a zero defects committee: Examine the various activities that must be conducted in preparation for formally launching the Zero Defects program - The quality improvement task team should list all the individual action steps that build up to Zero Defects day in order to make the most meaningful presentation of the concept and action plan to personnel of the company. These steps, placed on a schedule and assigned to members of the team for execution, will provide a clean energy flow into an organization-wide Zero Defects commitment.

Since it is a natural step, it is not difficult, but because of the significance of it, management must make sure it is conducted properly.

8. Train supervisors in quality improvement: Define the type of training supervisors need in order to actively carry out their part of the quality improvement program. The supervisor, from the board chairman down, is the key to achieving improvement goals. The supervisor gives the individual employees their attitudes and work standards, whether in engineering, sales, computer programming, or wherever.

Therefore, the supervisor must be given primary consideration when laying out the program. The departmental representatives on the task team will be able to communicate much of the planning and concepts to the supervisors, but individual classes are essential to make sure that they properly understand and can implement the program.

9. Hold zero defects days: Create an event that will let all employees realize through personal experience, that there has been a change. Zero Defects is a revelation to all involved that they are embarking on a new way of corporate life. Working under this discipline requires personal commitments and understanding. Therefore, it is necessary that all members of the company participate in an experience that will make them aware of this change.

10. Encourage employees to create their own quality improvement goals: Turn pledges and commitments into action by encouraging individuals to establish improvement goals for themselves and their groups. About a week after Zero Defects day, individual supervisors should ask their people what kind of goals they should set for themselves. Try to get two goals from each area. These goals should be specific and measurable.

11. Encourage employee communication with management about obstacles to quality (Error-Cause Removal): Give the individual employee a method of communicating to management the situations that make it difficult for the employee to fulfill the pledge to improve. One of the most difficult problems employees face is their inability to communicate problems to management. Sometimes they just put up with problems because they do not consider them important enough to bother the supervisor. Sometimes supervisors don’t listen anyway. Suggestion programs are some help, but in a suggestion program the worker is required to know the problem and also propose a solution. Error-cause removal (ECR) is set up on the basis that the worker need only recognize the problem. When the worker has stated the problem, the proper department in the plant can look into it. Studies of ECR programs show that over 90% of the items submitted are acted upon, and fully 75% can be handled at the first level of supervision. The number of ECRs that save money is extremely high, since the worker generates savings every time the job is done better or quicker.

12. Recognise participants’ effort: Appreciate those who participate. People really don’t work for money. They go to work for it, but once the salary has been established, their concern is appreciation. Recognize their contribution publicly and noisily, but don’t demean them by applying a price tag to everything.

13. Create quality councils: Bring together the professional quality people for planned communication on a regular basis. It is vital for the professional quality people of an organization to meet regularly just to share their problems, feelings, and experiences, with each other. Primarily concerned with measurement and reporting, isolated even in the midst of many fellow workers, it is easy for them to become influenced by the urgency of activity in their work areas. Consistency of attitude and purpose is the essential personal characteristic of one who evaluates another’s work. This is not only because of the importance of the work itself but because those who submit work unconsciously draw a great deal of their performance standard from the professional evaluator.

14. Do it all over again – quality improvement does not end: Emphasize that the quality improvement program never ends. There is always a great sign of relief when goals are reached. If care is not taken, the entire program will end at that moment. It is necessary to construct a new quality improvement team, and to let them begin again and create their own communications.

From the above 14 points Philip Crosby communicated that management should take prime responsibility for quality, and workers only follow their managers’ example. Crosby defined the Four Absolutes of Quality Management:

- Quality is conformance to requirements
- Quality prevention is preferable to quality inspection
- Zero defects is the quality performance standard
- Quality is measured in monetary terms – the price of non-conformance

According to Crosby, five characteristics of an highly successful organisations are:

- People routinely do things right first time
- Change is anticipated and used to advantage
- Growth is consistent and profitable
- New products and services appear when needed
- Everyone is happy to work there

SQA audit is the audit conducted by the SQA of the project / function.

From the CMMi point of view below are the four goals:

1. SQA activities are planned.

2. Adherence of software products and activities to the applicable and defined standards, procedures, and requirements are verified objectively.

3. All affected groups and individuals are informed of software quality assurance activities and results.

4. Non-compliance issues that cannot be resolved within the software project are addressed by senior management.

Commitment needed: The project follows a written organizational policy for implementing software quality assurance (SQA). This policy typically specifies that:

1. The SQA function is in place on all software projects and functions.

2. The SQA group has a reporting channel to senior management that is independent of

- Project manager
- Software engineering group
- And other software-related groups

3. Senior management should periodically reviews the SQA activities and results.

Four Abilities:
1. A group that is responsible for coordinating and implementing SQA for the project (i.e., the SQA group) exists.

2. Adequate resources and funding are provided for performing the SQA activities:

- A manager is assigned specific responsibilities for the project’s SQA activities.
- A senior manager, who is knowledgeable in the SQA role and has the authority to take appropriate oversight actions, is designated to receive and act on software non-compliance items.
- Tools to support the SQA activities are made available.

3. Members of the SQA group are trained to perform their SQA activities.

4. The members of the software project receive orientation on the role, responsibilities, authority, and value of the SQA group.

Eight Activities:
1. An SQA plan is prepared for the software project according to a documented procedure. This procedure typically specifies that:

- The SQA plan is developed in the early stages of, and in parallel with, the overall project planning.
- The SQA plan is reviewed by the affected groups and individuals.
- The SQA plan is managed and controlled.

2. The SQA group’s activities are performed in accordance with the SQA plan. The plan covers:

- Responsibilities and authority of the SQA group.
- Resource requirements for the SQA group (including staff, tools, and facilities).
- Schedule and funding of the project’s SQA group activities.
- The SQA group’s participation in establishing the software development plan, standards, and procedures for the project.
- Evaluations to be performed by the SQA group.
- Audits and reviews to be conducted by the SQA group.
- Project standards and procedures to be used as the basis for the SQA group’s reviews and audits.
- Procedures for documenting and tracking non-compliance issues to closure.
- Documentation that the SQA group is required to produce.
- Method and frequency of providing feedback to the software group and other software-related groups on SQA activities.

3. The SQA group participates in the preparation and review of the project’s software development plan, standards, and procedures.

- The SQA group provides consultation and review of the plans, standards, and procedures with regard to compliance to organizational policy, compliance to externally imposed standards and requirements (e.g., standards required by the statement of work), standards that are appropriate for use by the project, topics that should be addressed in the software development plan, and other areas as assigned by the project.
- The SQA group verifies that plans, standards, and procedures are in place and can be used to review and audit the software project.

4. The SQA group reviews the software engineering activities to verify compliance:

- The activities are evaluated against the software development plan and the designated software standards and procedures.
- Deviations are identified, documented, and tracked to closure.
- Corrections are verified.

5. The SQA group audits designated software work products to verify compliance.

- The deliverable software products are evaluated before they are delivered to the customer.
- The software work products are evaluated against the designated software standards, procedures, and contractual requirements.
- Deviations are identified, documented, and tracked to closure
- Corrections are verified.

6. The SQA group periodically reports the results of its activities to the software engineering group.

7. Deviations identified in the software activities and software work products are documented and handled according to a documented procedure. This procedure typically specifies that:

- Deviations from the software development plan and the designated project standards and procedures are documented and resolved with the appropriate software task leaders, software managers, or project manager, where possible.
- Deviations from the software development plan and the designated project standards and procedures not resolvable with the software task leaders, software managers, or project manager are documented and presented to the senior manager designated to receive non-compliance items.
- Non-compliance items presented to the senior manager are periodically reviewed until they are resolved.
- The documentation of non-compliance items is managed and controlled

8. The SQA group conducts periodic reviews of its activities and findings with the customer’s SQA personnel, as appropriate.

Measurement: Measurements are made and used to determine the cost and schedule status of the SQA activities.

Three Verifications:
1. The SQA activities are reviewed with senior management on a periodic basis.

2. The SQA activities are reviewed with the project manager on both a periodic and event-driven basis.

3. Experts independent of the SQA group periodically review the activities and software work products of the project’s SQA group.

Sample Checklist of SQA audit:

1. Is the Work order Amended for the change in PM or extension of Project?

2. Are the latest versions of Development Plans and Estimates Approved?

3. Is the schedule updated?

4. Are the planned efforts for the current phase (from schedule), consistent with the effort distribution on SQAP and the latest approved estimate?

5. Is the actual start and end dates for the activities completed since last SQA audit?

6. Are the Internal Review meetings held and Minutes of Meeting prepared?

7. Are the minutes of meeting circulated to affected support groups?

8. Are the Efforts captured in the effort capturing tool?

9. Is there any evidence for implementing the corrective action identified on the previous metrics sheets?

10. Are the metrics tracked and the metrics sheet updated, as per the frequency of analysis in Software Quality Assurance Plan?

11. Is the Master List of Project Document updated?

12. Are Change Control Forms available for the changes in Configurable Items?

13. Are staffing Plan, Risk Plan updated?

14. Are weekly status reports being sent to Sr. Management?

15. Are status reports being sent to customer as per Software Project Management Plan?

16. Is project back up taken? Is any Back up restoration check conducted?

17. Has DAR (Decision Analysis and Resolution) been performed as planned?

18. Has CAR (Casual Analysis and Resolution) been performed at end pf phases?

19. Is Requirements Trace ability report updated?

20. Are the relevant audits conducted for completed activities?

21. Are peer review records available for the work products developed since last audit? Are the peer review findings tracked to closure?

22. Are updated test cases with actual results available?

23. Are the tools, standards and templates used for the current development activity, identified in the relevant plans?

24. Are the Non compliances for the audits last conducted closed?

Many methods are used to perform the process and product assurance functions. Audits are used to examine the conformance of a development process to procedures and of products to standards. Embedded SQA activities, which have the purpose of detecting and removing errors, take a variety of forms, including inspection and testing. Assessment is another method of process assurance. Analysis techniques, such as causal analysis, reliability prediction and statistical process control, help ensure both process and product conformance.

Process Assurance: Schulmeyer defines software quality assurance as “. . . the set of systematic activities providing the evidence of the ability of the software process to produce a software product that is fit for use.”

SQA oversight provides management with unbiased feedback on process compliance so process lapses can be addressed in a timely fashion. It provides management with an early warning of risks to product quality and can provide recommendations to address the situation.

It is essential that the software quality assurance personnel have a reporting path which is independent of the management responsible for the activities audited and the associated daily conflicts generated by schedule and budget. Independent oversight, through various methods, encourages adherence to the official process. Locating an appropriate level of management where SQA will have frequent access, active support, and be above the conflicts of interest may be a difficult but necessary step.

The methods typically used to accomplish process assurance include SQA audit and reporting, assessment and statistical process control analysis.

Product Assurance: Assurance that the product performs as specified is the role of product assurance. This includes “in process,” or embedded, product assurance, as well as some methods that involve independent oversight.

The purpose of embedded SQA processes is product quality assurance. The activities are part of the development life cycle which will “build-in” the desired product quality. This focus allows identification and elimination of defects as early in the life cycle as possible, thus reducing maintenance and test costs. Embedded SQA methods include formal inspection, reviews, and testing.

Independent oversight functions can also be a part of product assurance. An independent test function, or testing which is witnessed by an independent entity such as SQA, is one method of providing product assurance. Other options include tests witnessed by customers, expert review of test results, or audits of the product.

Methods and supporting technologies
Many methods are used to perform the process and product assurance functions. Audits are used to examine the conformance of a development process to procedures and of products to standards. Embedded SQA activities, which have the purpose of detecting and removing errors, take a variety of forms, including inspection and testing. Assessment is another method of process assurance. Analysis techniques, such as causal analysis, reliability prediction and statistical process control, help ensure both process and product conformance.

1. Audit: Auditing is a method used in both process and product assurance. Audits are embedded into the software life cycle, as well as being performed as part of SQA.

An SQA audit is performed to “determine the adherence to established standards and procedures.” Evaluation of the sufficiency or effectiveness of the procedures or standards is occasionally part of an SQA audit. This type of audit examines records, as opposed to products, according to a sampling process to determine if procedures are being followed correctly. Such an audit is often performed by an external auditor who is not part of the software project.

In contrast, an embedded audit examines products to determine if the software products conform to standards and if project status is accurate. An independent auditor may perform this function or evaluate the records of such an audit that was performed by the development process. For documents, the audit is often performed manually. For code, it may be done manually or by an automated tool.

2. Embedded SQA Error Detection Methods:

- Formal Inspection
- Reviews
- Walkthroughs
- Testing

– Formal Inspection: Formal inspection is an examination of the completed product of a particular stage of the development process (such as design or code), typically employing checklists, expert inspectors, and a trained inspection moderator. The objective is to identify defects in the product. There are many techniques of doing inspections, but many follow the methods developed by Michael Fagan over 20 years ago.

Certain projects which have an effectively performing inspection process report better than 80% defect detection rates.

- Reviews: Reviews are also applied as an alternative to formal inspections as an SQA method. Informal design and code review methods are difficult to quantify since they are generally done at the discretion of the product author, do not follow a detailed process and are not reported at the project level. Informal review is a valuable alternative if the more effective formal inspection is not used.

The term “review” is also used to refer to project meetings (e.g., a product design review) which emphasize resolving issues and which have a primary objective of assessing the value of the product.

- Walkthroughs: Walkthroughs are meetings in which the author of the product acts as presenter to proceed through the material in a stepwise manner. The objective is often raising and/or resolving design or implementation issues. Walkthroughs tend to be informal and lacking in “close procedural control.”

- Testing: Testing is a dynamic analysis technique that has the primary objective of error detection. Testing of software is performed on individual components during intermediate stages of development, subsystems following integration, and entire software systems. It involves execution of the software and evaluation of its behavior in response to a set of input against documented, required behavior.

3. Assessment: Assessment is determining the capability of a process through comparison with a standard. The exact methods used are dependent on the standard applied. Two standard assessment methods which are frequently employed are ISO 9000 and SEI SW-CMM. Malcolm Baldrige is another assessment standard, but is not used as often by software projects.

The Software Engineering Institute (SEI) at Carnegie Mellon University was established by Congress in 1984 to improve the practice of software engineering. A key product developed by the SEI to aid in this mission is the Software Capability Maturity Model. The SW-CMM is a model for software process improvement. The model establishes criteria describing the characteristics of a mature software organization and has staged software process maturity levels. There are 5 levels of process maturity, with level 1 being the lowest and level 5 being the highest. Within the maturity levels are groupings of software engineering topics called Key Process Areas (KPAs).

The ISO 9001 international standard was established to address quality requirements across diverse industries. As such, the requirements within the standard are written in a generic manner to accommodate the diversity of applications. The corresponding ISO 9000-3 document gives guidance for applying the standard to software. Note that, as of this writing, the ISO 9001 standard is under revision.

Use of assessments may involve individuals outside of the organization such as a CMM lead assessor or an ISO registrar, but many times the assessment is conducted using internal resources to identify areas for improvement or in preparation for a formal assessment. Assessment uses a combination of random auditing and interviewing to answer a list of questions which is tailored to fit the organization being assessed.

4. Analysis:

- Causal Analysis and Defect Prevention Processes
- Reliability Prediction
- Statistical Process Control

- Causal Analysis and Defect Prevention Processes: The purpose of these activities is to address the process weaknesses that allowed product defects to be inserted in order to prevent reoccurrence of similar types of defects. One method to accomplish this objective includes root cause analysis and process brainstorming. First the team of individuals, which may include developers and other analysts, determines the root cause of the defect insertion. If the cause is systemic and/or may be repeated, brainstorming for a remedy is performed to decrease the likelihood of reoccurrence of similar defects under similar circumstances. Ideas for process improvement are generated from the brainstorming session and passed on to a process management team. These activities may be performed at various stages of the software life cycle, but it is recommended that the elapsed time between defect discovery and this type of analysis be minimized.

- Reliability Prediction: The IEEE Standard Glossary of Software Engineering Terminology definition of software reliability is: “The ability of the software to perform its required function under stated conditions for a stated period of time.” The ability to predict the reliability of a software system would enable project management to better perform product assurance and assess readiness for release. Three bases used in estimating reliability are failure record, behavior for a random sample of input points, or quantity of actual and “seeded” faults detected during testing. However, these methods are imperfect; software reliability prediction is still a science under development. Furthermore, this technique requires an extensive error history database.

- Statistical Process Control: Statistical process control is the use of statistical methods to assure both process and product quality. These methods include Pareto analysis, Shewhart control charts, histograms, and scatter diagrams. This technique can be used to evaluate if a process is out of statistical control, thus indicating process defects and/or potential for increased product defects.