1 Agenda for PBDA 1. Basic approach 2. Products 3. Cycles 4. Product-based development approach (PBDA)
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
1
Agenda for PBDA
1. Basic approach 2. Products3. Cycles4. Product-based development
approach (PBDA)
2
1. Basic approach
The approachExecution of the approachEmphasis on executing the approachApplication of the approachReason for the approachDisclaimer for the approachGoal of this course
1. Basic approach
3
The approach
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
1. Basic approach
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
4
Execution of the approach
Execution of the approach consists of completing a small number of tangible objects called work products (WPs) for each product in the system
1. Basic approach
5
Emphasis on executing the approach
1. Basic approach
Emphasis on executing the approach is on• Wisdom -- we don’t want to do stupid things• Simplicity -- we don’t want to lose the forest
in all the trees
6
Application of the approach
Apply same set of activities to each product in the system
This approach deals with development of products from conception to sell-off
1. Basic approach
7
Reason for the approach (1 of 2)
The approach brings discipline to the development by accommodating all aspects of the product and its life cycle in a way that the product comes together smoothly
Having a disciplined approach to developing products makes cost, schedule, and quality predictable
Having a disciplined approach reduces the likelihood of system failure
1. Basic approach
8
Reason for the approach (2 of 2)
after deliverybefore delivery
lack of qualified people
unmanaged risks
wrong requirements
failure toexecute
other
didn’t meetrequirements
overlookedsomething
failed
failed to impresscustomer
1. Basic approach
9
Disclaimer for the approach
System engineering is more of an art than a science.
Almost any approach to system engineering will work if someone takes ownership of success
No one approach is better than all the othersThe reasons for applying any system
engineering approach are the same as for the PBDA
1. Basic approach
10
Goal of this course
The goal of this course is to explain one approach for developing systems and to indicate how this approach relates to other approaches.
1. Basic approach
11
2. Products
Product definitionProducts composed of productsTypes of productsNeed for productsNeed for lower-level productsExamples
2. Products
12
Product definition (1 of 2)
A product is something produced A product is something we can procure --
hardware, software, data, services.
2. 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.
2. Products
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 2. Products
15
Types of products (1 of 2)
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
2. Products
delivered products
support products
16
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
Types of products (2 of 2)
2. Products
17
Need for products
We need products to describe what we’re controlling
Products may be developed or procured without development
2. Products
18
Need for lower-level products
We need lower-level products if we’re going to procure something needed for doing the development
2. Products
19
Good example -- we can use the lower-levelproducts to make the higher-level product
Good example -- we can use the lower-levelproducts to make the higher-level product
Examples (1 of 4)
model airplane
fuselage wing stabilizer rudder glue
2. Products
Example 1 -- model airplane
20
Bad example -- we wouldn’t use the lower-levelproducts to make the higher-level product
Bad example -- we wouldn’t use the lower-levelproducts to make the higher-level product
house
kitchen bathroom bedroom 1 bedroom 2 garage
Examples (2 of 4)
2. Products
Example 2 -- house as a bad example
21
Good example -- we can use the lower-levelproducts to make the higher-level product
Good example -- we can use the lower-levelproducts to make the higher-level product
Examples (3 of 4)
house
plumbing foundation framing roof electrical dry wall
2. Products
Example 3 -- house as a good example
22
Examples (4 of 4)
radar
sensor computer
staff facilities tools capital communications library
system integration lab
delivered products
Development of a product includes both deliveredand support products.
Development of a product includes both deliveredand support products.
Example 4 -- supportproducts
2. Products
23
3. Cycles
Product life cyclePre-develop-phase activitiesDevelop-phase activitiesPost-develop-phase activitiesNew government life cycleLife cycle of a product-line
3. Cycles
24
Product life cycle
phases
time
pre-develop
post-develop
develop
3. Cycles
Product life cycle has three phases Product life cycle has three phases
25
Pre-develop-phase activities
sub phases or activities
time
meet the customer
discuss the work
respond to RFP
identify opportunity
3. Cycles
Overlapping sub-phases or activities get enterpriseinto business and prepare for development phase
Overlapping sub-phases or activities get enterpriseinto business and prepare for development phase
26
Develop-phase activities (1 of 4)
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
controlunderstand wants
design
acquire products
build
verify
sell-off
Activities in develop phase
are the same as in basic approach
but with morefamiliar names
Activities in develop phase
are the same as in basic approach
but with morefamiliar names
3. Cycles
27
Develop-phase withnames of basic
approach
Develop-phase withnames of basic
approach
Develop-phase activities (2 of 4)
sub-phases or activities
time
understand wants
design
acquire products
build
verify
sell off
control
3. Cycles
28
Develop-phase activities (3 of 4)
Not every product has the same activities• Developing software may not require
acquiring products• Integration or verification may be
deferred to another level• Some products may be so simple that
they don’t require formal management.
3. Cycles
29
Develop-phase activities (4 of 4)
activities
time
learn what buyer wants
have architect make blueprint
get land and lumber
build
see if the house is OK
close
supervise
3. Cycles
30
Post-develop-phase activities
time
train
produce
upgrade
maintain
operate
dispose
Overlapping activitiesof post development
complete the life cycle
Overlapping activitiesof post development
complete the life cycle
field test and validate
support
3. Cycles
sub-phases or activities
31
New government life cycle
concept &technology
development
systemdevelopment &demonstration
productionand
deployment
operationsand
support
A B C IOC FOC
Technology opportunities and user-needs entry points
pre-system acquisition
system acquisition(EMD LRIP and production)
sustainment
MNS ORDrequirements process
New government life cycle accommodates COTSNew government life cycle accommodates COTS
3. Cycles
32
Product-line life cycle
time
product 2
product N-1
product N
product 1
Product line has a life cycle with each producthaving its own life cycle
Product line has a life cycle with each producthaving its own life cycle
life cycle of product N
3. Cycles
33
4. PBDA
PBDA block diagramApplication of PBDAValue of PBDAWork products (WPs)Major work productsProcess WPsTemporary WPsDivisions of WPsOptimizing WPs
4. PBDA
34
PBDA block diagram (1 of 2)
1. control
2. understand wants
3. design
4. acquire
5. build
6. verify
7. sell off
external: customer team
external: sub product teams
wants
agreed-upon wants
design
sub wants
sub
pro
du
ct
ag
reem
ent
sub test results
sub products
schedulebudgetrisks
actionsconfigurationsreviews
tes
t re
sult
s pro
du
ct
tes
t re
sult
s
ag
reem
ent
checkliststeps
steps
4. PBDA
35
PBDA block diagram (2 of 2)
The PBDA diagram shows products and work products as text• On lines connecting activities• On bubbles attached to activities
4. PBDA
36
Application of PBDA (1 of 4)
productof interest
lower product 1
lowerproduct 2
lowerproduct N
higherProduct
PBDA is applied to each product separatelyPBDA is applied to each product separately
4. PBDA
37
Application of PBDA (2 of 4)
Sub products usually come from lower products in the hierarchy, but they may come from peer or higher products -- especially when a product is being installed on another product
The customer is usually a higher product but the customer may a peer or lower product. There may also be multiple customer products
4. PBDA
38
Example with 10 productsExample with 10 products
System
Subsystem Subsystem
HWCI HWCI Unit
CSCI
HWCI HWCI
CSCI
Application of PBDA (3 of 4)
4. PBDA
Example with 10 products
39
Developing the example with 10 instantiations of PBDADeveloping the example with 10 instantiations of PBDA
1
2 3
6 7 8
9 10
5
Application of PBDA (4 of 4)
4. PBDA
Example with 10 products(continued)
40
Value of PBDA (1 of 3)
Makes explaining system engineering easierHandles systems at all levels• Not just top-level
Handles systems of all sizes• Not just top-level
Handles systems from start-to finish• Not just through development
Handles work products as systems
4. PBDA
41
Value of PBDA (2 of 3)
Handles all developers• Not just government
Handles teaming• Not just one-company
Handles other disciplines • Other disciplines fit in as developers of
products using PBDAReduces the number of types of products
that must be addressed -- with resulting decrease in process costs
4. PBDA
42
requirements management plan
Value of PBDA (3 of 3)
Brings order to the large number of WPsBrings order to the large number of WPs
4. PBDA
design
sub wants
budget
risksactions
configurationproblems
reviewsproduct
build steps
verify steps
test results
agreement
checklist
RR -requirements review
CR -- concept review
PDR -- preliminary design review
CDR -- critical design reviewTRR -- test readiness review
VR -- verification review
FCA -- functional configuration audit
PCA -- physical configuration audit
MM -- management review
production plan
improvement plan
maintenance plan
support planoperation plan
build plan
verification plan
disposal plan
metrics
minutes
process
improvementsdesign
sub wants
budget
risks
actions
configuration
problems
reviews
product
build steps
verify steps
test resultsagreement
checklist
design
sub wants
budget
risks
actions
configuration
problems
reviews
productbuild steps
verify steps
test results
agreement
checklist
The number of WPs can be overwhelming without a method to bring order
43
Definition of work products (WP)
A work product (WP) is a document that is used to control the PBDA
Much of the execution of the PBDA can be thought of as creating and using the associated WPs
Major work products are used for most of the product development
Minor work products are used for the remainder of the development
PBDA executed by creating and using WPsPBDA executed by creating and using WPs
4. PBDA
44
Major work products (1 of 4)
designwants
sub wantssub product
sub test result
sub agreement
schedule
budget
risks
actions
configuration
problems
reviews
product
build steps verify steps
test results
agreement
There are 15 major WPs used by in development shown in red
There are 15 major WPs used by in development shown in red
checklist
4. PBDA
45
Major work products (2 of 4)
designwants
sub wantssub product
sub test result
sub agreement
schedule
budget
risks
actions
configuration
problems
reviews
product
build steps verify steps
test results
agreement
product (not a WP)
product (not a WP)
There are 14 major WPs in developmentbecause a product is not a document
There are 14 major WPs in developmentbecause a product is not a document
checklist
4. PBDA
46
Major work products (3 of 4)
designwants
sub wantssub product
sub test result
sub agreement
schedule
budget
risks
actions
configuration
problems
reviews
product
build steps verify steps
test results
agreement
customer team
sub team
contractor team
The contractor team has RAA for the red WPs whereasother teams have RAA for the remaining WPs
The contractor team has RAA for the red WPs whereasother teams have RAA for the remaining WPs
checklist
4. PBDA
47
Major work products (4 of 4)
Many of the products are dependent upon predecessor products
Many of the products are dependent upon predecessor products
designwants
sub wantssub product
sub test result
sub agreement
schedule
budget
risks
actions
configuration
problems
reviews
product
build steps verify steps
test results
agreement
W D
D
W D
D
customer
checklist
4. PBDA
48
Process WPs
metrics
Providing processes adds more WPsProviding processes adds more WPs
minutes
process
improvements
processes
4. PBDA
49
design
Temporary WPs
Many temporary WPs appearMany temporary WPs appear
design
schedule
plan
concept
A plan is early portions of the schedule and design
The concept is the underlying idea, cost drivers, and major partitioning of the design
4. PBDA
50
Divisions of WPs (1 of 3)
design
wants sub wants
test results
Many of the WPs are made up of WPsMany of the WPs are made up of WPs
contract
SOW
spec
external I/Fs
INS
DEM
TST
ANA
problem
description
studies
manage
contract
SOW
spec
external I/Fs
problem
timeline
FFBDs
trades
4. PBDA
51
Divisions of WPs (2 of 3)
schedule risks
actions configurationproblems
date
functional
action
issues
CRs
I&T
CM
history
TPPs
risks
4. PBDA
52
Divisions of WPs (3 of 3)
reviews
RR -requirements review
CR -- concept review
PDR -- preliminary design review
CDR -- critical design review
TRR -- test readiness review
VR -- verification review
FCA -- functional configuration audit
PCA -- physical configuration audit
MM -- management review
process
mandatory
steps
4. PBDA
53
Optimizing WPs (1 of 4)
Not all WPs must be formally usedNot all WPs must be formally used4. PBDA
design
sub wants
schedule
budget
risks
actions
configuration
problems
reviews
product
build steps
verify steps
test results
agreement
Radar(all used)
checklist
schedule
actions
configuration
problems
product
Spec(some used)
checklist
agreement
54
Optimizing WPs (2 of 4)
complexity
requirements size
hostility
Don’t useWP
Use WP
Size, complexity, requirements, and level of hostilitydetermine when to use a WP
Size, complexity, requirements, and level of hostilitydetermine when to use a WP
4. PBDA
55
Optimizing WPs (3 of 4)
budget
risks
metrics
process
improvements
Some WPs are maintained only at enterprise levelSome WPs are maintained only at enterprise level
enterprise
4. PBDA
56
Optimizing WPs (4 of 4)
risksproject
Some WPs are maintained only at project levelSome WPs are maintained only at project level4. PBDA
Related Documents
