July 2002 COSYSMO-IP COnstructive SYStems Engineering Cost Model – Information Processing PSM User’s Group Conference Keystone, Colorado July 24 & 25, 2002 Dr. Barry Boehm Ricardo Valerdi University of Southern California Center for Software Engineering USC C S E U niversity ofSouthern C alifornia C enterfor Softw are Engineering Version 3
37
Embed
July 2002 COSYSMO-IP COnstructive SYStems Engineering Cost Model – Information Processing PSM User’s Group Conference Keystone, Colorado July 24 & 25,
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
July 2002
COSYSMO-IP COnstructive SYStems Engineering Cost
Model – Information Processing
PSM User’s Group Conference
Keystone, Colorado
July 24 & 25, 2002
Dr. Barry BoehmRicardo ValerdiUniversity of Southern CaliforniaCenter for Software Engineering
USC
C S E University of Southern CaliforniaCenter for Software Engineering
Version 3
July 2002 2
Outline – Day 1• USC Center for Software Engineering
• Background & Update on COSYSMO-IP
• Ops Con & EIA632
• Delphi Round 1 Results
• Updated Drivers
• Lessons Learned/Improvements
• LMCO & INCOSE Comments
• Q & A
USC
C S E University of Southern CaliforniaCenter for Software Engineering
July 2002 3
Outline – Day 2• Review of yesterday’s modified slides
to clarify terminology
• A few new slides to emphasize points
• Review of current driver definitions
• Definition for two new Cost drivers– Technology Maturity– Physical system/information system
tradeoff analysis complexity
USC
C S E University of Southern CaliforniaCenter for Software Engineering
July 2002 4
Objectives of the Workshop• Agree on a Concept of Operation• Converge on scope of COSYSMO-IP model• Address definitions of model parameters• Discuss data collection process
USC
C S E University of Southern CaliforniaCenter for Software Engineering
C S E University of Southern CaliforniaCenter for Software Engineering
July 2002 21
4 Size Drivers1. Number of System Requirements
2. Number of Major Interfaces
3. Number of Operational Scenarios
4. Number of Unique Algorithms
USC
C S E University of Southern CaliforniaCenter for Software Engineering
Number of Technical Performance Measures
Number of Modes of OperationNumber of Different Platforms
COSTDriver
COSTDriver
July 2002 22
Size Driver Definitions (1 of 4)
Number of System RequirementsThe 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: Use this driver as the basis of
comparison for the rest of the drivers.
USC
C S E University of Southern CaliforniaCenter for Software Engineering
July 2002 23
Size Driver Definitions (2 of 4)
Number of Major InterfacesThe 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.
USC
C S E University of Southern CaliforniaCenter for Software Engineering
July 2002 24
Size Driver Definitions (3 of 4)Number of Operational Scenarios*The number of operational scenarios** that a system is specified tosatisfy. Such threads typically result in end-to-end test scenariosthat are developed to validate the system satisfies its requirements.The number of scenarios can typically be quantified by countingthe number of end-to-end tests used to validate the systemfunctionality and performance. They can also be calculated bycounting the number of high-level use cases developed as part ofthe operational architecture.
USC
C S E University of Southern CaliforniaCenter for Software Engineering
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-to-ground, 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
July 2002 25
Size Driver Definitions (4 of 4)Number of Unique AlgorithmsThe number of newly defined or significantly altered functions thatrequire unique mathematical algorithms to be derived in order toachieve the system performance requirements.
Note: Examples could include a complex aircrafttracking algorithm like a Kalman Filter being derived using existingexperience as the basis for the all aspect search function. AnotherExample could be a brand new discrimination algorithm beingderived to identify friend or foe function in space-basedapplications. The number can be quantified by counting the
numberof unique algorithms needed to support each of the mathematicalfunctions specified in the system specification or mode descriptiondocument (for sensor-based systems).
USC
C S E University of Southern CaliforniaCenter for Software Engineering
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…
USC
C S E University of Southern CaliforniaCenter for Software Engineering
Level of service requirementsThe difficulty and criticality of satisfying the Key Performance Parameters (KPP). For example: security, safety, response time, the “illities”, etc…
Technology MaturityThe relative readiness for operational use of the key
technologies.
July 2002 29
12 Cost Drivers (cont.)
1. Number and diversity of stakeholder communities
2. Stakeholder team cohesion
3. Personnel capability
4. Personal experience/continuity
5. Process maturity
6. Multisite coordination
7. Formality of deliverables
8. Tool support
Team Factors (7)
USC
C S E University of Southern CaliforniaCenter for Software Engineering
July 2002 30
Cost Driver Definitions (1,2,3 of 7)
USC
C S E University of Southern CaliforniaCenter for Software Engineering
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 thequality 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…
July 2002 31
Cost Driver Definitions (4,5,6,7 of 7)
USC
C S E University of Southern CaliforniaCenter for Software Engineering
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.
July 2002 32
Lessons Learned/Improvements
Lesson 1 – Need to better define the scope and future of COSYSMO-IP via Con OpsLesson 2 – Drivers can be interpreted in differentWays depending on the type of programLesson 3 – COSYSMO is too software-orientedLesson 4 – Delphi needs to take less time to fill outLesson 5 – Need to develop examples, rating scales
USC
C S E University of Southern CaliforniaCenter for Software Engineering
The current COSYSMO focus is too software oriented. This is a good point. We propose to change the scope from "software-intensive systems or subsystems" to "information processing (IP) systems or subsystems." These include not just the software but also the associated IP hardware processors; memory; networking; display or other human-computer interaction devices. System engineering of these IP systems or subsystems includes considerations of IP hardware device acquisition lead times, producibility, and logistics. Considerations on non-IP hardware acquisition, producibility, and logistics are considered as IP systems engineering cost and schedule drivers for the IOC version of COSYSMO. Perhaps we should call it COSYSMO-IP.
LMCO Comments
USC
C S E University of Southern CaliforniaCenter for Software Engineering
July 2002 34
The COSYSMO project should begin by working out the general framework and WBS for the full life cycle of a general system. We agree that such a general framework and WBS will eventually be needed. However, we feel that progress toward it can be most expeditiously advanced by working on definitions of and data for a key element of the general problem first. If another group would like to concurrently work out the counterpart definitions and data considerations for the general system engineering framework, WBS, and estimation model, we will be happy to collaborate with them.
LMCO Comments (cont.)
USC
C S E University of Southern CaliforniaCenter for Software Engineering