The document discusses software documentation and quality assurance techniques. It provides details on various types of software documentation like requirements specification, design documentation, test documentation, standards and metrics. It also summarizes key quality assurance techniques like reviews, testing, modeling and their types. Specific techniques like inspections and audits are explained in detail with roles and procedures.

1. UNIT- IV

2. • Software Documentation
Mr. M. E. Patil
S.S.B.T COET, Bambhori

3. Software Documentation
• Identifies all relevant documentation which
concerns development, verification,
validation, use and maintainance of the
software.
• It states how documents will be checked for
accuracy and describes criteria for document
distribution.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

4. Documentation
Documentation is often seriously neglected by software programmers.
Many projects and companies have failed due to poor quality
documentation.
If you find your programmer does not, or will not, document their
software, then it is best to get rid of them now.
If the software is undocumented and they leave, the only option is to start
again and rewrite it all.
Picking up the pieces of poorly documented software is a very expensive
and a time consuming exercise, it’s cheaper to start from scratch.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

5. Reasons to document
• 1) So that you can understand the software
• 2) So that the software can be understood by other people
• 3) So that advanced projects can be undertaken
• 4) So that you can use parts of the code for other projects
• 5) To make life easier for your self
Mr. M. E. Patil
S.S.B.T COET, Bambhori

6. IEEE std 730, A minimum Documentation
must include
• Software Requirement Specification (SRS)
• Software Design Description.
• Software verification and validation plan (SVVP)
• Software verification and validation report. (SVVR)
• User documentation
• Software configuration management plan.
• Software test plan.
• Software test report
Mr. M. E. Patil
S.S.B.T COET, Bambhori

7. Software Requirement Specification (SRS)
• Describe the capabilities, states and functionality of
all aspects of the system
• This includes major components, subcomponents
and interface of the software and may include
databases.
• It includes the specially required items by the users.
• Documentation needs to be prepared for each
deliverables and non deliverable item of the
software, firmware and hardware.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

8. Software Design Description
• This includes major components,
subcomponents and interface of the software
and may include databases
• This process should be carried out by the
standard procedure which has been agreed
on.
• This process may include use of computerized
tools.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

9. Software Interface Documentation
• It describes capabilities and functionality of all
interfaces between any two components of
the system.
• This include the major components ,
subcomponents and external systems
• Both internal and external interfaces of the
software should be described.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

10. Software Test documentation
• It includes the test cases and test case specifications
• The test case specification includes all information
directly needed for performing the actual testing of
the various software modules.
• The software test documentation include
– Test design specification.
– Test log
– Test summary report
Mr. M. E. Patil
S.S.B.T COET, Bambhori

11. Software Development Plan
• There is no good standard for this
• Whatever format you choose to use, come
with a format , get everyone to agree on it ,
and stick to it.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

12. User Documentation
• Ex. Manuals , Guides and so on.
• It specifies and describe the required inputs, options
and other user activities necessary for the successful
use and application of the system.
• The user documentation have two objectives
– Tutorial objective -to train the user
– To provide the on-going reference from the usage
of the system
Mr. M. E. Patil
S.S.B.T COET, Bambhori

13. Document distribution
• Process interface to configuration mgt.
• Distribution to internal project personnel
• Distribution to external project personnel
• Security limitations of documents.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

14. Types Of Documentation
• Architecture/Design – Overview of software. Includes
relations to an environment and construction
principles to be used in design of software
components
• Technical – Documentation of code, algorithms,
interfaces and APIs
• End User – Manuals for the end-user, system
administrators and support staff
• Marketing – Product briefs and promotional
collateral
Mr. M. E. Patil
S.S.B.T COET, Bambhori

15. Standards, Practices,
Conventions and Metrics

16. Standrads
To be applied by every step of product development
• Documentation
• Variable and module naming
• Software programming standards
• Software inspection procedures
• Software testing standards and procedure
• Software quality metrics
Mr. M. E. Patil
S.S.B.T COET, Bambhori

17. Metrics
Metrics refer to the collection and use of data which
reflect productivity and quality of the products
produced
The unit of labour is LOC
Software quality metrics must include
• Branch metric
• Decision point metric
• Domain metric
• Error message metric
• Requirements demonstration metric
Mr. M. E. Patil
S.S.B.T COET, Bambhori

18. ISO 9000
Paragraph 4.4 of standard (ISO 9000) states
following :
“ The supplier shall establish and maintain
documented procedures to control and verify
the design of the product in order to ensure
that the specified requirements are met.”
Mr. M. E. Patil
S.S.B.T COET, Bambhori

19. ISO 9000
The list includes :
• Design and development planning (4.4.2)
• Organizational and technical interfaces (4.4.3)
• Design input (4.4.4)
• Design Output (4.4.5)
• Design Review (4.4.6)
• Design Verification (4.6.7)
• Design Validation (4.4.8)
• Design Changes (4.4.9)
Mr. M. E. Patil
S.S.B.T COET, Bambhori

20. ISO 9000
• This is very broad coverage
• The coverage is good, but it is difficult to
understand and implement
Mr. M. E. Patil
S.S.B.T COET, Bambhori

21. Are all standards, practices, conventions and metrics
which are to be applied, identified?
- Is compliance with these items monitored and
assured?
- Are the following standards all provided:
• Documentation standards?
• Logic structure standards?
• Coding and commentary standards?
Mr. M. E. Patil
S.S.B.T COET, Bambhori

22. Quality Assurance Techniques

23. Nine Techniques
• Reviews
• Standardization
• Simulation
• Testing
• Analytical Modeling
• Execution Analysis
• Independent verification and validation technique
• Correctness proof
Mr. M. E. Patil
S.S.B.T COET, Bambhori

24. Reviews
• There are four review techniques
• 1) Auditing
– Desk checking of development documents for
accuracy, clarity and standards conformance as
well as for errors by the individuals
– Least expensive
– Excellent way to detect and correct the errors
– It is very Talent dependent
Mr. M. E. Patil
S.S.B.T COET, Bambhori

25. Reviews
• 2) Inspection
– It is a highly disciplined and formal technique of
group of dynamics used for finding the errors in
deliverables, such as documents and source code.
– All participants have well defined role, while
management is specifically excluded from the
participation .
– Most expensive but most effective at finding
errors.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

26. Reviews
• 3) Reviewing
– Called as Peer reviews or management reviews
depending on the method used for selection of
participants
– It is the technique of displaying results of a
development process.
– The audience will usually consists of few
developers , managers and user representatives
– Very expensive when large number of peoples are
involved .
Mr. M. E. Patil
S.S.B.T COET, Bambhori

27. Reviews
• 4) Walkthrough
– Intermediate deliverables can be tested for
completeness and verified against peer
documents.
– Some times called as document testing
– Least expensive .
Mr. M. E. Patil
S.S.B.T COET, Bambhori

28. Standardization
• It is the process of creation of formal operational
criteria that establish a model against which
deliverables and the procedures can be compared
and measured.
• This is critical technique for any installation
Mr. M. E. Patil
S.S.B.T COET, Bambhori

29. Simulation
• This is the process of studying system behavior
through use of measurable computer models
• Usually performed utilizing specialized tools such as
simulation language.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

30. Testing
• Most commonly used and misused verification
method
• 45% or more budget are spent on testing.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

31. Types of Testing
• Acceptance Testing
– Overall check of final products at and/or prior to
delivery to ascertain that the product is according
to the contractual requirements
– Is simply judged as more of a legal act than a
technical one.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

32. Types of testing
System Testing
– Overall check of final products at and/or prior to
delivery and is the final technical survey and
evaluation of the viability and quality of the
system, as produced.
Functional Testing
-- This is the technique to discover discrepancies
between the functional definitions of the system
and the actual operating system.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

33. Types of Testing
Logical testing
– It is used to discover errors in the system
computation and logical functions.
.Path Testing
--This testing is used to confirm test effectiveness(
coverage), based on control topology of the code.
-- this technique demands the knowledge about the
internal structure of the source code.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

34. Types of Testing
Stress Testing
-Test to demonstrate at which point the system can
be caused to overload ie. The extreme conditions.
Regression testing
- This involves old tests to be run (previously run and
achieved)
-Is used to demonstrate that the new release still
performs everything the old one did.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

35. Analytical modeling
• Analytical modeling attempt to develop
mathematical representations of the system.
• It is similar to (and frequently a part of ) simulation.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

36. Execution Analysis
• Technique of analysis of an execution.
• Usually used to find the efficiency bottlenecks.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

37. Independent verification, validation
and testing
• This form of testing involves the utilization of totally
independent agency to find critical errors during the
development process.
• It is very expensive but very efficient technique.
• Used for large and/or critical projects. particularly
involving the danger of loss of life
• Ex. Atomic reactor control system.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

38. Correctness Proofs.
• These are the techniques used for formally prove the
correctness of programs or algorithms, similar to
mathematical theorems
• These are not suitable for the real-life systems.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

39. Reviews and Audits

40. Reviews and Audits
• Reviews and audits are to ensure that the
product meets all client needs and
requirements and to find development
anomolies as early and inexpensively as
possible.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

41. Reviews and Audits
• Management Review Process
• Technical Review Process
• Software Inspection Process
• Walkthrough Process
• Audit Process
• Document Verification
Mr. M. E. Patil
S.S.B.T COET, Bambhori

42. Software Inspection Process
Mr. M. E. Patil
S.S.B.T COET, Bambhori

43. Software Inspection Objectives
• To detect and identify software element defects.
• It is conducted by a group of 3-6 participants.
• Defect data shall be systematically collected and
stored in the inspection data base.
• Most powerful mechanism for finding defects in
documents and the program code
Mr. M. E. Patil
S.S.B.T COET, Bambhori

44. Special Responsibilities
Moderator
- He is the chief planner
- Meet the manager for the inspection process.
Reader
- At the meeting the reader leads the inspection
team through the software elements in
comprehensive and logical fashion.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

45. Special Responsibilities
Recorder
- The recorder is charged with documenting defects at
the meeting and recording inspection data required
for process analysis.
Inspector
- Identifies and describes defects in the software
element.
-Must be knowledgeable of the inspection process
-should represent viewpoints at the meeting
Mr. M. E. Patil
S.S.B.T COET, Bambhori

46. Special Responsibilities
Author
-The author is responsible for the software
elements meeting its inspection entry criteria
-Responsible for contributing to the inspection
based on special understanding of the
software elements for performing any rework
required
Mr. M. E. Patil
S.S.B.T COET, Bambhori

47. Software Inspection Input
• Software Elements to be inspected.
• Approved software element specification and
inspection checklist.
• Standards and guidelines.
• Any inspection reporting forms.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

48. Entry Criteria
Authorization
- Inspections are planned for and documented in
the appropriate project planning documents.
Initiating the Event
- The inspection process is triggered by
-Software elements availability
-Project plan compliance
-SQAP or SVVP schedule compliance.
-scheduled re-inspection
-At the request of management
Mr. M. E. Patil
S.S.B.T COET, Bambhori

49. Minimum Entry Criteria.
-The software elements must confirm to
project standard of content and format.
-All prior milestones must be satisfied.
-All required supporting documentation must
be available
- For re-inspection all items noted on the
defect list must be satisfied.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

50. Software Inspection Procedure
Planning
-The author assembles the inspection package
materials for the moderator
-The moderator is responsible for assuring that they
meet the inspection entry criteria.
Overview
-If scheduled an overview presentation of the
software element is conducted by the moderator
-The author makes the presentation.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

51. Software Inspection Procedure
Preparation
-Each inspector must become thoroughly familiar
with the software element.
Examination
-The Inspection meeting follows this agenda
-Introduce meeting
-Establish preparedness
-Review the inspection checklist
-Read s/w elements & record defects.
-Review the defect list.
-Make the exit decision.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

52. Software Inspection Procedure
Rework
-The author revises the materials, addressing all
items on the inspection defect list.
Follow-up
-It provides follow-up on two levels.
-Verifying rework per inspection
-Reporting inspection data
Mr. M. E. Patil
S.S.B.T COET, Bambhori

53. Software Inspection Exit Criteria
• All the defects that have been detected are resolved.
• This single exit criteria is applied to all inspections.
• Each project shall develop its own criteria to meet
the needs of its specific products and development
environment.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

54. Software Inspection Output
• Defect list containing the defect location ,
description, categorization .
• Inspection defect summary.
• Inspection report containing
number of participants, meeting duration,
the size of material inspected, the total
preparation time of the inspection team, the
estimate of the rework effort and the rework
completion date
Mr. M. E. Patil
S.S.B.T COET, Bambhori

55. Software Inspection Audit ability
• It is provided by the following
-Documented inspection procedures
-Retained inspection reports
-Retained inspection defect data.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

56. Data Collection Requirements
• Defects are categorized by the following
Type- It identifies s/w element attributes
Class- It characterize evidence of nonconformance,
and for example may be categorized as missing,
wrong, or extra.
Other Classes- Additional defect classes used when
inspecting documents could include ambiguous
and inconsistent.
Severity- All defects are ranked by severity, such as
major severity and minor severity.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

57. Walkthrough Process

58. Walkthrough Objective
• To evaluate software for defects , omissions, and
contradictions & to consider alternative
implementations.
• The author makes an overview presentation of the
software elements under review.
• This is followed by the discussion from the
participants after which the presenter walks through
the software elements in detail.
• It is useful but less effective than inspection
Mr. M. E. Patil
S.S.B.T COET, Bambhori

59. Special Responsibilities
Moderator
-Is responsible for conducting specific
walkthrough
Recorder
-Responsible for writing all comments made
during the walkthrough that pretend to
-error found
- question of style
Mr. M. E. Patil
S.S.B.T COET, Bambhori

60. - omissions
- contradictions
- suggestions for improvements or
alternative approaches.
Author
-The author is responsible for the software
elements being examined and presents the
materials.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

61. Walkthrough Input
• Statement of objectives for the walkthrough
• The software element under examination.
• Standards
• Specifications for the software elements.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

62. Entry Criteria
Authorization
– Walkthrough are planed for, and documented in
the appropriate project planning documents.
Initiating Event
- it is conducted when the author indicates that the
software element is ready and when the moderator
is appointed.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

63. Walkthrough Procedures
1) Planning
– Moderator identifies the team
– Schedules the meeting
– Distributes all necessary materials.
2) Overview
-presentation is made by the author
3)Preparation
-Each member must review the input materials
during this phase.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

64. 4) Examination
-The presenter makes an overview presentation
-The author walks through the specific software
elements so that the walkthrough team may ask
questions or raise issues regarding the software
element.
5) Exit Criteria
-It will be complete when the entire software
elements have walked through.
-all the deficiencies , omissions , and suggestions
for improvement have been noted and the
walkthrough report has been issued.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

65. Walkthrough Output
• It contains statement of objectives, a list of
– deficiencies,
– omissions,
– contradictions
– suggestions and any recommendations regarding
how to overcome the deficiencies
Mr. M. E. Patil
S.S.B.T COET, Bambhori

66. Auditability
• The walkthrough report meeting minutes, and
other materials on which conclusions are
based, shall become part of he project
documentation
Mr. M. E. Patil
S.S.B.T COET, Bambhori

67. Software Audit

68. Audit Objective
• Compliance confirmation of products and processes
to certify adherence to standards, guidelines,
specifications and procedures
• Audits are performed in accordance with
documented plans and procedures
• Two kinds of audits
- individual, desk check type and
- audit performed by a team
It is the responsibility of the audit team leader to
organize and direct the audit
Mr. M. E. Patil
S.S.B.T COET, Bambhori

69. Audit Input
Following inputs are required
• Purpose and scope of the audit
• Objective audit criteria
• The software elements and processes to be
audited
• Background information for the products and
processes being audited
Mr. M. E. Patil
S.S.B.T COET, Bambhori

70. Entry Criteria
• A special project milestone has been reached
• External parties demand an audit
• A local organizational element has requested
the audit
Mr. M. E. Patil
S.S.B.T COET, Bambhori

71. Audit Procedures
• Planning
• Overview
• Preparation
• Examination
• Reporting
Mr. M. E. Patil
S.S.B.T COET, Bambhori

72. Planning
• Project processes to be examined
• Software required to be examined
• Reports shall be identified
• Report distribution
• Required follow-up activities
• Requirements
• Objective audit criteria
• Audit procedures and checklists
• Audit personnel
• Organizations involved in the audit
• Date, time, place, agenda and intended audience of overview
session
Mr. M. E. Patil
S.S.B.T COET, Bambhori

73. Overview
• Overview meeting with the audited
organization is recommended
Mr. M. E. Patil
S.S.B.T COET, Bambhori

74. Preparation
Preparations required by the audit team
• Understand the organization
• Understand the products and processes
• Understand the objective audit criteria
• Prepare for the audit report
• Detail the audit plan
Audit team leader should make arrangements for
• Team orientation and training as needed
• Facilities for audit interviews
• Materials, documents and tools required
• The software elements to be audited
• Scheduling interviews
Mr. M. E. Patil
S.S.B.T COET, Bambhori

75. Examination
• Review procedures and instructions
• Examine the work breakdown structures
• Examine evidence of implementation and
balanced controls
• Interview personnel to ascertain the status
and functioning of the processes and the
status of the product
• Examine element documents
• Test the elements
Mr. M. E. Patil
S.S.B.T COET, Bambhori

76. Reporting
• Audit team will issue a draft report for review
and comments
• It will have deficiencies, findings and
recommendations
Mr. M. E. Patil
S.S.B.T COET, Bambhori

77. Audit Exit Criteria
• Each element is examined
• Findings are presented
• Response to draft audit is received
• Final findings are formally presented
• The audit report is prepared and submitted
• The recommendation report is prepared
• The follow-up actions have been performed
Mr. M. E. Patil
S.S.B.T COET, Bambhori

78. Audit Output
The draft and final audit report shall contain
• Audit identification
• Scope
• Conclusions
• Synopsis
• Follow-up
Mr. M. E. Patil
S.S.B.T COET, Bambhori

79. ISO 9000 Quality Standards

80. ISO 9000
• Is a family of standards for quality
management systems
• It is maintained by ISO, the International
Organization for Standardization and is
administered by accreditation and
certification bodies
Mr. M. E. Patil
S.S.B.T COET, Bambhori

81. ISO 9000
Some of the requirements in ISO 9001 would include
:
• A set of procedures that cover all key processes in
the business
• Monitoring processes to ensure they are effective
• Keeping adequate records
• Checking output for defects, with proper corrective
action
• Regularly reviewing individual processes and the
quality system itself for effectiveness
• Facilitating continual improvement
Mr. M. E. Patil
S.S.B.T COET, Bambhori

82. ISO 9000
• A company or organization that has been
independently audited and certified to be in
conformance with ISO 9001 may publicly state
that it is “ ISO 9001 certified ” or “ ISO 9001
registered ”.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

83. ISO 9000
• Certification to an ISO 9000 standard does not
guarantee the compliance i.e. quality of end
products and services, rather it certifies that
consistent business processes are being
applied
Mr. M. E. Patil
S.S.B.T COET, Bambhori

84. ISO 9000
ISO 9001 : 2000 is the standard that provides a
set of standardized requirements for a quality
management system regardless of
• What the user organization does
• It’s size
• Whether it is in the private or public sector
Mr. M. E. Patil
S.S.B.T COET, Bambhori

85. ISO 9000
Why an organization should implement ISO 9001 :
2000
• Without satisfied customers, an organization is in
peril!
• To keep customers satisfied, the organization needs
to meet their requirements
• The ISO 9001 : 2000 standard provides a tried and
trusted framework for taking a systematic approach
to managing the organization’s processes so that
they consistently turn out product that satisfies
customers’ expectations
Mr. M. E. Patil
S.S.B.T COET, Bambhori

86. Comparison of ISO 9000
Model with SEI’s CMM

87. Both models deal with methods of
accessing the ability of suppliers to
meet their commitments

88. Capability Maturity Model, CMM
• CMM is a five level framework for measuring
Software Engineering Practices
• They determine the degree of technological maturity
of an organization
- by answers to some 101 questions
• A CMM assessment usually takes five working days
• It is conducted by a team of four people
• The assessors must be highly-trained professionals
with great development experience
• The SEI takes care to control over who an assessor is
and what rights the person may have
Mr. M. E. Patil
S.S.B.T COET, Bambhori

89. ISO 9000
• It defines a minimum level of generic
attributes for a quality management program
• CMM addresses only software, while ISO 9000
addresses the entire organization
Mr. M. E. Patil
S.S.B.T COET, Bambhori

90. Model’s Orientations
• Orientation of CMM is software development
process
• The CMM was specifically developed for software
management and engineering process issues
• The model describes a series of levels, five in number
: key process areas (KPA) and their usages
• Software QA is (a KPA of) level 2
• Software quality management is (a KPA of) level 4
Mr. M. E. Patil
S.S.B.T COET, Bambhori

91. Model’s Orientations
• The Orientation of ISO 9000-3 is a quality
system management
• The objective of ISO 9000 series is the
structure and auditability of QA of
organization
Mr. M. E. Patil
S.S.B.T COET, Bambhori

92. ISO 9000 Weaknesses
Issue 1 : Complexity
• ISO 9000 itself is not simply a standard but a
set of standards
Issue 2 : Repeatability (Reliability of Audit)
• One of the most pressing weakness is who
audits the auditor?
• There is no universally accepted system for
certifying an ISO 9000 auditor
Mr. M. E. Patil
S.S.B.T COET, Bambhori

93. ISO 9000 Weaknesses
Issue 3 : Inherent Structure
• A software organization is not audited
according to ISO 9000-3 but only according to
ISO 9001
• The quality audit is performed according to
ISO 9001
Mr. M. E. Patil
S.S.B.T COET, Bambhori

94. ISO 9000 Weaknesses
Issue 4 : Key audit factors
• They are very limited and most KPAs are not
even mentioned
• E.g. requirements, design, testing, project
management
• There are no agreed-upon metrics for any
area
Mr. M. E. Patil
S.S.B.T COET, Bambhori

95. ISO 9000 Weaknesses
Issue 5 : Process/product improvement
• Some concepts are nonexistent
• ISO 9000 has become a very important
marketing issue
Mr. M. E. Patil
S.S.B.T COET, Bambhori

96. CMM Weaknesses
Issue 1 : Granularity
• It is too small
• It allows some sort of shading for instances
when a site excels in one technology but lacks
in another
Mr. M. E. Patil
S.S.B.T COET, Bambhori

97. CMM Weaknesses
Issue 2 : People/process/technology
• The CMM is based on
people/process/technology
• This is insufficient
• What is demanded to produce software is :
High Quality
Useful
On time and within budgets
Mr. M. E. Patil
S.S.B.T COET, Bambhori

98. CMM Weaknesses
Issue 3 : CMM Focus
• The focus of the CMM is still on technology,
not problem solving
Mr. M. E. Patil
S.S.B.T COET, Bambhori

99. CMM Weaknesses
Issue 4 : Site Comparisions
The following must be proven for validity
• Graduating to the next level
• Improvements in productivity
• Quality and customer satisfaction
Mr. M. E. Patil
S.S.B.T COET, Bambhori

100. CMM Weaknesses
Issue 5 : Objective measurements
• The model does not sufficiently include
objective measurements of real things
Mr. M. E. Patil
S.S.B.T COET, Bambhori

101. CMM Strengths
• Very strong control over the auditors
• The SEI is maintaining a “public database” of
the data collected by it’s accredited auditors
Mr. M. E. Patil
S.S.B.T COET, Bambhori