bluuebunny/crossref_metadata_2025_split huggingface dataset:
2.3.3 Measurement For Small Projects
Authors: Baxter Donald F. 
Published: November 2014

AbstractAfter several years of leading successful systems projects, you are now tasked to assemble a small team to address a design problem with a component of the major weapon system developed by your company and to report your findings and recommendations in two months. This is a classic assignment for a small project … limited duration, small group, and specific task. While you might think this is an opportunity to fall under the radar of the corporate reporting and measurement program, you're missing out if you don't take advantage of the unique opportunity to experience and explore the possibilities available to you through working on a small project and the opportunities for understanding measurement in ways that just aren't possible on larger programs. This paper explores the world of measurement in small projects.
2.3.4 Experience with Extending CMMISM for Safety Related Applications
Authors: Bofinger Mark , Robinson Neil , Lindsay Peter , Spiers Mick , Ashford Matt , Pitman Adrian 
Published: November 2014

Abstract+SAFE, a safety extension to the Capability Maturity Model ‐ Integrated (CMMI) has been developed and trialed in Australia, for use in assessing suppliers of safety‐related systems. This paper describes the latest version of the safety extension and also reports on the results of seven trials.
3.3.4 Requirements Variability Management
Authors: Jorgensen Raymond W. 
Published: November 2014

AbstractWhen a project is “reused” from an initial project to subsequent reapplications of the original project, the question of management of the intellectual property between projects becomes a significant maintenance issue. When intellectual property is copied from one project space and pasted into the next project space, the intellectual property (IP) between the two projects is no longer directly shared (it's rather salvaged), and the IP between the two projects will tend to diverge. Enhancements or variations that are introduced into that IP will not be managed as a product family, but rather be managed as project specific IP. Any global updates needed across all projects then become difficult and costly to understand and apply. One change must be re‐created in each project sharing the same product definition. True sharing or reuse of IP between the projects becomes difficult.To truly share IP between two or more projects, the IP material must come from the same source (not different copies). Sharing IP between projects encourages a product family approach to engineering. The fear, though, of shared IP is a perception that the project will no longer be able to preserve their project's unique definition or unique needs. They are “different from the original project”, thus they must maintain their own IP. And sharing other project data with their unique customer bias is out of the question.
4.3.5 A Question of Context – Why Manufacturing Cultures Don't Understand Systems Engineering
Authors: Iliff Randall C. 
Published: November 2014

AbstractEffective management of Systems Engineering requires expertise not only within the discipline, but expertise in explaining the discipline as well. This is particularly critical in the commercial sector, whose management is overwhelmingly rooted in manufacturing process and culture. Manufacturing is an important and essential skill set, but it is fundamentally different than the creative process of Systems Engineering. Bridging the communication gap is essential to establishing even an opportunity to perform effective Systems Engineering. This paper equips the reader with a clear understanding of the challenge, and the insight needed to become an informed and effective Systems Engineering advocate.
1.4.1 Application of Systems Engineering Principles In The Creation of a New Master of Science In Systems Engineering Degree Program
Authors: Harwell Richard M. 
Published: November 2014

AbstractA university accepts the challenge to create a new Master of Science curriculum needed by industry. Industry declares a major shortfall in knowledgeable systems engineers and an inability to knowingly identify the capabilities of those practitioners that are available. Add to that mixture, a professional base that is still debating how to define itself and the boundaries that govern its practice. These are just some of the elements faced by Southern Polytechnic State University and Lockheed Martin Aeronautics Company (both based in Marietta, Georgia) in developing a joint Certificate Program and a Master of Science in Systems Engineering Degree Program. And these concerns do not take into account other issues that every new curriculum faces.
1.4.4 Combined Research and Curriculum Development in Information‐Centric Systems Engineering
Authors: Austin Mark A. , Baras John S. , Kositsyna Natalya I. 
Published: November 2014

AbstractThis paper describes a multidisciplinary program of research and curriculum development in Information‐Centric Systems Engineering currently underway at the Institute for Systems Research, University of Maryland, College Park. This work is supported by a significant grant from the National Science Foundation and industrial funds from US industry. After motivating the need for an information‐centric approach to systems engineering education, this paper describes the research methodology, pathway from research to curriculum development and teaching, and architecture for web‐based project deliverables.
2.4.2 New Approach to Generic Attributes
Authors: Wells Curt , Ibrahim Linda , LaBruyere Larry 
Published: November 2014

AbstractGeneric Attributes (GAs) are measures of process performance introduced by the systems engineering capability model, EIA/IS 731. The systems model defines two GAs – Effectiveness and Value. While the concept of GAs is generally accepted as valid, they have been used very little, due to difficulties in interpretation and appraisal.Revised definitions and a new approach for appraising and using GAs have been developed for the Federal Aviation Administration Integrated Capability Maturity Model® v2.0 (FAA‐iCMM®). The improved approach to Generic Attributes provides the needed clarity and measurement objectivity. Definitions of the iCMM GAs and their relationship to process model concepts are described, along with a practical approach to appraising GAs.
2.4.3 Verification “Auditability” can be “Free”
Authors: Jones James H. 
Published: November 2014

AbstractWhen simple audit support standards are applied to developing project requirements verification documentation in the current new product development environment, several benefits accrue. Data then made available from the verification documentation supports technical test reviews and an effective project status metric, as well as rigorously proving that verification is complete for specified requirements. Essential to verify requirements for systems affecting human safety, audit support standards enabled rigor could be useful during planning and testing to assure quality under ISO 9001 parameters claimed as met by many companies. When methods described in this paper virtually automate the resulting auditability, it essentially becomes “free“.
3.4.5 Were the Ancient Egyptians System Engineers?
Authors: Jacobs Vladimir 
Published: November 2014

AbstractSystems engineering is a 20th century discipline. To judge whether an organization is on a world class systems engineering level, we evaluate whether the organization's development processes and resulting product satisfy the 8 systems engineering axioms. Could we evaluate ancient organizations? The pyramids on the Giza Plateau are the only remaining wonders of the ancient world. The sheer scale and precision of Kufu's great pyramid obviously required a quality process. But were the ancient Egyptians systems engineers? This paper will outline how the pyramids were built, and whether that process satisfied the systems engineering Axioms.
4.4.3 It's the people that matter – applying a Systems Engineering approach to process improvement
Authors: Carver Elizabeth , Kemp Duncan 
Published: November 2014

AbstractThis paper describes approaches taken within the UK Warship Support Agency (WSA) and BAE SYSTEMS to implement improved Systems Engineering processes throughout complex supply chains. The supply chains needed to develop and support complex products, such as large aircraft or warships, require large teams to collaborate across organisational and cultural boundaries.To be successful the extended enterprise needs business processes which are honed to drive down life cycle costs and which manage the key emergent capabilities such as safety, availability, flexibility, and reliability. Such business processes are heavily dependant upon the people in the system and those people represent a complex web of interdependant factors. Improving these processes, which are almost exclusively goal and knowledge based, therefore requires significant understanding of how to integrate diverse teams and cultures.This paper describes the techniques used within the WSA's Enterprise Integration and Shared Data Environment Team and BAE SYSTEMS Advanced Technology Centre in understanding and improving complex goal and knowledge based processes. It describes how the teams analyse improvement requirements, and how they implement change in such a difficult, but critical, area.
5.4.4 Optimizing Distributed Software Architectures for Ground Based Weapon Systems
Authors: LaCerte Yves 
Published: November 2014

AbstractModern ground based weapon systems depend heavily upon electronics and software for correct and safe operations. Many of these ground based weapon systems exhibit behaviors from very different domains: automobiles (e.g. engines and transmissions), aircraft avionics systems (e.g. sophisticated sensors and advanced situational awareness), and hard real‐time industrial controls (e.g. weapon loading equipment).This paper describes the fundamental approach to Crusader's software architecture and through specific examples, demonstrates that the Crusader software architecture is highly adaptable, provides a firm technical foundation for evolutionary growth, and is capable of supporting a family of ground based weapon systems.
6.4.1 A Case Study of the Near‐Catastrophic Mir‐Progress 234 Collision with Emphasis on the Human Factors/Systems‐Level Issues Surrounding this Mishap
Authors: Holland Dwight 
Published: November 2014

AbstractThis paper examines the June 1997 collision between the Progress 234 Supply Ship, and the Russian Mir Space Station. The unmanned Progress 234 cargo supply ship was being flown manually on a practice approach to MIR, when it collided with the Spektr module of the MIR station. The result was a punctured pressure hull, which resulted in a decompression that nearly forced the crew to leave the station in an emergency mode. An analysis of this collision reveals that a host of systems and human factors issues combined to promote the chances for such a collision occurring. These systems‐level attributes that increased the probability of a collision happening included: ground‐control pressure to perform a difficult task, a hectic pace of operations, and previous “close calls” with a variety of on‐board systems failures that left the crew in a stressed state. Systems failures in the docking apparatus itself contributed to making the attempted docking more difficult than would normally have been the case. The general deterioration of economic conditions in Russia and the Ukraine also appears to have played a subtle predisposing role for this type of practice approach to be attempted to begin with due to the mission payment/incentive structure that required the crew to complete certain tasks, and the difficulties involved with obtaining automatic docking devices from the Ukrainians for a reasonable price. Human factors issues that are noted as contributing to this mishap include chronic fatigue from the loss of sleep for an extended period just prior to the mishap, very poor display‐control interfacing under the conditions that the docking was attempted, and embedded psychological/financial pressures resulting from the previous docking failure with Progress 233. From a human factors perspective, the MIR Commander's situation awareness was dramatically degraded during the manual Progress 234 docking attempt due to inadequate visual display and control information, particularly with regard to the position, range, and velocity information of the Progress 234 supply ship.
6.4.3 Architecting An Engineering Documentation System
Authors: Recker Steven A. 
Published: November 2014

AbstractThis paper examines the architecture, development & implementation of a document information management system developed for a systems engineering core group. The intent of the paper is to provide an overview of the approach employed as well as provide insight into the requirements, drivers and the solution. This review also illustrates how the development team made use of systems engineering methods, processes, practices and heuristics. The Engineering Documentation System (EDS) is currently in use by the Systems Engineering department of the Military Aircraft and Missiles division of the Boeing Company.
6.4.4 Applied Systems Analysis and Fuzzy Optimization to Water Quality Management Problems
Authors: Doukas Louis , Sappakitkamjorn Jeerapa , Kildea Daniel 
Published: November 2014

AbstractIn this paper, we present a mathematical model to solve water quality management problems concerned with waste load allocation by integrating systems analysis and fuzzy optimization, to overcome two major difficulties; complexity and uncertainty. The main emphasis of this paper is to present a guideline in order to develop a fuzzy optimization model dealing with multiple conflicting goals between the Pollution Control Department and dischargers. Fundamentally, the goal of the Pollution Control Department is to maximize water quality whereas the goal of dischargers is to minimize the cost of wastewater treatment. The fuzzy optimization model considered in this research is one developed from multi‐objective fuzzy mathematical programming which provides a mathematical procedure for finding an optimal solution in decision‐making problems with conflicting goals despite lack of certainty. The model can be used as a decision‐making tool for managing water quality of any specific water body. It will not only suggest an optimal solution that leads to a compromise between the goals of the Pollution Control Department and the dischargers, but also aid in determining how much waste can be discharged into the water body without violating water quality standards.
6.4.5 Knowledge‐based decision‐support system design for water quality assessment in distribution networks
Authors: Zhou Huimin , Doukas Louis , Roddick Felicity 
Published: November 2014

AbstractThe work on Knowledge‐Based Decision Support System Design for Water Quality Assessment in Distribution Networks is presented. This paper outlines and summarises the essential activities such as, system definition, functions allocation, requirements specification, the prototype systems design, decision‐making processes, and the knowledge database development. The integration of these activities led to the successful application of systems engineering methodology. In addition, the effects of operating parameters such as, chlorine residuals, coliforms, pH value, iron, manganese, turbidity, and colour were assessed to provide a better understanding of the link among the chemical, physical, microbiological and aesthetic issues concerning drinking water supply security and safety.
1.5.3 Epistemological Issues in Representation of Things and Requirements Specification
Authors: Ferris Timothy L.J. 
Published: November 2014

AbstractThis paper discusses the problem of specification of the requirements for a project from the point of view of requirements as a representation of the hypothetical or target product. The relationship between the description and nature of things presented by epistemology is considered. Project requirements introduce the further problem of knowing the essence of things through the representation provided by a description, and that before construction the proposed product is hypothetical. This is presented and discussed.
2.5.1 Assessing the Reliability of Socio‐technical Systems
Authors: Gregoriades Andreas , Sutcliffe Alistair , Shin Jae‐Eun 
Published: November 2014

AbstractThis paper presents a Bayesian belief network (BBN) approach for socio technical system reliability assessment. A human error model (BBN) quantifies error influences arising from user knowledge, ability and task environment, combined with factors describing the complexity of user action and user interface quality. System reliability evaluation is achieved by the System Reliability Analyser tool, which enables the iterative manipulation of the human error model according to high‐level scenarios.
2.5.4 Modeling Objectives on Cost: Insight for Practitioners and Academicians
Authors: Snyder Frank J. , Parnell Gregory S. , Klimack William K. 
Published: November 2014

AbstractFollowing a previous paper entitled Modeling Objectives on Cost in a Decision Maker's Value Structure, the authors present the results of survey research conducted to determine whether or not the objective of minimizing cost should be included as part of the fundamental objectives hierarchy when modeling a decision maker's value structure. Conclusions are drawn for both practitioners and academicians. For practitioners, the discussion addresses which technique those who know and use decision analysis prefer and why. Suggestions for using the two competing techniques both separately and together are offered. For academicians, as a by‐product of the surveys, survey results illuminate how much and what kind of decision analysis training and education is received by systems engineers, operations researchers, engineering managers, decision analysts, and others. Standard contingency table hypothesis testing is used to validate certain points.
3.5.2 Requirements Engineering with Goal‐Driven Use Cases
Authors: Kaffenberger Ruediger 
Published: November 2014

AbstractIn the wake of UML, use cases have become a popular means to capture requirements. But those who do requirements engineering and design at the system level are sceptic about their value, because use case descriptions in their popular form are perceived as inadequate at this level. The points of critique are that there is no precise definition of how a use case is to be described and no well defined method for the system level, tools exist only for Object Oriented Methodology.The concept of use cases but comes in many flavours. Especially the goal‐driven use case concept aims at the system level. It retains the benefits of use cases and at the same time is suited to a wide range of applications. It has been designed to meet the following objectives:

It can represent the requirements of all kinds of stakeholders.
It can be refined or elaborated in well‐defined steps.
Existing information can be reused in a controlled way.
The use cases can be managed along with other forms of requirements by a single tool.The use case concept presented here not only supports object oriented methods but also equally well the standard methods of design and development at the system level.
3.5.4 A COTS‐Aware Requirements Engineering Process: a Goal‐ and Agent‐oriented Approach
Authors: Chung Lawrence , Cooper Kendra 
Published: November 2014

AbstractThe goals of developing systems better, faster, and cheaper continue to drive software engineering practitioners and researchers to investigate software engineering methodologies. In requirements engineering, the focus has been on modeling the software engineering process and products for systems that are being built from scratch. As the size and complexity of systems continues to grow the use of commercial off the shelf (COTS) components is being viewed as a solution. Effective use of COTS components, however, requires a systematic approach that provides both a set of concepts for modeling the subject matter and a set of guidelines for using such concepts. In particular, the process needs to recognize and address the people oriented problems including the identification and resolution of conflicting goals, bridging the gaps between stated requirements and ‘approximately fitting’ components while still satisfying the customer. In this paper, we present a goal and agent oriented requirements engineering process model that explicitly addresses the use of COTS components. More specifically, we present (part of) our model for a COTS‐Aware Requirements Engineering (CARE) process and illustrate it using a Digital Library System.
6.5.4 CloudSat System Engineering: Techniques That Point to a Future Success
Authors: Basilio Ralph R. , Boain Ronald J. , Lam Try 
Published: November 2014

AbstractNumerous books, articles, and technical papers have been written on system engineering's role in successful project management. Components of the project development life cycle such as the definition and analysis of requirements, the design process, configuration control, and risk management are frequently identified as key ingredients to the successful outcome of any endeavor. This is true for deployment of a product or system and also for rollout of an important service. Most of the literature focuses on what the major system engineering steps are without necessarily addressing how to complete each step or how to successfully transition between them. Over the past three years the CloudSat Project, a NASA Earth System Science Pathfinder mission to provide from space the first global survey of cloud profiles and cloud physical properties, has implemented a successful project system engineering approach. Techniques learned through heuristic reasoning of past project events and professional experience were applied along with select methods recently touted to increase effectiveness without compromising efficiency. The use of an online database as the single repository for officially identified requirements and completing a streamlined system‐level fault tree analysis and accompanying probabilistic risk assessment are some specific examples. The collective set has allowed the CloudSat Project to be successful through formulation, approval, and at least early implementation phase.
6.5.5 Restructuring the International Space Station Integrated Verification Process Using Quality Function Deployment and Decision Analysis
Authors: Haskins Bill R. 
Published: November 2014

AbstractThe International Space Station (ISS) integrated verification process was developed to provide a disciplined systems engineering approach for the verification of the ISS specification requirements and to provide a traceable archive of verification data needed to sustain ISS operations. This paper describes and illustrates a tailored version of how Quality Function Deployment (QFD) and decision analysis techniques were used to restructure the ISS integrated verification process. This tailored approach has been accomplished to facilitate the use of QFD and decision analysis by systems engineers and can be used for other systems engineering processes for small or large‐scale integration programs.