SE&I Overview - Center for Software Engineering

advertisement
Towards a
Work Breakdown Structure
for
Net Centric System of Systems
Engineering and Management
20th International Forum on COCOCMO
Workshop
October 2005
Gan Wang gan.wang@baesystems.com Jo Ann Lane jolane@usc.edu
Ricardo Valerdi rvalerdi@mit.edu
Barry Boehm boehm@cse.usc.edu
CS-1
1
3/14/2016
Outline
 Background, motivation, goals and scope
− Relevant needs and trends in SoS system engineering and management
− Development objectives
 Basic foundations for the SoS WBS
− Product-oriented structure
− Scalable Spiral Model
− Three-team construct
 Net centric System of Systems (SoS) Program Work Breakdown
Structure (WBS)
 Implications and anticipated benefits
 Conclusions
2
3/14/2016
Background
 Systems engineering needs and trends
− Increasing focus on capability-based acquisition
− Increasing focus on user/value
− Increasing complex systems of systems
• Disproportional increase in complexity and interdependency
• Disproportional increase in needs for interoperability
− Increasing COTS, Open Source, reuse, and legacy integration
 New challenges in systems engineering and program management
− Evolutionary, rather than revolutionary
− Capability, rather than functionality
− Lifecycle perspective, rather than acquisition focused
− Heterogeneous, rather than homogeneous
− Negotiation, rather than mandate
3
3/14/2016
Motivation for Net Centric SoS WBS
 A step into continuing understanding of net centric SoS systems
engineering and management
− What is common, what is different?
− New scopes and emphases
• Beyond traditional systems engineering considerations
• Emerging behaviors and risk from evolutional process
− What is/belongs, what is/does not?
− What works, what does not?
 Time to step back and rethink
− Systematic
− Holistic
− Mission and capability focused
New Perspective Required for Net Centric SoS/FoS
4
3/14/2016
Motivation (cont.)
 No standard or commonly-accepted WBS above system level
− Traditional program/project management focuses on system and
performance
• Build-to-spec, requirement-driven, waterfall-ish
− Existing WBS constructs are system development focused – difficult to
scale upward
• Development/acquisition centric, little attention to O&M
• Interpretabilities and independencies disregarded
• Enterprise context absent
 Tool needed for integrated systems engineering and program
management in net centric SoS programs
− Facilitates the unification of SoS SE and PM
− Emerging systems engineering method: Capability Planning
 Basis for cost estimating
5
3/14/2016
Net Centric SoS WBS Goals
 Provide
− Standardized, yet flexible, prototypical WBS for net centric SoS engineering
and management programs – a standard template to develop programspecific WBS
− Reference model for SoS program management, systems engineering and
cost estimating
− Full SoS life cycle “cradle-to-grave” perspective and support
− Systematic and holistic approach
− Basic analysis framework for decision making
− Clear, consistent and commonly accepted terminology definition
− Tailorable and adaptable model
6
3/14/2016
Goals (cont.)
 Integrate community-accepted best practices
− General systems engineering and program management lifecycle
− System-level WBS
− Program and practice examples
− Existing international standards
•
•
•
•
ISO/IEC 15288: Systems Engineering – System Life Cycle Processes
DoD 5000.2: Operation of the Defense Acquisition System
ANSI/EIA 632 Processes for Engineering a System
MIL-HDBK-881: Work Breakdown Structure
 Leverage leading development in net centric SoS systems engineering
and processes, e.g.,
− Spiral development model
− Capability-based acquisition
− Capability planning and investment analysis practices
7
3/14/2016
Net Centric SoS WBS Scope
 Target SoS/FoS type programs
− With the charter to evolve mission capabilities of a SoS/FoS
− Prototypical program lifecycle perspective
 Consider
−
−
−
−
Program management and the supporting enterprise functions
Systems engineering and integration products
Development and O&M environments
Governance model
 Capture three basic components of the SoS engineering and management practices
− Systems
•
•
Components and relationships
Infrastructure
− Processes
•
•
•
•
Program management
Systems engineering & integration
Technology development
Operations and support
− People
•
•
•
Management and acquisition authorities
Teams
Stakeholder community
8
3/14/2016
Outline
 Background, motivation, goals and scope
− Relevant needs and trends in SoS system engineering and management
− Development objectives
 Basic foundations for the SoS WBS
− Product-oriented structure
− Scalable Spiral Model
− Three-team construct
 Net centric System of Systems (SoS) Program Work Breakdown
Structure (WBS) – Top-level View
 Anticipated benefits and conclusions
9
3/14/2016
Basic Foundations of SoS WBS
 Product-oriented Work Breakdown Structure
− “Product”: physical entity, organization, function/service
− Processes and activities associated with products
 Scalable Spiral Process Model
− Risk-driven OODA loops
 Three-team execution model
− Plan-driven team
− IV&V team
− Agile Rebaselining Team
10
3/14/2016
Emerging Scalable Spiral Process
Observe new/updated objectives,
Orient with respect to stakeholders
• Usage monitoring
• Risk/Opportunity analysis
• Competition, technology,
marketplace ISR
• Business case/mission analysis
constraints, alternatives
priorities, feasibility, risks
• Prototypes, models, simulations
Operate as current system
Accept new system
Act on plans, specifications
• Keep development stabilized
• Change impact analysis,
preparation for next cycle (miniOODA loop)
Decide on next-cycle capabilities,
architecture upgrades, plans
• Stable specifications, COTS
upgrades
• Development, integration, V&V, risk
management plans
• Feasibility rationale
Life Cycle Architecture Milestone for Cycle
Source: USC-CSE
11
3/14/2016
Three-Team Execution Model
• Emerging technologies
• New threats
• Operational environment changes
…
1.
Plan-Driven Team
2.
IV&V Team
3.
Agile Rebaselining Team
Environmen
t Change
Factors
Agile Team
Spiral Charlie
Requirements
KPPs
Architecture Baseline
• Requirement creeps
• Emerging applications
• Unforeseen complexities
…
Agile Team
Internal
Change
Factors
Plan-Driven Team
Spiral Bravo
Requirements
KPPs
Architecture Baseline
IV&V Team
Spiral Alpha
Requirements
KPPs
Architecture Baseline
SoS Evolutionary Spirals
Time
12
3/14/2016
Outline
 Background, motivation and goals
− Relevant needs and trends in SoS system engineering and management
− Development objectives
 Basic foundations for the SoS WBS
− Product-oriented structure
− Scalable Spiral Model
− Three-team construct
 Net centric System of Systems (SoS) Program Work Breakdown
Structure (WBS)
 Implications and anticipated benefits
 Conclusions
13
3/14/2016
SoS Program WBS
Level 1
Level 0
The SoS
Program
The SoS in
Operation
Spiral Alpha
Spiral Bravo
Spiral Charlie
Program
Office
Development
IV&V
Team
PlanDriven
Team
Agile
Team
14
3/14/2016
The SoS Program WBS (cont.)
 The SoS in Operation: consists of legacy systems, current operational
organizations, “as-is” doctrine and CONOPS
− Important in understanding the baseline “as-is” architecture and business
case analysis
 Spiral Alpha: current development increment executed by the PlanDriven Team, with relative stable capability objectives, requirements,
architecture baseline, and clear deliverables
 Spiral Bravo: next development increment in planning by the Agile
Rebaselining Team; new baseline based on near- to mid-term
capabilities needs, priorities and new technologies in test labs
 Spiral Charlie: future development increment in planning by the Agile
Rebaselining Team; new baseline based on future capability needs,
priorities and emerging technologies
 Program Office: the supporting enterprise with a mission and resources
to accomplish the mission
− Three teams under it
− Enterprise-level/(DoD) DOTMLPF support
15
3/14/2016
The SoS in Operation – the Legacy
Level 2
Level 1
The SoS in
Operation
Operational
Plans
Member
Systems
Operational
Organizations
Level 3
Operational Doctrine
Operational Architecture
Operational Processes
Resources and Budgets
Subplans
Organization 1
Organization 2
…
Organization k
Peer
Systems
Operational
Maintenance &
Support
Operational
Facilities
Communications
Infrastructure
Peer System 1
Peer System 2
…
Peer System p
System 1
System 2
…
System n
Data Centers
Networks
Processes &
Procedures
Support Centers
Support Organizations
Training Services
Logistics Depots
Maintenance Services
Site 1
Site 2
…
Site m
16
3/14/2016
The SoS in Operation – Dealing With Legacy
 Operations & Maintenance (O&M) centric
 Coping with “as-is” architecture, capability and interoperability
−
−
−
−
−




Inconsistent doctrine, processes
Different CONOPS
Partial interoperability
Ad hoc communications protocols
Gaps and overlaps in functionality
Adapt to emerging behaviors (trial and error, “learning the rope”)
Typically managed by different program offices or service organizations
Source for new capability needs and acquisition requirements
Baseline for business case analysis, e.g., ROI
17
3/14/2016
Spiral Alpha – Current Development Increment
Plan-Driven
Team
Phase/Spiral
Plan
Level 3
Level 2
Level 1
Spiral Alpha
Operational
Requirements
Requirements by
Type
Mission Objectives &
Constraints
Proposal
The WBS
Resource & Budgets
Estimates
Integrated Master
Plan & Schedule
Subplans
The SoS Version Alpha
The Capability
Model
Performance, Cost,
and Schedule
Objectives &
Thresholds
Lifecycle
Support
Systems
Member
Systems
Communications
Infrastructure
Peer
Systems
System 1
Peer System 1
…
…
System n
Peer System p
Retired System n+1
…
Retired System n+k
Operational
Architecture Baseline
Functional Allocation &
Synthesis Products
Key Performance
Parameters
The Validated
SoS
The Integrated
and Verified SoS
The Deployed
SoS
Requirements, Plan &
Processes
Operational Plans &
Processes
Integration, Assembly,
Test & Checkout
Systems
Systems
Integration Labs &
Test Facilities
Personnel
System 1
…
System s
Operational
Organizations
Operational Facilities
Systems to be
Integrated
CONOPS
M&S & Analysis
Models
IV&V
Team
Training Functions
Requirements, Plan
& Processes
Existing
Infrastructure
Operational Test &
Evaluation Systems
Added
Infrastructure
Integration Labs &
Test Facilities
Validation Data
Personnel
18
3/14/2016
Spiral Alpha (cont.)
 Responsible by the Plan-Driven Team; verified and validated by the IV&V
Team
 Relative stable requirements and delivery goals
 Development/acquisition objective: operational capability
 Development methodology predominantly focused on function allocation
and synthesis (integration)
− Rather than performance-driven at the system level




Increasing emphasis on COTS systems integration
More waterfall like development model
Post-Milestone A/pre-MS B (DoD 5000) entry typically
The delivery becomes the new “as-is” SoS in Operation
19
3/14/2016
Single System
Level 4
Level 3
The System
The System
Plan
The System
Design
System
Requirements
The Subsystems
…Subsystems i
The Operational
System
The Validated
System
…Subsystems n
Level 5
Subsystems 1
The Integrated
and Verified
System
Maintenance &
Support
Systems
Operational Personnel
(dedicated)
Operational Facility
(dedicated)
Manuals & Procedures
Operational Data
• Modified version of Ruskin’s model
• Lifecycle orientation and O&M
extensions
• Prototypical system WBS for any of
the systems in the SoS
Support Systems
Training Function
Support Personnel
(dedicated)
Support Facility
(dedicated)
Maintenance & Spares
20
3/14/2016
Level 3
Level 2
Level 1
Spirals Bravo and Charlie
Spiral Bravo (Charlie)
Agile Team
The SoS Version Bravo
(Charlie) Baseline
Phase/Spiral
Plan
Operational
Requirements
Mission Objectives and
Constraints
The WBS
Resource & Budgets
Estimates
Subplans
Prioritized Performance,
Cost, and Schedule
Objectives
Prioritized Requirements by
Type
The Capability
Model
CONOPS
Operational Architecture
Baseline
Functional Allocation &
Synthesis Products
Key Performance
Parameters
M&S & Analysis Models
21
3/14/2016
Spirals Bravo and Charlie (cont.)
 Principal deliverables are capability and architecture models
 Principal responsibility of the Agile Team
− Working independently from the Plan-Driven Team
− May take on the overall SE&I role for the program
 Lifecycle perspective for evolution
 Focused on prioritization of future capability increments
 Primary repository of future/postponed capability needs and
requirements for acquisition
 Primary drivers for future capability needs:
−
−
−
−
−
Changing user needs
Changing environment or threats
Emerging technologies
Budget and resource constraints
Lessons Learned
 Pre-concept phase or pre-Milestone A activities typically
 Basis for future Spiral Alpha WBS
22
3/14/2016
Level 4
Level 3
Level 2
Level 1
Program Office – The Supporting Enterprise
The Program
Office
The Program
Mission
Mission Statement
Lifecycle
Objectives
Doctrine & Policies
Capability
Models
Integrated Master Plan
Integrated Master Schedule
Business Case Documents
Sub-plans
The WBS
Capability Needs
Documents
Lifecycle Architecture
Products
Joint Capabilities
Documents (JCDs)
Initial Capabilities
Documents (ICDs)
Integrated
Architecture Products
Capability Roadmap
Capability
Development
Documents (CDDs)
Capability
Production
Documents (CPDs)
Suboffices
The Program
Plan
Budget & Accounting
Functions
Legal & Contract Functions
Acquisition & Supply
Functions
Systems Engineering &
Integration Functions
Stakeholder
Group
PM
End Users
Systems Integrator
PARM/OEM/System
Suppliers
Labs
Peer Program Offices
Operations Offices
HR Function
IT Support Function
Administrative Support
Functions
23
3/14/2016
Program Office (cont.)
 The supporting enterprise ensuring successful evaluation of the SoS
capabilities based on mission
− Provides Organizational or (DoD) MOTMLPF supports to projects
− Provides infrastructure (e.g., IT) support
 Lifecycle evolutionary perspective
 Planning, managing, doctrine and oversight roles
− Manages the three teams – Plan-Driven, IV&V and Agile
 PM role in the stakeholder group includes a stakeholder liaison function
− Emerging and important function for SoS/FoS programs
 Reports to acquisition/service branch
− To (commercial) general manager
 System Integrator is a role, not an entity
− It has four potential job descriptions simultaneously:
• On the three teams
• The systems engineering & integration/capability planning at the program level
24
3/14/2016
Outline
 Background, motivation and goals
− Relevant needs and trends in SoS system engineering and management
− Development objectives
 Basic foundations for the SoS WBS
− Product-oriented structure
− Scalable Spiral Model
− Three-team construct
 Net centric System of Systems (SoS) Program Work Breakdown
Structure (WBS)
 Implications and anticipated benefits
 Conclusions
25
3/14/2016
Implications of Scalable Spiral Model
 Evolution-oriented and capability-focused
 Risk-driven and mission assurance
 Good transition for the culture and legacy program management
− Good talent pool for Plan-Driven Team
 Less material-oriented deliverables from early spiral(s)
− Architecture baseline more a focus
 Different operational philosophy and management skill set
− Build-to-spec will not work
− “Best value” objectives
− Cost, risk and schedule as independent variables
 Requires forward-looking vision and a new breed of PMs
26
3/14/2016
Implications of Standardized SoS-Level WBS
 Two prevalent structures:
− Product-oriented
− Activity-based
 Integration with process-oriented and activity-based structures
− Start with one structure at the top and integrate elements of the other at
lower levels
 Need to provide clear and consistent definition of terms
− Or potential risks of double-counting
− Need for glossary and data dictionary
 Possible different organizations for different purposes
− Different development models
 Less clear boundary for scope and division of responsibility
− Are the day-to-day operational activities (and personnel) “sunk cost”?
− Whose responsibility is it to establish doctrine, program office or larger
enterprise?
 Implications to cost estimating
 Linkage to other architecture products
27
3/14/2016
Anticipated Benefits




Provides a reference model for SoS/FoS engineering and management
Defines a common set of terminology related to SoSs
Enables visibility and insights into unique issues related to SoSs
Provides a holistic view for SoS engineering and program management,
particularly in terms of
− Interoperability
− Complexity and interdependency
− Ownership and governance model
− Conflict management
− Decision framework
 Facilitates further understanding of the
− Effort and cost in acquiring and owning an SoS
− Methodology that can be applied to estimate this cost
 Promotes the unification of systems engineering and project
management for SoS
− Linkage between architecting/engineering activities to the economic effect
28
3/14/2016
Outline
 Background, motivation and goals
− Relevant needs and trends in SoS system engineering and management
− Development objectives
 Basic foundations for the SoS WBS
− Product-oriented structure
− Scalable Spiral Model
− Three-team construct
 Net centric System of Systems (SoS) Program Work Breakdown
Structure (WBS)
 Implications and anticipated benefits
 Conclusions
29
3/14/2016
Conclusions To Date
 General systems engineering principles and project management
practices do apply to net centric SoS
 Traditional system-oriented WBS construct is inadequate, and there are
added ingredients in WBS for net centric SoS, from
− Added complexity
− Different scope, objectives and strategy
− Different environment
 Two different acquisition focuses:
− System: functionality
− System of systems: capability
 And, therefore, two different development strategies:
− System: waterfall
− System of systems: scalable spiral
 Not a complete WBS, but a step towards that direction
 A lot to learn, and more to explore…
30
3/14/2016
References
1)
2)
3)
4)
5)
6)
7)
8)
9)
10)
11)
12)
13)
14)
15)
B. Boehm, “The Future of Software and Systems Engineering Processes,” USC-CSE-TR-2005-507,
2005
Boehm, B. and Turner, R., Line Dancing with Elephants – the Systems Engineering of Network-centric
Complex systems of Systems (NCSOS), SSCI Member Forum, 2005
A. Ruskin, “Using 100% Product-Oriented Work Breakdown Structures to Unify System Engineering
and Project Management,” ICSE-INCOSE, 2004
A. Sage and C. Cuppan, “On the Systems Engineering and Management of Systems of Systems and
Federations of Systems,” Information.Knowledge.Systems Management, 2001
M. Jamshidi, “System-of-Systems Engineering – a Definition,” IEEE SMC 2005, Hawaii, October 2005
J. Lane and R. Valerdi, “Synthesizing System-of-Systems Concepts for Use in Cost Estimation,” IEEE
SMC, 2005
J. Lane, “COSOSIMO Workshop Minutes,” 2005
C. Dickerson and et al, Using Architectures for Research, Development and Acquisition, OASD-NII,
2004
P. Jain, and C. Dickerson, “Family-of-Systems Architecture Analysis Technologies,” INCOSE, 2005
D. Bracamonte, “An Adaptive Automated Model for formatting & Presenting Life Cycle Costs,” ISPP
Proceedings, 1993
ISO/IEC 15288, Systems Engineering – System Life Cycle Processes, 2002
DoD Instruction 5000.2, Operation of Defense Acquisition System, 2000
ANSI/EIA 632, Process for Engineering a System, 1999
J. Martin, “Overview of the EIA 632 Standard – ‘Processes for Engineering a System’ (Tutorial G)”
MIL-HDBK-881, DoD Work Breakdown Structure, 1993
31
3/14/2016
32
3/14/2016
Example of Product-Oriented WBS
System-level WBS…
The System
The System
Plan
The System
Design
The Integrated
System Postand Verified
Accomplishment
System
Products
The
Validated
The Subsystems
System
System
Requirements
Subsystems 1
The Subsystem
i Plan
…
Subsystems i
The Subsystem
i Design
Subsystem i
Requirements
…
Subsystems n
The Integrated and
Verified Subsystem i
The Subsystem i’s
Sub-Subsystems
Subsystem i PostAccomplishment
Products
The Validated
Subsystem i
… for engineering and constructing a system
Source: A. M. Ruskin
33
3/14/2016
Download