Управление информацией в системной инженерии: уровни описания
Уровни описания управления информацией в системной инженерии:
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. На основе опыта разработки конкретной архитектуры сделать апдейт Симултрека.
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. На основе опыта разработки конкретной архитектуры сделать апдейт Симултрека.