1. USC Annual Research Review - March 2006 University of Southern California Center for Software Engineering Software Architecting On the Acquisition Side USC Annual Research Review 16 March 2006 DeWitt T. Latimer IV, CSDP PhD Student, USC

2. USC Annual Research Review - March 2006 University of Southern California Center for Software Engineering Outline Overview - Environment Acquisition Program Goals System Engineering and Architecting Software Architecting Integration of System and Software Architecture Experience using LeanMBASE Way Ahead Summary

3. USC Annual Research Review - March 2006 University of Southern California Center for Software Engineering 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

4. USC Annual Research Review - March 2006 University of Southern California Center for Software Engineering 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 box around software development Acquisition Program Goals

5. USC Annual Research Review - March 2006 University of Southern California Center for Software Engineering 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 helps determine the reasonableness of the proposed solution Acquisition Program Goals

6. USC Annual Research Review - March 2006 University of Southern California Center for Software Engineering 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 experienced programmatic level acquisition failures related to software development Acquisition Program Goals

7. USC Annual Research Review - March 2006 University of Southern California Center for Software Engineering 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 specify and operate many CMMI-AM process areas for the SPO System Engineering and Architecting

8. USC Annual Research Review - March 2006 University of Southern California Center for Software Engineering 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 Software Estimates System Engineering and Architecting

9. USC Annual Research Review - March 2006 University of Southern California Center for Software Engineering 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?) Software Architecting

10. USC Annual Research Review - March 2006 University of Southern California Center for Software Engineering 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 Software Architecting

11. USC Annual Research Review - March 2006 University of Southern California Center for Software Engineering 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 System s Software Integration of System and Software Architectures

12. USC Annual Research Review - March 2006 University of Southern California Center for Software Engineering 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 Integration of System and Software Architectures

13. USC Annual Research Review - March 2006 University of Southern California Center for Software Engineering 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 Experience using LeanMBASE

14. USC Annual Research Review - March 2006 University of Southern California Center for Software Engineering 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 interaction OCD Focus on prototype development adds to the SPO need to perform COTS/Reuse V&V Experience using LeanMBASE

15. USC Annual Research Review - March 2006 University of Southern California Center for Software Engineering 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 Experience using LeanMBASE

16. USC Annual Research Review - March 2006 University of Southern California Center for Software Engineering 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 Review 4.Continue development of system/ software integration tools and training Way Ahead

17. USC Annual Research Review - March 2006 University of Southern California Center for Software Engineering Summary Overview - Environment Acquisition Program Goals System Engineering and Architecting Software Architecting Integration of System and Software Architecture Experience using LeanMBASE Summary

18. USC Annual Research Review - March 2006 University of Southern California Center for Software Engineering 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

19. USC Annual Research Review - March 2006 University of Southern California Center for Software Engineering Backup

20. USC Annual Research Review - March 2006 University of Southern California Center for Software Engineering 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

21. USC Annual Research Review - March 2006 University of Southern California Center for Software Engineering 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

22. USC Annual Research Review - March 2006 University of Southern California Center for Software Engineering 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.