Presentation is loading. Please wait.

Presentation is loading. Please wait.

Relationship-Oriented Architecture: A New Paradigm in System Engineering Tobin Anthony, Ph.D. Christopher Costello Shawnee Heritage Government Solutions.

Similar presentations


Presentation on theme: "Relationship-Oriented Architecture: A New Paradigm in System Engineering Tobin Anthony, Ph.D. Christopher Costello Shawnee Heritage Government Solutions."— Presentation transcript:

1 Relationship-Oriented Architecture: A New Paradigm in System Engineering Tobin Anthony, Ph.D. Christopher Costello Shawnee Heritage Government Solutions July 10, 2007

2 Agenda  Introduction  The Problem  Relationship-Oriented Architecture  Example  Case Studies

3 Introduction  Tobin Anthony, Ph.D. 12 yrs with NASA GSFC 12 yrs with NASA GSFC 10 yrs in aerospace and defense systems 10 yrs in aerospace and defense systems  Christopher Costello 19 yrs in aerospace and defense systems 19 yrs in aerospace and defense systems 12 yrs in small business engineering12 yrs in small business engineering  Shawnee Heritage Government Sol’n Majority-owned by Shawnee Indian tribe Majority-owned by Shawnee Indian tribe Native-American 8(a) exemption pending Native-American 8(a) exemption pending Principals in business since 2003 Principals in business since 2003

4 ROA Concept  Simple Is Better Than Complex  A Picture Is Worth 1000 Words

5 Micromanagement Diagnosis: Chaos The Problem: Inefficient management of design cycle leading to cost & schedule overrun The Cure: Develop a system architecture to guide system design But you end up with… A Tool Expert A “Key Man ” Poor Communication

6 SE 2 Typical Program Office Program Manager System Engineer/ DPM Subsystem 1Subsystem 2Subsystem 3 Manages Effort Interacts with Customer Responsible for glue between subsystems Manages requirement process Subsystem 4Subsystem 5 Subsystem 6Subsystem 7Subsystem 8 How does the SE manage all these subsystems?How does the SE track the progress of the design? SE 1SE 3 Only one engineer understands the entire system

7 ROA Solves The tool expert by… Being tool independent The key man by… Simplifying the process Poor communication by… Providing illustrative products Micromanagement by… Defining architectural relationships

8 What is ROA?  History Developed by authors for use on UAV ground system program Developed by authors for use on UAV ground system program Honed by years of frustration seeing programs “winging it” Honed by years of frustration seeing programs “winging it”  Concept Database, not tool-oriented Database, not tool-oriented Simple means of illustrating system by emphasizing relationships between elements Simple means of illustrating system by emphasizing relationships between elements

9 ROA Concept - Simplicity  Rigorous, but not rigor mortis Define a core set of system products Define a core set of system products Illustration of the system architectureIllustration of the system architecture Minimal set to document and communicate the design Minimal set to document and communicate the design  Engineer identifies systems elements and defines the relationship between them  Examples of system elements are: Requirements Requirements Functions Functions Components (HW or SW) Components (HW or SW) Test procedures Test procedures Development milestones Development milestones Relationships Between Elements Determine How the System Is Used & Built to Meet Requirements

10 ROA Concept – 1000 Words

11 Glue the System Together Top Level Model Requirements Interfaces State Transitions Use Cases Test Test Procedures Schedule Any Element

12 ROA: A Simple Example System Requirement: Take a Picture Perform Still Imaging Perform Image Transfer Perform Store ImagePerform Frame ImagePerform Image Capture

13 ROA: A Simple Example System Requirement: Frame Image (derived) Perform Frame ImageZoom TargetPerform Site TargetPerform Focus TargetTarget via View FinderTarget via LCD

14 ROA: Camera Development System Requirements: Capture, Store Image, Site Target (derived) Perform Store ImagePerform Image CaptureSingle Image CaptureMultiple Image CaptureRetrieve Image from Focal Plane Write Image to FlashPerform Site TargetTarget via View FinderTarget via LCD Perfectly Engineered! Marketing Really Wanted Good News! No dependencies so nothing else effected Bad News! Not enough room for a lot of flash memory! Not all the bells and whistles but it will sell!

15 ROA: TLM/Req/WBS Consistency Perform Store ImagePerform Image CaptureSingle Image CaptureMultiple Image CaptureRetrieve Image from Focal Plane Write Image to FlashPerform Site Target Target via View Finder Target via LCD Perform Still Imaging Perform Image Transfer WBS & IPT Structure Matches Architecture! To Multiple Levels!!! One Architecture Providing the Glue for All Management and Engineering Efforts!

16 Benefits of ROA  Relationships between elements are defined Enables evaluation of effects of changes to elements Enables evaluation of effects of changes to elements  System design can be linked with management activities WBS WBS IPT structure development IPT structure development EVMS EVMS  Elements are linked to requirements Requirements without elements Requirements without elements Unverified requirementsUnverified requirements Elements without requirements Elements without requirements BloatwareBloatware

17 Benefits of ROA  Software Tool Independent Can develop architecture in any software environment Can develop architecture in any software environment CoreCore DOORSDOORS Requisite ProRequisite Pro System ArchitectSystem Architect MS OfficeMS Office  Requires database back-end Provides link between individual elements and management artifacts Provides link between individual elements and management artifacts Database can be simple spreadsheet Database can be simple spreadsheet

18 Case Studies  Bringing UAV Ground System to CDR  Forensic Analysis of Safehold Mode Software

19 Completing Design: Challenges  Behind schedule Engineering signed up to unrealistic schedules Engineering signed up to unrealistic schedules Management did not understand engineering needs Management did not understand engineering needs  Management insight into progress limited Mgmt to Engineering: “You’re Gold-Plating!” Mgmt to Engineering: “You’re Gold-Plating!” Lack of trust through lack of communication Lack of trust through lack of communication  Could not get to CDR Customer and management did not agree on level of detail Customer and management did not agree on level of detail System engineering not ready in customer opinion – poor CPAR System engineering not ready in customer opinion – poor CPAR

20 SELECT AIRSPEED PERFORM VECTOR FLIGHT MODE PERFORM VEHICLE FLIGHT MODE PERFORM MISSION PLAN FLIGHT MODE SELECT MISSION PLAN FLIGHT MODE SELECT VECTOR FLIGHT MODE SELECT ALTITUDESELECT COURSESELECT CLIMB RATE COMMAND PLAN AIRSPEED COMMAND PLAN ALTITUDE COMMAND PLAN COURSE COMMAND PLAN CLIMB RATE COMMAND FLIGHT PARAMETERS DISPLAY PLAN AIRSPEED DISPLAY PLAN ALTITUDE DISPLAY PLAN COURSE DISPLAY PLAN CLIMB RATE DISPLAY AIRSPEED DISPLAY ALTITUDE DISPLAY COURSE DISPLAY CLIMB RATE COMMAND FLIGHT MODE Why We Couldn’t Get to CDR  Airspeed, altitude, course are independent of mode Built separately for each mode. Built separately for each mode.  This model was given to different developers Each model was implemented differently Each model was implemented differently Very difficult to integrate!!! Very difficult to integrate!!!  Not clear how this function fits into the entire system

21 Completing Design: Hierarchical Functional Decomposition PERFORM VEHICLE COMMAND & CONTROL PERFORM PREFLIGHT VEHICLE PERFORM LAUNCH VEHICLE PERFORM VEHICLE FLIGHT MODES PERFORM START VEHICLE SESSION PERFORM VEHICLE MISSION PLANNING Group Common Functionality And Identify Dependencies

22 PERFORM VECTOR FLIGHT MODE PERFORM VEHICLE FLIGHT MODE PERFORM MISSION PLAN FLIGHT MODE SELECT MISSION PLAN FLIGHT MODE SELECT VECTOR FLIGHT MODE PERFORM VEHICLE FLIGHT CONTROL COMMAND FLIGHT MODE DISPLAY FLIGHT MODE Completing Design: Consolidate Common Functionality

23 SELECT AIRSPEED PERFORM VEHICLE FLIGHT CONTROL SELECT ALTITUDESELECT COURSESELECT CLIMB RATE COMMAND FLIGHT PARAMETERS DISPLAY FLIGHT PARAMETERS DISPLAY AIRSPEED DISPLAY ALTITUDE DISPLAY COURSE DISPLAY CLIMB RATE Completing Design: Detail-level Use Case Definition Only building one vehicle control module for multiple flight modes Each function can be linked to a hardware component

24 Completing the Design: ROA Solution  Used the minimum set of artifacts Requirements - what we have to do Requirements - what we have to do Top-level model (glue) – how we are going to do it Top-level model (glue) – how we are going to do it Interface diagram – who we need to interface to Interface diagram – who we need to interface to State diagram – when things are getting done State diagram – when things are getting done Sequence diagram – how the system behaves Sequence diagram – how the system behaves  ROA Design was implemented in MS Office framework Used Word, PowerPoint, Excel, and Access Used Word, PowerPoint, Excel, and Access Files were under CM Files were under CM Accessible by management, engineering and customerAccessible by management, engineering and customer Everyone Working to the Same Goal, Focused on Objectives

25 Next Phase of Program was Bid and Won Using Architecture Artifacts to Show Enhancements! Completing Design: Results  Artifacts became management tool Earned-value was related to each capability in TLM Earned-value was related to each capability in TLM Mgmt supported engineers when they had insight to progressMgmt supported engineers when they had insight to progress Customer gained confidence as they had insight to designCustomer gained confidence as they had insight to design  Successful CDR Customer engineers defended our design to their management Customer engineers defended our design to their management Highest CPAR rating Highest CPAR rating  Reduced build and test schedule because architecture was well-conceived and communicated!

26 Forensic Engineering: Challenges  Approached customer on ROA use Customer liked methodology but wanted to see it applied to real problem Customer liked methodology but wanted to see it applied to real problem  Safehold Software flagged as concern Contractor identified software robustness as potential issue Contractor identified software robustness as potential issue Concerned about algorithm “sinkholes”Concerned about algorithm “sinkholes” Recommended full-scale redevelopmentRecommended full-scale redevelopment Software had no documented design Software had no documented design Algorithm document existedAlgorithm document existed No knowledge of functional dependenciesNo knowledge of functional dependencies  Large Red Team assigned to study problem

27 Forensic Engineering: ROA Solution  ROA solution effort was two-pronged Build top-level model (TLM) Build top-level model (TLM) Link functions to requirements Link functions to requirements Done as a parallel effort to Red team Done as a parallel effort to Red team  TLM identified functional interfaces as the software was built  ROA team scoured requirements and linked TLM elements to relevant requirements Developed an Illustration of the Software Design

28 Forensic Engineering: Results  No need to redesign software Some areas of improvement identified Some areas of improvement identified  Identified six requirements not being met by design  Red team came to same conclusion Relied on software and hardware-in-the-loop testing Relied on software and hardware-in-the-loop testing Thorough, time-consuming, but not very broadThorough, time-consuming, but not very broad Delivered collection of opinions – no artifacts Delivered collection of opinions – no artifacts ROA: 1.5 FTEs, 6 Weeks, Design Artifacts Red Team: ~15 FTEs, 4 Months, Opinion

29 Future  Develop ROA cookbook Provide a standards-based means of publishing methodology Provide a standards-based means of publishing methodology  Software tool Develop MS Office-based toolset allowing ROA development Develop MS Office-based toolset allowing ROA development  Develop interfaces to external systems Software development Software development Earned Value Management System Earned Value Management System Toolsets to accompany established requirements software Toolsets to accompany established requirements software

30 Summary  ROA enables the system engineer to become the system designer  ROA provides a means of documenting system design  ROA models lead to good implementation


Download ppt "Relationship-Oriented Architecture: A New Paradigm in System Engineering Tobin Anthony, Ph.D. Christopher Costello Shawnee Heritage Government Solutions."

Similar presentations


Ads by Google