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


3

Adapting the process

Adapt process by• Using PBD activities as template • Adapting PBD activities to the

program


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


5

Performing an activity once (2 of 2)

Work the following only once at the enterprise level• People• Facilities• Capital• Tools


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


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


8

Rolling up information

Maintain the following at the product level but roll results to top• Schedule • Budget• TPPs


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


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


11


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


12


Avoiding change of focus • Allowing people to focus on one area at a

time improves productivity• People resist frequent changes of focus


13


Example 1 -- Writing

• Focuses -- Content, grammar, and spelling

• Desirable -- Check each once per document

• Undesirable -- Check each once per sentence


14


Example 2 -- Requirements Management• Focuses -- Content, VM, and tracing • Desirable -- Check each once per

document• Undesirable -- Check each once per

requirement


15


Example 3 -- Documentation of Studies• Focuses -- Content and documentation • Desirable -- Check each once per study• Undesirable -- Check each once per update


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


17

Avoiding low-value concepts (1 of 4)

Avoiding error paths in processesAvoiding iteration in processesAvoiding studies without objectives

Editorial


18


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


19


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


20


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


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


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


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


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.


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


31

Simple Products

Some developments don’t require all seven activities• Study• Concept• Purchased product• Service


32

Incremental builds

Incremental builds allow parallel design and build

build 1

build 2

build 3

single product multiple products


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


35

Prototypes

Prototypes are a separate set of PBDsDocumentation may be less rigorous

product

prototype


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 imager cattle display

cameraimage

processing hardware

display display computer

display software

system IPT

Subsystem 6 IPT


Overcome bynegotiation

ormapping

38

Less-than-optimum team (2 of 2)


cattle camera cattle imager and display

cameraimage

processing hardware


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


40

Algorithms

Algorithms can be treated as another product

system

algorithms unit

CSCI


41

Reduction of hierarchy


cameraimage

processing hardware

control computer

control software


display software

find and display cattle

make image

extract cattle

locations

control hardware

display cattle

control display

Reducing hierarchy reduces number of products


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.


43

4. Questions to identify risks

PeopleFeasibility risksCompany and management supportControlDecision makingManufacturing riskUnderstanding customersCustomer and contractor togetherCommunicationsDefinition of complete


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


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


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


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


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


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


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


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


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


53

Definition of complete

Question: How do people and the program know when they’re done?

Desirable answer• Defined tasks with measurable completion

criteria


1 agenda for implementation of pbda r1. optimization of product development r2. heuristics r3....

Documents