bluuebunny/crossref_metadata_2025_split huggingface dataset:
Engineering of Computer‐based Systems (ECBS) Three New Methodologies–Three New Paradigms
Authors: Evans Richard P. , Park Sooyong 
Published: November 2014

AbstractThe integration of information technologies dramatically increases the interactions among physical components and processes, generates complex dynamics, and creates component interdependencies unknown in earlier systems. Although development processes for the individual components exist, they remain largely fragmented. Thus, the need for a system‐level discipline and interdisciplinary engineering specialty—engineering of computer‐based systems (ECBSs). The IEEE Computer Society Technical Committee on ECBS provides a focus, in conjunction with the efforts of other organizations such as INCOSE, to promote the ECBS discipline, encourage research in the field, and establish a framework for education and training. This paper includes a description of three new methodologies developed and applied in the engineering of several large‐scale computer‐based systems: System Assessments, and Assessment Control Board (ACB); a Systems Integration (SI) Program; and an Engineering Baseline System (EBS).
PROPOSING A TOOL TO SUPPORT THE PROCESS OF SYSTEM ARCHITECTING
Authors: Chasse John L. , Hyer Scott A. , Parker Thomas A. 
Published: November 2014

AbstractSystems engineering tools are continuously being developed to make arduous tasks easier by reducing cycle times and smoothing transitions from one phase to another. A tool should ultimately free individuals from labor intensive, repetitive, non‐creative tasks and allow them to concentrate their talents on the problem at hand. The process of systems architecting is a task which requires a great deal of creativity. However, it can be dominated by cumbersome tasks involving traceability, documentation, verification, and validation. A system architecting tool could perform, or at least support many of these tasks, allowing the architect to focus on understanding the client's situation and produce an innovative system solution. A system architecting tool could also assist in managing information distributed over multiple platforms. Although existing tools accomplish some portion of these tasks, there are vast capabilities yet to be developed. This paper describes the capabilities required of a system architecting tool. To a tool developer, it describes these capabilities from the architect's (user's) point of view. To potential users, it serves to suggest what could and should be expected from systems engineering tools. This paper also serves to emphasize the aspects of good system architecting practices.
MONITORING THE DEFINITION AND DEVELOPMENT PROCESS OF LARGE SOFTWARE SYSTEMS
Authors: Kaslow David E. , Shupp Jeffrey K. 
Published: November 2014

AbstractIn developing large software systems, systems engineers too often pay more attention to the allocation of the mission functional requirements based on system specifications and less to operator based or design requirements derived from design concepts. However, the success of any large system development lies with the maturation of these design concepts and requirements. Of special importance are the concepts covering requirements key to satisfying the mission objective, or the concepts which span functional components, made up of hardware and software configuration items (CIs) and manual operations, within the system. This paper discusses a criteria which, when applied to a given design concept, identifies the concept as key. Key concepts must be identified early, analyzed thoroughly, and checked for consistency with the requirements that drive them throughout the definition and development process. If the proper level of analysis and design is performed against these concepts, the system will have a minimum number of issues to resolve as it approaches operational status.
CURRENT TRENDS IN REQUIREMENTS AND SPECIFICATION MANAGEMENT
Authors: James Laurence 
Published: November 2014

ABSTRACTOver the last 5 years, Marconi Systems Technology has been involved in developing a state‐of‐the‐art software product for requirements elicitation, traceability and management, able to interface with other best‐of‐breed CASE (Computer Aided Systems Engineering) tools. The product, known as “RTM” (Requirements & Traceability Management) (MST 1996), has achieved critical worldwide acclaim and is currently in use on some of the most advanced systems under development.Through direct contact with many projects, it became clear that the different interest groups present in a company or project (from marketing to project management and systems engineers) had radically different expectations both on how they wanted to use such requirements management support and also what capabilities they as specific interest groups wanted from a requirements management tool.Two common themes appeared to be shared by these interest groups. The first was the need to move away from the realm of primitive ASCII based requirement representations into the much more powerful and comfortable review and editing environments provided by many of today's leading desktop publishing tools. The second was to have the powerful information modeling, traceability, audit trail and impact analysis capabilities of RTM “fused” into their preferred editing environments.This paper describes some of these current trends in requirements & specification management and their implementation in RTM V3.
SYSTEMS ENGINEERING IS MORE THAN JUST A PROCESS
Authors: Harwell Richard 
Published: November 2014

AbstractThe systems engineering process is a roadmap, a pathway to help us achieve our goals. As with systems engineering tools, the process assists ‐but is not a substitute for “getting the job done”. Unlike many processes, systems engineering must have a proper environment to flourish ‐ in fact, it's an inherent element of the application of the process.
AN INTEGRATED PROCEDURE FOR EXPLAINING SOFTWARE REQUIREMENTS
Authors: MacStravic James A. 
Published: November 2014

AbstractAn integrated procedure is presented for the analysis of subsystem requirements and the explanation of software requirements to Software Engineers for implementation. The procedure is supported by the tailored use of a system requirements analysis tool, RDD‐100, used to develop the requirements descriptions, to provide traceability through the levels of analysis, and to support the automated production of System Requirements Specifications and Interface Requirements Specifications. The procedure was applied to a program and achievements are described.
A Simplified Method for Requirements Flowdown and Test Limit Definition
Authors: Acaba Ralph , Bostic Kevin 
Published: November 2014

AbstractA simple yet disciplined method for consistently flowing down requirements was created and implemented on a production radar program at Hughes Aircraft Company. This structured Requirements Flowdown Methodology was supplemented by a similar methodology developed for determining the limits at which the flowed down requirements are tested. These methodologies were created with the objective of producing a system that will better suit the needs of the customer. These customer needs include the need for proper operation of the product as specified for the entire product life under all specified environmental conditions, as well as improved system performance and increased reliability. With the structured definition of test limits as defined in the methodology described herein, a reduction in the number of field failures that cannot be duplicated at repair facilities is also accomplished. This reduces the amount of logistical support necessary to maintain an operational product in the field, minimizing the time necessary to isolate and repair failures, and resulting in increased customer satisfaction.
DESIGNING FOR FAILURE: ANOMALY IDENTIFICATION AND TREATMENT IN SYSTEM REQUIREMENTS ANALYSIS
Authors: Carson Ronald S. 
Published: November 2014

AbstractA method for identifying anomalous (or “what if”) conditions in the system requirements analysis (SRA) is proposed using the concept of functional failure (Spangler 1993, Armstrong 1995). The method complements and extends (Carson 1995) by defining “sufficient” conditions for SRA completeness which complement the previously defined “necessary” conditions for completeness. Identification of the functional failures during the SRA allows the system designer to treat different anomalies rigorously at the beginning of a program as part of the system design. System requirements for “fault tolerance” or “inhibiting fault cascading” are easily incorporated into the resulting SRA as required behaviors (functions) for specific antecedents. The developed process ensures in a verifiable manner that the SRA is complete and there are no incorrect or indeterminate behaviors due to inadequate system design. If applied at all levels of the system development (mission design, system design, subsystem design, end item design) one could expect no surprises during test and integration atanylevel of design.
Heuristic Structuring and Methods Selection in the SEP: An Expert System in M.4
Authors: Clayson Mark H. 
Published: November 2014

AbstractSystems engineering problems, and their analysis and design methods, become increasingly structured during the systems engineering process. The analysis and control function plays a structuring role in the concept phase and at the start of every loop (e.g., requirements, design, validation) in the systems engineering process. Part of analysis and control can be decomposed into a structuring loop which selects or matches methods to be applied. Heuristics are a powerful unstructured method for leveraged structuring in the critical concept phase, and later.The criteria for matching of heuristics and more structured methods to problems is logically described in decision tables. These in turn may be implemented in a knowledge base or expert system. One such operational prototype has been developed in the M.4 rule‐based environment, and is described here. The benefits of such aids may be significant for the systems engineering management and systems architects heavily involved in the analysis and control function. The same approach may be followed using existing taxonomies for specific tool selection.
LESS IS MORE: CAPTURING THE ESSENTIAL DATA NEEDED FOR RAPID SYSTEMS DEVELOPMENT
Authors: DeGregorio Gary L. , Novorita Robert J. 
Published: November 2014

AbstractIn order to improve customer satisfaction and reduce systems development cycle time, engineering organizations must enhance their requirements capture and management capabilities. This means using formally specified and prioritized user requirements to drive technical development and supplying management with the information needed to make and implement decisions.Most system development processes define their inputs and outputs in the form of documents, instead of the essential data consumed or generated. These documents tend to weave together user and system requirements with architecture and design concepts which result in an unstructured set of information. To remedy this situation, an information structure has been developed, that will hold the essential data needed to support system development.This paper describes the motivation, components, and implementation of a requirements and decision management information structure, which includes requirements, decisions, rationale, and other key marketing, management, and engineering information, to support systems engineering improvement efforts.
INTEROPERABILITY OF DISTRIBUTED INFORMATION HANDLING SYSTEMS
Authors: Harmon S. Y. , Hritz L. M. 
Published: November 2014

AbstractDevelopment of distributed computing systems is a complex process made even more difficult by the interactions between algorithms and their execution environments. To improve the development process, nine algorithm characteristics and four execution environment characteristics were identified. These are independent of the specific functions and applications with which they are associated. Dependencies between these characteristics were explored for distributed algorithms and execution environments. Eight algorithm constraints and four environment constraints were derived which must be met to avoid the injection of anomalies into the computed results.
DISTRIBUTED SYSTEM ENGINEERING: IMPLEMENTING SE IN AN INTEGRATED PRODUCT TEAM ENVIRONMENT
Authors: Pittman Bruce 
Published: November 2014

AbstractMany organizations are turning to Integrated Product Development (IPPD) and Integrated Product Teams (IPT's) as a way to improve the speed and cost effectiveness of their system development process. The Secretary of Defense issued a directive on May 10, 1995 directing the use of IPPD and IPT's to the maximum extent practicable. IPPD and IPT's have proven to be an effective tool when implemented properly, but they are no panacea. One of the challenges of IPT's is that the culture of the organization must change and the implementation of the system engineering process must also change. This paper will take the DoD Guide to Integrated Product and Process Development (Version 1.0) and examine the changes that are required in the way that system engineering has been implemented within project organizations on both the government and contractor side. The applicability of this approach to purely commercial projects will also be examined.The concept of Distributed System Engineering (DSE) was developed to describe a new process for implementing SE within an IPPD structured project. DSE includes cultural changes that are required, new ways of developing and managing requirements and tradeoffs, as well the new knowledge and skills that the IPT members will need in order to step up to this challenge. The role of the project manager and the functional managers in project implementation must also change. An implementation strategy for getting started with DSE in a IPPD environment will be described.
Document Centered vs. Design Centered Systems Engineering or Word Processors vs. Systems Engineering Tools
Authors: Sampson Mark E. 
Published: November 2014

AbstractMany systems engineers currently use word processors and spreadsheets to do their job of document generation. This paper discusses another way of generating design documentation as a by‐product of a computed‐aided design capture process. This paper describes the differences between the two approaches to design, provides examples, and shows the advantages of using tools to capture the design and generating documents from the “logic” contained in the design database versus using “word processors for schematic capture”
CREATING LOW‐COST, LOW‐IMPACT METRICS DESIGNED TO FOSTER PROCESS IMPROVEMENT EFFORTS IN THE ENGINEERING ENVIRONMENT
Authors: DiGiovanna Darryl , Redling Thomas , Miller William , Stratton Richard 
Published: November 2014

AbstractAlliedSignal, AT&T, and Lucent Technologies have spent a great deal of time and money to design and implement effective metrics programs. After much trial and error the companies created a set of metrics that are useful and easily collected and analyzed. Along the way, many trial metrics programs were piloted. The following case studies document both the pilot tests that led up to the development of a working metrics program as well as the improved metrics programs that are now in place at both organizations.
“Good is Not Good Enough” Strategies of Implementing Performance Measures in a Mature and Successful Program
Authors: Hines James E. , Antony Patrick R. 
Published: November 2014

AbstractThe present Space Shuttle program is one in transition ‐ both from the government agency and the contractor level. NASA is restructuring the management of the Space Shuttle Program by turning over the reins of the day‐to‐day operations to a prime contractor, United Space Alliance ‐ USA (a joint venture partnership with Rockwell and Lockheed Martin). This move is intended to save millions of dollars in costs by eliminating duplicate resources, streamlining operations, and reducing nonessential program requirements. As a contractor, Rockwell, responsible for Orbiter operations and production as well as systems and payload/cargo integration, is also restructuring. All separate shuttle related contracts have been consolidated into one Shuttle Program. While this consolidation effort is taking place, Rockwell, the NASA, and USA are working closely together to provide the American public a Space Shuttle Program that continues to be technically viable, safe, and now more cost effective.Central to the paradigm shift of organizational consolidation is the way people think and do their work and the importance of setting key performance measures for success. This paper deals specifically with the methodology and implementation procedures Rockwell applied in utilizing metrics to measure Shuttle product success. Applying metrics on a new program is difficult enough. But incorporating a formal set of performance measurements into a well established, mature program that is in the process of restructuring is doubly difficult.
Using EPIC's Systems Engineering Capability Maturity Model to Support Process Improvement at Texas Instruments Incorporated
Authors: Kuhn Dorothy A. 
Published: November 2014

AbstractThis paper describes the use of EPIC's Systems Engineering Capability Maturity Model (SE‐CMM) within the Systems Group (SG) of Texas Instruments Incorporated. TI's SG has used the SE‐CMM in several ways, some of which have had more utility than others. The utility of each of these uses is discussed in the context of the model's intended use. Additionally, a brief description of the new SE‐CMM Version 1.1 is provided.
ALLIED SIGNAL CAPABILITY MODELS AND ASSESSMENT TOOL
Authors: Booth Thomas C. , Oran William A. 
Published: November 2014

AbstractIn 1995 AlliedSignal Aerospace (ASA) developed a Systems Engineering (SE) Maturity Model which was widely distributed at the Fifth Annual INCOSE Symposium in St. Louis MO. In addition, AlliedSignal has also developed both Program Management (PM) and Integrated Product Delivery and Support (IPDS) maturity assessment tools. The rationale and genesis for the development of these models/tools will be discussed along with a description of a new integrated SE/PM/IPDS capability assessment tool. The tool has been used in assessments performed in 14 sites spread among 4 strategic business units. The rationale for these assessments and some of the preliminary findings will also be discussed. The results of the assessments are being used by each site to develop focused action plans to improve its total IPDS performance.
THE APPLICATION OF ELECTRONIC INFORMATION SHARING IN SUPPORT OF SYSTEMS ENGINEERING PRACTICE
Authors: Allen Charles R. , Young Ralph R. 
Published: November 2014

AbstractThe capability of organizations to share information electronically in support of systems engineering practice is often discussed but seldom applied successfully. PRC has developed a capability which has been effective in sharing technology throughout the Company and which has greatly facilitated reuse. This paper describes PRC's Process Asset Library (PAL) and reports on current efforts to improve navigation to make it even more effective, as well as other plans for the future. An electronic Program Manager's Binder developed by PRC is improving information sharing and facilitating start‐up time of new programs. A PRC project tackling the office of the 21st century is discussed. Preliminary data which indicate a ten‐fold improvement in time to develop an engineering process are shared. It is believed that the results being achieved are quickly taking PRC toward world‐class levels in systems and software engineering.
Requirements Management Working Group: Characteristics of Good Requirements
Authors: Kar Pradip , Bailey Michelle 
Published: November 2014

AbstractThis paper identifies and documents the major characteristics of well defined requirements for both individual requirements and aggregates of requirements such as those found in specifications. Characteristics exhibited by well defined requirements are described. The descriptions are followed by a brief discussion of the characteristics. A few examples of well defined requirements are provided. Some supporting characteristics of requirements are also described. These supporting characteristics are not properties of the requirements themselves but are attributes assigned to individual requirements to assist in managing the requirements through the life cycle. The paper was written and reviewed by members of the requirements working group of the INCOSE.
1 Agency‐level Systems Engineering for “Systems of Systems”
Authors: Carlock Paul G. , Scardina John A. , Decker Steven C. , Fenton Robert E. , Pate Charles W. 
Published: November 2014

Abstract“Systems of systems” differ from single systems in the way in which they are implemented and in how their implementation must be controlled. For this reason, the systems engineering processes necessary to ensure successful implementation of systems of systems differ in several important ways from the systems engineering processes typically applied to individual systems. A successful approach to implementing systems of systems requires a multi‐tiered set of systems engineering processes that builds upon the traditional single‐system approach.
3 Towards a Unified Systems Methodology for Australian Defence Systems‐of‐Systems
Authors: Cook S C , Lawson E , Allison J S 
Published: November 2014

AbstractThis paper endeavours to identify a systems methodology that could prove useful in the creation and operation of military systems‐of‐systems. The paper opens with a review of basic systems thinking and proposes a military systems hierarchy that is useful in characterising military systems on the basis of their behaviour and the relevant disciplines with which each can be tackled. We then examine the systems methodology framework called Total Systems Intervention described by Flood and Jackson (1991) and discuss how this can help select a systems methodology for the range of defence systems identified in the hierarchy. The paper concludes by suggesting how TSI might be tailored to defence needs, in particular, high‐level systems.
1 Industrial Ecology and Systems Engineering – a Perfect Match?
Authors: Asbjornsen Odd A. 
Published: November 2014

ABSTRACTThe greatest threat to the acceptance of industrial ecology is the imprecise nature of the handling the topic in the mass media. Popular slogans pass for scientific proclamations without any foundation in physics or thermodynamics. This paper presents a clear and beneficial role that systems engineering can play in educating the public and politicians to make informed decisions. The marriage of the two disciplines offers an alternative to media manipulation and political agendas in decisions that have long‐term consequences affecting future generations. The same message has relevance to practising Systems Engineers by focusing attention on the long‐term effects of decisions made today under contract or other pressures that lead to sub‐optimal choices.
3 What's the Balanced Scorecard got to do with Systems Engineering?
Authors: Haskins Cecilia 
Published: November 2014

ABSTRACTGood ideas are everywhere and increasingly SE project managers are looking to business practices for techniques to improve the management and delivery of complex systems. One emerging technique should appeal to systems engineers for its holistic approach to evaluating the performance of organisations, namely the Balanced Scorecard. In keeping with the conference theme, “Sharing the Future,” this paper builds on the processes and definitions provided in the INCOSE Systems Engineering Measurement Primer to describe the technique and propose how it may be applied to the management of programs.