Учебное пособие (курс лекций)

МИНИCTEPCTBO ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

Федеральное государственное автономное

образовательное учреждение высшего профессионального образования

«СЕВЕРО-КАВКАЗСКИЙ ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ»

 

УТВЕРЖДАЮ

Проректор по учебной работе
________________________

(подпись)

«___»_________________2015 г.

СИСТЕМНАЯ ИНЖЕНЕРИЯ

УЧЕБНОЕ ПОСОБИЕ (КУРС ЛЕКЦИЙ)

Направление подготовки: 09.04.02 «Информационные системы и технологии»

Магистерская программа: Управление данными

Квалификация выпускника: Магистр

Изучается в 1 и во 2 семестрах

Зав. кафедрой информационных систем и технологий __________________В. И. Дроздова «__» _____________ 2015 г.   Директор института информационных технологий и телекоммуникаций _________________Чипига А.Ф. «___»_________________2015     Рассмотрено УМК института информационных технологий и телекоммуникаций Протокол № «__» _____________ 2015 г.   Председатель УМК института ______________ И. П. Хвостова

Зав. кафедрой информационных систем и технологий __________________В. И. Дроздова «__» _____________ 2015 г.   Доцент кафедры информационных систем и технологий ___________________ Романенко М.Г. «__» ____________ 20____ г.

 

Ставрополь

МИНИCTEPCTBO ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

Федеральное государственное автономное

образовательное учреждение высшего профессионального образования

«СЕВЕРО-КАВКАЗСКИЙ ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ»

 

Дроздова В.И., Романенко М.Г.

УЧЕБНОЕ ПОСОБИЕ (КУРС ЛЕКЦИЙ)

«СИСТЕМНАЯ ИНЖЕНЕРИЯ»

Направление подготовки: 09.04.02 «Информационные системы и технологии»

Магистерская программа: Управление данными;

Квалификация выпускника: Магистр

 

Ставрополь

 

Печатается по решению

Учебно-методического совета

Северо-Кавказского федерального

университета

УДК

ББК

 

Рецензенты:

Линец Г.И. доктор технических наук, заведующий кафедрой инфокоммуникаций института информационных систем и телекоммуникаций Северо-Кавказского федерального университета

Панкратова О.П. кандидат педагогических наук, доцент кафедры информатики Северо-Кавказского федерального университета

 

Дроздова В.И.., Романенко М.Г. Системная инженерия: учебное пособие (курс лекций). – Ставрополь: Изд-во СКФУ, 2015. – 121 с.

 

 

Учебное пособие по дисциплине «Системная инженерия» составлено в соответствии с программой дисциплины для магистров вузов направления подготовки магистратуры 09.04.02 Информационные системы и технологии и содержит курс лекций.

Теоретический материал, представленный в учебном пособии, отражает основные понятия системной инженерии и жизненного цикла программного обеспечения, методологии, применяемые в системной инженерии, стандарты, используемые при создании программного обеспечения и реинжиниринг бизнес-процессов.

 

УДК

ББК

 

 

© ФГАОУ ВПО «Северо-Кавказский

федеральный университет», 2015

 

СОДЕРЖАНИЕ

РАЗДЕЛ 1. ОСНОВНЫЕ ПОНЯТИЯ СИСТЕМНОЙ ИНЖЕНЕРИИ

Тема 1. Основы системной инженерии

План лекции

1.1Определение системной инженерии.

1.2Проблемы современной инженерии

1.3Универсальность системной инженерии

 

Проблемы современной инженерии

Сложность современных проектов: до 10 млн. деталей (нефтяная платформа), проект существует до 100 лет;

До 1000 контракторов на один проект, у каждого контрактора свой язык;

Мультидисциплинарность;

Требования и спецификации проекта приходят с самых разных сторон и непрерывно меняются;

Каждый проект стал «вавилонской башней».

Что дает системная инженерия

По данным INCOSE:

8% затрат на внедрение системной инженерии дают выигрыш в 20% стоимости проектов, и на 50% увеличивают вероятность окончания проекта в срок. Это достигается через введение общего языка, описывающего проект, сознательный сдвиг усилий на ранние стадии проекта, где цена ошибки экспоненциально меньше.

Стадия обнаружения ошибки Коэффициент стоимости ошибки

Требования x1 (единица отсчета)

Проектирование x5

Строительство x12

Проверки x40

Функционирование x250

Новизна

Интеграция разных идей в одной организационной системе на уровне международного стандарта;

Использование этих идей в организации можно обсуждать и проверять.

 

Универсальность системной инженерии

Системная инженерия применима к любым рукотворным системам любой области человеческой деятельности (включая организации, сервисы, сами системы стандартизации).

Охватывает полный цикл жизни (например: замысел, разработка, производство, использование, поддержка и вывод из эксплуатации).

Учитывает необходимость контрактации (приобретения и поставки продуктов и услуг)

Охватывает использование внутри организаций и между организациями (в «расширенной организации» проекта)

Включает в процессы людей, оборудование, компьютеры, софт (ссылается на связанный стандарт ISO 12207 – жизненный цикл софта)

Применяется параллельно, итеративно и рекурсивно для различных частей системы

Учитывает особенности композиции любых систем – встроенных, автономных, интегрированных и любых других, сложных и простых

Происхождение

Совместная разработка ISO и IEC, активное участие INCOSE;

Начало работ в 1996, версии в 2002, 2005 (ГОСТ Р ИСО/МЭК 15288-2005), 2008;

Призван гармонизировать так называемое «болото стандартов» системной инженерии (многочисленные стандарты, принятые различными военными ведомствами, государствами, отраслевыми организациями стандартизации).

Некоторые термины

Система – совокупность взаимодействующих элементов, организованных для достижения одной или более провозглашенных целей (предоставления продукта или услуги)

Зафиксированный вариант (Baseline) – вариант спецификации или самой системы (продукта, услуги), прошедший формальное согласование и утверждение, являющийся основанием для дальнейшего развития, изменения в который могут быть внесены только через формальную процедуру

Организация – человек или группа людей, сооружений и оборудования, для которых определены ответственность, полномочия и взаимоотношения (адаптировано из ISO 9000:2005). Часть организации (даже один человек) или группа организаций – тоже организация, если в ней есть ответственность, полномочия и отношения

Процесс – набор взаимосвязанных или взаимодействующих действий, преобразующих входы в выходы (из ISO 9000:2005). Процессы состоят из действий (activities), а действия – из задач (tasks)

Продукт – результат процесса (ISO 9000:2005)

Проект – мероприятие с определенными критериями начала и окончания, предназначенное для создания продукта или услуги с учётом определённых ресурсов и требований (адаптировано из ISO 9000:2005). Может быть рассмотрен как уникальный экземпляр процесса, состоящий из скоординированных и управляемых действий, и может включать действия из Проектных процессов и Технических процессов, определенных в ISO 15288

Приёмка (Validation) – подтверждение, что система удовлетворяет пользовательским требованиям.

Проверка (Verification) – подтверждение, что специфицированные к системе требования выполняются.

Обеспечивающая система (Enabling system) – система, поддерживающая работу рассматриваемой системы на протяжении каких-либо стадий её жизненного цикла, но не вносящая прямого вклада в её работу на стадии эксплуатации.

 

Выводы по теме

1. Определение системной инженерии.

2. Проблемы современной инженерии

3. Описаны основные аспекты подтверждающие универсальность системной инженерии

Вопросы для самопроверки

1. Дайте определение системной инженерии.

2. Перечислите проблемы современной инженерии.

3.Дайте определение основным терминам, использующимся в системной инженерии.

РАЗДЕЛ 2. ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Тема 2. Жизненный цикл и этапы разработки программного обеспечения

 

План лекции

2.1. Подход жизненного цикла

2.2. Этапы жизненного цикла программного обеспечения

2.2.1 Постановка задачи

2.2.2 Анализ требований и определение спецификаций

2.2.3 Проектирование

2.2.4 Реализация

2.2.5 Сопровождение

 

Подход жизненного цикла

Жизненный цикл (ЖЦ) системы представляет собой эволюцию (прогресс, развитие) системы через смену ее состояний от первичного замысла до прекращения ее существования. Использование этого понятия означает применение к системе подхода жизненного цикла.

Подход жизненного цикла – это подход, методы (онтология и нотация описания) которого требуют при рассмотрении и описании системы рассматривать и описывать ее как проходящую во времени через ряд состояний. Эти состояния от появления первичного замысла и до прекращения существования системы необходимо учитывать при принятии любых решений по поводу изменения системы с учетом их последствий на протяжении всего времени ее существования.

Рассмотрим примеры подходов, не являющихся подходами жизненного цикла. Это подходы, не акцентирующие внимания на единстве системы во времени, то есть не рассматривающие систему как единый 4D («четырехмерный», пространство 3D+время) объект. Для таких подходов характерно отдельное рассмотрение множества целевых систем – проект, строительная площадка, готовый объект, реконструкция, ремонт. Решения по поводу этих систем принимаются без учета их дальних последствий. Типовые ошибки, допускаемые при таких подходах: при подготовке описания проекта принимают во внимание функционирование объекта, но забывают о потребностях, как стройки, так и отдаленной во времени реконструкции; или во время стройки считают возможным допускать отклонения от описания проекта без внесения в него изменений.

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

Понимаемые таким образом стадии не обязаны следовать строго друг за другом, они могут накладываться во времени (например, проект здания существует не только до строительства, но и во время него). Однако начало и конец каждой стадии жизненного цикла должны быть отмечены принятием специального решения полномочными стейкхолдерами системы. Конкретный состав стадий и их связи определяются спецификой, как целевой системы, так и используемого процессного подхода.

Совокупность процессных описаний, получаемых при применении подхода жизненного цикла к системе, называется описанием жизненного цикла. Описание жизненного цикла состоит из описаний процессов, изменяющих систему на каждой стадии жизненного цикла и тем самым проводящим систему через ее эволюцию.

Если методы описания приводят к появлению датацентрического описания, функционирующего как полноценная учетная система, то можно говорить о создании информационной модели жизненного цикла системы.

Применение процессного подхода к описанию жизненного цикла приводит к необходимости при описании жизненного цикла и его составляющих описывать процессы, протекающие в системе. Процесс «управление жизненным циклом» состоит из подпроцессов, соответствующих различным стадиям жизненного цикла. Переход от одной стадии к другой приводит к постадийной эволюции системы.

Стандарт ISO/IEC 15288:2008 «Systems and software engineering  System life cycle processes» задает в рамках объединения процессного подхода и подхода жизненного цикла набор конкретных опорных описаний отдельных процессов, применяемых к целевой системе при ее продвижении по стадиям жизненного цикла. Стандарт ISO/IEC 15288:2008 – процессный стандарт жизненного цикла, включающий:

1. Конкретный процессный подход жизненного цикла, предписывающий:

- идентификацию систем и их окружения;

- идентификацию стейкхолдеров, их интересов;

- использование некоторых методов описания процессов (онтологий и нотаций описания).

2. Опорные описания групп процессов жизненного цикла, организованных как:

- процесс «Управление жизненным циклом системы X», состоящий из

- процессов «Управление Стадией N жизненного цикла системы X».

- процесс «Управление Стадией N жизненного цикла системы X», состоящий из 25 обязательных процессов жизненного цикла для стадии N жизненного цикла системы X.

Примером иного стандарта управления жизненным циклом может, например, служить стандарт МАГАТЭ IAEA-TECDOC-1305. Этот процессный стандарт содержит указание на другие методы описания процессов, свой конкретный набор стадий жизненного цикла АЭС и иной набор архитектурных описаний процессов ЖЦ.

Для интеграции требований разных стандартов управления жизненным циклом, предписывающих различные группы описаний процессов жизненного цикла, может быть применена конструкция тематической группы описаний архитектурного подхода ISO 42010, как это описано в Приложении D ISO 15288:2008 на примере специальных свойств. Для доказательства того, что система обладает определенным набором специальных свойств (безопасности, ремонтопригодности, качества и т.п.) из описаний процессов базового подхода (например, подхода ISO 15288:2008) делаются специальные выписки практик и результатов, адресующие те специальные интересы стейкхолдеров, для которых и были разработаны соответствующие отраслевые стандарты (например, IAEA-TECDOC-1305 в случае АЭС). Стейкхолдер (Stakeholder) – это заинтересованная сторона. Это лицо или организация, имеющие права, долю, требования или интересы к системе или использованию ее свойств. Эти группы выписок являются не самостоятельными описаниями процессов, а процессными выписками – выборками (возможно, расширенными) тех частей основных описаний процессов, которые адресуют специальные интересы, т.е. обеспечивают достижение нужных специальных характеристик. Реализуемость такого подхода к проблемам безопасности или качества может быть обоснована тем, что обеспечение качества или безопасности не только являются предметом отдельных процессов, но и определяются обязательными практиками при осуществлении всех процессов жизненного цикла системы.

Нужно также добавить, что процессы, как любые системы, сами проходят жизненный цикл: их задумывают, проектируют, потом идет постановка процессов (претворение процессных норм в жизнь) и т.д. Цикл жизни процесса – это его прохождение по уровням зрелости. Уровни зрелости процесса составляют его стадии жизненного цикла, на которых описание процесса имеет разный нормативный статус (от отсутствия описания, к описанию процессов as is, далее к обязательному выполнению описаний как нормы, далее к постоянному пересмотру и улучшению нормативных описаний).

Постановка задачи

Процесс постановки задачи является очень важным этапом в разработке программного обеспечения и обеспечивает качество программного продукта в целом. На этом этапе необходимо четко сформулировать назначение программного продукта и требования к нему.

Для того чтобы иметь возможность определить требования к программному обеспечению, необходимо провести предпроектное обследование, в процессе которого определяется целесообразность данной разработки и определяются наиболее важные свойства, которыми должно обладать, разрабатываемое программное обеспечение.

В результате проектного обследования готовится техническое задание, в котором отражаются все основные требования к разработке.

 

2.2.2. Анализ требований и определение спецификаций

После разработки технического задания необходимо приступить к построению общей логической модели проектируемого программного обеспечения. Для этого разрабатывают спецификации, которые содержат в себе точное формализованное описание функций и ограничений разрабатываемого программного обеспечения. Спецификации содержат более детальное описание задачи, с учетом выбранного математического аппарата и методов ее решения. В общем виде спецификации входят в техническое задание.

На этом этапе рекомендуется сформировать тесты для поиска ошибок в разрабатываемом программном обеспечении, указав ожидаемые результаты.

Проектирование

Процесс проектирования сложного программного обеспечения обычно включает:

- разработка общей структуры;

- декомпозицию общей структуры;

- разработка компонентов.

В результате должна быть создана детальная модель со спецификациями. Тип модели зависит от выбранного подхода (структурный, объектный или компонентный) и конкретной технологии проектирования.

При проектировании программного обеспечения различают:

- логическое проектирование, которое включает описание будущего программного продукта;

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

 

Реализация

В процессе реализации программного продукта происходит поэтапный процесс написания кода на выбранном языке программирования (кодирование),а также его тестирование и отладка.

 

Сопровождение

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

Основные причины выпуска новых версий:

- исправление ошибок, возникающих во время использования программного продукта;

- совершенствование версий программного продукта, расширение его функциональности;

- адаптация программного продукта под новое программное обеспечение.

В процессе разработки новых версий программного продукта происходит пересмотр проектных решений принятых на предыдущих этапах.

На текущий момент роль этого этапа жизненного цикла программного обеспечения существенно возросла, так как теперь программы создаются итерационно: сначала выпускается относительно простая версия, затем следующая с большими возможностями и т. д..

 

Выводы по теме

1. Дано определение и описан подход жизненного цикла программного обеспечения.

2. Рассмотрены этапы жизненного цикла программного обеспечение.

 

Вопросы для самопроверки

1. Дайте определение жизненного цикла.

2. Расскажите о подходе жизненного цикла.

3.Охарактеризуйте этапы жизненного цикла программного обеспечения.

План лекции

3.1. Системный подход

3.1.1 Подход

3.1.2 Онтология

3.1.3 Стейкхолдер

3.1.4 Система

3.2 Архитектурный подход

3.3 Деятельностные подходы

3.4 Процессный подход

3.5 Четыре группы процессов

 

Подход системной инженерии к управлению жизненным циклом систем представляет собой результат гармонизации ряда подходов, в частности:

- системного;

- архитектурного;

- процессного;

- жизненного цикла;

- оценки зрелости процессов.

Ниже будут кратко охарактеризованы перечисленные подходы и введены основные термины, необходимые для их применения.

Далее мы дадим значительно более точное определение термина подход, однако для начала будет достаточно сказать, что подход к какой-то области знаний, виду деятельности или кругу проблем состоит в задании определённой онтологии. Онтология – это перечень того, что мы видим в окружающем мире, какие именно объекты и их аспекты мы выделяем и считаем важными при решении стоящих перед нами задач.

 

Системный подход

Системный подход задаёт свою онтологию – предписывает видеть в мире системы, их границы, назначение, элементы, их связи, стейкхолдеров, их интересы и т.д., и описывать мир с использованием именно этих терминов.

 

Подход

1. Framework – как термин нигде не определяется, является омонимом, то есть имеет множество значений в словарном гнезде.

2. Определение:

This International Standard establishes a common process framework for describing the life cycle of man-made systems (ISO 15288).

ISO/IEC 15288 defines a generic, top-level framework based upon a set of processes that can be combined into various suitable life cycle models.

Нормативная клауза архитектурных описаний ISO 42010 представляет собой conceptual framework (or frame of reference), that establishes terms and concepts pertaining to the content and use of (architectural) description.

ISO/IEC TR 15543 -- A framework for IT security assurance.

3. Русский: «подход» понимается как набор (в том числе предопределенных, «библиотечных») методов описаний, включающих тематическую онтологию и нотации, а также правила их применения, дополненные указанием на набор стейкхолдеров и их интересов к системе. В целом подход приводит к созданию, интерпретации и использованию в качестве норм связанного набора описаний системы.

Это близко традиционному использованию слова «подход», которое указывает на перенос методов и онтологий, разработанных в одних предметных дисциплинах, на объекты других дисциплин – например, рассмотрение процессов как систем (системный подход к процессам), систем как процессов (процессный подход к системам) и т.д.

Важная особенность: когда говорится о «концептуальном подходе» – используется слово approach, а когда подход оформляется в виде конкретного описания, то он чаще называется framework.

4. Формально: подход – это набор методов описания систем и правил их применения, используемый для формирования описаний систем и установления деятельностных (процессных) норм.

5. Комментарий: можно считать, что «междисциплинарность», входящая в определение системной инженерии (INCOSE: Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems) – это гармонизация множества подходов – системного, процессного, архитектурного и ряда других.

Framework в сочетании «reference framework» переводится как стандарт, то есть описание подхода, используемое в качестве проверяемой нормы.

 

Онтология

1. Ontology, data model. Используется в методах интеграции данных (стандарты ISO 15926, ISO 18876, ISO 18629, Gellish и т.д.).

2. Определение:

Сonceptual data model -- data model in the three schema architecture defined by ISO/TR 9007, in which the structure of data is represented in a form independent of any physical storage or external presentation format. NOTE Adapted from the IDEF1X specification. (ISO 15926 3.1.3)

В описании языка Gellish уточняется:

Such a model has different names in different disciplines and different conventions are used in those disciplines to document such a model:

- In philosophy such a model is called an ontology that tries to describe in general terms the structure of reality and imagination or a part of it. An ontology is generally documented as a collection of propositions expressed in a natural or artificial language.

- In information technology such a model is called a data model or schema that describes the structure of 'data' about a part of the reality or processes in it. Such a 'data structure' is a collection of relationships between 'objects'. A data model is generally documented in an artificial language. To support understanding it is often also documented in a graphical schema that shows the objects and their relationships. Data models in information technology can be used to model nearly anything, so they include models of any kind of object and its behaviour, including also models of business processes.

- In linguistics such a model is called (the definition of) an artificial language, with as aspects a grammar and a vocabulary with its semantics. The definition of the structure of such an artificial language has an 'ontological commitment', which means that the language definition is such that it enables the expression of meaningful propositions about the structure of reality and imagination.

3. Русский: онтология. Мы выбираем наиболее общее (философское) наименование, поскольку даже в сфере IT все больше используется слово ontology (в том числе среди разработчиков ISO 15926 в последние годы модель данных ISO 15926-2 все чаще называют онтологией, а не моделью данных). Нужно также учесть, что слово «онтология» используется не только в сфере IT, но и в методологии – когда речь идет о создании и сравнении различных методов описания систем или деятельности.

4. Формально: онтология – это набор концептов и отношений между ними. Данное определение следует парадигме Bunge-Wand-Weber, в которой весь мир состоит из объектов и отношений, эта парадигма на сегодняшний день общепринята в информационных технологиях.

5. Комментарий: онтологии в системной инженерии используются для двух целей:

- Интеграция различных описаний (как в случае правил соответствия методов описания - viewpoint correspondence rule, так и в случае интеграции данных информационных моделей в варианте ISO 15926 или Gellish).

- Обсуждений адекватности методов описаний интересам стейкхолдеров, так как каждый метод описания содержит в себе какую-то онтологию и отражающую концепты этой онтологии нотацию. Например, логистическое описание проекта никак не отражает того, насколько результат проекта будет удовлетворять заказчика. С другой стороны, логистическое описание дает информацию о том, вовремя ли получит заказчик результат - удовлетворяющий его или не удовлетворяющий. Это вопрос прежде всего онтологический: какие черты реальности отражают используемые методы описаний.

 

Стейкхолдер

1. Stakeholder, вводится в стандартах, основывающихся на системном подходе.

2. Определение:

Stakeholder – individual or organization having a right, share, claim, or interest in a system or in its possession of characteristics that meet their needs and expectations (ISO 15288 4.29).

System stakeholder: An individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system (ISO 42010 3.8).

3. Русский: стейкхолдер. Перевод «заинтересованное лицо» создает дополнительную омонимию с юридическим термином гражданского кодекса «заинтересованное лицо», а также аналогичным термином из корпоративного управления. Слово «стейкхолдер» уже закрепилось в русском языке, Яндекс находит его на 19 тыс. страниц.

4. Формально: стейкхолдер – это роль, в которой могут быть человек или организация, состоящая в наличии интереса к системе, в том числе к её функционированию или конструкции, назначению, продукту, обладанию системой какими-либо характеристиками.

Предметом наших рассмотрений будут являться создаваемые людьми системы. Системами мы будем называть любые существующие в мире или воображаемые объекты или явления (включая знаки и символы), если они обладают всеми четырьмя перечисленными признаками:

- Могут быть выделены из окружения, отделены от внешнего мира.

- Могут быть рассмотрены как состоящие из каких-то элементов.

Между этими элементами, и между элементами и внешним окружением, могут быть выделены связи, взаимодействия.

Может быть определено назначение системы, то есть можно указать какие-то результаты (материальные или информационные, в специальных случаях – продукты), предоставляемые внешнему миру.

 

Система

Система – это то, что может быть выделено из окружения, разделено на имеющее связи элементы, и имеет какое-то назначение для внешнего окружения.

Создаваемые людьми системы могут включать в себя и людей, и целые организации. На многие вопросы в рамках описанных ниже подходов просто невозможно ответить, рассматривая системы только лишь как совокупности сооружений, оборудования и компьютеров.

Как система могут быть рассмотрены не только объекты, но и явления. Для нас одним из основных применений системного подхода будет рассмотрение примеров человеческой деятельности (процессов, проектов) как систем.

Выделяя систему из внешнего мира, мы зачастую одновременно выделяем во внешнем мире иные системы, с которыми взаимодействует интересующая нас система. Чтобы отличать ту систему, которая нас интересует, от иных систем, мы будем иногда называть интересующую нас систему целевой системой. Роли систем во внешнем мире тоже могут быть уточнены: обеспечивающая система, система в операционном окружении.

Говоря о системе, необходимо всегда указывать ту конкретную систему, которая имеется в виду в данный момент. Просто слово система стоит использовать только в общетеоретических текстах. Самым предпочтительным вариантом является использование названия системы, определяющее её границы и назначение: АЭС, ГЭС, самолёт, информационная модель, процесс. Если это невозможно, следует добавлять разъяснения, позволяющие определить границы или элементы системы: «компьютерная система – это комплект оборудования и установленное на нём программное обеспечение…».

Ещё два важных для дальнейшего рассмотрения понятия, связанные с понятием системы – интерес и стейкхолдер.

Для любой системы можно выявить множество интересов к разным аспектам её функционирования или устройства. Это могут быть интересы к продуктам и результатам, предоставляемым системой. При этом продукты и результаты бывают как прямые (например, вырабатываемая ГЭС электроэнергия), так и косвенные (например, потенциальная угроза для жизни и здоровья, которой является АЭС). Среди интересов может быть интерес к деньгам, которые система приносит – интерес собственника к его предприятию, или интерес налоговой инспекции к налогоплательщику. Интересы могут быть к составным частям системы – интерес начальника цеха к станкам в его сфере ответственности, или интерес конструктора к чертежам порученного ему узла.

Условное лицо, роль которого по отношению к системе определяется его интересами, мы будем называть стейкхолдером (иногда также говорят «заинтересованное лицо»).

Введённые понятия система (system), целевая система (system of interest), обеспечивающая система (enabling system), система в операционном окружении (system in operational environment), интерес (concern), стейкхолдер (stakeholder) соответствуют основным понятиям, введённым международным стандартом процессов жизненного цикла ISO/IEC 15288:2008 Systems and software engineering - System life cycle processes.

 

Архитектурный подход

Теоретически, человек может начать создавать требуемую ему систему в натуральную величину, непосредственно в металле и камне, методом проб и ошибок. Для больших систем это происходит крайне редко (работы великого архитектора Гауди скорее исключение). В основном люди начинают работать с описаниями системы (текстами, чертежами, макетами, симуляторами) и даже после создания самой системы (построенного дома, корабля, АЭС) работа с описаниями занимает у них существенное время. Поэтому особое внимание мы посвятим разным способам описания, для чего введем некоторые строгие определения для вольно использующихся в этой сфере слов, постаравшись обеспечить их соответствие терминологии, используемой в международных стандартах.

Некая система может выступать в роли модели целевой системы, если она может быть использована для получения информации о целевой системе без непосредственного контакта с целевой системой. Модели могут быть как материальными (макеты, прототипы), так и знаковыми, то есть состоящими из слов, чисел, формул, рисунков. Знаковую систему-модель целевой системы мы будем называть описанием целевой системы.

Описание целевой системы - знаковая система, составленная из совокупности фактов (утверждений) о целевой системе (бывшей, нынешней, будущей), которая может быть использована для получения данных о целевой системе без доступа к ней.

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

Описание системы включает всю информацию, которая когда-либо была (или будет) порождена о системе. В описание АЭС входят и строительные чертежи в недрах какого-нибудь архива, и самая свежая информация, отображённая на её пульте управления, и многолетний архив данных о режимах АЭС, хранящийся в СО ЕЭС, и расчёт цен на завтра в её узле поставки, выполненный в АТС. Наличие связей с целевой системой и единообразное использование накопленных в разных местах данных позволяют считать эту слабосвязанную совокупность информации одной системой – описанием целевой. Как показывает этот пример, описание системы в полном виде может быть недоступно какому-то одному лицу, и извлечение из описания данных о системе бывает чрезвычайно трудоёмко. Часто проще бывает обратиться к самой системе и получить данные непосредственно (например, лазерной съёмкой уже построенной электростанции в 3D), а не из описания (чертежа).

Большинство описаний систем начинаются своё существование как документоцентрические. В архивы, а потом и в электронные базы данных, разнообразные сведения о системе попадают в виде документов. Собственно факты о системе отражены в документах отдельными словосочетаниями или фразами текстов, цифрами в клетках таблицы или наборами точек на чертежах. С развитием систем хранения информации становится возможен переход к датацентрическим описаниям, когда единичные факты (утверждения) становятся элементарными единицами хранения, с которыми можно работать по отдельности или группами, передавать и принимать, между которыми можно устанавливать связи. При переходе к датацентрическим описаниям документы превращаются в совокупности фактов, которые сформированы для выдачи кому-то как выписка из датацентрического описания (сформированы как изображение на бумаге или экране – текст, таблица, 2D или 3D чертёж), или получены от кого-то (как изображение на бумаге или файл с текстом, таблицей, 2D или 3D чертёжом) и немедленно разобраны на содержащиеся в них отдельные утверждения.

Как упомянуто выше, описания систем часто существуют как разрозненные наборы сведений в разных шкафах и в разных компьютерах, разнесённых на тысячи километров друг от друга. «Хорошим» описанием может считаться только такое описание, в котором каждый факт появления новой информации учитывается, то есть в едином месте можно узнать о том, что появление или изменение информации произошло, кто и когда его произвёл, какой его статус (предложение, одобренное предложение, утверждённый вариант), как его найти. Кроме того, в «хороших» описаниях информация хранится надёжно, не подделывается, не искажается и не утрачивается. Такие описания называются учётными системами, а про хранящиеся в них факты говорят, что они не просто «хранятся», а «учтены» в системе.

Из всех возможных описаний системы мы хотели бы строить и использовать наилучшие, самые актуальные и удобные. На сегодня «наилучшими» можно считать те описания, для которых обеспечены датацентричность и учётность. Именно такие описания мы будем называть информационными моделями.

Информационная модель – датацентрическое описание системы, являющееся в то же время единой учётной системой.

При рассмотрении и описании системы можно пользоваться разными методами.

В рамках каждого метода в системе рассматриваются свои собственные элементы. Методы бухгалтера предписывают видеть в реальной электростанции активы, пассивы, сделки, денежные потоки и иные элементы бухгалтерской онтологии. Для работы строителя в реальной электростанции надо увидеть строительные материалы, детали механизмов, монтажное оборудование. Интересы разных стейкхолдеров лучше всего учитываются при рассмотрении в разных предметных онтологиях.

Для сбора и записи данных о системе в рамках метода описания для каждой предметной онтологии должна существовать специальная нотация – совокупность графических изображений для концептов и их отношений и правил использования этих изображений. Буквы и цифры, используемые для построения означающих концепты слов, также составляют нотацию. Именно такая нотация используется при строго формализованной записи бухгалтерских данных в виде цифр в клетках предписанных форм отчетности. Не менее строго, но совершенно по иному, формализовано создание сборочных чертежей в виде наборов линий, организованных в графические и текстовые изображения.

Каждый метод описания предна<