bluuebunny/crossref_metadata_2025_split huggingface dataset:
1.6.2 Formalizing a Structured Natural Language Requirements Specification Notation
Authors: Cooper Kendra , Ito Mabo 
Published: November 2014

AbstractRequirements specification notations are developed by organizations in order to meet their specific needs. For example, the Threads‐Capabilities notation, an in house notation at Raytheon Systems Canada, Ltd., has been developed and used for specifying their complex, large scale, air traffic control systems. It is a semi‐formal, structured, natural language notation. In this work, we investigate how to make this semi‐formal notation more rigorous (i.e., formal) by developing and applying a new formalization process to it. By doing this, we can obtain the advantages of formal methods (precise, unambiguous, automatic generation of test specifications, automated typechecking, etc.) while retaining the style and readability of the original notation. We call the formalized notation the Stimulus Response Requirements Specification (SRRS) notation. Our results have been successful for the specific notation. The formalized notation has been demonstrated to reduce the time and improve the quality of the requirements specifications. There is additional training time, however, needed to learn to use the notation and tools.
1.6.4 IT3‐Integrated Technology Training Template
Authors: Kwinn Mike , Balough Second Lieutenant Eric , Beach Jason , Nogic Dominik , Rains Matt , Williams Stuart 
Published: November 2014

AbstractDue to an influx of new equipment into the military, the US Army and Project Manager (PM) Soldier have identified the need for a template which can be used to identify what type of training is best utilized for specific functions of the equipment used by soldiers, in order to begin training development earlier in the Army Acquisition Cycle. Using a complete functional decomposition of required tasks in the Army, we used the Multi Attribute Utility Theory (MAUT) to match training requirement tasks with the most appropriate training type taking into account objectives such as cost, time and training. The result is a comprehensive list of training requirements and their associated types of training as well as a Version 1.0 template that was used to make these connections. The use of this functional training template will allow PM's to start planning for training of the new equipment that they are producing much earlier in the development process. This reduction in training development lag time will decrease fielding time and increase the speed at which units are able to integrate new equipment and types of training.
2.6.1 Model Driven Design with Matlab
Authors: Reitz Elliott 
Published: November 2014

AbstractThe technical challenge of recognizing pertinent information on images of mail‐pieces (such as indicia) has encouraged the integration of multiple technologies into a complex modelling environment. The modelling environment was developed to build and select the appropriate algorithms and subsystem component designs. A C/C++ library has been developed for components of the system model that are selected for product application. Prototyping has been extensively used in all of the environments. Example products developed with this approach that have been delivered to customers include: a classifier algorithm for character recognition (USPS RIP2), a Pre‐sort‐Label detection device (USPS APPS CFT), and a Non‐Address‐Attribute‐System for recognition of indicia (UK Royal Mail Address Interpretation). The results have exceeded expectations for schedule, performance, and development costs.
2.6.3 From function‐driven Systems Engineering to object oriented Software Engineering
Authors: Hoffmann Hans‐Peter 
Published: November 2014

AbstractThis paper describes a model‐based system and software development process that combines both function‐driven systems engineering and object oriented software engineering. The key part of this “Integrated Process” is the “Bridge” between the two paradigms. Tools chosen to demonstrate the Integrated Process are the I‐Logix tools Statemate® Magnum, for the function‐driven systems engineering, and Rhapsody® in C++ for UML‐based software engineering. Rules can be established on how an architectural design model built with Statemate will be translated to a UML model for further software design and implementation with Rhapsody. The outlined mapping is not limited to Rhapsody. Rather, the Statemate‐to‐UML Bridge is equally applicable to any UML‐based software design automation tool.Initially conceived for the design and development of highly complex embedded systems in aerospace/defense applications, the process is also applicable to other industrial applications.
3.6.3 Where Does Software Engineering Begin During Systems Engineering?
Authors: Lee Carol Sue 
Published: November 2014

AbstractWithin systems engineering and systems development, it is typical to bring in the software engineers after the system has been designed. Because their involvement usually begins with the Software Requirements Specifications (SRS), software engineers must spend time in gaining an understanding of the overall system design and the product they must build according to the SRS. In addition, software engineers may discover that the system design has not accounted for some of the necessary components or subsystems, which would require that the system design be changed. This paper enforces the need to bring in the software engineers as full members of the team as early as possible. This does not mean that the software engineers would begin coding. Rather, the software engineers would bring to the table their knowledge of modularization, configuration, binding, and execution. If applied correctly, this involvement could make a significant difference in the costs of the product as well as the product's quality. By including the software engineers early in the systems engineering process, there would be no question of where to begin; they would have already started. In other words, when systems engineering begins, so should software engineering.
3.6.5 Architecting Systems for Human Space Flight
Authors: Wocken Gerald 
Published: November 2014

AbstractHuman‐system interactions have been largely overlooked in the traditional systems engineering process. Awareness of human factors (HF) has increased in the past few years, but the involvement of HF specialists is still often too little and too late. In systems involving long‐duration human space flight, it is essential that the human component be properly considered in the initial architectural definition phase, as well as throughout the system design process. HF analysis must include not only the strengths and limitations of humans in general, but the variability between individuals and within an individual over time, and the dynamics of group interactions
5.6.3 Lessons Learned Applying Tools and Methodologies to Develop C4ISR Architecture Framework Compliant Architecture Products
Authors: Rice David , Meilich Abraham 
Published: November 2014

AbstractWith the advent of the Clinger‐Cohen Act of 1996 mandate to develop an enterprise information technology architecture, there has been a more intensive focus by all federal government agencies, and more specifically the DoD, on defining their instantiation of an Enterprise Architecture Framework. The Federal Enterprise Architecture Framework (FEAF) was the first attempt to document the ground rules for various government agencies to develop their own architectures to be compliant with the intent of Clinger‐Cohen. The DoD has adopted the FEAF and tailored it into the C4ISR Architecture Framework (AF). The C4ISR AF Products are robust in terms of capturing the architecture, but are problematic when they need to be rigorously modeled on the path to producing a system that is compliant with that architecture. The recommended documentation of the artifacts from this architecture is not consistent across all the products from a system or software “methodology representation” standpoint. Since the introduction of the C4ISR AF, agencies and contractors have grappled with capturing these products (which represent different views of the architecture) in a common repository for verification of completeness, consistency across views, and accuracy of information represented in these views. This is a non‐trivial challenge for the U.S. Army Digitization effort that integrates existing Army C4ISR systems and designs for interoperability. Lockheed Martin Mission Systems is providing systems engineering and integration expertise in modernizing the U.S. Army Battle Command Systems (11 “stovepipe” systems) under the ongoing Systems of Systems Engineering and Integration contract. The capture of this complex architecture is being facilitated through the use of a repository‐based tool ‐ System Architect 2001 (SA 2001) by Popkin Software. This paper highlights the challenges, lessons learned, and solutions which have come out of this effort to capture and model the C4ISR AF artifacts in a manner that is useful to systems engineers and system architects. The proper utilization of these artifacts will enable the users and customers of this systems to have a system design that meets their needs and can be successfully integrated as the Army matures to a field‐able, totally integrated battle command and control system of systems.
5.6.4 Application of the C4ISR Architecture Framework: What Does It Really Mean?
Authors: Hyer Scott A. , Engler James F. 
Published: November 2014

AbstractIn 1997 the Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR) Architecture Framework Version 2.0 was released as a guide for the U.S. Department of Defense (DoD) in the development of system architectures. This Framework was developed under the auspices of the C4ISR Working Group consisting of representatives from the Joint Staff, the military services, the Office of the Secretary of Defense, and other Defense agencies. The main motivation for the C4ISR Framework has been to ensure that architectures are interrelatable as well as comparable and integratable across Joint and multinational organizational boundaries. DoD, supported by recent government legislation, will pursue the development of more interoperable, integrated systems to meet the challenges posed now and in the future. Developed to focus on information technology, the C4ISR Framework is finding broad application in the DoD community. The C4ISR Framework serves as a consistent guideline on how architectures should be described by calling out a number of views serving operational, system, and technical interests. The need for consistency and guidance is clear. What is not clear however, is how this guidance will influence engineering activities being conducted on DoD programs. Application of the C4ISR Framework is very much in the pioneering stage. Experience is needed to set examples and teach lessons as with anything new. This paper offers some experience by developing an operational architecture view in an application to Air Defense.
2.1.1 Using a Knowledge Management Tool to Improve U.S. EPA's Enterprise Architecture
Authors: McMahon Ethan , Sullivan John 
Published: November 2014

AbstractEnterprise architecture (EA) is a process for ensuring that an organization's information resources are aligned with its goals and business. EA can be used for several purposes, such as improving business processes that are performed across an organization and integrating information management resources. For EA to achieve its potential, it is important to use an EA tool for housing and analyzing the organization's information. The U.S. Environmental Protection Agency (EPA) is using such a knowledge management tool, called the Architecture Repository and Tool (ART), that is based on Metis software from Computas. ART can be used to identify which organizations perform the same business processes and to highlight opportunities for storing commonly used data. This paper illustrates how ART is a knowledge management tool that can reveal an organization's gaps, weaknesses, and opportunities for improvement.
2.1.2 Application of the Systems Engineering Approach to the Tritium Extraction Facility Design
Authors: Simpkins Philip 
Published: November 2014

AbstractThe Commercial Light Water Reactor ‐ Tritium Extraction Facility is being designed and built as a tritium processing facility at the Savannah River Site (SRS) in South Carolina. When built it will be the only facility processing tritium in the United States. The design of this facility required some equipment to be designed as ‘one of a kind‘. The Systems Engineering (SE) approach was applied to define the functions and requirements necessary to design and operate the facility. The SE approach for the Tritium Extraction Facility (TEF) was a major effort encompassing Requirements Analysis, Risk Management, Interface Control, and supporting plans and documentation for the facility and 23 major systems. This paper will describe the SE approach in general and give examples of selected Functions and Requirements (F&Rs) supporting the TEF design. Also presented will be advantages of using the SE approach on the design of the TEF and observations made during the design process.
4.2.4 Organizational Implications of “Real‐Time Concurrent Engineering“: Near Term Challenges and Long Term Solutions
Authors: Stagney David B. 
Published: November 2014

AbstractIn late 2001, a product development team was assembled at a major aerospace corporation to create an innovative product design process based on the concepts of Integrated Concurrent Engineering (ICE).R&D funding for the “Real‐Time Concurrent Engineering” (or “RTCE“) project ended in late July of 2002 even though the tools and processes that had been developed were providing a great deal of value to the company. In response, the team leadership struggled to craft a new vision for their project and to understand some of the unexpected barriers they had encountered within their own company.This paper discusses the organizational challenges that the pioneering RTCE team faced. The issues are categorized into four major groups: Organizational Structure, Organizational Culture, Leadership and Finance. Strategies for near term re‐vitalization and long term value‐creation are proposed in the context of a new project implementation model.
5.2.3 Breaking the 5‐Sigma Barrier with Systems Engineering
Authors: Gianacakes George 
Published: November 2014

AbstractMany organizations have successfully implemented Six Sigma (6σ) quality programs, but have begun to hit what they call the 5‐sigma barrier — they have discovered that you can only get so much quality improvement from the back end of the development process. To overcome this 5‐sigma barrier, organizations are increasingly adopting the Design for Six Sigma (DFSS) methodology that in many ways reflects the “systematics” of product development. This paper examines the Six Sigma and DFSS approach and how DFSS in essence is a “Statistical Systems Engineering” approach that can achieve six‐sigma levels and beyond in product development.
6.2.1 The Ten Most Powerful Principles for Quality in Systems Engineering and Software
Authors: Gilb Tom 
Published: November 2014

AbstractWe know we need better engineering control. But which solutions work? What are the most fundamental underlying principles we can observe in successful projects? This paper presents 10 powerful principles, that are neither widely taught, nor appreciated. They are based on ideas of measurement, quantification and feedback. Our maturity level with respect to ‘numbers’ is poor. Within projects, many of our most critical measures are often not quantified, when they should be. Hopefully, as we move to higher maturity levels we will begin to appreciate the power of numeric expression for qualities such as security, portability, adaptability, maintainability, robustness, usability, and reliability. Decide to make them numeric on your project. Draft some more‐numeric requirements today, surprise your team tomorrow!
3.3.1 Systems Engineering With Solution Spaces
Authors: Hause Matthew , Thom Francis 
Published: November 2014

AbstractWhen creating UML models of systems, a common strategy is to model all the elements as classes. This technique is inadequate, because eventually the element has to represent something in a given solution space. Instead, the system should be modeled using a library of Systems Engineering concepts that can be applied to the problem. In this paper, we propose using Systems Engineering profiles, patterns, concepts and standards, corresponding to solution spaces to model the system and support both the product and the process. These can be used throughout the system lifecycle, from modelling the concepts and physical environment in the requirements stage, to creating physical systems from the model during the implementation stage. This library, or ontology, could be built up over time to create a Systems Engineering Body of Knowledge (SEBOK), allowing reuse of requirements, concepts, and problem‐solving techniques.
4.3.1 Formalizing Informal Stakeholder Requirements Inputs
Authors: Kitapci Hasan , Boehm Barry W. , Grünbacher Paul , Halling Michael , Biffl Stefan 
Published: November 2014

AbstractOften, the stakeholders who can contribute the most value and realism to system requirements are the ones with the least time available to participate in the process. We have found the EasyWinWin requirement negotiation method and tools to be an effective way to involve such busy stakeholders. It avoids time‐consuming group wordsmithing, but results in relatively informal win‐win agreements (e.g., “24/7” or “anytime, anywhere” vs. more precise availability and accessibility requirements). For the past three years, we have been using EasyWinWin to capture informal requirements from stakeholders in an annual series of 15‐20 University of Southern California (USC) electronic services projects. In the context of these projects, we have been exploring alternative methods for formalizing these informal requirements inputs, including natural language processing, keyword analysis, template‐based refinement, formal methods expertise, and inspections. The paper summarizes our analysis of the relative strengths and difficulties of using these methods and our approach during the USC e‐services applications projects.
5.3.1 Training Systems Engineers for System Acquisition
Authors: Fisher Jack , Humel Paul F. , Fisher Gerard H. 
Published: November 2014

AbstractAn experiential systems engineering training program developed for a customer of the California Institute of Technology Industrial Relations Center (IRC) was described in a previous paper (Fisher 2001). This program was modified under the sponsorship of the IRC and the Aerospace Corporation's training organization, the Aerospace Institute, to provide systems engineering training for Air Force personnel from the Space and Missile Systems Command.The course now includes eight full‐day class meetings over a period of 14 weeks with an instructor‐defined class‐long exercise requiring the design of a satellite system. Two courses were conducted in parallel, offset by one week. Each class of 24 students was divided into two teams. The exercise requires each team to develop a system with a number of pre‐defined steps that are described by the instructor tutorials. The exercise originates with an instructor‐prepared system requirements document and culminates with a student‐prepared Preliminary Design Review, life cycle cost estimate and risk management plan. The tutorial material prepares the students for each step in the system development process. Each 8‐hour class meeting involves a tutorial by the faculty as well as student team reports describing their progress with the exercise.Modifications to the earlier program include the addition of a class meeting utilizing the facilities of the Aerospace Concept Design Center (CDC). The CDC provides the capability to derive space system characteristics with computer‐based mathematical models. This allows the students to conduct tradeoff analyses to select a system design concept from the possible alternatives.
6.3.2 Deployment of SE including Manufacturing Systems development: Practical Aspects
Authors: Lardeur Etienne , Auzet Christian 
Published: November 2014

AbstractNowadays, the improvement of engineering efficiency is presently one of the most important issues in the field of industry. Engineering coordination through information control is often taken as means to solve this issue. PSA Peugeot Citroën has decided to explore this approach, and has consequently decided to deploy Systems Engineering. SE provides an adequate and structured approach for the development of the new vehicles. Because of its industrial background, the SE Framework of an automotive company must take into account the development of the vehicles and the related manufacturing systems. This study is the answer ‐ on practical aspects ‐ to the following problematic: how may optimal co‐ordination of the engineering of a complex and mass product and its associated manufacturing systems can be concretely be achieved? This paper presents the practical aspects of a Ph.D. study, while another submitted and accepted paper presents the theoretical aspects of the same study.
3.4.1 Traceability: A Systems Integration Perspective
Authors: Mason Paul , Arkley Paul , Riddle Steve , Saeed Amer 
Published: November 2014

AbstractIt has been argued previously that system integration requires a controlled environment, which in turn demands a number of integration and management undertakings (Sage & Lynch, 1998). This paper considers one such undertaking, information integration and management, and in particular, means of managing and tracking information across disjoint CASE tools.A taxonomy is proposed that defines a conceptual framework for traceability in a systems integration context. The framework is realised by exporting information from the internal models of tools to an integrated environment consisting of: i) a Workspace comprising a set of structures or meta‐models expressed in a common modelling language representing selected notations for which tool support exists; ii) well‐formedness constraints over these structures capturing properties of the notations; and iii) associations between the structures. To maintain consistency, the structures are verified against a further structure that defines common building blocks underlying the various notations.