Page 1 of 7 Effective Date: 12/18/03 Software Supplier Process Requirements

Transcription

1 Page 1 of 7 Software Supplier Process Requirements 1.0 QUALITY SYSTEM FRAMEWORK 1.1 QUALITY POLICY The Seller shall document and implement a quality program in the form of Quality manual or detailed Quality procedures which are defined and auditable. The procedures shall include organization, assignments, functions, and procedures pertinent to the quality program and shall reflect current operating methods and shall be reviewed and updated with proper documentation. 1.2 ORGANIZATION The Seller shall establish policy statements defining the Quality function. The Quality function shall have sufficient responsibility, authority, and organizational freedom to identify and evaluate Quality problems and to initiate, recommend or provide solutions. Organizational charts shall be maintained and available for review. 1.3 CONTRACT REVIEW The Seller s procedures shall provide that the Seller reviews all Customer contracts and associated drawings and specifications to assure incorporation of Customers quality and technical requirements and to provide for timely and adequate planning. Seller s procedures shall identify how amendments to the contract are to be processed. 1.4 PERSONNEL TRAINING The Seller shall document and implement a methodology for personnel training and/or qualification. The Seller shall ensure personnel performing quality functions shall have received specific quality training. Records of training shall be detailed and updated regularly PROCUREMENT DOCUMENTS The Seller shall establish and document the procurement procedure and shall review outgoing procurement documents. The scope of the review procedure shall include verification that applicable quality and technical requirements are incorporated in the procurement documents. For Off the Shelf software or reusable software products, the Supplier shall document the evaluation prior to use for compliance with the requirements.

2 1.5.2 CONTROL OF SELLER S SUPPLIERS Page 2 of 7 The Seller shall establish a methodology for selection, evaluation, and control of suppliers. The suppliers shall be selected on the basis of their ability to supply product in accordance with the Supplier s requirements CUSTOMER FURNISHED EQUIPMENT / PRODUCT The Seller shall establish a documentation system for the inspection, protection and control of Customer furnished property. Such property can include software tools, test rigs or software which is supplied for embedding. Records shall be maintained as to inspection, configuration, and location of such property. The Seller shall establish procedures which include: a. examination on receipt for transit damage b. inspection for completeness, type and quantity c. functional test, if applicable d. identification, segregation and damaged or otherwise unsuitable shall not be altered, reworked or modified without prior written approval. 2.0 DESIGN PROCESS CONTROL 2.1 SOFTWARE QUALITY PLAN The Seller shall ensure that the procedures define the requirements for program quality planning. The SQA planning procedure shall include / define the following: a. Identification of the SQA requirements and the activities that are to be implemented. b. Schedule showing when each activity will be implemented. c. Specific organizational assignments. d. The interaction between SQA functions and the overall software development effect. (The SQA plan should address all phases of the software lifecycle, including change control, configuration, and software release.) e. SQA participate in the overall change process. The Seller shall update and review the SQA program with contract / engineering requirements periodically. The Seller shall ensure that the program plan identifies the SQA activities which should include all phases of the software lifecycle including: 1. Requirements definition 2. Software design 3. Implementation 4. Testing 5. The release process 6. Installation / checkout 7. Operational In the program plan, the Seller shall identify SQA activities early in the software planning process and emphasize the use of preventative measures as well as

3 Page 3 of 7 remedial controls. The program plan shall also identify all reviews including requirements, design, code, test plan, and test readiness. The Seller shall document and implement all SQA activities. 2.2 PROGRESS REPORTING The Seller shall submit program status reports to the Buyer and SQA activity shall be included as part of the overall program status. The Seller s Program Management shall maintain cognizance of their SQA activities. The Seller shall participate in milestone review activity, for all aspects of program responsibility. 2.3 SQA EVALUATIONS The Seller shall ensure that SQA tasks have been performed throughout all phases of the software performance period. At the end of each lifecycle, the Seller shall perform an evaluation of all software and associated documentation to assure that all contract requirements have been met and that appropriate development practices and conventions have been implemented. The Seller s procedures shall provide for the identification and disposition of discrepancies throughout the software lifecycles. Records of SQA activities shall be retained and be made available to the Buyer upon request. 2.4 REQUIREMENTS ACTIVITIES The Seller shall evaluate the system and software requirements specifications such that the software requirements are understandable, unambiguous, testable, and traceable to System / Subsystem / Interface requirements. The Seller shall evaluate the software interface requirements to assure that the parameter definitions are complete and consistent with the Software functional requirements, the interface specification take into account the specified error tolerance for the software process and algorithms, and that potential problems have been resolved or identified. The Seller shall evaluate the Hardware / Software interface requirement specifications to assure that the requirements are compatible with Hardware and Software design requirements. 2.5 DESIGN AND IMPLEMENTATION The Seller shall evaluate the proposed software design at the top level as well as the detailed level. During development, the Seller shall evaluate the Source Code and whether it conforms to the Seller s approved standards and procedures. The Seller shall document integration and integration testing SOFTWARE TESTING ACTIVITY The Seller shall show traceability to the established software / system requirements. Procedures shall provide for the review of all test documentation.

4 2.6.2 SOFTWARE TEST ENVIRONMENT Page 4 of 7 The Seller s SQA shall ensure that each item being tested has been documented and identified with part number, name and version identity. Each item being used in the test environment shall be documented and identified SOFTWARE TEST PARTICIPATION The Seller shall document test activities and ensure they are witnessed and verified by SQA designated representative as defined in the planning documentation. The Seller s control system shall have test anomalies recorded and entered in them SOFTWARE ACCEPTANCE ACTIVITY The Seller shall plan and document a standard for acceptance including: a. baseline acceptance criteria b. method of evaluation / validation c. hardware and software environments d. problem handling (during acceptance) e. software and hardware identification f. configuration auditing g. conformity review 3.0 SOFTWARE SUPPORT ACTIVITY 3.1 REPLICATION The Seller shall have procedures for media replication (e.g. the number of copies of each software item to be delivered; the type of media for each software item, including format and version, in human-readable form; the stipulation of required documentation such as manuals and user guides; copyright and licensing concerns addressed and agreed to.) 3.2 DELIVERY The Seller shall develop a procedure for delivery to ensure that all data items are delivered in accordance with Buyer requirements. 3.3 INSTALLATION The Seller shall develop a procedure for installation addressing the installation schedule, the availability of the Buyer s system and equipment, the contractual validation of each software installation, the formal approval and hand over on completion, how problems are handled and programming embedded devices. 3.4 MAINTENANCE The Seller shall develop procedures for software maintenance addressing the scope of maintenance activity, baselining before maintenance commences, how

5 Page 5 of 7 change requests are handled, approved and closed, and how system upgrades are integrated into the maintenance plan and who is responsible for system problems. 3.5 QUALITY SYSTEM SUPPORT ACTIVITIES The Seller s SQA shall ensure that software standards and procedures detail the software developments activity being followed. The Seller s SQA shall document reviews of the software process to ensure compliance to the software development plan and that problems and latent problems have been identified. All process changes shall be approved prior to implementation. 3.6 SUPPORT ACTIVITIES The Seller shall identify, maintain, and place software tools under configuration control. 3.7 SOFTWARE CONTROL / DEVELOPMENT LIBRARY The Seller shall document and implement procedures relating to the establishment, maintenance, and control of software. The procedures shall address the revision control process, backup process, build process, and release process. 3.8 SOFTWARE CONTROL / PRODUCTION LIBRARY The Seller shall document and implement procedures relating to the establishment, maintenance, and control / production software. The procedures shall address the revision control process, backup process, build process, release process, media process, archive process, environmental control, and virus protection. A disaster recovery process shall be defined and implemented. 3.9 CONFIGURATION MANAGEMENT The Seller shall document and implement a Configuration Management process which addresses the following: a. configuration identification b. baseline and traceability c. change control d. change review e. problem reporting f. configuration status accounting g. archive, retrieval, and release A procedure shall be established and maintained for the identification of software items during all phases of software development. The following criteria must be met: a. Each individual software item has been uniquely identified b. Each version has its own functional and technical specification.

6 Page 6 of 7 c. All development tools which affect the functional and technical specifications have been identified. d. All interfaces to other software items have been recorded e. All documents and computer files relating to the software items have been identified. f. A direct relationship between the software item and the contract requirements has been established. The Seller shall establish a software configuration index which includes the following: a. Project name b. File listing (name, version and date) c. Version description d. Sub-system identification e. System identification f. Open work / Changes required g. Waivers The Seller shall establish and maintain procedures to identify, document, review and authorize any change to the software items that have been placed under configuration management. The following shall be addressed in the procedures: a. Identification of the reason for the change. b. Changes are reviewed and the effects on other items shall be identified. c. All changes are authorized. d. Verification activities shall be identified. e. Changes have been classified The Seller shall ensure that documents are controlled throughout the entire development and verification process. Documents relative to change control shall be maintained and Seller s system shall prevent unauthorized changes as well as assure removal of obsolete documents QUALITY RECORDS The Seller shall establish a master list of all documentation so as to identify the current revision status of all documents. This master list shall include external standards and customer supplied documentation. Document changes shall be reviewed and approved by the same function organization that performed the original review and approval. Retention periods shall be established for all types of documentation. The Seller shall detail what are defined as quality records for the following processes: a) Management review b) Contract review c) Design reviews d) Design verification e) Subcontract evaluation f) Calibration records g) Non-conforming material h) Corrective actions i) Internal audits and Training

7 j) Records of Customer supplied products Page 7 of INTERNAL AUDITS The Seller shall establish a methodology for a Quality Audit Program which reviews the quality system to ensure its continuing suitability and effectiveness. Records of such reviews shall be maintained and reported to the relevant organizations management. Each audit shall be scheduled on the basis of the status and importance of the activity to be audited SOFTWARE METRICS The Seller shall establish and implement a Metrics Procedure identifying where major improvements or cost savings may be implemented. The Metrics methodology shall provide root cause data that is not maskable, sufficient data to perform meaningful analysis, and data that is easy to capture. The Seller shall implement a data capture program and a method for metrics analysis that includes a process of categorization and root cause investigation. The Seller shall implement a process improvement plan RISK MANAGEMENT The Seller shall establish and implement a Risk Management procedure including the following: a) Risk identification meeting/brainstorming b) Risk analysis c) Risk categorization d) Risk reduction e) Risk mitigation The Seller shall review risk plan and close/open new Risks as appropriate. Documentation of this shall be included in the Risk Register, Risk Data sheets, and program meetings for Risk review process.