Software Development Procedure

1. PURPOSE:

1.1. This procedure provides an overall view of the activities of the software development life-
cycle and the processes associated with them. These software activities and processes support
the development of software within the company framework. If a subcontractor participates in
the development process or is outsourced, the subcontractor shall work according to this
software development life-cycle procedure or according to an equivalent process. This
document maps the various software development and support processes onto the software
development life cycle

2. RESPONSIBILITIES:

2.1. The R&D Manager has overall responsibility for all software development activities and for
implementation of this procedure.
2.2. The Software Manager is responsible for on-going development activities and
documentation of the software under development.
2.3. The Quality Assurance manager is responsible for validation activities and the archive of
software products, controlled documents and Design History File (DHF).

3. DEFINITIONS:

3.1. List of abbreviations……

Page 1 of 16
 Software Development Procedure

3.2. PROCEDURE:

3.3. Software Life Cycle Activities:

4.3.1 Management may request development or a substantial modification of a product. The
software of this product is developed in accordance with the requirements defined. The
software development procedure is based upon the software life cycle.
4.3.2 The software life cycle typically covers all phases and activities from concept,
development and product release, through updates following marketing, up until
retirement.
4.3.3 Activities in the software life cycle shall include seven phases: Concept, Requirements,
Design, Implementation, Validation, Production and Maintenance.
4.3.4 Each phase produce specific output. This output can consist of the creation, definition or
update of specific products. The output of each phase may serve as the input of the next
phase. The output may cause return to previous phase. For example, a failure detected in
the verification testing of the Design phase may result in requirement updates.
4.3.5 Each phase ends with a review to assess compliance with the requirements.
3.4. Software Development Products:
The software development can be in the form of a:
a. New product
b. Major modifications (re-engineering) of an existing product
c. New features added to an existing product
d. Bug fixes
The software can be developed for a desktop computer, embedded microprocessor, DSP
(Digital Signal Processor) or a micro-controller. The size and complexity of the software
developed determines the amount of development documentation produced to verify and
validate the software developed.
3.5. Software Development Activities:
4.5.1 The major software activities for a software development product include the following:
a. Hazard and risk analysis
b. Software requirements
c. Top level design
d. Detailed design
e. Coding
f. Unit testing
g. Integration testing
h. Validation testing
In addition, the following activities are performed:

Page 2 of 16
 Software Development Procedure

a. Software configuration management (all phases)

b. Software reviews, walkthroughs and code reviews
c. Algorithm development (when required)
d. OTS validation (when required)
e. Software archiving (after validation)
f. Software process audits (all phases)
3.6. Software Development Phases:
The outputs of the different activities during the software life cycle for all phases are shown
in the following table:
Major
Phase Major Activities Output
Milestones
 Product Definition  Feasibility Study Project Approval
 Identification of main  Initial Project
Concept product requirements requirements
 Master schedule  Development
Plan

 Identification of software  SRS SRS approval

requirements document**
 Preliminary hazard  Risk Analysis
analysis
Requirements  Primary
 Determination of “Level Traceability Analysis
of Concern” **for small embedded
 Updated master schedule projects and for Feature see
special section

 Definition of the system  SDD document

architecture (top-level)&
 IDD document
detailed design
 Test Plan-
 Updated hazard analysis
System level
Design  Test definition
 Updated Risk
 Updated master schedule Analysis
 Updated SRS
 Updated
Traceability Analysis

Page 3 of 16
 Software Development Procedure

Major
Phase Major Activities Output
Milestones
 Detailed design  Program Code
(comments in source code) (Executable + source
code)
 Coding
Implementation   Software testing
Coding Verification
report (module Level
 Test plan – Unit (module) verification)
 Updated master schedule **for Features see special
section

 Integration Level testing  Software Testing Approval

Report- Integration Release meeting
 System Level testing
Level Verification
 Updated master schedule
 Software Testing
Report - System level
Validation
 Bug List
Validation
 Updated SRS
 Updated SDD
 Updated Risk
Analysis
 Traceability
Analysis

 Design freeze  Software release Software release

Production form
 Transfer to production

 Version change due to  ECO Change approval

bugs, Customer complaint,
 Modification test
marketing considerations, etc.
report
Maintenance  Revision change could
 Updated Risk
initiate another cycle of Analysis
software life
 Traceability
Analysis

Each phase is described in its corresponding section.

3.7. Concept Phase:

During the concept phase product feasibility is being evaluated. Usually, the product
main frame is also being established. The output of this phase supplies the general inputs
(requirements, intended use, preliminary risk assessment, planning and resources
allocation) to the entire development process, with no specific implications on the SW
life cycle. As a preliminary assessment this stage performance is not obligated to the

Page 4 of 16
 Software Development Procedure

design control procedure, but it is recommended to perform a formal design review at the
end of this phase in order to approve project initiation.

3.8. Requirement Phase:

4.8.1 After Company Management has agreed on the general design of the new product,
including its features and the services provided, the R&D Manager will appoint a
Software Manager and a SW development team or decide if a subcontractor will be
involved in the process.

4.8.2 The software requirement determination will be prepared after input is obtained from the
following activities:
a. Design Input: main product requirements, including all regulatory requirements,
according to the product planned markets.
b. MRD - Marketing Requirements Determination
c. Interfaces: definition of requirements for interfacing hardware and/or software
components including required inputs, outputs, and constraints.
d. Initial Risk analysis: a preliminary hazard analysis of the software is conduct as
part of the general risk analysis for the product according to the Risk Analysis
Procedure. This shall be done to define safety hazard requirements and maintain
traceability of safety requirements. Analysis is prepared to determine if any new
potential hazards shall be introduced during the requirements specification
process. Attendees shall include the QA, R&D, Clinical and Marketing
Managers. Other attendees/reviewers, including external consultant shall be
invited according to project scope.

The project team shall prepare the Hazard analysis document and the
Software Manager shall approve the sections that are related to software.
In case this document reveals risks of an unacceptable level, design modifications
shall be performed and documented to mitigate those risks.

4.8.3 The Software Manager shall define the software requirements and prepare the SRS
(Software Requirements Specifications) document, definitions and analysis of software
requirements shall include functions, interfaces, and design constraints.

4.8.4 The format and content of the SRS document is found in the SRS template. This
template contains general information how to prepare the document. The SRS is a
controlled document and all changes to this document are managed according to the
Change Control Procedure. The SRS shall be filed it in the Design History File (DHF)
under the QA responsibility. The requirement specifications shall be provided to all
members of the software development team and shall serve as the basis for system

Page 5 of 16
 Software Development Procedure

analysis. After any updated of this document the old version shall be filed in the obsolete
design documents section of the DHF.

4.8.5 The SRS document shall be reviewed by the appropriate parties including R&D team,
marketing representatives, QA and RA. Attempt shall be made to identify incomplete,
ambiguous or conflicting requirements. In case of such requirements, the Software
Manager shall be informed and shall be asked to reconcile such conflicts.

4.8.6 Phase Output:

a. Software Requirements Specification (SRS) approved document.
b. Risk Analysis Document.
c. Primary Traceability Analysis.
d. Product schedule / Project plan verified and updated.

4.8.7 Reviews:

The SRS shall be reviewed in the Software Requirements Design review meeting, where
all relevant parties (as applicable: R&D team, Software team, Regulatory, QA and
Marketing representatives, external consultant or a representative on their behalf) can
contribute their input.
The purpose of the review is to finalize software requirements, to evaluate software
requirements for completeness, correctness, consistency, testability and traceability to
the marketing and system requirements, and to initiate software design phase. The
Software Manager is responsible for holding and summarizing the review, and tracking
action items to conclusion.

3.9. Design Phase:

4.9.1 Following the approval of the requirement specifications, review of the requirements and
analysis of the system, the software development team shall initialize the design phase.

4.9.2 The software design is comprised of top-level design and detailed design. The top-level
design determines the software architecture, behavior, interfaces and the logical structure
of the database. The detailed design defines the internal structures and interfaces of and
between the modules/classes/objects/packages/databases/algorithms/etc. The detailed
design is handled as part of the software implementation and is shown as high level
comments in the source code.

4.9.3 This phase describes the software’s logical structure, parameters to be measured,
information flow, logical processing steps, control logic, data structures, error messages
and security measures, also any supporting software and special drivers. The software
design specification shall be complete in an adequate matter so programmer is not

Page 6 of 16
 Software Development Procedure

required to make ad hoc design decisions.

4.9.4 Phase Output:

a. The interfaces with external systems are written by the Software Manager in the
Interface Design Document (IDD). The format for the IDD is found in the IDD
template, which contains the general information how to prepare the document.
b. The top-level design is recorded by the Software Manager in the Software Design
Document (SDD). The format for the SDD is found in the SDD template. This
template contains general information how to prepare the document.
c. The SDD and the IDD are controlled documents and all changes to these documents
are managed according to the Change Control Procedure. These documents shall be
filed it in the Design History File (DHF) under the control of QA.
d. The database design can be incorporated in the SDD or in a separate Database Design
Document.
e. For small embedded Software Projects, the requirements and design is recorded in
the same document, Software Requirements and Design Document (SRD). The
format for the SRD is found in the SRD template. This is also a controlled document.
f. For feature development, the requirements identification and design are handled in
the same document. The format for the Feature Development Specification (FDS) is
found in the FDS template. This is a controlled document and all changes to a feature
are controlled. A FDS usually relates to only one feature but it may include a
number of small features and bug fixes.
g. Each FDS that was implemented is incorporated into the baselined SRS, SRD
and SDD every few versions. This timeframe is dependent upon the number,
criticality and complexity of the features added to the system since the last
SRS, SRD and SDD update. Once the FDS is incorporated into the SRS, SRD
and SDD it becomes obsolete.

4.9.5 Review: After the evaluations are completed, a Design Review is held. The purpose of
the review is to finalize the software design, evaluate the software design for
completeness, correctness, consistency, and traceability to the software requirements and
to initiate the software implementation phase. Software managers, development team
and other relevant parties that can contribute to the input of the review. The review is
summarized and the summary is stored with the Quality Records as defined in the QA
Section. The Software Manager is responsible for holding and summarizing the review,
and tracking the action items to conclusion. Update of SRS, risk analysis, traceability
Analysis is performed as required.

Page 7 of 16
 Software Development Procedure

4.9.6 Test Plan-System Level document: This document shall be finalized at this stage. It is to
support software acceptance testing. Emphasis is placed on testing to assure safety
hazards have been appropriately mitigated or eliminated. The document shall be
prepared by the Software Manager. This document is also a controlled document and
shall be filed in the Design History File.

3.10. Implementation Phase (Coding Phase):

4.10.1Following the definition of the software requirements and design, the requirements shall
be broken down into functional modules or tasks and assigned to members of the
software development team.

4.10.2The purpose of this phase is to implement the SW requirements and verify that each
program unit meets requirements as defined in the design documentation. During this
phase, the following activities occur:
a. Each team member is responsible to design, write, and modify his/her assigned
segment(s) of the code under the supervision of the Software Manager.
b. Walkthroughs are held to review and evaluate the detailed design where deemed
necessary by the team leader. The walkthroughs are held as peer reviews and can be
performed in conjunction with the code reviews. The walkthrough summaries are
stored in the Quality Records as defined in the QA Section. When the walkthrough
and the code review are performed together, only one summary is recorded.
c. During the development of the modular segments of the code, each team member is
also responsible to debug the designed code sequences. The debugging process is
intended to ensure proper operation and data management and to identify any actual
or potential operating problems or logic and syntax errors.
d. Any errors or operating problems identified by the team members shall be then
corrected through logical restructuring of the code segments. Additional debugging
runs and repeated testing processes shall be conducted as needed by the team
members following each code revision, until the code has no apparent errors.
e. After the modular code segments have passed the code debugging, the code segments
shall be integrated into one comprehensive sequence that is intended to synchronize
all individual tasks identified in the requirements specifications.
f. Unit tests shall be performed on all features after review to verify satisfaction of
software requirements for safety related modules.
g. The Software Team shall plan, perform and document the Module level testing in the
safety related modules before being transferred to integration for other software
engineers to use. The functions to be tested are listed in a checklist that has been

Page 8 of 16
 Software Development Procedure

prepared beforehand. The functions found on the checklist that were tested and not
tested are to be summarized.
h. All software shall be under revision control as defined in the QA section. The test
results are filed with the Quality Records.
i. The Software Manager shall initiate code reviews for any potential risk function or
complex function.
j. The Software Manager shall check the source code to verify it is according to the
code standards.

4.10.3Phase Output:
a. Verified program source code
b. Unit Testing Plan
c. Unit Testing Results (filled checklists)

4.10.4Review: The assigned member of the Software Team shall review the applicable
program unit. The reviews shall use code walk-through for potential risk modules.

3.11. Validation Phase:

4.11.1Integration tests are performed during the integration of the software units within the
system. The purpose of the integration tests is to verify the software units being
integrated in the system with the existing software.

4.11.2This phase shall reveal that the software and system capabilities satisfy the specified
requirements. System test procedures shall be maintained and used for retesting as
required throughout the Software Maintenance Phase.

4.11.3The integration tests are performed informally by the development team. The functions
to be tested are listed in a checklist that has been previously prepared. The functions
found on the checklist that were tested and not tested are to be summarized.

4.11.4Software team shall plan, perform and document the Integration Level Testing. The
Software manager shall approve the Integration Testing Report.

4.11.5Testing should include at least two types of tests: a) Structural and b) Functional.
a) Structural tests (also known as code-based, or “white box”) are defined as
executing test cases by debugging and tracing the software's internal code. This
type of testing includes:
 Procedures to exercise the programs data structures, control and procedural
logic at the appropriate level
 Identification of “dead” code

Page 9 of 16
 Software Development Procedure

 Assurance that the programs statements and decisions are fully exercised by
testing
 For configurable SW, the integrity of the data in configuration tables shall be
evaluated for its impact on program behavior

b) Functional tests (also known as specification-based, or “black box”) are defined

as executing test cases from the requirement and functionality point of view,
regardless to the software's internal code. This test type can be applied to all
levels, from unit to system, and includes:
 Test cases in response to normal operation
 Test cases for responses to exceptional conditions
 Test cases for stress and worse case scenarios.
 The above test cases shall demonstrate the SW behavior:
 At the boundaries of its input and output domain (function and performance)
 In response to invalid, unexpected, special and sequence inputs (some of
which are obtained by random keystrokes, also known as: “Monkey tests”)

4.11.6At the end of the testing phase software documentation shall be reviewed and, if
applicable, updated. Software documentation include: SRS, SDD and Risk Analysis.

4.11.7The Traceability Analysis shall be performed to associate each test to a specific

requirement, risk and design.

4.11.8Handling errors: errors shall be documented, classified, prioritize and resolved. All the
code changes, due to errors, shall be documented. The Software Manager shall approve
this listing.

4.11.9SW verification provides objective evidence that design output of each step of the SW
life cycle meet all specification requirements. SW testing is part of the process, along
with the overall performance and documentation of life cycle activities. The magnitude
of efforts applied during the testing phase is directly correlated to complexity, criticality,
reliability, and associated risk of the SW.

4.11.10 In the testing phase, verification shall be perform at Integration Level and at System
Level as a part of the Final Software Validation Plan and Report

4.11.11 The purpose of the system tests is to validate the software’s functionality and
performance. The system tests are performed after completing the integration of all the
software units within the system.

4.11.12 Verification activities that are part of the final Validation Plan shall be performed
according to a written plan that defines the type, method, number of tests and their

Page 10 of 16
 Software Development Procedure

pass/fail criteria. This document shall identify and describe the methods, such as
inspection, analysis, demonstration or test, to demonstrate that the software complies
with the requirements expressed in the SRS. It shall be sufficiently detailed so as to
ensure maximum quality level and shall include not only valid actions with the system
but also potential failures and erroneous actions.

4.11.13 The tests are described in the Software Test Description (STD). The format for the
STD is found in the STD template. The STD is a controlled document and all changes
to this document are managed according to the Change Control Procedure. The STD
shall be filed it in the Design History File (DHF) under the control of QA.

4.11.14 The testing shall be carried out by software engineer not directly involved in the
development of the software.

4.11.15 Once the software is stable and has passed all the test plan’s tests satisfactory, it is
ready to be transferred to the production floor for an initial installation.

4.11.16 Phase output:

a. Test Reports document the results of the test process. These results shall cover the
entire testing efforts performed during the testing phase of the SW. The reports shall
be filed in the Design History File. Each test procedure run is recoded with its run
date, tester's name and pass/fail status for each item in the test procedure.
b. Bug reports present the pending problems remaining in the software. All errors
detected during testing shall be logged and classified to be reviewed later. SW QA
shall maintain the bug-list database.
c. Provide a new software version shall repeat itself as many times as necessary to
provide a reliable, stable, acceptable by QA/Product manager software revision.
d. If required the following documents shall be updated SRS, SDD, Risk Analysis and
Traceability Analysis
e. Software Version Description: after the software product has completed the software
verification and validation processes, the Software Version Description (SVD) is
prepared by the software Manager. The format for the SVD is found in the SVD
template and is a controlled document.

4.11.17 Review: A SW Review is held after the code has been completed and integration
testing is nearing completion. The purpose of the review is to evaluate the STD for
correctness, completeness, consistency, testability and traceability to all of the existing
documents (SRS, SRD, FDS, etc.) that define the requirements, and to finalize the
integration phase and initiate system tests. Software managers, quality assurance, team
leaders and other members of the development group should be represented at this

Page 11 of 16
 Software Development Procedure

review. The Software Manager is responsible for holding and summarizing the review
and tracking action items to conclusion. The review is summarized and the summary is
stored in the DHF.

3.12.Production Phase

4.12.1 The production department shall receive an installation set to perform the initial
installation. After the installation is performed, a trained tester shall check to verify that
the installation output is correct.

4.12.2 Once the software uploaded to the target device is verified, an Approval meeting is
held. The required participants shall be the R&D team, Software Manager and the QA
manager. The DHF shall be reviewed in this meeting to verify the completeness and
consistency of the documentation. All tests results shall also be reviewed at this
meeting to verify that no critical bugs shall be left open and that all required tests have
been conducted.

4.12.3 Software approval indicates that:

a. Software verification and validation processes have been completed.

b. A formal review was conducted in which the DHF was reviewed.
c. All software life cycle activities were verified against this “Software Life Cycle”
Model and approved.
d. Traceability Analysis was reviewed and approved.
e. All safety/efficacy related issues reviewed and approved.

4.12.4 This approval indicates that from the Software development team stand point, the
software is permitted to move on to the next formal Release approval phase for beta
testing or to the field by ECO.

4.12.5 Version Control: After the new software version has been formally released for
Production no additional changes or modifications shall be permitted.

4.12.6 Any change or modification to the software must be initiated, treated, and implemented
through a formal design and development process resulting in a new version of
software.

4.12.7 Phase Output: Software Approval Form with known Bugs list.

3.13.Maintenance Phase:

4.13.1 The maintenance activities may include all engineering phases previously defined,
from requirements to system test, to be performed according to Modification
characteristics.

Page 12 of 16
 Software Development Procedure

4.13.2 All changes in the Software shall be handling with the Change Control procedure.
Requested changes/modifications shall be transferred to the authority list and Software
Manager who are required to select one of the following options:
a. Reject the change/modification request,
b. Approve the change/modification request for the current version, or
c. Accept the change/modification request for later versions.

4.13.3 Updating the SRS and SDD documents shall only be necessary for major software
modifications/enhancements, namely revision change. For revision change the entire
life cycle as described above shall be considered and the applicable steps shall be
conduced (as for new software).

4.13.4 For minor changes, version change and logging of changes in the bug-list database
shall suffice.

4.13.5 Bugs discovered after a software version’s release shall be logged in the bug-list
database and accumulated until the next software release.

4.13.6 Focused Tests: A focused series of functional tests shall be run for all software
changes. These tests shall concentrate on validating the intended performance of the
change and areas possibly affected by the change. The test report shall address only
these focused tests. Other SW features, unaffected by the change, may not be retested.

a. Intended Effects Test - to verify that the intended effect has been produced.
b. Unintended Effects Test - to verify that the functions of the module being changed
shall be not compromised. This testing shall be especially focused on any safety
functions performed by, or dependent on, the module changed.

4.13.7 The type of testing performed shall be decided upon filling and approving the Change
Request. All Test results shall be documented.

4.13.8 Reviews: The number and type of reviews to be conducted for maintenance changes is
determined by the extent of the software modification. Reviews may be conducted for
the changes to assure that the changes have been successfully implemented, that the
appropriate documentation has been updated, and for changes affecting safety, the
specified level of safety testing is performed. The reviews shall be documented and a
copy placed in the design history file.

3.14.Software Configuration Management:

4.14.1 The Software manager is responsible for the software configuration activities of the
project and the QA manager is responsible for the configuration management and
approval of controlled activities.

Page 13 of 16
 Software Development Procedure

4.14.2 All software controlled documents are identified as describe in Document Control
Procedure. This includes the controlled documents mention in this procedure and other
output products such as Source Code, executable files, Installation procedures, user
manuals, etc.

4.14.3 Any changes in the output products of the software development are handled by the
Change Control Procedure. The change control is performed using and Engineering
Change Order (ECO). The form will identify the document or product being
changed and provides a description and reasons for the change. The
originator/requestor should submit all required documentation to the authority list
including the Software Manager, R&D Manager and QA manager for their approval.

4.14.4 All approved software outputs are stored in the QA archive library and documentation
center. Any approved changes will be performed from a copy of these original outputs.

4.14.5 Version Number: Any software product has an identification code and a version
assigned by QA. The version number consists of three parts: x, y, z, where, x is
the major version, y is the minor version and z is the build number. The major
version is incremented upon a major change in the software component. The
minor version is incremented upon a minor change in the software component,
and zeroed upon a major change. The build number is incremented every time a
new software release is created for testing, installation or distribution for both
internal and external purposes. The build number is zeroed upon a change in the
major and the minor versions.

Page 14 of 16
 Software Development Procedure

4. ATTACHMENTS:
4.1. Standards and Guidelines
4.2. Software Requirements Specification template
4.3. Interface Design Document template
4.4. Software Design Document template
4.5. Software Test Description template
4.6. Software Version Description template
4.7. Code Review Summary
4.8. Integration Test Form
4.9. Unit Test Form

Page 15 of 16
 Software Development Procedure

Attachment A - Standards and Guidelines

This procedure is based in the following standards and guidelines:

1. General Principles of Software Validation; Final Guidance for Industry and FDA
Staff, FDA, CDRH, 11/1/02
2. FDA Guidance for the Premarket Submissions for Software Contained in Medical
Devices, 11/5/05
3. NB-MED/2.2/Rec4, Software and Medical Devices
4. ANSI/AAMI SW68:2001, Medical device software – Software life cycle processes
5. IEC 60601-1-4:2000, Edition 1.1, Collateral standard: General requirements for
programmable electrical medical systems

Page 16 of 16