bluuebunny/crossref_metadata_2025_split huggingface dataset:
6.2.2 Requirements for Outsourcing
Authors: Gilb Tom 
Published: November 2014

AbstractOutsourcing differs from other development because there is bound to be a contractual relationship, probably a geographic distance, a different sense of loyalty, language misunderstandings, cultural differences, reluctance to speak up to the client – and many other associated problems. Good requirements are always a problem, but outsourcing increases the problems, and makes even great demands on the requirements specification. The payoff for doing good requirements is greater, and the penalty for not doing them is more threatening.I am going to argue that we need to make use of far more explicit background specification for each requirement, a page or more of specification for each requirement. I will argue that this is a necessary investment – because failure to do so will probably cost far more – sooner or later. I will argue that failure to be more detailed than normal will be counted in the clients disfavor in any legal proceedings trying to determine responsibility for failure of the project.
7.1.2 Analysis of Singapore's 1991 Strategic Economic Plan Using the Large‐Scale Systems Engineering Framework
Authors: Seng Eng 
Published: November 2014

AbstractPlanning for large‐scale systems such as a country's economy is a huge undertaking and fraught with difficulties. This paper explores how such an undertaking could be managed using the large‐scale systems engineering framework. It uses the Singapore's Strategic Economic Plan of 1991 to retrospectively examine how well the large‐scale systems engineering framework could have measured up to such a Plan. It was found that such a framework is effective in understanding the complexities of and planning for such a large‐scale system.
7.3.0 Panel 7.3.0: SysML Early Applications and Lessons Learned
Authors: Friedenthal S. A. , Brookshier D. , Obeid P. , Peak R. , Steiner R. 
Published: November 2014

AbstractSysML is a general purpose systems modeling language that was adopted by the OMG in May 2006 (announced in early July). SysML is considered a key enabler to transition to model based systems engineering. The panel members will present what they have learned from their early experiences in implementing SysML from their diverse viewpoints, including end‐user, tool vendor and academic perspectives. Topics will include:End user perspective: Highlight industry experience on projects including What works, What methodologies are being employed, What is difficult, What is the response from the various stakeholders (customer, PM, software and hardware developers, testers) and What are suggested areas of improvement?Vendor perspective: Highlight tool vendor experiences including What SysML features are most requested, What has been difficult to implement, How well does SysML integrate with UML, What are suggested areas of improvement?Academia perspective: Highlight Academia experiences with SysML including Where does SysML fit in the curriculum and in research, What is difficult to teach, What is the response from students and faculty, What do you feel they are learning, and What are suggested areas of improvement (both from an educational perspective and a modeling language research perspective)?The moderator will also stimulate questions that cross the various viewpoints.
7.4.2 Development and Application of Abstract Relation Types for Use in Systems and System‐of‐Systems Design and Evaluation
Authors: Simpson Joseph J , Dagli Cihan , Miller Ann 
Published: November 2014

AbstractAbstract relation types (ART) are developed to represent, describe and establish a computational framework for a system. An abstract relation type is closely related to and builds upon two fundamental ideas. The first idea is the binary relation and structural modeling techniques developed by John N. Warfield. The second idea is the concept of abstract data types. These two ideas are combined to create an abstract relation type that provides a structured representation and computational method for systems and system components. The complete system description approach is based on six abstract relation types: context, concept, functions, requirements, architecture, and test (CCFRAT). When combined with digraphs and other graphical representations of the matrix form, ART provides a powerful tool for the communication of complex system interactions to large system design teams.
7.6.3 Case Study in Establishing Systems Engineering Principles: One Organization's Experience
Authors: Reutzel Adria Liszka 
Published: November 2014

AbstractEven within a well‐established systems engineering organization, formalizing the practice of systems engineering can be an arduous task. This paper describes one organization's effort to start this formalization by defining and documenting the very foundation of its practice: its systems engineering principles. Topics include the process for developing principles (augmenting organizational guidance with industry best practices), the final form of the principles (justifying terminology), and the connection to broader formalization efforts (associating the principles diagram to the systems engineering logo). The principles are divided into four categories that tie mainstream systems engineering definitions together: Stakeholder, Systems Engineer, Problem, and Solution.
9.4.3 Defining System Changeability: Reconciling Flexibility, Adaptability, Scalability, and Robustness for Maintaining System Lifecycle Value
Authors: Ross Adam M. , Rhodes Donna H. , Hastings Daniel E. 
Published: November 2014

AbstractDesigning and maintaining systems in a dynamic contemporary environment requires a rethinking of how systems provide value to stakeholders over time. Classically, two different approaches to promoting value sustainment may include developing either alterable or robust systems. The first accomplishes value delivery through altering the system to meet new needs, while the second accomplishes value delivery through maintaining a system to meet needs in spite of changes. The definitions of flexibility, adaptability, scalability, and robustness are shown to be different parts of the core concept of “changeability,” which can be described by three aspects: change agents, change effects, and change mechanisms. Cast in terms of system parameter changes, flexibility and adaptability are shown to relate to the origin of the change agent (external or internal to a system boundary respectively). Scalability and robustness, along with the additional property of modifiability, are shown to relate to change effects. The extent of changeability is determined by the number of possible change mechanisms available to the system as accepted by decision makers. Creating changeable systems, which can incorporate both classical notions of alterability and robustness, empowers systems to maintain value delivery over their lifecycle, in spite of changes in their contexts, thereby achieving value robustness to stakeholders over time.
10.1.2 Simple Yet Profound Enterprise Impact
Authors: Mooz Hal , Forsberg Kevin 
Published: November 2014

AbstractWe of The Center for Systems Management are continuously frustrated to find that many enterprises and organizations view process and process improvement as something that must be done to compete (SEI CMMI Level Three, ISO 9000, etc.) rather than as cost efficient best practices that produce substantial return on investment. In fact, some venture capitalists have stated to us “we want no process as it will inhibit our creativity.” Other enterprises state that they want to take it slow and easy with process adoption lest they bog down in the minutia of implementation.Unfortunately, these misperceptions are usually rooted in prior experiences where process improvement consisted of lengthy documentation and verbiage that ended up collecting dust on the bookshelf rather than being faithfully practiced by the enterprises' staff to produce exemplary and consistent results.Some of the most beneficial processes are extremely simple to implement yet they can produce high value results to the quality and safety of the activity. This paper explores a few of a family of Simple Yet Profound Management Techniques that if faithfully implemented will improve an enterprises performance and return on investment. The ultimate goal would be to have these processes instilled in a systemic enterprise culture.
10.4.0 Panel 10.4.0: U.S. OSD Systems of Systems Engineering Guide: Status Report & INCOSE Support
Authors: Baldwin Kristen , Dickerson Charles , Meilich Abe , Osterholz John , Touchin Malcolm , Bratt Steve 
Published: November 2014

AbstractIn May 2006, a task was issued by the U.S. Deputy Under Secretary of Defense for Acquisition and Technology (DUSD (A&T)) to develop a Systems of Systems Engineering Guidebook. The Office of the Secretary of Defense (OSD) convened a small group of Government, Industry and Academia, and selected the Stevens Institute of Technology to lead the project. During the summer and autumn of 2006, the International Council on Systems Engineering (INCOSE) was honored to be invited to provide a global representation of the systems engineering community in support of the OSD writing of a Systems of Systems, Systems Engineering (SoS SE) Guide.On 22 December 2006 the draft SoS SE Guide, version 0.9, was released for review and use by the systems engineering community. Industry and academia have been asked to submit their comments as part of the effort to pilot the recommendations in the Guide. In 2007, OSD has been actively engaging a sample of DoD SoS programs to pilot the Guide, especially with respect to the 16 OSD SE processes. The responses will become part of the first update to the Guide.At this panel, OSD will present the background and motivation for writing the Guide, along with an update on the pilot. Both OSD and INCOSE will discuss their insights. As part of the broad SE community review, the Guide will also be viewed from the UK perspective of Capabilities Based Acquisition. Looking to the future, the concepts and practices of Net Centricity, Network Enablement of Capabilities, and Semantic Web will be considered and how they might be more deeply integrated into future versions of the Guide. This panel will provide opportunities for INCOSE to continue to work with OSD and collaborate on SoS SE.
A Research Agenda for Systems of Systems Architecting
Authors: Axelband Elliot , Baehren Thomas , Dorenbos Dave , Madni Azad , Robitaille Paul , Valerdi Ricardo , Boehm Barry , Jackson Scott , Nadler Gerald , Settles Stan 
Published: November 2014

AbstractThis paper documents the activity of a workshop on defining a research agenda for Systems of Systems (SoS) Architecting, which was held at USC in October 2006. After two days of invited talks on critical success factors for SoS engineering, the authors of this paper convened for one day to brainstorm topics for the purpose of shaping the near‐term research agenda of the newly convened USC Center for Systems & Software Engineering. The output from the workshop is a list of ten high‐impact items with corresponding research challenges in the context of SoS Architecting.Each item includes a description of the research challenges, its link to contemporary academic or industrial problems, and reasons for advocacy of that area. The items were assessed in terms of value and difficulty to determine a prioritization both for the CSSE's future research agenda and for others in the field.
NCW – Nature's Predator‐Prey Abstraction
Authors: Gregg Michael L. , Miller Ann , Dagli Cihan 
Published: November 2014

AbstractThe Predator‐Prey ecosystem of the African savannahs provides a real‐world abstraction of network centric warfare (NCW). Prides of vultures scan the skies looking for dead or dying prey while packs of hyenas and lions fight it out on the ground to either track and kill their next meal or steal downed prey from their natural adversaries. Constantly observing and spying on each other, these incessant adversaries are always seeking a competitive advantage.When one of the circling vultures sights either downed prey or possible scraps from a ground‐based struggle, it signals others to descend. By doing so, they inadvertently share their intelligence with other predators on the ground. Based on distance to the prey, number of other predators in the area, and ratio of adversaries to allies, the race to the kill‐site is swift and the outcome means the difference between survival to fight again and starvation.Starting with the assumption that the Predator‐Prey ecosystem of the African savannah would be a real‐world abstraction of NCW, a study of the interactions between three representative species (lions, hyenas, and vultures) was initiated. Behavior, especially in regard to interactions with other species, pride or pack size, average ground or air speed, and territory size were investigated. During the investigation, it became clear that the interactions between the species could be clearly viewed as an analogy to a set of mobile combatants seeking to overthrow their adversaries; in this case the goal is food (i.e., survival) rather than social power, money, or property.A portion of this work analyzes the behavioral characteristics of each species much like war fighters dissect the capabilities of their adversaries. These species‐based parameters were used to analyze how different distributions of prey, in relation to predator territories, influence which predator species gets to the prey first in sufficient numbers to get the majority of the food. The analysis was performed using a simple Monte Carlo discrete event simulation model and considered the nominal, aggregated behavior of each pack or pride as a single unit, not the behavior of individual pack members. Using these aggregated characteristics of speed and the ability to sense downed prey at a distance, a clear parallel could be drawn to the groups of armed forces in war zones relative to available surveillance and tracking systems. Albeit, the struggle in the African savannah is an on‐going, zero‐sum war game.
2.4.1 An investigation into how systems engineering can help preserve natural environments
Authors: Fossnes Terje , Haskins Cecilia 
Published: November 2014

AbstractThe INCOSE Systems Engineering Vision suggests that if systems engineering is to be adopted by small and medium enterprises then lean/agile process sets must emerge accompanied by multiple views that include socio‐technical, economic and political perspectives.In this paper, the authors apply a lightweight systems engineering framework to analyze a socio‐technical problem domain with the potential to influence the quality of life in the Norwegian High Mountain Plateau. The results indicate that while many requirements of a vacation home are met by the architecture, providing modern conveniences while at the same time preserving the natural environment requires technological solutions, and systems engineering. In the opinion of these authors, this epitomizes the meaning of ‘Systems Engineering for the Planet.’
3.1.1 Working Towards a New Characterisation of Architecture
Authors: Bryant Peter , King Paul 
Published: November 2014

AbstractThe paper will discuss progress towards a new characterisation of architecture based on the activities of the recently formed INCOSE UK Chapter Architecture Working Group.The focus of the paper will be on describing the diversity of opinion we have observed in discussions of the fundamental characteristics of architecture and progress towards resolving the various conflicts that arise.We have made progress in refining the definition of architecture, the understanding of the role of patterns within architecting and how the conceptual underpinnings of architecture may be made consistent with the uses and types of architecture.
4.2.1 Software versus Systems Engineering, is there a difference?
Authors: Hadderingh J.N. 
Published: November 2014

AbstractThe topic for this paper is the question: should software engineering be considered a discipline of its own or is it identical to systems engineering. As software is becoming more and more important for systems this question becomes relevant as it addresses the approach towards software by the systems engineering community. This paper proposes to divide what is commonly called software engineering in two disciplines;
A specialty engineering discipline
A systems engineering discipline
The paper suggests the systems engineering discipline within software engineering to be identical to “normal” systems engineering. And supportive material is provided to support this statement.
4.3.2 Global Systems Engineering Competencies: A Business Advantage
Authors: Arnold Eileen 
Published: November 2014

AbstractAs market boundaries change, diversified corporations can no longer focus on end product markets. A competency system, flowed‐down from enterprise and business objectives and strategy to a workforce comprised of an individual's competencies with a global Systems Engineering focus, is proposed as a business advantage. Unexpected results, capitalizing on the synergies and combinations of competencies; the “whole is more than the sum of its parts” concept illustrates a newly introduced term, Emergent Competency behavior. A multi‐dimensional Systems Engineering Competency Model example, based on individual competencies with global and layer dimensions, is provided as a way to leverage the knowledge, skills, abilities, and attitudes of a workforce to achieve business success. Six categories of competencies are proposed to include Enterprise, Domain, Discipline, Cognitive, Environmental Sustainability, and Behavioral.
5.1.1 Conceptual Design to Cost: A new systems engineering tool
Authors: Hari Amihud , Shoval Shraga , Kasser Joseph 
Published: November 2014

AbstractIncorporating cost considerations in the system design is a critical part of the system development process. However, since current methods of incorporating cost considerations into the design need knowledge of the cost of the actual components to be used in the system; the technique know as Design to Cost (DTC) is not suitable for use in the conceptual or in the preliminary design phase where it is most needed. This paper introduces a methodology for performing DTC in the front ‐ end design phase that has been used with some success to provide cost estimates. This methodology, Conceptual DTC (CDTC) fills a critical gap in the systems engineer's toolbox. This paper begins with a short review of DTC, and then describes the CDTC methodology which allows cost factors to be treated in the same manner as the other system factors such as functional, performance, reliability and safety etc. as an integrated part of the design process, rather than as an external bolt‐on.
5.3.1 A Safety‐Driven Systems Engineering Process
Authors: Stringfellow Margaret V. , Owens Brandon D. , Dulac Nicolas , Leveson Nancy G. 
Published: November 2014

AbstractThis paper describes a new systems engineering process for safety‐driven development that combines three state‐of‐the‐art techniques: 1) Intent Specification, a framework for organizing system development and operational information in a hierarchical structure; 2) the STAMP model of accident causation, a system‐theoretic framework upon which to base more powerful safety engineering techniques; and 3) STAMP‐based Hazard Analysis (STPA).
5.3.2 The Development of International Standards for Very Small Enterprises
Authors: Laporte Claude Y. , Renault Alain , Alexandre Simon , Crowder Kenneth V 
Published: November 2014

AbstractIndustry recognizes that there are very small enterprises that develop parts which contain software components. These enterprises are very important to the world‐wide economy, and the parts they develop are often integrated into products made by larger enterprises. Failure to deliver a quality product on time and within budget threatens the competitiveness of both organizations. One way to mitigate these risks is for all the suppliers in a product chain put in place recognized engineering practices. Many international standards have been developed to capture proven engineering practices. However, these standards were not written for very small development organizations, those with less than 25 employees, and are consequently difficult to apply in such settings. An ISO/IEC JTC1/SC71 Working Group has been established to address these difficulties.
8.1.1 Service Engineering
Authors: Kemp Duncan , Linton Robert 
Published: November 2014

AbstractThis paper describes the approach being used to introduce net‐centric solutions into service within the UK Ministry of Defence. It describes specific differences between engineering conventional systems (such as ships or aircraft) and engineering net‐centric solutions and the problems that they introduce.The paper describes an approach to net‐centric systems development, which is based on the integration of three interdependent applications of conventional systems engineering: at the business, the service and component levels. The major focus of this approach is the extension of systems engineering from the design and manufacture of components into the delivery of services and the achievement of business effect.The paper describes some key techniques used in the systems engineering of services. These include benefits realisation management, service level definition, service architecting, performance design and application characterisation, capacity management and service acceptance.Finally the paper describes some of the cultural and behavioural issues that the authors have found essential to success.
8.1.2 Continuous Systems Development for Command, Control and Intelligence Systems
Authors: Yeoh Lean Weng , Teo Tiat Leng , Lim Horng Leong 
Published: November 2014

AbstractThe traditional software development model is no longer adequate to meet the challenges of fast evolving needs of Command, Control and Intelligence (C2I) systems. To enable the transformation of the 3rd Generation Singapore Armed Forces, continuous systems development approach has been adopted by Defence Science & Technology Agency (DSTA) to develop C2I capabilities for the Singapore Armed Forces (SAF). The key advantage of this approach lies in its flexibility to respond rapidly to meet changing needs and address emerging threats. The complexities of network centric operation entail the fielding of systems quickly for operational trials and to continuously discover capability gaps, so as to evolve systems capabilities over its lifecycle. This paper addresses the framework adopted by DSTA to develop C2I System‐of‐Systems.
10.3.1 Design with Overview – how to survive in complex organisations
Authors: Bonnema G. Maarten , Borches P. Daniel 
Published: November 2014

AbstractLiterature on how the design process should be conducted is abundant. Also literature on how the design process is performed in practice can be found. An issue that has received less attention is how to keep overview while the design project evolves. This article will look at several aspects of overview in the design process. Encapsulation is proposed as a means to avoid saturation of system designers, yet providing enough detail information. The notion of sampling the design process is introduced, as an equivalent to sampling a signal in time.The paper proposes to use the Function ‐ Key drivers architecting tool (FunKey) as a means to keep overview. Using this tool, it is possible to encapsulate details, yet provide insight and overview where needed. Also, it is possible to sample progress in the design project at a much higher frequency than using the (document) reviews described in system engineering guidelines like the INCOSE handbook.