Quality documentation

1
Quality Plan

• Quality documentation

2
Project Plan

• Failing to plan means planning to fail

3
(No Transcript)
4
Quality Assurance

• What is not tracked is not done
• The Goals of Quality Assurance
• To improve product quality by appropriately
  monitoring both the product and the development
  process that produces it.
• To ensure full compliance with the established
  standards and procedures for the product and the
  process.
• To ensure that any inadequacies in the process,
  product and standards are brought to managements
  attention so that these inadequacies can be fixed

5
Quality Assurance Plan

• The Quality Assurance Plan (QAP) defines the
  activities performed to provide assurance that
  the product-related items delivered to the
  customer conform to the established and
  contracted requirements.
• The QAP also describes how the project will be
  audited to ensure that the policies, standards,
  practices, procedures, and processes applicable
  to the project are followed.

6
IEEE Standard for SQAP

• IEEE Std 730-1989
• Standard for Software Quality Assurance Plans
• 12 pages
• IEEE Guide for Software Quality Assurance
  Planning
• draft P730.2
• 87 pages
• was ANSI/IEEE Std 983 - 1986

7
IEEE Std 730-1989

• Description Superseded Uniform minimum
  acceptable requirements for the preparation and
  content of Software Quality Assurance Plans
  (SQAPs) are provided. The standard also provides
  a standard against which such plans can be
  compared and assessed. It applies to the
  development and maintenance of critical software.
  For noncritical software, or for software already
  developed, a subset of the requirements of this
  standard may be applied.

8
Documentation standards

• Particularly important - documents are the
  tangible manifestation of the software.
• Documentation process standards
• Concerned with how documents should be developed,
  validated and maintained.
• Document standards
• Concerned with document contents, structure, and
  appearance.
• Document interchange standards
• Concerned with the compatibility of electronic
  documents.

9
Documentation process
10
Document standards

• Document identification standards
• How documents are uniquely identified.
• Document structure standards
• Standard structure for project documents.
• Document presentation standards
• Define fonts and styles, use of logos, etc.
• Document update standards
• Define how changes from previous versions are
  reflected in a document.

11
Document interchange standards

• Interchange standards allow electronic documents
  to be exchanged, mailed, etc.
• Documents are produced using different systems
  and on different computers. Even when standard
  tools are used, standards are needed to define
  conventions for their use e.g. use of style
  sheets and macros.
• Need for archiving. The lifetime of word
  processing systems may be much less than the
  lifetime of the software being documented. An
  archiving standard may be defined to ensure that
  the document can be accessed in future.

12
IEEE 730-1989 Standard for Software Quality
Assurance Plans

1. Purpose
2. Reference Documents
3. Management
4. Documentation
5. Standards, Practices, Conventions and Metrics
6. Reviews and Audits
7. Test
8. Problem Reporting and Corrective Action
9. Tools, Techniques, and Methodologies
10. Training
11. Risk Management

13
SQA Plan 1.Purpose

• Purpose
• Describes the purpose of the project SQAP
• Describe software covered by SQAP
• State portion of software life cycle covered
• Measurable Objectives (Next Slide)
• Answers the following
• What is the intended use of the software
  (criticality, interfaces etc)?
• What is the scope of this SQAP?
• How will this plan contribute to the success of
  the project?
• Name the SDLC that applies to the project and
  deviations?

14
SQA Plan 1. Purpose (Measurable Objectives)

• Example Objectives
• Technical review of all project documents
• Ensure maximum inspection rates of 6 pages/hour
  for documentation and 200 LOC/hour for code.
• Have a process defect yield of 99.9 before
  delivery.
• Have a delivered defect density lt 1 defect/1000
  LOC for first 12 months of operation

15
SQA Plan 2. Reference Documents

• Reference Documents
• complete list of documents referenced elsewhere
  in the SQAP

16
SQA Plan 3. Management

• Organization - depict structure of org.
• responsibilities
• Tasks
• tasks to be performed
• relationship between tasks and checkpoints
• sequence of tasks
• Responsibilities
• of each organizational unit
• Very simple in your projects due to limitations
  of available human resources.

17
SQA Plan 4. Documentation

• identify required documents
• state how documents will be evaluated
• minimum documents required by IEEE 730
• SRS - Software Requirements Specification
• SDD - Software Design Description
• SVVP - S Verification and Validation Plan
• SVVR - S. Verification and Validation Report
• User documentation - manual, guide
• SCMP - S Configuration Management Plan

18
SQA Plan 5. Standards, Practices, Conventions
and Metrics

• Identify S,P,C,and M to be applied
• How compliance is to be monitored and assured
• Minimum
• documentation standards, logic structure
  standards, coding standards, testing standards
• List Selected SQA product and process metrics
• Defects Found, Change Activity, Software
  Structure, Availability,
• Must be related to measurable objectives in
  Purpose Section.

19
SQA Plan 6. Reviews and Audits

• Purpose
• define what reviews/audits will be done
• how they will be accomplished
• what further actions are required
• Minimum
• Software Requirements Reviews
• Preliminary Design Review
• evaluate technical adequacy of top-level design

20
Min Set of Reviews/Audits (cont)

• Critical Design Review
• acceptability of detailed designs
• Software Verification and Validation Plan Review
• adequacy of planned verification and validation
• Functional Audit
• all requirements in SRS have been met
• Physical Audit
• software and documents are consistent and ready
• In-Process Audit
• Managerial Reviews

21
Quality reviews

• This is the principal method of validating the
  quality of a process or of a product.
• A group examines part or all of a process or
  system and its documentation to find potential
  problems.
• There are different types of review with
  different objectives
• Inspections for defect removal (product)
• Reviews for progress assessment (product and
  process)
• Quality reviews (product and standards).

22
Control and review

• Record key decisions
• Control key documents
• Control versions and deliverables
• Define standards
• Coding standards
• Naming conventions
• Routine structure
• Testing
• Documentation standards
• House style
• Conventions and examples
• Review and Audit

23
Types of review
24
Quality reviews

• A group of people carefully examine part or all
  of a software system and its associated
  documentation.
• Code, designs, specifications, test plans,
  standards, etc. can all be reviewed.
• Software or documents may be 'signed off' at a
  review which signifies that progress to the next
  development stage has been approved by
  management.

25
Review functions

• Quality function - they are part of the general
  quality management process.
• Project management function - they provide
  information for project managers.
• Training and communication function - product
  knowledge is passed between development team
  members.

26
Quality reviews

• The objective is the discovery of system defects
  and inconsistencies.
• Any documents produced in the process may be
  reviewed.
• Review teams should be relatively small and
  reviews should be fairly short.
• Records should always be maintained of quality
  reviews.

27
Review results

• Comments made during the review should be
  classified
• No action. No change to the software or
  documentation is required
• Refer for repair. Designer or programmer should
  correct an identified fault
• Reconsider overall design. The problem
  identified in the review impacts other parts of
  the design. Some overall judgement must be made
  about the most cost-effective way of solving the
  problem
• Requirements and specification errors may have
  to be referred to the client.

28
SQA Plan 7. Test

• Identify all tests that are not included in
  Software Verification and Validation Plan (SVVP)
  for the software covered by the SQAP and shall
  state the methods to be used.
• Unit Test
• Integration Test
• System Test
• Acceptance Test

29
SQA Plan 8. Problem Reporting

• Practices and Procedures for reporting, tracking,
  and resolving problems
• Organizational responsibilities

30
SQA Plan 9. Tools, Techniques and Methodologies

• identify the special software tools, techniques
  and methodologies
• purpose
• describe use

31
SQA Plan 10. Training

• This section will identify and provide a summary
  of the training activities to be provided for
  during system implementation.
• User Training
• Development Team Training

32
SQA Plan 10. Training

• covers
• the responsible party,
• audience for the class,
• format for the class (e.g. classroom, one-on-one,
  etc),
• types of materials \ tools (e.g. workbooks,
  handouts, overheads),

33
SQA Plan 11. Risk Management

• Describe overall risk management approach to be
  employed for the project.
• Risk Assessment
• Risk Control

34
Sections for Quality Documentation Definitions

• Terms explanations

35
Third-party Inspection

• Third-party Inspection Activities by an
  inspection agency involving unannounced, periodic
  verification of conformance to quality system and
  product specification criteria.

36
Certificate of Compliance

• Certificate of Compliance A document provided by
  the supplier of the component or constituent that
  attests the component or constituent complies
  with the report holders stated specifications.

37
Follow-up Inspections

• Follow-up Inspections Periodic inspections of
  the manufacturing facilities shall be back to the
  production and quality control records at the
  manufacturing facility

38
Incoming Materials

• Incoming Materials The documentation shall
  include procedures regarding inspections or tests
  that are conducted on incoming materials, or
  other means used to determine that the materials
  meet specifications (for example, mill test
  reports, certificates of analysis, certificates
  of compliance, etc.). If incoming material
  requiring a certificate at the time of receipt
  does not carry such a certificate, then the
  documentation shall contain provisions for the
  material to be segregated until it has been
  appropriately tested or inspected, or the
  certificate is received.

39
In-Process Quality Control

• In-process Quality Control The documentation
  shall describe in-process quality control
  procedures, including how manufacturing processes
  are monitored to ensure that the product is
  consistently manufactured within the allowable
  tolerances.
• Final Inspection The documentation shall detail
  any final inspections and/or tests that are
  conducted before the product is labeled and
  shipped, to ensure that the finished product
  complies with specifications and applicable
  design values.

40
Nonconforming Materials

• Nonconforming Materials The documentation shall
  specify how nonconforming materialsincoming
  materials, materials in production, and finished
  materials are segregated from production until a
  decision is made as to their disposition.

41
Monitoring

• Early warning of impending disaster
• Time to do something about it
• Avoid unpleasant surprises
• Culture
• Communication
• Internal
• With client
• OK to ask for help
• Requests taken seriously
• Milestones
• Roughly one every 1-2 weeks
• Review meetings
• Weekly

42
Inspection and Test Records

• Inspection and Test Records As regards any
  forms, checklists, reports, etc., used by
  in-house personnel to document tests,
  inspections, and other quality control
  procedures

43
References

• http//asingh.com.np/blog/ieee-srs-recommendations
  /
• Managing Successful Projects with PRINCE2 5th
  Edition
• http//standards.ieee.org/develop/policies/
• Software Engineering, Design, Reliability and
  Management, M.L.Shooman, McGraw-Hill, 1983.