Upload
alagan
View
61
Download
0
Embed Size (px)
DESCRIPTION
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. 1. Course details. Course and instructor Course content Textbook and time Schedule Grading Formats. - PowerPoint PPT Presentation
Citation preview
1. PBDA 1
Agenda for introduction1. Course details2. Disclaimer3. Reasons why systems fail4. Products5. Cycles, phases, and activities6. PBDA7. Management by WPs8. CMMI
1. PBDA 2
1. Course details
Course and instructorCourse contentTextbook and timeScheduleGradingFormats
1. Course details
1. PBDA 3
Course and instructorCourse -- 7310 Systems Engineering Design
Room -- 218 Caruth Hall
Instructor -- Jim Hinderer
Work phone number -- (972) 344 7410
Home phone number -- (972) 359 1557
E-mail address -- [email protected]
1. Course details
1. PBDA 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
1. PBDA 5
Textbook and time
Textbook -- noneClass time -- 7:15 - 9:15URL for class notes --
www.engr.smu.edu/sys/Hinderer/7310
1. Course details
1. PBDA 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
1. PBDA 7
Grading
Project -- 50%Final -- 50%
1. Course details
1. PBDA 8
FormatsNon-electronic: Pencil and paperElectronic: Office 97 Word, Excel, PowerPoint PC and not Macintosh
1. Course details
1. PBDA 9
2. DisclaimerDesign is more of an art than a science.Almost any approach to design will work if
someone takes ownership of successNo one approach is better than all the othersWe will use the approach used in the
Systems Engineering Process course
2. Disclaimer
1. PBDA 10
3. Reasons systems failafter
deliverybefore
delivery
lack of qualified people
unmanaged risks
wrong requirements
failure toexecute
other
didn’t meetrequirements
overlookedsomething
failed to impresscustomer
3. Reasons systems fail
1. PBDA 11
4. Products
Product definitionProducts composed of productsTypes of productsNeed for productsNeed for lower-level productsExamples
4. Products
1. PBDA 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
1. PBDA 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
1. PBDA 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
4. Products
1. PBDA 15
Types of products (1 of 2)
4. Products
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
4. Products
Delivered products
Support products
1. PBDA 16
Types of products (2 of 2)
4. Products
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
1. PBDA 17
Need for products
We need products to describe what we’re controlling
Products may be developed or procured without development
4. Products
1. PBDA 18
Need for lower-level productsWe need lower-level products if we’re
going to procure something needed for doing the development
4. Products
1. PBDA 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
Example 1 -- model airplane
Model airplane
Fuselage Wing Stabilizer Rudder Glue
4. Products
1. PBDA 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
Kitchen Bathroom Bedroom 1 Bedroom 2 Garage
Example 2 -- house, bad example
4. Products
1. PBDA 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
Example 3 -- house, good example
House
Plumbing Framing Roof ElectricalFoundation Dry wall
4. Products
1. PBDA 22
5. Cycles, phases, and activities
DefinitionsProduct life cyclePre-develop-phase activitiesDevelop-phase activitiesPost-develop-phase activitiesExampleClassical development
5. Cycles, phases, and activities
1. PBDA 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 tasksProcess -- steps used to accomplish an
activity
5. Cycles, phases, and activities
1. PBDA 24
Product life cycle
Phases
Time
Pre-develop
Post-develop
Develop
5. Cycles, phases, and activities
1. PBDA 25
Pre-develop-phase activities
Sub phasesor activities
Time
Meet the customer
Discuss the work
Respond to RFP
Sub phases overlap
Identify opportunity
5. Cycles, phases, and activities
1. PBDA 26
Develop-phase activitiesSub-phasesor activities
Time
Understand requirements
Design
Acquire products
Build
Verify
Sell off
Sub-phases overlap
Manage
5. Cycles, phases, and activities
1. PBDA 27
Post-develop-phase activitiesSub-phases
Time
Train
Produce
Upgrade
Maintain
Operate
Dispose
Sub-phases overlapField test and validate
Support
5. Cycles, phases, and activities
1. PBDA 28
Example -- build a houseActivities
Time
Learn what buyer wants
Have architect make blueprint
Get land and lumber
Build
See if the house is OK
Close
Supervise
5. Cycles, phases, and activities
1. PBDA 29
Classical development
Concept &technology
development
Systemdevelopment &demonstration
Productionand
deployment
Operationsand
support
A B C IOC FOC
Technology opportunities and user needs
Pre-system acquisition
System acquisition(EMD LRIP and production)
Sustainment
MNS ORD
Requirements process
1. PBDA 30
6. PBDAApproachPBDA block diagramApplication of PBDA to productsExampleWork products (WPs)
6. PBDA
1. PBDA 31
The approachDetermine 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
6. PBDA
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
1. PBDA 32
PBDA block diagram
1. Manage
2. Understand req
3. Design
4. Acquire
5. Build6. Verify
7. Sell off
External: higher product teams
External: lower product teams
contracts,specs,interfaces
specs, I/Fscontracts
lower specs & I/Fs
design
lowercontracts,specs,interfaces
status
lower product,test results,
test spec agree
lower test results
lower products
build proc
product
test proc
test resultstest spec
peoplefacilities, tools, capital,
communications, library
schedule, budget,risks, TPPs,
issues, AIs, problemsplans, timeline, changes, legal
control,status
agree
status
MR
RR
CR PDR CDR
TRR VR
FCA PCA
1. PBDA 33
Application of PBDA to products
Productof interest
Lowerproduct N
Higherproduct
Lowerproduct 1
Lowerproduct 2
PBDA is applied to each product separately
6. PBDA
1. PBDA 34
Example with 10 productsExample with 10 products
System
Subsystem Subsystem
HWCI HWCI Unit
CSCI
HWCI Unit
CSCI
Example (1 of 2)
6. PBDA
1. PBDA 35
Developing the example with 10 instantiations of PBDADeveloping the example with 10 instantiations of PBDA
1
2 3
6 7 8
9 10
5
Example (2 of 2)
6. PBDA
1. PBDA 36
6. Management by WPsDefinitionDelivered productsWPs for managementWPs other activitiesInput WPsOptimizing WPsPareto of WPs by likely useMeasuring usefulness of WPs
7. Management by WPs
1. PBDA 37
Definition
A work product (WP) is a tangible object that is used to control the PBDA Documents Elements of environment to support
engineeringMuch of the execution of the PBDA can be
thought of as completing the associated WPs
PBDA executed by completing WPsPBDA executed by completing WPs
7. Management by WPs
1. PBDA 38
Delivered productsDelivered products (2) -- product and
lower productsThe goal of PDBA is to transform lower
products into the productLower products may be
Delivered products Support products Services
Work products aid in the transformation
PBDA transforms lower products into higher productPBDA transforms lower products into higher product
7. Management by WPs
1. PBDA 39
WPs for managementEnvironment (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. 26 WPs support products used for managing each product in PBDA.
7. Management by WPs
1. PBDA 40
WPs for other activities
Understand (0) -- Design (3) -- design, lower specs, lower
interfaces Acquire (1) -- lower contractsBuild (1) -- build procedureVerify (3) -- test spec, test procedure, test
resultsSell off (1) -- agreement
9 WPs used for developing each product in PBDA. 9 WPs used for developing each product in PBDA.
7. Management by WPs
1. PBDA 41
Inputs WPsHigher inputs (3) -- contracts, specs, interfacesLower inputs (3) -- lower test results, lower test
spec, statusLower product (1) -- output from lower level
Inputs are monitored but don’t belong to the product of interest
Inputs are monitored but don’t belong to the product of interest
7. Management by WPs
1. PBDA 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 usedNot all WPs must always be used
7. Management by WPs
1. PBDA 43
Pareto of products by likely use
7. Management by WPs
An example pareto of support products by likely useAn example pareto of support products by likely use
decreasing likelihood of use
product (1)
lower products (1)
higher inputs (3)
budget & schedule (2)
environment (6)
design (3)
build proc (1)
problems and changes (2)
risks & TPPs (2)
verify (3)
plan and timeline (2)
lower inputs (3)
reviews and audits (9)
agreement (1)
lower contract (1)
issues and AIs (2)
legal (1)
1. PBDA 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 Value of an WP can be positive or negative
7. Management by WPs
1. PBDA 45
8. CMMIDefinitionObjectivesMaturity levelsProcess areasGoals and practicesGeneric goals and practicesSpecific goals and practicesContinuous vs staged modelsEvaluating adherence
8. CMMI
1. PBDA 46
DefinitionA 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
1. PBDA 47
Objectives (1 of 2)Improve performance, cost, and scheduleImprove collaboration among stakeholdersProvide competitive world-class products and
servicesProvide common business and engineering
perspectiveHandle systems-of-systemsUse common processes for systems and
softwareEnsure management support
8. CMMI
1. PBDA 48
Objectives (2 of 2)Encourage looking ahead rather than behindDevelop staff that uses best practicesAllow moving staff among projects without
changing processesImprove processes
8. CMMI
1. PBDA 49
Maturity levels
1. InitialProcess unpredictable, poorly controlled, and reactive
2. ManagedProcess characterized for projects and is often reactive
3. DefinedProcess characterized for the organization
4. Quantitatively managedProcess measured & statistically controlled
5. OptimizingEmphasis on continuing improvement
8. CMMI
1. PBDA 50
Process areas (1 of 6)
Focus: noneFocus: none
1. INITIAL (0)
8. CMMI
1. PBDA 51
Process areas (2 of 6)
Focus: basic project managementFocus: basic project management
2. MANAGED (7)requirements management
project planningproject monitoring and control
supplier agreement management
measurement and analysisprocess and product quality assurance
configuration management
8. CMMI
1. PBDA 52
Process areas (3 of 6)
Focus: process standardizationFocus: process standardization
3. DEFINED (11)requirements development
technical solutionproduct integration
verificationvalidation
8. CMMI
1. PBDA 53
Process areas (4 of 6)
Focus: process standardizationFocus: process standardization
3. DEFINED (CONTINUED)organization process focus
organizational process definitionorganizational training
integrated product managementrisk management
decision and analysis resolution
8. CMMI
1. PBDA 54
Process areas (5 of 6)
Focus: quantitative managementFocus: quantitative management
4. QUANTITATIVELY MANAGED (2)organizational process performance
quantitative project management
8. CMMI
1. PBDA 55
Process areas (6 of 6)
Focus: continuous process improvementFocus: continuous process improvement
5. OPTIMIZING (2)organizational innovation and deployment
causal analysis and resolution
8. CMMI
1. PBDA 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
1. PBDA 57
Generic goals and practices (1 of 2)GG 1: NoneGG 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
1. PBDA 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
managementGG 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 3GG 5: Same as GG 4
8. CMMI
1. PBDA 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 controlExample for project monitoring and control8. CMMI
1. PBDA 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 controlExample for project monitoring and control8. CMMI
1. PBDA 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 controlExample for project monitoring and control8. CMMI
1. PBDA 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
1. PBDA 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
1. PBDA 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