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 выглядит следующим образом:

Группы описаний

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

Процессная группа описаний

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

Для выполнения работы им требуется описание набора актов деятельности. Должны быть описаны сущности и информация, требуемые на входе производимых операций и получаемые на выходе. Эти входы и выходы обладают набором состояний, которые специфицируются с указанием правил перехода из одного состояния в другое. Распределение работ должно поддерживаться описанием ролей, которые включают в себя информацию о требуемых компетенциях и квалификации. Методы, сопровождаются руководствами (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 поддерживает описание процессов на разных уровнях абстракции, имеет высокую выразительность и выражает процесс с использованием понятного людям представления времени.

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

Проектная группа описаний

Для планирования ресурсов и управленческого контроля более приспособлена проектная или логистическая группа описаний, которая удовлетворяет нужды менеджеров. Они не заинтересованы в рассмотрении последовательности работ (микропроцессы). Для достижения целей проекта им требуется возможность распределения ресурсов по выполняемым работам и синхронизация работ во времени. Для этого используется функциональная иерархия, разбиение работ (work breakdown structure, WBS). С таким деревом работ удобно работать менеджерам. Становятся возможны группировка работ в стадии ЖЦ и определение контрольных точек для принятия решений, таких как пересмотр выделения ресурсов. Функциональная иерархия работ поддерживается большим количеством систем управления проектами и может отображаться в таких системах различными способами:

• диаграмма Ганта
• PERT (Program Evaluation and Review Technique).

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

См. также

см. Архитектурные методологии/подходы