October 28, 2001DRAFT1 COSYSMO: Reference System (Satellite Ground Station) Donald J. Reifer and Ricardo Valerdi University of Southern California

October 28, 2001DRAFT2 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) InceptionElaboration ConstructionTransition

October 28, 2001DRAFT3 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: –

October 28, 2001DRAFT4 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

October 28, 2001DRAFT5 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

October 28, 2001DRAFT6 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

October 28, 2001DRAFT7 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)

October 28, 2001DRAFT8 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 API’s

October 28, 2001DRAFT9 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.)

October 28, 2001DRAFT10 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

October 28, 2001DRAFT11 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

October 28, 2001DRAFT12 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 API’s A real-time clock is tied to the network to address timing requirements

October 28, 2001DRAFT13 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

October 28, 2001DRAFT14 Systems Engineering’s Job Scope of system engineering’s 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

October 28, 2001DRAFT15 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

October 28, 2001DRAFT16 Communications Architecture - Inter-Applications Interface View Standard API’s govern flow of information via applications Bus architecture is layered and conforms to CCITT layered standards

October 28, 2001DRAFT17 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

October 28, 2001DRAFT18 Systems Engineering’s Job Scope of system engineering’s 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

October 28, 2001DRAFT19 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

October 28, 2001DRAFT20 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

October 28, 2001DRAFT21 Current COSYSMO Structure COSYSMO Size Drivers Cost Drivers Effort Duration Calibration # Requirements # Interfaces # TPM’s # Scenarios # Modes # Platforms # Algorithms - Application factors -7 factors - Team factors -8 factors WBS guided By EIA 632

October 28, 2001DRAFT22 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 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 must develop to solve problem

October 28, 2001DRAFT23 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

October 28, 2001DRAFT24 Plan of Action & Milestones (Status) TaskDue DateResponsible* TaskDue Date Responsible* 1.Develop reference system11//01/01Reifer/Valerdi 2.Define cost drivers11/16/01Wheaton/Valerdi 3.Define size drivers11/16/01Hafen/Thomas 4.Define effort scope11/16/01Hafen/Thomas 5.Finalize survey instrument11/30/01Thomas/Valerdi 6.Send materials out for review12/03/01All focal points 7.Hold net meeting/discuss results12/11/01All focal points 8.Updates done/Delphi defined01/14/02Reifer/Valerdi 9.Send Delphi out01/15/02All focal points 10.Complete Delphi round02/15/02Reifer/Valerdi 11.Update done based on results03/05/02Reifer/Valerdi 12.Present results at annual review03/12/02Valerdi * Axelband/Boehm involved in all activities

October 28, 2001DRAFT25 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