bluuebunny/crossref_metadata_2025 huggingface dataset:
7.2.1 Development of an Integrated Facilities' Management Baseline at a Federal Agency Using a Systems Engineering Approach
Authors: Thurau Robert , Dagli Cihan , Enke David
Published: November 2014

The National Geospatial‐Intelligence Agency (NGA) has implemented an integrated facilities' management program covering its many buildings, operations, and site locations. In conjunction with organizational structure development, a commercial‐off‐the‐shelf (COTS) computer aided facilities management (CAFM) system was implemented to integrate data collection and user control. These facilities' management aspects include tracking building floor space usage, employee locations, AutoCad building designs, equipment inventory, operations and maintenance scheduling, etc. The systems engineering process included a spiral architecture development model, initial and recurring data validations, a risk management review, and multiple phases of tracking requirements and change control. Formal configuration management boards (CMB) were a critical element of development and continuing operation of CAFM. Use of an open systems interface design to allow exchange of data between CAFM and related databases from Human Resources and Security Departments was essential. By replacing the many separate legacy facilities programs with an integrated CAFM package, more complete data information was collected which allowed for better control and operation of facilities resources and improved strategic facilities' planning.
7.4.2 Extending Systems Engineering Frameworks for Special Application Areas: Case Study Safety and Security
Authors: Ibrahim Linda , Wells Curt , Bate Roger
Published: November 2014

Several standards, models, and frameworks provide systems engineering best practice. There are also many standards that address special applications of systems engineering. If an organization is already working on improving its systems engineering processes using a general model, how might it additionally address standards and best practice in related fields of interest in an efficient, effective way?

This paper describes a new construct, called an Application Area, designed for extending existing systems engineering frameworks with practices and guidance specific to a particular application. The construct is illustrated by means of the Safety and Security Application Area that was developed using this approach.
8.1.2 Improving the VVT Process: Evaluating the SysTest Results in Six Industrial Pilot Projects
Authors: Hoppe Markus , Engel Avner
Published: November 2014

Many companies experience extensive product rework and failure cost due to ineffective Verification, Validation, and Testing (VVT). Therefore, there is a great potential benefit in streamlining and optimizing the VVT process. To that end, a consortium of eight European companies, research institutes, and organizations conducted the SysTest project. The stated aim of SysTest was to “…decrease product development cost and time to market by 10%“. SysTest intended to achieve this aim by developing a generic methodology and process model to support the process of systems' VVT. This paper describes the results of using the SysTest products in six industrial pilot projects. The diverse pilot projects have shown that the SysTest products are applicable in different industries. Specifically, each project was able to use most components of the SysTest methodology and process model and the pilot projects conducted by the industrial partners exhibited an average of nearly 8% project cost reduction with standard deviation of about 15%.
8.3.1 Towards an Integrated Methodology for the Model‐based Development of Embedded Automotive Control Software
Authors: Buhr Kerstin , Conrad Mirko , Dörr Heiko , Fey Ines
Published: November 2014

The complexity of developing automotive control unit software can generally not be mastered without an efficient development methodology. The development discipline activities requirements, modelling / implementation and quality assurance are, for this reason, supported by individual methods. In order to optimally coordinate the methods with one another during their deployment, a structured integration of these individual specialised methods is, however, essential. The following paper, using the model‐based development approach as an example, outlines the content and structure of an integrated methodology that provides such integration. Its use shortens development time and increases product quality by coordinating the deployment of individual methods over the course of the entire developmental process. The main components of this kind of integrated methodology are an interdisciplinary information model, process models with integrated procedures for the realisation of single development activities as well as guidance such as checklists, templates, and examples, among other things. In this paper, we present the experiences that we have gained at DaimlerChrylser Research in developing and applying such an integrated methodology1.
8.4.1 Implications of Sociological System Theory on Systems Engineering and Product Development
Authors: Pulm Udo
Published: November 2014

Systems engineering can be regarded as a part of system theory, which seems to be most up to date in sociology trying to understand complex social systems. This contribution gives an overview on the development and appearances of system theory, compares systems engineering and the modern sociological system theory and shows how to improve the design and development of technical systems by the use of those sociological insights. This regard covers a new understanding of complexity, of systems themselves, of communication being any coordination of activities, as well as respective media. The considerations finally lead to a dynamic organisation as well as to measures how to approach complex social systems.
8.4.3 What Question are You Trying to Answer? Identifying the Right Products for an Architecture Effort
Authors: Russell Michael S.
Published: November 2014

Determining what architecture products are needed to support systems development within a Systems Engineering process is a challenge. Existing documents, such as DoD's Architecture Framework Document, provide some guidance, but no defined product identification process. The method proposed in this paper provides a repeatable process for selecting the architecture products required to support a systems engineering lifecycle, defining the content of each product, and identifying each product's customer. The method has been successfully used by several DoD programs over the past five years.
9.4.1 The Axes Guiding Development of a Capability Engineering Process
Authors: Bernier F. , Mokhtari M. , Couture M. , Lizotte M. , Lemieux F. , Lam S. , Lalancette C. , Dussault G.
Published: November 2014

Significant changes in the nature of military systems and the military environment require improvements of the current military systems acquisition process. The Capability Engineering Process (CEP), to be delivered through the CapDEM project, aims at improving military capabilities acquisition in the Department of National Defence and the Canadian Forces (DND/CF). However, opportunities to improve capability acquisition are too numerous to implement all of them within the CEP. This paper presents a structured approach to better orient the development of a CEP.
9.4.3 Seamless Engineering Process to Enhance Systems Engineering Effectiveness
Authors: Shepard Lynn , Bean Susan , Hough Andy , Jolly James
Published: November 2014

In order to effectively execute large and complex programs, an engineering process must be established that eliminates multi‐disciplinary barriers. This process needs to be focused on the entire product development cycle and work to keep engineering disciplines from executing independently. This paper will describe the integration of the systems, hardware, and software engineering approach, the utilization of event driven, use case‐based, object oriented design practices, and the use of an integrated tool suite to perform the requirements decomposition, traceability, architecture design, and multi‐level documentation generation. The authors will also address how this process aids unit testing, system level testing, and regression testing methodologies throughout the product development and deployment lifecycles.
10.1.1 A Systems Approach to Process Infrastructure
Authors: Armstrong James R
Published: November 2014

This paper looks at several aspects of process infrastructure and maturity from the viewpoint of systems thinking concepts. To start, the paper addresses the position of process infrastructure relative to ISO 15288 (ISO/IEC, 2002) enabling systems. Next, the paper looks at the impact of multiple standards on the infrastructure and the programs using it. A third view is the use of a systems approach to deal with the problem of multiple standards for how processes are implemented. The final view is how the common features implement both the science and engineering approach activities and how maturity levels address them.
10.2.1 Requirements – The Good, the Bad and the Ugly
Authors: Arnold Stuart , Martin James N
Published: November 2014

In our efforts to make system requirements “good,” we often end up making them “bad.” It is proposed that the real goal should be to make requirements BaD—balanced and dynamic. This paper describes why the so‐called “good” requirements are really, in the larger sense, bad for success of the system and the organization that sponsors it. The paper will explain what it means to have “balanced and dynamic” requirements. Times have changed—the systems engineering discipline needs to change its methods to keep up with the global trade situation. For this, we need better tools and techniques that support the BaD approach.
10.4.1 Measuring the Lifecycle Value of a System
Authors: Browning Tyson R. , Honour Eric C.
Published: November 2014

The goal of systems development is to produce enduringly valuable systems—i.e., systems that are valuable when delivered to their users and which continue to be attractive to their stakeholders over time. However, quantifying the lifecycle value (LCV) provided by a system has proven elusive. We propose an approach to quantifying a system's LCV based on the key parameters that have perceived value to the system's stakeholders. For this, we draw upon insights from the management, marketing, product development, value engineering, and systems engineering literature. By designing systems for maximum LCV, systems architects and engineers will provide dramatically increased value to their organizations. However, to provide maximum LCV, a system may need to be designed to facilitate adaptability to changing circumstances and stakeholder preferences.
12.2 Fundamental Principles of Evolutionary Project Management
Authors: Gilb Tom
Published: November 2014

The Evolutionary Project Management method – abbreviated Evo – is arguably the best systems engineering project management method (Larman and Basili 2003). However, it is also probably the least known and the least discussed, so the aim of this paper is to shed some light on it. Evo is particularly good at dealing with large, complex, and innovative systems – it does so by breaking down the project into a series of numerous small incremental steps. Each Evo step is both an opportunity to deliver some useful results to the stakeholders, and an opportunity to learn more about the system.
1.1.4 Joint Cognitive Systems: Considering the User and Technology as One System
Authors: McKenna Brian , Gualtieri James , Elm William
Published: November 2014

With the addition of advanced technologies and automation within systems, the tasks that operators are asked to complete have grown more complex. This has led to greater opportunities for malfunctions, critical incidents, and catastrophes. A major contributor to these problems is the human operator and the technology not being explicitly designed as a single Joint Cognitive System (JCS). The operator is typically only blithely considered during system design and is typically expected to adapt to inputs from the other subsystems. Thinking of the operator and the automation/technology from a holistic perspective, as a single JCS, instead of separate subsystems, allows for more effective, agile, and robust decision‐making. The operator must have a complete understanding of the automated processes and the work domain, leading to more informed decision‐making. Thinking of the entities as co‐agents, rather than two isolated components that must interface, allows for more effective problem solving and decision‐making.
4.2.2 How Planning for Success Can Lead to Catastrophic Failure
Authors: Schoening William W.
Published: November 2014

Despite significant advances and continuing efforts to improve our processes, major programs continue to fail – not slowly and gracefully, but suddenly and catastrophically. Examination of failed programs over several decades suggests that our traditional systems engineering and program management methods are inadequate for discovering and mitigating the underlying causes because they have significant difficulty coming to grips with such huge failures. This paper identifies several symptoms related to potentially catastrophic failures during product development. Each symptom is accompanied by suggestions for remedies that can illuminate the underlying potential problems without undue impact on the program.
1.4.3 Challenges in the Development of Systems Engineering as a Profession
Authors: Dixit Indrajeet , Valerdi Ricardo
Published: November 2014

This paper explores a fundamental and important question: is Systems Engineering a profession? It is fundamental because of the current existential crisis in the discipline and it is important because it helps in defining our role in the context of the greater technical community. By observing systems engineering through the theoretical lens of the professionalization literature rooted in sociology, we propose five key challenges to systems engineering as a profession. Firstly, defining the problem space, secondly, understanding the state of the body of knowledge, thirdly, the impact of lifecycle perspective, fourthly, the falsification of systems engineering theories and lastly, the question of standard of proof for systems engineering. The need for our thesis is motivated by understanding the current body of knowledge and proposing a direction that will enable the profession to overcome key challenges.
1.5.3 Case Study: Tailoring CMMI®‐based Command Media for a Company's Individual Business Areas
Authors: Turner Derek , Adkins Ronald
Published: November 2014

This paper describes a prescribed methodology for tailoring Command Media derived from the Carnegie Mellon®1 University's Software Engineering Institute's Capability Maturity Model® Integration for a company's business areas. The paper illustrates a case study for a specific Harris GCSD business area, Cronus, whose methodology was tailored to be generally applicable to the projects executed within the Cronus Business Area and still be compliant with Harris GCSD CMMI® Level 3 Command Media requirements. This tailoring becomes the basis for all projects within Cronus without the need for additional waivers and tailorings. This does not preclude any project from adopting the more general methodology; from further tailoring the Cronus methodology; or, continuing the process further to differentiate between studies, development contracts, quick‐react contracts, and other program types. This paper represents the results of the case study and may be applicable to other business areas within Harris and at other companies.
2.1.1 Defining Lean Systems Engineering Processes and Procedures
Authors: Olson Timothy G.
Published: November 2014

Many systems engineering processes and procedures are large or difficult to use. The situation becomes even worse when complexity is involved. Putting large or difficult to use process documentation on a website does not usually solve the problems. This article will describe best practices for defining lean (i.e., short and usable) processes and procedures. These best practices have been used at real organizations over the last few years to define lean processes and procedures. Measurable results include cutting organizational processes and procedures in half while making them more usable (e.g., reducing 400 pages to 200 pages), without losing any useful information. This article will also describe some success stories and describe some lessons learned.

The objectives of this article are to:

Describe common problems with process documentation, including some human aspects of using process documents.

Discuss some best practices for defining short and usable processes and procedures.

Describe some success stories in real organizations.

Provide some lessons learned.
2.1.3 The US Ballistic Missile Defense System: A Case Study in Architecting Systems‐of‐Systems
Authors: Hollon Heather , Dagli Cihan
Published: November 2014

Systems‐of‐Systems (SoS) engineering for modern complex systems is one of the most difficult challenges facing today's engineer. This paper provides a detailed case study of architecting for a major modern SoS: the US Ballistic Missile Defense System (BMDS). The BMDS is a massive SoS that encompasses several existing and new missile defense programs on a variety of platforms covering most of the world. This paper includes a review of currently defined practices for architecting SoS, a discussion of how the BMDS was architected, and then suggestions for architecting future additions to the program.
2.2.1 Eight deadly defects in systems engineering and how to fix them
Authors: Kasser Joseph E.
Published: November 2014

Any organization desirous to adopt or improve systems engineering needs to be aware that research into the nature of systems engineering has identified a number of defects in the current systems engineering paradigm. This paper discusses eight of these defects and ways to fix or compensate for them.
2.2.3 Combined Requirements Engineering (CRE): The quest for widening the applicability of requirements engineering practices in the emerging product‐service paradigm
Authors: Agouridas Vassilis , Kossmann Mario
Published: November 2014

Competitive pressures and the globalisation have led enterprises to continuously seek innovative ways to create value for their customers whilst either minimising costs or keeping these at acceptable levels. To this end, enterprises have been offering product‐service bundles to promote and support their core products. This situation has led to the emergence of so‐called product‐service paradigm; a key characteristic of which is the provision of the requisite capability through a combination of service and product characteristics. However, the majority of current requirements engineering (RE) practices are aimed at solely addressing either product or service aspects of capability. This paper highlights the quest to widen the applicability of established requirements engineering practices, used mainly for product‐oriented systems, to encompass, in a complementary manner, aspects of service‐oriented systems. To this end, the term ‘combined requirements engineering’ (CRE) is introduced. The paper presents and discusses challenges and issues derived from the need for CRE under the emerging product‐service paradigm. The paper concludes by giving directions for future research in addressing such challenges and issues.
2.3.1 Benefits and Costs of Model‐Based Fault Diagnosis for Semiconductor Manufacturing Equipment
Authors: Pietersma Jurryt , van Gemund Arjan J.C.
Published: November 2014

Model‐Based Diagnosis (MBD) is a promising solution for the fault diagnosis of complex systems. In this paper we review the benefits and costs of MBD. Our research is performed in cooperation with ASML which is the world's leading manufacturer of lithography systems for the semiconductor industry. We analyse the current way of working and the benefits that MBD offers. We present the results of practical modeling studies and discuss the benefits, costs, and cost reduction methods. We summarize the current research results and ongoing developments. Our results show that MBD has a high potential for diagnosis in a rapidly innovating industry. The fulfilment of this potential depends on the cost of modeling and the acceptance of MBD as part of broader pursuit for model‐based systems engineering.
2.4.3 DOES INCOSE NEEDS PR?
Authors: Zonnenshain Avigdor
Published: November 2014

The mission of INCOSE is to foster the definition, understanding, and practice of world class systems engineering in industry, academia, and government.

INCOSE's vision is to be world's premier professional society for advancing the art and practice of systems engineering.

INCOSE makes this vision a reality through its members, its chapters, its partners and through the systems engineering community.

Even though INCOSE has grown significantly since its formation in 1990, there are only five thousand members. The potential base individual members is more than hundred thousands.

There are hundreds of organizations which practice systems engineering and are familiar with the leading role of INCOSE in promoting systems engineering. But there are thousands of organizations that are not familiar with the benefits of systems engineering and the capabilities of INCOSE.

In this paper we propose to use Public Relations (PR) as one of the approaches and tools to promote the mission and the vision of INCOSE.

“PR is the practice of creating, promoting or maintaining goodwill and favorable image among the public towards an institution, public body.….”.

We demonstrate the planning of PR campaign for INCOSE by proposing the goals & aims of the campaign, defining the target audience, suggesting the messages & ideas to be delivered through the campaign, presenting some examples for how to deliver the messages (the medium), and discussing the timing of the individual PR activity.

This proposed PR campaign is not standalone, but it is part of the professional & managerial development of INCOSE, and a part of its marketing efforts.

It is proposed to form a PR committee which will plan the campaign and execute it.

The proposed goals for the PR campaign are very ambitious ‐ like doubling the number of members in 10 years, doubling the number of participating in INCOSE Annual International Conference in 5 years. But we assume these goals and aims are achievable, if we launch a PR campaign with broad perspectives:

Professional campaign

Excellence campaign

Globalization campaign

Business success campaign

Public decision making campaign.

Also, we describe some ingredients of PR campaign that we are launching for the INCOSE activities in Israel through the Israeli Chapter – INCOSE‐IL.

We propose that INCOSE management will consider to adapt our proposed approach for the benefit of INCOSE, its members, its chapters and the whole systems engineering community.
3.3.1 Driving system development process from strategic goals to requirements specification
Authors: GHAZI Hamid EL
Published: November 2014

In this paper we suggest a goal‐oriented requirements engineering method to guide the discovery of strategic goals of a company, and their operationalization by goals associated with its system under development. The method also allows the discovery of system requirements and it was applied within an industrial project that aims to fabricate a medical diagnostic instrument. For this purpose, we used the MAP formalism to describe the process and various deliverables associated with the development process. We also used the concepts of i* to model the dependencies between the strategic actors of the organisational environment, and to formalize the goals related to the system. Our method makes it possible to model the strategic goals of the company and their decomposition into tactical goals and thus ensuring requirements traceability.
3.3.2 Modeling Hierarchy, Coping with the Dynamic Range from Design Details up to Business Metrics; Illustrated by a Semiconductor Case
Authors: Muller Gerrit
Published: November 2014

A system functions as part of a broader enterprise. For the design of a system understanding is required of its purpose within the enterprise, as well as of its internal functioning. Models are a means to create and capture understanding. Many different models are needed during the design of a system, from broad enterprise models down to detailed implementation models of components or functions. In this article we show the hierarchy of models, their relations and the level of detail in these models. We use the semiconductor industry as an example.
3.3.3 Reuse and Usage for System Engineering Model Elements
Authors: Smith Darold K.
Published: November 2014

Systems engineers are being forced to address greater complexity caused by problems that extend the boundaries of existing systems by taking the larger view of systems of systems. The task of defining the total system with consistency and integrity becomes more complex and difficult to manage. More complex systems inherently tend toward larger combinations of variability in the system elements, thereby causing an explosion in the possible combinations of system configurations. At the same time, SysML is endeavoring to extend the capabilities of system engineering modeling capabilities to include more rigorous modeling (simulation), verification traceability, and traceability of critical components of delivered products. One way to consolidate system representations is by supporting the concepts of reuse and usages of system definitions. This paper provides an initial set of things to consider when developing the processes and the supporting system engineering data repository to address these needs.
3.4.1 Promoting the Real Value of Systems Engineering using an Extended SCARIT Process Model
Authors: Saunders Steven J.
Published: November 2014

Systems engineering is the discipline that defines and delivers complex systems to meet the needs of multiple, often conflicting stakeholders. In the past, many books and papers have been published focusing on process areas such as Requirements Engineering, Requirements Quality, Requirements Traceability, and Model Based Systems Engineering. In this paper, the author proposes that by previously focusing on the processes used in Systems Engineering, the real value adding steps of systems engineering; to understand the enterprise needs and to define the problem, has been overlooked. To help overcome this bias, an extended systems engineering process model is presented that strives to elevate the visibility and understanding of key value adding steps in the Systems Engineering process.

Six phases are highlighted in the extended systems engineering process model covering the technical phases of systems engineering. These phases are Stakeholder, Concerns, Architecture, Requirements, Implementation and Test (or SCARIT). Process oriented steps are characterized in the final three steps (Requirements, Implementation and Test) and result in definition and deployment of the solution. However, the extended process model precedes these steps with Stakeholders, Concerns and Architecture and postulates these three steps are where the real value of systems engineering is generated. These initial steps focus on defining the problem by looking at the enterprise needs.
3.4.2 The ROI of Systems Engineering: Some Quantitative Results
Authors: Boehm Barry , Valerdi Ricardo , Honour Eric
Published: November 2014

This paper presents quantitative results on the return on investment of systems engineering (SE‐ROI) from an analysis of the 161 software projects in the COCOMO II database. The analysis shows that, after normalizing for the effects of other cost drivers, the cost difference between projects doing a minimal job of software systems engineering – as measured by the thoroughness of its architecture definition and risk resolution – and projects doing a very thorough job was 18% for small projects and 92% for very large software projects as measured in lines of code.
4.1.0 Panel 4.1.0: Requirements Engineering for Software vs. Systems in General?
Authors: Kaindl H. , Griego R. , Hause M. , Hood C. , Mannion M.
Published: November 2014

Requirements Engineering is dealt with concurrently and largely separately by a software‐based requirements engineering community anchored in the IEEE and by the INCOSE Requirements Working Group. Apart from such organizational issues, are there fundamental technical differences between Requirements Engineering for software vs. systems in general? It seems as though even functional requirements can mean something more general for a system including mechanical parts than for software alone. Quality requirements on safety deal with humans and their relationship with some real artifacts in their environment, so they cannot be dealt with by software alone. However, reliability of underlying software will be important in this context. While the internal structure of software will not normally be specified in its requirements, structure of a more general system may well be. These are just examples of what should be discussed.

With regard to intelligent enterprises, there exist defined methodologies for enterprise modeling. Much as any other complex system, an enterprise may be better understood through modeling. Once an enterprise is better understood, it may be easier to make it intelligent. Whatever technical system is to be developed in an enterprise, it needs to fit into. By connecting enterprise modeling and requirements engineering, the likelihood of such a fit is increased. For software development, such connections have been worked out and are part of defined methodologies, some of them based on object‐oriented modeling. Are they applicable to the development of general systems?

The software‐based requirements engineering community and the INCOSE Requirements Working Group have been slowly getting in touch with each other recently. This panel should help to discover more common ground and to exchange ideas on the commonalities and the differences of their respective tasks and methodology.
4.4.3 Applying Measurement Principles and Adapting a Defect Predictability Model to Hardware Development
Authors: Frenz Paul J.
Published: November 2014

Software and Systems engineering are developing rich histories with measures and measurement tools to aid in project management. This paper addresses adapting those Software and System Engineering concepts and tools to a hardware development project.

General Dynamics Advanced Information Systems (GDAIS) Mission Systems has been assessed as CMMI Level 5 rating November 2, 2005. using the CMMI‐SE/SW/IPPD/SS, V1.1, staged model.
4.5.1 Extracting Value from Uncertainty: A Methodology for Engineering Systems Design
Authors: Cardin Michel‐Alexandre , Nuttall William J. , de Neufville Richard , Dahlgren John
Published: November 2014

Designers and managers of new investments in engineering systems look for ways to add value to their programs. One fundamental way to do this is by taking advantage of uncertainty. Although uncertainty is usually seen as negative in most investment projects, it can also increase performance if flexibility is incorporated into the system to capture upside opportunities, and reduce losses in case of downside events. This paper introduces a design methodology that adds value to engineering systems by considering flexibility at an early conceptual stage. It provides screening tools to find areas where flexibility can be incorporated at the engineering, operational, and management decision levels. In engineering and operations, technical modifications need to be done within the system to acquire the flexibility exercisable by managers. One example is the ability to expand or contract product output as demand fluctuates. At the management decision level, no explicit modification is needed, such as the ability to abandon the project altogether. The methodology incorporates screening tools based both on qualitative historical studies (GPS, B‐52, etc.) and quantitative Design Structure Matrices representing the engineering system (Bartolomei et al. 2006; Kalligeros 2006; Kalligeros, de Neufville 2006). The design process also provides a set of quantitative tools to assess the financial value of flexibility based on Real Options Analysis and simulation models (de Neufville et al. 2006; Kalligeros 2006; Kalligeros, de Neufville 2006). These give managers and designers discriminating tools with which to choose the most valuable flexibilities to implement in the engineering system. The methodology represents a practical procedure for understanding where flexibility can be found and incorporated into all areas of engineering system design. We present a case application to the design of a new hydrogen production and storage system: Fusion Island (Cardin 2006; Nuttall, et al. 2005).
4.5.3 Defining Military Pilot Training Requirements for 2015+ through the Application of Systems Approaches
Authors: Woodhead M A , Cleveley J W
Published: November 2014

The current military pilot training system in the UK is struggling to train the required number of pilots economically and to the standard needed by military operations. Several factors are crippling the training including unrealistic training aircraft and a fragmented training structure.

Currently there has only been limited structured analysis into pilot training, the current system has blindly evolved from cold war tactics/aircraft and is struggling to adapt to a changing world

This paper presents a fresh approach to military training by understanding the base requirements and the effect of the changing environment over the medium term (10‐20 years).
4.6.3 A Self‐assessment Scheme and an Evaluation of its Reliability based on ISO 9004:2000
Authors: Hwang Young‐ha , Kim Sang‐hyun , Kim Dong‐young
Published: November 2014

The self‐assessment based on ISO 9004:2000 in quality management system is an important process for the organization that continually improves its performance considering the effectiveness and efficiency of a quality management system. The scheme and process of the internal audit and self‐assessment based on ISO 9001:2000 and ISO 9004:2000 is an issue that continues to demand the attention of researchers in this field. Also, the reliability of self‐assessment results is a remarkable issue. One element of reliability is the extent to which different teams assessing the same project produce similar ratings when presented with the same evidence. This paper presents a self‐assessment scheme conducted during internal audits based on ISO 9004:2000 in Electronics and Telecommunications Research Institute in Korea. Furthermore, this paper evaluates the reliability of a self‐assessment scheme analyzing some results from two assessments between two teams in self‐assessment using Cohen's Kappa coefficient (Cohen 1960, Cohen 1968) and the observed agreement index (Jung 2003). The results indicate that the extent of agreement between the two teams is substantial and the self‐assessment scheme is reliable.
4.6.4 Evolution of Assessment in a Hierarchical Team Project at Final Year Undergraduate Level
Authors: Ferris Timothy L.J.
Published: November 2014

In a paper published in an earlier INCOSE symposium the author described a final year undergraduate course in systems engineering from the viewpoint of educational rationale. In this paper the various issues confronted in the teaching of this course are described and the changes made to the course and assessment processes in order to promote the outcomes intended by the lecturer are described. Emphasis is placed on changes implemented in 2006 because of some features of these changes which are interesting with respect to the process of developing the concept of writing a coherent description of an intended system by a large class of undergraduate students. The paper discusses difficulties confronted in the assessment processes, and the link between the assessment processes and the student effort in the teaching of this course.
5.1.1 System Evolution in the Intelligent Enterprise: An Historical Case Study of VISA's Transaction Processing Systems
Authors: Cokus Michael S. , Dahlgren John W.
Published: November 2014

Intelligent enterprises need systems which evolve well. Systems will increasingly be expected to evolve to meet users' changing needs, and predicting user demand is becoming more inexact. System engineers need to understand why some systems evolve well and put this knowledge into practice. Lessons learned from the evolution of actual systems should be incorporated into system design and development processes to equip the system engineer to meet this challenge.

This paper discusses a case study of the technological evolution of VISA's credit card transaction processing systems. It identifies key principles which were successfully applied to enhance system evolution. The paper discusses observations concerning how generic properties (the illities) relate to one another and how they were achieved in VISA's system design. Related issues of system platforms and component coupling which affect system evolution are also addressed.
5.4.1 The Continued Evolution of Validation: Issues and Answers
Authors: Armstrong James R.
Published: November 2014

A case can be made that the most significant change in systems engineering over the last several decades has been the growth of validation along with significant changes in its meaning. Validation has come from nonexistence to being one of the major elements of the discipline. However, this has not happened without issues and challenges that continue today. This paper addresses the changes in the way various standards have reflected the use of validation, how organizations have approached it, and what is currently happening in its practice. This paper identifies several issues and provides approaches to deal with them.
6.1.2 Better use of Design Descriptions to embrace complexity and creativity in Systems Engineering
Authors: Strengers George
Published: November 2014

Most Systems Engineering practitioners now have access to Computer Aided Systems Engineering (CASE) tools that greatly assist with the engineering of complex problems. However, the productivity of these tools is often offset by the inability to effectively manage the large amounts of data associated with the system models offered by these engineering tools. As well as better CASE tools to improve productivity and success, we must not forget the role of innovation and creativity as a means of progressing solutions to engineering problems. This paper examines the use of the long standing practice of using ‘design descriptions’ and advocates that we formalize this approach by using Systems Engineering Design Descriptions to manage the engineering complexity and to embrace engineering creativity.
7.5.3 Cultural Models of Organizational Risk in Product Development
Authors: Collins Shawn T
Published: November 2014

This paper uses cognitive domain elicitation methods to explore taxonomies of risk in engineering product development. The paper places typical technologies of risk control within a context of theories that emphasize system‐focused risk identification. Two case studies identify weaknesses in this approach: operator errors in a chemical plant, and pilot error classification on P‐3 aircraft. Shifting the emphasis to user‐focused rather than system‐focused risk identification reveals several key concepts that are missing from the formal theories of risk mitigation. Using numerical analysis from a survey at a small engineering company, the paper explores cognitive anthropology insights regarding the distinction between folk and scientific taxonomies. The results present four significant findings: People who think they disagree with each other don't; experts and non‐experts view risky things differently; despite this difference, non‐experts have a systematic understanding of risky things; and there are verifiable ways to elicit the structure of this understanding.
7.5.4 Controlling Project Risk by Design
Authors: Malotaux Niels
Published: November 2014

A lot of risks that plague projects have a high probability to occur: e.g. the risk that we don't deliver the right things or deliver late, and the underlying causes of these problems. This calls for proactively anticipating potential problems and organizing our projects in such a way that the probability of the impact is minimized. The Evolutionary Project Management (Evo) approach is just doing that, constantly being aware of what could go wrong and preventing it going wrong, by design. In stead of assuming a theoretical model of how humans “should” behave, Evo studies actual human behavior and strives to make optimum use of how humans actually behave. Opposing what's in our genes is a lost battle.

In this paper we will first investigate prevailing risk management. Then we show how Evo practices are designed to successfully mitigate typical risks in projects. Finally, we spend a few words on how Evo relates to Enterprise Intelligence. The techniques discussed are not merely theoretical ideas, but have been tested, honed and proved by the author in the practice of more than 50 projects in various environments and cultures.
8.1.1 Get Smart
Authors: Hamman Christopher , Mackertich Neal
Published: November 2014

It is becoming evident that in order to effectively compete in an increasingly challenging global marketplace, organizations are going to need to both extend and leverage their established Systems Engineering principles and practices across the entire enterprise. Early returns from an emerging Systems Engineering best practice, Critical Parameter Management, has proven itself highly effective in this regard. Critical Parameter Management is a set of tools, enablers, and best practices for managing, analyzing, and reporting technical product performance by unifying and integrating systems, engineering design, and manufacturing activities. Specifically, the use of a Critical Parameter Management has enabled Enterprise Systems intelligence and decision‐making through: real‐time, sensitivity analyses at the system, subsystem and component levels; efficiently shared technical product documentation and analyses; performance design margins that are statistically managed over the System product lifecycle for their customer and business benefit; and the capturing and leveraging of invested intellectual capital for future business reuse.
8.4.1 Intelligent Operational Scenarios – a Strategy for Cost‐Saving Scenario Selection
Authors: Dam Steven H.
Published: November 2014

Use of scenarios or “use cases” is all the rage these days. However, the approach most often used for scenario selection is ad hoc. As a result the list of scenarios can be largely overlapping and can leave gaps in needed capabilities. In this paper we demonstrate an approach to intelligently selecting a series of scenarios that build one upon the other to reach the mission objectives.
9.1.3 Organizational Strategies for Systems Engineering Capability Improvement
Authors: So Maria M. , Andary James F. , Caldwell Melissa
Published: November 2014

There is an increased focus on systems engineering as the key to mission success within the National Aeronautics and Space Administration (NASA). The agency has embraced a systems engineering excellence initiative to enhance the capabilities of systems engineering across the agency. This paper addresses some of the organizational steps that are being taken at the Goddard Space Flight Center to improve the systems engineering capability in support of the Center's programs and projects.
9.3.2 Simulation‐Based Design Using SysML Part 1: A Parametrics Primer
Authors: Peak Russell S. , Burkhart Roger M. , Friedenthal Sanford A. , Wilson Miyako W. , Bajaj Manas , Kim Injoong
Published: November 2014

OMG SysML™ is a modeling language for specifying, analyzing, designing, and verifying complex systems. It is a general‐purpose graphical modeling language with computer‐sensible semantics. This Part 1 paper and its Part 2 companion show how SysML supports simulation‐based design (SBD) via tutorial‐like examples. Our target audience is end users wanting to learn about SysML parametrics in general and its applications to engineering design and analysis in particular. We include background on the development of SysML parametrics that may also be useful for other stakeholders (e.g, vendors and researchers).

In Part 1 we walk through models of simple objects that progressively introduce SysML parametrics concepts. To enhance understanding by comparison and contrast, we present corresponding models based on composable objects (COBs). The COB knowledge representation has provided a conceptual foundation for SysML parametrics, including executability and validation. We end with sample analysis building blocks (ABBs) from mechanics of materials showing how SysML captures engineering knowledge in a reusable form. Part 2 employs these ABBs in a high diversity mechanical example that integrates computer‐aided design and engineering analysis (CAD/CAE).

The object and constraint graph concepts embodied in SysML parametrics and COBs provide modular analysis capabilities based on multi‐directional constraints. These concepts and capabilities provide a semantically rich way to organize and reuse the complex relations and properties that characterize SBD models. Representing relations as non‐causal constraints, which generally accept any valid combination of inputs and outputs, enhances modeling flexibility and expressiveness. We envision SysML becoming a unifying representation of domain‐specific engineering analysis models that include fine‐grain associativity with other domain‐ and system‐level models, ultimately providing fundamental capabilities for next‐generation systems lifecycle management.
9.3.3 Simulation‐Based Design Using SysML Part 2: Celebrating Diversity by Example
Authors: Peak Russell S. , Burkhart Roger M. , Friedenthal Sanford A. , Wilson Miyako W. , Bajaj Manas , Kim Injoong
Published: November 2014

These two companion papers present foundational principles of parametrics in OMG SysML™ and their application to simulation‐based design. Parametrics capabilities have been included in SysML to support integrating engineering analysis with system requirements, behavior, and structure models. This Part 2 paper walks through SysML models for a benchmark tutorial on analysis templates utilizing an airframe system component called a flap linkage. This example highlights how engineering analysis models, such as stress models, are captured in SysML, and then executed by external tools including math solvers and finite element analysis solvers.

We summarize the multi‐representation architecture (MRA) method and how its simulation knowledge patterns support computing environments having a diversity of analysis fidelities, physical behaviors, solution methods, and CAD/CAE tools. SysML and composable object (COB) techniques described in Part 1 together provide the MRA with graphical modeling languages, executable parametrics, and reusable, modular, multi‐directional capabilities.

We also demonstrate additional SysML modeling concepts, including packages, building block libraries, and requirements‐verification‐simulation interrelationships. Results indicate that SysML offers significant promise as a unifying language for a variety of models—from top‐level system models to discipline‐specific leaf‐level models.