bluuebunny/crossref_metadata_2025_split huggingface dataset:
4.1.1 Applying Integrated Product and Process Development (IPPD) on the U. S. Army Multi‐Role Armament and Ammunition System (MRAAS)
Authors: Moulder Roger D. , Engineer Matthew V. CilliLead Systems 
Published: November 2014

AbstractThe following quote was made by then Secretary of Defense, Dr. William Perry, on 10 May 1995.“…I am directing a fundamental change in the way the Department acquires goods and services. The concepts of IPPD and IPTs shall be applied throughout the acquisition process to the maximum extent practicable.”The purpose of this directive was to help reduce the “cost of the acquisition process by the elimination of activities that, although being performed by many dedicated and hardworking personnel, are not necessary or cost effective in today's environment.” Subsequently, the DoD Guide to Integrated Product and Process Development was released. This guide defines IPPD as, “A management process that integrates all activities from product concept through production/field support, using a multifunctional team, to simultaneously optimize the product and its manufacturing and sustainment processes to meet cost and performance objectives.”Since 1995, the various components of the United States Department of Defense have been implementing IPPD by allowing program managers the flexibility to choose the best IPPD practices and tools available for their programs. Much of the focus has been on acquisition programs, but the use of IPPD is now being pushed back into the Science and Technology (S&T) area as well. In fact, the Air Force Research Laboratory policy now is to use IPPD on all Advanced Technology Demonstration (ATD) Programs. The U.S. Army has also applied IPPD on several S&T programs such as the Future Scout Cavalry System (FSCS).This paper presents the results of applying IPPD on the U. S. Army Multi‐Role Armament and Ammunition System (MRAAS) Munition Suite Program. We first introduce the MRAAS Munition Suite Program and the rationale for the IPPD Process USFD—including the definition of the systems engineering process and tools. We then discuss the specific application of this process on the MRAAS Munition Suite Program. An overall objective was to apply the systems engineering process early in the life cycle of the system beginning with concept definition through manufacturing development into full‐scale production. In this discussion, we describe the unique approach that was used in the Request for Proposal (RFP) and subsequent contract award. We conclude with results to date of the application of the IPPD Process and offer observations for application to other Defense programs.
6.1.5 Dynamic Interface Management in a Transport Infrastructure Project
Authors: van der Laan Jan , Wildenburg Lion , van Kleunen Peter 
Published: November 2014

AbstractThis paper describes how Systems Engineering methods have been applied for the specification and interface management of the Dutch high‐speed line project (HSL‐Zuid), and the lessons which have been learned from this experience. This project is complex both in size and in the number of internal and external interfaces. The management of these interfaces is a challenge for which Systems Engineering provides a good approach, but the application is different from the applications in other industries. The focus of this paper is on the interface management of Design & Construct type contracts with high level functional specifications.
1.2.1 Computer Based Training: A Structured Solution Accommodating Diverse Learning Situations
Authors: Arnold Eileen P. 
Published: November 2014

AbstractComputer Based Training (CBT) courses have solved several of the inherent problems associated with the previously preferred Instructor Led Training (ILT) delivery in industry. The problems associated with Instructor Led classes as a one‐size fits all solution to education and training are identified. A CBT solution, a self‐paced learning solution, is explored as an additional choice to accommodate diverse learning situations and knowledge levels. This Case Study continues with an overview of curriculum development, processes used to develop the CBT courses and learner acceptance.
3.2.5 A Risk Management Approach For Effective COTS Acquisition and Life Cycle Support
Authors: Shaffer Gordon 
Published: November 2014

AbstractThe use of commercial‐off‐the‐shelf (COTS) products as part of an acquisition strategy has continued to present unique challenges to both acquisition and user organizations including the Federal Aviation Administration (FAA). Using a system engineering‐based programmatic risk management approach, the FAA has developed a risk mitigation methodology adapted to the acquisition and life cycle support of COTS‐based systems. Based on industry and government “lessons‐learned”, this methodology addresses COTS‐specific risk factors and practical acquisition‐phased risk mitigation strategies for both new and existing systems. It also provides a structured COTS obsolescence analysis process to establish the long range‐planning horizon needed to effectively support rapidly evolving COTS products. Having developed a COTS Risk Mitigation Guide and associated courseware, the FAA is equipping its personnel with the tools to support more informed program management decision‐making as part of the FAA's ongoing National Airspace System (NAS) modernization efforts.
4.2.4 Human‐agent Collaboration: Ontology and Framework for Designing Adaptive Human‐agent Collaboration Architectures
Authors: Madni Azad M. , Lin Weiwen , Madni Carla C. 
Published: November 2014

AbstractAgent‐based systems are continuing to gain in popularity as agent design tools and agent communication languages continue to mature. Today, agents have begun to play a variety of roles with respect to humans in agent‐based systems. As a result of these developments, the systems engineering, human factors, and cognitive sciences communities have begun to focus on the shared role of human and software agents in problem‐solving and decision making with a view to optimally leveraging the human component. This paper presents accomplishments to date on an ONR‐sponsored research initiative concerned with the development of a cognitively‐inspired, multi‐perspective conceptual framework for designing adaptive human‐agent collaboration architectures. Such architectures are capable of supporting dynamic function reassignment – the key to capitalizing on the human role in agent‐based systems.
4.2.5 Requirements Management by the Numbers Applying Common Criteria beyond the INFOSEC Arena
Authors: Kepchar Kenneth J , Yeager Julie 
Published: November 2014

AbstractThe security function has taken on a dramatically increased importance around the world with the events in New York and Washington in September 2001. As we search for ways to address the altered realities of today's society, the tendency is to create “different” or “unique” approaches to current problems. In the information security (or INFOSEC) realm, Common Criteria (CC) (ISO 15408) documents an international approach to formulating information security requirements. The CC structured methodology is discussed to show its potential application to other Systems Engineering applications. This provides a means to develop consistent and coherent requirement sets. The CC has also established a set of domain specific terms. This paper analyzes the CC terminology to show that CC utilizes the same guiding principles and program milestones as other Systems Engineering disciplines. In the process, we provide a mapping of the CC terminology to that commonly used in non‐security Systems Engineering domains.
5.2.5 Toward a Mathematical Theory of Systems Engineering Management
Authors: Honour Eric C. 
Published: November 2014

AbstractThe practices of systems engineering have high value in the development of complex systems. Heuristic wisdom contains several important relationships in systems engineering management, among quantities such as technical “size” and complexity, systems engineering effort, quality, schedule, cost, and risk. This theoretical paper explores quantitative relationships of these variables, portraying expected values. The paper further explores the benefits and drawbacks of each relationship, the cohesive structure of the relationships, potential usefulness, and the type and rigor of research necessary to prove each.
6.2.5 Supporting Concept Development Using Quantitative Requirements Traceability
Authors: Sutinen Krister , Almefelt Lars , Malmqvist Johan 
Published: November 2014

AbstractThis paper presents a product modeling system that supports the systems engineering process including qualitative and quantitative requirements traceability, and demonstrates its application in a case study of a passenger car cockpit. The system features a user interface that enables rapid trade studies. The paper further discusses how to introduce simulation models in the product development process and what kind of simulation models can be used during different development stages.
9.1.1 Analysis of Human factors in Specific Aspects of System Design
Authors: Balakrishnan Pradeep K 
Published: November 2014

AbstractAn important aspect of system design is the human factor. Human factor must be taken into consideration at every stage of system design. This paper discusses human aspects in specific areas of system development life cycle. The importance, relevance and significance of human aspects of each stage are discussed herein. The covered areas are system requirements, communication, environment, interface design and layout, ergonomics, training content and procedures and decommissioning.
9.1.2 Structuring a Systems Engineering Program at UALR
Authors: Chan Yupo , Iqbal Kamran , Al‐Rizzo Hussain , Liu Xian 
Published: November 2014

AbstractBy all measures, we have founded a successful Systems Engineering program in response to industrial and state requirements. Being a new program, however, the faculty and administration have both learned from the experience over the three years since the program was instituted. Given the dearth of systems engineering programs, a major challenge is to recruit formally trained systems engineering graduates. Another is to reach a consensus on the goals and content of our program. This paper reports this learning process.The University of Arkansas at Little Rock (UALR) is a regional university serving primarily the people of Arkansas. One half of the population in the state of Arkansas lives within 100 miles of Little Rock. The Little Rock metropolitan has a population of over 500,000. UALR is a member of the University of Arkansas system, which consists of eight campuses. UALR has approximately 11,500 undergraduate students and 1,500 graduate students. UALR offers bachelor's degrees in Engineering, Science, Education, Arts, and Humanities. It offers master's degrees in several areas, and doctoral degrees in Applied Science and Education. UALR is one of the fastest growing urban universities in the country. As a Carnegie doctoral intensive institution, it is one of several metropolitan universities in the country serving the industrial, commercial, and educational needs of the client population, including minority students (currently UALR's African American population is about 25% of the student body). The mission of the University is to provide the necessary support and access to a quality education for all citizens of Arkansas regardless of background.
9.1.4 Two Views of Systems Engineering: Project‐Centric and System Conception
Authors: Ferris Timothy L.J. 
Published: November 2014

AbstractThis paper discusses two different approaches to understanding the nature and purpose of Systems Engineering. The two approaches to thinking about Systems Engineering involve, on one side, a project level view in which Systems Engineering is seen as a set of processes by which major, complex projects may be addressed and completed on time and on budget and on performance. The contrasting view centres about the conceptual issues of determination of how we can be confident that our projects are appropriate and useful. This paper exposes the two views of Systems Engineering and discusses the relationship between them. The two views are different, and have different emphases, and so are instructive in different ways, but are different views of the same thing. The two views are not opposed and do not, fundamentally, conflict.
9.2.5 A Tale of Two Systems – A Comparative Study of Systems Engineering
Authors: Lister Peter M 
Published: November 2014

AbstractThis paper is a comparative study of two system development projects as a contribution to the demand for evidence of the benefits of Systems Engineering.The treatment is qualitative, but the similarities of the two systems concerned allow useful conclusions to be drawn. The projects were carried out by the same enterprise, used common subcontractors, were developed on similar technical infrastructure and were developed for the same end user. Both projects claimed to be applying Systems Engineering, however the very different outcomes conform to the old adage that says, ‘it ain't what you do, it's the way that you do it – that's what gets results‘,Both projects experienced the usual trials and tribulations that accompany engineering developments, however one system was accepted and delivered whilst the other ran significantly over‐budget and over time. This system was never delivered. The seeds of the problems that afflicted the unsuccessful project could be observed very early in the programme, and had they been addressed the outcome could have been different. The paper helps to support the hypothesis that intelligent use of SE can ensure project success.Projects may claim to use SE without actually delivering a good result. The paper addresses this problem by indicating some common sense observations that can identify weak or ineffectual SE practices.Not surprisingly the identity of the projects is not revealed, and in some cases details have been deliberately altered to ensure anonymity.
9.3.0 On the Transition of a Legacy System to a New System (Upgraded or Otherwise)
Authors: Martin James N 
Published: November 2014

AbstractThere are a number of approaches for dealing with the transition from a legacy system to its replacement (whether a new start or an upgrade). These include systems engineering with precedented systems, unprecedented systems, reused systems, reengineered systems, and systems engineering with COTS products. This paper will discuss the special needs associated with integration due to each of these approaches and their combinations. It will also discuss the considerations that would be involved in determining whether it would be more appropriate to use one of these approaches to the exclusion of the others and the specific role of systems integration in this. Furthermore, an approach is suggested for the planning effort that will, when completed, lead to the engineering of a system involving some mix of these components.
9.3.1 Path Dependence and Network Effects and How they Affect the Engineering and Integration of Systems
Authors: Martin James N 
Published: November 2014

AbstractPath dependence is discussed in terms of how it relates to the engineering of systems. A related phenomenon is network externalities. These two concepts will be described with respect to standards, requirements, architecture, intellectual property, time to market, and the spiral development approach. There will also be a discussion of how path dependence and network externalities influence systems integration at the level of product, process, and policy.
9.3.3 Make Me Autonomous when I Fly: A Systems Engineering Quest and Pilots' Paradise
Authors: Pietras Sherry L. , Dagli Cihan H. 
Published: November 2014

AbstractHow systems engineering practices may bring human cognition into the focus of advanced technology aviation system designs. This includes generating cognitive qualitative and quantitative requirements, as both functional and performance design requirements, early in the system conceptual design phase based on Technical Performance Measures (TPMs). Cognitive TPMs must be formulated and assigned high priorities to ensure they are not lost or compromised during conceptual phase trade‐offs. Otherwise, economic factors will drive automation that may consequently leave the pilot out of the loop. To prepare for the early design phases, systems engineers (SEs) must come to understand the pilot environment and pilot behavior in that environment. The customer's need, and SE purpose, is to optimize pilot situational awareness. Cockpit system designs must satisfy customer and user expectations. This is accomplished by ensuring pilot psychomotor and cognitive skills are kept intact and by monitoring for appropriate pilot workload during all phases of flight.Automated pilot assistants or intelligent agents may change how pilots fly but they do not change the pilot's underlying cognitive and physical make‐up. Therefore, such agents must be able to track and anticipate a pilot's behavior, assess the flight/mission situation, and provide advice in real time. The SE goal is to acquire good communications and teamwork, thus reducing pilot errors and ensuring a healthy crew. Language is a key problem‐solving tool for humans, lending itself readily for pilot adaptation to advanced cockpit technology incorporating voice recognition. All pilot tools are an extension of the pilot's consciousness; the pilot actually thinks with them. Therefore, automated advice must be designed such that the pilot feels the assistant is present in real time.
9.3.5 Internet Marketing In Central and Eastern Europe: Will It Catch Up With the West?
Authors: Sohmen Victor 
Published: November 2014

AbstractThis paper looks at the Internet as a marketing and e‐business tool, and its prospects in Central and Eastern European countries. Some of the impediments to Internet marketing in Central and Eastern Europe are considered. It is recommended that to narrow the gap with Western Europe, the use of e‐projects would provide flexibility and fast‐tracking capabilities to firms in the transitional economies. These countries can also craft strategies consonant with their own historical and cultural legacies. Insights are offered into Internet marketing prospects for Central and Eastern European countries as emerging and promising economies.
9.3.7 Systems Engineering Support Using an Embodied Conversational Agent
Authors: Leibrandt Robert P. 
Published: November 2014

AbstractThis 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

AbstractLess 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

AbstractOver 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

AbstractSystems 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

AbstractThis 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.