bluuebunny/crossref_metadata_2025_split huggingface dataset:
11.1.1 An Approach to a Network Centric Product Development System
Authors: Dagli  , Miller Ann , Abbott Russell 
Published: November 2014

AbstractCurrent product development architectures range from vertically stove‐piped organizational structure to dispersed organizational entities working in a collaborative manner. Various product development methodologies have been developed to speed the communication between product team members including co‐location of the development team, email, scheduled telecom and video‐com meetings, Internet Web casting to keep all team members in contact with one another. No company has implemented a network centric product development system that links all users in the product development process together in a single system where real time communication or shared databases are used or exist. This would require a company to change it business model as a network centric product development system requires closer cooperation between and within itself, subcontractors and suppliers. As an example, both Wal‐Mart and Deutsche Morgan Grenfell have incorporated network centric systems into their business model with great success. Can the product development process be used on a network centric system? A Network Centric Product Development System requires a system configured and optimized to speed team communication and share product databases regardless of team member location or organizational affiliation.
The Evolving Joint Perspective and Meta‐systems Theory: A Case Study based on the Joint Vision Document
Authors: Palmer Kent D. 
Published: November 2014

AbstractThe Evolving Joint Perspective document which was the precursor to the current Capstone Concept for Joint Operations was analyzed in relation to Meta‐systems Theory in this case study which was done in the 2004 timeframe. The basic thrust of the new document is the same as the original document so this analysis is considered to still be relevant. Meta‐systems theory is proposed as a basis for Joint Forces organization. Currently the theory that is the basis of both documents is Complex Adaptive Systems Theory. The emphasis here is on the dual of that which would be Complex Adaptive Meta‐systems Theory. Both Systems and Meta‐systems Theories are said to be needed to have a complete theory for Joint Operations of Joint Forces.
Undergraduate Basics for Systems Engineering (SE), using The Principles, Measures, Concepts and Processes of Planguage
Authors: Gilb Tom 
Published: November 2014

AbstractThere are some very basic things that systems engineers should be taught. These things are both fundamental and classic. They are fundamental because we can reuse them in a very wide variety of SE situations. They are classic in the sense that they have a very long usefulness half‐life. They are probably useful for at least a career lifetime. When I was in my Twenties, I decided to collect, to learn and to develop these SE Basics. Now, in my Sixties, I am more than ever convinced that these fundamentals should be share with students. The fundamentals are: Principles (heuristics, laws), Measures (ways to quantify critical factors), Concepts (really useful definitions of fundamental SE ideas), and Processes (really useful SE processes). I have published these in several books and papers already. I would like to argue here why they need teaching in undergraduate systems engineering. I believe that their usefulness and longevity are demonstrated in my own work, are acknowledged by many professional colleagues and some academics, and are self‐evident upon examination. Hopefully this paper can stimulate others to adopt at least the general idea, if not my exact artefacts.
A Conceptual Glossary for Systems Engineering: Define the Concept, don't quibble about the terms.
Authors: Gilb Tom 
Published: November 2014

AbstractWe seem to spend a lot of our time defining terms, arguing over terms, standardizing terms, and misunderstanding terms. In connection with my development of a planning language, and its basic textbook I had to make a decision regarding my glossary. One of the formal design requirements I had set for myself was that the planning language, and its textbooks were easy to translate into other international languages. It was primarily in order to satisfy that requirement that I came up with the concept of a concept‐centered glossary, rather than the conventional term‐focused glossary (like a conventional dictionary).The basic idea is that we focus on defining a concept, no matter how many synonyms it might have, or how many different opinions there are about what the concept should be called.
Expanding Functional Analysis to Develop Requirements for the Design of the HumanComputer Interface
Authors: McKenna Brian , Gualtieri James , Elm William 
Published: November 2014

AbstractThe purpose of this paper is to provide a framework for extending the functional analysis of a system to the human decision‐making agents in order to improve overall system effectiveness. The subsystems needed to accomplish the goals of the system can often be found through a functional analysis. However, the different subsystems need to be completely integrated in order for the system to be effective. This integration is often problematic within the Human‐Computer Interface (HCI), where the operator is reliant on the information provided in order to have an understanding of what is occurring within the work domain. As a functional analysis helps to define the goals to be accomplished and the subsystems that accomplish them, it follows that expanding the depth of the functional analysis will help integrate the human operator and technology through the HCI to make a more effective Joint Cognitive System (JCS). The functional analysis leads to the creation of more insightful design requirements for the HCI that directly link the work that the user must accomplish and the information needed to complete this work – making it truly user‐centered design. An example of how the functional analysis can be applied to a system is provided, comparing an HCI developed with typical design requirements to an HCI developed from an expanded functional analysis.
Using a Boundary Object Framework to Analyze Interorganizational Collaboration
Authors: Fong Allan , Valerdi Ricardo , Srinivasan Jayakanth 
Published: November 2014

AbstractThe U.S. military is facing a plethora of challenges as a result of tightening procurement budgets and the need to acquire new capabilities to operate in modern war environments. This requires integrating legacy systems with developing technologies in what is loosely defined to be a System of Systems. Most Systems of Systems require some integrator to manage and operate the system interfaces. In addition to technical integration challenges, these system integrators have the difficult undertaking of integrating various organizations. The boundary object framework proposed by this paper provides a tool for systems integrators working in System of Systems or any type of complex system to identify and categorize communication, coordination, and collaboration interfaces and address possible failures.
Meeting the Need for Defence Systems Engineers
Authors: Cropley David H , Campbell Alistair 
Published: November 2014

AbstractAustralia is entering a period of forecast skills shortages in defence industry. The growth in demand for new complex defence systems, stimulated by Federal Government spending, has highlighted the need for additional systems engineers and systems integration specialists. At the same time, the size of many companies in the Australian defence industry mitigates against strategic investment in programs to address their skills needs. This situation is compounded by strong growth in Australia's resources sector, fuelled by high prices for minerals, and the consequent competition for the same engineering professionals. This impacts on Australia's capacity to achieve self‐reliance in defence capability.Concurrent to this skills shortage, however, is a widespread recognition by all levels of government that action needs to be taken. The Skilling Australia's Defence Industry (SADI) initiative will inject approximately A$200 million over the next 10 years into programs to address the skills shortage. The initiative, run by Australia's Defence Materiel Organisation (DMO), has already allocated significant funding to companies that are engaging in new activities to address their skills requirements. This paper describes one such activity – the creation of a new Masters degree in Military Systems Integration.
From Research to Reality: Making COSYSMO a Trusted Estimation Tool in Your Organization
Authors: Valerdi Ricardo , Miller Chris 
Published: November 2014

AbstractAs the COSYSMO model transitions from the development phase into the adoption phase, industry stakeholders are beginning to embrace the model and integrate it into their existing measurement processes. To date, much of the guidance provided by the COSYSMO development team has been focused on the usage of the model. In the adoption phase, users need guidance on how to adopt the model as they work to convince management to invest resources in competition with other process improvement initiatives.This paper outlines a process which provides guidance on the piloting and institutionalization of COSYSMO designed to help scope the effort needed for successful adoption and implementation. The process has been developed as a result of interactions with over a dozen organizations that have participated in the industry calibration of the model and have begun to integrate the model into their internal processes. The knowledge obtained from working with these organizations is reflected in this process.
Biologically Inspired Systems Concepts –A personal history
Authors: Friedman George 
Published: November 2014

AbstractBiologically inspired systems concepts – witch include artificial intelligence and artificial life – represent an enormously rich and – to many – fascinating source of ideas for future systems engineering architectures and designs. However, this source has been fraught with many failures and is often controversial. The author has had the fortune to be exposed to many successes as well as failures in this field and attempts to summarize over 60 years of these experiences, with lessons learned.
1.1.1 Designing the Construction Process
Authors: Aslaksen Erik W. , Brouwer Paul , Schreinemakers Paul J.P. 
Published: November 2014

AbstractAfter its initial development in the telecommunications industry (Hall 1962, Bode 1967), systems engineering flourished mainly in the defence and aerospace industries. As a spin‐off from the development in these areas, systems engineering itself has developed and grown to accommodate many more domains all over the world. One of these domains is the construction industry. This paper elaborates on the tailoring of systems engineering principles to a construction industry environment: governments, railroads, city boards, highways and a lot of steel and concrete. It examines the equivalence between this domain and the more traditional systems engineering processes as a path to recasting systems engineering in a language that would make it more immediately useful and acceptable in the construction. Finally, the paper discusses some features of the implementation of such a reformulation undertaken within the Dutch construction industry, illustrating the communalities for applying Systems Engineering within the construction domain throughout the world.
1.1.2 Do It Right, Do It Early; Do It Early, Do It Right: Reshaping the DoD SE Investment Paradigm
Authors: Loren Jeff , Bullard Randy 
Published: November 2014

AbstractThe first standard deviation of a normal distribution curve overlaid on the Department of Defense (DoD) acquisition life cycle “wall chart” generally aligns with Milestones (MS) / Key Decision Points (KDP) B and C, which bound the System Development and Demonstration (SDD) phase. Taking this overlay to represent Systems Engineering (SE) effort supports the contention that, historically, the Services and their industry partners have done reasonably well in the practice and management of large amounts of post‐contract‐award SE. Much of this effort focuses on the fundamental activities of requirements decomposition and allocation needed for detail design to proceed.Analyses of DoD cost and schedule overruns have long pointed to optimistic technology maturation expectations and inadequately defined requirements as causal factors. It is almost axiomatic that process output quality directly reflects the suitability of input attributes. We suggest overlaying the near‐exponential “cost of change” curve on the above construct to support the case that early SE investment, focused on crafting and refining requirements, minimizes “churn” and rework in SDD. The objective is to have realistic, achievable requirements and technology paths at program launch, reducing the risk of breaching cost and schedule baselines.
1.1.3 Propositionofa Formal Frameto Facilitatethe Applicationof Processesin Systems Engineering
Authors: Rochet Samuel , Baron Claude , Malgouyres Hugues , Esteve Daniel 
Published: November 2014

AbstractIn this paper, we are interested in “good practices” of Systems Engineering synthesized in processes of Systems Engineering. We will show that it necessarily exists gaps between the processes described by standards of Systems Engineering and such they are applied in industry. These gaps can create a loss of “good properties” detrimental to a good management of projects. By a modeling and a formal validation of processes, we will show it is possible of insure a conservation of these properties, or at least to verify they appear in effectively applied processes.
1.2.1 Early History of Systems Engineering (Part 3) – 1950's in Various Engineering Sources
Authors: Ferris Timothy L.J. 
Published: November 2014

AbstractIn a pair of papers in the 2007 Symposium the early history of systems engineering, from the perspective of the IRE publications was presented. This paper extends this work with a discussion of the early history of systems engineering from the perspective of other publications produced by engineers within the engineering community. This paper reviews the matters identified and compares the findings with the findings from the corpus reviewed earlier. The differences are discussed with a particular view to understanding why different parts of the engineering community came to different positions.
1.2.2 Assumptions / Promises ‐ Shifting the Paradigm in Systems‐Engineering
Authors: Engel Avner , Winokur Michael , Döhmen Gert , Enzmann Marc 
Published: November 2014

AbstractIn the field of embedded systems, the need for increased competitiveness necessitates the shortening of the development lifecycle. Engineering activities, that in the past were conducted serially, must often proceed in parallel in order to reduce time‐to‐market. This causes the concurrently working design‐teams, to rely on preliminary information that has not yet been finalized. As a result, substantial rework is required throughout the development process, consuming as much as 50% of the total engineering effort.This paper describes early results from the European Commission supported SPEEDS (Speculative and Exploratory Design in Systems Engineering) project. The objective of SPEEDS is to construct theory and tools for concurrent system development which will reduce the overall systems development cost and time to market.We propose a shift in systems development paradigm, relying on the formal use of contracts composed of Assumptions and Promises (A/P), analogous to Bertrand Meyer's “design‐by‐contract” model proposed in the early 90's. Such assumptions and promises may be related to both technical and management domains, where contracts are defined at all levels of design abstraction. Horizontal A/Ps analysis (Consistency) and vertical A/P analysis (Composability) may be conducted, leading to early discovery and correction of technical or management incompatibilities emanating from invalid assumptions.SPEEDS utilize several enhanced COTS modeling tools, giving users the ability to apply design‐by‐contract to Model Driven Systems‐Engineering in all phases of the development lifecycle.
1.2.3 Getting the Message Across ‐ Creating Accessible Guides to Promote the Adoption of Systems Engineering Good Practices
Authors: Armitage Tim , Elliott Bruce , Chin Deborah , Kastenhuber Ed , Krueger Michael E. 
Published: November 2014

AbstractThe authors believe that better deployment of Systems Engineering (SE) would benefit the rail and transit sector. They have formed an INCOSE working group to develop guidelines which advance this objective, starting with the topic of requirements engineering.Although there is already sound guidance on requirements engineering, its influence within the sector has been limited. In hopes of changing this, the authors have created a short requirements guide, illustrated with practical examples and written in plain language. The authors' premise is that the benefits of increased accessibility outweigh any loss in comprehensiveness and precision.The guide is being produced following an iterative process involving peer review by INCOSE groups. The current working version is attached to this paper. The authors believe that following this guide would benefit rail and transit projects. The approach described may be of value to other SE practitioner trying to convince skeptics of the value of SE.
2.2.1 Collaborative Systems Thinking Research: Exploring systems thinking within teams
Authors: Lamb Caroline T. , Rhodes Donna H. 
Published: November 2014

AbstractThis paper describes ongoing research that seeks to develop an empirical basis for collaborative systems thinking, defined as “an emergent behavior of teams resulting from the interactions of team members and utilizing a variety of thinking styles, design processes, tools, and communication media to consider system attributes, interrelationships, context and dynamics towards executing systems design”. This type of thinking is critically important to addressing engineering systems challenges, and the research seeks to inform and enable effective systems engineering practice in contemporary engineering enterprises. Focusing on the aerospace domain, collaborative systems thinking is examined through the alignment of enterprise culture and standard technical processes. This paper draws on a variety of literature to compose a definition of collaborative systems thinking and propose a research agenda going forward.
2.2.2 MEASURING ORGANIZATIONAL RESPONSES TO STRESS: A LONGITUDINAL STUDY OF PRODUCT DEVELOPMENT TASK NETWORKS
Authors: Collins Shawn T. , Bradley Joe A. , Yassine Ali A. 
Published: November 2014

AbstractThis paper uses Network Analysis (NA) to study task interactions in a product development process (PDP). It explores the impact of significant organizational stress on changing information flow patterns in the PDP at a small engineering company. The analysis identifies structured patterns of centralization, role specialization, and formalized control in the PDP. This validates themes from organizational behavior and quality management literature regarding how organizations change in response to stress. These trends are difficult to uncover with Systems Engineering techniques such as the Design Structure Matrix (DSM) and N2 method. The results offer several findings. First, reducing variation in task outputs is an understandable approach to controlling a PDP. However, it is important to reduce variation in task inputs as well. Second, tasks, like people, can have varying roles and burdens in terms of how they share information. Companies that want to support multiple concurrent projects must make sure their PDP tasks have an appropriate distribution of labor. Finally, transitivity can identify both valuable and ineffective iteration among groups of tasks. This provides a metric of effective concurrency in a PDP.
3.3.1 Optimizing Resource Allocation Decisions
Authors: Wilson Mark A. 
Published: November 2014

AbstractThe paper explains how the analytical hierarchy process (AHP) theory of decision‐making can be used to create justifiable, traceable resource allocation decisions in a resource‐constrained organizational environment. By thinking about the decision as a six step process of: (1) framing the decision to be made, (2) identifying alternatives, (3) modelling‐evaluating the trade study, (4) choosing an alternative, (5) conducting sensitivity analysis, and (6) implementing the selected alternative, key stakeholders can better understand how to reliably and repeat‐ably make justifiable, traceable resource allocation decisions in the context of an enterprise systems framework.
3.4.1 Systems Engineering Project: Zero Population Growth by 2020
Authors: Pietras Sherry L. 
Published: November 2014

AbstractThe scientific conclusion as to the primary cause of global warming is human beings. Human use of fossil fuels causes carbon dioxide emissions and the resultant green house effect. To avoid the fast approaching point of global melt down will require halting the population growth. No amount of technological advances to clean emissions will preclude the accumulation of gases in our atmosphere without stabilizing the population causing these emissions. The United Nations (UN) estimate for world population by 2050 is 10.5 billion, a prediction of doom. The current world population is 6.7 billion, if growth slows down to 7.5 billion by 2050 global warming may stabilize. The consequences of global warming are evident today, such as melting of the polar caps, resultant floods and rising coastal waters. To stabilize the situation and avoid disaster something must be done. Imagine you are the Systems Engineer selected to propose the ‘Zero Population Growth by 2020’ project. First you pick up your INCOSE Systems Engineering Handbook and then what would you do?
3.4.2 Applying the Human Views for MODAF to the conception of energy‐saving work solutions
Authors: Bruseberg Anne 
Published: November 2014

AbstractNetwork enabled working capabilities are a central development theme for both civil and military domains, given technology trends and human interaction needs. Enterprise Architectures are essential modelling aids to support high‐level planning of such systems, with an operational perspective. MODAF, the Ministry of Defence Architectural Framework, is one such tool for UK defence applications. This paper introduces complementary modelling elements for MODAF to better account for the Human Factors concerns of Enterprise Architectures. A set of Human Views is proposed and a civil application to the implementation of a tele‐working scheme is explored.