• Language: A set of syntax and semantics
• Metamodel: A description of a model
• Method: Techniques for performing a task. “HOW” it needs to be done
• Methodology: Collection of related processes, methods and tools
• Process: A logical sequence performed to achieve a particular objective. “WHAT” needs to be done
• Tool: An instrument, when applied with the correct method, can enhance the efficiency of a task

• Waterfall
• Spiral
• “V” Model

DoD

1. Concept Refinement
2. Technology Development
3. System Development & Demonstration
4. Production & Deployment
5. Operations & Support

NASA

1. Concept Study
2. Concept Development
3. Preliminary Design
4. Final Design
5. Fabrication, Assembly and Test
6. Operations & Sustainment
7. Disposal

ISO 15288

1. Concept
2. Develop
3. Production
4. Operate
5. Support
6. Retirement

Harmony-SE takes a use case approach to modeling a system. Emphasis is on use of sequence diagrams and definition of operations and interfaces. Increments are use case based.

Methodology is available here. Methodology captured in a IBM Rational Harmony Deskbook Release 3.1.2 (2010).

The Harmony Process is split between “Harmony for Systems Engineering” and “Harmony for Embedded RT Development”. As you can see from the above figure the former focuses on the downwards side of the Vee development life cycle whilst the latter focuses on the upwards trajectory.

• Identify / derive required system functionality
• Identify associated system states and modes
• Allocate system functionality / modes to a physical architecture

1. Requirements Analysis
   1. Requirements Capture
   2. Definition of System Use Cases
2. System Functional Analysis
   • Main output is required operations to meet black-box use case scenarios
   • Use case is translated into an executable model and the underlying system requirements verified through model execution
3. Design Synthesis
   1. Architectural Analysis (Trade Study)
      • Elaborate a concept for implementation of identified operations based on parametric analysis
   2. Architectural Design
      • Allocated System Operations
      • Allocation is verified through model execution
      • After verification then architectural design may be analyzed with regard to performance analysis (reference previous measure of effectiveness metrics)
   3. Detailed Architectural Design
4. Hardware / Software Design

Closely follows the recursive nature of the Vee life cycle development approach. Adopts Integrated Product Development (IPD) team.

To view the model download the zip file, extract files and then select oosem_process_baseline_yyyymmdd/index.htm

Once the html model is loaded click on “Specify and design system” and then you will see the OOSEM process chart. As of writing the latest version is baselined as OOSEM Process Baseline 1/2020.

• Capture and analysis or requirements and design information to specify complex systems
• Integration with object-orientated software, hardware and other engineering methods
• Support for system-level reuse and design evolution

1. Set up model
2. Analyze stakeholder needs
   1. Captures as-is state, limitations and potential improvement.
   2. Analyzed using causal analysis techniques to determine limitations therefore derive mission requirements for the to-be system
   3. Mission requirements are provided as
      • Mission objectives
      • Measure of Effectiveness
      • Top-level use case and scenarios
3. Design system requirements
   • System is modeled as a black box.
   • Scenarios are modeled as activity diagrams with swim lanes
   • Requirement change is evaluate as risk and flexibility is built in
4. Define logical architecture
   • Decompose and partitioning the system into logical components that interact to satisfy system requirements
   • With a logical architecture the system design is more resilient to requirements change and is technology neutral
5. Synthesize candidate allocated architectures
   • Each logical component is mapped to a system node to address how the functionality is distributed
   • Requirements for each system element are traced to system requirements
6. Optimize and evaluate alternatives
   • Parametric models are used to analyze and optimize performance across a range of criteria (safety, reliability, cost)
   • Criteria and weightings are traceable to requirements and measure of effectiveness
   • Monitor Technical Performance Measures
   • Identify potential risks
7. Validate and verify system
   • Development of plans, procedures and methods
   • System level use cases, scenarios are primary inputs to the development of test cases and associated verification procedures

It was not easy to find a document that lays out what RUP SE is about. I found "Rational Unified Process" Rational Software White Paper TP026B, Rev 11/01 but it is a generalization of RUP SE.

Eventually found the below source material:

• Cantor M, “RUP SE: The Rational Unified Process for Systems Engineering” IBM Rational Software (2001). Accessed on September 8th, 2020 here
• Cantor M, “Rational Unified Process for Systems Engineering, Part 1: Introduction RUP SE Version 2.0” IBM Rational Software (2003). Accessed on September 8th, 2020 here
• Cantor M, “Rational Unified Process for Systems Engineering, PART II: Distinctive Features” IBM Rational Software (2001). Accessed on September 8th, 2020 here
• Cantor M, “Rational Unified Process for Systems Engineering, Part II: System architecture” IBM Rational Software (2003). Accessed on September 8th, 2020 here
• Cantor M, “Rational Unified Process for Systems Engineering, Part III: Requirements analysis and design” IBM Rational Software (2003). Accessed on September 8th, 2020 here

Based on the above SUP SE is baselined as Version 2.0

• Follow industry standard definition of systems
  • Adopt blackbox and whitebox representation
  • Blackbox representation is described in System Specification
  • Whitebox representation is described in System Architecture

• Apply the RUP framework to systems development
  • Lifecycle - focus on removing risks by adopting phases (Inception, Elaboration, Construction, Transition)
  • Iterations - Iterative development process
  • Disciplines - RUP takes into account the following disciplines
    • Business Modeling
    • Requirements
    • Analysis & Design
    • Implementation
    • Test
    • Deployment
    • Configuration & Change Management
    • Project Management
    • Environment

• Extend the RUP 4+1 architectural model into the RUP SE model framework
  • RUP SE provides for the following viewpoints (can be extended to others)
    • Role (RUP SE calls this 'Worker') - concerned with roles and responsibilities
    • Logical - concerned with logical decomposition
    • Physical - concerned with physical decomposition
    • Information - concerned with how information is stored and processed
    • Process - concerned with threads of control
  • RUP SE sets out four model levels
    • Context - system and its actors
    • Analysis - system partitioning in each viewpoint to establish conceptual approach
    • Design - realization of the analysis level
    • Implementation - realization of design level
• Employ UML as modeling language
• Provide tool assets - essentially maintaining a plug in to IBM's Rational Software
• Maintain all model levels as a program asset - essentially maintaining traceability of low fidelity and high fidelity systems

1. Start with Use Cases, i.e. how the system delivers value to / responds to Actors
2. Treat system as a blackbox which has measures of effectiveness / budgets to meet Actor's need
3. Develop whitebox representation of the system of how it will meet the operations defined by the blackbox representation
   1. RUP SE has Locality and Process as attributes of the whitebox representation. Locality is where the operation is hosted, Process is what executes the operation.
4. Specify subsystem use cases.
5. Visualize interaction of Actor with Process with a sequence diagram. Helps to identify whether processes can be combined if significant interaction between them.
6. Visualize interaction of Actor with Localities with a sequence diagram. Shows dataflows between assets, helping to define communication protocols.
7. Rinse and repeat.