1 Agenda for PBDA r1. Basic approach r2. Products r3. Cycles r4. Product-based development approach (PBDA)

2 1. Basic approach rThe approach rExecution of the approach rEmphasis on executing the approach rApplication of the approach rReason for the approach rDisclaimer for the approach rGoal 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 rExecution 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 rEmphasis 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 rApply same set of activities to each product in the system rThis approach deals with development of products from conception to sell-off 1. Basic approach

7 Reason for the approach (1 of 2) rThe 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 rHaving a disciplined approach to developing products makes cost, schedule, and quality predictable rHaving 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 to execute other didn’t meet requirements overlooked something failed failed to impress customer 1. Basic approach

9 Disclaimer for the approach rSystem engineering is more of an art than a science. rAlmost any approach to system engineering will work if someone takes ownership of success rNo one approach is better than all the others rThe reasons for applying any system engineering approach are the same as for the PBDA 1. Basic approach

10 Goal of this course rThe 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 rProduct definition rProducts composed of products rTypes of products rNeed for products rNeed for lower-level products rExamples 2. Products

12 Product definition (1 of 2) rA product is something produced rA product is something we can procure -- hardware, software, data, services. 2. Products

13 Product definition (2 of 2) rExamples Hardware -- space shuttle, house, circuit card, resistor Software -- program, firmware Data -- documents, work products Services -- activities rThe 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 r Delivered products -- part of the delivered product r Support products -- other products in support of delivered product r Either type of product may be Hardware Software Data Service Types of products (2 of 2) 2. Products

17 Need for products rWe need products to describe what we’re controlling rProducts may be developed or procured without development 2. Products

18 Need for lower-level products rWe 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-level products to make the higher-level product Good example -- we can use the lower-level products to make the higher-level product Examples (1 of 4) model airplane fuselagewingstabilizerrudderglue 2. Products Example 1 -- model airplane

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 kitchenbathroombedroom 1bedroom 2garage Examples (2 of 4) 2. Products Example 2 -- house as a bad example

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 Examples (3 of 4) house plumbingfoundationframingroofelectricaldry wall 2. Products Example 3 -- house as a good example

22 Examples (4 of 4) radar sensorcomputer stafffacilitiestoolscapitalcommunicationslibrary system integration lab delivered products Development of a product includes both delivered and support products. Development of a product includes both delivered and support products. Example 4 -- support products 2. Products

23 3. Cycles rProduct life cycle rPre-develop-phase activities rDevelop-phase activities rPost-develop-phase activities rNew government life cycle rLife 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

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 enterprise into business and prepare for development phase Overlapping sub-phases or activities get enterprise into 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 more familiar names Activities in develop phase are the same as in basic approach but with more familiar names 3. Cycles

27 Develop-phase with names of basic approach Develop-phase with names 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) rNot 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 activities of post development complete the life cycle Overlapping activities of 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 system development & demonstration production and deployment operations and support ABC IOC FOC Technology opportunities and user-needs entry points pre-system acquisition system acquisition (EMD LRIP and production) sustainment MNS ORD requirements process New 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 product having its own life cycle Product line has a life cycle with each product having its own life cycle life cycle of product N 3. Cycles

33 4. PBDA rPBDA block diagram rApplication of PBDA rValue of PBDA rWork products (WPs) rMajor work products rProcess WPs rTemporary WPs rDivisions of WPs rOptimizing 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 product agreement sub test results sub products schedule budget risks actions configurations reviews test results product test results agreement checkliststeps 4. PBDA

35 PBDA block diagram (2 of 2) rThe 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) product of interest lower product 1 lower product 2 lower product N higher Product PBDA is applied to each product separately 4. PBDA

37 Application of PBDA (2 of 4) rSub 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 rThe 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 products System Subsystem HWCI Unit CSCI HWCI CSCI Application of PBDA (3 of 4) 4. PBDA Example with 10 products

39 Developing the example with 10 instantiations of PBDA Application of PBDA (4 of 4) 4. PBDA Example with 10 products (continued)

40 Value of PBDA (1 of 3) rMakes explaining system engineering easier rHandles systems at all levels Not just top-level rHandles systems of all sizes Not just top-level rHandles systems from start-to finish Not just through development rHandles work products as systems 4. PBDA

41 Value of PBDA (2 of 3) rHandles all developers Not just government rHandles teaming Not just one-company rHandles other disciplines Other disciplines fit in as developers of products using PBDA rReduces 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 WPs 4. PBDA design sub wants budget risks actions configuration problems reviews product build steps verify steps test results agreement checklist 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 production plan improvement plan maintenance plan support plan operation plan build plan verification plan disposal plan metrics minutes process improvements design sub wants budget risks actions configuration problems reviews product build steps verify steps test results agreement checklist design sub wants budget risks actions configuration problems reviews product build 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) rA work product (WP) is a document that is used to control the PBDA rMuch of the execution of the PBDA can be thought of as creating and using the associated WPs rMajor work products are used for most of the product development rMinor work products are used for the remainder of the development PBDA executed by creating and using WPs 4. PBDA

44 Major work products (1 of 4) designwants sub wants sub product sub test result sub agreement schedule budget risks actions configuration problems reviews product build stepsverify 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 wants sub product sub test result sub agreement schedule budget risks actions configuration problems reviews product build stepsverify steps test results agreement product (not a WP) product (not a WP) There are 14 major WPs in development because a product is not a document There are 14 major WPs in development because a product is not a document checklist 4. PBDA

46 Major work products (3 of 4) designwants sub wants sub product sub test result sub agreement schedule budget risks actions configuration problems reviews product build stepsverify steps test results agreement customer team sub team contractor team The contractor team has RAA for the red WPs whereas other teams have RAA for the remaining WPs The contractor team has RAA for the red WPs whereas other 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 wants sub product sub test result sub agreement schedule budget risks actions configuration problems reviews product build stepsverify steps test results agreement WD D W D D customer checklist 4. PBDA

48 Process WPs metrics Providing processes adds more WPs minutes process improvements processes 4. PBDA

49 design Temporary WPs Many 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 wantssub wants test results Many 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) schedulerisks actions configuration problems 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 used 4. 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 requirementssize hostility Don’t use WP Use WP Size, complexity, requirements, and level of hostility determine when to use a WP Size, complexity, requirements, and level of hostility determine 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 level enterprise 4. PBDA

56 Optimizing WPs (4 of 4) risks project Some WPs are maintained only at project level 4. PBDA