Fewer Mistakes on the First Day: Architectural Strategies and Their Impacts on Acquisition Outcomes

Tenth Annual Acquisition Research Symposium Acquisition ManagementExcerpt from the Proceedings of the Tenth Annual Acquisition Research Symposium Acquisition ManagementNaval Postgraduate School Acquisition Research ProgramPrepared for the Naval Postgraduate School, Monterey, CANaval Postgraduate School Acquisition Research ProgramApproved for public release; distribution is unlimited

Zen in the Art of Cost Estimation

Engineering cannot wait until all phenomena are explained. Engineers may work effectively, often for centuries, with heuristics. This paper provides over thirty heuristics that have been inspired by the development and application of a systems engineering cost estimation model. The objective of this paper is to present such heuristics in a simple manner so that they can benefit those that develop, calibrate, and use cost models

A Survey on the Interplay between Software Engineering and Systems Engineering during SoS Architecting

Background: The Systems Engineering and Software Engineering disciplines are highly intertwined in most modern Systems of Systems (SoS), and particularly so in industries such as defense, transportation, energy and health care. However, the combination of these disciplines during the architecting of SoS seems to be especially challenging; the literature suggests that major integration and operational issues are often linked to ambiguities and gaps between system-level and software-level architectures. Aims: The objective of this paper is to empirically investigate: 1) the state of practice on the interplay between these two disciplines in the architecting process of systems with SoS characteristics; 2) the problems perceived due to this interplay during said architecting process; and 3) the problems arising due to the particular characteristics of SoS systems. Method: We conducted a questionnaire-based online survey among practitioners from industries in the aforementioned domains, having a background on Systems Engineering, Software Engineering or both, and experience in the architecting of systems with SoS characteristics. The survey combined multiple-choice and open-ended questions, and the data collected from the 60 respondents were analyzed using quantitative and qualitative methods. Results: We found that although in most cases the software architecting process is governed by system-level requirements, the way requirements were specified by systems engineers, and the lack of domain-knowledge of software engineers, often lead to misinterpretations at software level. Furthermore, we found that unclear and/or incomplete specifications could be a common cause of technical debt in SoS projects, which is caused, in part, by insufficient interface definitions. It also appears that while the SoS concept has been adopted by some practitioners in the field, the same is not true about the existing and growing body of knowledge on the subject in Software Engineering resulting in recurring problems with system integration. Finally, while not directly related to the interplay of the two disciplines, the survey also indicates that low-level hardware components, despite being identified as the root cause of undesired emergent behavior, are often not considered when modeling or simulating the system. Conclusions: The survey indicates the need for tighter collaboration between the two disciplines, structured around concrete guidelines and practices for reconciling their differences. A number of open issues identified by this study require further investigation

House of Project Complexity – Understanding Complexity in Large Infrastructure Projects

This paper describes our conceptualization of complexity in Large Infrastructure Projects (LIPs). Since complexity itself is an emergent concept that is hard to pin down, we focus on the relationship between various project features and, particularly, properties associated with complexity such as difficulty, outcome variability and non-linearity, and (non) governability. We propose a combined structural and process-based theoretical framework for understanding contributors to complexity in this particular substantive context – the “House of Project Complexity” (HoPC). The HoPC addresses the impact of inherent technical and institutional project features, the process of project architecting, the structural relationship between various project features and these “designed” constructs, and the emergence of risks and life-cycle properties (‘ilities’). The HoPC is first applied to two trial samples and then to the main data set of detailed case studies of infrastructure projects prepared for the IMEC study. We believe that the “House of Project Complexity” can be generally extended to other substantive contexts that exhibit similar properties as Large Infrastructure Projects (LIPs), in the extractive industries, large manufacturing projects, or other industrial megaprojects

Workshop Report Air Force/LAI Workshop on Systems Engineering for Robustness

Workshop repor

Status of Department of Defense Architecture Framework (DoDAF) Implementation within the Aeronautical Systems Center (ASC)

The purpose of this research was to identify the current status of the use of the Department of Defense Architecture Framework (DoDAF) systems architecture products within the Aeronautical Systems Center (ASC) program offices. There are regulatory requirements dictating the creation of DoDAF products as annexes to programmatic documentation, such as the Joint Capabilities Integration Development System (JCIDS) requirement for systems architectures as annexes for acquisition milestone decision documentation. In addition, the DoDAF itself identifies several products as being highly applicable for the development of acquisition strategies. This thesis investigated the use of systems architectures, and particularly DoDAF products, within the context of Air Force weapon systems acquisitions, as represented by ASC. The research indicated two conclusions: while programs required to follow the new acquisition processes are doing so, very few are employing systems architectures systematically, and at this point, at least within ASC, the benefits to acquisition program management personnel derived from an architectural context are not yet being realized. These conclusions result in several recommendations to ASC, the DoDAF Working Group, and the systems engineering community in general in terms of making systems architectures the standard way of doing business within Air Force weapon system acquisitions efforts. Specific procurement success stories are documented, including the Airborne Electronic Attack (AEA), the B-2 Group, and the Tanker Modernization Squadron