January 2006 e-Newsletter

You may be familiar with the ISO 9001:2000 requirements for document control in clause 4.2.3 and for record control in clause 4.2.4. However, are you aware of the extra requirements that the industry sector schemes have added to those basic requirements and the available guidance on document and record control? If you've thought about expanding or strengthening your control of documents and records, this article may identify possible improvements for your system.

We will first review the ISO 9001:2000 document and record control requirements, and then examine the additional requirements contained in:

By examining what these industry schemes viewed as shortcomings in ISO 9001:2000, you may identify new practices, regardless of your current standard. Then, we will look at the guidance in these standards:

ISO has launched the development of an International Standard providing guidelines for Social Responsibility. The guidance standard will be published in 2008 as ISO 26000 and be voluntary to use. It will not include requirements and will thus not be a certification standard.

There is a range of many different opinions as to the right approach, ranging from strict legislation at one end, to complete freedom at the other. ISO is looking for a golden middle way that promotes respect and responsibility based on known reference documents without stifling creativity and development. Their work will aim to encourage voluntary commitment to social responsibility and will lead to common guidance on concepts, definitions and methods of evaluation.

The need for organizations in both public and private sectors to behave in a socially responsible way is becoming a generalized requirement of society. It is shared by the stakeholder groups that are participating in the Work Group on Social Responsibility to develop ISO 26000: industry, government, labor, consumers, nongovernmental organizations, and others, in addition to geographical and gender-based balance.

To learn more about ISO 26000, go to: http://www.iso.org/sr

A recent article at InternetNews.com by Sean Michael Kerner with the Gartner research firm includes predictions for six technology trends expected to cause significant disruption and drive opportunity for business and the Information Technology industry.

Computer Notebook usage has been growing at a rapid clip for years. Notebooks are not always used strictly for work purposes by employees as mobility and work extend the technology beyond normal office boundaries. Gartner is now predicting that within the next two years (by 2008), 10 percent of companies will mandate their employees buy their own notebooks. Gartner figures that firms will have some form of a "notebook allowance" similar to a car allowance offered by some companies today.

The IT Job Market is also predicted to undergo a shift with the need for specialists declining in favor of what Gartner calls "versatilists" that handle multiple disciplines and assignments. By 2010, Gartner has predicted that the IT specialist job market will decline by 40 percent.

Business Process Outsourcing (BPO) service providers are predicted to be big winners. According to Gartner's forecast, BPO service providers will reap an $11 billion bounty from insurance companies by 2008 as insurers update their legacy systems. Gartner expects by 2008 that BPO service providers will have the intellectual property and technology platforms to align with distribution channels (for example, bank and investment houses) and launch insurance ventures that capture up to one percent of the global annual premium total of life, annuity, and property and casualty products.

The aging baby boomer population is a key demographic trend that will also play out in the IT industry as investments in Healthcare Software increase 50 percent by 2009. That increased investment, according to Gartner, will yield a 50 percent reduction by 2013 in the level of preventable deaths.

The influence of Regulatory Compliance needs is expected to continue to increase and is predicted to cut into discretionary IT budgets all the way through 2008. Compliance spending, according to Gartner, is currently growing twice as fast as discretionary IT budgets and that trend is expected to continue.

Gartner expects that the six trends will provide opportunities for new and old market players and help to drive market growth. "To catch the waves of change at their early stages, vendors, users, and investors in technology will need to look outside their industries to find early adopters that provide inspiration for how these trends translate into business value," said Daryl Plummer, group vice president and chief Gartner Fellow in a statement.

An article written by Watts Humphrey in the online Crosstalk magazine discusses six quality principles for acquiring quality software. An edited copy of his article follows:

If the customer does not demand a quality product, he or she will probably not get one.

If you want quality products, you must demand them. But how do you do that? That is the subject of this article. I first define quality, then I discuss quality management, and then third, I cover quality measurement. Next, I describe the methods for verifying the quality of software products before you get them, and finally, I give some pointers for those acquisition managers who would like to consider using these methods. That, of course, is the most critical point; even when you demand quality, if you cannot determine that you will get a quality product before you get it, you are no better off than you are today, struggling to recover from the effects of getting poor-quality products.

Product developers typically define a quality product as one that satisfies the customer. However, this definition is not of much help to you, the customer. What you need is a definition of quality to guide your acquisition process. To get this, you must define what quality means to you and how you would recognize a quality product if you got one.

In the broadest sense, a quality product is one that is delivered on time, costs what it was committed to cost, and flawlessly performs all of its intended functions. While the first two of these criteria are relatively easy to determine, the third is not. These first two criteria are part of the normal procurement process and typically receive the bulk of the customer’s and supplier’s attention during a procurement cycle, but the third is generally the source of most acquisition problems. This is because poor product quality is often the reason for a software-intensive system’s cost and schedule problems.

Think of it this way: If quality did not matter, you would have to accept whatever quality the supplier provided, and the cost and schedule would be largely determined by the supplier. In simplistic terms, the supplier’s strategy would be to supply whatever quality level he felt would get the product accepted and paid for. In fact, even if you had contracted for a specific quality level, as long as you could not verify that quality level prior to delivery and acceptance testing, the supplier’s optimum strategy would be to deliver whatever quality level it could get away with as long as it was paid.

Since, at least for software, most quality problems do not show up until well after the end of the normal acquisition cycle, you would be no better off than before. I do not mean to imply that this is how most suppliers behave, but merely that this would be their most economically attractive short-term strategy. In the long term, quality work has always proven to be most economically attractive.

In principle, there are only two ways to address the software quality problem. First, use a supplier that has a sufficiently good record of delivering quality products so you will be comfortable that the products he provides will be of high quality. Then, just leave the supplier alone to do the development work. The second choice would be to closely monitor the development process the supplier uses to be assured that the product being produced will be of the desired quality.

While the first approach would be ideal, it is not useful when the supplier has historically had quality problems or where his current performance causes concern. In these cases, you are left with the second choice: to monitor the development work. To do this, you must consider the second principle of quality management.

To produce quality products consistently, developers must manage the quality of their work.

While you may want a quality product, if you have no way to determine the product’s quality until after you get it, you will not be able to pressure the supplier to do quality work until it is too late. The best time to influence the product’s quality is early in its development cycle where you can determine the quality of the product before it is delivered and influence the way the work is done. At least you can do this if your contract provides you the needed leverage.

This, of course, means that you must anticipate the product’s quality before it is delivered, and you must also know what to tell the supplier to do to assure that the delivered product will actually be of high quality. Therefore, the first need is to predict the product’s quality before it is built. This is essential, for if you only measure the product’s quality after it has been built, it is too late to do anything but fix its defects. This results in a defective product with patches for the known defects. Unless you have an extraordinarily effective test and evaluation system, you will not then know about most of the product’s defects before you accept the product and pay the supplier.

While you might still have warranties and other contract provisions to help you recover damages, and you might still be able to require the supplier to fix the product’s defects, these contractual provisions cannot protect you from getting a poor quality product. Because most suppliers are adept at avoiding liability for defects, you have not gained very much by contracting for quality. To get the benefits of including quality provisions in your contracts, you must determine the likely quality of the product during development.

To determine the likely quality of a product while it is being developed, we must consider the third principle of quality work.

To monitor product quality before delivery you must measure quality during development. Further, you must require that the developers gather quality measurements and supply them to you while they do the development work. What measures do you want, and how would you use them? This article suggests a proven set of quality measures, but first, to define these measures, we must consider what a quality product looks like.

While software experts debate this point, every other field of engineering agrees on one basic characteristic of quality: A quality product contains few, if any, defects. In fact, it has been shown that this definition is equally true for software. We also know that software professionals who consistently produce defect-free or near defect-free products are proud of their work and that they strive to remove all the product’s defects before they begin testing. Low defect content is one of the principal criteria used for identifying the quality of software products.

To define the needed quality measures, we must consider the fourth quality principle.

The quality of a product is determined by the quality of the process used to develop it.

This implies that to manage product quality, we must manage the quality of the process used to develop that product. If a quality product has few if any defects, that means that a quality process must produce products having few if any defects. What kind of process would consistently produce products with few if any defects? Some argue that extensive testing is the only way to produce quality software, and others believe that extensive reviews and inspections are the answer. No single defect-removal method can be relied upon to produce high-quality software products. A high-quality process must use a broad spectrum of quality management methods. Examples are many kinds of testing, team inspections, personal design and code reviews, design analysis, defect tracking and analysis, and defect prevention.

One indicator of the quality of a process is the completeness of the defect management methods it employs. However, because the methods could be applied with varying effectiveness, a simple listing of the methods is not sufficient. So, given two processes that use similar defect-removal methods, how could you tell which one would produce the highest quality products? To determine this, you must determine how well these defect-removal methods were applied. That takes measurement and analysis.

Since a test removes only a fraction of a product’s defects, to get a quality product out of test, you must put a quality product into test.

This principle also applies to every defect-removal method, from reviews and inspections, through all the tests and other quality verification methods. Every defect-removal method only removes a fraction of the defects in the product; so to understand the quality of a development process, you must understand the effectiveness of the defect-removal methods that were used. Further, to predict the quality of the delivered product, you must measure the effectiveness of every defect-removal step.

This also means that the highest quality development process would be the one that removed the highest percentage of the product’s defects early in the process and then had the lowest number of defects in final testing. Finally, this means that the highest-quality products are those with the fewest defects on entry into the final stage of testing.

To evaluate a process, you must measure that process and then compare the measures with your criteria for a quality process. This means that you must have criteria that define what a quality process looks like. Defect removal is like removing impurities from water. To get water that is pure enough to drink, we should find progressively fewer impurities in each successive filtration step. Finally, if we were going to actually drink the water ourselves, we would not want to find any impurities in the final filtration step.

In effect, this means that the last filtration step is really used to verify the quality of the water produced by the prior stages. If there were any significant impurities, you would want to put that water through the entire filtration process again, starting from the very beginning. Then you might be willing to take a drink. Similarly, for a software system, this suggests three quality criteria.

While these sound like appropriate process-quality criteria, they have one major failing – you will not have complete defect data until the end of the process after the product has been built, tested, accepted, and used. During the process you will only know the number of defects found so far and not the number to be found in future stages. This is a problem because a low number of defects in a defect-removal stage could be because the product was of high quality, because the defect-removal stage was improperly performed, or because the defect data on that stage were incomplete. This means that you must have multiple ways to determine the effectiveness of a defect-removal stage and that these ways must include at least one way to evaluate the effectiveness of that stage at the time that it is actually enacted. Partial defect data can be used to do that. In fact, without these data, there is no way to determine the effectiveness of the defect-removal stages.

The three things we can measure about a process stage are: (1) the time the developers spent in that stage, (2) the number of defects removed in that stage, and (3) the size of the product produced by that stage. Then, using historical data, you could compare the data for any type of defect removal stage with like data for similar stages from previously completed projects. As long as you had comparable data for completed projects, you could see what an effective review, inspection, or test looks like. You could then determine the quality of each stage of the current project and either agree that the supplier proceed or repeat some prior phases until the quality criteria were met.

To find the defects injected in one hour of design work, the average developer would have to spend 60*2/3.3 = 36 minutes reviewing that design. Similarly, since developers inject an average of about 4.6 defects per hour during coding and find about 6.0 defects per hour in code reviews, this same average developer should spend about 60*4.6/6 = 46 minutes reviewing the code produced in each hour. Since there is considerable variation among developers, the SEI has established the general guideline that developers personally spend at least half as much time reviewing design or code quality as they spent producing that design or code.

Further, from data on many programs, we have found that, when there are fewer than 10 defects found while compiling each 1,000 lines of code and fewer than 5.0 defects found while unit testing each 1,000 lines of code, that program is likely to have few if any remaining defects. Combining these criteria with an additional requirement that developers spend at least as much time designing a program as they spent coding it, gives the following five software process quality criteria.

The quality profile has five terms that are derived from the above data. The equations for these terms are as follows.

To derive the five profile terms, consider formula No. 3 for code reviews. In one hour of coding, a typical software developer will inject 4.6 defects. Since this developer can find and fix defects at the rate of 6.0 per hour, he or she needs to spend 4.6/6.0 = 0.7667 of an hour, or about 46 minutes, reviewing the code produced in one hour. Since there is wide variation in these injection and removal rates, and since the number 0.7667 is hard to remember, the SEI uses 0.5 as the factor. Based on experience to date, this has proven to be suitable. Since these parameter values are sensitive to application type and operational criticality, we suggest that organizations periodically analyze their own data and adjust these values accordingly.

The formula for the code review profile term compares the ratio of the actual time the developer spent reviewing code with the actual time spent in coding. If that ratio equals or is greater than 0.5, then the criteria are met. The factor of 2 in the equation is used to double both sides of this equation so it compares twice the ratio of review to coding time with 1.0. Also, to get a useful quality figure of merit, we need a measure that varies between 0 and 1.0, where 0 is very poor and 1.0 is good. Therefore, the equation’s value should equal 1.0 whenever 2 times the code review time is equal to or greater than the coding time and be progressively less with lower reviewing times. This is the reason for the Minimum function in each equation, where Minimum (A:B) is the minimum of A and B. A little calculation will show that this is precisely the way equation No. 3 works. Equations No. 1 and No. 2 work in exactly the same way (except design time should equal or exceed coding time in equation No. 1).

To produce equations No. 4 and No. 5, the SEI used data it gathered while training software developers for TSP teams. It found that when more than about 10 defects/thousand lines of code (KLOC) were found in compiling, programs typically had poor code quality in testing, and when more than about five defects/KLOC were found in initial (or unit) testing, program quality was often poor in integration and system testing. Therefore, we seek an equation that will produce a value of 1.0 when fewer than 10 defects/KLOC are found in compiling, and we want this value to progressively decrease as more defects are found. A little calculation will show that this is precisely what equation No. 4 does. Equation No. 5 works the same way for the value of five defects/KLOC in unit testing.

For large products, it is customary to combine the data for all components into a composite system quality profile. Since the data for a few poor quality components could then be masked by the data for a large number of high quality components, it is important to have a way to identify any potentially defective system components. The process quality index (PQI) was devised for this purpose. It is calculated by multiplying together the five components of the quality profile to give a value between 0.0 and 1.0. Then the components with PQI values below some threshold can be quickly identified and reviewed to see which ones should be reinspected, reworked, or replaced.

Experience to date shows that, with PQI values above about 0.4, components typically have no defects found after development. Since the quality problems for large systems are normally caused by a relatively small number of defective components, the PQI measure permits acquisition groups to rapidly pinpoint the likely troublesome components and to require they be repaired or replaced prior to delivery. Once organizations have sufficient data, they should reexamine these criteria values and make appropriate adjustments.

Since few software development groups currently gather the data required to use modern software quality management practices, we must consider the sixth principle of software quality.

Quality products are only produced by motivated professionals who take pride in the quality of their work.

Because the measures required for quality management must be gathered by the software professionals themselves, these professionals must be motivated to gather and use the needed data. If they are not, they will either not gather the data or the data will not be very accurate. Experience shows that developers will only be motivated to gather and use data on their work if they use the data themselves, and if they believe that the practices required to consistently produce quality software products will help them do better work. Most developers who have used the TSP believe these things, but without proper training very few developers will.

While these measures and quality practices are not difficult, they represent a significant behavioral change for most practicing software professionals and their management. There are, however, a growing number of professionals who do practice these methods, and the SEI now has a program to transition these methods into general practice. The methodology involved is the PSP, and to consistently use the PSP methods on a project, development groups must use the TSP. There is now considerable experience with these methods, and it shows that with proper use TSP teams typically produce defect-free or nearly defect-free products at or very close to their committed costs and schedules.

Sound quality management is the key to software quality; without appropriate quality measures, it is impossible to manage the quality of a process or to predict the quality of the products that process produces. The developers must gather and analyze these data; they will not do this unless they know how to gather and how to use these data. This is why the sixth quality principle is critically important. Merely ordering the organization to provide the desired data will guarantee getting lots of numbers that are unlikely to be useful unless quality principle No. 6 is met. This requires motivating development management, and having development management train and motivate the developers in the needed quality measurement and management practices.

Once the developers regularly gather, analyze, and use these data, there only remains the question of how acquisition executives can get and use the data. This is both a contracting and a customer-supplier issue. Experience to date shows that when the developers use the TSP, you should have no trouble getting the required data.

The specific data needed to measure and manage software quality are the following:

Planned and actual values are needed for these items, and these data should be for the smallest modules and components of the system. To establish and maintain the required management and developer motivation, these quality measurement and management requirements must be addressed both contractually and through management negotiation.

Poor quality performance damages a software development organization’s cost and schedule performance and produces troublesome products. For acquirers to have a reasonable chance of changing the cost and schedule performance of their software vendors, they must demand effective quality management. The six principles of software quality reviewed in this article should help them do this.

By following these six principles and requiring suppliers to do so as well, you can consistently obtain quality softwareintensive products at or very near to their committed costs and schedules.

With up to 80% of information technology budgets of most organizations directly linked to service management processes, a new ISO standard that benchmarks this activity is expected to result in cost savings for users, whether large or small enterprises, as well as, increased productivity and improved customer service.

ISO 20000:2005 will enable organizations to benchmark their capability in delivering managed services, measuring service levels, and assessing performance.

Today, IT service providers are under sustained pressure to deliver high quality service at minimum cost. Concerns have been raised that IT services, whether provided by an in-house IT department or an external organization, are not aligned with the needs of the business and its customers. ISO 20000 will reduce operational exposure to risk, meet contractual and tendering requirements, demonstrate service quality, and deliver best value.

The implementation of ISO 20000 will ensure proactive working practices able to deliver high levels of customer service to meet their business needs.

"Organizations will reap major business and financial benefits by ISO 20000 adoption," explains François Coallier, Chair of the ISO group that approved the standard. "These service management processes deliver the best possible service to meet a customer’s business needs within agreed resource levels, i.e., service that is professional, cost effective, and with risks that are understood and fully managed."

ISO 20000:2005, which is issued in two parts under the general title, Information Technology - Service Management, will enable service providers to understand how to enhance the quality of service delivered to their customers, both internal and external.

7. Class Schedule: December, 2005 - February, 2006

To enroll in these public classes, you can click on the course title, go to Class Schedule at our web site, or call us at 800-404-7585.

Classes taught by Larry Whittington are shown in yellow.

Quality Management System Courses
ISO 9001:2000 Lead Auditor (RABQSA Certified) - BSI Management Systems
Initial course version developed by Larry Whittington

January	February	March
09-13 San Jose, CA	06-10 San Diego, CA	06-10 Las Vegas, NV
23-27 Reston, VA	13-17 Atlanta, GA	13-17 Reston, VA
30-03 Houston, TX	13-17 Orlando, FL	20-24 Chicago, IL
- -	27-03 St. Louis, MO	27-31 Seattle, WA

ISO 9001:2000 Internal Auditor (RABQSA Certified) - BSI Management Systems
Initial course version developed by an Associate at Whittington & Associates

January February March

18-20 San Jose, CA 22-24 San Antonio, TX 21-23 Atlanta, GA

24-26 Atlanta, GA - - 21-23 Pittsburgh, PA

Implementing ISO 9001:2000
Course developed by Larry Whittington

January February March

10-11 Chicago, IL 09-10 Atlanta, GA 07-08 Reston, VA

Understanding ISO 9001:2000

January February March

09 Chicago, IL - -
06 Reston, VA

Understanding ISO 9001:2000 Requirements (Atlanta Only - $345)
Course developed by Larry Whittington

February May

06 Atlanta, GA 01 Atlanta, GA

Quality System Documentation (ISO 9001:2000)
Course developed by Larry Whittington

January February March

- - 07-08 Atlanta, GA 09-10 Reston, VA

Information Security Management System Courses
ISO 17799 / ISO 27001 - Understanding an Information Security Management System

January February May

- - 07-08 Atlanta, GA 01-02 Atlanta, GA

- - 22-23 Newark, NJ - -

ISO 27001 - Information Security Management System Lead Auditor

February March

13-17 Atlanta, GA
06-10 Seattle, WA

ISO 17799 / ISO 27001 - Information Security Management System Implementation

February April June

07-09 Reston, VA
04-06 Atlanta, GA 06-08 Atlanta, GA

Environmental Management System Courses
Understanding ISO 14001:2004

January
March May

30 Atlanta, GA
27 San Jose, CA 10 Atlanta, GA

Implementing an Environmental Management System

January March April

17-18 Reston, VA 28-29 San Jose, CA 11-12 Atlanta, GA

31-01 Atlanta, GA - - - -

ISO 14001:2004 Internal Auditor

January February March

19-20 Reston, VA 20-21 Atlanta, GA 30-31 San Jose, CA

ISO 14001:2004 Lead Auditor

January February March

23-27 San Jose, CA 13-17 Houston, TX 20-24 Reston, VA

- - - - 27-31 Atlanta, GA

Aerospace (AS9100) Courses
AS9100:2004 Internal Auditor

February August

28-02 San Jose, CA
15-17 Dallas, TX

AS9100:2004 Lead Auditor

January March April

23-27 Orlando, FL
20-24 Atlanta, GA
24-28 Chicago, IL

On-site Courses
The above public courses can be offered on-site at your facility. In addition, we offer these on-site courses:

ISO 9001:2000 Auditor Update - The Process Approach (1 Day) - Course developed by Larry Whittington
Understanding ISO/TS 16949:2002 Requirements (1 Day) - Course developed by Larry Whittington
Internal Quality Auditing (2 Days) - Course developed by Larry Whittington (based on ISO 19011)
AS9100B: Requirements Beyond ISO 9001:2000 (1 Day) - Course developed by Larry Whittington

To arrange an economical on-site class, please call us at 800-404-7585.

-top-

Copyright © 2000 - 2007 Whittington & Associates, LLC. All Rights Reserved. 242 Highlands Drive, Woodstock, GA 30188 770-517-7944 or fax 770-517-7945	Site by Frogtown Media Web Design
Whittington & Associates provides training, consulting and auditing services for quality systems based on ISO 9001, ISO/TS16949, TL9000, AS9100, ISO 13485, as well as, ISO 27001, ISO 20000, ISO 22000, and ISO 14001.