Вы находитесь на странице: 1из 12

SOFTWARE DEVELOPMENT PLAN

FOR

NAME OF SOFTWARE PRODUCT

Document No. ____________ Revision ____

Plan Approvals

Written By: Date:


Developer/Programmer/Maintainer

Reviewed By: Date:


Subject Matter Expert

Approved By: Date:


Quality Assurance

Approved By: Date:


President

Company Name and Address


Document No. XXXXX
Revision X.0

REVISION HISTORY
Revision Revision ECO
Description
Level Date #
x.0 Xx/xx/xx xxx Draft release.

Page 2 of 12
Document No. XXXXX
Revision X.0
Software Development Plan

Table of Contents

1. Introduction..............................................................................................................................................4
2. Purpose....................................................................................................................................................4
3. Scope........................................................................................................................................................4
4. Level of Concern.....................................................................................................................................4
5. Software Development Process...............................................................................................................5
5.1 Planning.............................................................................................................................................5
5.2 Software Requirements Analysis.......................................................................................................6
5.3 Software Architectural Design...........................................................................................................7
5.4 Software Detailed Design..................................................................................................................7
5.5 Software Unit Implementation and Verification................................................................................7
5.6 Software Integration and Integration Testing....................................................................................8
5.7 Software System Testing...................................................................................................................9
5.8 Software Release...............................................................................................................................9
6. Organizational Structure........................................................................................................................10
7. Guidelines and Standards to be Used.....................................................................................................11

Page 3 of 12
Document No. XXXXX
Revision X.0

1. Introduction
Describe why the software is being developed.

2. Purpose
The purpose of this software development plan is to provide requirements for each life cycle process
necessary for the safe design and maintenance of name of software product.

3. Scope
This plan will address the following:

 the processes to be used in the development of the software system;

 the deliverables (includes documentation) of the activities and tasks;

 Traceability between system requirements, software requirements, software system test,


and risk control measures implemented in software;

 software configuration and change management, including SOUP configuration items


and software used to support development; and

 software problem resolution for handling problems detected in the software products,
deliverables and activities at each stage of the life cycle.

4. Level of Concern
The level of concern for name of software product is X (Class A, B or C) as definition of the level of
concern.

5. Software Development Process


Development of name of software product will be conducted in accordance with life cycle processes
defined in IEC 62304:2006. The processes and deliverables for each of the life cycle processes are as
follows:

5.1 Planning

 System requirements shall be determined and referenced.

 A process will be developed for coordinating the software development and the design
and development validation.

Page 4 of 12
Document No. XXXXX
Revision X.0
 The standards, methods, and tools used shall be determined and referenced.

 A plan shall be determined and referenced for the integration of software items (including
SOUP) and for testing during integration.

 Deliverables requiring verification, the verification tasks, the milestones at which the
deliverables are verified, and the acceptance criteria for the verification shall be determined
and referenced.

 A plan shall be determined and referenced to conduct the software risk management
process, including the management of risks relating to SOUP.

 The documents to be produced during the software development life cycle shall be
determined and referenced. For each identified document, the following information shall be
included or referenced:

o title, name or naming convention;

o purpose;

o intended audience of document; and

o procedures and responsibilities for development, review, approval and


modification.

 A plan for software configuration management shall be determined and referenced. The
software configuration management plan shall include or reference:

o the classes, types, categories or lists of items to be controlled;

o the software configuration management activities and tasks;

o the organization(s) responsible for performing software configuration


management and activities;

o their relationship with other organizations, such as software development or


maintenance; when the items are to be placed under configuration control; and

o when the problem resolution process is to be used.

5.2 Software Requirements Analysis

 Software system requirements shall be determined from the system level requirements.

 Software requirements shall include the following:

o functional and capability requirements;


Page 5 of 12
Document No. XXXXX
Revision X.0
o software system inputs and outputs;

o interfaces between the software system and other systems;

o software-driven alarms, warnings, and operator messages;

o security requirements;

o usability engineering requirements that are sensitive to human errors and training;

o data definition and database requirements;

o installation and acceptance requirements of the delivered medical device software


at the operation and maintenance site or sites;

o requirements related to methods of operation and maintenance;

o user documentation to be developed;

o user maintenance requirements; and

o regulatory requirements.

 Risk control measures implemented in software for hardware failures and potential
software defects shall be determined and referenced.

 Risk analysis shall be re-evaluated and updated as appropriate as a result of the software
requirements analysis activity.

 System requirements shall be re-evaluated and updated as appropriate as a result of the


software requirements analysis activity.

 Software requirements will be verified and documented to ensure that they:

o implement system requirements including those relating to risk control;

o do not contradict one another;

o are expressed in terms that avoid ambiguity;

o are stated in terms that permit establishment of test criteria and performance of
tests to determine whether the test criteria have been met;

o can be uniquely identified; and

o are traceable to SYSTEM requirements or other source.

Page 6 of 12
Document No. XXXXX
Revision X.0
5.3 Software Architectural Design

 The requirements for the software shall be transformed into a documented architecture
that describes the software’s structure and identifies the software items.

 An architecture shall be developed and documented for the interfaces between the
software items and the components external to the software items (both software and
hardware), and between the software items.

 If a software item is identified as SOUP, functional and performance requirements


necessary for its intended use shall be specified.

 If a software item is identified as SOUP, system hardware and software necessary to


support the proper operation of the SOUP item shall be specified.

 The segregation between software items that is essential to risk control shall be identified,
as will the method to ensure that the segregation is effective.

 The architecture shall be verified and documented that it:

o implements system and software requirements including those relating to risk


control;

o is able to support interfaces between software items and between software items
and hardware; and

o is able to support proper operation of any SOUP items.

5.4 Software Detailed Design

 The architecture shall be refined until it is represented by software units.

 A detailed design shall be developed and documented for each software unit of the
software item.

 A detailed design shall be developed and documented for any interfaces between the
software unit and external components (hardware or software), as well as any interfaces
between software units.

 The software detailed design shall be verified and documented that it:

o implements the software architecture; and

o is free from contradiction with the software architecture.

Page 7 of 12
Document No. XXXXX
Revision X.0
5.5 Software Unit Implementation and Verification

 Each software unit shall be implemented.

 Strategies, methods and procedures for verifying each software unit shall be established.
Where verification is done by testing, the test procedures shall be evaluated for correctness.

 Acceptance criteria for software units prior to integration into larger software items (as
appropriate) shall be established.

 Software units shall be tested to ensure that acceptance criteria are met.

 If present in the design, additional acceptance criteria shall be established as appropriate


for:

o proper event sequence;

o data and control flow;

o planned resource allocation;

o fault handling (error definition, isolation, and recovery);

o initialization of variables;

o self-diagnostics;

o memory management and memory overflows; and

o boundary conditions.

 Software unit verification shall be performed and the results documented.

5.6 Software Integration and Integration Testing

 A plan shall be determined and referenced for integrating software units.

 The integration plan shall be verified and documented that:

o the software units have been integrated into software items and the software
system;

o the hardware items, software items, and support for manual operations (e.g.,
human equipment interface, on-line help menus, speech recognition, voice control) of the
system have been integrated into the system.

Page 8 of 12
Document No. XXXXX
Revision X.0
 The integrated software items shall be tested in accordance with the integration plan and
the results documented.

 The integration plan shall address whether integrated software items perform as intended.

 Integration test procedures shall be evaluated for correctness.

 When software items are integrated, regression testing shall be conducted as appropriate
to demonstrate that defects have not been introduced into previously integrated software.

 Integration test records shall include the following content:

o test results (pass/fail and a list of anomalies);

o sufficient records to permit the test to be repeated; and

o the identity of the tester.

 Anomalies found during software integration and integration testing shall be entered into
a software problem resolution process.

5.7 Software System Testing

 A set of tests, expressed as input stimuli, expected outcomes, pass/fail criteria and
procedures for conducting software system testing shall be established and performed, such
that all software requirements are covered.

o Integration testing and software system testing may be combined into a single
plan and set of activities.

o Tests of combinations of requirements can be performed, especially if


dependencies between requirements exist.

 Anomalies found during software system testing shall be entered into a software problem
resolution process.

 When changes are made during software system testing, the following shall be
performed:

o repeat tests, perform modified tests or perform additional tests, as appropriate, to


verify the effectiveness of the change in correcting the problem;

o conduct testing appropriate to demonstrate that unintended side effects have not
been introduced; and

o perform relevant risk management activities.

Page 9 of 12
Document No. XXXXX
Revision X.0
 Software system testing shall be verified to ensure that:

o the verification strategies and the test procedures used are appropriate;

o software system test procedures trace to software requirements;

o all software requirements have been tested or otherwise verified; and

o test results meet the required pass/fail criteria.

 Software system test records shall include the following content:

o test result (pass/fail and a list of anomalies);

o sufficient records to permit the test to be repeated; and

o the identity of the tester.

5.8 Software Release

 Software verification shall be completed and the results evaluated before the software is
released.

 All known residual anomalies shall be documented.

 All known residual anomalies shall be evaluated to ensure that they do not contribute to
an unacceptable risk.

 The version of the software product that is being released shall be documented.

 The procedure and environment used to create the released software shall be documented.

 All activities and tasks defined in the software development plan are complete along with
all the associated documentation.

 The software product and configuration items shall be archived. Associated


documentation shall be archived for at least a period of time determined as the longer of:

o the life time of the device; or

o a time specified by relevant regulatory requirements.

 Procedures shall be established to ensure that the released software product can be
reliably delivered to the point of use without corruption or unauthorized change. These
procedures shall address the production and handling of media containing the software
product including as appropriate:

Page 10 of 12
Document No. XXXXX
Revision X.0
o Replication;

o media labeling;

o packaging;

o protection;

o storage; and

o delivery.

6. Organizational Structure
The software development team will be comprised of one project manager, one test engineer, one
quality management representative, and two support personnel for system and documentation
activities. The team will make all decisions by majority vote.

Functions of each member include the following:

 Project Manager – Develop all plans and procedures, develop and maintain project
schedule, define requirements, formulate code design, develop code, implement, compile, and test
code, integrate software with system, and generate control documents.

 Test Engineer – Perform verification and validation activities.

 Quality Management – Manage change control activities, manage document generation,


assist with document generation, periodically review and/or audit the development process, and
ensure applicable standards are current and available.

 Support – Participate in design reviews, participate on change board, and assist with
document generation.

7. Guidelines and Standards to be Used


The following guidelines and standards will be used throughout the software development process:

 Guidance for Industry and FDA Staff - Guidance for the content of premarket
submissions for software contained in medical devices (May 11, 2005)

 ISO 14971: Medical devices — Application of risk management to medical devices

 IEC 62304: Medical device software – Software life cycle processes

 IEC 12207: Systems and software engineering – Software life cycle processes

Page 11 of 12
Document No. XXXXX
Revision X.0
 IEC 15288: Systems and software engineering - System life cycle processes

Page 12 of 12

Вам также может понравиться