bluuebunny/crossref_metadata_2025 huggingface dataset:
3 A Proven Approach to Requirements Baseline Management
Authors: Kennedy Larry M. , Thomas Donna , Weber Marie D.
Published: November 2014

Requirements baseline management can be the single most effective method used to guide system development and test. This paper presents a proven approach to requirements baseline management, requirements traceability, and processes for major system development programs. Effective baseline management can be achieved by providing: effective team leadership to guide and monitor development efforts; efficient processes to define what tasks needs to be done and how to accomplish them; and adequate tools to implement and support selected processes.

As in any but the smallest organization, effective engineering leadership is essential to provide a framework within which the rest of the program's engineering staff can function to manage the requirements baseline. Once a leadership team is in place, the next task is to establish processes that cover the scope of establishing and maintaining the requirements baseline. These processes will form the basis for consistent execution across the engineering staff. Finally, given an appropriate leadership model with a forward plan, and a collection of processes that correctly identify what steps to take and how to accomplish them, consideration must be given to selecting a tool set appropriate to the program's needs.
2 Quantifying The Qualitative: How to Avoid Vague Requirements by Clear Specification Language
Authors: Gilb Tom
Published: November 2014

Generally, the quantification of quality is not mastered by current culture. Qualitative requirements can always be specified with quantitative clarity. This paper gives pragmatic ideas on how to achieve this. The main concept is to define a ‘scale of measure’.
3 The Future Systems Engineering Data Exchange Standard STEP AP‐233: Sharing the results of the SEDRES Project
Authors: Johnson Julian , Loeuillet Jean‐Louis , Inderst Manfred , Nilsson Benny , Torne Anders , Candy Linda , Harris David , Alenia Federica Luise
Published: November 2014

Sharing design information during the systems engineering activities on large international projects within virtual enterprises faces many challenges, amongst them is working with heterogeneous sets of systems engineering tools. The adoption of neutral data exchange standards is one appropriate approach now well advanced in areas such as structural design (Computer Aided Design or CAD).

ESPRIT project 20496, ‘SEDRES’, has made significant progress in producing a neutral data exchange standard based on STEP (ISO‐10303), embracing systems engineering design data. SEDRES stands for Systems Engineering Data Representation and Exchange Standardisation. Co‐funded by the European Commission and running 1996–1999, SEDRES was initiated by Aerospatiale, Alenia, British Aerospace, DASA and Saab. Also contributing are the Universities of Loughborough, Linkoping, and the Australian Centre for Test & Evaluation.

This paper reports on the development and prototyping of the Capability/2 data model, on early exchange experiences, and on the related ISO STEP AP‐233 standardisation activity. Two companion papers describe the data model content and data exchange evaluation in detail.
4 The Design, Implementation and Management of A Systems Engineering Database
Authors: Collins Rob , North Lee
Published: November 2014

The work reported in this paper has been completed over the last 18 months on the Bowman project. The Bowman project will encompass the design, development, manufacture, conversion (rollout) and support of the new communications systems for the British Army. The Bowman contract will be valued in excess of £3 Billion and be delivered and installed over a period of 6 years.

This paper describes the design, implementation and management of a Systems Engineering Database (SED) for the project. The SED contains all of the Engineering data for the project. Each item of data is maintained with a full audit‐trail of change information. All information is cross‐referenced and controlled against all other dependent information.

Replication of data is eliminated and thus consistency and integrity are assured. Metrics collected on the database provide managers with a high degree of visibility of progress.

Experience of developing and using the SED is reported and advantages and problem areas are detailed.
1 Information Security Risk Management for Systems Engineers
Authors: Gauvain Tony
Published: November 2014

Designing security in at the start of system definition and design, rather than adding it later, has long been accepted wisdom. Sadly system security has often been found to be deficient, and attempts to add improvements later have often proved to be disastrous.

Systems engineers see security as a contribution to a system's value to be managed throughout the system's life‐cycle. Increasingly networked systems produce increased benefit, but also increased risk. Standards such as BS7799 are emerging as a necessary way of promoting trust between networked and inter‐dependent systems.

Information Security Risk Management is an essential part of the good health of a system's life‐cycle. Managing Risk requires its measurement. This paper shows how the complexity and urgency of the relationship between Assets, Threats and Vulnerabilities in order to calculate Risk and then determine Safeguards, can only be met by sophisticated computer aided algorithmic software applications.
2 Systems Engineering Applied to Integrated Safety Management for High Consequence Facilities
Authors: Barter Robert H. , Morais Bernard G.
Published: November 2014

Integrated Safety Management is a concept that is being actively promoted by the U.S. Department of Energy as a means of assuring safe operation of its facilities. The concept involves the integration of safety precepts into work planning rather than adjusting for safe operations after work activities have already been defined. The system engineering techniques used to design an integrated safety management system for a high consequence research facility are described. An example is given to show how the system design evolved over time.
1 Creating a Collaborative Systems Engineering Environment: …the need for collaboration in Systems Engineering and the technologies to support it
Authors: Sampson Mark E.
Published: November 2014

We have often heard that everyone on a project needs to be a systems engineer—or at least have a systems perspective. This paper suggests using emerging technologies to capture the complex interrelationships that are the essence of systems engineering and presenting them to the right people at the right time in a context they understand through the web…creating virtual systems engineers in the process.
4 Simulation Based (Systems) Engineering or Collaborative Based Acquisition
Authors: Zittel Randy C.
Published: November 2014

Simulation tools have been applied to an increasing range of ongoing product development programs and have significantly reduced development time, life cycle costs and improved system quality. Some improvements have reportedly reduced the overall development time by half and some individual activities by 30 fold as described below.

The computer revolution and age of information technology is creating more realistic, more capable and more diversified simulation tools. Because of the opportunities to benefit business processes, the natural market forces are driving all industries to find better ways to couple information technology, and simulation tools are a large part of this evolution. Beyond simply networking more and more computers and software together in ever‐increasing capability, an entirely new approach is emerging where product development and management tools are accessible as needed via internet‐like convenience. This new approach is staggering in its potential to further advance operations and design capabilities; and it's capturing more elements of industry everyday. It has the potential to revolutionize product design all over again.
2 “Simple Simon met a System” – bridging the gap to the rest of the organisation
Authors: Sillitto H.G.
Published: November 2014

Pilkington Optronics uses many elements of Systems Engineering and product development best practice. The company is now tailoring a very competent, but complex, Systems Engineering methodology to provide a “smart but simple” core method, useable at all levels of our business from complex sensor systems to individual components; and by managers and marketeers as well as engineers.

The core method provides a consistent framework for communication between Systems Engineering and the rest of the company. It is compatible with the Thomson “MIST” Systems Engineering methodology, and consistent with both “Systems Engineering” and “world class product development” paradigms. These two paradigms are closely related. A business such as ours operating across the system/technology interface has to be able to operate seamlessly between the two.

This paper reviews recent experience, discusses some of the problems encountered, and outlines the approach to a more integrated cross‐project cross‐discipline method.
3 TAILORED RISK MANAGEMENT
Authors: Palmer John A. , Dechoretz Jason A.
Published: November 2014

United Defense is the prime contractor for Crusader, a high performance self propelled howitzer system for the Army. In managing this Integrated Product and Process Development program, United Defense has utilized an aggressive risk management approach. This approach involves five steps: identification, assessment and analysis, mitigation, tracking and closure. Each step is briefly described, but emphasis is placed on new methodologies developed to improve the accuracy, acceptance and believability of quantitative technical, cost and schedule risk assessments. An inhouse effort was successfully employed using program team working groups to develop risk category/threshold definitions and risk scales calibrated to the Crusader program. An electronic database supported life cycle for conducting and coordinating risk assessments has also been successfully employed. A “Top Ten” risk list has been routinely published based on a composite Technical/Cost/Schedule risk rating for all key Work Breakdown Structure items. The development of this process, its testing, results and management application are described.
4 Tailoring Generic Systems Engineering Processes: an agent‐oriented method
Authors: Murdoch John , McDermid John A. , Wilkinson Philip
Published: November 2014

The task of tailoring generic systems engineering process models to the particular needs of an organisation is addressed. Current process standards distinguish between different agents involved in a development process, for example, customer, developer and supplier roles. This approach is linked to existing agent‐oriented process modelling techniques, leading to an agent‐oriented method for tailoring systems engineering processes. Four process representations are developed to support the outline method. Objectives of the work include the embedding of systems engineering activity within the total end‐to‐end product development process, the organisation of legacy procedural documentation and support for defining information, tool integration and related needs.
1 The Resource Management Segment ‐ A Case Study in the Role of Software Architecture in the Systems Engineering Process
Authors: Gallini Thomas E.
Published: November 2014

This paper provides a case study of the development of the Resource Management Segment (RMS) of the Air Force Satellite Control Network (AFSCN). The focus of the study is the role of the system architecture in the systems engineering process for this project. The RMS project was an attempt to modernize and consolidate software used for AFSCN resource scheduling, orbit analysis, and resource monitoring. The approach taken by the responsible contractor was to do a complete object‐oriented development using the 4+1 View methodology described by Phillipe Kruchten in (Kruchten 1995). Specifically, this paper outlines the architectural approach, describes key issues that arose, and discusses the processes that surrounded the architecture. The discussion is focused on how the architecture fits into the RMS systems engineering approach. Finally, some lessons learned are summarized.
2 An IT Enterprise Architecture Process Model
Authors: Grossman Ira M. , Sargent James
Published: November 2014

This paper describes the authors' experiences using a process to develop Information Technology (IT) Enterprise Architectures. An IT Enterprise Architecture is a blueprint that explains how all the IT and Information Management elements work together as a whole. The IT Enterprise Architecture is characterized by four views: Work and Location, Information Sets, Applications, and Technology Infrastructure. The IT Enterprise Architecture Process is based on a seven step model. The seven steps are: (1) Define the IT Vision, Objectives and Principles, (2) Characterize the IT Baseline, (3) Create the IT Target Architecture, (4) Identify the Immediate and Future Opportunities and Perform a Gap Analysis, (5) Develop Migration Options, (6) Implement the IT Architecture, and (7) Continuously Review and Update IT Enterprise Architecture.
4 Analyzing Tool Interoperability Relative to Systems & Software Engineering Data Workflow
Authors: Ahearn Susan M. , Brown Jeffrey A. , Hruby Jim J.
Published: November 2014

At Raytheon Systems Company, Fullerton Operations, systems and software engineering have taken the approach that programs need a ‘tool thread’, which supports model‐based development with connectivity across all engineering phases. The study group has conducted an extensive analysis, examining many tools for each of the system engineering domains — requirements management (RM), systems architecting (SA), system software development (SW), and system integration and test (I&T). This analysis scored not only the performance of the tool in the applicable engineering domain and its support to model‐based development, but also scored a tool's interfaces to other tools. This analysis is a practical tool selection approach supporting the three tenets of simulation‐based acquisition: integrated engineering environment, iterative acquisition process, and evolved acquisition culture.
1 Systems Engineering in the 21st Century
Authors: Hitchins Derek K
Published: November 2014

While every age has its vicissitudes, western society is exhibiting some unique, well‐defined and persistent trends that will present major social challenges in the next century. Some of these trends are identified and their implications briefly described. Population growth continues, as does our global failure to recycle renewable resources, such as fresh water.

At the same time, systems engineering is continuing to evolve its problem‐solving potential, to the point where it could, and may need to, contribute to “social systems engineering”. Social engineering is all around us. Present political practice is raising society to a dynamic level in which social “scares” are invoking nation‐wide hysteria, as with BSE. Meanwhile the tempo of life and warfare rises inexorably.

Systems engineering can help. By understanding the behaviour of dynamic socio‐economic systems, it is possible to create societal models that self sustain and which do not “collapse” in the familiar domino syndrome.

The key, as so often in systems, is coupling and binding—of and between social groups and structures. Unpredictable non‐linear dynamic behaviour is promoted by increased coupling, while stable behaviour is exhibited by tightly‐bound functional groupings. Variety is an important factor, also—not too much, but not too little, either. Stable systems are comprised of complementary parts, implying variety with co‐operation. Size appears to be a factor. Too big, and a social structure fractures. Too small, and it cannot self‐sustain. Putting these and other systems engineering ideas together enables a variety of potential societal structures, organizations and “ways of living” to be created—a vision of the future.
3 Mature Procurement of Large Scale Systems: A Better Way to Buy
Authors: Courteney H. , Ruston S.
Published: November 2014

This paper examines current procurement practices in the systems engineering industry, and identifies some underlying features of the system that sometimes make it fail. It will mainly focus on the structure of rewards within and between organisations, and will also touch briefly on the unrealistic treatment of requirement specification. Finally it will be argued that a more mature approach to procurement is needed, and describe some features that ‘mature’ organisations might be expected to have.

Performance metrics and fixed price contract bids have been central in the systems engineering industry for the past decade. These have provided some important management tools, but there can be a damaging downside to these practices. This paper will examine a characteristic of some metrics within companies, contractual arrangements between organisations, and procurement policies, that can result in the opposite outcome to the intended goal.

A further point will examine the unrealistic assumptions about requirement specifications made by current commercial practice. It will be suggested that large scale projects based upon such false premises are inevitably flawed from the outset, and that a more realistic approach is needed to achieve program plans that actually deliver a satisfactory product on time and within budget.

Finally, it will be suggested that the next generation of management and commercial policy should refine their current approach in order to take account of these factors. A possible means by which this might be achieved is outlined.
4 System Engineering for Faster, Cheaper, Better
Authors: Forsberg Kevin , Co‐Principals Harold Mooz
Published: November 2014

The continued thrust to increase competitiveness and shorten time‐to‐market in industry, and the more recent effort to “reinvent” the procurement process in government, has created sustained pressure to adopt new paradigms for aerospace projects. The banner of “faster, cheaper, better” places emphasis on use of Commercial Off‐The‐Shelf (COTS) systems and components, Non‐Development Items (NDI) (previously developed products that are not commercially available), and advanced, lightweight components.

To make the concept of “System Engineering: Sharing the Future” effective, we must learn from the past. This paper reviews two successful and two unsuccessful projects, examining the processes they followed compared to the “traditional” approach used from the 1960s through the 1990s. The results illustrate that, without a valid and comprehensive process, “faster and cheaper” does not automatically lead to “better,” and, conversely, that an intelligently tailored process can greatly improve the success rate for “faster, cheaper, better” projects.
4 Shuttle Orbiter Production Change Impact Assessment Process ‐ A Collaborative Team Effort
Authors: Hines James E. , Weeks Donald P. , McCallister Timothy P. , Ouellette Fred A.
Published: November 2014

The present Space Shuttle program is one in transition ‐ both from the government agency and the contractor level. NASA is restructuring the management of the Space Shuttle Program by turning over the reins of the day‐to‐day operations to a prime contractor, United Space Alliance (USA) ‐ a joint venture partnership with Boeing and Lockheed Martin as major subcontractors. This move is intended to save millions of dollars in costs by eliminating duplicate resources, streamlining operations, and reducing nonessential program requirements. Most separate shuttle related contracts have been consolidated into one Shuttle Program. While this consolidation effort is taking place, NASA, USA, Boeing 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 is the way people think and do their work. Changes have been made emphasizing working together as teams and improving the processes they use. A critical process, that was changed, is the Orbiter modifications and upgrades change process. This process covers all changes to the Orbiter hardware, which fix flight to flight anomalies (modifications) as well as make upgrades, which increase safety, meet upcoming manifests, improve supportability and reduce costs. This paper deals specifically with process improvements made to the change control process methodology and implementation procedures (known as the change impact assessment process) by NASA, USA and Boeing to be more proactive and cost effective.
1 Systems Analysis of Personal Transport
Authors: Lowson Martin V.
Published: November 2014

Analysis of current types of public transport shows that they are mismatched to geography of modern towns, the form of which is dominated by the availability of the car. The requirements for a future urban public transport system are defined in general terms. The requirements cover those of the user, the urban environment, and technical requirements. It has been found that exploitation of existing technologies can meet these requirements in a new type of transport. This can be described as a personal automatic taxi system running on its own guideway network. The new transport system, which is an improved version of types previously proposed under the general description of Personal Rapid Transit (PRT), appears to offer an attractive and sustainable alternative to the car for urban transport in the next century.
4 Telecom and Defense Systems: Exploring Differences in the Practice of Systems Engineering
Authors: Martin James N.
Published: November 2014

Much of the work in developing process, methods, and tools for systems engineering (SE) has been performed in, or on behalf of, the defense and aerospace business domains. It is shown in this paper that there are significant differences in how systems are developed in these traditional domains of SE versus the telecommunications industry. Because of this, there will be difficulty in implementing “standard” SE process, methods, and tools in other domains than defense and aerospace. In order to successfully “transition” good SE practices to other domains, it is essential that the differences in implementation be understood and accounted for.
1 Implementing Systems Engineering on a CERCLA Project
Authors: Beitel George A.
Published: November 2014

The Comprehensive Environmental Response, Compensation, and Liability Act (CERCLA), enacted in 1980, provides a regulatory and legal mechanism to reduce risks from prior disposal of hazardous and toxic chemicals. Regulations, Standards, and Guidelines have been published to further define the CERCLA Process. The OU 7–10 Staged Interim Action Project at the Idaho National Environmental and Engineering Laboratory (INEEL) is a CERCLA project working to remediate a pre‐1970 disposal pit in which transuranic materials had been disposed. This paper analyzes the CERCLA process from a systems engineering perspective and describes how systems engineering is implemented on this project.
1 Exploiting Web‐Based Technology to Foster IPDT Productivity
Authors: Brown Phillip J. , Lavender Jack K.
Published: November 2014

Very few organizations are able to show a “bottom line” impact directly attributable to investments in information technology. While many reasons are postulated for this failure to produce measurable improvements, a large part of the solution appears to be getting the userinvolvedin defining requirements, identifying cost benefits, and implementing reengineered product development processes.

This approach was tried and validated for the Integrated Product Development Team (IPDT) on which it was applied. The product was a ground based weapon system. Results of the experiment exceeded expectations. Utilization of the system engineering process was an essential element in making this a successful endeavor.

Described herein is the process by which IPDT perspectives were changed, the role of cost benefit analysis, results obtained, and what was learned about transforming a well‐established culture.
2 Managing Research and Development Projects: A Systems Engineering Approach in the Early Stages of Design
Authors: Brink James R. , Peisert Gregory D. , Ventresca Carol
Published: November 2014

Earlier is better. The notion that decisions made early in the design process profoundly influence subsequent product cost and quality is well understood and widely accepted. Making better decisions earlier means we can avoid costly mistakes and dead‐end paths. For example, in the United States Department of Defense, 60 ‐ 70 percent of most weapon systems' costs are incurred subsequent to initial deployment of the system.1 Said another way, by the time a system is deployed, we are “locked into” most of the system's costs by the decisions we made during its design and subsequent production. Thus, making more informed decisions early in the design of a system can have far‐reaching life‐cycle cost implications. The questions thus become: How early is early? What process(es) can be applied early?

This paper presents an approach for applying systems engineering in the research and development (R&D) phase of system design. The approach centers on the notion that with quantitative methods and an underlying information technology infrastructure, project managers in R&D can make use of the information that is critical to making better decisions. The hypothesis is that better processes produce better products. A basic premise of this approach is that the use of quantitative techniques in R&D is just as appropriate and powerful as their implementation in a production environment. Specifically, modified six sigma methods can be applied early in the design process thus providing the manager with a measurably better way to evaluate and decide among competing design approaches. Having knowledge of the techniques, coupled with a set of tools to implement the approach, project managers can bring technology in R&D to a point that it can be transitioned into a “real” system.

The approach and tools presented in this paper have been adopted from industry best practices under U. S. Air Force sponsorship. After presenting the approach and associated tools, we discuss lessons learned based on U. S. Air Force pilot projects in which these methods are being employed to improve the affordability of high‐technology products.
3 Total Technology Development – Shifting the View in Systems Development
Authors: Schulz Armin P. , Clausing Don P. , Negele Herbert , Fricke Ernst
Published: November 2014

Technologies have become a critical issue within product development, since superior technologies are the foundation for successful products. Technology development until now has suffered from a fuzzy innovation process based on trial and error in a high‐pressure product development environment, often leaving no time for real innovation. Technologies developed under these circumstances seldom become superior, robust, mature and flexible, which are the criteria considered to be critical for technologies to provide competitive advantage.

In this paper the idea of separating technology development from product development into a steady technology stream is evolved. This enables companies to supply their product development programs with winning technologies at the right time. A four‐phase process framework to support and catalyze the technology development cycle is introduced, discussing the first phase in depth. The proposed framework is based on an integration of five major development methodologies and aims at providing competitive advantage to companies by emphasizing superior, robust, mature, and flexible technologies.
1 System Engineering and Simulation Tools for Naval Combat Systems
Authors: BELANT Thierry , GASMI Bernadette , GUILLERME Marie‐Pierre
Published: November 2014

This paper describes how modeling and simulation tools may be used to support the different phases of the System Engineering process. It is based on the experience acquired by THOMSON‐CSF/NCS‐France in Naval Combat Systems design and development.

Modeling and simulation tools cover studies and analysis at different levels of the System Engineering process:

Throughout the proposal phase:

Tactical and operational level where a simulation tool is used to assess the performance and effectiveness of a Combat System,

Throughout the program phase :

System requirement analysis level,

System design to consolidate the performance of system hardware and software architecture.

This paper shows how the authors use the technico‐operational simulation tool 1TACSIT to assess the performance of a Naval Combat System and the 2SESworkbench™ tool to assess a system architecture design.

Two examples based on real projects illustrate the benefits of modeling and simulation.
4 RISK MANAGEMENT FOR THE NEW MILLENNIUM
Authors: Hillson David
Published: November 2014

Project risk management has been recognised for some time as a formal discipline in its own right, and there is growing consensus on the elements which comprise best practice. However the project risk management field has not fully matured and there are a number of areas requiring further development. This paper presents the author's perceptions on the directions in which project risk management might develop in the short to medium term, comprising five key areas. These are : organisational bench‐marking using maturity model concepts; integration of risk management with overall project management and corporate culture; increased depth of analysis and breadth of application; inclusion of behavioural aspects in the risk process; and development of a body of evidence to justify and support use of risk management.
1 A Proven Approach to Driving Quality into the Bottom Line
Authors: Thomas Donna
Published: November 2014

Today's software development efforts need a conscience to drive quality into the bottom line. Historically, software development efforts have been overrun and delivered late, and unfortunately, the quality has suffered. A “proven” roadmap to achieving mission success for the quality assurance organization as well as the program will be provided in this paper. The approach has been taken with several programs contributed to improving total customer satisfaction, improving productivity, improving the reputation of the Quality Assurance department and growing the business.
2 The Transition from Spacecraft Development to Flight Operations: Human Factor Considerations
Authors: Basilio Ralph R.
Published: November 2014

In the field of aeronautics and astronautics, a paradigm shift has been witnessed by those in academia, research and development, and private industry. Long development life cycles and the budgets to support such programs and projects has given way to aggressive task schedules and leaner resources to draw from – all the while challenging assigned individuals to create and produce improved products or processes. However, this “faster, better, cheaper” concept cannot merely be applied to the design, development, and test of complex systems such as earth‐orbiting or interplanetary robotic spacecraft. Full advantage is not possible without due consideration and application to mission operations planning and flight operations. Equally as important as the flight system, the mission operations system consisting of qualified personnel, ground hardware and software tools, and verified and validated operational processes, should also be regarded as a complex system requiring personnel to draw upon formal education, training, related experiences, and heuristic reasoning in engineering an effective and efficient system.
3 Inter‐Stakeholder Behavior Analysis and Design Engineering
Authors: Mayhew Mick , Alessi Sam
Published: November 2014

Systems Engineering encounters situations where stakeholders disagree. Disagreement shows itself both in the form of different claims and through particular human interaction patterns. In situations of strong disagreement, systems engineers can benefit from social science methods. This paper presents such an approach that combines elements of cultural anthroplogy, family systems therapy, and systems engineering. It is intended to be used to document stakeholder behavior in a more rigorous and defensible manner and to point toward additional technical information that can benefit the systems engineering effort. Knowledge of stakeholder interaction patterns can also enable engineers to form better questions during requirements inquiry and can lead to a healther overall team environment.
3 An Implementation of the Analytic Hierarchy Process (AHP) on a Large Scale Integrated Launch Vehicle Avionics Systems Engineering Architecture Trade Study
Authors: Wagner James F.
Published: November 2014

The objective of a large scale integrated avionics architecture trade study is to consistently and fairly choose among alternative architectures. A structured process is required to accomplish this objective. The Analytic Hierarchy Process (AHP) provides a framework, and was used to quantitatively choose among four potential alternative avionics complement architectures with respect to meeting avionics design objectives and mission needs. This paper focuses on an implementation of the AHP on a large scale integrated launch vehicle avionics systems engineering architecture trade study. Several key characteristics of the four alternative architectures are identified and form the evaluation criteria for the trade study. AHP was used to carefully evaluate the relative importance of the criteria, and aide in the comparative judgements and synthesis of the criteria priorities and the selection of the alternative. The alternative avionics solution selected is a modular, federated (pseudo distributed) architecture of subsystems which results in the most efficient overall launch vehicle management.
1 Managing the Rework Cycle not the Schedule ‐ A Project Management Paradigm for the Future?
Authors: Mawby Dave
Published: November 2014

Many projects fail to deliver against their targets because conventional project management techniques are failing to cope with the project's dynamic environment, complex interactions and the multitude of ‘soft’ / people issues. If conventional techniques do not cope with the complicated factors that affect our larger projects, are there any better methods? This paper demonstrates that better management of the rework cycle and application of dynamic project modelling technology can provide a more robust means of controlling complex projects than many of those in common use today.

Combining this insight with the capability of anticipating and managing complexity through dynamic project modelling offers tomorrow's project managers the ability to build more robust programme plans. Project managers will then be better able to cope with pressures present within the project's environment and to respond more effectively to change. This understanding of the rework cycle and application of dynamic project modelling offer a new and more powerful project management paradigm for the 21st century.
1 Concept Analysis: Modeling and Organization Transformation
Authors: Oliver David W.
Published: November 2014

This paper models the concept analysis of a new freight locomotive product as an example of modern product development and organization evolution. It combines the producer business strategy with the purchasing railroad needs and the needs of the railroad customers, (Oliver 1997), (Gale 1994). Modeling techniques are shown for requirements elicitation. The results are tied to technical engineering effectiveness measures using analytical techniques and the less formal methods of TQM and Six Sigma, (Saaty 1983), (Harry 1994). As the example progresses there is an identification and presentation of critical engineering performance calculations and trade‐off to establish system level design tied directly to customer perceived value and quality and to business strategy.

As the locomotive design changes emerge, concurrent changes to the business structure, organization and motivation factors also emerge. Modeling makes Concept Analysis rigorous and provides transformation to the notations of recipients.
Starting at the Finish Line
Authors: Armstrong James R.
Published: November 2014

The front end of the program is given a lot attention in the world of systems engineering. For instance, requirements writing is a favorite subject. The back end activities are usually included to the extent of making sure the requirements cover them appropriately. Otherwise, the post‐design activities are often left to be addressed in a just‐in‐time fashion.

The most critical activity of this period, and indeed the program, has to be customer acceptance. Waiting until the time of acceptance to address the issues is high risk. Even the standards in use and development keep the user at arms length.

There are many lessons learned that substantiate this as a high risk approach and provide better approaches. This paper takes a look at the current status and brings these lessons learned together to identify early tasks that should be included in programs to reduce the risk, schedule and cost of non‐acceptance by the customer.
Pictorial Representation of Communication Satellite Resource Allocation Using STK
Authors: Shamash Micah , Wells Tyler
Published: November 2014

Over the past decade the need for communication satellites has grown dramatically, with the main consumer no longer being strictly the government cost‐effectiveness has become a main issue. Designing a communication satellite that will be cost effective, as well as, efficient for a given user community is often a daunting task; it requires analyzing many different hardware configurations to determine which will most effectively service the user community. Using a database of typical users and analyzing hardware trade‐offs is often times a preferred method of solving these types of analytical problems. More times than not this labor intensive analysis is done by hand, but to get reliable, easily reproducible results a “tool” can be developed to automate the analysis.

In looking at an analytical problem as extensive as communication satellite resource allocation, simple numerical data does not always provide for the best answer. This paper describes our experience using Satellite Tool Kit (STK) a COTS product to graphically display the results of our satellite resource allocation tool. This tool is currently being used to analyze hardware trade offs for the design of a communication satellite constellation.
Concept Mapping as a Communications Tool in Systems Engineering
Authors: McCartor Mary Morgan , Simpson Joseph J.
Published: November 2014

In any “deep learning” situation, and in communicating in particular, understanding will be enhanced by using techniques that more closely fit the nonlinear structure of our thinking processes. This idea is particularly relevant to systems engineering, which deals with so many interrelated concepts—concepts whose parts are often handled by separate organizations with different “languages” and foci, presenting additional barriers and confusions in understanding. In the figures in this paper, we have tried to show a variety of patterns that concept mapping can be cast in, for flexibility and interest. Our experience in Boeing is that such an approach simplifies, deepens, and clarifies communications, while providing the opportunity to find ways to develop more complete and better integrated concepts.
Developing and Teaching a System Architecting Process
Authors: Cabrera Orlando J.
Published: November 2014

This paper will present the definition and development of a System Architecting (SA) process as well as the SA class that was subsequently developed. Under the auspices of our Total Quality Management Program (TQM) and beginning in 1995, a group of senior System Engineers at Harris Government Communication System Division (GCSD) began meeting on a regular basis. The group's goals were to define SA and its application to GCSD, establish a processes for implementing architectural development and prepare an internal SA class. The group, named the System Architecting System Improvement Project or SA SIP, successfully accomplished its goals. In addition, the SIP contracted with the University of Southern California (USC) during the spring and summer of 1996. USC developed an intensive 48‐hour short course on System Architecting for Harris. The USC material was also used in the development of the internal class. The SIP developed class has been taught to System Engineers throughout the Electronic System Sector (ESS) of Harris since the summer of 1997.
A Fully Integrated Engineering Approach For Navy Theater Wide Theater Ballistic Missile Defense
Authors: Hyer Scott A. , Meshel David C. , Kovel Maxim I.
Published: November 2014

A cornerstone of any successful system development is in its engineering approach and planning. A concisely defined process, complete with objectives and products identified at each stage is necessary to draw multiple organizations together in working toward a common goal. This paper identifies the major parts of the engineering approach being taken on the U.S. Navy Theater Wide (NTW) Theater Ballistic Missile Defense (TBMD) Program. Guided by the general guidelines prescribed by the EIA‐632 Interim Standard (dated 1994), the authors developed a Systems Engineering Management Plan (SEMP) which defines the organizational structure and teaming arrangements, task responsibilities, engineering process, products, and schedule events.
CMMI Assessments
Authors: Ahern Dennis M. , Dunaway Donna K.
Published: November 2014

The CMMI Product Team has created a set of assessment requirements that are to be satisfied in any full, comprehensive assessment method for use with the CMMI models. The CMMI Assessment Requirements (CAR, v. 0.1) is an extension of prior work done at the SEI on a CMM®‐Based Appraisal Framework (CAF, v. 1.0). The CAR was written to comply with the emerging ISO/IEC 15504 standard, for wider applicability. The team has also created a comprehensive CMMI assessment method, called the Standard CMMI Assessment Method for Process Improvement (SCAMPI). This method is based on the SEI's CMM‐Based Appraisal for Internal Process Improvement (CBA IPI) and the SECM Appraisal Method (EIA/IS 731, Part 2). Pilot tests for CMMI products, using SCAMPI, are planned for 1999–2000.

The CMMI Product Team will also provide guidance for tailoring the CAR to address the needs of an organization that wishes a less‐than‐full or partial assessment. Such partial assessments, e.g., initial assessment or quick‐look, would provide less rigor than SCAMPI, but would also require fewer resources.
A Systems Engineering Approach to Simulation Based Acquisition (SBA)
Authors: Huang Paul , Sleder Pradip Kar Al , Kato Hiroko
Published: November 2014

Modernization of defense industry has come a long way technologically. The complexity and sheer magnitude of modern weapon systems represents a major design challenge. The involved life‐cycle support of those systems is very complicated. All of those added together will make the cost of any new weapon system prohibitively high. Facing this new challenge, United States Department of Defense (U.S. DoD) proposes an initiative, namely the Simulation Based Acquisition (SBA), to reduce the acquisition cycle. This initiative has significantly impacted the manner in which new weapon systems are concepted, designed, integrated, tested, produced, and supported throughout their life cycles. This paper presents a systematic approach to this DoD initiative. It leverages past experience in research and development in system integration related technology. Combining with lessons learned from executing modern weapon systems development, this process has the potential to provide the industry with a standard SBA process.
Open Systems and the Systems Engineering Process
Authors: Hanratty J. Michael , Lightsey Robert H. , Larson Arvid G.
Published: November 2014

The open system approach is both a technical approach to systems engineering and a preferred business strategy that is becoming widely applied by commercial manufacturers of large complex systems. It has the attention of DoD management who have mandated its use by DoD systems developers. Why? Because without such a change in system development practice, DoD risks being unable to maintain continued superior combat capability affordably!

Today, legacy weapons systems continue to be developed with their own, often unique and frequently closed, infrastructures, making upgrading or modifying them over their expected lifetimes (20 to 40 years) both problematic and expensive. Also, reduced procurement budgets and increased dominance of commercial technology cause acquisition managers to increasingly rely on commercial markets for affordable product development and support. So, as DoD's role shifts from being a technology producer to being a technology consumer, it relies more on commercial products whose design is not controlled by DoD and whose lifetimes are much shorter and more volatile than the weapons systems they support (e.g., years vs. decades). As a result, acquisition managers risk relying on unique products provided by a single supplier at high non‐competitive prices and with little opportunity for technology insertion by other suppliers.

This paper discusses the need for a rigorous systems engineering process which incorporates open systems concepts and principles — where resulting system designs more readily accommodate changing technology to achieve cost, schedule, and performance benefits by promoting multiple sources of supply and technology insertion.
1 Systems Engineering ‐ a pragmatic approach
Authors: Fletcher M J
Published: November 2014

This paper provides a personal view, built from practical experience, that considers and contrasts the approaches of developing a System from a “top down” decomposition of requirements with the historical methods of designing from the “bottom up”. The former follows the purist approach assuming an all‐new system development. The latter looks at the “traditional” approach of evolving systems out of a number of almost independently developed equipments or sub‐systems.

The paper proposes a pragmatic approach that retains both these techniques in Systems Engineering. In particular, this approach is applied to the reuse of Components, Equipments or SubSystems in the design of a new system.
Establish A Baseline Assessment to Manage Risks Using Risk Matrix
Authors: Willhite Anne Marie , Norton Darcy R.
Published: November 2014

This document describes a baseline risk assessment process and tool that was developed for the Air Force Electronic Systems Center (ESC) and based on Risk Matrix—a structured way to identify, prioritize, evaluate, and manage the impact of key risks on acquisition and development programs. The basic principles can be used by anyone who needs to manage risks.
A Design Attribute Methodology for the Identification and Ranking of Functional Integration Risk
Authors: Vick Jeffery D.
Published: November 2014

It is well known that applying validation methods during product development will reduce product functionality problems. Generally, the earlier an error is found, the less it costs to resolve it. The traditional amount of validation analysis applied during the detailed design of derivative commercial airplanes is being challenged due to market pressures to cut costs. Without sufficient validation, a significant number of functional integration problems can remain undetected until discovered late in development by flight tests or during airline operations – which translates into cost overruns. A tradeoff exists between making planned investments in validation analysis and incurring unplanned costs later. Having the ability to identify where in the design to focus design validation analyses is essential for assuring a functionally integrated product and minimizing total development costs. A design‐attribute risk assessment methodology based upon search theory, technical risk analysis concepts, and systems heuristics was developed and applied for this purpose.