COSYSMO:%20Reference%20System%20(Satellite%20Ground%20Station)

1
COSYSMO Reference System (Satellite Ground
Station)

• Donald J. Reifer
• and
• Ricardo Valerdi
• University of Southern California

2
Goals of Effort

• Build a COCOMO-like model for estimating system
  engineering resources
• Model a member of the COCOMO family of models
• This initial COSYSMO (Constructive System
  Engineering Model) effort will fill in the holes
  not covered by COCOMO II during the inception
  phase of the MBASE life cycle (see below)

Inception Elaboration Construction Transition
3
Purpose of Presentation

• To frame the model using an example system
• Identify what activities are and are not within
  the scope of the models effort and duration
  estimates
• Define the components of the labor estimate
• A detailed reference architecture specification
  for such a system has been prepared by The
  Aerospace Corporation and can be found at
• http//sunset.usc.edu/SSCS/abstract.html

4
Context Diagram

• Network operations
• external to boundary
• Satellite operations
• includes
• - COTS hardware
• - Software
• - Communications
• Signals to control
• antennas and remote
• facilities assumed to
• be digital in form

5
System Description

• External to system are elements of network
  operations
• These elements provide the antennas used to track
  satellites, the communications equipment for TTC
  and centralized resource management functions
• Internal to the system are the hardware and
  software to perform
• Mission planning - Orbit data processing
• Telemetry processing - Attitude data processing
• Satellite commanding
• Simulation and resource management are outside
  the scope of the system in this analysis

6
General System Engineering Tasks

• Prepare System Engineering Master Plan (SEMP),
  Test Evaluation Master Plan (TEMP)
• Define Technical Performance Measures (TPMs) for
  managing the effort
• Provide support to the Program Office on an
  as-directed basis
• Not within scope as charged to Program Office
  accounts
• Prepare/conduct System Integration and Test and
  ready facilities and regression tests for this
  purpose
• Not within scope as all but planning is done in
  phases outside of the Inception Phase

7
Labor Assumptions

• Person-month assumed to be 152 hours/month
• All directly chargeable labor included
• System engineering tasks/documentation
• Task management/progress reporting
• Algorithm/simulation development
• Specialty engineering (reliability, safety, etc.)
• Support personnel (CM, QA, publications, etc.)
• Integrated product team leadership and support
  (as applicable to the task at hand)

8
Software Architecture

• Software layered into
• - System services
• - Middleware
• - Applications
• Outer ring contains
• mission-specific information sources
• (databases, knowledge
• base and specialized
• code)
• Applications communi-
• cate via standard APIs

9
Simplifying Assumptions

• The architecture is layered with System Services
  residing in middle/information bases on outside
• Service layer segmentation is as defined by the
  reference architecture
• Performance has been taken into account in the
  design
• Applications are distributed across hardware
  elements of the system
• TTC Applications (mission planning, orbit, etc.)
• Mission Applications (payload command generation,
  maneuver planning, etc.)
• Support Applications (vehicle simulation, etc.)

10
Systems Engineerings Job

• Scope of system engineerings job
• Allocate system requirements to the software
• Define a compatible top-level architecture that
  meets requirements and takes advantage of
  COTS/GOTS
• Specify the major hardware/software system
  interfaces, both internal and external
• Map operational scenarios from the Operational
  Concept Document to the architecture
• Determine whether functional and performance
  requirements can be satisfied

11
More On The Job

• Job scope (continued)
• Perform necessary system tradeoffs to ensure that
  functional and performance requirements can be
  met
• Define algorithms needed to achieve system
  requirements for implementation in the software
• Validate these equations using 3D and 6D
  simulations
• Develop system integration and test strategy
  aimed at demonstrating compliance with
  requirements
• Perform market watch and work with suppliers to
  ensure that system requirements can be satisfied

12
Hardware Architecture - Bus View

• Hardware is distributed
• and communications is
• enabled via standard
• buses and protocols
• Each box on the network
• contains one or more
• COTS processors that
• interface via standard
• hardware APIs
• A real-time clock is tied
• to the network to address
• timing requirements

13
Simplifying Assumptions

• There is no custom hardware - all requirements
  can be satisfied using COTS components
• Hardware communicates via standard protocols
  across buses that have the bandwidth to
  accommodate the peak loading requirements of the
  applications
• Interfaces to external systems are well-defined
  and protocols have been specified
• Reliability-Maintainability-Availability measures
  of effectiveness for the system can be realized
  using vendor-supplied solutions

14
Systems Engineerings Job

• Scope of system engineerings job
• Allocate system requirements to the hardware
• Determine whether functional, performance and
  specialty engineering requirements can be
  satisfied
• Perform applicable hardware/software trade
  studies
• Define a compatible hardware architecture that
  satisfies the requirements
• Specify the major system interfaces, both
  internal and external
• Map operational scenarios to Operational Concept
  Document and to Test Evaluation Master Plan

15
More On The Job

• Job scope (continued)
• Define algorithms needed to achieve system
  fallback and recovery requirements via hardware
  BIT/FIT
• Develop system integration and test strategy
  aimed at demonstrating compliance with
  requirements
• Includes test bed and test facility long-lead
  item definition
• Ensure producibility and manufacturability of the
  hardware elements of the system
• Perform necessary system tradeoffs to ensure that
  functional and performance requirements can be met

16
Communications Architecture -Inter-Applications
Interface View

• Standard APIs
• govern flow of
• information via
• applications
• Bus architecture
• is layered and
• conforms to CCITT
• layered standards

17
Simplifying Assumptions

• There is no custom communications - all allocated
  requirements can be satisfied using vendor
  supplied solutions/systems
• Communications systems are viewed by hardware and
  software as pipes that provide data across system
  interfaces
• Bandwidth provided is acceptable as are the error
  detection and correction techniques
• Interfaces to external systems are well-defined
  and communications protocols are supported

18
Systems Engineerings Job

• Scope of system engineerings job
• Allocate system requirements for communications
• Perform communications tradeoff analysis
• Specify communications architecture and protocols
• Specify the major communications interfaces, both
  internal and external
• Map operational scenarios from the Operational
  Concept Document to the architecture via threads
  using communications flows to govern end-to-end
  processing flow

19
More On The Job

• Job scope (continued)
• Determine whether functional and performance
  requirements can be satisfied by performing an
  operational/interface analysis
• May need to develop prototypes or simulation
  model to accomplish this task
• Develop system integration and test strategy
  aimed at demonstrating compliance with
  requirements allocated to communications
• May require specialized equipment and facilities

20
Strawman COSYSMO

• Based on the scope of the example system, the
  model
• Will be of the form of COCOMO II
• Be developed via USC 7-step model building
  process
• Will initially be limited to Inception Phase
  tasks
• Will use EIA 632 to bound effort
• Focus on software intensive systems like defined
  in our example Satellite Ground Station
• Goal is to have something meaningful done by
  mid-March 2002

21
Current COSYSMO Structure
Requirements Interfaces TPMs Scenarios
Modes Platforms Algorithms
COSYSMO
Size Drivers
Effort
Duration
Cost Drivers

• Application factors
• 7 factors
• Team factors
• 8 factors

Calibration
WBS guided By EIA 632
22
Size Drivers (First Pass)
Size Drivers Measure of Counted By
requirements Functional requirements shalls
in System Spec Performance requirements
Measures of Performance/ Measures of
Effectiveness interfaces Interface
requirements interfaces needed to
be bounded via ICDs/MOAs TPMs
Managerial requirements of TPMs to be
reported scenarios Operational requirements
operational threads and/or system level use
cases modes Operational requirements
operational modes to be supported
platforms Operational requirements platforms
to be supported algorithms Operational
requirements of new algorithms that
system engineering must develop to
solve problem
23
Cost Drivers (Initial List)

• Application factors
• Requirements understanding
• Architecture understanding
• Level of service requirements
• Legacy transition complexity
• COTS assessment complexity
• Platform difficulty
• Required business process reengineering

• Team factors
• Number and diversity of stakeholder communities
• Stakeholder team cohesion
• Personnel capability and continuity
• Process maturity
• Multis-site coordination
• Degree of system engineering ceremony
• Too support

Initial definitions prepared by Dr. Boehm in
previous charts
24
Plan of Action Milestones (Status)

• Task Due Date Responsible
• Develop reference system 11//01/01 Reifer/Valerdi
  
• Define cost drivers 11/16/01 Wheaton/Valerdi
• Define size drivers 11/16/01 Hafen/Thomas
• Define effort scope 11/16/01 Hafen/Thomas
• Finalize survey instrument 11/30/01 Thomas/Valerd
  i
• Send materials out for review 12/03/01 All focal
  points
• Hold net meeting/discuss results 12/11/01 All
  focal points
• Updates done/Delphi defined 01/14/02 Reifer/Valerd
  i
• Send Delphi out 01/15/02 All focal points
• Complete Delphi round 02/15/02 Reifer/Valerdi
• Update done based on results 03/05/02 Reifer/Valer
  di
• Present results at annual review 03/12/02 Valerdi

Axelband/Boehm involved in all activities
25
Summary and Conclusions

• Bounded COSYSMO using Satellite Ground Station
  example
• Defined what labor is within scope for the effort
• Defined typical tasks performed to support
  allocation of requirements for hardware, software
  and communications components of the system
• Summarized existing model assumptions, structure
  and components
• Developed size driver list a little further
• Created one briefing to serve as basis for
  further work