bluuebunny/crossref_metadata_2025_split huggingface dataset:
8.5.2 Evaluation of Interrater Agreement in Internal Audit based on ISO 9001:2000
Authors: Hwang Young Ha , Yi Chan‐goo 
Published: November 2014

AbstractAn internal audit in quality management system based on ISO 9001:2000 is an important process that continually improves the effectiveness and efficiency of a quality management system. The reliability of assessments of an internal audit based on ISO 9001:2000 is an issue that continues to demand the attention of researchers in this field. One element of reliability is the extent to which different teams assessing the same project produce similar ratings when presented with the same evidence. Cohen's Kappa coefficient has been the most popular measure of reliability for measuring the degree of interrater agreement beyond chance. However, the application of the Kappa coefficient may be biased downwards due to two Kappa “paradoxes.” To compensate for the deficiency of the Kappa coefficient, we additionally use a simpler index of observed agreement between two teams of auditors. Using Cohen's Kappa coefficient and the observed agreement, this paper presents some results from two assessments between two teams conducted during internal audits in Electronics and Telecommunications Research Institute in Korea. In each of these assessments, two independent teams performed the same ratings. The results indicate that in general there is at least moderate agreement between the two teams and the extent of agreement between the two teams is substantial.
8.6.3 Maintenance Practices and Metrics across Defense and Commercial Systems
Authors: Ramchand Ramya , Tatikonda Nirmala , Verma Dinesh , Nance Richard E. 
Published: November 2014

AbstractSystems and software engineering are converging disciplines with increasing evolution of modern complex systems towards increased information and knowledge content. Further, with the capital investment associated with such systems and their long operational life spans, a longer‐term notion of quality during design and implementation is necessary. The realities of cost, safety, and staffing considerations are forcing increasing emphasis on reuse and reengineering strategies. This imperative becomes even more urgent with the thrust towards the inclusion of commercial‐off‐the‐shelf components in system architectures. One key operational imperative for complex systems is the cost of maintenance. This paper presents an industry survey conducted to understand maintenance practices prevalent in commercial and defense industries. Results from an industry survey focused on system maintenance measures and metrics are also presented. This survey focused on information and knowledge intensive systems and was supported by INCOSE‐The International Council on Systems Engineering and SOLE‐The International Society of Logistics.
9.1.2 Future Trends in Automotive Requirements Engineering
Authors: Houdek Frank , Weber Matthias 
Published: November 2014

AbstractIn the last few years, requirements engineering for software‐based systems has attracted a great deal of attention in the automotive industry. Requirements specification documents have been recognized as a crucial element in the software and system quality chain. Consequently, several industrial initiatives have been launched to improve requirements specification quality, the creation process, and tool support. For instance, many automotive OEMs have introduced requirements engineering expert groups and piloting of requirements management tools.Despite the fact that the situation is still substantially heterogeneous, we observe a common level that the more mature projects have adapted as the current state of practice. However, due to methodological and tool restrictions, this level still falls very short of the full potential of tool‐supported systematic requirements management in the automotive domain.In this paper, we summarize the current state of the practice in requirements engineering for software‐based automotive systems (such as electronic control units) and identify future research directions and tool enhancement requirements. Additionally, we try to identify some popular myths, i.e. ideas that are often mentioned in the context of automotive requirements engineering but which seem to be unrealistic and/or undesirable from our point of view.
9.1.3 System Engineering Approach to Shipborne Weapon System Design
Authors: Sclano Eliseo , Giuliano Carlo , Calvo Corrado 
Published: November 2014

AbstractOne of the problems that System Engineers have to deal with whilst carrying out system design is to allocate requirements to the subsystems. An approach based on a stochastic model to perform requirements allocation to the subsystems of a Shipborne Weapon System (SWS) is outlined in this paper. The model allows computing the overall system performance, in terms of Probability of Escaping Hits (PEH). Computation of PEH is related to the predetermined set of multi‐threats scenarios (including the threat characteristics), the defended area and the ship vulnerability, but at the same time it is subject to functional, physical and performance assumptions of the subsystems as derived from trade‐off studies. On one hand, the model allows to check whether the overall system performance of a SWS configuration, not completely defined by the customer, is achieved and eventually, after the needed iterations, the parameters characterising each subsystem become requirements. On the other hand, if the subsystems characteristics are known, the model allows checking the overall system performance.
9.2.3 Gathering Historical Lifecycle Quality Costs to Support Optimizing the VVT Process
Authors: Engel Avner , Bogomolni Izhak , Shachar Shalom , Grinman Arie 
Published: November 2014

AbstractThe purpose of this paper is to describe the process and results of gathering historical lifecycle quality costs for avionic systems. This is done via a pilot project conducted at LAHAV, the military aircraft division of the Israel Aircraft Industries (IAI). This project is performed in conjunction with the SysTest project, a European Comission R&D project chartered with developing a systems Verification, Validation and Testing (VVT) methodology and a process model for estimating product lifecycle cost, risk, quality, time, etc.The SysTest project and IAI's pilot project are described briefly. The paper presents IAI's methods for obtaining historical quality cost data covering the entire lifecycle with a further focus on the development phases. Quantitative methods for aggregating the results as well as quality cost implications are discussed along with means to optimize the VVT process and reduce the cost of quality at IAI.
9.3.1 A Knowledge Management System Life Cycle Description Using the ISO/IEC 15288 Standard
Authors: Herald Tom , Berkemeyer Wayne , Lawson Harold W. 
Published: November 2014

AbstractDevelopment of a Knowledge Management (KM) system is often considered to be a technical challenge of incorporating the proper system building blocks that provide the mechanism for information transfer from a knowledge source to a potential user. These building blocks include tangible elements such as databases, servers, networks, search engines, web portals and even extend to expert networks and artificial intelligence algorithms. This paper provides a life cycle description of a KM system that includes both tangible and intangible elements. These intangible elements include interfacing the human‐in‐the‐loop, human motivation to contribute to (and to search) the KM system, and establishing a community of practice that includes policies, procedures and guides that encourage a learning organization. Peter Senge (Senge 1994) defines a learning organization as requiring an environment for individual and organizational growth to facilitate continual improvement and maintain a leadership position. The KM system is a tool that, when properly implemented in a business, can indeed facilitate the environment of a learning organization. This paper uses the recently released ISO/IEC 15288 standard (ISO/IEC 2002) and provides a detailed system description model for the life cycle Technical Processes implemented for a KM system. ISO/IEC 15288 also provides descriptions of Enterprise, Agreement and Program Management processes which are summarized for the KM system as a part of Appendix A.
9.3.2 Integrating System Engineering into PDM by AP233
Authors:   EADS Deutschland GmbH, Eckert Roland ,   EADS Deutschland GmbH, Mansel Wolfgang 
Published: November 2014

AbstractIn the manufacturing industry Product Data Management (PDM) systems are backbone systems. The data must be complete, correct, easy to find, easy to visualise and extractable for reports. A drawback is that today's PDM systems are focussed on automotive applications. There is however an increasing need e.g. from aerospace industry for an extended PDM schema to cover systems engineering product aspects. STEP ISO 10303 ‐ AP233 provides an appropriate approach for integrating systems engineering needs into PDM systems, specifically future modularised STEP ISO 10303 application protocols will allow to construct the required PDM schema extensions at reduced customisation effort. A framework for a systems engineering PDM system is proposed and data exchange aspects discussed. A demonstrator for the proposed solution was build using AP233 interfaces for systems engineering CASE tools coupled to an appropriate PDM system.
9.4.3 Thales system engineering community of practice : a knowledge management approach
Authors: Decamps Cécile , Galinier Michel 
Published: November 2014

AbstractAbout 3000 people worldwide belong to the Thales system engineering community. This community of common practices is first of all based on human networks and coordination, but it also requires a systematic approach (tools, methods and processes) to facilitate knowledge and work sharing.This paper describes the objectives, way to proceed and main results of such a knowledge management approach.
9.5.2 An integrated set of technical measures to support earned value management and technical review
Authors: Sillitto H G 
Published: November 2014

AbstractSuccessful experience with the use of key technical performance indicators, in a number of projects in various businesses within the group, has allowed us to define a coherent set of key technical indicators. This set provides a comprehensive “health check” showing the status and current achievement of a project, and supports risk assessment and earned value management by providing an objective view of the current level and trend of solution maturity, requirements compliance, and residual uncertainty.The set includes requirements and verification status, estimate of performance against key technical requirements, estimate of solution maturity, cost drivers, and issue close‐out. The paper presents the rationale and philosophy of the approach, and shows examples of the measures in action.
10.1 Achieving CMMI level 3
Authors: Richard Robert 
Published: November 2014

AbstractThales Training and Simulation (TT&S) SA achieved CMMI level 3 in June 2003. This covers Software, Project Management and Systems Engineering.Following an action plan on Software (CMM level 3 achieved in 1996) TT&S defined a strategy leading to reach CMMI level 3 for all disciplines (including Bid and Project management). This paper aims at sharing :
lessons learnt to reach CMMI level 3
benefits perceived by TT&S
brakes encountered during implementation of the action plan
Three keys strongly contributed to this success. The first one is the experience that TT&S gained during the Software CMM action plan. The second one is the involvement of management. The third one is measurement of progress through internal assessmentsNote: CMM and CMMI are registered copyrights of CMU/SEI
10.4 A Conceptual Glossary for Systems Engineering
Authors: Gilb Tom 
Published: November 2014

AbstractThis paper discusses some of the insights gained and the problems experienced to date in developing a conceptual glossary for the planning language, ‘Planguage.’ It also outlines a model to build on for similar work in organizing knowledge about concepts. The author's opinion is that further development of such glossaries is needed as concepts form a fundamental basis for educational and organizational purposes.
10.8 Integrating Systems Engineering and Marketing
Authors: Paul David J. , Webster William C. , Kenley C. Robert 
Published: November 2014

AbstractCustomer Oriented Requirements Understanding (CORU) continues to be the key to successful Systems Engineering and Marketing of large Aerospace and Government systems. Buyers hold all of the Requirements and all of the money. This is defined as the “Customer Needs or Requirements PULL” environment.Systems Engineers ask if the principles of CORU operate in a Commercial “Seller Product or Technology PUSH” environment, and whether causal models can be constructed which address and differentiate (or segment) markets accurately. If so, the principles which are effective in large system acquisition environments (with limited numbers of stakeholders) can be translated to the relatively large stakeholder environment of product development for TELCOs, consumer electronics and high‐technology systems, and other high‐volume commercial products. The key process techniques of Requirements Elicitation and Requirements Causality Modeling are described along with a robust economic and Systems Engineering model for a network‐like architecture of how these processes link the Customers (Buyers) with Needs or Requirements together with the Sellers or developers of Capabilities or Products. Research results are delineated which make the case that these linkages through Requirements Elicitation and Requirements Causality Modeling process techniques are basic principles of CORU which are valid in both the Requirements PULL or DoD environments as well as in the Product PUSH or commercial environments. Examples are given in which Value Hierarchies are aligned across Customer‐Seller boundaries to achieve product success in both the Commercial and the DoD environments.
10.11 SpecRight: Writing correctly requirements, produce product specification and requirement justification file
Authors: Chevallier Jean , Marshall Richard M 
Published: November 2014

AbstractSpecRight is a tooled approach to the capture of technical requirements, product specifications and requirements justification documents. This is done by combining educational elements, formal definitions, and automated work guides. By answering the questions in each work guide users can create complete systems engineering documents.The objectives of the approach are to be an aid and a guide to capture and structure technical requirements and to produce and manage product specifications and requirements justification. As systems engineering needs correctly‐documented requirements, SpecRight is a useful means of performing the first step of the engineering process.Following a demand from the European Space Agency (ESTEC) a prototype of SpecRight has been created to demonstrate that the logic could be performed and supported by software. We are now working to complete SpecRight such that it is in line with ISO 21351 Functional and Technical Specifications.
10.12 SYSTEM LEVEL EMC – FROM THEORY TO PRACTICE
Authors: Zamir R. , Bar‐Natan V. 
Published: November 2014

AbstractThis article discusses the vast importance of incorporating Electro‐Magnetic Compatibility (EMC) engineering as an inseparable part of system engineering in a complex, technologically‐advanced, tight‐scheduled military Project, starting from the Project proposal stage (in response to a Request for Proposal – RFP), down to cositing impacts tests in the platform. The Project's product is defined as an operational prototype. On one hand, this prototype will prove the system's functional properties as were specified by the Customer, while on the other hand serving as a first article that is required to withstand all of the environmental conditions as a serially‐produced system, including full EMC requirements. The unique system which is being addressed here has multiple, diverse capabilities and is comprised of elements and units belonging to various families, e.g., electronic boxes, electro‐optical units, inertial sensors, functional display, computer, etc. The units are based on home‐developed and Commercial Off‐the‐Shelf (COTS) units (military as well as civilian/industrial). Furthermore, we will present the methodology that was employed to minimize problems/failures during system EMC tests, in both the laboratory and after installation in the platform.
1.2.2 Using an Enterprise Architecture to Assess the Societal Benefits of Earth Science Research
Authors: Martin James N 
Published: November 2014

AbstractAn enterprise architecture for the Earth Science activities of the National Aeronautics and Space Administration (NASA) was developed to assist in assessing the capacity of scientific instruments in meeting the needs of society. It can also help them develop the right investment strategies and help scientists and engineers in their planning for system development, especially for complex space‐based environmental sensors. The architecture contains about 3000 elements that are involved in earth science research: observation sources, sensors, environmental parameters, data products, mission products, observations, science models, predictions, and decision‐support tools. The science models use observations from the space‐based instruments to generate predictions about various aspects of the environment. These predictions are used by decision‐makers around the world to help minimize property damage and loss of human life due to adverse conditions such as severe weather storms. The architecture is developed using both traditional and non‐traditional SE tools and techniques. This paper will describe additional methods needed for the SE toolbox.
1.2.3 The Systems Engineering Approach to Warship Signatures Management
Authors: Manzini Mauro , Montigiani Marco 
Published: November 2014

AbstractThis paper presents how Systems Engineering (SE) is applied to the design of warship radar and infrared signatures. The two signatures are treated as a system, the “signatures system“. Starting from the system definition a SE approach is described which provides a way of managing the warship signatures, taking into account all aspects involved and the relevant interrelations. The need to use a concurrent approach to reach a successful system design is highlighted.While modern technologies do permit “fully stealth” designs, these require very great efforts, often in contrast with the constraints imposed by a real project. The aim of this paper is to show how the system level vision of SE allows design of a cost effective system which provides the proper balance of technical and economical factors.Finally, a brief description of the role of the system engineer is provided.
1.3.3 Potholes in the Road to Good Systems Engineering
Authors: Armstrong James R. 
Published: November 2014

AbstractOver several decades of observing the practice of systems engineering, both in classrooms and on programs, several recurring problems have been identified. It was anticipated that lessons would be learned, and this set of problems would decrease significantly in occurrence, if not disappear completely. However, that has not happened. It seems that many of the problems are rooted in basic mental roadblocks. This compendium is assembled as a watchlist of some of these roadblocks for new and old practitioners.
1.4.3 Estimating and Optimizing System's Quality Costs of Transport Helicopter Avionic System Upgrade
Authors: Engel Avner , Shachar Shalom , Bogomolni Itzhak 
Published: November 2014

AbstractThis paper depicts IAI's real‐life experience in estimating and optimizing system's quality costs associated with upgrading a transport helicopters' avionic system. This pilot project was conducted at Lahav, the military aircraft division of the Israel Aircraft Industries (IAI) in conjunction with the SysTest project. SysTest was a European Commission R&D project chartered with developing a systems Verification, Validation and Testing (VVT) methodology and a process model for estimating product lifecycle cost, risk, quality, time, etc.The SysTest endeavor and IAI's pilot project are described briefly. Thereafter, the paper presents a case study where the overall quality costs are estimated based on the current VVT strategy established at Lahav/IAI. Our findings showed that the actual performance of VVT process amounted to 34% of the quality costs. The appraisal risk cost (expected cost associated with the detection of defects during the VVT process) amounted to 6%. Notably, the impact risk cost (cost emanated from not performing VVT as part of the VVT strategy) amounted to 60% of the quality costs. At the same time, a significantly improved VVT strategy, reducing the cost of quality by over 25%, is readily available.Our conclusion is that the current VVT strategy at Lahav/IAI is clearly not a most efficient one. Less cost‐effective VVT activities are performed at too high a performance level and visa versa. We assert that systems' VVT is performed at many organizations based on “engineering intuition” and, plainly, this is not a good yardstick. We are currently starting to apply a formal VVT optimization methodology in a large IAI program, developing a state of the art communication satellite.
2.1.2 Enterprise Architecture and Aesthetics
Authors: King Paul 
Published: November 2014

AbstractEnterprise architecture is the discipline of describing and analysing the relationship between an enterprise's objectives and purpose, and the system of systems which the enterprise uses to help achieve those objectives. This paper makes the case for the importance of aesthetics in enterprise architecture. It proposes an enterprise architectural modelling language which addresses enterprise form, purpose and aesthetics. This language is a meta‐model extension of SysML which uses the power of SysML to address the engineering aesthetic of enterprise architecture.The paper is based on work carried out for the UK Ministry of Defence's Integration Authority to develop an “Integration Services Support Environment” (ISSE). ISSE uses the enterprise architecture modelling language to enable the consistent description, and hence analysis, of a large and heterogeneous system of systems. ISSE itself has been developed as a enterprise architecture modelling tool and as a repository of interconnected models of MoD's enterprise.
2.2.1 A Structured Method for Generating, Evaluating and Using Metrics
Authors: Kitterman Dick 
Published: November 2014

AbstractThis paper presents a method of generating metrics for a project, organization, process, or product. It first points out that metrics generation starts with a bounding of the area of interest. Then it shows how to examine the outputs associated with the area of interest for metrics on effectiveness that are stated in the general parameters of quantity, quality, cost and time. Next, the paper focuses on the area of interest's internal activities to develop metrics on efficiency, using the same general parameters. The paper then demonstrates a number of tests that can be used to evaluate the goodness of the metrics for use in a decision process. Finally, the paper discusses how metrics presentation has importance equal to metrics content and shows examples of good and bad ways to present metrics.
2.2.2 A Meta‐process Producing a Deliverable‐centric Process
Authors: Lizotte M. , Lalancette C. , Dussault G. , Lam S. , Couture M. , Mokhtari M. , Bernier F. 
Published: November 2014

AbstractThe current paper introduces the Iterative and Incremental Meta‐process (I2M) being applied to develop a Capability Engineering Process (CEP). This simple method is founded on the assumption that such a CEP, and even any process, should be developed as methodically as engineering is performed for systems and software system development. This effort is performed as part of a major Canadian R&D effort called the Collaborative, Capability, Definition, Engineering and Management (CapDEM).