| Name |
Description |
Abstract |
Status |
Publication date |
Edition |
Number of pages |
Technical committee |
ICS |
| ISO/IEC/IEEE 16326:2019 |
Systems and software engineering — Life cycle processes — Project management |
1.1 Purpose This document is intended to aid project managers in managing to successful conclusion those projects concerned with systems, including software systems.
This document specifies the required content of the project management plan (PMP). This document also quotes the extracted purpose and outcome statements from the technical management processes of ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207, and adds detailed guidance for managing projects that use these processes for systems, including software systems.
1.2 Field of application This document is written for those who use or plan to use ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207 on projects dealing with systems, including software systems, regardless of project scope, products, methodology, size or complexity. The field of application of this document spans the whole system or software life cycle and addresses all project management roles, specifically:
— those responsible for establishing and continuously improving their organization's policies for implementing ISO/IEC/IEEE 15288 system life cycle processes and ISO/IEC/IEEE 12207 software life cycle processes;
— those responsible for executing any ISO/IEC/IEEE 15288 system life cycle process or ISO/IEC/IEEE 12207 software life cycle process at a project level.
— organizations or individuals subcontracting a project management effort.
In many organizations, the various responsibilities of project management are assigned to more than one person. Where the term "project manager" is used in this document, the guidance, advice or normative requirement is taken as applying to the applicable role within the organization.
This document is intended to provide guidance for two-party situations and can be equally applied where the two parties are from the same organization. This document can also be used by a single party as self-imposed tasks.
This document can also serve as guidance in multi-party situations, where high risks are inherent in the supply and integration of complex software-based systems, and procurement can involve several vendors, organizations or contracting parties.
1.3 Limitations The normative content specifications for PMPs and the guidance for application of the technical management processes have general application across the scope of ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207, but are developed with a focus on projects dealing with systems with a significant software element, and software systems.
|
Published |
2019-12 |
Edition : 2 |
Number of pages : 29 |
Technical Committee |
35.080
Software
|
| ISO/IEC 16350:2015 |
Information technology — Systems and software engineering — Application management |
ISO 16350:2015 establishes a common framework for application management processes with well-defined terminology that can be referenced by the software industry. It contains processes, activities, and tasks that apply during the stage of operation and use from the point of view of the supplier organization that enhances, maintains, and renews the application software and the software-related products such as data-structures, architecture, designs, and other documentation. It applies to the supply, maintenance, and renewal of applications, whether performed internally or externally with respect to the organization that uses the applications.
|
Published |
2015-08 |
Edition : 1 |
Number of pages : 85 |
Technical Committee |
35.080
Software
|
| ISO/IEC TR 16351:2019 |
Information technology — Systems and software engineering — Application management guidance on the relationship between ISO/IEC 16350:2015 and Application Service Library® |
This document provides guidance on the relationship between ISO/IEC 16350:2015 and a commonly used application management framework, ASL. It can be used by any organization or person wishing to understand how ASL can be used with ISO/IEC 16350:2015, including:
a) an internal or external application management organization that has demonstrated or intends to demonstrate conformity to the requirements specified in ISO/IEC 16350:2015 and is seeking guidance on the use of ASL to establish and improve an AMS and the processes;
b) an application management organization that already uses ASL and is seeking guidance on how ASL can be used to support efforts to demonstrate conformity to the requirements specified in ISO/IEC 16350:2015;
c) an assessor or auditor who wishes to understand the use of ASL as support to achieve the requirements specified in ISO/IEC 16350:2015.
The correlations provided in this document relate to the 2nd version of ASL® (ASL2).
Clause 4 describes how ASL® can support the demonstration of conformity to ISO/IEC 16350:2015.
Clause 5 relates chapters in ASL® to clauses in ISO/IEC 16350:2015.
|
Published |
2019-09 |
Edition : 1 |
Number of pages : 8 |
Technical Committee |
35.080
Software
|
| ISO/IEC 17998:2012 |
Information technology — SOA Governance Framework |
ISO/IEC 17998:2012 describes a framework that provides context and definitions to enable organizations to understand and deploy service-oriented architecture (SOA) governance.
ISO/IEC 17998:2012 defines:
SOA Governance, including its relationship between Business, IT, and EA governance; this assists organizations in understanding the impact that the introduction of SOA into an organization has on governance;
an SOA Governance Reference Model (SGRM) and its constituent parts, which assists organizations in specifying their appropriate governance regimes; and capturing best practice as a basis for a common approach;
the SOA Governance Vitality Method (SGVM) which assists organizations in customizing the SGRM and realizing their SOA Governance Regimen.
ISO/IEC 17998:2012 is not intended to be used as provided; it is intended to be customized to create appropriate SOA governance for the organization. Many of the lists are non-normative and exemplary and intended to be filtered and as input to the customization process.
ISO/IEC 17998:2012 does not include an explanation of the fundamentals and value of SOA, which is important for being able to understand and apply SOA governance. It lists some of the many other specifications and books that are available on SOA basics.
|
Published |
2012-09 |
Edition : 1 |
Number of pages : 87 |
Technical Committee |
35.080
Software
;
35.100.05
Multilayer applications
|
| ISO/IEC TR 18018:2010 |
Information technology — Systems and software engineering — Guide for configuration management tool capabilities |
Configuration management (CM) is a process central to the software engineering life cycle. CM has been established as an ISO/IEC standard life cycle process in ISO/IEC 12207:2008, Information technology — Software life cycle processes and ISO/IEC 15288: 2008, Information technology — System life cycle processes.
ISO/IEC 12207:2008 and ISO/IEC 15288:2008 describe a comprehensive set of processes, activities and tasks to be performed when acquiring or developing software. However, these documents do not address the capabilities that a CM tool user can expect from a tool in order to support the CM process and other software engineering life cycle activities. There is a gap between CM process descriptions and corresponding CM process automation services which affects both tool users and tool suppliers.
ISO/IEC TR 18018:2010 provides guidance in the evaluation and selection for CM tools during acquisition. CM tool evaluation by prospective users can be complex, time consuming, and expensive. ISO/IEC TR 18018:2010 helps to characterize what a CM tool can and cannot do in the CM process.
ISO/IEC TR 18018:2010 provides guidance for tool manufacturers in implementing a minimum set of capabilities. The capabilities defined in ISO/IEC TR 18018:2010 are linked to ISO/IEC 12207:2008 and ISO/IEC 15288:2008, and will provide tool manufacturers with guidance on the characteristics their tools should support to meet these International Standards.
|
Published |
2010-02 |
Edition : 1 |
Number of pages : 27 |
Technical Committee |
35.080
Software
|
| ISO/IEC 18019:2004 |
Software and system engineering — Guidelines for the design and preparation of user documentation for application software |
ISO/IEC 18019:2004 provides guidelines for the design and preparation of user documentation for application software. It describes how to establish what information users need, how to determine the way in which that information should be presented to the users, and how then to prepare the information and make it available.
Application software includes consumer software packages, software for office applications, business software and specialist software for use by professionals.
ISO/IEC 18019:2004 is for use by people responsible for specifying, designing and preparing user documentation for application software and people who manage these activities, including developers of tools for creating hardcopy documentation, product designers, application developers, project managers, authors, programmers, translators and localization staff.
It is intended for use in all types of organizations, whether or not a dedicated documentation department is present. In all cases, it can be used as a basis for local standards and procedures. Readers are assumed to have experience or knowledge of software development or documentation development processes.
|
Withdrawn |
2004-01 |
Edition : 1 |
Number of pages : 146 |
Technical Committee |
35.080
Software
|
| ISO/IEC 19500-1:2012 |
Information technology — Object Management Group — Common Object Request Broker Architecture (CORBA) — Part 1: Interfaces |
ISO/IEC 19500-1:2012 specifies the CORBA Object Model and uses concepts from that model to define the operation of the Object Request Broker (ORB). The ORB is the basic mechanism by which objects transparently make requests to, and receive responses from, each other on the same machine or across a network. A client need not be aware of the mechanisms used to communicate with or activate an object, how the object is implemented, or where the object is located.
|
Published |
2012-04 |
Edition : 1 |
Number of pages : 509 |
Technical Committee |
35.080
Software
|
| ISO/IEC 19500-2:2003 |
Information technology — Open Distributed Processing — Part 2: General Inter-ORB Protocol (GIOP)/Internet Inter-ORB Protocol (IIOP) |
ISO/IEC 19500-2:2003 specifies the General Inter-ORB Protocol (GIOP) for object request broker (ORB) interoperability. GIOP can be mapped onto any connection-oriented transport protocol that meets a minimal set of assumptions defined by this standard.
ISO/IEC 19500-2:2003 also defines the Internet Inter-ORB Protocol (IIOP), a specific mapping of the GIOP which runs directly over connections that use the Internet Protocol and the Transmission Control Protocol (TCP/IP connections).
ISO/IEC 19500-2:2003 provides a widely implemented and used particularization of ITU-T Rec. X.931 | ISO/IEC 14752. It supports interoperability and location transparency in ODP systems.
|
Withdrawn |
2003-04 |
Edition : 1 |
Number of pages : 96 |
Technical Committee |
35.080
Software
|
| ISO/IEC 19500-2:2012 |
Information technology — Object Management Group — Common Object Request Broker Architecture (CORBA) — Part 2: Interoperability |
ISO/IEC 19500-2:2012 specifies a comprehensive, flexible approach to supporting networks of objects that are distributed across and managed by multiple, heterogeneous CORBA-compliant Object Request Brokers (ORBs). The approach to inter-ORB operation is universal, because elements can be combined in many ways to satisfy a very broad range of needs.
ISO/IEC 19500-2:2012 specifies
ORB interoperability architecture
Inter-ORB bridge support
General Inter-ORB Protocol (GIOP) for object request broker (ORB) interoperability. GIOP can be mapped onto any connection-oriented transport protocol that meets a minimal set of assumptions defined by this International Standard
Internet Inter-ORB Protocol (IIOP), a specific mapping of the GIOP which runs directly over connections that use the Internet Protocol and the Transmission Control Protocol (TCP/IP connections)
CORBA Security Attribute Service (SAS) protocol and its use within the CSIv2 architecture to address the requirements of CORBA security for interoperable authentication, delegation, and privileges
ISO/IEC 19500-2:2012 provides a widely implemented and used particularization of ITU-T Rec. X.931 | ISO/IEC 14752. It supports interoperability and location transparency in ODP systems.
|
Published |
2012-04 |
Edition : 2 |
Number of pages : 226 |
Technical Committee |
35.080
Software
|
| ISO/IEC 19500-3:2012 |
Information technology — Object Management Group — Common Object Request Broker Architecture (CORBA) — Part 3: Components |
ISO/IEC 19500-3:2012 defines
the syntax and semantics of a component model, based on CORBA IDL, and a corresponding meta-model,
a language to describe the structure and state of component implementations, and a corresponding meta-model,
a programming model for constructing component implementations,
a runtime environment for component implementations,
interaction between components and Enterprise Java Beans,
meta-data for describing component-based applications, and interfaces for their deployment, and
a lightweight subset of the component model, programming model and runtime environment.
|
Published |
2012-04 |
Edition : 1 |
Number of pages : 339 |
Technical Committee |
35.080
Software
|
| ISO/IEC 19501:2005 |
Information technology — Open Distributed Processing — Unified Modeling Language (UML) Version 1.4.2 |
ISO/IEC 19501:2004 describes the Unified Modeling Language (UML), a graphical language for visualizing, specifying, constructing and documenting the artifacts of a software-intensive system. The UML offers a standard way to write a system's blueprints, including conceptual things such as business processes and system functions, as well as concrete things such as programming language statements, database schemas, and reusable software components.
|
Published |
2005-04 |
Edition : 1 |
Number of pages : 432 |
Technical Committee |
35.080
Software
|
| ISO/IEC/IEEE 8802-1CB:2019/Amd 2:2023 |
Information technology — Telecommunications and information exchange between systems — Local and metropolitan area networks — Specific requirements — Part 1CB: Frame replication and elimination for reliability — Amendment 2: Extend stream identification functions |
|
Published |
2023-02 |
Edition : 1 |
Number of pages : 76 |
Technical Committee |
35.110
Networking
|
| ISO/IEC 19513:2017 |
Information technology — Object Management Group Unified Profile for DoDAF and MODAF (UPDM), 2.1.1 |
This International Standard provides a specification language, UPDM, that is readily understandable not only by the community of architects of information technology systems but also by a wide range of end users including executives and enterprise management that sponsor such systems, program managers that oversee their development, developers of supporting hardware and software (design, implementation, and testing), subject matter experts, and end users. UPDM bridges the gap from setting of requirements to high level system design and to visualization for practitioners. While designed in the context of military organizations and their procurement processes, UPDM can also be applied in entirely civilian industrial and service organization contexts. UPDM 2.1.1 supports the capability to: ? model architectures for a broad range of complex systems, which may include hardware, software, data, personnel, and facility elements; ? model consistent architectures for system-of-systems down to lower levels of design and implementation; ? model service oriented architectures; ? support the analysis, specification, design, and verification of complex systems; and ? improve the ability to exchange architecture information among related tools that are UML based and tools that are based on other standards. The profile provides the modeling of operational capabilities, services, system activities, nodes, system functions, ports, protocols, interfaces, performance, and physical properties and units of measure. In addition, the profile enables the modeling of related architecture concepts such as DoD's doctrine, organization, training material, leadership & education, personnel, and facilities (DOTMLPF) and the equivalent UK Ministry of Defence Lines of Development (DLOD) elements. UPDM 2.1.1, as illustrated in Figure 1.1, addresses DoDAF and MODAF Viewpoints as well as enabling extensions to new architecture perspectives (e.g., Services views, Custom views, Logistics views cost views, etc.). MODAF terminology has been used for simplicity.
|
Published |
2017-10 |
Edition : 1 |
Number of pages : 415 |
Technical Committee |
35.080
Software
|
| ISO/IEC 19515:2019 |
Information technology — Object Management Group Automated Function Points (AFP), 1.0 |
1.1 Purpose This International Standard defines a method for automating the counting of Function Points that is generally consistent with the Function Point Counting Practices Manual, Release 4.3.1 (IFPUG CPM) produced by the International Function Point Users Group (IFPUG). Guidelines in this International Standard may differ from those in the IFPUG CPM at points where subjective judgments have to be replaced by the rules needed for automation. The IFPUG CPM was selected as the anchor for this International Standard because it is the most widely used functional measurement specification with a large supporting infrastructure maintained by a professional organization.
1.2 Applicability This International Standard is applicable to the functional sizing of transaction-oriented software applications, and in particular those with data persistency. To be consistent with the IFPUG CPM, the International Standard provides details on the support of applications using relational databases. However, the International Standard can be used and extended for any type of transactional application with data persistency.
1.3 Limitations This International Standard does not address the sizing of enhancements to an application or maintained functionality (often called Enhancement Function Points). Extensions of the automated counting methods described in this International Standard such as Automated Enhancement Function Points will be addressed in future addendums to this International Standard. This International Standard does not address sizing for the non-functional components of a software application. Non-functional components (as defined by IFPUG) include:
— Structural Quality Constraints Reliability, Security, Performance Efficiency, Maintainability, etc.
— Organizational Constraints locations for operations, target hardware, compliance to standards, etc.
— Environmental Constraints interoperability, security, privacy, safety, etc.
— Implementation Constraints development language, delivery schedule, etc.
|
Published |
2019-05 |
Edition : 1 |
Number of pages : 28 |
Technical Committee |
35.080
Software
|
| ISO/IEC 19678:2015 |
Information Technology — BIOS Protection Guidelines |
ISO 19678:2015 provides requirements and guidelines for preventing the unauthorized modification of Basic Input/Output System (BIOS) firmware on PC client systems. Unauthorized modification of BIOS firmware by malicious software constitutes a significant threat because of the BIOS's unique and privileged position within the PC architecture. A malicious BIOS modification could be part of a sophisticated, targeted attack on an organization ?either a permanent denial of service (if the BIOS is corrupted) or a persistent malware presence (if the BIOS is implanted with malware).
As used in this publication, the term BIOS refers to conventional BIOS, Extensible Firmware Interface (EFI) BIOS, and Unified Extensible Firmware Interface (UEFI) BIOS. This International Standard applies to system BIOS firmware (e.g., conventional BIOS or UEFI BIOS) stored in the system flash memory of computer systems, including portions that may be formatted as Option ROMs. However, it does not apply to Option ROMs, UEFI drivers, and firmware stored elsewhere in a computer system.
Subclause 7.2 provides platform vendors with requirements for a secure BIOS update process. Additionally, subclause 7.3 provides guidelines for managing the BIOS in an operational environment.
While this International Standard focuses on current and future x86 and x64 client platforms, the controls and procedures are independent of any particular system design.
|
Published |
2015-05 |
Edition : 1 |
Number of pages : 15 |
Technical Committee |
35.080
Software
|
| ISO/IEC TR 19759:2005 |
Software Engineering — Guide to the Software Engineering Body of Knowledge (SWEBOK) |
ISO/IEC 19759:2005, a guide to the software engineering body of knowledge (SWEBOK), identifies and describes that subset of the body of knowledge that is generally accepted, even though software engineers must be knowledgeable not only in software engineering, but also, of course, in other related disciplines. SWEBOK is an all-inclusive term that describes the sum of knowledge within the profession of software engineering.
|
Withdrawn |
2005-09 |
Edition : 1 |
Number of pages : 187 |
Technical Committee |
35.080
Software
|
| ISO/IEC TR 19759:2015 |
Software Engineering — Guide to the software engineering body of knowledge (SWEBOK) |
ISO/IEC TR 19759:2015 characterizes the boundaries of the software engineering discipline and provides topical access to the literature supporting that discipline.
|
Published |
2015-10 |
Edition : 2 |
Number of pages : 336 |
Technical Committee |
35.080
Software
|
| ISO/IEC 19770-1:2017 |
Information technology — IT asset management — Part 1: IT asset management systems — Requirements |
ISO/IEC 19770-1:2017 specifies requirements for an IT asset management system within the context of the organization.
ISO/IEC 19770-1:2017 can be applied to all types of IT assets and by all types and sizes of organizations.
NOTE 1 This document is intended to be used for managing IT assets in particular, but it can also be applied to other asset types. It can be suitable, in whole or in part, for managing embedded software and firmware, however its use for these purposes has not been determined. It is not intended for managing information assets per se, i.e. it is not intended for managing information as an asset independent of hardware and software assets. Certain types of data and information are covered, such as data and information about IT assets in scope, and depending on how the scope is defined, it can cover digital information content assets. See the Introduction for an explanation about IT assets.
NOTE 2 This document does not specify financial, accounting, or technical requirements for managing specific IT asset types.
NOTE 3 For the purposes of this document, the term "IT asset management system" is used to refer to a management system for IT asset management.
ISO/IEC 19770-1:2017 is a discipline-specific extension of ISO 55001:2014, with changes, and is not a sector-specific application of that International Standard. ISO 55001:2014 is intended to be used for managing physical assets in particular, but it can also be applied to other asset types. This document specifies requirements for the management of IT assets which are additional to those specified in ISO 55001:2014. Conformance to this document does not imply conformance to ISO 55001:2014.
ISO/IEC 19770-1:2017 can be used by internal and external parties to assess the organization's ability to meet the organization's own IT asset management requirements.
|
Published |
2017-12 |
Edition : 3 |
Number of pages : 37 |
Technical Committee |
35.080
Software
|
| ISO/IEC TR 19760:2003 |
Systems engineering — A guide for the application of ISO/IEC 15288 (System life cycle processes) |
ISO/IEC TR 19760:2003 is a Technical Report that provides guidance for application of the International Standard ISO/IEC 15288 Systems Engineering - System life cycle processes in regard to systems and projects irrespective of size and type. ISO/IEC TR 19760:2003 can be used as a companion document to the International Standard by those who:
apply the International Standard within their organization;use the International Standard in regard to a specific system;prepare organizational and domain specific standards based on the International Standard.
ISO/IEC TR 19760:2003 elaborates on factors that should be considered when applying the International Standard. It does this in the context of the various ways in which ISO/IEC 15288 may be applied. ISO/IEC TR 19760:2003 provides example application concerns lists for user consideration. However, ISO/IEC TR 19760:2003 is not intended to provide how-to guidance for each application area of the International Standard.
Guidance is provided for appropriate tailoring of the International Standard for application to specific systems or projects.
ISO/IEC TR 19760:2003 also provides appropriate links to other ISO documents for supporting application of the International Standard and to aid in assessing the effectiveness of the application of the International Standard.
|
Withdrawn |
2003-11 |
Edition : 1 |
Number of pages : 75 |
Technical Committee |
35.080
Software
|
| ISO/IEC 19761:2003 |
Software engineering — COSMIC-FFP — A functional size measurement method |
ISO/IEC 19761:2003 specifies the set of definitions, conventions and activities of the COSMIC-FFP Functional Size Measurement Method. It is applicable to software from the following functional domains:
application software which is needed to support business administration;real-time software, the task of which is to keep up with or control events happening in the real world;hybrids of the above.
ISO/IEC 19761:2003 has not been designed for measuring the functional size of a piece of software, or its parts, which:
are characterized by complex mathematical algorithms or other specialized and complex rules, such as may be found in expert systems, simulation software, self-learning software and weather forecasting systems, orprocess continuous variables such as audio sounds or video images, such as may be found, for instance, in computer game software, musical instruments and the like.
However, within the local environment of an organisation using the COSMIC-FFP Functional Size Measurement Method, it may be possible to measure these FUR in a way which is meaningful as a local standard. ISO/IEC 19761:2003 contains provision for the local customisation of the method for this purpose.
|
Withdrawn |
2003-02 |
Edition : 1 |
Number of pages : 17 |
Technical Committee |
35.080
Software
|
| ISO/IEC 19761:2011 |
Software engineering — COSMIC: a functional size measurement method |
ISO/IEC 19761:2011 specifies the set of definitions, conventions and activities of the COSMIC Functional Size Measurement Method. It is applicable to software from the following functional domains:
application software;
real-time software;
hybrids of the above.
ISO/IEC 19761:2011 has not been designed for measuring the functional size of a piece of software, or its parts, which
is characterized by complex mathematical algorithms or other specialized and complex rules, such as can be found in expert systems, simulation software, self-learning software and weather forecasting systems, or
processes continuous variables such as audio sounds or video images, such as can be found in computer game software, musical instruments and the like.
|
Published |
2011-03 |
Edition : 2 |
Number of pages : 14 |
Technical Committee |
35.080
Software
|
| ISO/IEC 19770-1:2006 |
Information technology — Software asset management — Part 1: Processes |
ISO/IEC 19770-1:2006 has been developed to enable an organization to prove that it is performing software asset management (SAM) to a standard sufficient to satisfy corporate governance requirements and ensure effective support for IT service management overall. ISO/IEC 19770-1:2006 is intended to align closely to, and to support, ISO/IEC 20000. Good practice in SAM should result in several benefits, and certifiable good practice should allow management and other organizations to place reliance on the adequacy of these processes. The expected benefits should be achieved with a high degree of confidence:
SAM should facilitate the management of business risks, cost control and give competitive advantages.
|
Withdrawn |
2006-05 |
Edition : 1 |
Number of pages : 25 |
Technical Committee |
35.080
Software
|
| ISO/IEC 19770-1:2012 |
Information technology — Software asset management — Part 1: Processes and tiered assessment of conformance |
ISO/IEC 19770-1:2012 establishes a baseline for an integrated set of processes for Software Asset Management (SAM), divided into tiers to allow for incremental implementation, assessment and recognition.
ISO/IEC 19770-1:2012 applies to SAM processes and can be implemented by organizations to achieve immediate benefits. It can be applied to all software and related assets, regardless of the nature of the software, where related assets are all other assets with characteristics which are necessary to use or manage software. For example, it can be applied to executable software (such as application programs, operating systems and utility programs) and to non-executable software (such as fonts, graphics, audio and video recordings, templates, dictionaries, documents and data). It can be applied to all technological environments and computing platforms (e.g. virtualized software applications, on-premises or software-as-a-service; it is equally relevant in cloud computing as it is in older computing environments).
|
Withdrawn |
2012-06 |
Edition : 2 |
Number of pages : 80 |
Technical Committee |
35.080
Software
|
| ISO/IEC DIS 19770-6 |
Information technology — IT asset management — Part 6: Hardware identification tag |
|
Under development |
|
Edition : 1 |
Number of pages : 51 |
Technical Committee |
35.080
Software
;
03.120.20
Product and company certification. Conformity assessment
|
| ISO 14217:1998 |
Aerospace — Airframe ball bearings, double-row, self-aligning, precision, sealed, heavy duty — Inch series |
|
Withdrawn |
1998-05 |
Edition : 1 |
Number of pages : 6 |
Technical Committee |
49.035
Components for aerospace construction
|
| ISO/IEC 19770-2:2009 |
Information technology — Software asset management — Part 2: Software identification tag |
ISO/IEC 19770-2:2009 establishes specifications for tagging software to optimize its identification and management.
It applies to:
Platform providers: These are the entities which are responsible for the computer or hardware device and/or associated operating system, or virtual environment, on which software can be installed or run. Platform providers which support ISO/IEC 19770-2:2009 additionally provide tag management capabilities at the level of the platform or operating system.
Software providers: These are the entities that create (“software creators”), package (“software packagers”) or license (“software licensors”) software for distribution or installation. These include software manufacturers, independent software developers, consultants, and repackagers of previously manufactured software. They may also be in-house software developers.
Tag providers: These are the entities that create (“tag creators”) or modify (“tag modifiers”) software identification tags. A tag provider may be part of the software provider organization, or may be a 3rd party organization or the software consumer.
Tag tool providers: These are the entities that may provide any number of tools that create, modify or use software identification tags. These tools include development environments that provide automatically generated software identification tags, installation tools that may create and/or modify tags on behalf of the installation process as well as desktop management tools that may create tags for software that does not have a tag and/or modify tags with release details throughout the software lifecycle.
Software consumers: These are the entities that purchase, install and/or otherwise consume software, and who are intended as the one of the major beneficiaries of the improved information provided by the software identification tag as specified in ISO/IEC 19770-2:2009.
ISO/IEC 19770-2:2009 does not detail SAM processes required for reconciliation of software entitlements with software identification tags.
It does not specify product activation or launch controls.
It is not intended to conflict either with any organization's policies, procedures and standards or with any national laws and regulations. Any such conflict should be resolved before using ISO/IEC 19770-2:2009.
|
Withdrawn |
2009-11 |
Edition : 1 |
Number of pages : 99 |
Technical Committee |
35.080
Software
|
| ISO/IEC 19770-2:2015 |
Information technology — IT asset management — Part 2: Software identification tag |
ISO/IEC 19770-2:2015 establishes specifications for tagging software to optimize its identification and management.
This part of ISO/IEC 19770 applies to the following.
a) Tag producers: these organizations and/or tools create software identification (SWID) tags for use by others in the market. A tag producer may be part of the software creator organization, the software licensor organization, or be a third-party organization. These organizations and/or tools can broadly be broken down into the following categories.
Platform providers: entities responsible for the computer or hardware device and/or associated operating system, virtual environment, or application platform, on which software may be installed or run. Platform providers which support this part of ISO/IEC 19770 may additionally provide tag management capabilities at the level of the platform or operating system.
Software providers: entities that create, license, or distribute software. For example, software creators, independent software developers, consultants, and repackagers of previously manufactured software. Software creators may also be in-house software developers.
Tag tool providers: entities that provide tools to create software identification tags. For example, tools within development environments that generate software identification tags, or installation tools that may create tags on behalf of the installation process, and/or desktop management tools that may create tags for installed software that did not originally have a software identification tag.
b) Tag consumers: these tools and/or organizations utilize information from SWID tags and are typically broken down into the following two major categories:
software consumers: entities that purchase, install, and/or otherwise consume software;
IT discovery and processing tool providers: entities that provide tools to collect, store, and process software identification tags. These tools may be targeted at a variety of different market segments, including software security, compliance, and logistics.
ISO/IEC 19770-2:2015 does not prescribe Information Technology Asset Management (ITAM) or other IT-related processes required for reconciliation of software entitlements with software identification tags or other IT requirements.
ISO/IEC 19770-2:2015 is not intended to conflict either with any organization's policies, procedures or standards or with any national or international laws and regulations.
|
Published |
2015-10 |
Edition : 2 |
Number of pages : 73 |
Technical Committee |
35.080
Software
|
| ISO/IEC 19770-3:2016 |
Information technology — IT asset management — Part 3: Entitlement schema |
ISO/IEC 19770-3:2016 establishes a set of terms and definitions which may be used when discussing software entitlements (an important part of software licenses). It also provides specifications for a transport format which enables the digital encapsulation of software entitlements, including associated metrics and their management.
This common set of terms and associated transport format is intended to facilitate the management of software entitlements. The intended benefits of the better management of entitlements include easier demonstration of proof of ownership, cost optimization of the use of entitlements and easier license compliance management.
Furthermore, one of the benefits of having a standard for entitlement structure is that it may encourage the normalization by industry of names for and the details of, different types of entitlements. A common lexicon is critical to standardization and shared understanding. The terms in this part of ISO/IEC 19770 should form a part of that lexicon over time.
It should be noted that within this text, attributes of an XML entity will be denoted with angle brackets, <attribute>. XML elements are noted with quotes, "Element".
ISO/IEC 19770-3:2016 deals only with software entitlements, which are defined as the subset of software licenses that are concerned with usage rights. It is expected that the original documentation of licensing terms and conditions will be definitive for legal purposes, and will always take precedence over the Ent encapsulation.
ISO/IEC 19770-3:2016 does not detail ITAM processes required for discovery and management of software (which is provided for in ISO/IEC 19770‑1) or software identification tags (as defined by ISO/IEC 19770‑2).
ISO/IEC 19770-3:2016 does not consider identifying mechanisms for product activation.
ISO/IEC 19770-3:2016 is not intended to conflict with any organization's policies, procedures and standards, or with any national laws and regulations. Any such conflict should be resolved before using this part of ISO/IEC 19770. In case the conflict cannot be resolved, the specification shall not be implemented.
|
Published |
2016-04 |
Edition : 1 |
Number of pages : 62 |
Technical Committee |
35.080
Software
|
| ISO/IEC 19770-4:2017 |
Information technology — IT asset management — Part 4: Resource utilization measurement |
ISO/IEC 19770-4:2017 establishes specifications for an information structure to contain Resource Utilization Measurement information to facilitate IT asset management (ITAM).
This document is applicable to all types of organization (for example, commercial enterprises, government agencies, and non-profit organizations).
|
Published |
2017-09 |
Edition : 1 |
Number of pages : 38 |
Technical Committee |
35.080
Software
|
| ISO/IEC 19770-5:2013 |
Information technology — Software asset management — Part 5: Overview and vocabulary |
ISO/IEC 19770-5:2013 provides an overview of Software Asset Management (SAM), which is the subject of the ISO/IEC 19770 family of standards, and defines related terms.
ISO/IEC 19770-5:2013 contains:
an overview of the ISO/IEC 19770 family of standards;
an introduction to SAM;
a brief description of the foundation principles and approaches on which SAM is based; and
consistent terms and definitions for use throughout the ISO/IEC 19770 family of standards.
ISO/IEC 19770-5:2013 is applicable to all types of organization (e.g. commercial enterprises, government agencies, non-profit organizations).
|
Withdrawn |
2013-11 |
Edition : 1 |
Number of pages : 17 |
Technical Committee |
35.080
Software
|
| ISO/IEC 19770-5:2015 |
Information technology — IT asset management — Part 5: Overview and vocabulary |
ISO/IEC 19770-5:2015 provides
a) an overview of the ISO/IEC 19770 family of standards,
b) an introduction to IT asset management (ITAM) and software asset management (SAM),
c) a brief description of the foundation principles and approaches on which SAM is based, and
d) consistent terms and definitions for use throughout the ISO/IEC 19770 family of standards.
ISO/IEC 19770-5:2015 is applicable to all types of organization (e.g. commercial enterprises, government agencies, and non-profit organizations).
|
Published |
2015-08 |
Edition : 2 |
Number of pages : 19 |
Technical Committee |
35.080
Software
|
| ISO/IEC 19770-8:2020 |
Information technology — IT asset management — Part 8: Guidelines for mapping of industry practices to/from the ISO/IEC 19770 family of standards |
This document defines requirements, guidelines, formats and approaches for use when producing a mapping document that defines how industry practices map to/from the ISO/IEC 19770 series.
This edition is focused solely on mappings to/from both the second edition of ISO/IEC 19770-1 that was published in 2012, or the third edition of ISO/IEC 19770-1 that was published in 2017. However, the title of this document is deliberately more general as it is expected that future editions of this document also include mapping frameworks related to other parts of the ISO/IEC 19770 series.
In this document where reference is made to ISO/IEC 19770-1 without the specification of an edition number or a publication year, then the text applies to all editions of ISO/IEC 19770-1.
|
Published |
2020-01 |
Edition : 1 |
Number of pages : 17 |
Technical Committee |
35.080
Software
|
| ISO/IEC 19770-11:2021 |
Information technology — IT asset management — Part 11: Requirements for bodies providing audit and certification of IT asset management systems |
This document specifies requirements and provides guidance for certification bodies providing audit and certification of an ITAMS in accordance with ISO/IEC 19770-1. It does not change the requirements specified in ISO/IEC 19770-1.
This document can also be used by accreditation bodies for the accreditation of certification bodies. However, this document does not specify requirements or provides guidance for accreditation bodies to audit certification bodies.
A certification body providing ITAMS certification is expected to be able to demonstrate fulfilment of the requirements specified in this document, in addition to the requirements in ISO/IEC 17021-1.
|
Published |
2021-06 |
Edition : 1 |
Number of pages : 16 |
Technical Committee |
35.080
Software
;
03.120.20
Product and company certification. Conformity assessment
|
| ISO/IEC 19793:2008 |
Information technology — Open Distributed Processing — Use of UML for ODP system specifications |
ISO/IEC 19793:2008 defines use of the Unified Modeling Language (UML 2.1.1 Superstructure Specification, OMG document formal/07-02-05) for expressing system specifications in terms of the viewpoint specifications defined by the Reference Model of Open Distributed Processing (ISO/IEC 10746, Parts 1 to 4) and the Enterprise Language (ISO/IEC 15414).
It covers the expression of a system specification in terms of RM-ODP viewpoint specifications using defined UML concepts and extensions (e.g. structuring rules, technology mappings, etc.) and relationships between the resultant RM-ODP viewpoint specifications.
ISO/IEC 19793:2008 is intended to be used by
ODP modellers who want to use the UML notation for expressing their ODP specifications in a graphical and standard way,
UML modellers who want to use the RM-ODP concepts and mechanisms to structure their UML system specifications, and
modelling tool suppliers, who wish to develop UML-based tools that are capable of expressing RM-ODP viewpoint specifications.
|
Withdrawn |
2008-12 |
Edition : 1 |
Number of pages : 105 |
Technical Committee |
35.080
Software
|
| ISO/IEC 19793:2008/Cor 1:2010 |
Information technology — Open Distributed Processing — Use of UML for ODP system specifications — Technical Corrigendum 1 |
|
Withdrawn |
2010-09 |
Edition : 1 |
Number of pages : 3 |
Technical Committee |
35.080
Software
|
| ISO/IEC 19793:2015 |
Information technology — Open Distributed Processing — Use of UML for ODP system specifications |
ISO/IEC 19793:2015 defines use of the unified modelling language (UML 2.4.1 superstructure specification, ISO/IEC 19505-2, for expressing system specifications in terms of the viewpoint specifications defined by the reference model of open distributed processing (RM-ODP, Rec. ITU-T X.901 to X.904 | ISO/IEC 10746 Parts 1 to 4) and the Enterprise Language (Rec. ITU-T X.911 | ISO/IEC 15414). It covers:
a) the expression of a system specification in terms of RM-ODP viewpoint specifications using defined UML concepts and extensions (e.g., structuring rules, technology mappings, etc.);
b) relationships between the resultant RM-ODP viewpoint specifications.
ISO/IEC 19793:2015 is intended for the following audiences:
? ODP modellers who want to use the UML notation for expressing their ODP specifications in a graphical and standard way;
? UML modellers who want to use the RM-ODP concepts and mechanisms to structure their UML system specifications;
? modelling tool suppliers, who wish to develop UML-based tools that are capable of expressing RM‑ODP viewpoint specifications.
|
Published |
2015-04 |
Edition : 2 |
Number of pages : 118 |
Technical Committee |
35.080
Software
|
| ISO/IEC 20246:2017 |
Software and systems engineering — Work product reviews |
ISO/IEC 20246:2017 establishes a generic framework for work product reviews that can be referenced and used by all organizations involved in the management, development, test and maintenance of systems and software. It contains a generic process, activities, tasks, review techniques and documentation templates that are applied during the review of a work product. A work product is any artefact produced by a process. This document defines work product reviews that can be used during any phase of the life cycle of any work product. This document is intended for, but not limited to, project managers, development managers, quality managers, test managers, business analysts, developers, testers, customers and all those involved in the development, testing and maintenance of systems and software.
|
Published |
2017-02 |
Edition : 1 |
Number of pages : 42 |
Technical Committee |
35.080
Software
|
| ISO/IEC 23360-2:2006 |
Linux Standard Base (LSB) core specification 3.1 — Part 2: Specification for IA32 architecture |
ISO/IEC 23360-2:2006 is the IA32 architecture-specific Core part of the Linux Standard Base (LSB). It supplements the generic LSB Core module with those interfaces that differ between architectures.
Interfaces described in ISO/IEC 23360-2:2006 are mandatory except where explicitly listed otherwise. Core interfaces may be supplemented by other modules; all modules are built upon the core, ISO/IEC 23360-1:2006.
|
Withdrawn |
2006-12 |
Edition : 1 |
Number of pages : 78 |
Technical Committee |
35.080
Software
|
| ISO/IEC 20741:2017 |
Systems and software engineering — Guideline for the evaluation and selection of software engineering tools |
ISO/IEC 20741:2017 gives guidelines for the evaluation and selection of software engineering tools, covering a partial or full portion of the software engineering life cycle.
It establishes processes and activities to be applied for the evaluation of software engineering tools and selecting the most appropriate software engineering tools from several candidates.
It establishes, for selected processes, the tasks and activities that can be applied for the evaluation of software engineering tools and selecting the most appropriate software engineering tools from several candidates.
It establishes processes that can be applied for the evaluation of software engineering tools and selecting the most appropriate software engineering tools from several candidates.
As these processes are generic, organizations can adapt these generic processes to meet organizational needs. The software engineering tool evaluation and selection processes can be viewed in the larger context of the organization's technology adoption process.
ISO/IEC 20741:2017 provides the following:
a) guidance on identifying organizational requirements for software engineering tools;
b) guidance on mapping those requirements to software engineering tool characteristics to be evaluated;
c) a process for selecting the most appropriate software engineering tool from several tools, based on measurements of the defined characteristics.
NOTE 1 Guidance on mapping those requirements to software engineering tool capabilities to be evaluated is not covered by this document, but is covered by a series of standards for each tool area.
Primary users of this document are organizations that intend to adopt software engineering tools to support their software life cycle processes. Software tool suppliers can also use this document to describe characteristics of their software engineering tools.
ISO/IEC 20741:2017 is not intended to apply to:
a) software engineering frameworks whose purpose is to provide mechanisms for data, control and presentation integration;
b) general purpose tools (e.g. word processors, spreadsheets) which can be used in software engineering activities, nor software engineering tools of very narrow scope or specific purpose (e.g. a compiler);
c) planning for the implementation of software engineering tools within an organization.
NOTE 2 A user of this document can make the best possible selection of a software engineering tool and yet have no guarantee of a successful implementation.
The methods described in this document are useful not only for the selection of software engineering tools, but for any project where COTS/FOSS software can be selected instead of engaging in new software development.
To follow the guidance provided in this document consists in applying the activities and tasks that are attached to the defined processes to evaluate and select software. Organizations using this document for trade purposes can specify the minimum set of processes and their related activities and tasks, suitable to their given application.
|
Published |
2017-05 |
Edition : 1 |
Number of pages : 34 |
Technical Committee |
35.080
Software
|
| ISO/IEC 20926:2003 |
Software engineering — IFPUG 4.1 Unadjusted functional size measurement method — Counting practices manual |
ISO/IEC 20926:2003 specifies the International Function Point Users Group (IFPUG) Release 4.1 unadjusted Functional Size Measurement Method.
It provides:a clear and detailed description of function point counting;
a foundation to ensure that counts are consistent;guidance to allow function point counting of Functional User Requirements from the deliverables of popular software development methodologies and techniques;a framework to enable automated support for function point counting.
The provisions of ISO/IEC 20926:2003 can be applied by anyone using function point analysis for software measurement. ISO/IEC 20926:2003 was designed for use by persons new to function point counting as well as those with intermediate and advanced experience.
|
Withdrawn |
2003-10 |
Edition : 1 |
Number of pages : 342 |
Technical Committee |
35.080
Software
|
| ISO/IEC 20926:2009 |
Software and systems engineering — Software measurement — IFPUG functional size measurement method 2009 |
ISO/IEC 20926:2009 specifies the set of definitions, rules and steps for applying the IFPUG (International Function Point Users Group) functional size measurement (FSM) method.
ISO/IEC 20926:2009 is conformant with all mandatory provisions of ISO/IEC 14143-1:2007. It can be applied to all functional domains and is fully convertible to prior editions of IFPUG sizing methods.
IFPUG function point analysts have identified different delivery rates (hours to deliver a function point) related to building applications in different functional domains calibrated for varying project sizes and software complexities.
ISO/IEC 20926:2009 can be applied by anyone requiring a measurement of functional size. Persons experienced with the method will find ISO/IEC 20926:2009 to be a useful reference.
|
Published |
2009-12 |
Edition : 2 |
Number of pages : 24 |
Technical Committee |
35.080
Software
|
| ISO/IEC 20968:2002 |
Software engineering — Mk II Function Point Analysis — Counting Practices Manual |
ISO/IEC 20968:2002 specifies the set of definitions, conventions and activities of the MkII FPA Functional Size Measurement Method.
The method can be used to measure the functional size of any software application that can be described in terms of logical transactions, each comprising an input, process and output component. The sizing rules were designed to apply to application software from the domain of business information systems, where the processing component of each transaction tends to be dominated by considerations of the storage or retrieval of data.
The method may be applicable to software from other domains, but the user should note that the sizing rules do not take into account contributions to size such as from complex algorithms as typically found in scientific and engineering software, nor do the rules specifically take into account real-time requirements
MK II FPA is independent of the project management method to be used and of the development method employed. It is a measure of the logical, business requirements, independent of how they are implemented.
|
Published |
2002-12 |
Edition : 1 |
Number of pages : 93 |
Technical Committee |
35.080
Software
|
| ISO/IEC DIS 21031 |
Information technology — Software Carbon Intensity (SCI) specification |
|
Under development |
|
Edition : 1 |
Number of pages : 8 |
Technical Committee |
35.080
Software
;
13.020.40
Pollution, pollution control and conservation
|
| ISO/IEC/IEEE 21839:2019 |
Systems and software engineering — System of systems (SoS) considerations in life cycle stages of a system |
1.1 Purpose This document provides a set of critical system of systems (SoS) considerations to be addressed at key points in the life cycle of the system of interest (SoI). This document refers to considerations that apply to an SoI that is a constituent system that interacts in an SoS. The considerations and life cycle model align with those which are already defined in ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 24748-1. Selected subsets of these considerations can be applied throughout the life of systems through the involvement of stakeholders. The ultimate goal is to achieve customer satisfaction, so that when delivered, the SoI will operate effectively in the operational or business environment which is typically characterized as one or more systems of systems.
This document concerns those systems that are man-made and are configured with one or more of the following: hardware, software, humans, procedures and facilities.
1.2 Field of application This document addresses SoS considerations that apply to systems at each stage of their respective life cycles.
There is a wide variety of systems in terms of their purpose, domain of application, complexity, size, novelty, adaptability, quantities, locations, life spans and evolution. This document is concerned with describing the system of systems considerations that apply to a system that is the SoI; that is a constituent system within a system of systems. It applies to one-of-a-kind systems, mass produced systems or customized, adaptable systems.
1.3 Limitations This document does not detail the approach to addressing system of systems considerations in terms of methods or procedures.
This document does not detail the described documentation in terms of name, format, explicit content and recording media of documentation.
|
Published |
2019-07 |
Edition : 1 |
Number of pages : 31 |
Technical Committee |
35.080
Software
|
| ISO/IEC/IEEE 21840:2019 |
Systems and software engineering — Guidelines for the utilization of ISO/IEC/IEEE 15288 in the context of system of systems (SoS) |
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.
NOTE 1 Throughout the document, there is mixed use of "system of systems" and "systems of systems". "SoS" could refer to a system of systems or systems of systems. Similarly, "CS" could refer to a constituent system or constituent systems.
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 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.
NOTE 2 In many cases, this document notes that ISO/IEC/IEEE 15288 processes or process outcomes "? applies as stated to SoS." Some interpretation within the context of SoS can still be needed.
|
Published |
2019-12 |
Edition : 1 |
Number of pages : 58 |
Technical Committee |
35.080
Software
|
| ISO/IEC/IEEE 21841:2019 |
Systems and software engineering — Taxonomy of systems of systems |
This document defines a normalized taxonomy for systems of systems (SoS) to facilitate communications among stakeholders. It also briefly explains what a taxonomy is and how it applies to the SoS to aid in understanding and communication.
|
Published |
2019-07 |
Edition : 1 |
Number of pages : 8 |
Technical Committee |
35.080
Software
|
| ISO/IEC/IEEE FDIS 23026 |
Systems and software engineering — Engineering and management of websites for systems, software and services information |
This document defines system engineering and management requirements for the life cycle of websites including strategy, design, engineering, testing and validation, and management and sustainment for Intranet and Extranet environments. This document applies to those using web technology to present information and communications technology (ICT) information, such as information for users of systems and services, plans and reports for systems and software engineering projects, and documentation of policies, plans, and procedures for IT service management. This document provides requirements for website owners and website providers, managers responsible for establishing guidelines for website development and operations, for software developers and operations and maintenance staff who may be external or internal to the website owner's organization. It applies to websites for public access and for limited access, such as for users, customers, and subscribers seeking information on IT products and services.
The goal of this document is to improve the usability of informational websites and ease of maintenance of managed Web operations in terms of:
a) locating relevant and timely information,
b) applying information security management,
c) facilitating ease of use,
d) providing for consistent and efficient development and maintenance practices.
This document is not primarily for websites used primarily for marketing or sales, or to deliver instructional material, or to provide Graphical User Interfaces (GUI) for business or consumer transactional application processing. However, this document may provide useful insights for managing such sites.
This document focuses on vendor- and product-independent considerations. It does not include specifications for application development tools, programming languages used for archiving site content or for presentation of content on the web, metadata tags, or protocols for web page design based on World Wide Web Consortium (W3C®) and related industry guidelines. It does not address tools or systems used for management or storage of information content (data, documents) that may be presented on websites.
This document does not address the design and architecture of software supporting the Internet.
|
Under development |
|
Edition : 1 |
Number of pages : 70 |
Technical Committee |
35.080
Software
|
| ISO/IEC 23026:2006 |
Software Engineering — Recommended Practice for the Internet — Web Site Engineering, Web Site Management, and Web Site Life Cycle |
ISO/IEC 23026:2006 defines recommended practices for World Wide Web page engineering for Intranet and Extranet environments, based on World Wide Web Consortium (W3C®) and related industry guidelines.
|
Withdrawn |
2006-06 |
Edition : 1 |
Number of pages : 72 |
Technical Committee |
35.080
Software
|
| ISO/IEC/IEEE 23026:2015 |
Systems and software engineering — Engineering and management of websites for systems, software, and services information |
ISO/IEC/IEEE 23026:2015 defines system engineering and management requirements for the life cycle of websites, including strategy, design, engineering, testing and validation, and management and sustainment for Intranet and Extranet environments. The goal of ISO/IEC/IEEE 23026:2015 is to improve the usability of informational websites and ease of maintenance of managed Web operations in terms of locating relevant and timely information, applying information security management, facilitating ease of use, and providing for consistent and efficient development and maintenance practices. It applies to those using web technology to present information and communications technology (ICT) information, such as user documentation for systems and software, life-cycle documentation for systems and software engineering projects, and documentation of policies, plans, and procedures for IT service management. ISO/IEC/IEEE 23026:2015 provides requirements for website owners and website providers, managers responsible for establishing guidelines for website development and operations, for software developers and operations and maintenance staff who may be external or internal to the website owner's organization. It applies to websites for public access and for limited access, such as for users, customers, and subscribers seeking information on IT products and services. It includes increased emphasis on the human factors concerns for making information easily retrievable and usable for the intended audience. It focuses on vendor- and product-independent considerations.
|
Published |
2015-05 |
Edition : 1 |
Number of pages : 46 |
Technical Committee |
35.080
Software
|
| ISO/IEC 23360-1:2006 |
Linux Standard Base (LSB) core specification 3.1 — Part 1: Generic specification |
The Linux Standard Base (LSB) defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB.
These specifications are composed of two basic parts: A common specification ("LSB-generic" or "generic LSB"), ISO/IEC 23360-1:2006, describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part ("LSB-arch" or "archLSB") describing the parts of the interface that vary by processor architecture. Together, the LSB-generic and the relevant architecture-specific parts of ISO/IEC 23360 for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture.
ISO/IEC 23360-1:2006, the LSB-generic document, is used in conjunction with an architecture-specific part. Whenever a section of the LSB-generic specification is supplemented by architecture-specific information, the LSB-generic document includes a reference to the architecture part.
|
Withdrawn |
2006-12 |
Edition : 1 |
Number of pages : 458 |
Technical Committee |
35.080
Software
|
| ISO/IEC 23360-5:2006 |
Linux Standard Base (LSB) core specification 3.1 — Part 5: Specification for PPC32 architecture |
ISO/IEC 23360-5:2006 is the PPC32 architecture-specific Core part of the Linux Standard Base (LSB). It supplements the generic LSB Core module with those interfaces that differ between architectures.
Interfaces described in ISO/IEC 23360-5:2006 are mandatory except where explicitly listed otherwise. Core interfaces may be supplemented by other modules; all modules are built upon the core.
|
Withdrawn |
2006-12 |
Edition : 1 |
Number of pages : 77 |
Technical Committee |
35.080
Software
|
| ISO/IEC 23360-6:2006 |
Linux Standard Base (LSB) core specification 3.1 — Part 6: Specification for PPC64 architecture |
ISO/IEC 23360-6:2006 is the PPC64 architecture-specific Core part of the Linux Standard Base (LSB). It supplements the generic LSB Core module with those interfaces that differ between architectures.
Interfaces described in ISO/IEC 23360-6:2006 are mandatory except where explicitly listed otherwise. Core interfaces may be supplemented by other modules; all modules are built upon the core.
|
Withdrawn |
2006-12 |
Edition : 1 |
Number of pages : 73 |
Technical Committee |
35.080
Software
|
| ISO/IEC 23360-7:2006 |
Linux Standard Base (LSB) core specification 3.1 — Part 7: Specification for S390 architecture |
ISO/IEC 23360-7:2006 is the S390 architecture-specific Core part of the Linux Standard Base (LSB). It supplements the generic LSB Core module with those interfaces that differ between architectures.
Interfaces described in ISO/IEC 23360-7:2006 are mandatory except where explicitly listed otherwise. Core interfaces may be supplemented by other modules; all modules are built upon the core.
|
Withdrawn |
2006-12 |
Edition : 1 |
Number of pages : 73 |
Technical Committee |
35.080
Software
|
| ISO/IEC 23360-8:2006 |
Linux Standard Base (LSB) core specification 3.1 — Part 8: Specification for S390X architecture |
ISO/IEC 23360-8:2006 is the S390X architecture-specific Core part of the Linux Standard Base (LSB). It supplements the generic LSB Core module with those interfaces that differ between architectures.
Interfaces described in ISO/IEC 23360-8:2006 are mandatory except where explicitly listed otherwise. Core interfaces may be supplemented by other modules; all modules are built upon the core.
|
Withdrawn |
2006-12 |
Edition : 1 |
Number of pages : 72 |
Technical Committee |
35.080
Software
|
| ISO/IEC 23360-1-1:2021 |
Linux Standard Base (LSB) — Part 1-1: Common definitions |
This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB.
The LSB specification set is divided into modules, each of which provides fundamental system interfaces, libraries, and runtime environment upon which all conforming applications and libraries using that module depend.
The modules of the Linux Standard Base are:
LSB Core - core components
LSB Desktop - desktop related components
LSB Languages - runtime languages
LSB Imaging - printing and scanning
LSB Trial Use - components that are not yet mandatory
Interfaces described in the LSB Core module specification are supplemented by other LSB module specifications. All other modules depend on the presence of LSB Core.
These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. Architecture-specific parts of of an LSB module specification may also contain additional information that is not referenced in the common part.
The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed.
The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification.
|
Published |
2021-10 |
Edition : 1 |
Number of pages : 12 |
Technical Committee |
35.080
Software
|
| ISO/IEC 23360-1-2:2021 |
Linux Standard Base (LSB) — Part 1-2: Core specification generic part |
This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB. These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture. The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed. The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification. This is the common part of the Core module of the Linux Standard Base (LSB), LSB Core - Generic. This module provides the fundamental system interfaces, libraries, and runtime environment upon which all conforming applications and libraries depend. LSB Core - Generic, the common part, should be used in conjunction with an architecture-specific part. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. Architecture-specific parts of the LSB Core Specification may also contain additional information that is not referenced in the common part. Interfaces described in this part of the LSB Core Specification are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Core module are supplemented by other LSB modules. All other modules depend on the presence of LSB Core.
|
Published |
2021-10 |
Edition : 1 |
Number of pages : 1052 |
Technical Committee |
35.080
Software
|
| ISO/IEC 24570:2005 |
Software engineering — NESMA functional size measurement method version 2.1 — Definitions and counting guidelines for the application of Function Point Analysis |
ISO/IEC 24570:2004:
specifies a method to measure functional size of software,gives guidelines how to determine the components of functional size of software,specifies how to calculate the functional size as aresult of the method, andgives guidelines for the application of the method.
|
Withdrawn |
2005-02 |
Edition : 1 |
Number of pages : 124 |
Technical Committee |
35.080
Software
|
| ISO/IEC 24570:2018 |
Software engineering — NESMA functional size measurement method — Definitions and counting guidelines for the application of function point analysis |
ISO/IEC 24570:2018 specifies the set of definitions, rules and guidelines for applying the Nesma Function Point Analysis (FPA) method.
|
Published |
2018-02 |
Edition : 2 |
Number of pages : 70 |
Technical Committee |
35.080
Software
|
| ISO/IEC 23360-1-3:2021 |
Linux Standard Base (LSB) — Part 1-3: Desktop specification generic part |
This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB.
These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture.
The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed.
The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification.
This is the common part of the Desktop module of the Linux Standard Base (LSB). This module provides the fundamental system interfaces, libraries, and runtime environment upon which all conforming applications and libraries depend requiring the LSB Desktop module depend.
The common part of LSB Desktop should be used in conjunction with an architecture-specific part. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. Architecture-specific parts of LSB Desktop may also contain additional information that is not referenced in the common part.
Interfaces described in this part of LSB Desktop are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Desktop module supplement those described in the LSB Core module. They do not depend on other LSB modules.
|
Published |
2021-10 |
Edition : 1 |
Number of pages : 2940 |
Technical Committee |
35.080
Software
|
| ISO/IEC 23360-1-4:2021 |
Linux Standard Base (LSB) — Part 1-4: Languages specification |
The LSB Languages specification defines components for runtime languages which are found on an LSB conforming system.
|
Published |
2021-10 |
Edition : 1 |
Number of pages : 186 |
Technical Committee |
35.080
Software
|
| ISO/IEC 23360-1-5:2021 |
Linux Standard Base (LSB) — Part 1-5: Imaging specification |
This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB. These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture. The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed. The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification. This is the Imaging module of the Linux Standard Base (LSB). This module provides the fundamental system interfaces, libraries, and runtime environment upon which conforming applications and libraries requiring the LSB Imaging module depend. Interfaces described in LSB Imaging are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Imaging module supplement those described in the LSB Core module. They do not depend on other LSB modules.
|
Published |
2021-10 |
Edition : 1 |
Number of pages : 79 |
Technical Committee |
35.080
Software
|
| ISO/IEC 23360-2-2:2021 |
Linux Standard Base (LSB) — Part 2-2: Core specification for X86-32 architecture |
This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB. These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture. The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed. The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification. This is the X86 architecture specific part of the Core module of the Linux Standard Base (LSB). This part supplements the common part of the LSB Core module with those interfaces that differ between architectures. This part should be used in conjunction with LSB Core - Generic, the common part. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. This part may also contain additional information that is not referenced in the common part. Interfaces described in this part of the LSB Core Specification are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Core module are supplemented by other LSB modules. All other modules depend on the presence of LSB Core.
|
Published |
2021-10 |
Edition : 1 |
Number of pages : 231 |
Technical Committee |
35.080
Software
|
| ISO/IEC 23360-2-3:2021 |
Linux Standard Base (LSB) — Part 2-3: Desktop specification for X86-32 architecture |
This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB. These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture. The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed. The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification. This is the X86 architecture specific part of the Desktop module of the Linux Standard Base (LSB). This part supplements the common part of the LSB Desktop module with those interfaces that differ between architectures. This part should be used in conjunction with the common part of LSB Desktop. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. This part may also contain additional information that is not referenced in the common part. Interfaces described in this part of LSB Desktop are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Desktop module supplement those described in the LSB Core module. They do not depend on other LSB modules.
|
Published |
2021-10 |
Edition : 1 |
Number of pages : 493 |
Technical Committee |
35.080
Software
|
| ISO/IEC TR 24587:2021 |
Software and systems engineering — Agile development — Agile adoption considerations |
This document provides an overview of agile readiness factors that are likely to determine whether an organization, project, product or team is ready to start the transition to using an agile approach to their system and software development and maintenance activities.
This document provides a general approach that is applicable to all agile methodologies and does not cover specific agile methodologies, such as Scrum, SAFe and eXtreme Programming (XP).
|
Published |
2021-10 |
Edition : 1 |
Number of pages : 19 |
Technical Committee |
35.080
Software
|
| ISO/IEC/IEEE 24641 |
Systems and Software engineering — Methods and tools for model-based systems and software engineering |
|
Under development |
|
Edition : 1 |
|
Technical Committee |
35.080
Software
|
| ISO/IEC 23360-3-2:2021 |
Linux Standard Base (LSB) — Part 3-2: Core specification for IA64 (Itanium™) architecture |
This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB. These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture. The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed. The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification. This is the Itanium™ architecture specific part of the Core module of the Linux Standard Base (LSB). This part supplements the common part of the LSB Core module with those interfaces that differ between architectures. This part should be used in conjunction with LSB Core - Generic, the common part. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. This part may also contain additional information that is not referenced in the common part. Interfaces described in this part of the LSB Core Specification are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Core module are supplemented by other LSB modules. All other modules depend on the presence of LSB Core.
|
Published |
2021-10 |
Edition : 1 |
Number of pages : 237 |
Technical Committee |
35.080
Software
|
| ISO/IEC 23360-3-3:2021 |
Linux Standard Base (LSB) — Part 3-3: Desktop specification for IA64 (Itanium TM) architecture |
This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB. These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture. The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed. The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification. This is the Itanium™ architecture specific part of the Desktop module of the Linux Standard Base (LSB). This part supplements the common part of the LSB Desktop module with those interfaces that differ between architectures. This part should be used in conjunction with the common part of LSB Desktop. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. This part may also contain additional information that is not referenced in the common part. Interfaces described in this part of LSB Desktop are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Desktop module supplement those described in the LSB Core module. They do not depend on other LSB modules.
|
Published |
2021-10 |
Edition : 1 |
Number of pages : 493 |
Technical Committee |
35.080
Software
|
| ISO/IEC 23360-4-2:2021 |
Linux Standard Base (LSB) — Part 4-2: Core specification for AMD64 (X86-64) architecture |
This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB. These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture. The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed. The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification. This is the X86-64 architecture specific part of the Core module of the Linux Standard Base (LSB). This part supplements the common part of the LSB Core module with those interfaces that differ between architectures. This part should be used in conjunction with LSB Core - Generic, the common part. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. This part may also contain additional information that is not referenced in the common part. Interfaces described in this part of the LSB Core Specification are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Core module are supplemented by other LSB modules. All other modules depend on the presence of LSB Core.
|
Published |
2021-10 |
Edition : 1 |
Number of pages : 230 |
Technical Committee |
35.080
Software
|
| ISO/IEC 23360-4-3:2021 |
Linux Standard Base (LSB) — Part 4-3: Desktop specification for AMD64 (X86-64) architecture |
The Linux Standard Base (LSB) defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB. These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture. The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed. The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification. This is the X86-64 architecture specific part of the Desktop module of the Linux Standard Base (LSB). This part supplements the common part of the LSB Desktop module with those interfaces that differ between architectures. This part should be used in conjunction with the common part of LSB Desktop. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. This part may also contain additional information that is not referenced in the common part. Interfaces described in this part of LSB Desktop are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Desktop module supplement those described in the LSB Core module. They do not depend on other LSB modules.
|
Published |
2021-10 |
Edition : 1 |
Number of pages : 493 |
Technical Committee |
35.080
Software
|
| ISO/IEC 23360-5-2:2021 |
Linux Standard Base (LSB) — Part 5-2: Core specification for PowerPC 32 architecture |
This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB.
These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture.
The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed.
The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification.
This is the PPC32 architecture specific part of the Core module of the Linux Standard Base (LSB). This part supplements the common part of the LSB Core module with those interfaces that differ between architectures.
This part should be used in conjunction with LSB Core - Generic, the common part. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. This part may also contain additional information that is not referenced in the common part.
Interfaces described in this part of the LSB Core Specification are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Core module are supplemented by other LSB modules. All other modules depend on the presence of LSB Core.
|
Published |
2021-10 |
Edition : 1 |
Number of pages : 256 |
Technical Committee |
35.080
Software
|
| ISO/IEC 23360-5-3:2021 |
Linux Standard Base (LSB) — Part 5-3: Desktop specification for PowerPC 32 architecture |
This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB.
These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture.
The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed.
The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification.
This is the PPC32 architecture specific part of the Desktop module of the Linux Standard Base (LSB). This part supplements the common part of the LSB Desktop module with those interfaces that differ between architectures.
This part should be used in conjunction with the common part of LSB Desktop. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. This part may also contain additional information that is not referenced in the common part.
Interfaces described in this part of LSB Desktop are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Desktop module supplement those described in the LSB Core module. They do not depend on other LSB modules.
|
Published |
2021-10 |
Edition : 1 |
Number of pages : 493 |
Technical Committee |
35.080
Software
|
| ISO/IEC 23360-6-2:2021 |
Linux Standard Base (LSB) — Part 6-2: Core specification for PowerPC 64 architecture |
This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB.
These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture.
The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed.
The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification.
This is the PPC64 architecture specific part of the Core module of the Linux Standard Base (LSB). This part supplements the common part of the LSB Core module with those interfaces that differ between architectures.
This part should be used in conjunction with LSB Core - Generic, the common part. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. This part may also contain additional information that is not referenced in the common part.
Interfaces described in this part of the LSB Core Specification are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Core module are supplemented by other LSB modules. All other modules depend on the presence of LSB Core.
|
Published |
2021-10 |
Edition : 1 |
Number of pages : 252 |
Technical Committee |
35.080
Software
|
| ISO/IEC 23360-6-3:2021 |
Linux Standard Base (LSB) — Part 6-3: Desktop specification for PowerPC 64 architecture |
This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB.
These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture.
The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed.
The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification.
This is the PPC64 architecture specific part of the Desktop module of the Linux Standard Base (LSB). This part supplements the common part of the LSB Desktop module with those interfaces that differ between architectures.
This part should be used in conjunction with the common part of LSB Desktop. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. This part may also contain additional information that is not referenced in the common part.
Interfaces described in this part of LSB Desktop are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Desktop module supplement those described in the LSB Core module. They do not depend on other LSB modules.
|
Published |
2021-10 |
Edition : 1 |
Number of pages : 493 |
Technical Committee |
35.080
Software
|
| ISO/IEC 23360-7-2:2021 |
Linux Standard Base (LSB) — Part 7-2: Core specification for S390 architecture |
This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB.
These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture.
The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed.
The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification.
This is the S390 architecture specific part of the Core module of the Linux Standard Base (LSB). This part supplements the common part of the LSB Core module with those interfaces that differ between architectures.
This part should be used in conjunction with LSB Core - Generic, the common part. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. This part may also contain additional information that is not referenced in the common part.
Interfaces described in this part of the LSB Core Specification are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Core module are supplemented by other LSB modules. All other modules depend on the presence of LSB Core.
|
Published |
2021-10 |
Edition : 1 |
Number of pages : 253 |
Technical Committee |
35.080
Software
|
| ISO/IEC 23360-7-3:2021 |
Linux Standard Base (LSB) — Part 7-3: Desktop specification for S390 architecture |
This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB.
These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture.
The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed.
The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification.
This is the S390 architecture specific part of the Desktop module of the Linux Standard Base (LSB). This part supplements the common part of the LSB Desktop module with those interfaces that differ between architectures.
This part should be used in conjunction with the common part of LSB Desktop. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. This part may also contain additional information that is not referenced in the common part.
Interfaces described in this part of LSB Desktop are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Desktop module supplement those described in the LSB Core module. They do not depend on other LSB modules.
|
Published |
2021-10 |
Edition : 1 |
Number of pages : 493 |
Technical Committee |
35.080
Software
|
| ISO/IEC 23360-8-2:2021 |
Linux Standard Base (LSB) — Part 8-2: Core specification for S390X architecture |
This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB.
These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture.
The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed.
The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification.
This is the S390X architecture specific part of the Core module of the Linux Standard Base (LSB). This part supplements the common part of the LSB Core module with those interfaces that differ between architectures.
This part should be used in conjunction with LSB Core - Generic, the common part. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. This part may also contain additional information that is not referenced in the common part.
Interfaces described in this part of the LSB Core Specification are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Core module are supplemented by other LSB modules. All other modules depend on the presence of LSB Core.
|
Published |
2021-10 |
Edition : 1 |
Number of pages : 250 |
Technical Committee |
35.080
Software
|
| ISO/IEC 23360-8-3:2021 |
Linux Standard Base (LSB) — Part 8-3: Desktop specification for S390X architecture |
This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB.
These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture.
The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed.
The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification.
This is the S390X architecture specific part of the Desktop module of the Linux Standard Base (LSB). This part supplements the common part of the LSB Desktop module with those interfaces that differ between architectures.
This part should be used in conjunction with the common part of LSB Desktop. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. This part may also contain additional information that is not referenced in the common part.
Interfaces described in this part of LSB Desktop are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Desktop module supplement those described in the LSB Core module. They do not depend on other LSB modules.
|
Published |
2021-10 |
Edition : 1 |
Number of pages : 493 |
Technical Committee |
35.080
Software
|
| ISO/IEC TS 23360-1-6:2021 |
Linux Standard Base (LSB) — Part 1-6: Graphics and Gtk3 specification |
The Trial Use Specification defines components which are not required parts of the LSB Specification.
|
Published |
2021-10 |
Edition : 1 |
Number of pages : 519 |
Technical Committee |
35.080
Software
|
| ISO/IEC 23396:2020 |
Systems and software engineering — Capabilities of review tools |
This document specifies the capabilities of a tool to support review work.
The evaluation and selection of the review tools are performed in accordance with ISO/IEC 20741 which defines the general evaluation selection process and evaluation characteristics. This document defines capabilities specific to review tools in the process. By using these two standards together, it is possible to derive objective and reasonable results of the evaluation and selection of review tools.
The review work is based on the process, activities, and tasks defined in ISO/IEC 20246. It is also assumed that the review targets are defined in ISO/IEC 20246. The review work in this document is assumed not to be performed by a 3rd party, but within a project.
The review tool capabilities specified in this document harmonize with the review process defined in ISO/IEC 20246. This document does not include automated process, activities, or tasks for conducting reviews such as automated source code checkers defined in ISO/IEC 30130.
Issues which are identified in the review are recorded and managed by the tool; but defects found in tests and issues found in general except for reviews are out of the scope of this document.
|
Published |
2020-07 |
Edition : 1 |
Number of pages : 31 |
Technical Committee |
35.080
Software
|
| ISO/IEC 23531:2020 |
Systems and software engineering — Capabilities of issue management tools |
This document defines the capabilities of issue management tools and is used to select the most appropriate one from many issue management tools. The evaluation and selection of the issue management tools is performed in accordance with ISO/IEC 20741 which defines the general evaluation selection process and evaluation characteristics. Issue management is based on the tasks described in several activities in their processes (e.g. project assessment and control, decision management, and system/software requirements definition) of ISO/IEC/IEEE 12207.
This document is independent of development methodology or approaches (e.g. Waterfall or Agile) or lifecycle processes (e.g. implementation or operation).
|
Published |
2020-12 |
Edition : 1 |
Number of pages : 36 |
Technical Committee |
35.080
Software
|
| ISO/IEC 23643:2020 |
Software and systems engineering — Capabilities of software safety and security verification tools |
This document specifies requirements for the vendors and gives guidelines for both the users and the developers of software safety and security verification tools. The users of such tools include, but are not limited to, bodies performing verification and software developers who need to be aware and pay attention to safety and/or security of software. This document guides the verification tool vendors to provide as high-quality products as possible and helps the users to understand the capabilities and characteristics of verification tools.
This document introduces use cases for software safety and security verification tools and entity relationship model related to them. This document also introduces tool categories for software safety and security verification tools and gives category specific guidance and requirements for the tool vendors and developers.
|
Published |
2020-06 |
Edition : 1 |
Number of pages : 30 |
Technical Committee |
35.080
Software
|
| ISO/IEC 24744:2007 |
Software Engineering — Metamodel for Development Methodologies |
Development methodologies may be described in the context of an underpinning metamodel, but the precise mechanisms that permit them to be defined in terms of their metamodels are usually difficult to explain and do not cover all needs. For example, it is difficult to devise a practice that allows the definition of properties of the elements that compose the methodology and, at the same time, of the entities (such as work products) created when the methodology is applied. ISO/IEC 24744:2007 introduces the Software Engineering Metamodel for Development Methodologies (SEMDM), a comprehensive metamodel that makes use of a new approach to defining methodologies based on the concept of powertype. The aim of SEMDM is to define methodologies in information-based domains, i.e. areas characterized by their intensive reliance on information management and processing, such as software, business or systems engineering. The SEMDM combines key advantages of other metamodelling approaches with none of their known drawbacks, allowing the seamless integration of process, modelling and people aspects of methodologies. Examples are given where other metamodels are mapped to SEMDM and a brief synopsis of problems is provided.
Various methodologies are defined, used, or implied by a growing number of standards, and it is desirable that the concepts used by each methodology be harmonized. A vehicle for harmonization is the SEMDM. Conformance to this metamodel will ensure a consistent approach to defining each methodology with consistent concepts and terminology.
|
Withdrawn |
2007-02 |
Edition : 1 |
Number of pages : 78 |
Technical Committee |
35.080
Software
|
| ISO/IEC 24744:2007/Amd 1:2010 |
Software Engineering — Metamodel for Development Methodologies — Amendment 1: Notation |
|
Withdrawn |
2010-02 |
Edition : 1 |
Number of pages : 24 |
Technical Committee |
35.080
Software
|
| ISO/IEC 24744:2014 |
Software engineering — Metamodel for development methodologies |
Development methodologies may be described in the context of an underpinning metamodel, but the precise mechanisms that permit them to be defined in terms of their metamodels are usually difficult to explain and do not cover all needs. For example, it is difficult to devise a practice that allows the definition of properties of the elements that compose the methodology and, at the same time, of the entities (such as work products) created when the methodology is applied. ISO/IEC 24744:2014 introduces the Software Engineering Metamodel for Development Methodologies (SEMDM), a comprehensive metamodel that makes use of a new approach to defining methodologies based on the concept of powertype. The aim of SEMDM is to define methodologies in information-based domains, i.e. areas characterized by their intensive reliance on information management and processing, such as software, business or systems engineering. The SEMDM combines key advantages of other metamodelling approaches with none of their known drawbacks, allowing the seamless integration of process, modelling and people aspects of methodologies. Examples are given where other metamodels are mapped to SEMDM and a brief synopsis of problems is provided.
Various methodologies are defined, used, or implied by a growing number of standards, and it is desirable that the concepts used by each methodology be harmonized. A vehicle for harmonization is the SEMDM. Conformance to this metamodel will ensure a consistent approach to defining each methodology with consistent concepts and terminology.
|
Published |
2014-11 |
Edition : 2 |
Number of pages : 96 |
Technical Committee |
35.080
Software
|
| ISO/IEC TR 24748-1:2010 |
Systems and software engineering — Life cycle management — Part 1: Guide for life cycle management |
ISO/IEC TR 24748-1:2010 provides information on life cycle concepts and descriptions of the purposes and outcomes of representative life cycle stages. It also illustrates the use of a life cycle model for systems in the context of ISO/IEC 15288 and provides a corresponding illustration of the use of a life cycle model for software in the context of ISO/IEC 12207. ISO/IEC TR 24748-1:2010 additionally provides detailed discussion and advice on adapting a life cycle model for use in a specific project and organizational environment. It further provides guidance on life cycle model use by domains, disciplines and specialties.
ISO/IEC TR 24748-1:2010 gives a detailed comparison between prior and current versions of ISO/IEC 12207 and ISO/IEC 15288, as well as advice on transitioning from prior to current versions and on using their application guides. The discussion and advice are intended to provide a reference model for life cycle models, facilitate use of the updated ISO/IEC 15288 and ISO/IEC 12207, and provide a framework for the development of updated application guides for those International Standards. ISO/IEC TR 24748-1:2010 is a result of the alignment stage of the harmonization of ISO/IEC 12207 and ISO/IEC 15288.
|
Withdrawn |
2010-10 |
Edition : 1 |
Number of pages : 76 |
Technical Committee |
35.080
Software
|
| ISO/IEC TS 24748-1:2016 |
Systems and software engineering — Life cycle management — Part 1: Guidelines for life cycle management |
ISO/IEC TS 24748-1:2016 provides guidelines for the life cycle management of systems and software, complementing the processes described in ISO/IEC/IEEE 15288 and ISO/IEC 12207. This Technical Specification:
- addresses systems concepts and life cycle concepts, models, stages, processes, process application, key points of view, adaptation and use in various domains and by various disciplines;
- establishes a common framework for describing life cycles, including their individual stages, for the management of projects to provide, or acquire either products or services;
- defines the concept and terminology of a life cycle;
- supports the use of the life cycle processes within an organization or a project. Organizations and projects can use these life cycle concepts when acquiring and supplying either products or services;
- provides guidance on adapting a life cycle model and the content associated with a life cycle or a part of a life cycle;
- describes the relationship between life cycles and their use in applying the processes in ISO/IEC/IEEE 15288 (systems aspects) and ISO/IEC 12207 (software aspects);
- shows the relationships of life cycle concepts to the hardware, human, services, process, procedure, facility and naturally occurring entity aspects of projects; and
- describes how its concepts relate to detailed process standards, for example, in the areas of measurement, project management and risk management.
|
Withdrawn |
2016-05 |
Edition : 1 |
Number of pages : 65 |
Technical Committee |
35.080
Software
|
| ISO/IEC/IEEE 24748-1:2018 |
Systems and software engineering — Life cycle management — Part 1: Guidelines for life cycle management |
This document provides guidelines for the life cycle management of systems and software, complementing the processes described in ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207. This document:
— addresses systems concepts and life cycle concepts, models, stages, processes, process application, key points of view, adaptation and use in various domains and by various disciplines;
— establishes a common framework for describing life cycles, including their individual stages, for the management of projects to provide, or acquire either products or services;
— defines the concept and terminology of a life cycle;
— supports the use of the life cycle processes within an organization or a project. Organizations and projects can use these life cycle concepts when acquiring and supplying either products or services;
— provides guidance on adapting a life cycle model and the content associated with a life cycle or a part of a life cycle;
— describes the relationship between life cycles and their use in applying the processes in ISO/IEC/IEEE 15288 (systems aspects) and ISO/IEC/IEEE 12207 (software aspects);
— shows the relationships of life cycle concepts to the hardware, human, services, process, procedure, facility and naturally occurring entity aspects of projects; and
— describes how its concepts relate to detailed process standards, for example, in the areas of measurement, project management and risk management.
|
Published |
2018-11 |
Edition : 1 |
Number of pages : 72 |
Technical Committee |
35.080
Software
|
| ISO/IEC/IEEE DIS 24748-1 |
Systems and software engineering — Life cycle management — Part 1: Guidelines for life cycle management |
The proposed project is a revision of ISO/IEC/IEEE 24748-1:2018, Guidelines for life cycle management. There are no scope changes.
The document provides guidelines for the life cycle management of systems and software, complementing the processes described in ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207. This document:
— addresses systems concepts and life cycle concepts, models, stages, processes, process application, key points of view, adaptation and use in various domains and by various disciplines;
— establishes a common framework for describing life cycles, including their individual stages, for the management of projects to provide, or acquire either products or services;
— defines the concept and terminology of a life cycle;
— supports the use of the life cycle processes within an organization or a project. Organizations and projects can use these life cycle concepts when acquiring and supplying either products or services;
— provides guidance on adapting a life cycle model and the content associated with a life cycle or a part of a life cycle;
— describes the relationship between life cycles and their use in applying the processes in ISO/IEC/IEEE 15288 (systems aspects) and ISO/IEC/IEEE 12207 (software aspects);
— shows the relationships of life cycle concepts to the hardware, human, services, process, procedure, facility and naturally occurring entity aspects of projects; and
- describes how its concepts relate to detailed process standards, for example, in the areas of measurement, project management and risk management.
|
Under development |
|
Edition : 2 |
Number of pages : 75 |
Technical Committee |
35.080
Software
|
| ISO/IEC TR 24748-2:2011 |
Systems and software engineering — Life cycle management — Part 2: Guide to the application of ISO/IEC 15288 (System life cycle processes) |
ISO/IEC TR 24748-2:2011 is a guide for the application of ISO/IEC 15288:2008. It addresses system, life cycle, process, organizational, project, and adaptation concepts, principally through reference to ISO/IEC TR 24748-1 and ISO/IEC 15288:2008. It then gives guidance on applying ISO/IEC 15288:2008 from the aspects of strategy, planning, application in organizations, and application on projects.
ISO/IEC TR 24748-2:2011 is intentionally aligned with both ISO/IEC TR 24748-1 and ISO/IEC TR 24748-3 (Guide to the application of ISO/IEC 12207) in its terminology, structure and content.
|
Withdrawn |
2011-09 |
Edition : 1 |
Number of pages : 76 |
Technical Committee |
35.080
Software
|
| ISO/IEC/IEEE 24748-2:2018 |
Systems and software engineering — Life cycle management — Part 2: Guidelines for the application of ISO/IEC/IEEE 15288 (System life cycle processes) |
This document is a guideline for the application of ISO/IEC/IEEE 15288:2015. It addresses system, life cycle, organizational, project, and process, concept application, principally through reference to ISO/IEC/IEEE 24748‑1 and ISO/IEC/IEEE 15288:2015. It gives guidance on applying ISO/IEC/IEEE 15288:2015 from the aspects of strategy, planning, application in organizations, and application on projects. It also provides comparison of the differences between ISO/IEC/IEEE 15288:2015 and the prior versions, ISO/IEC 15288:2008.
This document is intended to be consistent with both ISO/IEC/IEEE 24748‑1 and ISO/IEC/IEEE 15288:2015 in its treatment of life-cycle concepts and systems engineering processes.
NOTE Systems engineering for defense programs is addressed in IEEE Std 15288.1, Application of Systems Engineering on Defense Programs.
|
Published |
2018-12 |
Edition : 1 |
Number of pages : 64 |
Technical Committee |
35.080
Software
|
| ISO/IEC/IEEE DIS 24748-2 |
Systems and software engineering — Life cycle management — Part 2: Guidelines for the application of ISO/IEC/IEEE 15288 (System life cycle processes) |
The proposed project is a revision of ISO/IEC/IEEE 24748-2:2018, Systems and software engineering — Life cycle management — Part 2: Guidelines for the application of ISO/IEC/IEEE 15288 (System life cycle processes). There are no scope changes.
ISO/IEC/IEEE 24748-2 is a guideline for the application of ISO/IEC/IEEE 15288. It addresses system, life cycle, organizational, project, and process, concept application, principally through reference to ISO/IEC/IEEE 24748-1 and ISO/IEC/IEEE 15288. It gives guidance on applying ISO/IEC/IEEE 15288 from the aspects of strategy, planning, application in organizations, and application on projects. It also provides comparison of the differences between ISO/IEC/IEEE 15288 current revision and the prior version, ISO/IEC 15288:2015.
|
Under development |
|
Edition : 2 |
Number of pages : 69 |
Technical Committee |
35.080
Software
|
| ISO 8858-1:1990/Cor 1:2001 |
Hard coal — Froth flotation testing — Part 1: Laboratory procedure — Technical Corrigendum 1 |
|
Withdrawn |
2001-04 |
Edition : 1 |
Number of pages : 1 |
Technical Committee |
73.040
Coals
|
| ISO/IEC TR 24748-3:2011 |
Systems and software engineering — Life cycle management — Part 3: Guide to the application of ISO/IEC 12207 (Software life cycle processes) |
ISO/IEC TR 24748-3:2011 is a guide for the application of ISO/IEC 12207:2008. It addresses system, life cycle, process, organizational, project, and adaptation concepts, principally through reference to ISO/IEC TR 24748-1 and ISO/IEC 12207:2008. It gives guidance on applying ISO/IEC 12207:2008 from the aspects of strategy, planning, application in organizations, and application on projects.
ISO/IEC TR 24748-3:2011 is intentionally aligned with both ISO/IEC TR 24748-1 and ISO/IEC TR 24748-2 (Guide to the application of ISO/IEC 15288) in its terminology, structure and content.
|
Withdrawn |
2011-09 |
Edition : 1 |
Number of pages : 111 |
Technical Committee |
35.080
Software
|
| ISO/IEC/IEEE 24748-3:2020 |
Systems and software engineering — Life cycle management — Part 3: Guidelines for the application of ISO/IEC/IEEE 12207 (software life cycle processes) |
This document is a guideline for the application of ISO/IEC/IEEE 12207:2017. This document establishes guidance to implement a common framework for software life cycle processes, with well-defined terminology, that can be referenced by the software industry. This document provides guidance on defining, controlling, and improving software life cycle processes within an organization or a project. This document recommends methods and approaches suitable for a variety of life cycle models. The guidance emphasizes the importance of establishing a strategy, planning, and the involvement of stakeholders, with the ultimate goal of achieving customer satisfaction.
This document applies to the acquisition, supply, design and development, transition, operation, maintenance, and disposal (whether performed internally or externally to an organization) of software systems, products, and services (including software as a service (SaaS)), and the software portion of any system. Software includes the software portion of firmware. The guidance on processes, activities, and tasks in this document can also be applied during the acquisition of a system that contains software. The guidance in this document can also be used as a basis for selecting, establishing, and improving organizational environments, e.g., methods, procedures, techniques, tools, and trained personnel.
In the context of this document, there is a continuum of human-made systems from those that use little or no software to those in which software is the primary interest. It is rare to encounter a complex system without software, and all software systems require physical system components (hardware) to operate, either as part of the software system-of-interest (SoI) or as an enabling system or infrastructure. Thus, the choice of whether to apply this document for guidance to the software life cycle processes, or ISO/IEC/IEEE 24748-2, depends on the SoI. At a high level, both documents have the same life cycle process framework, but differ in guidance for activities and tasks to perform software engineering or systems engineering, respectively.
The processes and process groups in this document are identical in their purpose and outcomes with those in ISO/IEC/IEEE 12207:2017 and in ISO/IEC/IEEE 15288:2015, with one exception: the System/Software Requirements Definition process of ISO/IEC/IEEE 12207:2017 and this document has a different name from the System Requirements Definition process of ISO/IEC/IEEE 15288:2015.
Use of the guidance in this document is appropriate regardless of software system size or complexity or organizational size. The process outcomes from the ISO/IEC/IEEE 12207:2017 life cycle processes are meant to be generic and applicable to the engineering of any software system in any size organization.
This document does not prescribe nor detail a specific software life cycle model, development methodology, method, modelling approach, or technique and method. The variety of ways for implementing software (e.g., development of new code, integration of existing open source components and commercial products, or modifications to existing software, including transition to new platforms) make it impossible to detail specific procedures.
This document does not establish a management system or provide guidance on the use of any management system standard. However, it is intended to be compatible with the quality management system specified by ISO 9001, the service management system specified by ISO/IEC 20000-1, the IT asset management system specified by ISO/IEC 19770 (all parts), and the information security management system specified by ISO/IEC 27000.
Clause 6 provides guidance on aspects of purposes, outcomes, activities, and tasks in ISO/IEC/IEEE 12207:2017. However, this document does not repeat the detailed requirements and recommendations for purposes, outcomes, activities, and tasks for each life cycle process found in ISO/IEC/IEEE 12207:2017. Clause 6 also provides references to specialized standards that provide more detailed requirements and guidance for the various processes and information products (information items). This document does not detail information items (process inputs and outputs) in terms of name, format, explicit content and recording media.
NOTE ISO/IEC/IEEE 15289 addresses the content for life cycle process information items (documentation).
|
Published |
2020-10 |
Edition : 1 |
Number of pages : 66 |
Technical Committee |
35.080
Software
|
| ISO/IEC/IEEE 24748-4:2016 |
Systems and software engineering — Life cycle management — Part 4: Systems engineering planning |
The evolution of the harmonized set of ISO/IEC/IEEE 15288-12207 related
standards and technical reports that are discussed in this International Standard
provides detailed requirements and guidance on the application of system life cycle
processes. This International Standard unifies technical and management
requirements and guidance from several of these sources to specify the requirements
for the content of a SEMP and to provide a common SEMP format. This International
Standard also identifies the processes as defined in ISO/IEC/IEEE 15288 to perform
the necessary project planning activities to accomplish the project's technical effort and
to develop the project's SEMP. Due to close alignment with the content of
ISO/IEC 24748, ISO/IEC 26702 is now Part 4 of the multi-part International Standard,
ISO/IEC 24748 (Systems and software engineering ? Life cycle management).
|
Published |
2016-05 |
Edition : 1 |
Number of pages : 62 |
Technical Committee |
35.080
Software
|
| ISO/IEC/IEEE 24748-5:2017 |
Systems and software engineering — Life cycle management — Part 5: Software development planning |
ISO/IEC/IEEE 24748-5:2017 provides a common framework for planning and controlling the technical processes and activities to produce and sustain software products. The complete life cycle is covered by this document, from idea conception to the retirement of a software product. The framework described by this document provides for best practices in communication and cooperation among parties that plan for, develop, utilize, and manage modern software.
ISO/IEC/IEEE 24748-5:2017:
- specifies the required information items to be produced through the implementation of the required planning and control processes;
- specifies the required content of the required information items;
- gives guidelines for the format and content of the required and related information items; and
- details the processes necessary to develop and implement a software plan.
ISO/IEC/IEEE 24748-5:2017 is intended to provide guidance for parties involved in the planning of software engineering at all stages of the software life cycle. It is intended to provide a common framework for two-party and multi-party collaborations and can be applied where the parties are from the same organization. This document can also be used by a single party.
ISO/IEC/IEEE 24748-5:2017 is applicable to:
- those who use ISO/IEC/IEEE FDIS 12207 on projects dealing with software products and services related to those products;
- those who are responsible for the technical management of the development of software systems;
- organizations and individuals performing software development activities; and
- organizations and individuals developing information items during the development of software.
|
Published |
2017-06 |
Edition : 1 |
Number of pages : 40 |
Technical Committee |
35.080
Software
|
| ISO/IEC/IEEE FDIS 24748-6 |
Systems and software engineering — Life cycle management — Part 6: System and software integration |
|
Under development |
|
Edition : 1 |
Number of pages : 42 |
Technical Committee |
35.080
Software
|
| ISO/IEC TS 24748-6:2016 |
Systems and software engineering — Life cycle management — Part 6: System integration engineering |
ISO/IEC TS 24748-6:2016
- specifies activities and processes to be implemented for engineering the integration of systems-of-interest throughout the life cycle (systems made of products and/or services; see Note 1),
- provides guidance for the integration process and its relationships to other system life cycle processes as described in ISO/IEC/IEEE 15288,
- specifies the information items to be produced through the implementation of the integration engineering (integration process and its relationships to other system life cycle processes),
- specifies the contents of the information items, and
- provides guidelines for the format of the information items.
ISO/IEC TS 24748-6:2016 can be applied to
- those who use or plan to use ISO/IEC/IEEE 15288 on projects dealing with man-made systems, software-intensive systems, products and services related to those systems, regardless of project scope, methodology, size or complexity, and
- anyone performing integration engineering activities to aid in ensuring that the application of the integration process and its relationships to other system life cycle processes conform to ISO/IEC/IEEE 15288.
|
Published |
2016-12 |
Edition : 1 |
Number of pages : 35 |
Technical Committee |
35.080
Software
|
| ISO/IEC/IEEE 24748-7:2019 |
Systems and software engineering — Life cycle management — Part 7: Application of systems engineering on defense programs |
This document establishes the requirements for systems engineering activities to be performed on projects of the United States (US) Department of Defense (DoD) and other defense agencies across the entire system life cycle, including the planning, acquisition, modification, and sustainment of defense systems. It provides the foundation for systems engineering within the context of ISO/IEC/IEEE 152881 and the acquisition environment of DoD and other defense agencies at all levels of system hierarchy. This document provides detailed requirements for the application of the life cycle processes, activities, and tasks of ISO/IEC/IEEE 15288 for use on any defense system and includes the effective integration of agreement processes, technical processes, technical management processes, and essential specialty engineering requirements.
|
Published |
2019-02 |
Edition : 1 |
Number of pages : 51 |
Technical Committee |
35.080
Software
|
| ISO/IEC FDIS 24773-4 |
Software and systems engineering — Certification of software and systems engineering professionals — Part 4: Software engineering |
|
Under development |
|
Edition : 1 |
Number of pages : 14 |
Technical Committee |
35.080
Software
|