bluuebunny/crossref_metadata_2025 huggingface dataset:
9.3.7 Systems Engineering Support Using an Embodied Conversational Agent
Authors: Leibrandt Robert P.
Published: November 2014

This paper will provide the rationale for and capabilities of simple intelligent agents and more advanced Embodied Conversational Agents (ECAs) as an augmentation to the Systems Engineering Professor and Systems Engineering Mentor. The use of these agents to support in‐house Systems Engineering Management training and mentoring efforts with a limited number of teachers and practitioners is discussed.

Suppose an intelligent agent or ECA could provide real‐time support to a student that reduces the need for direct instructor involvement. Perhaps a practitioner with a real world problem needs performance support after core business hours. These agents provide a spectrum of capabilities from a series of indexed Frequently Asked Questions to a highly tailored context intelligent response? Yes, this approach allows users to have an interaction with a “guide/mentor” who answers direct questions and can sometimes anticipate the next in the thread based on user profiling. The ECA can react appropriately to the question, tailor the response and generally seem lifelike.

How would you go about developing this capability? Is there added benefit in preparing new faculty? How would the practitioner benefit? By discussing the use in terms of the Systems Engineering Body of Knowledge (SEBoK) and using an existing Systems Engineering case study we'll explore the answers to these questions.
3.3.5 Specification Types, Principles, And Organization
Authors: Jones David A.
Published: November 2014

Less than ten years ago there were around twenty types of standard military spec formats, but then came acquisition reform, emphasis on performance specs, the superseding of MIL‐STD‐490 (Specification Practices), and database vendor claims that specs are a waste of time. Last year at the INCOSE symposium a panel of experts decisively stated that both databases and specs ware needed. If specs are still worthwhile, how should they be used and how should they be organised? This paper reviews the types of former and present mil specs, and the reasons for the changes. It shows how different types of specs apply to different parts of the development process. The paper then goes further and examines the characteristics of good specs for any purpose and offers practical suggestions for organising them, including a useable outline. (This paper does not deal with determining the requirements for particular systems.)
4.3.2 Can NASA's Integrated Product Teams become “Hot Groups“?
Authors: Lovell Randal W.
Published: November 2014

Over the past few years, new Systems Engineering approaches to team management have been developed and employed at NASA. The latest team approach is utilizing Integrated Product Teams (IPTs). An IPT is a team of stakeholders created for a particular project to be the focal point of a specialized area or task. The team is responsible for all activities within that specialized area that might include engineering design, project schedule or budget.

This paper examines NASA's current IPT management and how it evolved and whether it can obtain the status of “Hot Group“. A Hot Group is a group of hand picked employees that is obsessively single‐minded about a task. A Hot Group is much more innovative and creative and performs at a higher intensity than an IPT.

What does it take for a NASA IPT to evolve into a Hot Group? Through examination of the obstacles confronting IPTs (and high performance teams in general) and researching the expert's recommendations to overcome these obstacles, a forward action plan can be adopted for creating these high performance innovative Hot Groups at NASA.
4.3.3 Systems Engineering on the Dark Side of the Moon
Authors: Rhodes Donna H.
Published: November 2014

Systems engineering is an essential discipline for both defense and commercial businesses. To date, it has not been possible for INCOSE to establish as strong a leadership presence in the commercial world as it has in the defense world. This is clearly related to the fact that heritage membership of INCOSE came largely from a defense orientation. It is also related to the author's premise that just as our observer point on earth limits our ability to see the dark side of the moon, our point of observation in our professional domain limits the capacity to truly see the ‘other side‘. The author, having a seventeen year career in the defense industry, recently transitioned to a position in commercial software product development. The observations and insights gained are the subject of this paper, and advocate further comparative research and study of systems engineering as a means to enrich the overall theory and practice.
5.3.5 Addressing the people problem ‐ ISO/IEC 15288 and the Human‐System Life Cycle
Authors: Arnold Stuart , Earthy Jonathan , Sherwood‐Jones Brian
Published: November 2014

This paper takes a system viewpoint on an organization's “most valuable asset“‐ its people. It provides an overview of how key International Standards consider people ‐ their roles, characteristics and behaviour ‐ as they create, interact with and form a part of complex systems. ISO/IEC 15288 provides direction at a strategic technical level on the design of humans into a system product, on human influence on the required system services and on the effective execution of system process by humans throughout the life cycle. Nevertheless, a human‐centred approach requires particular techniques that are beyond the scope of this system‐level standard. A human‐centred standard, designed to complement ISO/IEC 15288, is therefore to be published in 2002 by ISO. The perspectives this standard takes, and the rationale behind them, are described.
1.4.2 Space System Concept Center, a CDC in an Educational Environment
Authors: Schiffner Michael
Published: November 2014

The Institute of Astronautics (LRT) at the Technische Universität München gathered during the last years experience in the area of implementing Concurrent Design Center (CDC) in industry. It was both involved in the implementation of the Satellite Design Office at Astrium in Friedrichshafen and in Ottobrunn and developed a software tool to support the development process in the SDO. It was also involved in the implementation of a design center at Fairchild Dornier Corporation (Finkel et. all, 2002).

To teach the students the idea of concurrent engineering besides system modeling and systems engineering, the institute decided to provide a workshop for students during which they will learn these ideas. To achieve this goal, a small CDC, called Space System Concept Center (S2C2), was established at the institute.

This paper describes the workshop and the experience gathered during the last workshops. It outlines the process and team size required to perform a workshop in an educational environment.
1.4.3 Designing a new airport using a system engineering approach in a classroom exercise
Authors: Ludema Ir. Marcel W.
Published: November 2014

In the year 1999 the main transportation issue in the Netherlands was the Question: “If, why and how to facilitate the need for a new national airport?“. Amsterdam Airport Schiphol is growing towards its maximum capacity, due to space and environmental restrictions. The Dutch government looked for alternatives to facilitate the demand for further growth in air transportation, besides expanding the current airport. An alternative would be an airport on an artificial island a few kilometers out of the coast of the Netherlands. As part of a course addressing the subjects System Engineering and Integrated Logistic Support it became the problem field used as a case study. A problem solving method was developed based on some basic inter‐related concepts such as the necessary requirements for capacity, availability and maintainability that should be addressed during the system engineering phases related to the design and development of complex systems. Students stepwise designed a conceptual plan for an airport in sea on an artificial island based on the problem solving method. In respect to the duration of the course the results were more than satisfying.
5.4.1 ProACT™: Process‐aware Zero Latency System for Distributed, Collaborative Enterprises
Authors: Madni Azad M. , Madni Carla C. , Salasin John
Published: November 2014

Enterprise integration technologies such as XML, publish‐subscribe, and message brokers have made it possible for distributed enterprises to exchange information in a consistent, standardized way. However, these technologies do not address how to effectively integrate humans within distributed, collaborative enterprises nor do they specifically address how to minimize latencies in collaborative enterprises.

This paper presents ProACT™, a process‐aware collaborative system for integrating distributed collaborative enterprises at the functional/task level. ProACT exploits knowledge and awareness of planning/process execution status to eliminate/reduce information latencies in the distributed enterprise. ProACT employs a variety of process‐enabled, zero latency strategies such as optimal information caching, information prefetching, message prioritization in a bandwidth‐limited network, optimum database partitioning, and information replication to achieve the near‐instantaneous awareness goals of the enterprise.
5.4.2 Understanding Enterprise Behaviour: A Feasibility Study
Authors: Clegg Ben , Turner Mathew
Published: November 2014

This paper describes work conducted as a joint collaboration between the Virtual Design Team (VDT) research group at Stanford University (USA)1, the Systems Engineering Group (SEG) at De Montfort University (UK) and Elipsis Ltd2. We describe a new docking methodology in which we combine the use of two radically different types of organizational simulation tool. The VDT simulation tool operates on a standalone computer, and employs computational agents during simulated execution of a pre‐defined process model (Kunz, 1998). The other software tool, DREAMS3, operates over a standard TCP/IP network, and employs human agents (real people) during a simulated execution of a pre‐defined process model (Clegg, 2000).

This docking study was conducted to develop a supporting tool‐set for the concept of Enterprise Systemics, an approach designed to address the increasing commercial volatility of enterprises. It has been funded by the PISCES network project4, which has drawn together a cross‐disciplinary resource for comprehending the dynamics of the extended enterprise.
6.4.2 Anti‐terror Meta‐systems Engineering
Authors: Palmer Kent D.
Published: November 2014

The major terrorist incident of 2001 in the USA is used as an example of the relationship between the system schema and the meta‐system schema to show why understanding Meta‐systems Engineering beyond conventional Systems Engineering is, now more than ever, a necessity.
1.5.4 Capability Maturity Model Integration (CMMI) Process Using Unified Modelling Language (UML) for Flight Safety Process Modernization at a Major Range Test Facility Base
Authors: Donahe Dave , Gonzales Regina M. , Eubanks Carl , Gonzales Eli
Published: November 2014

The Capability Maturity Model Integration (CMMI) initiative is a blend of systems engineering and software procedures that promote process improvement in multi‐discipline activities such as a support system modernization at a Test Range. Using processes that promote consensus, the CMMI provides a cohesive framework for development that accommodates multiple disciplines toward a modernization development effort. This paper describes the on‐going processes involved in applying systems modeling techniques within a CMMI process environment to Flight Safety modernization at a Major Test Range. The system analysis and modeling is being done using various Requirements Engineering methods and is being expressed in the Unified Modeling Language (UML). This modeling effort is still at the conceptual or requirements elicitation phase. Some initial models will be presented in this paper along with the process framework that is being applied.
2.5.3 Overcoming the Obstacles to Systematic Design Reuse
Authors: Cole Robert
Published: November 2014

Although some level of design reuse is present in any engineering project, systematic design‐for‐reuse is less commonplace. Despite the known benefits of reuse, the implementation of systematic reuse faces strong resistance from management and designers. This paper considers inhibitors to implementing design reuse methodologies and the steps required to successfully transition from a no‐reuse culture to one of systematic reuse. Also considered are some of the pitfalls that can doom a poorly planned reuse initiative.
3.5.1 A Prototype Tool for Improving the Wording of Requirements
Authors: Kasser Joseph
Published: November 2014

The majority of work on a project is in response to a set of need statements or requirements, consequently errors in requirements are a major cause of project cost and schedule overruns. This paper presents a simple concept based on the FBRET approach (Cook et al. 2001) that can minimise the production of poorly articulated requirements, and describes a prototype software tool that implements the concept.
1.6.5 The Case for Flexibility in System Design
Authors: Saleh J.H. , Marais K. S. , Hastings D. E. , Newman D.J.
Published: November 2014

In this paper, we make the case for flexibility in system design. Flexibility is here defined as the ability of a system to respond to changes in its initial objectives and requirements, occurring after the system has been fielded, in a timely and cost‐effective manner. We argue that flexibility reduces a design's exposure to uncertainty, and provides a solution for mitigating market risk as well as risk associated with technology obsolescence. In order to illustrate the dynamics of system requirements, we first review the requirement generation activity. In addition, we demonstrate the criticality of technology obsolescence in the particular case of its impact on DoD related systems.
2.6.2 Integrated SE and PDM tool Support for Medium Sized Companies
Authors: Vonno Remco , Smeets Gaston , Boersema Niek
Published: November 2014

This paper describes how a fast and pragmatic design process for complex customer specific product development can be supported with a single tool. A commercial Product Data Management (PDM) tool has been extended with new functionality to provide support for the Systems Engineering (SE) needs of a medium sized company focused on modular design, maximum reuse and early involvement of suppliers.
3.6.1 The Concept Exploration Phase and Successful Coaching of Systems Engineering
Authors: McGuire Kathleen
Published: November 2014

Applying systems engineering techniques to the Concept Exploration (CE) phases of projects is often met with either indignation or incredulity. This much less structured, problem‐ridden phase seems to many to defy the use of process. This phase has traditionally been problematic and difficult to execute. IF the word “process” is too strong, the idea of “systems thinking” that helps make some order out of chaos can be effectively used for coaching teams to better performance.

This paper discusses some typical problems encountered in one organization and some successful use of systems engineering approaches to improve the teams' performances in the Concept Exploration phase.
3.6.4 Market Your Systems Engineering With Business Skills
Authors: Farwell Tracy J.
Published: November 2014

Several indirect methods for quantifying the economic value of Systems Engineering practices are described. All are easily recognized as conventional valuations. Systems Engineers are more effective when marketing their core skills in a business context. This paper supports those SEs who participate in the marketing of Systems Engineering as Engineering.
4.6.5 Towards an Improved Understanding of Humans as the Components that Implement Systems Engineering
Authors: Axelsson Jakob
Published: November 2014

Successful systems are developed from a good understanding of two things: the features and functions desired by the customers, and the features and behaviour of the available components. A firm developing a complex technical system is also a complex technical system in itself, so the same two things need to be understood about the organisation. Much research on systems engineering focus on defining the features and functions of the organisation, but less attention has been given to the prime component used for implementing it: the human being. In this paper, an initial attempt is made at describing some of the issues involved, from a mainly philosophical perspective.
5.6.1 Characterizing the Relationships Between Product Developers and Their Customers
Authors: Schoening William W.
Published: November 2014

The systems engineering approach of a product developer is strongly influenced by the business relationships with customers. The model presented in this paper characterizes those relationships and provides a framework for understanding why some developments are successful while others have little chance of success. The model is then used to examine more complex scenarios and transitions between scenarios to help understand some of the business management challenges encountered in a heterogeneous mix of business scenarios. A notation for describing these relationships is introduced to facilitate describing the individual scenarios.
6.6.2 System Integration in the Power Utility Industry: Lessons Learned
Authors: Rothweiler Angela
Published: November 2014

The shift from regional monopolies to retail marketers has caused significant structural changes within the Power Utility Industry, such as the disintegration of the transmission sectors, the transformation from engineering management to business leadership, the reorganization of distribution operations, and the ongoing acquisitions, mergers and buy‐outs. For the past 6 years, utility companies have been seeking new economic solutions that will allow them to survive within the competitive market. One area that has gained popularity is substation automation (SA). SA entails the integration and data management of intelligent electronic devices (IEDs) within the substation.

This paper attempts to use systems engineering (SE) principles for the design and development of substation data concentration (SDC) systems. A collaborated effort between the designer, the utility experts, the programmers and the technical manager transform the SDC operational need into system performance parameters; integrate functional and program interfaces in a manner that optimizes the total system; and ensures reliability, maintainability and survivability to meet cost and scheduling objectives.
6.6.4 Introducing Systems Engineering in the Fast Track: Wireless Data Communications Goes One Step Beyond
Authors: Ransyn Jack , Verhoeven Maarten , Vonno Remco
Published: November 2014

This paper contains the way Systems Engineering principles have been implemented in a very specific environment, a software engineering firm that creates applications for wireless data communication. This environment is challenging for a number of reasons, but mostly because there doesn't seem to be time for structuring the development process and introducing formal methods. On the other hand, not introducing a formal systems engineering method would be a dead end street sooner or later, given the fact that the company is making the transition from being project and consultancy oriented, towards becoming a productising firm with repeatable processes and predictable quality.

The challenge was answered by introducing a dedicated task force, called the RADS team (Requirements Analysis Design Support). This team introduced the Systems Engineering way of working in a rather unorthodox way, that suited the way the company worked without interrupting or delaying its core processes. It proved to be highly effective, and can be used as an example for other organizations.
1.1.1 Improving Forecasting with Soft Systems Methodology
Authors: Stajnko Frank , Doukas Louis
Published: November 2014

The engineering of tomorrow's world today can only happen if we have some idea of what tomorrow's world is going to be like. This leads us into the murky world of forecasting and strategy making, which are highly dangerous and difficult activities for most organisations. Of course if you have perfect knowledge about the future, then strategy making is relatively easy, as there are literally hundreds of effective decision making and optimisation methodologies available for this purpose. Sadly, finding reliable, accurate and concise knowledge about the future is anything but easy. This is the central problem of strategy making. Strangely enough, it is possible to accumulate relatively large amounts of raw data and information about the future, unfortunately processing and condensing this into useful knowledge is remarkably difficult. Information about the future can be hard (logical, deterministic and syntactic), but is mostly soft (vague, complex and semantic). Forecasters often ignore the latter because it is impossible to process normatively, however the appropriate use of Checkland's Methodology (a soft methodology) can greatly improve this situation. In particular, this paper shows how Checkland's Methodology and the correlation matrix can be used together, in order to discover patterns of information about the future that are more consistent, reliable and meaningful. This knowledge is critical for effective forecasting and strategy making.
1.1.2 Using Patterns to Share Best Results ‐ A proposal to codify the SEBOK
Authors: Haskins Cecilia
Published: November 2014

INCOSE has been making good progress in the compilation of a Systems Engineering Body of Knowledge (SEBOK). The committee struggles now with an abundance of literature augmented by over a decade of symposia proceedings and other material collected in the INSIGHT and the Journal of SE. Specifically, INCOSE struggles with the question of how to share this wealth with the world as the organization and its members attempt to communicate the value of SE to the international community, engineers and product developers.

This is not a unique challenge. A history of civil engineering and other disciplines may offer some insights into how to cope with this opportunity. In 1977, Christopher Alexander tackled this question with the creation of “Patterns” and Pattern Languages. This author proposes that creation of a Pattern Language Framework to document the “Best Results” of Systems Engineering using the resources of the SEBOK will yield positive results in the quest to share the message of Systems Engineering. This paper is intended as the first in a series to introduce the reader to underlying concepts
3.1.3 System Level Costs—Eliminating Guesswork
Authors: Stump Evin
Published: November 2014

Whenever a parametric cost estimate is made for a large system, there comes a time near the end of the estimating process when the analyst wonders if everything that is supposed to be in the estimate actually is in the estimate. Among the frequent errors and omissions are so‐called “system level” costs, also known as “wraps” or “SLCs.” NASA and the Air Force, in the NASA Air Force Cost Model define system level cost elements as comprising:

Systems Engineering and Integration

Integration, Assembly and Checkout

Ground Support Equipment

Program Management

System Test Operations

Launch and Orbital Operations Support

Not all of the items above should be added to a basic estimate. For one thing, not all of them occur in every major project. Moreover, many parametric models include some of the above in the basic estimates. But many cost models leave out some of them. And some cost models leave out any system integration above the subsystem/subassembly level (sometimes called level 2 integration). These can be significant omissions. In some cases, the errors could as large as 100%.

SLCs often cause problems for projects trying to get an accurate handle on their costs. Recognizing this, the NASA Independent Program Assessment Office (IPAO) contracted with Galorath Incorporated to study these costs, and to get more visibility into their behavior. This study began in August 2001, and was completed in May 2002. The study had access to the NAFCOM99 database, and to other data previously collected by Galorath.

The outcome of the study was a strengthening of Galorath's SEER‐H hardware cost model with respect to system level costs. The model previously could estimate these costs, but with less accuracy because of the need to rely strongly on the cost analyst's perceptions of the complexity of the project. With the modifications to the SEER‐H model coming out of this study, more objective criteria are available.
5.1.1 Reusable Specification Components for Model‐Based System‐Engineering
Authors: Weiss Kathryn Anne , Ong Elwin C. , Leveson Nancy G.
Published: November 2014

Many modern, complex systems follow common design principles where the system is broken down into various subsystems and components. For example, every spacecraft requires a number of subsystems such as attitude determination and control, power, thermal, communications and propulsion. These subsystems have common functionalities and similar interactions, rendering them suitable for representation with a reusable specification architecture. Their similarities can be used to create a system‐engineering environment specific to modeling that particular system, its subsystems and the subsystems' interactions. Based on this hypothesis, a domain‐specific specification architecture has been developed that is tailored for cross‐disciplinary use by systems and software engineers.
5.1.2 Using the Systems Engineering Process to Explain Baseball's Rising Fastball
Authors: Bahill Terry , Baldwin David G.
Published: November 2014

The systems engineering process, called the SIMILAR Process, is used to help explain baseball's perceptual illusion of the rising fastball. This Systems Engineering process is comprised of the following seven tasks: State the problem, Investigate alternatives, Model the system, Integrate, Launch the system, Assess performance, and Re‐evaluate. This Systems Engineering Process is not sequential. The functions are performed in a parallel and iterative manner. In this paper this process is not used to design a new system, but rather it is used to understand an existing system.
3.2.2 Interfacing a Verification, Validation, and Testing Process Model with Product Development Methods
Authors: Hoppe Markus , Lévárdy Viktor , Vollerthun Andreas , Wenzel Stefan
Published: November 2014

A thorough balancing of the costs of conducting verification and validation with the costs of failure promises new possibilities in reducing overall project costs and time‐to‐market. One goal of the presented SysTest project is to develop an approach to support the strategic verification, validation, and test (VVT) planning. This approach, reflected in the VVT Process Model, supports the trade off between different VVT strategies by calculating the effect of the strategy on cost‐, schedule‐, and quality‐risk. This paper describes the VVT Process Model, which is currently developed, and its application in the development process of a hydraulic pump. Furthermore, its interfaces with other company methods and the corresponding information flows between them are illustrated. To demonstrate its potential, the VVT Process Model is positioned in the verification process.
5.2.4 Systems and Objects
Authors: Simpson Joseph J. , Simpson Mary J.
Published: November 2014

This paper discusses basic system concepts including structure, content, semantics, scale and context. These basic concepts are reviewed and discussed in the light of two different human activity modes: system discovery mode and system design mode. A system meta‐model is outlined and discussed in terms of system behavior and context. A generic systems engineering model and process is reviewed and used as a basis to construct a system object model that facilitates the representation, description and detailed communication of system relationships and characteristics. The model is presented at the conclusion of this paper.
2.3.1 Systems Engineering Process Improvement in a Multi‐Model Environment
Authors: Evers John , Miller Chris
Published: November 2014

This paper reviews the major steps in the successful effort in reaching Level 3 maturity at Raytheon Falls Church, against the EIA/IS‐731 Systems Engineering Capability Model. This effort was conducted at the same time as other improvement efforts at Raytheon Falls Church, adding to the complexity of the task while providing the opportunity for synergy as well. Key elements associated with process improvement are discussed, including change management activities and their relation to other models for improvement. Finally, these elements are evaluated for application to other process improvement efforts in a multi‐model environment, such as the use of CMMI® and Lean or Six Sigma.
2.3.3 The Good, the Bad, and the Agile: XP Meets Systems Engineering
Authors: McDaniel Daryl , Neyman Roger
Published: November 2014

“Agile” development methodologies (ADMs) have emerged in recent years in response to widely perceived failings of commercial software development organizations (CSDOs) to reliably produce quality results in a predictable timeframe. Criticism of requirements engineering (RE) practices current in CSDOs is prominent among the motivations spurring this movement. Comparison of high level features of ADMs with established systems engineering (SE) approaches reveals that there is significant commonality between them. The most important difference relates to the mixing in of development activities with high level RE activities, involving developers in them from the outset and reducing formality. On the basis of this analysis we make some general observations on the value of ADMs and their advocacy.
5.5.1 Systems Engineering a Systems Engineering Innovation Center
Authors: Jackson Tony , Doggart Tim , Siemieniuch Carys , Woodhead Mike
Published: November 2014

In common with many other companies, BAE SYSTEMS is undergoing significant change to focus on the challenges inherent in emerging classes of complex systems. This led to the concept of an integrated Systems Engineering research and training center, the ‘Systems Engineering Innovation Center‘, founded in partnership with Loughborough University and one of the UK Government's Regional Development Agencies. The Center will expand to encompass wider academic and industrial partnerships which will ultimately span industrial sectors and academic disciplines. This paper describes the Systems Engineering approach to the setting up of this center and describes a number of lessons learned in its development.
3.6.1 Extending UML™ from Software to Systems
Authors: Friedenthal Sanford A. , Burkhart Roger
Published: November 2014

INCOSE and the Object Management Group (OMG) are collaborating on an initiative to extend the Unified Modeling Language (UML) to provide a general‐purpose systems modeling language to support analysis, specification, design, and verification of complex systems. This language will be a key enabler for transitioning the practice of systems engineering from a document‐centric to a model‐centric approach. Many different applications of UML to systems engineering have been demonstrated and published, and are in active use by various groups, but a standardized extension of UML for systems engineering is not currently available. This paper provides the background, motivation, and approach of this critical initiative to develop a standardized extension of UML for systems engineering, and highlights some of the early results to establish the requirements for the modeling language. Additional information can be found on the OMG Systems Engineering Domain Special Interest Group (SE DSIG) web site at http://syseng.omg.org.
5.6.1 Systems Engineering Education Development (SEED) Case Study
Authors: Bagg Thomas C. , Granata Raymond L. , Brumfield Mark D. , Casey Carolyn A. , Jamison Donald E.
Published: November 2014

The Systems Engineering Education Development (SEED) Program was initiated to help the Goddard Space Flight Center resolve a Systems Engineering skill shortage. The chronology of events and the experiences of the pilot program are outlined to describe the development of the present program. The program goals are included in order to give a focus on what the developers saw as the program drivers. Lessons learned from a pilot program were incorporated into the present program. The sponsors of the program are constantly learning from past efforts and looking for continuous improvement. We list several future ideas for improvement and change.
5.6.3 Developing Capacity for Engineering Systems Thinking in a Project‐Based Learning Environment
Authors: Frank Moti , Elata David , Lavy Ilana
Published: November 2014

This paper presents a qualitative study of students' capacity for systems engineering thinking as it develops during a Problem‐Based Learning (PBL) introductory course. This course is given to Mechanical Engineering freshmen and aims to provide a broad view of the field and of the process of engineering design. Data was collected in semi‐structured interviews with the students, the teacher, and the teacher assistant, and by classroom observations. Analysis of the collected data shows that through PBL, in which the students are exposed to synthesis processes and design procedures, they develop their capacity for engineering systems thinking. Furthermore, through experience they become aware of the importance of the top‐down approach and of the process of optimization in systems engineering.
5.6.4 A Video Approach to Knowledge Management
Authors: Wilke Martin , Finkel Stephan , Zender Joe , Schwehm Gerhard
Published: November 2014

The scientific exploration of our Solar System often requires scientific missions that span a period of sometimes two decades. During this period, a spacecraft and instrumentation is designed, built, flown wide into the Solar System, operated, the data analyzed and archived. The preservation of human expertise and all further needed information is a challenge for all teams involved in these missions. For the International Rosetta Mission a Video Approach was proposed, designed and is currently implemented. The authors present the overall Rosetta knowledge management approach, in particular the design and implementation of the Video Approach. It is shown that this approach is well suited as a complementary approach to the standard knowledge management implementations and can refresh and preserve additional knowledge. Sometimes this video approach is the only way within the time and cost framework of the teams involved to preserve significant parts of their expertise.
6.6.1 An Integrated Engineering and Economic Model Proposal for Ocean Thermal Energy Conversion Technology
Authors: Tompkins Robin H , Rezachek David , Briggs Mike
Published: November 2014

Ocean Thermal Energy Conversion (OTEC) techniques represent a unique opportunity to exploit solar energy from a source available 24 hours a day 365 days a year, can compete economically with conventional fossil fuel power plants, use minimal consumables, and produce virtually no harmful emissions. Large‐scale commercial and industrial adoption of OTEC will be realized only if a clear economic advantage can be demonstrated based on accurate and complete economic modeling. Determination of optimal system designs require application of multivariate system optimization techniques to define the “best” OTEC plant including non‐traditional economic activities that an OTEC plant supports with minor or no additional capitalization or operational costs. Non‐traditional activates that must be considered include sale of cold water effluent to agriculture/aquaculture users, industrial facilities for cooling, and fresh water production. OTEC's low/no emissions also allows sale of emission credits. This paper presents a proposal for modeling OTEC technology using system optimization techniques to define appropriate OTEC plant capacity combined with integrated non‐traditional economic activities to better understand the benefits and costs of OTEC power plants.
7.6.2 Connected Requirements: …liberating requirements so they can influence design
Authors: Sampson Mark E
Published: November 2014

Customer Requirements are important because that is what the customer will buy. Many organizations have learned the hard lesson of producing a product that doesn't meet customer needs–Ford's Edsel, Motorola's Iridium Satellite Phones, and others quickly come to mind. Given their importance its not uncommon for organizations to use a variety of means/methods to keep up with them–including documents, databases, and tracing tools. The problem is that even though the requirements are captured somewhere, they don't go anywhere and thus they have no influence over the design of the product. Teamcenter Requirements is after solving this problem by integrating or connecting the requirements into the development process so that requirements show up where the decisions are being made so they can have an influence over the design as the design decisions are being made. This presentation will cover the basics of Teamcenter Requirements as well as demonstrate the benefits of integrating requirements with the entire product life cycle.
7.6.4 World Class Intelligence Analysis
Authors: BeVier John L. , Calimer Colleen A.
Published: November 2014

This paper describes how combining certain aspects of systems re‐engineering with intelligence analysis creates a hybrid methodology resulting in a major transformation of the intelligence analysis discipline. The world and technology have changed over the years and now actionable intelligence must be provided in a collaborative environment prior to and during crises. Analysis of today's intelligence complexities demands a move away from analytic thinking to systems thinking. By introducing the concept of a “system” into the process of intelligence analysis, analysts are empowered to create and use systems models. These system models comprise all of the systems necessary for world‐class intelligence analysis – to include systems‐of‐systems of target, customer, and analyst. To the degree that these models are sufficiently accurate, the analyst can apply logic and judgment to produce projections of the future. Therefore, a continuing close customer‐analyst collaborative relationship enables professional determination of the most likely consequences of alternative customer operations.
1.7.1 Risk Management Capability Maturity Quantitative Assessment Tool
Authors: Shoults John
Published: November 2014

A checklist and questionnaire based risk management capability assessment method is developed that gives quantitative scores directly linked to the goals and practices of the Capability Maturity Model Integration™ (CMMI) model. Direct and indirect artifact objective evidence is enumerated and scored against a benchmark model using the checklist. Affirmation data is collected using the questionnaire and categorized into culture, process, experience, and application per the Project Management Institute‐International Council on Systems Engineering (PMI‐INCOSE) risk management maturity level development model.
4.7.2 Systems Engineering in Science & Technology
Authors: Zittel Randy C.
Published: November 2014

Systems Engineering has proven itself as the essential foundation of US military acquisition for over 40 years and is spreading across the world in its application to military and commercial development programs alike. It has generally not been applied to the development of advanced technology across the US military. From an increasing body of knowledge, this is now being addressed in the US Department of Defense with the formalization of systems engineering in science & technology, which has resulted in codifying techniques, tools and best practices. Through the application of the Integrated Product and Process Development teaming process and established systems engineering practices, increasing examples of success have proven the need to establish systems engineering as the formal approach in advanced technology development. The US DoD has documented this approach sufficiently to establish mandatory education for all advanced development managers to change the research and development culture and accelerate the use of systems engineering in advanced technology development throughout its research activities. This paper describes this emerging systems engineering approach as demonstrated in US Army, Navy and Air Force programs.
1.8.4 Probabilistic Risk/Reliability Analysis (PRA) Using a Simulation Approach
Authors: Miller Ian , Kossik Rick , Nutt Mark W. , Hill Ralph S.
Published: November 2014

Probabilistic risk/reliability (PRA) analyses for engineered systems are conventionally based on fault‐tree methods. These methods are mature and efficient, and are well suited to systems consisting of interacting components with known, low probabilities of failure. Even complex systems, such as nuclear power plants or aircraft, are modeled by the careful application of these approaches.

However, for systems that may evolve in complex and nonlinear ways, and where the performance of components may be a sensitive function of the history of their working environments, fault‐tree methods can be very demanding. This paper proposes an alternative method of evaluating such systems, based on probabilistic time‐based simulation using intelligent software objects to represent the components of such systems. Using a Monte Carlo approach, simulation models can be constructed from relatively simple interacting objects that capture the essential behavior of the components that they represent. Such models are capable of reflecting the complex behaviors of the systems that they represent in a natural and realistic way.
4.8.3 Developing Performance Measures for New Technologies
Authors: Mirchandani Chandru
Published: November 2014

To justify the research of new technologies is often fraught with a sense of foreboding. This is because the technology under evaluation is “new” in terms of use. The classical theory of reliability states that historical information on a process or system improves the reliability of the process or system. The Bayesian camp prefers to state it as the decrease in the degree of uncertainty in the success of the process or system. To assist a system development team to decide when, if at all, how and what new technology should be used in their new development is non‐trivial. However, if the performance measures are stated early and very concisely, this methodology can be used to provide a relative table of merit. This paper describes one aspect of technology selection and illustrates how the process can be used to select the technology of choice.
5.8.2 How does AP233 support a Systems Engineering process (e.g. ANSI/EIA‐632)?
Authors: Johnson Julian , Bailey Ian
Published: November 2014

The development of the Systems Engineering data standard AP233 was initiated and pursued by the work of the SEDRES and SEDRES‐2 projects during 1996 through 2001. Subsequently Modular‐AP233 has been under development, building on the experience of the SEDRES/AP233 data model, and extending the scope with additional Systems Engineering concepts. This document explains how a data standard such as AP233 provides support to a practical systems engineering process, in at least two ways, firstly by providing clarity to systems engineering concepts and secondly by enabling practical support to interoperability of systems engineering support tools. The support is illustrated primarily in the context of ANSI/EIA 632.
5.8.4 The Boeing Standard Systems Engineering Approach To Systems Architecting and Its Application To The V‐22 Osprey
Authors: Bruff Robert S , Dagli Cihan H
Published: November 2014

This paper describes the Boeing standard systems engineering approach, or process, to systems architecting and its application for the Engineering and Manufacturing Development (EMD) and Low Rate Initial Production (LRIP) phases of the V‐22 program. It is applicable to both MV‐22 (the Marine baseline configuration) and CV‐22 (the Special Operations Forces (SOF) configuration). (This is a joint program under the overall direction of Naval Air Systems Command (NAVAIR).) It details the integration effort of design engineering, specialty engineering, test engineering, supportability and manufacturing engineering to meet cost, technical performance and schedule objectives. It defines the systems engineering management process for design, development, test and evaluation tasks required to progress from an operational need to deployment of a well architected and subsequently successful operation of the V‐22 system by the customer.
1.1.3 A Quantitative Methodology for the Optimal Selection of Design Margins in Complex Systems
Authors: Snape Simon , Sen Pratyush , Whittle Steve
Published: November 2014

Design margins are the additional performance capability incorporated into a system to compensate for uncertainties. It is common place for uncertainties to be allowed for by introducing design margins based on experience. However, there is currently great interest within industry in applying robust and probabilistic methods, as the arbitrary selection of design margins is inappropriate in today's design ‐ to ‐ cost environment.

With this in mind, this paper presents a novel quantitative methodology developed to estimate and select design margins in an optimal and robust manner. Particular attention is given to design margins in a performance context, i.e. design margins intended to improve the probability of a system/process performing to requirements.

Furthermore the link between Design Margins and Critical Design Features (a sub‐set of top level product attributes / requirements that are agreed as being critical to project success) is explained and an approach to determine and manage both is introduced.
1.2.1 Introducing new technical and methodological requirements in avionics systems safety engineering
Authors: CAPIRCIO Patrice
Published: November 2014

Avionics safety is under facing new technical and methodological challenges.

After a description of the actual safety process required by airworthiness regulation, the main new technical concerns to deal with are presented, one of the most important being software errors. THALES AVIONICS is under implementing a new safety engineering process providing a way to cope with these new technical requirements and fully compliant with new methodological ones such as ISO 9001 V2000 and CMM‐I.

As a conclusion, a brief identification of the other challenges being expected in the near future is given and the capability of the THALES AVIONICS process to deal with is stated.
1.5.3 Is SE Evolving Fast Enough?
Authors: Ring Jack
Published: November 2014

Attendees were polled at the end of the INCOSE 2002 panel session, “Is SE Evolving Fast Enough? This paper reports the questions and attendee responses as well as the author's interpretations of the responses. Two important conclusions are; 1) SE is not evolving fast enough and 2) key opportunities for evolving the practice of SE are not being pursued. This poll should be considered only a quick look at the issue. The purpose of this paper is to motivate INCOSE to conduct a more comprehensive survey of SE practitioners regarding the issue.