USC Annual Research Review - March 2006 University of Southern California Center for Software Engineering Software Architecting On the Acquisition Side

USC Annual Research Review - March 2006

University of Southern CaliforniaCenter for Software Engineering

Software ArchitectingOn the Acquisition Side

USC Annual Research Review16 March 2006

DeWitt T. Latimer IV, CSDPPhD Student, USC



Outline

• Overview - Environment• Acquisition Program Goals• System Engineering and Architecting• Software Architecting• Integration of System and Software Architecture• Experience using LeanMBASE• Way Ahead• Summary



Overview - Environment

• Goal: Determine the type of software architectures needed for a system development in the concept exploration phase (Phase A of the Space Systems Acquisition Life Cycle)

• Based on current military satellite system acquisition

• Acquiring System Program Office (SPO) has dedicated software staff available to matrix to various functions throughout the SPO

Overview - Environment



Acquisition Program Goals

• Understand total system concept sufficiently to– Establish a credible budget – Establish a credible schedule– Select development contractor capable of delivering system

• Mitigate software acquisition-related issues– “Software-Intensive System”– History of software acquisition difficulties

Acquisition may only see a black boxaround software development




Issues in Selecting a Source

Selecting a source needs to include identifying issues such as capability to perform and reasonableness of proposed solution

SPO personnel need to do research in advance to know what is “reasonable” to be able to differentiate!!

Knowing the architecture helpsdetermine the reasonableness of theproposed solution




Software Acquisition Environment Issues

• Criteria for being software intensive– Nearly 100% of system functions will be

• implemented by software• largely depend on the performance of underlying software• or require software connectors for enterprise integration

– Larger scale than normal for military space systems• Numerous recent military space

systems have experiencedprogrammatic level acquisitionfailures related to softwaredevelopment




System Engineering and Architecting

• System Engineers develop the system architecture which defines the operational environment boundaries– Requirements Development– Requirements Management– Configuration Management– Decision Analysis and Resolution– Product Quality Assurance– Risk Management– Validation and Verification

System Engineers specifyand operate many CMMI-AMprocess areas for the SPO




DoDAF Issues

Utilizing the DoD Architectural Framework (DoDAF), the number of elaborations that take place from the OPSCON does not typically expose all software developmental items at the SPO-level during Phase A

DoDAF Credible SoftwareEstimates




Software Architecting

• Software architecture has been identified to answer 3 key questions– Completeness of Software Estimates in System

Estimate

– COTS/Reuse Assumption Verification and Validation

– Enterprise Integration Risk Reduction(e.g. Do the requirements we’re giving the developers match

with enterprise evolution goals and current enterprise requirements?)




Issues with Software Architecting

• Typical software architecting products require extensive elaboration at the developmental level

• CASE tools tend to be expensive to acquire and require expensive training to utilize properly

• CASE tools are not standard between satellite vendors

• The SPO has decided to not standardized on a CASE tool and wait for the selection of a single source closer to the design phase (Phase B) – Due to desire to keep multiple contractors open who use

different tools and the cost to acquire and train SPO staff – SPO decided to use a LeanMBASE method to document

software architecture activities at the conceptual level




Integration of System and Software Architectures

• System Engineers provide– System Architecture with

requirements flowed to various system elements

– Work Breakdown Structure

• Software Architects and Engineers provide– Software Architecture– Software component

estimates

Systems

Software




Evolving Integration Solution

Developing an intermediate model– Based on IDEF0– Enables traceability by allowing further elaboration beyond

DoDAF limits– Not yet software specific

Developing checklists and training materials for SPO personnel to be able to ensure changes in either the system or software architectures are flowed to the other (model coherence)

However, this necessitates having a specific software architecture product to specify methods of traceability – driving our selection of LeanMBASE




Experience using LeanMBASE

Selection rational for LeanMBASE for the software architect:– Chief software engineer’s familiarization with model – No direct cost was associated with usage

Initiated in Dec 2005, the software architecture team is approaching a LCO (Life-Cycle Objective) review in the April timeframe




Positive Experiences Using LeanMBASE

Operational Concept Description (OCD)– Maps fairly directly to systems engineering products – Concisely captured goals and scope of software

architecture activity– Fit into CMMI-AM based process environment

Comprehensive document format – Enabled quick reviews by software experts– Enabled reviews by non-software staff– Established span of authority for software architect

without extensive interactionOCD Focus on prototype development adds to the

SPO need to perform COTS/Reuse V&V




Problems with LeanMBASE Approach

System and Software Requirements Definition (SSRD) Mostly redundant with normal system engineering products– Since software acquisition personnel are tightly integrated with

the systems engineers, this product may be unnecessary

System and Software Architecture Description (SSAD) required extensive tailoring– Completely removed technology specific section of SSAD

(section 4)– Technology independent section (SSAD 3) requires more

information than an acquirer really needs to know to establish methods of determining credibility of developer estimates




Way Ahead

1. Eliminate SSRD– Provide mapping document to guide reviewer where items from

the SSRD would be answered from other sources

2. Continued evolution of SSAD and other LeanMBASE products– Lifecycle Plan in use– Feasibility Rationale Document

not yet in use

3. Progress to LCO Review4. Continue development of system/

software integration tools and training

Way Ahead



Summary

• Overview - Environment• Acquisition Program Goals• System Engineering and Architecting• Software Architecting• Integration of System and Software

Architecture• Experience using LeanMBASE• Summary



Thanks To

Prof Boehm – advisor and mentor

Mr. Sisti, Mr. Berg, Mr. Marz – SPO staff providing management, oversight and project sponsorship

Mr. Whitson – Aerospace systems engineering support and domain expert

Mr. Goldhirsh – SPO software architect and willing guinea pig



Backup



Acronyms

• DoDAF – Department of Defense Architectural Framework

• LCO – Lifecycle Objectives• MBASE – Model Based Software Engineering• OCD – Operational Conception Description• SPO – System Program Office• SSAD – System and Software Architecture

Description• SSRD – System and Software Requirements

Definition• V&V – Verification and Validation



References

• LeanMBASE Guidelines Version 1.4

• CMMI Acquisition Module (CMMI-AM), Version 1.0

• “COTS-Based Systems…”, Adams Eslinger, Aerospace TOR SMC-TR-01-19

• “Project Breathalyzer”, SPMN

• NSS 03-01



Bio

DeWitt Latimer is currently a PhD student in Computer Science at the University of Southern California studying under Prof Barry Boehm and Prof Guarav Sukhatme investigating the nature of acquiring autonomous robotic systems. DeWitt is also currently serving in the USAF as the chief software engineer for a satellite system in the concept development phase where he is certified to level II in Systems Engineering. He earned is MS degrees in Robotics (2001) and Civil Engineering (2002) at Carnegie Mellon University. He is a member of the IEEE, ACM, ASCE, and AFCEA and was awarded the CSDP credentials from the Computer Society.

Documents

USC Annual Research Review - March 2006 University of Southern California Center for Software Engineering Software Architecting On the Acquisition Side