Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Управление информацией в системной инженерии: уровни описания

Уровни описания управления информацией в системной инженерии:

1. Стандарт архитектурного описания и архитектурного фреймворка -- ISO 42010 (проект на сентябрь 2007г. -- http://www.canieti.com.mx/assets/files/807/N3849%20NWIP%20Architecture%20Description.pdf, согласованный с ISO 15288 и, увы, с насквозь документоцентрическим ISO 15289. Как я понимаю, следующий драфт будет в июле -- они согласуются с GERAM http://www.cit.gu.edu.au/~bernus/taskforce/geram/versions/geram1-6-3/v1.6.3.html и RM-ODP http://en.wikipedia.org/wiki/RM-ODP).

Архитектура -- фундаментальная организация системы, заключенная в ее компонентах, их отношениях друг ко другу и окружению (environment), а также принципы ее дизайна и эволюции. Также: высокоуровневая концепция системы в ее окружении. В xAF дается другое определение: принципы самоограничения в дизайн-выборах.

2. Фреймворк корпоративной архитектуры системной инженерии (PraxOS Симултрек).
architecture framework -- a set of architectural concerns, generic stakeholders, predefined viewpoints, and viewpoint correspondence
rules, that have been established to capture a common practice for architectural descriptions in a specific domain or stakeholder community.

framework -- фреймворк (набор инструментальных средств и правил их применения)
stakeholder -- стейхолдер (лицо, как-то заинтересованное в системе).
concern -- интерес (интерес к разработческим, эксплуатационным, политическим, регуляторным, социальным и иным факторам, который проявляет один или более стейкхолдеров системы).
generic <класс> - абстрактный <класс> (выражение, указывающее на необходимость подстановки во время использования какого-то экземпляра класса (множества всех объектов)).
viewpoint -- вьюпойнт, соглашение по конструированию, интерпретации и использованию вью, адресующего предписанный набор интересов для набора стейкходлеров.
viewpoint correspondence rule -- правило согласования вьюпойнтов.
description -- описание (учтенное описание. Особо замечу, что я перевожу documented как "учтенное" -- совершенно необязательно, чтобы описание было именно в форме документа, я сознательно избавляюсь от документоориентированного языка).
domain -- предметная область.

Архитектурный фреймворк -- набор архитектурных интересов, типовых стейкхолдеров, предписанных вьюпойнтов и правил согласования вьюпойнтов, которые были определены для учёта общепринятой практики архитектурных описаний в конкретных предметных областях или сообществах стейкхолдеров.

3. Корпоративная архитектура конкретного Заведения (architecture, "эскизный проект").

4. Проект системы (design, to be).

5. Configuration management (as built и далее).
* * *
План работы:
1. Понять по-русски, о чем говорит ISO 42010 и сопутствующие ему стандарты, причем адаптировать понятое для датацентрики (см. http://ailev.livejournal.com/611877.html)
2. Разработать PraxOS Симултрек -- в письменном виде.
3. Предложить клиенту его корпоративную архитектуру (которая соответствует PraxOS Симултрек, и которая тем самым соответствует творчески понимаемым ISO).
4. На основе опыта разработки конкретной архитектуры сделать апдейт Симултрека.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 9 comments