Quality documentation - PowerPoint PPT Presentation


PPT – Quality documentation PowerPoint presentation | free to download - id: 438dc2-MzgyO


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

Quality documentation


Quality Plan QUALITY ... to ensure that the finished product complies with specifications and applicable design values. Nonconforming Materials Nonconforming ... – PowerPoint PPT presentation

Number of Views:718
Avg rating:3.0/5.0
Slides: 44
Provided by: ictMcast


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Quality documentation

Quality Plan
  • Quality documentation

Project Plan
  • Failing to plan means planning to fail

(No Transcript)
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
  • To ensure that any inadequacies in the process,
    product and standards are brought to managements
    attention so that these inadequacies can be fixed

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.

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

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.

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
  • Document interchange standards
  • Concerned with the compatibility of electronic

Documentation process
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.

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.

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

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

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
  • Have a delivered defect density lt 1 defect/1000
    LOC for first 12 months of operation

SQA Plan 2. Reference Documents
  • Reference Documents
  • complete list of documents referenced elsewhere
    in the SQAP

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.

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

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.

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

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

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
  • There are different types of review with
    different objectives
  • Inspections for defect removal (product)
  • Reviews for progress assessment (product and
  • Quality reviews (product and standards).

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

Types of review
Quality reviews
  • A group of people carefully examine part or all
    of a software system and its associated
  • 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

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

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

Review results
  • Comments made during the review should be
  • 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
  • Requirements and specification errors may have
    to be referred to the client.

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

SQA Plan 8. Problem Reporting
  • Practices and Procedures for reporting, tracking,
    and resolving problems
  • Organizational responsibilities

SQA Plan 9. Tools, Techniques and Methodologies
  • identify the special software tools, techniques
    and methodologies
  • purpose
  • describe use

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

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

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

Sections for Quality Documentation Definitions
  • Terms explanations

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

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.

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

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.

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
  • 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.

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.

  • 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

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

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