bluuebunny/crossref_metadata_2025 huggingface dataset:
1.1.1 Architecting Space Systems
Authors: Warmkessel Joyce , Kaliardos William N.
Published: November 2014

This paper describes current research in a new process for architecting space systems. It has been observed that traditional systems architecting processes tend not to be followed in practice. Research shows that a single point solution is determined very early, long before the implications of this decision are fully discovered, and the solution is only abandoned when it becomes impossible to implement.

This research sets forth an alternative process that provides designers with sets of potentially novel, optimised architectures on which to focus. The process emphasises placing team effort on problem understanding and formulation, versus brainstorming designs within a prematurely constrained architecture. An important step involves representing space architectures as major functions rather than specific forms, allowing brainstorming of the “whats” versus the “hows.”

This paper presents the major steps in the process, applied to a distributed satellite swarm for measuring the ionosphere. Simulation results are also presented.
5.1.1 Keeping the Focus During Requirements Analysis
Authors: Carson R. S.
Published: November 2014

The requirements analysis process can have difficulties and diversions which work against success using the standard flow processes. This paper examines seven key problem areas and shows how they can be treated in a disciplined manner to ensure more success during the requirements analysis process. The treatment herein is intended to serve as a reminder of things generally known to practicing systems engineers but often overlooked or neglected in the rush to complete projects. Attention to these items helps catch problems before the design or fabrication is finished, helping to reduce costs of rework. This set of tools can be easily used as review criteria for those needing to develop, manage, design to or verify requirements.
2.2.4 A System Approach to Evaluate Mission Based Flight Performance of Air Ambulance Helicopters
Authors: Kachab D. , Kusumo R. , Sinha A. K. , Hoffmann P. H. , Scott M. L. , Hogan P. , Laycock K.
Published: November 2014

The type of mission systems and the number of crew on board “air ambulance helicopters”, are mission dependent. To evaluate the system effectiveness of the helicopter, with systems and crew on board, requires a holistic study of the mission capability, flight performance, reliability, maintainability and cost. A set of system methodologies are required to evaluate and integrate these parameters to study the mission effectiveness. In this paper a methodology is developed to evaluate the flight performance from a system perspective. The methodology is demonstrated by considering an example helicopter in an air ambulance role on an “incident medical response mission“.
6.2.2 “Shoot the Modelers & Begin Design”; Focusing Analysis on Design Using a System Model
Authors: Steiner Rick
Published: November 2014

One of the principal pitfalls of model driven system development is the establishment and enforcement of appropriate stopping criteria. Without it, good system modelers will continue to add unnecessary detail, and bad system modelers will gloss over important issues. Establishing the boundaries of system analysis activities has frequently been ad‐hoc, or vaguely documented in planning documents.

Model driven system design promotes the use of a system model, instead of paper specifications, to describe system static and dynamic relationships. This paper explores the use of this system model approach as a framework for specifying and aggregating analysis activities, and as a mechanism for assessing completeness and consistency of the resulting system concept over time.
8.2.3 A Joint Government & Industry Initiative for Smart Acquisition
Authors: Haysman Peter , Hall Simon
Published: November 2014

This paper gives an overview of a study conducted on behalf of the Future Artillery Weapons Systems (FAWS) Integrated Project Team (IPT) of the UK Ministry of Defence, Defence Procurement Agency (DPA), with BAE SYSTEMS.

The initial aim of the study was to provide an insight into the interactions amongst the FAWS programmes & projects, and their respective links to external programmes & projects to provide an understanding of the overall systems architecture of the FAWS IPT.

A background to the investigation is given from the stimulus of the UK MoD Smart Procurement Initiative (SPI) together with the approach adopted for the study, the data collection process and the tools & methods applied and a selective overview of the issues.

As a result of the study activity a number of observations were drawn by the authors on potential implications for the “bigger picture” of capabilities acquisition, including critical inputs and outputs required of acquisition stakeholders and models of Incremental vs Mid Life Improvement (MLI) acquisition and these are presented in overview.
2.3.2 Towards a Knowledge Based Soft Systems Engineering Method for Systems of Systems
Authors: Staker Rod
Published: November 2014

A knowledge based soft systems engineering method for systems of systems investigations is described. The method is based on a combination of the positive features of existing methods from the systems engineering, management science and knowledge engineering literature. The methods on which it is based include Conventional Systems Engineering, Personal Construct Psychology, Quality Function Deployment, Soft Systems Methodology, Distributed Knowledge Engineering and Critical Systems Heuristics. It seeks to enable geographically dispersed participants to collaborate fairly to make joint knowledge about their collective needs and preferences explicit, and to capture these in a structured form in an electronic knowledge repository. Once such problem knowledge has been captured in a structured electronic form, automated reasoning techniques may be used to support decision‐making concerning actions to take to resolve problems and take advantage of opportunities. These reasoning techniques might include artificial intelligence based techniques such as rule‐based reasoning, probabilistic reasoning and constraint logic programming, as well as multi‐objective mathematical programming under uncertainty techniques.
3.3.4 A Systems Engineering Based Tool For Municipal Solid Waste Management In Hochiminh City
Authors: Tu Nguyen Viet , Doukas Louis
Published: November 2014

Traditionally, waste management planning has been put into the technical, environmental and economic context only, and solid waste management (SWM) focused largely on technology. Under increasing pressures on resources (of land, energy, finance, and environmental quality), legislation, living standards, public response to ecoenvironmental pollution, it is clear that SWM is becoming increasingly an social‐technical profession, and should be examined in a broader context rather than that of traditional approaches.

For the first time in Vietnam, the paper indicated using systems approaches and methodologies to engineer an integrated conceptual systems model. It found that twelve areas should be changed systematically in order to improve the whole municipal solid waste management (MSWM) operations for meeting future challenges and needs in terms of management, organisation, technology, ecoenvironment, economics, urban planning, and legislation.

It concluded that systems engineering (SE), when combined with other social approaches, could help managers in their decision making and strategic management planning processes related to topics such as administration structure reforms, policy making, financial structure establishment, service development and performance enhancement, technology selection, processes and procedures innovation in MSWM.
6.3.1 Pilot application of the Object Oriented System Engineering Method (OOSEM) using Rational Rose Real Time™ (RRT) to the Navy Common Command and Decision (CC&D) Program
Authors: Steiner Rick , Friedenthal Sanford , Oesterheld Jerry , Thaker Gautam
Published: November 2014

The introduction of an object oriented systems engineering method and tool was assessed during a short duration pilot project on the Navy's Common Command and Decision (CC&D) program. The pilot determined that the method/tool offers significant benefit for specifying and designing a complex command and control system relative to traditional approaches. This paper describes the pilot approach, summarizes the object oriented methodology and tool evaluated, and presents some of the significant findings.
6.3.3 Emergence: Open Your Eyes to New Vistas
Authors: McConnell George R.
Published: November 2014

A paper presented at INCOSE 2000 (McConnell, 2000) outlined some of the issues which arise as Systems Engineers grapple with the emergent behaviour, properties and capabilities which complex systems exhibit. Using traditional methods of modelling in the traditional way often results in an inability to understand why the emergences happen, when they will occur or how to minimise their impact.

This paper builds on that introduction and offers for consideration the idea that the most fundamental thing which must be done is to avoid the trap of viewing the system only from the perspective that the Systems Engineer feels most comfortable with. While it is not possible to remove all problems this way, some of the difficulties can be ameliorated by the judicious use of currently available modelling techniques. The paper also suggests a new perspective on modelling itself ‐ modelling for understanding rather than modelling for prediction.
8.3.1 A New Graphical Systems Engineering International Standard: ISO/IEC 15909 for High‐level Petri Nets
Authors: Billington Jonathan
Published: November 2014

The International Organisation for Standardisation (ISO) and the International Electrotechnical Commission (IEC) have a Joint Technical Committee (JTC1) for the promulgation of Information Technology Standards. JTC1 is divided into a number of subcommittees (SCs), with SC7 having carriage for Software and Systems Engineering Standards. Working Group (WG)11 of SC7 has been developing standards in the area of Software Engineering Data Description and Representation. One of the standards developed by WG11 (ISO/IEC 15909) is for the specification of distributed and concurrent systems using high‐level Petri nets. This standard has now reached the status of a Final Draft International Standard, and hence its technical content is fixed. The final ballot should be held in the middle of 2001. This paper provides the background, scope, justification, current status and future directions of this project.
8.3.4 Enhancing Conferences and Symposia using Web Based Asynchronous Techniques1
Authors: Kasser Joseph
Published: November 2014

This paper describes ways to enhance conferences using Web‐Based asynchronous techniques and their advantages and disadvantages as compared to a traditional synchronous face‐to‐face conference. The paper also treats the development of the prototype WebConference as a Case Study, discusses the prototyping experiments using the world as a laboratory and provides several lessons about the requirements and systems engineering processes.
4.4.4 Functional Modular Design: Towards a Methodology for Managing Uncertainty
Authors: Humphries Josh , Radcliffe David
Published: November 2014

This paper presents the concept for a methodology, Functional Modular Design (FMD), being developed to assist systems engineers to manage technical, operational and commercial uncertainties as they develop systems concepts. This methodology is being developed and refined through an iterative process of reviewing design practice involving modularity, proposing elements of the methodology and conducting industry case studies. This process is described and an example of a case study is presented. The FMD method consists of a three‐phase process of using guidelines to synthesise a candidate design concept, a life cycle cost (LCC) analysis based on many possible operational scenarios and the identification of areas for system improvement. A set of four basic FMD guidelines are presented and their application discussed. The wider implications for this approach in systems engineering are explored.
5.4.1 Data for Management: Readiness Measurement and Sustainability Assessment in the RAN
Authors: Saunders D.S. , Brown J.R. , Doukas L. , Brash W.
Published: November 2014

This paper examines data for management within the Royal Australian Navy (RAN) preparedness management system. Data for management presents a significant challenge, and in this paper we explore some of the issues that need to be addressed before a future RAN preparedness management system is architected to achieve quantitative and objective cost/capability decisions.

We examine how data is exchanged in the management process, the operational view of the preparedness management system and the nature of the data used in the management process. Within the context of the nature of data, we examine a classification of data that may be used to represent its contribution to the management processes. This classification of data provides a basis for a brief discussion of the significant issues that need to be addressed in the architecting process of data for management.
5.4.3 What Is Senior Management Commitment?
Authors: Sheard Sarah
Published: November 2014

Almost all change management guidance emphasizes that without senior management commitment, true change is difficult or impossible. Yet little guidance is available that describes in detailed terms what actions senior managers must take to demonstrate such commitment. This paper draws on the author's experiences in change management (primarily in implementing capability models) to discuss what senior management commitment means in practice. Senior managers must understand and then act upon five principles. Senior managers establish a common vision of an improved organization, demonstrate their commitment by actions that are taken “in the heat of battle,” engage other managers, provide resources, and actively address organizational incompetence. Examples are given of actions that demonstrate strong commitment and of actions that convey a different message. Change programs are most likely to succeed when the commitment is strong and clear.
7.4.1 Australian Experiences with CMMI
Authors: Rout Terence P. , Tuffley Angela , Marshall David , Pitman Adrian
Published: November 2014

The CMMI Evaluation Project is an initiative established by the Australian Defence Directorate of Software Acquisition Reform (DSWAR) to determine the effectiveness of using the CMMI for risk assessment of suppliers capability in systems & software engineering. An objective of the overall reform program is to encourage Australian Defence industry to use such models for establishing process improvement programs. As part of the evaluation strategy, the use of CMMI in assessments is being trialed with a few invited suppliers to ascertain the impact and effectiveness of the model and the assessment method from both an industry and Defence perspective.

This paper gives the findings from the initial pilot assessments conducted. The results include an analysis of the effort requirements for the assessment; an examination of the conformance issues identified with respect to ISO/IEC TR 15504 ‐ Software Process Assessment (ISO/IEC, 1998); together with observations on the assessment process, particularly on data collection practices and the development of team consensus. The paper focuses on lessons learned from the pilot assessments, both in terms of their contribution to the CMMI Development Project and their relevance to the wider audience of users of the SW‐CMM and EIA/IS 731, particularly in Australia, and the goals of DSWAR.
7.4.2 EIA/IS‐731 to CMMI – A Guide for Transition
Authors: Clouse Aaron , Wells Curt , Schoening Bill
Published: November 2014

The Capability Maturity Model® Integration (CMMISM) project has integrated the Capability Maturity Model for Software (SW‐CMM®) version 2C, Electronics Industry Alliance (EIA/IS‐731) Systems Engineering Capability Model version 1.0, and the Integrated Product Development Capability Maturity Model (IPD‐CMM) v0.98a. For the systems engineering community that has been using EIA/IS‐731, this integration of CMMs has resulted in many changes to the practices and amount of information contained in the model. The purpose of this paper is to provide guidance for transition to CMMI by describing differences in the models that should be considered in making the transition.
8.4.3 Systems Engineering MegaPractices – Identification, Assessment and Redundancy By Object Analysis and Modeling
Authors: Beshore David G.
Published: November 2014

What happens when practices and disciplines overlap? – Wasted efforts, turf battles, redefinition of lifecycle models based on different management, engineering, manufacturing, finance, maintenance and support viewpoints. In short, a proliferation of the ‘way we do things around here’.

Systems engineering has become a set of complex processes that are difficult to implement and improve. Too often, either sub processes are developed for lower tier Integrated Product Team performance or for large enterprise level practices which are promoted as ‘Best Practices’ (Heibler 1998). Most often, the linkage at different levels of abstraction is very difficult to see, much less apply. These are difficult to implement for management of larger and smaller projects. Also many projects in an enterprise are at different stages of development, which makes process improvement across the organization difficult to assess and implement.

Lifecycle ‘Practices’ and ‘Standards’ are generated as panaceas for good systems engineering and are evidenced as:

Systems integration,

Systems design,

Systems validation,

Software engineering,

Design to Cost (DTC),

Design for Manufacture and Assembly (DFMA),

Cost as an independent variable (CAIV),

Affordability,

Quality Function Deployment (QFD),

Supply Chain Management,

Robust Design,

Risk management,

Requirements management,

Time‐to‐market, and

Just‐in‐Time Manufacturing

The purpose of this paper is to show how a set of capability improvement models (SW‐CMM 1995, SECM‐EIA731 1998, CMMI 2000, ISO 9001 1994, ISO 15504 1998) and process definition standards (IEEE1220 1998, EIA‐632 1998, ISO 15288 2000, and ISO12207 1995) can be used to test these megapractices for commonality and redundancy. Object oriented (OO) techniques are be used to: 1) identify the validity of megaprocesses, 2) determine which processes belong to megapractices and are common throughout the chosen set, and 3) assist assessors and process improvement practitioners in selection and optimization of best set of practices for the top level enterprise down to team level performance. Conclusions from this analysis are:

Systems Integration includes Design Reviews, Integrated Schedules, and Integrated Planning

CAIV includes Trade Studies, Requirements, Risk, Cost, Performance (TPMs), and Decision Making

Software Development is a large subset of Systems Integration in software‐intensive systems
8.4.4 Integrating a Geographically Distributed Team using Commercial Technology
Authors: Musani Riaz , Mosher Todd
Published: November 2014

Current web‐based information management systems (IMS) offer a wide variety of tools for a team to work with in a virtual environment. When choosing such a system, users should envision possible tools required and supplemental processes to develop effective communication architectures. This paper discusses the approach that the Polar Night team used during a 9‐month proposal preparation phase to develop a virtual team from ten geographically diverse/distributed organizations, and the lessons learned from combining commercially available IMS to develop an integrated systems engineering application.
1.6.3 Towards a Systems Engineering Framework For Tranportation Systems Simulation as Requirement Validation Tool
Authors: Dhalgren Joy , SAHRAOUI Abd‐El‐Kader
Published: November 2014

Transportation improvements have been and will be an important concern of public policy makers, transport agencies, and transport economists. To address this concern, we propose applying system engineering concepts and techniques and mainly to use simulation as a requirement validation tool to assess the extent to which possible improvements would meet the requirements of various stakeholders. We will use a multi‐level requirements approach and simulation by abstraction. The approach will be limited to highlight the importance of such a tool for decision support in the requirement steps.
1.6.4 Requirement Management Versus Models
Authors: Stemm Douglas J.
Published: November 2014

This paper will discuss the experience of two projects that wanted to manage requirements and design their system using a model‐based design process. The effect on the engineering community was significant. Trying to use requirement management tools that are specification‐based in a model‐based design process also had problems. The experiences of these projects will be used to form conclusions that will be of benefit to other projects that want to move into model‐based design.
4.6.3 The Real Requirement for future complex military systems – more than just the Operational Need?
Authors: Rabbets Tim , Emerton Simon , Bradley Steven
Published: November 2014

This paper shows how the real requirement for complex systems is not only driven by the operational need but also by the implementation technology and even by elements of the engineering process.
8.6.3 Systems Thinking Applied to Teaming
Authors: Hoheb Albert C. , Polokoff Elyse , Tilney Lindsay
Published: November 2014

The Aerospace Institute (TAI) provides the learning environment for staff at The Aerospace Corporation (a Federally Funded Research and Development Centre). The staff averages over 23 years of industry with advanced degrees. Our knowledgeable space engineering and scientific staff particularly challenges TAI when presenting concepts related to teaming.

Most people equate team‐related training as applied psychology. This may make engineers and scientists uncomfortable. TAI applied systems thinking to the description of teaming and found some surprising results. It yielded a multifaceted Team Map. One facet reveals the team‐based competencies, such as roles and responsibilities. Another facet conveys the team life cycle and the specific attributes for each role in the life cycle phase. The third useful facet provides the associated data of team relationships. The map has several practical applications; it provides a reference for teams, a descriptor for tool application, and a source to develop team diagnostics. The Aerospace Institute used it in curriculum evolution to differentiate among its team related course offerings.
8.6.4 A CDROM Systems Engineering Book of Knowledge (CD‐SEBOK)
Authors: Beshore David G. , Patmor Lynette L. , Wilson Willie B.
Published: November 2014

Since 1997, our systems engineering (SE) process organization developed tools, techniques, and methods using commercial‐off‐the‐shelf (COTS) tools and Internet Servers to collect and deploy systems engineering knowledge. The phases of development described, herein, explain the rapid growth and contributions that began with a single dedicated web‐based PC server and culminated in a CDROM‐based Systems Engineering Book of Knowledge (CD‐SEBOK) from a network of servers.

The development steps included:

Initially providing content on a single SE process –‘requirements’ on prototype server (1997), then

Expansion to six (6) processes for the entire SE department (1998), then

Validation of content by process owners (1998), then

Transfer of content to CDROM to provide a virtual web, version control and personal search engine, (1999)and finally,

Expansion of content from multiple business site websites (1999) and then

Recapture on CDROM (2000).

Content is currently 640 Mbytes of highly linked (8300 hyperlinks) information related to systems engineers and is considered to be a book of knowledge for systems engineers throughout the company. The content also is used in internal and external assessments for the Capability Improvement Models, such as SW‐CMM, CMMI and SECM (EIA‐731).

The development process included many object‐oriented (OO) methods that provided a complete and efficient method to gather requirements for the server and the development of a CDROM with a powerful search engine. These methods include uses cases, content classes, collaboration, sequence, state and deployment diagrams. A new lifecycle method, called Synchro‐Xtm (Beshore 1999), was used during the specification, design, build and verification phases to reduce risk during development along with object oriented techniques (Ericksson 1999). The model forces different reviews among distinct teams to provide necessary inputs during product development.

The development of the CD‐SEBOK contained inherent risks:

Lack of Resources or Commitment

Requirements Misunderstanding

Misunderstanding of Web Content Scope

Inadequate Password Protection

Information Security Misunderstanding

SE Common Processes Not Identified at Business Site Level

The integration team (20 people from various business sites) was responsible for identifying and managing risk that might preclude successful completion of the team's responsibilities and implementation of the CD‐SEBOK. It was the responsibility of each team member to constantly evaluate and identify any issue/problem that could adversely impact the CD‐SEBOK.
4.7.3 Assessing Requirements Engineering Processes with the REAIMS Model: Lessons Learned
Authors: Kauppinen Marjo , Kujala Sari
Published: November 2014

Organizations are becoming increasingly interested in improving their requirements engineering processes. The assessment of the current situation is the first step towards systematic process improvement. The REAIMS model (Sommerville et al. 1997) has been developed to evaluate the status of existing requirements practices. This paper describes an assessment process and two assessment instruments that can help organizations to use the REAIMS model. We evaluated the model, the process and the instruments by performing an assessment in three organizations. The results of the study indicate that the REAIMS model provides useful information for communication, motivation and process improvement planning. REAIMS assessment results are dependent on assessors, and are therefore not reliable for long‐term monitoring and benchmarking as such. A systematic assessment process such as the one described in this paper can improve reliability of assessment results.
5.7.1 On Soft Data and Test & Evaluation
Authors: Sproles Noel
Published: November 2014

The test and evaluation of complex socio‐technical systems is difficult. This is especially so when those involved in the testing and evaluation of such systems tend to associate closely with the physical sciences. The social or behavioral sciences have developed methods to address such problems and have shown that these methods are capable of providing rigorous results. A discussion of the worth of qualitative data and an overview of the social science methods likely to be appropriate for evaluating complex systems involving humans is provided. A brief overview of an instance where qualitative data analysis methods proved useful in the evaluation of a military command and control system is discussed in order to illustrate the merit of social science methods for T&E
7.7.2 The Mission System Design Center: A Pilot of Formulation‐Phase Concurrent Engineering in Aerospace Design
Authors: Wall S. D.
Published: November 2014

In this paper we describe pilots of a concurrent‐engineering, formulation‐phase design team demonstrated in spacecraft missions. This “Mission Team” operates within a design center called the Mission System Design Center, where design tools are linked via a central database and use large‐screen projection systems to engage the entire team in system‐level trade discussions. In these pilots, the Mission Team was able to manage complex trades, resolve conflicts, and rebalance requirements in the face of typical formulation phase issues. This team operates to periodically re‐evaluate requirements and resource allocations (e. g., mass, power, funds, datarate) in the face of both externally and internally imposed changes.
2.1.3 Functional Analysis for Existing Products: a Detailed Procedure
Authors: Lentz V. A. , Lerner Bruce
Published: November 2014

Functional Analysis (FA) for regenerative systems is often executed as reverse engineering or design recovery. The initial product developer completed the Functional Analysis, and minimal updates were required or took place as the product evolved. The working definition of a function has often become ambiguous. When the goal is to reify what the product / system does, Functional Analysis is one method to be used in conjunction with the identification of the scenarios to support a system decomposition to discover underlying functions. The scenarios identify how the system / product is used by external systems (a human or other man‐made system) and FA helps to expose the system behaviors that are required to support that use, and the functions that are required to support that behavior. The value of functional analysis is the yield of the main and derived functions of the system / product, which are the solution independent functions. The separation of the domain functions from the subsequently developed implementation functions (those required to provide a design dependent capability) facilitates the insertion of technology and management of change.

The transition of the modular product structure Adifon [ADI2001] from the Phase 1 team to the on‐going implementation required the clarification and documentation of a procedure for Functional Analysis. The generic part of that procedure is described here with templates and detailed ‘user’ instructions.
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

The 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

This 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

Computer 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

The 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

Agent‐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

The 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

The 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

This 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

An 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

By 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

This 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

This 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

There 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

Path 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

How 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

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