bluuebunny/crossref_metadata_2025_split huggingface dataset:
6.3.4 FDA GOOD MANUFACTURING PRACTICES (GMP) FOR MEDICAL DEVICES
Authors: Farrell Gerald N. 
Published: November 2014

AbstractThe objective of the presentation is to discuss the Food and Drug Administration change to the Good Manufacturing Practices (GMP) rules. The proposed changes have a direct relationship to and integration of System Engineering processes and methods. As systems become more complex, procedures must be followed that organize and discipline the structure of development. Design controls must be enacted that increase the safety and effectiveness of medical devices. The FDA is in the process of changing these rules so processes must be defined and followed. It also puts the FDA development and production requirements more in line with ISO 9000. As stated by FDA, ISO 9000 has been incorporated into the new rules, but the new rules go much further.As evidenced by the following, the processes that are being enacted by FDA are not new in structure or content, but emphasize the need for the engineering community to define the development and design processes and follow them. The objective of the presentation is to educate the system engineering community on the regulatory constraints that are being enacted by another government agency, the Food and Drug Administration. It is intended that the participant of the presentation will come away with an understanding that the FDA is enacting rules that directly apply to the system engineering process and disciplines associated with system design and development.
2.1.2 Spacecraft Performance Requirements Tracking and Verification for the Tropical Rainfall Measuring Mission
Authors: Carter Ruth Chiang , Hendershot James E. 
Published: November 2014

AbstractThe Tropical Rainfall Measuring Mission (TRMM) is a joint United States and Japan observatory program that will conduct systematic measurements of tropical rainfall required for major strides in weather and climatic research. The TRMM satellite is scheduled for launch in August 1997 aboard a Japanese H‐II rocket. Although significantly along in the requirements development process, a decision was made in June 1994 to initiate an automated computer‐based requirements tracking and verification system. The automated computer‐based system facilitated the task of insuring all top‐level system requirements were properly addressed in subsystem level documentation and subsequently verified through uniquely identifiable verification activities.The Requirements Tracking System (RTS), a PARADOX for Windows based relational data base tool for managing project requirements, was chosen due to its low cost, flexibility, and favorable use on other Goddard Space Flight Center (GSFC) projects. Considerable time was invested creating the initial data base. The four step process involved electronically importing existing requirements specifications, isolating and classifying each requirement, allocating top‐level requirements to subsystems, and establishing the child‐parent relationship between each requirement. The completed data base helped to identify top‐level requirements without corresponding subsystem requirements (childless parents) and subsystem requirements without corresponding parents (orphans). Each requirement was addressed individually to insure total traceability of TRMM project requirements.In order to insure that each requirement developed for the in‐house designed and built TRMM satellite was addressed by subsystem designers, spacecraft performance requirements verification matrices were developed. At the subsystem level, specific test procedures, analyses, and demonstration/inspection activities were tied to each subsystem requirement. Subsystem level verification activities were then used to assess the design implementation(s) selected for top‐level space segment requirements. The verification matrices will be used during upcoming verification activities to insure compliance with requirements as well as analyze potential implications of non‐compliance or test failure.
1.2.1 AUTOMATED REQUIREMENTS EXTRACTION GENERATES PRODUCTIVITY IMPROVEMENTS
Authors: Black J. Emmett 
Published: November 2014

AbstractExtraction of requirements from customer specifications has long been a tedious, time‐consuming and error‐prone manual effort. This is further compounded by the tendency for requirements to be vague and fuzzy things which are difficult to manage.Automated support may be facilitated by use of a system which places customer specifications into an easily navigated, enriched information resource, and which automatically and consistently extracts candidate requirements and issues from specifications while creating links to the original source documentation. Requirements become tangible objects which can be easily reviewed, adjudicated and managed, thus significantly improving productivity and overall quality in requirements capture.We describe a scenario demonstrating how such a system has been used to provide automation and support to the earliest phases of systems engineering, and provide some measurement of productivity improvement.
1.2.2 COTS INTEGRATION IN SOFTWARE SOLUTIONS A COST MODEL
Authors: Ellis Tim 
Published: November 2014

AbstractIn today's global marketplace, software solutions are not only composed of newly developed code, but may also consist of one or more Commercial Off The Shelf (COTS) software products which provide existing functionality. More and more customers are requiring the use of COTS software products whenever possible.In COTS based solutions, more functionality is bought rather than made. This reduces the software development cost but at the same time increases the amount of integration work. It is extremely difficult to estimate the effort to integrate various COTS products into one seamless solution. Past experience at Loral Federal Systems (LFS) has shown that the traditional method of using Source Lines of Code (SLOC) as an estimation technique in the COTS arena does not yield accurate results. This paper will describe the construction and implementation of a bid cost model which uses Function Point Analysis and the identification of COTS cost drivers to help estimate the COTS integration effort.The model is not a paper model, but an actual database application with a Graphical User Interface (GUI). This effort was supported financially by LFS.
5.2.1 NOT INVENTED HERE: THE MOVEMENT FROM INTERNALLY DEVELOPED TOOLS TO DOORS FOR REQUIREMENTS MANAGEMENT
Authors: Rundlet Nancy , Miller William D. 
Published: November 2014

AbstractAT&T organizations in the nineties are challenging the previously conventional wisdom of using proprietary, internally developed tools for the requirements management of products and services. The Dynamic Object‐Oriented Requirements System (DOORS) is an enabling technology for AT&T to extend the reach of requirements management throughout projects to provide improved systems engineering integration and control. This paper documents templates for value and cost models to compare DOORS to AT&T internally developed tools. DOORS provides a path to gracefully and economically move from uncoupled or loosely coupled internal tools to an integrated environment that binds the information operated on by other functional engineering and non‐engineering disciplines. In the drive to improve competitiveness, AT&T's executive management insists that work performed in organizations add the most value at the least cost to make the corporation's products and services more competitive in quality, capabilities, timeliness, and cost. Internally developed tools have no market test to provide the information of their value and true costs. DOORS is a commercially supported product that meets such a market test.
6.1.2 USE OF PROTOTYPING IN DEVELOPING OPERATIONAL SYSTEMS
Authors: Sary Charisse 
Published: November 2014

AbstractPrototyping has matured from primarily a risk‐mitigation strategy to an approach to iteratively developing operational systems. With the push to develop “faster, better, cheaper” systems, prototyping has emerged as a viable approach to meet these needs. Prototyping can be viewed as an iterative process that includes rapid, research, testbed, and operational stages or can be part of an evolutionary development process. When used properly, prototyping can improve productivity and reduce the cost of rework as the system evolves. Probably the best example of an evolutionary process is the spiral life cycle. This life cycle was conceived as a risk‐reduction approach in response to perceived shortfalls with the waterfall approach to development. This paper describes prototyping experience at Computer Sciences Corporation, mostly gained on the Systems, Engineering, and Analysis Support (SEAS) contract with NASA's Goddard Space Flight Center.
1.3.4 The Systems Challenge Posed by the Desire for Re‐Usability
Authors: Cox John E. 
Published: November 2014

AbstractShortened product cycles, reduced development costs and increased market share are conceptual benefits of system component re‐usability.Applying this approach to certain classes of complex systems without appropriate safeguards incurs substantial risk of system failure. There are steps that can be taken in the initial phase of a program to minimize this risk and predict that performance of the system will be within the customer's window of expectation.This paper describes the types of system where re‐usability can be a problem and discusses the system engineering steps that can be taken to ensure expected benefits from re‐use.
2.3.3 Risk and Opportunity Management and the Project Cycle
Authors: Forsberg Kevin , Mooz Harold 
Published: November 2014

AbstractSystem engineering, as a function, is responsible for oversight of risk and opportunity management of a project. Design engineering is likewise responsible for risk and opportunity management at the Configuration Item level and below. Any complete process model, designed to illustrate engineering responsibilities, must emphasize the risk and opportunity aspects of system engineering management, and must illustrate these important activities in the context of the overall system engineering process. The model presented in this paper meets these objectives.The evolving baseline for the technical aspects of the project cycle can be illustrated during decomposition and definition process in a set of descending steps, and during the integration and verification process in a set of ascending steps. This representation creates a “Vee,” with the evolving baseline represented by the legs, or core, of the “Vee.” Risk and opportunity management activities, which are essential to the process, are shown as supporting activities off the core of the “Vee.”Use of a “Vee” model was introduced in our paper presented at the first NCOSE symposium in Chattanooga in October 1991. The “Vee” model illustrates the end‐to‐end involvement of system engineering in the development process, emphasizes the use of risk reduction and opportunity enhancement techniques, and encourages the implementation of concurrent engineering (including integrated product teams).During the past three years we have gained valuable experience in using this model as the heart of our System Engineering and Project Management training and consulting with major government and commercial clients. As a result of this highly illustrative model we have experienced considerable success in conveying the intricacies of the system engineering process to system engineers, project and program managers, and executives.As noted in our 1991 paper, others have considered a “Vee” project model in the past, but they only considered the core of the “Vee.” The enthusiastic acceptance of our model by many professionals is based on the power of the model in providing visualization of the complete development process. Key features of the model are: 1) Only the activities on the core of the “Vee” are part of the evolving baseline managed under configuration control, 2) project risk and opportunity management activities are off‐core activities external to the current baseline, and 3) time and baseline maturity move to the right, which helps illustrate the impact to the approved baseline caused by users with changing requirements.Enhanced graphics and lessons‐learned examples have been included to provide full understanding of how these concepts are used to drive toward optimum solutions based on value, risk, and opportunity.
5.1.2 DEVELOPMENT AND EVOLUTION OF AN INTEGRATED PRODUCT DEVELOPMENT SYSTEM/CENTER AT THE SPACE AND MISSILE SYSTEMS CENTER
Authors: Rountree Richard C. , Guillen Andrew T. , Lee Evelyn 
Published: November 2014

AbstractAn Integrated Product Development Center (IPDC) was developed at the Air Force Space and Missile System Center (SMC) and achieved Initial Operational Capability (IOC) in June 1994. The IPDC provides a computer‐aided environment to accomplish systems engineering and program management activities characteristic of Integrated Product Development (IPD) implemented within the Air Force. The IPDC serves as the nucleus of an overall IPD System (IPDS), connecting Integrated Product Team (IPT) members internal and external to SMC, and facilitating and encouraging a “paperless”, efficient, and cost‐effective environment. Initial emphasis was on establishing a collaborative work environment and providing acquisition support tools for IPTs. Users of the IPDC expressed general satisfaction with the center, its initial usage in its first three months exceeded 80 percent of its daily availability. The paper addresses the conceptualization of the IPDS/C, the systems engineering process applied to identify its requirements, design, and current and planned user environments.
7.3.1 SUGGESTIONS FOR REQUIREMENTS MODEL ROBUSTNESS
Authors: DeFoe Joseph C. , Sheard Sarah A. 
Published: November 2014

AbstractThe behavior implied by a set of requirements must be modeled to ensure that a system built as specified will meet user needs and expectations. Requirements modeling explores possible operational scenarios to establish which capabilities the system must have to be effective.Requirements modeling can be done either implicitly, in the heads and on the white boards of the team producing the requirements, or explicitly, using any number of formalisms and tools. In either case, specific strategies and ground rules must be employed if the model is to properly explore the operationally necessary, externally observable behaviors of the system.This paper presents a set of such strategies to consider when developing a requirements model. Strategies that lead to a robust model help ensure the final system will be operationally suitable. Examples of systems for which the requirements seem to have been insufficiently modeled are used to illustrate the need for a process that accounts for varied external behaviors, perceived concurrencies, synchronization lags, real world objects, and expresses what the system must do, not how it is do it.
7.3.2 REQUIREMENTS MANAGEMENT AND DATABASES THE F‐22 PROGRAM SOLUTION
Authors: Reed Michael A. 
Published: November 2014

AbstractThe complexity and extreme costs which drive a major system development effort have forced an increasing dependency on joint prime contractor efforts. When this fact is combined with the necessity for a structured requirements development and management process, the need for more efficient and standardized method for managing requirements is evident. This paper proposes a more synergistic alternative to what is normally a disconnected, word processor oriented and subcontractor dependent process.
7.3.3 A SET THEORY MODEL FOR ANOMALY HANDLING IN SYSTEM REQUIREMENTS ANALYSIS
Authors: Carson Ronald S. 
Published: November 2014

AbstractA mathematical model for system requirements analysis (SRA) is developed utilizing elementary set theory. The model provides a means to explicitly treat unwanted or unexpected conditions that may be experienced by the system being analyzed. The SRA model can also be used to derive completeness criteria for the development of system states, as well as the completeness of the SRA itself. The requirement antecedents (the “under what conditions” for each function and performance requirement) are categorized in accordance with their associated consequences. Although generally applicable, the model finds its highest utility in the area of software requirements because of their unique design processes which focus on system states. As such, a relationship with software development “formal methods” is described.
6.2.1 THE IMPACT OF SYSTEMS ENGINEERING ON QUALITY AND SCHEDULE *EMPIRICAL EVIDENCE*
Authors: Frantz W. Forrest 
Published: November 2014

AbstractMost Systems Engineering (SE) organizations have little need to prove their worth. SE disciplines are required to fulfill contractual line items. The worth of SE disciplines was long since proven. But not all companies and organizations are this lucky. In fact, a large company known for its strength in SE may have organizations that don't understand or practice SE disciplines. In these organizations, it can be difficult to “sell” Systems Engineering.This paper defines Systems Engineering and presents empirical evidence of its worth. Three similar projects were run in parallel. Each had varying degrees of SE disciplines implemented ‐from nearly none to high. The two projects using SE were delivered more than twice as fast. The project using the highest level of SE was delivered nearly three times faster and had the highest quality. While conclusions concerning what caused an outcome in any complex project are subjective, this paper compares the projects in detail so that conclusions can be drawn as to what caused cycle time and quality differences.
2.5.1 A NEW SYSTEMS ENGINEERING TAXONOMY
Authors: Shenhar Aaron J. 
Published: November 2014

AbstractAlthough real‐world systems exhibit considerable differences, there is very little distinction in the literature between the system type and the description of its actual system engineering pursuit. We suggest here a new approach to systems engineering. It is based on the premise that the actual process of systems engineering must be adaptive to the real system type. Using this concept, we present a two‐dimensional taxonomy in which systems are classified according to four levels of technological uncertainty, and three levels of system scope. We then describe the differences found in systems engineering styles in various areas, such as system requirements, functional allocation, systems design, system testing, and project organization. Furthermore, we show that adapting the wrong system and management style may cause major difficulties during the process of system creation.
2.5.2 THE NECESSITY OF LOGICAL CONTINUITY
Authors: Grady Jeffrey O. 
Published: November 2014

ABSTRACTThere apparently exists a very strongly held view among many members of NCOSE that requirements analysis is a proper precursor to functional analysis. This view was documented in MIL‐STD‐499B, which failed approval as DoD moved toward commercial standards in manufacturing and management areas, but lives on in draft IEEE P1220 and draft EIA 632.The author tried for several years prior to publication of his book System Requirements Analysis to arrange the elements of the system engineering process using this sequence, such that there existed a condition of logical continuity, without success. SAMSO and BMO system requirements analysis documents, such as SAMSO STD 77‐6, offered an alternative that encouraged logical continuity and that was the basis for the author's book, System Requirements Analysis.This paper makes the case for the necessity for logical continuity in the development of systems to satisfy complex needs, identifies a work sequence that complies, and exposes the discontinuity entailed in the approach encouraged by current standards.The author recognizes that the position expressed in this paper may be separated from the position endorsed in current draft standards only by semantic differences, but attempts to expose such differences have been unsuccessful to date leading to the conclusion that the differences are substantive. Those who hold the view opposed to that expressed in this paper are encouraged to contrast their position and carefully explain how their approach assures logical continuity or declare the lack of any need for it.
3.5.2 SYSTEMS ENGINEERING FLOWDOWN ON THE F‐15 PROGRAM
Authors: Hugge Paul B. 
Published: November 2014

AbstractSystems Engineering defines a disciplined design and verification process for developing systems. Its iterative and balanced approach results in systems that meet all of their intended needs and satisfy all of their intended customers. McDonnell Douglas Aerospace (MDA) is implementing Systems Engineering across the enterprise, including mature systems such as the F‐15 Weapon System.The F‐15 Program has taken Systems Engineering and tailored it to support new development activity. The F‐15 Program expects to improve product reliability and maintainability, develop performance upgrades, and improve the producibility of the F‐15 Weapon System by applying a disciplined Systems Engineering process to selected elements of the system.The F‐15 Program is expanding its Systems Engineering approach as part of its Integrated Product Development organization. This paper describes MDA's Systems Engineering process, the tailored F‐ 15 Program implementation approach, and progress to date.
6.4.3 A Systems Engineering Approach to Optimize Customer Satisfaction on Complex Systems
Authors: Lakey Peter B. 
Published: November 2014

AbstractAt McDonnell Douglas, a creative approach to resolving the issue of flowing down requirements to best meet customer needs has been developed. The approach provides guidance identifying and rank ordering preferred design choices, developing requirements flowdown, and illustrating the sensitivity of performance parameters based on the selection of optimal choices. The methodology determines a Customer Quality Model (CQM) using modified Quality Function Deployment (QFD) assessments[1] in combination with management science techniques for optimization to perform numerical suballocation of system level requirements. The approach provides guidance toward solutions which protect the customer's interests without the need for the customer to dictate design solutions and contractual requirements at these suballocated levels of detail. A computer application of this methodology has been produced by McDonnell Douglas and exists as an EXCEL software tool.
6.5.2 AN ISO 9000 QUALITY SYSTEMS ENHANCES SYSTEMS ENGINEERING
Authors: Wray Richard B. 
Published: November 2014

AbstractNo matter what industry you are in, the question “Are you ISO certified?” is becoming more important. As you read the International Organization for Standardization (ISO) 9000 set of standards, however, you will realize they offer much opportunity for interpretation. The primary thrust of ISO 9000 is quality processes in product development and use of quality systems. The issue often boils down to understanding the system requirements of your industry and company for quality, determining what you do, documenting what you do and doing what you have documented. For systems engineering in the National Council on Systems Engineering (NCOSE), the question is particularly relevant due to this focus of ISO 9000 on quality systems and of NCOSE on the quality systems engineering needed to achieve world class status. The key expertise of systems engineering is technical process understanding for product development. Thus there is a clear relationship between systems engineering and ISO 9000 requirements.This article summarizes some key facets of the ISO 9000 quality system approach and how this affects systems engineering. Then it describes systems engineering, as it is evolving in the NCOSE Systems Engineering Process Working Group (SEPWG), and how it is impacted by ISO 9000. Finally, it draws some conclusions about their relationship and future.