• Save
DesSoft - Quality Assurance Procedures
Upcoming SlideShare
Loading in...5
×
 

DesSoft - Quality Assurance Procedures

on

  • 273 views

 

Statistics

Views

Total Views
273
Views on SlideShare
262
Embed Views
11

Actions

Likes
0
Downloads
0
Comments
0

2 Embeds 11

http://www.behance.net 6
https://www.behance.net 5

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

DesSoft - Quality Assurance Procedures DesSoft - Quality Assurance Procedures Document Transcript

  • Engineering Design Software Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Quality Assurance Procedures 1
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software Table of Contents A. Quality Program a. b. c. Quality Program Documents Indoctrination and Training Personnel Qualification B. Software lifecycle and documentation C. Software Development a. b. c. d. D. Software testing a. b. c. E. Software incident management Monthly technical support summary Publication of patches/fixes on web page Program Compliance a. b. c. d. K. Order entry Distribution work order Production first copy verification Software security and authorization Software Technical Support a. b. c. J. Product marketing plan Marketing and promotional material Software production and distribution a. b. c. d. I. Contract Document Review Procurement Control Software Marketing a. b. H. Software version control Software reliease review Patch version control Software defect tracking Software retirement Contract review and procurement a. b. G. Software verification and validation plan Beta test and beta test review Software verification & Vaildation report Software configuration control a. b. c. d. e. F. Software Quality Plan and Planning Review Software Design Specification and Design review Software Development Software Readiness Review Corrective action request Audits and surveillance Management assessment Stop Work Order Quality records 2
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software QAP 1.1 Quality Program Documents Purpose This procedure establishes the requirements for the preparation and issuance of DesSoft’ QA program documents, namely the quality assurance policy manual and the quality assurance procedures (QAP). General The procedures contained in this document govern all DesSoft activities which are deemed to affect the quality of products and services throughout the software life-cycle. The QAP is developed to implement DesSoft commitment to quality as documented in the Quality Assurance Policy Manual (QAPM). The QAP shall be made available to and implemented by all personnel whose activities are controlled by the QA Program. The sample forms contained in the QAP are merely an aid to implement certain requirements of the QAP. These forms may be altered or substituted as deemed appropriate provided that the intent of the requirements are adhered to. QA Program Document Preparation The QA Manager shall direct the preparation of QA program documents. Each QA Program document shall be identified by its current revision number and effective date, and shall contain a table of contents which lists all sections of the document including appendices. Quality Assurance Policy Manual (QAPM) The QAPM shall address DesSoft quality program commitments, and the required organizational structure. The QAPM shall include a management statement directing DesSoft personnel to implement provision of the Quality Assurance Program appropriate to the activities related to their job responsibilities. Quality Assurance Procedures (QAP) The QAP shall provide specific quality requirements for controlling key software design, development, testing, production, and maintenance activities. The requirement shall include implementation methods and responsibilities. QA Program Document Review and Approval The QA Manager shall perform and coordinate the review of QA Program documents. The purpose of the review is to ascertain that the QAPM and QAP meet applicable regulatory requirements and the guidance of applicable industry codes and standards. QA Program documents shall be reviewed and signed by the QA Manager, and approved by the Directors. Issuance and Control The QA Manager is responsible for the distribution of QA Program documents. The QAPM shall be issued to appropriate DesSoft personnel and client organizations in accordance with the QA and reporting software support service agreement requirements. The QAP shall be made available to all DesSoft personnel whose activities affect product quality. 3
  • Engineering Design Software Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 QA Program Document Issuance The QAPM shall be issued with a controlled copy page which identifies the document title, revision number, copy number, recipient’s name, organization, and issue date. The document title page shall also identify the copy number. An acknowledgement of receipt form shall be used as the controlled copy page, and it shall immediately, follow the document title page. The QAP may be issued as controlled document or distributed on line through DesSoft network as uncontrolled document. As a minimum, one copy of the QAP shall be issued to the QA Manager. Reciept Acknowledgement The individual receiving the controlled QA program document is obligated to comply with all instructions provided in the Acknowledgement of receipt form. This includes the return of a signed and dated copy of the form to the QA Manager. Distribution Logs All QAPM and QAP copies issued for use shall be accountable. The QA Manager shall maintain a controlled document distribution log for all QA program documents. For each QA program document, the log shall identify assigned copy numbers, the designated recipient, and the organization represented by the recipient. Uncontrolled Copies Where appropriate, uncontrolled copies of QA Program documents may be supplied for information purposes by the QA Manager provided that the copies are clearly marked “Uncontrolled”. Uncontrolled copies of QA Program documents may also be placed on DesSoft computer network. In this case, the document does not require an Acknowledgement of receipt form. Revision Control Revisions to QA Program documents shall be prepared, reviewed, approved, issued, and controlled in the same manner as the original document. Each revision to a QA Program document shall have the revised areas clearly identified. The revision number shall be identified on each page of the QA Program documents. QA Records The revision of the QAPM and QAP shall be retained by the QA Manager as QA records. The QA Manager shall submit superseded revisions of these QA program documents to the QA Library for records retention. The controlled document distribution log shall also be retained by the QA Manager as QA record. 4
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software QAP 1.2 Indoctrination and Training Purpose This procedure establishes the requirements for indoctrination and training of all personnel performing activities related to the design, development, testing, production and maintenance of software products controlled by the QA Program. QA Program Orientation Training The QA Manager is responsible for the QA Program training. All personnel performing activities, which are controlled by the QA program, shall receive QA Program orientation training. This requirement shall include management personnel who prepare, review or approve QA documents. QA Program Orientation Training Schedule New employee shall receive the QA Program orientation training within sixty (60) days of employment, or prior to their involvement in any activities controlled by the QA Program. This requirement shall include subcontractors working under DesSoft QA Program. Orientation Training Topics The QA Program orientation training shall cover, as a minimum, the following:       DesSoft’ commitment to quality software products and services. Applicable regulations, industry codes, and standards. Overview of the Quality Assurance Policy Manual. Overview of the Quality Assurance Procedures QA Program implementation responsibilities. Corrective action process. Orientation Training Documentation The orientation training shall be documented for each employee, and applicable subcontractor in accordance with the subcontract documents. Training documentation shall include employee name, training date, topics covered, signature of the instructor and employee’s acknowledgment. Update and Refresher Briefings Briefings on significant QA Program changes or quality issues shall be given to DesSoft employees as determined appropriate by the QA Manager. Update or refresher briefings shall be determined by the QA Manager.  QA Records - QA orientation training and update/refresher briefing documentation shall be retained by the QA Manager as QA record.  Attachments – (A) Employee Quality Assurance Orientation Record form (B) Additional Employee Training form. 5
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software Employee Quality Assurance Orientation Record: Name: Title: Date Hired: Department: Responsibilities: The employee named above has received basic indoctrination training covering the following material:     QA program background Review of established policies (QAPM) Overview of established procedures (QAP) Review of corrective action report requirements (Including client notification for safety issues per 10CFR21)  Review of corrective action process I certify that the above named employee has completed QA orientation training and has displayed a satisfactory level of understanding: Training Instructor: Title: Date: Employee Acknowledgment I have participated in the QA program orientation training listed above, and I understand how these policies and procedures affect my job responsibilities. Employee Title: Date: 6
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software Record of Additional Employee Training: Name: Title: Date Hired: Location/Department: Responsibilities: The employee named above has received additional QA training which covered the following material:           Software Life Cycle & Documentation Software Development and Testing Software Configuration and Control Software Production and Distribution Software Technical Support Contract Review Procurement and Software Tools QA Records Control ……………………………………………. ……………………………………………. I certify that the above named employee has completed additional QA training as required to perform the activities related to the job responsibilities defined above and has displayed a satisfactory level of understanding. Training Instructor: Title: Date: Employee Acknowledgment I have participated in the additional training listed above, and I understand how these policies and procedures affect my job responsibilities. Employee Title: Date: 7
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software QAP 1.3 Personnel Qualification Purpose This procedure establishes the qualification requirements for technical personnel involved in the software activities. Applicability Personnel qualification requirements shall be imposed on all employees and subcontractors performing software design, development, testing, and maintenance activities controlled by the QAP. Qualification requirements for quality audit personnel are addressed in the Program Compliance section of the QAP. Personnel Qualification Specific qualification requirements for technical personnel are based upon a personnel classification system defined below: Job Classification Product Development Manager Lead Development Engineer Development Engineer Technical Support Manager/ Testing Manager Technical Support/Test Engineer Technical Writer Qualification with Degree MS (CS or Engineering), or BS + 3 Years experience. BS (CS or Engineering) + 1 year experience BS (CS or Engineering), MS (CS or Engineering), or BS + 3 years experience. BS (CS or Engineering), BS Engineering Technology, or BA English Qualification without Degree 5 years experience 3 years experience 2 years experience 4 years experience 1 years experience 1 years experience Note: Experience refers to applicable experience. Personnel Qualification Documentation Personnel qualification documentation may include diploma(s), transcripts, license(s), resume, etc. or a combination thereof. Personnel qualification shall be reviewed by the responsible manager. QA Records Personnel qualification records shall be forwarded to and maintained by the designated Human Resource personnel in the personnel file. 8
  • Engineering Design Software Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 QAP 2.0 Software Life Cycle and Documentation. Purpose - This procedure establishes the process by which software product is developed, designed, tested, released and maintained by DesSoft. General The software life cycle spans from the conception of the software product until the retirement of the software product. DesSoft develops, modifies, integrates and releases software products. Each software product is developed through the following phases: 1. 2. 3. 4. 5. Software Requirements Software Design & Implementation Software Testing Software Maintenance Software Retirement Each of these lifecycle phases shall be performed in accordance with the requirements in the respective sections of the QAP. The DesSoft Software Lifecycle is presented in Attachment A.  Software Life Cycle Process - The specific software life cycle process may vary from one software product to another. Attachment B presents two software lifecycle processes commonly used by DesSoft. Other software life cycle processes may be used. The specific software life cycle used for each version of the software product shall be defined in the Software Quality Plan. Software QA File The Product Marketing Manager or designee shall maintain a software QA File for each version of the software product. The Software QA File shall contain the following: A. B. C. D. E. F. Approved Software Quality Plan including all revisions (QAP 3.1) Approved Software Design Specification and design review form including all revisions (QAP 3.2) Approved Development Review Form if required by the SQP (QAP 3.3) Approved Software Readiness Review Form (QAP 3.4) Approved Software Verification and Validation Plan including all revisions (QAP 4.1) Approved Software Verification and Validation Report including applicable Beta Test documents (QAP 4.2 & 4.3) G. Software Release Review Form (QAP 5.2) H. Software Distribution Form (QAP 5.2) The Software Development Manager shall maintain the Software QA File current throughout the development process until the software product is released. QA Records - The Software QA File shall be maintained as QA records and shall be submitted to the QA Library after the product release. Attachment 1.0 Software Life Cycle Flowchart 2.0 Software Development Models – Waterfall & Spiral 9
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software Software Life Cycle: Software Quality Plan No. Planning Review Yes. Yes. New Enhancements Software Design Marketing Plan No. No. Design Review No. Marketing Plan Review Yes. Yes. Marketing Material Software Development Independent Testing No. Readiness Review No. Yes. Order Entry Production Security Device QA Release Review Yes. Technical Support Product Retirement Product Distribution 10
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software Software Development Model – Water fall In the Waterfall model of software development, each phase of the life cycle is completed in sequence, including documentation, before the next phase begins. In this model each phase is independent and the completion of phases represents milestones in the development process as shown below:  Software Quality Plan  Software Design  Software Development  Software Testing  Software Release  Software Maintenance  Software Retirement 11
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software Software Development Model – Spiral In the Spiral model of development, prototype of the software is generated in accordance with the requirements specified in the Software Quality Plan. The prototype of modules thereof is designed, coded, tested, and modified as necessary until the baseline is established with sufficient stability for independent testing. The process is repeated until the software is released. Software Quality Plan Software Development Software Design Software Testing Software Release Software Maintenance Software Retirement 12
  • Engineering Design Software Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 QAP 3.1 Software Quality Plan and Planning Review Purpose This procedure establishes the requirements for planning activities of software product which is developed, produced and released by DesSoft. General The Product Marketing Manager is responsible for the preparation of a Software Quality Plan (SQP) prior to the initiation of new software product or any modification to a existing software product. In preparation of the SQP, the Product Marketing Manager should consider input from past or current users, technical support, testing, Engineering and corporate marketing/sales. Software Quality Plan (SQP) The Product Marketing Manager shall prepare a SQP with the Product Development Manager prior to the initiation of software development activities. The SQP defines the software quality and technical requirements. The SQP for new software product or major modification thereof shall address the following in detail as applicable. a) b) c) d) e) f) g) h) i) j) k) l) m) Product overview and its relation to DesSoft product strategy Market opportunity and customer needs Customer base intended Prioritized enhancement of feature list Functional requirements Impact to and integration with existing DesSoft products Pricing strategy Product competitive analysis Product dependency and constraints Dependency on DesSoft shared components Requests for development of new components Resource, schedule and cost estimates Development process: Waterfall, Spiral, or other The SQP for software error correction or minor revisions shall address, as a minimum, the changes to software features, errors to be corrected, planned reviews, applicable quality requirements, resource, schedule and cost estimates. The SQP for each revision of the software shall identify the following as applicable: 1. 2. 3. 4. 5. 6. 7. 8. Software Name and Version Platform and Network Environment Product Development Manager Independent Lead Test Engineer Planned Beta Release Date Planned Software Release Date Planned Software Reviews Required Software Development Documents 13
  • Engineering Design Software Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 SQP Review and Approval The SQP shall be reviewed, as applicable, by the President, Vice President of Engineering, Vice President of Marketing & Sales, Product Development Manager, and QA Manager. The SQP review shall be documented on the SQP cover sheet. SQP Revision The product Marketing Manager shall prepare revisions to the SQP to reflect changes in requirements. Revisions to the SQP shall be reviewed and approved in the same manner as the original. QA Records The approved SQP and all revisions shall be maintained in the Software QA File by the Product Development Manager. Attachments 1.0 Sample SQP and Planning Review Cover Sheet 14
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software Software Quality Plan Cover Sheet Software Name: Platform: Software Version: Network Supported: Target Beta Release Date: Revison Number Target Release Date: Soft Document Index and Review  Software Design Specification  Software V & V Plan  Software V & V Report      Software Marketing Plan  Product Marketing Release Plan  Marketing Material Development Review  Marketing Release Readiness Review  Other:  Other: Software Design Review Product Development (Freeze) Review Product Readiness (Distribution) Review Beta Release Review Key Personnel Product Development Manager: Lead Testing Engineering Product Marketing Manager Component Manager   Software Planning Review & Approval Submitted By: Approved By: (Prod Develop Manager) (Prod Marketing Manager) (VP of Marketing) (VP of Engineering) (QA Manager) (President) Date: Date: Date: Date: Date: Date: 15
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software Software Planning Review Checklist Software Name: Version # General Review Checklist 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Comment # Is there a clear assessment of the objectives for this proposed product release? Are the objectives validated against market and company requirements? Is there a prioritized list of enhancements or features to be included in this release? Is the Open Enhancement Summary Report attached? Is there an estimated time to address each planned enhancement? Is the Open Error Summary Report attached? Is there a list of open errors to be addressed in this product release? Is there an estimate of the effort to address errors to be corrected? Is there a list of potential dependencies and on other DesSoft products included? Is there an impact statement on marketing and sales included? Is there an impact statement for production, authorization & ordering? Is there a schedule, manpower and cost estimate attached? Is the lifecycle reviews adequately and appropriately planned? Is a Beta Test required for this version release? Product Specific Review Checklist Comment # Remarks: 16
  • Engineering Design Software Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 QAP 3.2 Software Design Specification and Review Purpose This procedure establishes the requirements for preparation, review and approval of software design specification. General The Software Design Specification defines the scope of a product development effort including project management and implementation. The overall quality of the software product is highly dependent on the initial design of the software documented on the SDS. The SDS provides the basis for the software coding and for the preparation of Software Verification and Validation Plan. Software Design Specification (SDS) The Product Development Manager shall prepare a SDS based on the approved SQP. The SDS shall address the following as applicable. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Software feature list and requirement items Requirement technical basis Flowcharts and major tasks Software module design and interface Functional requirements and acceptance criteria Algorithm and equations Interface and interdependencies Critical definitions and acronyms List of software tools Dependency on specific DesSoft shared components Coding standards and conventions Database structure & libraries Limitations and restrictions on input and functional parameters Development milestones and associated schedule Impact to the User Documentation The SDS shall use the SDS Cover sheet (QAF) 3.2 which identifies the following: A. B. C. D. E. F. Software name and version Platform and network environment Product Development Manager Lead Test Engineering DesSoft Component Engineers SDS Revision History 1. SDS Review and Approval - The SDS shall be reviewed by the Product Marketing Manager, Independent Test Engineer, Applicable Component Manager(s), and approved by the Vice President of Engineering. A copy of approved SDS shall be distributed to the designated independent Test Engineer and QA Manager. 17
  • Engineering Design Software Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 SDS Revisions The Product Development Manager shall prepare revisions to the SDS to reflect changes in the requirements. Revisions to the SDS shall be reviewed and approved in the same manner as the original. QA Records All revisions of approved SDS shall be maintained in the software. QA file by the Product Development Manager. Attachment 1.0 Sample SDS Cover Sheet 18
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software Software Name: Platforms: Target Beta Release Date: Submitted By: Received By: Approved By: Rev Description Software Design Specification Cover Sheet Software Version: Network Supported: Target Release Date: . Software Design Specification Review & Approval (Prod Develop Manager) (Prod Marketing Manager) (Lead Test Engineer) (VP of Engineering) Prepared By/Date. Revisions Received By/Date. Reviewed By/Date. Revision Number Date: Date: Date: Date: Approved By/Date. 19
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software QAP 3.3 Software Design Implementation Purpose - This procedure establishes the requirements for implementation of software design, coding and developer testing. General The software design is implemented in accordance with the approved SDS. The module design is defined in the SDS is developed into coding in a manner, which is consistent with coding standards, and conventions specified in the SDS. Implementation Process Each software module should be as independent a possible to facilitate debugging individually, and compared against design requirements during the implementation process. It is essential that the development team perform the development verification of each module. This development verification should include the code review and module testing. Only fully debugged modules shall be combined into larger software components. This process of individually debugging software modules and/or components should be repeated as practical until the development team is satisfied within the observed level of stability. The development tests used to evaluate software stability are iterative in nature and not subject to version control. The development team may make changes to coding until the desired stability is attained. The development testing should also achieve that the software is reasonably error free and meet all the requirements specified in the SDS prior to software freeze for independent testing. When the Product Development Manager is ready to freeze the software module(s) for independent testing, a development review may be conducted in accordance with the SQP. User Reference Documents User Reference Documents (URD) are considered an integral part of the software. As such the URD should be developed in parallel with the software. The URD may take the form of printed hard copy, or on-line files. A draft URD shall be prepared prior to the software freeze and should provide details for each of the following items as applicable.          All product features Applicable operating systems or platforms How to use the product Default and required user input Built in database or libraries How to interpret the output Designed limitations All relevant assumptions A tutorial example A draft URD, as appropriate, should be provided to the independent test engineer with the software for module testing. The final URD shall contain the available means for user to report software error and problems. The final URD shall be reviewed by the independent Test Engineer and presented at the Software Readiness Review for approval. 20
  • Engineering Design Software Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Product Development Review When required by SQP, the development review is performed to determine if the product or modules thereof is ready for independent testing and if technical contents of the URD are complete. The Product Development Manager is responsible to coordinate this review with the Product Marketing Manager, independent Test Engineer and QA Manager. The product development review shall be documented on the Product Development Review Sheet. QA Records The Product Development Manger shall maintain the approved URD and the product development review sheet in the software QA File as QA Record. Attachment  Sample Product Development Review Sheet 21
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software Product Development (Freeze Readiness) Review Checklist Software Name: Module Name(s): 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Versions # Platforms: Review Criteria Is the baseline version (& edition name) Identified? Are the compiler, executable linker and I/O utilities identified? Are all item changes, additions, retirements (Relative to the baseline) Identified? Is there a list of all implemented requirements? Is the list of requirements reconciled with those listed in the SDS? Has a cross reference list of SDS items to enhancement numbers been identified? Has the developer performed a self-code verification? Is there a list of all errors and anomalies identified by developers? Are all errors and anomalies not fixed and remain open, identified? Is the Database description present and has it been updated? Is there a clear statement of any limitations? Is SVVP & Test Matrix development under way? Comments # Remarks: Disposition of Reviewed Software or Modules:  Reject - See Attached Comments  Accept Submitted By: Reviewed By: Reviewed By: Reviewed By:  Proceed with development of remaining modules.  Initiate independent Testing (Prod. Develop Manager) Date: (Prod. Marketing Manager) Date: (Testing Engineer) Date: (QA Manager) Date: 22
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software QAP 3.4 Software Readiness Review Purpose This procedure establishes the requirements for software readiness review. General The purpose of the software readiness review is to assess the overall readiness of the software and the URD for commercial release. The software readiness review shall verify that all software requirements specified in the SQP have been satisfied including documentation. Responsibilities The Products Marketing Manager is responsible for coordinating and documenting the software readiness review. The Lead Test Engineer is responsible for verifying the completion of required software test activities specified in the SVVP, for entering all unresolved software errors identified during the independent testing, and verifying the accuracy of the open error summary. The QA Manager is responsible for verifying the completeness of software documentation. The VP of Engineering is responsible for the approval of the software release. Software Readiness Review Process The software readiness review shall cover the following items as a minimum: 1. 2. 3. 4. 5. 6. 7. 8. The requirements in the SQP have been satisfied and the SQP has been updated to reflect the current software features and capability. The requirements in SDS have been fully implemented. The required Alpha and Beta Tests have been completed in accordance with the approved SVVP. All open errors and anomalies have been summarized/ categorized by the Lead Test Engineer, and concurred by the Product Development Manager. All closed errors and incorporated enhancements have been confirmed by the Lead Test Engineer. The URD has been reviewed and accepted by the Lead Test Engineer. The configuration control of the software is traceable to the base line version. Open errors of the software are acceptable for commercial release. The software readiness review shall be documented on the review form. If the software is determined NOT ready, the Product Marketing Manager shall assign the required actions to appropriate personnel to resolve the review comments. The software readiness review shall be rescheduled until the software is approve for release. QA Records The software readiness review sheet and associated comments shall be maintained in the software QA File by the Product Development Manager as QA record. Attachment - A. Sample Software Readiness Review Sheet 23
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software Software Name: Software Readiness Review Checklist Version: Module Name(s): 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Platform: Review Criteria Is the baseline version (& edition name) identified? Are the compiler, executable linker and I/O utilities identified? Is there a list of all implemented requirements? Are all item changes, additions, or retirements (relative to the baseline) identified? Is the list of requirements reconciled with those listed in the SDS? Has a cross-reference list of SDS items to enhance numbers been identified? Does the Test Matrix sufficiently cover the listed requirements? Is there sufficient documentation that testing was performed by personnel independent from development activities? Is there a list of all closed and outstanding errors and anomalies? Is the classification of outstanding errors consistent with acceptance standards? Is SVVR complete and ready for review and approval? Have all configuration management requirements been met? Are software QA Files complete? Is there a clear statement of any software limitations? Is there a README.TXT file included on the first disk that addresses limitations or issues not covered by the documentation? Comments # Remarks: Disposition of Reviewed Software:  Reject - See attached comments  Accept Submitted By: (Prod. Marketing Manager) Reviewed By: (Prod. Develop Manager) Reviewed By: (Lead Test Engineer) Reviewed By: (QA Manager) Approved By: (VP of Engineering)  Proceed with software production Date: Date: Date: Date: Date: 24
  • Engineering Design Software Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 QAP 4.1 Software Verification and Vaildation Plan Purpose This procedure establishes the requirements for the Software Verification and Validation Plan (SVVP). General The SVVP defines the methods necessary to objectively verify that the requirements in the SDS have been implemented in the software code and user documents. The SVVP addresses the overall plan for the verification and validation activities throughout the software development process. SVVP Preparation The Lead Test Engineer is responsible for the preparation of the SVVP based on the approved SDS. The SVVP shall cover all features or enhancements specified in the SDS. The SVVP shall define in sufficient detail the Alpha test scope, approach, resources requirements, planned software tools, and schedules consistent with the SQP. During the preparation of the SVVP, the Lead Test Engineer shall work closely with the Product Development Manager as the software implementation progresses, and refine the SVVP to include all test phases planned and all test cases to be used. The SVVP shall define the accuracy and functional tests developed for each feature or enhancement. SVVP Contents The SVVP shall define the following:           Detailed description of the planned internal Alpha test phases and Beta Test if required by the SQP. The pre-requisite and objective of each test phase and activities (features or enhancements) to be tested. The test case to be executed in each test phase. The test platform and environment under which test cases are to be executed. How each test case results are to be bench-marked. Regression tests planned. Functional tests planned including contents and adequacy of the Help and error messages. If calculations are used for test results bench-mark, the calculation shall be independently verified prior to use. Software tools needed and their classification shall be identified. Planned resources and schedule. SVVP Review and Approval The SVVP shall be reviewed by the Product Development Manager and approved by the VP of Engineering prior to initiating test execution. QA Records The final approved SVVP shall be maintained by the Lead Test Engineer in the Software QA file. 25
  • Engineering Design Software Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 QAP 4.2 Beta Test and Beta Test Review Purpose This procedure establishes the requirements for Beta test activities when required by the SQP. General Beta tests are performed by outside organizations. These organizations may include client users, potential clients and/or specially arranged evaluator with expertise in selected technical areas. Beta Tests The Product Marketing Manager is responsible for the planning of Beta Tests. The Beta test locations, test period and test results reporting requirements shall be prepared by the Product Marketing Manager and be included as Beta test instructions in the Beta test package. The Beta test period shall commence in accordance with the SVVP. In general, the Beta tests should be performed after the completion of corresponding internal Alpha testing. Only Beta released software shall be sent to the Beta test sites along with appropriate software documents in a Beta test package. The Beta test package shall be transmitted with the Beta test instructions by the Product Marketing Manager. Beta Test Results Review All Beta test results shall be directed to the Product Marketing Manager. Regularly during the Beta test period and when it has ended, the Product Marketing Manager shall review the Beta test results with the Product Development Manager and designated Test Engineer, and summarize, classify, and record all findings. All confirmed errors shall be entered into the software error tracking database. QA Records The Beta release document, Beta test package, Beta test results and Beta test summary shall be maintained as part of the SVVR by the Lead Test Engineer in the Software QA file. 26
  • Engineering Design Software Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 QAP 4.3 Software Verification and Validation Report Purpose This procedure establishes the requirements for the Software Verification and Validation Report (SVVR). General The SVVR describes the results of the SVVP execution. The SVVR shall be prepared by the Lead Test Engineer for each iteration of software freeze/testing including the Beta test. SVVR Contents The SVVR shall include the following: 1.0 Summary of test results 2.0 A list of all test cases used and results of each test case verified including the identification of the testing personnel 3.0 A list of errors identified and the severity of the errors 4.0 The unique identification of user documents verified including revision numbers 5.0 The platform and network environment tested 6.0 A summary of tested objects including version numbers 7.0 Test tools used 8.0 Administrative summary of test hours spent 9.0 The installation procedures tested 10.0 Summary of Beta test results and identified errors 11.0 Security code and authorization process test results The SVVR is compiled through- out the test activities for each product freeze. The Lead Test Engineer is responsible for collecting the above test documentation as test progresses. A SVVR is required for each software freeze. SVVR Review and Approval The SVVR shall be reviewed by the Product Development Manager. Where the review indicates additional iteration of software development activities, the decision for additional iteration shall be documented on the SVVR. The Product Marketing Manager approves the SVVR. The final SVVR for a software version shall be reviewed at the Product Readiness Review meeting by the Product Development Manager, Product Marketing Manager, QA Manager and approved by the VP of Engineering. QA Records All revisions of approved SVVR shall be maintained by the Lead Test Engineer in the Software QA file. 27
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software QAP 5.1 Software Version Control Purpose This procedure establishes the requirements for the software version identification number to provide configuration control. General Each software product which DesSoft produces shall be assigned a software name and a version control identification number. The software version number provides means of the unique identification for a specific software configuration. Software Version Number - The software version number shall have the following format: A.BC.ZZ Where, A = General version number. This one or two digit number starting from”1” changes with the release of a “major” software upgrade. B = Minor upgrade version number. This one digit number starting from “0” changes with release of a “minor” upgrade C = Correction release number. This one digit number starting from “0” changes with release of error correction only where no software feature or enhancement are provided ZZ = Version iteration tracking number. This two digit number starting from “01” is used to track the sequential “freeze” or “build” progression of a software product through the development phase of its life cycle Software Version Number Implementation The software version that has been approved for commercial release is generally identified by the version number in the “A.BC” format except the patch version which retains the “A.BC.ZZ” format. This version number is specified on the SQP as well as all the software development documents. For example, a minor upgrade of the existing software version 4.15.02 will be referred as version 4.20 in all documents. The first software freeze of this upgrade testing will be identified as version 4.20.01. Each subsequent development iteration, would be compiled as 4.20.02, 4.20.03, and so on until it is released as version 4.20. In addition, it is possible to initiate parallel development for a correction release of the existing software version 4.15.02. The parallel development would employ the version number 4.16.01, 4.16.02, and so on. This version number control also applies to a “patch version”. It should be noted that the software itself shall always retain the ability to display the complete version number including the “ZZ” number. The software version number may be controlled by the software tools such as PVCS. 28
  • Engineering Design Software Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Software Change Control Any change to commercially released software shall be controlled through the use of SQP and software error database. Code Control All software versions subject to configuration management shall be controlled and maintained in order to protect and preserve the validity of the completed software product. Software codes may be controlled manually or by configuration control tools for storing and retrieving the history of changes made to source code, executables, utilities, documentation files and databases. The tools used for this purpose shall also be required to support unlimited branching and provide safe merging for unimpeded parallel development. QA Records Commercial product version masters including the source code, program, executables, associated documentation, input files, and output results of all independent tests performed shall be maintained in the software QA File. The Software QA File shall be submitted to the QA Library as QA records when the software is released. 29
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software QAP 5.2 Software Release Review Purpose This procedure establishes the requirements of the review for software release. The software release review shall cover pre-release, patch, commercial and QA&R releases. General The QA Manager shall release all software from the software/QA library on the software release from in accordance with this procedure. Software Release Review The product Marketing Manager shall initiate and coordinate the release of software for distribution as follows:  Prepare the Software Release Form to identify the software version to be released, indicating whether it is a pre-release, patch, commercial release or QA&R client’s release.  For commercial and QA&R releases, verify that the first production copy has been checked by obtaining release from the designated Test Engineer.  Verify that all orders for the software have been entered into the database by obtaining release from the Sale Administration Manager. The software release shall be reviewed and approved by the VP, Engineering, VP, Marketing & Sales and QA Manager. All release reviews and approval shall be documented on the Software Release Form. A copy of Software Release Form shall be forwarded to the Production Manager for software distribution. QA Records The QA Manager shall maintain the completed Software Release Form as QA Records in the Software QA File. Attachment Sample Software Release Form 30
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software Software Release Form Software: User Documents: Version No. Edition: Distribution Media:  CD  USB Stick  3 1/2” HD  Other  Other  Other Quantity: Description  Pre-Release  Dealers Only  Beta – Attach Beta Distribution List  Others  Patch Release  Web – Responsible  Commercial Release Order Entry completed by Sales Administration Manager : First Copy Verified by independent Testing:  QA & R Client Release Order Entry completed by Sales Administration Manager : First Copy Verified by independent Testing: Approved: Approved: Approved: Internal Distribution:  Production Manager (VP, Engineering) (VP, Marketing) (QA Manager)  QA Manager  SVVR Date: Date: Date:  Technical Support Manager 31
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software QAP 5.3 Patch Version Control Purpose This procedure establishes the requirements for the creation and release of a patch version of the previously released software. General A patch version is a “quick fix” for the current commercially available software version and is limited to the correction of software errors only for a specific client or clients. The patch version is classified as “prerelease” and must be clearly identified as instructed in this procedure. Patch Version Control Each patch version shall be identified with a version number in the format of A.BC.ZZ. The ZZ number shall be incremented from the last released iteration number. The patch version shall be embedded with a warning statement in the main display and any reports printed as follows or a similar statement: “The Patch version #A.BC.ZZ contains modifications necessary to correct software error No(s)___, ___. This Patch version has not been independently verified. The user of this patch version is responsible for verifying the accuracy of any output produced” The patch version shall be cumulative. All errors corrected in a superseded patch version shall remain corrected in the new patch version. It should be noted that no patch version may be used as the baseline for future commercial version release. Since patch version is limited to quick error correction, no URD revision shall be provided with any patch version. Patch Version Release The patch version shall be released in accordance with the release procedure in QAP 5.2. Each patch deliverable shall include installation and applicability instructions, a log of all error corrections therein, and a disclaimer of the patch version (see Paragraph 3.0 of this procedure). Patch Version Distribution The distribution of a patch version shall be determined by the Product Development Manager. The patch version may be distributed by download through the World Wide Web (WWW) or via email as a link. QA Records The Product Development Manager shall maintain and collect the freeze memo, patch version disk/tape and the release notice as QA records. When the patch version is released, these records shall be submitted to QA Manager. 32
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software QAP 5.4 Software Defect Tracking Purpose This procedure establishes the requirements for reposting, tracking, evaluating and resolving software errors/enhancements/anomalies, collectively referred to as “defects”. General DesSoft maintains a Software Defect database to track the status of all reported software errors/enhancements/ anomalies. It may not be apparent to a user whether a software problem is an error or an enhancement. However all reported software problems are evaluated, classified and tracked by DesSoft. Software Defects Reporting Any user who identifies a software problem in a commercially released software product is asked to notify the responsible Technical Support personnel. This request is provided in the software URD. The Technical Support personnel is responsible for logging and reporting all user contacts in accordance with QAP 9-1. During the contact or its investigation the Support Engineer may identify a previously unknown defect. At this point they are required to log the problem into the defect database and notify the Product Development Manager in order to coordinate its evaluation. DesSoft development and test personnel may also enter a previously unknown issue into the defect database. Issues submitted under these conditions are also subject to the referenced evaluation process. It should be noted that some problems identified during the testing phase of a new product version are reported and tracked in the defect database as an “anomaly”. An anomaly is essentially the same as an error, but it has the distinction of being limited to the software version under development. (i.e. it is not present in any commercially released version), whereas, an error would apply to both the version under development and a commercially released version. Software Defects Evaluation Upon receipt of a newly submitted defect, the Product Development Manager is responsible for completing a thoughtful and timely evaluation of the issue(s) and achieve a consensus among the key team members (development, test, and support) as to its definition and evaluated status. The Product Development Manager has the authority to assign investigation/evaluation tasks to a team member as may be required. The evaluator shall attempt to recreate the reported problem, and refine its description as may be required to properly communicate its true nature. If the problem is determined is determined to be an “enhancement”, no further action is required by this QAP. Next, an assessment of the “1 st affected version” is required to determine whether the issue is to be classified as an “error” or “anomaly”. If classified as an anomaly, the remaining evaluation steps should be applied (as applicable). If classified as an error, the following information shall be specified: The extent of the error’s impact on product items (one or more can apply): Source Code – A deficiency that is due to inadequate source code. Document – A deficiency that is due to inadequate documentation. Library Data – A deficiency that is due to inadequate library database. 33
  • Engineering Design Software Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Other – This is a catch-all classification for any deficiency type which does not fall into one of the above.  The version number in which the error first occurs.  The severity level of error: Critical – classified as “Critical” if either of the following apply:   Software operations and or functions are severely faulted that the software is “unusable” or Analytical software module procedures un-conservative results which have been further evaluated in accordance with QAP 10.5 as being reportable under 10CFR21. The QA Manager shall be notified immediately when a “Critical Error” is determined to exist. Major – A “Major” error is one which prevents the use of primary section(s)or feature(s) of the software and for which no feasible avoidance exists. Intermediate – an “Intermediate” error is either   Any error which prevents the use of primary function(s) and for which an avoidance exists, or Any error which prevents the completion of a secondary function and for which no avoidance exists. Minor - All miscellaneous errors of any type not included in the above categories.  The “priority” level for error correction There are four (4) priority fields provided for priority designation by a) Marketing and Sales, b) Development, c) Testing, and d) support. The development priority is required and other priority designations are optional. High – Error correction is to be effected in the next software release. All “ Critical”, easily fixed errors shall be given this priority. Medium – Error correction is to be made as soon as possible, within the context of planned development activities and the complexity of the required fix. Low – Error correction is to be made in accordance with the schedule of software development.    Any known “Recommended User Action” or “Avoidance”. Recommended corrective action plan if any Other pertinent information such as action status, estimated development effort, affected editions, reported by, test case ID, etc. The evaluator(s) and the evaluation date shall be identified in the database. Software Error Correction and Enhancement Incorporation. - The software errors and enhancements can only be corrected and incorporated into the software through a software revision. The Product Marketing Manager shall review the error/enhancement database as part of software development planning activities in accordance with the requirements of QAP 2.0. The Product Marketing Manager shall initiate such software revisions by completing a Software Quality Plan (SQP). 34
  • Engineering Design Software Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Software Error/Enhancement/ Anomaly Closeout. The status of a software error/enhancement/anomaly shall be changed to “closed” only after all related tests have been executed, verified, and documented in the approved SVVR. The Lead Test Engineer shall enter or review all error closeout in the database to ascertain that sufficient data is recorded in the database for traceability, such as fixed version number, test cases, etc. Published Error Report Summary error reports shall be generated for each DesSoft software product by the Lead Test Engineer. The interval at which the software error reports are generated, published and distributed to client users is dependent upon the service level subscribed by the client. Summary error reports shall consist of the following three (3) sections: Monthly/Quarterly Errors Summary: A complete description of all errors reported during the reporting period shall be provided. Information in these reports shall include the error number, date or error logged, error description, error status, summary statement, priority, severity, first affect version number, and avoidance if known. Summary of Open Errors: A summary list of all “open” errors known to exist in the current commercial version shall be provided through the end of the indicated reporting period. Information in these reports shall include the error number, date of error logged, priority, severity, and first affected version number. Summary Error Reports Distribution: A summary list of all errors closed by a released software version shall be provided with the released software version. Information in this report shall include the error number, error description, priority and severity. The above error reports shall not include software enhancements or anomalies limited to an unreleased software version. Software Error Reports Distribution The above summary error reports shall be distributed on a monthly basis to all clients in possession of a current QA&R contract and the Product Development Manager. On a quarterly basis, these summary reports shall be distributed to all clients with a current M.E.S. contract. The quarterly distribution of error reports may also be made to selected organizations within DesSoft’s dealer network designated by the Product Marketing Manager. The distribution of error reports shall be performed by the QA Administrator. QA Records The published error reports shall be maintained by the QA Administrator in the QA Library as QA Records. 35
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software QAP 5.5 Software Retirement Purpose This procedure establishes the requirements for the retirement of commercially distributed software product or a specific edition thereof. This procedure does not apply to software version update. General When a software product is no longer meeting the market demand or DesSoft’s strategic product mixes, the Product Manager shallretire such software in accordance with this procedure. Once a software is retired, DesSoft will cease distribution of the retired software, and technical support of it after a period of time as specified on the retirement form. Software Retirement Initiation. The Product Manager shall initiate and coordinate the retirement of commercially released software as follows:  Prepare the Software Retirement Form (QAF 5.5) to identify the software to be retired, planned retirement date, indicating reason(s) for the software retirement, and the period of continued technical support.  Indicate intended DesSoft replacement of equivalent software, if any, the current version, the release or anticipated release date.  Provide a brief assessment of market impacts in terms of customer needs, competitors’ product, and market share.  Provide a brief financial assessment of revenue, and the cost of revenue.  Identify all current and past customers of the software, and the latest version of the software distributed to each customer.  Recommended if customers should be offered an option to purchase the software, suggested pricing, and why. Software Retirement Review and Approval Reviewer/ Approval Product Marketing Manager VP of Engineering Chief Financial Officer Chief Technology Officer President Review Subject Adequacy of market impact statement Adequacy of replacement/ equivalent software Accuracy of financial assessment Consistency with DesSoft’s strategic plan Potential legal ramification The approved Software Retirement Form shall be distributed to the Production Manager, Sales Managers, Technical Support Manager and QA Manager. 36
  • Engineering Design Software Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Software Retirement Implementation The Product Marketing Manager shall notify all current and past customers in writing of the planned software retirement when the Software Retirement Form is approved. Such notification shall include:  Software name to be retired, and the effective date.  The option to purchase the software, option period and the purchase price, as applicable.  A statement of cessation of error reporting tracking and the period for which technical support will remain active.  DesSoft’s replacement or equivalent software product. The Product Marketing Manager shall forward a copy of the notification letter to the QA Manager. The Production Manager shall remove the retired software from the production area on the effective date. The Technical Support Manager shall issue a final software error summary report of the retired software, notify the appropriate technical support personnel of the termination date of the technical support activities of the retired software. QA Records The completed Software Retirement Form with all notification letters shall be maintained by the QA Manager as QA records in the Software QA File. Attachments Sample Software Retirement Form. 37
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software Software Retirement Form Software Name: Reason(s) for retirement: Effective Date: Recommended Termination Date of Technical Support. Market and Financial Assessment:  Recommended DesSoft Replacement Software This Version Available Remarks:  Now  Customer Option to Purchase the Retired Software Remarks: Version No:  By / / Purchase Price: See next page for a listing of current and past customers. Prepared By: Reviewed By Reviewed By Reviewed By: Approved By: Product Marketing Manager VP of Engineering Chief Financial Officer Chief Technology Officer President Date: Date: Date: Date: Date: Distribution: Production Manager, QA Manager, Sales Manager 38
  • Engineering Design Software Current & Past Customers Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Software Name: Current Customer Name, Address and Contact Person. Software Version No. Past Customer Name, Address and Contact Person Software Version No. 39
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software QAP 6.1 Contract Document Review Purpose This procedure establishes the requirements for DesSoft’s review of client contract documents which include, but are not limited to, Software Licensing Agreement, Purchase Orders and Change Orders thereof and/or service agreements. General All clients contact documents can be reviewed by DesSoft to assure that Client’s requirements and expectations are fully understood, and that DesSoft has available resources and capabilities to meet stated requirements in the contact documents. Contract Review Coordination The Sales Administration Manager is responsible for coordinating contract review activities. Incoming contract documents shall be forwarded to the Sales Administration Manger who performs an initial review of contract documents. If the contract documents contain any quality and/or technical requirements, a Contract Document Review Form (QAF 6.1) is used for the distribution of the contract documents for review. As a minimum, Contract documents shall be reviewed by the responsible Product Marketing Manager, Sales Manager, and QA Manager. Review and Comment Resolution. The technical requirements in the client contract documents shall be reviewed by the Product Marketing Manager. The commercial requirements shall be reviewed by the QA Manager. All comments shall be documented on the Contract Document Review Form. The responsible Sales Manager shall coordinate the resolution of review comments with the appropriate client personnel. The resolution review comments shall also be documented on the Contract Document Review Form. All review comments are to be resolved prior to the execution or acceptance of the contract document by the Order Entry Manger. Change Control Changes to the contract documents shall be reviewed and processed in the same manner as the original contract documents. QA Records The completed Contract Document Review Form with the contract document, shall be maintained by the Sales Administration Manager as QA records. Attachment Sample Contract Review Form. 40
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software Contract Document Review Form Client: Contract Document(s) Client Contact:  New Phone:  Existing Date:  Software Email: Please review the attached contract document and provide your comments to me no later than:  Signature:  Title  Date Reviews Technical Requirements:  Acceptance as in:  Signature  Title & Date  Comments Received Commercial Terms and Conditions:  Acceptance as in  Signature  Title and Date  Comments Received QA Requirements:  Acceptance as in  Signature  Title and Date  Comments Received No Review Required – Standard DesSoft Contract  Marketing Manager  Date 41
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software QAP 6.2 Procurement Control Purpose This procedure establishes the requirements for DesSoft’s procurement activities. General DesSoft’s procurement activities are limited to technical services and commercial items. The procurement of technical services is controlled by procurement documents such as subcontracts or service agreements. Commercial items are controlled by visual receipt inspection or technical evaluation. Procurement Document Control The manager, who requests technical service procurement, shall prepare a procurement document. The procurement document shall contain the following provisions:             Clearly defined scope of work Technical requirements Deliverables Acceptance criteria including performance parameters Documentation requirements DesSoft review and approval requirements Quality assurance requirements Progress reporting requirements Cost and schedule information Restrictions on further subcontracting QA records submittal requirements Commercial terms and conditions Procurement Document Review and Approval The procurement document shall be reviewed by a DesSoft officer and QA Manager. Both the officer and the QA Manager shall countersign the procurement document indicating their approval. Revisions to the Procurement Documents Changes to the procurement documents shall be processed in the same manner as the original procurement document. Software Tools Software tools are purchased as commercial grade (off the shelf) items used in the software development activities. Software tools shall be evaluated and classified prior to its use. Each software tool shall be categorized according to its intended use of function as defined by one of the following tool classes: 42
  • Engineering Design Software Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Standard Tools These tools are used by DesSoft for productivity improvement and/or convenience. The use of standard tools has no impact on the function of the end product. Examples of standard tools are word processors, text editors, debuggers, source code version control software, general utility packages, etc. The only control for standard tools is that each tool be used per its documented instructions. Support Tools These tools are a direct or indirect component of the end product. The use of support tools are verified with the end product controlled by the configuration management process. Examples of support tools are file compression/decompression programs, installation and configuration program generation software, etc. Verification Required Tools These tools are an indirect component of the end product and require a baseline verification. The baseline verification shall consist of a comparison of application software performance and output results with or without the new tool. Examples of verification required tools are device drivers, source code, compilers, executable linkers, database libraries, software libraries, etc. Software Tool Evaluation The requisitor of the software tool shall perform an evaluation of the software tool. The software tool evaluation and the resulting classification of the tool shall be documented on the Software Tool Evaluation Form (QAF 6.2). For Verification required tools, requisitor shall also verify the proper installation of the tool, adequacy and applicability of the tool for intended use. Consideration should also be given to the need for training. The completed evaluation form and training, if required, shall be reviewed and approved by the responsible manager of the requisitor and QA Manager prior to its use. Approved Software Tool Evaluation Form with verification documents shall be forwarded to the QA Manager. Commercial Mass Production Items The Production Manager is responsible for performing a visual inspection of all mass production items and components received, upon arrival at DesSoft’s facility. These items include disketts/tapes, published user documents, marketing material, diskette labels, security devices and binders. Defective items shall be rejected and returned to the supplier. QA Records All approved procurement documents and Software Tool Evaluation Forms shall be maintained as QA records. 43
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software QAP 7.1 Software Marketing Plan Purpose This procedure establishes the requirements for the development of software marketing plan. General When indicating on the SQP, a marketing plan is generated for a new product development or a major modification to a existing product. Marketing Plan The Product Marketing Manager shall prepare a Marketing Plan as required by the SQP. The Marketing Plan should consider the overall product objective in the SQP, and shall address the following in detail. A. B. C. D. E. F. G. H. Market Opportunity Product Competitive Analysis Comparable Product Price Ranges Validation of Customer Needs Optimum time to market Target Markets Marketing Material Development Marketing Budget Estimates Marketing Plan Review and Approval The Marketing Plan shall be reviewed by the Product Development Manager and approved by the Vice President of Marketing and Sales. QA Records The approved software marketing plan is not a QA record. However, it is recommended that the software marketing plan be maintained for information by the Product Marketing Manager. 44
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software QAP 7.2 Marketing and Promotional Material Purpose This procedure describes the process for developing marketing and promotion materials. General Each marketing collateral piece which DesSoft develops shall follow certain guidelines regarding content and design. Furthermore, all marketing material shall go through the review process prior to its release. Marketing Material Content Guideline A successful brochure delivers a message in clear and concise terms quickly. Most people Do Not Read Brochures, they skim through; read the head line, read the sub headline or two, look at the graphics, get bored and throw it away, or put it aside for “later”. The key to developing an effective brochure is to deliver your message in short phrases, with plenty of graphics. The text should be structured in tiers; the top tier should offer a promise of key benefits that mean something to a potential user. The next tier should describe the benefits in more detail, even if there is some redundancy. The next tier deals with the more technical information and features. Finally, you should include a short summary of the benefits. Other useful things to include: quotes from customers, industry researchers, oracles or journalists, used as separate text blocks. For guidance, benefits are promises of real gains that the customer can achieve when using the software; features are descriptions of the capabilities of the software. Content - All DesSoft collateral materials must achieve the following:  In the first 100 words or less, the collateral piece must deliver a clear and concise message of: a) what the product does, and b) what the key benefits are  There must be a “hook” in the first 100 words that will convince readers to want to continue on (e.g.: a promise of a major benefit that is not fully detailed).  The document must show the top five benefits as bullet points  There must be graphics that illustrate the more difficult-to-understand areas, (i.e. flow charts),  There must be clear screen shots (of at least 300dpi) that are big enough to see clearly. Guidelines: 2 sided 8.5 x 11 = 1-2 screen shots; 4 page 11 x 17 = 4-6 screen shots.  There must be enough text, but not too much. Guideline: 2 sided 8.5 x 11 = 500 words maximum; 4 page 11 x 17 = 1000 words  Use quotes from customers (at least two per brochure),  List features and system requirements in a box. 45
  • Engineering Design Software Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Layout  Be sure to follow the DesSoft “look”  Use the pre-set family of colours  Be sparing with headlines and sub heads, so that they can be prominent,  Use the pre-set family of typestyles. Ongoing Objectives ,  Upgrade the DesSoft logo to be more modern, but keep the exisiting “look”  Follow the collateral materials strategy in the product marketing plan: Corporate brochure that describes the DesSoft company and strategy overall; family brochure for each logical grouping of products; mailer for each logical grouping of products or individual product when launched.  Keep all technical spec sheet documents electronic, and available on-line worldwide (do not print or hold inventory of a vast number of documents which require upgrading constantly). Marketing Material Review Process After the Product Marketing Manage r has developed the content, the following guidelines in section 3.0, the collateral material needs to be reviewed. Participants and tasks - The following people will be involved in the decision-making process about the development of the marketing material:  Product Marketing Manager - responsible for content  Product Development Manager - responsible for the technical accuracy of the marketing material.  Executive(s) – Responsible for “ The bigger picture review”; needs to evaluate if the collateral’s content meets its objective; does it get across what we want customers/ resellers/ investors/ etc. to know or remember about DesSoft and/ or its product(s)?  Marketing Communications Manager – responsible for design, grammar, consistency in style with other collateral documents, pre-press and printing coordination.  Marketing Department Manager – responsible for final sign-off. Time schedule The review process will only allow two revision rounds after which the Marketing Communications Manager should be able to complete a final version for sign-off. QA Records There is no QA records generated in this procedure. 46
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software QAP 8.1 Order Entry Purpose This procedure establishes the requirements for customers order entry into DesSoft’s order processing system. General Customer contracts or orders with specific quality/technical requirements must be first reviewed in accordance with QAP 6.1 prior to order entry. Customer orders for DesSoft’s commercial software products or services shall be entered according to this procedure. Responsibilities The Order Entry Manager is responsible for accurate and prompt entry of all sales orders into the system. This responsibility includes the training of order entry personnel of the proper use of the system and the verification of entry accuracy. Order Entry Process  All orders received shall be forwarded to Order Entry Manager.  Each order shall contain the following information as a minimum.  Identify customer or dealer name, billing/shipping addresses, pricing schedule, currency code, and dealer commission as applicable.  Software product or service identifier, service start date and duration, quantity and unit price.  For each new license or when applicable, the serial number of security lock is identified.  Required optional information such as platform, language, discount etc. Special Cost Orders There are special procedures on the Desktop Instructions for split orders, back orders and recurring orders. These instructions shall be made available to the order entry personnel and followed to ensure proper handling of these special cases. QA Records There is no QA records generated in this procedure. 47
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software QAP 8.2 Distribution Word Order Purpose This procedure establishes the requirements for the software distribution control of any released software. General When a software product is released for distribution, the Product Marketing Manager is responsible for providing a signed software release form and the released CD to the Production Manager for duplication and distribution of the released product. The production Manager is responsible to generate a distribution word order from the order entry system. Distribution Work Order The distribution work order shall provide the following instruction:        Client and Shipping address Purchase order number, if applicable Shipping method and special instructions Item numbers Item description including software name, version, distribution media, and security lock type if applicable. Quantity Prices Packaging & Shipping The Production Manager is responsible for filling the work order. All required items should be included and verified by the production personnel. If a specific item is not currently available, the packaging list shall state that the item is on back order. The shipping package shall be clearly labeled in accordance with the word order instruction. The work order shall be initialed by the production personnel who performed the package completeness and accuracy verification. QA Records The work orders which have been completed shall be maintained by the Production Manager as QA records for one year. 48
  • Engineering Design Software Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 QAP 8.3 Production First Copy Verification Purpose This procedure establishes the requirements for the software production activities of any released software. General When a software product is released for distribution, the Product Marketing Manager is responsible for providing a signed software release form and the released CD to the Production Manager for duplication and distribution of the released product. Master CD Generation  The Product Marketing Manager is responsible for generating a master CD from released software products.  The master CD shall be verified for completeness and usability by the designated Test Engineer.  Upon successful verification of the master CD, the Test Engineer shall sign the distribution form which releases the master CD for replication of CD production.  After the CD replication, the master CD shall be submitted to the QA Manager with the Production QA Release form for records. QA Records The master CD and the completed QA Release forms shall be maintained as QA records in the QA Library. 49
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software QAP 9.1 Support Incident Management Purpose This procedure establishes the requirements for tracking and documentation of software technical support activity, for providing input to planning activities of software product development as it relates to the Technical Support Department. General DesSoft maintains a Support Incident database to track the status of all support contacts. All support incidents are logged, evaluated, responded and followed up. Any support incidents resulting in software errors or enhancement requests are transferred to the Software Defect database. Support Incident Tracking Technical support personnel who receive a support contact shall promptly log the incident in the Support Incident database in accordance with the existing database template.     The contact identification shall be entered completely so that response and follow-ups can be made. The incident description shall be entered in sufficient detail to allow independent evaluation of the reported incident. The software product shall be identified including version numbers and modules as applicable. The action status shall be entered and updated until closure. The technical support personnel shall attempt to make a preliminary determination of the required actions as follows:  The reported incident is within the technical support responsibility. The technical support personnel will respond to the caller and document the course of action taken in the Support Incident database. Where appropriate, a reference to the existing error/enhancement number from the Software Defect database shall be made in the incident report.  If a reported incident is determined to be a new software error or enhancement, the support personnel shall review the Software Defect database to verify this is not a previously entered error/enhancement. Then enter the problem into the Software Defect database, and enter the appropriate error/enhancement number in the incident report of the Support Incident database. The technical support personnel shall notify the Lead test engineer and the Product Development Manager, and obtain a committed evaluation date. The technical support personnel shall also follow up with the caller, provide the error/enhancement number and an anticipated time frame for resolution or workaround.  The reported incident involves an issue which requires evaluation by either the developer and/or test engineer. Notify the appropriate personnel for further evaluation. Document the evaluation responsibility transfer in the incident report and follow up with the caller. The assigned evaluator shall provide and document the resolution in the incident report. The technical support personnel shall follow up with the caller. 50
  • Engineering Design Software Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Support Incident Closure The technical support personnel are responsible for closing all incident reports. Any issue within an incident report, which has been logged in the software defect database, is considered closed issue in the support database. QA Records The Support Incident and Software Defect database are QA Records and shall be maintained on line. 51
  • Engineering Design Software Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 QAP 9.2 Monthly Technical Support Summary Purpose The monthly summary will provide incident details which show the type and status of the calls received by the support department as well as define errors found in the past month and possible trends that have developed because of these errors. Responsibilities Technical support personnel are responsible for timely and accurately entering the incident call data into the incident call and error databases. The Technical Support Manager is responsible for producing the monthly summary reports defined herein. Incident Summary The Technical Support Manager shall issue a monthly Incident Summary which shall consist of, as a minimum, the following information for each technical support personnel.     Source of Contact – Phone/Email/Web Type of Contact – Startup/Training/Usage/Error/Enhancement Request Status – Open/Resolved/Unresolved Time per Incident – Total Minutes/Average Minutes/ Days to Resolve The summary shall also include the following for each software product:    Number of software errors identified Number of organizations contacted Number of contacts from each organization The summary report should also provide a brief support trend analysis. Distribution of Monthly Summary Reports The Monthly Summary Report shall be distributed to respective Product Marketing Managers, Vice Presidents of Engineering, Vice Presidents of Marketing and Sales, and the QA Manager. QA Records Technical Support Monthly Summary Reports shall be maintained by the Technical Support Manager for a year as QA records. 52
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software QAP 10.1 Corrective Action Request Purpose This procedure establishes the requirements for identifying and correcting conditions adverse to quality. General Any DesSoft employee who identifies a condition or potential condition adverse to quality is required to submit a Corrective Action Request (QAF 10.1) to the QA Manager. The CAR shall provide a statement of the problem in sufficient detail. The Corrective Action Process utilized by DesSoft is depicted in Attachment A. Initial QA Review of CAR Upon receipt of a CAR, the QA Manager shall verify the existence of the identified condition, assign a CAR number, enter into the CAR log. The QA Manager shall also make an initial review of the CAR to determine if corrective action is required. Remedial Action - If remedial action is determined appropriate, the QA Manager shall assign a responsible person to prescribe remedial action necessary to correct the problem, and a completion date of the remedial action. The assignee shall complete the remedial action and return the CAR to the QA Manager. Significance Review The QA Manager shall also perform or cause to perform a significance review of the CAR. A significant condition shall be determined based on the potential safety implication, repeated problems, or process weakness. This review shall also assess the need to issue stop work order and determine whether the identified condition is reportable in accordance with 10CFR21 requirements. Such review shall be documented on the CAR form. Root Cause and Preventive Action Upon determination of a significant condition, the QA Manager shall assign a responsible person to perform a root cause evaluation and prescribe appropriate action to prevent recurrence. The assignee shall complete the required action and return the CAR to the QA Manager. CAR Closure The QA Manager shall follow-up on the implementation of CAR actions. The CAR shall be closed after the completion of all remedial and preventative action has been verified by the QA Manager. QA Records The completed CAR form and all support documents shall be maintained by the QA Manager in the QA Library as QA records. Attachment  Corrective Action Process  Sample Corrective Action Request Form – QAF 10.1 53
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software Corrective Action Process Problem Identification QA Review Action Required No Yes Remedial Action Significant Problem No Yes Perform 10CFR21 evaluation and/or issue Stop Work Yes 10CFR21 evaluation or Stop Work. No Root Cause Determination Action to Prevent recurrence 54 QA Verification & Close Monitor & Trend Analysis
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software Corrective Action Report .CAR. Reported By: Statement of problem or Non-Conformance: Page……of……….. Date: CAR Evaluation Does the CAR require issue of a Stop Work Order  No  Yes SW –  No  Yes 21- Does the CAR require client notification (10CFR21)? Affected Activities: Recommended Corrective Activities: Assigned to: Affected Software (Specific Versions) Response Due Date: Assigned By:  Quality Assurance Manager:  Date: Response Corrective Action Taken (for significant CAR, includes possible causes and action to prevent recurrence: Follow-Up Action and Closure Completion of Corrective Action verified by: Remarks: Date:  Closed By: Quality Assurance Manager  Date: 55
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software QAP 10.2 Audits and Surveillance Purpose This procedure establishes a system of audits and surveillance’s to verify QA program implementation. Internal audits and surveillance are performed to verify program compliance of software product or service. General DesSoft is subjected to audits by QA & reporting clients in accordance with client contract provisions. These client audits are governed by the clients QA procedures. DesSoft conducts internal audits to verify program compliance of a software product, or a process, or activities governed by the QAP as deemed necessary by the QA Manager. Surveillance is performed at the supplier’s facility to assess a supplier’s capability and its quality system, or to verify a supplier’s implementation of the quality system. Both the internal audit and the supplier surveillance shall be conducted under the direction of a Lead Auditor in accordance with the procedures specified herein. The audits shall be performed by personnel who are not directly involved in the activities being audited. Schedule The audit schedule shall be issued by the QA Manager annually, reviewed and revised as necessary to assure that the audit schedule is maintained current. The audit schedule shall be identifying activities to be audited and the month of the audit. Audit preparation  Audit Team Selection An audit team shall be identified prior to the beginning of each audit. This team shall consist of, as a minimum, a qualified Lead Auditor. Additional auditors and technical specialists may be added to the audit team.  Audit Plan The Lead auditor shall develop and document an audit plan for each audit. This plan shall identify the audit scope, requirements, audit team, organizations to be notified, applicable documents, audit schedule and written checklists.  Audit Notification The Lead Auditor shall notify the organization to be audited prior to the audit. This notification shall include the audit scope and schedule, and the audit team. 56
  • Engineering Design Software Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Audit Performance  Pre-Audit Conference A pre-audit conference should be conducted with the management of the audited organization. The pre-audit conference shall confirm the audit scope and schedule, set the time for the post-audit conference, and establish channels of communication.  Audit Audits shall be performed in accordance with the written checklists incorporated into the audit plan. Elements that are being audited shall be evaluated against specified requirements. Objective evidence shall be examined to the depth necessary to determine if these elements are being implemented effectively. Conditions requiring prompt corrective action shall be reported immediately to the management of the audited organization.  Post-Audit Conference At the conclusion of the audit, a post-audit conference shall be held by the audit team with the management of the audited organization. The audit results shall be presented to the audited organization during the postaudit conference. Audit Report The Audit report shall be issued by the Lead Auditor within thirty days of the audit. The audit report shall be distributed to the responsible management of the audited organization and shall include the following information, as appropriate:  Description of the audit scope.  Identification of the audit team  Identification of the personnel contacted during the audit.  Summary of audit results, including a statement on the effectiveness of the QA program elements which were audited  Description of each reported “audit finding” in sufficient detail to enable corrective action to be taken by the audited organization.  Recommended corrective action for each “audit finding” and any suggestions for general improvement to the QA program as appropriate.  Requested date for audit response. 57
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software Audit response The responsible manager of the audited organization shall coordinate the investigation of all audit findings, evaluate for the root cause of the findings, prescribe and schedule corrective action including measures to prevent recurrence. A written response to the audit report shall be submitted to the Lead Auditor prior to the requested response date. The response shall clearly state the corrective action taken and to be taken. In the event that corrective action cannot be completed prior to the audit response, the response shall include a scheduled date for completion of corrective action. Audit Follow-Up Action and Audit Close The Lead Auditor shall review audit response to determine the adequacy of the corrective action. Where necessary, a follow-up audit shall be performed. The Lead Auditor shall verify the completion of corrective action. Once all issues related to an audit are resolved, the audit shall be closed by the Lead Auditor. Auditor Qualification - Personnel shall be qualified in order to perform QA audits and surveillance as an Auditor or Lead Auditor. Auditor Training Auditor candidates shall complete an auditor training course designated by the QA Manager. Such required training shall be documented and shall include the following: Codes and Standards 10CFR50, Appendix B ASME NQA-1 ISO 9001 ISO 9000-3 Audit Techniques and Process Audit Objectives Audit Checklist Audit Performance Audit Documentation Audit Reporting Corrective Action Audit Follow-Up and Close Out Audit Management Audit Planning Organizing Audits Communication The competence of the auditor candidates shall be demonstrated through written examinantion prior to being involved in any audit. Education and Experience The auditor candidates should have a bachelor degree or equivalent. For the purpose of auditor qualification, a bachelor degree is equivalent to an associate degree plus participation in two audits as an Auditor Trainee. The auditor candidates shall have a minimum of four years of appropriate work place experience, of which at least two years being involved in QA activities. The auditor candidates shall also have participated in at least two audits, not including audits required to satisfy equivalent education requirements, as an auditor trainee prior to qualification as an Auditor. The Lead Auditor candidate shall have participated in at least three additional audits as a qualified auditor, within three years, prior to qualification as a Lead Auditor. 58
  • Engineering Design Software Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Auditor and Lead Auditor Qualification Records The QA Manager shall complete an Auditor or Lead Auditor qualification form for each person who satisfactorily completes the defined qualification requirements. This qualification form shall document the candidates name, education, experience, training courses completed, results of written examinations, and shall be approved by the QA Manager. The QA Manager’s auditor qualification shall be approved by the President. Maintenance of Lead Auditor Proficiency The QA Manager shall perfom an annual evaluation of each Lead Auditor to determine their proficiency in QA auditing. Lead Auditors shall maintain their proficiency through one or more of the following activities:    Active participation in the performance audits Review and study of codes, standards, procedures, and other documents related to QA programs and auditing. Participation in QA and/or auditor training programs The QA Manager shall document all annual evaluation. The President shall perform the annual evaluation of the QA Manager’s qualification. Lead Auditors who fail to maintain their proficiency for more than two years shall be required to re-qualify through remaining and re-examination in accordance with this procedure. Audit participation log The QA Manager shall maintain an audit participation log for each qualified Auditor and Lead Auditor. This log shall list the audit date(s), audit identification number, and auditor’s role (Auditor or Lead Auditor). QA Records The Lead Auditor is responsible for the assembly and maintenance of the audit package. The audit package shall include the audit plan, audit report, written response, completed checklists, and objective evidence of corrective action verification. When an audit is closed, the Lead Auditor shall submit the complete audit package to the QA Library. The QA Manager shall maintain the Auditor and Lead Auditor qualification files in the QA Library. 59
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software QAP 10.3 Management Assessment Purpose This procedure establishes the requirement for a periodic management assessment of DesSoft’s QA Program. General Every two years, a management review team shall evaluate the QA Program. This evaluation assesses the effectiveness of the QA program in producing quality software and related services. Management Assessment Team The management assessment team consists senior DesSoft managers and/or independent consults, or combination thereof. The president appoint a team leader from among the team members. Management Assessment Criteria The management assessment shall focus on company-wide quality issues and should be conducted using written criteria approved by the team leader. Assessment should address one or more of the following questions:  The adequacy of the QA program in addressing the scope of DesSoft’s activities.  The effectiveness of the QA program implementation in achieving the desired level of quality.  The consistency of the QA program with respect to industry and regulatory requirements.  The effectiveness of the QA organization and the QA Manager.  The flexibility of the QA procedures in addressing all DesSoft products and services.  The employee support for the QA program implementation.  The effectiveness of the management assessment process. Management Assessment Results The results of the management shall be summarized in a report including recommended actions for improvements. The management assessment report shall be submitted to the President. Executive Management Review and Action The President and other senior executives shall review the assessment report and decide on actions to be taken to improve effectiveness of DesSoft’s QA program and its implementation. QA Records The management assessment report shall be retained by the QA Manager as QA records. 60
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software QAP 10.4 Stop Work Order Purpose This procedure establishes the requirements and process of DesSoft’s stop work order. General The QA Manager has the authority to issue a stop work order when such an order is the only effective means to prevent continued non-conformance and to take immediate corrective action. Stop Work Order Issuance A Stop Work Order (SWO) shall be issued by the QA Manager when a CAR or a critical software error indicates a fundamental breakdown in the QA Program. The SWO shall be issued on the SWO form (QAF 10.5) and shall include the following:  A SWO number is assigned and entered in the SWO log.  Explicit instructions describe the exact activities to be stopped.  All managers to whom the SWO applies shall be clearly identified.  The effective date and time of the SWO shall be identified.  The reference number of the CAR or software error number which caused issuance of SWO shall be identified.  The SWO shall be authenticated with the QA Manager’s and President’s seignitures. Stop Work Order Distribution When issued, the SWO shall be distributed to all affected managers. In addition, the SWO shall be posted in the immediate work area of the stopped activities. The QA Manager shall maintain a copy of the SWO in the QA Library. Any supporting documents such as associated CAR or software error report, and any other information necessary to demonstrate the action taken to identify, evaluate, resolve the SWO, shall be maintained in the SWO file. Stop Work Order Rescission The QA Manager shall rescind the SWO once satisfied that the problem has been adequately corrected, such that continued work stoppage is unnecessary. The justification for the SWO recission shall be documented on or attached to the SWO. QA Records The SWO log and SWO files are QA records which shall be maintained by the QA Manager. Attachment – Stop Work Order Form 61
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software Stop Work Order SW - - To: Effective immediately, all managers referenced above are hereby ordered to notify affected employees and stop work on the following activities: This order remains in effect until the attached Corrective Action Request (CAR # …………..) has been returned to the QA Manager, and its corrective action implantation has been verified to the satisfaction of the QA Manager.  QA Manager:  Date:  Time: Distribution Acknowledgement  President:  VP President: Rescission CAR# ……………….has been reviewed and verified. It provides sufficient measure to correct, and preclude recurrence of the identified condition(s) adverse to quality. Therefore effective immediately, this Stop Work Order is rescinded.  QA Manager:  Date:  Time: 62
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software QAP 10.5 10CFR21 Notification Purpose This procedure establishes the client notification system of potential reportable condition under the rules of 10CFR21, “Reporting of Defects and Non-Compliance”. General Most of DesSoft’s QA & Reporting clients are subject to Section 206 (Non-Compliance) of Energy Reorganization Act 1974 for work performed in support of systems and structures important to the safe operation of their facilities. Code of Federal regulation, Title 10, Part 21, “Reporting of Defects and NonCompliance”, defines requirements for implementing section 206. While DesSoft does not directly perform any safety related activities under 10CFR21, DesSoft’s software products may be used by the QA and Reporting clients to perform analyses of safety related systems and structures. Accordingly, certain software errors and activities may create a potential reportable condition under 10CFR21. This determination of potentially reportable condition is dependent upon the application of DesSoft’s software and, therefore, can only be made by DesSoft clients. Potential Reportable Condition Evaluation When a software error is categorized as a critical error or a Corrective Action request is determined to require a 10CFR21 evaluation, the QA Manager shall be notified. The QA Manager shall make a preliminary evaluation to establish the validity of the deficiency as one which could potentially create a substantial safety hazard. Upon such determination, the QA Manager shall appoint manager, knowledgeable in the area of the identified deficiency, to complete an evaluation within 60 days. Such evaluation shall be documented in sufficient detail and detail the following: Nature of the deficiency and the safety hazard which could potentially be created. The date when information of the deficiency was obtained and the date when the evaluation is completed. The extent of the deficiency. Client Notification If a potentially reportable condition under 1OCFR21 is determined, the President and QA Manager shall be notified immediately. The QA Manager shall notify within 24 hours all QA & Reporting clients by telephone, email or fax, followed by written notification. Client notification shall include details related to the deficiency and any recommended mothod of evaluation which client should perform to determine if a substantial safety hazard exists as a result of using the deficient software. 10CFR21 Log and File The QA Manager shall maintain a 10CFR21 log which identifies each potentially reportable condition and its final disposition. The QA Manager shall assemble a file of all information related to the identification, evaluation, and notification of the potentially reportable condition. 63
  • Engineering Design Software Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Posting Requirement Current copies of the 10CFR21 requirements shall be posted in a visible location and shall not be removed without the approval of the QA Manager. Posting shall be implemented on all premises where activities are performed subject to 10CFR21. QA Records The 10CFR21 log and 10CFR21 files are QA records which shall be maintained by the QA Manager. 64
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software QAP 11.0 Quality Records Purpose This procedure establishes the requirements for the records system, collection, storage, maintenance and deposition of QA records. General Quality records are generated by the various activities performed throughout the software lifecycle, and by QA Program implementation activities. These QA records provide objective evidence of the quality of DesSoft’s software products and services, and of other support activities which affect quality. A document is considered a QA record when the document has been completed (e.g., prepared, reviewed and approved). The documents that shall become QA records have been identified throughout the QAP. Record System QA records shall be generated, collected, organized, and maintained by the responsible manager or personnel designated by that manager. The responsible manager shall submit these QA records to the QA Library in accordance with the prescribed schedule and procedures. A central repository of all submitted QA records, known as QA Library, is maintained in DesSoft’s home office under the direction of the QA Manager. The QA Library shall be located in an area capable of being locked after business hours. The access to the QA Library shall be controlled by the QA Manager and is limited to QA personnel only. A records check-out log shall be maintained by the QA Manager for any QA records removed from the QA Library. QA Records Classification QA records shall be classified as “Lifetime” or “Non-permanent” in accordance with the following definition: Lifetime records are those that meet one or more of the following criteria:  Those records which would be of significant value in demonstrating capability of an item for safe operation.  Those records which would be of significant value maintaining, reworking, repairing, replacing or modifying an item.  Those records which would be of significant value in determining the cause of an accident or malfunction of an item.  Those records that provide required baseline data for in-service verification of an item. Non-permanent records are those which do not meet the above criteria. 65
  • Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Engineering Design Software Table 12-1lists all required QA records which are classified as “Lifetime” records. All other records are “ Non-permanent”. Type QA Program Software Product Lifetime QA Records Title/Description Quality Assurance Policy Manual Quality Assurance Procedures Controlled Distribution Logs QA Audits and Surveillance Management Assessment Reports Indoctrination and Training Records Personnel Qualification Records Corrective Action Requests Stop Work Orders 10CFR21 Evalution Client Files QA Record Index Subcontract documents Software QA Files Softare Error Reports Software disks/tapes Software Version Source Codes URD and ATS word processing files Product Release Forms Software Error Database QA Record Retention All QA records shall be subject to the following retention periods: Record Classification Lifetime Non-Permanent Minimum Retention Period 5 Year 1 Year The defined retention periods are relative to the end of the life of the corresponding item (i.e, software version, QA program revision, etc.) All current QA & Reporting service clients shall be notified sixty days prior to the expiration of a document retention period. Any clients requests for purchasing copies of QA records which have reached their retention period shall be submitted to DesSoft’s QA Manager in writing prior to the indicated expiration date. 66
  • Engineering Design Software Reg. No. CK99 2635323  PO Box 53055 Wierdapark, 0149 www.dessoft.co.za  +27 12 644-2974  +27 12 644-2497 Receipt Control The QA Manager shall be responsible for receiving and processing all records. Each time a quality record is submitted for inclusion in the QA Library, the following procedures shall apply:  Verify the completeness of the QA records, such that they have been approved, and that the completeness is verifiable by means such as page numbering.  Verify that all written records are legible and have sufficient contrast for reproduction, and that all electronic/digital media are clearly labeled.  Duplicate the QA records and transmit the duplication records to off-site storage.  Enter the QA record into the QA Records Index. As a minimum, the index shall include a record identifier or the title, record classification, date of receipt, and date of transmittal to off-site storage, and disposition status. Storage, Preservation and Safekeeping All QA records in hard copy or CD shall be maintained in the QA Library in a controlled environment. A duplicate copy of these QA records shall be stored in the off-site storage facilities. Commercial release related QA records shall be sent within three months of the product release. Other QA records shall be sent annually. On-line QA records such as Software Defect and Support Incident databases shall be maintained on-line with a weekly backup as a minimum. Off-site storage location(s) shall be pre-authorized by the QA Manager and shall be sufficiently remote from the QA Library to eliminate the possibility of simultaneous exposure to a single event of hazard. In order to preclude deterioration, loss and/or damage, QA records shall be firmly attached in binders, or placed in folders or envelopes. In addition, storage arrangements shall prevent damage from moisture, pressure, temperature, humidity, magnetic fields, excessive light, insect infestation and any other reasonably foreseeable hazards. Disposition All QA records for which the specified retention period has expired or is nearing expiration, shall be subject to an annual evaluation prior to being destroyed. This evaluation shall be coordinated by the QA Manager. Should a QA record be retained beyond its retention period per this evaluation, it shall be stamped “Retired” and re-evaluated during the next annual evaluation. QA Records The QA records index and QA Record Check Out Log shall be maintained by the QA Manager as a QA record. 67