1. PBDA 1

Agenda for introduction1. Course details2. Disclaimer3. Reasons why systems fail4. Products5. Cycles, phases, and activities6. PBDA7. Management by WPs8. CMMI

1. PBDA 2

1. Course details

Course and instructorCourse contentTextbook and timeScheduleGradingFormats

1. Course details

1. PBDA 3

Course and instructorCourse -- 7310 Systems Engineering Design

Room -- 218 Caruth Hall

Instructor -- Jim Hinderer

Work phone number -- (972) 344 7410

Home phone number -- (972) 359 1557

E-mail address -- j-hinderer@mindspring.com

1. Course details

1. PBDA 4

Course content

Show how to design a system from start to delivery

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

1. Course details

1. PBDA 5

Textbook and time

Textbook -- noneClass time -- 7:15 - 9:15URL for class notes --

www.engr.smu.edu/sys/Hinderer/7310

1. Course details

1. PBDA 6

Schedule May 28 -- Introduction June 2 -- Design June 4 -- Ideas June 9, 11 -- Example June 16, 18 -- Software June 23, 25 -- System June 30 -- Hardware July 2, 7 -- Math 1 July 9, 14 -- Math 2 July 16, 21 -- Transforms 1 July 23, 28 -- Transforms 2 July 30 -- Final

1. Course details

1. PBDA 7

Grading

Project -- 50%Final -- 50%

1. Course details

1. PBDA 8

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

1. Course details

1. PBDA 9

2. DisclaimerDesign is more of an art than a science.Almost any approach to design will work if

someone takes ownership of successNo one approach is better than all the othersWe will use the approach used in the

Systems Engineering Process course

2. Disclaimer

1. PBDA 10

3. Reasons systems failafter

deliverybefore

delivery

lack of qualified people

unmanaged risks

wrong requirements

failure toexecute

other

didn’t meetrequirements

overlookedsomething

failed to impresscustomer

3. Reasons systems fail

1. PBDA 11

4. Products

Product definitionProducts composed of productsTypes of productsNeed for productsNeed for lower-level productsExamples

4. Products

1. PBDA 12

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.

4. Products

1. PBDA 13

Product definition (2 of 2)Examples

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

Software -- program, firmware Data -- documents, work products Services -- activities

The concept of a product makes explaining system engineering easier.

4. Products

1. PBDA 14

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

4. Products

1. PBDA 15

Types of products (1 of 2)

4. Products

Level N product

Products can be divided into two types of products -- delivered products and support products

Products can be divided into two types of products -- delivered products and support products

4. Products

Delivered products

Support products

1. PBDA 16

Types of products (2 of 2)

4. Products

Delivered products -- part of the delivered product

Support products -- other products in support of delivered product

Either type of product may be

Hardware

Software

Data

Service

1. PBDA 17

Need for products

We need products to describe what we’re controlling

Products may be developed or procured without development

4. Products

1. PBDA 18

Need for lower-level productsWe need lower-level products if we’re

going to procure something needed for doing the development

4. Products

1. PBDA 19

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

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

Example 1 -- model airplane

Model airplane

Fuselage Wing Stabilizer Rudder Glue

4. Products

1. PBDA 20

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

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

House

Kitchen Bathroom Bedroom 1 Bedroom 2 Garage

Example 2 -- house, bad example

4. Products

1. PBDA 21

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

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

Example 3 -- house, good example

House

Plumbing Framing Roof ElectricalFoundation Dry wall

4. Products

1. PBDA 22

5. Cycles, phases, and activities

DefinitionsProduct life cyclePre-develop-phase activitiesDevelop-phase activitiesPost-develop-phase activitiesExampleClassical development

5. Cycles, phases, and activities

1. PBDA 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

5. Cycles, phases, and activities

1. PBDA 24

Product life cycle

Phases

Time

Pre-develop

Post-develop

Develop

5. Cycles, phases, and activities

1. PBDA 25

Pre-develop-phase activities

Sub phasesor activities

Time

Meet the customer

Discuss the work

Respond to RFP

Sub phases overlap

Identify opportunity

5. Cycles, phases, and activities

1. PBDA 26

Develop-phase activitiesSub-phasesor activities

Time

Understand requirements

Design

Acquire products

Build

Verify

Sell off

Sub-phases overlap

Manage

5. Cycles, phases, and activities

1. PBDA 27

Post-develop-phase activitiesSub-phases

Time

Train

Produce

Upgrade

Maintain

Operate

Dispose

Sub-phases overlapField test and validate

Support

5. Cycles, phases, and activities

1. PBDA 28

Example -- 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

5. Cycles, phases, and activities

1. PBDA 29

Classical development

Concept &technology

development

Systemdevelopment &demonstration

Productionand

deployment

Operationsand

support

A B C IOC FOC

Technology opportunities and user needs

Pre-system acquisition

System acquisition(EMD LRIP and production)

Sustainment

MNS ORD

Requirements process

1. PBDA 30

6. PBDAApproachPBDA block diagramApplication of PBDA to productsExampleWork products (WPs)

6. PBDA

1. PBDA 31

The approachDetermine 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

6. PBDA

Approach consists of applying these seven activities to each product in the

system

Approach consists of applying these seven activities to each product in the

system

1. PBDA 32

PBDA block diagram

1. Manage

2. Understand req

3. Design

4. Acquire

5. Build6. Verify

7. Sell off

External: higher product teams

External: lower product teams

contracts,specs,interfaces

specs, I/Fscontracts

lower specs & I/Fs

design

lowercontracts,specs,interfaces

status

lower product,test results,

test spec agree

lower test results

lower products

build proc

product

test proc

test resultstest spec

peoplefacilities, tools, capital,

communications, library

schedule, budget,risks, TPPs,

issues, AIs, problemsplans, timeline, changes, legal

control,status

agree

status

MR

RR

CR PDR CDR

TRR VR

FCA PCA

1. PBDA 33

Application of PBDA to products

Productof interest

Lowerproduct N

Higherproduct

Lowerproduct 1

Lowerproduct 2

PBDA is applied to each product separately

6. PBDA

1. PBDA 34

Example with 10 productsExample with 10 products

System

Subsystem Subsystem

HWCI HWCI Unit

CSCI

HWCI Unit

CSCI

Example (1 of 2)

6. PBDA

1. PBDA 35

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

1

2 3

6 7 8

9 10

5

Example (2 of 2)

6. PBDA

1. PBDA 36

6. Management by WPsDefinitionDelivered productsWPs for managementWPs other activitiesInput WPsOptimizing WPsPareto of WPs by likely useMeasuring usefulness of WPs

7. Management by WPs

1. PBDA 37

Definition

A work product (WP) is a tangible object that is used to control the PBDA Documents Elements of environment to support

engineeringMuch of the execution of the PBDA can be

thought of as completing the associated WPs

PBDA executed by completing WPsPBDA executed by completing WPs

7. Management by WPs

1. PBDA 38

Delivered productsDelivered products (2) -- product and

lower productsThe goal of PDBA is to transform lower

products into the productLower products may be

Delivered products Support products Services

Work products aid in the transformation

PBDA transforms lower products into higher productPBDA transforms lower products into higher product

7. Management by WPs

1. PBDA 39

WPs for managementEnvironment (6) -- people, facilities, tools,

capital, communications, library [support products]

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 WPs support products used for managing each product in PBDA. 26 WPs support products used for managing each product in PBDA.

7. Management by WPs

1. PBDA 40

WPs for other activities

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

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

resultsSell off (1) -- agreement

9 WPs used for developing each product in PBDA. 9 WPs used for developing each product in PBDA.

7. Management by WPs

1. PBDA 41

Inputs WPsHigher inputs (3) -- contracts, specs, interfacesLower inputs (3) -- lower test results, lower test

spec, statusLower product (1) -- output from lower level

Inputs are monitored but don’t belong to the product of interest

Inputs are monitored but don’t belong to the product of interest

7. Management by WPs

1. PBDA 42

Optimizing WPs

Some work products can be shared between levels

Not all work products are needed at each level.

Not all WPs must always be usedNot all WPs must always be used

7. Management by WPs

1. PBDA 43

Pareto of products by likely use

7. Management by WPs

An example pareto of support products by likely useAn example pareto of support products by likely use

decreasing likelihood of use

product (1)

lower products (1)

higher inputs (3)

budget & schedule (2)

environment (6)

design (3)

build proc (1)

problems and changes (2)

risks & TPPs (2)

verify (3)

plan and timeline (2)

lower inputs (3)

reviews and audits (9)

agreement (1)

lower contract (1)

issues and AIs (2)

legal (1)

1. PBDA 44

Measuring usefulness of WPs-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 an WP can be positive or negative Value of an WP can be positive or negative

7. Management by WPs

1. PBDA 45

8. CMMIDefinitionObjectivesMaturity levelsProcess areasGoals and practicesGeneric goals and practicesSpecific goals and practicesContinuous vs staged modelsEvaluating adherence

8. CMMI

1. PBDA 46

DefinitionA maturity measurements method

A collection of best practices that address productivity, performance, cost, and stakeholder satisfaction

An integrated view of process improvement across disciplines

A follow on to SEI by Carnegie Mellon A standard by which Government selects

contractors http://www.sei.cmu.edu/cmmi/products/

models.html

8. CMMI

1. PBDA 47

Objectives (1 of 2)Improve performance, cost, and scheduleImprove collaboration among stakeholdersProvide competitive world-class products and

servicesProvide common business and engineering

perspectiveHandle systems-of-systemsUse common processes for systems and

softwareEnsure management support

8. CMMI

1. PBDA 48

Objectives (2 of 2)Encourage looking ahead rather than behindDevelop staff that uses best practicesAllow moving staff among projects without

changing processesImprove processes

8. CMMI

1. PBDA 49

Maturity levels

1. InitialProcess unpredictable, poorly controlled, and reactive

2. ManagedProcess characterized for projects and is often reactive

3. DefinedProcess characterized for the organization

4. Quantitatively managedProcess measured & statistically controlled

5. OptimizingEmphasis on continuing improvement

8. CMMI

1. PBDA 50

Process areas (1 of 6)

Focus: noneFocus: none

1. INITIAL (0)

8. CMMI

1. PBDA 51

Process areas (2 of 6)

Focus: basic project managementFocus: basic project management

2. MANAGED (7)requirements management

project planningproject monitoring and control

supplier agreement management

measurement and analysisprocess and product quality assurance

configuration management

8. CMMI

1. PBDA 52

Process areas (3 of 6)

Focus: process standardizationFocus: process standardization

3. DEFINED (11)requirements development

technical solutionproduct integration

verificationvalidation

8. CMMI

1. PBDA 53

Process areas (4 of 6)

Focus: process standardizationFocus: process standardization

3. DEFINED (CONTINUED)organization process focus

organizational process definitionorganizational training

integrated product managementrisk management

decision and analysis resolution

8. CMMI

1. PBDA 54

Process areas (5 of 6)

Focus: quantitative managementFocus: quantitative management

4. QUANTITATIVELY MANAGED (2)organizational process performance

quantitative project management

8. CMMI

1. PBDA 55

Process areas (6 of 6)

Focus: continuous process improvementFocus: continuous process improvement

5. OPTIMIZING (2)organizational innovation and deployment

causal analysis and resolution

8. CMMI

1. PBDA 56

Goals and practices

GG GG GG GG GG

SG SG SG SG SG

•Generic goals (GG) • Apply to each process area within a maturity levels• Have required generic practices (GP)

•Specific goals (SG)•Apply to process areas•Have required specific practices (SP)

8. CMMI

1. PBDA 57

Generic goals and practices (1 of 2)GG 1: NoneGG 2: Institutionalize a managed process

GP 2.1 Establish an organizational policy GP 2.2 Plan the process GP 2.3 Provide resources GP 2.4 Assign responsibility GP 2.5 Train people GP 2.6 Manage configurations GP 2.7 Identify and involve relevant

stakeholders

8. CMMI

1. PBDA 58

Generic goals and practices (2 of 2) GP 2.8 Monitor and control the process GP 2.9 Objectively evaluate adherence GP. 2.10 Review status with higher-level

managementGG 3: Institutionalize a defined process

All GG 2 GPs GP 3.1 Establish a defined process GP 3.2 Collect improvement information

GG 4: Same as GG 3GG 5: Same as GG 4

8. CMMI

1. PBDA 59

Specific goals and practices (1 of 3)SG 1 Establish estimates

SP 1.1 Estimate the scope of the requirements

SP 1.2 Establish estimates of work products and task attributes

SP 1.3 Define project life cycle SP 1.4 Determine estimates of effort and

cost

Example for project monitoring and controlExample for project monitoring and control8. CMMI

1. PBDA 60

Specific goals and practices (1 of 3)SG 2 Develop a project plan

SP 2.1 Establish the budget and schedule

SP 2.2 Identify project risks SP 2.3 Plan for data management SP 2.4 Plan for project resources SP 2.5 Plan for needed knowledge and

skills SP 2.6 Plan stakeholder involvement SP 2.7 Establish the project plan

Example for project monitoring and controlExample for project monitoring and control8. CMMI

1. PBDA 61

Specific goals and practices (1 of 3)SG 3 Obtain commitment to the plan

SP 3.1 Review plans that affect the project

SP 3.2 Reconcile work and resource levels

SP 3.3 Obtain pan commitment

Example for project monitoring and controlExample for project monitoring and control8. CMMI

1. PBDA 62

Continuous vs staged models (1 of 2)Continuous model

Process areas may have different levels of maturity

Same GGs, GPs, SGs and SPs as staged

729 page document; different than staged

8. CMMI

1. PBDA 63

Continuous vs staged models (2 of 2)Staged model

All process areas must have the same level of maturity

Same GGs, GPs, SGs and SPs as continuous

729 page document; different than continuous

8. CMMI

1. PBDA 64

Evaluating adherence

Categories Fully implemented Largely implemented Partially implemented Not implemented

All instantiations must be fully implemented for the enterprise to be fully implemented