Development Procedure
For MRC-II System
This document defines the Development Procedure for the MRC-II System (Modular Robot Controller – II). This procedure is not intended to satisfy any particular regulatory requirement (e.g., ISO 9001, FDA QSR), but defines a formal design process that should be compatible with those requirements.
Although a formal design process is often not appropriate for research, it will be used for the MRC-II System because the system will be a core development platform for many research projects in Computer Integrated Surgery. In addition, the formal design process and associated documentation should facilitate Institutional Review Board (IRB) approval of a clinical trial.
Note that this Development Procedure applies to the entire system (hardware and software). The MRC-II System is a software-intensive system, however, so this procedure emphasizes the software activities.
IEEE Guide to the Software Engineering Body of Knowledge (SWEBOK).
In general, the design shall proceed through the following phases: requirements definition, design, implementation, testing. It is not necessary to fully complete one phase before beginning the next. It may, for example, be useful to implement certain key features of the system before the entire design is complete. In addition, some subsystems may be further along the design process than others – e.g., it is acceptable to have one subsystem in the implementation phase while another is in the design phase. Furthermore, it may be necessary to return to an earlier phase to make modifications if additional information is discovered during a subsequent phase.
The development shall start by documenting the Customer Requirements. In this case, the “customers” are the researchers (professors and graduate students) that may decide to use the system. Other names for this document are the System Requirements Definition, User Requirements, and Concept of Operations (IEEE Standard 1362).
The Customer Requirements will indicate the desired functionality as well as any hardware or software constraints. The customer requirements may be conceptual in nature.
The Software Requirements Specification (SRS) shall be based on the Customer Requirements and Risk Analysis and shall define the software requirements of the system. It shall include functional, performance, interface and safety specifications. This document can specify design constraints, but should not include any design details. All specifications should be unambiguous and testable.
The Risk Analysis shall identify the system hazards and methods of control. The Risk Analysis may take the form of a Failure Modes Effects Analysis (FMEA), a Failure Modes Effect and Criticality Analysis (FMECA) or a Fault Tree Analysis (FTA). A preliminary Risk Analysis shall be created at this stage of the development process and be updated as the system design evolves.
A Design Review shall be held to review the Customer Requirements, Software Requirements Specification and (preliminary) Risk Analysis. This Design Review may also include some high-level design concepts. All potential customers of the system should be invited to the Design Review.
The system design phase shall include the construction of high-level design documents, such as flowcharts, schematics, architecture diagrams and interface descriptions. It may also include hardware or software prototypes.
A Design Review shall be held to review the high-level system design. All potential customers of the system should be invited to the Design Review. This design review may be held prior to, or during, the implementation phase.
In the implementation phase, software and hardware shall be developed to meet the design objectives. Software shall be developed according to the Programming Guidelines and shall include Doxygen documentation in the source code.
Testing shall be driven by a Verification and Validation Plan and shall consist of unit (module) testing, integration testing and system testing. Tests should be traceable to all elements of the Software Requirements Specification and Risk Analysis. Test software should be maintained under version control whenever possible, so that it is available for future regression testing. Test results shall be documented in Test Reports.
The system shall be released after all tests are successfully completed. All documents (except Test Reports) and software shall be placed under version control (if not already done). Test Reports shall be kept in a Design History File that is organized by the release versions.
Proposed changes shall be reviewed to determine whether any of the documents (Customer Requirements, Software Requirements Specification, Risk Analysis, etc.) require modification and whether any tests should be repeated. The changes shall be tracked using a version control system. The changes shall be tested prior to release by performing new tests, repeating existing tests or both.
This development procedure does not include the following elements that would normally be present at a medical device company.
Most documents would require management approval in the form of signatures. This is not required in a University setting, where the “management approval” process is less formal. Furthermore, it is hoped that the elimination of signatures will lead to a paperless development process.
A medical device company would have a Quality Assurance (QA) department that would generate some of the documents (Software Quality Assurance Plan and Verification and Validation Plan) and would also typically be responsible for at least the system-level testing.
As defined in the SWEBOK (see References), a Software Quality Assurance Plan (SQAP) “identifies documents, standards, practices, and conventions that govern the project and how they will be checked and monitored to ensure adequacy or compliance.” This project will include elements normally specified in the SQAP (e.g., programming guidelines, documentation standards and configuration management), but will not require creation of a separate document.
The software developers, or their designates, will take responsibility for creating the Verification and Validation Plan and for performing the testing.
A medical device company would have a Regulatory Affairs (RA) department to manage any regulatory compliance issues. The MRC-II System does contain any regulatory issues because it is a research platform, not a medical product. This development procedure is intended, however, to produce a system and associated documentation that can be submitted to an Institutional Review Board (IRB) prior to the clinical use of any application developed with this system.
|
Rev |
Date |
Description |
|
1 |
2/11/03 |
Initial Version (changes tracked by date for now) |