Site

RW - Navigation

RW - Recent

Last 10 entries [comments]:

Forums

Last 10 posts [threads/views]:

Wiki

Last 10 pages updated:

There are 484 wiki pages in total.



RSS logoRSS Feed
 

The Residual World::Tag = 'Iso'

Entries that have been tagged with 'Iso'.-

ISO/IEC/IEEE 42010:2011, Systems and software engineering—Architecture Description Released

by Nic Plum on Friday 11 November, 2011 - 11:45 GMT

Posted in NewsStandards

Tags: ieeeisoiso42010newsstandard

International Standards Organisation logo

Just received news from Rich Hilliard via the IEEE 1471 Users List (to become the “ISO/IEC/IEEE 42010 Users List):

Today I was notified that IEEE P42010 was approved as a revised standard by the IEEE-SA Standards Board on 31 October 2011.

This standard replaces IEEE 1471:2000 and is identical to the ISO standard approved in July with 21 approvals and 0 disapprovals from member bodies.

The new standard, designated ISO/IEC/IEEE 42010:2011, Systems and software engineering—Architecture description, is available from IEEE and ISO.

The IEEE 1471 website will become the ISO/IEC/IEEE 42010 website.

The old website will redirect to the new URL which is:

Looking at the website I noticed

Per IEEE rules: An approved IEEE standard will remain active for   ten years. If the Sponsor does not complete a revision process   within ten years, the standard will be transferred to inactive   status.

Curious to know whether this means a standard has to be revised or whether the requirement is simply to review - it might still be a perfectly good standard even if it hasn’t been revised since the decision might be on review that it’s good enough.

Having to say ISO/IEC/IEEE every time is a bit of a mouthfull and therefore inevitably will be shortened in everyday use. Is there an acceptable shortform(s) e.g. ISO 42010, IEC 42010 and IEEE 42010? It’s unlikely in speech that the full qualification will be used.

Comments

Comment on this article

Related Articles

    Sharing tags:

    External Links

    Conformance Assessment vs ISO/IEC 42010:2011

    by Nic Plum on Thursday 22 September, 2011 - 12:59 GMT

    Posted in Architecture FrameworkTRAKNewsStandards

    Tags: complianceconformanceieeeisoiso42010standardtrak

    Logo of The International Standards Organisation

    It’s very hard when everyone seems to be claiming conformance with ISO/IEC 42010 to establish whether the claims are true. All too often we get ‘partly compliant with ’ which means what exactly? As a standard trying to get standardisation in the field of architecture description and trying to eliminate the variability and anarchy it isn’t much use to be partly compliant (any more than claiming to be partly pregnant). You either do or don’t conform. The hard work put in by those that try to conform to the standard is undermined by those that claim conformance but don’t actually conform.

    I’m pleased to be able to say that TRAK has agreed to take part in a pilot against an official ‘conformance assessment instrument’ prototype that is being developed against ISO/IEC 42010:2011 which is soon to be jointly published by both the IEEE and ISO. The conformance instrument applies to Architecture Frameworks, Architecture Description Languages and Architecture Descriptions.

    As ever I’m sure the assessment and feedback will benefit both sides in refining and sharpening up the documentation. These are early days and no doubt some ideas still need to be worked through, hence the pilot using the prototype conformance instrument.

    I’m quietly confident with respect to TRAK itself (time will tell!) but more importantly it will be useful to have an independent assessment of any claim to conformity whereas the current situation allows any Tom, Dick or Harry to claim conformity with impunity and where no sanctions can be applied. I look forwards to this situation being changed.

    Comments

    Comment on this article

    Related Articles

      Sharing tags:

      External Links

      How ISO/IEC 42010 Controls Architectural Description

      by Maestoso on Sunday 31 January, 2010 - 10:56 GMT

      Posted in Architecture FrameworkStandards

      Tags: architecture descriptionconceptconsistencyexchangeieee1471isoiso42010modelrulestandard

      ANSI/IEEE Std 1471 :: ISO/IEC 42010 - Recommended Practice for Architectural Description of Software-Intensive Systems

      ISO/IEC42010:2007 states that ‘most architects must work within an architecture framework’ where this is defined as ‘a predefined set of concerns, stakeholders, viewpoints and viewpoint correspondence rules; established to capture common practice for architecture descriptions within specific domains or user communities’.

      It controls architectural modelling at a high level by requiring architecture viewpoints that specify what concerns a particular view answers and what content a view must contain. It does not specify how the modelling is done or what presentation language must be used, for example UML, SysML, BPMN.

      image

      ISO/IEC 42010:2007 Conceptual Framework for Architecture Description

      UPDATE. The re-issue of the standard as ISO/IEC/IEEE 42010:2011 changes the underlying conceptual metamodel in the standard. This is shown on ISO/IEC/IEEE 42010 website.

      IEEE 1471 does not specify any particular one because it states that these are specific to the needs of a particular domain and there is not, as yet, any consensus on generic architecture frameworks. 

      In ISO 42010:2007 it specifies that an analysis be undertaken of the consistencies across the architectural views and any known inconsistencies be identified. Where does this consistency arise from, however, and what is the scope? It is perfectly possible for an architecture description comprising a set of models to be self-consistent. The problem is that another architect can choose to model using different object types and whilst again consistent the 2 architects will have produced 2 architecture descriptions that can’t easily be exchanged or re-used.


      IEEE 1471 is evolving and not only has the name changed to better reflect the application of architecture modelling - ‘Systems and Software Engineering - Architecture Description’ [draft 7, 25th January 2010]. It also has more on architecture frameworks and states that

      Correspondences and correspondence rules as specified in 5.7.2 and 5.7.3 may be used to express, record, enforce and analyze consistency between models, views and other AD elements.

      IEEE 1471 is definitely heading in the right direction and provides useful principles and rules. Simply making a reference to IEEE 1471, however, is not sufficient in order to control architectural modelling to the level needed to be able to maximise the likelihood of success for the exchange of architecture descriptions (or models). Correspondence rules are necessary but there are potential problems with sets of text-based rules (this affects any requirement collection). A metamodel defines that only the allowed element types and relationships that can be used in a model or architecture description. In essence it provides the architect with a mandated language of nouns (element types) and verbs (relationships) to describe the system of interest. It is also visual and a very concise form of specification. There will always be the need for additional rules to specify consistency between views for the system of interest but having a metamodel is essential to a consistent set of building blocks from which to construct the views.

      I’d argue strongly that having a declared metamodel is fundamental to defining an architecture framework and that without one you can’t hope to control consistency of modelling or meaning (semantics). excaim

      Even with a well-defined and controlled architecture framework there will be problems in exchanging architecture descriptions (and models) since modelling is a creative art providing many ways of modelling a particular thing and we have local or personal modelling styles. If we don’t share or have good access to a central set of definitions which includes elements and probably agreed boundaries (i.e. agreed understanding of the system breakdown structure) it is likely that elements will have different semantics.

      IEEE 1471 is a good start and an architecture framework with a metamodel helps, but there is a lot more to put in place to be able to successfully exchange and collaboratively develop architecture descriptions (and models).

      Comments

      Comment on this article

      Related Articles

        {REL[6165][related1_blog]d4uriDksREL}

        Sharing tags:

        External Links

        1.2.004 adl admin advice applescript application architecture architecture description architecture description language architecture framework artefact artisan studio award berlow blog boundary browser bug c3 capability capability configuration colaboration collaboration committee compare compliance concept concert conference configuration control conformance consistency content contrast css cv01 def stan defence definition demonstration denmark department for transport develop discovery dndaf document dod dodaf drawing enterprise enterprise architect ertms event evolve exchange exploit forum fun geneology gfdl gnu graph group handbook hazard head-model history humour ibm rhapsody iec ieee ieee1471 iet ietf implement implementation incose innovation institute integrated ea interoperability introduction ipad iso iso42010 isse keynote knowledge language linkedin lockheed martin london london underground m3 mac management mdg meaning meeting metamodel mil std modaf model modelling style naf nato natural language needline news nist no magic magicdraw noun omg omnigraffle ontology open source opensource operational organisation oxfordshire perspective plan platform playlist portability presentation procurement profile project public publication publish purpose rail relationship release repository research resource rfc4677 risk role rssb rule safety sea search security sentence service singapore site softeam modelio software solution song sos sourceforge sparx systems sparx systems enterprise architect specification spreadsheet stakeholder concern standard steering group stencil stereotype store strategy structure support sysml system system authority system of systems systems engineering team template test threat
         

        All articles/posts © of the respective authors

        Site design and architecture © 2010 - 2011 Eclectica Systems Ltd.