bluuebunny/crossref_metadata_2025_split huggingface dataset:
1.4.1 VALUE SYSTEMS ANALYSIS: APPLICATION TO TEAM MOTIVATION
Authors: McCumber William H. 
Published: November 2014

AbstractDegree 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

AbstractDesign 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

AbstractThe 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

AbstractOrganisations 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

AbstractThe 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

AbstractSystems 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

AbstractThe 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

AbstractModern 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

AbstractSmall 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

ABSTRACTThis 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.
Continuous Electronic ENhancements using Simulatable Specifications
Authors: Gearhart Larry , Thullen Mark , Winn Alan 
Published: November 2014

ABSTRACTCurrent 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

ABSTRACTThis 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

ABSTRACTAs 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

ABSTRACTThe 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

ABSTRACTIn 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

ABSTRACTHaving 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

ABSTRACTRecent 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

ABSTRACTRoughly 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

ABSTRACTAs 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

ABSTRACTToday'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

ABSTRACTDoD 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

ABSTRACTIn 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.