Agenda for introduction

1
Agenda for introduction

• 1. Course details
• 2. Disclaimer
• 3. Reasons why systems fail
• 4. Products
• 5. Cycles, phases, and activities
• 6. PBDA
• 7. Management by WPs
• 8. CMMI

2
1. Course details

• Course and instructor
• Course content
• Textbook and time
• Schedule
• Grading
• Formats

1. Course details
3
Course and instructor

• Course -- 7310 Systems Engineering Design
• Room -- 218 Caruth Hall
• Instructor -- Jim Hinderer
• Work phone number -- [phone]
• Home phone number -- [phone]
• E-mail address -- j-hinderer_at_mindspring.com

1. Course details
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
5
Textbook and time

• Textbook -- none
• Class time -- 715 - 915
• URL for class notes -- www.engr.smu.edu/sys/Hinder
  er/7310

1. Course details
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
7
Grading

• Project -- 50
• Final -- 50

1. Course details
8
Formats

• Non-electronic Pencil and paper
• Electronic Office 97 Word, Excel, PowerPoint
• PC and not Macintosh

1. Course details
9
2. Disclaimer

• Design is more of an art than a science.
• Almost any approach to design will work if
  someone takes ownership of success
• No one approach is better than all the others
• We will use the approach used in the Systems
  Engineering Process course

2. Disclaimer
10
3. Reasons systems fail
after delivery
before delivery
lack of qualified people
unmanaged risks
didnt meet requirements
wrong requirements
overlooked something
failure to execute
failed to impress customer
other
3. Reasons systems fail
11
4. Products

• Product definition
• Products composed of products
• Types of products
• Need for products
• Need for lower-level products
• Examples

4. Products
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
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
14
Products composed of products
Level 1 Product
Higher-level products
Level 2 Product 1
Level 2 Product 2
Level 3 Product 1
Level 3 Product 2
Level 4 Product 2
Level 4 Product 1
Level 4 Product 3
Lower-level products
4. Products
15
Types of products (1 of 2)
Level N product
Delivered products
Support products
Products can be divided into two types of
products -- delivered products and support
products
4. Products
4. Products
16
Types of products (2 of 2)

• 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

4. Products
17
Need for products

• We need products to describe what were
  controlling
• Products may be developed or procured without
  development

4. Products
18
Need for lower-level products

• We need lower-level products if were going to
  procure something needed for doing the
  development

4. Products
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
4. Products
20
Example 2 -- house, bad example
House
Kitchen
Bathroom
Bedroom 1
Bedroom 2
Garage
Bad example -- We wouldnt use the lower-level
products to make the higher-level product
4. Products
21
Example 3 -- house, good example
House
Plumbing
Framing
Roof
Electrical
Foundation
Dry wall
Good example -- We can use the lower-level
products to make the higher-level product
4. Products
22
5. Cycles, phases, and activities

• Definitions
• Product life cycle
• Pre-develop-phase activities
• Develop-phase activities
• Post-develop-phase activities
• Example
• Classical development

5. Cycles, phases, and activities
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 tasks
• Process -- steps used to accomplish an activity

5. Cycles, phases, and activities
24
Product life cycle
Phases
Pre-develop
Develop
Post-develop
Time
5. Cycles, phases, and activities
25
Pre-develop-phase activities
Sub phases or activities
Sub phases overlap
Identify opportunity
Meet the customer
Discuss the work
Respond to RFP
Time
5. Cycles, phases, and activities
26
Develop-phase activities
Sub-phases or activities
Manage
Understand requirements
Sub-phases overlap
Design
Acquire products
Build
Verify
Sell off
Time
5. Cycles, phases, and activities
27
Post-develop-phase activities
Sub-phases
Field test and validate
Sub-phases overlap
Train
Operate
Maintain
Support
Produce
Upgrade
Dispose
Time
5. Cycles, phases, and activities
28
Example -- build a house
Activities
Supervise
Learn what buyer wants
Have architect make blueprint
Get land and lumber
Build
See if the house is OK
Close
Time
5. Cycles, phases, and activities
29
Classical development
30
6. PBDA

• Approach
• PBDA block diagram
• Application of PBDA to products
• Example
• Work products (WPs)

6. PBDA
31
The approach
Determine what customer wants
Make it happen
Decide what to do
Get what it takes to do it
Do it
Approach consists of applying these seven
activities to each product in the system
Check it out
Convince customer its what he or she wanted
6. PBDA
32
PBDA block diagram
External higher product teams
contracts, specs, interfaces
people facilities, tools, capital,
communications, library
schedule, budget, risks, TPPs, issues, AIs,
problems plans, timeline, changes, legal
status
1. Manage
contracts
MR
specs, I/Fs
2. Understand req
control, status
RR
design
3. Design
lower specs I/Fs
CR
PDR
CDR
4. Acquire
lower contracts, specs, interfaces
lower products
product
5. Build
test results test spec
lower test results
lower product, test results, test spec
6. Verify
status
agree
agree
TRR
VR
test proc
7. Sell off
External lower product teams
33
Application of PBDA to products
Higher product
Product of interest
Lower product 1
Lower product 2
Lower product N
PBDA is applied to each product separately
6. PBDA
34
Example (1 of 2)
System
Subsystem
Subsystem
HWCI
HWCI
Unit
HWCI
Unit
CSCI
CSCI
Example with 10 products
6. PBDA
35
Example (2 of 2)
1
2
3
5
8
6
7
10
9
Developing the example with 10 instantiations of
PBDA
6. PBDA
36
6. Management by WPs

• Definition
• Delivered products
• WPs for management
• WPs other activities
• Input WPs
• Optimizing WPs
• Pareto of WPs by likely use
• Measuring usefulness of WPs

7. Management by WPs
37
Definition

• A work product (WP) is a tangible object that is
  used to control the PBDA
• Documents
• Elements of environment to support engineering
• Much of the execution of the PBDA can be thought
  of as completing the associated WPs

PBDA executed by completing WPs
7. Management by WPs
38
Delivered products

• Delivered products (2) -- product and lower
  products
• The goal of PDBA is to transform lower products
  into the product
• Lower products may be
• Delivered products
• Support products
• Services
• Work products aid in the transformation

PBDA transforms lower products into higher product
7. Management by WPs
39
WPs for management

• Environment (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.
7. Management by WPs
40
WPs for other activities

• Understand (0) --
• Design (3) -- design, lower specs, lower
  interfaces
• Acquire (1) -- lower contracts
• Build (1) -- build procedure
• Verify (3) -- test spec, test procedure, test
  results
• Sell off (1) -- agreement

9 WPs used for developing each product in PBDA.
7. Management by WPs
41
Inputs WPs

• Higher inputs (3) -- contracts, specs, interfaces
• Lower inputs (3) -- lower test results, lower
  test spec, status
• Lower product (1) -- output from lower level

Inputs are monitored but dont belong to the
product of interest
7. Management by WPs
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 used
7. Management by WPs
43
Pareto of products by likely use
product (1)
budget schedule (2)
lower products (1)
risks TPPs (2)
environment (6)
issues and AIs (2)

higher inputs (3)
reviews and audits (9)
design (3)
plan and timeline (2)
problems and changes (2)
agreement (1)
build proc (1)
lower contract (1)
lower inputs (3)
legal (1)
verify (3)
decreasing likelihood of use
An example pareto of support products by likely
use
7. Management by WPs
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
7. Management by WPs
45
8. CMMI

• Definition
• Objectives
• Maturity levels
• Process areas
• Goals and practices
• Generic goals and practices
• Specific goals and practices
• Continuous vs staged models
• Evaluating adherence

8. CMMI
46
Definition

• A 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
47
Objectives (1 of 2)

• Improve performance, cost, and schedule
• Improve collaboration among stakeholders
• Provide competitive world-class products and
  services
• Provide common business and engineering
  perspective
• Handle systems-of-systems
• Use common processes for systems and software
• Ensure management support

8. CMMI
48
Objectives (2 of 2)

• Encourage looking ahead rather than behind
• Develop staff that uses best practices
• Allow moving staff among projects without
  changing processes
• Improve processes

8. CMMI
49
Maturity levels
5. Optimizing Emphasis on continuing improvement
4. Quantitatively managed Process measured
statistically controlled
3. Defined Process characterized for the
organization
2. Managed Process characterized for projects and
is often reactive
1. Initial Process unpredictable, poorly
controlled, and reactive
8. CMMI
50
Process areas (1 of 6)
1. INITIAL (0)
Focus none
8. CMMI
51
Process areas (2 of 6)
2. MANAGED (7) requirements management project
planning project monitoring and control supplier
agreement management measurement and
analysis process and product quality
assurance configuration management
Focus basic project management
8. CMMI
52
Process areas (3 of 6)
3. DEFINED (11) requirements development technical
solution product integration verification validat
ion
Focus process standardization
8. CMMI
53
Process areas (4 of 6)
3. DEFINED (CONTINUED) organization process
focus organizational process definition organizati
onal training integrated product management risk
management decision and analysis resolution
Focus process standardization
8. CMMI
54
Process areas (5 of 6)
4. QUANTITATIVELY MANAGED (2) organizational
process performance quantitative project
management
Focus quantitative management
8. CMMI
55
Process areas (6 of 6)
5. OPTIMIZING (2) organizational innovation and
deployment causal analysis and resolution
Focus continuous process improvement
8. CMMI
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
57
Generic goals and practices (1 of 2)

• GG 1 None
• GG 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
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
  management
• GG 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 3
• GG 5 Same as GG 4

8. CMMI
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 control
8. CMMI
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 control
8. CMMI
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 control
8. CMMI
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
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
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