This standard describes an iterative process for managing and executing software maintenance activities. Use of this standard is not restricted by size, complexity, criticality, or application of the software product. This standard uses a process model to discuss and depict aspects of software maintenance. The criteria established apply to both the planning of maintenance for software while under development, as well as the planning and execution of software maintenance activities for existing… read more software products. Ideally, maintenance planning should begin during planning for software development. This International Standard provides the framework within which generic and specific software maintenance plans may be executed, evaluated, and tailored to the maintenance scope and magnitude of given software products. This International Standard provides the framework, precise terminology, and processes to allow the consistent application of technology (tools, techniques, and methods) to software maintenance. This International Standard provides requirements and guidance for the maintenance of software. The basis for the Maintenance Process and its activities is consistent with ISO/IEC/IEEE 12207:2017, Systems and software engineering -- Software life cycle processes. This standard defines the activities and tasks of software maintenance, and provides maintenance planning requirements. It does not address the operation of software and the operational functions, e.g., backup, recovery, or system administration, which are normally performed by those who operate the software. read less
This document specifies the concept of integrity levels with the corresponding integrity level requirements for achieving the integrity levels. Requirements and recommended methods are provided for defining and using integrity levels and their corresponding integrity level requirements. This document covers systems, software products, and their elements, as well as relevant external dependences. This document is applicable to systems and software and is intended for use by: a) definers of… read more integrity levels such as industry and professional organizations, standards organizations, and government agencies; b) users of integrity levels such as developers and maintainers, suppliers and acquirers, system or software users, assessors of systems or software and administrative and technical support staff of systems and/or software products. One important use of integrity levels is by suppliers and acquirers in agreements, for example, to aid in assuring safety, financial, or security characteristics of a delivered system or product. This document does not prescribe a specific set of integrity levels or their integrity level requirements. In addition, it does not prescribe the way in which integrity level use is integrated with the overall system or software engineering life cycle processes. It does, however, provide an example of use of this document in Annex A. read less
SBus is a high performance computer I/O interface for connecting integrated circuits and SBus Cards to a computer system motherreboard. This standard defines the mechanical, electrical, environmental, and protocol requirements for the design of SBus Cards and the computer system motherreboard that supports those cards. Every SBus Card shall implement appropriate self-descriptive and initialization firmware using FCode, which is similar to the Forth programming language. The details of this… read more firmware standard are beyond the scope of this standard.1) In addition, other software interfaces may be used for communication with SBus Cards. SBus is intended to provide a high performance I/O bus interface with a small mechanical form factor. The small size, high levels of integration, and low power usage of SBus Cards enable them to be used in laptop computers, compact desktop computers, and other applications requiring similar characteristics. SBus Cards are mounted in a plane parallel to the motherreboard of the computer system, allowing the computer system to have a low profile. SBus is not designed as a general purpose backplane bus. SBus allows transfers to be in units of 8, 16, 32, or 64 bits. Burst transfers are allowed to further improve performance. SBus allows a number of SBus Master devices to arbitrate for access to the bus. The chosen SBus Master provides a 32-bit virtual address which the SBus Controller maps to the selection of the proper SBus Slave and the development of the 28-bit physical address for that Slave. The selected SBus Slave then performs the data transfers requested by the SBus Master. Simple SBus Cards may be designed to operate solely as Slaves on the SBus. read less
This document establishes a common framework of process descriptions for describing the life cycle of systems created by humans, defining a set of processes and associated terminology from an engineering viewpoint. These processes can be applied to systems of interest, their system elements, and to systems of systems. Selected sets of these processes can be applied throughout the stages of a system's life cycle. This is accomplished through the involvement of stakeholders, with the ultimate goal of achieving customer satisfaction.
ISO/IEC 8802 local area networks (LANs) of all types can be connected together using MAC bridges. Each individual LAN has its own independent MAC. The bridged LAN created allows the interconnection of stations as if they were attached to a single LAN, although they are in fact attached to separate LANs each with its own MAC. A MAC bridge operates below the MAC service boundary, and is largely transparent to protocols operating above this boundary, in the Logical Link Control (LLC) sublayer or… read more Network layer. The presence of one or more MAC bridges can lead to differences in the quality of service provided by the MAC sublayer; it is only because of such differences that MAC bridge operation is not fully transparent. read less
This document establishes a common process and framework for measurement of systems and software. It defines a process and associated terminology from an engineering viewpoint. The process can be applied to the project and products across the life cycle. The measurement process can be applied throughout the life cycle to aid the planning, managing, assessing, and decision-making in all stages of a system or software life cycle. This document also provides activities that support the definition,… read more control and improvement of the measurement process used within an organization or a project. This document does not assume or prescribe an organizational model for measurement. The user of this document decides, for example, whether a separate measurement function is necessary within the organization and whether the measurement function should be integrated within individual projects or across projects, based on the current organizational structure, culture and prevailing constraints. This document does not prescribe a specific set of measures, method, model or technique. The users of this document are responsible for selecting a set of measures for the project and defining the application of those measures across the process, products, and other elements of the life cycle. The parties are also responsible for selecting and applying appropriate methods, models, tools and techniques suitable for the project. This document is not intended to prescribe the name, format, explicit content, or recording media of the information items to be produced. This document does not imply that documents be packaged or combined in some fashion. These decisions are left to the user of this document. ISO/IEC/IEEE 15289 addresses the content for life cycle process information items (documentation). The measurement process is supposed to be appropriately integrated with the organizational quality system. Not all aspects of internal audits and non-compliance reporting are covered explicitly in this document as they are assumed to be in the domain of the quality system. This document is not intended to conflict with any organizational policies, standards or procedures that are already in place. However, any conflict should be resolved and any overriding conditions and situations need to be cited in writing as exceptions to the application of this document. read less
This document: — provides risk management elaborations for the processes described in ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207, — provides the users of ISO/IEC/IEEE 15288, ISO/IEC/IEEE 12207 and their associated elaboration standards with common terminology and specialized guidance for performing risk management within the context of systems and software engineering projects, — specifies the required information items that are to be produced through the implementation of risk management… read more process for claiming conformance, and — specifies the required contents of the information items. This document provides a universally applicable standard for practitioners responsible for managing risks associated with systems and software over their life cycle. This document is suitable for the management of all risks encountered in any organization or project appropriate to the systems or software projects regardless of context, type of industry, technologies utilized, or organizational structures involved. This document does not provide detailed information about risk management practices, techniques, or tools which are widely available in other publications. Instead this document focuses on providing a comprehensive reference for integrating the large and wide variety of processes, practices, techniques, and tools encountered in systems and software engineering projects and other lifecycle activities into a unified approach for risk management, with the purpose of providing effective and efficient risk management while meeting the expectations and requirements of organization and project stakeholders. read less
This part of ISO/IEC/IEEE 21451 defines communication methods and data formats for transducers (sensors and actuators) communicating with RFID tags. This part of ISO/IEC/IEEE 21451 also defines Transducer Electronic Data Sheet (TEDS) formats based on the ISO/IEC/IEEE 21451 series of standards and protocols for accessing TEDS and transducer data. It adopts necessary interfaces and protocols to facilitate the use of technically differentiated, existing technology solutions. It does not specify… read more transducer design or signal conditioning. There is currently no openly defined independent interface standard between transducers and RFID tags. Each vendor builds its own interface. Without such a standard, transducer interfacing and integration to RFID tags and systems are time-consuming and all vendors' duplicated efforts are economically unproductive. The purpose of this part of ISO/IEC/IEEE 21451 is to provide interfaces and methods for interfacing transducers to RFID tags and reporting transducer data within the RFID infrastructure. It also provides the means for device and equipment interoperability. read less
The scope is the considerations that arise at key points in the life cycle for a system of interest (SOI) that is considered as a constituent part of a system of systems (SoS). SoS engineering is the process of planning, analyzing, organizing, and integrating the capabilities of a mix of existing and new systems into a system-of-systems capability that is greater than the sum of the capabilities of the constituent parts. It is intended to guide the engineering of the SOI through consideration of potential SoS impacts on system concepts, requirements, design, and operations and maintenance. At each stage of the life cycle of a system, key SoS operational, technical and management considerations are identified as needed to operate effectively in an SoS context.
This document provides guidance on the application of processes in ISO/IEC/IEEE 15288 to systems of systems (SoS). The scope of this document is the same as ISO/IEC/IEEE 15288, which addresses more than systems engineering activities. This document provides general guidance for each ISO/IEC/IEEE 15288 process and process outcome in the context of SoS, but it does not address specific activities, tasks, methods, or procedures. Additional processes and process outcomes unique to SoS can still be… read more needed and are not covered by this document. This document explores the similarities and differences between systems and SoS and, by extension, the similarities and differences between engineering of systems and SoS. The guidance contained in this document is expected to evolve as the discipline matures. read less
This document deals with the tool capabilities and methods for model-based systems and software engineering (MBSSE). This document:--specifies a reference model for the overall structure and processes of MBSSE-specific processes, and describes how the components of the reference model fit together;--specifies interrelationships between the components of the reference model;--specifies MBSSE-specific processes for model-based systems and software engineering; the processes are described in terms… read more of purpose, inputs, outcomes and tasks;--specifies methods to support the defined tasks of each process;--specifies tool capabilities to automate or semi-automate tasks or methods. This document does not bring any additional life cycle processes for system and software but specifies an MBSSE reference model considered as activities, not only from the life cycle perspectives of systems engineering problem solving and the system-of-interest evolution, but also from the cognitive perspectives of modelling and model management, which can sustain and facilitate the system and software life cycle processes during digital transformation and in the digital age. The processes defined in this document are applicable for a single project, as well as for an organization performing multiple projects or an enterprise. These processes are applicable for managing and performing the systems and software engineering activities based on models within any stage in the life cycle of a system-of-interest. read less