System Engineering

INCOSE PresentationNader KameliManager, Software Engineering

GuidantCardiac Rhythm Management

Desire

Speed up the product development process

Commissioned by management team

Members of management team

First Step

Before speeding up the process …

Need to understand the current speed …

Analysis of past projects

Analysis

Problem: Did not complete projects “on plan”

Completed project on Plan - Completed project on time, with budget, effort and functionality identified in the functional plan at the time of contract.

Assumption ValidationAssumption:

Loosely defined system definition at the start of contract causes resource/schedule impact downstream

Methodology Survey cross functional areas for input

Department Dependencies

Marketing, Regulatory, SW/HW Design, SW IRV,

SAM, Research,

Technology

Advanced Tools, IC Design,

Hybrid Design, Reliability

Quality System Services, AEG, Supplier Development,

AME/Test Eng, Clinicals,

Manufacturing

System Design

Components, Manufacturing Process, or Schedule

System Requirements

Survey Results

Unstable System Definition At Start System not well defined at

start Late Requirements Changes Late Design Changes Impact of New Process

Technologies not well defined Impact of New Component

Technologies not well defined

Project Management Constraints Proof of concept

Prototyping not completed

Experienced Technical Staff not Available

Low Confidence Schedules Needed Resources are not

available on time Shifting Project Priorities

Responses to “top 3 issues affecting your plan”

Survey Conclusion

Assumption: Loosely defined system definition at the start of contract

causes resource/schedule impact downstream

Two Major Impactors System Definition Project Management

Assumption validated

Industry Best Practices

Purpose To identify challenges with RNPD outside

Guidant

Methodology Literature Search

Industries Software intensive systems Mission-critical systems Complex systems

Lessons Learned by NASA

“Mistakes that have been repeated Lack of clear definition of requirements early

in system design phase:Starting design before requirements were knownVague SpecificationsDesign from the bottom-up rather than top-downIncomplete documentation of requirementsLack of early and Thorough requirements

analysis prior to the start of a design”

NASA Space Engineering Lessons Learned, Nov 1989

Lessons from NASA

“…if the expenditures on the system design phase (up to and including the preliminary design phase) is less than 5% of the estimated cost of the project, vast cost (and schedule) overrun can be expected…”

NASA System Engineering Handbook, 1995

“Up to 15% of the estimated total development cost may need to be spent on project definition in order to reduce risk.”

System Engineering Management Guide, Defense System Management College, 1993

UK Civil Software-based System Development

Study on over 14000 organizations showed: 80-90% of the systems did not meet their goals Around 40% of the developments failed or were

abandoned Less than 25% fully integrated business and

technology objectives Only 10-20% met their success criteria

Critical System Thinking and Information Systems Development, 1997

Standish Group’s Research in US

Standish group is a research and advisory organization specializing in mission-critical software intensive systems

Research of 365 US organizations covering some 8380 applications grouped projects in 3 categories:

Standish Group’sProject Outcomes Categories

Standish Group’s Success-Potential Metric

Recommendation for Success

“For Practitioners: It is imperative to understand what is

needed by all stakeholders The user focus must be captured in a

clear, traceable and testable set of requirements

Attention to interface definition and management is vital for project success”

System Engineering and Evaluation Center, 2000

Recommendation for Success

“For planners: Adherence to systems engineering

principles and processes across organization will save money.

Insufficient investment in the early design phases (5 to 15%) is likely to lead to project cost overrun of between 50% and 100% for both hardware and software projects.”

System Engineering and Evaluation Center, 2000

Typical Process

Start ofthe

PlanningPhase

Full ProjectTeam

Assigned

Planning based on Historical inf ormation &Preliminary Sy stem Requirements

Sy stem Requirements Dev elopment Sy stem Design Dev elopment

Start ofthe

DesignPhase

End of PlanningPhase

Global Marketing Review

SubSystem DevelopmentSubSystem Development

SubSystem Development

System Development at Risk

Global Marketing Review

ApprovedConcept Analysis

Document

Approved ConceptRequirements

Document

ConceptReview A

ConceptReview B

NPPResourcesAssigned

SystemEngineersAssigned

Concept ReviewPhase Complete

Start ofConceptPhase

Start ofthe

PlanningPhase

Concept Phase

Start ofthe

PlanningPhase

SystemEngineersAssigned

High Level Planning based on Historicalinformation (Top-Down)

Detail Planning Based on System Requirementsand System Design (Bottom-Up)

System Requirements Development &System Acceptance Test Protocols

System Design Development

System Review

System Development at Risk

HighConfidence

Plan

Contract Phase IIApproval

End of PlanningPhase

Project DevelopmentTeam Assigned

Start ofthe

DesignPhase

Planning Phase

ContractPhase I

End of PlanningPhase

No

Yes

SyRs/PrtclComplete

SyDDComplete

Received High Level SupportPiloted on a projectLearned and improvedStandardize the Process

Application

Better system definitionHigher confidence & Less Risk planLess chance of overrunLower cost of reworkImprove organization’s marketing and

planningWill increase resource availability for

redeployment to other projects

Conclusion

Questions and Answers