Loading in 2 Seconds...
Loading in 2 Seconds...
Tutorial H01:. International Council on System Engineering – 2003 Symposium Crystal City, VA June 30, 2003. Dr. Barry W. Boehm – USC Center for Software Engineering Dr. John E. Rieff – Intelligence and Information Systems , Raytheon
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
International Council on System Engineering – 2003 Symposium
Crystal City, VA
June 30, 2003
Dr. Barry W. Boehm – USC Center for Software Engineering
Dr. John E. Rieff – Intelligence and Information Systems, Raytheon
Gary D. Thomas– Intelligence and Information Systems, Raytheon
Ricardo Valerdi – USC Center for Software Engineering
US Army Research Labs, US Army TACOM
USC CSE Annual Research Review
(Los Angeles, CA)
(Los Angeles, CA)
Practical Software & Systems Measurement Workshop
Systems Engineering Research
(Los Angeles, CA)
Working Group Meeting
From CMMI-SE/SW/IPPD/SS, v1.1
Level 2: Project Planning
SP 1.4 Determine Estimates of Effort and Cost
Level 2: Measurement and Analysis
SP 1.2 Specify Measures
Calibration: the tuning of parameters based on project data
CER: a model that represents the cost estimating relationships between factors
Cost Estimation: prediction of both the
person-effort and elapsed time of a project
Driver: A factor that drives the amount of Systems Engineering effort
Parametric: an equation or model that is approximated by a set of parameters
Rating Scale: a range of values and definitions for a particular driver
Understanding: an individual’s subjective judgment of their level of comprehension
Gather Project Data
Gather more data;
Determine statistical significance
WBS guided by
Level of detail
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
Breadth and Depth of Key SE Standards
Source : Draft Report ISO Study Group May 2, 2000
SBIRS or FCS
Source: ISO/IEC 15288.
Operate, Maintain, or Enhance
Transition to Operation
Replace or Dismantle
Global Command and Control System
Include ISO/IEC 15288 Stages
Satellite Ground Station
Joint Strike Fighter
Future Combat Systems
PMNS = effort in Person Months (Nominal Schedule)
A = constant derived from historical project data
Size = determined by computing the weighted average of the (4) size drivers
E = could represent economy/diseconomy of scale, currently equals 1
n = number of cost drivers (14)
EM = effort multiplier for the ith cost driver. The geometric product results in an overall effort adjustment factor to the nominal effort.
This driver represents the number of requirements for the system-of-interest at a specific level of design. Requirements may be functional, performance, feature, or service-oriented in nature depending on the methodology used for specification. They may also be defined by the customer or contractor. System requirements can typically be quantified by counting the number of applicable “shall’s” or “will’s” in the system or marketing specification. Do not include a requirements expansion ratio – only provide a count for the requirements of the system-of-interest as defined by the system or marketing specification.
This driver represents 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 all applicable Interface Control Documents.
This driver represents the number of operational scenarios that a system must satisfy. Such threads typically result in end-to-end test scenarios that are developed to validate the system and satisfy all of its requirements. The number of scenarios can typically be quantified by counting the number of unique end-to-end tests used to validate the system functionality and performance or by counting the number of high-level use cases developed as part of the operational architecture.
This driver represents 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. As an example, this 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.
Application Factors (8)
This cost driver rates the level of understanding of the system requirements by all stakeholders including the systems, software, hardware, customers, team members, users, etc.
This cost driver rates the relative difficulty of determining and managing the system architecture in terms of platforms, standards, components (COTS/GOTS/NDI/new), connectors (protocols), and constraints. This includes tasks like systems analysis, tradeoff analysis, modeling, simulation, case studies, etc.
This cost driver rates the difficulty and criticality of satisfying the ensemble of Key Performance Parameters (KPP), such as security, safety, response time, interoperability, maintainability, the “ilities”, etc.
This cost driver rates the complexity of migrating the system from previous system components, databases, workflows, environments, etc., due to new technology introductions, planned upgrades, increased performance, business process reengineering, etc.
The maturity, readiness, and obsolescence of the technology being implemented.
The breadth and depth of documentation required to be formally delivered based on the life cycle needs of the system.
The number of different platforms that the system will be hosted and installed on. The complexity in the operating environment (space, sea, land, fixed, mobile, portable, information assurance/security). For example, in a wireless network it could be the number of unique installation sites and the number of and types of fixed clients, mobile clients, and servers. Number of platforms being implemented should be added to the number being phased out (dual count).
The number of levels of design related to the system-of-interest and the amount of required SE effort for each level.
Team Factors (6)
Represents a multi-attribute parameter which includes leadership, shared vision, diversity of stakeholders, approval cycles, group dynamics, IPT framework, team dynamics, trust, and amount of change in responsibilities. It further represents the heterogeneity in stakeholder community of the end users, customers, implementers, and development team.
Basic intellectual capability of a Systems Engineer to analyze complex problems and synthesize solutions.
The applicability and consistency of the staff at the initial stage of the project with respect to the domain, customer, user, technology, tools, etc.
Maturity per CMMI, EIA 731 or SE CMM.
Location of stakeholders, team members, resources, corporate collaboration barriers.
Coverage, integration, and maturity of the tools in the Systems Engineering environment.
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
*Developed by Gary Thomas at Raytheon Garland
The TOC is “Home Base”
Document Assumptions and Requirement Sources
Initialize Project Parameters
Rate Cost Drivers
Determine Labor Distributions/Profiles
Generate Effort Hours and Costs
*Enter CWBS Task Descriptions
*Time Phase the Estimate
*Review and Submit to Pricing FunctionPossible SE “Cost Estimation Mode” Steps Using COSYSMO
Dr. Barry Boehm
John E. Rieff
Gary D. Thomas