TECHNICAL PAPER ABSTRACTS

SESSION 1

 

Session 1 Track 3: Modeling

 

1.3.1           Modeling of Hardware Software Performance of High-Tech Systems

                  G. Muller, Embedded Systems Institute;             P. van den Bosch, Océ Technologies BV

                  M. Verhoef, Chess; O. Florescu, Technical University Eindhoven

 

The performance of the control system is an important aspect of a machine. It would be a waste if a high-tech machine has been build such that it can physically achieve a high throughput, for example printed sheets of paper, but is limited because the software controlling it cannot keep up. Unfortunately, with current techniques it is hard to “predict” beforehand what the performance of the software will be when it finally runs in the real system on the real processor(s). There are two (extreme) ways to deal with it:

1. Over-dimension the hardware platform to make sure the software will run.

2. Implement the software, then run and evaluate its performance on the target hardware platform. Then use this information in the next design cycle.

The disadvantages of both approaches are clear. In the first situation the cost price of the entire system will surely be higher than necessary. In the second case, the design time is increased dramatically because more design cycles are needed. Therefore, it is important to strive to a development method that leads to fast design cycles for software performance, while having an accurate enough prediction. In this paper we will discuss a pragmatic modeling approach to design for performance in the domain of software intensive systems.

 

1.3.2           A Vision for Super-Model Driven Systems Engineering

                  S. R. Piggott, L. Hartman, P. Melanson, Canadian Space Agency

 

Model-Based Systems Engineering (MBSE) has been developing for some time, and has recently acquired new impetus with the completion of the Systems Modeling Language (SysML). This paper envisions taking MBSE much further, to a future of highly integrated and automated design and verification coupled with advances in simulation and domain linkage to allow the synthesis of complete systems from requirements into mathematical models and then into physical realizations. This would permit the application of three of the most successful approaches from agile software development, namely rapid, iterative development of the system starting with the highest value functions, facilitating continual reassessment of the future direction, and continual regression testing to ensure that system bugs are identified and removed rapidly. We envisage the requirements and the model evolving together from proto-requirements and proto-model in increasing detail until the point at which the model can be realized with real hardware and software. Taking this further, the MBSE engine can perform trade-offs and optimization on the design. Implementing this vision requires progress in a number of technologies, such as data exchange between domain tools. At this time, much engineering effort is consumed in people communicating and mediating information and translating it from one form to another (e.g. system design to mechanical design). If we can realize the vision proposed, we can remove much of the burden of information mediation and optimization, allowing engineers to focus on their expertise and larger issues. The potential savings in labour are huge.

 

1.3.3           Hybrid Systems Dynamics, Petri Net, and Agent-Based Modeling of the Air and

                  Space Operations Center

                  B. White, J. Mathieu, J. James, P. Mahoney, L. Boiney, R. Hubbard The MITRE Corporation

 

In an earlier paper, an existing Air and Space Operations Center (AOC) process model (i.e., Petri net) and new global and mission models for the environment in which the AOC operates (i.e., System Dynamics) were linked (federated). The focus of this paper is the development of an operator-environment model (i.e., Agent-Based Model). An existing systems framework for attention allocation of operators within the AOC has been implemented that supports multiple modeling paradigms. The results for linking the Petri net and System Dynamics models are summarized, and new results for the Agent-Based Model are presented based on a pilot-down scenario. It has been observed that many AOC operators can become distracted by a pilot-down critical event, even if the operator is not able to directly assist in the rescue. Furthermore, this distraction has been hypothesized to have a detrimental effect on the activities the non-involved operators are currently handling.

 

1.3.4           Model-Based Design and Verification of Fault-Tolerant Systems

                  M. Sorea, EADS Germany; H. Ruess, IABG mbH

 

There is an increasing trend towards model-based development (MBD) of safety-critical systems. In an MBD approach, various development activities such as simulation, testing, code generation, and verification are based on a single formal model of the system. In this paper we show that the MBD approach can also be applied towards automating the safety analysis process. Using precise formal models of the system as the basis of the analysis helps avoiding design errors at early stages in the development lifecycle. The analysis is automated by means of model-checking tools, which results in a more thorough analysis and reduced manual effort compared to more traditional methods. We illustrate model-based analysis using the fault-tolerant startup protocol for a time-triggered middleware architecture (TTA). For a functional model of this protocol, it is verified that the specified safety requirements are satisfied in the presence of all faults within the given fault hypothesis. We demonstrate that exact, complete, and consistent safety analyses can---and in fact should---be carried out for relevant industrial designs in very early phases of the development life cycle and in an automated fashion.

 

 

Session 1 Track 4: Developing SE Professionals

 

1.4.1           An Integrated Approach to Developing Systems Professionals

                  H. L. Davidz, M. W. Maier, The Aerospace Corporation

 

As the level of integration and the complexity of engineering systems increase, there is an increasing need to develop systems capabilities in engineers.  Often, the demand for increased systems capabilities is automatically translated into a need to develop the systems capabilities of individuals.  However, the systems capabilities of groups and organizations are what really matter for complex engineering systems, and individual capabilities do not automatically translate into group and organizational capabilities.  This paper describes an integrated approach to developing systems professionals.  To guide practitioners in utilizing relevant theoretical issues and research results, a five-step plan to developing systems professionals is given.  First, there is a description of how to frame the relevant problem space.  Next, desired roles and competencies are linked to this problem spectrum.  After describing how to develop an appropriate multi-level strategy, the paper discusses how individual systems skills combine.  Potential assessments for the development approach are shown.  Since group and organizational issues can trump efforts to develop the systems capabilities of individuals, it is important to frame the relevant problem space, match the desired capabilities to that space, and create a multi-level integrated strategy to develop those capabilities in individuals, groups, and organizations.

 

1.4.2           A Model for Successful Engineering Internship: Growing Our Own Future Engineers

                  M. Malloy, The MITRE Corporation

 

UCLA’s Higher Education Research Institute reported there has been a 60% drop in science and engineering majors among incoming college freshmen since the year 2000.  Competition for the dwindling number of graduating entry-level engineers is fierce.  At the same time, the academic experience of engineering rarely emulates what students can expect in the real world.  Students need relevant work opportunities to validate their career plans while keeping them engaged in their engineering degree programs.  Two years ago, we established an Internship Program to respond to both sides of this challenge.  Internship expands the concept of training beyond enhancing the skills of existing staff, to include a company making a training investment in student engineers they might like to hire full-time someday.  In this paper, we provide a template for our successful Internship Program as a model for other employers who would like to “grow their own” entry-level engineers.

 

1.4.3           Challenges in the Development of Systems Engineering as a Profession

                  I. Dixit, University of Southern California; R. Valerdi, Massachusetts Institute of Technology

 

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.4.4           Measurably Improving Your Systems Engineering Requirements

                  T. Olson, Quality Improvement Consultants, Inc. (QIC)

 

Requirements continue to be a major problem area for most organizations.  According to industry reports, the leading causes of quality, cost, and schedule problems are lack of understanding of the customer’s needs, incomplete requirement specifications, and managing changing requirements.  So what can an organization focus on now to improve their systems engineering requirements?  This paper will describe some practical strategies that organizations can use to measurably improve their requirements as well as their requirements process.

 

The objectives of this paper are to:

·         Present some requirements problems from industry.

·         Present a useful classification of requirements problems from the literature.

·         Provide specific strategies to address the requirements problems from the literature.

·         Describe some practical strategies that organizations can use to measurably improve their requirements.

·         Provide some requirements lessons learned and provide some industry references.

 

 

Session 1 Track 5: Intelligent Decisions

 

1.5.1           A Decision Support System to Schedule Design Activities in Aircraft Industry

                  I. Lizarralde, A. Riviere, EADS CRC France; P. Esquirol, LAAS-CNRS

 

This paper highlights the relationship between Project Management and Systems Engineering through a framework proposal that links dependencies management and project scheduling. It investigates the problems of project scheduling at the design stage of the development of a civil aircraft, mainly characterised by a dynamic environment and uncertainties concerning the duration of activities.

This framework is supported by methods dedicated to the management of schedules at tactical levels with fully elastic tasks that takes into account dependencies between design teams as new constraints.

 For end users, this framework can be considered as a Decision Support System (DSS). The DSS is a tool to check if all scheduling constraints are satisfied or to solve over-constrained problems through interactions with end-users. This approach, illustrated with AIRBUS use cases, is flexible enough to be implemented within the aerospace industry, by facilitating cooperation between design teams and by providing the possibility to carry out schedules simulations.

 

1.5.2                       Emerging Real-Time Intelligent Agents In Space Launch Verification and

Anomaly Resolution

                  D. G. Beshore, The Aerospace Corporation

 

In 1997, the Evolved Expendable Launch Vehicle (EELV) program, now under the auspices of the United Launch Alliance (ULA), began with fundamental goals to reduce cost and improve the reliability of launching satellites and interplanetary spacecraft.  With payloads costing more that several billion dollars each, the reliability of launch vehicles mandates perfect launches.  Subsequently, launch systems have become highly complex with increasing launch rates of satellites to perform surveillance, network-centric command and control, and communications on the land, sea, air and space.  Launch system Ground Computers, Command and Control (GC3) has grown exponentially in software capabilities, collecting and displaying data to domain experts, and transmitting real-time data to world-wide support teams. Rapid and accurate anomaly resolution with customers and contractors, especially for events leading up to day-of-launch (DOL) involves hundreds of personnel using these complex systems.  This paper describes near-term capabilities which are the building blocks of future intelligent agents:  decision making, knowledge management; computer systems, control software and desktop PC tools.  These agents are rapidly maturing into integrated systems decision making processes that are responsive within seconds.  This near-term development activity is compared with a 20-year forecast of spaceport intelligent agent systems.

 

1.5.3           Case Study: Tailoring CMM®-Based Command Media for a Company's Individual

                  Business Areas

                  D. Turner, R. Adkins, Harris Corporation

                 

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.

 

1.5.4                       Time-Expanded Decision Networks: A Framework for Designing Evolvable

Complex Systems

                  O. de Weck, M. Silver, Massachusetts Institute of Technology

 

This paper describes the concept of Time-Expanded Decision Networks (TDN), a new methodology to design and analyze flexibility in large-scale complex systems. This includes a preliminary application of the methodology to the design of Heavy Lift Launch Vehicles for NASA’s space exploration initiative. Synthesizing concepts from Decision Theory, Real Options Analysis, Network Optimization, and Scenario Planning, TDN provides a holistic framework to quantify the value of system flexibility, analyze development and operational paths, and identify designs which can allow managers and systems engineers to react more easily to exogenous uncertainty. TDN consists of five principle steps, which can be implemented as a software tool: 1. Design a set of potential system configurations 2. Quantify switching costs to create a “static network” that captures the difficulty of switching among these configurations 3. Create a time-expanded decision network by expanding the static network in time, including chance and decision nodes 4. Evaluate minimum cost paths through the network under plausible operating scenarios 5. Modify the set of initial design configurations to exploit high-leverage switches and repeat the process to convergence. Results can inform decisions about how and where to embed flexibility in order to enable system evolution along various development and operational paths.

 

Session 1 Track 6: SE Processes

 

1.6.1           Using CORE Model-Based Systems Engineering Software to Support Program

                  Management in the U.S. Department of Energy Office of the Biomass Program

                  P. J. Simpkins, Vitech Corporation

                  C. Riley, D. Sandor, National Renewable Energy Laboratory

 

Biomass research has been a cornerstone of the U.S. Department of Energy’s (DOE’s) renewable energy development and deployment efforts during the last 25 years. Today, as the true cost of the nation’s reliance on imported oil becomes increasingly clear, the DOE Biomass Program is poised to bring biomass-derived biofuels to the market as a sustainable, domestic alternative to petroleum-derived fuels. To ensure that the program is focused on the activities critical to achieving this goal, the program is implementing systems engineering processes, practices, and tools to guide informed decision-making as biomass-to-biofuel systems are advanced from concept to commercial adoption. The program is using CORE, a Model-Based Systems Engineering (MBSE) software tool, to organize, coordinate, and document the program goals, milestones, and project tasks in a central repository. CORE is facilitating management and communication of program status, through the automated generation of accurate and up-to-date custom reports, Gantt charts, and tables in Microsoft Word, Microsoft Project, and Microsoft Excel formats, which are widely available to all program participants.

 

 

 

1.6.2           Practical Process Implementation: Using SE Methods to Develop SE Processes

                  J. T. Nolte, D. W. Newbern, P. S. Vanghel, Northrop Grumman

 

At our company, process development and process implementation is taking a new direction. We have completed and revised a robust set of corporate core processes, based on the Capability Maturity Model Integrated (CMMI) that address our primary business areas of systems engineering and system development. However, as our business evolves, we are finding new areas of related activities that are not effectively represented by our current corporate process descriptions. In this paper we present an approach for using SE methods to prepare processes for repeated reuse, in specialized areas. Our preliminary results have already been used to support marketing and business development, showing other current customers our capability and the potential to assist them in a new way. The preliminary results have also been used effectively by staff and project managers to improve management processes on existing programs.

 

1.6.3           Managing Dynamic New Product Development Processes

                  Y. Reich, A. Karniel, Tel Aviv University

 

New Product Development (NPD) processes are considered most challenging, involving major risks due to unknown or unforeseen obstacles, in terms of technology and business risks. The actual process activities which depend on the evolving product knowledge could be determined only during process execution. Thus, process planning is inherently dynamic and requires adaptation to product knowledge changes as well as other changes. Current Workflow tools can support ad-hoc changes, but do not support the planning of process dynamics and the execution of such dynamic process changes as they unfold.

 

The current article presents a novel system framework for managing dynamic process planning changes resulting from changes in customer requirements, product structure, product parametric dependencies and constraints, as well as ad-hoc changes. The proposed framework comprises: process planning, incorporating the Design Structure Matrix (DSM) method; business rules for interprating the DSM-based plan to process plan; dynamic process plan changes; and implementation of changes into Run Time process simulation.

 

1.6.4           Synthesizing the Organizational System

                  E. P. Arnold, BAE Systems Land & Armaments

 

All Change is inevitable.  The pace at which change transpires and the complexity of that change is dependent upon the:

1) Number of concurrent change drivers

2) Degree to which the drivers are instituted

3) Cultural acceptance of the drivers

4) Capacity (Resources) to implement the change, and

5) Application of system synthesis

 

At BAE Systems Land & Armaments, Armament Systems, the realization that the numerous initiatives and business drivers required for our business unit to become world class, required the combining of separate elements to form a coherent whole; system synthesis. Synthesizing the organization is a key to intelligent enterprise, since it is lean, adaptive, and agile.

 

The major initiatives and business drivers used for illustration of our organizational system in this presentation include:

1. Armament System's Business Process Model

2. International Standards Organization (ISO) Standards

3. BAE Systems corporate flow down of their Life Cycle Management processes

4. Capability Maturity Model Integrated (CMMI®)

 

This presentation addresses how CMMI® acted as an enabler, to help drive the synthesis of our business initiatives in pursuit of an integrated organizational system. The interaction of these multiple forces results in a combined effect that is greater than the sum of their individual effects. CMMI® has acted as the change agent to drive cooperative interaction among our internal groups and is aiding in our business units’ transition as a recently acquired BAE Systems unit. CMMI® provides a common language of communication and lays the foundation for the interconnected links among the elements.

 

SESSION 2

 

Session 2 Track 1: Drivers for SE

 

2.1.1           Defining Lean Systems Engineering Processes and Procedures

                  T. Olson, Quality Improvement Consultants, Inc.

 

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:

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

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

3. Describe some success stories in real organizations.

4. Provide some lessons learned.

 

2.1.2           Milestone Driven Systems Engineering Methods

                  B. H. Wells, Raytheon

 

Methods are presented that have been used successfully on large programs including a $3B development program that reached the System Requirements Review (SRR), Preliminary Design Review (PDR) and Critical Design Review (CDR) on or ahead of schedule. These methods link the non-systems engineering activities into the system engineering processes and provides an effective means of communication and coordination between the systems engineers and design engineers to reduce the risk of achieving each milestone successfully.  These methods augment the established systems engineering processes for technical reviews and use the milestone events as the impetus to drive the team and the program forward.

 

2.1.3                       The US Ballistic Missile Defense System: A Case Study in Architecting

                  Systems-of-Systems

                  H. L. Hollon, C. H. Dagli, University of Missouri-Rolla

 

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.

 

Session 2 Track 2: Requirements & Stakeholders

 

2.2.1           Eight Deadly Defects in Systems Engineering and How to Fix Them

                  J. E. Kasser, SEEC/University of South Australia

 

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.2           Using Stakeholder Analysis to Define the Problem in Systems Engineering

                  T. E. Trainor, G. S. Parnell, Department of Systems Engineering, USMA

 

The first step in most system life cycles is the problem definition.  Stakeholder analysis is a key technique to insure the problem has been fully and completely described before we attempt to obtain a solution to the problem.  We identify and describe the three most common techniques for stakeholder analysis:  interviews, focus groups, and surveys.  We compare the three techniques using five criteria: time commitment of participants, ideal stakeholder group, preparation, execution, and analysis.  We identify best practices to make stakeholder analysis both effective and efficient.  This paper will aid the new practitioner and student of systems engineering as they organize and execute an effective stakeholder analysis, which is critical to the success of any systems engineering project.

 

2.2.3           Combined Requirements Engineering (CRE): The Quest for Widening the

                        Applicability of Requirements Engineering Practices in the Emerging

                  Product-Service Paradigm

                  V. Agouridas, University of Leeds; M. Kossmann, University of West England and Airbus UK

 

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.

 

Session 2 Track 3: Modeling

 

2.3.1           Benefits and Costs of Model-Based Fault Diagnosis for Semiconductor

                  Manufacturing Equipment

                  J. Pietersma, A. J. van Gemund, Delft University of Technology

 

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.3.2           Model-Based Techniques for Intelligent Integration and Testing in Industry

                  N. Braspenning, J. van de Mortel-Fronczak, J. Rooda, Eindhoven University of Technology

                  D. van der Ploeg, ASML Netherlands B.V.

 

The effort required for integration and testing of high-tech multi-disciplinary systems is increasing with each new or upgraded system that is developed. To counter this trend of increasing integration and test lead time and costs, we propose a model-based integration and testing (MBI&T) method, where formal and executable models of the system components are used to replace the component realizations for early integration and system testing. In this paper, we describe how the integration and testing process currently used in industry can be made more intelligent by applying model-based techniques from the MBI&T method. We also show how to analyze the necessary trade-off between the investments needed for model development and the potential effort reduction, using a systematic and automatic integration sequencing method.

                 

2.3.3           HCI Aspects of SysML and Architectural Frameworks

                  M. C. Hause, F. Thom, Artisan Software Tools

 

The Human Computer Interface (HCI) is one of the most important aspects of any system. It governs how people perceive the environment in which the system is deployed, and can either enable or hinder their ability to interact with that environment. Specifying the appropriate characteristics of the interface is therefore crucial to the correct implementation of the system. The goals of HCI are to develop or improve the safety, utility, effectiveness, efficiency, and usability of systems that include computers. The challenges for HCI are to keep abreast of technology, and to ensure that their designs offer good HCI, as well as harnessing the potential functionality of the new technology. As SysML becomes more prevalent for modeling systems, integrating HCI aspects into these models has the potential for improving HCI, eliminating duplication of tasks, and making systems more useable. This paper will look at SysML and DoDAF/MoDAF (MAF) and how they contribute towards defining the parameters in which the HCI will take place.

 

 

 

 

 

 

Session 2 Track 4: Decision Assessment

 

2.4.1           Decision Analysis for Design Trades for A Combined Scientific-Technological

                  Mission Orbit on Venus Micro Satellite

                  J. Herscovitz, D. L. Barnett, RAFAEL

                 

The scope of the VENµS Technological Mission is to evaluate and qualify the IHET (Israeli Hall Effect Thruster) performance in space and to use the IHET for mission enhancement. IHET will be used to demonstrate space missions that require high ΔV and are hardly achievable using traditional chemical propulsion in microsatellties.

During the satellite's third mission phase (VM3) the VENµS satellite will fly in a high drag environment. The IHET will be used for autonomous orbit maintenance to enable continuation of the scientific mission, which is vegetation monitoring.

 

This paper describes the selection of VM3 orbit. Different orbit candidate alternatives were compared according to pre-determined criteria and weighted accordingly, using the NGT technique. After all candidate alternatives were analyzed, they were compared using a Decision Analysis for Design Trades method. Based on the analysis, the final orbit was chosen.

 

2.4.2                       Incorporating Software Cost and Risk Assessment into Early System

Development Trade Studies

                  K. A. Weiss, Jet Propulsion Laboratory;

                  N. G. Leveson, Massachusetts Institute of Technology;             J. Francis, Payload Systems, Inc.

 

This paper introduces a new method called SOCRATES (Software Cost and Risk Assessment for Trade and Engineering Studies) for incorporating software cost and risk assessment into the early concept development activities and trade studies typically conducted for complex systems.  Early conceptual architecture trade studies often omit software cost and risk in architectural comparisons.  However, the increasing importance of software in complex system design and its impact on project risk necessitates consideration of the cost and risk associated with developing and fielding software in early engineering architectural trade studies.  SOCRATES takes into consideration the allocation of functionality to both software and human controllers and evaluates the utility of assigning control based on development cost, development risk, and mission risk.  It also provides input to system engineers about the relative comparison of the cost and risk for a variety of system architecture concepts as well as recommendations based on the results.  The technique is demonstrated on the Lunar and Mars Transportation and Surface Operations Architectures developed for the NASA Exploration Initiative Concept Exploration and Refinement Study.

 

2.4.3           Does INCOSE Need PR?

                  A. Zonnenshain, RAFAEL

 

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.

SESSION 3

 

Session 3 Track 1: Systems of Systems

 

3.1.1           System of Systems Engineering Model by Multistage Analytical

                  Target Cascading

                  H. M. Kim, University of Illinois at Urbana-Champaign

 

This paper presents a multilevel, multistage approach to system of systems engineering optimization where a system design/selection is linked with system allocation along the multistage decision making horizon. The approach is composed of two parts: pseudo-hierarchical formulation (i.e., how to model the stages of multiple, separate decision making processes), and multistage coordination (i.e., how efficiently the proposed model would perform). The pseudo-hierarchical formulation expands the analytical target cascading previously developed by the author into multiple stages to capture level-by-level and stage-by-stage system of systems design optimization. The multistage coordination is based on the alternating directions method that is incorporated as an efficient means to solve this inherently large-scale optimization problem. An airline example validates the methodology where an airline plans to introduce multiple new aircraft to capture dynamically changing future demand of the customers. The proposed methodology is validated against the all-in-one approach and the sequential approach.

 

3.1.2           Architecture-Based Drivers for System-of-Systems and Family-of-Systems Cost

                  Estimating

                  G. Wang, P. Wardle, A. Ankrum, BAE Systems

 

As the industry undergoes a paradigm shift from a system-based procurement model to a capability-based acquisition model with a focus on integration of legacy systems and interoperability of systems of systems and families of systems, new challenges have emerged for the field of cost estimating.  What is the cost of an operational capability in a net centric environment based on enterprise architecture?  This paper explores a set of enterprise architecture-based drivers for estimating the life cycle cost or total ownership cost of operational capabilities from integration of complex systems of systems and families of systems.  It attempts to extend the traditional systems engineering practices and to address the new challenges from capability-based engineering and interoperability of systems of systems.

 

3.1.3           Exploring Intelligent Entreprise System Limitations

                  K. D. Palmer, SEEC Student

 

In this paper we will consider the implications of Meta-systems Engineering for Intelligent Enterprises. We may think of this as the dark side of intelligent enterprise systems. Our essay is a search for light at the end of this tunnel by employing the theory of Special Systems and the Emergent Meta-system. This work brings together advanced theories in order to redefine the nature of the Intelligent Enterprise and Enterprise in general.

 

Session 3 Track 2: Framework & Commonality

 

3.2.1           An Enterprise Architecture Framework for Developing Command and Control Systems

                  L. Yeoh, C. Lam, Defence Science and Technology Agency

                  H. Syn, ST Electronics (Info-software Systems) Pte Ltd

           

In recent years, the way in which military operations are being conducted has changed dramatically. This has largely been driven by advancements in technology that now allow faster communications, better situation assessment and more effective decision-making. Military forces are now striving to realize the next stage of transformation by harnessing new technology to create a network-centric enterprise that takes advantage of pervasive knowledge in order to achieve greater war-fighting capability.  Integrated Knowledge-Based Command and Control (IKC2) is an integrated, network-enabled and knowledge-based approach to warfare that bears similarities to the intelligent enterprise. It is a force multiplier that will enable military forces to achieve their desired mission objectives. However, there are many challenges to the successful development of IKC2 systems.

 

3.2.2           Enabling Economics-Driven Systems Engineering Through Reusable Software

                  Architectures and Components

                  R. W. Selby,  Northrop Grumman

 

Economics-driven systems engineering integrates system design principles with measurement-based analyses of value, options, and tradeoffs.  This study helps enable economics-driven systems engineering by describing an example of measurement-based analysis of software reuse in large-scale systems.  Software reuse enables developers to leverage past accomplishments and facilitates significant improvements in software productivity and quality.  Software reuse catalyzes gains in productivity by avoiding redevelopment and gains in quality by incorporating components whose reliability has already been established.  The purpose of this study is to characterize software reuse empirically by investigating one development environment that actively reuses software.  Twenty-five software systems ranging from 3000 to 112,000 source lines have been selected for analysis from a NASA systems development environment.  The amount of software either reused or modified from previous systems averages 32% per project in this environment.  Non-parametric statistical models are applied to examine numerous development variables across the software modules in the systems.  This research focuses on initial results and graphical characterizations of the data.  Four classes of software modules are analyzed: (a) modules reused without revision, (b) modules reused with slight revision (< 25% changes), (c) modules reused with major revision (³ 25% changes), and (d) newly developed modules.  The modules reused without revision had the fewest faults, lowest fault correction effort, and lowest fault densities.  In conclusion, we outline future research directions that build on these strategies and ideas.

 

3.2.3           Divergence: The Impact of Lifecycle Changes on Commonality

                  R. Boas, E. Crawley, MIT

 

Sharing common parts, processes, interfaces and infrastructure offers the potential to increase the overall efficiency and effectiveness of an enterprise through reductions in costs, lead times and risks associated with the development of product/system families.  While the benefits of commonality have attracted much interest across industry, the government and academia, the current practice and research fail to account for a significant challenge associated with commonality:  the natural reduction of commonality over time, a phenomenon termed “divergence.”  Divergence occurs due to requirements changes; learning in development and operations; the availability of new technologies; obsolescence; program timing; and for reasons associated with corporate culture.  The impact of divergence is an overestimation of the benefits of commonality:  planned benefits aren’t realized through the course of development while the penalties of pursuing commonality (cost, time, risk, performance) are incurred.  The TFX (F-111) fighter aircraft program of the 1960’s is provided as a historical example of divergence and its impacts.  Accounting for divergence will improve multi-system program planning and execution.

 

Session 3 Track 3: Modeling

 

3.3.1           Driving System Development Process from Strategic Goals to Requirements

                  Specification

                  H. El Ghazi, Centre de recherche en informatique (C.R)

 

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

                  G. Muller, Embedded Systems Institute

 

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.3           Reuse and Usage for System Engineering Model Elements

                  D. K. Smith, UGS

 

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.

 

Session 3 Track 4: Value of SE

 

3.4.1           Promoting The Real Value of Systems Engineering Using an Extended SCARIT

                  Process Model

                  S. J. Saunders, Raytheon Australia Pty. Ltd.

 

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

                  R Valerdi, Massachusetts Institute of Technology;

                  B. W. Boehm, University of Southern California

                  E. Honour, University of South Australia & Honourcode, Inc.

 

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.

 

3.4.3                       The Value-Based Theory of Systems Engineering:

                  Identifying and Explaining Dependencies

                  B. Boehm,  A. Jain, University of Southern California

 

The Value-Based Theory of Systems Engineering brings together many interdisciplinary theoretical lenses into a state of synchrony and allows reasoning about systems in different dimensions, and at various levels of abstraction. The theory’s primary strength is in its ability to identify and work through the dependencies of most socio-political-technical systems and explain success in such contexts by situating the success-critical stakeholders at the forefront. In this paper we present the 4+1 theoretical lenses of the Value-Based Theory of Systems Engineering with a core emphasis on the Dependency Theory – the first and most complex of the four component theories.

 

SESSION 4

 

Session 4 Track 4: Review Approaches

 

4.4.1           Rule-Based Design Reviews

                  T. S. Gilb, RPL

 

Design reviews would benefit from the support of Specification Quality Control (SQC). By the use of SQC with a set of relevant design review rules, it should be possible to ensure prior to a design review that all the relevant information for a review is present in the design specifications, and that all the minimum review criteria are met. This will ensure management time is not wasted and aid better decision-making.

 

In addition, this paper outlines the impact of Evolutionary Project Management (Evo) on the design review process.

 

 

 

 

 

4.4.2           Measurement-Driven Systems Engineering Using Six Sigma Techniques to Improve

                  Software Defect Detection

                  R. W. Selby, P. C. Selby, Northrop Grumman

 

System developers and managers continually strive to identify, undertake, and realize improvements in system development methods. Measurement-driven systems engineering guides the identification of improvement opportunities and enables the quantitative evaluation of progress and benefits.  Six Sigma techniques provide a structured approach for using measurement-driven methods to decrease the variances and shift the means of user-defined metrics such as defect densities, development cycletimes, and resource expenditures.  This research investigates the effectiveness of software defection detection using peer reviews across 12 system development phases on 14 large-scale systems.  This study analyzes 3418 defects from 731 peer reviews and benchmarks the defect injection and detection performance across the 12 system development phases.  Six Sigma techniques including the define-measure-analyze-improve-control (DMAIC) method, root cause analysis, and control charts helped achieve in-phase detection of 95 percent of defects and realize over 50 percent improvements in defect densities and closure cycletimes for certain peer review types.

                 

4.4.3           Applying Measurement Principles and Adapting a Defect Predictability Model to

                  Hardware Development

                  P. J. Frenz, General Dynamics Advanced Information Systems

 

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.4.4           Systems Architecture: A View Based on Multiple Impacts

                  T. S. Gilb, RPL

 

In order to properly support the systems engineering process, the systems engineering profession needs to consciously adopt a more productive view of systems architecture. Many existing definitions of systems architecture are too narrow: they focus too much on ‘structure.’ The focus needs to be shifted to the impact on requirements.

 

Session 4 Track 5: Uncertainty & Knowledge Management

 

4.5.1           Extracting Value from Uncertainty: A Methodology for Engineering Systems Design

                  M. Cardin, R. de Neufville, Massachusetts Institute of Technology

                  W. J. Nuttall, University of Cambridge; J. Dahlgren, The MITRE Corporation

 

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.2           Knowledge Management- A Key Element of Success

                  L. P. Long, The Boeing Company; C. H. Dagali, Univeristy of Missouri-Rolla

 

Knowledge Management is a complex and elusive goal that is becoming more and more important to organizational success.   Modeling Knowledge Management in today’s organizational environment requires the consideration of not only integrated domains of various knowledge agents but also the realization that in order to construct knowledge (and ultimately intelligence) you must consider the aspect of time variance, data/information value, and knowledge recognition and placement.  An individual can not stand fixed in the present and expect the data and information collected in the past to represent the same knowledge when projected into the present.  Knowledge (and Knowledge Value) is relative to the position on the historical time line at which it was initially established. The act of collecting data and information is insufficient for knowledge generation. If you apply a time-knowledge model relationship then the value of knowledge will have a different increasing value all along the timeline, thus helping to ensure that today’s knowledge is more capable of meeting the needs of the present as well as establishing a stronger foundation for the future. 

 

As products increase in complexity and manufacturing is distributed among a multitude of stakeholders, the knowledge of how to maneuver through the maze of system integration and product life cycle dynamics while maintaining a margin of profitability have significant commercial advantages. 

 

The need for successful Knowledge Management is essential to maintaining a competitive edge in the business environment.  Understanding the relationships between data, knowledge and the intra-related processes which represent the collective knowledge for success can be complex.  In the paragraphs that follow, the reader is encouraged to follow the knowledge model that relates the elements of organizational knowledge management as it models data & knowledge, and processes to establish a set of solutions from which one optimum solution emerges to satisfy the initial goal or Program.

 

4.5.3           Defining Military Pilot Training Requirements for 2015+ through the Application of

                  Systems Approaches

                  J. Cleveley, M. Woodhead, Loughborough University

                 

This paper describes the requirements established for a Military Pilot Training System in 2015, and the predicted environment in which such a system would be required to operate. The paper outlines the derivation of these findings by describing the following:

•     The systems approach to the problem.

•     The tools and techniques employed in developing a Military Pilot Training System (MPTS) model.

•     How the MPTS model was used to determine the Military Pilot Training Requirements for present day.

•     The key areas of research performed (both for present day and 2015 and beyond) leading to the definition of the environment in which a 2015 military pilot training system would have to operate.

•     How the MPTS model was used to determine the Military Pilot Training Requirements for 2015.

•     Validation of the MPTS

The document will confirm that there is a continuing market for new and existing military pilot training systems into 2015 and beyond, detailing the specific key factors that must be addressed for such a system to be successful in a 2015 environment.

 

4.5.4                       Dialogic Design for the Intelligent Enterprise:

                  Collaborative Strategy, Process, and Action

                  P. H. Jones, Redesign Research; A. N. Christakis, T. Flanagan, Dialogic Design International

 

Dialogic design provides efficient, reliable approaches for organizations to envision and implement cohesive, comprehensive, and compelling roadmaps for enterprise evolution. Using structured dialogue to integrate the collective intelligence of stakeholders, we produce a shared representation of the intelligent enterprise, enabling “organizing around intellect.” Dialogic design is progressive in focus, scaling from strategic vision to business process design to system requirements, mapping each level’s priorities to successive requirements. Each focus inquiry iterates from deep problem understanding, to generative solution design, through consensus action planning.

 

We applied Structured Dialogic Design to the transformation of a small consultancy, with findings applicable to any enterprise. The process efficiently enables a democratic, collaborative approach to redesign of socio-organizational systems and practices, using a software-supported collaborative process. It efficiently achieves true consensus on organizational and business strategy, resolves multiple conflicts of values and resource decisions, and determines the most effective priorities while preventing groupthink errors.

 

Session 4 Track 6: SE Standards

 

4.6.1           Applying Creativity in Modelling and Simulation

                  D. H. Cropley, SEEC/University of South Australia

 

This paper examines the application of concepts and principles of creativity to the domain of modelling and simulation. The paper will start by examining the background to modern views of creativity in technological enterprises. This culminates with a functional model of creativity that focuses not only on characteristics such as novelty, but also on the pre-requisite characteristic of relevance and effectiveness. This means that for a product or system, or indeed a model or simulation, to be regarded as creative, it must not only be original and novel, but must, as a pre-requisite, do what it has been designed to do. For this reason, issues such as fidelity, and other quality metrics applied to models, will be relevant. The paper then examines reasons for endeavouring to build creativity into modelling and simulation. The paper will study potential benefits and penalties associated with creativity in this domain, and will offer suggestions about the appropriateness, or otherwise, of attempting to build novelty into the process of modelling and simulation.

 

4.6.2           YADSES: Yet Another Darn Systems Engineering Standard

                  D. D. Walden, Sysnovation, LLC

 

It has happened to most everyone – someone releases the “next best” Systems Engineering standard (or method or tool or …) and your organization has decided to use it. How does one incorporate this new standard into the existing set of organizational processes without “breaking” the current processes and negatively impacting compliance to all the “old” standards that do not go away? By the way, expect to repeat this process at least every other year.

 

This paper gives practical advice to help ensure organizations are prepared for these types of situations. Guidance is given on how to establish and maintain organizational processes such that the introduction of Yet Another Darn Systems Engineering Standard (or YADSES as we will refer to it) causes minimal impact.

 

4.6.3           Self-Assessment Scheme and an Evaluation of Its Reliability Based on ISO 9004:2000

                  Y. Hwang, S. Kim, Electronics and Telecommunications Research Institute

                  D. Kim, Carleton University

 

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 Hierachical Team Project at Final Year

                  Undergraduate Level

                  T. L. Ferris, SEEC/University of South Australia

 

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.

 

 

SESSION 5

 

Session 5 Track 1: Intelligent Enterprises

 

5.1.1                       System Evolution in the Intelligent Enterprise: An Historical Case Study of

                  VISA's Transaction Processing Systems

                  M. S. Cokus, J. W. Dahlgren, The MITRE Corporation

                 

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.1.2           Integrating the Intelligent Enterprise

                  K. Dixon, University of Bath; S. Brown, BAE Systems; J. Keirl, Dstl

 

The need for enterprise intelligence continues to grow in response to increasingly complex and dynamic organizational environments. However, an intelligent enterprise is comprised of more than a collection of intelligent resources. Like an effective team the whole is made greater than the parts by the manner in which they integrate. Enterprise intelligence enables an organization to both fully exploit existing opportunities whilst remaining capable and ready to respond to future change. In this paper we focus on the contribution made to this dynamic stability by the systemic integration of resources. Using a multi-level systems model we develop a framework, drawing on the concept of intellectual capital, to examine data from a case study of a UK government funded research organization. The findings provide an important insight into the interplay between the social and structural aspects of the linkages that integrate resources and the implications this has for creating enterprise intelligence.

 

5.1.3           Seven Secret Tips To Build Intelligent Enterprise Architectures

                  J. W. Carl, Riverside Research Institute; J. M. Colombi, Air Force Institute of Technology

 

An article in the Fall 2006 issue of INCOSE Insight about the 2007 INCOSE International Symposium [Insight, 2006] cited four behaviors needed for an enterprise to exhibit intelligence: (1) It measures both the value of results to stakeholders and the conformance of results to principles of systems and society; (2) It maintains precise awareness of the enterprise situation with respect to goals; (3) It adapts to and aligns the enterprise with changes in context and capabilities in pursuit of improving goal achievement and sustainable worth; and (4) It ensures enterprise integrity even when all factors are changing unpredictably.

 

Unfortunately, knowing that these behaviors signify an intelligent enterprise does not tell us how to build intelligent enterprise architectures. But there are seven secret tips gained through hard experience that can substantially contribute to the construction of successful enterprise architectures. Well, they’re really not secret, but if they were widely practiced we wouldn’t hear Cobb’s Paradox [Cobb, 2004]: "We know why projects fail, we know how to prevent their failure ─ so why do they still fail?"

 

Session 5 Track 4: Validation & Verification

 

5.4.1           The Continued Evolution of Validation: Issues and Answers

                  J. R. Armstrong, Systems and Software Consortium

 

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.

 

5.4.2           MV² Tool : A Management Tool for the of Validation and Verification of

                  Requirements by Airbus

                  C. Ducamp, A. Lagarrigue, Airbus

 

As the final integrator of the whole of systems and structures, equipments and engines that compose the aircraft, Airbus developed an Information System to manage product requirements and deployed it on a transnational basis. The specification of the tool - labeled MV² - was based on the process of V&V (Validation & Verification) of requirements applied to a given aircraft program. Apart from the requirements related to its environment of use, and of the interfaces with the existing processes, the tools or databases already in place, the mission of Airbus was to make sure it could control the satisfaction of all the users involved throughout the life cycle of the product in the activities of validation and verification of the requirements.

 

The results obtained by MV², already applied to the A380 and A400M programs, corroborated the strategy carried out by Airbus, i.e.:

- to manage the operational state of a function, a system, an equipment, a structural part, for the whole requirements applied to them.

- to challenge the response times between the test results or analyses and the modification of the functional elements, considered at the elementary product level as well as at the comprehensive product level.

 

5.4.3           Usability of Formal Verification on EFFBD Models:

                        Applying Petri Nets to Systems Engineering Issues

                  C. M. Seidner, IRCCyN – SODIUS; J. Lerat, SODIUS; O. H. Roux, IRCCyN

 

Assessing the safety and the dependability of a system is one of the systems engineer’s main targets. Formal tools, however powerful they may be to meet these issues, are often too cumbersome and complex to use. In this paper, we show that efficient formal methods can be used on high-level models used in Systems Engineering to achieve some verification and validation processes. We give an overview of ongoing work on the translation of EFFBD-like models to time Petri nets, using model transformation and meta-modeling. We also present some encouraging results obtained with a prototype translation tool.

SESSION 6

 

Session 6 Track 1: Complexity

 

6.1.1           Principles of Complex Systems for Systems Engineering

                  S. A. Sheard, Third Millennium Systems LLC

 

This paper shows how three systems of types well-known to systems engineers can be understood as complex systems. This is important because research in complex systems sciences is vibrant and provides critical insight, but if systems engineers do not understand the complex aspects of the systems they work with daily, they may not be able to use these research results. To date, systems engineering has been looking only at exploiting the “order” side of the order-to-chaos spectrum, and it is time now to understand and begin to utilize principles from the middle and from the chaos side of the spectrum.

 

The three examples are INCOSE, the systems engineering process (such as a company’s standard process), and air traffic control. INCOSE represents most volunteer organizations and social groups.  Most systems engineers do not realize that the systems engineering process for a company is a network that can be studied by complex systems methods.  Air traffic control may come closest to many systems engineers’ definition of a system.

 

This paper provides principles of complex systems based on a variety of sources, and shows the appli­cation of complex systems to one of the examples.

 

6.1.2           Overcoming Engineering Challenges of Providing an Effective User Interface

                        to a Large Scale Distributed Synthetic Environment on the US Teragrid:

                  A Systems Engineering Success Story

                  R. S. Kalawsky, I. R. Holmes, Loughborough University

 

Over recent years large scale distributed synthetic environment enterprises have been evolving in a diverse range of scientific and engineering fields. These computer modelling and simulation systems are increasing in scale and dimension in order to allow scientists and engineers to explore the attributes and emergent properties of a given system design. Within the field of computational science the grid has been developed to facilitate very large scale collaborative simulation enterprises. The grid is similar to DIS/HLA in that it supports interconnectivity but differs in the sense that it supports intercommunication of large super computing resources. An important factor in the rapid adoption of the grid has been its role in enabling access to significant supercomputing resources not usually available at a single institution. However, the major challenge for the grid has been the lack of an effective and ubiquitous interface to the huge computational resource (which can comprise over 6000 CPUs distributed across the globe) at any time and from any location. This paper describes a unique user interface built on systems engineering principles and practices to solve the problem of delivering real-time interaction (from lightweight computing devices such as PDAs to high end computing platforms) with simulations delivering high resolution 3D images. The application of our work is likely to have far reaching benefits for many sectors including: aerospace, medical informatics, engineering design, distributed simulation and modelling.

 

6.1.3           Organizational Strategies for Systems Engineering Capability Improvement

                  M. M. So, J. F. Andary, M. Caldwell, NASA/Goddard Space Flight Center

 

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.

 

 

 

Session 6 Track 2: Organizational Challenges

 

6.2.1           From Foresight to Insight: A Strategic Alignment Model for New Product Development

                  H. Lee, INER & National Tsing Hua University; C. Liu, M. Lee, National Tsing Hua University

 

The most important roles of strategic management concern about the right “attention” and the right “execution.” Based on this idea, the research question of this study is “How to align the strategy of a company to new product development?” This paper will focus on the longitudinal deployment of strategy and try to provide a solid methodology of strategic alignment to penetrate the multiple management levels of a company. Based on Ansoff’s gap analysis model of strategic management, roadmapping techniques of management of technology, Work Breakdown Structure of project management, a Strategic Alignment Model for New Product Development (SAM-NPD) is proposed in this study. A Six-Echelon model, including industry, market, product, technology, intellectual property and cost structure analyses, is also developed for guiding the implementation of the SAM-NPD model. Finally, a

longitudinal case study of the successful application of this methodology in Taiwan is illustrated.

 

6.2.2           Requirements for Outsourcing

                  T. S. Gilb, RPL

 

Outsourcing differs from other development because there is bound to be a contractual relationship, probably a geographic distance, a different sense of loyalty, language misunderstandings, cultural differences, reluctance to speak up to the client – and many other associated problems. Good requirements are always a problem, but outsourcing increases the problems, and makes even great demands on the requirements specification.  The payoff for doing good requirements is greater, and the penalty for not doing them is more threatening.

 

I am going to argue that we need to make use of far more explicit background specification for each requirement, a page or more of specification for each requirement. I will argue that this is a necessary investment – because failure to do so will probably cost far more – sooner or later. I will argue that failure to be more detailed than normal will be counted in the clients disfavor in any legal proceedings trying to determine responsibility for failure of the project.

 

6.2.3           Five Avoidable Problems in Process Improvement

                  M. Hoppe, HOOD Group

 

Several factors are the sources for the increasing pressure on companies to change. However, a majority of change programmes fail. In this paper we discuss five avoidable problems in improvement initiatives that may lead to such project failures. To each problem we suggest a solution, and describe how it can be implemented in a simple way. The solutions are: create problem awareness, allocate key people that are able and willing to support the project teams, start with one pilot project, allocate qualification topics to roles, and define project milestones and review criteria.

 

Session 6 Track 4: Frameworks

 

6.4.1           The Hitchins-Kasser-Massie (HKM) Framework for Systems Engineering

                  J. E. Kasser, SEEC/University of South Australia

 

George Friedman (Friedman, 2006) called for the development of a grand unified theory of systems engineering (GUTSE) echoing (Hill and Warfield, 1972) who wrote “development of a theory of systems engineering that will be broadly accepted is much to be desired.” Taking up the spirit of the challenge, this paper applies systems thinking to systems engineering to propose a framework that can serve as a vital element in formalizing the discipline of systems engineering and potentially as a platform for developing such a theory.

 

This paper focuses on what systems engineers do, and builds on past research and success. Documenting research using an object-oriented approach in a creative and innovative manner it discusses the evolution of a proposed framework for systems engineering that meets or shows promise of meeting the following four requirements (Kasser, 2006):

 

1. The framework shall provide an understanding of why systems engineers can’t

    agree on their roles and activities.

2. The framework shall provide an understanding of the reasons for the overlap

     between systems engineering and management.

3. The framework shall provide a way to cope with complexity.

4. The framework shall enable the lowering of the cost of doing work by at least an

    order of magnitude.

 

The framework is based on a combination of the Hitchins’ five-layer representation of systems engineering (Hitchins, 2000) extended by Kasser and Massie over the systems lifecycle phases (Kasser and Massie, 2001) coupled with Shenhar and Bonen’s taxonomy of systems based on technological uncertainty (risk) (Shenhar and Bonen, 1997).

 

6.4.2           A Metric Framework for Capability Definition, Engineering and Management

                  S. Lam, J. G. Pogotto, Defence Research and Development Canada

                  C. Pogue,  D. Hales, CAE Professional Services Canada

 

As defence planning and management evolves from a platform-centric, threat-based approach toward a capability-based paradigm, the need for a rigorous approach to systems engineering at the capability level is amplified.  This is because capability-based plans incorporate system-of-systems configurations with varying developmental timeframes that must deliver interoperable effects on the battlefield.  In addressing this challenge, a capability-based planning construct is being examined within the Department of National Defence.  This construct is supported by integrating and enabling concepts like enterprise architectures, system-of-systems engineering principles and capability metrics.  While an architecture framework is useful for developing functional requirements of a capability, a metric framework, as this paper contends, can be used as a guide for defining and articulating desired quality characteristics. This paper describes the concept of a capability metric framework, and how it has been applied to define capability goals and evaluate implementation options.

 

6.4.3           Architecture Frameworks in System Design: Motivation, Theory, and Implementation

                  M. G. Richards, N. Shah,             D. Hastings, D. Rhodes, Massachusetts Institute of Technology

 

This research examines the underlying rationale of architecture frameworks and their use in acquisition with the goal of identifying best practices to improve system development.    Three key questions are addressed: (1) What is the role of artifacts in system design? (2) What are the benefits provided by architecture frameworks? And (3) what are the best measures-of-effectiveness for assessing the value of architecture frameworks?  To address the first question, we review relevant literature on collaborative design and propose a rationale for using artifacts as communicative and illustrative tools.  Second, we enumerate the motivations for their use in system design and acquisition.  Third, eight measures-of-effectiveness of architecture frameworks are derived from the literature and our experience with the Department of Defense Architecture Framework.

SESSION 7

 

Session 7 Track 1: Communities & SE

 

7.1.1           No Vehicles on the Mall

                  C. Pringle,  R. S. Carson, Central Washington University

 

Systems Engineering methods are applied to address symptomatic problems associated with pedestrian-vehicle interactions on a university campus. Through discovery techniques a more accurate picture of the true problem is obtained. Using system modeling, potential consequences associated with proposed solutions are identified. An optimized solution was identified which maximized benefits without incurring unacceptable costs. This application of Systems Engineering shows the value of problem definition and analysis prior to solution implementation in the domain of public policy.

 

7.1.2           Analysis of Singapore's 1991 Strategic Economic Plan Using the Large Scale

                  Systems Engineering Framework

                  E. Chia, Defence Science and Technology Agency

 

Planning for large-scale systems such as a country’s economy is a huge undertaking and fraught with difficulties. This paper explores how such an undertaking could be managed using the large-scale systems engineering framework. It uses the Singapore’s Strategic Economic Plan of 1991 to retrospectively examine how well the large-scale systems engineering framework could have measured up to such a Plan. It was found that such a framework is effective in understanding the complexities of and planning for such a large-scale system.

 

7.1.3           The Story of Verdal:  How One Intelligent Community Uses Systems Engineering to

                  Enable Sustainable Development

                  C. Haskins, NTNU

 

Verdal is a small community in mid-northern Norway, with a culturally significant historical tradition dating back to 1030. The town has reinvented itself to keep abreast of changing times; moving from an agriculturally based economy to an industrial region. The changes have been mostly evolutionary and unscripted until 1999 when a downturn in the business of the largest employer threatened the welfare of the entire community. Today, Verdal is one of the most stable and admired communities in Norway. To remain that way, they are embarking on a new initiative using systems engineering to ensure sustainable growth. This is their story.

This paper provides a case history of how systems engineering is being applied to a non-traditional application domain - sustainable development - in the context of an "intelligent community" in Norway. The case is allegorical and has relevance for practitioners in city planning and manufacturing.

 

7.1.4           Coping With System Integration Challenges in Large Complex Environments

                  G. Muller, Embedded Systems Institute

 

The increasing scope of systems integration poses many challenges for the system integrators. This paper contends that in conventional projects the Systems Integration phase is systematically underestimated. During this phase all unexpected and unforeseen problems surface, where most problems are cross-organizational. When the project size increases with more suppliers, more users, more enterprise processes, and more (intelligent) functionality, then the system integration phase gets tremendously more difficult.

 

In this paper we will bring order to the integration process and discuss an approach and best practices to cope with systems integration in conventional projects. Such level of integration approach is a prerequisite to deal with all added integration complexity in systems with a scope of (intelligent) enterprises.

 

Session 7 Track 4: Perspectives on SE

 

7.4.1           Coupling Enterprise and Technology by a Compact and Specific Architecture

                  Overview

                  G. Muller, Embedded Systems Institute

 

Enterprise level projects tend to be delayed and to exceed budgets. Original expectations and targets are not met by these projects. Many solutions have been proposed to address this problem, one of them the application of Systems Engineering at large. In this paper we show how a compact Architecture Overview is a helpful instrument to keep enterprise level projects on track.

 

Practical experience shows that such an overview provides a quick insight in project progress and in potential threats. Principal customers and managers should ask the architects for this overview. Benefit for the architects of making the overview is that it helps to position their work in the enterprise context. Experience also shows that pragmatic system engineering practices, such as process orientation and project management are complementary to the proposed overview. This combination of overview and pragmatic systems engineering is very powerful.

 

One of the main issues in creating an architecture overview is the need for breadth, what needs to be included and for whom, and the balancing act of providing sufficient depth, what are crucial details that are part of this top-level description. Also the way of describing is discussed, from stakeholder needs to ambiguity and the level of formalism.

 

7.4.2           Development and Application of Abstract Relation Types for Use in Systems and

                  System-of-Systems Design and Evaluation

                  J. J. Simpson, Systems Concepts; C. H. Dagli, A. Miller, University of Missouri-Rolla

 

Abstract relation types (ART) are developed to represent, describe and establish a computational framework for a system.  An abstract relation type is closely related to and builds upon two fundamental ideas. The first idea is the binary relation and structural modeling techniques developed by John N. Warfield. The second idea is the concept of abstract data types. These two ideas are combined to create an abstract relation type that provides a structured representation and computational method for systems and system components.  The complete system description approach is based on six abstract relation types:  context, concept, functions, requirements, architecture, and test (CCFRAT). When combined with digraphs and other graphical representations of the matrix form, ART provides a powerful tool for the communication of complex system interactions to large system design teams. 

 

7.4.3                       Some Early History of Systems Engineering - 1950's in IRE Publications (Part 1):

The Problem

                  T. L. Ferris, SEEC/Univeristy of South Australia

 

This paper is part 1 of the first stage in a project investigating the early history of systems engineering. Many current texts refer to the post World War II era as the origin of systems engineering as a means to overcome the problems of systems development projects that failed to deliver satisfactory product systems according to budget and schedule. The present paper investigates primary sources from the 1950’s period to develop an understanding of the concerns present in the engineering community when systems engineering is said to have emerged in order to develop an understanding of the objectives and issues of concern addressed. The sources have been investigated from the perspective of the evidence that they provide concerning the reasons why systems engineering emerged with the characteristics that it developed.

 

7.4.4              Some Early History of Systems Engineering - 1950's in IRE Publications (Part 2):

The Solution

                  T. L. Ferris, SEEC/University of South Australia

 

This paper is the second stage in a project investigating the early history of systems engineering. Many current systems engineering texts refer to the post World War II era as the origin of systems engineering as a means to overcome the problems of systems development projects that failed to deliver satisfactory product systems according to budget and schedule. The present paper investigates primary sources from the 1950’s period to provide an understanding of the early stages of development of the systems engineering solution to the problems that had been observed and discussed in part 1 of this study. The sources have been investigated from the perspective of the evidence that they provide concerning the systems engineering solution to the problems which had been experienced and why these solutions were regarded as satisfactory.

 

Session 7 Track 5: Risk

 

7.5.1           Taking Out the Garbage: How to Get Good Risks into Your Risk Tool

                  V. Parker, Northrop Grumman Corporation

 

You have a sophisticated risk tool. You have leadership buy-in on the importance of risk management and you have formal risk management communication channels. Yet, your risk assessment discussions swirl and your list of top risks does not accurately reflect what you know to be true. Worse, the risk information is not helpful in your organization's decision-making forums. What else can you do? Consider the old saying "garbage in, garbage out." Before you dazzle them with your quantitative analysis and Monte Carlo simulations, strive for getting good content into the tool. In this white paper, you will see examples of effective risk statements and learn a proven approach for getting better risk data into your organization's decision-making activities – and put that sophisticated risk tool to good use.

 

7.5.2           Risk Analysis

                  E. D. Smith, University of Missouri – Rolla; T. Bahill, University of Arizona

 

This paper presents a risk analysis example with quantitative data for frequency of occurrence and severity of consequences. It presents an algorithm for deriving severity scores. Then it shows use of a risk management tool that is commonly used in industry. Finally it presents many other factors that affect human perception of risk. Identifying and controlling risk is a characteristic behavior of intelligent enterprises.

 

7.5.3           Cultural Models of Organizational Risk in Product Development

                  S. T. Collins, University of Connecticut

 

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.

 

Session 7 Track 5: Risk

 

7.5.4           Controlling Project Risk by Design

                  N. Malotaux, N R Malotaux – Consultancy

 

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.

 

Session 7 Track 6: SE Principles & Heuristics

 

7.6.1                       Systems are Imaginary -- Systems are Not Real:  Some Thoughts on the

                  Nature of Systems Thinking

                  J. N. Martin, The Aerospace Corporation

 

Systems are not as real as we think they are. It is indeed true that engineers design things that when placed into service are very real. But these things are merely constituents of perhaps many different systems. Which systems these engineered things belong to is really up to our imagination to make such assignments. The assignments of these things to systems is what is involved in “systems thinking.” We make assignments of things to systems before these things exist in order to examine their contribution to the system’s intended “purpose.” We can even make assignments of things to (different) systems to examine how they are currently behaving (or perhaps misbehaving). This paper will explore what it means to employ systems thinking to imagine various system structures and to examine these structures for their suitability in different situations to address perceived problems.

 

 

 

 

7.6.2           Damn the Torpedoes! Lessons from Underwater Warfare.

                  T. Fossnes, Norwegian Defence Procurement Division – Submarines

 

Torpedoes in underwater warfare have become an increasingly more sophisticated threat to the opponent over the past 150 years. Human ingenuity, creativity and advancements in technology have resulted in a very complex and intelligent system in its own right. This paper examines five cases where torpedo failures ended in more indignation for the weapon launchers rather than their targets, or caused severe consequences for the carrying platforms. The recent loss of the Russian submarine Kursk is an example of the latter, examined in case 5. Cases from the history of torpedo failures provide cautionary tales: the failures are largely attributed to inadequate systems engineering performance and badly executed enterprise performance during different stages of the systems’ life cycles. Experiences gained from these failures are applied in the torpedo industry today; intelligent enterprises have discovered that responsible systems engineering provides the key to safer product development and operations. 

 

7.6.3           Case Study in Establishing Systems Engineering Principles:

                  One Organization's Experience

                  A. L. Reutzel, Sandia National Laboratories

 

Even within a well-established systems engineering organization, formalizing the practice of systems engineering can be an arduous task. This paper describes one organization's effort to start this formalization by defining and documenting the very foundation of its practice: its systems engineering principles. Topics include the process for developing principles (augmenting organizational guidance with industry best practices), the final form of the principles (justifying terminology), and the connection to broader formalization efforts (associating the principles diagram to the systems engineering logo). The principles are divided into four categories that tie mainstream systems engineering definitions together: Stakeholder, Systems Engineer, Problem, and Solution.

 

7.6.4           Some Powerful Systems Engineering Heuristics

                  T. S. Gilb, RPL

 

The heuristics recommended for systems engineering are as follows:

1. All designs are valid if they deliver the performance within the constraints.

2. The system level architecture optimizes to assist the specialist disciplines, and yet also constrains them.

3. We don’t really know if something will work until we try it out.

4. System models cannot be relied on, and their only justification is when there is no other realistic way to economically represent the future system.

5. Systems need to be built to tolerate change and expansion beyond current stakeholder needs.

6. The number of system stakeholders is most likely always one more than you know about; and known stakeholders have at least one more requirement than you currently know about.

7. You cannot economically satisfy all critical stakeholder needs, so the job is to increase value-to-cost ratios in the long term.

8. The most critical requirements and critical designs are probably soft, not hard….and most systems engineers are not social engineers.

9. Don’t ever try to build it all at once – evolve the system based on highest value early, and aim to rapidly learn from the realities.

10. Manage the detail through focusing on the high-level measurable objectives, not through bureaucracy.

11. Contractors will deliver better value for money, if paid only for value delivered, not for work completed.

12. Risks are impossible to detail completely and correctly, but can be controlled by frequent and early numeric feedback and change – as well as creating openness for necessary change in architecture, contracts and relationships.

SESSION 8

 

Session 8 Track 1: Intelligent Enterprises

 

8.11                        Get Smart- Enabling Enterprise Systems Intelligence and Decision Making

Through Critical Parameter Management

                  C. N. Hamman, N. A. Mackertich, Raytheon Integrated Defense Systems

 

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.1.2           Human Factors Integration for MODAF: Needs and Solution Approaches

                  A. Bruseberg, Systems Engineering and Assessment Ltd.; G. Lintern, General Dynamics

 

The design of complex, large-scale, socio-technical systems such as Network-Enabled Capability (NEC) requires collaboration of diverse disciplines since it needs to embrace all areas of systems design.  One approach to dealing with such complexity is the use of Architectural Frameworks such as MODAF.  There is a concern however, as to the extent to which MODAF is able to address Human Factors Integration (HFI) issues that should be applied as an integral part of socio-technical system design.  Equally, the discipline of HFI may not sufficiently consider concerns from the Systems Engineering domain.  This paper provides an assessment of the adequacy of MODAF in addressing HFI design issues and summarizes recommendations and initial solution approaches. 

 

8.1.3           Towards an Integrated Model of Enterprise Systems

                  G. A. Kennedy, C. E. Siemieniuch, M. A. Sinclair, Loughborough University

 

An enterprise system consists of a number of components or building blocks.  It is common to use views or models of the enterprise that contain a selection of these components (dependent on the intended usage of the model).  The premise is that if these views are considered systems in their own right then the total enterprise system is actually a system-of-systems. Difficulty arises however when the boundaries between the systems overlap - it is therefore necessary to have an integrated model of the total enterprise that can cope with these overlaps and hence interactions between the systems.  Within this paper there will be two main areas of work described; firstly the development of models/tools of “soft” enterprise characteristics; and secondly how these characteristics may be included in an integrated model of an enterprise system.  Case studies of UK organizations (primarily within the defence industry) were undertaken to provide context to the results.

 

Session 8 Track 2: Commercial Applications

 

8.2.1           The  Compilation of an Integrated Qualification and Commissioning

                  Programme for    a Nuclear Power Plant

                  B. C. Brits, PBMR Ltd

 

Systems engineering principles, and more specifically qualification principles, are application dependant. In general, these principles can be easily applied in the qualification of most products in the automotive, aerospace and arms industries. When it comes to the qualification of a commercial nuclear power plant (or probably any commercial plant for that matter), however, there are numerous limiting factors that prohibit the orthodox application of these basic principles.

 

The intent of this paper is to show how the classic qualification principles can be interpreted and adapted to a specific application, provided there is a solid understanding of both the basic qualification principles, as well as the peculiarities associated with the specific product and its related industry sector. The size, cost, design complexity, maturity of technology base and the projected life cycle of the product, as well as acceptable practices within its industry sector, have a significant effect on how the basic principles can be applied. Once the application of the principles is understood, it becomes relatively easy to plan and structure a process for the compilation of an integrated qualification programme. This process is essential to ensure that all angles are covered during the qualification planning stages, and to ensure effective execution and management of the planned qualification activities.

 

8.2.2           Improvement of Software Engineering Performances:

An Experience Report at Bombardier Transportation –

Total Transit Systems Signalling Group

                  C. Y. Laporte, Ecole de Technologie Superieure

                  D. Roy, Centre de Recherche Informatique de Montreal

                  M. Doucet, Bombardier Transportation – Canada

                  M. Drolet, Bombardier Transportation – USA

 

The performance of the Bombardier TTS/Pittsburgh Signaling group has been evaluated twice: first in November 2003 and again in January 2006.  The 2003 evaluation established a baseline for the evaluation of progress made in 2006.  During those visits, the same evaluation method was used to evaluate project performance and organizational change management, i.e. the people issues.  Since 2003, there has been substantial improvement in both process maturity level and process performance.  This experience report, at Bombardier Transportation, illustrates that process performance improvements are achievable when two key factors are involved, namely: a link between business goals and process improvement activities, and a sponsor committing the right level of resources to the improvement program.  This paper explains the multi-dimensional methodology used to perform the evaluations, as well as the business goals and the quantitative performance improvements achieved since 2003.

 

8.2.3           Optimal Integration and Test Planning Applied to Lithographic Systems

R. Boumen, I. S.M. de Jong, J. M. van de Mortel-Fronckzak, J. E. Rooda

Eindhoven University of Technology

 

In the current integration and test phase of the development of a complex system, (the “right side” of the V-model) planning is becoming more and more difficult because of: 1) variability in delivery times of components, 2) failing tests and subsequent repairs, 3) resource changes and the use of component models, and 4) the growing system complexity and growing number of components and tests. Manually created integration and test plans are often not optimal regarding time-to-market. Furthermore, creating and maintaining these plans costs a lot of effort. In this paper, we introduce a method that allows to automatically create optimal integration and test plans. This method can be used by intelligent enterprises to shorten the time-to-market of a system and to reduce the effort needed to create and maintain integration and test plans. We illustrate this method with two cases studies related to the development of ASML lithographic machines (ASML 2006).

 

Session 8 Track 3: SysML

 

8.3.1           Bridging the Chasm - Tracing from Architectural Frameworks to SysML

                  M. C. Hause, F. Thom, Artisan Software Tools

 

A conspicuous disconnect exists between a MoDAF/DoDAF Architectural Model (MAF) and any subsequent Systems Engineering modeling activities. MAF permits the modeling of ‘system-of-systems’ and they both facilitate the capture of the high-level properties of a system’s interfaces. However, how is this critical information communicated to an organization contracted to develop the real system? How does an organization ensure traceability from MAF artifacts and any subsequent Systems Engineering artifacts? In addition to heavyweight and lightweight mapping, SysML offers bridges that provide traceability between artifacts in MAF and any subsequent system specification. The concepts used by the different languages are examined as well as mapping from MAF to SysML. Then this paper explores allocation and requirements traceability. Due to the inherent extensibility of a UML-based model, properties not prescribed by MAF (‘Risk’) can be added to a MAF and the two approaches to flow-down can be augmented with these domain specific properties.

 

8.3.2           A Formal Universal Systems Semantics for SysML

                  M. H. Hamilton, W. R. Hackler, Hamilton Technologies, Inc.

 

OMG SysML is a general purpose systems modeling language adopted by OMG in May, 2006.  Used for specifying, analyzing, designing, and verifying complex systems; it provides graphical representations with a semantic foundation for modeling system requirements, behavior, structure, and integration with a broad range of engineering analysis. SysML represents a subset of UML2 with extensions needed to satisfy the requirements of UML for systems engineering. The goal is to enhance systems quality, improve the ability to exchange information among tools, and help bridge the semantic gap between systems, software, and other engineering disciplines (Friedenthal et al. 2006). This paper provides an analysis of how SysML may be further enhanced by a more formal framework that uses the semantics, based on the axioms of a general systems theory, of the universal systems language, 001AXES (Hamilton April 1994).  At the same time SysML provides 001AXES with a standardized based approach for capturing this formalism.

 

001AXES has had a focus on reliable systems since its inception. Instead of object oriented and model driven systems, the designer thinks in terms of system oriented objects (SOOs) and system driven models. Much of what seems counter intuitive with traditional approaches, that tend to be software centric, becomes intuitive with this approach, which is system centric. How to minimize errors and maximize integration of systems to software, reuse, open architectures, evolvable systems, and productivity in a system's development becomes better understood; this understanding can then be used as a means to an end­­—designing and building better systems.

 

001AXES is used today to address problems considered difficult to solve with traditional approaches (Hamilton and Hackler 1991, 2003-2004); it can be used to address these problems for SysML users as well. Its preventative paradigm and how the 001AXES kernel can provide SysML with a formal foundation will be discussed.  Examples show mappings between SysML and 001AXES and how the kernel can be used to support SysML.

 

8.3.3           Enterprise Domain Modelling Process Using SysML for the Tooling Enterprise

                  at the U.S. NNSA's Pantex Plant

                  D. A. McGrath, L. M. Mayes, BWXT Pantex; R. M. Griego, Sandia National Laboratories

 

This paper describes the process and methods applied in modelling an enabling enterprise within the NNSA Pantex Plant within the U.S. Nuclear Weapons Complex.  The process used is based on the Enterprise Domain Modelling and systems analysis methods enabled by Systems Modelling Language (SysML).  SysML consists of four types of views to describe a system:  structure, requirements, parametrics, and behavior (INCOSE, 2006).  The  model illustrated behavioural viewpoints of the tooling enterprise.

 

Session 8 Track 4: Scenarios & States

 

8.4.1           Intelligent Operational Scenarios: A Strategy for Cost-Saving Scenario Selection

                  S. H. Dam, Systems and Proposal Engineering Company (SPEC)

 

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.

 

8.4.2                       Exploring Concurrent Activities: Using State Machines to Understand

                  Net-Enabled Operations

                  R. Sorensen, Vitech Corporation

                  R. Funk, M. Ball, Centre for Operational Research and Analysis

 

The Defence Research and Development Canada (DRDC) Centre for Operational Research and Analysis (CORA) is developing capability engineering analysis tools to help build and assess Net-Centric architectures.  This paper describes the research into State-Machine (SM) models to simulate job workflow that can either be done serially using the Task, Process, Exploit and Disseminate (TPED) cycle or concurrently using the Task, Post, Process, Use (TPPU) cycle.

Classical behavioural models cannot simulate TPPU beyond simple cases due to all the possible permutations in the job flow.  SM models overcome this by storing the status of activities and then use them in the next time slice as inputs to change the status through an action or an output.  The SM approach shifts the analysis orthogonal to the timeline so the interrelationships of concurrent activity can be simulated in more detailed than is feasible for classical architecture models.  Sample results and analysis tools for the current SM model are presented.

 

8.4.3           Architecture Scenario Analysis: Estimating the Credibility of the Results

                  M. Gammelgård, M. Ekstedt, P. Närman, Royal Institute of Technology / KTH

 

The Defence Research and Development Canada (DRDC) Centre for Operational Research and Analysis (CORA) is developing capability engineering analysis tools to help build and assess Net-Centric architectures.  This paper describes the research into State-Machine (SM) models to simulate job workflow that can either be done serially using the Task, Process, Exploit and Disseminate (TPED) cycle or concurrently using the Task, Post, Process, Use (TPPU) cycle.

 

Classical behavioural models cannot simulate TPPU beyond simple cases due to all the possible permutations in the job flow.  SM models overcome this by storing the status of activities and then use them in the next time slice as inputs to change the status through an action or an output.  The SM approach shifts the analysis orthogonal to the timeline so the interrelationships of concurrent activity can be simulated in more detailed than is feasible for classical architecture models.  Sample results and analysis tools for the current SM model are presented.

 

SESSION 9

 

Session 9 Track 1: Human Factors

 

9.1.1           Human Functional Analysis of Lean Staffing: Extensions to the Department of

                  Defense Architecture Framework (DoDAF)

                  G. Lintern, General Dynamics; A. Bruseberg, Systems Engineering & Assessment Ltd.

 

We address the problem of lean staffing with a review of the Department of Defense Architecture Framework and conclude that the human system aspects of the relevant Organizational and Systems Views need to be informed by special analytic methods from Cognitive Systems Engineering. We describe a systematic framework for Human Views in a companion paper. In this paper, we illustrate how selected knowledge acquisition methods of cognitive engineering can be used to generate supplemental information for the Human Views needed to resolve the issue of lean staffing.

 

9.1.2           Better use of Design Descriptions to Embrace Complexity and Creativity in

                        Systems Engineering.

                  G. Strengers, Tenix Defence Pty Ltd

 

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.

 

9.1.3           System Resilience: Capabilities, Culture and Infrastructure

                  S. Jackson, University of Southern California

 

System resilience is the ability of organizational, hardware and software systems to mitigate the severity and likelihood of failures or losses, to adapt to changing conditions, and to respond appropriately after the fact.  Challenger, Columbia, Chernobyl and Bhopal are examples of such failures. System resilience goes beyond traditional disciplines, such as reliability and system safety to achieve its goal. System resilience employs systems engineering principles at product and infrastructure levels. The infrastructure system includes such nodes as the developer, the customer, the user, the maintainer, and the operator. System resilience requires that systems engineering principles be practiced across organizational boundaries and to a greater level of detail than is common in today’s world. System resilience depends on developing beneficial paradigms within all nodes of the infrastructure. Finally, system resilience requires that all nodes of the infrastructure system have a set of capabilities that are directly derivable from root causes of catastrophes. The combination of capabilities, culture and infrastructure forms the basic framework of system resilience.

 

A key aspect of catastrophes is emergence, that is, the negative interaction among two or more elements of the system, who, when acting alone perform benignly. Prediction of emergence and design against emergence is a major challenge of resilience.

 

Adaptability is the characteristic of a system that allows it to survive a catastrophe. Although rules for the creation of adaptability in human-intensive systems have been formulated, similar rules for hardware and software systems are in their infancy.

 

Session 9 Track 2: Notable Approaches

 

9.2.1           Optimized Airport Security Infrastructure System (OASIS)

                  J. M. Gonzalez, S. L. Harris, E. R. Castaneda, J. Kim, George Mason University

 

It has been suggested that the current security measures being implemented in airports around the country produce “soft targets” in the form of lengthy queues.  These soft targets heighten the risk of a terrorist attack within airport premises that could potentially have the same impact as destroying a commercial flight. Using Washington Dulles International Airport as a case study, this study examines the security measures being implemented in the airport and designs a methodology that will result in optimal allocation and usage of security resources.  Two alternatives are designed that make use of layered, defense-in-depth security measures that aim to deter terrorist attacks by using the concept of unpredictability.  Models of these alternatives are built and the best alternative is selected by analyzing simulation outputs and evaluating them based on a value function.  At the end of the study, an Optimized Airport Security Infrastructure System (OASIS) that will provide a more efficient and reliable method for screening passengers and their luggage is proposed.

 

9.2.2           Object-Oriented Systems Engineering Method (OOSEM) Applied to Joint Force

                  Projection (JFP), a Lockheed Martin Integrating Concept (LMIC)

                  L. Izumi, S. Friedenthal, A. Meilich, Lockheed Martin Corporation

 

A Lockheed Martin Team is developing an enterprise architecture to specify a Joint Mission Capability Package for Next Generation Long Range Strike (NGLRS) in support of Major Combat Operations.  The modeling approach leverages the Object-Oriented Systems Engineering Method (OOSEM) and the newly adopted Object Management Group Systems Modeling Language (OMG SysML™) using the I-Logix Rhapsody modeling tool. The preliminary modeling effort resulted in a model of the enterprise architecture and an executable architecture to support behavior analysis and simulation. The analysis and simulation are intended to allow JFP to validate customer and mission requirements and develop and demonstrate System of Systems (SoS) architecture solutions.  A brief overview of SysML is included in the paper; however, those who are not familiar with SysML will benefit from a review of the OMG’s SysML Tutorial [3].

 

9.2.3           Standardized Process as a Tool for Higher Level Systems Thinking

                  C. M. Lamb, D. H. Rhodes, Massachusetts Institute of Technology

 

Standardized processes are being used to address three issues in engineering today: increasing system complexity; shifting demographics; and longer development cycles that result in a dearth of experiential learning for young engineers.  There is obvious value in having engineers who can see the big picture and effectively broker design tradeoffs: engineers capable of systems thinking.  However, what is the impact of standardized processes on the ability of teams of engineers to make these critical tradeoffs?  This paper lays the groundwork for research investigating ways in which standardized process usage facilitates or hinders systems thinking within engineering teams—termed collaborative systems thinking.

 

Session 9 Track 3: SysML

 

9.3.1           Teaching SysML Through a Process Led Approach for Systems Engineering:

                        Lessons for the SysML Standard

                  D. J. Battersby, BAE Systems, SEIC

 

The systems modelling language, SysML, supports the growing demand for model based systems engineering. This paper describes the design of undergraduate teaching material for SysML based upon an approach which maps the language to systems engineering needs. These needs are high level requirements for a systems engineering language, which are based upon elements of systems engineering lifecycle process standards. This approach is designed to show the capabilities of SysML and UML against the backdrop of a set of simple and logical activities which the students could identify in the context of their studies and industrial experience.

 

The course material was successful in introducing the students to visual modelling through an initial analysis of UML for systems engineering, followed by the introduction of SysML where this adds value to the UML 2 standard. Lecture material and a practical session were used to emphasise this focus on systems problems, including hardware and human aspects. As these issues were addressed the information presented was assessed against the needs identified in order to show the value of SysML to the students.

 

The comparison of the standard with the needs identified resulted in a compliance table that explored how well SysML supports systems engineering; this identifies a number of potential weaknesses of the language which can be seen as opportunities for the next iteration of the standard. The key difficulty identified when trying to apply the SysML standard was the lack of a methodology for the application of the language. This methodology would allow the use of SysML by engineers without previous experience of UML though providing a framework for use and education.

 

9.3.2           Simulation-Based Design Using SysML - Part 1: A Parametrics Primer

                  R. S. Peak, M. W. Wilson, M. Bajaj, I. Kim, Georgia Tech

                  R. Burkhart, Deere & Company; S. Friedenthal, Lockheed Martin Corporation

 

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

                  R. S. Peak, M. W. Wilson, M. Bajaj, I. Kim, Georgia Tech

                  R. Burkhart, Deere & Company; S. Friedenthal, Lockheed Martin Corporation

                 

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.

 

Session 9 Track 4: COSYSMO & Changeability

 

9.4.1           Lessons Learned From Industrial Validation of COSYSMO

                  R. Valerdi, Massachusetts Institute of Technology; J. E. Rieff, Raytheon Corporation

                  G. J. Roedler, Lockheed Martin Corporation; M. J. Wheaton, The Aerospace Corporation

                  G. Wang, BAE Systems

 

The development of COSYSMO has been an ongoing collaboration between industry, government, and academia since 2001.  INCOSE provided expertise as well as a forum for collaboration between stakeholders that led to the eventual development of the model.  In 2004, we provided eleven lessons learned from experiences collecting systems engineering data from six companies in collaboration with the INCOSE Measurement Working Group and the Practical Software and Systems Measurement (PSM).  These lessons were focused on the development of COSYSMO that was motivated by a similar model from the software domain, COCOMO II, but was a first of its kind for systems engineering.  Now that the development phase of the model is completed we take a retrospective view of lessons learned during the ongoing validation phase of the model and present new lessons learned that should help cost model developers, academic researchers, and practitioners develop and validate similar approaches.  These lessons include the need for more specific counting rules, an approach to account for reuse in systems engineering, and strategies for model adoption in organizations.

 

9.4.2           Incorporating Security and Survivability into the System of Systems Architecting

                  A. Singh, C. H. Dagli, University of Missouri-Rolla

 

System of systems (SoS) security and survivability issues have found prominence in the wake of increased importance of such large scale interconnected systems. The threats and risks associated with SoS architectures present unique challenges to system architects. SoS security and survivability practices are needed to ensure the performance and survival of the system under an intrusion. Current security engineering activities are performed independent of the system architecting process, leading to ad hoc solutions and after-the-fact reactions to vulnerabilities as discussed in (Evans et al. 2005). Literature on security and survivability oriented system architecting activities is far and few in between. This paper studies the major classes of threats and risks associated with SoS and the response to such vulnerabilities.  Existing works were researched to outline the key characteristics of an effective security and survivability process that can be integrated with systems engineering activities. Overviews of three survivability architectures are provided on the basis of the identified criteria. Comments on the currently available solutions and future areas of emphasis are presented.

 

9.4.3           Defining Changeability: Reconciling Flexibility, Adaptability, Scalability, and

                  Robustness for Maintaining System Lifecycle Value

                  A. M. Ross, D. H. Rhodes, D. E. Hastings, Massachusetts Institute of Technology

 

Designing and maintaining systems in a dynamic contemporary environment requires a rethinking of how systems provide value to stakeholders over time. Classically, two different approaches to promoting value sustainment may include developing either alterable or robust systems. The first accomplishes value delivery through altering the system to meet new needs, while the second accomplishes value delivery through maintaining a system to meet needs in spite of changes. The definitions of flexibility, adaptability, scalability, and robustness are shown to be different parts of the core concept of “changeability,” which can be described by three aspects: change agents, change effects, and change mechanisms. Cast in terms of system parameter changes, flexibility and adaptability are shown to relate to the origin of the change agent (external or internal to a system boundary respectively). Scalability and robustness, along with the additional property of modifiability, are shown to relate to change effects. The extent of changeability is determined by the number of possible change mechanisms available to the system as accepted by decision makers. Creating changeable systems, which can incorporate both classical notions of alterability and robustness, empowers systems to maintain value delivery over their lifecycle, in spite of changes in their contexts, thereby achieving value robustness to stakeholders over time.

SESSION 10

 

Session 10 Track 1: Intelligent Enterprises

 

10.1.1          Capability Engineering:  Learning from Practice

                  W. Robbins, C. Lalancette, M. Lizotte, C. Necaille, J. Pagotto, B. Waruszynski,

                  Defence R&D Canada

 

For over four years, Defence R&D Canada has been investigating Capability Engineering, which aims at supporting the Capability-Based Planning (CBP) decision-making process, under the Collaborative Capability Definition Engineering and Management Technology Demonstration (CapDEM TD) project.  Based on the systems engineering paradigm, the approach is articulated around three axes:  People, Process and Materiel.  This paper presents the results of an experimental evaluation conducted to assess the CapDEM approach to Capability Engineering.  The focus is on the lessons learned from Exercise Beta, the second of three validation exercises which are part of an evaluation strategy attempting to evolve capability engineering from theory into practice.

 

10.1.2          Simple Yet Profound Enterprise Impact

                  H. Mooz, K. Forsberg The Center for Systems Management

 

We of The Center for Systems Management are continuously frustrated to find that many enterprises and organizations view process and process improvement as something that must be done to compete (SEI CMMI Level Three, ISO 9000, etc.) rather than as cost efficient best practices that produce substantial return on investment. In fact, some venture capitalists have stated to us “we want no process as it will inhibit our creativity.” Other enterprises state that they want to take it slow and easy with process adoption lest they bog down in the minutia of implementation.

Unfortunately, these misperceptions are usually rooted in prior experiences where process improvement consisted of lengthy documentation and verbiage that ended up collecting dust on the bookshelf rather than being faithfully practiced by the enterprises’ staff to produce exemplary and consistent results.

 

Some of the most beneficial processes are extremely simple to implement yet they can produce high value results to the quality and safety of the activity. This paper explores a few of a family of Simple Yet Profound Management Techniques that if faithfully implemented will improve an enterprises performance and return on investment. The ultimate goal would be to have these processes instilled in a systemic enterprise culture.  

 

10.1.3          Evaluating Product Development Task Interactions Using Network Analysis

                  S. T. Collins, University of Connecticut;

                  A. A. Yassine, University of Illinois at Urbana-Champaign

 

This paper proposes the integration of two useful systems engineering analysis tools, the Design Structure Matrix (DSM) and Network Analysis (NA) to study task interactions in a Product Development Process (PDP) using a small engineering company as a case study.  The DSM is a matrix-based systems engineering tool that enables streamlining of the PDP through task sequencing and simulation of project execution. NA techniques such as key players, centrality, influence, and brokerage provide methods to identify critical product development tasks and interactions to focus PDP improvement.  Collecting interactions between product development tasks in matrix form provides opportunities to use DSM and NA techniques to identify highly central tasks and identify patterns of cross-coupling between tasks and the groups performing those tasks.  One benefit is the ability to describe feedback characteristics of critical PDP tasks.  This is valuable when evaluating the impact of omitting, combining, or re-sequencing task execution based on program-specific constraints. 

 

10.1.4                   Systems Engineering for the Intelligent Enterprise – More Important Than You May Think

                  R. Kaffenberger, Ferchau Engineering GmbH

 

The emergence of the intelligent enterprise is very important for all of us, because the classical enterprises that govern the way of our lives are not able to cope with the pace of change we experience. For many systems engineers like me the term “Intelligent Enterprise” is not part of the daily work. Nor do we have a clear idea why Systems Engineering would be the key enabler for the formation and survival of the intelligent enterprise. I will give a short characterization of the intelligent enterprise and the kind of systems engineering required to establish and maintain it.

 

This is my interpretation in classical system engineering terms of some of the information collected in the “knowledge claims” compiled by the INCOSE Intelligent Enterprise Working Group (IEWG 06).

SESSION 11

 

Session 11 Track 1: Intelligent Enterprises

 

11.1.1          An Approach to a Network Centric Product Development System

                  R. Abbott, A. Miller, C. H. Dagli, University of Missouri-Rolla

 

Current product development architectures range from vertically stove-piped organizational structure to dispersed organizational entities working in a collaborative manner.  Various product development methodologies have been developed to speed the communication between product team members including co-location of the development team, email, scheduled telecom and video-com meetings, Internet Web casting to keep all team members in contact with one another.  No company has implemented a network centric product development system that links all users in the product development process together in a single system where real time communication or shared databases are used or exist.  This would require a company to change it business model as a network centric product development system requires closer cooperation between and within itself, subcontractors and suppliers.  As an example, both Wal-Mart and Deutsche Morgan Grenfell have incorporated network centric systems into their business model with great success.  Can the product development process be used on a network centric system?  A Network Centric Product Development System requires a system configured and optimized to speed team communication and share product databases regardless of team member location or organizational affiliation.

 

11.1.2          Systematic Enterprise Definition

                  J. O. Grady, JOG System Engineering, Inc.

 

One prerequisite to enterprise improvement is management awareness of the enterprise current process, organization, and the relationship between these entities. That is, the enterprise must define itself as a system capable of satisfying a pre-defined enterprise functionality using a particular organizational entity structure derived from that needed functionality. If this sounds familiar, it should because it is precisely the way system engineers have defined product systems for many years applying traditional structured analysis. The same methods used to define large product systems can be employed to define enterprises and their programs which are, after all, process systems. This paper describes how this process can be employed to re-engineer an enterprise that has been found to be inefficient. It is not suggested as a way to originally engineer an enterprise, though it will work in that context, because enterprises are commonly formed by entrepreneurs who seldom have a lot of interest in organized ways of thinking. Over time, however, an initial success will often expose a need for better discipline and efficiency.

 

11.1.3          Tour d horizon in Requirements Engineering - Areas Left for Exploration

                  M. F. Kossmann, C. Ingamells, Airbus; M. Odeh, A. Gillies, University of the West of England

 

The present paper aims to give an overview of the state-of-the-art in Requirements Engineering (RE) based on a wide collection of publications from recent years, and focuses specifically on some advanced areas that need to be further explored in the future. Those areas addressed here are the use of ontologies and UML in RE, the coverage of non-functional requirements, interfaces to other engineering disciplines and other functions, as well as RE in the context of corporate wide improvement initiatives such as CMMI and Lean Enterprise Value.

 

KEY RESERVES

 

KR 01         A Conceptual Glossary for Systems Engineering: Define the Concept, Don't Quibble about the Terms

                  T. S. Gilb, RPL

 

We seem to spend a lot of our time defining terms, arguing over terms, standardizing terms, and misunderstanding terms. In connection with my development of a planning language, and its basic textbook I had to make a decision regarding my glossary. One of the formal design requirements I had set for myself was that the planning language, and its textbooks were easy to translate into other international languages. It was primarily in order to satisfy that requirement that I came up with the concept of a concept-centered glossary, rather than the conventional term-focused glossary (like a conventional dictionary).

                 

The basic idea is that we focus on defining a concept, no matter how many synonyms it might have, or how many different opinions there are about what the concept should be called.

 

KR 02          Creative Product Development

                  M. J. Dick, Northrop Grumman Corporation, Integrated Systems Sector

 

Enterprises can establish a culture for engineering creativity by encouraging engineers to  practice proven conceptualisation techniques that lead to better designed systems.  This paper presents several easily-performed creativity techniques that work within the context of engineering. 

 

KR 03          Cultural Differences - and how they affect Systems Engineering.

                   A. Pandikow, Syntell Group; R. Larsson, L. Ruhe, Saab Services USA LLC;

                   E. Herzog, Saab Aerosystems AB

 

Systems Engineering often deals with complex systems being developed and / or supported by multi-national teams of engineers with different cultural backgrounds. In such environments, cultural differences among the involved individuals often lead to misinterpretations and misunderstanding, leading to suboptimal solutions or even errors in design and failures in systems. In this paper we intend to draw the attention of systems engineers to the area of anthropology, where the analysis of cultural differences delivers a number of interesting insights that may be of great use for improving communication among systems engineers. We provide indices for measuring cultural differences as well as recommendations how cultural analysis can be integrated in the Systems Engineering process.

 

KR 04         Effective Industrial Modeling for High-Tech Systems: The Example of Happy Flow

                  G. Muller, Embedded Systems Institute; J.M.J. Beckers, Océ Technologies BV

                  W.P.M.H. Heemels, B.H.M. Bukkems, Technische Universiteit Eindhoven

 

In the design of high-tech systems like copiers, wafer steppers and televisions, modeling plays an important role. However, not all developed models are industrially successful. It would be very beneficial if guidelines were available on how to create industrially effective models that support the system architects and speed up the multi-disciplinary design of high-tech machines. In this paper, we describe a very successful industrial model in the context of the design of copiers. The model is developed for the design of the paper transport system (the mechanical layout of the paper track, the schedule of print jobs, sensors, actuators, etc.) in a multi-functional office copier. As most other activities in the printer are synchronized to the paper transport system, this design issue is at the heart of the overall design and has a major influence on the total functioning of the machine. The so-called Happy Flow model is based on kinematic modeling and its generic elements are not restricted to copiers only. Its main ideas are applicable to a much wider range of mechatronic products. It is important to learn from such instances of successful industrial models. The aim of this paper is to identify the success factors of this particular model, which forms a first step towards a more systematic method on how to construct industrial effective models.

 

KR 05         Everything Always Works the Way It's Supposed to Right? The Importance of

                        Tool Integration and Customization in Today's Development Programs

                  J. L. Colwell, The Boeing Company; C. H. Dagli, University of Missouri - Rolla

 

In theory, the relationships between customer needs and requirements, design artifacts, and what is actually built are straight forward. In practice, it is not always as simple as one would think. Tools used to develop today’s Architecture’s cover a broad landscape that is complicated by a multitude of tools for requirements management, analysis and design, and development environments.  Further complicating the issue can be customer mandates for usage of specific tools, toolsets, or Integrated Development Environments (IDE’s).  This paper describes how the overall requirements hierarchy and the traceability to design artifacts were established and implemented for a medium sized program.  The integration of the requirements management tool, DOORS, with IBM’s Rational Software Architect (RSA) using a third party tool, DOORKeeper, will be described.  Finally, the development of customized tools for the standardization and automation of requirements and design metrics gathering will be described.

 

     

 KR 06         The Evolving Joint Perspective and Meta-systems Theory: A Case Study Based

                        on the Joint Vision Document Moving from a Systems View to a Meta-Systems

                  View of the Evolving Joint Perspective

                  K. D. Palmer, SEEC Student

 

The Evolving Joint Perspective document which was the precursor to the current Capstone Concept for Joint  Operations was analyzed in relation to Meta-systems Theory in this case study which was done in the 2004 timeframe. The basic thrust of the new document is the same as the original document so this analysis is considered to still be relevant. Meta-systems theory is proposed as a basis for Joint Forces organization. Currently the theory that is the basis of both documents is Complex Adaptive Systems Theory. The emphasis here is on the dual of that which would be Complex Adaptive Meta-systems Theory. Both Systems and Meta-systems Theories are said to be needed to have a complete theory for Joint Operations of Joint Forces.

 

KR 07         Expanding Functional Analysis to Develop Requirements for the Design

                       of the Human-Computer Interface

      B. P. McKenna, J. Gualtieri, ManTech - Cognitive Systems Engineering Center

      W. C. Elm, Resilient Cognitive Solutions

 

The purpose of this paper is to provide a framework for extending the functional analysis of a system to the human decision-making agents in order to improve overall system effectiveness. The subsystems needed to accomplish the goals of the system can often be found through a functional analysis. However, the different subsystems need to be completely integrated in order for the system to be effective. This integration is often problematic within the Human-Computer Interface (HCI), where the operator is reliant on the information provided in order to have an understanding of what is occurring within the work domain. As a functional analysis helps to define the goals to be accomplished and the subsystems that accomplish them, it follows that expanding the depth of the functional analysis will help integrate the human operator and technology through the HCI to make a more effective Joint Cognitive System (JCS). The functional analysis leads to the creation of more insightful design requirements for the HCI that directly link the work that the user must accomplish and the information needed to complete this work – making it truly user-centered design. An example of how the functional analysis can be applied to a system is provided, comparing an HCI developed with typical design requirements to an HCI developed from an expanded functional analysis.

 

KR 08         From Research to Reality: Making COSYSMO a Trusted Estimation

                        Tool in Your Organization

                  R. Valerdi, Massachusetts Institute of Technology; C. Miller, SSCI

 

As the COSYSMO model transitions from the development phase into the adoption phase, industry stakeholders are beginning to embrace the model and integrate it into their existing measurement processes.  To date, much of the guidance provided by the COSYSMO development team has been focused on the usage of the model.  In the adoption phase, users need guidance on how to adopt the model as they work to convince management to invest resources in competition with other process improvement initiatives.

This paper outlines a process which provides guidance on the piloting and institutionalization of COSYSMO designed to help scope the effort needed for successful adoption and implementation.  The process has been developed as a result of interactions with over a dozen organizations that have participated in the industry calibration of the model and have begun to integrate the model into their internal processes.  The knowledge obtained from working with these organizations is reflected in this process.

 

KR 09         Modeling Emergent Behavior for Systems-of-Systems

                  J. C. Hsu, M. Butterfield, The Boeing Company

 

Emergent behaviors exist in biological systems, physical systems and human performance.  Little is currently known about constructing an interoperable network of systems and the incorporation of known emergent behaviors.  Definitions of emergence are introduced.  The four principles of emergence are outlined and discussed.  Conceptual agent-based modeling is discussed to illustrate possible modeling approaches for identifying and assessing emergent behaviors according to the emergent principles.  The agent-based simulation will be the inputs to system-of-systems (SoS) architectural models.  Neural network artificial intelligence may be needed to assist our understanding of the emergent behaviors during operations of SoS and the associated system architecture model development.  It is recommended that the integration of agent-based simulation and neural network methods with SysML be considered.

 

KR 10         Requirement Relationships: A Theory, Some Principles, and a Practical Approach

                  T. S. Gilb, RPL

 

This paper will argue that the ‘conventional ideas’ [NASA 97, INCOSE01, Raytheon06] of how requirements relate to other entities is unnecessarily weak in relation to the complex demands placed on a systems engineering task. We will argue that it would improve systems engineering requirements practice if we were to invest substantially more in effort to determine, and to specify, at least a dozen or two useful relationships for each requirement. We will argue that the nature or variety of these relationships should but relatively unlimited (by a standard or tool), and should be whatever is useful to the engineering work. In addition, we need to keep the requirement relationship specifications, together with the core requirement itself, in a reusable requirement ‘object’ (a mini database about each discrete requirement, which is tool independent). Systematic rules and conventions, like those illustrated, will enable more-automated use (analysis, presentation, consistency checking, reuse) of requirements, even with simple text string searching.

 

KR 11         Using a Boundary Object Framework to Analyze Interorganizational Collaboration

A.     Fong, J. Srinivasan, R. Valerdi,  Massachusetts Institute of Technology

 

The U.S. military is facing a plethora of challenges as a result of tightening procurement budgets and the need to acquire new capabilities to operate in modern war environments.  This requires integrating legacy systems with developing technologies in what is loosely defined to be a System of Systems.  Most Systems of Systems require some integrator to manage and operate the system interfaces.  In addition to technical integration challenges, these system integrators have the difficult undertaking of integrating various organizations.  The boundary object framework proposed by this paper provides a tool for systems integrators working in System of Systems or any type of complex system to identify and categorize communication, coordination, and collaboration interfaces and address possible failures.