ISO 42010

Uit NORA Online
Naar navigatie springen Naar zoeken springen
Onderdeel van
Lijsten & Verwijzingen
Contact
NORA Beheer
nora@ictu.nl
Status
Naam
ISO 42010
ID

ISO/IEC/IEEE 42010:2022, NEN-ISO/IEC/IEEE 42010:2022

Type

Standaard

Publicatiedatum
2022-11-01
Versie
2022
Wijzigingsdatum


Richtlijnen voor het beschrijven van architectuur van systemen en software en de kaders voor die architecturen

De ISO 42010 geeft aan hoe je architectuurproducten kunt beschrijven en gaat daarbij uit van de volgende invalshoek(en):

Figuur 4- Architectuur-views van de NEN-ISO 42010

De ISO 42010 norm stelt geen eisen aan de vorm van de architectuurbeschrijving, anders dan de inhoud die het uiteindelijk moet gaan bevatten. De ISO 42010 gaat dus ook niet over verschillende tussenvormen van een architectuurbeschrijving in het proces van de totstandkoming ervan zoals bijvoorbeeld de PSA als start van een architectuurbeschrijving nog zonder oplossing (solution), maar wel met een oplossingsruimte (kader), die later uitgroeit tot een Solution Architectuur (SA) met de gekozen oplossing. Beide versies zijn architectuurbeschrijvingen die aan de ISO 42010 kunnen conformeren. De ISO 42010 gaat ook niet over hoe architectuurbeschrijvingen tot stand komen. Er wordt wel gehint dat formele methoden minder ambigue resultaten geven dan informele methoden.

De eisen die vanuit de ISO 42010:2022 worden gesteld aan de inhoud van een architectuurbeschrijving staan in Hoofdstuk 6 benoemd. Die inhoud mag verspreid zijn over hoofdstukken en onder andere titels en hoeft niet zozeer een bepaalde volgorde aan te houden (als het (digitale) document het maar bevat).
Wat bijvoorbeeld in een PSA moet zijn opgenomen, is in de NORA uitgewerkt, zie PSA-format
Zo'n uitwerking is nog niet opgenomen voor andere architecturen, zoals een Solution Architectuur (SA), Software Description Architectuur (SAD) of een Enterprise Architectuur (EA).

verschillen tussen de versies van 2011 en 2022

Bas Kaptijn (ICTU) heeft de versie uit 2022 vergeleken met de eerdere versie uit 2011. Daarbij zijn geen ingrijpende verschillen geconstateerd. In de ISO 42010:2022 worden de verschillen als volgt beschreven:

  1. The term used to refer to the subject of an architecture description is changed from “system of interest” (SoI) to “entity of interest” (EoI) to be compatible with ISO/IEC/IEEE 42020 and ISO/IEC/IEEE 42030 standards and to allow for its application in non-system architecture situations.
  2. The term “entity” is also used in this document when entities are considered as surrounding things in an environment of an EoI.
  3. The term “architecture description framework” (ADF) replaces “architecture framework” in the previous edition. It is defined in order to differentiate ADFs from other kinds of architecting frameworks like architecture evaluation frameworks specified in ISO/IEC/IEEE 42030.
  4. Architecture description element, introduced in the 2011 edition (see ISO/IEC/IEEE 42010:2011, 4.2.6, 5.7 and A.6) is now defined in Clause3 as identified or named part of an architecture description allowing representing at least stakeholders, concerns, perspectives, and aspects identified in an AD, and views, view components, viewpoints, and model kinds included in an AD.
  5. Aspect and stakeholder perspective concepts ―already introduced in the 2011 edition (See 3.5, note 1 of 5.6, Annex A and B) are defined and described to accommodate current practice where these ideas are prevalent.
  6. A correspondence defines an identified or named relation between AD elements, as in Clause 4.2.6 of the 2011 edition. But, to clarify the relationship between AD and correspondence, a note 1 to the definition is added to state that for the purpose of correspondences, an architecture description can be considered as an AD element in another architecture description. This correspondence between ADs is necessary because an architecture can be described by more than one AD and these alternatives of architectures have related for activities like trade-off analysis and decision making.
  7. The term “architecture view component” is introduced as a separable portion of one or more architecture views, replacing “architecture model” in the 2011 edition. This change is to account for the fact that some parts of a view are model-based while others may not be. View components can be derived from an information source, which can sometimes be a model.
  8. Model-based view components are governed by model kinds and documented by legends. Nonmodel-based view components are documented by legends.
  9. Model kinds are identified as a new conformance case to encourage model-based architecting.
  10. The concept of architecture viewpoint is updated to accommodate current practice where a viewpoint governs one or more architecture views within an AD.
  11. The definition of “model kind” given by the 2011 edition is extended to include categories of models as used by ADF like UAF.
  12. The figures use an informal entity-relationship diagram notation replacing UML class diagrams in the 2011 edition, to facilitate comprehension by users of this document. The multiplicities of the relationships are explained in the text when necessary.
  13. Annex E illustrates a few concepts pertaining to architecture life cycles and architecture description life cycles.
  14. Annex F shows examples of how some architecture description frameworks can conform to requirements of this document.



Waar toepasbaar

  • Functioneel toepassingsgebied:
  • Organisatorisch werkingsgebied:

Meer informatie

Als in wet- en regelgeving dwingend wordt verwezen naar Nationale normen (NEN normen), dan zijn deze normen vrij beschikbaar. Dit houdt in dat de normgebruiker niet voor de norm hoeft te betalen om deze te kunnen inzien. De ministeries betalen hiervoor jaarlijks een bedrag aan NEN, want het auteursrecht op de normen blijft bij NEN.
Zie verder NEN Connect: Vrij Beschikbare Normen