Transcript COSYSMO: Reference System (Satellite Ground Station)

USC
C
S E
University of Southern California
Center for Software Engineering
COSYSMO: Reference System
(Satellite Ground Station)
Donald J. Reifer
and
Ricardo Valerdi
University of Southern California
October 28, 2001
DRAFT
1
USC
C
S E
University of Southern California
Center 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)
Inception
October 28, 2001
Elaboration
Construction
DRAFT
Transition
2
USC
C
S E
University of Southern California
Center for Software Engineering
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
October 28, 2001
DRAFT
3
USC
C
S E
University of Southern California
Center for Software Engineering
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, 2001
DRAFT
4
USC
C
S
E
University of Southern California
Center for Software Engineering
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
– Telemetry processing
– Satellite commanding
- Orbit data processing
- Attitude data processing
• Simulation and resource management are outside the
scope of the system in this analysis
October 28, 2001
DRAFT
5
USC
C
S E
University of Southern California
Center for Software Engineering
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 asdirected 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, 2001
DRAFT
6
USC
C S E
University of Southern California
Center for Software Engineering
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, 2001
DRAFT
7
USC
C
S E
University of Southern California
Center for Software Engineering
Software Architecture
• Software layered into:
- System services
- Middleware
- Applications
• Outer ring contains
mission-specific
information sources
(databases, knowledge
base and specialized
code)
• Applications communicate via standard API’s
October 28, 2001
DRAFT
8
USC
C
S E
University of Southern California
Center for Software Engineering
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, 2001
DRAFT
9
USC
C
S E
University of Southern California
Center for Software Engineering
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, 2001
DRAFT
10
USC
C S E
University of Southern California
Center for Software Engineering
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, 2001
DRAFT
11
USC
C
S E
University of Southern California
Center for Software Engineering
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, 2001
DRAFT
12
USC
C
S E
University of Southern California
Center for Software Engineering
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, 2001
DRAFT
13
USC
C
S E
University of Southern California
Center for Software Engineering
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, 2001
DRAFT
14
USC
C
S E
University of Southern California
Center for Software Engineering
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, 2001
DRAFT
15
USC
C
S E
University of Southern California
Center for Software Engineering
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, 2001
DRAFT
16
USC
C
S E
University of Southern California
Center for Software Engineering
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, 2001
DRAFT
17
USC
C
S E
University of Southern California
Center for Software Engineering
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, 2001
DRAFT
18
USC
C
S E
University of Southern California
Center for Software Engineering
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, 2001
DRAFT
19
USC
C
S E
University of Southern California
Center for Software Engineering
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, 2001
DRAFT
20
USC
C
S E
University of Southern California
Center for Software Engineering
Current COSYSMO Structure
# Requirements
# Interfaces
# TPM’s
# Scenarios
# Modes
# Platforms
# Algorithms
Size
Drivers
Effort
COSYSMO
Duration
Cost
Drivers
- Application factors
Calibration
-7 factors
- Team factors
-8 factors
October 28, 2001
DRAFT
WBS guided
By EIA 632
21
USC
C
S E
University of Southern California
Center for Software Engineering
Size Drivers (First Pass)
Size Drivers
Measure of:
Counted By:
# requirements
Functional requirements
Performance requirements
# interfaces
Interface requirements
# TPMs
# scenarios
Managerial requirements
Operational requirements
# modes
Operational requirements
# platforms
# algorithms
Operational requirements
Operational requirements
October 28, 2001
DRAFT
# shalls in System Spec
# Measures of Performance/
# Measures of Effectiveness
# interfaces needed to be
bounded via ICD’s/MOA’s
# of TPMs to be reported
# operational threads and/or
system level use cases
# operational modes to be
supported
# platforms to be supported
# of new algorithms that
system engineering must
develop to solve problem
22
USC
C
S E
University of Southern California
Center for Software Engineering
Cost Drivers (Initial List)
• Application factors
• Team factors
– Requirements understanding
– Architecture understanding
– Level of service
requirements
– Legacy transition complexity
– COTS assessment
complexity
– Platform difficulty
– Required business process
reengineering
– 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, 2001
DRAFT
23
USC
C
S
E
University of Southern California
Center for Software Engineering
Plan of Action & Milestones (Status)
Task
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Develop reference system
Define cost drivers
Define size drivers
Define effort scope
Finalize survey instrument
Send materials out for review
Hold net meeting/discuss results
Updates done/Delphi defined
Send Delphi out
Complete Delphi round
Update done based on results
Present results at annual review
Due Date
Responsible*
11//01/01
11/16/01
11/16/01
11/16/01
11/30/01
12/03/01
12/11/01
01/14/02
01/15/02
02/15/02
03/05/02
03/12/02
Reifer/Valerdi
Wheaton/Valerdi
Hafen/Thomas
Hafen/Thomas
Thomas/Valerdi
All focal points
All focal points
Reifer/Valerdi
All focal points
Reifer/Valerdi
Reifer/Valerdi
Valerdi
* Axelband/Boehm involved in all activities
October 28, 2001
DRAFT
24
USC
C
S E
University of Southern California
Center for Software Engineering
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
October 28, 2001
DRAFT
25