Systems of Systems Evalua/ons using SCRAM

Transcription

1 Systems of Systems Evalua/ons using SCRAM Jo Ann Lane University of Southern California Angela Tuffley RedBay Consul/ng, Australia Adrian Pitman Australian Defence Material Organisa/on smi Betsy Clark SoJware Metrics Inc. metrics.com

2 SoS Evalua/ons Overview Based on Schedule Compliance Risk Assessment Methodology (SCRAM) Developed by the Australian DMO Elaborated to support evalua/on of SoS capabili/es Strives to answer ques/ons such as What is the probability that a given SoS capability will be available by a certain date? What is the most probable date SoS capability will be available? What are the risks associated with this probability? April 2015 CSSE Annual Research Review 2

3 SCRAM Flow of Ac/vi/es Evaluate project compliance with current schedule Conduct root cause analysis using RCASS model Iden/fy possible remedia/on ac/vi/es Es/mate most likely schedule comple/on date: Monte Carlo schedule risk analysis Parametric es/ma/on to complete Present results to management for ac/on April 2015 CSSE Annual Research Review 3

4 SoS Considera/ons With SCRAM Rela/onships between SoS stakeholders and cons/tuent systems Cons/tuent system robustness and flexibility Level of SoS architecture maturity Asynchronous incremental cons/tuent system evolu/on Tracking SoS capability schedules Monte Carlo simula/ons for SoS April 2015 CSSE Annual Research Review 4

5 SoS Cons/tuent System Upgrades Over Time System A upgrade 1 System D upgrade System B and C upgrades System A upgrade April 2015 CSSE Annual Research Review 5

6 Evalua/ng SoS Schedules do we need to simultaneously support both the legacy system and system of interest here? System of interest Requirements Acquisition In-service Legacy system In-service do we need to support both the current in-service interface as well as the expected future interface in our system of interest? Interfacing system 1 In-service Interfacing system 2 Current in-service Planned upgrade in-service Interfacing system 3 Acquisition Planned upgrade in-service peer systems in parallel acquisitions need to exchange and agree interface documentation prior to the completion of the acquisition to allow sufficient time for development time! April 2015 CSSE Annual Research Review 6

7 Monte Carlo Simula/ons for SoS P(SoS) = P(cs 1 ) * P(cs 2 ) * P(cs 3 ) * * P(cs n )! April 2015 CSSE Annual Research Review 7

8 Common SoS Problems Affec/ng Schedule Lack of a[en/on to CS organiza/onal and technical issues Inability to track progress of SoS capability development Understanding CS limita/ons (e.g., CS priori/es vs. SoS priori/es, interoperability, fragile systems that are difficult to change) Immature technology or tech refresh coordina/on issues, especially those that may impact interoperability between systems Lack of planning for data/database conversions required for system upgrades Deployments using all or nothing approach rather than incremental rollout of capability parts Lack of integra/on and test planning/execu/on at the SoS level Impacts related to any required SoS level safety or security cer/fica/ons April 2015 CSSE Annual Research Review 8

9 SCRAM for MedFRS Example Medical First Responder SoS to provide continuous patient care from point of response to hospital/trauma care center! April 2015 CSSE Annual Research Review 9

10 MedFRS SCRAM Analysis Desired MedFRS SoS capability Incorpora/on of an Electronic Health Record (EHR) on MedFRS first responder placorm that is compa/ble with four regional hospitals Issues Want new capability within 6 months Interoperability Issues: Four regional hospitals/three different EHR COTS system Power and space issues on the first responder placorms New na/onal healthcare EHR standard may impact exis/ng EHR systems Compa/bility with other EHR systems not a high priority for hospitals Assump/on that future versions of EHR systems will be interoperable out of the box April 2015 CSSE Annual Research Review 10

11 MedFRS SCRAM Analysis (con%nued) SCRAM evalua/on Two op/ons evaluated: One team to implement sojware required to be interoperable with mul/ple EHR systems Two teams work in parallel to provide necessary interoperability Results of Monte Carlo simula/ons using 3- point es/mates 90% probability that two- team approach will result in desired capability with six months 50% probability that one- team approach will result in desired capability within six months Most probably schedule for one- team approach: 9 months April 2015 CSSE Annual Research Review 11

12 Conclusions and Future Work SoS master scheduling much more challenging compared to single system scheduling SCRAM must focus on both single system and SoS- level issues Process works well for directed and acknowledged SoS more work needed for collabora/ve SoS DMO SCRAM program developing materials to be[er support SoS capability SCRAMs (expected date: late 2015) April 2015 CSSE Annual Research Review 12