Transcript Slide 1

USC
C S E
University of Southern California
Center for Software Engineering
COSYSMO
COnstructive SYStems Engineering Cost MOdel
INCOSE CAB Briefing
November 1, 2002
Dr. Barry Boehm
Ricardo Valerdi
University of Southern California
Center for Software Engineering (CSE)
November 2002
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Outline
• Background on CSE, COSYSMO, and COCOMO II
• COSYSMO Overview
– Operational concept and scope
– Prototype demo
• Model Progress to Date
– Front end sizing and drivers
– Full life cycle sizing and drivers
• Calendar of activities/milestones
• Action items
• How can the CAB help?
November 2002
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
USC Center for Software Engineering (CSE)
• Researches, teaches, and practices CMMI-based
Software engineering
– Systems and software engineering fully integrated
• Focuses on better models to guide integrated systems
and software engineering
– Success models: stakeholder win-win, business
cases
– Product models: requirements, architectures, COTS
– Process models: spiral extensions, value-based
RUP extensions
– Property models: cost, schedule, quality
• Applies and extends research on major
programs (DARPA/Army, FCS, FAA ERAM,
NASA Missions)
November 2002
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
USC-CSE Affiliates (34)
• Commercial Industry (15)
– Daimler Chrysler, Freshwater Partners, Galorath, Group
Systems.Com, Hughes, IBM, Cost Xpert Group, Microsoft,
Motorola, Price Systems, Rational, Reuters Consulting, Sun,
Telcordia, Xerox
• Aerospace Industry (6)
– Boeing, Lockheed Martin, Northrop Grumman, Raytheon,
SAIC, TRW
• Government (8)
– DARPA, DISA, FAA, NASA-Ames, NSF, OSD/ARA/SIS, US
Army Research Labs, US Army TACOM
• FFRDC’s and Consortia (4)
– Aerospace, JPL, SEI, SPC
• International (1)
– Chung-Ang U. (Korea)
November 2002
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
USC-CSE Cost, Schedule, and Quality Models
• Build on experience with COCOMO 1981, COCOMO II
– Most widely used software cost models worldwide
– Developed with Affiliate funding, expertise, data
support
• Collaborative efforts between Computer Science (CS) and
Industrial Systems Engineering (ISE) Depts.
– 3 CS PhD’s, 2 ISE PhD’s to date
– Valerdi an ISE PhD student
– Boehm joint appointment in CS, ISE
• COCOMO Suite of models
– Cost, schedule: COCOMO II, CORADMO, COCOTS
– Quality: COQUALMO
– Systems Engineering: COSYSMO
• Uses mature 7-step model development methodology
November 2002
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
7-step Modeling Methodology
Analyze Existing
literature
1
Perform
Behavioral Analysis
2
Identify Relative
Significance
3
A-PRIORI MODEL
+
SAMPLING DATA
=
A-POSTERIORI MODEL
Perform ExpertJudgement, Delphi
Assessment
4
Gather Project Data
5
Determine Bayesian
A-Posteriori Update
6
Gather more data;
refine model
7
November 2002
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
COSYSMO: Overview
• Parametric model to estimate system
engineering costs
• Covers full system engineering lifecycle
• Focused on use for Investment Analysis,
Concept Definition phases estimation and
tradeoff analyses
– Input parameters can be determined in
early phases
November 2002
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Key Members of the COSYSMO
Working Group
Aerospace Corp.
Galorath
LMCO
Raytheon
SAIC
SPC
TRW
US Army/PSSM
USC
November 2002
Karen Owens, Marilee Wheaton
Evin Stump
Garry Roedler, Gary Hafen
Gary Thomas, John Rieff
Tony Jordano, Don Greenlee
Chris Miller
Marilee Wheaton
Cheryl Jones
Barry Boehm, Elliot Axelband,
Don Reifer, Ricardo Valerdi
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
COSYSMO Operational Concept
# Requirements
# Interfaces
# Scenarios
# Algorithms
+
Volatility Factor
Size
Drivers
Effort
Multipliers
- Application factors
-5 factors
- Team factors
-7 factors
- Schedule driver
November 2002
Effort
COSYSMO
Duration
Calibration
WBS guided by
EIA/ANSI 632 &
ISO/IEC 15288
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Previous COSYSMO Evolution Path
Inception
Elaboration
Construction
IP (Sub)system
1. COSYSMO-IP
C4ISR System
2. COSYSMO-C4ISR
Physical Machine
System
System of
Systems (SoS)
November 2002
Oper Test
& Eval
Transition
3. COSYSMO-Machine
4. COSYSMO-SoS
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Revised View of COSYSMO Evolution Path
(Results from last week’s meeting)
Conceptualize
Develop
Oper Test
& Eval
Transition to
Operation
Global Command
and Control
System
1. COSYSMO-IP
Satellite Ground
Station
2. COSYSMO-C4ISR
Joint Strike Fighter
3. COSYSMO-Machine
Future Combat
Systems
4. COSYSMO-SoS
Operate,
Maintain, or
Enhance
Replace or
Dismantle
Include ISO/IEC 15288 Stages
Initiate data collection for all and let
the amount of data received
determine what is included.
November 2002
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Breadth and Depth of Key SE Standards
Process
description
High level
practices
Detailed
practices
ISO/IEC 15288
EIA/ANSI 632
IEEE 1220
Level of detail
System life
Conceptualize Develop
Input to
632/1220
Transition to
Operation
Operate,
Maintain,
or Enhance
Replace
or Dismantle
Purpose of the Standards:
ISO/IEC 15288 - Establish a common framework for describing the life
cycle of systems
EIA/ANSI 632 - Provide an integrated set of fundamental processes to
aid a developer in the engineering or re-engineering of a system
IEEE 1220 - Provide a standard for managing systems engineering
November 2002
Source : Draft Report ISO Study Group May 2, 2000
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
ISO/IEC 15288 Key Terms
• System
– a combination of interacting elements organized to achieve one or more
stated purposes
• System-of-Interest
– the system whose life cycle is under consideration in the context of this
International Standard
• System Element
– a member of a set of elements that constitutes a system
– NOTE: A system element is a discrete part of a system that can be
implemented to fulfill specified requirements
• Enabling System
– a system that complements a system-of-interest during its life cycle
stages but does not necessarily contribute directly to its function during
operation
– NOTE: For example, when a system-of-interest enters the production
stage, an enabling production system is required
November 2002
Source: ISO/IEC 15288.
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
ISO/IEC 15288 System of Interest
Structure
Systemof-interest
System
System
element
System
System
element
System
System
element
November 2002
System
element
System
element
System
System
element
System
element
System
element
System
System
element
System
element
System
element
System
element
System
element
System
element
System
element
System
System
element
System
System
element
System
element
System
element
Source: ISO/IEC 15288.
Make or
buy
System
element
System
element
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Raytheon myCOSYSMO* Demo
*Developed by Gary Thomas
at Raytheon Garland
November 2002
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Outline
• Background on CSE, COSYSMO, and
COCOMO II
• COSYSMO Overview
– Operational concept and scope
– Prototype demo
• Model Progress to Date
– Front end sizing and drivers
– Full life cycle sizing and drivers
• Calendar of activities/milestones
• Action items
• How can the CAB help?
November 2002
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
4 Size Drivers
1.
2.
3.
4.
Number of System Requirements
Number of Major Interfaces
Number of Operational Scenarios
Number of Unique Algorithms
• Each weighted by complexity, volatility, and degree of reuse
November 2002
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Size Driver Definitions (1 of 4)
Number of System Requirements
The number of requirements taken from the system
specification. A requirement is a statement of capability or
attribute containing a normative verb such as shall or will. It
may be functional or system service-oriented in nature
depending on the methodology used for specification. System
requirements can typically be quantified by counting the
number of applicable shall’s or will’s in the system or
marketing specification.
Note 1: Use this driver as the basis of comparison for the rest of the drivers.
Note 2: Use equivalent size weighted by complexity, volatility, and degree of
reuse.
November 2002
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Size Driver Definitions (2 of 4)
Number of Major Interfaces
The number of shared major physical and logical
boundaries between system components or functions
(internal interfaces) and those external to the system
(external interfaces). These interfaces typically can be
quantified by counting the number of interfaces
identified in either the system’s context diagram and/or by counting
the significant interfaces in applicable Interface Control
Documents.
November 2002
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Size Driver Definitions (3 of 4)
Number of Operational Scenarios*
The number of operational scenarios** that a system is specified to
satisfy. Such threads typically result in end-to-end test scenarios
that are developed to validate the system satisfies its requirements.
The number of scenarios can typically be quantified by counting
the number of end-to-end tests used to validate the system
functionality and performance. They can also be calculated by
counting the number of high-level use cases developed as part of
the operational architecture.
Number of Modes of Operation (to be merged with Op Scen)
The number of defined modes of operation for a system. For example,
in a radar system, the operational modes could be air-to-air, air-toground, weather, targeting, etc. The number of modes is quantified by
counting the number of operational modes specified in the Operational
Requirements Document.
*counting rules need to be refined
**Op Scen can be derived from system modes
INCOSE CAB Briefing
November 2002
USC
C S E
University of Southern California
Center for Software Engineering
Size Driver Definitions (4 of 4)
Number of Unique Algorithms
The number of newly defined or significantly altered functions that
require unique mathematical algorithms to be derived in order to
achieve the system performance requirements.
Note: Examples could include a complex aircraft
tracking algorithm like a Kalman Filter being derived using existing
experience as the basis for the all aspect search function. Another
Example could be a brand new discrimination algorithm being
derived to identify friend or foe function in space-based
applications. The number can be quantified by counting the number
of unique algorithms needed to support each of the mathematical
functions specified in the system specification or mode description
document (for sensor-based systems).
November 2002
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
12 Cost Drivers
Application Factors (5)
1.
2.
3.
4.
5.
November 2002
Requirements understanding
Architecture complexity
Level of service requirements
Migration complexity
Technology Maturity
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Cost Driver Definitions (1,2 of 5)
Requirements understanding
The level of understanding of the system requirements
by all stakeholders including the systems, software, hardware,
customers, team members, users, etc…
Architecture complexity
The relative difficulty of determining and managing the
system architecture in terms of IP platforms, standards,
components (COTS/GOTS/NDI/new), connectors
(protocols), and constraints. This includes systems analysis,
tradeoff analysis, modeling, simulation, case studies, etc…
November 2002
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Cost Driver Definitions (3,4,5 of 5)
Level of service requirements
The difficulty and criticality of satisfying the Key Performance
Parameters (KPP). For example: security, safety, response time,
the “illities”, etc…
Migration complexity (formerly Legacy transition
complexity)
The complexity of migrating the system from previous system
components, databases, workflows, etc, due to new technology
introductions, planned upgrades, increased performance, business
process reengineering etc…
Technology Maturity
The relative readiness for operational use of the key
technologies.
November 2002
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
12 Cost Drivers (cont.)
Team Factors (7)
1.
2.
3.
4.
5.
6.
7.
November 2002
Stakeholder team cohesion
Personnel capability
Personal experience/continuity
Process maturity
Multisite coordination
Formality of deliverables
Tool support
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Cost Driver Definitions (1,2,3 of 7)
Stakeholder team cohesion
Leadership, frequency of meetings, shared vision, approval cycles,
group dynamics (self-directed teams, project engineers/managers),
IPT framework, and effective team dynamics.
Personnel capability
Systems Engineering’s ability to perform in their duties and the
quality of human capital.
Personnel experience/continuity
The applicability and consistency of the staff over the life of the
project with respect to the customer, user, technology, domain,
etc…
November 2002
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Cost Driver Definitions (4,5,6,7 of 7)
Process maturity
Maturity per EIA/IS 731, SE CMM or CMMI.
Multisite coordination
Location of stakeholders, team members, resources (travel).
Formality of deliverables
The breadth and depth of documentation required to be formally
delivered.
Tool support
Use of tools in the System Engineering environment.
November 2002
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Size Factors
Mapping of Old to New COSYSMO-IP Drivers
Old (7)
New (4)
Number of System Requirements
Number of Major Interfaces
Number of Technical Performance
Measures
Number of Operational Scenarios
Number of Modes of Operation
Number of Different Platforms
Number of Unique Algorithms
Number of System Requirements
Number of Major Interfaces
Number of Operational Scenarios
Number of Unique Algorithms
Level of Service Requirements
Architecture complexity
November 2002
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Delphi Round 1 Highlights
Range of sensitivity for Size Drivers
6.48
5.57
6
4
November 2002
2.21
2.23
# Modes
# TPM’s
2.54
# Algorithms
# Interfaces
1
# Requirements
2
2.10
# Platforms
Effort
# Scenarios
Relative
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Mapping of Old to New COSYSMO-IP Drivers
New (5)
Old (9)
Application Cost Factors
# of TPMs
# of Platforms
Requirements understanding
Architecture complexity
Level of service requirements
Legacy Transition complexity
COTS assessment complexity
Platform difficulty
Required business process
reengineering
Technology Maturity
Physical system/information
subsystem tradeoff analysis
complexity
November 2002
Requirements understanding
Architecture complexity
Level of service requirements
Migration complexity
Technology Maturity
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Delphi Round 1 Highlights (cont.)
Range of sensitivity for Cost Drivers (Application Factors)
4
November 2002
Legacy transition
2.81
Level of service reqs.
1.93
2.43
Requirements und.
1.74
Platform difficulty
1.13
COTS
2.13
Bus. process reeng.
2
2.24
Architecture und.
EMR
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Mapping of Old to New COSYSMO-IP Drivers
New (7)
Old (8)
Team Cost Factors
Reqs Und
Number and diversity of stakeholder
communities
Stakeholder team cohesion
Personnel capability
Personnel experience/continuity
Process maturity
Multisite coordination
Formality of deliverables
Tool support
November 2002
Stakeholder team cohesion
Personnel capability
Personal experience/continuity
Process maturity
Multisite coordination
Formality of deliverables
Tool support
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Delphi Round 1 Highlights (cont.)
Range of sensitivity for Cost Drivers (Team Factors)
November 2002
Process maturity
2.16
2.46
Personnel capability
1.84
1.94
Personal experience
1.78
Formality of deliv.
1.28
1.91
Tool support
1.25
Stakeholder cohesion
2
Stakeholder comm.
EMR
Multisite coord.
4
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Outline
• Background on CSE, COSYSMO, and
COCOMO II
• COSYSMO Overview
– Operational concept and scope
– Prototype demo
• Model Progress to Date
– Front end sizing and drivers
– Full life cycle sizing and drivers
• Calendar of activities/milestones
• Action items
• How can the CAB help?
November 2002
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
INCOSE Issues and Answers
Issue
Application scope
Answer
Life Cycle scope
Full 15288 lifecycle
Too many size drivers
Reduced from 7 to 4
Conflicting cost drivers
Reduced from 17 to 12
Overlap between
COSYSMO and CII
Candidate starting point
identified
November 2002
Framework covers all
systems; initial model
scope TBD by data
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
COSYSMO/COCOMO II Mapping
Previous candidate starting point
EIA Stage
TBD
Development
Inception
Elaboration
Construction
Transition
14
12
10
14
10
8
5
5
38
18
8
4
19
36
16
4
8
13
34
19
8
10
24
24
3
3
3
30
Management
Environment/CM
Requirements
Design
Implementation
Assessment
When doing
COSYSMO-IP and
COCOMOII,
Subtract grey areas
prevent double
counting.
Deployment
TBD
TBD
TBD
= COCOMOII
November 2002
= COSYSMO-IP
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Size Drivers vs. EIA/ANSI 632 & ISO/IEC
15288 Stages Late in the Life Cycle
632 - 20
15288
(Implement- 632 - 21
632 - 31
632 - 32
632 - 33b
15288
(Maintenance
15288
ation)
(Transition) (Verification) (Readiness) (Validation) (Operations) or Support) (Retirement)
# System Requirements
# Major Interfaces
# Unique Algorithms
# Operational Scenarios
# Recursive Levels in the Design
# Systems being Phased Out
(Covered by Migration Complexity?)
# Operators / Maintainers
# Training Courses
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
# Installations
# System Elements
# Length of Lifecycle
Legend
Bold = existing driver
Italics = proposed addition
November 2002
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Cost Drivers vs. EIA/ANSI 632 & ISO/IEC
15288 Stages Late in the Life Cycle
Application factors
–Requirements understanding
–Architecture complexity
–Level of service requirements,
criticality, difficulty
–Migration complexity
–Technology risk (maturity &
obsolescence)
632 - 20
15288
(Implement- 632 - 21
632 - 31
632 - 32
632 - 33b
15288
(Maintenance
15288
ation)
(Transition) (Verification) (Readiness) (Validation) (Operations) or Support) (Retirement)
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
- Operational Complexity
Legend
Bold = existing driver
Italics = proposed addition
November 2002
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Cost Drivers vs. EIA/ANSI 632 & ISO/IEC
15288 Stages Late in the Life Cycle
Team factors
–Stakeholder team cohesion
–Personnel capability
–Personnel experience/continuity
–Process maturity
–Multi-site coordination
–Formality of deliverables
–Tool support
632 - 20
15288
(Implement- 632 - 21
632 - 31
632 - 32
632 - 33b
15288
(Maintenance
15288
ation)
(Transition) (Verification) (Readiness) (Validation) (Operations) or Support) (Retirement)
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Legend
Bold = existing driver
Italics = proposed addition
November 2002
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Outline
• Background on CSE, COSYSMO, and
COCOMO II
• COSYSMO Overview
– Operational concept and scope
– Prototype demo
• Model Progress to Date
– Front end sizing and drivers
– Full life cycle sizing and drivers
• Calendar of activities/milestones
• Action items
• How can the CAB help?
November 2002
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Parametric Cost Model Critical Path
Usual #
Months*
Critical Path Task
6
Converge on cost drivers, WBS
6
Converge on detailed definitions and rating scales
12
Obtain initial exploratory dataset (5-10 projects)
6
Refine model based on data collection & analysis
experience
12+
Obtain IOC calibration dataset (30 projects)
9
Refine IOC model and tool
*Can be shortened and selectively overlapped
November 2002
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Calendar of Activities: 2003
(opportunities to accelerate tasks)
Practical Software &
Systems Measurement
Workshop
USC CSE Annual Research Review
Practical Software &
Systems Measurement
Workshop
Telecon
D
J
F
M
A
M
J
J
A
S
2003
N
D
2004
INCOSE
Fall Workshop
INCOSE 2003
Conference on
Systems Integration
November 2002
O
COCOMO Forum
Paper &
tutorial
submitted
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Action Items from Last Week
1. Develop a project Plan
2. Address technology maturity/obsolescence
3. Refine driver definitions to incorporate
ISO/IEC 15288 definitions
4. Incorporate System and People idea
5. Refine drivers applicability matrix
6. Develop data collection strategy
7. Generate Data Collection Form
8. Update Stakeholder Cohesion to include
diversity, identification and trust
November 2002
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Outcomes From Last Week’s Workshop
November 2002
• Reach consensus on resolving the
issues
• Converge on scope of COSYSMO-IP
model
• Address INCOSE issues
• Address definitions of model
parameters
• Discuss data collection process
• Promote involvement by Affiliates
• Define next steps for CSI and INCOSE
conferences
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
How can the CAB help?
• Model Calibration Data
– COSYSMO IOC will be delivered within 9
months of having 30 “clean” data points
• Commitment of resources to assist with model
and data definition and collection
• Your support for our proposal to INCOSE
SECOE
• Help in obtaining lead participants from other
INCOSE Corporate Members
• Establish COSYSMO “owner” within INCOSE
– Measurement Working Group willing
• Data, Data, Data
November 2002
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Key Members of the COSYSMO
Working Group
Aerospace Corp.
Galorath
LMCO
Raytheon
SAIC
SPC
TRW
US Army/PSSM
USC
November 2002
Karen Owens, Marilee Wheaton
Evin Stump
Garry Roedler, Gary Hafen
Gary Thomas, John Rieff
Tony Jordano, Don Greenlee
Chris Miller
Marilee Wheaton
Cheryl Jones
Barry Boehm, Elliot Axelband,
Don Reifer, Ricardo Valerdi
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Points of Contact
Dr. Barry Boehm
[[email protected]]
Dr. Elliot Axelband
[[email protected]]
Don Reifer
[[email protected]]
Ricardo Valerdi
[[email protected]]
Website
http://sunset.usc.edu
November 2002
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Backup Charts
November 2002
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
USC-CSE Research ($10M backlog)
• DARPA/Army: Model applications and extensions for
Future Combat Systems
• DARPA: Architectures for mobile distributed
systems (DASADA)
• FAA: Acquisition processes; COCOMO security
extensions
• NASA: Empirical methods for High Dependability
Computing
• NSF: Center for Empirically-Based Software
Engineering (with U. of Maryland)
• NSF: Strategic Design (with CMU, Virginia,
Washington)
• Industry Affiliates’ program
November 2002
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
General Affiliate Benefits
•
•
•
•
•
•
•
•
•
•
November 2002
Affiliates-only Web portal
– Early access to tools, methods, papers, talks,
student resumes
Tools: COCOMO Suite, Architecture tools, WinWin
Technical Report series
Workshops on Affiliate-prioritized topics
Annual Research Review and Steering Group
meeting
Annual one-day professor-visit
Bilateral visit arrangements; internships
Conferences and special workshops
Monthly LA SPIN meetings
Tutorials and eWorkshops
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Collaboration Modes and Special Benefits
•
•
•
•
•
•
November 2002
Software architecting assistance
-Aerospace, Hughes, JPL, Northrop Grumman, TACOM, TRW,
Xerox
Software process/cost/quality/cycle time assistance
-Aerospace, Litton, Microsoft, Northrop Grumman, Raytheon, SAIC,
Sun, TACOM, TRW, Xerox
Management reviews of critical projects
-Litton, Motorola, SAIC, SEI, TRW
Reviews of corporate research programs
-Daimler Chrysler, Draper Labs, Lockheed Martin, SAIC, SEI, SPC,
Telcordia, TRW
Joint research contracts
-Aerospace, Lockheed Martin, Northrop Grumman, SEI, SPC, TRW
Aid in commercializing USC-CSE research
-C-Bridge, Galorath, Group Systems.com, Marotz, Price Systems,
Rational
INCOSE CAB Briefing
USC
C S E
University of Southern California
Center for Software Engineering
Collaboration Modes and Special Benefits - II
•
•
•
•
•
November 2002
Special Projects
-Aerospace, Auto Club, FAA, Fidelity, IBM, JPL, Litton, Northrop
Grumman, Telcordia
Joint workshops on key topics
-Aerospace, Motorola, Rational, DOD/SIS, SEI, SPC
Focused working groups (COSYSMO)
-Aerospace, Galorath, Lockheed Martin, Raytheon, SAIC, SPC, TRW
Visiting collaborators
-Aerospace, Chung-Ang, C-Bridge, IBM, JPL, Litton, Northrop
Grumman, SEI, TRW
Corporate State-of-the-art tutorials
-Boeing, Chung-Ang, Daimler Chrysler, Draper, EDS, FAA, Fidelity,
IBM, JPL, Litton, Lockheed Martin, Lucent, Motorola, Microsoft,
Raytheon, SAIC, SEI, SPC, Sun, TRW, Xerox
INCOSE CAB Briefing