摘要:

AbstractMost system engineers today use graphical representations of a system to communicate its functional and data requirements. The most commonly used representations are the Function Flow Block Diagram (FFBD), Data Flow Diagram (DFD), N2 Chart, IDEF0 Diagram, and Behavior Diagram (BD). This paper discusses the characteristics of each and shows how they are related.When analyzed in the context of specifying functional control and data modeling, it appears that the FFBD and DFD representations are limiting, special cases of the Behavior Diagram. The N2 Chart has the same capability as the DFD, with a more formal format. The IDEF0 is essentially an N2 Chart with some control definition (no constructs) capability. The IDEF0 has the capability to indicate the allocation of functions to system components.Thus, the Behavior Diagram features comprise a “parent/unified” set of graphical system representations. To achieve the same level of specification completeness, you would have to use an integrated set of the FFBD and one of the data models or augment the FFBD with a graphical representation of the data model, as was done at TRW (then called Function Sequence Diagrams, FS

ISSN:2334-5837    

DOI:10.1002/j.2334-5837.1995.tb01965.x

年代:1995

数据来源: WILEY

摘要:

AbstractAs currently defined and practiced, the systems engineering process (SEP) overlooks the design of human‐system interaction (HSI) as a systems engineering activity. Integrating HSI engineering into the SEP would promote the cost‐effective development of highly usable, reliable systems and products. This paper shows that the integration effort must identify the roles that humans play and the perspectives from which system development can be perceived: Support system, environmental system, and total system (which includes the system's users). This paper presents a scheme for an SEP that includes HSI definition and design, and it shows an example of applying the scheme to a software system, where the HSI is human‐computer interaction. Integrating HSI engineering and SEP forms the basis of effective multidisciplinary collaboration and the development of human‐centered

ISSN:2334-5837    

DOI:10.1002/j.2334-5837.1995.tb01966.x

年代:1995

数据来源: WILEY

摘要:

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 pract

ISSN:2334-5837    

DOI:10.1002/j.2334-5837.1995.tb01967.x

年代:1995

数据来源: WILEY

摘要:

AbstractA rapid method has been developed for the design of computing system capabilities and/or human work flow activities. This design method is call Rapid Process Design (RPD) and is based on the definition of processes and not requirements. This design originally was developed for use as a preliminary design tool supporting the Definition Phase for system development programs using the Rapid Development Methodology (RDM) [1]. The RPD method allows for quick design of automated computing processes for immediate computing system capability deliveries. A key element of RPD is the definition of a process and its associated conditions and constraints. The process definition can be used to support evaluation and testing of a delivered computing system capability or human work flow.

ISSN:2334-5837    

DOI:10.1002/j.2334-5837.1995.tb01968.x

年代:1995

数据来源: WILEY

摘要:

AbstractResearchers and Project Managers in a research and development environment often resist the notion that a structured process such as System Engineering can be applied to their environment. While it is impossible to invent to a schedule, it is certainly possible and necessary to use good engineering practices in the research and development process. System Engineering is one of these necessary engineering disciplines.To illustrate the use of System Engineering in its applications in R&D, this paper will follow the development of a new ceramic material from its origin in the research laboratories in the early 1960s through its application to the Space Shuttle thermal protection studies in the late 1960s and its production scale‐up as the Space Shuttle tile material in the 1970s, to its ultimate potential in the current exploratory studies as a matrix for repair of human bone in the 1990s.The author was closely associated with the material throughout much of its history. In the mid‐ to late 1960s the author was deputy director of the Materials and Structures Laboratory (where the material was invented by Robert Beasley) in the Lockheed Palo Alto, California, Research Facility. The author later became program manager of the Space Shuttle Tile Prog

ISSN:2334-5837    

DOI:10.1002/j.2334-5837.1995.tb01969.x

年代:1995

数据来源: WILEY

摘要:

AbstractIn today's systems engineering environment, budgets are decreasing while needs are remaining constant or even increasing. This paper discusses the concept of designing systems so that in the event of budget reductions, there is no need to cancel the project and restart the development of a system with lower capability. Instead, the least‐important requirements are easily eliminate

ISSN:2334-5837    

DOI:10.1002/j.2334-5837.1995.tb01970.x

年代:1995

数据来源: WILEY

摘要:

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 requirement

ISSN:2334-5837    

DOI:10.1002/j.2334-5837.1995.tb01971.x

年代:1995

数据来源: WILEY

摘要:

AbstractGovernment and industry are focusing on “information” system technology to provide dramatic changes that will be the critical factors in a comprehensive range of activities from achieving‐competitive‐advantage to winning‐wars. System, software, and security engineering for information systems involve principles and practices that continue to evolve. This paper identifies, compares, and questions those principles and practices. It characterizes the information system development/integration paradigms as being in a state of flux. In addition, architectural concepts are discussed that provide a framework for information system services that support a variety of missions and functions.Three salient points of the paper are: (1) system engineers should become familiar with “technical” information system architecture alternatives, (2) advances in technology are leading to the merging of system, software, and hardware engineering disciplines at the architectural level, and (3) requirements‐definition and design‐resolution procedures are being revolutionized through incremental/continuous deve

ISSN:2334-5837    

DOI:10.1002/j.2334-5837.1995.tb01972.x

年代:1995

数据来源: WILEY

摘要:

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.

ISSN:2334-5837    

DOI:10.1002/j.2334-5837.1995.tb01973.x

年代:1995

数据来源: WILEY

摘要:

AbstractThis paper argues for the necessity of an engineering discipline for computer based systems and outlines its beginnings. It is based on results obtained and directions mapped out for such a discipline by the IEEE Technical Committee on Engineering of Computer Based Systems (ECBS).Computer Based Systems are seen as the technical artifacts of a dedicated engineering discipline. Experience and heuristics of such a discipline need to be grounded in a practical theory. On top of such a theory, a systems engineering approach has to be defined that allows the professional practice of the discipline and the safeguarding of the entire life cycle of all its artifacts. Such a systematization of a discipline inevitably leads to guidelines and to reference standards. Those reference standards reflect the systems engineering approach and regulate the engineering process. The different classes those reference standards fall into are discussed and some consequences are proposed.

ISSN:2334-5837    

DOI:10.1002/j.2334-5837.1995.tb01974.x

年代:1995

数据来源: WILEY