1 Agenda for implementation of PBDA r1. Optimization of product development r2. Heuristics r3....
-
Upload
ellen-wilson -
Category
Documents
-
view
215 -
download
0
Transcript of 1 Agenda for implementation of PBDA r1. Optimization of product development r2. Heuristics r3....
1
Agenda for implementation of PBDA
1. Optimization of product development2. Heuristics3. Application notes4. Questions to identify risks
2
1. Optimization of product development
Adapting the process Performing an activity once Omitting activities Using one group of people Rolling up information Embedding tasks Doing what people do naturally Avoiding duplication Avoiding low-value concepts Avoiding events that are OBE Avoiding over-run
1. Optimization of product development
3
Adapting the process
Adapt process by• Using PBD activities as template • Adapting PBD activities to the
program
1. Optimization of product development
4
Performing an activity once (1 of 2)
Perform the following tasks once at the program level• Processes• Tools• Communications and library• Life cycle plan• IMP, SEMP, SDP
1. Optimization of product development
5
Performing an activity once (2 of 2)
Work the following only once at the enterprise level• People• Facilities• Capital• Tools
1. Optimization of product development
6
Omitting activities
Examples of products not needing the acquire activity• Software • Providing a service • Products having no lower products
Example of product not needing activities after design• Studies
Example of products not needing verify activity• Program that move all testing to the highest level
1. Optimization of product development
7
Using one group of people (1 of 2)
Using a common group of people for each of the following across all products
• Reliability
• Maintainability
• Safety
• Supportability
• Training
• Test planning
1. Optimization of product development
8
Rolling up information
Maintain the following at the product level but roll results to top• Schedule • Budget• TPPs
1. Optimization of product development
9
Embedding tasks
Embed the following as indicated • Processes into PBD activities• Plans into the schedule• Trade studies and analysis into requirements,
design, and verification• Validation into requirements and design• Testability, supportability, reliability, and
maintainability into design
1. Optimization of product development
10
Doing what people do naturally (1 of 6)
Productivity can be increased by asking people to do things they do naturally
People resist doing work the hard wayExamples
• Using familiar tools• Avoiding change of focus• Avoiding unuseful work
1. Optimization of product development
11
Doing what people do naturally (2 of 6)
Using familiar tools• Allowing people to use familiar tools
improves productivity• People prefer using tools they’re use to• For example, people prefer using Word,
Excel, and PowerPoint rather than data base tools like RTM, SLATE, or DOORS
1. Optimization of product development
12
Doing what people do naturally (3 of 6)
Avoiding change of focus • Allowing people to focus on one area at a
time improves productivity• People resist frequent changes of focus
1. Optimization of product development
13
Doing what people do naturally (4 of 6)
Example 1 -- Writing
• Focuses -- Content, grammar, and spelling
• Desirable -- Check each once per document
• Undesirable -- Check each once per sentence
1. Optimization of product development
14
Doing what people do naturally (5 of 6)
Example 2 -- Requirements Management• Focuses -- Content, VM, and tracing • Desirable -- Check each once per
document• Undesirable -- Check each once per
requirement
1. Optimization of product development
15
Doing what people do naturally (6 of 6)
Example 3 -- Documentation of Studies• Focuses -- Content and documentation • Desirable -- Check each once per study• Undesirable -- Check each once per update
1. Optimization of product development
16
Avoiding duplication
Avoid duplication in the following areas• Requirements between levels in the product
hierarchy• Requirements between requirements, design, and
verification descriptions• Tutorial information such as product descriptions• Designs between levels of product hierarchy• Analyses and trade studies resulting from having lost
earlier versions
1. Optimization of product development
17
Avoiding low-value concepts (1 of 4)
Avoiding error paths in processesAvoiding iteration in processesAvoiding studies without objectives
Editorial
1. Optimization of product development
18
Avoiding low-value concepts (2 of 4)
Avoiding error paths in processes• Assume a success; and if an obstacle presents itself,
find a way around the obstacle.• Error paths in processes appear to give completion
since they represent the path to be taken in case of an undesired outcome
• Error paths clutter process diagrams, require time to obtain agreement on their design and are almost never tracked in processes
• Just do the task and not document ways of failing to reach the goal
1. Optimization of product development
19
Avoiding low-value concepts (3 of 4)
Avoiding Iteration in processes• Iteration and recursion in process diagrams
reflect a common practice• The common practice is to try to do
something; and then if unsuccessful, try again.• Like error paths, iteration and recursion
require time to obtain agreement on their design and are almost never tracked in processes
1. Optimization of product development
20
Avoiding low-value concepts (4 of 4)
Avoiding studies without objectives• Give objectives to trade studies and analysis• Treat as tools and use them when needed• Avoid performing them for their own sake
1. Optimization of product development
21
Avoiding events that are OBE (1 of 2)
Cost can be saved by not dwelling on work that has been overcome by events (OBE)
There are two main sets of management objects in developing a product• 1. Management objects• 2. Objects involving design, lower product
requirements and interfaces, test specs, and test procedures
1. Optimization of product development
22
Avoiding events that are OBE (2 of 2)
Objects that are in one of these two main sets are easier to maintain
Objects not in one of these two sets are ignored and become obsolete
Examples are• Plans• Studies• Justifications• Traces
1. Optimization of product development
23
Avoiding over-run (1 of 2)
Productivity can be improved by ensuring that the product engineering staff doesn’t get over-run by development of lower products
Lower products depend upon receiving requirements from a higher product
1. Optimization of product development
24
Avoiding over-run (2 of 2)
If the higher product don’t provide the requirements needed by the lower product, then the lower products will pass the higher product and ignore its direction.
A priority of product engineering is to provide product design that results in specifying the requirements for the lower product.
1. Optimization of product development
25
2. Heuristics
DefinitionsExamples
2. Heuristics
26
Definition
Heuristic definition• Rules of thumb
Rule of thumb definition• A rule based on practical experience
without reference to scientific principals• May have widespread validity, but may
not always be true
2. Heuristics
27
Examples (1 of 3)
Example 1 -- People• Good people are number one priority• Better to have good people and bad process
than good process and bad peopleExample 2 -- Planning
• Plan the work and work the plan• Develop requirements as if they were going to
be implemented by another company• Don’t confuse requirements and design
2. Heuristics
28
Examples (2 of 3)
Example 3 -- Hierarchy • Don’t confuse requirements and levels of
hierarchy• RAA for a product should rest with only one
IPTExample 4 -- Order of tasks
• Parallel is good; serial is badExample 5 -- Partitioning
• Maximize cohesion and minimize coupling
2. Heuristics
29
Heuristics (3 of 3)
Example 6 -- Control• Push control to the lowest level
Example 7 -- Optimization• Work first; optimize last• Simplify
2. Heuristics
30
3. Application notes
Simple products Incremental builds Spiral development Prototypes Enterprise boundary Less-than-optimum design Less-than-optimum team Common component Algorithms Reduction of hierarchy State of mind
3. Application notes
31
Simple Products
Some developments don’t require all seven activities• Study• Concept• Purchased product• Service
3. Application notes
32
Incremental builds
Incremental builds allow parallel design and build
build 1
build 2
build 3
single product multiple products
3. Application notes
33
Spiral development (1 of 2)
function form
buildcertify
final form
intermediate form 2
intermediate form 1
34
Spiral development (2 of 2)
Another form of Incremental builds that allow parallel design and build
3. Application notes
35
Prototypes
Prototypes are a separate set of PBDsDocumentation may be less rigorous
product
prototype
3. Application notes
36
Enterprise boundary
cattle locating device
cattle camera cattle imager and display
cameraimage
processing hardware
displaydisplay
computer
display software
company 1
company 3company 2
Splitting aproduct on an
enterpriseboundary maybe a problem
37
Less-than-optimum design (1 of 2)
cattle locating device
cattle imager cattle display
cameraimage
processing hardware
display display computer
display software
system IPT
Subsystem 6 IPT
3. Application notes
Overcome bynegotiation
ormapping
38
Less-than-optimum team (2 of 2)
cattle locating device
cattle camera cattle imager and display
cameraimage
processing hardware
display display computer
display software
system IPT
subsystem 6 IPTsubsystem 5 IPT
Overcome bynegotiation
ormapping
39
Common component
Common components can be treated as shared products
system
unit unit
common CSCI
3. Application notes
40
Algorithms
Algorithms can be treated as another product
system
algorithms unit
CSCI
3. Application notes
41
Reduction of hierarchy
cattle locating device
cameraimage
processing hardware
control computer
control software
display display computer
display software
find and display cattle
make image
extract cattle
locations
control hardware
display cattle
control display
Reducing hierarchy reduces number of products
3. Application notes
42
State of mind
The application of the PBDA approach is a state of mind.
It’s the ability to reduce clutter by treating a product as a set of products and then being able to apply the PBDA activities to each product.
3. Application notes
43
4. Questions to identify risks
PeopleFeasibility risksCompany and management supportControlDecision makingManufacturing riskUnderstanding customersCustomer and contractor togetherCommunicationsDefinition of complete
4. Questions to identify risks
44
People
Question:: How is the program staffed?Desirable answer
• People who take ownership• People skilled in relevant technology and
management• People who can work in teams• People who aren’t parochial• People who have big-picture perspective• Method for moving people on, off, and around the
program
4. Questions to identify risks
45
Feasibility risks
Question : How close to limits are science and engineering; e.g. state-of-the-art performance, throughput, memory, weight, power, cooling, testability, reconfigurability, and manufacturability?
Desirable answer• We’ve done this before• We’re not pushing laws of physics• We’re not pushing limits• Risk is managed
4. Questions to identify risks
46
Company and management support
Question: Do the company and management support the program?
Desirable answer• People and resources are available• There are company visibility and people
rewards
4. Questions to identify risks
47
Control
Question: How is the program controlled to be successful?
Desirable answer• Limited number of effective metrics that
include cost, schedule, risk, and performance• Frequent error detection and correction• Deviations corrected as opposed to only
observed• Future work anticipated and provided for
4. Questions to identify risks
48
Decision making
Question: How does the program make and enforce decisions?
Desirable answer• Means for understanding options• Means for getting consensus• Means for propagating and enforcing
decisions
4. Questions to identify risks
49
Manufacturing risk
Question: Are all the components proven and readily available off-the shelf?
Desirable answer• Everything is COTS• We’re not developing hardware or software• We’re not having someone else develop
hardware and software
4. Questions to identify risks
50
Understanding customers
Question: Who are the customers and users, and what do they expect?
Desirable answer• Customers and users identified• Expectations understood and agreed to
with the customers
4. Questions to identify risks
51
Customer & contractor together
Question Do customer and contractor work together for program success?
Desirable answer• Customer and contractor on same team, and both feel
ownership for project success• Contractor and customer work together as opposed to
being in conflict• Customer and contractor support streamlining, and
work to move program forward• Customer and contractor solve problems together
4. Questions to identify risks
52
Communications
Question: How do all phases of the program work in parallel?
Desirable answer• Organizations that reflect the hierarchy• E-mail, intranet, libraries, and electronic
documents• Environment and tools to do the job• Teams that communicate and that have clear
responsibilities• Know customer, product, and team interfaces
4. Questions to identify risks
53
Definition of complete
Question: How do people and the program know when they’re done?
Desirable answer• Defined tasks with measurable completion
criteria
4. Questions to identify risks