ISO 42010 - История изменений

Admin: Перенаправление на ISO/IEC/IEEE 42010

2017-11-30T13:03:40Z

Перенаправление на ISO/IEC/IEEE 42010

Admin в 12:21, 3 октября 2017

2017-10-03T12:21:03Z

Admin: /* Назначение */

2016-12-03T13:27:30Z

‎Назначение

Admin: /* Назначение */

2016-12-03T13:26:55Z

‎Назначение

Admin: /* Архитектурные методологии */

2016-12-03T13:22:12Z

‎Архитектурные методологии

Admin в 17:04, 18 ноября 2016

2016-11-18T17:04:49Z

Admin: /* Архитектурные методологии */

2016-10-20T13:49:58Z

‎Архитектурные методологии

Admin: /* Архитектурные методологии */

2016-10-20T13:49:40Z

‎Архитектурные методологии

Admin: /* Процессная группа описаний */

2016-10-20T13:48:32Z

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

Admin в 14:03, 25 июля 2016

2016-07-25T14:03:52Z

@@ Строка 1: / Строка 1: @@
-'''ISO/IEC/IEEE 42010:2011 - Системная и программная инженерия. Описание архитектуры'''
+#REDIRECT [[ISO/IEC/IEEE 42010]]
-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).
-−
-Менеджеры проектов с успехом применяют эти методы для решения собственных задач. Они могут описывать стадии и этапы ЖЦ, определять контрольные точки. Но применение только проектной группы описаний накладывает свои ограничения. Эти методы не предоставляют возможности описания артефактов, использующихся в проекте, в том числе планов, руководств, отчетов. Графики проектов не предусматривают четкого описания последовательности выполнения работ. Это реализуется в виде связей-зависимостей начала и окончания отдельных работ. Но такой подход не позволяет описывать, например, итерации свойственные ЖЦ сложных систем. Группа проектных описаний не предоставляет стандартного способа описания ролей. В системах управления проектами они представляются в качестве особого вида ресурсов. Эти недостатки указывают на то, что использовать только проектную группу описаний недостаточно.
-−
-== См. также ==
-см. [[:Категория:Архитектурные подходы|Архитектурные методологии/подходы]]
-−
-[[Категория: Стандарты системной инженерии]]

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

@@ Строка 9: / Строка 9: @@
 Схема взаимосвязей основных концепций ISO 42010 выглядит следующим образом:
-[[Файл:ISO-42010-diagram.png|center]]
+[[Файл:ISO-42010-diagram.png|800px|center]]
 == Группы описаний ==

← Предыдущая		Версия 13:26, 3 декабря 2016
Строка 6:		Строка 6:

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

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

@@ Строка 31: / Строка 31: @@
 Менеджеры проектов с успехом применяют эти методы для решения собственных задач. Они могут описывать стадии и этапы ЖЦ, определять контрольные точки. Но применение только проектной группы описаний накладывает свои ограничения. Эти методы не предоставляют возможности описания артефактов, использующихся в проекте, в том числе планов, руководств, отчетов. Графики проектов не предусматривают четкого описания последовательности выполнения работ. Это реализуется в виде связей-зависимостей начала и окончания отдельных работ. Но такой подход не позволяет описывать, например, итерации свойственные ЖЦ сложных систем. Группа проектных описаний не предоставляет стандартного способа описания ролей. В системах управления проектами они представляются в качестве особого вида ресурсов. Эти недостатки указывают на то, что использовать только проектную группу описаний недостаточно.
-== Архитектурные методологии ==
+== См. также ==
 см. [[:Категория:Архитектурные подходы|Архитектурные методологии/подходы]]
 [[Категория: Стандарты системной инженерии]]

← Предыдущая		Версия 17:04, 18 ноября 2016
Строка 34:		Строка 34:
	см. [[:Категория:Архитектурные подходы\|Архитектурные методологии/подходы]]		см. [[:Категория:Архитектурные подходы\|Архитектурные методологии/подходы]]

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

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