SD-05-002 Page 1 of 10

Hospira
San Diego
SD-05-002

Current Date: 12/10/2004 Supersedes: Initial Release Effective:02/01/05

TITLE
Software Development Plan / Template

APPROVALS
Author: Marty King Date: 12/17/04
CR Initiator: Marty King Date: 12/17/04
Software Eng. Mgr: Marty King Date: 12/17/04
Site Quality Manager: Michael Carlson Date: 1/3/05
Site Director: Marty McNeela Date: 12/16/04

REFERENCE DOCUMENTS

SD-05-001 Software Development Process

SD-05-003 Software Inspection Process
GN.10-39 Product Software Development
93.G-0250 Device Development Process and Deliverables
GN.10-74 Hospira Device Design Controls Program

REASON FOR REVISION

Initial Release

ATTACHMENTS
Attachment A Software Development Plan Template
SD-05-002 Page 2 of 10

1.0 SCOPE

The Software Development Plan SOP applies to all software development products created
under the management of the Hospira-San Diego software department.

2.0 PURPOSE

The purpose of this SOP is to describe the process of creating the Software Development
Plan for a specific software program. Attachment A, Software Development Plan Template
is to be used as the starting point for creating this plan.

3.0 ABBREVIATIONS

SOP = STANDARD OPERATING PROCEDURE

SDP = SOFTWARE DEVELOPMENT PLAN

4.0 PROCESS FOR CREATING SDP

4.1 When to Create SDP

The Software Development Plan is the first document that must be completed for
every software development project. The completed plan dictates the details of the
development program. Since no two programs are exactly alike, the plan gives the
team the ability to tailor the processes and deliverables to meet the needs of the
project. The plan details the processes, plans, guidelines, and checklists that will be
used for the project as well as other details like deliverables, training, team members,
schedule etc.

4.2 Software Development Plan Template – Attachment A

4.2.1 This is the template that is to be used to create a SDP for each software
project.

4.2.2 Some of the text in the template is underlined and in italics. These are the
sections that are to be removed and replaced by specific input from the author
of the SDP.

4.3 Signoff

The SDP will be reviewed and approved by those designated on the Software
Development Plan Template in Attachment A and as required for each project’s
Document Approval Matrix.

ATTACHMENT A – SOFTWARE DEVELOPMENT PLAN TEMPLATE

The following eight pages consist of the Software Development Plan Template.
 Project Name
Software Development Plan
Document Number: XXXXXX-XXXX, Rev X

Project Name
Software Development Plan
(SDP)

Revision X

Approvals:

Author, Title Date

Name, Manager, Software Engineering Date

Name, Software Lead Date

Name, Software Quality Engineering Date

Date

Date

Date

[Link] Page 3 of 10
 Project Name
Software Development Plan
Document Number: XXXXXX-XXXX, Rev X

1.0 SCOPE

A software development plan describes the development and maintenance process, product
engineering practices, organization, management structure, activities performed, schedules,
staffing and other resources that are used to develop a specific software project. The
software development plan serves as a vehicle for planning and controlling the project, and
describes the specific processes that will be applied to a software project.

The software development plan also serves the important purpose of describing how the
site-specific software tools will be applied to the project being planned.

Describe the specific scope of the software program here.

2.0 PURPOSE

This Software Development Plan describes the process, practices, organization, schedules,
and resources that are used on Project Name to develop the software identified in Section
2.1 below.

In addition to providing traditional project planning information, this software development

plan is used to tailor the standard Software Engineering activities to fit the needs and
constraints of this project. The Project Name Software Configuration Management Plan and
the Software Quality Plan are separate documents that will be used to describe how the
SCM and Software Quality processes are applied to this project.

2.1 Project Identification

Provide a brief summary of the project objectives, the product to be delivered, major
work activities, major project milestones, and the relationship of this project to other
projects as appropriate.

3.0 DEFINITIONS

This section defines special terms, abbreviations, and acronyms used in this Software
Development Plan.

Confirm that each acronym listed below is used in this document and add others that are
used but not listed here. Delete those not used.

PRD Product Requirements Document

SCM Software Configuration Management
SDD Software Detailed Design
SDP Software Development Plan
SRD Software Requirements Definition
SQE Software Quality Engineering
SVG Software Verification Group
SVVP Software Verification and Validation Plan
SW Software
UIS User Interface Specification

[Link] Page 4 of 10
 Project Name
Software Development Plan
Document Number: XXXXXX-XXXX, Rev X

V&V Verification and Validation

4.0 REFERENCE DOCUMENTS

This section lists documents that are specifically referenced in this Software Development
Plan.

This section shall identify the compliance documents, documents referenced in the plan, and
any supporting documents required to implement, or supplement, the SDP. Ensure that the
reference document list is consistent with other project documentation. Ensure that all
documents listed in the plan are referenced. Specify documents completely including the
version and date reference.

5.0 PROJECT ORGANIZATION AND RESPONSIBILITIES

This section describes the project organization, roles and responsibilities that will be used to
execute the Project.

5.1 Organization

This section should reference the project-specific structure of the development team
using either a narrative description or an organization chart.

5.2 Roles and Responsibilities

This section identifies the individuals responsible for each major project role and
activity.

Role Responsibility Name Location

Software Engineering Has responsibility for the overall

Manager software program especially in the
areas of process compliance, staffing
and ultimate software features and
quality.
Software Engineering Has overall technical responsibility for
Lead(s) the software program and product.
Configuration Manager Supports the integration of developer’s
software and maintains the
developmental baselines for a specified
product line. Oversees all SCM
activities.
Software Quality Responsible for ensuring adherence to
Engineer all Hospira Guidelines concerning
software development.
Software Verification Responsible for ensuring that all
Manager software V&V protocols are written,
executed and traced to all software
requirements in the SRD.

[Link] Page 5 of 10
 Project Name
Software Development Plan
Document Number: XXXXXX-XXXX, Rev X

Add others as
necessary

6.0 TRAINING

All software engineers that are working on this project will be trained on applicable company-
wide Standard Operating Procedures and the following set of specific processes and/or
guidelines. Training records will be kept.

Update with applicable training and to which team members the training applies.

7.0 PROJECT MANAGEMENT

7.1 Project Objectives

Describe the project's objectives and goals. Discuss the relative priorities of budget,
schedule, and requirements.

7.2 Assumptions, Dependencies and Constraints

State the assumptions on which the project is based, the external events upon which
it is dependent, and any constraints under which the project is to be conducted.

7.3 Risk Management

Identify any risk factors associated with the project. Risk factors that should be
considered are:

 Technical Risks
 Risks due to size and complexity of the design or product
 Personnel Risks (hiring, retention, etc.)
 Contractual Risks
 Risks in achieving customer acceptance
 Organizational Risks (e.g. multiple teams communicating from multiple sites)

A strategy or a proposed action should be described for controlling or mitigating each

of the identified risks.

7.4 Project Control

Describe how the project is monitored and controlled. Reporting mechanisms,

report formats, information flows, review and audit mechanisms, and other project
control tools and techniques should be identified here.

7.5 Hazard Management

If a hazard analysis and/or plan of the entire project exists, then hazard mitigation
that is attributed to software solutions must be traced. Traceability must be
established and maintained so that one can trace from hazards to requirements to
implementation and then to test. The method for establishing this traceability must
be indicated here as well as the location of the traceability artifacts.

[Link] Page 6 of 10
 Project Name
Software Development Plan
Document Number: XXXXXX-XXXX, Rev X

8.0 PROJECT SOFTWARE DEVELOPMENT MODEL

Describe the development model (like waterfall, spiral, etc) to be utilized in the development
of this specific project. The described development model will be consistent with the
flowchart shown in SD-05-001, Software Development Process. Include any planned
techniques such as phased delivery of software, multiple development iterations, feature-
based delivery, etc. Provide the definition of the project ‘unit’ under development, and the
process steps through which those units may proceed independently for this project.

9.0 TECHNICAL METHODS AND TOOLS

Describe the technical tools, methods, and techniques to be used in the project. These
include software programs, development methods, analytical tools and techniques, design
tools, automated test tools, modeling languages and applicable design or coding standards
that must be followed, etc.

10.0 PROJECT TASKS, SCHEDULE AND ESTIMATES

This section specifies the project activities, tasks, resource requirements, and schedules
required for the project. It describes a plan for carrying out the project activities and tasks.
Schedules are not to be embedded in this document but rather a pointer to their location
must be given.

10.1 Tasks

Specify the project tasks, events, and/or milestones.

10.2 Resource Requirements

Provide, as a function of time, estimates of the total resources that are required to
complete the project. Numbers and types of personnel, computer time, support
software, computer hardware, office and laboratory facilities, travel, etc. are typical
resources specified in this subsection.

10.3 Dependencies

Specify the interdependencies of the project tasks and dependencies on external

events. Techniques such as dependency lists, critical path networks, and activity
networks, may be used here to describe these relationships.

11.0 PROJECT SOFTWARE DEVICE DESIGN CONTROL

The table that follows summarizes the minimum required deliverables that will be produced
for any project. If any deliverable on this list is determined to be unnecessary for the specific
project, it may be designated as ‘N/A’ in the table (but not deleted from the table). All
deliverables marked as ‘N/A’ will have an associated rationale for that decision. Additional
deliverables may be added as necessary.

[Link] Page 7 of 10
 Project Name
Software Development Plan
Document Number: XXXXXX-XXXX, Rev X

Document Number,
Yes/
Phase Required Deliverable Responsible
No/NA
Person, Notes

Software Requirements Document (SRD)

User Interface Requirements Document
Design (UIRD)
Input
Use Case Scenarios

Software Hazard Analysis

Software Development Plan

Design Software Quality Plan

Dev
Planning Software CM Plan

Unit Test Plan

Software Design Description (SDD)

Source Code

Software Hazard Analysis

Trace Matrices

Software Architecture
Design
Output
Unit Test Protocols and Reports

Coding Standards

Design Reviews

Code Reviews

Software Program Management Reviews

12.0 REVIEWS

This section defines the types of management, technical, and peer reviews which will be
conducted during this project.

12.1 Management Reviews

[Link] Page 8 of 10
 Project Name
Software Development Plan
Document Number: XXXXXX-XXXX, Rev X

The following software work products will be reviewed and signed off by management.
Customize this list to include only those work products that will be done for this
project.

 Software Development Plan

12.2 Technical Reviews

The following work products will be reviewed or inspected per the Software Inspection
Process (SD-05-003).

Customize this list to include only those work products that will be done for this
project.

 Software Requirements Document

 User Interface Requirements Document
 Software Design Document(s)
 Software Hazard Analysis
 Source Code Reviews
o Provide definition of code review criteria (e.g., all new and modified files)

12.3 Software Reviews and Inspections

The procedure for performing software reviews is the Software Inspection Process
(SD-05-003). The software review and inspection activity is a method that can be
used to verify the output from a development activity that cannot be verified by means
of an objective test. Records will be kept and stored in the Design History File from all
software reviews or inspections.

12.4 Software Program Management Reviews

Software Program Management Reviews will be held at critical points of the program.
These will be described here with a reference to SD-05-001, Software Development
Process.

13.0 METRICS AND MEASUREMENTS

The metrics to be collected provide indicators that track ongoing project progress, software
products, and software development processes. This section describes the quality and
process measurements that will be obtained for this project and specify the metric data that
is to be collected in order to derive the measurement. These metrics are to be collected
quarterly unless otherwise noted.

Note that this list of metrics is only a list of possible metrics that MAY be collected. This list
must be reduced to the list of metrics that are ABSOLUTELY NECESSARY and useful for
this project and nothing more.

13.1 Technical Product Quality

 Complexity – the complexity of relationships between components.

13.2 Process Quality

[Link] Page 9 of 10
 Project Name
Software Development Plan
Document Number: XXXXXX-XXXX, Rev X

 Defects discovered per testing phase.

 Defects discovered per review or inspection
 Cumulative defects discovered per release across life cycle
 Cumulative defects corrected per release across life cycle
 Defects discovered per unit time during customer use
 Requirements stability – provides an indication of the completeness, stability, and
understanding of the requirements
 The rate at which Software Change Request (SCR) are being written and resolved
 The type and severity of the SCRs
 The SCR density (the number of SCRs per software unit size)
 The number of defects in each software application/unit
 Review Results – status of action items from life-cycle review
 Inspections of software documents or code
 Peer evaluations of products, e.g., walkthroughs, technical reviews

13.3 Project Management

 Progress – how well the project is performing with respect to its schedule. Actual vs.
planned
 Effort – visibility into the contributions of staffing on project costs, schedule
adherence, and product quality. Actual vs. planned
 Cost – tracking of actual costs against estimated costs and predicts future costs.
Actual vs. planned
 Training – information on the training program and staff skills. Actual vs. planned

14.0 APPENDICES

This section could contain schedules, tables, figures, block diagrams, etc. that are referred
to in this document but are not included in the referencing sections themselves.

**END OF DOCUMENT**

[Link] Page 10 of 10