bluuebunny/crossref_metadata_2025_split huggingface dataset:
6.3.1 Pilot application of the Object Oriented System Engineering Method (OOSEM) using Rational Rose Real Time™ (RRT) to the Navy Common Command and Decision (CC&D) Program
Authors: Steiner Rick , Friedenthal Sanford , Oesterheld Jerry , Thaker Gautam 
Published: November 2014

AbstractThe introduction of an object oriented systems engineering method and tool was assessed during a short duration pilot project on the Navy's Common Command and Decision (CC&D) program. The pilot determined that the method/tool offers significant benefit for specifying and designing a complex command and control system relative to traditional approaches. This paper describes the pilot approach, summarizes the object oriented methodology and tool evaluated, and presents some of the significant findings.
6.3.3 Emergence: Open Your Eyes to New Vistas
Authors: McConnell George R. 
Published: November 2014

AbstractA paper presented at INCOSE 2000 (McConnell, 2000) outlined some of the issues which arise as Systems Engineers grapple with the emergent behaviour, properties and capabilities which complex systems exhibit. Using traditional methods of modelling in the traditional way often results in an inability to understand why the emergences happen, when they will occur or how to minimise their impact.This paper builds on that introduction and offers for consideration the idea that the most fundamental thing which must be done is to avoid the trap of viewing the system only from the perspective that the Systems Engineer feels most comfortable with. While it is not possible to remove all problems this way, some of the difficulties can be ameliorated by the judicious use of currently available modelling techniques. The paper also suggests a new perspective on modelling itself ‐ modelling for understanding rather than modelling for prediction.
8.3.1 A New Graphical Systems Engineering International Standard: ISO/IEC 15909 for High‐level Petri Nets
Authors: Billington Jonathan 
Published: November 2014

AbstractThe International Organisation for Standardisation (ISO) and the International Electrotechnical Commission (IEC) have a Joint Technical Committee (JTC1) for the promulgation of Information Technology Standards. JTC1 is divided into a number of subcommittees (SCs), with SC7 having carriage for Software and Systems Engineering Standards. Working Group (WG)11 of SC7 has been developing standards in the area of Software Engineering Data Description and Representation. One of the standards developed by WG11 (ISO/IEC 15909) is for the specification of distributed and concurrent systems using high‐level Petri nets. This standard has now reached the status of a Final Draft International Standard, and hence its technical content is fixed. The final ballot should be held in the middle of 2001. This paper provides the background, scope, justification, current status and future directions of this project.
8.3.4 Enhancing Conferences and Symposia using Web Based Asynchronous Techniques1
Authors: Kasser Joseph 
Published: November 2014

AbstractThis paper describes ways to enhance conferences using Web‐Based asynchronous techniques and their advantages and disadvantages as compared to a traditional synchronous face‐to‐face conference. The paper also treats the development of the prototype WebConference as a Case Study, discusses the prototyping experiments using the world as a laboratory and provides several lessons about the requirements and systems engineering processes.
4.4.4 Functional Modular Design: Towards a Methodology for Managing Uncertainty
Authors: Humphries Josh , Radcliffe David 
Published: November 2014

AbstractThis paper presents the concept for a methodology, Functional Modular Design (FMD), being developed to assist systems engineers to manage technical, operational and commercial uncertainties as they develop systems concepts. This methodology is being developed and refined through an iterative process of reviewing design practice involving modularity, proposing elements of the methodology and conducting industry case studies. This process is described and an example of a case study is presented. The FMD method consists of a three‐phase process of using guidelines to synthesise a candidate design concept, a life cycle cost (LCC) analysis based on many possible operational scenarios and the identification of areas for system improvement. A set of four basic FMD guidelines are presented and their application discussed. The wider implications for this approach in systems engineering are explored.
5.4.1 Data for Management: Readiness Measurement and Sustainability Assessment in the RAN
Authors: Saunders D.S. , Brown J.R. , Doukas L. , Brash W. 
Published: November 2014

AbstractThis paper examines data for management within the Royal Australian Navy (RAN) preparedness management system. Data for management presents a significant challenge, and in this paper we explore some of the issues that need to be addressed before a future RAN preparedness management system is architected to achieve quantitative and objective cost/capability decisions.We examine how data is exchanged in the management process, the operational view of the preparedness management system and the nature of the data used in the management process. Within the context of the nature of data, we examine a classification of data that may be used to represent its contribution to the management processes. This classification of data provides a basis for a brief discussion of the significant issues that need to be addressed in the architecting process of data for management.
5.4.3 What Is Senior Management Commitment?
Authors: Sheard Sarah 
Published: November 2014

AbstractAlmost all change management guidance emphasizes that without senior management commitment, true change is difficult or impossible. Yet little guidance is available that describes in detailed terms what actions senior managers must take to demonstrate such commitment. This paper draws on the author's experiences in change management (primarily in implementing capability models) to discuss what senior management commitment means in practice. Senior managers must understand and then act upon five principles. Senior managers establish a common vision of an improved organization, demonstrate their commitment by actions that are taken “in the heat of battle,” engage other managers, provide resources, and actively address organizational incompetence. Examples are given of actions that demonstrate strong commitment and of actions that convey a different message. Change programs are most likely to succeed when the commitment is strong and clear.
7.4.1 Australian Experiences with CMMI
Authors: Rout Terence P. , Tuffley Angela , Marshall David , Pitman Adrian 
Published: November 2014

AbstractThe CMMI Evaluation Project is an initiative established by the Australian Defence Directorate of Software Acquisition Reform (DSWAR) to determine the effectiveness of using the CMMI for risk assessment of suppliers capability in systems & software engineering. An objective of the overall reform program is to encourage Australian Defence industry to use such models for establishing process improvement programs. As part of the evaluation strategy, the use of CMMI in assessments is being trialed with a few invited suppliers to ascertain the impact and effectiveness of the model and the assessment method from both an industry and Defence perspective.This paper gives the findings from the initial pilot assessments conducted. The results include an analysis of the effort requirements for the assessment; an examination of the conformance issues identified with respect to ISO/IEC TR 15504 ‐ Software Process Assessment (ISO/IEC, 1998); together with observations on the assessment process, particularly on data collection practices and the development of team consensus. The paper focuses on lessons learned from the pilot assessments, both in terms of their contribution to the CMMI Development Project and their relevance to the wider audience of users of the SW‐CMM and EIA/IS 731, particularly in Australia, and the goals of DSWAR.
7.4.2 EIA/IS‐731 to CMMI – A Guide for Transition
Authors: Clouse Aaron , Wells Curt , Schoening Bill 
Published: November 2014

AbstractThe Capability Maturity Model® Integration (CMMISM) project has integrated the Capability Maturity Model for Software (SW‐CMM®) version 2C, Electronics Industry Alliance (EIA/IS‐731) Systems Engineering Capability Model version 1.0, and the Integrated Product Development Capability Maturity Model (IPD‐CMM) v0.98a. For the systems engineering community that has been using EIA/IS‐731, this integration of CMMs has resulted in many changes to the practices and amount of information contained in the model. The purpose of this paper is to provide guidance for transition to CMMI by describing differences in the models that should be considered in making the transition.
8.4.3 Systems Engineering MegaPractices – Identification, Assessment and Redundancy By Object Analysis and Modeling
Authors: Beshore David G. 
Published: November 2014

AbstractWhat happens when practices and disciplines overlap? – Wasted efforts, turf battles, redefinition of lifecycle models based on different management, engineering, manufacturing, finance, maintenance and support viewpoints. In short, a proliferation of the ‘way we do things around here’.Systems engineering has become a set of complex processes that are difficult to implement and improve. Too often, either sub processes are developed for lower tier Integrated Product Team performance or for large enterprise level practices which are promoted as ‘Best Practices’ (Heibler 1998). Most often, the linkage at different levels of abstraction is very difficult to see, much less apply. These are difficult to implement for management of larger and smaller projects. Also many projects in an enterprise are at different stages of development, which makes process improvement across the organization difficult to assess and implement.Lifecycle ‘Practices’ and ‘Standards’ are generated as panaceas for good systems engineering and are evidenced as:

Systems integration,
Systems design,
Systems validation,
Software engineering,
Design to Cost (DTC),
Design for Manufacture and Assembly (DFMA),
Cost as an independent variable (CAIV),
Affordability,
Quality Function Deployment (QFD),
Supply Chain Management,
Robust Design,
Risk management,
Requirements management,
Time‐to‐market, and
Just‐in‐Time ManufacturingThe purpose of this paper is to show how a set of capability improvement models (SW‐CMM 1995, SECM‐EIA731 1998, CMMI 2000, ISO 9001 1994, ISO 15504 1998) and process definition standards (IEEE1220 1998, EIA‐632 1998, ISO 15288 2000, and ISO12207 1995) can be used to test these megapractices for commonality and redundancy. Object oriented (OO) techniques are be used to: 1) identify the validity of megaprocesses, 2) determine which processes belong to megapractices and are common throughout the chosen set, and 3) assist assessors and process improvement practitioners in selection and optimization of best set of practices for the top level enterprise down to team level performance. Conclusions from this analysis are:

Systems Integration includes Design Reviews, Integrated Schedules, and Integrated Planning
CAIV includes Trade Studies, Requirements, Risk, Cost, Performance (TPMs), and Decision Making
Software Development is a large subset of Systems Integration in software‐intensive systems
8.4.4 Integrating a Geographically Distributed Team using Commercial Technology
Authors: Musani Riaz , Mosher Todd 
Published: November 2014

AbstractCurrent web‐based information management systems (IMS) offer a wide variety of tools for a team to work with in a virtual environment. When choosing such a system, users should envision possible tools required and supplemental processes to develop effective communication architectures. This paper discusses the approach that the Polar Night team used during a 9‐month proposal preparation phase to develop a virtual team from ten geographically diverse/distributed organizations, and the lessons learned from combining commercially available IMS to develop an integrated systems engineering application.
1.6.3 Towards a Systems Engineering Framework For Tranportation Systems Simulation as Requirement Validation Tool
Authors: Dhalgren Joy , SAHRAOUI Abd‐El‐Kader 
Published: November 2014

AbstractTransportation improvements have been and will be an important concern of public policy makers, transport agencies, and transport economists. To address this concern, we propose applying system engineering concepts and techniques and mainly to use simulation as a requirement validation tool to assess the extent to which possible improvements would meet the requirements of various stakeholders. We will use a multi‐level requirements approach and simulation by abstraction. The approach will be limited to highlight the importance of such a tool for decision support in the requirement steps.
1.6.4 Requirement Management Versus Models
Authors: Stemm Douglas J. 
Published: November 2014

AbstractThis paper will discuss the experience of two projects that wanted to manage requirements and design their system using a model‐based design process. The effect on the engineering community was significant. Trying to use requirement management tools that are specification‐based in a model‐based design process also had problems. The experiences of these projects will be used to form conclusions that will be of benefit to other projects that want to move into model‐based design.
8.6.3 Systems Thinking Applied to Teaming
Authors: Hoheb Albert C. , Polokoff Elyse , Tilney Lindsay 
Published: November 2014

AbstractThe Aerospace Institute (TAI) provides the learning environment for staff at The Aerospace Corporation (a Federally Funded Research and Development Centre). The staff averages over 23 years of industry with advanced degrees. Our knowledgeable space engineering and scientific staff particularly challenges TAI when presenting concepts related to teaming.Most people equate team‐related training as applied psychology. This may make engineers and scientists uncomfortable. TAI applied systems thinking to the description of teaming and found some surprising results. It yielded a multifaceted Team Map. One facet reveals the team‐based competencies, such as roles and responsibilities. Another facet conveys the team life cycle and the specific attributes for each role in the life cycle phase. The third useful facet provides the associated data of team relationships. The map has several practical applications; it provides a reference for teams, a descriptor for tool application, and a source to develop team diagnostics. The Aerospace Institute used it in curriculum evolution to differentiate among its team related course offerings.
8.6.4 A CDROM Systems Engineering Book of Knowledge (CD‐SEBOK)
Authors: Beshore David G. , Patmor Lynette L. , Wilson Willie B. 
Published: November 2014

AbstractSince 1997, our systems engineering (SE) process organization developed tools, techniques, and methods using commercial‐off‐the‐shelf (COTS) tools and Internet Servers to collect and deploy systems engineering knowledge. The phases of development described, herein, explain the rapid growth and contributions that began with a single dedicated web‐based PC server and culminated in a CDROM‐based Systems Engineering Book of Knowledge (CD‐SEBOK) from a network of servers.The development steps included:

Initially providing content on a single SE process –‘requirements’ on prototype server (1997), then
Expansion to six (6) processes for the entire SE department (1998), then
Validation of content by process owners (1998), then
Transfer of content to CDROM to provide a virtual web, version control and personal search engine, (1999)and finally,
Expansion of content from multiple business site websites (1999) and then
Recapture on CDROM (2000).Content is currently 640 Mbytes of highly linked (8300 hyperlinks) information related to systems engineers and is considered to be a book of knowledge for systems engineers throughout the company. The content also is used in internal and external assessments for the Capability Improvement Models, such as SW‐CMM, CMMI and SECM (EIA‐731).The development process included many object‐oriented (OO) methods that provided a complete and efficient method to gather requirements for the server and the development of a CDROM with a powerful search engine. These methods include uses cases, content classes, collaboration, sequence, state and deployment diagrams. A new lifecycle method, called Synchro‐Xtm (Beshore 1999), was used during the specification, design, build and verification phases to reduce risk during development along with object oriented techniques (Ericksson 1999). The model forces different reviews among distinct teams to provide necessary inputs during product development.The development of the CD‐SEBOK contained inherent risks:

Lack of Resources or Commitment
Requirements Misunderstanding
Misunderstanding of Web Content Scope
Inadequate Password Protection
Information Security Misunderstanding
SE Common Processes Not Identified at Business Site LevelThe integration team (20 people from various business sites) was responsible for identifying and managing risk that might preclude successful completion of the team's responsibilities and implementation of the CD‐SEBOK. It was the responsibility of each team member to constantly evaluate and identify any issue/problem that could adversely impact the CD‐SEBOK.
4.7.3 Assessing Requirements Engineering Processes with the REAIMS Model: Lessons Learned
Authors: Kauppinen Marjo , Kujala Sari 
Published: November 2014

AbstractOrganizations are becoming increasingly interested in improving their requirements engineering processes. The assessment of the current situation is the first step towards systematic process improvement. The REAIMS model (Sommerville et al. 1997) has been developed to evaluate the status of existing requirements practices. This paper describes an assessment process and two assessment instruments that can help organizations to use the REAIMS model. We evaluated the model, the process and the instruments by performing an assessment in three organizations. The results of the study indicate that the REAIMS model provides useful information for communication, motivation and process improvement planning. REAIMS assessment results are dependent on assessors, and are therefore not reliable for long‐term monitoring and benchmarking as such. A systematic assessment process such as the one described in this paper can improve reliability of assessment results.
5.7.1 On Soft Data and Test & Evaluation
Authors: Sproles Noel 
Published: November 2014

AbstractThe test and evaluation of complex socio‐technical systems is difficult. This is especially so when those involved in the testing and evaluation of such systems tend to associate closely with the physical sciences. The social or behavioral sciences have developed methods to address such problems and have shown that these methods are capable of providing rigorous results. A discussion of the worth of qualitative data and an overview of the social science methods likely to be appropriate for evaluating complex systems involving humans is provided. A brief overview of an instance where qualitative data analysis methods proved useful in the evaluation of a military command and control system is discussed in order to illustrate the merit of social science methods for T&E
7.7.2 The Mission System Design Center: A Pilot of Formulation‐Phase Concurrent Engineering in Aerospace Design
Authors: Wall S. D. 
Published: November 2014

AbstractIn this paper we describe pilots of a concurrent‐engineering, formulation‐phase design team demonstrated in spacecraft missions. This “Mission Team” operates within a design center called the Mission System Design Center, where design tools are linked via a central database and use large‐screen projection systems to engage the entire team in system‐level trade discussions. In these pilots, the Mission Team was able to manage complex trades, resolve conflicts, and rebalance requirements in the face of typical formulation phase issues. This team operates to periodically re‐evaluate requirements and resource allocations (e. g., mass, power, funds, datarate) in the face of both externally and internally imposed changes.
2.1.3 Functional Analysis for Existing Products: a Detailed Procedure
Authors: Lentz V. A. , Lerner Bruce 
Published: November 2014

AbstractFunctional Analysis (FA) for regenerative systems is often executed as reverse engineering or design recovery. The initial product developer completed the Functional Analysis, and minimal updates were required or took place as the product evolved. The working definition of a function has often become ambiguous. When the goal is to reify what the product / system does, Functional Analysis is one method to be used in conjunction with the identification of the scenarios to support a system decomposition to discover underlying functions. The scenarios identify how the system / product is used by external systems (a human or other man‐made system) and FA helps to expose the system behaviors that are required to support that use, and the functions that are required to support that behavior. The value of functional analysis is the yield of the main and derived functions of the system / product, which are the solution independent functions. The separation of the domain functions from the subsequently developed implementation functions (those required to provide a design dependent capability) facilitates the insertion of technology and management of change.The transition of the modular product structure Adifon [ADI2001] from the Phase 1 team to the on‐going implementation required the clarification and documentation of a procedure for Functional Analysis. The generic part of that procedure is described here with templates and detailed ‘user’ instructions.