bluuebunny/crossref_metadata_2025_split huggingface dataset:
5.2.2 Self Organizing Maps (SOMs) for Systems, Software, Management and CMMI Document Relevancy
Authors: Beshore David G. 
Published: November 2014

AbstractThe size of the systems engineering book of knowledge is unknown, but continuously expanding! The systems and software standards are quagmires of legacy and evolution. Stacks of documents (books, standards, guidebooks, handbooks, papers, process manuals) relate to the subject of systems engineering and engineering management. Developing ‘best practices‘, from systems engineering bodies of knowledge (Beshore 2001), is critical to the future engineering success of large programs. The CMMI (CMMI) represents the latest internationally driven model requirements standard for systems engineering, software engineering and integrated product development. An automated method is presented in this paper to determine document relevance to any body of knowledge or sets of process or process assessment standards. Specific examples and uses of new tools have been used to improve documentation relevancy of Raytheon's IPDS (Integrated Product Development System) to the CMMI process requirements models. With this approach there is a way out of the document and standards quagmire through more focused process planning on programs.
6.2.3 Improving the Efficiency of Improving Efficiency – Re‐engineering the R&D Organization
Authors: Blonigen Brad , Dagli Cihan H. 
Published: November 2014

AbstractSystems engineering tools were first used to improve the quality and efficiency of the systems that were produced for sale to the customer. These same tools were then applied to the manufacturing systems that produced these products to allow for more efficient production. It is time to move the focus farther up the line and apply the tools to the systems that support and produce the manufacturing systems. By using a systematic approach to the organization and management of the R&D organization, increases in efficiency can be derived that can either be used to reduce near‐term costs or be leveraged to gain even greater returns through re‐investment in technology development. This paper looks at the process of re‐engineering the R&D organization using systems engineering tools.
2.3.2 Idealized Front End Process and Maturity Matrix: A Tool for Self‐Assessment of Process Maturity Leading Up to Product Launch Decisions
Authors: Wirthlin Joseph R. , Rebentisch Eric 
Published: November 2014

AbstractTo better characterize the processes used to generate requirements for new products (a.k.a., the “fuzzy front end” of product development), product development literature was extensively reviewed to identify best practices. An idealized front‐end process model was developed from this literature review and then through an iterative process involving empirical field research, used to create a maturity‐based assessment tool. 17 enterprises engaged in new product development provided data for case studies on the front end of product development and the processes used in requirements generation. Using these case study data, the 17 organizations were scored using the assessment tool to identify the organizations that had the most mature front‐end processes in place. The highest‐performing organizations were compared with the lowest‐performing organizations to identify specific practices that differentiated their performance.
5.3.2 Put Me in Coach; I'm Ready to Play!: A Discussion of an Evolving Curriculum in Systems Engineering
Authors: McCarthy Daniel J. , McFadden Willie J. , McGinnis Michael L. 
Published: November 2014

AbstractPrior to 1999, the Introduction to Systems Engineering Design course was taught late in the sequence of courses that the typical student took in the Department of Systems Engineering at the United States Military Academy. The normal progression of courses front‐loaded students with various modeling and analysis “toolkit” courses. Much later in the program students were taught the engineering design big picture. In 1999, the academic program was overhauled. The introductory engineering design course became the first course in the academic program. In addition, the program's courses were separated into “methods” courses that fill the student's toolkit and “formulation” courses that require students to synthesize various tools in formulating and solving small‐scale engineering problems. Finally, summer academic internship experiences were linked with a yearlong capstone design experience during the student's senior year. This paper discusses these changes and highlights advantages of this improved approach to teaching systems engineering.
5.3.3 Review of Papers Concerning Engineering Teams in INCOSE Symposia 1991 to 2002
Authors: Ferris Timothy L.J. 
Published: November 2014

AbstractThis paper reviews the discussions of work by engineering teams, and some very closely related issues, in the INCOSE Annual Symposia to date. The purpose of this work is to identify the issues associated with teamwork in engineering teams and the strategies to address the issues with negative effects. The publications are found to address the issues at two distinct levels, the macro of how teams should operate and the overall performance of team structures, and the micro, concerning the inner functioning of the teams, and the issues associated with the human character of the participants. The majority of the literature reviewed addresses the macro level, with only a few papers about the micro dimensions of teamwork. The review is organised chronologically to investigate temporal development of the thinking of authors.
3.4.2 Supporting Object‐Oriented Analysis of Human Performance Systems
Authors: Douglas Ian 
Published: November 2014

AbstractThere is a move towards conceptualizing, packaging and building human performance support systems, such as e‐learning, around reusable objects. As with the software engineering domain this approach may only be successful if analysis and design also moves to an object model. There is a need for new methodological thinking and automated tools to support the change. An automated object‐oriented performance analysis system is described, which enables modeling and collaboration during human performance systems analysis. The system is based on web services and uses a repository model to support the sharing and reuse of analysis knowledge both within and between organizations.
3.4.3 Generation of Hardware Description Languages from Modelisation tools based on Meta‐modelisation
Authors: Rault Valéry 
Published: November 2014

AbstractOne of the main problems when creating systems lies in the different tools and methods used by the various disciplines. Even when doing calculators and computers, with the involvement of only two disciplines, hardware and software, this situation raises many problems early in the design phase and has important consequences on the result. A way to break this wall would be to standardize the efforts around a single design tool, used by the systems, software and hardware engineers as well. As an enabler for such a standardization capability, this paper presents a generator of hardware description languages that uses a meta‐model. A major benefit is to generate code such as VHDL, Verilog or System C from various modelling tools like UML, I‐Logix's Statemate or even from other sources.
2.5.3 Product Development Interrelationships
Authors: Morais Bernard G. , Mar Brian W. 
Published: November 2014

AbstractProduct development processes are driven by a tradeoff between customer, developer and market forces. Commercial consumer product development is very sensitive to market conditions and efforts to increase market share. Defense and aerospace product development is more sensitive to the government customer desire to manage cost, time and schedule of the development effort and to advance the technology. This paper examines the lessons learned from both the commercial and defense product development experiences and presents a unified approach that will respond to any combination of product development issues.
6.5.2 The Role of Systems Engineering in Intelligent Transportation Systems
Authors: Mackey William F. , Krueger Michael E. 
Published: November 2014

AbstractThis paper explores how systems engineering is being applied to meet the growing need for an Intelligent Transportation System (ITS). There are similarities between the approaches that civil engineers take to design highways and that systems engineers take to solve complex system development problems. The process of developing a highway design can be directly correlated to the system development life cycle used in systems engineering. The progression of highway development is demonstrated to be an evolution of technologies, inventions, organizational creations, and legislative acts that has supported the development of a national interstate transportation system in the United States. The ITS is a global phenomena and is being pursued in Europe, Australia, and Japan as well as the United States. Until now, highway development has been the domain of civil engineers concerned with highway structures, materials loading, traffic patterns, and supporting facilities. However, the growing need for ITS or intelligent‐vehicle highway systems (IVHSs) requires that traditional civil engineering disciplines be integrated with computers, communications, and eventually fully automated vehicles. This paper's thesis suggests that the complex highway transportation of the 21st century can benefit from the collaboration of systems engineers and civil engineers.
6.5.3 Product Model for Requirements and Design Concept Management: Representing Design Alternatives and Rationale
Authors: Andersson Fredrik , Sutinen Krister , Malmqvist Johan 
Published: November 2014

AbstractThroughout the development of complex products, thousands of requirements are established, communicated, followed up, and verified. In addition, even more design solutions, at various levels of abstractions, are created, refined, evaluated, industrialised and verified during this period. Although design tools support the documentation and administration of the output of these activities, i.e. requirements and solutions, they lack the functionality to support the iterative gestation of requirements and design solutions as they are created. This paper illustrates how a product model, focusing on requirements and design concept management, can address these issues by incorporating design rationale, i.e. the reasoning and the justification underlying requirements and solutions considered, with the aim to close the gap between product models and design rationale models. The product model has been implemented in a commercial PDM software and its use is illustrated with the information from the design of a passenger car cockpit.
2.6.3 Security Engineering Awareness for Systems Engineers
Authors: Sheard Sarah A. , Moini Assad 
Published: November 2014

AbstractSystems engineers generally are not trained in computer systems security, and those who are trained often have limited exposure to narrow areas of computer security. The result is that system‐wide security requirements often are not understood or addressed adequately, and delivered systems may contain hidden security flaws and vulnerabilities that are later exploited. Reactive efforts to patch or harden system security later in the system lifecycle are very costly and only can address flaws and vulnerabilities after they have been discovered. Given both the explosive growth of the Internet and our ever‐increasing reliance on critical information infrastructure, it is no longer sufficient for systems engineers to remain technically naïve about security considerations. This paper discusses some of the reasons for this new urgency; the areas where knowledge of computer systems security is important to systems engineers; and some topics that must be considered when eliciting, analyzing, and specifying system‐wide security requirements.
2.6.4 Measurement of System Safety Processes
Authors: Caseley Paul , Clark Graham , Murdoch John , Powell Antony 
Published: November 2014

AbstractThe ‘Measurement of Safety Processes and ALARP’ project is a UK Ministry of Defence Corporate Research Programme, managed by QinetiQ Ltd. that is developing fine‐grained, non‐invasive, measurement systems for the safety domain. The need for better measurement systems is being driven by a number of factors, principally the need to reduce risks to As Low As Reasonably Practicable (ALARP) and the achievement of higher levels of process maturity.The Safety Process Engineering Language (SPEL) is a language‐based measurement framework for safety processes. The approach, originally developed in the software engineering domain, is described via a case study of its industrial application on an auto‐code verification project. We show how the technique enables the cost‐effective collection of fine‐grained information to help identify improvements in the technical and business management of the safety process.
4.6.2 Intelligent Agent Saves Lives
Authors: Steinberg Richard K. 
Published: November 2014

AbstractDesigning human computer interfaces for rapid command and control decision‐making displays has unique challenges. Displays for Air Traffic Control, Military Operations, and Emergency Management require an interface that optimizes performance while minimizing errors. In addition to performing the emergency functions, maintaining operational readiness of equipment is a task where errors and time delays could cause loss of human life. Interaction efficiency is critical to avoid operator fatigue and minimize operator error rates that could cost lives. In emerging emergency management systems and concepts, the user typically acts as a manager by exception while the majority of system activity is computer automated. While direct interaction of the user with the system is minimal, an inaccurate action by the user can have catastrophic consequences. There is clearly a need for decision aiding systems to help focus users on the most important information. This paper describes a case study that demonstrates the use of a human engineered intelligent agent. The results of this effort suggest as much as a 40% reduction in casualty risks while using the intelligent agent and strong positive preference ratings by all operators who used it.
1.7.2 An Integrated Risk Management Process
Authors: Saad Joe , Hsu John C. 
Published: November 2014

AbstractWhen the risk management process was introduced at the Boeing Airlift And Tanker (A&T) Programs, many obstacles were encountered. It was determined to overcome these obstacles and improve the process. While the process of risk analysis and mitigation is well known, implementation is more challenging than just establishing the process and procedures. The detailed steps of implementation are presented. Visibility of critical risk to program level manager and customer is vitally important for both program management and timely and effective resolution. The company profit as well as customer budget control depend on close monitoring of project spending. The project cost risk is converted to impact assessment of Estimate At Completion (EAC) at the earlier stage of the project progress. The integration of project risk with program level risk and with business risk is discussed.
4.7.1 How to Quantify Quality: Finding Scales of Measure
Authors: Gilb Tom 
Published: November 2014

Abstract‘Scales of measure’ are fundamental to the definition of all scalar system attributes; that is, to all the performance attributes (such as reliability, usability and adaptability), and to all the resource attributes (such as financial budget and time). A defined scale of measure, allows you to numerically quantify such attributes.‘Scales of measure’ form a central part of Planguage, a specification language and set of methods, which I have developed over many years.This paper describes how you can develop your own tailored scales of measure for the specific system attributes, which are important to your organization or system. You cannot rely on being ‘given the answer’ about how to quantify. You will lose control over your current vital system performance concerns if you cannot, or do not, quantify your critical attributes.
5.7.1 The C4ISR Architecture Framework V 2.0: Considerations for Usage
Authors: Iaquinto Joseph F 
Published: November 2014

AbstractMany DoD contracts require the use of the C4ISR Architecture Framework. This framework prescribes a specific set of architectural artifacts. However it provides very little guidance on how one is to use this framework. This paper provides a brief introduction to the C4ISR Architecture Framework, version 2.0. Following this, specific usage guidance is provided to aid the C4ISR Framework user in accomplishing the objectives of the Framework.
5.7.2 Systems Engineering: a Natural Approach to C4ISR
Authors: Maley Joseph , Long James 
Published: November 2014

AbstractIn 1998, the United States Department of Defense mandated the C4ISR Architecture Framework for all ongoing and future contracted architectures. The goal is to ensure that future military systems are interoperable and provide the warfighter with the support and effectiveness required for successful missions.The C4ISR Architecture Framework specifies a set of “standard” views capturing various system perspectives. As with nearly all frameworks, the outline and contents are defined, but the methodology and support aids are left to the developmental organization's discretion. Many organizations implement processes that develop and manage the various C4ISR artifacts as independent deliverables, which are often inconsistent. Removing these inconsistencies occupies much of the time and resources available at every developmental stage. Failing to recognize inconsistencies leads to actual developmental, integration, and operational problems along with expensive retrofit efforts.This paper indicates how the use of a proven systems engineering process in concert with a comprehensive systems engineering tool significantly reduces these inefficiencies, establishes a stronger base for decision making, and allows management to mitigate strategic and developmental risks more successfully.
6.7.1 Leveraging Web Services in Product Design – Implications for System Engineering
Authors: Brunk Brett K. 
Published: November 2014

AbstractThe rise of the Internet has had a profound effect on application development and user interfaces. In a similar fashion, emerging web services technologies have the potential to change the way applications are assembled and re‐used. Web services provide application designers new building blocks for assembling a product that meets users' needs – at the same time, web services come with their own set of design constraints. For web services to be successfully incorporated into a product, it is important that system designers understand how web services change application design. This paper begins by exploring the main components of web services and shows how web services affect system design. In addition, web services introduce three concepts – modularity, re‐application and interface decomposition – that can be applied to general system engineering design.
3.8.2 Integrating Systems Engineering and Earned Value Manag ement
Authors: Solomon Paul J. 
Published: November 2014

AbstractEarned value is the only technique proven to effectively integrate cost, schedule and technical performance management (Czelusniak 1997). However, because earned value is a derived measure, its effectiveness as a measure of performance depends on the effectiveness and objectivity of its base measures and on the capabilities of the systems engineering and project management processes that are employed. Earned value management (EVM) can provide more management value if it is integrated with systems engineering, if its implementation is consistent with pertinent standards and capability models and if the base measures for earned value are based on technical performance.This paper provides a framework and practical guidance for EVM process improvement. The framework is based on a gap analysis between the EVM standard and three standards and capability models for systems engineering and project management. The cited standards and models provide more explicit guidance towards achieving the principles of EVM than is provided by the EVM standard itself. Practical guidance for process improvement is based on best practices within Northrop Grumman Corporation and on the Software Engineering Institute (SEI) publication, “Using CMMI® to Improve EVM” (Solomon 2002).
3.8.3 Systems Engineering and Process Infrastructure Development
Authors: Armstrong James R 
Published: November 2014

AbstractAll the lessons learned in developing products for external customers often are forgotten when developing internal products. This is especially true when developing the infrastructure, processes in particular, for performing systems engineering. Processes usually are written in a design‐first approach with all the errors that such a process creates. There is a better way to develop processes. This paper addresses how to apply the systems engineering process to developing processes and their supporting infrastructure.
3.8.4 Zoned Analysis: A Circular Bird's‐Eye View of Project Tasks and Deliverables1
Authors: Zirker Larry , Johnesee Jim , Hamelin Douglas 
Published: November 2014

AbstractZoned analysis (ZA) is a graphical decomposition methodology initially practiced in academia to ensure that all aspects of a curriculum were addressed with lesson plans, but this method has been adapted as a systems engineering tool with multiple end uses to facilitate collaboration of team members, enhance management understanding of the project, show team members their responsibilities, link requirements to deliverables, and aid in gap analysis. A ZA appears as a bull's‐eye or target with partitioned pie‐shaped sections emanating from the center circle to outer circles. The title of the project or program is placed in the center circle. Subsequent partitioned circles, or zones, facilitate the decomposition hierarchy of the project with the outer‐most zones or elements evolving as terminal elements or deliverables. This article shows examples of ZAs and provides instruction on how to construct a ZA.
1.4.2 Enterprise Architecture and Enterprise Process Improvement
Authors: Ibrahim Linda , Wells Curt , Bate Roger 
Published: November 2014

AbstractThe Federal Enterprise Architecture (FEA), once institutionalized throughout government, can become a major driver for process improvement. This will depend on the use of best practice in creating, applying, and evolving it and the successful launching and execution of projects to realize those improvements. An enterprise process improvement model that provides best practice guidance for creating, applying, evolving, and institutionalizing the FEA, can align with the FEA in striving for enterprise improvement. Industry is monitoring Government progress, and some companies are working on their enterprise architectures.Enterprise architecture and enterprise process improvement are similar concepts, with similar methods, seeking similar objectives. This paper examines the commonalities between enterprise architecture and process improvement and illustrates how an enterprise process improvement model, when used in combination with enterprise architecture, can enable improvement across government and industry.