Packageability as an ‘Ility’ for Systems Engineering

IEEE Transactions on Engineering Management, 2018

The terms module and modularity are not part of the technical taxonomy in any of the systems engineering standards, which do not regard a module as a part of the formal system breakdown structure. In this paper, we redefine the term module as a unit composed of a set of components with a set of specific interfaces. This unit serves one or more purely nonfunctional goals, such as flexibility, evolvability, manufacturability, testability, and maintainability. According to this definition, a configuration item, a subsystem, an assembly, a subassembly, or a component can all be regarded as modules as they can serve nonfunctional goals. The important assertion here is that a module's boundaries do not necessarily coincide with those dictated by the functional or spatial system decomposition and hierarchy. The aim of this paper is to lay the foundations for the future standardization of various engineering design processes based on modularity for nonfunctional benefits. A clear definition of the terms module and modularity can assist systems designers and developers to optimize the value of a modular system. This research highlights the present inconsistencies in the field of modular system design and puts forward some critical questions, which will shape the future research into this field.

Deployment requirements describe the precise, desired configuration of a software system. They relate the system's non functional requirements to its architecture, providing a basis for making decisions about design trade-offs in terms of the resulting system's non functional properties. The purpose of this position paper is to propose a research direction towards developing an approach for reasoning about deployment decisions. Its main objective is to quantitatively evaluate and select between different potential architecture solutions in order to shorten customer time-to-value and increase satisfaction. In this paper we analyze the relationship between deployment requirements and non-functional properties, and discuss work in progress of developing a deployment-based methodology for evaluating software architecture.

INCOSE International Symposium

The objective of this study was to analyse the development of radar systems in a government research and development environment from a systems engineering perspective and identify which, if any, systems engineering tools and methods are used. The practical portion of the research took a mixed methods approach where both qualitative and quantitative data collection techniques were used. The quantitative portion of the research assessed aspects of systems engineering in the context of the research environment the participant is working in using categories of the Systems Engineering Capability (SECM) EIA/IS 731 model. Analysis of the data indicated that, in principle, systems engineering methods and tools are supposed to be applied in this research area, however this was not done consistently across projects. Some of the challenges in this research area included eliciting clear customer requirements, resource constraints and budget and schedule overruns. Recommendations were made based on the findings from a systems engineering perspective. Research Design and Methodology Research begins with the formulation of the research question(s) which strongly influence the rest of the research process including methodology, data collection and analysis methods (Wohlin & Aurum 2015). These methods may be qualitative, such as semi-structured interviews or participant observation, or quantitative such as surveys (Zahle 2018). Case studies provide an analysis that is in-depth and focussed on one or few cases and can give insight into causality, however it can be argued that the degree to which the results can be applied to an outside environment is unknown (Elm et al. 2008). Research into systems engineering is growing, hence data gathering tools such as surveys will be increasingly used (Smartt & Ferreira 2013). The data collected from these surveys are useful in understanding, for instance, the effect of using best practice systems engineering methods on project performance, or building a business case for using these methods (Smartt & Ferreira 2013). An explanatory mixed methods design was used where an initial quantitative phase was followed up by a qualitative phase. The results of the quantitative phase was used as a framework to analyse the data collected in the qualitative phase (Borrego, Douglas & Amelink, 2009). Research Instrument An online questionnaire was used for the quantitative portion of the practical research. The questionnaire was used to assess the perspective of team members on the methods and tools used during various radar system development projects they have been involved in. These experimental radar systems are intended primarily for safety and security.

Communications of the ACM, 1982

Subprogram packages are groups of related subroutines used to extend the available facilities in a programming system. The results of developing several such packages for various applications are presented, with a distinction made between external and internal design criteria— what properties packages should offer to their users and the guidelines designers should follow in order to provide them. An important issue, the design of reusable software, is thus addressed, and the concept of abstract data types proposed as a desirable solution.

INCOSE International Symposium, 2001

The emphasis on utilizing commercial products/technologies to develop modern complex systems and to upgrade legacy systems has yielded relatively immediate returns in terms of reduced acquisition time and cost. In this context, examples of complex systems include weapon systems, telecommunication systems, train control systems. Such systems are generally characterized as being information and knowledge intensive, distributed, multifunctional, and software intensive.Prudent introduction and application of commercial technologies and products in the design and development of C4ISR systems has reversed the traditional pattern of increasing system acquisition costs. This is reflected in Figure 1 for four functionally equivalent systems. The same reversal of trends has also been realized during the system production phase. These, relatively short term benefits (in terms of reduced development and production cost) notwithstanding, unique challenges exist relative to the on‐going evolution...