Date post: | 20-Dec-2015 |
Category: |
Documents |
View: | 215 times |
Download: | 0 times |
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
USC Annual Research Review - March 2006
University of Southern CaliforniaCenter 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
USC Annual Research Review - March 2006
University of Southern CaliforniaCenter 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
USC Annual Research Review - March 2006
University of Southern CaliforniaCenter 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 boxaround software development
Acquisition Program Goals
USC Annual Research Review - March 2006
University of Southern CaliforniaCenter 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 helpsdetermine the reasonableness of theproposed solution
Acquisition Program Goals
USC Annual Research Review - March 2006
University of Southern CaliforniaCenter 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 experiencedprogrammatic level acquisitionfailures related to softwaredevelopment
Acquisition Program Goals
USC Annual Research Review - March 2006
University of Southern CaliforniaCenter 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 specifyand operate many CMMI-AMprocess areas for the SPO
System Engineering and Architecting
USC Annual Research Review - March 2006
University of Southern CaliforniaCenter 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 SoftwareEstimates
System Engineering and Architecting
USC Annual Research Review - March 2006
University of Southern CaliforniaCenter 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
USC Annual Research Review - March 2006
University of Southern CaliforniaCenter 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
USC Annual Research Review - March 2006
University of Southern CaliforniaCenter 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
Systems
Software
Integration of System and Software Architectures
USC Annual Research Review - March 2006
University of Southern CaliforniaCenter 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
USC Annual Research Review - March 2006
University of Southern CaliforniaCenter 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
USC Annual Research Review - March 2006
University of Southern CaliforniaCenter 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 interactionOCD Focus on prototype development adds to the
SPO need to perform COTS/Reuse V&V
Experience using LeanMBASE
USC Annual Research Review - March 2006
University of Southern CaliforniaCenter 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
USC Annual Research Review - March 2006
University of Southern CaliforniaCenter 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 Review4. Continue development of system/
software integration tools and training
Way Ahead
USC Annual Research Review - March 2006
University of Southern CaliforniaCenter 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
USC Annual Research Review - March 2006
University of Southern CaliforniaCenter 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
USC Annual Research Review - March 2006
University of Southern CaliforniaCenter for Software Engineering
Backup
USC Annual Research Review - March 2006
University of Southern CaliforniaCenter 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
USC Annual Research Review - March 2006
University of Southern CaliforniaCenter 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
USC Annual Research Review - March 2006
University of Southern CaliforniaCenter 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.