Agenda for introduction

1. Introduction 1

Agenda for introduction

1. Course details 2. Basic approach 3. Products4. Cycles, phases, and activities5. Control 6. System engineering7. Homework

1. Introduction 2

1. Course details

Course and instructorCourse contentTextbook and timeScheduleGradingFormats

1. Course details

1. Introduction 3

Course and instructorCourse -- 7301 Systems Engineering Process

Room -- 125 Caruth Hall

Instructor -- Jim Hinderer

Work phone number -- (972) 344 7410

Home phone number -- (972) 596 2693

E-mail address -- [email protected]

1. Course details

1. Introduction 4

Course content

Show how to develop a system from start to delivery

Illustrate a product-based development approach (PBDA)

Show applications to commercial and military systems, large and small systems, hardware and software systems, and people systems

1. Course details

1. Introduction 5

Textbook and time

Textbook -- noneClass time -- 6:30 - 9:20

6:30 - 7:50 first lecture period 7:50 - 8:00 break 8:00 - 9:20 second lecture period

1. Course details

1. Introduction 6

Schedule8/28 Introduction9/4 Labor Day, no class9/11, 18 Understanding-customer9/25, 10/2, 9, 16 Design10/23 Acquisition and build10/30 Verification and sell-off11/6, 13 Management11/20 Processes11/27 Report, no class12/4 Implementation12/11 Final, take home

1. Course details

1. Introduction 7

GradingHomework 30%Exam 30%Final 40%

1. Course details

1. Introduction 8

FormatsNon-electronic: Pencil and paperElectronic: Office 97 Word, Excel, PowerPoint PC and not Macintosh

1. Course details

1. Introduction 9

2. Basic approach

System engineeringGuidelinesActivitiesApplication

2. Basic approach

1. Introduction 10

System engineeringSystem engineering is more of an art than a

science.Almost any method of system engineering

will work if someone takes ownership of success

No one method of system engineering is better than all the others

The goal of this course is to explain one method for developing systems and to indicate how this method relates to other methods.

2. Basic approach

1. Introduction 11

Guidelines

WisdomSimplicity

2. Basic approach

1. Introduction 12

Activities

Determine what customer wants

Decide what to do

Get what it takes to do it

Do it

Check it out

Convince customer it’s what he or she wanted

Make it happen

2. Basic approach

1. Introduction 13

Application

Apply same set of activities to each product

2. Basic approach

1. Introduction 14

3. Products

Product definitionProducts composed of productsNeed for lower-level productsExamples

3. Products

1. Introduction 15

Product definition (1 of 2)

A product is something produced by nature or by human industry or art

A product is something we can procure -- hardware, software, data, services.

3. Products

1. Introduction 16

Product definition (2 of 2)Examples

Hardware -- space shuttle, house, circuit card, resistor

Software -- program, firmware Data -- documents, management objects Services -- activities

The concept of a product makes explaining system engineering easier.

3. Products

1. Introduction 17

Products composed of products

Level 1 Product

Level 2 Product 1

Level 2 Product 2

Level 3 Product 1

Level 3 Product 2

Level 4 Product 2

Higher-level products

Lower-level products

Level 4 Product 1

Level 4 Product 3

3. Products

1. Introduction 18

Need for lower-level products

A product that doesn’t need development or support does not need lower-level products

Whether a product needs lower-level products depends upon whether we care about it. A stone has no lower level components A light bulb has lower level components,

but purchasers don’t care A personal computer has lower level

components, and some people may careWhether we want to put effort into it

3. Products

1. Introduction 19

Example 1 -- model airplane

Model airplane

Fuselage Wing Stabilizer Rudder Glue

Good example -- We can use the lower-level products to make the higher-level product

3. Products

1. Introduction 20

House

Kitchen Bathroom Bedroom 1 Bedroom 2 Garage

Bad example -- We wouldn’t use the lower-level products to make the higher-level product

Example 2 -- house, bad example

3. Products

1. Introduction 21

Example 3 -- house, good example

House

Plumbing Framing Roof Electrical

Good example -- We can use the lower-level products to make the higher-level product

Foundation Dry wall

3. Products

1. Introduction 22

4. Cycles, phases, and activities

DefinitionsProduct life cyclePre-develop-phase activitiesDevelop-phase activitiesPost-develop-phase activitiesNotes on activitiesExample


1. Introduction 23

Definitions

Cycle -- a complete set of events occurring in the same sequence Product life cycle Contract life cycle

Phase -- part of a cycle; the period of time the activities take

Activity -- execution of a set of tasksProcess -- steps used to accomplish an

activity


1. Introduction 24

Product life cycle

Phases

Time

Pre-develop

Post-develop

Develop


1. Introduction 25

Pre-develop-phase activities

Sub phases

Time

Meet the customer

Discuss the work

Respond to RFP

Sub phases overlap

Identify opportunity


1. Introduction 26

Develop-phase activities (1 of 2)

Determine what customer wants

Decide what to do

Get what it takes to do it

Do it

Check it out

Convince customer it’s what he or she wanted

Make it happen

Manage

Understand requirements

Design

Acquire products

Build

Verify

Sell-off


1. Introduction 27

Develop-phase activities (2 of 2)

Sub-phases

Time

Understand requirements

Design

Acquire products

Build

Verify

Sell off

Sub-phases overlap

Manage


1. Introduction 28

Post-develop-phase activitiesSub-phases

Time

Train

Produce

Upgrade

Maintain

Operate

Dispose

Sub-phases overlapField test and validate

Support


1. Introduction 29

Notes on activities

Not every product has the same activities Developing software may not require

acquiring products Integration or verification may be

deferred to another levelSome products may be so simple that they

don’t require formal management.


1. Introduction 30

Example 1-- build a houseActivities

Time

Learn what buyer wants

Have architect make blueprint

Get land and lumber

Build

See if the house is OK

Close

Supervise


1. Introduction 31

5. Control

Control by engineering productsControl by product-based

development approach (PBDA)

5. Control

1. Introduction 32

Control by engineering products (1 of 2)

Level N Product

DeliverableProducts

EnvironmentProducts

EngineeringProducts

Products can be divided into three delivered products. Environment products, and engineering products.

Products can be divided into three delivered products. Environment products, and engineering products.

5. Control

1. Introduction 33

Deliverable products -- part of level-N product

Environment products -- physical products that interact physically with the level-N product throughout its life, such as manufacturing, test, and maintenance equipment

Engineering products -- other products that enable development of the level-N product, such as specifications

Control by engineering products (2 of 2)

Engineering products support the developmentof delivered products and environment productsEngineering products support the developmentof delivered products and environment products

5. Control

1. Introduction 34

Control by PBDA (1 of 15)External: higher product teams

External: lower product teams

2. Understand req

3. Design

4. Acquire

1. Manage

5. Build6. Verify

7. Sell off

specs, I/Fs

lower specs & I/Fs

lowercontracts,specs,interfaces

lower test results

contracts

contracts,specs,interfaces

agree

design

schedule, budget,risks, TPPs, issues, AIs, plans, timeline, changes, problems, legal

agree

control,status

build proc

test proc

FCA

TRR VR

PDR CDR

RR

MR

CR

lower product,test results,

test spec

lower products

PCA

status

status

people, facilities, tools, capital,

communications, library

product

test resultstest spec

1. Introduction 35

Control by PBDA (2 of 15)

HigherProduct

LowerProduct 1

LowerProduct 2

LowerProduct N

Productof Interest

PBDA is applied to each product separately

5. Control

1. Introduction 36

Example with 10 productsExample with 10 products

System

Subsystem Subsystem

HWCI HWCI Unit

CSCI

HWCI Unit

CSCI


5. Control

1. Introduction 37

Developing the example with 10 instantiations of PBDADeveloping the example with 10 instantiations of PBDA

1

2 3

6 7 8

9 10

5


5. Control

1. Introduction 38

Control by PBDA (5 of 15)Environment (6) -- people, facilities, tools,

capital, communications, library Control (11) -- schedule, budget, risks, TPPs,

issues, AIs, timeline, plans, changes, problems, legal

Reviews and audits (9) --MR, RR, CD, PDR, CDR, TRR, VR, PCA, FCA

26 management activities for each product in PBDA26 management activities for each product in PBDA

5. Control

1. Introduction 39


Understand (0) -- Design (3) -- design, lower specs, lower

interfaces Acquire (1) -- lower contractsBuild (2) -- build procedure, productVerify (3) -- test spec, test procedure, test

resultsSell off (1) -- agreement

10 management activities for each product in PBDA10 management activities for each product in PBDA

5. Control

1. Introduction 40

Control by PBDA (7 of 15)Higher inputs (3) -- contracts, specs,

interfacesLower inputs (4) -- lower product, lower

test results, lower test spec, status

Inputs are monitored by aren’t MOsInputs are monitored by aren’t MOs

1. Introduction 41


Some management objects can be shared between levels

Not all management objects are needed at each level.

Not all management objects must always be usedNot all management objects must always be used

5. Control

1. Introduction 42


System engineering has evolved slowly Many disciplines such as software and

electrical engineering could not identify where they fit within system engineering, so they defined what they needed independently

As a result, there are many overlapping concepts

Other disciplines fit in as developers of products using PBDA

PBDA helps understand where other disciplines fit PBDA helps understand where other disciplines fit

5. Control

1. Introduction 43


Makes explaining system engineering easierAllows these disciplines to be parallel

rather than randomly aligned

system engineering

software

supportability electrical engineering

maintainabilityconfiguration management

PBDA allows disciplines to use similar approaches PBDA allows disciplines to use similar approaches

5. Control

1. Introduction 44


Alternate approach 106 activities 966 management objects Result of many overlapping perspectives

Alternate approaches have a lot of activities to manageAlternate approaches have a lot of activities to manage

5. Control

1. Introduction 45

Control by PBDA (12 of 15)PBDA

7 activities 43 items to manage• 36 management objects• 7 inputs• total of 35 + 8N for a product with N lower

products Result of applying same approach at all levels

PBDA is simplerPBDA is simpler

5. Control

1. Introduction 46


complexity

requirements size

hostility

use no MOs

use all MOs

When to use PBDA is determined by several factorsWhen to use PBDA is determined by several factors5. Control

1. Introduction 47

Control by PBDA (14 of 15)-1 -- maintained but an obstacle 0 -- not maintained 1 -- maintained but not used 2 -- maintained and used to monitor 3 -- maintained and used to control 4 -- maintained and used to optimize

Value of management object can be positive or negative Value of management object can be positive or negative

5. Control

1. Introduction 48


An example pareto of management objects by likely useAn example pareto of management objects by likely use5. Control

decreasing likelihood of use

product (1)

lower products (1)

higher inputs (3)

budget & schedule (2)

environment (6)

design (3)

build (1)

problems and changes (2)

risks & TPPs (2)

verify (3)

plan and timeline (2)

lower inputs (3)

reviews and audits (9)

agreement (1)

acquire (1)

issues and AIs (2)

legal (1)

physical

paper

externalpaper

1. Introduction 49

6. System engineering

Definition of RAADefinition of a systemDefinition of a product engineerDefinition of a project managerDefinition of a system engineer


1. Introduction 50

Definition of RAA (1 of 2)

R -- Responsibility: Who is supposed to do the task

A -- Authority : Who has the authority to do the task

A -- Accountability : Who gets blamed if something goes wrong

RAA has three partsRAA has three parts


1. Introduction 51

Definition of RAA (2 of 2)

The goal is to Give authority to people who are

responsible and accountable Make people with authority responsible

and accountable

The goal of RAA is to assign duty and powerto get the job done

The goal of RAA is to assign duty and powerto get the job done


1. Introduction 52

Definition of a system

Definition used here Each product is a system

Definitions used by others System is the highest level product System is the highest level product

within a company or an enterprise

Each product is a systemEach product is a system


1. Introduction 53

Definition of a product engineer

The person who has RAA for the product Performs the roles of the project manager

and the system engineer

The product engineer has RAA for the productThe product engineer has RAA for the product


1. Introduction 54

Definition of a project manager

The person who has RAA for the product Manages projectProvides the environment to develop the

productGenerally has a significant level of technical

depth

The project manager is a product engineerwho concentrates on management

The project manager is a product engineerwho concentrates on management


1. Introduction 55

Definition of a system engineer (1 of 6)

Definition used here The person who has RAA for the technical

part of the product and the administrative duties associated with the technical part

Reports to project manager

As used here, system engineering does a subset of the product engineer tasks

As used here, system engineering does a subset of the product engineer tasks


1. Introduction 56


Definitions used by others Customer advocate and system auditor Technical leader Developer of the system front end Requirements keeper

There are many other definitions of system engineer used in practice

There are many other definitions of system engineer used in practice


1. Introduction 57


Perceptions of system engineer vary from technical leader to clerk

Problems Not technical Role not understood by management Doesn’t get done in time Overcome by events

The perception of the system engineering jobvaries from technical leader to clerk

The perception of the system engineering jobvaries from technical leader to clerk


1. Introduction 58


System engineer should lead the parade rather than clean up behind it

A problem the system engineer must overcome is being passed by the design, product acquisition, build, and verification activities

The ideal system engineer is a leaderThe ideal system engineer is a leader


1. Introduction 59


Leadership involves finding the leaders and being a leader among the leaders

Leadership involves finding the most active part of a project and leading at that point

A system engineer can become absorbed in processes to the point of abdicating leadership

Becoming a leader takes a lot of work and there are many pitfalls

Becoming a leader takes a lot of work and there are many pitfalls


1. Introduction 60


modifier synthesizer

challenger

reproducer dreamer

innovator

planner

practicalizer

risk

creativity

A challenge is be recognized as an innovatorA challenge is be recognized as an innovator6. System engineering

1. Introduction 61

7. Homework (1 of 2)

1. What is the best method for developing products: (a) product-based-development approach (PBDA), (b) object-oriented development, (c) clean room, (d) no one method of system engineering is better than all the others?

2. How many products are shown in example 1.3-3: (a) 0, (b) 1, (c) 6, (7)?

3. How many design activities are associated with the products in example 1.3-3: (a) 0, (b) 1, (c) 6, (7)?

7. Homework

1. Introduction 62

Homework (2 of 2)

4. The activity of getting land and lumber in example 1.4-1 is which one of the following PBDA activities: (a) manage, (b) design, (c) acquire products, (d) build?

5. An interface document between subsystems is an example of (a) development product, (b) engineering product, (c) environment product, (d) activity?

6. Which of the following has the greatest RAA: (a) product engineer, (b) system engineer, (c) project manager, (d) all have the same RAA?

7. Homework

Agenda for introduction

Documents

Transcript of Agenda for introduction