Просмотр исходного текста страницы ISO/IEC/IEEE 42010

'''ISO/IEC/IEEE 42010:2011 - Системная и программная инженерия. Описание архитектуры'''
ISO/IEC/IEEE 42010 Systems and software engineering — Architecture description

Отечественная локализация: ГОСТ Р 57100—2016 "Системная и программная инженерия. Описание архитектуры"

== Назначение ==
Стандарт, разработанный для управления архитектурным описанием сложных [[система|систем]], позволяет установить, что у деятельности, а значит и у [[жизненный цикл]] и его [[:Категория:Практики|практик]], как у любой системы, есть одна или несколько '''[[стейкхолдер|заинтересованных сторон]]''' (stakeholders).

Каждая из этих сторон обычно имеет '''набор интересов''' (concerns), связанных с системой, и стремится их удовлетворить. Для удовлетворения каждого из интересов создаются отдельные '''группы описаний''' (views) системы. По сути, группа описаний представляет систему с определенной точки зрения, а набор групп образует полное описание системы. Соглашения, по которым группа описаний создается, отображается и анализируется, устанавливаются '''[[Метод описания|методом описания]]''' (viewpoint). Тем самым метод описания определяет [[:Категория:Языки|языки]], включая нотации, описания или типы продуктов, применяемые для описания группы описаний, а также все связанные методы [[Моделирование|моделирования]] или приемы анализа, применяемые к моделям этой группы. Данные языки и приемы применяются для получения результатов, имеющих отношение к адресуемым интересам. Каждая группа создается в соответствии со своим методом.

Схема взаимосвязей основных концепций ISO 42010 выглядит следующим образом:

[[Файл:ISO-42010-diagram.png|800px|center]]

== Группы описаний ==
Описание деятельности с разных упомянутых точек зрения используется разными заинтересованными лицами и составляется из разных групп описаний. Описание с точки зрения создания ценности принимает вид набора требований разного рода (спецификаций). Описание деятельности с точки зрения выполняемой трансформационной работы интересует инженеров и представляется в виде '''процессной группы описаний'''. [[Логистика]] интересует менеджеров проектов, и описывается с помощью '''проектной группы описаний'''.

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

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

Интерес инженеров к описанию технологической цепочки стал причиной появления и распространения ряда методов процессного описания:
* В момент зарождения процессного метода описания получили популярность методы функционального разбиения [[IDEF0]] для описания «логической последовательности» дел, и описания процесса [[IDEF3]] для описания развертки во времени.
* Идея необходимости множества групп описаний привела к появлению языка [[UML]], поддерживающего одновременно пять групп описаний (пять типов диаграмм). Для описания процессов могут использоваться UML диаграммы активности и [[Сценарий использования|вариантов использования]] (Use Case diagram, Activity diagram).
* Язык [[SysML]], основанный на UML, предлагает расширение диаграммы активности, предоставляющую возможность моделировать потоки физических элементов или энергии. По сути, диаграмма активности – это вариация диаграммы состояний (State Diagram), где состояния заменены на акты активности, а переходы между состояниями представляют собой выполнение работы. Но диаграммы состояний не позволяют нам представить развертку процесса по времени в терминах, которые понятны человеку («раньше-позже-одновременно»).
* Этим же недостатком страдает и BPEL (Business Process Execution Language), который представляет собой машину состояний и ориентирован на машинное исполнение моделей процессов.
* В настоящий момент активно развивается и набирает популярность метод [[OMG BPMN]] ([[OMG]] Business Process Metamodel and Notation). Готовится вторая версия этого стандарта, включающая возможность описания взаимодействия между исполнителями работ. BPMN поддерживает описание процессов на разных уровнях абстракции, имеет высокую выразительность и выражает процесс с использованием понятного людям представления времени.

Информация, предоставляемой процессной группой описания, не может удовлетворить нужды менеджеров, которые занимаются планированием ресурсов, потоков материалов, финансов и должны принимать решения об их распределении. Описания процессов не позволяют получить представление о проекте в целом и не предоставляют удобные для менеджеров способы оценки длительности проекта, «задействования ресурсов» во времени, прохождения «[[Гейты и вехи|контрольных точек]]» - того, что обычно связывают с проектной группой описаний, а не процессной. Нет выделения стадий проекта, определения точек принятия решений, функциональной иерархии, позволяющей распределять работы по ресурсам, расчета [[CPM|критического пути]] или [[CCPM|критической цепи]] – все это затрудняет оценку рисков в ходе выполнения проекта и не дает менеджерам эффективно выполнять свою работу. С другой стороны, инженеры получают подробное описание требуемых трансформационных операций и руководства по их выполнению.

=== Проектная группа описаний ===
Для планирования ресурсов и управленческого контроля более приспособлена проектная или логистическая группа описаний, которая удовлетворяет нужды менеджеров. Они не заинтересованы в рассмотрении последовательности работ (микропроцессы). Для достижения целей проекта им требуется возможность распределения ресурсов по выполняемым работам и синхронизация работ во времени. Для этого используется функциональная иерархия, '''разбиение работ''' (work breakdown structure, WBS). С таким деревом работ удобно работать менеджерам. Становятся возможны группировка работ в стадии ЖЦ и определение [[Гейты и вехи|контрольных точек]] для принятия решений, таких как пересмотр выделения ресурсов. Функциональная иерархия работ поддерживается большим количеством систем управления проектами и может отображаться в таких системах различными способами:
* [[диаграмма Ганта]]
* [[PERT]] (Program Evaluation and Review Technique). 

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

== См. также ==
см. [[:Категория:Архитектурные подходы|Архитектурные методологии/подходы]]

[[Категория: Стандарты системной инженерии]]
[[Категория: Стандарты ISO]]
[[Категория: Стандарты IEEE]]
[[Категория: Стандарты IEC]]