Software QA

ISO 9001 for Software Industry

2009-11-09T18:58:00.000-08:00

-- updated quarterly (ISO 9000-3, TickIT,...) --
"Quality will always win if you give it a chance." -- Small Business 2000
Tantara offers easy access to ISO 9001 information (ISO 9000-3, TickIT,...) that is specific to improving a software organization's process effectiveness and product/service potential.
See Tantara's main hotlist for other information.

When reading information on the internet, take note of the standard/model's edition being discussed/compared. Click here for a list depicting the current edition of key standards/models.
Click here for a quick view of the world's maturity regarding software quality and software process capability.

Resources:

Guidelines for application of ISO 9001 to software development: This web page summarizes ISO 9000-3:1991.

ISO 9000-3:1991 guidelines translated in plain english: Praxiom summarizes their interpretation of ISO 9000-3:1997 and highlights their main points.

ISO 9000-3:1991 checklist: Suggestions and a list of questions to determine whether requirments are met.

ISO 9001 explained clause-by-clause (both 2000 & 1994 editions): This is a good summary of how to interprete the ISO 9001 standard.

ISO 9001:2000 guidance: Lots of guidance here from ISO themselves.

ISO standards for the software industry: Enter software in the keyword field of the form -- if you prefer to view all computing specific standards, enter "information technology" in the keyword field. Then, click the SEARCH button to see the list of ISO standards.

ISO 9001:2000 translated in plain english: Praxiom summarizes their interpretation of ISO 9001:2000 and highlights their main points.

Trillium capability (area 5) - Quality System: Refer to this model's capability area #5 for a phase (level) approach to implementing an ISO 9001 compliant quality system for software development.
Articles:

Applicability of ISO 9001 to software development: How is ISO 9001:1994 relevant to software development organizations? What is the role of ISO 9000-3:1997?

Briefing--ISO 9000:1994 series: In light of the software development challenge, a briefing on the ISO 9000 series of standards (presented in March 1996).

History and relationship of process standards/models: Software process improvement is often influenced by process related standards/models and thus, it is important that a "change agent" understands the history and relationships of these standards/models.

TickIT description: TickIT is an ISO 9001 scheme for the software industry. Discover the principles and objectives of this scheme.

TickIT--providing confidence in ISO 9001:1994 certification: This paper traces the events that led up to the TickIT initiative, outlines TickIT, and discusses the issues that were outstanding in 1995.
Documents and Reports:

Report: Comparison of ISO 9001:1994 and SEI's SE-CMM V1.1 [pdf]: This is a top level summary of the comparison between the Systems Engineering Capability Maturity Model and ISO 9001.

Report: Comparison of ISO 9001:1987 and SEI's SW-CMM V1.1 [pdf]: M. Paulk's comparison report for SEI, report released in 1994. Comparison is version 1.1 of SEI's Capability Maturity Model for Software (SW-CMM) against the initial release (1987 edition) of ISO 9001. Also see M.Paulk's January 1996 IEEE Software feature article "How ISO 9001:1994 Compares with the CMM V1.1".

Report: Executive overview - TickIT for ISO 9001:2000 [pdf]: This is a quick four page overview of the revised TickIT guide for ISO 9001:2000.
Registered Software Organizations and their Registrars:

Quality Digest's search for ISO 9001 registered organizations: A form is presented; to view all software development organizations registered to ISO 9001in North America, enter "9001" in the "Standards" field and "software" in the "Scope of Registration" field -- leave all other fields blank. -- Note: Click here to purchase a complete directory of all ISO 9000 registered companies in North America.

Registrar Accreditation Board (RAB) accredited ISO 9000 registrars: Enter "33-Information Technology" in the scope field of the form presented at the bottom of this page. Click SUBMIT button to see a list of RAB accredited "ISO 9000 registrars for the software industry".

Standards Council of Canada (SCC) accredited ISO 9000 registrars: This is the current list of SCC accredited ISO 9000 registrars.
Governing agents for ISO 9001 and related software industry schemes:

ISO: The home (web) site for the International Organization for Standardization.

ISO Members: This is a list of all ISO Members--view this list to determine who is the ISO Member representative for your country.

ISO's Technical Sub-Committee #176-SC2 (re: Quality Management/Assurance): This site is provided for work specific to ISO 9001 and 9004 -- checkout this site for the many guidelines regarding transitioning ISO 9001:1994 to ISO 9001:2000

ISO's Technical Committee #176 (oversees Quality Management/Assurance): This site is for the TC176 committee members who oversee work pertaining to the ISO 9000 series and related standards/guidelines (e.g., ISO 10000 serries...)

TickIT: The home (web) site for the United Kingdom's TickIT scheme.
If you found this hotlist helpful, imagine what Tantara can do "in person" (consulting / training).
Why consider Tantara's consulting/training?
Tantara is one of the few firms that has proven experience in both software process improvement and ISO 9001 (ISO 9000-3, TickIT, AS 3563).
more

Managing Capability and Maturity

2009-02-24T21:00:00.000-08:00

Managing Capability and Maturity: Part 2

By: David Norfolk, Practice Leader - Development, Bloor Research
Published: 24th February 2009
Copyright Bloor Research © 2009

Page Tools

More from author
February 2009
Managing capability and maturity : 1
February 2009
You don't want a CMDB, you want a CMS
February 2009
Continuous Application Performance Management
January 2009
Something new in Perforce SCM
January 2009
Application Integrity: the Coverity approach.
December 2008
Compuware CU2008 - Day 2
December 2008
CU2008 Day 1
Syndication
Delicious
Digg
reddit
Facebook
StumbleUpon
In part one of this article,we talked about informal maturity management and why it might be a good thing. Now we want to talk about "the real thing" (CMMI; Capability Maturity Management Integrated, from the Software Engineering Institute at Carnegie Mellon) and why it might be worth the effort. But first, a warning: CMMI is not about gaining a shiny medal and boasting about it. As one CMMI ML5 (Maturity Lebvel 5) company once put it to me (more or less) "our marketing department can claim all sorts of wonderful things and point to real case studies that back up their claims. CMMI is all about not fooling ourselves, making sure that we can actually deliver on our marketroids' claims".

And, another thing to remember. It's generally accepted "in the trade" that if you are at CMMI Maturity Level 1 (ML1: managing, possibly successfully, by the seat of your pants and relying on the right people being around because you're not sure exactly what they do), there's no point in looking at CMMI ML5 as a target. It is simply beyond your comprehension. Aim for CMMI ML2 or 3. This means knowing what you've got, where it runs, what it does and who looks after it; and also involves identifying a few "good practices" that are being used and provably deliver something useful to the business, and sharing them with everyone in the organisation. Now, as a goal, that might sound reasonable, and even achievable.

That said, we thought we'd talk to a CMMI ML5 organisation: Aricent (its appraisal record is here—you should always check a CMMI ML claim, to see what it really means) and attempt to convey a glimpse of the vision. If it all seems too airy-fairy, by all means go back to the previous paragraph and stop reading there.

We talked to R. Sathyavageeswaran, an Assistant Vice President for Quality at Aricent, which is one of the largest privately-held companies in Silicon Valley, focussed on providing strategic innovation, technology and outsourcing services to the communications industry.

Bloor: How is CMMI assessment used—for external marketing or internal process?

S: Aricent has had a long and robust Quality journey where we have aligned our Quality Management Systems to meet the requirements of various international standards and frameworks to meet our business needs.

To give a quick summary, we started off our Quality journey by getting certified to ISO 9001 in 1996, CMM Level 4 in the year 2000, BS7799 Information Security standards in the year 2002, CMMI v1.1 Level 5 in the year 2003, TL9000 (Telecom specific ISO 9001 standards) in the year 2005, ISO 27001 Information Security standards in the year 2007 and now, CMMI v1.2 Level 5 in the year 2008. These frameworks and standards help us in ensuring a very high level of quality in all our deliveries. Alignment to these international standards and frameworks has been primarily to improve our internal processes, while letting the customers benchmark our services with known international standards.

Bloor: OK, so what is the impact of CMMI on your front-line developers?

RS: During our journey towards CMMI assessment, we have been able to implement many process improvements which have resulted in improving schedule/effort compliance and the quality of our deliveries. Some major improvements that were demonstrated during assessment are given below:

Implementation of Monte-Carlo Simulation based Process Performance Models to identify sub-processes that have an impact on the project outcome and help the project team manage the projects better. This has helped us to improve our estimations and re-estimations.
Implementation of a suite of prediction tools to predict defects, schedule, SLA and effort. These include:
Test End Date Prediction using the Exponentially Weighted Moving Average (EWMA) technique (a paper on this technique was selected for presentation in a Software Testing Conference held in Bangalore (India) where it was well received—see abstract here).
Use of a Rayleigh distribution to predict defects during and after the delivery of the product.
Reliability assessment using the Gompertz technique.
Use of non-homogeneous Poisson Process (NHPP) based tools to predict post-release defects.
Use of Monte-Carlo simulation based prediction of effort and SLAs (for maintenance type of projects).
Use of Moving Range Control Charts (XmR charts) for tracking critical sub-processes identified at the time of estimations.
Implementation of a comprehensive Health Index to track the health of projects under maintenance. This has helped us to improve our SLA compliance significantly (by approx 24%) and obtain a corresponding improvement in our Customer Satisfaction Index by 15% during the same period. [The Customer Satisfaction Index is on a scale of +5 to -5 and measures satisfaction levels derived from formal feedback in customer surveys.] This was also selected for presentation in the Global TL9000 conference held in Denver, USA (Sep 2008) where it was well received and we got invitations to present in other forums as well. Our marketing team even covered this through a press note.
Use of basic and advanced statistical techniques to baseline performance, with probabilistic modelling capability.
Bloor: Hmm... with our interest in testing, we're rather impressed to find someone putting defect prediction into practice. We also like seeing someone placing numbers against the benefits delivered

RS: In addition, the following process improvements were successfully demonstrated in many instances during the assessment:

Tracking review effectiveness using 2x2 matrix across different phases of projects.
Implementation of klocwork, a commercially-available Static Analysis tool, in our Products' Business Unit, resulting in reduction in memory leaks in our products.
A suite of tools to plan, identify, and track risks in projects. This includes Risk Profiling and Risk Identification Tracking through intranet tools; and maintenance of a Risk Database.
Process Improvements in the area of QMS (Quality Management System) integration, Testing Effectiveness, Test Automation, Internal Auditing, etc.
All of the above have had a deep impact on our employees. Here's a list of a few benefits:

For Project Managers: The improved focus on Quantitative Project Management helps the project managers in managing the project better, right from planning till closure. The statistical process control mechanisms and process performance models that we introduced as part of our journey to CMMI helps them in predicting the quality and schedule, thereby reducing any negative surprises.
For Developers and Testers: The focus on a well defined documented system, along with training delivery mechanisms, helps the developers and testers to get quickly ramped up on projects. As part of the journey, we enhanced our process assurance on both upstream and downstream life cycle phases and this has resulted in improved quality of deliveries and improved customer satisfaction, which has a very positive impact on team morale and engagement.
For the Business team: It has helped the business team to predict customer satisfaction and retention (based on the various Quality-Cost-Delivery metrics) and also helped in putting in some internal controls on costs/efficiencies/defect rates etc.
In addition, as a robust measurement framework is available, all stakeholders in the project are able to see the relevant metrics and take actions at the appropriate time.

Bloor: So, exploring the measured business value delivered a bit further, what is the impact of CMMI ML5 on business outcomes and how will this be measured?

RS: During this journey, we have seen significant improvements in our ability to meet our plans, quality of deliveries, SLA compliance and most importantly, on our Customer Satisfaction Index. These are business critical parameters and we would continue to track these, along with productivity improvement and repeat business from customers.

Bloor: Ah, we like measuring Customer Satisfaction formally. OK, so what next—reassessment? When?

RS: We plan to expand the scope of the assessment to include more business units and more geographical locations. We will track the CMMI model continuously and upgrade our Quality systems to meet any changes that the SEI may incorporate into the model and plan to go for a re-assessment in the next 24–36 months.

Bloor: But, surely, there must be some downsides to all this?

RS: There are no major downsides in a model based improvement journey. However, as the company goes through inorganic growth through acquisitions of companies which may not have a mature quality system, we would like to keep a close watch on integration of processes to ensure that the processes in these acquired entities are enhanced to meet the business needs.

The other possible area to consider would be the suitability of CMMI for really short duration or low efffort projects. In such cases, it would be better to adapt the full-blown CMMI requirements to meet the requirements of the project—which the CMMI model allows anyway, through project-level tailoring.

Bloor: Yes, that last is a good point, a degree of flexibility is, indeed, built into CMMI. Thank you.

So, there you have it. Does this all sound useful? Well, no matter. You can start on the maturity journey without CMMI. Get rid of the "blame culture". Start managing your assets. Take a look at ITIL v3. Identify "good practice" and make sure everyone gets to use it. Start measuring business outcome in a way that makes sense to the business users (who, ultimately, pay your salaries) and relate your budget requests and project reviews to these metrics. And, please, analyse every delivered project, to see if you can learn things that will help you do it better next time.

Then revisit CMMI and see if there might be something in it after all. It does seem to be succeeding, and not just with US Defence suppliers—see here for a review of the formal "class A" CMMI appraisal results the SEI knows about. They make interesting reading and may dispel a few misconceptions.

Reader Comments

Do you agree with what David Norfolk is saying? Perhaps you feel, or even know, different? Why not post your opinion on this issue?

more

2008-10-22T23:27:00.001-07:00

PTA Professional Edition Updates
Latest Update: Version 1.54 Build 1206 - October 11, 2008.

Build 1206 - Download Latest Cumulative Update - October 11, 2008
If the PTA Risk Assessment tool is already installed on your computer, we strongly recommend that you keep it up-to-date by downloading a free cumulative update with the latest improvements and bug fixes (4MB size; less than 1 minute download time, applicable for all previous versions of PTA).
Build 1206 introduces a revised reporting system which enables better aggregation and sorting of threat model data and analysis results. The new mechanism allows users to define simple Tags Filter queries which filter the data shown in reports according to the tags attached to the threat’s model entities.
Thanks to Andy Baron for his excellent tip on sorting report records at runtime and to Jerry Lee for his great help in defining the tags query UI.
Build 1206 is fully compatible with all existing PTA threat models and libraries versions.
If this is your first time with PTA, you are invited to visit our download area and get a full version of the PTA Professional Edition Risk Assessment tool.

Latest Support Notes :
If you encounter problems when trying to run PTA for the first time after installation:
Please have a look at section 8 in PTA Support & FAQ page which includes a few updated solutions regarding difficulties in running PTA on machines with Office 2007/2003 installed.
How do I know the current version of PTA installed on my computer?
Click the Help About menu option in PTA main menu. The About dialog displays the current PTA version and build number.

***

Moving up the ladder from ISO 9001

2008-03-04T00:49:00.000-08:00

go here

Software Testing

2008-02-18T22:34:00.000-08:00

The main objective of testing is to find defects in requirements, design, documentation, and code as early as possible. The test process should be such that the software product that will be delivered to the customer is defect less. All Tests should be traceable to customer requirements.Test cases must be written for invalid and unexpected, as well as for valid and expected input conditions. A necessary part of a test case is a definition of the expected output or result. A good test case is one that has high probability of detecting an as-yet undiscovered error.Eight Basic Principles of Testing· Define the expected output or result.· Don't test your own programs.· Inspect the results of each test completely.· Include test cases for invalid or unexpected conditions.· Test the program to see if it does what it is not supposed to do as well as what it is supposed to do.· Avoid disposable test cases unless the program itself is disposable.· Do not plan tests assuming that no errors will be found.The probability of locating more errors in any one module is directly proportional to the number of errors already found in that module.Best Testing Practices to be followed during testing· Testing and evaluation responsibility is given to every member, so as to generate team responsibility among all.· Develop Master Test Plan so that resource and responsibilities are understood and assigned as early in the project as possible.· Systematic evaluation and preliminary test design are established as a part of all system engineering and specification work.· Testing is used to verify that all project deliverables and components are complete, and to demonstrate and track true project progress.· A-risk prioritized list of test requirements and objectives (such as requirements-based, design-based, etc) are developed and maintained. · Conduct Reviews as early and as often as possible to provide developer feedback and get problems found and fixed as they occur.
Posted by expert at 12:38 AM 0 comments
Older Posts

List of software companies certified for quality

2008-02-01T21:27:00.000-08:00

go here

Application software threat analysis

2008-01-25T12:05:00.000-08:00

Buggy and insecure software applications are the top factor in security breaches.
The majority of data breaches are caused by attackers that exploit application software vulnerabilities. Attackers are not limited to Islamic cyber-terror groups like Team Evil, that exploited a known vulnerability in the Invision Power Board Web application. Software vulnerabilities are increasingly exploited by threats from trusted insiders such as contract programmers who have access to the source control repositories of company projects.
We improve software security with software quality

Software defect reduction is a highly economical way of preventing data breaches. You may be able to save hundreds of thousands of dollars in your security budget by decisive, focused software defect reduction.

We carry out a systematic threat analysis on critical business and Internet-facing Web applications after choosing a particular business unit and application functions. You get a cost-effective risk mitigation plan that shows you where and how you should remove software defects and how best to maintain reliable software.

The process requires executive level sponsorship that will later on, need to buy into implementation of the risk mitigation plan. The team members are chosen at a preliminary planning meeting with the lead consultant and the project's sponsor. There are typically 4-8 active participants with relevant knowledge of the business and the software. The team is lead by 2-4 expert Software Associates consultants that have the domain expertise, people skills and patience to guide a chaotic process.

The threat analysis follows a 7 step process: Set scope, Identify business assets, Identify software components, Classify vulnerabilties, build a system threat model, build the risk-mitigation plan and validate findings. Since there is normally a great deal of shared information between process steps, control flows asynchronously between steps.
Companies that perform software application threat analysis receive a clear picture of where to focus their software quality and application patching efforts.

Contact us today for a free consultationUS: +1 301-841-7122Israel: +972 (0)3 610 9750Sales AT software DOT co DOT il

More professional services from Software Associates
Digital Asset Protection
Business vulnerability assessment
Risk control optimization
Featured research articles
Software security assessment of production systems
The 7 step process for software threat analysis
Practical threat analysis in software development
10 questions your CEO should be able to answer

Next >

more

Capability Maturity Model Integration CMMI

2008-01-23T15:31:00.000-08:00

Capability Maturity Model® Integration (CMMI®) is a process improvement approach that provides organizations with the essential elements of effective processes.[1] CMMI best practices are published in documents called models, which each address a different area of interest. There are now two areas of interest covered by CMMI models: Development and Acquisition.

The current release of CMMI is Version 1.2. There are two version 1.2 models now available:
CMMI for Development (CMMI-DEV), Version 1.2 was released in August 2006. It addresses product and service development processes.

CMMI for Acquisition (CMMI-ACQ), Version 1.2 was released in November 2007. It addresses supply chain management, acquisition, and outsourcing processes in government and industry.
Regardless of which model you choose, CMMI best practices should be adapted to each individual organization according to its business objectives. Organizations cannot be CMMI "certified." Instead, an organization is appraised (e.g., using an appraisal method like SCAMPI) and is awarded a 1-5 level rating. The rating results of such an appraisal can be published if released by the appraised organization.[2]

Contents
1 Process Areas
2 History
3 Appraisal
4 Benefits
5 CMMI Concepts
6 References
7 Footnotes
8 See also
9 External links
//
more

List of CMM Level 5 Certified companies in India

2008-01-22T18:16:00.000-08:00

go here

Configuration Management and ISO 9001

2007-11-09T04:42:00.000-08:00

Robert Bamford, William J. Deibler II Software Systems Quality Consulting, http://www.ssqc.com/

Configuration management is about managing change of the multiple items composing an information system. This article puts in reference the configuration management function and the ISO 9001 standard. This standard offers a wide range of advice on how to deal with this important, but often neglected, aspect of software engineering.

The software engineering practices associated with software configuration management (SCM or CM) offer a number of opportunities to address requirements found in the International Standard, ISO 9001. From a management perspective, the principles and practices of CM represent an accepted and understood foundation for implementing ISO-compliant processes in software engineering organizations. In addition, the growing number of tools for automating CM practices is chance for improving the efficiency and effectiveness of these processes.

This article begins with brief, general definitions of configuration management and of ISO 9001.
Configuration Management
While there is no single definition of CM, there are three widely disseminated views from three different sources: the Institute of Electrical and Electronics Engineers (IEEE), The International Organisation for Standardisation (ISO), and the Software Engineering Institute (SEI) at Carnegie Mellon University.

The IEEE perspective on CM
A most widely understood description of the practices associated with configuration management is found in the IEEE Standard 828-1990, Software Configuration Management Plans.
[Numbers in brackets are added]

"SCM activities are traditionally grouped into four functions: [1] configuration identification, [2] configuration control, [3] status accounting, and [4] configuration audits and reviews."
IEEE Standard 828-1990 goes on to list specific activities associated with each of the four functions (the number of the paragraph containing the reference appears in parentheses):
Identification: identify, name, and describe the documented physical and functional characteristics of the code, specifications, design, and data elements to be controlled for the project. (Paragraph 2.3.1)

Control: request, evaluate, approve or disapprove, and implement changes (Paragraph 2.3.2)
Status accounting: record and report the status of project configuration items [initial approved version. status of requested changes, implementation status of approved changes] (Paragraph 2.3.3)

Audits and reviews: determine to what extent the actual configuration item reflects the required physical and functional characteristics (Paragraph 2.3.4)

This list is similar to the set of activities noted by Pressman:
"Software configuration management is an umbrella activity ... developed to (1) identify change, (2) control change, (3) ensure that change is being properly implemented, and (4) report change to others who may have an interest."

The ISO perspective on CM
In the guideline document, ISO 9000-3:1991 Guidelines for the application of ISO 9001 to the development, supply and maintenance of software, the International Organisation for Standardisation identifies a similar set of practices as CM:
"Configuration management provides a mechanism for identifying, controlling and tracking the versions of each software item. In many cases earlier versions still in use must also be maintained and controlled.

"The [CM] system should
"a) identify uniquely the versions of each software item;
"b) identify the versions of each software item which together constitute a specific version of a complete product;
"c) identity the build status of software products in development or delivered and installed;
"d) control simultaneous updating of a given software item by more than one person;
"e) provide coordination for the updating of multiple products in one or more locations as required;
"f) identify and track all actions and changes resulting from a change request, from initiation ... to release."

The SEI perspective on CM
Based on a review of currently available tools and an evolving understanding of the organizational role of CM, the SEI advocates a broader definition of CM in SEI-92-TR-8:
"The standard definition for CM taken from IEEE standard 729-1983 [updated as IEEE Std 610.12-1990] includes:
"Identification: identifying the structure of the product, its components and their type, and making them unique and accessible in some form
"Control: controlling the release of product and changes to it throughout the life cycle …
"Status Accounting: recording and reporting the status of components and change requests, and gathering vital statistics about components in the product
"Audit and review: validating the completeness of a product and maintaining consistency among the components …

"[The IEEE] definition of CM … needs to be broadened to encompass … :
"Manufacturing: managing the construction and building of the product
"Process management: ensuring the correct execution of the organization's procedures, policies, and life-cycle model
"Team work: controlling the work and interactions between multiple developers on a product."

more

more

Advice on Configuration Management

Software Validation

2007-11-03T14:32:00.000-07:00

Software validation is a critical tool used to assure the quality of device software and software automated operations. Software validation can increase the usability and reliability of the device, resulting in decreased failure rates, fewer recalls and corrective actions, less risk to patients and users, and reduced liability to device manufacturers.

Software validation can also reduce long term costs by making it easier and less costly to reliably modify software and revalidate software changes. Software maintenance can represent a very large percentage of the total cost of software over its entire life cycle. An established comprehensive software validation process helps to reduce the long-term cost of software by reducing the cost of validation for each subsequent release of the software.

Table of Contents
SECTION 1. PURPOSE
SECTION 2. SCOPE
2.1. Applicability
2.2. Audience
2.3. THE LEAST BURDENSOME APPROACH
2.4. Regulatory Requirements for Software Validation
2.4. Quality System Regulation vs Pre-Market Submissions
SECTION 3. CONTEXT FOR SOFTWARE VALIDATION
3.1. Definitions and Terminology
3.1.1 Requirements and Specifications
3.1.2 Verification and Validation
3.1.3 IQ/OQ/PQ
3.2. Software Development as Part of System Design
3.3. Software is Different from Hardware
3.4. Benefits of Software Validation
3.5 Design Review
SECTION 4. PRINCIPLES OF SOFTWARE VALIDATION
4.1. Requirements
4.2. Defect Prevention
4.3. Time and Effort
4.4. Software Life Cycle
4.5. Plans
4.6. Procedures
4.7. Software Validation After a Change
4.8. Validation Coverage
4.9. Independence of Review
4.10. Flexibility and Responsibility
SECTION 5. ACTIVITIES AND TASKS
5.1. Software Life Cycle Activities
5.2. Typical Tasks Supporting Validation
5.2.1. Quality Planning
5.2.2. Requirements
5.2.3. Design
5.2.4. Construction or Coding
5.2.5. Testing by the Software Developer
5.2.6. User Site Testing
5.2.7. Maintenance and Software Changes
SECTION 6. VALIDATION OF AUTOMATED PROCESS EQUIPMENT AND QUALITY SYSTEM SOFTWARE
6.1. How Much Validation Evidence Is Needed?
6.2. Defined User Requirements
6.3. Validation of Off-the-Shelf Software and Automated Equipment
APPENDIX A - REFERENCES
Food and Drug Administration References
Other Government References
International and National Consensus Standards
Production Process Software References
General Software Quality References
APPENDIX B - DEVELOPMENT TEAM

more

more

Software Quality Basics

2007-11-03T12:52:00.000-07:00

'Quality' is a relative term and it is generally used with reference to the end use of the product. The word 'quality' has variety of meanings including fitness for purpose, grade, degree of preference, degree of excellence & fulfillment of promises.

It may also be defined as a degree of conformance of design and specifications. American Heritage Dictionary defines Quality as "A characteristics or attribute of something". When we examine an item based on its measurable characteristics, two kinds of quality may be encountered:1.Quality of design2.Quality of conformanceThe quality of design of a product is concerned with the tightness of the specifications for manufacture of the product. It depends on the type of customers in the market, capital goods, profit consideration of the organization & special requirements of the product. The quality of conformance is concerned with how well the manufactured product conforms to the quality of design. To achieve this, the incoming raw materials have to be of adequate quality, selection of the process should be proper, operators need to be trained and experienced & proper care should be taken during shipment and storage of finished goods. A proper inspection program & feedback mechanism should exist, both for internal inspection & for the customers.The quality of performance is concerned with how well the manufactured product gives its performance t depends upon the quality of design & the quality of conformance.The cost of carrying out the company's quality functions (meeting the quality needs of the customers) are known as costs of quality. It provides baseline for the current cost of quality and identifies opportunities for reducing the cost of quality in the future. A quality cost committee of the American Society for Quality Control has recommended that quality cost be defined in four categories:

more

debugging and testing

2007-11-03T12:37:00.000-07:00

Debugging is a methodical process of finding and reducing the number of bugs, or defects, in a computer program or a piece of electronic hardware thus making it behave as expected. Debugging tends to be harder when various subsystems are tightly coupled, as changes in one may cause bugs to emerge in another.
Contents[hide]
1 Origin
2 Tools
3 Basic steps
3.1 Recognize a bug exists
3.2 Isolate source of bug
3.3 Identify cause of bug
3.4 Determine fix for bug
3.5 Fix and test
4 Steps to reduce debugging
4.1 The correct mindset
4.2 Start at the source
4.3 Treat user input with suspicion
4.4 Use of log files
4.5 Test suites
4.6 Change one thing at a time
4.7 Back out changes that have no effect
4.8 Think of similar situations
5 See also
6 References
7 External links

more

Freeware Debugging Freeware Download Shareware Download ...
Download freeware Debugging freeware download Debugging shareware download software Debugging software directory provide Software Developer :: Debugging ...www.brothersoft.com/Software_Developer_Debugging_Download_List_1.html - 57k - Cached - Similar pages

Testing and Debugging Software
Readers chose VMware Workstation as the Best Testing and Debugging Software.www.windowsitpro.com/Articles/Index.cfm?ArticleID=40181 - Similar pages

New Approaches to Software Debugging
The long term goal of our research is to investigate more effective, general methods of debugging complicated software systems. We are investigating new ...www.cs.purdue.edu/AnnualReports/95/AR95Book-126.html - 4k - Cached - Similar pages

Software debugging, testing, and verification
IBM Systems Journal issue 41-1, Software Testing and Verification - Software debugging, testing, and verification - Feature paper.www.research.ibm.com/journal/sj/411/hailpern.html - 53k - Cached - Similar pages

Software Debugging Process: How it goes and how to improve it ...
The process of debugging: formalization & improvement.www.codeproject.com/Purgatory/debugprocess.asp - 31k - Cached - Similar pages

Chipping software for faster debugging
If you've spent some time doing software development, you know that debugging and testing consume more time than writing code, especially on large projects. ...www.primidi.com/2007/10/06.html - 26k - Cached - Similar pages

Deshpande Center - Complex Systems and Communications Projects
This project is applying a novel technology to the problems of understanding, evolving, testing, and debugging software systems. The technology will be able ...web.mit.edu/deshpandecenter/proj_ernst.html - 17k - Cached - Similar pages

Linux software debugging with GDB
Most flavours of Linux come with the GNU debugger, or gdb to the shell. Gdb lets you see the internal structure of a program, print out variable values, ...www.ibm.com/developerworks/library/l-gdb/ - 53k - Cached - Similar pages

! Aware: default selections: Software Debugging and Testing
Debugging can be just as disciplined, systematic, and quantifiable as any other area of software engineering--which means that we should eventually be able ...www.rocketaware.com/spec/softdev/debug/ - 50k - Cached - Similar pages

Applicability of ISO 9001 to Software Development

2007-10-11T18:52:00.000-07:00

go here

ISO 9000-3 1997 Guidelines in Plain English
go here

ISO 9000-3 1997 is now OBSOLETE. It has been replaced by ISO IEC 90003 2004.

How to ensure EVM operates well for software projects

2007-10-07T03:52:00.000-07:00

go here

Configuration Management

2007-08-23T15:05:00.000-07:00

FAQ's
go here

SPICE (ISO/IEC 15504) VS SEI CMMI

2007-06-28T17:18:00.000-07:00

Acceptance of ISO/IEC 15504
ISO/IEC 15504 has been successful as:

In 2006 GM and Chrysler have started phasing out CMMI in favor of SPICE as they relocate their engineering centers to Europe.
ISO/IEC 15504 is publicly available through National Standards Bodies.
It has the support of the international community
Over 4000 assessments have been performed to date
Major sectors are leading the pace such as automotive, space and medical systems with industry relevant variants
Domain-specific models like Automotive SPICE can be derived from it
There have been many international initiatives to support take-up such as SPICE for small companies.

more

Adding SPICE whiile preserving the CMM

ISO/IEC 15504 - SPICE

2007-06-28T16:51:00.000-07:00

Contents: What is ISO/IEC 15504?What does the SEI plan to do to be compliant to this standard? How will the SEI help the community prepare to meet this standard?How does ISO/IEC 15504 relate to the Software CMM and to ISO 9001?Will the software community have to choose between 15504 and their current model of choice?What are the considerations in determining whether 15504 conformance is important to my business?How can I obtain more information about 15504?

http://www.sei.cmu.edu/cmmi/faq/15504-faq.html

ISO/IEC 15504 (all parts) provides a framework for the assessment of processes. This framework can be used by organizations involved in planning, managing, monitoring, controlling and improving the acquisition, supply, development, operation, evolution and support of products and services.

ISO/IEC 15504-3:2004 provides guidance on meeting the minimum set of requirements for performing an assessment contained in ISO/IEC 15504-2.

It provides an overview of process assessment and interprets the requirements through the provision of guidance on:

performing an assessment;
the measurement framework for process capability;
process reference models and process assessment models;
selecting and using assessment tools;
competency of assessors;
verification of conformity.

ISO/IEC 15504-3:2004 also provides an exemplar documented assessment process that conforms to the requirements of 4.2 in ISO/IEC 15504-2.
Corrigenda, Amendments and other parts
ISO/IEC 15504-1:2004
ISO/IEC 15504-2:2003
ISO/IEC 15504-4:2004
ISO/IEC 15504-5:2006

http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=37454

There are a variety of ISO standards addressing various aspects of process improvement.
ISO 9000 is a set of standards for quality management systems that is accepted around the world. Currently more than 800,000 organizations in 161 countries have adopted ISO 9000 as national standards. When you purchase a product or service from an organization that is registered to the appropriate ISO 9000 standard, you have important assurances that the quality of what you receive will be as you expect. In addition, with the year 2000 revision of the standard, quality objectives, continual improvement, and monitoring of customer satisfaction provide the customer with increased assurances that their needs and expectations will be met. There is significant overlap between ISO 9000 and SW-CMM® Level 2. A comparison of the two is documented in A Comparison of ISO 9001 and the SW-CMM® [download is cmm9001.pdf] Note that the document was scanned in reverse order, so the first page you see is actually the last page of the document.
ISO 15504 (SPICE) SPICE (ISO/IEC 15504) is a major international initiative to develop a Standard for Software Process Appraisal. The project is carried out under the auspices of the International Committee on Software Engineering Standards ISO/IEC JTC 1/SC 7, through its Working Group on Software Process Appraisal (WG10). Since 1993, the SPICE (ISO/IEC 15504) (Software Process Improvement and Capability Determination) project, launched within the ISO has been developing a framework standard for software process Appraisal, bringing together the major suppliers and users of Appraisal methods. Field trials of SPICE-based Appraisal commenced in January 1995, and will continue until ISO/IEC 15504 is published as a full International Standard, scheduled by 2002.
ISO 12207 offers a framework for software life-cycle processes from concept through retirement. It is especially suitable for acquisitions because it recognizes the distinct roles of acquisitor and supplier. In fact, the standard is intended for two-party use where an agreement or contract defines the development, maintenance, or operation of a software system. It is not applicable to the purchase of commercial-off-the-shelf (COTS) software products. ISO 12207 provides a structure of processes using mutually accepted terminology, rather than dictating a particular life-cycle model or software development method. Since it is a relatively high-level document, 12207 does not specify the details of how to perform the activities and tasks comprising the processes. Nor does it prescribe the name, format, or content of documentation. Therefore, organizations seeking to apply 12207 may want to use additional standards or procedures that specify those details.
CMMI® version 1.2 is coming. Are you ready?
CMMI® version 1.1 will be sunsetted as of August 31, 2007, and version 1.1 of the Introduction to the CMMI® will not be offered after December 31, 2006. MDM will provide the new version 1.2 of the CMMI® introduction class, along with training on SCAMPISM version 1.2.
Learn MoreLearn about the L2 QuickStart Workshop.

Purpose Driven Process ImprovementSM is designed to:

improve quality
reduce costs
improve morale
reduce cycle times
increase productivity
improve project control

Is process improvement right for you?

-->
http://www.mdmaturity.com/models.php

ISO 15504

ISO/IEC 15504 also known as SPICE (Software Process Improvement and Capability dEtermination) is a "framework for the assessment of processes" developed by the Joint Technical Subcommittee between ISO (International Organization for Standardization) and IEC (International Electrotechnical Commission).
ISO/IEC 15504 initially was derived from process lifecycle standard ISO 12207 and the ideas of capability maturity in SW CMM.
Contents
1 Overview
2 The ISO/IEC 15504 standard
2.1 Reference model
2.1.1 Processes
2.1.2 Capability levels and process attributes
2.2 Assessments
2.2.1 Assessment process
2.2.2 Assessment model
2.2.3 Tools used in the assessment
2.3 Assessor qualifications and competency
2.4 Uses of ISO/IEC 15504
2.4.1 Process improvement
2.4.2 Capability determination
3 History
4 Acceptance of ISO/IEC 15504
5 References
6 External links

more

what you get as you head towards CMMI Level 5

2007-06-28T16:41:00.000-07:00

go here

FAQ's

2007-06-28T13:31:00.001-07:00

Optimising the software delivery cycle **** A ZDNet UK discussion panel ****
Quality software delivery is a perennial challenge for anyone involved in the software delivery process, from CIOs to developers.
There is a rolling pressure to deliver, within a fixed time frame and a very fixed budget, high quality, robust software that can both support and help grow the business.
How can you best deliver quality software on time and to budget?
Discover how some of the big software development houses do it in this ZDNet UK panel discussion.
Watch the panel discussion

http://www.zdnet.co.uk/zdnetuk/resources/articles/0,1000001991,39287689,00.htm

2007-05-31T21:00:00.000-07:00

[Methods & Tools] [Links]

Martinig & Associates has conducted software process evaluation based on the Capability Maturity Model (CMM ( CMMI) between 1993 and 2001 using a questionnaire based the first version of the assessment questionnaire produced by the Software Engineering Institute (SEI) in 1987. These assessments evaluated the quality of the software development process of organisations. There are more than 200 organisations assessed in our database from all over the world.

Software Process Assessments Results
ISO 9000 and CMM usage
CMM (1987 questionnaire) Maturity levels and key process area results
CMM (1987 questionnaire) Technology usage results
Articles
Does training influence the quality of the software development process?
Assessing Readiness for (Software) Process Improvement
Don't Write Another Process
Process Improvement – Is it a Lottery?
Software Development Articles - Software Process Improvement area
Resources
External links page

http://www.martinig.ch/ae/process.php

Journey from ISO 9001 to SW CMM Level 5

2007-05-31T00:05:00.000-07:00

[PDF]
Two stage journey from ISO 9001 to CMM Level 5, an Experience
File Format: PDF/Adobe Acrobat - View as HTMLSyntel (India) Ltd. Journey from ISO 9001 to SW CMM Level 5. Page 1 of. 8. Journey from ISO 9001 to SW CMM Level 5. (A Two Stage Journey Experience) ...www.softwaredioxide.com/channels/Content/Syntel_Journey_ISO_to_CMM.pdf - Similar pages
AmitySoft receives ISO 9001 millennium version
With the certification, AmitySoft has achieved the distinction of being one of the first set of software companies in India to be ISO 9001:2000 compliant. ...amitysoft.com/press9.aspx - 13k - Cached - Similar pages

FAQ;s

2007-05-20T03:20:00.000-07:00

Table of Contents Software QA and Testing Frequently-Asked-Questions Part 1, covers the following:
What is 'Software Quality Assurance'?
What is 'Software Testing'?
What are some recent major computer system failures caused by software bugs?
Does every software project need testers?
Why does software have bugs?
How can new Software QA processes be introduced in an existing organization?
What is verification? validation?
What is a 'walkthrough'?
What's an 'inspection'?
What kinds of testing should be considered?
What are 5 common problems in the software development process?
What are 5 common solutions to software development problems?
What is software 'quality'?
What is 'good code'?
What is 'good design'?
What is SEI? CMM? CMMI? ISO? Will it help?
What is the 'software life cycle'?
Software QA and Testing Frequently-Asked-Questions Part 2, covers the following:
What makes a good Software Test engineer?
What makes a good Software QA engineer?
What makes a good QA or Test manager?
What's the role of documentation in QA?
What's the big deal about 'requirements'?
What steps are needed to develop and run software tests?
What's a 'test plan'?
What's a 'test case'?
What should be done after a bug is found?
What is 'configuration management'?
What if the software is so buggy it can't really be tested at all?
How can it be known when to stop testing?
What if there isn't enough time for thorough testing?
What if the project isn't big enough to justify extensive testing?
How does a client/server environment affect testing?
How can World Wide Web sites be tested?
How is testing affected by object-oriented designs?
What is Extreme Programming and what's it got to do with testing? Software QA and Testing Less-Frequently-Asked-Questions, covers the following:
Why is it often hard for organizations to get serious about quality assurance?
Who is responsible for risk management?
Who should decide when software is ready to be released?
What can be done if requirements are changing continuously?
What if the application has functionality that wasn't in the requirements?
How can QA processes be implemented without reducing productivity?
What if an organization is growing so fast that fixed QA processes are impossible?
Will automated testing tools make testing easier?
What's the best way to choose a test automation tool?
How can it be determined if a test environment is appropriate?
What's the best approach to software test estimation?
Other Software QA and Testing Resources
Top 5 List
Software QA and Testing-related Organizations and Certifications
Links to QA and Testing-related Magazines/Publications
General Software QA and Testing Resources
Web QA and Testing Resources
Web Security Testing Resources
Web Usability Resources
Software QA and Test Tools
Test tools
CM tools and PM tools
Web site test and management tools
Web Site Test Tools and Site Management Tools
Load and performance test tools
Java test tools
HTML Validators
Link Checkers
Free On-the-Web HTML Validators and Link Checkers
PERL and C Programs for Validating and Checking
Web Functional/Regression Test Tools
Web Site Security Test Tools
External Site Monitoring Services
Web Site Management Tools
Log Analysis Tools
Other Web Test Tools
Jobs and News
Web Job Boards useful to QA and Test Engineers
Latest News Headlines -- Technology, Software Development, Computer Security, Tech Stocks, more...
Software QA and Testing Bookstore
Software Testing Books
Software Test Automation Books
Software Quality Assurance Books
Software Requirements Engineering Books
Software Metrics Books
Configuration Management Books
Software Risk Management Books
Software Engineering Books
Software Project Management Books
Technical Background Basics Books
Other Books

http://www.softwareqatest.com/

Vendor Selection

2007-05-20T02:46:00.000-07:00

for software outsourcing
http://72.14.235.104/search?q=cache:7o8W9ifNxbsJ:www.oobp.org/Vendor/Downloads_GetFile.aspx%3Fid%3D540+copc+or+cobit&hl=en&amp;amp;amp;ct=clnk&cd=5&gl=in

for esourcing

eSourcing Capability Models
Quality models and certification for IT and ITES organizations
With the continued growth of IT services and ITES (Information Technology Enabled Services), organizations are striving to reach higher levels of performance and capability. In these relationships, service providers use information technology as a key component of, or as an enabler for, delivering their services. Technology alone does not provide complete solutions, as the eSourcing relationships between clients and their service providers must overcome many challenges to be successful.
The eSourcing relationship challenges include:
Clients often have little experience in outsourcing and have no standard criteria for selecting a provider.
Success criteria for the relationship are not well understood or agreed upon from inception by both parties.
Clients’ expectations often change as the nature of the services change, due to rapid shifts in technology and tools, and providers are not always able to keep up with those changes
The necessary trade-offs between the service’s quality, speed, and cost are not always articulated and understood.
The transfer of personnel, equipment, and knowledge between the client and service provider is often problematic.
Service providers often have trouble analyzing and reporting their progress in terms that are meaningful for clients.
Types of sourcing services
The IT Services Qualification Center (ITSqc) at Carnegie Mellon University has created “best practices” capability models for both sides of the eSourcing relationship. The eSourcing Capability Model for Service Providers (eSCM-SP) v2 was released in April 2004. The eSourcing Capability Model for Client Organizations (eSCM-CL) is being released in 2006.
eSCM for Service Providers
The eSCM-SP v2 offers ITES providers a framework to improve their capability to deliver consistently high quality services. It also assists them in establishing, managing, and continually improving relationships with clients. The intent of the eSCM is to present service providers with a set of best practices that help them effectively manage sourcing relationships. Besides, it presents clients with a way to evaluate and compare service provider’s capabilities.
ITSqc developed the eSCM-SP for three purposes. First, it helps ITES providers appraise and improve their ability to provide high quality sourcing services. Second, it gives them a way to differentiate themselves from the competition. Third, prospective clients can evaluate service providers based on their eSCM-SP level of certification and Practice Satisfaction Profile.
Each of the Model’s 84 Practices is distributed along three dimensions: Sourcing Life-cycle, Capability Areas, and Capability Levels. While most quality models focus only on delivery capabilities, the eSCM-SP’s Sourcing Life-cycle includes delivery, as well as initiation and completion of contracts where many commonly encountered problems arise.
The eSCM-SP offers a five-level improvement path that service providers can travel to enhance value and sustain excellence over time. By grouping the practices into increasing levels of capability, the eSCM-SP describes an improvement path for a service provider. Providers may advance from a minimal level of delivering services, to the highest level, where they are proactively enhancing value for clients, regardless of the requirements or scope of sourcing efforts.
The eSCM-SP has been designed to complement existing quality models so that service providers can capitalize on their previous improvement efforts. The Model’s structure complements most existing quality models such as ISO 9001, ISO 20000-1, ISO 27001, the CMMs®, COBIT® and COPC-2000®. Therefore it can be implemented in parallel with these other frameworks. A series of documents comparing the eSCM-SP with other models and standards is in production and available from the ITSqc Web site.
eSCM for Client Organizations
In order to address both aspects of the eSourcing relationship, the ITSqc has developed the eSCM for Client Organizations (eSCM-CL), which addresses the challenges of sourcing relationships from client’s perspective. Existing frameworks do not comprehensively address the best practices needed by client organizations to successfully source and manage ITES. Actions of the client organization and of the service provider in these sourcing relationships are critical for the success.
Many other frameworks focus on delivery, although the roots of many sourcing difficulties often lie elsewhere. The 95 Practices of the eSCM-CL cover the full sourcing life cycle. This best practice model begins with the client’s strategy for eSourcing, moving through initiation into delivery and, eventually, into completion activities. It allows client organizations to continuously evolve, improve, and innovate their capabilities to develop stronger, longer term, and more trusting relationships with their service providers. It also ensures that their sourcing activities provide true business value to the organization. Key aspects of the eSCM-CL that are not covered by many other standards include organizational change management and value management practices to ensure that the organization successfully manages its sourcing transformation, and that its sourcing activities return appropriate value and align with the organization’s objectives.
In addition, eSCM-CL enables client organizations to appraise and improve their capability to foster the development of more effective relationships, better manage these relationships, and experience fewer failures in their client-service provider relationship.
The eSCM-SP v2
The 84 eSCM-SP v2 Practices are arranged within three dimensions: Sourcing Life-cycle, Capability Areas, and Capability Levels.
The eSCM-CL
The Sourcing Life-cycle addressed by the eSCM-CL extends earlier than the Phases of the Sourcing Life-cycle covered by the eSCM-SP. Its 95 Practices address the sourcing activities of the client organization dealing with its sourcing strategy and analysis of its operations and potential sourcing opportunities during the Analysis Phase.
ITSqc and UL
Carnegie Mellon University’s ITSqc is a multidisciplinary group of researchers, practitioners, and organizations that addresses the needs of ITES providers and their clients. To that end, the ITSqc develops quality models and qualification methods for organizations involved in eSourcing. eSCM, a set of complimentary best practices for the IT-Sourcing Market, is fast becoming the standard for sourcing relationships on both sides of the service relationship. For more information about the eSCM Models or eSCM-certified organizations, visit http://www.itsqc.cmu.edu/. These documents and all Model documents are available at itsqc.cmu.edu/downloads.
UL is an ITSqc-authorized provider of independent, third-party eSCM appraisals and evaluations, which can lead to certification by the ITSqc at Carnegie Mellon University.
For more information about eSourcing Capability Model, please contact Dr. Hefley at Hefley@cmu.edu or JC Sekar, General Manager, Management System Registration Services (Asia Pacific, Middle East and Africa) at Jc.sekar@sg.ul.com.

http://www.ul-asia.com/news_nl/2006-Issue20/page6.htm

SEI Authorized Lead Assessor

2007-02-20T12:56:00.000-08:00

How to become an SEI Partner
http://www.sei.cmu.edu/partners/lead-assessor.html

SEI Partner Network Directory: SEI Partner Directory Search
http://partner-directory.sei.cmu.edu/

Index of FAQs
Appraisal Program
CERT Coordination Center
CMMI Frequently Asked Questions
Education and Training
Intellectual Property
INTRo
IPRC
ISO/IEC 15504 [0.03MB PDF]
OCTAVE
Open Systems
People Capability Maturity Model
Risk Management
SEI Partner Network
SEIR
Software Product Line Acquisition
Sunset of the Software CMM
TSP and PSP
Publications

http://www.sei.cmu.edu/about/faq-list.html

People Capability Maturity Model (People CMM)
This topic contains questions and answers about the People CMM.
http://www.sei.cmu.edu/cmm-p/version2/faq.html#Q204

Contents: What is the People Capability Maturity Model (People CMM)?What are the plans for People CMM in the coming year?How do I become a People CMM Lead Appraiser?How do I get more information about the People CMM?My organization is planning an appraisal soon, and we have been guiding our improvement program with Version 1 of the People CMM; can we still conduct the appraisal with version 1?Why isn't there a continuous representation of People CMM version 2?Will People CMM version 2 be integrated into CMMI?How does People CMM version 2 support integrated product development teams?Where can I obtain training on the People CMM?When will you release People CMM version 3?How do I find an authorized People CMM Lead Appraiser?

What is the People Capability Maturity Model (People CMM)?
The People Capability Maturity Model (People CMM) is a maturity framework that focuses on continuously improving the management and development of the human assets of an organization. It describes an evolutionary improvement path from ad hoc, inconsistently performed practices, to a mature, disciplined, and continuously improving development of the knowledge, skills, and motivation of the workforce that enhances strategic business performance. The People CMM provides guidance to organizations in selecting immediate improvement actions that help organizations
characterize the maturity of their workforce practices
set priorities for immediate action
integrate workforce development with process improvement
become an employer of choice
With the help of the Capability Maturity Model Integration (CMMI) and Capability Maturity Model for Software (SW-CMM), many organizations have made valuable improvements in their software and systems processes and practices. These organizations have also discovered that their continued improvement requires significant changes in the way they manage and develop their people. The People CMM can be coupled with CMM-based software process improvement programs or used on its own to guide improvements in workforce practices or to address strategic human capital objectives.
return to top

What are the plans for People CMM in the coming year?
The People CMM team is migrating to SCAMPI for People CMM Appraisals. Six pilot SCAMPI A appraisals were completed from 2004 to 2006. An interpretive guidance document, Interpreting SCAMPI for a People CMM Appraisal at Tata Consultancy Services has been published and is available on the SEI's Web site at http://www.sei.cmu.edu/publications/documents/05.reports/05sr001.html.
An Intermediate Concepts of the People CMM Course is available to the public. Information about that course and the necessary prerequisites can be found at http://www.sei.cmu.edu/products/courses/a15.html.
A People CMM Instructor Training course is available for those who wish to become SEI-authorized Introduction to People CMM instructors. Information about the course and the prerequisites for taking it can be found at http://www.sei.cmu.edu/products/courses/a18.html.
A SCAMPI for People CMM course will be available in 2007.
return to top

How do I become a People CMM Lead Appraiser?
Organizations that become SEI Partners for SCAMPI (Standard CMMI Appraisal Method for Process Improvement) with People CMM appraisal services can sponsor candidates to become SEI-authorized SCAMPI Lead Appraisers. Candidates who successfully complete the process outlined below will be authorized to train appraisal teams and lead appraisals on behalf of SEI Partner organizations.
Individuals who wish to become Authorized SCAMPI with People CMM Lead Appraisers must meet the following requirements:
ensure that their organizations have applied to become transition partners for SCAMPI appraisal services, have been accepted, and have signed the applicable Carnegie Mellon University/SEI agreement
have a signed Code of Professional Conduct for SEI Services in place
have successfully completed the application process to become an Authorized People CMM SCAMPI Lead Appraiser that consists of
participation as an appraisal team member on at least one SCAMPI A appraisal with People CMM within the prior 24 months
at least ten years of management, human resources, or organizational development experience
a minimum of two years of experience managing technical personnel
an advanced degree in a related management area or equivalent experience
have successfully completed the Introduction to People CMM course
have successfully completed the Intermediate Concepts of People CMM course
have successfully completed the SCAMPI Lead Appraiser Training for People CMM
have successfully been observed leading a SCAMPI Appraisal with People CMM
return to top

How do I get more information about the People CMM?
Direct links to all People CMM products and services can be found at http://www.sei.cmu.edu/cmm-p/version2/. Questions about the Introduction to the People CMM course can be directed to Course Information e-mail: course-info@sei.cmu.edu. Questions about interpreting the People CMM should be directed to Sally Miller, e-mail to sal@sei.cmu.edu. Additionally, the Software Engineering Information Repository (SEIR) contains a People CMM section where users of the model have contributed implementation guidance. You can access the SEIR at https://seir.sei.cmu.edu/seir/.
return to top

My organization is planning an appraisal soon, and we have been guiding our improvement program with Version 1 of the People CMM; can we still conduct the appraisal with version 1?
Appraisals against People CMM version 1 are no longer accepted. All organizations should use version 2 of the model for guiding improvement programs and appraisal because of its improvements and greater consistency with CMMI.
return to top

Why isn't there a continuous representation of People CMM version 2?
People CMM version 2 is only produced in a staged representation. After lengthy review of the literature and experience gathered from implementers on programs to improve workforce practices, the authors determined that these programs often fail when workforce practices are not introduced as a system, but rather are deployed in isolation. For instance, efforts to install empowered teams are likely to fail if compensation practices continue to reward individual performance without recognizing contribution to team performance and team success.
return to top

Will People CMM version 2 be integrated into CMMI?
There are no existing plans to integrate the People CMM into CMMI, either directly or by extensions. Currently, the CMMs that have been integrated in CMMI all concern behavior performed in or on behalf of projects, whereas the People CMM concerns behavior performed regularly throughout the organization. Nevertheless, People CMM Version 2 has adopted some of the advances made in the CMMI Framework and has tried to ensure that People CMM improvement programs would integrate with improvement programs guided by CMMI. Enhancing the focus on process abilities in workforce competencies at maturity level 3 and quantitative performance management practices at maturity level 4 will make integrating these various models much easier.
return to top

How does People CMM version 2 support integrated product development teams?
Because of its inherent subject matter, the People CMM presents a more detailed model for the evolutionary development of workgroups or teams. Nevertheless, the CMMI-DEV+IPPD model and People CMM both focus on process-based workgroup development at maturity level 3, and this was one motivation for creating People CMM version 2. The IPPD materials in CMMI-DEV+IPPD are supported by several process areas in People CMM Version 2 as follows:
Integrated Project Management (IPPD)Specific Goal 3 - Apply IPPD Principles
Competency Analysis (level 3)Communication and Coordination (level 2)Workgroup Development (level 3)
Organization Process Definition (OPD) Specific Goal 2 - Enable IPPD Management
Work Environment (level 2)Communication and Coordination (level 2)Compensation (level 2)Workgroup Development (level 3)Participatory Culture (level 3)Workforce Planning (level 3)Competency Development (level 3)Competency-Based Practices (level 3)
Additional People CMM guidance for integrated product development teams can be found in Competency Integration (level 4), Empowered Workgroups (level 4), and Continuous Capability Improvement (level 5). These are high maturity process areas within a staged model, so care should be taken to ensure that an organization has the proper foundation (maturity level 2 and 3) in place to manage successful implementation.
return to top

Where can I obtain training on the People CMM?
The SEI-authorized Introduction to the People CMM , Intermediate Concepts of the People CMM, People CMM Instructor Training and SCAMPI for People CMM courses are offered by the SEI. For more information on these courses and for a list of scheduled dates, see the SEI Web site at http://www.sei.cmu.edu/products/courses/courses.html#CMM.
The SEI-authorized Introduction to the People CMM course is also available from SEI Partner organizations.
return to top

When will you release People CMM version 3?
Currently there are no plans for a version 3. Version 2 was not released for review until six years after the release of version 1 in 1995. We do not anticipate accelerating the revision cycle unless there is evidence from People CMM improvement programs that significant additions or changes need to be made to the model.
return to top

How do I find an authorized People CMM Lead Appraiser?
The list of SEI-authorized SCAMPI for People CMM Lead Appraisers will appear in the online Partner Directory in November 2006.
The listing of authorized People CMM Lead Assessors who are still using the soon to be sunsetted People CMM Appraisal Method can be found at http://partner-directory.sei.cmu.edu/.
return to top
top

ISO/IEC 15504 FAQ's
http://www.sei.cmu.edu/iso-15504/resources/FAQ.PDF

2006-11-27T06:51:00.000-08:00

http://www.mobotix.nl/Images/software.jpeg

Software companies in india

2006-10-05T00:52:00.000-07:00

http://business.mapsofindia.com/software-companies-india/index.html

SCAMPI

2006-09-26T18:44:00.000-07:00

http://www.sei.cmu.edu/publications/documents/01.reports/01hb001.html

CMMI

2006-02-23T12:36:00.000-08:00

http://www.sei.cmu.edu/cmmi/presentations/euro-sepg-tutorial/

From ISO 9001 to CMM Level 5, a journey
http://www.softwaredioxide.com/Channels/Content/Syntel_Journey_ISO_to_CMM.pdf

Quality certifications for Software Industry
http://jobfunctions.bnet.com/whitepaper.aspx?&tags=TQM%2FSix+Sigma%2FISO+9000&docid=151719

Software Quality Basics
http://www.webizus.com/newsletter/oct02/software-quality.html

Software process assessment and improvement for CMMI
http://www.martinig.ch/ae/process.php

For the record.... - Reader Comment - CIO
KPMG assessed our QMS in accordance with ISO 9000-2000, which mandates external ... Our CMMI Level 5 assessment covers all of our operations in Mumbai, ...comment.cio.com/comments/16677.html - 81k - Cached - Similar pages

Software process development

2006-01-17T20:43:00.000-08:00

http://www.sysmod.com/psp.htm

http://www.bitpipe.com/rlist/term/Software-Quality-Assurance.html

SOFTWARE ENGINEERING STANDARDS
http://www.12207.com/test.htm

ISO 9000: Lessons Learned by Canadian Software Companies
Registration to ISO 9001 certifies that a company's QMS and the ... be kept in mind when searching for consultants, registrars, and information on ISO 9001. ...www.orioncanada.com/Lessons.htm - 32k - Cached - Similar pages

TECH TIPS
http://www.unixwiz.net/techtips/index.html

CONTENT MANAGEMENT SYSTEMS (CMS)
http://en.wikipedia.org/wiki/Content_management_system

SOFTWARE PROJECT MANAGEMENT
http://www.comp.glam.ac.uk/pages/staff/dwfarthi/projman.htm

SOFTWARE DEVELOPMENT METHODOLOGY
http://www.phptr.com/articles/article.asp?p=605374&seqNum=3&rl=1

Software Quality Basics - Monthly Newsletter (October 2002 ...
ISO 9001, the standard in the 9000 series that pertains to software development and maintenance, identifies the minimal requirements for a quality system. ...www.webizus.com/newsletter/oct02/software-quality.html - 27k - Cached - Similar pages

Gap Audit for software companies
http://www.quality.org/ISO9000-3/ISOGapChecklist.pdf

Software quality assurance

Software development process
Activities and steps
Requirements Architecture Design Implementation Testing Deployment
Models
Agile Cleanroom Iterative RAD RUP Spiral Waterfall XP
Supporting disciplines
Configuration management Documentation Software quality assurance (SQA) Project management User experience design

Software Quality Assurance (SQA) consists of a means of monitoring the software engineering processes and methods used to ensure quality. It does this by means of audits of the quality management system under which the software system is created. These audits are backed by one or more standards, usually ISO 9000.

It is distinct from software quality control which includes reviewing requirements documents, and software testing. SQA encompasses the entire software development process, which includes processes such as software design, coding, source code control, code reviews, change management, configuration management, and release management.

Whereas software quality control is a control of products, software quality assurance is a control of processes.
Software quality assurance is related to the practice of quality assurance in product manufacturing.

There are, however, some notable differences between software and a manufactured product. These differences stem from the fact that the manufactured product is physical and can be seen whereas the software product is not visible. Therefore its function, benefit and costs are not as easily measured. What's more, when a manufactured product rolls off the assembly line, it is essentially a complete, finished product, whereas software is never finished. Software lives, grows, evolves, and metamorphoses, unlike its tangible counterparts. Therefore, the processes and methods to manage, monitor, and measure its ongoing quality are as fluid and sometimes elusive as are the defects that they are meant to keep in check.

See also
Software Assurance
Software: Quality control

more

Tantara: Hotlist -- ISO 9001 for software industry (ISO 9000-3 ...
Site Map for software process improvement, SQA, ISO 9000-3, SEI CMM Site Map. Consulting for software process improvement, SQA, ISO 9000-3, SEI CMM, ...www.tantara.ab.ca/iso_list.htm - 24k - Cached - Similar pages
Hotlist: Software process improvement, SQA, ISO 9000-3, SEI CMM ...
Consulting for software process improvement, SQA, ISO 9000-3, SEI CMM, Consulting ... imagine what Tantara can do "in person" (consulting / training ...www.tantara.ab.ca/info.htm - 51k - Cached - Similar pages

tired of reading all this heavy stuff?
go here for some laffs on consultants
http://managementconsultant-tqmcintl.blogspot.com/ ....

tqmcintl Industry: Consulting Location: Mumbai : Maharashtra : India ISO 9001 QMS ISO 13485 ENGINEERING NEWS UP-DATE ISO 22000 Explosion protected not Flame proof WTO CRO ISO TQM Information Security Management and ISO 27001 Software QA ISO 17025 CE Marking ISO 14000 GMP requirements SA 8000 ISO 20000 COBIT COPC STANDARD Lean Six Siqma ISO 17021 5 S Energy Manager boiler and pressure vessels eSCM useful Reference tables ERP Management Consultant hotels and restaurants Fami QS Food borne diseases and infections storing food grains Halal and Kosher wet tissues ready made garmets marking Inspection, measuring and testing equipment

............. UNDER DEVELOPMENT ...............................

Appendix-D
Guidelines* for the application of ISO 9001 : 2000 t
the supply, develoment, installation & maintenance 0
computer software.
4 Quality management system
4.1 General Eequiaements :-
The organisation shall define and manage the processes necessary to ensu: ~ that product and/or service confornls to customer requirements. As a means :implementing and demonstrating the defined processes, the organisation s establish a quality management system covering the requirements of . International Standard. The quality management system shall be impIemen maintained and improved by the organisation.
The Quality Management System of a software-producing organisa ~ should define and manage activities and tasks related' to the following process;;.:
a) The primary life cycle processes of acquisition, supply, developm~ operation and maintenance of software;
b) The organisationallife cycle processes of management, infrastructIr:'e improvement and training;
c) The supporting life cycle processes of documentation, configurati management, verification, validation, joint review, audit and probl resolution, which are needed to implement the primary 2L:_ organisational
;::e cycle processes.
The two primary types of software-producing organisations are:
a) Organisations that develop software in response to specified custo requirements;
ased on ISOllEe 12207; Information technology-software life cycl
. 4 ~ I sotoo-J [D"'tt t161:\O[q J +1\.. tooo..pJ~

161
Training Manual on ISO 9000 : 2000 and TQM
b) Organisations that develop software in anticipation of customer needs.
Actual organisations may be a combination of the two types. Oiganisations that develop software in response to specified customer requirements should include processes that define the customer requirements and track their fulfIlment throughout the software life cycle.
Organisations that develop software in anticipation of a customer should
Include processes that define the software capabilities and control change to the definition throughout the software life cycle. The organisation shall prepare quality management system procedures that
Describe the processes required to implement the quality management system. The range and ex1:ent of the system procedures shall be dependent upon such factors as the size and type of the organisation, the complexity and interaction of the processes, the methods used and the skllls and training of personnel involved in performing the work. This shall include:
a) System level procedures that describe the activities required to implement the quality management system;
b) Procedures that describe the sequence and interactive nature of the processes necessary to ensure the conformity ofthe product and/or servIce;
c) Instructions that describe the operating practice and control of process activities.
A software-producing organisation should define the sequence and interaction ofthe life cycle processes in:
a) Procedures that define life cycle models for development, such as waterfall, incremental and evolutionary;
b) Development plans, which should be based upon a life cycle model.
4.2 Document tion requirements
4.2.1 General
The organisation shall establish a quality management system as a meaIls of meeting its quality policy, achieving its quality objectives and ensuring that the product and/or service conform to customer requirements. No further software-specific guidance is provided.
4.2.2 Quality manual
The organisation shall prepare a quality mannal. The quality manual shall include:
a) A description of the elements of the quality management system and their interaction (and any reduction in scope of this International

Appendix-D
162
Standard.
b) The system level procedures or reference thereto.
NOTE The quality manual need not be a stand alone document. The quality manual may be:
a) A stand alone document or a set of documents;
b) Stored on paper or on computer media. Storage of the quality manual upon computer media offers the following advantages over paper media in most situations:
a) Easeofdocumentprodllction, distribution, access, control, withdrawal and archiving;
b) Reduced cost of production, distribution and archiving;
c) Reduced impact on the environment.
4.2.3 Control of documents
The organisation shall establish quality management system level procedures for controlling documents required for the operation of the quality management system. These procedures shall ensure that:
a) Documents are approved for adequacy prior to release;
b) Documents are reviewed, updated as necessary and re-approved;
c) The relevant versions of docnments are available at locations where activities essential to the effective functioning of the quality management system are performed;
d) Obsolete documents are removed from all points of issue and use, or otherwise controlled to prevent unintended use;
e) Any obsolete documents retained for legal or knowledge-preservation purposes are suitably identified.
A master list or an equivalent document control procedure, identifying the current revision status of documents, shall be established and be readilyavailabl to preclude the use of invalid and/or obsolete documents. Documents shall be legible, readily identifiable and retrievable. Applicable docuinents of externa..origin shall be identified and recorded.
NOTE Documents may be in any form or any type of media.
4.2.4 Control of Records
Quality records appropriate to the organisation shall be maintained t demonstrate conformity to the requirements and the effective operation of the quality management system. The organisation shall establish andmaintain qualir;management system level procedures for theidentification, storage, retrie\-a.i...

163
Training Manual on ISO 9000: 2000 and TQM
,j
protection, retention time, and disposition of quality records,
Organisations developing and maintaining software should retain the following types of quality records:
a) Review records;
b) Test results;
c) Audit reports;
d) Problem reports,
When storing quality records, consideration should be given to:
a) The rate of degradation of the media upon which the records are stored;
b) The availability of the devices aeeded to access the quality records from the media at possible times when retrieval is required,
5 Management responsibility
5.1 Manasement commitment
Top management shall demonstrate its commitment to:
a) Creating and maintaining awareness of the importance to fulfil customer requirements;
b) Establishing the quality policy and the quality objec;tives and planning;
c) Establishing a quality management system;
d) Performing management reviews;
e) Ensuring the availability of resources (see 6),
The quality management system of a software-producing organisation should be established by means of a management process that:
a) Initiates and defines the scope of the quality management system;
b) Plans the execution of each instance of a software life cycle process;
c) Ex~cutes and controls each instance of a software life cycle process;
d) Reviews and evaluates each instance of a software life cycle process:
5.2 Customer Focus
In an organisation that develops software in anticipation of a customer need, top management should ensure that processes are established and enacted to eTJ.sure that information about current, future, explicit and implicit customer needs and expectations is collected, analysed and included in the product requirements, as appropriate, The acquisition process of a customer and the supply process of a software-producing organisation should combine to provide the customer requirements as input to the development and maintenance processes,
Appendix-D
5.3 Quality Policy
Top management shall establish its quality policy and ensure that it:
a) Is appropriate for the needs of the organisation and its customers:
b) Includes commitment to meeting requirements and continua.improvement;
c) Provides a framework for establishing and reviewing quali _ objectives;
d) Is communicated, understood and implemented throughout th;o.organisation;
e) Is reviewed for continuing suitability.
5.4 Planning
5.4.1 Objectives
The organisation shall establish quality objectives at each relevant functio and level within the organisation. The quality objectives shall
Be consistent with the quality policy and the commitment to contin improvement. Quality objectives shall include those needed to meerequirements for produ~ts andlor services.
For software, possible top-level quality objectives are:
a) Conformity to customer requirements;
b) Conformity to product requirements;
c) Conformity to system requirements;
d) Conformity to acceptance criteria.
For software, lower-level quality objectives should be defined based the quality characteristics of the software product. Examples of such qualJ-:objectives, with their associated quality characteristics in parentheses. are
a) A specified mean time between failures (reliability);
b) A specified number of defects per thousand lines of code (reliabilI-:
c) A specified number of discrete operations required to accomp task (usability);
d) COnfOffility to a progranlming language standard (portability):
e) Specified limits on the amount of computer hardware reSO\l;__ required to execute the software (efficiency);
f) A specified mean time to repair (maintainability);
g) A specified time to maximum time to rebuild the software aft change to the source code has been made (maintainability)".

165
Training Manual on ISO 9000 : 2000 and TQM
5.4.2 Quality planning
For a software-producing organisation, quality planning occurs at two levels:
a) The organisationallevel
b) The project level.
Software quality planning at the organisationallevel should result in quality system procedures and instructions.
For software, such quality system procedures and instructions should include:
a) Descriptions of software life cycle models to be used for the types of projects that the organisation undertakes;
b) Descriptions of how the organisation normally implements software life cycle processes;
c) Descriptions of the contents of software products, such as software requirements documents, architectural design documents, detailed design documents, source code headers and software user manuals;
d) Descriptions of the contents of software management plans, such as software project management plans, software configuration management plans, software verification and validation plans and software quality assurance plans;
e) Descriptions of how software engineering methods are tailored for the organisation's projects;
f) Descriptions of conventions for the use of programming languages,
software libraries and frameworks.
Software quality planning at the project level should result in a description of how specific products are to be developed or maintained. In contrast, software devel.opment planning should result in a definition of what products are to be produced, who is to produce them, and when they are to be produced.
Software quality planning at the project level should:
a) Identify the quality requirements for the product and/or service;
b) IdentifY the quality system procedures and instructions to be used;
c) Tailor the quality system procedures and instructions to the project by adding, deleting or modifYing material;
d) Define product-specific procedures and instructions, such as software test specifications detailing test plans, tests designs, test cases and test procedures;

Appendix-D
e) Specify methods, tools, programming language conventions, librane5 and franleworks to be used in the project;
f) Identify who is responsible for approving the outputs ofproces es for subsequent use.
Software project quality requirements should be stated as:
a) Product quality objectives;
b) Process requirements, such as the use of software inspections ~ independent testing.
The exit criteria for processes, such as inspections and testing, sho include product quality objectives such "no defects detected" and "all t passed".
Software quality planning should also define the measurement, monitorin.:. analysis and improvement processes to be used by the organisation or proj ~ Quality planning should define the type, location, timing and frequency :measurements and the requirements for records of the measurement, monito - _ analysis and improvement processes.
5.5 Responsibility authority & communication.
5.5.1 Responsibility and authority
Roles and their interrelations, responsibilities and authorities shall defined in order to facilitate effective quality management and shah communicated to relevant levels ofthe organisation. Organisational freeCJ:~ necessary to perform tasks that affect quality shall be defined. No fur.:software-specific guidance is provided.
5.5.2 Management representative
Top management shall appoint member( s) of the management irrespective of other responsibilities, shall have defined authority that in
a) Ensuring that a quality management system is implemented and maintained in accordance with the requirements of this Internan.Standard;
b) Reporting to top management on the performance of the management system, including needs for improvement;
c) Ensuring awareness of customer requirements througho organisation.
NOTE The responsibility of a management representative normally' liaison with external parties on matters relating to the ~ management system.
5.5.3 Internal Communication

167
Training Manual on ISO 9000 : 2000 and TQM
The organisation shall establish and maintain procedures for internal communication between the various levels and functions regarding the qualio/ management system and its effectiveness.
5.6 Management review
The organisation shall establish a quality management system level procedure for management review. Top management, at intervals it determines, shall review the quality management system to ensure its continuing suitability, adequacy and effectiveness. The review shall evaluate the need for changes to the organisation's quality management system, including policy and objectives.Management review shall include periodic review of current performance and improvement opportunities related to:
a) Results of audits;
b) Customer feedback;
c) Process perfornlance and product conformity analyses;
d) Status of preventive and corrective actions;
e) Follow-up actions from earlier management reviews;
f) Changing circumstances. The outputs from the management review shall be actions related to:
g) Improvement of the quality management system;
h) Process, product and/or service audits;
i) Resource needs. Results of management reviews shall be recorded.
The results of software process assessments should be considered at Management Reviews.
6 Resource Management
6.1 Provision of Resources
The organisation shall determine and provide in a timely manner, the resources needed to establish and maintain the quality management system.
6.2 Human resources
6.2.1 General
The organisation shall assign personnel to ensure that those who have responsibilities defined in the quality management system are competent on the basis of applicable education, training, skills and experience.
6.2.2 Competence, awareness and training.
The organisation shall establish and maintain system level procedures to:
a) Determine competency and training needs;

Appendix-D
b) Provide training to address identified needs;
c) Evaluate the effectiveness of training at defined intervals;
d) Maintain appropriate records of education, training, skills, and expenence.
The organisation shall establish and maintain procedures to make its employees at each relevant function and level aware of:
a) The importance of confonnity with the quality policy, and with therequirements of the quality management system;
b) The significant impact of their work activities on quality, actual or potential;
c) The benefits of improved personal performance;
d) Their roles and responsibilities in achieving conformity with the quality policy and procedures and with the requirements of the quality management system;
e) The potential consequences of departure from specified procedures. A software-producing organisation should establish a training process that ensures the continual capability of its staff.
6.3 Infrastructure
The organisation shall define, provide and maintain the infrastructure needed to achieve the confonnity of product and/or service. This shall include:
a) Workspace and associated facilities;
b) Equipment, hardware and software;
c) Suitable maintenance;
d) Supporting services.
The infrastructure should include hardware, software, tools, techniques. standards, and facilities for development, operation, or maintenance. At minimum, the infrastructure should contain software tools that:
a) Enable the creation of documents and source code;
b) Convert source code to executable code.
The probability of inserting defects into software can be reduced by use of tools that:
a) Detect software defects, such as non-confonnities to programmin= language rules;
b) Measure software metrics, such as cyc10matic complexity and t ::coverage, that can be used to estimate the number of defects p
c) Enable the version history of a software item to be traced;
168

169
Training Manual on ISO 9000 : 2000 and TQM
d) Enab~e source code to be traced to its design;
e) Enabl~ designs to be traced to requirements; 'tt
f) Enable the accessibility, security and integrity of software items to be preserved.
6.4 Work environment
The organisation shall define and implement those human and physical factors of the work environment needed to achieve conformity of product and/ or service. This shall include:
a) Health and safety conditions;b) Work methods;c) Work ethics;d) Ambient working conditions.
The following aspects should be considered for people developing or maintaining software:
a) Concerning work ethics, the probability of introducing non-conformity into software is reduced by the adoption of a culture that encourages the people to check their own work products and that of their colleagues for errors before they are input to the next stage of a development or maintenance process;
b) Concerning ambient working conditions, Lhe probability of introducing non-conformity into software increases with the background noise level and the frequency of interruption.
7 Product Realization
1'\\4Y\o..~C o~ 'o~ ~hA--'J~.7.1 Planning ...:J.J I I\Jl..1 r - ~
Processes that are necessary to realize the required product and/or service and their sequence and interaction shall be determined, planned and implemented. In determining such processes, the organisation shall consider the outputs from quality planning (see 5.4).
In a software-producing organisation, the following software life cycle processes defined in I~O/IEC 12207:1995 should be tailored to realise the required product and/or service:
a) Development process, which defines the activities of an organisation that defines and develops the software product;
b) Operation process, which defines the activities of an organisation that provides the service of operating a computer system in its live environment for its users;
c) Maintenance process, which defines the activities of an organisation

Appendix-D
that provides the service of maintaining the software product; that is, managing modifications to the software product to keep it current and in operational fitness;
d) Documentation process, which defines the activities for recording the infomlation produced by a life cycle process;
e) Configuration management process, which defines the activities that identify, define, and baseline software items in a system; control modifications and releases of the items; record and report the status of the items and modification requests; ensure the completeness, consistency, and correctness of the items; and control storage handling, and delivery of the items;
f) Quality assurance process, which defines the activities, such as joint reviews, audits, verification and validation, for objectively assuring that the software products and processes are in conformity with their specified requirements and adhere to their established plans;
g) Verification process, which defines the activities for determining whether the software products of an activity fulfil the requirements or conditions imposed on them in the previous activities;
h) Validation process, which defines the activities for detemrining whether the requirements and the final, as-built system or software product fulfils its specific intended use;
i) Joint review process, which defines the activities for a multi-party evaluation of the status and product of an activity.
The organisation shall ensure these processes are operated under controlled conditions and produce outputs that meet customer requirements.
Methods and practices relevant to the consistent operation of software life cycle processes are:
a) Methods for software development that describe the techniques for software requirements analysis, softwa:e design, software inspection and software testing;
b) Practices defining how software development tools are to be used to support methods.
The criteria and methods to control processes needed to achieve produ and/or service conformity with the customer requirements should include:
a) Entry and exit criteria for each activity that are based upon metri ~m software quality characteristics1e.g. an exit criterion for the coding activity might be that the number oflines of code does not exceed a specified limit);
170

171
Training Manual on ISO 9000 : 2000 and TQM
b) Methods for the measurement of the software product or services attributes that are needed to verify conformity to the criteria (e.g. an attribute of a source code module might be the number of lines of code; methods need to be defined for counting number of lines of code in the selected programming language).
7.2 Customer-related Processes
7.2.1 Determination of Requirements Related to Product.
This process shall determine the :
a) Completeness of the customer's product and/or service requirements;
b) Requirements not specified by the customer but necessary for fitnessfor purpose; _____~ S to- t tA. h~ A R.er;!:.;;.c) Obligations related to product and/or service, including regulatory and legal requirements; --"'? ':r,-r A c-I.(, fn.,erL /)0>' k) .
d) Customer requirements for availability, delivery and support of product and/or service.
The acquisition process of a customer and the supply-process of a softwareproducing organisation should combine to provide the customer requirements as input to the development and maintenance processes.
The process for identifying the customer requirements should:
a) Include activities for capturing customer requirements, such as interviews, surveys, workshops and prototyping;
b) Define ror each customer requirement:
1. A unique identifier, to facilitate tracing of the implementation of the requirement during the development process;
11. A description of a capability required of the software or a constraint that applies to the software;
ill. The level of need, to indicate whether implementation the requirement is essential for the product or service to be acceptable;
IV. The priority of the requirement, to indicate in which release of the software the requirement must be implemented.
The customer requirements are the primary inputs to the development process, and the level of detail of the customer requirements should be sufficient for:
a) Controlling the development process;
b) The effective use of analysis and design techniques needed during development.

Appendix-D
7.2.2 Review of Requirements Releted to the Product.
The customer requirements, including any requested changes, shall be reviewed before a commitment to supply a product and/or service is provided to the customer (e. g. submission of a tender, acceptance of a contract or order) to ensure that:
a) Customer requirements are clearly defined for product and/or service;
b) Where the customer provides no written statement of requirement, the customer requirements are confirmed before acceptance;
c) Contract or order requirements differing from those previously expressed, e.g. in a tender or quotation, are resolved;
d) The organisation has the ability to meet the customer requirements for the product and/or service. The results of the review and subsequent follow-up actions shall be recorded.
When the product/or service includes computer software, the process for reviewing the customer requirements should:
a) Identify the required software quality characteristics (functionality, reliability, usability, maintainability, portability and efficiency);
b) Establish the verifiability of the required software quality characteristics;
c) Relate the acceptance criteria to the required software quality characteristics;
d) identify applicable regulatory and legal requirements;
e) identify applicable environmental requirements;
f) include joint reviews with the customer.
7.2.3 Customer communication
A software-producing organisation should communicate product and service information in the form of:
a) Interim products of the development and maintenance processes, such as design documents;
b) Demonstrations of interim products of the development and maintenance processes, such as prototypes;
c) Reports on the progress of the development project;
d) Reports on the performance of the product or service.
The joint review process should be used to get information from the customer about interim products, demonstrators and reports.
172

173
Training Manual on ISO 9000 : 2000 and TQM
p~J~«- ~6~~~Po'1l: ~
l! f
7.3. Design and Development 7.3.1 Design & Development Planning
In software engineering, design is a development activity, and therefore this clause refers to 'development' instead of 'design and/or development'.The software development plan may be defined by:
I) Identifying the components of the product or service that need to be developed;
2) Identifying software life cycle activities that are needed to produce the components of the product or service;
3) Estimating the resources and duration of the activities needed to produce the components of the product or service;
4) Constructing the network of activities, by taking account of the dependencies between the components;
5) Assigning resources, start and end time to each activity.
An alternative approach to steps (1) and (2) above is to select a software life cycle model that is suitable for the project and to use itas the framework for defining the components and activities. Example software life cycle models are:
ri
r]
a) Waterfall;
b) Incremental;
c) Evolutionary.
Stages of the software development plan may be identified by milestones, each of which marks significant progress in the development. Example milestones are:
a) Hhe approval of the customer requirements document;
b) The approval of the software requirements document;
c) The approval of the architectural design document;
d) The approval of the detailed design document;
e) The successful completion of unit tests;
f) The successful completion of integration tests;
g) The successful completion of qualification tests;
h) Acceptance of the software.
The software life cycle model may define stages and milestones. The software development plan may include the following review, verification and validation activities:
a) Inspections of the software requirements document;

Appendix-D
174
b) Joint review of the software requirements document with the customer,
c) Inspections of the architectural design document;
d) Demonstrations of prototypes;
e) Tracing of requirements to design and vice-versa;
f) J oint review of the architectural design document with the customer;
g) Inspections of the detailed design document;
h) Inspections of the source code;
i) Formal proof of the correctness of code;
j) Unit tests, i.e. standalone tests of software components;
k) Integration tests, i. e. tests of aggregations of software components;
1) Qualification tests, i. e. tests of the complete software product prior to delivery;
m) Acceptance tests, i.e. tests of the complete software product after delivery.
A software-producing organisation should include within the software development plan:
a) Definitions of quantities that will be used to measure progress against cost, schedule and quality goals;
b) The initial list of risks that have been identified, with estimates of the residual risk after planning Risks that should be considered in software development are:
c) Low capabilities of the organisation or its suppliers;
d) Low accuracy of the estimates of resources and duration required for each activity;
e) Significant differences betw~en the times that delivery of products or services are required and the times that results from optimising plans to meet cost and quality goals;
f) Significant geographical dispersion of the organisation, customers and suppliers;
g) High technical novelty, including novel methods, tools and supplied software;
h) Low quality or availability of supplied software and tools;
i) Low precision, accuracy and stability of the definition of the customer requirements and external interfaces.
A software-producing organisation should control development (including design) of a product or service by:

175
Training Manual on ISO 9000: 2000 and TQM
a) Reviewing and agreeing the development plan before development starts;
b) continuously monitoring and regularly reporting on progress-towards cost, schedule and quality goals;
c) continuously monitoring for risks to the project and taking appropriate action (i.e. contingency planning, pre-emptive action).
7.3.2 Design and Development Inputs
The software-producing organisation should perform software requirements analysis upon the design and development inputs with the objective of producing a complete and consistent software requirements specification that defines the:r---a) Functional requirements;
b)· Reliability requirements;
c) Usability requirements;
d) Maintainability requirements;
e) Portability requirements;
f) Efficiency requirements.
Software requirements analysis should be performed using software engineering methods and tools. Environmental requirements define the permitted impact of the product or service on a third party. An environmental requirement may also be a legal or regulatory requirement. Examples of environmental requirements for computer software are:
a) The software must be free of computer viruses;
b) Normal operation of the software must not result in accidental damage to people or property;
c) After a software failure, the behaviour of the software must not result in accidental damage to people or property.
An organisation should always produce software that is free of computer viruses. The organisation should operate systems to prevent the spread of computer viruses.
An organisation should never produce software that results in accidental danlage to people or property, including after a software failure. When customer requires a system containing hardware, software and people, the organisation should perform the following activities before software requirements analysis:
a) System requirements analysis, which should transform the customer requirements into a complete and consistent system requirements specification;
b) System architectural design, which should result in a feasible system
~,

Appendix-D
176
architectural design that implements all the system requirements.
In system architectural design, system requirements are allocated to hardware, software components and manual operations. The inputs to software requirements analysis are:
a) The system requirements allocated to software;
b) Specifications of the interfaces between the system components.
7.3.3 Design and development outputs
Software development outputs may include:
a) Architectural design specifications; ~
b) Detailed design specifications;
c) Source code;
d) Executable code;
e) Guides for installation, operation and maintenance;
o Software test specifications.
A software product should consist of one or more of the above software development outputs. A software product delivered to a customer for operational use should as minimum, contain:
a) Verified and validated executable code;
b) A guide to the installation and operation of the software.
A software-producing organisation should perform the following activities to produce the development outputs:
a) Software architectural design;
b) Software detailed design:. .--51c) Software coding and testing;-d) Software integration.
A software-producing organisation should produce development outputs using methods and tools that have been validated and approved for the application. Techniques for valicating methods and tools include:
a) Successful application by the organisation for a similar software product and/or service;
b) Successful outcome of proto typing the product and/or service;
c) Research of methods and tools used for producing similar products and/or services.
Software test specifications should contain, or refer to, the product and/or service acceptance criteria.

177
Training Manual on ISO 9000 : 2000 and TQM
Software design specifications and user guides should define the characteristics of the product and/or service that are essential to its s,afe and proper use.
The organisation should verifY each software specification or component before approving it for release to the customer or for use in subsequent development and maintenance activities. i H-- i
Software development reviews should include:
a) Architecturaldesignrevie~lV
b) Detailed design review; --
c) Source code review; () -d) Review of software test specifications; 2C)v-b e) Rser guides review.
Members of the development team should review and agree:
a) The architectural design, before starting detailed design;
b) Detailed designs of assemblies of software components, before the source code is written;
c) The source code and software test specifications, prior to testing;
d) User guides, prior to delivery of the software.
An architectural design review and user guide review may be performed jointly with the customer.
Software review techniques include, in order of increasing rigour:
a) Peer review;
b) Walkthrough;,
c) Inspection.
The software reliability requirements should be considered when selecting software review techniques and allocating resources to software review activities.
7.3.5 Design and development verification
Design and/or development verification shall be plann~d and performed to ensure the output meets the input requirements. The results ofthe verification and subsequent follow-up actions shall be recorded.
The following software development outputs should be verified:
a) Requirements;,
b) Design;

Appendix-D
178
c) Code;
d) The software product at each stage of integration;
e) Documentation.
Development outputs should be demonstrated to meet the development input requirements by one or more ofthe following verification techniques:
a) Review (i.e. peer review, walkthrough, inspection);'-b) Tracing of software requirements to software components and viceversa;
c) Formal proof of correctness of the development output;
d) Test, for example:
1. Unit tests of a software component to verify that it meets its detailed design specification;
11. Integration tests of an aggregate of software components to verify that it meet its architectural design specification;
l1l. Qualification tests of a software product to verifY that it meets its software requirements specification.
The record of any non-conformity in the software detected during verification should:
a) IdentifY the input requirement that has not been met;
b) IdentifY the software compollent, or part of that is non-conformant;
c) Describe the nature of the non-conformity, such as the error in a document or source code module, or the behaviour of executable code.
7.3.6 Design and development validation
Before delivery and installation of the software, the software development organisation should performed software validation:
a) Tracing customer requirements to software requirements and \ice-versa; v~·c£..;t.:.~ vi ~
b) Joint reviews of the software requirements with the customer;
c) Joint reviews of the software architecturaJ:desig~ with the customer.
d) Demonstrations of prototypes to the customer;. .e) Simulating acceptance tests in qualification testing.
After delivery and installation of the software, the customer should perfo software validation by conducting acceptance tests of the software. Where feasible, the acceptance tests should be performed before the software is rn.aC= available for operational use. However, some acceptance tests, such as th =~

179
Training Manual on ISO 9000 : 2000 and TQM
required to demonstrate reliability, may require operational use of the sofuvare.
7.3.7 Control of Design & Develupment Changes.
In software engineering, control of design change is a configuration management activity. Design change may occur in both software development and software maintenance.
The organisation should establish and maintain procedures for controlling design changes, which may arise at any time during the software product life cycle, in order to:
a) Document and justify the change;
b) Evaluate the consequences of any change;
c) Approve or disapprove the change;
d) Implement and verifY the change.
Control of design change should be performed upon each software specification or component that has been approved for use in subsequent development and maintenance activities or for release to the customer.
Changes to a software specification or component should maintain consistency between requirements specifications, design specifications, code, tests specifications and user manuals.
Tests to verify or validate that the capabilities of the software have not been reduced by a change are called "regressions tests". Regressions tests of software should always be performed when the interface to a software component has been changed, with objective of verifying that all the components that use the modified component still function correctly. - f> h..G ~- tt.....t;,
7.4 Purchasing . - j}e-t.::.~ .''V - At <-.v,. s o...t", lJ1'r->f7.4.1 Purchasing Process ~4.'"l..b Nt 1)v./1.~oJyt ~. -- fJh'·u.
In developing and maintaining software products, purchased products mayinclude' . t " ~ t-. ~ ~~~~~a) Commercial off-the-shelf software; A-~~ d.A- ~ .f\t>-t ~ .' Vb) Software acquired free from a third party;
c) Tools for the development and maintenance of the software product;
d) Training courses and materials.
Considering that products (b), (c) and (d) may be obtained without a financial transaction, the term "acquisition" is preferred to "purchasing".
A software development or maintenance organisation should implement procedures for the acquisition of software products and services.i V-e:f\d D 11. ~co n.di:I, ~ M. <'V~ ck..-f-o t\.. , . .1\ b 11 ()NIN-O J<. ,{.l r . f- LA. ~ t t- (~ ~+>U'c..'I.' 1.1 J-.c.')b ~ i'\,.b .

Appendix-D
7A.2 Purchasing information
Purchasing documents shall contaffi information clearly descnbing the product and/or service ordered, including where appropriate:
a) Requirements for approval or qualification of product and/or service.procedures, processes, equipment and personnel;
b) Any management system requirements. The organisation shall ensure the adequacy of purchasing documents for the specification of requirements prior to release.
When acquiring software products and services, the organisation is acting in the role of the customer, and the guidance on requirements specification provided in clauses 7.2 and 7.3.2 should be considered.
7.4.3 Verification of purchased product
The organisation shall determine and implement the arrangements necessary for verification of purchased product and/or service.
Where the organisation or its customer proposes to perform verificati activities at the supplier's premises, the organisation shall specify the required verification arrangements and method of product and/or service release in the purchasing documents.
When acquiring software products and services, the organisation is acting in the role of the customer, and the guidance on verification and validati provided in clauses 7.3.5 and 7.3.6 should be considered.
7.5 Production and service Prsvision
7.5.1 Control of Production & Service Provision
A software-producing organisation should plan and control producti operations by: .
a) Specifying the version of the software product or software compo to be released;
b) Defining procedures for the replication of the software;
c) Providing equipment that exactly reproduces the software;
d) Defining procedures for the packaging, including labelling, of a ~ of the software;
e) Providing equipment for packaging the software;
f) Defining procedures for the delivery of a copy of the software packa.::
Replication of software may involve:
a) Copying the master copy of the software product to distnbution
180

181
Training Manual on ISO 9000 : 2000 and TQM
b) Copying the master copy of the software product to the customer's computer by means of a computer network.
The software product may include a copy of the legal agreement (i.e.license) for the use of the product.
A software-producing organisation should plan and control service operations by:
a) Establishing a software operations process;
b) Establishing a software maintenance process;
c) Producing a plan for the organisation, work breakdown and schedule of operations and maintenance activities;
d) producing a quality plan for software operations and maintenance activities (see 5.4.2).
Software maintenance includes the following tasks:
a) Diagnosis of problems;
b) Design and implementation of:
1. Changes that correct problems and prevent future occurrences of similar or related problems;
11. Interface modifications, which maybe required when additions or changes are made to the hardware or software that the software product controls or exchanges data with;
111. Enhancements, such as additional functions or performance improvements.
Major interface modifications and enhancements to the software should be implemented using the software development process instead of the software maintenance process.
7.5.2 Validation of Processes for Production & Service Provision
Any software development production and/or service processes where the resulting output cannot be readily or economically verified by subsequent monitoring, inspection and/or testing should not be used in software development, production or servicing. Alternative software development production and/or service processes where the resulting output can be readily 0f economically verified by subsequent monitoring, inspection and/or testing should be used.
7.5.3 Identification and traceability
A software-producing organisation should establish procedures for identifying software products during development, production and servicing.
Appendix-D
182
Considering that the interaction or software items affects the conformity of a software product with customer requirements, a software-producing organisation should establish procedures for identifying the constituent software items of a software product during development, production and servicing.
Software items that should be identified include:
a) Requirements;
b) Documents;
c) Software components;
d) Test cases;
e) Development tools;
f) Records, e.g.:
1. Verification and validation records;
11. Problem reports;
11I. Change proposals.
Traceability is a requirement that is necessary for fitness for purpose (see clause 72.1). A software-producing organisation should control and record the unique identification of product and/or service by means of a configuration management system that provides for:
a) Configuration identification;
b) Configuration control;
c) Configuration status accounting;
d) Configuration evaluation;
e) Release management and delivery.
The configuration id~ntification information should include:
a) The name of each software item;
b) The version of each software item;
c) The type of each software item;
d) The version of each software item within a version of a software
product (therefore defining the configuration of a software product). The configuration control information should include:
a) The details of problem5 reported upon, or changes proposed to, a software item or software product;
b) The person or persons with the authority to decide upon actions to problems or changes to each software item or software product;

183
,d, mJ :n Ib ria :b d, 01
Training Manual on ISO 9000 : 2000 and TQM
c) The person or persons with the authority to decide on changes to the verification and validation status of each software-item or software product.
The configuration status accounting information should include the status of all changes proposed for a software item or a software product.
The configuration evaluation information should include the verification and validation status (e.g. successfully reviewed, unit tested, integration tested, qualification tested, or accepted) of each software item and software product.
The release management and delivery information should include the version of the software product and details of changes since the last release.
7.5.4 Customer property C~~)
The organisation shall exercise care with customer property while it is under the organisation's supervision or being used by the organisation. The organisation shall ensure identification, verification, storage and maintenance of customer property provided for use or incorporation. Any customer property that is lost, damaged or otherwise found to be unsuitable for use shall be recorded and reported to the customer.
A software-producing organisation should validate software products provided by the customer for use either as part of the software product or as tools for developing the product. Validation should be performed before use of the customer-supplied software product by:
a) VerifYing the identity of the product;
b) Integration testing of a product component;c) Testing of a customer-supplied tool against its specification or user manual.
A software-producing organisation should establish procedures for identifying and storing software products provided by the customer during development, production and servicing. The procedures should be part of the configuration management system for the product.
7.5.5 Preservation of Product
at u~ In
n~ l[
JO el
,k
ar 0),.1 1 it
r'<>)(nl Ii Ie h
b
D j
The organisation shall ensure that during internal processing and final delivery of product and/or service to the intended destination that the identification, packaging, storage, preservation, and handling do not affect confornlity with product andlor service requirements.
A software-producing organisation should ensure that its software products are not altered between the point of production and the point of delivery.
Software product identification information should be preserved to ensure traceability. In particular: . liJ.ft_ ~l~"':l ~d../ &-if - (j5~t~. ~~j u ".-j~' \) I. . Ire , fo,,<-cM.-i' ""i -0~6' V " rw 1 pfto ~'-"'J 0 Appendix-D 184 a) The labelling of any media used for storing the software shoufd be resistant to alteration; b) The software product identification information available at run-time should not be alterable. Software products should be unchanged during handling, packaging, storage and delivery. Delivery of software may be achieved by physical movement of media containing software, or by electronic transmission. The following risks to conformity should be considered and appropriate actions taken when handling, packaging, storing or delivering software: a) Deterioration of the media upon which the software is stored; b) The effects of compression and decompression techniques, if used; c) The effects of encryption and decryption techniques, if used; d) Alteration of contents by computer virus or electromagnetic fields. Concerning handling, packaging and storage, the configuration management system should include procedures for: a) Storing versions of software products according to their verification and approval status; b) Controlling access to the software items; c) Controlling the access to and retrieval of the software items; d) Releasing software; e) Regular backup of the software; f) Storage of copies in separate locations, so that a disaster does not result in total loss of the software product. Sets of software items with the same verification and approval status are known as "baselines". Software releases should be accompanied by release notes that identify the version of the software, changes made since the last release, and any user information not already in the user documentation. 7.6 Control of measuring and monitoring devices Software used for verification of specified requirements shall be validated prior to use, and in addition, special purpose software developed specifically to test a product, shall meet the applicable req~or the development of product, as stated iIJ. clause 7.3 of this International Standard. Measuring and monitoring devices used in software development, maintenance and operation include: 185 Training Manual on ISO 9000 : 2000 and TQM a) Additional software, which is not part of the software design, that is used for testing the software product; b) Data used for testing the software product; c) Software tools used for collecting performance, resource utilisation and coverage information; d) Computer hardware; e) Instrumentation interfacing to the computer hardware. Computer hardware and instrumentation devices used in software development, maintenance and operation may require calibration (e.g. the clock of the computer may need to be calibrated against a standard clock). The organisation should control and maintain software measuring and monitoring devices used in software development and maintenance by means of the software configuration management system (see 7.5.2 and ISO/IEC 12207: 1995 clause 6.2). A configuration management system should al~o be used for the computer hardware and instrumentation. 8 Measurement, analysis and improvement 8.1 General guidance To ensure that the quality management system and processes conform to requirements, a software-producing organisation should: a) Monitor and measure the conformity of products and/or services to quality requirements by means of review, verification and validation processes (see 7.3.4, 7.3.5 and 7.3.6); b) Monitor and measure customer satisfaction with products and/or services to check that the quality management system is achieving its objectives; . c) Conduct a programme of audits to check that the quality management system procedures are followed; d) Conduct a programme of software process assessments to identify process improvements that increase the degree of conformity to requirements. ( ~ S('(j ~ -l:-oo(1) C'___ b...t>.- 4 l.,V\A..L J
The measurement, monitoring, analysis and improvement processes, and .the type, location, timing and frequency of measurements and the requirements for records, should be identified as part of the quality planning (see 5.4.2). In software engineering, measurable characteristics of products, services and processes are called "metrics".
Types of software product metrics include:
a) Testability;

Appendix-D
186
b) Usability;
c) Reliability;
d) Maintainability;
e) Availability.
Types of software process metrics include:
a) Process maturity;
b) _ Number and types of defects in process outputs;
c) Defect removal efficiency;
d) Milestone slippage.
The effectiveness of metrics should be evaluated by estimating their capability: '
a) To predict customer satisfaction with the product and/or service, or;
b) To report the probable number of defects present in the product, or;
c) To report the degree of progress towards cost, schedule and quality objectives.
When the size and complexity of a software product implies that complete verification that a software product meets its requirements is not economically practical, statistical techniques should be used to estimate the:
a) The proportion of software product parts that need to be processed by each verification activity (e.g. the proportion of lines of code that should be covered in testing, the proportion of code that should be inspected);
b) The number of outstanding defects in the software product after each stage of verification (e.g. the number of defects per hundred lines of code after qualification testing). Statistical techniques may also be used to estimate the reliability and maintainability of the software product from data collected during development, operations and maintenance (e.g. mean time between failure, mean to time to repair).
8.2 Measurement and monitoring ). J ~ ~.h,.,,J- 6hd..e-v..8.2.1 Customer satisfaction ( ~'b' ) ~ b " -' 'r-
The organisation shall monitor information on customer satisfaction and/ or dissatisfaction. The methods and measures for obtaining and utilizing such infoffilation and data shall be defined. -
A software development and maintenance organisation should evaluate customer satisfaction by analysing: , . .J.1) .
Nt o~ {1:>tto1'(j (;.M ~ ~ 5.vt,Vl b~-hcYI ·l YIP t ~

187
Training Manual on ISO 9000 : 2000 and TQM
a) All non-conformities detected by customers during development, operation and maintenance;
b) All complaints received from customers during development, operation and maintenance;
c) All expressions of satisfaction with the software product and/or service;
d) The costs and benefits of the software product and/or service to customers.
Note that:
a) All non-conformities are complaints, but not all complaints are related to non-conformities;
b) A complaint is an expression of dissatisfaction;
c) Analysis of non-conformities and complaints should identify the number, type and severity of each non-conformity or complaint;
d) The methods and measures for obtaining and utilizing such information and data should be defined in the quality plan.
8.2.2 Internal audit ( / ~d r <:k...vl ~ wo.Ml.) ~ ~ f- 4u/-l vl7-) I The organisation shall carry out objective audits in order to determine if the quality management system has been effectively implemented and maintained and conforms to this International Standard. In addition, the organisation may carry out audits to identifY potential opportunities for improvement. The audit process, including the schedule, shall be based on the status and importance of the activities and/or areas to be audited and the results of previous audits. I The system level procedure for internal audit shall cover the audit scope, frequency and methodologies, as wen as the responsibilities, requirements for conducting audits, recording and reporting results to management. Audits shall be performed by personnel other than those who performed the work being audited. When software development and maintenance work is organized into projects, the audit schedule should define a selection of projects to be audited.To ensure that the whole quality management system is audited, the audit schedule may include projects at different stages of their life cycle, or may include audits of the same project at different stages of the life cycle, or both. 8.2.3 Measurement and monitoring of processes The organisation shall apply suitable methods for measurement and monitoring of processes necessary to meet customer requirements and to Appendix-D 188 demonstrate the process's continuing ability to satisfY its intended purpose. Measurement resu Its shall be used to maintain and/or improve those processes. To measure and monitor processes necessary to meet custoriler requirements and demonstrate the processes' continuing ability to satisfY its intended purpose, a software-producing organisation should: a) Establish and operate an improvement process (see ISO/IEe 12207: 1995; b) Perform internal audits; c) Perform software process assessments.~ 8.2.4 Measurement and monitoring of product and/or service A software-producing organisation should apply the following methods for monitoring of the characteristics of the product and/or service to verifY that requirements for the product and/or service are met: a) Design and development review (see 7.3.4); b) Design and development verification (see 7.3.5); c) Design and development validation (see 7.3.6); d) Customer satisfaction monitoring (see 8.2.1); Measurements of characteristics of the product and/or service should be collected during the monitoring activities (see 8.1). , (.J;;;: <>