ANGLE Incorporated Quality Assurance Plan

 

Forward

This document outlines the processes and procedures to be followed by ANGLE Incorporated employees, task managers, and senior directors in planning, executing, and delivering contract products and services.  The processes and procedures include task definition, resource assignment, schedule development, task execution management, and tracking and reporting.  Within these processes and procedures quality will be defined, monitored, delivered, and documented. 

Quality assurance begins with task definition and is an implicit or explicit element in every work stage.  To deliver quality products we must all understand what the quality objectives are, how they are measured, and what we need to do to produce products and services that meet those objectives.  This document establishes quality assurance related tasks, responsibilities, and documents as essential elements within the work process. 

This is a living document.  That is, as processes and procedures are implemented and exercised on various tasks we will learn that some things work well and others don’t.  Those lessons learned will be appended to this document as notes on execution guidance and/or incorporated into this document when necessary.  Maintenance and revision of this document is the shared responsibility of the ANGLE Incorporated Technical Director and Contracts Manager. 

 

ANGLE Incorporated Task Execution

1.General

Every ANGLE contract task includes deliverables.  Task execution includes performing some set of actions that result in creating those deliverables.  Sometimes the deliverables represent services work such as engineering review, physical configuration audit, design development or design configuration analysis.  Sometimes they are physical products, executable computer programs or other software artifacts.  The detailed process for each contract deliverable will likely differ from all others but the procedure for planning and execution will be nearly identical to all others used to create like deliverables. 

2.ANGLE Task Planning and Execution Procedures

2.1. Task Definition

Each task will come with a statement of work (SOW), a list of deliverables, and a deliverable schedule.  Usually the SOW will only have sufficient specificity to ensure the desired service or product is defined in general terms.  Depending on the type of work under contract (services or products), some or a lot of additional detail will have to be put into the SOW to define the work to be done sufficiently to assign resources, create a schedule, and create the desired deliverables.  A complete task definition is essential to effectively plan and execute the task.  For instance the task to analyze the RCS of a given specific ship may include the task to create and check the model to a particular date and must include frequency, waveform, and elevation information before in can be carried out.  In addition, for every task and deliverable the quality measures must be established, and they must be both meaningful and measurable. 

2.1.1.Statement of Work

The SOW provides the basic definition of the task to be completed and the deliverables to be created and delivered.  The task manager will expand the SOW by detailing the work elements needed to complete the work and/or create the product.  This collection of work elements is captured in a Work Breakdown Structure (WBS). 

2.1.2.Deliverables

Each deliverable will be described in detail, including any references necessary to develop or configure the deliverable in compliance with the SOW.  For each deliverable any and all constituency elements will be defined in detail as needed. 

2.1.3.Quality Definition

For each element of the SOW and deliverable a quality measure will be defined.  Quality measures must be capable of being measured and be relevant.  For example the quality of an analytical model may be directly measured by accuracy and fidelity for a particular analytical process.  Defining quality as only the accuracy of the model for those features represented provides a measurable quality attribute but the attribute is not relavent without defining the required fidelity.    

2.1.4.Test Description

For all physical products, including software, product testing will be conducted.  The test program description will be sufficiently complete to define how each element will be tested, what constitutes acceptable performance, and how test results will be recorded and reported.  The test program must be sufficiently detailed to validate the performance of each product element necessary for effective product performance.  A test program will constitute an integral element of the quality assurance program when implemented. 

2.2. Task Resource Assignment

Each element in the Task Definition requires some level of work or expenditure of funds or other assets to complete.  Elements of the SOW, deliverables, Quality Assessment functions, and testing must all be explicitly covered.  The resources assigned must match the skills and capabilities needed to complete the task.  Just as a junior graphics artist won’t be effective designing a software architecture, so also the newest junior programmer won’t be successful getting the programming lead to change his or her programming style to meet specific programming and documentation requirements without a lot of managerial assistance. 

2.2.1.People with the Necessary Skills and Capabilities

Each element of the task definition has to be decomposed into work elements and mapped onto the set of skills needed to successfully complete the work.  In turn, those skills must be mapped to specific people.  When a full match cannot be created, the mapping drives a choice between hiring a person and training a current employee to do the work. 

2.2.2.Hours Assignment

In addition to being critical to creating a realistic and achievable schedule the hours estimation and assignment phase ensures that real costs are incorporated for every element of the work.  QA is not free.  Just as in every other element a qualified person, based on the effort needed, must be assigned with hours to deliver quality products.

2.3.Schedule Development

The schedule flows from the work to be done and the resources available.  A two hundred hour task that can be split between 5 people only takes a week, compared with 5 weeks and some days to make up for holidays and interruptions when the task is performed by one person.  The schedule also handles conflicts and timing between tasks and things like element tests and QA checks. 

2.3.1.By Task Element

Task elements are scheduled to occur in a sequence that accounts for time requirements, task interdependencies, and available resources.  Available scheduling programs all have functions that track task dependencies and lead/lag requirements. 

12.3.2.By Resource (People or other Assets)

Scheduling by resources often imposes constraints that would not otherwise be apparent.  It may be possible to execute several tasks in parallel except that there are not enough people or tools or workstations to do them all at the same time.  The scheduling effort becomes more complicated as the number of tasks increases and their interdependencies become more complex.  QA resources must be included in the schedule just like every other resource.  The resource loading tools in most scheduling packages will allow the task manager to find the overloads and redistribute the workload or adjust the timing. 

2.3.3.Test Programs

When testing is a part of the development project, it must be conducted as an integral part of the work to the maximum extent possible.  There will be task elements or groups of task elements that will be testable as the product is developed.  Each of those testable parts should be scheduled for testing as it completes.  Test results can then be used to correct or validate the work as it completes, simplifying final product testing and troubleshooting.  While testing is part of a QA program, QA must also be part of a test program.  QA should be used to ensure the test activities are well designed, effectively executed, and recorded. 

2.4.Tracking and Reporting

The progress of every task and project has to be tracked to ensure the effort is achieving the objectives or creating the products the customer ordered.  QA activities and results are subject to the same reporting requirements.

2.4.1.Weekly Hours by Task and Individual

Every employee records his or her time every day for every task using the daily time card.  The system does not typically decompose projects to the element level, but it does allow the task manager to track how much effort went into his task at any point in time and the manager can match the individuals with the element they are working. 

2.4.2.Weekly Progress Reports

Each employee is required to complete a weekly progress report, a brief description of the tasks they worked, and what they accomplished during the week.  The project manager is required to submit a weekly progress report on the status of his project for the week.  This report tracks progress versus the task definition and the schedule. 

2.4.3.Monthly Progress Reports

The monthly progress report is usually both a company requirement and a contract deliverable.  These reports are a compilation of the weekly reports with respect to progress on the contracted tasking and products versus schedule, cost of the work to date versus the budget to date, significant events or milestones, problems with cost, schedule, or products, and the status of deliverables (reports, analyses, systems, etc.). 

3.Quality Assurance Records

3.1.General

All QA planning records are comprised of the detailed task definitions, resource assignments, schedules, and tracking reports created for Section 2.  These QA records will be integral with the planning and execution records for each task.  QA review and deficiency documents will be kept with the task records and copies will be filed in the corporate QA reports file. 

3.2.Review and Deficiency Records

When a QA review is conducted, a Quality Assurance Review Report (QARR) will be prepared and submitted to the Project Manager and the Technical Director.  When a review determines that the a product is unsatisfactory or unacceptable for any reason a written Quality Deficiency Report (QDR) will be also be created detailing the problems discovered referenced to the product/deliverable specification/description documents.  The deficiency report will be discussed with the employee responsible for creating the product and provided to the project manager and the Technical Director. 

3.3.QDR Correction

The QDR correction plan will be created by the Project Manager and approved by the Technical Director.  The correction plan will identify resources and schedule time to correct the problem and also identify the underlying cause of the problem.  Once approved the correction plan will be incorporated into the Task Schedule, resource requirements, and a revised QA test schedule.  When the deficiency has been corrected and rechecked the QDR will be annotated with the correction information and filed with both the Project documentation and the in the corporate QA Program reports file.