bluuebunny/crossref_metadata_2025_split huggingface dataset:
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

AbstractA 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

AbstractIn 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

AbstractMany 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

AbstractThis 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

AbstractAs 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

AbstractThis 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

AbstractThe 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

AbstractOne 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

AbstractMethodologies 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

AbstractMethodologies 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

AbstractThis 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

AbstractThis 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

AbstractSystems 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

AbstractThe 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

AbstractThis 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

AbstractModeling 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

AbstractNASA 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

AbstractThis 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

AbstractEvo, 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

AbstractThe 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.
4.2.2 Family‐of‐Systems Architecture Analysis Technologies
Authors: Jain Prem , Dickerson Charles 
Published: November 2014

AbstractThe United States Department of Defense (DOD) transformation initiatives have the potential to significantly improve operational effectiveness and efficiencies by having the right information at the right time at the right place to make critical time‐sensitive warfare decisions. Realizing these operational benefits requires interoperability among complex families of systems. New computer‐aided analysis technologies, methods, tools and simulation environments are needed to enhance understanding of the complex behavioral relationships among thousands of entities to 1) support DOD acquisition decisions to evaluate alternative Capability‐Based‐Acquisitions (CBA) 2) evaluate relative merits of multiple concepts of operations feasible in complex scenarios. This paper describes a set of executable model abstractions and a set of analysis technologies needed to build Family‐of‐Systems architecture analysis tools and the simulation environment. It proposes a CBA system engineering process linking the tools supporting these abstractions, analysis technologies and artifacts captured according to DOD Architecture Framework (DoDAF) standard.
4.4.1 A Hybrid Requirements Capture Process
Authors: Daniels Jesse , Botta Rick , Bahill Terry 
Published: November 2014

AbstractSystems engineers traditionally produce a system requirements specification containing shall‐statement requirements. However, the rapid adoption of use case modeling for capturing functional requirements in the software community has caused systems engineers to examine the utility of use case models for capturing system‐level functional requirements. A transition from traditional shall‐statement requirements to use case modeling has raised some issues and questions. This paper advocates a unified requirements engineering method in which use case modeling and traditional shall‐statement requirements are applied together to effectively express both functional and non‐functional requirements for complex, hierarchical systems. This paper also presents a practical method for extracting requirements from the use case text to produce a robust requirements specification.
4.4.2 Quantifying the Evolution of Goals in Requirements Engineering: A Study on the Quality Assurance Review Assistant Tool
Authors: Chowdhury Tropa , Chung Lawrence , Cooper Kendra 
Published: November 2014

AbstractGoal‐oriented requirements engineering is becoming increasingly important, as goals help to specify requirements, provide rationales to stakeholders, and detect causes behind requirements conflicts. Measuring and understanding the manner whereby goals are understood and modeled over time can have a vital implication to many aspects of software development. Despite the importance, however, there seems to be little help available in measuring the evolution of goals. This paper presents a scheme for quantifying the evolution of goals in requirements engineering. This paper also presents a case study for this scheme using a groupware application, called the Quality Assurance Review Assistant Tool (QARAT). The data collected are analyzed in relation to several conjectures regarding the structural evolution of the goals over 11 iterations. Ultimately, studies such as these can be used to help improve cost estimation, project planning, and risk analysis activities.