bluuebunny/crossref_metadata_2025 huggingface dataset:
4 A Framework for Early Evaluation of Functional Product Structures
Authors: Harzenetter Florian , Thomé Bernhard , Igenbergs Eduard
Published: November 2014

This paper proposes a framework which supports the assessment and optimisation of the quality of products in very early phases of product development. First, an introduction is given to the notion of architecture and its establishment during the lifecycle process. Then a set of metrics is presented which is used to evaluate structural properties of a product architecture. This evaluation mechanism also serves to optimise a product structure towards an optimal representation of these properties. Finally we will show that structural properties support quality aspects that can be used to determine desirable product structures for a given design problem.
4 System Flowdown Using Enhanced QFD
Authors: Clausing Don , Cohen Lou
Published: November 2014

In defense/aerospace systems engineering the requirements are usually flowed down to lower, more detailed system levels directly as a self‐contained process. Commercial systems engineering takes a more eclectic view of the flowdown process. Here we set forth the complete commercial system flowdown process, which has two primary features: (A) a zigzag path through requirements, concepts, and improvement at system level N, which is then repeated at level N+1, and (B) three sources for requirements at level N: (1) higher‐level requirements from level N‐1, (2) the voices of external stakeholders (VOES) at level N, and (3) amplifications of the functions at level N. Thus, this approach expands on the narrow flowdown of requirements by integrating it with the VOES and functional analysis, and integrating all of requirements with concept selection and improvement. This is done by utilizing QFD, functional analysis and amplification, and Pugh concept selection. This process when implemented effectively provides competitive advantage in the global commercial competitive markets.
3 Software Reusable Artifacts Evolution: A Three Levels of Abstraction Framework
Authors: Toffolon Claudine , Dakhli Salem
Published: November 2014

Abstract

The software crisis is still going on but is nowadays, more critical than ever as organizations cannot exist without operational software. Ramifications of the software crisis are both economic and social. In that context, software reuse is a key technology which permits organization to cope with many aspects of the software crisis (maintenance costs and development cycle times reduction, software systems quality increase). However, despite the potential benefits of software reuse, current reuse methods, techniques and tools fail to improve the software development process productivity and the software products quality. In particular, existing software technology doesn't take into account the organizational aspects of the software reuse process complexity. In this paper, we propose a three‐ levels of abstraction (conceptual, organizational, technical) framework to describe the reusable artifacts evolution activity. The conceptual level lists the main tasks of the evolution activity and the data flows they exchange. The organizational level describes the actors contributing to the evolution activity and the evolution tasks carried out by each actor. The technical level emphasizes the version control problems resulting from reusable artifacts evolution and defines a set of basic rules to cope with these problems.
4 SPARTAN: an approach to software and systems engineering process assessment
Authors: Holt Jon , Patel Dipesh
Published: November 2014

This paper, initially, describes a SPICE (ISO 15504) compatible software process assessment tool for safety‐critical systems for use in the rail industry. This assessment tool and methodology, known as SPARTAN, is then extended to take into account systems engineering, rather than just software engineering.
1 Towards a Standardised Systems Engineering Information Model
Authors: Herzog Erik , Törne Anders
Published: November 2014

Data exchange capabilities of contemporary systems engineering tools are, on the whole, limited. The main reason for this is the effort required for implementing tool to tool data exchange ‘bridges’, and the large number of tools available on the market.

This paper is one in a suite of three papers presenting the results of the Esprit 20496 ‐ SEDRES. The objective of the project has been to provide the groundwork for a systems engineering information exchange standard within the ISO 10303 (STEP) framework. The companion paper by Johnson et al. (Johnson et al., 1999] provides an overview of the project and a report on the results of SEDRES. In this paper, the focus is on presenting the structure, scope and plans for future extensions of the SEDRES information model.

The SEDRES information model has been specifically developed to facilitate data exchange between systems engineering tools. It has also been put forward as input for the standardisation work, that in due time will result in a STEP Application protocol for systems engineering – Application protocol 233.
2 Function Analysis and Decomposistion using Function Analysis Systems Technique
Authors: Wixson James R.
Published: November 2014

The “Father of Value Analysis”, Lawrence D. Miles, was a design engineer for General Electric in Schenectady, New York. Miles developed the concept of function analysis to address difficulties in satisfying the requirements to fill shortages of high demand manufactured parts and electrical components during World War II. His concept of function analysis was further developed in the 1960s by Charles W. Bytheway, a design engineer at Sperry Univac in Salt Lake City, Utah.

Charles Bytheway extended Mile's function analysis concepts and introduced the methodology called Function Analysis Systems Technique (FAST) to the Society of American Value Engineers (SAVE) at their International Convention in 1965 (Bytheway 1965). FAST uses intuitive logic to decompose a high level, or objective function into secondary and lower level functions that are displayed in a logic diagram called a FAST model.
3 Systems Engineering the Product Development Value Stream
Authors: Weiss Stanley I. , Warmkessel Joyce M.
Published: November 2014

Value stream analysis is a powerful tool for reducing cycle time in a product development enterprise. To date most applications have addressed the manufacturing phase. This paper describes the use of a systems engineering process to apply the concept of value stream analysis to product development and to develop a Product Development Value Stream (PDVS) map.
1 Tailoring Quality Function Deployment for Use in Systems Engineering
Authors: Plowman Catherine
Published: November 2014

This paper describes and illustrates a tailored version of the Quality Function Deployment (QFD) methodology referred to as the “House of Quality”. The tailoring has been accomplished to facilitate the use of QFD by systems engineers—especially in the early project phases. All steps are completely documented as are the augmentations to the standard QFD approach. These augmentations include project initiation; requirements normalization; customer, opportunity, and integration impact scoring; system concept scoring; and system concept synthesis and selection. The closing section describes a NASA project in which this tailored approached produced significant and quantifiable cost savings.
2 A Solution to the Architecture/Software Design Bind ‐ The Mission Object View
Authors: Frank Rodger F.
Published: November 2014

Two powerful approaches to system modeling, each of which addresses important issues in the system development process, are currently available for use: architecture view sets and domain level object modeling. Each of these techniques is insufficient to architect complex, software intensive systems when used alone – object modeling does not address important physical and low‐level architectural concerns and an architecture depiction may violate a smooth object development unintentionally. Additionally, the two approaches are interdependent and interact in conflicting, confusing ways. This is the central nature of the architecture/software design bind. This paper suggests a solution to the architecture/software design bind by including the domain object model in the architecture view set as a full fledged, participating view – the Mission Object View. This allows a controlled and complete relationship between object constructs and architecture entities.
3 Methodology for Measuring Requirements' Impact on Software Size
Authors: Stewart Ron , Donat Michael R.
Published: November 2014

Accurate estimation of the size of the software needed to implement a set of requirements allows for more efficient planning. Preliminary results at Raytheon System Canada Ltd. indicate that objective analysis of requirements can increase the precision of software size forecasts. This paper defines a methodology for measuring the impact of requirements on software size.
4 The Suitability of Using Objects for Modeling at the Systems Level
Authors: Cocks Dan
Published: November 2014

Functional analysis has been the traditional approach to modeling systems. Now that object‐oriented analysis has essentially displaced structured analysis for software development, it is reasonable to ask whether objects should go on to replace functions for modeling at all levels of system definition. Issues related to modeling notations, methods, and resulting analytical flexibilities are discussed. While the object oriented notations and methods have grown significantly in the past few years, they may not yet be ready to replace functional analysis at the system level.
1 Implementation of a Systems Engineering Tool in the Program Post‐Production Phase
Authors: van Gaasbeek James R
Published: November 2014

Systems engineering is applied during the development phase of a program. The continued application of systems engineering concepts during the production, post‐production and disposal phases can contribute significantly to program success. However, the resources available during development are frequently reassigned to other programs once serial production commences, and reduced even further during the post‐production and disposal phases. The introduction of systems engineering tools, even as late as the post‐production phase, can provide a resource multiplier that will allow continued and substantial system engineering support in the face of reduced systems engineering staffing. This paper addresses the implementation of a systems engineering tool late in the product lifecycle.
2 The Age of Process: Applying a Historical Perspective to the Present Day
Authors: Pajerek Lorraine
Published: November 2014

We are in the midst of a period in systems and software engineering that strongly emphasizes the importance of process. Process maturity has been extensively analyzed and codified, and the goal of process maturity has become pervasive throughout industry, government, and the academe. It may seem at times that more attention is paid to the process used to produce a product, than to the product itself.

This paper examines the background experiences that led to the development of process maturity models, and deconstructs some of the arguments that have been posited, both for and against. By looking back at the road we have travelled thusfar, we can glean some lessons that may be applied to the path we travel in the future.
2 System Design to Affordability in a Collaborative Systems Engineering Environment
Authors: Myers Kenneth N. , Verma Dinesh
Published: November 2014

The Cost as an Independent Variable (CAIV) concept requires establishing aggressive but realistic total system ownership cost objectives and goals very early during system development. A balanced set of goals are identified through cost, schedule, and performance tradeoffs and the management of associated risk. Subsequently, these ownership cost objectives guide the strategic system architecture, design and technology decisions.

The relationships and dependencies between different design views, schedules, and correlating infrastructure need to be rationalized in estimating the system cost of ownership. Furthermore, this has to be done within an environment of continuous flux. This becomes even more of a challenge in a Commercial‐Off‐The‐Shelf (COTS)‐intensive open system environment, with development, production, and system supportability being executed concurrently. The team can exploit a number of synergies that result from such a scenario. However, a prerequisite is the ability and infrastructure for timely and reliable information exchange between the disciplines contributing to design decisions. Effective execution of the CAIV methodology is dependent upon strong integration of multi‐disciplinary processes, methods, information and domain specific toolsets.

This paper describes an initiative to integrate a CAIV methodology for COTS‐intensive combat systems engineering into a collaborative systems engineering environment. A pilot effort to implement a common information model within a COTS Product Data Management (PDM) system, CAIV processes, and engineering tools supporting the execution of COTS‐based combat systems design is described. Future extensions to the information model, the systems engineering processes, and the collaborative engineering environment supporting combat systems design, development, and life cycle engineering activities are presented.
3 Mitigating the Risks and Increasing the Gains From Teamwork
Authors: Harrison Barbara , Dube Charles
Published: November 2014

Teams hold the potential for outperforming other types of work structures in complex circumstances, but many fail to deliver on this promise. Such failure can threaten the success of an entire project or program. In their work with teams, many of them complex in structure and makeup, the authors have developed a fairly simple and inexpensive process for forming and aligning teams that can significantly reduce the risk of team failure. While the process is fairly simple, the implementation of that process is not.
2 A Systems Engineering Framework for Integrated Automotive Development
Authors: Loureiro G. , Leaney P. G. , Hodgson M.
Published: November 2014

This paper proposes a systems engineering framework for integrated automotive development – the total view approach. It is a modelling framework that integrates the product, its life cycle processes and their associated organisations throughout the requirements, functional and physical analysis processes, at all levels of the product breakdown structure, deriving attributes as emergent properties of a whole integrated system. The paper justifies the framework through a review of traditional and current automotive development and two case studies.
3 Initial lessons of model‐based systems engineering for small commercial product development in the electrical domain (for Uninterruptible Power Supply System)
Authors: PAOLI Claude DE , Parrot Olivier , Rouge Alain , Dutey Catherine
Published: November 2014

1 ABSTRACT AND INTRODUCTION

For years the development of systems engineering has been led by industries and systems that can be characterized by single‐customer projects and large systems with long development life‐cycle. As market starts to be driven by other features (smaller systems and shorter projects, mass commercial products), it is necessary to examine how far current systems engineering practices support the new rules and whether these new rules affect established systems engineering practices. This is of course an ambitious and long‐term job but this article would like with other papers sharing the same concern and presented at INCOSE'99 to pave the way for this endeavor. We present herein the intermediate results of an experiment carried out by MGE UPS Systems, a world class provider of Uninterruptible Power Supply (UPS) systems and that investigates the interface between marketing and engineering to identify if better work in this area can improve time‐to‐market.
1 An Application of Object Oriented Systems Engineering (OOSE) To an Army Command And Control System: A New Approach to Integration of System and Software Requirements and Design
Authors: Meilich Abe , Rickels Michael
Published: November 2014

The purpose of this paper is to demonstrate how an Object Oriented Systems Engineering (OOSE) methodology developed at Lockheed Martin (LM) Management and Data Systems (M&DS) is being applied to the Army Global Command and Control System (GCCS‐A). This system is now migrating from a legacy Army system to a modern integrated Army wide system that supports the Joint GCCS. The focus of this paper is on providing practical examples of how some fundamental issues for using System Engineering methods (previously accomplished with structured analysis and design techniques) in conjunction with software OO methods were resolved using this OOSE methodology. These include: (1) how the system and software requirements specification must be synchronized; (2) capture of requirements and system design information using Object Oriented (OO) techniques and relationships; and (3) using the system objects to better manage the allocation of functionality in the system, maintenance of a legacy system, and ease of system analytical model maintenance during periods of requirements change.
2 Building a re‐use infrastructure: Optronics Reference Architecture and Layered Reference Model
Authors: Sillitto H.G.
Published: November 2014

Pilkington Optronics supplies sensor equipment and systems to a wide range of customers. These systems generally follow one of a few recognisable “design patterns”. However with a few notable exceptions re‐use between projects is limited.

The company wants to improve the leverage of its substantial technology investment into products; and to reduce the amount of investment required to produce variants and derivatives of current products.

To facilitate effective re‐use it is necessary to provide a common framework for identifying reuse opportunities. Several complementary tools established to provide this framework are presented. They include the “Reference Optronics System Architecture”, which describes a superset of all optronic systems at a particular level of decomposition; and the “8‐layer optronic system reference model”, an analogue of the OSI layered model for processing systems.

The paper describes these models and their significance for management of re‐use, technology planning, and teaming relationships.
3 The Systematic Methodology of Inventive Problem Solving ‐ TRIZ: A Review
Authors: Savransky Semyon D. ,   The TRIZ Experts
Published: November 2014

The weak point of traditional methods of innovation management is transformation of customer needs to the concept of new technique. Usually some creativity methods are used, but most of such methods cannot guaranty optimal result. TRIZ is a methodology to solve problems as close as possible to the Ideal Final Result by clarifying functions of the system under consideration even if contradictions rise during problem solving. The TRIZ methodology for inventive problems solving is used for the innovative resolution of various technical and physical contradictions in the artificial systems. TRIZ methodology developed by G.S. Altshuller, the author and TRIZniks in the former Soviet Union during last 50 years is reviewed. It is shown how TRIZ provides a possibility to find the best conceptual design of a new technique.
4 V & V in Plain English
Authors: Lake Jerome G.
Published: November 2014

The purpose of this paper is to discuss in plain English the role of V & V in confirming that a system product conforms to its appropriate set of related specified requirements. It is not expected that this discussion will once and forever settle the differences that exist in perceptions and practices of V & V. It is the intent, however, to remove some of the confusion and misunderstanding surrounding V & V with the expectation that the engineering of a system can thus be improved.

This paper first presents the basic concepts for engineering a system in order to place the functions of end product V & V in context. Second, the confusion and misunderstanding of V & V found in existing standards are pointed out and resolution provided. Third, considerations for proper implementation of V & V are given so that “verification” and “validation” can lead to efficient and effective engineering of world class systems.
1 Workgroup Software Tools applied to the Space Shuttle Orbiter Configuration Change Impact Assessment Study Process
Authors: McCallister Timothy P. , Weeks Donald P. , Hines James E. , Ouellette Fred A.
Published: November 2014

The Space Shuttle program is transitioning from the development phase to the operational phase. The National Aeronautics and Space Administration (NASA) is restructuring the management of the Space Shuttle Program by turning over the day‐to‐day operations to a prime contractor, United Space Alliance (USA), a joint venture partnership between Boeing and Lockheed Martin (LM). Most Space Shuttle related contracts have been consolidated into one Shuttle Program. This consolidation move is intended to save millions of dollars in costs by eliminating duplicate resources, streamlining operations, and reducing nonessential program requirements. NASA, USA, Boeing and LM are working closely together to provide the American public a Space Shuttle Program that continues to be technically viable, safe, and now more cost effective. Central to organizational consolidation and expected efficiency gains is ensuring people from all organizational elements of the program think and work together as integrated teams.

Shuttle ground processing and flight operations have been consolidated under the USA banner. The Orbiter hardware/software design center remains at Boeing. NASA retains configuration control of the Shuttle system. This new arrangement, while providing efficiencies, can present challenges. Diverse requirements and incentives must be considered in identifying and implementing technically viable, safe, and cost effective changes while maintaining the design baseline configuration of the Orbiter. A concurrent engineering team process involving NASA, USA and Boeing is used to resolve design configuration issues when they arise. This paper deals specifically with the application of Lotus Notes workgroup software technology and the Internet to provide an on‐line collaborative environment used during configuration change studies. This environment facilitates the use of a systematic concurrent engineering process by study teams as they assess proposed Orbiter modifications.
2 A Requirements Driven Approach to Synthesis of Military Satellite Communications Payloads
Authors: Henkle Thomas G.
Published: November 2014

This paper presents a structured approach to synthesizing communications payloads based on expressed requirements of a military client. The approach stresses the functions performed by a communications payload rather than technologies that facilitate their implementation. Benefits of a structured approach include increased focus on client requirements, timely development of realistic payload concepts, enhanced acceptability of those concepts, and a more robust design relative to technology driven designs. A process model is developed. Payload synthesis models are presented.
3 Metrics for Full Systems Engineering Lifecycle Activities (MeFuSELA)
Authors: Tugwell GC , Holt JD , Jobling CP , Neill CJ
Published: November 2014

Complexity is perhaps the single most cited cause of project failure. Complexity exists throughout the whole of the project lifecycle and is not always apparent until the project is running into difficulty. The aim of this paper is to present a suite of metrics that can be used to highlight complexity at all phases of the project lifecycle, rather than just after the system has been built. A basic assumption of the work is that all models for the system are represented using the industry standard Unified Modelling Language (UML).
4 Taming the Expanding System Complexity of a Commercial Product: Embracing Systems Engineering Principles in a Commercial Development Environment
Authors: Miller Paul
Published: November 2014

The development momentum of complex commercial products are often choked by an interminable cycle of test and corrective action that devours and overwhelms valuable resources. The root cause of this class of problem is that traditional commercial development environments do not make use of sound Systems Engineering principles as their products mature into highly complex systems. This paper provides an account of how Fujitsu Australia's Telecommunications Research and Development (R&D) centre is exploiting the years of experience gained by the Aerospace and Defense industries, and adapting their highly tuned and proven Systems Engineering practices into the commercial development environment. The centre piece of this paper is the adopted generic Systems Engineering Model that has become the central focus of development capability maturation within the R&D centre.
Optimizing Systems Engineering Specification Quality Control Processes
Authors: Gilb Tom
Published: November 2014

Inspection is a proven technique for achieving quality control of specifications and, identifying associated process improvements. In fact, Inspection can be applied to any discipline which produces documents. It has been applied with excellent results to hardware engineering (e.g. aircraft and electronics), management and sales contracts documentation.

Software Inspections are widely known within the software industry, but most organizations do not make the most of them. This is because many people misunderstand and misinterpret Inspection. This paper aims to provide some direction as to how to get the most value from your Inspections.
Enhance Quality in Complex Systems with a Common Project Model
Authors: Ogren Ingmar
Published: November 2014

Complex systems concern multiple stakeholders and will often have multiple system representations such as the “real system” and various simulators. If the understanding of the system differs among the stakeholders and if the system representations differ from the “real system”, this is a quality problem.

One way to attack this quality problem is to create a “Common Project Model (CPM)”, which is then common in two ways:

it is common among the system's stakeholders

it is common among the different representations of the system.

To build a useful CPM, you need a tool‐supported modeling technique, which is understandable and sufficiently formal to model the structure and behavior of a complete system including the missions of the system with their connection to the different components in the system.

The CPM should preferably be evolved together with the system. It can then be used to support various technical and application activities.
Introducing Requirements Engineering for the Basic Engineering Phase of Automation Concepts
Authors: Wenzek Hagen R , Scherff Birgit
Published: November 2014

Basic engineering for automation concepts becomes more demanding for the companies that want to employ state‐of‐the‐art technologies. To overcome the typical heuristic processes in the planning departments and to respect the high significance that software now has for automation technology, requirements engineering is being introduced for this matter. This paper describes the important aspects that need to be considered in the plant engineering context, how tools and methods can be implemented and what evaluations are being done.
Year 2000 Triage for Non‐IT and Embedded Systems
Authors: Biggs Bruce B. , Jackson Harry
Published: November 2014

This paper describes the Year 2000 (Y2K) problem and explains how it extends beyond the renovation of application software, to operating system software and embedded systems. It will show why fixing the Y2K problem in embedded systems will be difficult, yet crucial to preserving the defense of our nation ‐ and specifically maintaining our warfighting Command and Control (C2) systems. It also discusses the Enterprise TriageSM methodology, a Y2K solution based on the idea that mission‐critical system changes, and the risks to the systems' operation, must be identified and addressed as early as possible.
Infrastructure Management Model: A Case for Examining Relationships
Authors: Godau Ralph I.
Published: November 2014

Traditionally, infrastructure management has been the realm of the technocrats. This has led to the assessment of infrastructure systems as standalone technical entities as opposed to a interdependent homologous systems comprising technical, social, environmental, economic and political influences.

Recent infrastructure 'crises' in Australia highlights a need to have a fresh outlook and examination of the way infrastructure is managed.

This paper explores the concept of using visual qualitative analysis for examining and capturing the complex nature of the relationships that bind infrastructure management systems together. This will be done through the examination of stakeholder perceptions in relation to current infrastructure management practices.
Implementing Risk Management as part of a Systems Engineering Process
Authors: Laporte Claude Y. , Boucher Guy
Published: November 2014

During the last five years, Oerlikon Aerospace developed and implemented engineering processes. In this paper, we discuss the application of risk management to the re‐engineering of operator console stations of a missile weapon system. We briefly describe the systems engineering process. Finally, twelve lessons learned are discussed.
4 Who Teaches Whom
Authors: Ball Jenny , Ogleby David , Hardaker Chris
Published: November 2014

As we are all well aware, Systems Engineering is a diverse field. It is a changing field. It means different things to different people. The words ‘Systems Engineering’ are difficult to define in one phrase that people can agree on and that means something tangible. Given these factors, the task of providing training in Systems Engineering is fraught with difficulty from the outset. Add to that a delegate base from a large, diverse, geographically disparate organisation, and you have quite a challenge. This, however, is the arena in which we work, and this paper describes some of the approaches we have taken and lessons we have learnt in providing Systems Engineering training for the Marconi branch of the General Electric Company over the last few years.
Managing in an Environment with a Level 1 Customer
Authors: Radke Neill B.
Published: November 2014

Frequently, a systems development organisation encounters a customer that can be characterised in terms of the Systems Engineering Capability Model (SECM) as a Level 1 organisation. The developer must identify that customer as Level 1 early in the project development cycle and manage the project accordingly. Agreement must be reached with the customer as to what is to be built and how the system will be accepted. Requirements and acceptance criteria must be clearly defined and negotiated with the customer.
Process Measurement: How It Changes As Process Maturity Increases
Authors: Minnich Ilene
Published: November 2014

Many of the domains we work with every day are described by Capability Maturity Models® – including systems engineering, software engineering, secure systems engineering, etc. Each CMM describes the domain's primary process activities, as well as methods for improving the organization's ability to perform its processes. But in order to determine a process' current capability level, as well as to be able to improve a process, certain measurements must be in place. How do we know what measurements to take? How do we know if the resultant number(s) are “good enough”? How do we know what changes to make to our processes based on the measurements? And how do the characteristics of the data and our resultant actions change as our organization's processes move up through the maturity levels? This paper will give a brief look at each of these issues.
Integrative Systems Approach to Cost Deployment
Authors: Jeyaratnam Canestus , Doukas Louis , Pollock Graham
Published: November 2014

The central theme to this paper is to provide the research outcome on the application of a software model developed for effective transfer of user requirements into product design features including cost analysis, with built‐in scientific decision making support tool. In the extremely competitive global environment, there is a need for integrating cost evaluation and deployment into the design process in a systematic way for up front identification of cost while maintaining a balance of quality and performance requirements. The developed model is Excel® based and tested with actual industry based case studies as applied to Australian manufacturing and industry. The proposed model will establish measures of World Best Practice with minimum complexity to improve product design and project management.
British Army Equipment Support ‐ How Does It Measure Up To Systems Engineering?
Authors: Wright D M H
Published: November 2014

This paper sets out the full range of activities involved in the British Army's business of supporting our extensive range of complex equipment. These activities are then set against the requirements of total systems engineering, that is the engineering and optimisation of both product and process. A number of shortfalls are identified, principally that there is little attempt to use through‐life systems engineering to achieve optimisation. A comparison is then made between Defence procurement and the operation of the normal commercial market. The demands of equipment support in this commercial environment are also addressed. A number of recommendations for improvement are made, principally the adoption of a more commercial approach to equipment procurement and support.
The CMMI Project
Authors: Ferguson Jack R.
Published: November 2014

The CMMI Project

The CMMI project is a collaborative effort sponsored by the Office of the Secretary of Defense/Acquisition and Technology (OSD/A&T) Systems Engineering with participation by U.S. government, industry, and the Software Engineering Institute (SEI). The project's objective is to develop a capability maturity model integrated product suite that provides industry and government with a set of integrated products to support process and product improvement.

This project was designed to preserve government and industry's investment in process improvement and to enhance the use of multiple models. The project's outputs include integrated model(s), assessment method(s), and training materials.

The CMMI project's objective is to improve the usability of the maturity modeling technology in a wider set of disciplines than simply software. The concept calls for use of common terminology, common components and rules for constructing models, to reduce the training and process improvement effort needed by users of multiple disciplines. In the initial phase, the scope of the CMMI project is restricted to the most needed disciplines: software engineering, systems engineering and Integrated Product and Process Development (IPPD). The initial set of models to be produced include staged and continuous representations for:

Software Engineering

Systems Engineering

Software and Systems Engineering

Software and Systems Engineering with IPPD.

The CMMI Product Suite was designed with the capability to expand in both disciplines and life cycle coverage. While the schedule for these expansions has not yet been decided, other disciplines (such as security systems engineering) are possible. Expansion decisions will be made based upon the success of the initial stage, user community needs and support, and availability of participants for the Product Development Team (PDT).

® Capability Maturity Model and CMM are registered in the U.S. Patent and Trademark Office
ATM or Gigabit Ethernet…Which One Will Be The One Stop Solution?
Authors: Smith Reggie
Published: November 2014

This trade study will examine both ATM (Asynchronous Transfer Method) and Gigabit Ethernet. I will look at these technologies to serve as the backbone for a network, plus service down to the desktop. I will examine cost, design, performance and future trends. These technologies will be compared in a same case scenario with both networks passing voice, video and data for a distributive network nationally. This comparison is also considering what the end‐users wish to increasingly use such as the following: scientific modeling, publications, medical data transfers, inter/intranets, data warehousing, network backups, interactive media applications, increased network reliability, low cost, compatibility, etc.

I chose this trade study subject comparison because “most organizations competing in the global marketplace increasingly turn to information management technology to gain a competitive advantage” (FORE, 1996). “These new organizations are driven by information and powered by new enablers such as distance learning, collaborative workgroups, telecommuting, videoconferencing, and multimedia front ends to existing databases. Today's conventional LAN (Local Area Network) technologies (e.g., Ethernet, Token Ring, and FDDI) and components (e.g., hubs, bridges, and routers) were not designed to support such demanding requirements” (FORE, 1996).

This explosive demand has brought about ATM and Gigabit Ethernet. I believe that ATM will become a natural backbone medium with Gigabit Ethernet service to the desktop. The future looks like a mixed environment with not just one medium providing service.
Managing the right thing: Risk Management
Authors: Langenberg Ilse , de Wit Franklin C.A.
Published: November 2014

The product range of Hollandse Signaalapparaten consists of high‐tech military and civil products. These projects are characterized by uncertainty, which can cause financial, schedule, and performance problems. In order to keep control over the development and delivery of the projects, these problems must be tackled as early on in the project as possible. The method which enables to do so is called risk management.

Risks are uncertainties that can occur during the execution in every phase of a project and that have a significant negative impact on the performance, schedule or cost of the project. Risk management can be defined as the identification, assessment and mitigation of risks in order to develop and deliver, on schedule and within cost, a system that meets the performance requirements.

The risk management process consists of the following steps:

Identify Risks

Quantify & Prioritize Risks

Plan Risk Mitigation

Implement Risk Mitigation

Track & Report Risks

Between the distinguished steps important iterations take place and the steps should be carried out several times during each project.

Risk management is an important, if not the most important, aspect of managing projects. Or as Rear Admiral Bill Carlson, United states Navy once said: “If you are not managing risk, you are managing the wrong thing.”
Experiencing Requirements Engineering for a small system
Authors: Rouge A. , Callet S. , Moinon C. , Ermine F. , Moulis G
Published: November 2014

For software, there exists a community that can provide awareness and elements to justify the adoption of good engineering practices. For systems engineering, all this work is still to be done. This paper provides a modest contribution to such an endeavor, and more precisely in the area of requirements engineering for small systems.

The targeted goals for this article are:

Is model‐driven requirements engineering, as practiced for large systems, relevant to develop small systems ?

In which way can requirements engineering return on investment be demonstrated ?

Are many of the assumptions made against documentation and model‐based requirements engineering valid ?

These issues are investigated in the context of the FRUITS experiment that aimed at comparing documentation‐driven and model‐driven requirements engineering.

This experiment was carried out in 1998 by the systems department of MTI (Matra Transport International), a railway system provider. And Objectif Technologie provided some support to carry it out.
Providing Pragmatic Advice On How Good Your Requirements Are ‐ The Precept “Requirements Counsellor” Utility
Authors: James Laurence
Published: November 2014

One of the main goals of the Precept venture as defined in (Precept 97) was to “significantly improve the requirements elicitation process”. There are many ways in which this could have been accomplished ranging from the development of new elicitation methods to the development of new intelligent elicitation utilities. This article discusses the latter approach and focuses on a specific Precept utility termed the “Requirements Counsellor” which is designed to provide feedback on the perceived “goodness” of a set of requirements.
Requirements Management for True System Reusability
Authors: Jorgensen Raymond
Published: November 2014

This paper examines capabilities that are required to maintain a reusable development environment for products that are shared across many unique customer needs. Uniqueness within a product offering is driven by special needs or circumstances of the customer, which is translated by a project team into real system requirements. This uniqueness, though, must be managed in light of the product offering that is being built and maintained within a business climate. Diversity of customer needs is a significant cost driver that should be managed to preserve the integrity of the product offering as well as to keep costs under control. By appropriately managing requirements within the project and product development environments, a single, reusable product definition can be preserved that is both tailorable for each customer as well affordable for future customers.
Lessons Learned in Reengineering a Legacy System
Authors: Wimmergren Alan
Published: November 2014

This paper describes Experian's efforts to reduce schedule risk and to improve system quality by instituting a formal testing methodology, both for building a large replacement system and for long term ongoing evolution of that system. Successful testing depends, among other things, on thorough and relatively stable requirements. The paper also describes a weakness of using prototypes to refine requirements and describes how the company instead uses a multiple release software life cycle in order to define requirements incrementally.
Using Web‐Based Tools for Providing Program Management Information
Authors: Manuel Gregory C. , Sunday David A.
Published: November 2014

This paper discusses the development and use of web‐based tools to communicate real‐time, critical Program‐level information throughout an enterprise network of several hundred managers, engineers, and other professionals. The design and development of tools will be briefly described, as well as the integration and current application of the tools. Finally, a vision for planned future enhancements will be discussed

The Internet has increasingly become the route of choice on the information highway. For the few reading this who are not aware of the Internet (where have you been for the past ten years?!?!), it is a system by which computers are electronically linked. The Internet is used to transmit information among widely‐dispursed, even worldwide, computers without regard to platform type. An Intranet is a ‘subset’ of the internet when restricted to operations within a company or enterprise network. The environment described within this paper is that of an Intranet.

At the Aircraft Combat Systems Business of the Integrated Systems and Aerostructures Sector of Northrop Grumman, the development and use of intranets has been expanding dramatically. The number of websites and pages has proliferated with no signs of slowing in the near future.

There have been debates and discussions in this forum and others regarding the inclusion of Program Management (or Program Management tools) in the broad discipline of Systems Engineering. Within our enterprise element, however, this discussion has been tabled (for now, at least). The SE organization resides within the Program Management organization, and advancement of tools development for SE and for Program Management is being directed, deployed and managed by that organization.
The Case For a Common Integrated Enterprise Environment
Authors: Smith Byron
Published: November 2014

This paper addresses the aspects of a new enterprise wide software enenvironment Today companies expend millions of dollars transmitting data from one phase of the life cycle to another. This is because data generated in one phase must be regenerated in another phase by different software tools. The Common Integrated Enterprise Enviroment (CIEE) mitigates this problem.
Cross‐Tool Database Connectivity (XDBC): A“Rosetta Stone” for Engineering Methods
Authors: Rhodes Robert R.
Published: November 2014

Software Engineers who work with multiple modeling tools (such as engineers who use legacy methods to specify requirements for object‐oriented development teams) have sundry and unique needs. An XDBC (Cross Database Connectivity) model to address these needs has been implemented. This XDBC model generalizes tool and method specific artifacts so that remote access to previously isolated tool repository data and cross‐tool translation becomes possible.
Requirements management as a matter of communication
Authors: Ogren Ingmar
Published: November 2014

Requirements work all started as a dialogue between a vendor and an end user. Nowadays this dialogue has been complicated through introduction of marketing and acquisition personnel. This has led to introduction of requirements specifications, but the need for a basic dialogue is still there since a specification cannot capture the increase of knowledge that will always take place during development.

An efficient dialogue must not only include requirements, but also stated missions, problem management and understandable formalism for the system's structure and behavior.

Further study of the dialogue shows that requirements management must be managed as a process in parallel with processes for development and verification.
A Human Factors Integration Capability Maturity Model
Authors: Sherwood‐Jones Brian , Earthy Jonathan , Bowler Yvonne , Taylor Robert , Forster Melanie
Published: November 2014

Vendor capability assessment is a vital risk‐reduction component of pre‐contract award on major projects, and process improvement has become recognised as an important development in improving productivity and quality. This has become established for Software Capability Evaluation, using Capability Maturity Models. Similar approaches have been developed for systems engineering and are starting to see application.

The integration of human factors into systems development is now seen as essential for reasons of manning, safety and operability. The Human Factors discipline has matured and there are now stable standards, and a consensus over the processes involved appears to have developed. However, the means of ensuring Integration into system development are less well evolved.

A capability assessment scheme for human factors would extend existing software and system engineering capability evaluations to give assurance that complex systems, such as command centres, will be operable on delivery. This would be particularly valuable because human adaptability and variability pose difficulty for reliance on hard requirements. Traditional specification and test against pre‐defined acceptance criteria is inadequate to assure operability in complex systems. Contractors and/or partners in the development need to provide assurance of their ability to do human factors work within this dynamic project environment and deliver sub‐systems which integrate into the worksystem.

This paper summarises the state of the art in Human Factors process models and capability evaluation, sets out the requirements for successful HFI capability evaluation, and discusses a proposed implementation strategy.

The presentation will review the requirements for such a scheme and present the development and implementation strategy for a general‐purpose Human Factors Integration Capability Maturity Model.