bluuebunny/crossref_metadata_2025 huggingface dataset:
4.2.3 From Process Aggregation to Process Integration
Authors: Browning Tyson R.
Published: November 2014

Abstract1

A process is a kind of system. As such, it derives its added value from the relationships among its elements (e.g., activities). For a group of activities to be truly integrated (versus merely aggregated), their interfaces must be well defined. In engineering processes, these interfaces usually indicate a flow of information. Engineering processes are extremely complex because of the large number of interfaces, as many types of information flow to many destinations. While the general structure of a process architecture is specified top‐down, the description of what actually flows must be extracted from the existing, implicit way work really gets done. Detailed descriptions of various processes must then be integrated into a process model that will have some prescriptive value. (The systems engineering “V” model applies to processes as well as to products.) This paper applies a powerful technique for representing and analyzing complex processes, the design structure matrix (DSM). The paper shows how to use the DSM to account for both internal and external inputs and outputs, providing the basis for process “puzzle pieces” that can be assembled to form large, integrated processes where value can flow.
7.2.2 Implementing A Cohesive Engineering Strategy Within A Corporate Matrix Structure
Authors: Williams Marcus , Duffin John
Published: November 2014

To achieve competitive advantage, an engineering enterprise adopting a matrix organisation needs to make the most of its engineering capability against a background of potentially competing project objectives and business imperatives.

This paper explores the pursuit of engineering strategy through the complementary perspectives of system product and engineering process. It proposes that these facets should be facilitated, co‐ordinated and controlled through the business enabler of process improvement. In support of this proposal, the paper describes a CMMI‐based framework through which to increase engineering capability across such an organisation.
8.2.2 Systems and Supportability Engineering and Integration: Best Practices for COTS‐Intensive Development
Authors: Verma Dinesh , Strandberg Tom
Published: November 2014

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 in available technologies, relevant missions and threat scenarios, and customer requirements and expectations. This results in the need for multiple technology refreshment and technology insertion strokes over the operational life span of these systems. COTS‐intensive C4ISR system performance, cost, and schedule risk must be viewed and analyzed from this long‐term perspective if a reduction in the total cost of system ownership is to be realized. This technical paper outlines the tailoring of the systems engineering and integration methodology to enhance its relevance to a COTS‐based acquisition paradigm through focusing on selected systems engineering sub‐processes and practices, such as open systems architecture formulation, assessment and evaluation; COTS assessment/selection; and COTS supportability engineering.
2.3.3 Designing Systems‐of‐Systems Without Getting Trapped in the Subsystem Maze
Authors: Kaffenberger Ruediger , Fischer Juergen
Published: November 2014

True systems‐of‐systems are one of the toughest challenges for system engineers. They face the problem to balance complexity of design and project structure against the product's cost during its lifecycle. The main cost driver is undesired redundancy in the product and/or the development process. Here we present a method that enables system engineers to shape the architecture of the system to the needs of the users and the development organisation. First we will give our definition of a system‐of‐systems, show why they are so important, and what makes them so demanding for the system engineer. After a look at the conventional way to solve the complexity problem and a discussion of its disadvantages we will present our method. We will give an impression how we derived it, and of the variants in applying it.
6.3.4 Threads, Reference Cases, and System Models: Adapting OOA to Complex System Specification
Authors: Steiner Rick
Published: November 2014

Behavioral system models are often necessary to specify top‐level system dynamic characteristics, especially for complex systems. Representing system stimulus/response behavior is often problematic, however. The scenario used to stimulate the system model may be overly simplistic, and won't be validated operational experts. On the other hand, operational experts will often develop a very broad set of system scenarios so detailed that they obfuscate the key system characteristics. This paper discusses a technique for aggregating operational system scenarios into a meaningful essential set of “reference cases”, which then serve as the functional baseline for system development and design verification.
7.3.3 Using Measurement to Assure Operational Safety, Suitability, and Effectiveness (OSS&E) Compliance for the C2 Product Line
Authors: Smith David L.
Published: November 2014

Air Force Policy Directive 63–12, Assurance of Operational Safety, Suitability, and Effectiveness, establishes the Air Force requirement to assure operational safety, suitability, and effectiveness (OSS&E) through a system's operational life. Electronic Systems Center (ESC) of Air Force Materiel Command (AFMC) is responsible to provide this assurance for each Command and Control (C2) system developed, procured, operated, maintained, modified, or employed.

This paper discusses the role measurement must play in the OSS&E assurance process, and offers guidance to develop effective measures. While specific measures must be adapted for each system, the concepts needed to develop effective measures are the same. A combination of product, process, and performance measures may serve as indicators to show the project manager the overall project OSS&E status. These could include trends that show compliance being maintained or in jeopardy, or the positive (or negative) effects of a particular course of action. Example measures are presented to reinforce the concepts being presented.
1.4.1 Enterprise Systemics: Systems Thinking for plotting Strategy at the ‘Extended Enterprise’ level”
Authors: Fairbairn Allen , Farncombe Andrew
Published: November 2014

This paper demonstrates the value of various systems techniques, and the system of systems concept in particular, to the design and management of key Extended Enterprise activity. By the Extended Enterprise (EE) we mean the context for the complete set of activities undertaken by companies operating together in a competitive market environment to deliver commercially viable products and services to consumers. We have coined the term ‘Enterprise Systemics’ to describe the use of a portfolio of systems techniques that facilitates, inter alia, plotting strategy at the EE (or network) level – perhaps the most challenging of corporate activity.

We describe what we mean by the Extended Enterprise and some of the difficult challenges that it presents for current design methods and techniques. We report on work done to develop an approach that draws from diverse sources of systems type thinking. Case Study material is provided, from work done with a shared learning group in the UK over the last two years and from the successful industrial development of a UK Government funded research project.
1.4.2 Best Value Solutions: A Systems Engineering Perspective
Authors: Donnelly John J.
Published: November 2014

Key aspects of Systems Engineering create an environment that encourages the development of best value solutions. These elements include requirement analysis and allocation, trade studies, risk management, and program evaluation. In this discussion, the term “best value solution” is defined as a balanced solution between cost, performance, schedule and risk (Cook et al. 1999), (Kaye, Graham 1999).
1.4.4 U.S. DoD Legacy SE & Implications for Future SE Implementation
Authors: Simpson Mary J. , Simpson Joseph J.
Published: November 2014

This paper presents a high‐level, simplified view of systems engineering to establish a common context for discussing systems engineering environments. It examines often unstated bases and assumptions upon which systems engineering implementation in the U. S. Military is based, and offers observations regarding factors that deserve consideration in implementation of systems engineering outside of the military domain.
5.4.2 A Solution to the Risk Management / Innovation Dilemma
Authors: Cogliandro J.A.
Published: November 2014

Risk management is a proven, accepted form of control for large, multi‐faceted technical development programs; however, it may be ‘detrimental’ to some or all of these programs due to inaccuracies in its mathematical and cultural basis. We hypothesize that Risk Management is inappropriate for many programs; particularly small projects, technology development and insertion programs, and R&D projects. Risk management can also hinder ingenuity and promote mediocrity in larger programs, especially during the critical concept exploration and preliminary design phases. In short, a modified version of Risk Management is proposed. This new version is directly linked to the strategic goals of the organization; it is designed to foster innovation without sacrificing robust design and good program management. The method is called Strategic Risk Management and is also known as Three Dimensional Risk Management (3DRM“©®, Pat. Pend.). It uses a newly constructed risk consequence chart designed to correct the flaws in today's risk management programs and is easily applied to existing risk programs or developed in new programs. Each point on the likelihood/consequence curve is numerically linked to the organizations goals, tactics, and strategies, and is program phased, hence the third dimension. In effect, 3DRM creates three totally new risk management quadrants organized by phase, and maintains the traditional curve as quadrant three. A powerful graphical summary view is also presented, which highlights the juxtaposition between the risk level and expected return of each item, and overlays the original goals of that item. In the following pages we will attempt to quantify several of the assumptions behind the statements above while proposing a modified form of Risk management for use in all programs, large and small, conceptual and mature.

‐Author's note: This paper is written for the risk management professional and assumes a basic knowledge of risk management; including identification, consequence and likelihood setting, mitigation planning and tracking. Our desire is not to dismantle any currently implemented risk management program or preclude a future program, but to offer the possibility of amending and improving the process.
1.5.4 Adaptation of a Generic Systems and Software Engineering Process for Component‐Based Development
Authors: Lykins Howard
Published: November 2014

Component‐based development, in which systems developers rely on the marketplace and other sources of components external to the project, is becoming the norm in many applications of systems engineering. Even highly specialized systems such as those used by the military and aviation contain a significant proportion of off‐the‐shelf components. This paper describes a tailoring of an integrated process for systems and software engineering for use in a development context that emphasizes component‐based development. It discusses some key requirements for the tailored process, and provides examples of the process architecture and the process information model. It concludes with a brief discussion of using the tailored process for a specific project.
3.5.1 System Engineering in System Avionics
Authors: Kagan Jakob , Levy Boaz
Published: November 2014

System of systems development requires design of the integration and testing process with a system perspective. Efficient and effective development requires in‐depth system analysis leading to the need of specific tools, integrated into the system at different levels. System levels can be divided to Design, Integration and Production

A Missile, is a product that can't be recovered from its mission, therefore each flight test is extremely expensive. The flight test has to be the final stage in a in‐depth and integrative test process. A primary guideline for missile testing and integration is: “If a specific function has not been tested, it will not work“. This rule was implemented into the development of the ARROW‐2 missile avionics subsystem. In the system design process of the Arrow missile, the tools and processes required for development were included as an integral part of the system. The human factor was also considered an integral part of the process and taken into account in the planning stages.

This article presents the systems oriented testing methods used for the Arrow missile in preparations for flight tests. The issues presented include:

The unique principles that were applied to the testing process.

The guidelines of determining the integration team.

The End to End (E2E) tests methodology as part of the integration process.

The different integration sites and the use of each within the process.

The types of tests performed within the process.

The contribution of the system design approach in improving the integration process by enabling integration of product system features as part of the testing system
7.5.4 Improving the Systems Engineering Process At Israel Aircraft Industries ‐ A Case Study
Authors: Engel Avner , Winokur Michael , Goshen Drora , Geva Izhak
Published: November 2014

This paper describes Israel Aircraft Industries (IAI) efforts in improving the systems engineering process. To put the subject in its right perspective, the paper provides some background information about IAI and its engineering culture. The paper describes the Advanced Systems and Software Engineering Technology (ASSET) program, which started in 1992. The paper describes a company‐wide effort to improve systems engineering processes in four important areas:

Manage and plan systems engineering.

Adopt systems engineering database tools.

Improved Systems Testing.

Train Systems Engineers.

The paper concludes by citing our lessons learned. The participation of personnel from both headquarter and divisions, the concentration of improvements in the most critical areas, the importance of the Systems Engineering Management Process Group (SEMPG) and the usage of pilot projects as a dissemination vehicle for concepts and methodologies.
4.6.4 Requirements process and traceability issues in a SE methodology
Authors: HELLOUIN Laureen , Beaugrand Jean Luc , SAHRAOUI Abd‐El‐Kader
Published: November 2014

This paper describes an approach for multiple domains system design, especially for systems mainly composed of electronic and computer technologies. The systems engineering concepts are taken as basis; such concepts are available through standards, working group's documents and other similar approaches being carried out for various systems. The methodology is tailored to fit specific needs coming from encountered problems at practical and applicable levels. It is limited to requirements process and traceability issues. The objective of the work was oriented to set up a good practice of system engineering approach in the elaboration of a methodology to deal with electrical, electronic and computer systems requirements to improve specification documents completeness.
6.6.1 RACE for Faster, Better, Value
Authors: M'Pherson Philip K. , Pike Stephen
Published: November 2014

The Rapid Assessment of Cost Effectiveness, ie RACE, is a key tool for the early concept and synthesis stages of systems engineering projects, during which the best candidate system has to selected for delivery from a ‘faster, better, cheaper’ project. The selected system should then offer the best value for money throughout an often long operational life. The paper outlines an integrated methodology for through‐life cost‐effectiveness analysis. Its structure is conventional, but it incorporates some novel features that provide (1) a powerful and fast ‘system builder’ to synthesise system candidates within mythical future operations, (2) tests to show that user, system and architecture requirements are matched, (3) a measuring multidimensional value criterion to serve for effectiveness, (4) whole‐life cost‐effectiveness analysis conducted in a true value for money sense. RACE has been tested on a real task, and specimen (but disguised) results are presented.
7.6.1 Front‐end Operational Concepts ‐Starting from the Top
Authors: Gabb Andrew
Published: November 2014

This paper addresses the need for, use and development of operational concepts at the start of large projects. It is derived in part from the author's work in INCOSE's Requirements Working Group and acquisition reform in the Australian Department of Defence, but also from the author's experience in developing operational concepts for defence projects. The front‐end operational concept, derived in consultation with the system's potential users and other stakeholders, should serve as the driving document for the acquisition and supply of the system. However, there is often uncertainty about what such a document should contain, how it should be developed, and its relationship to other project documents. The paper addresses these issues, as well as the evolution of the Operational Concept throughout the life of the project.
1.7.1 Applying Systems Engineering in the mining and ore processing industry
Authors: Wilcocks Hillegert A.
Published: November 2014

Traditionally, acquisition projects in the South African mining and ore processing industry have followed an approach geared towards employing mature and well‐known technology. Recently, De Beers recognised that this approach would not satisfy the needs of complex systems that employ more technically advanced diamond sorting technology. As a result De Beers established a new systems acquisition approach that includes systems engineering principles and related activities appropriate for projects of this nature. This new approach is the subject of this paper.
4.7.4 Putting Cost in the Cost verses Performance Trade‐Off
Authors: Redman Quentin , Stratton George
Published: November 2014

Cost Performance Trade‐Off analysis is fundamental to the Systems Engineering process. A cost performance trade study, is a procedural search for a design solution that balances achieved systems performance, effectiveness and cost against the desired or required values for these features and the system. Within this paper we will discuss the methodology and rational behind that methodology for preparing the cost estimates to be utilized within these trade‐offs. Also included is a short discussion on appropriateness of cost modeling and analysis tools.
1.1.3 Educating Systems Engineers: Encouraging Divergent Thinking
Authors: McCumber William H. , Sloan Crystal
Published: November 2014

Parallels between divergent thought processes, studied in creativity research by developmental psychologists, and the intellectual control imperatives of systems engineering are examined. A metaphorical template of the systems engineer's thought processes as defined by and taught from the standpoint of convergence is presented, and a core set of training modules to aid in evolving systems engineers from domain engineer stock is recommended. A. D. Hall's 1969 model of the systems engineer's thought structure is resurrected and is found to still apply to the convergent mode of systems engineering training. It is suggested that teaching systems engineers to develop divergent thought processes is analogous to teaching “creativity” in other fields. An examination technique, employed with success in a related field (e.g., Microsoft certification), that uses the traditional “convergent” multiple choice question, but forces divergent thinking to arrive at the “correct” answer, is discussed.
1.1.5 Systems Engineering in COTS‐Based Systems
Authors: Fan Lin H.
Published: November 2014

As more and more software systems are developed by extensively making use of COTS products in recent years, applying systems engineering disciplines to a COTS‐based system is essential for building a successful system. A COTS based system is different from the traditional software system in that it uses COTS components as the basis of the system functionality. This means the new activities will become part of the software development process and the risks will bring into the system development process.

This paper identifies these differences and difficulties from the system engineering's point of view, and focuses on the major system engineering activities in all stages of a COTS‐Based System life cycle. These activities are not only considered the technical aspects of the COTS based system, but also none technical aspects, such as marketplace research, management and business strategy and process. In order to provide a cost‐effective software development solution in COTS based system, this paper introduces the Adaptive Enterprise Solutions (AES) platform system as an example.
2.1.2 Use of constraint programming techniques for systems pre design involving several technical fields (Application on an example of an Aircraft Weapon Delivery and Navigation System)
Authors: Kou P. , Regniez C , Pagniez P
Published: November 2014

Systems pre‐sizing involving several technical fields is generally based on a method where up‐going validation phases follow down‐going analysis phases. Meanwhile, the usual tools, when they exist, are often optimised to work in a single way.

The Constraint Satisfaction Solving Method (CSSM) introduces a technique, which fulfil the needs of preliminary design, putting aside the notions of “input” and “output“. Moreover, Constraint modelling is a way to ensure the consistency between the different technical fields.

A simplified example illustrates the problem on the Weapon Delivery and Navigation System of a military aircraft, underlining the many capabilities of the method.

As a conclusion a feedback on its introduction at Dassault Aviation's Systems Directorate is presented and specifications for a Constraints Models Managing tool are introduced.
3.1.2 Organizing for Successful System Development
Authors: Rosen Peter A.
Published: November 2014

While many options are available to organize a development organization for success, applying basic elements of system engineering management in defining, building, controlling and maintaining the organization chartered to develop the system will provide a solid foundation for the system engineering effort. This foundation will provide focus on the system under development and the processes to be applied to the development, rather than on organizational roles and responsibilities. While the proper organization will not guarantee success, inadequate organization of the effort will make the difficult process of system engineering a monumental challenge.
3.1.5 Partitioning National Defence into Portfolios
Authors: Vencel Les , Moon Terry , Cook Stephen
Published: November 2014

Partitioning national Defence into portfolios, where key capabilities and activities are appropriately aggregated together, has been suggested as an effective way to manage national Defence. This paper examines in detail the application of a heuristic approach to achieve this, assessing the efficacy of various ways of partitioning national Defence using the established heuristics of systems architecting. The insights gained may then be applied to configure or refine the structure and to establish linking of the portfolios.
4.1.2 Geographic Information Systems (GIS) Applications And Trends
Authors: Raza Shahbaz
Published: November 2014

This paper presents an overview of GIS technology, its impact on various industries, current GIS technology trends, GIS standards, and systems engineering roles and challenges in the field of GIS. It introduces an overview of GIS technology i.e. what is GIS, how does GIS work, and what distinguishes GIS from other information systems. GIS is very much a multi‐disciplinary technology and can accommodate several application areas by integrating data from a variety of sources in a detailed and efficient manner. The paper discusses the impact of GIS application upon various disciplines e.g. business, engineering, political boundaries management, transportation, environmental management, natural resources, health care, and education. The development and application of geographic information systems is vibrant and exciting. The paper further reviews the existing and latest trends in GIS technology including new data sources, hardware and software developments. GIS is a rapidly growing field and requires an inherent need to have a set of common standards and rules to successfully complete GIS projects within time and budget. The paper also provides an overview of existing and future GIS standards and discusses the roles of various organizations involved in the development of GIS standards. Many areas in GIS are systems related and systems engineering can play a major role in helping GIS industry to be more productive and efficient to meet its customer needs. GIS technology, however, is relatively new and almost no formal systems engineering processes and practices are being applied. The paper addresses the major challenges faced by Systems Engineering in the development and management of GIS based systems.
5.1.5 A Systems Engineering Methodology for Combat Systems Development
Authors: Merritt Roger , Cropley David
Published: November 2014

Combat system development is difficult to do well; many issues surround the development of such systems. The history of the creation of large, complex, socio‐technical systems has been marred by a litany of project failures. Poor project outcomes result in business failure and significantly reduce the capability that can be achieved for the modest defense budgets of countries like Australia, Austria, Belgium, Canada, the Netherlands, Spain and Sweden. This situation is being exacerbated by the increasing dependence of modern military systems on software and the increasing complexity of such systems. This paper highlights major issues faced by the defense industries of ‘intermediate’ nations such as those listed. It proposes a solution in the form of a systems engineering methodology appropriate to combat system development.
1.2.3 A Structured Approach to Developing a Systems Capability
Authors: Goodlass Sue , Phillipson Alan
Published: November 2014

In November 1999, British Aerospace and Marconi Electronic Systems merged to become BAE SYSTEMS, one of the 3 largest Systems, Aerospace and Defence companies in the world. In order to maintain and improve the company's capability, Engineering Developing You (EDY), has been created. EDY forms part of an integrated framework for personal and professional development – but with over 20,000 engineers just in the UK, and almost the same number again in overseas divisions and joint ventures ‐ the task itself is far more complex than may at first appear.

For an (ex‐)Systems Engineer now working in the Virtual University, given the task of designing and developing this framework, using a structured Systems Engineering approach seemed to be a sensible approach. So how easy was it to apply a ‘soft system’ approach and how successful has it been ??
4.2.1 A Case Study in the Replacement of Legacy Systems with an Enterprise Resource Planning System
Authors: Raynor Rashad
Published: November 2014

This paper presents two case studies that involve the process of replacing multiple legacy systems with a comprehensive Enterprise Resource Planning (ERP) system. The paper will focus on the processes that each company took in evaluating the systems and the data housed in these systems. The lessons learned and an assessment of each company is presented at the conclusion of this paper.
6.2.1 The Concepts of Systems Engineering as Practiced by the Wright Brothers
Authors: Buede Dennis
Published: November 2014

To the best of our knowledge the term “systems engineering” was first used at AT&T's Bell Laboratories some time in between 1920 and 1940. [Buede, 2000] The systems engineering profession made rapid progress for 20‐30 years after World War II, as did all of engineering. Nonetheless it is possible to see the concepts of systems engineering being practiced prior to 1920.

The purpose of this paper is to explore one of those cases: the development and ultimate production of the airplane by the Wright brothers.
6.2.3 Application of Computer‐Aided Systems Engineering to Develop Automated Train Control (ATC) System
Authors: Lee Joong Yoon , Ahn Jang Keun , Park Young Won , Lee Woo Dong , Mok Jai Kyun
Published: November 2014

The project to develop an automatic train control (ATC) subsystem for the Automated Guided Transit (AGT) system has high technical risk because the wireless train control technology is unprecedented in Korea. To succeed in developing the ATC subsystem, SE team took a reverse engineering approach focused on building an engineering model of the ATC subsystem. The scope of this paper is to develop a functional architecture of the ATC subsystem using the CASysE tool of Vitech Corp., CORE. This paper shows how the generic SE process was tailored to perform a reverse engineering approach in developing the wireless signal/control subsystem.
9.1.7 Towards the Engineering of Requirements
Authors: Gilb Tom
Published: November 2014

Software engineers must articulate requirements in a clear testable manner. This paper outlines a framework for specifying requirements and discusses some key concepts for requirement specification.
9.1.9 Decision Metrics Matrix Process
Authors: Helm James C.
Published: November 2014

This paper presents a decision metric matrix process to evaluate the stakeholders needs related to their goal for improvement of a process, product or resources. The decision metric matrix gives the system engineer a method to name the components of the decision matrix and provides a process to extract, quantify and evaluate the metrics of the stakeholders' goals. Column one and subsequent rows of the decision matrix contain the decision parameters and the interior rows and columns contain the associated action statements and values. The stakeholder uses the action statements and action values as indicators to make a weighted decision concerning the goal. The decision metrics matrix uses concepts from the Goal‐Driven Measurement paradigm (Basili).
9.2.0 The Communications Requirements Evaluation & Assessment Prototype (CREAP)
Authors: Kasser Joseph E. , Cook Stephen C.
Published: November 2014

Today's requirements engineering processes do not have very effective checks to ensure that system requirements are feasible. This paper describes extending the use of Requirements Engineering tools to assist the writers of requirements to only accept requirements that are feasible using the FBRET approach (Cook et al. 2001). The approach is illustrated by the description of the Communications Requirements Evaluation & Assessment Prototype (CREAP). The CREAP is a prototype software package that is able to integrate military communications domain expertise and requirements engineering practice in order to ensure the feasibility of equipment selected to meet the requirements imposed on communications systems for a rapid force deployment in a design to inventory scenario.
9.2.4 Open Source Software Assessment for the Naval Oceanographic Office
Authors: Lever John A. , Maresca Chris , Munro Robert
Published: November 2014

This paper describes an ongoing analysis of the utility of Open Source software at the Naval Oceanographic Office (NAVOCEANO). NAVOCEANO possesses leading‐edge technical and science skills for the application of Information Technology (IT) in processing oceanographic data over multiple scientific domains. NAVOCEANO produces numerous information products supporting U.S. Navy operations, the Department of Defense, and the other military branches, as well as various national and international customers. These capabilities are critical to developing and maintaining the highest quality oceanographic products for the Navy fleet. In addition, NAVOCEANO maintains an extensive library of state‐of‐the‐art scientific applications software.

The Open Source Software Institute (OSSI) is a nonprofit organization that promotes development and implementation of Open Source software solutions within government and academic institutions.

In 2001 NAVOCEANO requested OSSI assess the use of Open Source software within NAVOCEANO, and OSSI contracted with Olliance Consulting Group to assist with this effort. The objectives, scope, approach, and some preliminary results of this evolving Open Source assessment are presented.
9.2.6 Aging Transport Systems Rulemaking Advisory Committee (ATSRAC) Aviation Standard Wiring Practices Manual – Task 7
Authors: FRAeS Ross Lloyd
Published: November 2014

ATSRAC was created to resolve certain aircraft wiring issues by problem solving. This entails the development of standards and therefore ATSRAC encompasses the theme of INCOSE 2002 – Problem Solving Through Structured Thinking with concentration on the Speciality Track of Development and Use of Standards.

Task Group 7 of ATSRAC (of which the author is a committee member) adopted the Systems Engineering approach to solve the problem of introducing the requirement (through an industry standard) of a Standard Wiring Practices Manual.

Soon after TWA 800 accident it was noted by the FAA that ‘aging’ could not be limited to structural systems and it was now necessary to include non‐structural systems in the FAA program covering Aging Aircraft.

Standard Wiring Practices Manuals were developed, implemented and utilised by Aircraft Manufacturers in the development of their product line.

Originally driven by (and in the most part, echoing) Military Standards, the layout and content varies considerably between manufacturers.

Task Group 7 was established under the auspices of ATSRAC to develop a Standard for aircraft wiring practices.

ATSRAC Task Group 7 is an example of ‘Development and Use of Standards‘.

This paper provides a solution to inconsistencies with aircraft wiring not only between manufactures but also different aircraft models from the same manufacturer. This will be accomplished by developing standards, which are intended to be mandated throughout the aviation industry.
9.2.7 Integrated Product Development Planning within Distributed Organizations using ProcessEdge™
Authors: Madni Azad M. , Madni Carla C. , Plaut Jeff , Zarnow David
Published: November 2014

After a series of acquisitions, major aerospace companies are still consolidating their infrastructures and processes. One of the more challenging issues is consolidating the systems engineering infrastructure. This is because each acquired company has its own systems engineering processes and best practices despite the fact that all claim to have embraced integrated product process development (IPPD) and systems engineering standards. Compounding the problem is the fact that each organization has a legacy of tools, applications, and databases that produce sufficiently different outputs that it becomes near impossible to reconcile them. This paper presents a “view from the trenches” as a major aerospace company took on this challenge. The circumstances, approach, and findings from this work should resonate with practitioners in the field while providing them with insights for future undertakings.
9.2.9 The Role of Systems Integration in Knowledge Management and the Knowledge Economy
Authors: Martin James N
Published: November 2014

This paper discusses the role of systems integration in knowledge management and the knowledge economy. It describes the social, human, organizational, and technological factors involved with the systems engineering and integration of the systems that must support knowledge management.
9.3.6 Effective Engineering Decisions Through Structured Collaboration
Authors: Wilson Mark A.
Published: November 2014

This paper describes a methodology for engineering decision‐making through structured collaboration. This collaborative decision engineering methodology has been effective in both government and commercial arenas on a wide range of programs. By thinking about the decision as a three step process of: (1) framing the decision to be made, (2) generating alternatives, and (3) deciding the course of action, decision makers can harness group dynamics to help achieve the goal of implementing engineering decisions that work and last.
2.3.1 The Impact of CMMI Maturity on Innovation
Authors: Walden David D.
Published: November 2014

This paper analyzes the impact that increased process maturity has on innovation. The Process Areas (PAs) and Generic Practices (GPs) of the Capability Maturity Model Integration for Systems Engineering / Software Engineering / Integrated Product and Product Development / Supplier Sourcing (CMMI‐SE/SW/IPPD/SS) were each individually assessed for their impact against six key characteristics associated with innovation.

The analyses suggest that, on balance, increasing an organization's process maturity in the areas covered by the CMMI has a positive effect on the ability to innovate. Most PAs are either neutral to or have a positive influence on innovation. A few PAs have a negative influence on innovation. The results of this analysis are consistent with a similar analysis that used the EIA/IS‐731 Systems Engineering Capability Model (SECM).
2.3.5 Systems Engineering Beyond Capability Models
Authors: Sheard Sarah A. , Schoening William W.
Published: November 2014

Capability models have been used for more than a decade to improve the ability of organizations to produce software and systems. The models themselves have matured and currently capture much industry wisdom. However, it is important to note that capability models1 do not and cannot include everything that an organization needs to know to do systems engineering well. This paper attempts to show where systems engineering is broader or deeper than is captured in capability models. Organizations that address these areas when implementing capability model‐based process improvement will make their systems engineering capability robust.
3.3.1 Tools for Requirements Discovery, Creation, and Elicitationa
Authors: Heydt Harold J. , Alessi R. Sam
Published: November 2014

Systems engineers can benefit by increasing their familiarity with multiple approaches and tools for helping human beings express their desires and wants. This paper addresses this issue by presenting an overview of requirements elicitation tools. Numerous tools are discussed with their applicability to hardware, software, or soft systems, or any combination. It provides an overview of “what” the tools can do but not “how” to use the tool, the difficulty of learning (rough order of magnitude learning time), the type of product the tools are of greatest value (benefit/cost) for usage, and some advantages and disadvantages for each tool.
3.3.2 The Communications Requirements Evaluation & Assessment Prototype (CREAP) Project: A Case Study of a System Engineering Educational Project
Authors: Kasser Joseph , Cook Stephen C. , Pilgrim Anthony , Gamaliel Yoyok , Ton Dat Bao
Published: November 2014

This paper contains a case study describing the development of a software tool to prove a concept for use in design to inventory scenarios. The tool was developed by Master's students at the University of South Australia. The case study, designed as a reference for similar activities in other academic institutions, contains a list of lessons learned on the project. All the lessons learned have to do with the nontechnical aspects of the project. Even though the project was small, many of the attributes of large projects were seen.
3.3.3 Separating Product and Process Requirements
Authors: Abadi Christiano Danny , Bahill Terry
Published: November 2014

When engineers design a system, they must design both the product and the process that will develop it. Accordingly, systems engineers must separately write requirements for the product and the process. Stating these requirements in separate documents should make it easier to get the requirements right and manage the requirements when either the product or the process requirements change.
4.3.1 Innovation and Technology Management
Authors: Simpson Joseph J.
Published: November 2014

A systematic approach to innovation and technology management is outlined in terms of a generic systems engineering process. Two types of innovation, incremental and disruptive, are described and discussed. All aspects of the product development and application environment must be correctly managed if an organization wishes to consistently produce innovative technologies and products. System engineering concepts provide a structured framework for the successful practice of innovation and technology development, deployment and management.
4.3.4 NASA Technology Assessment Using Real‐Options Valuation
Authors: Shishko Robert , Ebbeler Donald H. , Fox George
Published: November 2014

We examine the use of real‐options valuation in the context of prioritizing advanced technologies for NASA funding. Further, we offer a set of computational procedures that quantifies the option value of each technology. Other researchers have applied a real‐options framework to private sector investments. In the case of NASA investments in advanced technologies, the underlying products, which must be used to justify the investments, are nearly pure public goods—in particular, space‐related scientific results and discoveries to be shared worldwide. As in the private sector, uncertainty plays a significant role in the motivation to use real options in NASA. Uncertainty in NASA technology investments can be classified as development risk and programmatic risk (whether missions using the technology will actually fly). The latter might be called the technology's “market risk.”

We carried out the approach on a number of planetary exploration technologies. We illustrate the detailed calculations using one of them — lightweight propellant tank technology.
5.3.4 Introducing Innovative Technology in a Contract‐Driven Environment
Authors: Myers Kenneth N. , Beckley Jennie
Published: November 2014

This paper discusses our experiences in developing and introducing a web‐centric Collaborative Engineering Environment (CEE) into an organization whose lifeblood is performing on government contracts. We review events in the team's 3‐1/2 year history that led to an increasing awareness that the product development paradigm needed to introduce innovation into the engineering organization is very different from that needed to perform successfully on a contract. While many lessons from the world of contracting have been valuable, some of the disciplined processes learned over the course of many years, such as up front specification and traditional forms of progress tracking, can hinder innovation. Finally, we summarize the process adaptations we have made to address the conflicts.
6.3.5 An Implementation of a Process Centered Collaborative Engineering Environment within the Satellite Industry
Authors: Hartmann Ralf , Knirsch Ulrich
Published: November 2014

The paper presents an approach for a Collaborative Engineering Environment (CEE), facilitating the work of distributed design teams. It includes an internet portal providing among others access to tools and to a project database. A core element is the so‐called process guidance, which is not only the basis for the derivation of the CEE user requirements ‐ including standard tools ‐ but also the primary reference for tailoring of processes to specific projects. The process guidance, which is currently being implemented at Astrium, is centered on databases with web interfaces. Thanks to the non‐proprietary software, it is easy to implement, to use and to update. Additionally, the paper discusses lessons learned in the development process.
1.4.5 A Systems Approach to Open‐Inquiry Evaluation of Engineering Programmes
Authors: Harris Michael B.
Published: November 2014

The problem of how to evaluate engineering programmes is considered. Engineering organisations are under pressure to improve the performance of their programmes, as failures in technological projects receive increasing criticism, while the demand remains for increasingly complex projects to be undertaken. Many engineering organisations have realised that the success of such programmes depends more on the management and related programme issues and less on the engineering details. Evaluation of engineering programmes is demanded, yet evaluation techniques from ‘soft’ (non‐engineering) domains with little understanding of engineering values and culture may be quickly dismissed as ‘not sufficiently quantitative’ and ‘without a systems (engineering) basis‘.

Programme evaluation in the human services field is well established, and the types of programme evaluations are outlined. However, engineering programmes present a complex problem space for the evaluator, and require an evaluation method capable of accounting for the values and culture of engineering stakeholders.

This paper outlines the systems approach for solving this problem of engineering programme evaluation, on the assumption that the engineering programmes are sufficiently complex that specialist evaluators from ‘soft’ domains conduct the evaluation. An evaluation model is proposed, based upon the open inquiry evaluation method used in human services programme evaluation, superimposed on the proven process used in the engineering discipline of Test and Evaluation (T&E) to validate ‘hard’ products of engineering programmes. With this model, it is suggested that an evaluation technique is easily understood and appreciated by the critical reference group in technology‐intensive domains.
2.4.1 Integrating Beyond Capability Maturity Models®
Authors: Ibrahim Linda
Published: November 2014

The Federal Aviation Administration (FAA) has been successfully pursuing integrated process improvement since 1997 using FAA's integrated Capability Maturity Model® (FAA‐iCMM®). FAA‐iCMM v1.0 integrated three CMMs: the software, systems engineering, and software acquisition models. Version 2.0 additionally integrates several important improvement approaches including ISO 9001:2000, EIA/IS 731, Malcolm Baldrige National Quality Award, CMMI, ISO/IEC TR 15504, ISO/IEC CD 15288, and ISO/IEC 12207. By integrating beyond CMMs, the FAA‐iCMM now contains guidance for improving business and technical processes ranging from enterprise management to operation and disposal.

This paper describes FAA‐iCMM v2.0, points out specific contributions from new sources, and illustrates some insights gained from taking a broader perspective ‐ when integrating beyond CMMs. The paper will be of interest to any organization that has been using multiple standards and finds that approach too expensive, confusing, or ineffective. It will also be of interest to organizations that do business with the FAA.