iTeh StandardsiTeh Standards
EURUSD
Your shopping cart is empty.

35.080 - Software

ICS 35.080 Details

Software

Softwareentwicklung. Systemdokumentation

Logiciels

Programska oprema

General Information

Parent
35 - INFORMATION TECHNOLOGY

e-Library Subscription

Create subscription and get permanent access to documents within 35.080 - Software

Type
Monthly Subscription
for
seat
×
$ 227.19
$ 227.19

Currently subscription includes documents marked with .We are working on making all documents available within the subscription.

Standardization Organization
Technical Committee
Directive
Mandate
50
ISO
ISO/IEC/IEEE 24748-6:2023(Main)
Systems and software engineering — Life cycle management — Part 6: System and software integration

This document: — provides supplemental requirements and guidance for the planning and performing of the integration processes given in ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207; — provides guidance on the relationship between the integration process and other life cycle processes. — specifies requirements for information items to be produced as a result of using the integration process, including the content of the information items. This document is applicable to: — those who use or plan to use ISO/IEC/IEEE 12207 or ISO/IEC/IEEE 15288, or both, on projects dealing with human-made systems, software-intensive systems, and products and services related to those systems, regardless of the project scope, methodology, size, or complexity; — anyone planning or performing integration 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 or ISO/IEC/IEEE 12207.

  • Standard
    42 pages
    English language
    sale 15% off
  • Draft
    42 pages
    English language
    sale 15% off
  • Draft
    42 pages
    English language
    sale 15% off
ISO
ISO/IEC/IEEE 23026:2023(Main)
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, website engineers, designers, developers, and operations and maintenance staff, who can 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 systems, products and services. The requirements and recommendations in this document address the following aspects of usability of informational websites and ease of maintenance of managed website operations: a) locating relevant and timely information; b) applying information security management; c) facilitating accessibility and ease of use; d) providing for consistent and efficient development and maintenance practices. This document is not particularly applicable to websites used primarily for marketing or sales, to deliver instructional material (tutorials), or to provide graphical user interfaces (GUI) for business or consumer transactional application processing. However, this document can provide useful insights for managing such sites. This document does not address vendor and product considerations for website engineering and management. This document does not include specifications for application development tools, programming and scripting languages used for websites, metadata tags, or protocols for network communications. It does not address tools or systems used for management or storage of information content (data, documents) that can be presented on websites. This document does not address the design and architecture of software and systems supporting the Internet.

  • Standard
    57 pages
    English language
    sale 15% off
  • Draft
    57 pages
    English language
    sale 15% off
ISO
ISO/IEC 24773-4:2023(Main)
Software and systems engineering — Certification of software and systems engineering professionals — Part 4: Software engineering

This document elaborates requirements and recommendations for certifications schemes based on ISO/IEC 24773-1, which are specific to the domain of software engineering.

  • Standard
    14 pages
    English language
    sale 15% off
  • Draft
    14 pages
    English language
    sale 15% off
ISO
ISO/IEC 25059:2023(Main)
Software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Quality model for AI systems

This document outlines a quality model for AI systems and is an application-specific extension to the standards on SQuaRE. The characteristics and sub-characteristics detailed in the model provide consistent terminology for specifying, measuring and evaluating AI system quality. The characteristics and sub-characteristics detailed in the model also provide a set of quality characteristics against which stated quality requirements can be compared for completeness.

  • Standard
    15 pages
    English language
    sale 15% off
  • Draft
    15 pages
    English language
    sale 15% off
ISO
ISO/IEC/IEEE 24748-9:2023(Main)
Systems and software engineering — Life cycle management — Part 9: Application of system and software life cycle processes in epidemic prevention and control systems

This document provides requirements and guidance on the application of system and software engineering processes to systems for epidemic prevention and control. This document provides guidance that can be employed for adopting and applying system and software life cycle processes within an organization or a project in an epidemic emergency. It includes system of systems considerations in the context of epidemic emergency. This document applies to acquisition, supply, development, operation, maintenance, and disposal (whether performed internally or externally to an organization) of system or system of systems in an epidemic emergency. Many of the requirements and recommendations in this document are also applicable to other systems developed rapidly to respond to emergency conditions affecting the public.

  • Standard
    41 pages
    English language
    sale 15% off
  • Draft
    44 pages
    English language
    sale 15% off
  • Draft
    44 pages
    English language
    sale 15% off
ISO
ISO/IEC/IEEE 24641:2023(Main)
Systems and Software engineering — Methods and tools for model-based systems and software engineering

This document deals with the tool capabilities and methods for model-based systems and software engineering (MBSSE). This document: — specifies a reference model for the overall structure and processes of MBSSE-specific processes, and describes how the components of the reference model fit together; — specifies interrelationships between the components of the reference model; — specifies MBSSE-specific processes for model-based systems and software engineering; the processes are described in terms of purpose, inputs, outcomes and tasks; — specifies methods to support the defined tasks of each process; — specifies tool capabilities to automate or semi-automate tasks or methods. This document does not bring any additional life cycle processes for system and software but specifies an MBSSE reference model considered as activities, not only from the life cycle perspectives of systems engineering problem solving and the system-of-interest evolution, but also from the cognitive perspectives of modelling and model management, which can sustain and facilitate the system and software life cycle processes during digital transformation and in the digital age. The processes defined in this document are applicable for a single project, as well as for an organization performing multiple projects or an enterprise. These processes are applicable for managing and performing the systems and software engineering activities based on models within any stage in the life cycle of a system-of-interest.

  • Standard
    85 pages
    English language
    sale 15% off
  • Draft
    85 pages
    English language
    sale 15% off
  • Draft
    85 pages
    English language
    sale 15% off
ISO
ISO/IEC/IEEE 15288:2023(Main)
Systems and software engineering — System life cycle processes

This document establishes a common framework of process descriptions for describing the life cycle of systems created by humans, defining a set of processes and associated terminology from an engineering viewpoint. These processes can be applied to systems of interest, their system elements, and to systems of systems. Selected sets of these processes can be applied throughout the stages of a system's life cycle. This is accomplished through the involvement of stakeholders, with the ultimate goal of achieving customer satisfaction. This document defines a set of processes to facilitate system development and information exchange among acquirers, suppliers, and other stakeholders in the life cycle of a system. This document specifies processes that support the definition, control, and improvement of the system life cycle processes used within an organization or a project. Organizations and projects can use these processes when acquiring and supplying systems. This document applies to organizations in their roles as both acquirers and suppliers. This document applies to the full life cycle of systems, including conception, development, production, utilization, support and retirement of systems, and to the acquisition and supply of systems, whether performed internally or externally to an organization. The life cycle processes of this document can be applied iteratively and concurrently to a system and recursively to the system elements. This document applies to one-of-a-kind systems, mass-produced systems, and customised, adaptable systems. It also applies to a complete stand-alone system and to systems that are embedded and integrated into larger more complex and complete systems. This document does not prescribe a specific system life cycle model, development methodology, method, modelling approach or technique. This document does not detail information items in terms of name, format, explicit content, and recording media. ISO/IEC/IEEE 15289 addresses the content for life cycle process information items (documentation).

  • Standard
    116 pages
    English language
    sale 15% off
  • Draft
    116 pages
    English language
    sale 15% off
  • Draft
    116 pages
    English language
    sale 15% off
ISO
ISO/TR 25060:2023(Main)
Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — General framework for Common Industry Format (CIF) for usability-related information

This document describes information items enabling systematic human-centred design for interactive systems. Some of these information items are elaborated by separate International Standards, named the Common Industry Format (CIF) for usability-related information. This document provides the framework of information items, including definitions and the content for each information item. This document includes the following: — the intended users of the information items; — consistent terminology; — the high-level content structure to be used for documenting each information item. The information items are intended to be used as part of system-level documentation resulting from development processes such as those in ISO 9241-210, ISO 9241-220 and ISO/IEC JTC 1/SC 7 process standards (e.g. ISO/IEC/IEEE 15288, ISO/IEC/IEEE 29148). This document focuses on those information items needed for design, development and evaluation of usable systems, rather than prescribing a specific process. It is intended to be used in conjunction with existing International Standards, including the standards of the ISO 9241 series and the SQuaRE documents. This document does not prescribe any kind of method, life cycle or process. NOTE The information items produced by human-centred design activities can be incorporated in design approaches as diverse as object-oriented, waterfall, HFI (human factors integration), agile and rapid development.

  • Technical report
    20 pages
    English language
    sale 15% off
  • Draft
    20 pages
    English language
    sale 15% off
  • Draft
    20 pages
    English language
    sale 15% off
ISO
ISO/IEC TS 33010:2023(Main)
Information technology — Process assessment — Guidance for performing process assessments

This document provides an overview of process assessment and interprets the requirements of ISO/IEC 33002 and ISO/IEC 33004 through the provision of guidance on the selection and use of assessment models, documented assessment processes, and instruments or tools for assessment. Process assessment is applicable in the following circumstances: a) by or on behalf of an organization with the objective of understanding the state of its own processes for process improvement; b) by or on behalf of an organization with the objective of determining the suitability of its own processes for a particular requirement or class of requirements; c) by or on behalf of one organization with the objective of determining the suitability of another organization's processes for a particular contract or class of contracts.

  • Technical specification
    22 pages
    English language
    sale 15% off
  • Draft
    22 pages
    English language
    sale 15% off
  • Draft
    22 pages
    English language
    sale 15% off
ISO
ISO/IEC/IEEE 26531:2023(Main)
Systems and software engineering — Content management for product life cycle, user and service management information for users

This document specifies requirements for efficient development and management of information produced — throughout the life cycle of a system and software product; — for the provision of information for users of systems and software; — for the management of IT and support services. This document is independent of the tools, protocols, and systems used for content management. It does not address configuration management of software assets. The content management process presented in Clauses 6 to 10 is a specialization (lower-level process) of the information management process specified in ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207.

  • Standard
    53 pages
    English language
    sale 15% off
ISO
ISO/IEC 26563:2022(Main)
Software and systems engineering — Methods and tools for product line configuration management

This document, within the context of methods and tools that support the configuration management (CM) capability of software and systems product line engineering: — specifies processes for product line CM (the processes are described in terms of purpose, inputs, tasks, and outcomes); — specifies method capabilities to support the defined tasks of each process; — specifies tool capabilities that automate or semi-automate tasks and methods. This document does not concern the processes and capabilities of tools and methods for a single system but rather deals with those for a family of products.

  • Standard
    34 pages
    English language
    sale 15% off
ISO
ISO/IEC 26564:2022(Main)
Software and systems engineering — Methods and tools for product line measurement

This document, within the context of methods and tools that support the product line measurement and management and that demonstrate the quality of the products and a product line: — specifies processes for product line measurement (the processes are described in terms of purpose, inputs, tasks and outcomes); — specifies method capabilities to support the defined tasks of each process; — specifies tool capabilities that automate or semi-automate tasks and methods. This document does not concern the processes and capabilities of tools and methods for a single system but rather deals with those for a family of products.

  • Standard
    39 pages
    English language
    sale 15% off
ISO
ISO/IEC TR 29119-13:2022(Main)
Software and systems engineering — Software testing — Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems

This document: — gives information for software testers for the systematic, risk-based testing of biometric systems and larger systems which include biometric subsystems; — establishes the importance of both biometric standards and software testing standards and provides overviews of both areas and their standardization; — specifies the most important biometric standards for software testers of biometric systems; — provides information for software testers who wish to conform to both the relevant biometrics standards and the ISO/IEC/IEEE 29119 series of software testing standards by providing mappings between the two sets of standards; — is not limited to the testing of the technical performance of biometric systems in terms of error rates and throughput rates, but instead covers the testing of the full range of relevant quality characteristics, such as reliability, availability, maintainability, security, conformance, usability, human factors, and privacy regulation compliance; — gives information on applying a risk-based testing approach to the testing of biometric systems that covers the full range of product and project risks; — provides testers with an example set of product and project risks associated with biometric systems along with suggestions on how these risks can be treated as part of a risk-based approach to the testing; — includes mappings between the documentation requirements of ISO/IEC 19795-1, ISO/IEC 19795-2 and ISO/IEC 19795-6 and the software test documentation defined by ISO/IEC/IEEE 29119-3.

  • Technical report
    274 pages
    English language
    sale 15% off
  • Draft
    273 pages
    English language
    sale 15% off
  • Draft
    273 pages
    English language
    sale 15% off
ISO
ISO/IEC/IEEE 24748-7000:2022(Main)
Systems and software engineering — Life cycle management — Part 7000: Standard model process for addressing ethical concerns during system design

The standard establishes a set of processes by which engineers and technologists can include consideration of ethical values throughout the stages of concept exploration and development, which encompass system initiation, analysis, and design. This standard provides engineers and technologists with an implementable process aligning innovation management processes, system design approaches, and software engineering methods to help address ethical concerns or risks during system design. IEEE Std 7000™ does not give specific guidance on the design of algorithms to apply ethical values such as fairness and privacy.

  • Standard
    69 pages
    English language
    sale 15% off
  • Draft
    69 pages
    English language
    sale 15% off
ISO
ISO/IEC/IEEE 15026-2:2022(Main)
Systems and software engineering — Systems and software assurance — Part 2: Assurance case

This document specifies requirements for structure terminology of assurance cases. This document is applicable for developing and maintaining assurance cases.

  • Standard
    20 pages
    English language
    sale 15% off
ISO
ISO/IEC/IEEE 42010:2022(Main)
Software, systems and enterprise — Architecture description

This document specifies requirements for the structure and expression of an architecture description (AD) for various entities, including software, systems, enterprises, systems of systems, families of systems, products (goods or services), product lines, service lines, technologies and business domains. This document distinguishes the architecture of an entity of interest from an AD expressing that architecture. Architectures are not the subject of this document. This document specifies requirements for use of the architectural concepts and their relationships as captured in an AD. It does not specify requirements for any entity of interest or its environment. This document specifies requirements for an architecture description framework (ADF), an architecture description language (ADL), architecture viewpoints and model kinds in order to usefully support the development and use of an AD. This document specifies conformance to the requirements for an AD, ADF, ADL, architecture viewpoint and model kind. This document does not specify the processes, architecting methods, models, notations, techniques or tools by which an AD is created, utilized or managed. This document does not specify any format or media for recording an AD.

  • Standard
    62 pages
    English language
    sale 15% off
ISO
ISO/IEC/IEEE 32675:2022(Main)
Information technology — DevOps — Building reliable and secure systems including application build, package and deployment

This document provides requirements and guidance on the implementation of DevOps to define, control, and improve software life cycle processes. It applies within an organization or a project to build, package, and deploy software and systems in a secure and reliable way. This document specifies practices to collaborate and communicate effectively in groups including development, operations, and other key stakeholders. This document applies a common framework for software life cycle processes, with well-defined terminology. It contains processes, activities, and tasks that are to be applied to the full life cycle of software systems, products, and services, including conception, development, production, utilization, support, and retirement. It also applies to the acquisition and supply of software systems, whether performed internally or externally to an organization. These life cycle processes are accomplished through the involvement of stakeholders, with the ultimate goal of achieving customer satisfaction. The life cycle processes of this document can be applied concurrently, iteratively, and recursively to a software system and incrementally to its elements. This document applies to software systems, products, and services, and the software portion of any system. Software includes the software portion of firmware. Those aspects of system definition needed to provide the context for software systems, products, and services are included. There is a wide variety of software systems in terms of their purpose, domain of application, complexity, size, novelty, adaptability, quantities, locations, life spans, and evolution. This document describes the processes that comprise the life cycle of software systems. It therefore applies to one-of-a-kind software systems, software systems for wide commercial or public distribution, and customized, adaptable software systems. It also applies to a complete stand-alone software system and to software systems that are embedded and integrated into larger, more complex, and complete systems.

  • Standard
    81 pages
    English language
    sale 15% off
  • Draft
    81 pages
    English language
    sale 15% off
ISO
ISO/IEC TS 25052-1:2022(Main)
Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE): cloud services — Part 1: Quality model

This document defines the quality model of cloud services. The quality model of cloud services is composed of nine characteristics (some of which are further subdivided into subcharacteristics), which provide consistent terminology for specifying, measuring and evaluating cloud services so that the stakeholders, cloud service customer (CSC), cloud service provider (CSP) and cloud service partner (CSN) have a common understanding. Since the quality model in this document is the extension to the existing quality models defined in ISO/IEC 2501n, it can be used with the product quality model, IT service quality model, data quality model, and quality-in-use model according to evaluation purposes. As there are several cloud service categories, this document focuses on the quality model of SaaS (Software as a Service). NOTE Future documents are intended to address PaaS (Platform as a Service) and IaaS (Infrastructure as a Service).

  • Technical specification
    15 pages
    English language
    sale 15% off
  • Draft
    15 pages
    English language
    sale 15% off
  • Draft
    15 pages
    English language
    sale 15% off
SIST
SIST-TP CEN/TR 17603-40:2022(Main)
Space engineering - Software engineering handbook
CEN/TR 17603-40:2022

This Handbook provides advice, interpretations, elaborations and software engineering best practices for the implementation of the requirements specified in EN 16603-40 (based on ECSS-E-ST-40C). The handbook is intended to be applicable to both flight and ground. It has been produced to complement the EN 16603-40 Standard, in the area where space project experience has reported issues related to the applicability, the interpretation or the feasibility of the Standard. It should be read to clarify the spirit of the Standard, the intention of the authors or the industrial best practices when applying the Standard to a space project.
The Handbook is not a software engineering book addressing the technical description and respective merits of software engineering methods and tools.

  • Standard
    198 pages
    English language
    sale 10% off
    e-Library read for
    1 day
SIST
SIST-TP CEN/TR 17603-40-01:2022(Main)
Space engineering - Agile software development handbook
CEN/TR 17603-40-01:2022

This Handbook provides recommendations for the implementation of an Agile approach in space software projects complying with EN 16603-40 (based on ECSS-E-ST-40) and EN 16602-80 (based on ECSS-Q-ST-80).
This handbook is not an Agile development book, though it provides an Agile reference model based on Scrum and also covers other major Agile methods and techniques. Scrum has been selected as reference because of its widespread application in industry and its flexibility as a development framework to introduce or merge with other Agile methods and techniques. In relation to the EN 16603-40 and EN 16602-80, this handbook does not provide any tailoring of their requirements due to the use of the Agile approach, but demonstrates how compliance towards ECSS can be achieved. This handbook does not cover contractual aspects for this particular engineering approach, although it recognises that considering the approach of fixing cost and schedule and making the scope of functionalities variable, the customer and supplier need to establish specific contractual arrangements. Furthermore, it does not impose a particular finality for the use of Agile, either as a set of team values, project management process, specific techniques or supporting exploration by prototypes.

  • Technical report
    105 pages
    English language
    sale 10% off
    e-Library read for
    1 day
CEN
CEN/TR 17603-40:2022(Main)
Space engineering - Software engineering handbook
SIST-TP CEN/TR 17603-40:2022

This Handbook provides advice, interpretations, elaborations and software engineering best practices for the implementation of the requirements specified in EN 16603-40 (based on ECSS-E-ST-40C). The handbook is intended to be applicable to both flight and ground. It has been produced to complement the EN 16603-40 Standard, in the area where space project experience has reported issues related to the applicability, the interpretation or the feasibility of the Standard. It should be read to clarify the spirit of the Standard, the intention of the authors or the industrial best practices when applying the Standard to a space project.
The Handbook is not a software engineering book addressing the technical description and respective merits of software engineering methods and tools.

  • Standard
    198 pages
    English language
    sale 10% off
    e-Library read for
    1 day
CEN
CEN/TR 17603-40-01:2022(Main)
Space engineering - Agile software development handbook
SIST-TP CEN/TR 17603-40-01:2022

This Handbook provides recommendations for the implementation of an Agile approach in space software projects complying with EN 16603-40 (based on ECSS-E-ST-40) and EN 16602-80 (based on ECSS-Q-ST-80).
This handbook is not an Agile development book, though it provides an Agile reference model based on Scrum and also covers other major Agile methods and techniques. Scrum has been selected as reference because of its widespread application in industry and its flexibility as a development framework to introduce or merge with other Agile methods and techniques. In relation to the EN 16603-40 and EN 16602-80, this handbook does not provide any tailoring of their requirements due to the use of the Agile approach, but demonstrates how compliance towards ECSS can be achieved. This handbook does not cover contractual aspects for this particular engineering approach, although it recognises that considering the approach of fixing cost and schedule and making the scope of functionalities variable, the customer and supplier need to establish specific contractual arrangements. Furthermore, it does not impose a particular finality for the use of Agile, either as a set of team values, project management process, specific techniques or supporting exploration by prototypes.

  • Technical report
    105 pages
    English language
    sale 10% off
    e-Library read for
    1 day
ISO
ISO/IEC 29110-2-1:2015/Amd 1:2022(Amendment)
Software engineering — Lifecycle profiles for Very Small Entities (VSEs) — Part 2-1: Framework and taxonomy — Amendment 1: Update of references and editorial improvements
  • Standard
    2 pages
    English language
    sale 15% off
ISO
ISO/IEC/IEEE 29119-1:2022(Main)
Software and systems engineering — Software testing — Part 1: General concepts

This document specifies general concepts in software testing and presents key concepts for the ISO/IEC/IEEE 29119 series.

  • Standard
    47 pages
    English language
    sale 15% off
  • Standard
    55 pages
    English language
    sale 15% off
  • Standard
    51 pages
    French language
    sale 15% off
ISO
ISO/IEC/IEEE 14764:2022(Main)
Software engineering — Software life cycle processes — Maintenance

This document provides guidance for the maintenance of software, based on the maintenance process and its activities and tasks defined in ISO/IEC/IEEE 12207:2017, 6.4.13. Moreover, this document describes the maintenance process in greater detail and establishes definitions for the various types of maintenance. This includes maintenance for multiple software products with the same maintenance resources. “Maintenance” in this document means software maintenance unless otherwise stated. The document does not address the operation of software and the operational functions, e.g. backup, recovery, system administration, which are normally performed by those who operate the software. However, it does include the related disposal process defined in ISO/IEC/IEEE 12207:2017, 6.4.14. This document is written primarily for managers, maintenance organizations, quality managers, users and acquirers of systems containing software. Many of the activities and tasks discussed in this document apply equally to maintenance services, as well as to maintained software products. For example, in a COTS intensive system, maintenance services are performed to sustain the product in operations. While the scope of this document is software maintenance, hardware and hardware costs are important considerations for maintenance.

  • Standard
    36 pages
    English language
    sale 15% off
  • Draft
    36 pages
    English language
    sale 15% off
ISO
ISO/IEC/IEEE 26514:2022(Main)
Systems and software engineering — Design and development of information for users

This document covers the development process for designers and developers of information for users of software. It describes how to establish what information users need, how to determine the way in which that information should be presented, and how to prepare the information and make it available. It is not limited to the design and development stage of the life cycle, but includes information on design throughout the life cycle, such as design strategy and maintaining a design. This document provides requirements for the structure, information content, and format of information for users of software. This document can be applied to developing the following types of information, although it does not cover all aspects of them: — information for users of products other than software; — multimedia systems using animation, video, and sound; — computer-based training (CBT) packages and specialized course materials intended primarily for use in formal training programs; — maintenance information describing the internal operation of systems software; — information for users incorporated into the user interface itself. This document is applicable to information architects and information developers, including a variety of specialists: — information architects who plan the structure and format of information products; — usability specialists and business analysts who identify the tasks that the intended users can perform with the software; — developers and editors of the written content of information for users; — graphic designers with expertise in electronic media; — user interface designers and ergonomics experts working together to design the presentation of the information on the screen. This document is also a reference for those with other roles and interests in the process of developing information for users: — managers of the software development process or the information-development process; — acquirers of information for users prepared by suppliers; — usability testers, reviewers of information for users, subject-matter experts; — developers of tools for creating information for users; — human-factors experts who identify principles for making information for users more accessible and easily used.

  • Standard
    64 pages
    English language
    sale 15% off
  • Draft
    67 pages
    English language
    sale 15% off
ISO
IEC 81001-5-1:2021(Main)
Health software and health IT systems safety, effectiveness and security — Part 5-1: Security — Activities in the product life cycle

This document defines the LIFE CYCLE requirements for development and maintenance of HEALTH SOFTWARE needed to support conformance to IEC 62443-4-1 – taking the specific needs for HEALTH SOFTWARE into account. The set of PROCESSES, ACTIVITIES, and TASKS described in this document establishes a common framework for secure HEALTH SOFTWARE LIFE CYCLE PROCESSES. The purpose is to increase the CYBERSECURITY of HEALTH SOFTWARE by establishing certain ACTIVITIES and TASKS in the HEALTH SOFTWARE LIFE CYCLE PROCESSES and also by increasing the SECURITY of SOFTWARE LIFE CYCLE PROCESSES themselves. It is important to maintain an appropriate balance of the key properties SAFETY, effectiveness and SECURITY as discussed in ISO 81001-1. This document excludes specification of ACCOMPANYING DOCUMENTATION contents.

  • Draft
    52 pages
    English language
    sale 15% off
ISO
ISO/IEC 15909-3:2021(Main)
Systems and software engineering — High-level Petri nets — Part 3: Extensions and structuring mechanisms

This document defines enrichments, extensions and structuring mechanisms of Petri nets, applied on the definitions proposed in ISO/IEC 15909-1. This document facilitates the definitions of new kinds of Petri nets and their interoperability, while remaining compatible with those defined in ISO/IEC 15909-1. This document is written as a reference for designers of new Petri net variants, by defining common enrichments, extensions and structuring mechanisms, as well as a generalized process for defining new ones. This document is applicable to a wide variety of concurrent discrete event systems and in particular distributed systems. Generic fields of application include: — requirements analysis; — development of specifications, designs and test suites; — descriptions of existing systems prior to re-engineering; — modelling business and software processes; — providing the semantics for concurrent languages; — simulation of systems to increase confidence; — formal analysis of the behaviour of systems; — and development of Petri net support tools. This document can be applied to the design of a broad range of systems and processes, including aerospace, air traffic control, avionics, banking, biological and chemical processes, business processes, communication protocols, computer hardware architectures, control systems, databases, defence command and control systems, distributed computing, electronic commerce, fault-tolerant systems, games, hospital procedures, information systems, Internet protocols and applications, legal processes, logistics, manufacturing systems, metabolic processes, music, nuclear power systems, operating systems, transport systems (including railway control), security systems, telecommunications and workflow.

  • Standard
    15 pages
    English language
    sale 15% off
ISO
ISO/IEC/IEEE 29119-2:2021(Main)
Software and systems engineering — Software testing — Part 2: Test processes

This document specifies test processes that can be used to govern, manage and implement software testing for any organization, project or testing activity. It comprises generic test process descriptions that define the software testing processes. Supporting informative diagrams describing the processes are also provided. This document is applicable to testing in all software development lifecycle models. This document is intended for, but not limited to, testers, test managers, developers and project managers, particularly those responsible for governing, managing and implementing software testing.

  • Standard
    54 pages
    English language
    sale 15% off
  • Draft
    54 pages
    English language
    sale 15% off
ISO
ISO/IEC/IEEE 29119-4:2021(Main)
Software and systems engineering — Software testing — Part 4: Test techniques

This document defines test design techniques that can be used during the test design and implementation process that is defined in ISO/IEC/IEEE 29119‑2. Each technique follows the test design and implementation process that is defined in ISO/IEC/IEEE 29119‑2 and shown in Figure 1. This document is intended for, but not limited to, testers, test managers, and developers, particularly those responsible for managing and implementing software testing.

  • Standard
    135 pages
    English language
    sale 15% off
  • Draft
    136 pages
    English language
    sale 15% off
ISO
ISO/IEC/IEEE 29119-3:2021(Main)
Software and systems engineering — Software testing — Part 3: Test documentation

This document specifies software test documentation templates that can be used for any organization, project or testing activity. It describes the test documentation that is an output of the processes specified in ISO/IEC/IEEE 29119-2. This document is applicable to testing in all software development lifecycle models. This document is intended for, but not limited to, testers, test managers, developers, and project managers, particularly those responsible for governing, managing, and implementing software testing.

  • Standard
    84 pages
    English language
    sale 15% off
  • Draft
    84 pages
    English language
    sale 15% off
ISO
ISO/IEC TR 24587:2021(Main)
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).

  • Technical report
    19 pages
    English language
    sale 15% off
  • Draft
    19 pages
    English language
    sale 15% off
SIST
SIST-TP CEN/CLC/TR 17602-80-03:2021(Main)
Space product assurance - Software dependability and safety
CEN/CLC/TR 17602-80-03:2021

This Handbook provides guidance on the application of the dependability and safety requirements relevant to software defined in EN 16602-80 (equivalent of ECSS-Q-ST-80).
This Handbook provides support for the selection and application of software dependability and safety methods and techniques that can be used in the development of software-intensive space systems.
This Handbook covers all of the different kinds of software for which EN 16602-80 (equivalent of ECSS-Q-ST-80) is applicable. Although the overall software dependability and safety workflow description is mainly targeted to the development of spacecraft, the described approach can be adapted to projects of different nature (e.g. launchers, ground systems).
The methods and techniques described in the scope of this Handbook are limited to assessment aspects, not including development and implementation techniques for dependability and safety (e.g. fault tolerance techniques, or development methods like coding standards, etc.).
Although dependability is a composite term, including reliability, availability and maintainability, this Handbook addresses in particular the reliability aspects. Software maintainability and availability are not covered in depth by this handbook, because the relevant methods and techniques are still undergoing improvement. Nevertheless, whenever a link can be made to either of these two characteristics, it is explicitly mentioned in the corresponding section.

  • Technical report
    43 pages
    English language
    sale 10% off
    e-Library read for
    1 day
  • Draft
    43 pages
    English language
    sale 10% off
    e-Library read for
    1 day
SIST
SIST-TP CEN/CLC/TR 17602-80-04:2021(Main)
Space product assurance - Software metrication programme definition and implementation
CEN/CLC/TR 17602-80-04:2021

The scope of this Handbook is the software metrication as part of a space project, i.e. a space system, a subsystem including hardware and software, or ultimately a software product. It is intended to complement the EN 16602-80 (equivalent to ECSS-Q-ST-80) with specific guidelines related to use of different software metrics including their collection, analysis and reporting. Tailoring guidelines for the software metrication process are also provided to help to meet specific project requirements.
This Handbook provides recommendations, methods and procedures that can be used for the selection and application of appropriate metrics, but it does not include new requirements w ith respect to those provided by EN 16602-80 (equivalent to ECSS-ST-Q-80).
The scope of this Handbook covers the following topics:
• Specification of the goals and objectives for a metrication programme.
• Identification of criteria for selection of metrics in a specific project / environment (goal driven).
• Planning of metrication in the development life cycle.
• Interface of metrication with engineering processes.
• Data collection aspects (including use of tools).
• Approach to the analysis of the collected data.
• Feedback into the process and product based on the analysis results.
• Continuous improvement of measurement process.
• Use of metrics for process and product improvement.
This Handbook is applicable to all types of software of all major parts of a space system, including the space segment, the launch service segment and the ground segment software.

  • Technical report
    100 pages
    English language
    sale 10% off
    e-Library read for
    1 day
  • Draft
    100 pages
    English language
    sale 10% off
    e-Library read for
    1 day
SIST
SIST-TP CEN/CLC/TR 17602-80-11:2021(Main)
Space product assurance - Software process assessment and improvement - Part 1: Framework
CEN/CLC/TR 17602-80-11:2021

This handbook defines methods for process assessment and improvement that may be used to meet the requirements on
process assessment and improvement of the EN16602-80 (equivalent to ECSS-Q-ST-80C) subclause 5.7. These methods constitute a clear and proven w ay of implementing those requirements. Alternative methods can be used provided that they meet the detailed instructions provided in this handbook for recognition of software process assessment schemes and results and process improvement.
This handbook provides a detailed method for the implementation of the requirements of the EN16602-80 for software process assessment and improvement. It also establishes detailed instructions for alternative methods intended to meet the same EN16602-80 requirements.
The process assessment and improvement scheme presented in this handbook is based on and conformant to the ISO/IEC 15504 International Standard. In designing this process assessment and improvement scheme the ISO/IEC 15504 exemplar process assessment model w as adopted and extended to address specific requirements.
The methods provided in this handbook can support organizations in meeting their business goals and in this context they can be tailored to suit their specific needs and requirements. How ever w hen used to claim compliance with relevant requirements in EN16602-80 only the steps and activities explicitly marked as recommended in this handbook may be omitted or modified.

  • Technical report
    122 pages
    English language
    sale 10% off
    e-Library read for
    1 day
  • Draft
    122 pages
    English language
    sale 10% off
    e-Library read for
    1 day
SIST
SIST-TP CEN/CLC/TR 17602-80-01:2021(Main)
Space product assurance - Reuse of existing software
CEN/CLC/TR 17602-80-01:2021

This handbook provides recommendations, methods and procedures that can be used for the selection and reuse of existing software in space software systems.
This handbook is applicable to all types of software of a space system, including the space segment, the launch service segment and the ground segment software (including EGSEs) whenever existing software is intended to be reused within them.
This handbook covers the following topics:
• Software reuse approach including guidelines to build the Software Reuse File
• Techniques to support completion of existing software qualification to allow its reuse in a particular project
• Tool qualification
• Risk management aspects of reusing existing software Existing software can be of any type: Purchased (or COTS), Legacy-Software, open-source software, customer-furnished items (CFI's), etc.
NOTE Special emphasis is put on guidance for the reuse of COTS software often available as-is and for which no code and documentation are often available.
Legal and contractual aspects of reuse are in principle out of scope; how ever guidelines to help in determine the
reusability of existing software from a contractual point of view is provided in [ESA/REG/002].
Any organization with the business objective of systematic reuse may need to implement the organizational reuse processes presented in [ISO12207]. These processes w ill support the identification of reusable software products and components within selected reuse domains, their classification, storage and systematic reuse within the projects of that organization, etc. But these processes are out of scope of this handbook as the handbook is centred on the specific project activities to reuse an existing software product, not part of those organizational reuse processes more oriented to ‘design for reuse’ processes.
In addition, this handbook provides guidelines to be used for the selection and analysis of tools for the development, verification and validation of the operational software.

  • Technical report
    58 pages
    English language
    sale 10% off
    e-Library read for
    1 day
  • Draft
    58 pages
    English language
    sale 10% off
    e-Library read for
    1 day
SIST
SIST-TP CEN/CLC/TR 17602-80-12:2021(Main)
Space product assurance - Software process assessment and improvement - Part 2: Assessor instrument
CEN/CLC/TR 17602-80-12:2021

This handbook provides assessors with a number of instruments needed to perform software process capability assessments using the assessment method described in EN 17603-80-11 (equivalent to ECSS-Q-HB-80-02 Part 1). It also provides instruments that help assessors to carry out their activities when performing assessments and supporting the implementation of software process improvement initiatives using the method for process improvement described in Part 1.
The instruments provided are:
• The Process Assessment Model (PAM) required to perform assessments including process descriptions and process attribute indicators
• Conformance statement to the requirements in ISO/IEC 15504 Part 2
• A definition of the Process Reference Model (PRM) on which TR 17603-80-11 and TR 17603-80-12 (equivalent to ECSS-Q-HB-80-02 Part 1 and 2) PAM are based (defined in TR 17603-80-11)
• Detailed traces from base practices in the PAM to standard clauses and from work products to expected outputs.

  • Technical report
    129 pages
    English language
    sale 10% off
    e-Library read for
    1 day
  • Draft
    129 pages
    English language
    sale 10% off
    e-Library read for
    1 day
ISO
ISO/IEC/IEEE 32430:2021(Main)
Software engineering — Trial use standard for software non-functional sizing measurements

This document defines a method for the sizing of non-functional software requirements. It complements ISO/ IEC 20926:2009, which defines a method for the sizing of functional user requirements (FUR).1 This document also describes the complementarity of functional and non-functional sizes, so that sizing both functional and non-functional requirements (NFR) do not overlap. It also describes how non-functional size, together with functional size, should be used for measuring the performance of software projects, setting benchmarks, and estimating the cost and duration of software projects. In general, there are many types of non-functional software requirements. Moreover, non-functional aspects evolve over time and may include additional aspects in the as technology advances. This standard does not intend to define the type of NFR for a given context. Users may choose ISO 25010:2011 or any other standard for the definition of NFR. It is assumed that users will size the NFR based on the definitions they use. This document covers a subset of non-functional types. It is expected that, with time, the state of the art can improve and that potential future versions of this standard can define an extended coverage. The ultimate goal is a version that, together with ISO/IEC 20926:2009, covers every aspect that may be required of any prospective piece of software, including aspects such as process and project directives that are hard or impossible to trace to the software's algorithm or data. The combination of functional and non-functional size would then correspond to the total size necessary to bring the software into existence. Calculating the effort and duration of the implementation of the NFR is outside the scope of this standard.

  • Standard
    76 pages
    English language
    sale 15% off
  • Draft
    76 pages
    English language
    sale 15% off
ISO
ISO/IEC 23360-3-3:2021(Main)
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.

  • Standard
    493 pages
    English language
    sale 15% off
  • Draft
    493 pages
    English language
    sale 15% off
ISO
ISO/IEC 23360-8-3:2021(Main)
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.

  • Standard
    493 pages
    English language
    sale 15% off
  • Draft
    493 pages
    English language
    sale 15% off
ISO
ISO/IEC 23360-5-3:2021(Main)
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.

  • Standard
    493 pages
    English language
    sale 15% off
  • Draft
    493 pages
    English language
    sale 15% off
ISO
ISO/IEC 23360-3-2:2021(Main)
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.

  • Standard
    237 pages
    English language
    sale 15% off
  • Draft
    237 pages
    English language
    sale 15% off
ISO
ISO/IEC 23360-6-3:2021(Main)
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.

  • Standard
    493 pages
    English language
    sale 15% off
  • Draft
    493 pages
    English language
    sale 15% off
ISO
ISO/IEC 23360-4-3:2021(Main)
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.

  • Standard
    493 pages
    English language
    sale 15% off
  • Draft
    493 pages
    English language
    sale 15% off
ISO
ISO/IEC 23360-1-4:2021(Main)
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.

  • Standard
    186 pages
    English language
    sale 15% off
  • Draft
    186 pages
    English language
    sale 15% off
ISO
ISO/IEC 23360-2-2:2021(Main)
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.

  • Standard
    231 pages
    English language
    sale 15% off
  • Draft
    231 pages
    English language
    sale 15% off
ISO
ISO/IEC 23360-6-2:2021(Main)
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.

  • Standard
    252 pages
    English language
    sale 15% off
  • Draft
    252 pages
    English language
    sale 15% off
ISO
ISO/IEC 23360-4-2:2021(Main)
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.

  • Standard
    230 pages
    English language
    sale 15% off
  • Draft
    230 pages
    English language
    sale 15% off
ISO
ISO/IEC 23360-8-2:2021(Main)
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.

  • Standard
    250 pages
    English language
    sale 15% off
  • Draft
    250 pages
    English language
    sale 15% off
ISO
ISO/IEC 23360-1-1:2021(Main)
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.

  • Standard
    12 pages
    English language
    sale 15% off
  • Draft
    12 pages
    English language
    sale 15% off
50