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
Top Related