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

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