Difference between revisions of "IEEE 1471"
Jump to navigation
Jump to search
Dr Scofield (talk | contribs) (+ created IEEE 1471 page, refactored from glossary page) |
(Fixed link that was broken by acm.org) |
||
| (4 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
Common understanding is achieved by discussing common mental models using a common language. In systems architecture, IEEE-1471 helps us approach that goal: | Common understanding is achieved by discussing common mental models using a common language. In systems architecture, IEEE-1471 helps us approach that goal: | ||
:* [http://www.iso-architecture.org/ieee-1471/ ANSI/IEEE 1471-2000, Recommended Practice for Architecture Description of Software-Intensive Systems] | :* [http://www.iso-architecture.org/ieee-1471/ ANSI/IEEE 1471-2000, Recommended Practice for Architecture Description of Software-Intensive Systems] | ||
:* [http://en.wikipedia.org/wiki/IEEE_1471 Wikipedia:IEEE-1471] | :* [http://en.wikipedia.org/wiki/IEEE_1471 Wikipedia:IEEE-1471] | ||
:* [http://www.enterprise-architecture.info/Images/Documents/IEEE%201471-2000.pdf IEEE-1471 presentation slides] | :* [http://www.enterprise-architecture.info/Images/Documents/IEEE%201471-2000.pdf IEEE-1471 presentation slides] | ||
:* [http:// | :* [http://www.sigada.org/conf/sigada2000/private/SIGAda2000-CDROM/SIGAda2000-Proceedings/Emery-Architecture-Presentation.pdf?searchterm=Describing+Architectures Describing Architectures, D.Emery] | ||
IEEE-1471 looks slightly heavyweight at first glance, but it isn't in practice because it isn't a straightjacket. Its main benefit is in helping designers of system architecture to embrace the idea that interested parties ('''stakeholders''') each have their own concerns ('''viewpoints''') which need to be described in appropriate architectural '''views'''. | IEEE-1471 looks slightly heavyweight at first glance, but it isn't in practice because it isn't a straightjacket. Its main benefit is in helping designers of system architecture to embrace the idea that interested parties ('''stakeholders''') each have their own concerns ('''viewpoints''') which need to be described in appropriate architectural '''views'''. | ||
| Line 12: | Line 9: | ||
An architecture itself is just an abstraction, and it is through the multiple views that this abstraction reveals how it solves the numerous (and frequently orthogonal) requirements. One view definitely doesn't fit all. (See [[Talk:Components_and_Roles|Talk]] for more.) | An architecture itself is just an abstraction, and it is through the multiple views that this abstraction reveals how it solves the numerous (and frequently orthogonal) requirements. One view definitely doesn't fit all. (See [[Talk:Components_and_Roles|Talk]] for more.) | ||
[[Category:AW Groupies]] | [[Category: AW Groupies]] | ||
Latest revision as of 02:51, 12 August 2009
Common understanding is achieved by discussing common mental models using a common language. In systems architecture, IEEE-1471 helps us approach that goal:
IEEE-1471 looks slightly heavyweight at first glance, but it isn't in practice because it isn't a straightjacket. Its main benefit is in helping designers of system architecture to embrace the idea that interested parties (stakeholders) each have their own concerns (viewpoints) which need to be described in appropriate architectural views.
An architecture itself is just an abstraction, and it is through the multiple views that this abstraction reveals how it solves the numerous (and frequently orthogonal) requirements. One view definitely doesn't fit all. (See Talk for more.)