bluuebunny/crossref_metadata_2025 huggingface dataset:
3.8.2 Integrating Systems Engineering and Earned Value Manag ement
Authors: Solomon Paul J.
Published: November 2014

Earned value is the only technique proven to effectively integrate cost, schedule and technical performance management (Czelusniak 1997). However, because earned value is a derived measure, its effectiveness as a measure of performance depends on the effectiveness and objectivity of its base measures and on the capabilities of the systems engineering and project management processes that are employed. Earned value management (EVM) can provide more management value if it is integrated with systems engineering, if its implementation is consistent with pertinent standards and capability models and if the base measures for earned value are based on technical performance.

This paper provides a framework and practical guidance for EVM process improvement. The framework is based on a gap analysis between the EVM standard and three standards and capability models for systems engineering and project management. The cited standards and models provide more explicit guidance towards achieving the principles of EVM than is provided by the EVM standard itself. Practical guidance for process improvement is based on best practices within Northrop Grumman Corporation and on the Software Engineering Institute (SEI) publication, “Using CMMI® to Improve EVM” (Solomon 2002).
3.8.3 Systems Engineering and Process Infrastructure Development
Authors: Armstrong James R
Published: November 2014

All the lessons learned in developing products for external customers often are forgotten when developing internal products. This is especially true when developing the infrastructure, processes in particular, for performing systems engineering. Processes usually are written in a design‐first approach with all the errors that such a process creates. There is a better way to develop processes. This paper addresses how to apply the systems engineering process to developing processes and their supporting infrastructure.
3.8.4 Zoned Analysis: A Circular Bird's‐Eye View of Project Tasks and Deliverables1
Authors: Zirker Larry , Johnesee Jim , Hamelin Douglas
Published: November 2014

Zoned analysis (ZA) is a graphical decomposition methodology initially practiced in academia to ensure that all aspects of a curriculum were addressed with lesson plans, but this method has been adapted as a systems engineering tool with multiple end uses to facilitate collaboration of team members, enhance management understanding of the project, show team members their responsibilities, link requirements to deliverables, and aid in gap analysis. A ZA appears as a bull's‐eye or target with partitioned pie‐shaped sections emanating from the center circle to outer circles. The title of the project or program is placed in the center circle. Subsequent partitioned circles, or zones, facilitate the decomposition hierarchy of the project with the outer‐most zones or elements evolving as terminal elements or deliverables. This article shows examples of ZAs and provides instruction on how to construct a ZA.
1.4.2 Enterprise Architecture and Enterprise Process Improvement
Authors: Ibrahim Linda , Wells Curt , Bate Roger
Published: November 2014

The Federal Enterprise Architecture (FEA), once institutionalized throughout government, can become a major driver for process improvement. This will depend on the use of best practice in creating, applying, and evolving it and the successful launching and execution of projects to realize those improvements. An enterprise process improvement model that provides best practice guidance for creating, applying, evolving, and institutionalizing the FEA, can align with the FEA in striving for enterprise improvement. Industry is monitoring Government progress, and some companies are working on their enterprise architectures.

Enterprise architecture and enterprise process improvement are similar concepts, with similar methods, seeking similar objectives. This paper examines the commonalities between enterprise architecture and process improvement and illustrates how an enterprise process improvement model, when used in combination with enterprise architecture, can enable improvement across government and industry.
1.5.1 Bridging System Engineering and Human Factors Engineering: a step forward
Authors: René Jean
Published: November 2014

Human factors are the cornerstone for insuring QHSESA quality for all/some/many systems. Normative documents such as ISO 15288 or EIA 632 provide keys to human factors processes and activities. There are few links between system engineering (SE) processes and human factors engineering (HFE) processes.

This article bridges the gap between SE, using EIA 632, and HFE, using ISO TS 13407 and ISO TR 16982. The purpose is to provide project managers and system engineers with a guide helping them to plan and implement human centred design. The first part deals with SE, the second with HFE, and the third provides the bridge between the two. For each EIA 632 requirement, the article indicates the relevant ISO 13407 principles and activities to apply.

ISO 13407 is not as specific and clear as EIA 632. It would be relevant to enhance HF standards in order to encompass such processes as risk management, effectiveness analysis, or trade‐off analysis.
1.6.1 Software Project Management: Adding Stakeholder Metrics to Agile Projects
Authors: Gilb Tom
Published: November 2014

Agile methods need to include stakeholder metrics in order to ensure that projects focus better on the critical requirements, and that projects are better able to measure their achievements, and to adapt to feedback. This paper presents a short, simple defined process for evolutionary project management (Evo), and discusses its key features.
1.6.2 An Approach to Tailoring Major Technical Reviews Based on Project Characteristics and Stakeholder Interests
Authors: Richstein Alan B. , Nolte Jerome T. , Pfarr Barbara B.
Published: November 2014

Both NASA and DOD have well defined, proven technical review processes that include numerous technical reviews that occur throughout the systems engineering process life cycle. Many are well known by project managers and stakeholders such as developers and end users, an example of which is the critical design review (CDR). This major milestone for a large, complex new project may last two or more days, include an extensive agenda of topics, and entail hundreds of hours of developer time to prepare presentation materials and associated documents. Additionally, the weeks of schedule spent on review preparation is at least partly at the expense of other work.

This paper suggests an approach for tailoring technical reviews, based on the project characteristics and the project manager's identification of the key stakeholders and understanding of their most important issues and considerations. With this insight the project manager can communicate to, manage expectations of, and establish formal agreement with the stakeholders as to which reviews, and at what depth, are most appropriate to achieve project success. The authors, coming from diverse organizations and backgrounds, have drawn on their personal experiences and summarized the best practices of their own organizations to create a common framework to provide guidance on the adaptation of design reviews to other system engineers.
2.1.1 Isoperformance: Analysis and Design of Complex Systems with Known or Desired Outcomes
Authors: de Weck Olivier L. , Jones Marshall B.
Published: November 2014

Tradeoffs between performance, cost and risk frequently arise during analysis and design of complex systems. Many such systems have both human and technological components and can be described by mathematical input‐output models. Oftentimes such systems have known or desired outcomes or behaviors. This paper proposes “isoperformance” as an alternative approach for analyzing and designing systems by working backwards from a set of desired performance targets to a set of acceptable solutions. This is in contrast to the traditional “forward” process, which starts first in the design space and attempts to predict performance in objective space. Isoperformance can quantify and visualize the tradeoffs between determinants (independent design variables) of a known or desired outcome. For deterministic systems, performance invariant contours can be computed using sensitivity analysis and contour following. In the case of stochastic systems, the isoperformance curves can be obtained by regression analysis, given a statistically representative data set. Examples from opto‐mechanical systems design and human factors are presented to illustrate specific applications of the method.
3.5.2 Integrated Modular Avionics: a challenge in Tools & processes
Authors: Bonnet Pierre , Coupier Alain
Published: November 2014

For years, the avionics systems have been implemented via Line Replaceable Units (LRU) where each LRU is dedicated to one avionics function, leading to huge avionics costs as more and more functions were embedded.

In the late 80's, came the idea of Integrated Modular Avionics (IMA) where generic “platforms” would be shared by several “applications“.

“First‐generation” IMA programs demonstrated the industry capability to provide integrated “avionics suites” with standardised computing resources, leading to significant improvements in terms of direct and indirect aircraft costs.

With the “Second‐generation” of IMA program, the IMA platforms are now being procured separately from the hosted avionics applications, introducing many challenges in terms of industrial organisation, design processes and tools.

Thales with Diehl Avionik Systeme, its 49% German subsidiary, has been awarded IMA platforms on the A380 and had to overcome with Airbus these challenges to make this “2nd‐generation” IMA a success.

The paper will review how Thales and Diehl are conducting these changes, and how System Engineering processes are impacted.

The paper will also give some hints and what is still to be made or could be envisioned as a “3rd‐generation” IMA.
4.3.2 Systems Engineering Approach To Information Assurance
Authors: Taylor Kim H. , Sloan Crystal D.
Published: November 2014

Today's security solutions for protecting telecommunications and information infrastructures are primarily defensive. They are not commensurate with the increasingly sophisticated nature of the global cyberthreat, and likely ineffective in countering new, dormant threats that could be a strategic surprise to organizational security. Defensive measures such as firewall and antivirus software can only protect computer networks and systems against known signatures of malicious code. To engineer pre‐emptive capabilities and processes that discourage and repel attacks would require integration of key aspects of security domain engineering into systems engineering practices. An integrated approach would promote the implementation of security controls and processes as built‐in features of future human/computer systems and networks, rather than as separate solutions, thus enabling a more holistic and robust information assurance.
4.4.1 Concept of Operations Development Considerations for a Highly Networked System
Authors: Herald Tom , Verma Dinesh
Published: November 2014

Within the United States Department of Defense, the interest and focus on Network‐Centric Systems (NCS) is increasing. The US Navy defines network‐centric operations as “military operations that exploit state‐of‐the‐art information and networking technology to integrate widely dispersed human decision makers, situational and targeting sensors, and forces and weapons into a highly adaptive, comprehensive system to achieve unprecedented mission effectiveness.” (Committee, 2000) Therefore, the benefits of building a NCS appear to be obvious and desirable for providing greater information in order to render higher quality decisions and provide greater overall system capability. However what is not so obvious is the priority order of the incremental system benefits realized by the NCS. There is a need to identify the magnitude and order of the systems (or system capabilities) that are to be integrated to provide the greatest impact on the NCS mission needs.

The importance of developing a clear Concept of Operations (ConOps) document has been acknowledged for many years (since R. J. Lano's seminal publication in 1980). The process traditionally involves a single Systems Engineer (or System Architect) responsible for taking the needs statements from the involved stakeholders, and consolidating this tops‐down information into a coherent ConOps document. When the size of systems and the number of stakeholders were both small this “single person focal point” was reasonable; however, with NCSs this approach is no longer sufficient. The challenge is how to best formulate a NCS‐level ConOps when the number of stakeholders with uncompromising needs has increased drastically.

Since a new NCS is often made up of existing systems plus the development of new state‐of‐the‐art and emerging‐technology systems, there is potential to provide an early system analysis from the bottoms‐up and integrate with the stakeholder tops‐down needs. This source of information is the existing constituent system Concept of Operations (ConOps) documents. However, how can these be effectively used? This paper focuses on a reasonable implementation in direct support of the NCS Systems Engineer with the tops‐down and bottoms‐up mapping for effectively feeding the NCS‐level ConOps document development process.
6.5.1 Attributes of a Managerial and Organizational Infrastructure to Enable Safe Systems
Authors: Jackson Scott , Hann Stuart D.
Published: November 2014

Human‐intensive systems have become the subject of systems engineering studies in recent years. This concept can be used to define the organizational and managerial infrastructure that develops, maintains and operates complex systems subject to catastrophic failure. For a program to be effective, it must exist within this infrastructure that contains specific attributes that will enable it to meet its objectives. If it does not, even the most well planned program will experience shortfalls, and there are multiple examples of that occurring. This paper presents the attributes' observable features and shows how these attributes can be confidently applied to any organizational and managerial infrastructure. While these attributes are not a guarantee that a program will be effective, they provide the means to assure that any program will have an opportunity to perform at its best without being compromised by an inappropriate infrastructure. Case studies are cited and correlated to specific attributes, which, if applied, would have mitigated the probability of a major catastrophe.
6.6.1 Adapting Systems Engineering for Software‐Intensive Systems
Authors: Sheard Sarah A.
Published: November 2014

The nature of systems engineering has changed in the last quarter century because of the increasing presence of software in systems. This paper describes the adaptations that systems engineers should make to their skills and approaches in order to engineer software‐intensive systems better, and the places where systems engineers need to reinforce what continues to be useful about traditional systems engineering. Systems engineers should continue to contribute “systems engineering specialist” skills, help the project manager coordinate multidisciplinary activities that ensure a well‐engineered system, and continuously learn about software. Finally, the systems engineer might need to advocate for good systems engineering.
6.6.3 Lessons Learned from Implementing Configuration Management within Electrical/Electronic Development of an Automotive OEM
Authors: Knippel Erwin , Schulz Armin
Published: November 2014

In the past decade the automotive domain has encountered significant changes within its competitive environment. Automotive OEMs are forced to offer an increased number of variant models, to satisfy individual customer needs as well as constantly introduce innovative features within their products. Electrical/electronic systems play a major role enabling OEMs to address these needs. Development processes for electrical/electronic systems are moving into the focus of automotive companies. However current development approaches for these type of systems within automotive industry are only partially able to cope with the mentioned challenges and yield the necessary, high‐quality systems. Thus automotive OEMs started to restructure their development approaches for electrical/electronic systems and introduce Systems Engineering.

This paper is illustrating lessons learned from implementing configuration management within electrical/electronic development as part of an major initiative at a German OEM to introduce Systems Engineering. The initiative is still on its way, therefore the lessons learned are only part of the truth. The paper will start by highlighting the current situation of the automotive industry and point out the future role of electrical/electronic systems for achieving competitive advantage. Based on this background the need for Systems Engineering, especially within electrical/electronic development will be discussed. Configuration management as a part of Systems Engineering processes will be described in general and in its application in an automotive environment. The specifics of configuration management within Electrical/electronic development of an automotive OEM will be highlighted and discussed. Afterwards the paper discusses lessons learned during conception and implementation of the configuration management building blocks into the OEMs organization. Key success factors for introducing configuration management as part of a Systems Engineering initiative into an existing process and organizational landscape are then derived from the lessons learned.
7.3.1 Human Understandability for Optimizing Architectures
Authors: Smith Darold K.
Published: November 2014

Humans define, create, and use systems. Therefore, to minimize opportunities for problems in a system's lifecycle, the work products that affect the system definition and program lifecycle activities must be highly understandable and not subject to multiple interpretations. The antidote to complexity is (human) understandability. Understandability is driven by the amount and clarity of information presented and accessible to stakeholders at a particular level in the system architecture. High‐level information needs to be more general while lower‐level information must provide sufficient detail to prevent ambiguity and omissions. The issue is how to package information at each system level to maximize stakeholder understandability at that level.

This paper describes ways to increase human understandability and thereby increase system robustness of both the architecture elements and interfaces between them during the SE process. The result is a system definition that is more likely to satisfy the SE goals of delivering an error free product.
7.4.3 Inside‐Out Systems Architecting: An Approach to Architecting the NASA Orbital Space Plane
Authors: Post Kevin E. , Dagli Cihan H.
Published: November 2014

NASA has published the Level One requirements for the Orbital Space Plane development. Those requirements leave open opportunities for creative development of a spacecraft that not only will provide the world with efficient travel to and from low‐earth orbit, but also for crew rescue capability from the International Space Station. The success of the Orbital Space Plane development phase will depend strongly on the ability of competing contractors to establish criteria for gathering the needs of the stakeholders and develop models which are technically achievable, have acceptable risks, have acceptable costs, while adequately meeting the NASA needs.

This paper proposes a hypothesis for architecting the NASA Orbital Space Plane. Beginning with the level one system requirements, this approach defines a “system of systems” approach that moves from the “inside‐out” in an iterative fashion. This process allows the system architect to understand the out‐lying systems and when/where the architecting process should stop. Systems are inherently boundless and knowing also where are the client's core needs versus what are the “desirements“. Fundamentally, both the System Life Cycle functions (process architecting) and the System Functions (product architecting) need to be addressed in this way and in an integrated fashion. Each system level would address both the System Life‐Cycle Function as well as the System Functions.
7.5.3 Testing Industrial Embedded Systems – An Overview
Authors: Prins Martin
Published: November 2014

Industrial systems are becoming highly dependent on software modules. This results in a continuous increase of both development & test effort and maintenance & upgrading effort of innovative products. While on one hand competitiveness requires an as early as possible rollout of new developed products the increasing complexity tends to lengthen the testing trajectory and seriously threatens the quality of the delivered products. To limit this trend of increasing cost, time, and team size, research is required that targets on improving development and test methodologies, processes, and supporting tools.

Based on experiences in the semiconductor industry ‐ in particular the lithography segment of this industry ‐ this paper explores factors that should be taken into account when selecting a test strategy. In the paper, we discuss the major factors contributing to the complexity of complex system integration. In particular we will consider the problem of testing subsystem and system behavior during several stages of integration. We discuss several contributing factors to the test problem: the need to deliver in time, technology, and testing knowledge.
8.2.3 Verification, Validation & Testing Strategy and Planning Procedure
Authors: Lévárdy Viktor , Hoppe Markus , Honour Eric
Published: November 2014

This paper introduces a new systems engineering approach for verification and validation (V&V) planning: the Verification, Validation & Testing (VVT) Strategy and Planning Procedure. This iterative planning technique offers an effective method for the deeper integration of V&V planning with other systems engineering disciplines and supports the maximal fulfilment of the project goals and objectives. Since V&V is an important means to reduce project risk, the new VVT strategy & planning procedure assists the risk management efforts by feeding the results of risk analysis directly into VVT planning and the systems engineering measurement process. VVT planning defines the optimal risk reduction strategy in form of the VVT process and a measurement system to track project risks throughout the lifecycle. The three stages of the SysTest VVT Process are introduced in the first part of the paper and then the major steps of the VVT strategy & planning procedure are described in detail. Finally, the last section provides insight to the SysTest pilot projects presenting the first results of the VVT Methodology implementation.
8.3.1 Clearing The Confusion About Spiral/Evolutionary Development
Authors: Mooz Hal , Forsberg Kevin
Published: November 2014

US Government DoD Directives 5000.1 and 5000.2 declare a preference for evolutionary acquisition and spiral development both of which affect the life cycle and associated life cycle processes. Since this declaration there has been considerable confusion over what these terms mean and how they should be applied to system acquisition. Unfortunately, the DoD's own terminology definitions do not help to clarify these approaches and tend to counter traditional understandings. Both the Software Engineering Institute and Under Secretary of Defense E. C. (Pete) Aldredge have been quoted that there is confusion and lack of understanding of both the terms and application. This paper highlights the points of confusion and then takes the reader back to ground zero and builds a logic based understanding of available technical strategies. Included are technical methods/models, development strategies, and delivery strategies.
8.4.1 Supportability Analysis Process Flow
Authors: Navarro Ernesto A. , Carstens Howard D. , Sleder Albert
Published: November 2014

United Defense, L.P., Armament Systems Division has developed a process that improves the accuracy of reliability, maintainability, and supportability analyses during the design cycle. These analyses rely heavily on initial assumptions in calculating key parameters and serve as the basis for determining spares, manpower, maintenance policy, etc and ultimately the estimate for system Total Life Cycle Cost (TLCC). Because of this, it is imperative that the initial assumptions be realistic and credible. We found that by modeling and simulating the design against the customer's specific mission profile, we can obtain realistic credible results, permitting the program to make cost effective supportability decisions early in the system design cycle.

This paper presents the process and related tasks used in developing the supportability analysis in order to obtain realistic supportability results. Also, this paper discusses the benefits of the approach and draws a comparison between the traditional methodology and this new process.
8.6.2 Maintainability Considerations for Software Intensive Systems
Authors: Ramchand Ramya , Tatikonda Nirmala , Verma Dinesh , Nance Richard E.
Published: November 2014

This paper reflects one aspect of an overall research initiative to better understand and articulate the “cause and effect” relationship between design causes and operational effects. Here the specific focus is on “before the fact” system maintainability. Maintenance considerations for software intensive systems must be addressed early in design and must focus on the entire system life cycle. Use of commercial‐off‐the‐shelf (COTS) components in system architectures reinforces this need. COTS usage can be readily observed in modern commercial and defense systems. Such architectures are often characterized by an evolving physical baseline (technology refreshment) driven by obsolescence considerations. This paper proposes aspects of a framework to evaluate system architectures, with a particular focus on system maintainability and with the objective of positively influencing the long‐term cost of operational maintenance.
9.1.1 Applying Systems Engineering to University Satellite Projects
Authors: Meijers M.A.H.A. , Hamann R.J. , Zandbergen B.T.C.
Published: November 2014

A growing number of spacecraft development programs are emerging at universities across the world. These programs share a lot of characteristics because they are all encouraged by the perception that a small spacecraft can both be capable and low‐cost. The success of these missions, both on a performance and programmatic level, is often due to use of adapted design and verification methods from mainstream large satellites. These methods are well described in successive papers like [McInnes, 2001] & [Kitts, 1995]. Less attention is however paid to the adaptation of the requirements definition process and design configuration management process into a small satellite project. This paper shows the need for the adaptation of full Systems Engineering (SE) functionality into such a project and that it is possible to adapt the SE process, while keeping full functionality, into a small spacecraft project that is conducted in an educational environment. The paper describes the successful introduction of the requirement engineering process and configuration/design management in the Delfi‐1 university satellite program, as part of the primary author's master thesis.
9.2.1 Application Experiences of the VVT Process Modeling Procedure for Verification and Validation Planning
Authors: Hoppe Markus , Lévárdy Viktor , Leardi Carlo , Mendikoa Inigo , de Abajo Nicolas , González Juan A. , Lobato Vanesa , Peregrina Susana
Published: November 2014

A thorough balancing of the costs of conducting verification and validation with the costs of failure promises new possibilities in reducing overall project costs and time‐to‐market. One goal of the presented SYSTEST project is to develop an approach to support the strategic verification1 and validation2 (V&V) planning. This approach, reflected in the VVT3 Process Model, supports the trade‐off between different V&V strategies by calculating the effect of the strategy on cost‐, schedule‐, and quality‐risk. This paper briefly presents the VVT Process Model and describes in detail some first application experiences.
9.2.2 UML‐PVS Requirement Specification and Verification
Authors: Traore Issa , Jamal Hani M. Al , Liu M. Yanguo , Sahraoui Abd‐El‐Kader
Published: November 2014

In this paper, we present a specification‐based testing approach in which, first, the specification is validated by verifying important system properties using model checking, consequently increasing our confidence in it. Then, suitable test cases are generated for a system implementation using the previous specification as test oracle. The specification is produced using the UML, which is based on a graphical notation that is easy to learn and use. The formal model used during the model checking activities is based on a formal semantic that we have defined for a subset of the UML. We apply, in this paper, the approach to the case study of a safety‐critical software; namely, a temperature regulator software component that is used in various highly dependable systems.
9.4.1 A Systems Engineering Process Model for ‘By Default’ Systems Integrators
Authors: Cowper Douglas , Emes Michael , Smith Alan
Published: November 2014

Many individuals find themselves systems integrators ‘by default’. This situation comes with many challenges when integrating custom systems from off‐the‐shelf components. A particular challenge is for ‘by default’ systems integrators to employ sound systems engineering practices when they cannot be expected to have a good understanding of systems engineering principles, such as those described in ISO 15288. This paper aims to explore the issues and risks facing a ‘by default’ systems integrator, and proposes a simplified lifecycle model and documentation set based on ISO 15288 to assist with these challenges.
9.4.2 The Biggest Peoplesoft Implementation Ever – Implications for Systems Engineering
Authors: Parth Frank , Gumz Joy
Published: November 2014

This paper describes the largest Commercial Off The Shelf (COTS) human resources implementation ever attempted. The Department of Defense has chosen to combine its payroll and personnel functions for all four branches of the military: Army, Navy, Air Force and Marines. The software they have chosen is Peoplesoft. Changes will occur for a variety of technical and political reasons, including Peoplesoft release updates, hardware updates, supporting software updates, requirements changes, funding changes and changes in Congressional leadership. How will the project deal with these changes? System engineering expertise is needed to manage the change that will occur inevitably on a COTS implementation as massive as this one is.
9.5.1 Evolving risks and use of Commercial Off The Shelf (COTS) components
Authors: Domikis Richard
Published: November 2014

As we continue to defend our nations, the increased use of Commercial Off The Shelf (COTS) technology in military, infrastructure and other systems necessitates different approaches to address evolving risks and opportunities. COTS technologies have become far more capable over the last 10 years and that trend shows no sign of slowing. In fact, the commercial world is often on the cutting edge as companies vie to win market share. Nations and customers have recognized this trend and, with a desire to capitalize on it (cost and time), are now often specifying “maximum use of COTS” in many systems. This increasing specification and use of COTS technology will increase the challenges in protecting our nations, as well as afford us new opportunities for exploitation and defense. All views expressed in this paper are those of the author and do not represent the policy or position of his employer or school.
9.6.1 On Trade Studies
Authors: Buede Dennis
Published: November 2014

This paper addresses trade studies – decision making activities that must involve the selection of possible alternatives and then the evaluation of these alternatives on a set of objectives while being confronted with uncertainty about the ability of the alternatives to achieve high levels on the objectives. This discussion addresses six different types of trade studies: four for the system being developed and two for the qualification system that must address verification, validation and acceptance of the system design. The topics of this paper are the elements of all trade studies, the way in which the objectives and uncertainties change as we move from one type of trade study to another, and the benefits and pitfalls of trade studies. While this paper focuses on the trade studies for the system being developed, the same discussion could be created for the system that is developing the system being developed.
10.5 Experiences of Teaching Systems Architecting
Authors: Muller Gerrit
Published: November 2014

The experiences of four years teaching systems architecting are described. The duration of the course systems architecting is 5 days. The target audience consists of (potential) architects and stakeholders that cooperate intensely with the architect, such as project leaders, product managers, and group leaders. The course has been given 23 times in the period November 1999 to January 2004. The maximum number of participants is 16.

This paper discusses the course content and the course objectives, course materials, the course format, some course statistics, the expectations of the students up front and the evaluation at the end, the follow‐up and the longer term results, the derived course for managers, the lack of visibility of system architects, and the broader education context that is required for a systems architecting curriculum.
10.13 A Systems Engineering based RAM approach for rail infrastructure: intelligent application in a 25kV Traction Power Supply System
Authors: van Baaren Ron , Lafeber Rob , Sasso Monica
Published: November 2014

One of the leading projects in the Netherlands concerning the integration of reliability, availability and maintainability (RAM) in the development of new rail infrastructure is BB21/25kV TPS. This project is aimed at the design and development of a new generation 25kV Traction Power Supply System. This paper describes how the existing European Standard of the application of RAMS in railway applications has been tailored to the specifics of this project. The application hereof effectively made the 25kV Traction Power Supply System project the first large rail infrastructure project in the Netherlands that integrated RAM into design and development. Generic conclusions on the application of the pragmatic framework in other industries, such as shipbuilding, are also presented.
Enabling the Researcher: Applying Systems Engineering to Research
Authors: Bulca Ferhan
Published: November 2014

Methodologies utilized in research and product development have little in common. While the former thrives on freethinking and innovative creation, the latter is more dependent on a structured process. A culture shift is required from a purely knowledge‐driven academic environment to a commercial research environment that is more sensitive to budget and schedule constraints. In spite of these differences, systems engineering practices may be applied to research, helping the teams to produce favourable results.

This paper presents a case study related to the research phase of a commercial product development project in the biotechnology sector. The challenges in the research phase of the commercial project were handled through standard systems engineering practices, with new interpretations of established methodologies. Application of systems engineering practices significantly improved the rate of progress, produced a high level of stakeholder satisfaction and improved confidence in the results, thus indicating that systems engineering methodologies have a valid place in the research realm.
1.1.2 Enabling the Researcher: Applying Systems Engineering to Research
Authors: Bulca Ferhan
Published: November 2014

Methodologies utilized in research and product development have little in common. While the former thrives on freethinking and innovative creation, the latter is more dependent on a structured process. A culture shift is required from a purely knowledge‐driven academic environment to a commercial research environment that is more sensitive to budget and schedule constraints. In spite of these differences, systems engineering practices may be applied to research, helping the teams to produce favourable results.

This paper presents a case study related to the research phase of a commercial product development project in the biotechnology sector. The challenges in the research phase of the commercial project were handled through standard systems engineering practices, with new interpretations of established methodologies. Application of systems engineering practices significantly improved the rate of progress, produced a high level of stakeholder satisfaction and improved confidence in the results, thus indicating that systems engineering methodologies have a valid place in the research realm.
1.1.4 Structuring a Professional Systems Engineering Development Program
Authors: Sheard Sarah A. , Swayhoover Matthew T.
Published: November 2014

This paper proposes an approach to growing the number of knowledgeable, experienced, capable senior systems engineers within an organization. The organization identifies candidates and ranks them against organization‐specific Systems Engineering Quality Characteristics (SEQCs). Development plans for a cohort of selected participants are created based on the students' current and anticipated future roles in the organization. Feedback loops help guide the process, both for individual participants and for the systems engineering development program. The hope is to feed the increasing need for systems engineers and leaders to fill critical jobs on complex programs.
1.2.4 Towards Network Enabled Capability delivery through UK MOD Smart Acquisition
Authors: Kemp Duncan , Payne Gary
Published: November 2014

This paper defines the approach the UK Ministry of Defence took to determine the changes needed to its Smart Acquisition approach in order to enable the delivery of Network Enabled Capability (NEC). It describes the background to both Smart Acquisition and NEC, the benefits led and evidence based approach used to define the way forward, the use of causal link analysis, fuzzy cognitive mapping and system archetypes to understand the issues that needed resolving and finally it describes the changes that are being made.
1.3.2 A Generic, Adaptive Systems Engineering Information Model
Authors: Simpson Joseph J. , Miller Ann , Grasman Scott , Dagli Cihan
Published: November 2014

Systems engineering tasks generate large volumes of data and information that must be available over the lifecycle of the system. This paper outlines an information model designed to support existing systems engineering methods and practices as well newly developed techniques. Specific methods and models used for the capture, encoding and persistence of systems engineering information and design artifacts were given special attention during the evaluation, analysis and model design phases. A generic systems engineering meta‐model was then developed and used as a basis for the systems engineering information model that was developed and is presented in this work.
1.3.4 Object‐Oriented Development For DoDAF System of Systems
Authors: Stanilka Stanley P. , Dagli Cihan H. , Miller Ann
Published: November 2014

The Department of Defense Architecture Framework (DoDAF) provides architectural artifact examples for modeling complex system of systems within the information‐centric and hardware‐centric global battlespace theater. This framework is utilized by all U.S. government agencies and military branches that procure military hardware and plan for tomorrow's strategic evolution in the armed forces. This framework must be adopted by those business organizations who wish to market their products to the U.S. military. The models mandated by the DoDAF do not always align with the software development methods and production processes utilized in the commercial enterprises who position their products for acquisition into the network centric military markets. This is especially true for software industries where object oriented analysis and design methods have become entrenched as an industry standard. This paper analyzes object oriented development of complex systems and compares the artifacts produced through this method with artifacts produced through the structured architecture techniques described by the DoDAF. The comparison provides an evaluation of the commonality and gaps between both ideologies.
1.4.4 Towards a Collaborative Engineering Environment to Support Capability Engineering
Authors: Robbins Wayne , Lam Sylvia , Lalancette Claire
Published: November 2014

This paper presents the challenges and lessons learned during the realization of a prototype collaborative engineering environment to support capability engineering under the auspices of an R&D Technical Demonstration Program within the Canadian Department of National Defence. The definition and motivation of capability engineering is discussed, followed by the role, relevance and approach taken towards enabling collaboration within it. The basics of the collaborative environment, both as a system of systems and as it was applied to a departmental use case are highlighted, with specific emphasis on the breadth of issues that arise, including application, technical, organizational, personnel, cultural and process.
2.3.3 Modeling High Level Requirements in UML/SysML
Authors: Hause Matthew , Thom Francis
Published: November 2014

Modeling requirements with the Unified Modeling Language (UML) can be confusing for both first time and experienced systems engineers. Often this is due to inexperience with UML, or a reliance on object‐oriented techniques, where it is necessary to identify objects as the starting point for evaluating a potential system. When modeling requirements, however, this is normally the “pre‐object” stage, where identifying potential objects can mean defining the solution rather than defining the requirements. The techniques described in this paper focus on the UML/SysML diagrams that do not require objects, and are therefore better suited to this early part of the systems engineering lifecycle. In addition to expressing the requirements in a pure form, they help to identify system interaction, potential interfaces and the characteristics of these interfaces, and algorithms and equations. They also provide a means to achieve handover and traceability to subsequent stages of development, when object‐oriented techniques may be more appropriate.
3.1.2 Quantitative Assessment of Expected Space Mission Return in Terms of NASA's Institutional Goals
Authors: Shelton K. , Rodriguez G. , Weisbin C. R. , Elfes A.
Published: November 2014

NASA high‐level goals of Science, Exploration, and Inspiration present challenges to quantitative analysis. A quantitative method of comparison would assist in future mission design and understanding the return from missions in terms of the high‐level goals. In this paper, we propose a method to assign quantitative metrics to model potential return from future missions in NASA's high‐level goals in Science, Exploration, and Inspiration. The method uses the high‐level goals and engineering metrics to build a hierarchical metric tree. We have selected a set of seventeen future missions, which span a multitude of goals, to help define the metrics and provide a test set; human exploration missions have been included but at this stage the data is still limited. We demonstrate herein the results of the model by closely examining three missions from our test set; the integrated return from these missions is equivalent despite the disparate objectives and approaches of the missions themselves. We conclude by discussing future areas of research.
3.2.1 Development of a Sustainable Process for the Generation, Validation, and Application of Human Reliability Assessment within the Engineering Design Lifecycle
Authors: Ng G.A.L. , Siemieniuch C.E. , Sinclair M.A.
Published: November 2014

This paper describes the activities that were undertaken during a twelve‐month study investigating the application of Human Reliability Assessment (HRA) within a major international systems company. It is hoped that this paper might act as a template for other companies wishing to re‐evaluate their HRA processes and in order to develop sustainable processes to manage the generation and application of HRA along the engineering life cycle. The paper deals primarily with describing a process by which the HRA activities can be maintained and developed corporately.

The initial findings of the study were that there was a general lack of confidence in the results of current HRA activities and these activities differed in scope and detail depending on the customers and the platform's historical use of HRA. In order to overcome these differences and to foster best practice, the Capability Maturity Process was developed for HRA activities across the company to be owned, managed and maintained internally.

In addition a framework is suggested for HRA activities undertaken during the product development process. It is envisaged that this framework be tailored to allow the depth and appropriateness of different HRA techniques for different systems. Some common HRA techniques are presented together with a description of how they would fit into such a framework. The timeliness of the HRA activities were also considered, in that they can be applied at different stages of product development (early in the concept to screen out high level risks, down to activities leading up to qualification and certification of the product).
3.3.3 How to Routinely Assure Project Success
Authors: Malotaux Niels
Published: November 2014

Evo, short for Evolutionary Project Management Methods, is rapidly and frequently applying the Plan‐Do‐Check‐Act cycle, not just for the development of the project‐result, but also for the project organization and even on the methods used. We organize the work in weekly Task‐cycles. Task‐cycles feed bi‐weekly Delivery‐cycles by which we optimize the requirements and check our assumptions. We use TimeLine to create and maintain the total project scope and to connect the Project Result, through the Deliveries, to the work organized in Tasks. Evo combines Planning, Requirements Management, and Risk Management into Result Management, with a fanatical view on ROI. This paper explains the basics of this Evolutionary approach and practical details people can start applying immediately. People who think that this approach costs too much work are proven wrong by those who start applying the Evo methods: Projects coached by the author realized significant better results in significant shorter time.
3.4.3 Engineering a Corporate Memory: Some Practical Insights
Authors: Young Madalein
Published: November 2014

The requirement for a Corporate Memory / Knowledge Management capability originated in the South African Army's Directorate Army Logistics, as well as the Defence Institute as a means to facilitate knowledge sharing and preservation. Both parties stand to benefit from this initiative and the development was thus undertaken as a joint venture. The system engineering process, as tailored for the development of the Knowledge Management system, is presented in the paper. The current status of the development effort is detailed to provide a perspective of where we currently are. The paper further details future initiatives and also shares lessons learnt with the reader.