Software bug

A software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways. Most bugs arise from mistakes and errors made by people in either a program's source code or its design, and a few are caused by compilers producing incorrect code. A program that contains a large number of bugs, and/or bugs that seriously interfere with its functionality, is said to be buggy. Reports detailing bugs in a program are commonly known as bug reports, fault reports, problem reports, trouble reports, change requests, and so forth.

  

Prevention

Bugs are a consequence of the nature of human factors in the programming task. They arise from oversights or mutual misunderstandings made by a software team during specification, design, coding, data entry and documentation. For example: In creating a relatively simple program to sort a list of words into alphabetical order, one's design might fail to consider what should happen when a word contains a hyphen. Perhaps, when converting the abstract design into the chosen programming language, one might inadvertently create an off-by-one error and fail to sort the last word in the list. Finally, when typing the resulting program into the computer, one might accidentally type a '<' where a '>' was intended, perhaps resulting in the words being sorted into reverse alphabetical order. More complex bugs can arise from unintended interactions between different parts of a computer program. This frequently occurs because computer programs can be complex — millions of lines long in some cases — often having been programmed by many people over a great length of time, so that programmers are unable to mentally track every possible way in which parts can interact. Another category of bug called a race condition comes about either when a process is running in more than one thread or two or more processes run simultaneously, and the exact order of execution of the critical sequences of code have not been properly synchronized.
The software industry has put much effort into finding methods for preventing programmers from inadvertently introducing bugs while writing software.^[11][12] These include:

Programming style

While typos in the program code most likely are caught by the compiler, a bug usually appears when the programmer makes a logic error. Various innovations in programming style and defensive programming are designed to make these bugs less likely, or easier to spot.

Programming techniques

Bugs often create inconsistencies in the internal data of a running program. Programs can be written to check the consistency of their own internal data while running. If an inconsistency is encountered, the program can immediately halt, so that the bug can be located and fixed. Alternatively, the program can simply inform the user, attempt to correct the inconsistency, and continue running.

Development methodologies

There are several schemes for managing programmer activity, so that fewer bugs are produced. Many of these fall under the discipline of software engineering (which addresses software design issues as well). For example, formal program specifications are used to state the exact behavior of programs, so that design bugs can be eliminated. Unfortunately, formal specifications are impractical or impossible for anything but the shortest programs, because of problems of combinatorial explosion and indeterminacy.

Programming language support

Programming languages often include features which help programmers prevent bugs, such as static type systems, restricted name spaces and modular programming, among others. For example, when a programmer writes (pseudocode) LET REAL_VALUE PI = "THREE AND A BIT", although this may be syntactically correct, the code fails a type check. Depending on the language and implementation, this may be caught by the compiler or at runtime. In addition, many recently-invented languages have deliberately excluded features which can easily lead to bugs, at the expense of making code slower than it need be: the general principle being that, because of Moore's law, computers get faster and software engineers get slower; it is almost always better to write simpler, slower code than "clever", inscrutable code, especially considering that maintenance cost is considerable. For example, the Java programming language does not support pointer arithmetic; implementations of some languages such as Pascal and scripting languages often have runtime bounds checking of arrays, at least in a debugging build.

Code analysis

Tools for code analysis help developers by inspecting the program text beyond the compiler's capabilities to spot potential problems. Although in general the problem of finding all programming errors given a specification is not solvable (see halting problem), these tools exploit the fact that human programmers tend to make the same kinds of mistakes when writing software.

Instrumentation

Tools to monitor the performance of the software as it is running, either specifically to find problems such as bottlenecks or to give assurance as to correct working, may be embedded in the code explicitly (perhaps as simple as a statement saying PRINT "I AM HERE"), or provided as tools. It is often a surprise to find where most of the time is taken by a piece of code, and this removal of assumptions might cause the code to be rewritten

Bug management

It is common practice for software to be released with known bugs that are considered non-critical, that is, that do not affect most users' main experience with the product. While software products may, by definition, contain any number of unknown bugs, measurements during testing can provide an estimate of the number of likely bugs remaining; this becomes more reliable the longer a product is tested and developed ("if we had 200 bugs last week, we should have 100 this week"). Most big software projects maintain two lists of "known bugs"— those known to the software team, and those to be told to users. This is not dissimulation, but users are not concerned with the internal workings of the product. The second list informs users about bugs that are not fixed in the current release, or not fixed at all, and a workaround may be offered.
There are various reasons for not fixing bugs:

• The developers often don't have time or it is not economical to fix all non-severe bugs.
• The bug could be fixed in a new version or patch that is not yet released.
• The changes to the code required to fix the bug could be large, expensive, or delay finishing the project.
• Even seemingly simple fixes bring the chance of introducing new unknown bugs into the system. At the end of a test/fix cycle some managers may only allow the most critical bugs to be fixed.
• Users may be relying on the undocumented, buggy behavior, especially if scripts or macros rely on a behavior; it may introduce a breaking change.
• It's "not a bug". A misunderstanding has arisen between expected and provided behavior

Given the above, it is often considered impossible to write completely bug-free software of any real complexity. So bugs are categorized by severity, and low-severity non-critical bugs are tolerated, as they do not affect the proper operation of the system for most users. NASA's SATC managed to reduce the number of errors to fewer than 0.1 per 1000 lines of code (SLOC)^{[citation needed]} but this was not felt to be feasible for any real world projects.
The severity of a bug is not the same as its importance for fixing, and the two should be measured and managed separately. On a Microsoft Windows system a blue screen of death is rather severe, but if it only occurs in extreme circumstances, especially if they are well diagnosed and avoidable, it may be less important to fix than an icon not representing its function well, which though purely aesthetic may confuse thousands of users every single day. This balance, of course, depends on many factors; expert users have different expectations from novices, a niche market is different from a general consumer market, and so on.
A school of thought popularized by Eric S. Raymond as Linus's Law says that popular open-source software has more chance of having few or no bugs than other software, because "given enough eyeballs, all bugs are shallow". This assertion has been disputed, however: computer security specialist Elias Levy wrote that "it is easy to hide vulnerabilities in complex, little understood and undocumented source code," because, "even if people are reviewing the code, that doesn't mean they're qualified to do so."
Like any other part of engineering management, bug management must be conducted carefully and intelligently because "what gets measured gets done"and managing purely by bug counts can have unintended consequences. If, for example, developers are rewarded by the number of bugs they fix, they will naturally fix the easiest bugs first— leaving the hardest, and probably most risky or critical, to the last possible moment ("I only have one bug on my list but it says "Make sun rise in West"). If the management ethos is to reward the number of bugs fixed, then some developers may quickly write sloppy code knowing they can fix the bugs later and be rewarded for it, whereas careful, perhaps "slower" developers do not get rewarded for the bugs that were never there.

Tools, Techniques, and Metrics

Metrics

Metrics in the area of software fault tolerance, (or software faults,) are generally pretty poor. The data sets that have been analyzed in the past are surely not indicative of today's large and complex software systems. The analysis by [DeVale99] of various POSIX systems has the largest applicable data set found in the literature. Some of the advantages of the [DeVale99] research are the fact that the systems are commercially developed, the systems adhere to the same specification, and the systems are large enough that testing them shows an array of problems. Still, the [DeVale99] research is not without its problems; operating systems may be a more unique case than application software; operating systems may share more heritage from projects like Berkeley's Unix or the Open Software Foundation's research projects. The issue with gathering good metrics data is the cost involved in developing multiple versions of complex robust software. Operating systems offer the advantage of many organizations building their own versions of this complex software.
The results of the [DeVale99] and [Knight86] research show that software errors may be correlated in N-version software systems. The results of these studies imply that the failure mode for programmers is not unique, destroying a major tenant of the N-version software fault tolerance technique. It is important to remember however, the the [Knight86] research, like most other publications in this area, are case studies, and may not be an in-depth study across enough variety of software systems to be a conclusive result.

Tools

Software fault tolerance has an extreme lack of tools in order to aide the programmer in making reliable system. This lack of adequate tools is not very different from the general lack of functional tools in software development that go beyond an editor and a compiler. The ability to semi-automate the adding of fault tolerance into software would be a significant enhancement to the market today. One of the biggest issues facing the development of software fault tolerant systems is the cost currently required to develop these systems. Enhanced and functional tools, that can easily accomplish their task, would surely be welcomed in the market place.
 
 

Techniques

Recovery Blocks

The recovery block method is a simple method developed by Randell from what was observed as somewhat current practice at the time. [Lyu95] The recovery block operates with an adjudicator which confirms the results of various implementations of the same algorithm. In a system with recovery blocks, the system view is broken down into fault recoverable blocks. The entire system is constructed of these fault tolerant blocks. Each block contains at least a primary, secondary, and exceptional case code along with an adjudicator. (It is important to note that this definition can be recursive, and that any component may be composed of another fault tolerant block composed of primary, secondary, exceptional case, and adjudicator components.) The adjudicator is the component which determines the correctness of the various blocks to try. The adjudicator should be kept somewhat simple in order to maintain execution speed and aide in correctness. Upon first entering a unit, the adjudicator first executes the primary alternate. (There may be N alternates in a unit which the adjudicator may try.) If the adjudicator determines that the primary block failed, it then tries to roll back the state of the system and tries the secondary alternate. If the adjudicator does not accept the results of any of the alternates, it then invokes the exception handler, which then indicates the fact that the software could not perform the requested operation.
Recovery block operation still has the same dependency which most software fault tolerance systems have: design diversity. The recovery block method increases the pressure on the specification to be specific enough to create different multiple alternatives that are functionally the same. This issue is further discussed in the context of the N-version method.
The recovery block system is also complicated by the fact that it requires the ability to roll back the state of the system from trying an alternate. This may be accomplished in a variety of ways, including hardware support for these operations. This try and rollback ability has the effect of making the software to appear extremely transactional, in which only after a transaction is accepted is it committed to the system. There are advantages to a system built with a transactional nature, the largest of which is the difficult nature of getting such a system into an incorrect or unstable state. This property, in combination with checkpointing and recovery may aide in constructing a distributed hardware fault tolerant system

capability maturity model

  Capability Maturity Model Integration (CMMI) is a process improvement approach that provides organizations with the essential elements of effective processes that ultimately improve their performance. CMMI can be used to guide process improvement across a project, a division, or an entire organization

CMMI in software engineering and organizational development is a trademarked process improvement approach that provides organizations with the essential elements for effective process improvement.
CMMI according to the Software Engineering Institute (SEI, 2008), helps "integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes."^[2]

Overview

CMMI currently addresses three areas of interest:

1. Product and service development — CMMI for Development (CMMI-DEV),
2. Service establishment, management, and delivery — CMMI for Services (CMMI-SVC), and
3. Product and service acquisition — CMMI for Acquisition (CMMI-ACQ).

CMMI was developed by a group of experts from industry, government, and the Software Engineering Institute (SEI) at Carnegie Mellon University. CMMI models provide guidance for developing or improving processes that meet the business goals of an organization. A CMMI model may also be used as a framework for appraising the process maturity of the organization.^[1]

CMMI originated in software engineering but has been highly generalised over the years to embrace other areas of interest, such as the development of hardware products, the delivery of all kinds of services, and the acquisition of products and services. The word "software" does not appear in definitions of CMMI. This generalization of improvement concepts makes CMMI extremely abstract. It is not as specific to software engineering as its predecessor, the Software CMM (CMM, see below)...

 History

CMMI was developed by the CMMI project, which aimed to improve the usability of maturity models by integrating many different models into one framework. The project consisted of members of industry, government and the Carnegie Mellon Software Engineering Institute (SEI). The main sponsors included the Office of the Secretary of Defense (OSD) and the National Defense Industrial Association.

CMMI is the successor of the capability maturity model (CMM) or software CMM. The CMM was developed from 1987 until 1997. In 2002, CMMI Version 1.1 was released. Version 1.2 followed in August 2006.

 CMMI topics

 CMMI representation

CMMI exists in two representations: continuous and staged.^[1] The continuous representation is designed to allow the user to focus on the specific processes that are considered important for the organization's immediate business objectives, or those to which the organization assigns a high degree of risk. The staged representation is designed to provide a standard sequence of improvements, and can serve as a basis for comparing the maturity of different projects and organizations. The staged representation also provides for an easy migration from the SW-CMM to CMMI.^[1]

 CMMI model framework

For more details on this topic, see Process area (CMMI).

Depending on the CMMI constellation (acquisition, services, development) used, the process areas it contains will vary. Key process areas are the areas that will be covered by the organization's processes. The table below lists the process areas that are present in all CMMI constellations. This collection of sixteen process areas is called the CMMI Model Framework, or CMF.

Capability Maturity Model Integration (CMMI) Model Framework (CMF)
Abbreviation	Name	Area	Maturity Level
REQM	Requirements Management	Engineering	2
PMC	Project Monitoring and Control	Project Management	2
PP	Project Planning	Project Management	2
CM	Configuration Management	Support	2
MA	Measurement and Analysis	Support	2
PPQA	Process and Product Quality Assurance	Support	2
OPD	Organizational Process Definition	Process Management	3
CAR	Causal Analysis	Support	5

 CMMI models

CMMI best practices are published in documents called models, each of which addresses a different area of interest. The current release of CMMI, version 1.2, provides models for three areas of interest: development, acquisition, and services.

• CMMI for Development (CMMI-DEV), v1.2 was released in August 2006. It addresses product and service development processes.
• CMMI for Acquisition (CMMI-ACQ), v1.2 was released in November 2007. It addresses supply chain management, acquisition, and outsourcing processes in government and industry.
• CMMI for Services (CMMI-SVC), v1.2 was released in February 2009. It addresses guidance for delivering services within an organization and to external customers.
• CMMI Product Suite (includes Development, Acquisition, and Services), v1.3 is expected to be released in 2010. CMMI Version 1.3—Plans for the Next Version

Regardless of which model an organization chooses, CMMI best practices should be adapted by an organization according to its business objectives.

ISO standards

ISO 9000 is a family of standards for quality management systems. ISO 9000 is maintained by ISO, the International Organization for Standardization and is administered by accreditation and certification bodies. The rules are updated, as the requirements motivate changes over time. Some of the requirements in ISO 9001:2008 (which is one of the standards in the ISO 9000 family) include

• a set of procedures that cover all key processes in the business;
• monitoring processes to ensure they are effective;
• keeping adequate records;
• checking output for defects, with appropriate and corrective action where necessary;
• regularly reviewing individual processes and the quality system itself for effectiveness; and
• facilitating continual improvement

A company or organization that has been independently audited and certified to be in conformance with ISO 9001 may publicly state that it is "ISO 9001 certified" or "ISO 9001 registered". Certification to an ISO 9001 standard does not guarantee any quality of end products and services; rather, it certifies that formalized business processes are being applied.
Marketing departments take advantage of public confusion and ignorance about ISO 9000. Goods and services outstanding proclaim their ISO 9000 STATUS. Most consumers suppose that ISO 9000 is the same as ISO 9001.
Although the standards originated in manufacturing, they are now employed across several types of organizations. A "product", in ISO vocabulary, can mean a physical object, services, or software.
Quality is a "culture" - ISO 9001 "Quality" is an important Accreditation to achieve, it is also essential for maximum benefit that information is shared so that the culture of the business ensures that the Quality culture is embedded

Summary of ISO 9001:2008 in informal language

• The quality policy is a formal statement from management, closely linked to the business and marketing plan and to customer needs. The quality policy is understood and followed at all levels and by all employees. Each employee needs measurable objectives to work towards.
• Decisions about the quality system are made based on recorded data and the system is regularly audited and evaluated for conformance and effectiveness.
• Records should show how and where raw materials and products were processed, to allow products and problems to be traced to the source
• • You need to determine customer requirements and create systems for communicating with customers about product information, inquiries, contracts, orders, feedback and complaints.
• When developing new products, you need to plan the stages of development, with appropriate testing at each stage. You need to test and document whether the product meets design requirements, regulatory requirements and user needs.
• You need to regularly review performance through internal audits and meetings. Determine whether the quality system is working and what improvements can be made. Deal with past problems and potential problems. Keep records of these activities and the resulting decisions, and monitor their effectiveness (note: you need a documented procedure for internal audits).
• You need documented procedures for dealing with actual and potential nonconformances (problems involving suppliers or customers, or internal problems). Make sure no one uses bad product, determine what to do with bad product, deal with the root cause of the problem seeking and keep records to use as a tool to improve the system.

1987 version

ISO 9000:1987 had the same structure as the UK Standard BS 5750, with three 'models' for quality management systems, the selection of which was based on the scope of activities of the organization:

• ISO 9001:1987 Model for quality assurance in design, development, production, installation, and servicing was for companies and organizations whose activities included the creation of new products.
• ISO 9002:1987 Model for quality assurance in production, installation, and servicing had basically the same material as ISO 9001 but without covering the creation of new products.
• ISO 9003:1987 Model for quality assurance in final inspection and test covered only the final inspection of finished product, with no concern for how the product was produced.

ISO 9000:1987 was also influenced by existing U.S. and other Defense Standards ("MIL SPECS"), and so was well-suited to manufacturing. The emphasis tended to be placed on conformance with procedures rather than the overall process of management—which was likely the actual intent.^{[citation needed]}

1994 version

ISO 9000:1994 emphasized quality assurance via preventive actions, instead of just checking final product, and continued to require evidence of compliance with documented procedures. As with the first edition, the down-side was that companies tended to implement its requirements by creating shelf-loads of procedure manuals, and becoming burdened with an ISO bureaucracy. In some companies, adapting and improving processes could actually be impeded by the quality system.^{[citation needed]}

2000 version

ISO 9001:2000 combines the three standards 9001, 9002, and 9003 into one, called 9001. Design and development procedures are required only if a company does in fact engage in the creation of new products. The 2000 version sought to make a radical change in thinking by actually placing the concept of process management front and center ("Process management" was the monitoring and optimizing of a company's tasks and activities, instead of just inspecting the final product). The 2000 version also demands involvement by upper executives, in order to integrate quality into the business system and avoid delegation of quality functions to junior administrators. Another goal is to improve effectiveness via process performance metrics — numerical measurement of the effectiveness of tasks and activities. Expectations of continual process improvement and tracking customer satisfaction were made explicit.
The ISO 9000 standard is continually being revised by standing technical committees and advisory groups, who receive feedback from those professionals who are implementing the standard.[1]
ISO 9001:2008 only introduces clarifications to the existing requirements of ISO 9001:2000 and some changes intended to improve consistency with ISO 14001:2004. There are no new requirements. Explanation of changes in ISO 9001:2008. A quality management system being upgraded just needs to be checked to see if it is following the clarifications introduced in the amended version.Practical Guide to Implementing ISO 9001:2008

 Certification

ISO does not itself certify organizations. Many countries have formed accreditation bodies to authorize certification bodies, which audit organizations applying for ISO 9001 compliance certification. Although commonly referred to as ISO 9000:2000 certification, the actual standard to which an organization's quality management can be certified is ISO 9001:2008. Both the accreditation bodies and the certification bodies charge fees for their services. The various accreditation bodies have mutual agreements with each other to ensure that certificates issued by one of the Accredited Certification Bodies (CB) are accepted worldwide.
The applying organization is assessed based on an extensive sample of its sites, functions, products, services and processes; a list of problems ("action requests" or "non-compliances") is made known to the management. If there are no major problems on this list, or after it receives a satisfactory improvement plan from the management showing how any problems will be resolved, the certification body will issue an ISO 9001 certificate for each geographical site it has visited.
An ISO certificate is not a once-and-for-all award, but must be renewed at regular intervals recommended by the certification body, usually around three years. In contrast to the Capability Maturity Model there are no grades of competence within ISO 9001.

Auditing

Two types of auditing are required to become registered to the standard: auditing by an external certification body (external audit) and audits by internal staff trained for this process (internal audits). The aim is a continual process of review and assessment, to verify that the system is working as it's supposed to, find out where it can improve and to correct or prevent problems identified. It is considered healthier for internal auditors to audit outside their usual management line, so as to bring a degree of independence to their judgments.
Under the 1994 standard, the auditing process could be adequately addressed by performing "compliance auditing":

• Tell me what you do (describe the business process)
• Show me where it says that (reference the procedure manuals)
• Prove that this is what happened (exhibit evidence in documented records)

The 2000 standard uses a different approach. Auditors are expected to go beyond mere auditing for rote "compliance" by focusing on risk, status and importance. This means they are expected to make more judgments on what is effective, rather than merely adhering to what is formally prescribed. The difference from the previous standard can be explained thus:

Under the 1994 version, the question was broadly "Are you doing what the manual says you should be doing?", whereas under the 2000 version, the question is more "Will this process help you achieve your stated objectives? Is it a good process or is there a way to do it better?"^{[citation needed]}

The ISO 19011 standard for auditing applies to ISO 9001 besides other management systems like EMS ( ISO 14001), FSMS (ISO 22000) etc.

 Industry-specific interpretations

The ISO 9001 standard is generalized and abstract. Its parts must be carefully interpreted, to make sense within a particular organization. Developing software is not like making cheese or offering counseling services; yet the ISO 9001 guidelines, because they are business management guidelines, can be applied to each of these. Diverse organizations—police departments (US), professional soccer teams (Mexico) and city councils (UK)—have successfully implemented ISO 9001:2000 systems.
Over time, various industry sectors have wanted to standardize their interpretations of the guidelines within their own marketplace. This is partly to ensure that their versions of ISO 9000 have their specific requirements, but also to try and ensure that more appropriately trained and experienced auditors are sent to assess them.

• The TickIT guidelines are an interpretation of ISO 9000 produced by the UK Board of Trade to suit the processes of the information technology industry, especially software development.
• AS9000 is the Aerospace Basic Quality System Standard, an interpretation developed by major aerospace manufacturers. Those major manufacturers include AlliedSignal, Allison Engine, Boeing, General Electric Aircraft Engines, Lockheed-Martin, McDonnell Douglas, Northrop Grumman, Pratt & Whitney, Rockwell-Collins, Sikorsky Aircraft, and Sundstrand. The current version is AS9100.
• PS 9000 is an application of the standard for Pharmaceutical Packaging Materials. The Pharmaceutical Quality Group (PQG) of the Institute of Quality Assurance (IQA) has developed PS 9000:2001. It aims to provide a widely accepted baseline GMP framework of best practice within the pharmaceutical packaging supply industry. It applies ISO 9001: 2000 to pharmaceutical printed and contact packaging materials.
• QS 9000 is an interpretation agreed upon by major automotive manufacturers (GM, Ford, Chrysler). It includes techniques such as FMEA and APQP. QS 9000 is now replaced by ISO/TS 16949.
• ISO/TS 16949:2002 is an interpretation agreed upon by major automotive manufacturers (American and European manufacturers); the latest version is based on ISO 9001:2000. The emphasis on a process approach is stronger than in ISO 9001:2000. ISO/TS 16949:2002 contains the full text of ISO 9001:2000 and automotive industry-specific requirements.
• TL 9000 is the Telecom Quality Management and Measurement System Standard, an interpretation developed by the telecom consortium, QuEST Forum. The current version is 4.0 and unlike ISO 9001 or the above sector standards, TL 9000 includes standardized product measurements that can be benchmarked. In 1998 QuEST Forum developed the TL 9000 Quality Management System to meet the supply chain quality requirements of the worldwide telecommunications industry.
• ISO 13485:2003 is the medical industry's equivalent of ISO 9001:2000. Whereas the standards it replaces were interpretations of how to apply ISO 9001 and ISO 9002 to medical devices, ISO 13485:2003 is a stand-alone standard. Compliance with ISO 13485 does not necessarily mean compliance with ISO 9001:2000.
• ISO/TS 29001 is quality management system requirements for the design, development, production, installation and service of products for the petroleum, petrochemical and natural gas industries. It is equivalent to API Spec Q1 without the Monogram annex.

 Debate on the effectiveness of ISO 9000

The debate on the effectiveness of ISO 9000 commonly centers on the following questions:

1. Are the quality principles in ISO 9001:2000 of value? (Note that the version date is important: in the 2000 version ISO attempted to address many concerns and criticisms of ISO 9000:1994).
2. Does it help to implement an ISO 9001:2000 compliant quality management system?
3. Does it help to obtain ISO 9001:2000 certification

ADAVNTAGES

It is widely acknowledged that proper quality management improves business, often having a positive effect on investment, market share, sales growth, sales margins, competitive advantage, and avoidance of litigation.The quality principles in ISO 9000:2000 are also sound, according to Wade, and Barnes, who says "ISO 9000 guidelines provide a comprehensive model for quality management systems that can make any company competitive." Barnes also cites a survey by Lloyd's Register Quality Assurance which indicated that ISO 9000 increased net profit, and another by Deloitte-Touche which reported that the costs of registration were recovered in three years. According to the Providence Business News , implementing ISO often gives the following advantages:

1. Create a more efficient, effective operation
2. Increase customer satisfaction and retention
3. Reduce audits
4. Enhance marketing
5. Improve employee motivation, awareness, and morale
6. Promote international trade
7. Increases profit
8. Reduce waste and increases productivity

However, a broad statistical study of 800 Spanish companies ^[5] found that ISO 9000 registration in itself creates little improvement because companies interested in it have usually already made some type of commitment to quality management and were performing just as well before registration.

 Problems

A common criticism of ISO 9001 is the amount of money, time and paperwork required for registration.According to Barnes, "Opponents claim that it is only for documentation. Proponents believe that if a company has documented its quality systems, then most of the paperwork has already been completed.
ISO 9001 is not in any way an indication that products produced using its certified systems are any good. A company can intend to produce a poor quality product and providing it does so consistantly and with the proper documentation can put an ISO 9001 stamp on it. According to Seddon, ISO 9001 promotes specification, control, and procedures rather than understanding and improvement.  Wade argues that ISO 9000 is effective as a guideline, but that promoting it as a standard "helps to mislead companies into thinking that certification means better quality, ... [undermining] the need for an organization to set its own quality standards."  Paraphrased, Wade's argument is that reliance on the specifications of ISO 9001 does not guarantee a successful quality system.
The standard is seen as especially prone to failure when a company is interested in certification before quality.^[ Certifications are in fact often based on customer contractual requirements rather than a desire to actually improve quality."If you just want the certificate on the wall, chances are, you will create a paper system that doesn't have much to do with the way you actually run your business," said ISO's Roger Frost.Certification by an independent auditor is often seen as the problem area, and according to Barnes, "has become a vehicle to increase consulting services." In fact, ISO itself advises that ISO 9001 can be implemented without certification, simply for the quality benefits that can be achieved.
Another problem reported is the competition among the numerous certifying bodies, leading to a softer approach to the defects noticed in the operation of the Quality System of a firm.
Abrahamson argued that fashionable management discourse such as Quality Circles tends to follow a lifecycle in the form of a bell curve, possibly indicating a management fad.

software engineering

Difference between iso and cmm

ISO 9001 and CMM have similar goals but different methods. Three experts describe what these quality standards mean to the software industry.

Your company's adherence to industry quality standards, such as the ISO 9001 and Capability Maturity Model (CMM), could determine if you land that new lucrative contract. What should these standards mean to your organisation? Find out what three experts think, and then add your two cents.

A quick overview of ISO 9001 and CMM
ISO 9001 is the creation of the International Organisation for Standardisation (ISO), a Swiss-based federation of national standards bodies. Carnegie Mellon University's Software Engineering Institute (SEI) created CMM.

ISO 9001 is part of the ISO 9000 family of standards. The new ISO 9001:2000 designation comprises the ISO 9001, ISO 9002, and ISO 9003 standards. ISO 9001 targets the manufacturing process, although it also includes manufacturing services and software development.

CMM offers a model for judging the software processes of an organisation and for identifying key practices required to increase the maturity of these processes. It establishes a successful means for modeling, defining, and measuring the maturity of the processes used by software professionals.

ISO started out as a European standard. If your company didn't have ISO 9000 certification, it wasn't permitted to bid on a proposal. In particular, many European telecom companies require ISO 9000. ISO 9000 shows customers and potential customers that you have a basic quality system in place to produce a consistent product.

-Once you get the ISO stamp, you can put it on your company propaganda," said Ron Weidemann, director of quality for Teradata, a database software producer in San Diego.

ISO 9000 can be likened to the Good Housekeeping Seal of Approval. The United States, however, is not as stringent about ISO certification. Weidemann noted that, while some American companies require ISO certification, many others do not. Weidemann found that CMM was better for his company. -We needed a basic system, and CMM met our needs," he said. "We adopted it, but we also use ISO in order to sell in Europe."

What's the difference between ISO 9001 and CMM?
Understanding the difference between ISO and CMM means recognising a cultural understanding of quality. -Microsoft and many other software companies govern quality with the 80-20 rule," said David Smith, vice president of Technology Futures, a technology forecasting company in Austin, TX. -The rationale is, 'it's a real product if 80 percent of the problem can be addressed and the remaining 20 percent is part of the business model.' But the reality is the software industry's business model is not a business model of total quality. And that is part of the challenge when you compare a CMM model against an ISO model."

The problem, as Smith sees it, is a conflict between the approaches to quality of ISO and CMM programs, on the one hand, and the business model that corporations use on the other. -When you're developing a product, the hardest problems to fix are the last 20 percent," noted Smith.

Smith highlights three critical elements for understanding ISO 9001 and CMM:

• Understanding and documenting the true requirements is a key element in both standards.
• Document how you write the software code so other people can understand its value.
• Understand the requirements outlined in the program management and business models. It means understanding the maximum payback from the ISO and CMM levels. This is difficult to achieve because it requires both management and supervisory hats.

Software in the original description of ISO 9001 is different from software that runs on a computer, explains Mark Paulk, a senior member of the technical staff at Carnegie Mellon's SEI.

Paulk's advice: Understand the essence of ISO 9001 so you can compare it to CMM. ISO 9001's definition of software is more general and includes music, entertainment, or anything involving the creation of an intangible product.

-But the original bias of the standard was strongly toward the manufacturing environment, where all the historical work had been done," said Paulk. -And that is one of the criticisms of the early releases of the standards. One of the objectives of the ISO 9000 revisions was it failed to make the standard more comfortable to users in other environments."

CMM goes further
But the problem, and goal, is balancing ISO and CMM against the business model, says Smith. -The key difference between ISO 9001 and CMM is understanding that the software process is both a software process and a manufacturing process," he explained. -ISO 9001 and the whole ISO process approaches software from a manufacturing standpoint. CMM approaches it from a development standpoint."

The CMM model was designed with five levels of maturity, notes Weidemann. -ISO does not have them. CMM's level 5 is the ultimate level, and [there are] only about 200 companies in the world that are at level 4 or above. It is pretty elite. CMM standards are more stringent that ISO standards. ISO standards are very loose. ISO does not say you have to have certain standards, but CMM says you must meet these standards and here is what they are," he said.

Smith added, -CMM was designed to ensure bug-free development. And ISO is designed to put quality into the manufacturing process. Their purposes are different. Some versions of CMM and ISO have been merged together."