bluuebunny/crossref_metadata_2025_split huggingface dataset:
Investigation of cell association techniques in uplink cloud radio access networks
Authors: Yan Shi , Wang Wenbo , Zhao Zhongyuan , Ahmed Abana 
Published: November 2014

AbstractCloud radio access networks (C‐RANs) have been proposed as promising solutions to increase both the spectrum and energy‐efficiency performances in the fifth generation wireless communication systems. Many published works have discussed the concrete implementation technology to justify the huge development potential of C‐RAN. However, few litterateurs focused on characterising the cell association in the uplink. In this paper, we study the cell association techniques in uplink C‐RAN systems. Three received power based cell association techniques, namely the single best, N‐best and N‐th best, are presented and analysed. To characterise the random deployment of remote radio heads (RRHs) with multiple antenna configuration, stochastic geometry is used to evaluate the proposals' ergodic capacity, and the corresponding closed‐form expressions are derived. For the received power based cell association techniques, both analytical and simulation results demonstrate that the ergodic capacity gain from an increase in RRH density is larger than that of increasing the number of antennas per RRH. Copyright © 2014 John Wiley & Sons, Ltd.
An antifungal mechanism of curcumin lies in membrane‐targeted action within Candida albicans
Authors: Lee Wonyoung , Lee Dong Gun 
Published: November 2014

AbstractThe aim of this study is to investigate the antifungal mechanism of curcumin. This polyphenolic compound has been used traditionally in Asia for medicinal, culinary, and other purposes. Although antifungal effect of curcumin has been reported, this is the first study for its mode of action underlying disruption of plasma membrane in Candida albicans. The leakage of potassium ion from the fungal cytosol and dissipation in membrane potential was detected by bis‐(1,3‐dibutylbarbituric acid)trimethine oxonol [DiBAC4] staining. We also investigated an increase in membrane permeability in curcumin‐treated C. albicans with influx of propidium iodide assay. Fluorescence analysis with 1,6‐diphenyl‐1,3,5‐hexatriene supported the membrane‐targeted mechanism of action indicating membrane disruption. On the basis of these results, we studied the effects of curcumin treatment on model membrane to elucidate its antifungal mechanism. Using calcein leakage assays from curcumin‐treated large unilamellar vesicles and giant unilamellar vesicles, we found that curcumin has membrane‐active mechanism inducing leakage of intracellular component through the flappy membrane. Therefore, this study suggests that curcumin exerts antifungal activity via inducing disruption of fungal plasma membrane. © 2014 IUBMB Life, 66(11):780–785, 2014
INTEGRATED APPLICATION OF RISK MANAGEMENT AND COST OF QUALITY
Authors: Brekka Lawrence T. , Picardal Chelo , Vlay George J. 
Published: November 2014

AbstractRisk management and cost of quality are two management methodologies that are receiving increasing attention from organizations concerned with the management of large, complex design, development, manufacturing, and operational programs. Typically these two methodologies are treated as separate functions and are executed independently of each other. In fact, cost of quality determines information critical in identifying and assessing risks in a program, and risk management provides procedures for monitoring and mitigating the risks that are identified with that information. Program management will be enhanced by the coordinated application of cost of quality and risk management. Clear program management responsibilities among the system engineer, program control manager, and program manager ensure effective, coordinated application of the two methodologies.
A RISK MANAGEMENT PROGRAM FOR A TASK‐ORDER CONTRACT
Authors: Ramchandani C. , Ligon W. , Rabenstine D. , Bhatia K. 
Published: November 2014

AbstractThis paper describes a risk management program that Computer Sciences Corporation (CSC) developed for a NASA Goddard Space Flight Center (GSFC) task‐order contract. The program uses a closed‐loop risk management process, supported by a spreadsheet‐based tool to standardize the information that task managers must enter and to facilitate risk impact calculations. The paper addresses the challenges of developing and deploying a risk management program for a diverse task‐order contract. The paper also describes process improvement actions taken to maximize program acceptance among CSC task managers.
A CUSTOMER ORIENTED APPROACH TO OPTIMIZING SUBALLOCATIONS OF SYSTEM REQUIREMENTS
Authors: Hadel J. J. , Lakey P. 
Published: November 2014

AbstractA proper Systems Engineering approach to aircraft requirements allocation demands that upper‐level performance requirements be flowed down and allocated to lower‐level subfunctions in a logical, traceable, structured process. Normally it is not in the customer's best interest to contractually specify suballocated values developed from the top requirement because such action borders on dictating hardware design solutions instead of focusing on communicating customer overall needs to the contractor. Because of this, the requirement flowdown process appears to offer opportunities for multiple feasible solutions which are all capable of meeting the customers top level requirement. Thus, there is need for a systems engineering process which is capable of identifying a “best choice” among these selections. At McDonnell Douglas, a creative approach to resolve this requirements flowdown issue has been developed. The approach provides guid‐ance identifying and rank ordering preferred design choices, developing requirements flowdown, and documenting rationale behind identification and selection of optimal choices. The process focuses on a guidance philosophy which identifies customer needs using Quality Function Deployment assessments in combination with linear optimization analyses to perform numerical suballocation of top requirements. The approach provides guidance towards 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. An application of this process to the diagnostic requirements area has been packaged by McDonnell Douglas as a single integrated set of software modules which fit on a floppy disk capable of operating on a desktop PC.
REQUIREMENTS FOR DEVELOPMENT OF SOFTWARE REQUIREMENTS
Authors: Mar Brian W. 
Published: November 2014

AbstractThis paper (1) describes what the current literature identifies as qualities of good software requirements, (2) identifies and examines different categories of software requirement methods, and (3) concludes that methods used to develop software requirements, though not perfect, have advantages that can improve the development of requirements for any type of system. Twelve requirement qualities were identified from the literature and these were used to establish evaluation criteria for software requirement development methods. Three methods selected for evaluation were the Hatley‐Pirbhai method (1988), the CoRE (Consortium Requirements Engineering, SPC, 1992), and Requirements State Machine Language (RSML) develop by Leveson (1990). None of these method stands out as being superior and each have strengths and weaknesses depending upon the application, but each offers improvements over the text based methods used in traditional systems engineering efforts to create function/requirement sets.
TEACHING THE GENERATION OF OPERATIONS BASED REQUIREMENTS
Authors: DeFoe Joseph C. 
Published: November 2014

AbstractThis paper presents specific recommendations that have been found effective within IBM (now Loral) Federal Systems for teaching the process of generating operations‐based requirements. Specific recommendations include:
Base the workshop on a holistic, flexible process
Base exercises on a problem the students can relate to as a user
Ensure the students understand the needs the entity addresses before allowing them to begin requirements analysis
Have all exercises involve teams
Have at least two exercises using each critical method or technique covered in the workshop
Have multiple teams work the same problem
Construct class requirements definition examples such that there is at least one with a clearly superior resolution, and one with number of nearly equivalent “okay” resolutions
HOW TO DO AND USE REQUIREMENTS TRACEABILITY EFFECTIVELY
Authors: Curtis A. Scott 
Published: November 2014

AbstractEvery customer wants good requirements traceability when they start a new program. They want to ensure their contractor provide “tops down” traceability when deriving lower‐level requirements to ensure the original customer requirements are met thus avoid what is commonly called “requirements creep”. However, most customers are soon disappointed about the methodology their contractors use when trying to actually implement requirements traceability. After a while most contractors persuade their customers to relax their expectations and finally drop the requirements traceability task and say “Let's just design and build it, we're just wasting time.”This paper will present a “how‐to‐do” requirements traceability more efficiently as well as “how‐to‐use” the information more effectively once you've done all that work. Topics include customer requirements traceability; derived requirements traceability; requirements allocation traceability; design compliance traceability; verification traceability; product sell‐off traceability; and operational lessons learned traceability. Real experience and lessons learned from many programs are revealed to help avoid some of the pitfalls and provide more efficient methods for performing these tasks. A generic, multi‐user requirements traceability database is discussed to describe how to automate the requirements traceability process for increased productivity.
RESPONSIVE CONSTRUCTIVIST REQUIREMENTS ENGINEERING: A PARADIGM
Authors: Mayhew Michael E. , Alessi R. Samuel 
Published: November 2014

AbstractPoor requirements can lead to cost and schedule overruns and are therefore a source of low quality products and stressful work environments. This paper introduces a “responsive constructivist” paradigm for use by systems engineers to address these concerns. The paradigm is “responsive” to stakeholder statements in a nonlinear but methodological manner. “Constructivist” refers to the abstract construction of problem space based on a linguistic understanding of the various stakeholder's worldview of the problem, not necessarily upon the “preordinate positivist” beliefs of science. This paradigm asserts the necessity of approaching requirements such that the human component is more formally embraced. This challenges requirements engineers to evaluate their own stance of curiosity and neutrality. Additionally, questioning types and patterns aid to gather different views of the problem. This responsive constructivist systems engineering paradigm can improve the quality of interpersonal communications, thereby resulting in higher quality requirements and alternate problem abstractions.
Using Rapid Prototypes for Early Requirements Validation
Authors: Andrews Blake A. , Goeddel William C. 
Published: November 2014

AbstractUsing rapid prototypes for early validation can accelerate product development in all phases of the development life cycle. The most obvious benefit is the ability to evaluate requirements for applicability and unanticipated errors early in the development life cycle. However, additional benefits can also be realized during the follow‐on phases of the development life cycle. These benefits are often not considered as a part of the planning and decision making process regarding systems modeling tools. During the development of the 777 Autopilot Flight Director System (AFDS), system engineers at Collins Air Transport Division (CATD) evaluated both a conventional approach and a rapid prototyping approach in the development of two complex system functions. The lessons learned from this exercise could significantly change the way CATD system engineering teams approach system development in future projects.
AN OPERATIONS CONCEPT DEVELOPMENT METHODOLOGY USING A GRAPHIC PROCESS FLOW TECHNIQUE
Authors: Denzler David W. R. , Mackey William 
Published: November 2014

AbstractAn iterative methodology has been developed for creating operations concept documents (OCDs) that improves operations concept development by using a graphic process flow technique. This technique analyzes and presents the operations concept in a format that system developers, customers, and operations personnel can readily understand. The approach reduces costs and complexities associated with the more conventional OCD development preparation by stressing hierarchical text development. For example, one OCD constructed using this methodology was completed in 20 percent of the conventional development time.
DEVELOPING A CAPABILITY MATURITY MODEL FOR SYSTEMS ENGINEERING
Authors: Kuhn Dorothy A. , Garcia Suzanne M. 
Published: November 2014

AbstractA proposed collaboration of industry to develop a capability maturity model and assessment instrument for systems engineering was made at the 1993 NCOSE Symposium. Several companies have participated in this collaboration, providing dedicated staff and resources to do the work.This paper presents the goals, structure and nature of this collaboration and the results of its efforts to date.
Interim Maturity Model
Authors: Reichner Al 
Published: November 2014

AbstractIdeally, a systems engineering maturity model, together with a questionnaire and supporting documentation, provides the capability for an organization to do a self assessment of its processes, practices, management, metrics, and quality. It would be a framework for assessing an organization's level of systems engineering maturity. Currently, several corporations, educational institutions, and government agencies are doing research in the field of systems engineering maturity models. This paper describes some of the research and products. Loral Space and Range Systems (LS&RS), realizing the potential benefits of a self assessment, used a model developed by Bill Money of Loral Command and Control Systems and evaluated its Systems Engineering Laboratory's maturity. The proponents of the assessment process hoped that the evaluation would provide an assessment of the current state of the division's systems engineering maturity, guidance for improvement, and improve effectiveness, making the organization more competitive. This paper presents an overview of the key features of the Loral model, how Loral used the model, and a summary of the findings and action plan. Even with its weaknesses, the assessment process was definitely worth the effort and cost. The paper concludes with recommendations on how others can benefit from the LS&RS maturity model experience.
Retooling the Organization
Authors: Schuster Cecilia H. 
Published: November 2014

AbstractEven in this age of “Continued Process Improvements” where companies are paying increasing attention to their processes, attention may fail to be focused on day‐to‐day details in actual procedures until a tool is applied to the job. This paper addresses case studies that illustrate common pitfalls encounted when introducing automation into organizations. The conclusion supported by these illustrations is that technology insertion should be planned and that people are the most important factor in planning for change.
AN INTEGRATED APPROACH TO COMPLEX SYSTEMS ANALYSIS AND PERFORMANCE SIMULATION
Authors: Peterson Kenneth J. , Mar Brian W. 
Published: November 2014

ABSTRACTThis paper presents a classification of types of simulation techniques and a correlation matrix that maps types of simulation techniques and types of systems engineering tasks. An analysis identifying the most appropriate application of specific types of simulation to “front end” systems engineering task is presented. A template for creating specifications to acquire systems engineering support and system simulation tools is developed to allow systems engineering efforts to increase their level of maturity.
MANAGING COMPLEXITY: AN APPLICATION OF CONSTRAINT THEORY
Authors: Friedman George J. 
Published: November 2014

ABSTRACTA fundamental intellectual thrust of Systems Engineering thinking is its extensive nature: the ability to integrate across many dimensions and disciplines, and to formulate problems. By contrast, most of our engineering and scientific education has concentrated on intensive thought processes: the concentration on relatively low dimensional submodels and the solution of problems. This paper provides a framework to guide systems engineers in multidimensional thought processes and problem formulation. It is based on the constraint theory developed by Dr. George J. Friedman.
SYSTEMS THINKING FOR PRODUCT DEVELOPMENT
Authors: Dick Michael J. 
Published: November 2014

AbstractSYSTEMS THINKING is a disciplined methodology for dramatically improving both the quality and the development/production efficiency of high technology customer‐focused products. It begins at product inception and applies throughout the product lifecycle.Systems thinking gives multidisciplinary teams a simple, thorough methodology for understanding the interdependence, interaction, and tradeoff among the many complex product development concerns.At each phase of product development, systems thinking uses a simple, integrated set of activities: 1) Address the full spectrum of product objectives/requirements. 2) Stimulate and guide the generation of new ideas. 3) Perform risk‐based concept evaluation. 4) Use fault analysis to pinpoint and correct weak areas. 5) Document decisions and lessons learned.Using systems thinking at each phase of product development assures meticulously thought out decisions before proceeding to the next phase. Such forethought is essential for success with today's complex products.
A CONCURRENT METHODOLOGY FOR THE SYSTEM ENGINEERING DESIGN PROCESS
Authors: Childers Susan Rose , Long James E. 
Published: November 2014

AbstractThe system engineering design process as detailed in MIL‐STD 499 does not adequately address the incorporation of design issues relevant to specialty engineering disciplines. This paper details a process by which the concerns of specialty engineers are addressed and incorporated into the system design in a consistent and efficient manner. The paper also introduces an incremental system engineering process (The Onion Model) which allows complete interim solutions at increasing levels of detail during the system specification process.Along with the three standard concurrent engineering focuses of requirements analysis, functional analysis, and architecture definition, the process includes concurrencies for specialty engineering. Each specialty engineer assesses the implications of the system engineering design process in relation to the specific specialty requirements and evaluates the implications of the system functional and physical architectures on the realization of an adequate specialty engineering solution. Once an integrated solution achieves the approval of the acquisition agency, it is refined to the next level of detail. When the system level design is sufficiently refined to generate the System/Segment Specification, the segment development process may begin.
IDENTIFYING PROFILING SYSTEM REQUIREMENTS WITH QUALITY FUNCTION DEPLOYMENT
Authors: LaSala Kenneth P. 
Published: November 2014

AbstractSystem engineering may be accomplished by many approaches. Central to each approach, however, is the development of clear, consistent user requirements and their translation into corresponding technical requirements. Quality Function Deployment (QFD) has been shown to be an effective means of developing and translating requirements. To test the applicability of QFD to NOAA systems, a generic, hypothetical atmospheric profiling network was subjected to a limited application of QFD. The results, though limited, showed that QFD can be applied to NOAA systems. Although more work is required to complete the profiler application in detail, this limited application has provided a model and lessons learned. Although this paper discusses a system of potential use within NOAA, the views expressed in this paper are solely those of the author and do not necessarily represent the views of NOAA.
FREQUENTLY ASKED QUESTIONS ON SYSTEMS ENGINEERING PROCESS
Authors: Rhodes Donna H. 
Published: November 2014

AbstractThe evolution of engineering processes is greatly enhanced through the sharing of lessons learned between organizations. Loral Federal Systems (formerly IBM Federal Systems Company) has evolved its Systems Engineering process over the past decade to a fairly mature process, with clearly defined ownership. Over the past several years, we've participated in many interchanges with other companies and organizations. Out of these exchanges, thoughts on various aspects of process management become crystallized through discussions on the FAQs ‐ Frequently Asked Questions. This paper addresses many of the frequently asked questions brought up in process exchanges, and the related lessons learned in hopes that other process owners will benefit and that further discussion will be prompted as a result.
Benchmarking System Engineering: Harris Case Study
Authors: Kraemer Bruce P. , Kabaservice Thomas P. 
Published: November 2014

AbstractIn 1991 Harris' Electronic System Sector decided to look for new ways to achieve significant improvements in its product development capabilities. A variety of plausible efforts were considered. One of the projects undertaken was to explore the applicability of Benchmarking as applied to the System Engineering discipline.In this paper Harris describes its benchmarking journey including the project origins, approach to benchmarking and lessons learned in applying this improvement technique.The practice of benchmarking requires a considerable amount of honesty and “soul baring” between benchmarking partners. But, it is accepted practice that information shared between partners be held in confidence. Therefore, this paper concentrates on the approach used and lessons learned in applying benchmarking rather than specific insights regarding how Harris or its benchmarking partners currently conduct their System Engineering or might change System Engineering practices as a result of the benchmarking.
Object Oriented Life Cycle Approach to System Engineering
Authors: Tronstad Yngvar D. 
Published: November 2014

AbstractThis paper provides a description of an Object Oriented Life Cycle process and methodology that combines System Engineering and HW/SW Engineering in one unified formal representation. The method, called RDDTM‐Object Modeler (RDDTM‐OM), emphasizes the interaction of the objects in the context of the system. This is done by object semantics that represents the components of the system, their interconnection and their behavioral interaction, to the level of detail that describes distributed design of computer based systems. The focus on objects that are transformed throughout the steps of the development process ensures a traceable and strong coupling to the problem at hand. If system requirements are based on an object oriented approach starting with the understanding of the problem domain, re‐use is easier and more likely to occur.