SE Fundamentals, 9-25-2010 - SMU

An Overview ofAn Overview of Systems Engineeringy g g

George W. Chollar, Ph.D., P.E.Adjunct Professor

Systems Engineering Program

SMU Lyle School of Engineering

September 28 2010September 28, 2010

Topics to be discussedTopics to be discussed

• What is Systems Engineering (SE)

• What does SE provide

• How can SE be applied in the design process

• Lessons Learned from the application of SE

• Challenges in the application of SE• Challenges in the application of SE

Systems Engineering Fundamentals ‐ 2

What is a SystemWhat is a System

• A “system” is:– A collection of hardware, software, people, facilities, and/or

d d l h bprocedures organized to accomplish some common objectives

• Common Systems • These items are also – Computer Systems

– Navigation Systems

Defense Systems

Systems– Aircraft, Ships, Automobiles

– Defense Systems

– Transportation Systems

– Banking Systems

– Integrated Circuits

– Thermometer

– Disk Driveg y

– Healthcare Systems

– Human Resource Systems

Disk Drive

– Door Hinge

– Fastening Devices ‐ nut & – Quality Control Systems bolt, rivets, glues


What is Systems EngineeringWhat is Systems Engineering

• As defined by the International Council on Systems Engineering (INCOSE)

Systems Engineering is an interdisciplinary approach and means to enable the– Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems

– Systems Engineering focuses on defining customer needs and required f i li l i h d l l d i i hfunctionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem:

• Operations, Performance , Test, Manufacturing, Cost & Schedule , Training & Support, Disposal

– Systems Engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation

– Systems Engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs

Ref: www.incose.org


Areas of Focus for Systems EngineeringAreas of Focus for Systems Engineering

6070

uct C

ost

1. Influences on Product Cost

100%Cost Committed

2. Committed vs. Incurred Cost

s

20304050

60

ence

on

Prod

u(%

)

Cos

t

20%

40%

60%

80%Cost Committed

Cost Incurred

Cost Focus

010

Influ

Design Material Labor Overhead

Major Cost ContributorsConcept

& PreliminaryDesign

DetailedDesign &

Integration

Constructionor

Production

Use, Refinement& Disposal

0%

20%

4 A li ti f M th d & T l3 P ti R ti

C

4. Application of Methods & Tools

Must move quality

Traditionally, most quality effort is here.

ost

3. Proactive vs. Reactive

sis

SE Process TraditionalQuality Processes

ocus

quality effort here!

Incr

easi

ng C

o

ConceptUtility

ncre

asin

g Em

phas

Qua

lity Fo


ResearchDesign

PrototypeProduction

Customer

In

Program Lifecycle Phase

ConceptInitiation

DetailDesign Prototype Pilot

Production Production

Systems Engineering’s LegacySystems Engineering s LegacyMil Std 499 Willi P (US S f D f)Mil‐Std‐499July 1969

System Engineering Management

Mil‐Std‐499AMay 1974

William Perry (US Sec of Def) “Perry Memorandum”

Promotes dual‐use products & processesAbolishes new military standards

June 1994

The Systems Engineering method recognizes each system as an integrated whole even though composed of diverseMay 1974

Engineering Management

Mil‐Std‐499BJune 1992

Systems Engineering

whole even though composed of diverse, specialized structures and sub-functions.

J.A. Morton, Elec. Mfg., Aug 1959

Systems Engineering is the science ofy g g“Coordination Copy”

EIA/IS‐632Processes for Engineering

IEEE‐1220Appl & Mgmt of SE Process

1992

ISO‐15288System Life

C l P

Systems Engineering is the science of designing complex systems in their totality to ensure that the component sub-systems making up the system are designed, fitted together checked and operated in the mostg g

a SystemDecember 1994

1992

ISO/IEC‐15288IEEE‐1220

February 1995

Cycle Processes1996

together, checked and operated in the most efficient way.

G.M. Jenkins, Univ. of Lancaster, mid-1960’s.

Systems Engineering is an interdisciplinary2002

ISO/IEEE‐15288F b 2008

ANSI/EIA‐632January 1999

Trial Use

IEEE‐1220September 2005

Systems Engineering is an interdisciplinary approach encompassing the entire technical effort to evolve and verify an integrated and life-cycle balanced set of system product and process solutions that satisfy customer

Systems Engineering Fundamentals ‐ 6Key references for current SE processes

February 2008September 2005Full Use

Coordinationprocess solutions that satisfy customer needs.

MIL-STD-499B (draft), Sept 1993.

Impact of Systems Engineering on Products, Processes, and Services

• Systems that … fail to impress the stakeholders

• Systems that are incomplete

• Systems that workWh t E i i Di i li id tif– What Engineering Disciplines can you identify

– What Systems can you identify


What does SE provideWhat does SE provide

St k h ld ti• Stakeholder perspective– A result that cost‐effectively satisfies the objectives and needs of the

stakeholdersstakeholders

• Process perspective– Definition of –

• what the system must do, • how well the system must do it, and • how the system should be tested to verify and validate its performance• how the system should be tested to verify and validate its performance

• Lifecycle perspective– Attention to the entire Life Cycle –Attention to the entire Life Cycle

• “Gleam” in the eyes of the stakeholders, Definition of Needs of the Stakeholders, Development and integration, Production, Operational use, Stages of refinement Retirement DisposalStages of refinement, Retirement, Disposal


What is a SE design processWhat is a SE design process

d h d d d f f d h• Based on the decomposition and definition of requirements and architectures•• Functions of the design processFunctions of the design process

1. Define the problem to be solved2. Define and evaluate alternative concepts for solving the problem3. Define the System Level Design ProblemSystem Level Design Problem

a. Develop the operational conceptb. Define system boundary with external systems diagramc. Develop system objectives hierarchyd. Develop, analyze and refine requirementse. Ensure requirements feasibilityf. Define the qualification system requirementsg. Obtain approval of system documentation

4. Develop the system Functional Architecture5. Develop the system Physical Architecture6. Develop the system Allocated Architecture7. Develop the Interface Architecture8. Define the Qualification System for the system


Who participates in the SE processWho participates in the SE process

• People with many different disciplines must be involved

• The Stakeholdersmust be involved

• Different disciplines need to include –– Traditional engineering fields – electrical, mechanical, aero, civil,Traditional engineering fields electrical, mechanical, aero, civil,

chemical, software, etc.

– Supporting engineering fields – reliability, maintainability, logistics, analysts, mathematicians

– Non‐engineering fields – management, legal, cost, scheduling, Configuration and Data Management (CM/DM) etcConfiguration and Data Management (CM/DM), etc.

• Engineers skilled in the process (or methods) of Systems Engineering form the nucleusEngineering form the nucleus


The role of Stakeholders in SEThe role of Stakeholders in SE

• Stakeholders –– Are an integral part of a project– They are the individuals or organizations from whom requirements will beThey are the individuals or organizations from whom requirements will be

drawn, the people who will influence the design, the people who will be impacted by or receive benefit/value from your completed projectIt is extremely important to involve stakeholders in all phases of your– It is extremely important to involve stakeholders in all phases of your project for two reasons1. Experience shows that their involvement in the project significantly

i h f b b ildi i lf i f db kincreases your chances of success by building in a self‐correcting feedback loop

2. Involving them in your project builds confidence in your product and will l i i digreatly ease its acceptance in your target audience

– There are many different types of stakeholders• Purchaser, End‐User, Subject Matter Experts, Management, Manufacturers, Suppliers, Marketing, Distributors, Installers, Maintainers, Trainers, …


The role of Stakeholders in SEThe role of Stakeholders in SE

• Comment provided by a student in a Systems Engineering class at SPAWAR Systems Center – Atlantic, Charleston, SC– Paraphrased from presentation by Col Coleman USMC ForceNet– Paraphrased from presentation by Col. Coleman, USMC, ForceNet

Conference, San Diego, CA, Nov 2005.

• “… an important concept often overlooked by Systems Engineers is Common Sense! Ask questions, gain understanding of answers, make sense of requirements and over deliver if sense of requirements, and over deliver if possible. Put yourself in the warfighters boots, walk a mile per requirements, then walk five more walk a mile per requirements, then walk five more and run one. Now, does your product function well? Can you, the engineer, make it better? …”


The role of Requirements in SEThe role of Requirements in SE• The systems engineering design process involves:• The systems engineering design process involves:

– defining all of the system’s requirements and then– bundling them by segmenting and refining into

– a specification for each of the system’s segments elements components– a specification for each of the system s segments, elements, components, and configuration items

• Requirements are best illustrated in a Hierarchy– Mission requirements– Mission requirements

• At the top of the Hierarchy• Relate to needs that are important to the stakeholders• Involve interaction of several systems

– Stakeholder requirements • Statements by the stakeholders• Define constraints and performance parameters• Often found in the Operational Needs or• Often found in the Operational Needs or

Operational Requirements Documents– System requirements

• Derived by systems engineersy y g• Stated in engineering terms

– Derived RequirementsSystems Engineering Fundamentals ‐ 13

The role of Requirements in SEThe role of Requirements in SE

• The temptation of engineers (and management) in Product Development

J h d d d i i i ?– Just go ahead and start designing … or wait?

“When are companies going to stop wasting billions of dollars on failed projects? The vast majority of this waste is completely avoidable; simply get the right business

“15% of project fail outright, 51% are challenged” Standish

… a common thread on challenged/run‐away project is the


needs (requirements) understood early in the process.” (Mitch Bishop, irise blog post, 6/8/2009)

failure to understand & keep‐up with customer requirements. Texas Instruments/Standish

Example Requirement: Th M Sh ll b 3 F f h C l W llThe Moat Shall be 3 Ft from the Castle Wall.


The role of Reviews in SEThe role of Reviews in SE

• Technical reviews are an integral part of the SE Process– scheduled and conducted during each engineering life cycle phase, as

appropriateappropriate

– progress assessed against plan, against the established agreement, and against the applicable enterprise‐based life cycle phase exit criteria.

– conducted to determine whether to continue the investment in future engineering life cycle phases, based on;a) the risks and costs associated with lower‐layer developments;a) the risks and costs associated with lower layer developments;

b) the maturity of the development to date;

c) if requirements and technical plans being tracked are on schedule and are achievable within existing project constraints;achievable within existing project constraints;

d) resources required for lower‐layer projects;

e) readiness to proceed, to include external supplier availability and agreement preparations

Ref: EIA‐632Systems Engineering Fundamentals ‐ 16

Potential Reviews in the SE ProcessPotential Reviews in the SE ProcessAlt ti S t R i id ll t ti l t d l t f d t f f th d l t th t h thPre‐System• Alternative System Review ‐ considers all potential concepts and selects a preferred concept for further development that has the potential for satisfying identified stakeholder requirements

• System Requirements Review ‐ validates that the set of stakeholder requirements is complete, consistent with acquirer’s intent, and understood by the developer

• System Definition Review ‐ demonstrates convergence on and achievability of technical requirements and readiness to initiate the

Pre System Definition

System Definition System Definition Review demonstrates convergence on and achievability of technical requirements and readiness to initiate the

Subsystem Design Phase

• Subsystem Requirements Review ‐ held for each subsystem‐layer building block development, validates that the set of assigned and other local stakeholder requirements is complete, consistent with stakeholder’s intent, and understood by the developer

• System Preliminary Design Review for each subsystem building block development confirms that:

SubSystemDesign

a) subsystem building block specifications have been defined appropriately;

b) subsystem building block end product designs satisfy requirements assigned from the parent building block;

c) enabling products for the associated processes have been defined adequately to initiate enabling product developments;

d) the approaches planned for next lower‐layer building blocks are appropriately planned;

e) lower‐layer building block project risks are identified, and mitigation plans are feasible and judged to be effective

• System Detailed Design Review or Critical Design Review for each lower‐layer building block development demonstrates that:a) specifications and/or drawings or software development files have been appropriately defined;

b) the building block end product designs satisfy requirements assigned from the parent building block;

) bli d f h i d h b d fi d d l i i i bli d d l

Detail Design

c) enabling products for the associated processes have been defined adequately to initiate enabling product developments;

d) the building block project is either: 1) ready for continued development; 2) appropriately defined for purchase of products from an external supplier; 3) ready for fabrication of building block elements; or 4) adequately defined so that off‐the‐shelf products or reuse products can be used to fulfill product requirements and are available within the enterprise.

• Readiness Reviews for each building block from the bottom up demonstrate that delivered end products from lower‐layer building E d P d t


f g f p p y gblocks have been validated, or that validation tests are adequately planned, and that each set of integrated products forming a composite end product is ready for end product verification and end product validation.

Ref: EIA‐632

End ProductIntegration,

T&E

The role of Integration in SEThe role of Integration in SE

I t ti (& t t)• Integration (& test)– Brings all of the detailed elements of the overall design togetherg

– Uses a process of testing (or qualification)– Result is a valid system for meeting the needs of the

t k h ldstakeholders– Performed by engineers (of the appropriate disciplines) according to specificationsg p

– Involves the elements of the system and the system itself

• Integration ensures that the system meets the ultimate needs of the stakeholders


The role of Qualification in SEThe role of Qualification in SE

l f• Qualification– The process of verifying and validating the system design and then obtaining the stakeholders’ acceptance of the design

• Verification – determination that the system was built right

• Validation – determination that the right system was• Validation – determination that the right system was built

• Acceptance – a stakeholder function for agreeing that p g gthe designed system as evaluated by the stakeholders, is acceptable


The role of Qualification in SEThe role of Qualification in SE

• What is the purpose of Qualification?– Not only to find faults and failures but also to prevent them

and to provide comprehensible diagnosis about their locationand to provide comprehensible diagnosis about their location and cause

• What knowledge is needed to design a qualification system?system?– A basic knowledge of faults and some modeling of fault

importance • What does the Qualification Designer need to do?

– Realize that the design of the qualification system is not only important in terms of finding and defining faults and errors butimportant in terms of finding and defining faults and errors but also in guiding designers to preclude them from introducing faults in the first place

– However no qualification system is perfectHowever, no qualification system is perfect


SE is based on Lessons LearnedSE is based on Lessons Learned

d f l h b d h d• Past successes and failures have contributed to the creation and advancement of SE

• INCOSE has developed a list of “pragmatic principles” for key SE areasp p g p p y

• Each item represents a principle that has either, when heeded, aided the member in practicing successful systems engineering or, when ignored, led to difficultiesto difficulties

• THE LISTS– KNOW THE PROBLEM, THE CUSTOMER, AND THE CONSUMER (12 items)

– USE EFFECTIVENESS CRITERIA BASED ON NEEDS TO MAKE SYSTEM DECISIONS (7 items)

– ESTABLISH AND MANAGE REQUIREMENTS (10 items)

– IDENTIFY AND ASSESS ALTERNATIVES SO AS TO CONVERGE ON A SOLUTION (4 items)

– VERIFY AND VALIDATE REQUIREMENTS AND SOLUTION PERFORMANCE (8 items)

– MAINTAIN THE INTEGRITY OF THE SYSTEM (4 items)

– USE AN ARTICULATED AND DOCUMENTED PROCESS (7 items)

– MANAGE AGAINST A PLAN (9 items)

Ref: INCOSE Pragmatic PrinciplesSystems Engineering Fundamentals ‐ 21

SE Lessons Learned from Past ProductsSE Lessons Learned from Past Products

l d l d ll d l• In general, SE concepts and practices are applied in all development activities, there are successes, … but often there are weaknesses and areas for improvement

• Failures are usually related to the Requirements process –System NameHMS Titanic

Year1912

Cause of FailureQuality control

Reqmt Process DeficiencyDevelopment & VerificationHMS Titanic

Edsel automobileApollo 13IBM PC Jr

1912195819701983

Quality controlCustomer needsConfig MgmtC stomer needs

Development & VerificationValidationVerificationDe elopmentIBM PC Jr.

Space Shuttle ChallengerNew CokeH bbl S T l

1983198619881990

Customer needsMgmt vs. Tech concernsArroganceT t l S t t t

DevelopmentVerification & ValidationValidationV ifi tiHubble Space Telescope

Motorola Iridium SystemSpace Shuttle Columbia

199019992002

Total System testAdvancing TechnologyHeed lessons learned

VerificationValidationVerification & Validation


Northeast power outage 2003 Tree trimming DevelopmentRef: Bahill and HendersonRed Italics – Total/Catastrophic Failure

Blue – Recovered from Failure

Challenges in the Application of SEChallenges in the Application of SE

d d l1. Many considerations and interrelations

2. Many different and controversial value judgments

3 Knowledge from several disciplines3. Knowledge from several disciplines

4. Knowledge at the levels of principles, practices, and perspectives

5. Consideration involving product definition, development, and deployment

6. Considerations that cut across the three different life cycles associated with systems planning and marketing, RDT&E, and system acquisition or productionproduction

7. Risks and uncertainties involving future events which are difficult to predict

8. A fragmented decision making structure

9. Human and organizational need and value perspectives, as well as technology perspectives

10 Resolution of issues at the level of institutions and values as well as at the


10. Resolution of issues at the level of institutions and values, as well as at the level of symptoms Ref: Sage & Armstrong

Summary ‐What do we(Systems Engineers) need to do?

• In the development of products, processes, and services, we need to –– Understand the phases of the system’s life cycle

– Understand the importance of performing the engineering of a system

– Establish a definition for the engineering of a system

– Recognize the key process model for engineering of a system

– Appreciate the richness of decisions that are inherent in the engineering process

– Be aware of the diversity of expertise required for the i i


engineering processRef: Buede

SE ReferencesSE References

I i l C il S E i i i• International Council on Systems Engineering, www.incose.org

• D.M. Buede, The Engineering Design of System ‐Models and Methods, Wiley Series in Systems Engineering, 2000.

• A P Sage J E Armstrong Introduction to Systems Engineering Wiley Series in Systems• A.P. Sage, J.E. Armstrong, Introduction to Systems Engineering, Wiley Series in Systems Engineering, 2000.

• Mil‐Std‐499, “System Engineering Management”, 17 July 1969.

• Mil Std 499A “Engineering Management” 1 May 1974• Mil‐Std‐499A, Engineering Management , 1 May 1974.

• Mil‐Std‐499B, “Systems Engineering”, 7 Sept 1993.

• IEEE Std ‐1220‐1998, IEEE Standard for Application and Management of the Systems Engineering Process 1998Engineering Process, 1998.

• EIA‐632, “Processes for Engineering a System”, Sept 2003.

• ISO/IEC‐15288, “Systems and software engineering ‐ System life cycle processes”, 1 Feb 2008.

• “An Identification of Pragmatic Principles – Final Report” January 21 1993 INCOSE• An Identification of Pragmatic Principles – Final Report , January 21, 1993, INCOSE.

• A.T. Bahill, S.J. Henderson, “Requirements Development, Verification, and Validation Exhibited in Famous Failures”, Systems Engineering, Vol 8, No. 1, 2005, Wiley Periodicals.


Thank You!

Questions, Comments?
