Name(s):

Employer:

Title

Abstract

Name(s):

James Long

Employer:

Vitech Corporation

Title

Model-Based Systems Engineering: A Primer on What, Why, and How

Abstract

This basic tutorial identifies the elements and benefits of a complete model-based system engineering process, and demonstrates its value for project success and tailorability using vignettes from a sample application.

Name(s):

Neil Harrison

Cecilia Haskins

Employer:

Avaya, Denver, CO, USA

TSS, Bergen, Norway

Title

Introduction to Patterns Through Writing Systems Engineering Patterns

Abstract

This course addresses the subject of writing patterns to communicate the practices of Systems Engineering. The need for this tutorial was suggested from audience reaction to the Haskins paper presentation at the INCOSE symposium in DC. This introductory pattern writing course covers a brief history of the patterns movement, a survey of the variety of pattern forms, and an exercise in which the participants actually write a pattern and conduct an actual workshop of their pattern.

Anyone interested in writing patterns or better understanding patterns will want to attend.

Name(s):

Gerrit Muller

Employer:

Embedded Systems Institute

Title

Software as Integrating Technology in Complex Systems

Abstract

This tutorial is based on the module “Role of Software” of the SARCH course that has been given 24 times to a wide variety of commercial participants: Philips (MRI scanners, X-ray equipment, consumer electronics, semiconductors, lighting), Océ (printers), ASML (wafersteppers), Siemens (car navigation), FEI (electron microscopes), Assembleon (placing machines), and Bosch (security systems, cameras, conferencing systems).

The system architect plays an important role in the creation of today’s complex systems. In most companies a severe gap exists between conventional engineering disciplines and software engineering. This gap is partially caused by the education in software engineering and the lack of education in systems engineering, where system includes software. If systems engineering education is available it is often based on conventional engineering programs. The gap observed in industrial practice exists also in the education!

Name(s):

Tom Gilb

Employer:

Result Planning Limited

Title

Advanced Requirement Engineering Specification:
for control of multiple critical performance, quality and resource attributes.

Abstract

Requirement(s) Engineering is arguably the most critical single discipline in systems engineering. Bad requirements are cited as a main cause of large systems engineering project failures (P Morris, ‘The Management of Projects’, Telford, London 1994). I would argue that the theory and teaching of requirements today is in bad shape. There are several signs of this. Most so-called requirements are actually ‘design’ for unstated requirements! Most requirements are a nice sounding set of words with no testable or quantified structure and very little information about the requirements and its relation to all other requirements, designs, and plans.

This tutorial will open up a radically new approach to requirements that will rectify many of these problems. It is based on the ideas in ‘Planguage’ a specifically invented and evolved language for requirements specification. Fundamentals are reexamined (what is a function requirement?). All qualitative requirements are quantified richly. Ten to 30 parameters are used to describe a single reusable requirement fully and appropriately for its task. Requirements are related directly and individually to stakeholders. Requirements are looked at in the wider systems engineering context of design, testing, project management, and engineering-work quality-control.

Name(s):

Dr. Tyson R. Browning

Employer:

M.J. Neeley School of Business, Texas Christian University

Title

Architecting and Engineering Systems, Processes, and Organizations Using the Design Structure Matrix (DSM)

Abstract

Products, processes, and organizations are complex systems.

They are challenging to plan and manage.  Fortunately, an advantageous method is coming into mainstream practice for representing and analyzing complex system architectures.  This method, the design structure matrix

(DSM), is helping practitioners plan and manage product architectures, organizational structures, and process flows.

        Akin to a traditional N2 diagram and the System2 matrix (SV-3) in the DoD Architecture Framework, the DSM is a square matrix that documents dependencies between system components.  These components can be product parts, teams, processes, activities, or other things.  By doing some simple analysis, one can prescribe a modular system architecture or organization structure.  Adding a time-basis enables one to prescribe a faster, lower-risk process.  Because the DSM highlights process feedbacks, it helps identify iteration and rework loops-key drivers of cost and schedule risk.  The DSM can also show how delays in external inputs, such as requirements and equipment, trace directly to increased cost, schedule, and risk.

        The DSM is concise and visually appealing and is in use in a number of industries, companies, and agencies.  (It is also known as the dependency structure matrix and the dependency source matrix.)  People

have found the tool extremely useful for fostering architectural and organizational innovation, and for enabling the situation awareness and empowerment of people executing complex processes.

        This tutorial introduces the DSM and four distinctive applications useful to product developers, project planners, project managers, systems engineers, and organizational designers.  Real-life examples will be presented.  Participants will come away with a clear understanding of why dependencies and interfaces are important and how to manage them.  Participants will leave with a course notebook of descriptive materials and access to free tools that can be applied immediately to projects.

Name(s):

Mark A. Powell

Employer:

Attwater Consulting

Academic Affiliation: Stevens Institute of Technology

Title

Dealing with Uncertainty in Systems Engineering

Abstract

Systems Engineering is a discipline that is always practiced in an environment of uncertainty. Systems Engineers make important decisions with uncertainty in every aspect of the Project Lifecycle, often simultaneous and sequentially. Classical statistical methods as traditionally taught to address this problem are rarely practical for the Systems Engineer. However, recent advances in Statistical Decision Theory combined with applications of Markov Chain Monte Carlo methods have finally made the application of probability and statistics practical for the Systems Engineer in all aspects, throughout the entire project life cycle. This tutorial addresses these state of the art techniques, and provides attendees with both the methods and examples of real world SE problems solved with these new methods.

You will learn

● how to apply probability and statistics in actual practice throughout the project lifecycle

● conditional probability analysis

● Markov Chain Monte Carlo (MCMC) techniques

● how to provide good support for decisions with unknown decision maker risk aversion

You will take home a CD-ROM Disc with

● a probability and statistics programming language suitable for decision analysis and MCMC methods

● example software programs using conditional probability analysis and MCMC techniques

● the example exercises presented in the tutorial of actual SE decision making

● extensive references

(Attendees will be strongly encouraged to bring a laptop computer (Windows compatible with a CD-ROM drive) to perform the computational tutorial exercises in parallel with the lecture, but a laptop is not required.)

Name(s):

Mr. James E. Long

Dr. Steven Dam

Employer:

Vitech Corporation

Systems and Proposal Engineering Company (SPEC)

Title

Developing Executable Architectures for Systems of Systems (SoS) using DoDAF

Abstract

This full-day tutorial introduces the DoD Architecture Framework (DoDAF), giving a history and overview of the DoDAF for those not familiar with this framework. The DoDAF Architecture Framework specifies a set of “standard” views capturing various system perspectives. This tutorial presents some of the more unusual concepts and philosophy. As with nearly all frameworks, the outline and contents are defined, but the methodology and support aids are left to the developmental organization’s discretion. Many organizations implement processes that develop and manage the various DoDAF artifacts as independent deliverables, which are often inconsistent. Removing these inconsistencies occupies much of the time and resources available at every developmental stage. Failing to recognize inconsistencies leads to actual developmental, integration, and operational problems along with expensive retrofit efforts. This tutorial identifies these potential problems and applies lessons learned from years of system engineering and architecture development to reduce programmatic risk.

This tutorial presents a system engineering approach to architecture development that leads to an executable architecture that can be verified through modeling and simulation. This approach includes the necessary techniques, processes and tools needed to develop the architecture in a complete defensible manner. Selection criteria for techniques and tools are also provided. As an example, the tutorial uses a proven systems engineering process in concert with a comprehensive systems engineering tool that significantly reduces inefficiencies, establishes a stronger base for decision making, and allows management to mitigate strategic and developmental risks more successfully. Methods to implement the architecture at the enterprise level are also discussed. Throughout the tutorial the presenters focus on better ways to communicate the results to the variety of personnel who will form the target audience for the architecture.

Name(s):

Abraham Meilich, Ph.D., C.C.P. (lead contact); Sanford Friedenthal; Howard Lykins

Employer:

Lockheed Martin Corporation

Title

Object Oriented Systems Engineering Methodology (OOSEM)

Abstract

This tutorial will introduce an Object Oriented Systems Engineering Method (OOSEM), which integrates a top down systems approach with object oriented concepts and modeling techniques. . Based upon the widely known Unified Modeling Language (UML) and its soon to be adopted standardized extension for Systems Engineering (i.e., SysML), this method brings object oriented modeling to the systems engineering community, and adapts it for modeling systems-level requirements and design. OOSEM brings to the Systems Engineering a technique for leveraging some of the advantages of OO to help architect more flexible, extensible, and upgradeable systems with new evolving technology. Another major goal of OOSEM is ease of integration with object-oriented methods for software engineering and integrates with hardware engineering and other disciplines. Models developed by this method simultaneously serve the needs of systems engineers and facilitate the systems-to-software and hardware transition. OOSEM can thus serve as the systems engineering front end of an integrated method for systems, software and hardware development.

The System Engineering community has typically used top down structured analysis techniques to capture and analyze the system to be developed. Software analysis techniques in the past have also taken advantage of a structured approach, but over the last several years they have evolved to an object oriented approach for analysis and design. Systems and software engineers struggle to communicate with these different techniques. The OOSEM approach integrates a top down systems approach with OO concepts and UML/SysML to help bridge this gap.

This tutorial will introduce the student to the OOSEM method, which has evolved from a combination of research and early application to projects. This work was initially presented in various INCOSE papers. (Lykins, Friedenthal, Meilich 2000, Meilich and Rickels 1999, Steiner, Friendenthal, Oesterheld 2001). The tutorial will describe how the system level activities are performed and artifacts are developed using UML/SysML. Important concepts and issues will be illustrated by simple examples presented by the instructors and by interactive discussion. The tutorial will conclude with a discussion of future efforts in this area.

Topics covered include:

An overview of systems engineering and the context for OOSEM

An overview of UML, SysML, and modeling concepts and their relevance to OOSEM

An in-depth overview of OOSEM activities and work products

An overview of tool support requirements and approach.

Future work

Name(s):

Art Felix

Employer:

U. S. Navy

Title

Standard Approach to Trade Studies for Program/Project Managers and Systems Engineers - What Program/Project Managers should demand and expect from a Systems Engineer’s Trade Study

Abstract

The model for the trade study process described in this tutorial is based on the ‘Standard Approach to Trade Studies’. The process modeled herein describes the steps for performing and documenting a trade study (trade-off study), developing products for the Decision-Making Authority (DMA), and guidelines in tailoring the study to meet the needs of the program. This trade study process model is a series of steps used to transform subjective data to more quantitative information for the DMA in the decision-making process. Particular attention is given to support the Program/Project manager with information in support of decisions made resulting from this trade study process with an emphasis on resurrecting and updating a trade study at a later date. Each step in this process model is designed to alleviate problems identified in past trade study models. This process model presents a framework and structure centered on the familiar summary matrix to help document the thinking process in more quantitative decision-making terms. Within this process model, standard terms and definitions are used, roles and responsibilities of the participants and decision-makers are documented, and a suggested flow is illustrated. This trade study process meets Level 3 ‘Decision Analysis and Resolution’ requirements of the Capability Maturity Model Integration (CMMI Ò ).

Name(s):

Harry Lewis

Employer:

SONEX Enterprises Inc

Title

Continuous Early Validation (CEaVa) Tutorial

Abstract

Many complex technological based systems are being produced that are not used or useful on delivery, because the wrong problem was solved. This is common due to changes in the operational environment. There has been literature that discusses the need to get stakeholders involved earlier in the development process to correct this problem; however, no one has developed a detailed framework that accomplishes this intent. This research developed a method involving a four-step sequence that validates the system early to ensure that the right problem is being solved. The method is called Continuous Early Validation (CEaVa). It is a method that increases the likelihood of producing the correct system in the end. The method develops visibility of potential disconnects among stakeholders' needs, original written requirements, organizational policy, and derived requirements. The CEaVa method will validate the external and internal consistency of the problem statement. Additionally, CEaVa provides a process to facilitate consensus resolving the potential disconnects with decision analytical reasoning for trade-off analysis of the system engineering aspects of the development.

The CEaVa method was developed by Dr. Bob Larsen (LTC US Army), under the direction/guidance of Dr. Dennis Buede, in order to evaluate Army acquisition programs. Dr. Larsen has contracted with SONEX Enterprises Inc. to develop CEaVa as a web-based process for implementation for the Army Chief of Staff organization. Dr. Larsen has managed the development of this tutorial.

This tutorial will provide a demonstration on how CEaVa is being implemented in evaluating Department of Defense acquisition programs.

In summary, the CEaVa method will improve the development process, which will increase the likelihood of building the right system within budget and schedule.

Name(s):

Niels Malotaux

Employer:

N R Malotaux - Consultancy

Title

Abstract

In today’s competitive environment, it’s not enough to run a project until it is ready. We must accomplish ever more in less time. This calls for constantly optimizing the way we run projects, beyond what we can learn from basic project management courses with general guidelines on how to setup and run projects even beyond what we normally learn from actually running projects. Theory is good. But not all theory works as expected in real practice. In this tutorial we will present methods that have been proven in practice to make projects deliver more successful in significantly shorter time.

Evolutionary Project Management Methods (Evo) allow projects to routinely deliver Quality On Time: What the customer needs, when he needs it, creating customer success.

Time and budget limits are not exceeded any more. These methods are taught and coached in actual development projects with remarkable results.

Elements of these methods are solving the discipline problem, exploiting our intuition mechanism, continuously balancing priorities, keeping focus and preventing any stakeholder’s complaints. It integrates Planning, Requirements Management and Risk Management into Result Management.

At the end of this workshop I will ask you “Can you afford not to use Evo?”. You will know the answer.

Name(s):

Ivy Hooks

Employer:

Compliance Automation Inc.

Title

Writing Defect Free Requirements in Government and Industry

Abstract

It is obvious that if we do not have the correct requirements we will not get the desired product. Still every study about cost and schedule overruns and failed software projects lists requirement problems among the top three culprits. Clearly, getting defect-free requirements is difficult, but essential to providing quality, timely and cost-effective products.

Requirement problems affect all industries and all types of projects. Types of defects are neither industry nor project unique; they range from missing requirements to stating implementation instead of requirements, from poorly written and ambiguous to just plain wrong. Some of the defects can be avoided by using standards and educating the writers and reviewers. Some of the defects will have to be removed after the writing, but before design has begun.

We will address the common defects and avoidance and removal methods that can be put in place to rapidly improve the quality and timeliness of the requirements.

Name(s):

Alain Faisandier

Claude Feliot

Jean-Philippe Lerat

Employer:

MAP Système

Alstom

Sodius

Title

A complete picture to model complex systems: what, when, how and why model systems.

Abstract

Systems that are currently under design within enterprises are more and more complex. The economical context raises more constraints than ever. The cause of most of industrial problems, leading to project slipping and over costs can be found in a weak engineering.

Quite often, the design team’s members do not master the right intellectual tools that help to solve complex problems. Without a global/holistic vision of the system, hence called “a system vision”, and without the knowledge of the modelling techniques that can be used, the system design is not supported by the right models. This situation leaves the highest levels of system without a solid, consistent and cost-effective architecture.

Systems Engineering focuses on :

- a general “system-level” approach,

- a framework to structure design & development activities

- a set of processes, methods and modelling techniques,

- a cost-effective implementation inside the organizations.

This tutorial focuses on modelling techniques and aims to refresh this domain with an introduction to advanced techniques.

The tutorial provides keys to effectively model systems and to derive the most cost-effective organization to engineer a system. It draws a comprehensive view of modern Systems Engineering, using the latest achievements in terms of processes and modelling techniques.

The tutorial is built as a progression from basic modelling techniques to new concepts and techniques, ending with SAGACE, a state of the art method.

The tutorial is composed of two parts :

The first part describes modelling techniques that are efficient to elicit use cases, needs and expectations. The tutorial presents the way they can be used to generate and analyse requirements, to design behavioural, logical architectures and physical architectures. The modelling techniques are aligned with the generic technical processes defined in modern international standards such as ISO-IEC 15288, ANSI-EIA 632, ANSI-IEEE 1220.

The second part goes deeper in system modelling, with an introduction to studies derived from a method known as SAGACE ™, formerly created for the CEA, the French Nuclear Agency.

The methods presented during the course are a real breakthrough in the “ Systems Way of Thinking” and provides unmatched capabilities to model high-level systems.

The tutorial comes with world-class training material and is organized with an on-going example that is considered under the different point of views.

Name(s):

Peter Hantos

Employer:

The Aerospace Corporation

Title

Unified Life Cycle Modeling

Abstract

Life Cycle Modeling (LCM) is an often misunderstood and misused area of systems and software engineering. Although engineering curricula and “real-life” projects give lip service to LCM, on closer look there is a gap between actual practices and LCM considerations learned in class or included in documentations. This tutorial introduces Unified Life Cycle Modeling (ULCM,) a highly intuitive, pattern-based approach that provides guidelines to process architects and project managers for navigating the confusing and sometimes contradictory life cycle model descriptions and standards. ULCM is used to demonstrate, document, and analyze the relationship between concurrent engineering streams of the key disciplines in Integrated Product and Process Development (IPPD) and their relationship to government acquisition or corporate development processes. Examples will come from widely used software development life cycle patterns; platform-based, product-line development of software-intensive systems; and the development and integration of electronic hardware elements, such as PCBs (Printed Circuit Boards) and ASICs (Application Specific Integrated Circuits). Finally, the role and applicability of relevant ISO/IEEE standards and the Object Management Group’s SPEM (Software Process Engineering Metamodel Specification) will be explored.

Name(s):

Tim Kasse

Employer:

Kasse Initiatives LLC

Title

How to Establish and Maintain Integrated Teams --CMMI Level 3.5 –

Abstract

This half-day tutorial is directed at organizations with projects and people who find themselves not only needing to have well established and well integrated project management functions in place, but needing to build self-managed and empowered teams whose members are collectively responsible for delivering the work product in order to support clear business objectives.

Participants will be presented with concepts that begin with basic project management extending into integrated project management and then into integrated teams. Basic project management functions will be continued to Integrated Project Management based on an organization’s set of standard processes and a true integration of plans that affect the project. This presentation will illustrate the organizational culture changes needed to accept and nurture integrated teams through the establishment of an organizational environment and the policies and visible support of higher-level management.

Name(s):

Dr. Amihud Hari

Employer:

• System Engineering and Evaluation Centre (SEEC), University of South Australia (UNISA)
• Technion, Haifa, Israel

Title

ICDM – Conceptual Design Methodology

Abstract

Conceptual design of a new product, which satisfies market needs economically, has always been the highlight of the engineering profession, especially in modern industry which struggles to succeed in a global, competitive market. The system engineering theory tells you to develop candidate solutions, evaluate and choose, however there is no agreed to method as to how to meet this process requirement. Conceptual design takes place very early in the design process, under pressure, and must usually be accomplished within a short time which tend to result in many late engineering design changes. It has been shown that most of the product life cycle costs are determined during this important stage and cannot be reduced in later stages.

Integrated Customer Driven Conceptual Design Method (ICDM) is a new, practical, proven and effective structured methodology for the conceptual design of new high value products/systems. ICDM covers the entire process of the conceptual design phase. ICDM provides a suite of methods for each step of the conceptual design phase e.g. analysing customer needs and requirements, new product definition and specifications generation, abstraction, creation of ideas, synthesis of concepts, evaluation and selection of solutions, conceptual failure mode analysis, conceptual design to cost and risk and time to market analysis

ICDM enables the new product development team to develop a creative, competitive and economic product that includes the important features that the customer would agree to pay for and avoids features that he would not like to pay for. The introduction of the method also significantly improves the innovation and decision making skills of managers. ICDM is a proven method for performing the critical task of solution creation evaluation and selection in the system engineering process to make the best choice.

Name(s):

Harry Lewis

Employer:

SONEX Enterprises Inc

Title

Continuous Early Validation (CEaVa)

Abstract

Many complex technological based systems are being produced that are not used or useful on delivery, because the wrong problem was solved. This is common due to changes in the operational environment. There has been literature that discusses the need to get stakeholders involved earlier in the development process to correct this problem; however, no one has developed a detailed framework that accomplishes this intent. This research developed a method involving a four-step sequence that validates the system early to ensure that the right problem is being solved. The method is called Continuous Early Validation (CEaVa). It is a method that increases the likelihood of producing the correct system in the end. The method develops visibility of potential disconnects among stakeholders' needs, original written requirements, organizational policy, and derived requirements. The CEaVa method will validate the external and internal consistency of the problem statement. Additionally, CEaVa provides a process to facilitate consensus resolving the potential disconnects with decision analytical reasoning for trade-off analysis of the system engineering aspects of the development.

The CEaVa method was developed by Dr. Bob Larsen (LTC US Army), under the direction/guidance of Dr. Dennis Buede, in order to evaluate Army acquisition programs. Dr. Larsen has contracted with SONEX Enterprises Inc. to develop CEaVa as a web-based process for implementation for the Army Chief of Staff organization. Dr. Larsen has managed the development of this tutorial.

This tutorial will provide a demonstration on how CEaVa is being implemented in evaluating Department of Defense acquisition programs.

In summary, the CEaVa method will improve the development process, which will increase the likelihood of building the right system within budget and schedule.

Name(s):

Prof. Dr. Mike Mannion

Prof. Dr. Hermann Kaindl

Employer:

Glasgow Caledonian University

Vienna University of Technology

Title

Requirements Reuse

Abstract

Reuse and requirements are very important for efficient and successful systems development. However there are many open issues about performing them well, in particular the reuse of requirements. This tutorial presents the experiences of requirements reuse using a Method for Requirements Authoring and Management (MRAM).

For modern, highly complex, high reliability systems, the need for properly structured, carefully controlled requirements specifications, which are understandable, complete and consistent is essential in order for the resultant computer-based system to be delivered on time, within budget and to the desired high level of quality. One approach to managing these problems is to establish a pool of reusable requirements and to construct the requirements for a new system by making a selection from the pool. A concern of this approach is the efficient and clean selection of a consistent combination of requirements. A consistent combination is one in which the requirements selected satisfy any constraints imposed by the pool of reusable requirements.

MRAM is a method for establishing and selecting from product line requirements that addresses this concern. Using MRAM means the management of the requirements definition process is more effective and efficient, producing more accurate and complete requirements documents. TRAM (Tool for Requirements Authoring and Management) is a software tool to support MRAM that utilises current proven office technology ( MS-Word, MS-Access). The tutorial presents the results of MRAM/TRAM as it has been applied to a real-world application.

Name(s):

Jorge R. Buenfil

Employer:

Enterprise Tool Integration

Title

Project Estimation based on Requirements Analysis using UML tools

Abstract

This tutorial shows how to use a UML tool to drive the time and cost estimation of a project by analyzing and validating the originating

Name(s):

Gerrit Muller

Employer:

Embedded Systems Institute

Title

Roadmapping

Abstract

This tutorial is based on the module “Roadmapping” of the SARCH course that has been given 24 times to a wide variety of commercial participants: Philips (MRI scanners, X-ray equipment, consumer electronics, semiconductors, lighting), Océ (printers), ASML (wafersteppers), Siemens (car navigation), FEI (electron microscopes), Assembleon (placing machines), and Bosch (security systems, cameras, conferencing systems).

Roadmapping is one of the means to relate Industry, Government and Academic activities, by bringing all activities in (time) perspective. The academic world ought to be out of phase with the other parties (state-of-the-art versus state-of-the-practice), but should be inspired by future needs of the other parties. Roadmapping is a tool that makes these relationships visible in a constructive way.

Name(s):

Hal Mooz

Employer:

Center for Systems Management

Title

Introduction of the Systems Engineering Dual Vee Model

Abstract

This tutorial addresses the bridging of industry, government, and industry by introducing an expanded version of the Vee model to serve as a universal frame of reference for managing solution development concurrent with architecture complexity.

In 1990 Dr. Kevin Forsberg and I introduced the Vee model that has enjoyed wide spread multinational adoption and a core reason for the success of Visualizing Project Management having sold almost 40,000 copies. Since then we have continued to evolve the Vee into the Vee+ and the Vee++ models. We have now expanded the model to simultaneously address both solution development and architecture complexity management. This tutorial will cover all development models leading up to the Vee, Vee+, Vee++ and the Dual Vee Model.

Objectives:

Students will learn:

1. The power of models
2. The role of solution development models
3. The heritage and objective of the Waterfall
4. The evolution of the Spiral and win-win Spiral
5. The motivation and birth of the Vee
6. Solution development and architecture management issues
7. Vee model versions and enhancements
8. The power of the Dual Vee
9. Implementation strategies and tactics
10. How to apply to unified, incremental, linear and evolutionary development.
11. Applicability to Agile Development

Name(s):

Tom Gilb

Employer:

Result Planning Limited

Title

Competitive Systems Engineering: how to do systems engineering in hot competition. Detailed pragmatic and unconventional techniques.

Abstract

Some systems engineering is done in continuous international competition. For example telecommunications products. For example military systems. The problem is not merely to get it done well on time, but to visibly beat the competition in quality and price while also beating them on time to market. There are specific engineering methods and processes that emphasize the ability to ‘beat the enemy’. This tutorial will highlight the specific methods we can offer to aid the competitive engineering process. The methods are innovative and the key idea is the ability to quantify all critical qualitative aspects of a system, not just the conventional ones.

Name(s):

Tom Gilb

Employer:

Result Planning Limited

Title

Systems Engineering Specification Quality Control: the application of the 'Inspection' method to the quantified measurement of the degree to which all types of systems engineering specification meet defined standards.

Abstract

How can you cheaply and objectively measure the quality of systems engineering specifications? I call this discipline Specification Quality Control. It is based on sampling (early and frequently) of ongoing engineering specification on absolutely all requirements, design, contracts, bids, engineering diagrams, test plans and software artifacts. The process is based on counting defects with respect to written official specification standards, and extrapolating to get a truer count of major defects and their consequences. It is based on setting a formal economic limit of major defects per page allowed before exit to other engineering processes. SQC effectively teaches adherence to standards, and is capable of giving clear early warning signals to project management, while there is still time to rectify bad work. The method has been proven and documented to save millions of $ in rework costs in aircraft, electronics and software industries.

Name(s):

Bill Schindel

Employer:

ICTT

Title

Pattern-Based Systems Engineering: An Extension of Model-Based Systems Engineering

Abstract

Systems Engineering is arguably fifty years old as a formalized approach to the engineering of complex systems. This is very young in comparison to the several centuries that electrical, mechanical, chemical, or civil engineering have had to develop into mature disciplines that have a complete scientifically-grounded theoretical basis matched with a practical set of methods. Compared to, for example, electrical engineering, we might think of systems engineering as somewhere between the work of Hertz and Maxwell. For this reason, we should not be surprised that systems engineering is still developing toward an actual engineering discipline, versus a body of knowledge dominated by practical methods.

A hallmark of this evolution is the current effort to extend prose-oriented systems engineering to Model-Based Systems Engineering (MBSE). There are different interpretations of the meaning of MBSE, ranging from mathematically-oriented formal methods to software-inspired modeling languages, and the relation of these to prose-oriented “traditional” systems engineering is not always clear. Experienced systems engineers have found reasons to question the benefits of MBSE when it appears to ignore practical needs, but traditional methods are under pressure to produce better results.

This tutorial will begin by introducing an approach to MBSE that directly addresses the need for a theoretical foundation based on the key elements of physics and mathematics supporting other engineering disciplines—in particular, the concept of interactions at the heart of all the other mature engineering disciplines. On the basis of this “physics of systems engineering” an underlying meta-model will be demonstrated that has been practically applied to MBSE over the last decade, bridging commercial automotive, mil-aerospace, commercial telecommunications, medical and health care systems, and consumer goods, while linked to academically sound engineering and mathematical principles beyond good prose-based practices. This includes demonstrating the surprising insight that prose-based requirements statements are the non-linear generalization of linear transfer functions.

After illustrating practical MBSE in these commercial, governmental, and academic settings, this tutorial will then demonstrate the extension of MBSE to Pattern-Based Systems Engineering (PBSE). This is systems engineering of product lines or families of configurable systems, in which models of requirements, not just designs, are re-used. This is a major paradigm shift in systems engineering, as it moves the SE emphasis from methods and procedures to mastery of standard patterns at the heart of major enterprises and domains—the patterns that describe aerospace, automotive, telecom, manufacturing, health care, and other modeled systems. PBSE thereby accelerates the development of systems engineers earlier in their careers by their mastery of explicit re-usable models and dramatically improves the ability to demonstrate CMMI or Six Sigma improvements.