October 28, 2001DRAFT1 COSYSMO: Reference System (Satellite Ground Station) Donald J. Reifer and...

October 28, 2001 DRAFT 1

COSYSMO: Reference System (Satellite Ground Station)

Donald J. Reifer

and

Ricardo Valerdi

University of Southern California

USC

C S E University of Southern CaliforniaCenter for Software Engineering


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)

USC


Inception Elaboration Construction Transition


Purpose of Presentation• To frame the model using an example system:

– Identify what activities are and are not within the scope of the model’s 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

USC



Context Diagram

USC


• 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


System Description• External to system are elements of network operations

– These elements provide the antennas used to track satellites, the communications equipment for TT&C 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

USC



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

USC



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)

USC



Software Architecture

USC


• 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 API’s


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– TT&C Applications (mission planning, orbit, etc.)

– Mission Applications (payload command generation, maneuver planning, etc.)

– Support Applications (vehicle simulation, etc.)

USC



Systems Engineering’s Job• Scope of system engineering’s 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

USC



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

USC



Hardware Architecture - Bus View

USC


• 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 API’s• A real-time clock is tied to the network to address timing requirements


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

USC




– 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

USC




– 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

USC



Communications Architecture -Inter-Applications Interface View

USC


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


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

USC




– 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

USC




– 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

USC



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

USC



Current COSYSMO Structure

USC


COSYSMOSizeDrivers

CostDrivers

Effort

Duration

Calibration

# Requirements# Interfaces# TPM’s# Scenarios# Modes# Platforms# Algorithms

- Application factors-7 factors

- Team factors-8 factors

WBS guidedBy EIA 632


Size Drivers (First Pass)

USC


Size DriversSize Drivers Measure of:Measure of: Counted By:Counted By:# requirements Functional requirements # shalls in System Spec

Performance requirements # Measures of Performance/# Measures of Effectiveness

# interfaces Interface requirements # interfaces needed to bebounded via ICD’s/MOA’s

# 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 mustdevelop to solve problem


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

USC


Initial definitions prepared by Dr. Boehm in previous charts


Plan of Action & Milestones (Status)

USC


TaskTask Due DateDue Date Responsible*Responsible*1.1. Develop reference systemDevelop reference system 11//01/0111//01/01 Reifer/ValerdiReifer/Valerdi2. Define cost drivers 11/16/01 Wheaton/Valerdi3. Define size drivers 11/16/01 Hafen/Thomas4. Define effort scope 11/16/01 Hafen/Thomas5. Finalize survey instrument 11/30/01 Thomas/Valerdi6. Send materials out for review 12/03/01 All focal points7. Hold net meeting/discuss results 12/11/01 All focal points8. Updates done/Delphi defined 01/14/02 Reifer/Valerdi9. Send Delphi out 01/15/02 All focal points10. Complete Delphi round 02/15/02 Reifer/Valerdi11. Update done based on results 03/05/02 Reifer/Valerdi12. Present results at annual review 03/12/02 Valerdi

* Axelband/Boehm involved in all activities


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

USC


October 28, 2001DRAFT1 COSYSMO: Reference System (Satellite Ground Station) Donald J. Reifer and...

Documents

Transcript of October 28, 2001DRAFT1 COSYSMO: Reference System (Satellite Ground Station) Donald J. Reifer and...