Software System Reliability Analysis

Award Information
Agency: Department of Defense
Branch: Army
Contract: W911QX-07-C-0061
Agency Tracking Number: O064-SP4-2043
Amount: $98,992.00
Phase: Phase I
Program: STTR
Solicitation Topic Code: OSD06-SP4
Solicitation Number: N/A
Timeline
Solicitation Year: 2006
Award Year: 2007
Award Start Date (Proposal Award Date): 2007-04-09
Award End Date (Contract End Date): 2008-04-09
Small Business Information
458 E Jackson, Webster Groves, MO, 63119
DUNS: 023299220
HUBZone Owned: N
Woman Owned: N
Socially and Economically Disadvantaged: N
Principal Investigator
 Peter Lakey
 President
 (314) 961-7454
 peterlakey@sbcglobal.net
Business Contact
 Peter Lakey
Title: President
Phone: (314) 961-7454
Email: peterlakey@sbcglobal.net
Research Institution
 UNIV. OF MARYLAND
 Carol Smidts
 3112 Lee Building, Research Administration
College Park, MD, 20742
 (301) 405-7314
 Nonprofit college or university
Abstract
Establishing the reliability of embedded software-based systems is increasingly important as the DoD's dependency on software grows and the size and complexity of software systems increase. Currently, no theory is in general practice that adequately explains the behavior of software systems reliability in a consistent and repeatable way. Currently, we cannot point to a best practice (although John Musa and other experts would argue that operational profile testing is the SRE best practice). At the conclusion of Phase II of this STTR, the CC/UMD team is confident that we will not only have produced such a best practice, but that the practice will be publicized and widely known among DoD management and practitioners, and that these people will promote the best practice. The best practice will incorporate an advanced theory for explaining software systems reliability. The theory will be based on well understood principles of software operation. The software reliability theory is by nature fundamentally different from hardware reliability. Hardware reliability is characterized by physical changes in system parts which result in a breakdown in one or more components or sub-systems. Software does not fail in that manner. Software systems fail as a result of design flaws, design limitations, or simply unknown requirements.

* Information listed above is at the time of submission. *

US Flag An Official Website of the United States Government