bluuebunny/crossref_metadata_2025 huggingface dataset:
APPLICATIONS OF MODERN SYSTEMS ANALYSIS PARADIGMS TO THE DEVELOPMENT OF COMPLEX SYSTEMS
Authors: Biernacki J. , Bodi R. , Wagner R. , Juhasz J.
Published: November 2014

The overwhelming volume of requirements and specifications associated with large complex multi‐disciplinary system development projects pose exceptional challenges to project engineers in their efforts to track and manage the hardware design response to the requirements and specifications. Previous systems engineering approaches using available methodologies and automated computer tools have been increasingly difficult to apply as the project complexity grows. Without effective methodologies and tools ensuring that system functional requirements are accurately interpreted and flowed down to the specification level has been difficult. Likewise, the allocation of functions to the architectural components, assemblies, and software including the interfaces among interacting systems has been hampered by inadequacy of conventional tools. This traceability extends to the identification of verification requirements associated with all elements of the system.

The demand for increasingly complex systems, coupled by the ever‐increasing sophistication of available supporting engineering and management tools, has spawned a variety of modern methodologies for addressing complex development tasks. These new paradigms, aided by powerful computer‐based software tools, provide a structured development framework to:

Instill a disciplined focus on system engineering based on requirements

Establish a comprehensive, unambiguous path of trace‐ability from top‐level requirements to detailed design

Provide a common means for communicating complex system behavior to all program participants via graphical depictions

Develop a platform for the systematic support of the verification and test planning activities

Analyze the failure propagation behavior of the system for assessment of multiple failure modes and effects, safety and hazards analyses, redundancy management and failure tolerance

Create a simulation environment to study system behavior for analysis of performance, interfaces, and anomalies given a variety of hypothetical operational scenarios.

This paper discusses the application of such a methodology, known as Enhanced Modern Structured Analysis (EMSA), which is being used in the analysis of the Space Station Freedom. The EMSA method has been derived from the methodologies of leading experts in the field of systems analysis, with suitable enhancements which were found necessary to accommodate the Space Station Program needs. The software to support this particular analysis is the RDD‐100 (TM) package from Ascent Logic Corporation, as well as the Failure Environment Analysis Tool (FEAT) developed by Lockheed Engineering and Sciences Company. The hardware platform is an Apple Mactinosh IIfx(TM).

Due to the prolific nature of general systems analysis, coupled with the power of a sophisticated computer platform and the flexibility of the methodology, this paradigm is recognized as having a wide applicability for analysis.
Enhanced System Engineering Efficiency in the 21st Century
Authors: Zajac Blair
Published: November 2014

The trend has been to increased system complexity. It is anticipated that the trend will continue into the 21st century. This paper addresses the issues of how to accomplish system design (trade) and performance analyses in this environment. In particular, we examine an analysis technique that relates to both implementation methods and task partitioning.

Recent advances in graphical programming computer technology have opened a new vista to enhancing the system engineering process. We start out with an introduction to this new technology. A general approach to using this methodology is then presented. This is followed by a specific application example using LabVIEW, a graphical programming language available on Macintosh computers.

This paper is closed with a discussion of a technique where a target computer could be automatically programmed directly by the system engineer.
1.5.4 ROADMAP FOR SUSTAINED COMPETITIVE ADVANTAGE
Authors: Rhodes Donna H.
Published: November 2014

Sustaining a competitive advantage in the global marketplace is a continuous challenge. Fast paced changes in technology, re‐engineered processes, revolutionary acquisition reforms, and highly sophisticated enabling techniques and toolsets are impacting our business. Without a proactive approach, it is easy to fall behind or “get off track”. Well‐defined roadmaps are needed to guide growth and change. While many businesses today develop business and technology strategies, these are not enough. A Systems Engineering Core Competency Strategy is equally essential to engineering organizations who will remain competitive in the next decade. This paper presents the key elements of this strategy, including recommendations for its development and use, and lessons learned based on a decade of experience.
3.1.1 SYSTEM ENGINEERING THE PEOPLE SYSTEM
Authors: Minds Kevin S.
Published: November 2014

This paper describes an architecture study for a system with the objective of developing a corporation's core competence in Systems Engineering. The study focuses on people as the key resource to be leveraged upon in order to achieve this objective. A system called the People System is postulated and defined by applying a tailored version of the Systems Engineering process.
3.2.1 Matching Tools to the Systems Engineering Process
Authors: Oliver David W.
Published: November 2014

The goal of this paper is to map the steps of the systems engineering process to classes of tools. This is an application of systems engineering with models and objects. It results in a rigorous definition of the functions performed by each tool class, the information captured by each tool, where in the engineering process the tool is used, and the interfaces between the tools. This paper utilizes the tools taxonomy described previously, [Oliver, Steiner 1994].

The tools automate the systems engineering process. Each kind of tool performs particular functions and captures particular sets of information. In this paper the tools are mapped to a meta‐model for the systems engineering process. That meta‐model describes the core systems engineering steps and gives an information model for each step, [Oliver 1994a]. The meta‐model of the systems engineering process describes the engineering steps that have emerged over the years as best practices. It describes the sequences that are imposed by reality and defines as concurrencies those steps that may be performed either concurrently or in several different sequences. The mapping then establishes the interfaces between tool types; how the tools should integrate.

This paper focuses on the tools used in association with requirements engineering and management as a specific example. An NCOSE survey of member priorities for tools disclosed that tools for requirements engineering and management were a top concern and the Tools Technical Committee elected to focus 1994 and 1995 efforts on this topic. This approach, using models and objects is rigorous and readily altered as new tools classes or engineering steps are identified through engineering experience.
3.2.3 COTS Integration and Support Model
Authors: Waund Carolyn K.
Published: November 2014

Programs requiring system development with high content of Commercial off the Shelf (COTS) hardware and software are becoming more prevalent in the federal marketplace. Much of the emphasis on COTS solutions is driven by the need to lower the cost and deployment time of new systems to meet reduced budgets. Another factor is the availability of powerful COTS information systems technology to facilitate government processes.

Loral Federal Systems (LFS) has in recent years moved to address this important systems integration market. Individual projects achieved varying degrees of success in adapting traditional system development processes and management practices in the high‐COTS environment. This project experience is a key resource. This paper highlights the results of an LFS initiative to use lessons learned on recent COTS‐based projects to define a COTS integration and support model for guiding future projects. This initial model will be refined and matured by the LFS organization in the future. This paper provides: (1) observations about the current state of COTS integration, (2) description of a model for a COTS integration and support process, and (3) discussion of COTS project lessons learned and their incorporation in the COTS process.
7.2.1 A REQUIREMENT AND VERIFICATION TRACEABILITY TOOL
Authors: Elmore Donald C. , Cabrera Orlando J.
Published: November 2014

This paper will present the background, development, and use of a requirement and verification traceability (RVT) tool for Systems Engineering. Beginning in the late 1980's, System Engineers in the Government Communication Systems Division of Harris Corporation began to develop an automated tool to support RVT. Working within the framework of our Total Quality Management (TQM) initiative, a team of System Engineers developed a tool that has been used on a multitude of programs. The RVT information is embedded in the program's documentation (specification, statement of work, interface control documents, etc.) and then a parser is used to populate a database. Once in the database, requirement and verification reports and matrices are generated using Structured Query Language (SQL). For several years, this tool has served the needs of our System Engineering staff and has received accolades from our customers.
AUTOMATING THE MANAGEMENT OF INTERFACE DATA
Authors: Niedermuller Bob
Published: November 2014

Generation and maintenance of interface data are a significant part of the Systems Engineering effort on most programs. Typically the control is accomplished through Interface Control Documents (ICD's). The data used to generate the ICD has many other applications, such as wire lists, loads analysis, weights reports, etc. In most applications the ICD is actually a subset of the available interface data, and control and maintenance of this data is a multifarious task. Using an electronic database to record all interface data and generate the ICD and other required data from the resulting database cannot only save a significant amount of effort, but can improve the quality and data consistency. This process can enhance the Systems Engineering effort throughout all phases of the program from inclusion of initial interface Requirements, through Functional Allocation, Design Synthesis, Interface Management, and Verification.

This approach was used to generate interface documentation for an Unmanned Air Vehicle to Automatic Test Equipment (ATE) interface. The process has proven to be less labor intensive than previous methods, and has shown significant savings in updates and generating related documents from the same database. When maintained on a network, it allowed the systems engineers working the interfaces access to the latest data, without having to generate and control printed copies. This paper will discuss the factors that must be considered in implementing an interface management database, such as selection of a DBMS program, data formats, control of the database, and will discuss the experience gained from this application, and will provide examples of the results.
SYSTEMS PERSPECTIVE TO DESIGN OPTIMIZATION
Authors: Hines Jim , Abbatine Michael S. , Fry Keith
Published: November 2014

Rockwell Space Systems Division has been undergoing dramatic changes in the last three years to embrace the Integrated Product Team (IPT) development concept. The architecture of the design system operates is critical to our mission in becoming cheaper, faster, better. Our design architecture is evolving from one that is a byproduct of the design to one of driving good design. A key element in the design process is the interconnectivity of systems and design engineering.

This paper discusses the changes that are occurring in people, processes and technologies which are evolving to produce cost effective, designed products by Rockwell Space Systems Division. A modification product design case study involving tool integration known as Enterprise Process and Data Management (EPDM) will be examined in more detail.
3.3.2 LOCKHEED'S SYSTEM ENGINEERING COUNCIL
Authors: Jaggers Jerry , Khouri Jennifer
Published: November 2014

Lockheed Missiles & Space Co., Inc.'s (LMSC's) Space Systems Division (SSD) has long had a system engineering council, where senior system engineers from all the division's lines of business meet to guide the division's system engineering activities. After a temporary cessation due to a division reorganization, the council has again resumed activity, with a new charter, concrete goals, and renewed interest in preserving and strengthening our core system engineering capability. This paper addresses the history of the council, the required resources, the lessons learned, and the future plans for the council.
4.1.3 A RIGOROUS METHOD FOR FORMAL REQUIREMENTS DEFINITION
Authors: LaPlue Larry , Garcia Ruth A. , Rhodes Robert
Published: November 2014

The authors propose a formal method for writing behavioral requirements usable by a broad spectrum of system engineers. The method includes a requirement template with specific syntax to include all relevant aspects of a behavioral requirement, a “black box” approach to system analysis and a unique organization for requirements specification. The method addresses the most commonly encountered problems that engineers face when writing and maintaining requirements. The paper describes these problems, provides details of the method, and justifies the unique features of the method. Directions for future research to improve the method are also provided.
6.1.3 REQUIREMENTS MANAGEMENT: CONTRASTING TRADITIONAL SYSTEMS AND SOFTWARE ENGINEERING METHODS
Authors: LaBudde Edward V.
Published: November 2014

Traditional system engineering has been the source of most of the requirements' decomposition and management techniques. Requirements' decom‐ position and flow down concentrate on a top‐down mission oriented view. The emphasis is on functional flow (input/output), black box performance allocation, and system interaction. However, it is weak in areas like operating logic, behavior, and timeline requirements.

We contrast and compare the requirements' process and management techniques for the traditional system engineering and modern software approaches. We can indicate at least one gap in the area of operating logic and timeline analysis as well as numerous important under laps.

Consequently, the design of many computer‐ based systems suffers from a substantial risk at the interface between system and software design engineering. The gap, created by a failure to address operational logic, sequencing, performance and timeline requirements in both disciplines, can have a major impact on program cost, schedule, and performance. Potentially, major safety related risks may result from the gap in logic and timeline requirements' tracking and allocation. In addition, significant under laps occur in operational analysis, interface control, performance, human factors, risk analysis, trade‐off studies, reviews, and planning. Therefore, these can create a risk if the software engineering effort is weak in traditional system engineering discipline. Suggestions for reducing the gap and under lap are offered.
A Formalism for the Specification of Operationally Embedded Reactive Systems
Authors: Sherry Lance
Published: November 2014

The Operational Procedure Information Model, presented in this paper, provides a formalism for the specification of the behavior of operationally embedded reactive systems found in aircraft guidance and navigation systems. The information model assigns semantic interpretations of the operational procedure construct to the elements of a finite state machine. The operational procedure construct captures the embedded operational behavior of the system over all the missions in the life‐cycle. The finite state machine captures the reactive behavior of the system.

The information model, captured in a database and interrogated through a graphical user‐interface, can be used for simulation, analysis, and the generation of code and documentation.
2.2.3 PEOPLE CAPABILITY MATURITY MODEL (P‐ CMM): INCORPORATING HUMAN RESOURCES INTO PROCESS IMPROVEMENT PROGRAMS
Authors: Hefley William E. , Curtis Bill , Miller Sally , Konrad Michael
Published: November 2014

The People Capability Maturity Model (P‐ CMM) is an adaptation of the Capability Maturity Model SM for Software (CMM SM) focused on developing the organization's talent. The motivation for the P‐ CMM is to radically improve the ability of software organizations to attract, develop, motivate, organize, and retain the talent needed to steadily improve software development capability. Although being initially developed with a focus on software and information systems development, the principles and many practices of the P‐ CMM apply equally to systems engineering. There is thus on the horizon a family of capability maturity models to help organizations improve their development capability: the CMM for Software, the Systems Engineering CMM (SE‐CMM), and the P‐CMM.
6.2.4 A Methodology for Capturing An Organization's Systems Engineering Best Practices
Authors: Walden David D.
Published: November 2014

As part of Computing Devices International's journey to become a Six Sigma company and a World Class Systems Engineering organization, numerous process improvement teams have been formed. One such team is the Systems Engineering Best Practices Team, whose charter is to determine and document the best Systems Engineering practices currently being used in the organization.

This paper describes the methodology that was used by the Systems Engineering Best Practices Team. The methodology is based on a survey followed by an iterative elaboration of each process in priority order. In addition to defining the process used for each of the best practices, Six Sigma and Systems Engineering metrics were also included. The paper also shares some of the lessons learned through application of this methodology.
1.4.1 VALUE SYSTEMS ANALYSIS: APPLICATION TO TEAM MOTIVATION
Authors: McCumber William H.
Published: November 2014

Degree of conjointness between task structure, organizational structure and personal value system determines how well individuals and teams accomplish tasks. People cope with the demands of situations in accordance with (predominantly) one of eight value systems. Many approaches to motivation are based on “one size fits all,” assumptions. Value system analysis allows one to select personnel whose value system is conjoinable to task and organizational structure. Total Quality Management (TQM) often fails because it assumes consistent responses from employees. The “emergent, cyclical double‐helix model of adult biopsychosocial development,” is a tool which enables matching people to tasks, managers and peers through value system analysis. Root causes of the failure of TQM and the lack of universal acceptance of the philosophy of W. Edwards Deming are clarified through value systems analysis. Illustrative scenarios are presented. A general procedure for staffing teams is outlined.
4.4.2 SYSTEM PERFORMANCE REPRESENTATION: STANDARD SCORING FUNCTIONS
Authors: McCumber William H.
Published: November 2014

Design is a series of nested decisions which lead from the abstract to the concrete. Most design decisions involve multiple objectives and multiple criteria. Criteria have relative importance, a range of expression and order of preference within that range. This paper presents a method by which design decisions can be approached. The set of standard scoring functions developed by Wymore enable encoding of relatively complex system performance parameters in an easily manipulated trade study (multiobjective decision technique). The twelve basic shapes translate measurements made of system parameters into a standard score (utility). The resulting set of representations are then weighted and combined to create a single measure of relative effectiveness across a set of system criteria.
4.4.4 Application of the ‘Vee’ to Incremental and Evolutionary Development
Authors: Forsberg Kevin , Mooz Harold
Published: November 2014

The technical aspects of the project cycle have been modeled as a sequence of events descending with increasing detail through decomposition and definition, from user requirements to piece parts and lines of code. Then starting at the lowest level, the technical aspects ascend through integration and verification up to the system at the highest level. This representation as a ‘Vee’ was first presented in the 1991 NCOSE symposium in Chattanooga, Tennessee (Ref. 1). The cycle presented in that paper was described as a single thread, or what is now called in the software world the grand design. Extension of this concept to incremental and evolutionary environments is essential to provide for application on any project. This paper provides that model and visualization.

Three cases are examined: an incremental development with a single product delivery, incremental development with incremental product delivery, and evolutionary product development.
4.5.1 A Systems Engineering Capability in the Global Market Place
Authors: Rochecouste Hervé
Published: November 2014

Organisations that produce a physical product have no difficulty in promoting their capability; Systems Engineering organisations produce a conceptual product: their deliverables consist mainly of information. A Systems Engineering capability is therefore an abstract entity, and sometimes hard to visualise. For a Systems Engineering organisation to remain competitive in the Global Market Place, it must have a method of assessing, promoting and improving its capability. Although NCOSE is moving towards a common understanding, to date there are no external benchmarking systems that can be used to provide an absolute indication of Systems Engineering effectiveness. A method for assessing the Software Engineering Capability of contractors has been developed by the Software Engineering Institute of the Carnegie Mellon University, but the method is not directly applicable to Systems Engineering. The IEEE P1220 Standard for the Application and Management of the Systems Engineering Process imposes (4.14, Re‐Engineering, Self Assessment, Lessons Learnt) a requirement to implement an improvement program. There is also a requirement for benchmarking the Systems Engineering Process (6.8.7e). This paper describes an internal assessment methodology that an organisation can adopt to improve its effectiveness, and meet/exceed these IEEE P1220 requirements.
5.4.1 USE OF COMMERCIAL‐OFF‐THE‐SHELF/NON‐DEVELOPMENTAL ITEMS (COTS/NDI) IN DOD SYSTEMS
Authors: May Charlie
Published: November 2014

The concept of using COTS/NDI has been advanced as a method for getting new technology to military fleet and field users more rapidly and at less cost. Through use of this concept, new technology can undoubtedly be fielded sooner, but there are some difficulties associated with the concept that need to be examined and dealt with before developers wholeheartedly adopt and implement it.
5.4.3 THE FOUNDATION OF SYSTEMS ENGINEERING
Authors: Alessi R. Samuel , Friedman George J. , Grady Jeffrey O. , Mayhew Michael E. , Mayhew Kathy , Rhodes Donna H. , Schuster Cecilia H. , Woods Thomas W. , McCumber William H.
Published: November 2014

Systems Engineering is an existing reality but what is it? Many definitions exist but there seems to be no universally accepted one. Is it a process, a department, or an engineering discipline? From whence did it come and upon what fundamental scientific, mathematical, or logical facts does its foundation rest? The author team intends, over a period of time, to research earlier related work reported upon in National Council on Systems Engineering (NCOSE) publications and other literature, explore these questions in new research, and periodically report progress to NCOSE membership through Symposium papers and presentations and NCOSE Journal papers. This paper begins this process reporting on an intended course of action, identifying the people involved, soliciting the interest of others in pursuing these questions, and offering preliminary results.

The initial work reported upon entails identification of a team, its mission, and several theories that will be pursued in research efforts by subteams seeking to support those theories or prove them false. The careful reader will see in this process a merger of the systems approach and the scientific method as a basis for the research project. The several theories are alternative scenarios that will be explored. The final result may be to show that some combination of the theories offers the complete answer supporting the notion that we are inflicted with competing alternative theories at present because we are all looking at specific manifestations of a more general concept than we are presently able to observe and describe. We should be seeking a simpler and more elegant structure that embraces all of our views.

We say that we will apply the scientific method but also recognize that this venerated method may be part of the problem inhibiting people from recognizing the critical role that people play in the systems approach. While the team enters this study with the predisposition that systems theory and qualitative and quantitative methodologies offer promise, we will not close our eyes to the possibilities exposed through study of positive and postmodern paradigms.

From time to time the team may find it necessary to terminate interest in one theory, merge findings into a grander view, or initiate additional analytical channels.
7.5.1 Process Engineering and Development using Customer Focused Object Oriented Design
Authors: Peterson Craig E.
Published: November 2014

The need for application of system engineering expertise to review and re‐engineer institutional processes has become increasingly apparent. In order to provide a unified approach which can be used on any process, a synthesis of current system engineering approaches has been developed. When combined with Total Quality Management principles, this approach is called Process Engineering and Development using Customer Focused Object Oriented Design (PED‐CFOOD).

Over the last few years, Software System Engineering (S/WSE) principles have evolved towards an Exoteric Perspective (EP) described by (McMenamin 1987). That is, examining systems from the point of view of the external world in which the system is embedded, and determining what flows into and out of the system. EP has two problems with it, though.

First, there are usually multiple external perspectives that can be adopted. The current solution is to try to examine the system from as many as time will allow, and then settle on the one that seems the most appropriate. TQM, on the other hand, provides us with a suggestion as to which might be most appropriate, namely, the viewpoint (focus) of the Customer.

Second, it does not provide a conceptual framework for process or product design. Object oriented development concepts provide that framework.

This paper provides a general description of this approach, and illustrates how the approach might be used in practice.
DEVELOPMENT OF INFORMATION SYSTEM SECURITY REQUIREMENTS FROM A SYSTEMS ENGINEERING PERSPECTIVE
Authors: Urbanski James L.
Published: November 2014

Modern systems, regardless of their design or purpose, rely on a wide variety of mission assets and resources. One of those assets, information (specifically for this paper, data information) may require protection due to its sensitive nature. If security is necessary, then the system developer may need to identify security services (such as confidentiality) and may require protection mechanisms (such as encryption) to be included as part of the overall system design and development. Information System Security (INFOSEC) requirements should be an integral part of the systems engineering process. In the systems engineering process, the initial activity is the identification of requirements. That is also the topic for security requirements, i.e., determining what data needs to be protected. Further development of related topics follows and includes threat assessment, policy and doctrinal (procedural) guidance, and risk analysis. These security‐related concepts contribute to the identification of system security objectives, e.g., the mission data that requires protection in accordance with the postulated threat and applicable policy guidance. Finally, doctrinal and technology concepts are presented such that architectural decisions can be made to implement security mechanisms for the system security requirements.
SMALL TEAM ENGINEERING: A PATH FROM REQUIREMENTS THROUGH COTS IMPLEMENTATION
Authors: Newbern David , Nolte Jerry
Published: November 2014

Small team engineering is examined as a methodology to deal with the problem of identifying and prioritizing requirements and the selection of an appropriate implementation strategy when short implementation schedules of six to twelve months are required. Small team engineering includes team building with customers and users with an iterative process led by system engineers to build team consensus. Three scenarios are examined to illustrate the use of small team engineering in a variety of situations with an emphasis on the use of COTS products in building solutions to problems.
Developing a System Solution in a Commercial Environment
Authors: Gutierrez Carol J. , McKennon Jane , Eldridge Miriam , Bhadra Abhijeet
Published: November 2014

This paper describes our philosophy and systems approach for iterative development using multiple prototypes (software, documentation, and training) in a commercial environment. The desired result has been not just a product solution, but rather a system solution. Also discussed are our reuse approach and the technical focus for the next generation of our product family. Several development experiences are discussed: 1) our approach to eliciting and capturing customers' needs and critical requirements for configuration management and change control of the models; 2) our approach to developing a need‐driven product with an easy‐to‐use user interface; and 3) the systematic development of the process and product documentation in substantially less time than commonly thought possible. Also presented are some lessons learned and benefits realized during our current development effort.
Applying Systems Engineering to VLSI Design
Authors: Gardner John R.
Published: November 2014

This paper explores the usefulness of the disciplined Systems Engineering approach to the intricate and complicated science of VLSI design. The basics of Systems Engineering are reviewed and several recently published VLSI papers are evaluated and measured as to their use of this approach.
Continuous Electronic ENhancements using Simulatable Specifications
Authors: Gearhart Larry , Thullen Mark , Winn Alan
Published: November 2014

Current board/module‐level development processes cause errors in specifications and design while developing a product, and are usually not identified until late in development. Defining the system requirements for applying formal methods to the specification of board/module‐level products, and the associated impacts to the development process, tool integration, and electronic data interchange (EDI) will significantly alleviate these errors. The CEENSS program has several demonstrations, beginning with Build‐1 in January of 1997, which will examine the efficacy of this methodology. The CEENSS Project is sponsored by the Manufacturing Technology Directorate of Wright Laboratory, WL/MTIB, Wright Patterson AFB.
Process Change in Systems Engineering: From Document‐Driven to Model‐Based Approach
Authors: Gordy Lowell W. , Noel Donald R. , Rhoads Russell P. , Nichols Camille M. , Gutierrez Carol J.
Published: November 2014

This paper presents a case history of change in Systems Engineering methodology on the Theater High Altitude Air Defense (THAAD) program over a 3‐1/2 year period. During this time, the program's systems engineering moved from a document‐driven to a model‐based approach. Factors associated with making this change are discussed by members of the team that helped with the implementation. Also discussed are what we feel to be the benefits of a model‐based approach, lessons learned, and suggestions for projects considering such an approach.
The Impact of Executable Requirements Models
Authors: Cohen Moshe S.
Published: November 2014

As design complexities soar, companies continuously improve their development process in order to remain competitive and meet their time‐to‐market constraints. Development methods based on textual specifications of the requirements often lead to late deliveries of the wrong product. To address this, companies need to formally capture the requirements and generate an executable specification model as a way to verify the correctness of the specification. Through the use of code synthesis methods, the model can be used for rapid prototyping, thus allowing for an early validation of the needs, and therefore, delivering the right product. However, this requires commitments to process adjustments.
Resolved: Software Should Lead in Systems Engineering
Authors: Armstrong James R. , Pyster Arthur
Published: November 2014

The systems engineering community has long debated the extent to which software disciplines, processes, and practitioners should influence systems engineering. In August 1996, the authors held a lively debate at a meeting of the Washington Metropolitan Area Chapter of INCOSE on the proper role of software engineering within systems engineering. The particular issue debated was the proposal that software ideas, process, and people should be in the lead when building complex systems. Pyster favored that view while Armstrong opposed it. While some of our comments were tongue in cheek for the fun of the audience, the topic itself is quite serious. This paper elaborates on the points made at that debate.
Integration phases: all is set at the design phases
Authors: Cattan Denise
Published: November 2014

In System Engineering, let us be told that the first technical issues are encountered during design phases. But let us claim that sentence occurs when components are integrated together to build The System. This integration1 phase starts after components acceptance. Its goal it to aggregate step by step the components to be able to detect and locate any possible trouble and treat it. The main difficulty lies in updating planned organization and resources management to face unplanned daily events. Anyway this integration phase has to end with system delivery. If the integration phase was not properly prepared, its costs will increase without control: deal is settled good or bad in previous phases.

Customer focuses satisfaction or unsatisfaction on validation2 and qualification3 final phases which pose the same problem.

This paper shows how the final integration ‐validation ‐ qualification phases are planned from the very beginning in the “Méthode d'Ingénierie Système Thomson‐CSF‐MIST”.
Defining “System” – an Engineering Point of View
Authors: Paul Arthur S.
Published: November 2014

Having observed different terminology, emphases, and concepts being used by writers from various disciplines to define “system,” this analyst hypothesized that an analysis of these definitions will identify diversity in the current uses and applications of the word “system,” and provide a basis for a definition that is applicable to the engineering community. This analysis involved a preliminary review of definitions of “system” from a wide variety of sources, and selecting a set which seemed to apply to engineering work for more detailed analysis. Fourteen definitions, which satisfy this criterion, are discussed in this paper. While varying extensively in terminology, level of details, applicability, and scope, these definitions of “system” are remarkably consistent in conveying some fundamental concepts, such as: wholeness, order, interrelationships among parts, and purpose.
Engineering Harmony Between Systems and Software
Authors: Rose Susan
Published: November 2014

Recent process improvement initiatives (Paulk et al. 1993; Software Engineering Institute 1994) have focused on maturing the processes for systems and software engineering. However, these initiatives address the systems and software engineering processes separately. The separation makes it difficult for developers of software‐intensive systems, who must deal with the systems/software interface issues, to make effective use of systems or software process improvements. This paper lists the requirements needed to establish a harmonious development interface between systems and software engineering and describes a process that has been created to meet these interface requirements.
Analysis of System Requirements Negotiation Behavior Patterns
Authors: Egyed Alexander , Boehm Barry
Published: November 2014

Roughly 35 three‐person teams played the roles of user, customer, and developer in negotiating the requirements of a library information system. Each team was provided with a suggested set of stakeholder goals and implementation options, but were encouraged to exercise creativity in expanding the stakeholder goals and in creating options for negotiating an eventually satisfactory set of system requirements.

The teams consisted of students in a first‐year graduate course in software engineering at USC. They were provided with training in the Theory W (win‐win) (Boehm‐Ross, 1989) approach to system requirements determination and the associated USC WinWin groupware support system (Boehm, et al, 1995)(Horowitz, 1996). They were required to complete the assignment in two weeks.

Data was collected on the negotiation process and results, with 23 projects providing sufficiently complete and comparable data for analysis. A number of hypotheses were formulated about the results. Some of the hypotheses addressed the use and potential improvement of WinWin features. Others addressed more general process issues, e.g. that the uniform set of initial conditions would lead to uniform results. This paper summarizes the data analysis, which shows that expectations of uniform group behavior were generally not realized.

In terms of goals for relevant Capability Maturity Models (CMM's), this implies that the System Engineering CMM's Level 2 goal of Planned and Tracked processes is more realistic than the Software CMM's Level 2 goal of Repeatable processes.
An Information Architecture for Systems Engineering ‐ Progress, Examples, and Directions
Authors: DeGregorio Gary
Published: November 2014

As the complexity of our systems continues to rise, a growing number of engineers, managers and marketing professionals are realizing that they must make dramatic process improvements in order to address the challenges of timely systems development in a strong competitive environment. Three critical elements are needed to provide the foundation for these process improvements: 1) an information architecture; 2) an information structure, optimized by domain; and 3) Enterprise‐wide decision making and technology planning processes. This paper will describe the progress made in developing and piloting these capabilities, provide an example of successful use, and outline some of the next steps.
Yes Virginia, You Can Build a Defect Free System, On Schedule and Within Budget
Authors: Kasser Joe
Published: November 2014

Today's software and systems development life cycle paradigm is characterized by large cost overruns, schedule slips, and dramatic performance deficiencies in weapon, C4I, and automated information systems. This paper describes an alternative paradigm that can produce defect free systems on schedule and within budget.
Product‐Only WBS
Authors: Grady Jeffrey O.
Published: November 2014

DoD has traditionally required a work breakdown structure (WBS) on programs that includes both product and services components apparently based on the belief that this is the only way to account for all program cost elements. The author maintains, and supports in this paper, that not only is it possible to capture all program work under a product‐only WBS but that it will encourage better program planning, more manageable programs, and a more efficient transform between an enterprise identity and the needs of all programs within the enterprise.

The author extends the U.S. Air Force integrated management system beyond the notions advanced in his book System Engineering Planning and Enterprise Identity involving the generic to program planning transform. This transform is made simpler and easier to apply within the context of a product‐only WBS.

We begin by reviewing the purposes of the two axes of the matrix management structure. The functional organization is the key to written practices, personnel training, continuous improvement, and an efficient program planning process. We will then defend the product‐only WBS and discuss how the program planning transform process can be implemented within the context of the product‐only WBS.
Visualizing System Engineering and Project Management as an Integrated Process
Authors: Mooz Harold , Forsberg Kevin
Published: November 2014

In many project environments System Engineering and Project Management are managed separately. This situation is aggravated by the discipline segregation by universities and by the corresponding professional organizations. The International Council on System Engineering (INCOSE) and Project Management Institute (PMI) operate independently and usually don't participate in each others' conferences. Project Management and System Engineering tools are rarely integrated. INCOSE members are usually not members of PMI and vice versa. Project Management, the integration of business management and technical management into systems management, requires discipline and informed implementation. The process model explained here and detailed in our recent book, Visualizing Project Management (Wiley & Sons), is a significant step to visualizing and applying these inseparable processes.
Defining the Roles and Responsibilities of the Systems Engineering Organization/Team
Authors: Fisher Jack
Published: November 2014

When we discuss and teach systems engineering, we usually describe all of the activities required to design and develop a system but do not consider the organizational assignment of these responsibilities. The assignment of tasks to the systems engineering organization/team (SEOT) is important as the successful implementation of many projects depends upon the correct identification and assignment of tasks to the SEOT. Several approaches to the determination of roles and responsibilities are examined and a model statement of work for the SEOT is presented.
The Integrated Product Development CMMSM
Authors: Pyster Arthur , Sheard Sarah A.
Published: November 2014

The Integrated Product Development (IPD) Capability Maturity Model (CMM1) is being developed as a framework to (1) establish, appraise, and improve processes for the entire product life cycle, where “product” includes both goods and services; (2) provide a common reference model and language for IPD concepts; (3) support the adoption of IPD in a wide range of industries, service operations, government, and academia; and (4) be the framework for integrating other popular CMMs and quality frameworks such as the SE‐CMM (Bate, et al 96), SECAM (INCOSE 96), SW‐CMM (Paulk, et al 93), and ISO‐9000 (ISO 91).

The Enterprise Process Improvement Collaboration (EPIC) has been developing the IPD‐CMM since March 1995. The model reported on here, Version 0.9, will be revised prior to general release in mid‐1997, based on feedback from pilots, public review, and additional development by the authors.

Because IPD is increasingly central to systems engineering, and because systems engineering process improvement must be coordinated with process improvement initiatives for other disciplines, such as software, the IPD‐CMM will likely have a broad impact on the systems engineering community.
Pilot Results Applying the System Security Engineering CMM
Authors: Hefner Rick
Published: November 2014

The Systems Security Engineering Capability Maturity Model (SSE‐CMM) describes the essential characteristics of an organization's security engineering process that must exist to ensure good security engineering. The model also highlights the relationship between security engineering and systems engineering.

This paper summarizes pilot appraisals conducted at four security contractors during 1996. The results indicate the model and appraisal method are fundamentally sound. In 1997, the project will promote use of the model by acquisition agencies to evaluate potential system security vendors.
The Frameworks Quagmire, A Brief Look
Authors: Sheard Sarah A.
Published: November 2014

Organizations wishing to remain competitive often want to comply with all possible contractor evaluation criteria, process models, and quality standards, but the field is evolving rapidly. This paper describes the categories of compliance frameworks and characteristics of seven important frameworks: the CMM, SE‐CMM, IPD‐CMM, ISO 9000, SDCE, MIL‐STD‐498, and Trillium. The paper also discusses trends and recommendations for how to deal with the Frameworks Quagmire.
Continuous Measurable Improvement Of Software Systems
Authors: Stewart Ronald , John Robert
Published: November 2014

The establishment of a state‐of‐the‐art development environment and a rigorous iterative process provides the basis for the effective application of Continuous Measurable Improvement (CMI) techniques to software system development. This paper outlines how to establish divisional and program‐specific processes to support the production of high quality, maintainable systems. The iterative process allows for the continuous evaluation, feedback, and improvement of the software systems. Metric tools and techniques support the evaluation of these developed systems. Continous measurement and trend analysis through the system life‐cycle provides real‐time indication of areas requiring improvement. The Canadian Automated Air Traffic System (CAATS) project of Hughes Canada Systems Division (HCSD) is used to illustrate the application of CMI to software system engineering.
Graduate Course for Systems Engineering at the Fachhochschule München
Authors: Hettich Gunter
Published: November 2014

This paper describes a successfully completed project that resulted in establishing the first graduate course for Systems Engineering in Germany. Furthermore the paper demonstrates how increasing industrial unemployment problems and academical considerations to reduce interface problems concerning the developement of electronical devices can be the basis of an excellent co‐operation between industrial companies and the Fachhochschule München. The paper is divided into three major parts: 1) a description of the background, of the history and of special restraints of the project, 2) the explanation of the curriculum and 3) practical experiences during the first two years after starting this eductional program.
A Course on Systems Engineering for Railway Projects
Authors: Jin Jenny Q. , Allan Jeff , Williams John
Published: November 2014

The Railway Systems Engineering (RSE) team of the University of Birmingham is producing a new post‐experience course on the application of systems engineering for UK railway industry. The principal objective of this course is to give participants a detailed grounding in the application of systems engineering. The course work includes lectures, syndicate exercises, and laboratory workshop sessions. This paper presents our initial work on the course preparation, outlines the course contents, and discusses how the course will be delivered.