introduction

InnerSphere Technologies CONFIDENTIAL

Software Development Planfor the

SEDA Software ProgramJanuary 29, 2000

Revision - 1.1

Prepared for

Prepared by

Approvals

Title Printed Name Signature DateClient Representative Dr. Victoria Wise 03-21-2000

Project Team Lead Vincent Crisologo 03-21-2000

Project Member Vicente Lerum 03-21-2000

Project Member Joseph Tingzon 03-21-2000

Project Member Jay Sadler 03-21-2000

Project Member David Chin 03-21-2000

Software Development Plan, SEDA Software Program For Internal Use Only. This document contains confidential, proprietary information of InnerSphere Technologies. It may not be

copied or reproduced without the prior, written permission of InnerSphere Technologies.


Software Development Plan, SEDA Software Program Page ii For Internal Use Only. This document contains confidential, proprietary information of InnerSphere Technologies. It may not be



Revision History

Revision Date Author Description

Draft 01-20-2000 InnerSphere Technologies Development Team

Initial Document

1.0 01-29-2000 InnerSphere Technologies Development Team

Revision 1.0

1.1 03-22-2000 InnerSphere Technologies Development Team

Revision 1.1

Software Development Plan, SEDA Software Program Page ii For Internal Use Only. This document contains confidential, proprietary information of InnerSphere Technologies. It may not be



CHANGE HISTORYS

UB

ST

AN

TIV

E

REVISION - DRAFT

REVISION 1.0 REVISION 1.1

Section 5.2 outline form only

Section 5.2 describes dependencies for deliverables

Made changes in conformity with SEDA OCD2.1

Sections 5.3-5.4 unexpanded

Sections 5.3-5.4 detail resource requirements and budget/resource allocation

Additions in sections 3.2

Appendices A and B uncompleted

Appendix A – project schedule Gantt chart -- added to documentAppendix B – risk management chart --integrated into document

Appendix A – project schedule Gantt chart added

Bibliography standard MLA style

Bibliography enhanced with annotations

ST

YL

IST

IC

Single spacing Spacing set to “At least 18 points”

Single spacing

Single-spaced glossary tables

Single-spaced glossary tables, spacing after paragraphs set to 4 points

Reformatted Appendix B

Non-sequential numbering of first five pages

Sequential Roman numeral numbering of first five pages; remainder in Hindu-Arabic numerals

replaced "will" with "shall" where text implies obligation

Isolated capitalization and spelling oversights

Capitalization and spelling rectified

Updated calendar dates

Mixed fonts in Table of Contents

Consistent fonts in Table of Contents

Removed irrelevant entries in bibliography

Software Development Plan, SEDA Software Program Page iii For Internal Use Only. This document contains confidential, proprietary information of InnerSphere Technologies. It may not be



Table of Contents

1.0 INTRODUCTION...........................................................................................................71.1 PROJECT OVERVIEW.....................................................................................................7

1.1.1 Prototype Version..................................................................................................81.1.2 Operational Version...............................................................................................81.1.3 Enhanced Version..................................................................................................8

1.2 PROJECT DELIVERABLES...............................................................................................81.2.1 Operational Concept Document (OCD)................................................................81.2.1 Software Development Plan (SDP).......................................................................91.2.2 Prototype Version..................................................................................................91.2.3 System Requirements Specifications (SRS)..........................................................91.2.4 Software Design Document (SDD).......................................................................91.2.5 Operational Version...............................................................................................91.2.6 Test Plan and Procedures Document (TP)...........................................................101.2.7 User's Manual (UM)............................................................................................10

1.3 EVOLUTION OF THE SDP............................................................................................101.4 REFERENCE MATERIALS.............................................................................................11

1.4.1 Books...................................................................................................................111.4.2 Websites...............................................................................................................111.4.3 Electronic Books..................................................................................................121.4.4 Journals................................................................................................................12

1.5 GLOSSARY...................................................................................................................121.2.1 Definitions...........................................................................................................121.5.1 Acronyms.............................................................................................................141.5.2 Abbreviations.......................................................................................................15

2.0 PROJECT ORGANIZATION.......................................................................................162.1 PROCESS MODEL.........................................................................................................162.2 ORGANIZATIONAL STRUCTURE...................................................................................172.3 ORGANIZATIONAL BOUNDARIES AND INTERFACES....................................................172.4 PROJECT RESPONSIBILITIES........................................................................................18

3.0 MANAGERIAL PROCESS..........................................................................................193.1 MANAGEMENT OBJECTIVES AND PRIORITIES.............................................................193.2 ASSUMPTIONS, DEPENDENCIES, AND CONSTRAINTS..................................................203.3 RISK MANAGEMENT...................................................................................................213.4 MONITORING AND CONTROLLING MECHANISMS.......................................................223.5 STAFFING PLAN..........................................................................................................23

4.0 TECHNICAL PROCESS..............................................................................................244.1 METHODS, TOOLS, AND TECHNIQUES........................................................................24

4.1.1 Computing System...............................................................................................244.1.2 Target System......................................................................................................244.1.3 Development Methods.........................................................................................254.1.4 Development Team Structure..............................................................................25

Software Development Plan, SEDA Software Program Page iv For Internal Use Only. This document contains confidential, proprietary information of InnerSphere Technologies. It may not be



4.1.5 Programming Languages.....................................................................................264.1.6 Technical Standards.............................................................................................264.1.7 Developing and Modifying Procedures for CSCIs..............................................26

4.2 SOFTWARE DOCUMENTATION.....................................................................................264.3 PROJECT SUPPORT FUNCTIONS...................................................................................27

4.3.1 Configuration Management.................................................................................274.3.1.1 Configuration Responsibilities.........................................................................284.3.1.2 Configuration Control Process.........................................................................28

4.3.2 Software Quality Assurance................................................................................284.3.2.1 Organizational Structure...................................................................................294.3.2.2 Other Resources...............................................................................................294.3.2.3 Methods and Procedures..................................................................................29

4.3.3 Training................................................................................................................294.3.4 Testing.................................................................................................................294.3.5 Verification and Validation.................................................................................30

4.4 DEVELOPMENT ENVIRONMENT REQUIREMENTS.........................................................304.4.1 Hardware..............................................................................................................304.4.2 Software...............................................................................................................31

5.0 WORK PROCESSES....................................................................................................325.1 WORK PACKAGES.......................................................................................................32

5.1.1 Operational Concept Document..........................................................................325.1.2 Software Development Plan................................................................................325.1.3 System Requirement Specifications....................................................................335.1.4 Software Design Document, Top Level Design..................................................335.1.5 Software Design, Document Detailed Design.....................................................335.1.7 Test Plan and Procedures Document...................................................................345.1.8 User’s Manual......................................................................................................34

5.2 DEPENDENCIES............................................................................................................355.3 RESOURCE REQUIREMENTS.........................................................................................355.4 BUDGET AND RESOURCE ALLOCATION......................................................................355.5 SCHEDULE...................................................................................................................36

5.5.1 Operational Concept Document..........................................................................365.5.2 Software Development Plan................................................................................365.5.3 System Prototype.................................................................................................375.5.4 Requirements Review..........................................................................................375.5.5 System Requirement Specifications....................................................................375.5.6 Preliminary Design Review.................................................................................375.5.7 Software Design Document Top Level Design...................................................385.5.8 Software Design Document Detailed Design......................................................385.5.9 Critical Design Review........................................................................................385.5.10 Operational Version.............................................................................................385.5.11 Test Manual.........................................................................................................395.5.12 Users Manual.......................................................................................................39

Software Development Plan, SEDA Software Program Page v For Internal Use Only. This document contains confidential, proprietary information of InnerSphere Technologies. It may not be



Figures and Tables

Figure 2.2-1. Work Products Team Structure..........................................................................17Figure 2.3-2 Gen-Probe Liaisons.............................................................................................18Table 3.1-1. InnerSphere Technologies Philosophical and Ethical Principles........................20Figure 3.3-1. Risk Management Paradigm Functions.............................................................21Table 3.5-1. SEDA Staffing Requirements............................................................................23Table 4.4.2-1. SEDA Project Development Software.............................................................31Table 5.2.1. Phase Activities and Tasks..................................................................................35Table 5.4.1. Physical and Human Resource Allocation..........................................................36

Appendices

Appendix A SEDA Project Schedule....................................................................................40SEDA Gantt Chart 1 January 2000 Milestones....................................................................40SEDA Gantt Chart 2 February 2000 Milestones.................................................................41SEDA Gantt Chart 3 March 2000 Milestones......................................................................42Appendix B SEDA Software Risk Analysis Table...............................................................43Appendix B Legend.................................................................................................................48

Software Development Plan, SEDA Software Program Page vi For Internal Use Only. This document contains confidential, proprietary information of InnerSphere Technologies. It may not be



Software Development Plan, SEDA Software Program Page 7 For Internal Use Only. This document contains confidential, proprietary information of InnerSphere Technologies. It may not be



1.0 Introduction

The Software Development Plan (SDP) is the second in a series of formal, structured documents supporting the software development efforts of InnerSphere Technologies. This SDP establishes a plan for producing the Signal Event Detection Analysis software program, hereinafter referred to as "SEDA". The intended audience of this SDP is senior management and R & D staff of Gen-Probe, Inc., San Diego CA. This SDP shall also be used by InnerSphere Technologies as a master coordinating document to be referred to during the entire SEDA development effort.

1.1 Project Overview

Gen-Probe, Inc. has solicited InnerSphere Technologies to develop an integrated system for their R & D scientists and technicians for processing and analyzing data generated by the LB8® single molecule counter used for conducting bioassays.

Methods and tools currently in use for this process are inadequate for handling large amounts of data, for performing analysis of the data, and for distinguishing true signals from noise (random non-signals).

The R & D staff at Gen-Probe currently uses an ad hoc method that converts text file output from the molecule counter to an MS Excel spreadsheet. A graph report is then generated from the output. While this method is adequate for plotting 2000 data points, a typical sample involves millions of data points. In addition, the current scheme lacks any advanced internal signal processing facility. Finally, filtering out undesirable data is a tedious manual process, making the process susceptible to error, time-consuming, and ultimately, a rather expensive solution to the data processing issue.

InnerSphere Technologies shall design and implement SEDA to address both the limitations of the current system, and provide a path for evolution, i.e., to allow the system to grow and adapt as needed.

InnerSphere Technologies shall develop two versions of SEDA in accordance with the incremental process model. A prototype version shall be created first to provide the user with an initial view of program features. The user shall review and approve the prototype version before work begins on the next, design phase. The second version shall be the operational version delivered to the customer at the completion of the project. The operational version shall provide the user with the desired functionality and requirements. InnerSphere Technologies shall also offer a description of an enhanced version of SEDA to demonstrate possible upgrades in future versions of the program.




1.1.1 Prototype Version

The prototype shall introduce the graphical user interface. The user interface shall provide the look and feel of the operational version. The user shall have some interaction with the prototype to develop an understanding of how the final product will be presented.

1.1.2 Operational Version

The operational version shall include all the features included in the prototype version plus all the functionality required by the user. The operational version shall define a means for efficient short-term storage of collected information, namely a database. The operational version shall be able to calculate normalized statistical standard deviation and normalized statistical mean as part of its statistical functions. It shall also allow the user to perform some signal processing and curve fitting.

The SEDA software shall include a complete and comprehensive set of printed user documentation. These documents shall include a Quick Start Guide, a Tutorial, and a Reference Manual. In addition, SEDA shall provide a link to an on-line help viewer.

1.1.3 Enhanced Version

Besides all of the features of the operational version, the enhanced version may include multiple test stations for simultaneous testing and the ability to perform batch processing. The enhanced version may allow generation of various advanced statistical analysis functions, and offer advanced signal processing.

The enhanced version may also include Internet/Intranet capabilities. Future versions may also support various OSs such as UNIX or Macintosh. Real-time data analysis, support for additional instrumentation, increased security features, and acceptance of additional data input types may also be considered in future enhancements.

1.2 Project Deliverables

1.2.1 Operational Concept Document (OCD)

The OCD is the introductory document outlining SEDA. It presents the InnerSphere Technologies problem-solution strategy, and identifies hardware and software components of SEDA. The OCD also explores the formal statement of the problem, the characteristics of the user, the external processes to be provided, proposed product features and criteria for acceptance. The document is scheduled for delivery on January 29, 2000.




1.2.1 Software Development Plan (SDP)

The SDP introduces the InnerSphere Technologies development team, and elements of SEDA. The SDP discusses project management issues as applied to SEDA, including the organization of the project; managerial, technical and work processes, and the proposed development schedule. The document is scheduled for delivery January 29, 2000.

1.2.2 Prototype Version

The prototype version of SEDA shall demonstrate the basic capabilities of the application. It shall serve as a tool to consolidate a minimum set of project requirements as well as to discover and address any misunderstandings between the customer and developer in regard to the system's functionality. The prototype is scheduled for delivery February 2000.

1.2.3 System Requirements Specifications (SRS)

The SRS shall identify the specific requirements for SEDA. These include functional, external, interface, performance, and database requirements, as well as a discussion of ways to validate these requirements. Also presented are design constraints and process diagrams. This document is scheduled for delivery February 24, 2000.

1.2.4 Software Design Document (SDD)

The SDD provides two design views of the deliverable product for SEDA. The first view, known as the SDD - Top Level Design (SDD-TLD), contains an overview of the Computer Software Configuration Item (CSCI) for SEDA, along with information about the CSCI architecture, general constraints, assumptions and dependencies. The second view of the SEDA design is the SDD-Detail Design (SDD-DD), which covers the CSCI data and data files, as well as traceability requirements. The SDD shall formalize and define the structural models, data flows, functional processes, and data models of the software product. This document is scheduled for delivery March 7, 2000.


The operational version of the SEDA code shall be developed for delivery to the customer, following testing and implementation. SEDA shall consist of a Graphical User Interface (GUI) for file selection and data presentation, data cataloguing, storage and retrieval. The operational version shall be able to calculate normalized statistical standard deviation and normalized statistical mean as part of its statistical functions. It shall also allow the user to perform some signal processing and curve fitting. The lifecycle of SEDA shall pass from the analysis and design phase to the implementation phase when work on the operational version begins.




1.2.6 Test Plan and Procedures Document (TP)

The TP defines the test objectives, build plan integration, test cases, and tests for all specific processes and system requirements for SEDA. The TP shall cover environmental needs, responsibilities, staffing and training needs, scheduling, risk and contingency plans. Implementation of the testing phase shall be initiated once the operational version of SEDA is functional. The TP is scheduled for completion and delivery March 22, 2000.

1.2.7 User's Manual (UM)

The UM introduces SEDA to the prospective user. The UM informs the end users of hardware and software requirements, provides a brief tutorial and glossary, and identifies error messages likely to be encountered by the user. The UM shall further be divided into a Quick Start Guide, a Tutorial and a Reference Manual. The UM shall be provided in the form of both a printed manual, and an on-line help system. The UM shall assist SEDA users with the operation of the application. This document is scheduled for completion and delivery March 18, 2000.

1.3 Evolution of the SDP

After its initial draft, this SDP shall be revised as required to handle situations that include changes to the scope of the project. Regardless of the reason for the evolution of this document, both the customer and the development team must agree on the proposed changes, and both parties must approve the changes before they are put in effect.

The process by which modifications to this document occur is as follows:

Any corrections, additions or omissions shall be presented on a hard copy of the current version of this document.

Items/sections to be replaced shall have one red line drawn through them with the replacement text clearly associated with them.

Items/sections to be deleted shall have one red line drawn through them. Items/sections to be added shall be clearly displayed with their desired placement clearly

noted.

The InnerSphere Technologies' project leader shall be assigned ownership of the SDP during the development process. The owner of this document shall be responsible for delegating maintenance tasks to other team members as required. However, it remains the responsibility of the owner to assimilate the changes of those sections into the official version. Current versions of the documents shall reside on our development server.




1.4 Reference Materials

NOTE: for a more detailed annotated bibliography, consult http://SE660.home.att.net/integrated_annotated_bibliography.htm. Alternatively, a reprint of the bibliography is located in Appendix D of the SEDA Reference Manual.

For the purposes of this SDP, the following sources and references shall apply:

1.4.1 Books

Beizer, B. (1990) Software Testing Techniques, 2nd ed. International Thomson Computer Press. Classic textbook with a comprehensive and modern approach to software testing tools, thinking, strategies, and procedures.

McConnell, S. (1998) Software Project Survival Guide. Microsoft Press.A Microsoft insider's practical view of how to succeed in software projects.

Pressman, Roger S. (1996) Software Engineering: A Practitioner's Approach, 4th ed. McGraw Hill Book Company.Textbook and venerated standard reference for software engineering theory and practice.

Sommerville, I. (1996) Software Engineering, 5th ed. Addison-Wesley.Textbook and standard reference for software engineering theory and practice.

1.4.2 Websites

NOTE: Where no publication date is indicated at the site, these documents were accessed via the (World Wide Web) WWW in January 2000.

Molecular Machines, Inc. Areas of Application: Pharmaceutical High Throughput Screening, Medical Diagnostics, Research; Products-Main: LB8® - Single Molecule Counter, Plates; Technology-Main. root URL: http://molecular-machines.com/ (pages in order: root + areaspharmmain.htm, areasmedmain.htm, areasresmain.htm, prodsmmain.htm, prodmmmain.htm, techclmain.htm ) Several webpages describing the LB8® - Single Molecule Counter, output of which is manipulated by software built for the SEDA project.

National Instruments. (January, 2000) Product Catalog: LabWindows/CVI Full Development System for Windows. http://sine.ni.com/apps/we/nioc.vp?lang=US&pc=mn&cid=2460



http://sine.ni.com/apps/we/nioc.vp?lang=US&pc=mn&cid=2460

http://sine.ni.com/apps/we/nioc.vp?lang=US&pc=mn&cid=2460

http://molecular-machines.com/

http://SE660.home.att.net/integrated_annotated_bibliography.htm


LabWindows CVI (C for Virtual Instrumentation) was developed to add more flexibility to the existing LabView product, with the flexibility to add customized C language routines

1.4.3 Electronic Books

Project Management Institute. (1996) Guide to the Project Management Body of Knowledge. http://www.pmi.org/publictn/pmboktoc.htmTextbook for the project management course, systematizing common practices in the field into a "body of management knowledge".

Orfanidis, S. Introduction to Digital Signal Processing. Prentice Hall: Upper Saddle River, NJ. http://www.ece.rutgers.edu/~orfanidi/intro2sp.html#pub A book freely available on the Internet, investigating various aspects of digital signal processing.

Smith, S. The Scientist and Engineer’s Guide to Digital Signal Processing. California Technical Publishing. http://www.dspguide.com/ DSP techniques, their applications, and explanations of algorithms used for processing.

1.4.4 Journals

Craig, R. (January 20, 1999) "Windows 2000 Database Choices", ENT, v 4, i 2, pp Seeger, S.. (April 1998) "Single molecule fluorescence: High Performance Molecular

Diagnosis and Screening", BIOforum, pp 179-185. (Translated from German.)Seminal paper outlining the advantages of LIF spectroscopy for single molecule detection over CCD technology.

1.5 Glossary

1.5.1 Definitions For the purposes of this SDP, the following definitions shall apply:

Access97 a desktop relational database management system by Microsoft

ad hoc for the special purpose presently at hand.

Analyte the specific biomolecular substance being tested

Assay biochemical/biomolecular test or protocol

Blackboard.com an web-based education delivery system

Build plan a plan listing all compiling options for a software product

Confocal having the same foci (as "confocal lens")

Confocal Laser-induced Fluorescence

a high-sensitivity, large dynamic range and high spatial resolution bioanalytic technology for screening and identifying



http://www.dspguide.com/

http://www.ece.rutgers.edu/~orfanidi/intro2sp.html#pub

http://www.pmi.org/publictn/pmboktoc.htm


Spectroscopy (LIF) single molecules in an analyte by measuring the molecule's fluorescence in reaction to laser stimulation and specific marker substances

Database a collection of data organized especially for rapid search and retrieval

Development server the (usually high-performance) computer used by the software product developer

Excel a generic spreadsheet program tightly integrated with other Microsoft Office Products

Fluorescence the excitation of a molecule with a wavelength of light causing the molecule to emit light at a different wavelength

Fourth Generation (Programming) Language

a non-procedural high-level language built around database systems

Front end the "public" end of an application; usually corresponds to "client"; the part of the application with which user has most interaction

Gantt chart a bar graph

Hyper Text Markup Language (HTML)

a subset of SGML used for rendering text and format information viewable by web browsers; allows documents (or multimedia) to be statically linked to local or remote locations

Incremental builds a process in which successive iterations in the development of the software product build on a common base, expanding outward

Laser light amplification by stimulated emission of radiation

LB8® - Single Molecule Counter

instrument manufactured by Molecular Machines, Inc. that implements the confocal LIF spectroscopy technology

Pentium an 8x86 family microprocessor first introduced in 1995 by intel

pro bono done or donated without charge; free:

Regression testing repetition of tests to show lack of side effects from adding a feature

SGML a markup language for defining structure and managing documents in electronic form

Software Development Plan

this document (also known as Software Project Plan or Software Project Management Plan)

Visual Basic a RAD-oriented "visual" programming language by Microsoft, offering drag-and-drop code generation




1.5.1 AcronymsFor the purposes of this SDP, the following acronyms shall apply:4GL Fourth Generation (Programming) Language

ASCII American Standard Code for Information Interchange (here, refers to an encoding format)

CDR Critical Design Review

CM Configuration Manager, Configuration Management

COTS Commercial Off The Shelf

CSCI Computer Software Configuration Item

CSU Computer Software Unit

DBA Database Administrator

GUI Graphical User Interface

HTML Hypertext Markup Language

LAN Local Area Network

MS Microsoft

NIC Network Interface Card

OCD Operational Concept Document

PC Personal Computer

PDR Preliminary Design Review

RAD Rapid Application Development

RAM Random Access Memory

RR Requirements Review

SCCB Software Configuration Control Board

SCM Software Configuration Manager

SDD Software Design Description

SDD - DD Software Design Description - Detail Design

SDD - TLD Software Design Description - Top Level Design

SDF Software Development Folder

SDL Software Development Library

SDP Software Development Plan

SEDA Signal Event Detection Analysis (software program)

SEE Software Engineering Environment




SEI Software Engineering Institute

SP/CR Software Problem/Change Reports

SPMP Software Project Management Plan

SQA Software Quality Assurance

SRS System Requirements Specifications

STE Software Test Environment

SWM Software Manager

TP Test Plan

UM User's Manual

WWW World Wide Web

1.5.2 AbbreviationsFor the purposes of this SDP, the following abbreviations shall apply:CA California

e.g. ex gratis (for example)

GB gigabytes (109 bytes)

i.e. id est (that is)

Inc. Incorporated

MB megabytes (106 bytes)

Mbps megabits (106 bits) per second

MHz megahertz - 106 cycles per second

R&D research and development




2.0 Project Organization

2.1 Process Model

InnerSphere Technologies shall follow an incremental process model. According to the definition given by Pressman (1996), this model uses the "elements of the linear sequential model (analysis, design, coding and testing) with the iterative philosophy of prototyping." (p. 37). The incremental model shall allow InnerSphere Technologies to create a core product upon which subsequent iterations of the software shall be based. At the end of each increment, Gen-Probe shall be able to use and evaluate the product. Feedback from user-product interaction shall allow Gen-Probe and InnerSphere Technologies to refine SEDA by incorporating new and improved features.

Figure 2.1-1. Incremental Process Model (adapted from Pressman [1996])



Second Imcrement

…

SYSTEM/INFORMATI

ON ENGINEERI

NGANALYSIS

CODE TESTCore Product

ANALYSIS

CODE TESTDESIGN

ANALYSIS

CODE TESTDESIGN

First Imcrement

DESIGN


2.2 Organizational Structure

The SEDA project leader shall assign work products to task leaders. The task leader shall have the overall responsibility of scheduling, allocating resources, organizing, and motivating the team. The following chart shows the hierarchical flow of authority in the

general SEDA work structure:Figure 2.2-1. Work Products Team Structure

2.3 Organizational Boundaries and Interfaces

A pseudo-contractual arrangement shall be established between a Gen-Probe scientist and InnerSphere Technologies' technical lead. The technical lead shall convey project requirements to the project leader, who shall delegate the work to the project task leaders. Assigned tasks shall be accomplished in accordance with the contract stipulations. The project leader shall coordinate the configuration management, software quality assurance, test and evaluation, and documentation management groups. This structure is represented graphically in the following chart:



TASK LEADER

TEAM MEMBER

TEAM MEMBER

TEAM MEMBER

PROJECT LEADER


Figure 2.3-1. Support Group Organization

The following chart lists Gen-Probe liaison employees available for contact by InnerSphere Technologies. Task leaders are authorized to request project-specific information from these liaisons, as shown in the following chart:

Figure 2.3-2 Gen-Probe Liaisons

2.4 Project Responsibilities

For each phase of software design, a member of InnerSphere Technologies shall be designated as a task leader. This leader shall be responsible for following the assigned task from inception to completion. Quality assurance, configuration management, test and evaluation, and documentation management functions of the project shall be integrated into the overall design.



GEN-PROBE LIAISON

EMPLOYEEWAI LAMMICK BECKER

VICENTE LERUM

PROJECT LEADER

SOFTWARE QUALITY ASSURAN

CE

CONFIGURATION

MANAGEMENT

TEST AND EVALUATI

ON

DOCUMENTATION

MANAGEMENT


3.0 Managerial Process

The managerial process for SEDA shall be guided by a controlled, decentralized approach. The group leader shall coordinate and assign specific tasks to the other group members, or to a task leader. The group leader and assigned task leaders shall assume responsibility for: Adhering to organizational policies established in this document Following the documented plan and software development process description Allocating adequate human and material resources Delegating authority Training people impacted by the project Quantifying and objectively reviewing the software development process and its work

products Reviewing project status with appropriate levels of management and taking corrective

action

3.1 Management Objectives and Priorities

The primary InnerSphere Technologies management objective is the completion of SEDA as scheduled. To achieve this objective, the development team shall take into account the work environment constraints, as well as utilizing open intra- and inter-group communications, skills development, training, and team solidarity building.

Many internal project risks can be effectively minimized by insisting on complete and open communications. The following table lists key philosophical and ethical principles guiding InnerSphere Technologies' project.




GLOBAL PERSPECTIVE

Viewing software development within the context of the larger systems-level definition, design, and development.

Recognizing both the potential value of opportunity and the potential impact of adverse effects.

FORWARD-LOOKING VIEW

Thinking toward tomorrow, identifying uncertainties, anticipating potential positive or negative outcomes.

Managing project resources and activities while anticipating uncertainties.

OPEN COMMUNICATION

Encouraging free-flowing information at and between all project levels, and between teams on other projects.

Enabling formal, informal, and impromptu communication. Using processes that empower the individual (bringing unique

knowledge and insight to identifying and managing risk).

INTEGRATED MANAGEMENT

Making risk management an integral and vital part of project management.

Adapting risk management methods and tools to a project's infrastructure and culture.

CONTINUOUS PROCESS

Sustaining constant vigilance. Identifying and managing risks routinely through all phases of

the project's life cycle.

SHARED PRODUCT VISION

Mutual product vision based on common purpose, shared ownership of responsibility, and collective communication.

Results-oriented focus.

TEAMWORK Working cooperatively to achieve common goals. Pooling talents, skills, and knowledge.

Table 3.1-1. InnerSphere Technologies Philosophical and Ethical Principles

Awareness and application of these principles of empowerment enable the development team to implement SEDA successfully and deliver the product on or ahead of schedule.

3.2 Assumptions, Dependencies, and Constraints

The development team is dependent upon Gen-Probe to provide sample data to be analyzed by the software package. It is expected that both Gen-Probe and InnerSphere Technologies shall commit to the principles of open exchange of timely, accurate, project-related information, since ultimately customer satisfaction depends on the product's delivery as specified.

Because this project is not intended for use by the entire Gen-Probe organization, but rather limited to an investigational research program, Gen-Probe's conventional documentation standards or development criteria do not apply here.




Because SEDA is being developed on a pro bono basis, choices of Commercial Off-the-Shelf (COTS) software used in development of SEDA shall be constrained to freeware or time-limited/demonstration software. The development team's most substantial constraint is that of time. The timeline of this project is demanding, and it is crucial that all requirements are defined and adhered to. Unilateral commitment to the requirements of the project is critical to the timely delivery of the product.

3.3 Risk Management

In any complex business undertaking, where many internal and external forces may disrupt or divert activities planned to achieve a goal, it is imperative for the business plan to incorporate risk management strategies. In the case of the development of SEDA, risk can be described as any factor whose impact on the project could reduce the quality of the end product, increase costs, delay its completion, or end in project failure.

The Software Engineering Institute (SEI) risk management paradigm represents a set of functions that are identified as continuous activities through the life cycle of a project. Each risk nominally goes through these functions in sequence (see Figure 3.3-1), but the activity occurs continuously, concurrently, and repeatedly (e.g., the mitigation plan for one risk may yield another risk) throughout the project life cycle.

FUNCTION DESCRIPTION

IDENTIFY Search for and locate risks before they

become problems

ANALYZE Transform risk data into decision-making

information. Evaluate impact, probability, and timeframe; classify and prioritize risks.

PLAN Translate risk information into decision and

mitigating actions (both present and future) and implement those actions.

TRACK Monitor risk indicator and mitigation actions.

CONTROL Correct for deviations from the risk mitigation

actions.

COMMUNICATE

Provide information and feedback internal and external to the project on the risk activities, current risks, and emerging risks.

---- Communication happens throughout all the functions of risk management --

Figure 3.3-1. Risk Management Paradigm Functions



DESIGN

LESSERRISK

RISK


To mitigate risk, InnerSphere Technologies shall implement a risk assessment plan. This plan articulates two key activities to implement the strategy. The first is the application of the risk management paradigm, resolving technical risk in a systematic and structured way. The second is collaboration with Gen-Probe to identify the potential risks. The risk assessment table identifies risk potential, category, probability, impact, and mitigation. (See Appendix B)

3.4 Monitoring and Controlling Mechanisms

The work products of repeatable processes shall comply with specified standards and requirements. Further, work products are reviewed by those affected, and placed under version control or configuration management.

The project leader shall ensure the overall project remains on schedule. The task leaders in turn shall keep control of their assigned task(s). By implementing a multi-tiered approach to monitoring schedule deadlines, the project has improved chances of success.

InnerSphere Technologies shall implement a Software Configuration Management (SCM) system. The SCM system allows software design changes, anomalies, and updates to be recorded, monitored, verified, and archived. The SCM process is essential to the success of the SEDA development project.

One of the most important monitoring and controlling functions is handled by the person responsible for the SCM. The SCM Manager maintains all versions of documents in hard and electronic copy, tracks hours expended, records meeting minutes, and ensures InnerSphere Technologies development team has the most recent versions of the documentation and revisions of software.

The auditing process shall be by a Software Configuration Control Board (SCCB). The board members shall be assigned to review each document and software product. When the review is complete, the board shall convene and discuss all proposed changes. The changes shall be implemented by majority rules. The proposed document or software changes shall not be deemed final until all board members sign off on the documents. The SCCB is composed of:

SCCB Chair – Jay Sadler SCM Manager – David Chin Technical Advisor – Vicente Lerum Technical Advisor – Joseph Tingzon

In addition to the primary auditing performed by the SCCB, the following audits shall also be instituted:

Requirements Review (RR) Preliminary Design Review (PDR) Critical Design Review (CDR)




3.5 Staffing Plan

The organizational structure of InnerSphere Technologies is shown below:

Figure 3.5-1. SEDA Project Organizational Chart

Staffing necessary to execute and support the SEDA development effort is presented in the following table. The personnel directly supporting the SEDA development effort are developers and managers. InnerSphere Technologies meets two to three times weekly for several hours.

JOB TITLE STAFFING Project Leader 1 Senior Programmer (SP) 2 Software Configuration Management (SCM) Specialist 1 Database Administrator (DBA) Specialist 1 Test and Evaluation Specialist 1 Technical Lead 1 Network Specialists 2 Documentation Specialists 5

Table 3.5-1. SEDA Staffing Requirements



PROJECT

CONTROLLER/SCMVicente Lerum

DATABASESPECIA

LISTJay Sadler

TEST AND

EVALUATION SPECIALIST

David Chin

SR.

PROGRAMMERJoseph Tingzon

P R O J E C T L E A D E RVincent Crisologo

DOCUMENTATION

SPECIALISTSDavid Chin

Vicente LerumJoseph Tingzon

Jay SadlerVincent Crisologo

TECHNICAL

LEADVicente Lerum

HARDWARE

SPECIALISTSDavid ChinJay Sadler


4.0 Technical Process

4.1 Methods, Tools, and Techniques

Technical issues connected with the SEDA project are discussed in this section. These include the computing system, target system, development methods, team structure, programming languages, technical standards, and procedures for developing and modifying CSCIs.

4.1.1 Computing System

The development system should meet the following minimum requirements:

Hardware 300 MHz Pentium 64 MB RAM 8.4 GB Hard Drive

Software O/S for an IBM-PC operating system Fourth generation programming language Database Statistical analysis software Graphing software

4.1.2 Target System

The customer has defined the SEDA client system. This system shall be built at a minimum level due to cost considerations, but is upgradeable. The client system minimum requirements include:

Hardware 200 MHz Pentium 32 MB RAM 6.4 GB Hard Drive

Software O/S for an IBM-PC operating system Intranet/Internet browser Database

4.1.3 Development Methods




Two versions of SEDA shall be developed: a prototype and an operational. The operational version shall be divided into 2 phases.

The prototype version shall use a COTS product as part of the design of a data analysis software package for Gen-Probe. It shall provide the look and feel of the operational version, but shall only simulate the database interface, the analysis and the graphing functions. The prototype version shall serve as a front end to the expanded operational version.

The operational version shall use COTS products to design and build a relational database. Like the prototype, the operational version shall also use COTS to analyze and graph the data.

In the first phase of the operational version, a relational database shall be designed and built. The LB8 single molecule counter used by Gen-Probe for this project outputs data in the form of a text file. SEDA shall provide an interface to import the text file and transfer it into the database. The customer has provided the development team with sample data for this task. The operational version shall also provide an interface allowing export of files from the database to other file formats (MS Excel *.xls, ASCII, and text).

In the second phase of the operational version, an interface shall be designed for graphing as well as performing statistical analysis on the data. This operational version shall be able to process different data sets concurrently and save the processed data as a new data set to the database.

InnerSphere Technologies uses Software Engineering by Sommerville (1996), and A Guide to the Project Management Body of Knowledge by the PMI Standards Committee (1996), to standardize the software development process across all software development projects. For the SEDA project, the incremental process methodology shall be used.

4.1.4 Development Team Structure

The SEDA project development effort shall be broken down into three major areas, reflecting individual team member expertise. The first area is data analysis tools development. The second area is database development. The third area is graphical tool development. Each team member shall be assigned a specific part of the total effort as a primary area of development responsibility.

Each group member shall work separately to complete the individual task, then the group shall come together and each member shall do a walk-through of their process with the rest of the team. It is suggested that this method will provide the quickest task throughput, strengthen the individual's skill level, and enhance the group learning experience.

4.1.5 Programming Languages




The database shall be developed using COTS tools. The GUI, graphing as well as the statistical analysis functions shall be developed using COTS tools.

4.1.6 Technical Standards

The SEDA project shall use the National University Software Engineering Capstone Project Document Specifications as the baseline for all project documentation requirements and format. SEDA shall incorporate custom code as well as code generated by COTS tools. Custom coding standards shall follow a traditional top-down procedural design with modular construction and indentation. Each function shall include a descriptive paragraph. Comments shall be included throughout the custom code to provide clarification as needed.

4.1.7 Developing and Modifying Procedures for CSCIs

All CSCIs shall be kept on the development server (Blackboard.com) under the control of the project leader. The development server shall be hosted on a WWW server, remotely accessible by each team member.

4.2 Software Documentation

The software documentation requirements for SEDA are listed here, including milestones, baselines, and reviews.

Operational Concept Document (OCD) Software Development Plan (SDP) Requirements Review (RR) System Requirements Specification (SRS) Software Design Document (SDD)

Top Level Design (SDD-TLD) Preliminary Design Review (PDR)

Detailed Design (SDD-DD) Critical Design Review (CDR)

Test Plan (TP) User's Manual (UM)

The OCD shall set the stage for the development of the SRS. The OCD is designed to establish the project environment, data requirements, and design. This document shall explain both the functionality and scope of services provided by SEDA.

The SDP establishes the plan guiding the SEDA development effort. The intended audience of the SDP is selected R&D staff at Gen-Probe. This SDP shall also be used by InnerSphere Technologies as a master coordinating document to be referred to during the entire SEDA development effort.




The SRS shall provide a detailed description of the problem that the software must solve, expressed as system requirements. Project-related information and relationships, data flows and structure are documented. Hardware, software, and user interfaces are described for external system elements and internal software functions. The SRS shall describe system requirements to a level of detail sufficient to enable designers to produce a system to satisfy those requirements. Requirements stated in the SRS shall be testable and unambiguous.

The SDD provides the detailed description and development foundation of SEDA. The SDD states the purpose of the CSCI, and describes the database management systems for SEDA. The SDD also provides the functional, behavioral, and performance requirements of SEDA. The SDD shall specify the design requirements necessary for the development of SEDA. . The intended audience of the SDD is selected R&D staff at Gen-Probe. InnerSphere Technologies shall document the specific details of the design using the SDD.

The TP shall detail the activities required to prepare for and conduct the specified tests. The TP shall list testing tasks to perform, and how they are to be scheduled. Besides specifying the sources used in preparing the test protocols, it shall also define the test tools and environments needed to conduct the system test. Finally, the TP includes an SRS cross-reference table as a checklist for verifying tests of all requirements identified in the SRS.

The UM shall provide assistance to the first-time and experience SEDA user. For both kinds of users, a Quick Start Guide shall provide guidance to installing SEDA and contact information for InnerSphere Technologies. A Tutorial shall be targeted at the first-time user, while a comprehensive Reference Manual is for both users. The Reference Manual details procedures for using all SEDA features and lists error codes.

Design reviews shall be held throughout the development process. The major design reviews (requirements review, preliminary design review, and critical design review) shall include the project manager, software manager, quality, and technical leads, and a Gen-Probe representative.

4.3 Project Support Functions

4.3.1 Configuration Management

The Software Development Library (SDL) shall house all software, associated development tools and utilities, and procedures. The SDL shall contain a combination of hard copy, magnetic, and optical media. A COTS revision control program shall handle tracking source files. An on-line library system with write-protected files and file-sharing capabilities shall be used to control documentation.

4.3.1.1 Configuration Responsibilities




The Project Controller shall oversee the SDL, maintain its files, and collaborate with the Software Manager (SWM) and the SQA representative in monitoring the storage, change, audit and accessibility of SDL files. The Project Controller alone furnishes copies of the SDL files for use by project personnel, ensuring that only authorized changes are accepted.

The SQA representative and CM shall identify development support items (such as version numbers) subject to configuration control. Items for development support include items in both the Software Engineering Environment (SEE) and the Software Test Environment (STE). SEE items installed on the development server shall be verified by the SWM for correct version number. As they are produced and tested, developmental software items shall become part of the configuration and shall also be controlled as part of the SDL.

4.3.1.2 Configuration Control Process

InnerSphere Technologies' projects articulate a two-tiered approach to configuration management. In the first tier, the programmer's workspace represents an area where individual developers exercise control over the product as it is being built or modified. After the product has successfully completed the review process (which includes passing unit testing), it is elevated to the second tier. Here, the product is incorporated with the other files in the SDL. At the second level, it falls under the control of the Project Controller, who implements a formal control process using Software Problem/Change Reports (SP/CRs). Because of this strict formal control process, only changes authorized by the SWM are made to the software once it has been placed in the SDL.

Developers sign out a CSCI from the SDL when assigned to perform work that requires review of the material contained in the file, or that will result in the updating of either the source files or documentation contained in the Software Document Folder (SDF). Upon completion of access to or updates of the SDF, all accessed or updated items are resubmitted to the Project Controller for storage.

4.3.2 Software Quality Assurance

The SCCB implements the SQA function. The SQA function ensures the quality of the software and its documentation. Processes for producing the software are also monitored by the SQA function. SQA activities include: reviewing project requirements; designing and producing test documentation; reviewing Configuration Management (CM) practices and procedures; and preparing review reports in the form of software quality evaluation reports.

4.3.2.1 Organizational Structure

SQA personnel shall be responsible for identifying and assessing quality issues. They are authorized to initiate, recommend, or provide quality-delivery solutions. To maintain objectivity in quality reviews of the software and associated documentation, SQA operations shall be conducted independently of SEDA development.




The SQA representative reports to the CM. The CM has the authority and responsibility for reviewing the SQA operations and ensuring the accomplishment of all quality program tasks. The CM has the responsibility and authority to integrate the SQA operations in conformity with the Common Approach.

4.3.2.2 Other Resources

For effective SQA operations, the SQA representative has access to the same computer workstations and tools as the software development group.

4.3.2.3 Methods and Procedures

Procedures and methods necessary for delivery of an effective SQA are specified in this section. The project quality program demands an ongoing evaluation of the development process and products, as well as the various kinds of analysis, verification, and monitoring essential to each developmental phase.

The evaluation of software quality involves:

Inspections - assessment of processes (internal reviews, CM audits, and technical reviews) and products (documentation and CSCIs)

Analysis – evaluation of both the process (development phases) and the products (documentation and CSCIs).

4.3.3 Training

InnerSphere Technologies shall offer a complete one-time training package in the form of a "train the trainer" session to a small group of Gen-Probe Inc., employees.

4.3.4 Testing

As each Configuration Software Unit (CSU) is implemented, the developer performs unit testing. Tested CSUs are then integrated in preparation for testing of the next incremental build. Incremental builds involve the development of successively greater capability/functionality and early testing in an incremental fashion until completion of all the capabilities. Using incremental builds, integration becomes a continual process throughout the implementation of CSUs.

Informal unit testing is applied to the units developed for SEDA. SQA personnel may monitor testing. After a review of the unit test material, a log is made of testing performed on each unit. The test results are filed in the SDF.




Unit testing of the individual SEDA CSCI combines source file inspection and execution testing. The purpose of unit testing is to ensure that the unit performs properly before integration into SEDA, and that all requirements are met. To support effective unit testing for the CSCI, the following unit test guidelines are applied:

Each functional requirement shall be tested Each line of code and/or script shall be executed or inspected Each decision shall be executed or inspected Each condition determining each decision shall be exercised or inspected.

4.3.5 Verification and Validation

Verification and validation shall be performed using SEDA running on the development server. This integration and test process is documented in the SDF. Incremental software builds shall be generated as necessary and build directives created to document the added components and any changes resulting from SP/CRs. Regression testing shall be performed to ensure changes have been made correctly and no new defects have been introduced. Any changes necessary shall be made to the code and associated documentation prior to product delivery.

4.4 Development Environment Requirements

The hardware and software required for development of the SEDA project are covered in this section.

4.4.1 Hardware

The hardware necessary to support SEDA consists of Pentium PC computers used as the development and target/testing platforms.

The development PC must be configured with a minimum of 64 megabytes of memory, and an 8.4-gigabyte hard disk drive. The Pentium PC serves as the software development platform for the effort and may also be used to generate project documentation. A complete list of development hardware required is provided the following table:




HARDWARE ITEM PURPOSEPentium, IBM-compatible PC Primary development platform64 MB memory Short term storage for data

Minimum for average computer performance.8.4 GB hard drive Magnetic storage for long term storage of

data.

Table 4.4.1-1. SEDA Project Development Hardware

4.4.2 Software

The software items identified for SEDA project development and testing are listed in the following table:

SOFTWARE ITEM PURPOSEO/S for an IBM-PC operating system Development O/S for PC environmentStatistical analysis software Provides statistical analysis functionsDatabase Provides a data repository for short and

long term storageGraphing software Provides graphing functions for data

output4GL Provides main structure that connects

the database to the analysis and graphing functions

Table 4.4.2-1. SEDA Project Development Software




5.0 Work Processes

5.1 Work Packages

The work breakdown structure shall state the tasks to be completed by each work process document.

5.1.1 Operational Concept DocumentThe OCD provides an overall scheme for SEDA.

Purpose and Introduction

States the purpose of the OCD. Includes a glossary of definitions and acronyms found in the text. Includes references to research material. Surveys the OCD's organization

Provide a product definition of SEDA. The product definition:

States the current problem with the Gen-Probe’s processes. Presents a proposed solution utilizing SEDA.

Describes the characteristics of the end-users of SEDA. Defines InnerSphere Technologies’ solution strategy for SEDA. Describes the

implementation and testing phase. Explores the processes to be provided by SEDA. Lists the various required processing environments to be delivered by SEDA. Distinguishes the levels of product features proposed for SEDA. Defines the acceptance criteria for SEDA.

5.1.2 Software Development Plan

The SDP maps the development of SEDA. The SDP:

Introduces itself and defines its purpose. Provides a glossary and list of references of materials used in the development of the

SDP. Describes the partial organization of Gen-Probe’s R&D department. Defines InnerSphere Technologies' design team as associated with the design,

development, implementation, and testing of SEDA. Describes the managerial process of SEDA as pertaining to the design, development,

implementation, and testing of SEDA. Outlines the technical and work processes implemented in the development of SEDA. Provides a development schedule that graphically depicts the work breakdown for the

development of SEDA.




5.1.3 System Requirement Specifications

The SRS shall be drawn from an analysis of the SEDA OCD and SDP, as well as from elicitation of requirements from the client, yielding a set of software requirements. The SRS shall be the guideline for the development of SEDA. The SRS:

Defines and introduces the SRS Provides a glossary and list of references used in the development of the SRS. Provides a generalized description of SEDA Defines the specific requirements used in the development of SEDA Presents the design of technical process diagrams. Defines the entities, relationships, attributes, and associations used in the development of

SEDA. Defines the validation requirements used to qualify the SRS specific requirements.

5.1.4 Software Design Document, Top Level Design

The SDD-TLD provides an overview of SEDA. The SDD-TLD:

Defines the scope used in the development of SEDA. The scope shall include the system and document overview. The scope shall consist of glossary terms used within the SDD.

Lists material consulted in the SDD. Defines the CSCI overview as related to SEDA. 5.1.5 Software Design, Document Detailed Design

The SDD-DD reflects the detailed design of SEDA. The SDD-DD: Determines the detailed software design of SEDA. Provides detailed design of all CSCI data and data elements developed for SEDA. Defines a detailed design of the relational database CSCI. Defines requirement traceability for CSU items. Defines CSU items correlated in the SDD to requirements in the SRS.

5.1.6 SEDA Software Code (Operational Version)

The operational version shall utilize the SDD to develop, implement, and test SEDA. The software code documentation shall include the following:

Detailed relationships and design of database. Software system design/code.

5.1.7 Test Plan and Procedures Document




The TP shall characterize the plans and procedures used to test SEDA. The TP:

Defines test objectives utilized in the development of SEDA. Defines the build integration utilized in the development of SEDA. Defines the build

plan. Defines the test cases for evaluating the software used in SEDA. Defines the test requirements for evaluating SEDA software. Identifies any applicable environmental needs associated with the testing of SEDA. Defines the breakdown of responsibilities within the InnerSphere development team as

related to the testing and evaluation of SEDA. Defines any required staffing and training needs associated with the testing of SEDA. Develops a schedule for tests related to the evaluation of the SEDA. Defines any risks or contingencies that may exist in relation to the testing of SEDA. 5.1.8 User’s Manual

The UM defines the purpose of SEDA. The UM:

Describes SEDA’s installation procedures. Provides user instructions for the various functions of SEDA. Defines and describes all error messages that a user may encounter while using SEDA Provides a glossary for SEDA. This should include definitions and acronyms associated

with SEDA.




5.2 Dependencies

The major phase activities of the SEDA project for each increment can be mapped as follows: Information Engineering – Analysis, Systems Engineering – Design, Implementation – Coding, and Testing – Testing. Each major phase must be completed before the subsequent phases may begin.

PHASE ACTIVITY TASKSInformation Engineering Operational Concept Document

Software Development Plan Initial Prototype

Systems Engineering System Requirement Specifications Software Design Document Top Level Design Software Design Document Detailed Design

Implementation System Software Code (Operational Version)Testing Test Plan and Procedures Document

Integration Testing Systems Testing

Table 5.2.1. Phase Activities and Tasks

5.3 Resource Requirements

The resources required to complete the SEDA project are modest, consisting mainly of hardware and software owned by InnerSphere Technologies. These resources include individual computer workstations (Windows 95/98/NT) for each member of the InnerSphere Technologies development staff, Microsoft Project 98, Microsoft Office 97, Microsoft Visual Studio 6.0, and Microsoft Visual Basic. These items shall be used to support all phases of the development process in addition to software/system documentation and configuration management.

Other software requirements include evaluation or demonstration versions of various mathematical, analytical or scientific related COTS product. These software packages shall be obtained by InnerSphere Technologies and shall be evaluated to determine their usefulness in furnishing the SEDA project with its advanced mathematical and graphing capabilities.

See Figure 3.5-1. SEDA Project Organizational Chart for InnerSphere Technologies staffing requirements.

5.4 Budget and Resource Allocation

Due to the pro bono nature of the SEDA project and the moderate resource requirements described above, the expected expenditures for the project are nominal. InnerSphere Technologies anticipates that a total of $500.00 is sufficient to cover the expenses for the purchase of COTS software and any office supplies needed to support project development.




Physical and human resources shall be allocated as necessary to support the various stages of development. A total of 2400 person-hours have been scheduled for SEDA development (5 developers times 40 hours per week times 12 weeks) and shall be allocated as shown in the following table:

ACTIVITYEFFORT

(% TOTAL PERSON-HOURS)Information Engineering 8

Systems Engineering 45

Implementation 15

Testing 32

Table 5.4.1. Physical and Human Resource Allocation

5.5 Schedule

This subsection provides the schedule for the various project functions, activities, and tasks, taking into account the precedence relations and the required milestone dates. The information presented here includes task leaders and any staffing requirements. In addition, this section defines the project start, document review, completion, presentation, and scheduled review dates.

5.5.1 Operational Concept Document

TASK LEADER Joseph Tingzon

STAFFING REQUIREMENTS SEDA Development Team

PROJECT START DATE January 11, 2000

DOCUMENT REVIEW January 25, 2000

COMPLETION DEADLINE January 27, 2000

PRESENTATION DATE January 29, 2000

ACCEPTANCE CRITERIA Client Approval

5.5.2 Software Development Plan

TASK LEADER Vincent Crisologo


PROJECT START DATE January 15, 2000

DOCUMENT REVIEW January 25, 2000

COMPLETION DEADLINE January 29, 2000




PRESENTATION DATE January 29, 2000


5.5.3 System Prototype

TASK LEADER Vicente Lerum


ATTENDEES Client, SEDA Development Team

SCHEDULED REVIEW DATE January 27, 2000


5.5.4 Requirements Review




SCHEDULED REVIEW DATE February 1, 2000


5.5.5 System Requirement Specifications

TASK LEADER Jay Sadler


PROJECT START DATE February 1, 2000

DOCUMENT REVIEW February 8, 2000

COMPLETION DEADLINE February 10, 2000

PRESENTATION DATE February 24, 2000


5.5.6 Preliminary Design Review

COORDINATOR Jeff Appel






5.5.7 Software Design Document Top Level Design

TASK LEADER David Chin





PRESENTATION DATE February 2000


5.5.8 Software Design Document Detailed Design






PRESENTATION DATE February 2000


5.5.9 Critical Design Review

COORDINATOR Jeff Appel












SCHEDULED REVIEW DATE March 24, 2000


5.5.11 Test Manual

TASK LEADER Joe Tingzon


PROJECT START DATE March 7, 2000

DOCUMENT REVIEW March 9, 2000

COMPLETION DEADLINE March 11, 2000

PRESENTATION DATE N/A


5.5.12 Users Manual

TASK LEADER Jay Sadler



DOCUMENT REVIEW March 21, 2000

COMPLETION DEADLINE March 25, 2000

PRESENTATION DATE N/A





Appendix A

SEDA Project Schedule

SEDA Gantt Chart 1

January 2000 Milestones




SEDA Gantt Chart 2

February 2000 Milestones




SEDA Gantt Chart 3 March 2000 Milestones




Appendix B

SEDA Software Risk Analysis Table

CA

TE

GO

RY

RISK POTENTIAL

CH

AN

CE

%

IMP

AC

T

MITIGATION

PR

OD

UC

T S

IZE

Confidence in size estimate

10 2 Regular meetings with development team and customer.

Size of database created

50 1 Regular meetings with development team and customer.Database requirements shall be determined by

customer's data file sizes.Number of users

of the product80 2 As user numbers grow, the customer must ensure

network bandwidth is adequate.Number of

projected changes

75 1 Regular meetings with development team and customer early in the development stage.

Customer supplied with several prototypes to solidify initial requirements

BU

SIN

ES

S I

MP

AC

T Visibility of this

product to management

60 1 Product is designed for R&D purposes.Product shall not be visible to general management.

Accuracy of delivery deadline

100

1 Regular meetings with development team and customer to handle any issue or change.

Number of users to the system

75 2 System use limited to specific users, as stated in the SRS

Interoperability 100

1 Original data files shall not be altered.Original test methods shall be available to the customer.

Amount of product documentation

80 1 To provide an acceptable level of documentation, the project shall schedule adequate time to generate required documentation.




CA

TE

GO

RY

RISK POTENTIAL

CH

AN

CE

%

IMP

AC

T

MITIGATION

CU

ST

OM

ER

RIS

KS

Sophistication of end users

80 3 Development team shall provide training to Gen-Probe R&D personnel.

Customer relationship

80 2 Establish a good customer relationship.Involve and keep the customer informed at all

development stages.Concrete

customer requirements

70 1 Regular meetings with development team and customer to handle any changes.

Provide customer with prototypes early in the development cycle.

Formal requirements meetings

100

2 Regular meetings with development team and customer to handle any changes.

Customer involvement in all requirements related meetings

Customer review participation

70 2 Regular meetings with development team and customer to handle any changes.

Customer involvement in all requirements related meetings

Customer technical competence

50 2 Development team shall provide training to R&D personnel.

Customer micro-management

5 3 Customer must agree to let development team develop product without interference.

Customer awareness of software process

70 2 Regular meetings with development team and customer.Customer to be involved in all milestone-related meetings

Number of projected changes to the requirements

5 1 Regular meetings with development team and customer early in the development stage.

Customer supplied with several prototypes to solidify initial requirements




CA

TE

GO

RY

RISK POTENTIAL

CH

AN

CE

%

IMP

AC

T

MITIGATION

TE

CH

NO

LO

GY

RIS

KS

New technology to organization

65 2 The development team is familiar with all technologies that are being utilized on this project.

New algorithms 50 2 Algorithms shall be based on existing algorithms.Algorithms shall be extensively tested prior to

implementationNew unproven

hardware70 4 There is no unproven hardware required in the project.

All necessary hardware has already been established.New or unproven

software70 2 There is a minimal amount of unproven software in the

project.A team shall be tasked to familiarize themselves with any

new software early in the development cycleUnproven

database interface

10 4 Database interface is a proven technology.

Specialized user interface

10 4 Anticipated user interface shall be a standard RAD COTS tool.

The tool shall be implemented and controlled by the SCM manager




CA

TE

GO

RY

RISK POTENTIAL

CH

AN

CE

%

IMP

AC

T

MITIGATION

PR

OC

ES

S R

ISK

S

Standard process for software development

100 1 Implementation of the Incremental Process Model development methodology.

Written description of software process

75 1 The software process is defined in section 2.1 and 4.1.3 of the SDP

Team members willingness to use software process

100 1 The development team is required to use the Incremental Process Model development methodology.

Formal technical reviews

90 2 The development team shall conduct the following technical reviews:

Requirements Review, Preliminary Design Review, Critical Design Review

Formal technical reviews documented

90 2 The Project Controller/SCM manager shall document technical review minutes

Document outlines and examples developed

75 3 Predefined document templates have been developed and shall be implemented.

Is 90 percent or more of code in a high-order language?

50 3 Custom code shall be minimized through the use of COTS products and software development tools.

Specific testing methods used for software analysis

80 2 Testing methods are defined in section 4.3.4 Verification and Validation methods are defined in

section 4.3.5.Software tools used

to support planning and tracking activities

80 3 The development team shall use a project-planning tool for planning and tracking.

Weekly status reports for all functional groups shall be held throughout the development effort.

Software tool used to create software prototypes

60 2 RAD software tool shall be used to quickly develop the prototypes

Configuration Management tools used to control and track change activity

100 3 A revision control system shall be used to control and track change activity.




CA

TE

GO

RY

RISK POTENTIAL

CH

AN

CE

%

IMP

AC

T

MITIGATION

DE

V E

NV

IRO

NM

EN

T Software

management tool available

80 3 The development team shall use a revision control system.


Tools for analysis and design

60 3 The development team shall use a COTS tool for analysis and design.

Software configuration management tool

65 3 The development team shall use a revision control system.


ST

AF

F R

ISK

S

Qualified personnel 100 1 The development team is comprised of individuals with varied skill sets to cover all areas of the development cycle.

Do personnel have the right combination of skills?

80 1 The skill set of the development team overlaps and reinforces individual skills.

Sufficient staffing 10 1 Each member of the development team is required for the timely completion of the project.

If a member cannot complete the project, the other team members shall assume the work of the missing person.

Each member is cross-functional.Any work area can be assumed by another member of

the teamStaff committed to

duration of project100 1 Each member of the development team is committed

to the completion of the project. Each member is a cross-functional.




Appendix B Legend

Table Fields

Risk Potential Description of the item with potential risk.Chance % The probability (as a percentage) this risk may occur.Impact A rating of the impact of unmitigated risk on project schedule/product

delivery.Mitigation Steps taken to address this risk.

Chance%

100% This risk exhibits the greatest likelihood of occurring.0% This risk exhibits the no likelihood of occurring

Impact

1 May cause negligible impact to project schedule and delivery of product. 2 May cause minor impact to project schedule and delivery of product3 May cause marginal impact to project schedule and delivery of product.4 May cause critical impact to project schedule and delivery of product.

The following indicates the worst case scenario:

Probability = 100%Impact = 4

The following condition indicates best case scenario:

Probability = 0%Impact = 1



introduction

Business

software development

software design document

seda software programpage

procedures document

seda software program

project overview

project deliverables

operational version