Skip all navigation and jump to content Jump to site navigation Jump to section navigation.
NASA Logo + Visit NASA.gov
Assurance Process for Complex Electronics
Home Complex Electronics Background Complex Electronics Assurance Process TECHNIQUES CHECKLISTS Site Map
Life Cycle
PLANNING
V&V
REQUIREMENTS
PRELIMINARY DESIGN
DETAILED DESIGN
IMPLEMENTATION
TESTING
OPERATIONSOPERATIONS
SUPPORTING PROCESSES
PRINT THIS SECTION

 

Planning Phase

Complex Electronics Assurance Plan

The Complex Electronics Assurance Plan (CEAP) describes the activities and analyses that will be performed throughout the development (and operations) life cycle for the complex electronics. The assurance activities are coordinated with the activities of the developers, to review, assess, and analyze the various products produced by the development team. In addition, the assurance engineers ensure that the processes defined in the Complex Electronics Development Plan are followed, through the use of audits.

This page covers:

Assurance Activities

Assurance for complex electronics is implemented primarily through the following activities:

  • Documentation Review
  • Reviews, Walkthroughs, and Formal Inspections
  • Audits
  • Analyses

Documentation Review

Individual review of a document, design, or hardware description code is performed by the assurance engineer. This type of review may or may not use a checklist (if one is available). The quality of the artifact is evaluated against best practices, and the results are fed back to the author of the artifact.

Reviews, Walkthroughs, and Formal Inspections

Formal inspection is an examination of the completed product at a particular stage of the development process (such as a design), typically employing checklists, expert inspectors, and a trained inspection moderator. The objective is to identify defects in the product. There are many techniques of doing inspections, but most follow the methods developed by Michael Fagan over 20 years ago.

Reviews are an alternative to formal inspections as a process assurance method. Informal design review methods are difficult to quantify since they are generally done at the discretion of the product author, do not follow a detailed process and are not reported at the project level. Informal review is a valuable alternative if the more effective formal inspection is not used.

Walkthroughs are meetings in which the author of the product acts as presenter to proceed through the material in a stepwise manner. The objective is often raising and/or resolving design or implementation issues. Walkthroughs tend to be informal and lacking in close procedural control.

Audits

A process assurance audit is performed to determine the level of adherence to the project plans and procedures. Evaluation of the sufficiency or effectiveness of the procedures and plans is occasionally part of an audit, though normally the evaluation is performed when the procedures and plans are first produced. This type of audit examines a sampling of records to determine if procedures are being followed correctly.

Records can include formal products (e.g., official design document), informal development information, log files, tool output files, and even emails. Configuration management and change control records are also often examined during a process assurance audit.

Analyses

Analyses are performed when required to evaluate an aspect of the system, a project artifact, or the impact of changes. For complex electronics, the specific analyses will depend on the device, the level of criticality, safety implications, life cycle phase, and other factors. An analysis can be as simple as a documented expert review or as complex as a computer simulation. The method used in performing the analysis needs to be documented, as well as the results.

Creating the Assurance Plan

This web site contains the assurance process for complex electronics that will be tailored for an individual project. The CEAP is the documented result of that tailoring activity. The assurance process is found under the Lifecycle section, though other sections have explanatory text that can be helpful.

If you have not gone to the Planning page and followed the steps there (through Step 3), please do so now. If the electronic device used by the project is not complex, you do not need to create an assurance plan. If the device is complex, you will use the agreed-to classification to determine what activities to perform.

The following steps define how to turn the assurance process into an assurance plan for your project.

  1. Find an assurance plan template to use that is compatible with your project, program, or Center. You can use the template provided with this assurance process (ce-assurance-plan.doc) which covers all criticalities. Low, Moderate , and High Criticality templates have been created for your convenience.
  2. Include the following general information in the assurance plan:
    1. Purpose - why does the document exist?
    2. Scope - what is, and is not, covered by the plan.
    3. Applicable documents - list the standards and higher-level documents that apply to the assurance of complex electronics.
    4. Reference documents - list any documents that it would be helpful to have on hand when following (or reviewing) this plan.
  3. Complete the management section of the plan. This section describes how you (or your team) will perform the activities, how you will interface with other project team members, the schedule and how it ties in to the project schedule, and the resources you need to complete the tasks. Specifically address these items:
    1. The complex electronics classification (high, moderate, or low) and how it was determined.
    2. The project organization showing both internal and external interfaces.
    3. Roles and Responsibilities. This assurance process has a general roles and responsibilities table and specific ones for each life cycle phase. These tables can be used in the assurance plan as-is, or modified to fit the project.
    4. Resources used (people) for the activities. You will want to determine the tasks (#4, below) first and use that information to generate an estimate of the amount of time and effort necessary to complete the tasks.
    5. Schedule. Tie the assurance schedule to the project schedule.
    6. Training required to follow the assurance plan. This could be training in specific analyses, in the particular hardware description language (HDL) or tools used by the project, or in general process assurance.
    7. Tools used or required to perform the assurance functions. For example, static analysis software to use on the HDL code.
    8. Reporting. Discuss how the assurance engineer will report periodic status as well as audit and document review findings to the project.
    9. Risk Management. How are risks related to the complex electronics identified, tracked, and mitigated?
    10. Problem reporting. How will problems identified by audits, reviews, or analyses be reported to the project? How will the problems be tracked, and who has the responsibility for closure?
  4. Determine the tasks for each life cycle phase. Define the entrance criteria (what has to be in place before the activities can be performed), what tasks will be done, and the exit criteria (what has to happen before the life cycle phase is considered complete. This assurance process has pages that list entrance and exit criteria for each life cycle phase, and a table with assurance activities (including reviews, evaluations, and analyses). The table indicates whether a task is applicable to a particular classification. Using the tables (for requirements, preliminary design, detailed design, testing), determine (and document) what activities and analyses will be performed for the project. Review the techniques in detail to determine if they are applicable to the project.
  5. Decide on the number and types of audits. Process audits determine that the project is following their plans. List the audits that will be performed and the schedule for the audits. The schedule can be tied to project activities (e.g., Audit the configuration management process prior to the Critical Design Review).
  6. Define the documents to review. Most reviews are called out in the particular life cycle phase. However, it is a good idea to list the documents that will be reviewed by the assurance team. This list should include management documents (e.g., the CE Development Plan) and product documents (e.g., the design description or a test procedure).

The plan you have created will be reviewed by the complex electronics developer, the system engineer, and project management. The plan may also be reviewed within the quality assurance organization. Once approved, the Complex Electronics Assurance Plan guides the assurance activities for the rest of the project life cycle. Like all project plans, it is a living document and should be reviewed and updated whenever any significant changes occur in the project.

Template for a Complex Electronics Assurance Plan: ce-assurance-plan.doc



FirstGov logo + NASA Privacy, Security, Notices NASA Curator: Richard Plastow
NASA Official: Cynthia Calhoun
Last Updated: 01/28/2008