bluuebunny/crossref_metadata_2025 huggingface dataset:
SYSTEMS REENGINEERING
Authors: Fisher Gerard H. , Fisher Jack , Pittman R. Bruce
Published: November 2014

The current political environment is causing Congress to reduce the number of new program starts. In response, companies are reducing their research, development and capital investment budgets. Nevertheless, customers are demanding more value in the form of reduced cost, faster cycle time and higher quality products and processes. For a company to remain competitive and grow, it must find innovative means to improve performance. Systems reengineering may provide the “silver bullet.” This paper describes a new INCOSE Working Group (WG) formed by the merger of the Benchmarking and Good Practices WGs. A draft charter for the SRWG is proposed and areas of interest are discussed.
INCOSE Measurement Working Group Report
Authors: MacLean Jeanmarie , Roedler Garry , Antony Patrick
Published: November 2014

This paper provides information on the INCOSE Measurement Working Group (MWG). The charter and goals are presented along with a short history of the working group. The activities from the past year are discussed to highlight accomplishments and future plans. A brief description of each measurement working group product is provided to inform the community of the products available to them.
2.1.1 Synthesis of an Anti‐Terrorist Air Transportation Security System
Authors: Woodhead M A , Priestley D
Published: November 2014

The paper explores how a systems engineering methodology, based on a diagrammatic modeling approach which adopts a variety of viewpoints and perspectives, can be used to develop an initial understanding of the air transportation system (ATS) and an assessment of its susceptibility to terrorist threats. The ATS model is extended and refined in order to incorporate existing security systems, which can be assessed with regard to the susceptible components of the ATS. Similarly, the terrorist threat capability is modeled, providing a means by which future threats may be anticipated. Analysis of the interaction points between the systems allows the air transportation system's vulnerability to specific threats to be assessed. Since there are a large number of potential attack modes, there has to be some rationalization and down‐selection in order to give focus to what are perceived to be the most serious threats. This focus leads to the identification of counter‐measure concepts that can then be built into a comprehensive integrated security system.

Clearly, this topic involves high levels of security restriction. It is not the intent of this paper to enter into confidential or classified topics, but rather to illustrate how a systems engineering approach can be utilized to provide a top‐level introduction to the problem of countering terrorist threats to air transportation in order to synthesize a layered security system.
3.1.3 An Optimization Strategy for Allocating Fault Detection and Fault Isolation Requirements
Authors: Carson Ronald S.
Published: November 2014

To support system maintenance, most deployed systems require some level of fault detection and fault isolation (FD/FI), often expressed as a percentage of faults detected, with a given rate or confidence‐level of fault isolation to a single, replaceable unit. In contrast to the usual method of allocating the identical FD or FI requirements to every replaceable unit, we propose a revised allocation method that optimizes system effectiveness (satisfying requirements for minimum cost). The resulting allocation both satisfies the system FD/FI requirements and provides an optimum solution over all elements of the system by considering the effect of varying failure rates for individual replaceable units.
1.2.3 Difficulties in Using Multicriterion Decision Making Techniques for Tradeoff Studies Selecting Amongst Alternative Concepts
Authors: Bahill A. Terry , Dahlberg Sten O. , Lowe Robert A.
Published: November 2014

When choosing amongst alternative designs, decision‐makers would like to know that the choice of the preferred design is based on knowledge and experience, and not on some artifact of the decision making process. But often, the apparent best alternative is just that, an artifact of the method that was chosen to do the tradeoff study. In our research we applied seven multicriterion decision‐making techniques to some real‐world data sets. We found that the recommended alternative depended on the technique that was used.
2.2.3 Project Management and Systems Engineering: Where the Professions Intersect ‐ Generate Synergy Not Conflict
Authors: Kauffman Donald C.
Published: November 2014

An analysis of standards and guides for both the project management and systems engineering professions is presented which summarizes the areas of unique specialty in each profession and highlights the areas of intersection between the professions. Which profession should dominate the intersection? This paper presents guidelines to help the project stakeholders decide on a synergistic approach to addressing the intersection of the professions.
2.2.4 User Error: Practical Ways to Protect Your System
Authors: Courteney Hazel
Published: November 2014

In civil air transport, at least 70% of accident causal factors are attributed to crew error, so technical reliability is not enough to guarantee safety. There is currently a great deal of discussion about ‘human factors’ in system design. There are text books written on how to create good ‘human centred’ designs; performance failures and accidents are frequently blamed on its shortfalls. This paper will argue that human performance should be considered in system safety assessment, and offers practical suggestions on how to achieve it.

Specific techniques will be presented for:

Risk identification: a systematic method for the identification of risk areas, and the acceptability of the proposed design.

User Involvement: concrete advice on how and when to involve users, what specifically to ask them, and how to collate the results into a single design solution.
5.2.1 Development Life Cycle Mobile
Authors: Kelliher Timothy P.
Published: November 2014

Life cycle models are of continuing interest to systems engineers and management because they provide a structure on which to base decisions and measure progress. The community has yet, however, to settle on a general model with which it is comfortable. Each of the models that have gained popularity over the years have had something to offer but have also failed to capture enough of the essence of the life cycle to provide the desired comfort. The models that have achieved wide use provide an intuitive metaphor, allowing users to quickly understand the status of the system with respect to the model. The life cycle mobile takes another step forward in the search for a comfortable model. It attempts to provide the necessary structure for decision making, maintain an intuitive metaphor, and most importantly reflect the actual way systems get developed.
5.2.5 Using Stakeholder Mental Models to Create An Integrated Conceptual Model for Systems
Authors: Gonzales Regina M. , Lovelace Nancy
Published: November 2014

This paper discusses initial findings from the research and development of a modeling tool that can be used by stakeholders. The goal of the tool is to allow stakeholders, who are not trained analysts, to create the first models of a system at the pre‐requirements stage. The approach we used was to study how people reason about systems as they create initial models of systems. In addition to learning about the models created, we discovered a meta‐language that stakeholders use while reasoning about a system. Both of these are rich sources of information an analyst can quickly use to form an initial integrated concept of the system. This integrated system model (ISM) reflects a more complete system concept than those created using analyst‐driven methods because the stakeholders viewpoints are fully utilized to create the ISM.
3.3.1 Why Don't System Engineers Want To Use System Engineering Tools?
Authors: Hopkins Frank W.
Published: November 2014

Consulting with several different companies over the past few years, I find many system engineering organizations either don't use system engineering tools or don't use them effectively. Reluctance to use system engineering tools impedes effective and efficient system engineering.

Some of the problems are:

Tools force one to do the hard work of system engineering and not gloss over such tasks as requirements parsing

Tools often require one to go to a separate work area

One never seems to finish the job when one uses a system engineering tool

One doesn't have time because of the need for viewgraphs for the next design review.

System engineering tools are complex; they differ in many ways from familiar word processing and viewgraph preparation tools.

This paper will describe some pitfalls in non‐disciplined practice and how tools make the tasks easier. It will stress benefits of using tools rather than stream of consciousness. The paper will give recommendations for making tool use more acceptable.
1.4.2 Simulation Use During the Development of an Aircraft Cargo Handling System
Authors: Salzetti Sarah , Snow Robert
Published: November 2014

This paper describes the use and benefits of a simulation of the 767 freighter cargo handling system. Systems Engineering developed the simulation to support requirements development and validation, and system design and verification. To meet the 767 freighter mission and performance objectives, the cargo handling system was designed around a centralized controller, distributed IO architecture utilizing cargo position sensor feedback. This became the first Boeing cargo handling system using microprocessor based software to assess system status and operator inputs, and to command cargo movement. This paper provides a brief description of the cargo handling system. It also illustrates how the simulation was used to ensure that the system would meet its operational goals without violating the primary requirement of safety for crew, cargo loaders, airline maintenance personnel and the public.
3.4.1 Leading Indicators Of Rework: A Method of Preventing Software Defects
Authors: Stewart Ronald , Holt Peter , John Robert
Published: November 2014

At Raytheon Systems Canada Ltd. (RSCL), it has been found that certain software metrics provide early warning signs of future rework. By using leading indicators early in the software development cycle to identify high risk units, substantial rework can be saved later in the cycle. It is expected that this finding can be replicated on any project with a software review and testing process, development environment, and metrics program similar to that of a RSCL project.
3.4.3 Web‐Based Systems Engineering Application Profiles
Authors: Austin Mark A.
Published: November 2014

Version 1.0 of the INCOSE Systems Engineering Applications Profiles have been published in traditional report form (INCOSE AFWG, 1996). This paper describes the design, implementation, and presentation of Systems Engineering Applications Profiles (SEAPs) on the World Wide by Graduate Students in the Master of Science in Systems Engineering Program at the Institute for Systems Research, University of Maryland, College Park. We believe that the educational and professional benefits of presenting Systems Engineering Application Profiles in a hypermedia format on the World Wide Web extend well beyond simple delivery of data/information. The use of Java Applets for on‐line interactive analysis of simple systems analysis problems will be described. This paper concludes with a summary of the student feedback in this course and our current plans for further development of on‐line applications profiles.
4.4.1 Systems Engineering in the Intensive Care Unit: A Model of Post‐Operative Patient Re‐Awakening Time
Authors: Zaleski John R.
Published: November 2014

In a study of the post‐operative recovery of Coronary Artery Bypass Graft (CABG) patients, it was observed that these patients tended to awaken from the effects of anesthesia at varying rates. Because the time at which patients awoke was critical to latter phases of the study, determining the factors which affected the rate of re‐awakening were of primary importance. To determine the critical parameters which influenced the re‐awakening time of CABG patients, a closed‐form model of the patients' cardiovascular and respiratory systems was constructed to isolate and identify the number of parameters which were thought to affect reawakening time. As a result of this analysis, a mathematical relationship was determined which described the re‐awakening time of a patient as a function of several physiological parameters. These included patient body temperature, body mass, body size, and the quantity of anesthetic (fentanyl) administered during surgery. The work discussed in this paper was performed at the University of Pennsylvania in conjunction with my Ph.D. dissertation requirements.
5.4.3 The Global Information Infrastructure, the Global Information Society, is it a reality?
Authors: Piedras Graciela
Published: November 2014

Digital technologies have opened new opportunities and allowed the convergence of telecommunications, broadcasting and information technologies. In spite of the excitement for the Global Information Infrastructure/Global Information Society, GII/GIS, there are still many obstacles to overcome to be able to achieve it, such as defining standards and protocols, ensure interoperability, interconnection and international cooperation. This paper examines strategic options that can be followed to implement the GII. The analysis addresses how it generates opportunities to develop applications such as in distance learning, telemedicine, trade, etc., and how it can also widen the gap between developed and developing countries if the necessary steps are not taken so as to ensure that the essential technology is available to the countries. Among the means to attain there is a brief overview of regulatory aspects an issue that is a priority if we want to make the GII a reality.
3.5.1 Developing and Applying a Joint SW‐CMM and SECM Appraisal Methodology
Authors: Hollenbach Craig R. , Mosier Steve
Published: November 2014

Periodic appraisals of process maturity as measured by both systems and software maturity models are costly undertakings and divert project engineers and managers from their primary focus. To minimize the cost and impact, a single appraisal method that addresses both systems and software engineering in a timely and cost‐effective manner is needed. This presentation discusses the current state of software engineering and systems engineering maturity models (using the EIA 731 SECM and the SEI CMM for Software) in terms of their commonalties and unique features and describes one company's efforts to develop a joint appraisal method.
5.5.3 Business Process Re‐Engineering: Team Building
Authors: Flowers Shirlee J.
Published: November 2014

This paper describes the re‐engineering of a business process resulting in the implementation of an alternative management structure for a large aerospace engineering services organization. The paper examines some basic concepts for aligning tasks, schedules, budget and people into an effective management and staff with emphasis on the work to be performed. Analytic tools were used to derive the benefits and value of reorganizing the work force into a medium‐sized department of 41 personnel. The results indicate that the reorganization was beneficial in project accomplishment, cost, risk reduction, people satisfaction, and customer satisfaction. In summary, the re‐engineering of the business process improved the management process.
2.6.3 Workshops and Forums for Engineering and Management of Complex Systems1
Authors: Crisp H. E. , Franke M. E.
Published: November 2014

Characteristics of complex systems and systems engineering practices are reviewed. A workshop program (WES‐21) sponsored by the U. S. Navy for promoting wise technology investments in the engineering and management of complex systems in the 21st century is described. Topics and results from the three annual workshops held in 1994, 1995, and 1996 are discussed. Due to changes in the way the Department of Defense (DoD) acquires goods and services, the third workshop was designed to couple the group discussions closely with the DoD mandated concepts of Integrated Product and Process Development (IPPD). The Lean Aircraft Initiative (LAI) program, which is independent of WES 21, is also discussed. LAI is aimed at lean manufacturing principles and practices.
2.6.4 The New Academia: Computer‐Based Distance Learning Case Study
Authors: Worden Gregory
Published: November 2014

Shrinking budgets and increased competition have forced industry to seek new technologies to increase efficiency. The explosive growth of the Internet has brought the promise of inexpensive and novel applications such as GroupWare.

Very quietly, the world next door is undergoing a revolution. Working professionals are returning to continuing education programs to maintain a competitive edge. They demand flexibility in both time and place. Academia has responded.

ActiveClass is one of the new breed of computer‐based distance learning programs. It employs the latest software components in a familiar design that allows students to attend class from the office or at home, virtually anywhere in the world.

The experiences working professionals gain in academia will be brought back to industry. GroupWare is now being used for research and electronic meetings, not only to reduce travel cost but also to engender a deeper collaboration.
5.6.3 The Systems Engineering Life‐Cycle Process Functional Working Group A Government / Industrial Partnership
Authors: Johnson Robert , Cheetham Christina , Fisher Gerard H. , Quinn Anne , Smith Dennis
Published: November 2014

The Department of Defense (DoD) has recognized the relationship between good systems engineering and products that meet the customers' needs. The DoD Joint Logistics Commanders (JLC) Joint Group on Systems Engineering (JGSE) has commissioned a new functional working group called, Systems Engineering Life Cycle Process (SELCP). In July, SELCP sponsored a Systems Engineering Workshop in San Diego. The attendees were experts in systems and software engineering from industry, academia, INCOSE, IEEE and government. The issues associated with this new paradigm were discussed, a forward action plan was developed and expectations for continued cooperation were assured.

This paper will describe the motivations that led to renewed government interest in systems engineering, the results of the San Diego Workshop and future plans for SELCP to collaborate with INCOSE and other industrial organizations. Joint meetings have been held with several working groups of INCOSE and plans are in place for collaboration on new systems engineering products. This cooperation between government and industry will help to ensure high‐quality products that meet customer requirements and expectations.
7.3. Crusader System Engineering Tool Set Continuous Improvement Process
Authors: Eidenschink Bruce , Kee‐Bowling Bonnie , Laedtke Patricia , Sanyal Saumya , Schweikert Tim , Zimmermann Roger
Published: November 2014

Implementation of system engineering tools on large scale development programs require mechanisms that allow for the continued evolution of the selected suite. The initial requirements for a system engineering tool selection will change and evolve as in any system. A program will have changing objectives, champions, and organizations as it progresses through its life cycle. Awareness and use of accepted industry practices for improvement to this type of system have proven vital to its evolution. This paper presents the process and techniques used for evolving one such tool suite within an Integrated Product Development (IPD) organization on Crusader, a major Department of Defense (DOD) development program.

This paper documents 4 years of lessons learned during the support, maintenance, and evolution of the Crusader System Engineering (SE) Computer‐Aided Engineering (CAE) tool environment from its initial selection to its current configuration. The tool set, consisting of Requirements and Traceability Management (RTM), Requirements Driven Development (RDD‐100), and Interleaf, has undergone two process improvement cycles. The process, events, and outcomes are described within this paper.
7.9. Integrated Product and Process Development and the Use of Integrated Product Teams
Authors: Leibrandt Rob , Gunther Dave
Published: November 2014

This paper seeks to examine the importance of Integrated Product and Process Development as demonstrated within the Department of Defense. We have focused on 3 major areas of focus. One is IPPD's focus on product and process life cycle, the second is the way stakeholders are integrated into the process early, and the third is concurrent development of the product and processes.

Focusing on the life cycle means that the IPPD process plans for and manages product and process development from inception to disposal. Stakeholders are defined as important decision‐makers that have a stake in the decision at hand or the outcome of the program. Stakeholders must be included from the beginning. Lastly, we discuss the development of processes concurrently with their products. What are the processes that we want to integrate with the design and development of the product?

Each of these areas is first described in detail and then specific examples of systems development efforts, which employed the technique, are described. Specific benefits and results in these examples are used to “drive home” the importance of integration or concurrency of product and process development.

This paper is the basis for the development of a videotape which will be complete prior to the INCOSE conference. Very short segments of the video and/or CD‐ROM will be used if this paper is chosen for presentation.
7.10. Integration of System Engineering Tools
Authors: Rader Jock
Published: November 2014

Integration of tools is a major issue in the provision of a useable set of tools to support system engineering. Integration can be approached from different perspectives including: infrastructures (middleware), and the integration characteristics of individual tools. This paper concentrates on integration mechanisms which a given tool might enjoy. A major portion of the paper looks at application programming interfaces (APIs) which provide the most complete range of integration possibilities: and the various dimensions of APIs are analyzed. Also discussed are internal programming languages, filters, modification of internal tool files and shared repositories. Tool enhancement techniques are mentioned in places because they are so intertwined with integration. In order to make intelligent choices of tools to support systems engineering for a project or organization, it is necessary to understand a wide range of tool integration properties in detail.
7.15. Risk in Risk Management
Authors: Armstrong James R
Published: November 2014

Although there has been a great acceptance of risk management over the last decade, there is still room for improvement in the practice. As with any new idea, there have been multiple variations developed in application. The situation doesn't warrant a grand effort to standardize. However, the practitioner should be aware of the differences and the risks inherent in applying risk management.

With any new concept, there will be a drive for both better theoretical understanding and application to new areas. One example in the case of risk management is the application to software. However, the resulting more detailed theoretical description of risk has created a conflicting set of definitions that can cause problems when merged with the original versions. One part of this paper looks at both views and seeks to explain what the differences are, their potential impact, and which way a project lead should go when faced with such a conflict in definitions.
1.1.2 Ground Data System Risk Mitigation Techniques for Faster, Better, Cheaper Missions1
Authors: Catena John , Saylor Rick , Casasanta Ralph , Weikel Craig
Published: November 2014

With the advent of faster, better, and cheaper missions, NASA Projects acknowledged that a higher level of risk was inherent and acceptable with this approach. It was incumbent however upon each component of the Project, whether spacecraft, payload, launch vehicle or ground data system, to ensure that the mission would nevertheless be an unqualified success.

The Small Explorer (SMEX) program's ground data system (GDS) team developed risk mitigation techniques to achieve these goals starting in 1989. These approaches have developed through the SMEX series of missions and are practiced today under the Triana program. These techniques are:

Mission Team Organization – Empowerment of a close‐knit ground data system team comprising system engineering, software engineering, testing, and flight operations personnel,

Common Spacecraft Test & Operational Control System – Utilization of the pre‐launch spacecraft integration system as the post‐launch ground data system on‐orbit command and control system,

Utilization of operations personnel in pre‐launch testing – Making the flight operations team an integrated member of the spacecraft testing activities at the beginning of the spacecraft fabrication phase,

Consolidated Test Team – Combining system, mission readiness and operations testing to optimize test opportunities with the ground system and spacecraft, and

Reuse of Spacecraft, Systems, Standards, and People – Obtaining greater efficiencies through reuse of common spacecraft components, flight and ground‐based subsystems, standardized interfaces, and project team personnel.

The SMEX ground system development approach for faster, better, and cheaper missions has been very successful. This paper will discuss these risk management techniques in the areas of ground data system design, implementation, test and operational readiness.
2.1.2 Practical Experience Applying Business Process Reengineering to US ARMY Airworthiness Qualification
Authors: Branson Ronald , Hughes Timothy , Pratcher Rebecca
Published: November 2014

This paper relates the experiences of the US Army Aviation & Missile Command team chartered to reengineer the Airworthiness Release and Qualification Process. Specifically, it reviews the processes the team used to identify issues and problems with the current process; development of recommended approaches for changes; definition and modeling of the current and “to be” processes; and lessons learned selling the new and improved process to the leadership and to the action officers.
2.1.4 Managing the Wood not the Trees ‐ The Smart Acquisition Approach to Systems of Systems
Authors: Arnold Stuart , Brook Peter
Published: November 2014

The challenge of Systems of Systems has particular significance in the acquisition, deployment and operation of defence equipment. In the UK, MOD sees that a major part of the solution to the effective creation, use and evolution of defence SoS lies in particular improvements in organisational structure, in project responsibilities and in the definition and application of systems engineering processes. These three areas of change are providing a framework for tackling SoS issues. MOD's Smart Acquisition initiative is leading to management structures and responsibilities, at the executive and project levels, and to technical processes that more effectively meet the SoS challenges.
6.1.4 Modeling Objectives on Cost in a Decision Maker's Value Structure
Authors: Snyder Frank J. , Parnell Gregory S.
Published: November 2014

Multi‐objective decision problems involve trading off conflicting objectives and sacrificing resources (often money) to gain some level of performance or some compliment of attributes from the alternatives. This paper considers whether or not the objective of minimizing cost should be included as part of the fundamental objective hierarchy when modeling a decision maker's value structure. Specifically, it examines two approaches to representing cost (financial resources) in a value structure. In the first, minimizing cost is treated as a fundamental objective that should be included in the value structure. This approach suggests that a single numerical index should be used to rank‐order alternatives. In the second, minimizing cost is treated as an attribute of an alternative that is separate from the value structure. This second approach suggests that an alternative's utility can be plotted against the cost providing a set of utilities and associated costs. This paper explores and reports findings of interest in modeling the objective of minimizing cost.
7.1.4 Automatic Generation and Verification of Design Specifications for Railway Signalling Applications
Authors: Robinson Neil , Kearney Peter , Tombs David , Barney David , Nikandros George
Published: November 2014

We describe a project to develop a set of design tools for a railway signalling application, which is safety critical and has complex functional requirements. The toolset generates design specifications from functional requirements and verifies them against safety principles. The project addresses the overall engineering design process and has applicability to other domains.
8.1.1 Adding ‘ilities’ to Capability Maturity Modeling: The Safety CMM
Authors: Plowman Catherine , Alessi R. Sam
Published: November 2014

Building a strong behavior‐based safety culture within an organization is accomplished by evaluating its current safety climate and designing organizational changes in a way that will prevent occupational injuries, minimize work‐related illnesses, and promote better safety practices. The organizational changes must be integrated across the complete business environment in order for safety to become truly institutionalized. Currently, few approaches to safety improvement are effectively integrated. To address this need the INEEL is developing a new method entitled Safety Capability Maturity Appraisal. This work is based on a popular approach used by the Department of Defense and the Federal Aviation Administration to evaluate organizational, management, and technical performance. The approach uses an extensive normative questionnaire to establish a baseline of organizational performance, then conducts exploratory interviews with a sample of the organization's personnel to gain greater understanding of the underlying cultural issues that prevent change. An organization is scored on a maturity scale that measures its current capability to perform work in a systematic manner. Finally, an organizational intervention plan is designed and implemented that includes simultaneous changes to organizational, management, and technical business areas. Although Capability Maturity approaches have been used successfully, they currently lack the ability to assess the component of safety within an organization. Our current research is testing a comprehensive set of safety‐related questions that we have added to an existing Capability Maturity model. An experimental design will be used to determine the extent to which a safety capability maturity appraisal can provide valid information for the design and implementation of timely organizational changes that enhance both business and safety related practices. The initial research will be performed at Yellowstone National Park during the first quarter of 2001.
3.2.1 The Regulatory History and Environment for Development of Telecommunications Systems in the United States
Authors: Mackey William F.
Published: November 2014

This paper explores the development of telecommunications systems in the United States as a result of regulation and deregulation of the telecommunications industry. The systems engineer should understand evolution of the structure of the telecommunications industry from multiple viewpoints. This paper examines the industry from the legislative history, major court decisions, and the regulatory activities of the federal and state governments. A comparison of the Telecommunications Acts of 1934 and 1996 is developed and the historical environment, as well as the technologies and innovations that stimulated their creation, is also examined. The thesis of this paper is that the telecommunications industry is creating global changes that will alter the international community during the 21st century more significantly than the industrial revolution did in the 19th and 20th centuries.
3.2.2 A Systems Approach to Telecommunications Regulation
Authors: Mackey William F.
Published: November 2014

This paper explores the global development of the telecommunications industry using the United States as the primary example for telecommunications regulation and deregulation. The systems engineer must be prepared to examine the development of the telecommunications industry from multiple viewpoints. This paper examines the industry from several viewpoints including a legal viewpoint, regulatory process viewpoint, and economic viewpoint. The present global changes in privatization and liberalization are also examined in the United States, Europe, Latin America, the Asia‐Pacific region, and Africa and the Middle East. The thesis of this paper is that the telecommunications industry is creating global changes that will alter the international community during the 21st century more significantly than did the industrial revolution in the 19th and 20th centuries.
4.2.4 An Enterprise‐Wide Systems Engineering Process Improvement Framework
Authors: Walden David , Shi Yan‐Chi , Kennedy Alan
Published: November 2014

General Dynamics has established an enterprise‐wide Systems Engineering process improvement framework. The General Dynamics Technology Council sponsors several Corporate Technology Area Teams (CoTATs), with one specifically focused on Systems Engineering. This paper addresses the successes, challenges, and lessons learned in the establishment, execution, and evolution of an enterprise‐wide Systems Engineering process improvement activity.
6.2.1 A fresh view on model‐based systems engineering: The processing system paradigm
Authors: Muth Thomas , Herzberg Dominikus , Larsen Jens
Published: November 2014

Model‐based systems engineering and graphical notations have an enormous potential for increasing design productivity, system quality and lifetime by shifting the bulk of design efforts to early phases. In spite of that this is hardly questioned, the shift towards model‐based approaches has not come to a break through, as we are experiencing in software engineering. It is believed that a major reason is lack of a common system view that can act as a framework for developing modelling languages and methods for a broad community of system engineers.

This paper suggests such a framework. It identifies the systems of concern as a processing system that consist of a process control system and a resource system, and applies two related views on processing systems: A functional view and a solution view. The framework has been successfully tested on telecommunication systems and networks for some years. It is believed that it holds for many other system domains as well.
6.2.4 Investigating Risks in Systems Engineering Tool Data Exchange
Authors: Herzog Erik , Törne Anders
Published: November 2014

Data exchange capabilities are generally regarded as a desirable (but in many cases absent) property of systems engineering tools. While such capabilities are desirable it is also the case that there is a substantial risk that tool data exchange impose modifications to the data transferred. In this paper we illustrate how modifications are introduced based on the capabilities of individual tools, present an analysis of potentially adversary effects of data exchanges and discuss measures for preventing data exchange related errors from being introduced in a specification. The paper also discusses requirements for data exchange information models for heterogeneous domains to support representation of multiple semantic variants of basic concepts. Aspects of the emerging ISO standard AP‐233 is evaluated against these requirements and an example is presented to illustrate the point.
7.2.1 Help! How Do I Make My Organization Comply With Yet Another New Model?
Authors: Sheard Sarah A.
Published: November 2014

“Help! We have to revise all our ISO 9000 processes to meet the CMM!” Or, “Help, we're compliant with the CMM but now we have to write new processes for ISO 12207!” Or, “I don't want to write systems engineering processes to EIA/IS 731 because I'm only going to have to rewrite them to CMMI.”

If these sound familiar, it is because organizations are currently faced with the prospect of having to shift their process improvement attention from a current model, such as EIA/IS 731, ISO 9000, or the Capability Maturity Model for Software (SW‐CMM) to a new model, such as the Capability Maturity Model Integrated (CMMI)sm.1 To some shifting seems a daunting feat; in many cases it has taken years to adapt to the current model, and to start all over seems to negate the value of the current investment.

This paper shows that capability models (and other process standards such as ISO 9000) generally ask the organization to do similar or identical things, and adopting a new model should be approached as mapping and modifying rather than as starting over.
7.2.3 Is it only Systems Engineers that do Systems Engineering?
Authors: Hoyle Tim A.
Published: November 2014

Misunderstanding and confusion surround the use of the words “system”1 and “systems” in conjunction with engineers and engineering. Some engineers describe themselves as systems engineers but does this tell us what they actually do? Some organisations describe themselves as producing software systems; does this mean they need only software engineers to do this? The words “system” and “systems” are all‐embracing terms which at the corporate level can usefully indicate an ability to take on large complex engineering tasks but when used at a more local level can obscure and confuse an individual's roles and tasks. Such confusion hampers communication, understanding of project responsibilities, allocation of project resources and identification of recruitment needs.

This paper summarises how a business formed from many legacy organisations is adopting a common engineering process model and language to describe its engineering activities. It concludes that the use of the qualifier “systems” is not helpful in conjunction with the individual engineer. There are two reasons for this: ‐ i) systems engineers require different skills in their various roles and ii) engineers need to do systems engineering whatever their level in the project hierarchy.
8.2.4 The Successful Application of Risk Analysis To The Redesign of a Major System
Authors: Palmer John A. , Dechoretz Jason A.
Published: November 2014

The Crusader, a new, state of the art self propelled howitzer system for the US Army, has been designed and a firing prototype is in the field for test. However, the Army Chief of Staff has determined that a much more mobile and transportable system of armored vehicles is necessary for the US Army to successfully project force and respond to urgent situations on the battlefields of the future. As a result, he directed that Crusader be drastically reduced in weight within a short period of time. The purpose of this paper is to describe how risk assessment and analysis were applied to materially assist in successfully reaching the Chief's goal without the need to completely redesign the vehicle.
2.3.1 On the Acquisition of Systems of Systems
Authors: Cook Stephen C.
Published: November 2014

In this paper we examine the term “Systems of Systems” (SoS) and form a distinction between them and large monolithic systems based on system attributes and acquisition approaches. Importantly, for this paper, one of the distinguishing attributes is that SoS are formed from component systems that are acquired using multiple asynchronous projects. We raise the issue that the current stovepiped, project‐centric, prescriptive acquisition paradigm is not well suited to the acquisition of component systems for military systems of systems. The paper proceeds to identify more detailed issues that need to be addressed to improve acquisition outcomes and provides some mitigation strategies. The major recommendations are to increase the influence of top‐down, force‐structure planning, move away from project‐centric capability development and acquisition to broad, force‐area development, and to raise the importance of systems characteristics that will enhance their ability to be integrated into systems of systems, such as, adaptability, flexibility, and open interfaces.
6.3.2 A Frame‐Based Approach to Requirements Engineering
Authors: Cook Stephen C. , Kasser Joseph , Asenstorfer John
Published: November 2014

Requirements engineering is justifiably receiving increased attention at present as deficiencies in this endeavour are often cited as being responsible for poor project outcomes. The paper opens by identifying the goals for the next generation of requirements engineering support tools and postulates that requirements engineering practice and tools will require more than an incremental improvement to achieve these goals. The approach proffered is to apply expert system techniques to the problem. Through an examination of previous research we propose that a highly capable requirements engineering tool can be built based on intelligent agents operating on a bespoke frame‐based knowledge representation architecture. Evidence is presented that the approach has the representational richness and reasoning power to undertake the functionality identified as being necessary to assist requirements engineering.
8.3.3 A Second Application of the CEaVa Method
Authors: Larsen Bob , Buede Dennis
Published: November 2014

In the complex world of developing requirements and eliciting user needs, engineers build billions of dollars of products that are wrong on delivery, because they solved the wrong problem. The problem statement does change, because the environment (i.e., schedule, technology, people, or politics) changes. The Continuous Early Validation (CEaVa) refinement method will stabilize the problem statement (i.e., critical requirements or KPPs), which will enhance the probability of building the right product. We will highlight the second application on a billion dollar Army Information Technology system case study that utilized the CEaVa method.
4.4.1 Modeling the Customer Value of Product Development Processes
Authors: Browning Tyson R.
Published: November 2014

Abstract1

Lean is not minimizing cost, cycle time, or waste. Lean is maximizing value. In product development (PD)—a process where the systems engineering (SE) of products plays a significant role—sometimes getting lean requires doing more, not less. Providing a preferred combination of technical performance, affordability, and lead time requires a flexible and lean PD process. Value is affected not only by the presence of necessary (value‐adding) activities in the PD process but also by the way those activities work together (as a system) to ensure that they use and produce right information. Lean PD requires the right information in the right place at the right time.

The kernel of the idea is based on systems thinking. The value of a system is more than the value of its individual components. Similarly, the value of a process is more than the value of its individual activities. How well the components or activities work together (or fail to do so) makes the difference in value. If all the activities add value, how can we ensure that they work together in such a way that the overall process maximizes its potential value? Lean PD requires the systems engineering of processes.
4.4.3 A Visual Explanation of Development Methods and Strategies including the Waterfall, Spiral, Vee, Vee+, and Vee++ Models
Authors: Mooz Hal , Forsberg Kevin
Published: November 2014

Considerable confusion continues relative to development methods, development strategies, and delivery strategies. This confusion is prevalent in routine engineering discussions and in recent textbooks. Method models such as the Waterfall, Spiral, Vee, Vee+, and Vee++ offer a variety of software and system development approaches each with a specific emphasis. Each of these models can be applied to an incremental or evolutionary strategy according to the nature of the project and each of these in turn can be produced in single or multiple deliveries.

This paper addresses the choosing of a technical development strategy, which consists of selecting and implementing a combination of the most appropriate development method, a development strategy, and a delivery strategy.
8.4.2 A Case Study in the Application of UML and OOA/D in an Information Management Program
Authors: Gibbons Paul J.
Published: November 2014

During the past few years, Object Oriented (OO) techniques have begun to expand from what had traditionally been a software development focus. Specifically, the expansion of these techniques has not only been extended on the programmatic time line, but also expanded in applicability to other disciplines including Systems Engineering. As the time‐line applicability of these techniques has grown, early‐on program phases which particularly address Systems Engineering are gaining emphasis. As a result of this, OO techniques are becoming a key tool set in the current‐day Systems Engineering discipline.

This paper provides a Case Study of an ongoing competitively won Information Warehouse and human‐system information access program. An overview of the Unified Modeling Language (UML) and related OOA/D techniques are explored. A particular emphasis is placed on insights and lessons learned from the System Engineering perspective.
6.5.1 Using COTS tools in the development of a Model Based Avionics Architecture Tool
Authors: Chau Savio , Hall Ronald , Traylor Marcus , Whitfield Adrian
Published: November 2014

Information and discussion of the development of an Avionics Architecture Tool that is model‐based using commercial off the shelf (COTS) products will be provided. Statemate Magnum from I‐Logix Inc. was used in this work. A number of areas of interest will be discussed, including the user and institutional needs affecting tool design, development, and deliverables, how plug‐and‐play general component models is used for avionics architecture rapid prototyping, the basic architecture of a general component model, and preliminary results of utilising the tool to develop a “straw man” avionics architecture.
6.5.3 An Approach to Generalising the State Space of a Distributed Missile Simulator
Authors: Gordon Steven , Kristensen Lars , Billington Jonathan
Published: November 2014

Formal methods can be used to verify refinements made in the design stages of systems. For example, the state space of a detailed design model can be compared with that of an abstract design model to see if it preserves sequences of events. Problems with state space analysis (state explosion, fixed initial states) make this difficult for real applications. In this paper we outline an approach for obtaining a generalised state space of a distributed missile simulator. The original state space has a repetitive structure. Our aim is to prove that for any initial state, the system will eventually halt, after which we can define a compact graphical representation of the state space, that is independent of the initial state.