Ситуационная инженерия методов - История изменений

Admin в 18:06, 6 марта 2019

2019-03-06T18:06:45Z

Admin в 17:39, 5 января 2018

2018-01-05T17:39:38Z

Admin в 11:49, 19 декабря 2016

2016-12-19T11:49:13Z

Admin: /* II поколение SME */

2016-11-18T13:43:26Z

‎II поколение SME

Admin в 11:27, 15 ноября 2016

2016-11-15T11:27:22Z

Admin: /* I поколение SME */

2016-11-15T11:11:24Z

‎I поколение SME

Admin в 11:03, 15 ноября 2016

2016-11-15T11:03:28Z

Admin: /* II поколение SME */

2016-08-02T14:29:49Z

‎II поколение SME

Admin в 08:04, 26 июля 2016

2016-07-26T08:04:33Z

Admin: /* II поколение SME */

2016-05-18T14:56:40Z

‎II поколение SME

@@ Строка 14: / Строка 14: @@
 * '''Минусы:''' переструктурированные описания невозможно "читать", только "прокликивать": не задана последовательность изложения, это "энциклопедия", а не "учебник", см. [http://ailev.livejournal.com/845850.html подробнее]).
-Ситуационная инженерия методов даёт описания, трудно совместимые с традиционно понимаемыми мелко детализуемыми "логическими процессами", описываемыми в [[IDEF0]], или еще более мелко детализуемыми (потому как для части из них подразумевается исполнение компьютером, которому всё нужно разжёвывать до мельчайших деталей и нельзя надеяться на понимание каких-то умолчаний) "физическими процессами", описываемыми в [[EPC]]/ARIS или [[OMG BPMN|BPMN]] 2.0. Описания методов конвертируются обычно не в workflow, а в projects - и соответствующий софт умеет выгружать ситуационные методы в виде проектов MS Project. Тем самым, реализации метода (endeavor) проще рассматривать как "проекты", а не как "процессы".
+Ситуационная инженерия методов даёт описания, трудно совместимые с традиционно понимаемыми мелко детализуемыми "логическими процессами", описываемыми в [[IDEF0]], или еще более мелко детализуемыми (потому как для части из них подразумевается исполнение компьютером, которому всё нужно разжёвывать до мельчайших деталей и нельзя надеяться на понимание каких-то умолчаний) "физическими процессами", описываемыми в [[Event-Driven Process Chain|EPC]]/ARIS или [[OMG BPMN|BPMN]] 2.0. Описания методов конвертируются обычно не в workflow, а в projects - и соответствующий софт умеет выгружать ситуационные методы в виде проектов MS Project. Тем самым, реализации метода (endeavor) проще рассматривать как "проекты", а не как "процессы".
 SME конкурирует с "готовыми методологиями" (off-the-shelf-methodologies), которыми торгуют большие компании: методологии разработки, которые one-size-fit-all, и должны быть далее внедрены полностью для того, чтобы работать.

@@ Строка 36: / Строка 36: @@
 === II поколение SME ===
-# Стандарт [[OMG Essence]] – ядро и язык для описания методов и практик [[Программная инженерия|программной инженерии]]. Основным отличием Essence от предыдущих попыток (таких как [[OPF]], [[SPEM]], [[ISO 24744]]) решить ту же задачу является то, что наряду с синтаксисом языка в Essence вводится хорошо проработанный базовый набор типизированных понятий, называемых ядром. Ядро Essence разделено на три области интересов (клиента, решения и деятельность). В каждой области интересов есть свои [[:Категория:Альфы|альфы]], пространства дел и [[:Категория:Компетенции|компетенции]]. Важными свойствами ядра являются исполнимость, расширяемость и практичность.
+# Стандарт [[OMG Essence]] – ядро и язык для описания методов и практик [[Программная инженерия|программной инженерии]]. Основным отличием Essence от предыдущих попыток (таких как [[OPF]], [[OMG SPEM 2.0|SPEM]], [[ISO 24744]]) решить ту же задачу является то, что наряду с синтаксисом языка в Essence вводится хорошо проработанный базовый набор типизированных понятий, называемых ядром. Ядро Essence разделено на три области интересов (клиента, решения и деятельность). В каждой области интересов есть свои [[:Категория:Альфы|альфы]], пространства дел и [[:Категория:Компетенции|компетенции]]. Важными свойствами ядра являются исполнимость, расширяемость и практичность.
 [[Категория: Дисциплины]]

@@ Строка 5: / Строка 5: @@
 * в компонентах метода нужно различать:
 ** '''акторов''' (люди и инструменты, являющиеся продолжением людей),
-** '''[[Работы|работы]]''' (взятые как разворачивающиеся во времени жизненные циклы, и как практики "того, что должно делаться"),
+** '''[[Работа|работы]]''' (взятые как разворачивающиеся во времени жизненные циклы, и как практики "того, что должно делаться"),
 ** '''[[Рабочий продукт|рабочие продукты]]''' или артефакты (модели, документы), языки и нотации, руководства и т.д.

@@ Строка 36: / Строка 36: @@
 === II поколение SME ===
-# Стандарт [[OMG Essence]] – ядро и язык для описания методов и практик [[Программная инженерия|программной инженерии]]. Основным отличием Essence от предыдущих попыток (таких как [[OPF]], [[SPEM]], [[ISO 24744]]) решить ту же задачу является то, что наряду с синтаксисом языка в Essence вводится хорошо проработанный базовый набор типизированных понятий, называемых ядром. Ядро Essence разделено на три области интересов (клиента, решения и endeavor). В каждой области интересов есть свои альфы, пространства дел и компетенции. Важными свойствами ядра являются исполнимость, расширяемость и практичность.
+# Стандарт [[OMG Essence]] – ядро и язык для описания методов и практик [[Программная инженерия|программной инженерии]]. Основным отличием Essence от предыдущих попыток (таких как [[OPF]], [[SPEM]], [[ISO 24744]]) решить ту же задачу является то, что наряду с синтаксисом языка в Essence вводится хорошо проработанный базовый набор типизированных понятий, называемых ядром. Ядро Essence разделено на три области интересов (клиента, решения и деятельность). В каждой области интересов есть свои [[:Категория:Альфы|альфы]], пространства дел и [[:Категория:Компетенции|компетенции]]. Важными свойствами ядра являются исполнимость, расширяемость и практичность.
 [[Категория: Дисциплины]]

@@ Строка 17: / Строка 17: @@
 SME конкурирует с "готовыми методологиями" (off-the-shelf-methodologies), которыми торгуют большие компании: методологии разработки, которые one-size-fit-all, и должны быть далее внедрены полностью для того, чтобы работать.
 == Поколения SME ==
@@ Строка 30: / Строка 32: @@
 # '''[[OPF]]''' (OPEN Process Framework) – один из ранних стандартов, представляет собой свободный набор компонентов для создания процессов [[ЖЦ]] на уровне проекта.
 # '''[[OMG SPEM 2.0]]''' - открытый стандарт [[OMG]] на базе профиля [[UML]] 2, предлагающий унифицированный способ представления ЖЦ.
-# '''ISO 24744'''
+# '''[[ISO 24744]]''' - стандарт ISO на метамодель для методик разработки. Гармонизирован с ISO 15288.
-#* Не нужно путать ISO 24744 (метамодель для методов разработки) и [[ISO 24774]] (формат описания практики, использовавшийся при создании ISO 15288). Хотя ничего не мешает использовать оба этих стандарта вместе, они друг другу не противоречат. Более того ISO 24744 гармонизирован с ISO 15288.
+# '''[http://www.semat.org SEMAT]''' - инициатива по стандартизации, находящаяся в русле ситуационной инженерии методов
-#* Это наиболее современный стандарт (есть и его перевод на русский), но для него нет программного обеспечения.
-#* Отличительной особенностью этого стандарта является не только его принципиальная расширяемость, но и стандартизация соотношения между методом и реализацией метода (endeavour, предпринятием), а также включение описания языков и нотаций для работы с особым видом рабочих продуктов: моделями. Стандарт также задаёт графическую нотацию для описания методов. Всего его метамодель определяет 68 компонент метода (чтобы сложилось впечатление, о чем это, приведу начало этого списка, в алфавитном порядке: Action, ActionKind, Build, BuildKind, CompositeWorkProduct, KompositeWorkProductKind, Conglomerate, Constraint, Document, DocumentKind, Element, EndeavourElement, Guidline, HardwareItem, HardwareItemKind, InstrantenousStage, InstantenousStageKind, Language, MethodologyElement, Milestone и т.д. -- вот из таких кирпичиков и складываются описания методов).
-#* Подробнее об этом стандарте [http://community.livejournal.com/incose_ru/16848.html тут].
-#* Особенностью этого стандарта является то, что он предлагает артефакт-центрированный (а не практико-центрированный, или процесс-центрированный) метод описания: в нём главными для описания метода являются рабочие продукты, а практики и приёмы работы с ними и над ними могут меняться по ходу дела. Так, [[Рабочий продукт|артефакт]] "план" может быть составлен множеством разных способов, с ним работают множество других практик, но его наличие постулируется -- и уже затем ситуационный метод строится, исходя из необходимости такого артефакта. Подробнее -- см. доклад Cesar Gonsales-Perez (презентация переведена на русский): http://www.vniiaes.ru/files/RuSEC%202010.rar
-# '''[http://www.semat.org SEMAT]''' (из текущих инициатив по стандартизации, находящихся в русле ситуационной инженерии методов)
-#* Главной своей задачей SEMAT ставит выработку нового набора типов компонент метода (новую "схему акта деятельности"), по составу которого будет достигнут не столько "научный результат" (творцов в SEMAT более чем хватает), но общественное согласие. По факту, основатели SEMAT хотят повторить успех UML в области SME -- в начале 90-х по поводу UML договорились между собой представители самых разных методологий разработки и соответствующих им языков ОО-моделирования. Результат известен, UML сегодня "царь горы". Те же самые люди, которые занимались унификацией UML из своих разнородных подходов в середине 90-х, возглавляют теперь SEMAT. Тем самым развитие SME приобретает еще и социальное измерение: способ задания в SEMAT онтологии метода упирает на "разделяемость" (shared) множеством людей, как основное свойство онтологии -- когда они получат результат (набор компонент метода), по факту под этим результатом подпишутся множество людей, и SEMAT будет претендовать на статус "стандарта де-факто".
 === II поколение SME ===

@@ Строка 28: / Строка 28: @@
 Был разработан ряд стандартов ситуационной инженерии методов, которые определяют '''"метамодель"''' метода - из каких компонентов состоит метод, характеристики этих компонент, и связи между компонентами. Среди этих стандартов наиболее известны (см. [http://ailev.livejournal.com/763554.html краткий обзор]):
-# '''[[OPF]]''' (OPEN Process Framework) – один из ранних стандартов, представляет собой свободный набор компонентов для создания процессов ЖЦ на уровне проекта.
+# '''[[OPF]]''' (OPEN Process Framework) – один из ранних стандартов, представляет собой свободный набор компонентов для создания процессов [[ЖЦ]] на уровне проекта.
-# '''[[OMG SPEM 2.0]]'''
+# '''[[OMG SPEM 2.0]]''' - открытый стандарт [[OMG]] на базе профиля [[UML]] 2, предлагающий унифицированный способ представления ЖЦ.
-#* К недостаткам этого стандарта можно отнести то, что в нём не проработаны вопросы соотнесения описываемого в нём метода и реального предпринятия (endeavor, актуального воплощения метода), нет никаких средств к работе с моделями как рабочими продуктами, ограничена иерархия практик.
-#* Как и все остальные "инженерии", ситуационная инженерия методов как метод разработки имеет свою аббревиатуру для обозначения "автоматизированной ситуационной инженерии методов" -- CAME (computer-aided method engineering, с потерей слова "ситуационная" - по аналогии с [[CASE]] -- computer-aided software engineeering), и свои инструменты -- CAME tools (ср. CASE tools).
-#* Главное достоинство OMG SPEM 2.0: это единственный стандарт, для которого уже сейчас существует приемлемый софт -- EPF Composer: http://ailev.livejournal.com/764182.html.
-#* Есть довольно много описаний "лучших практик" (от RUP до SCRUM и XP, с десятком промежуточных по степени agility), выполненных в соответствии с этим стандартом -- как свободных (http://epf.eclipse.org/), так и поставляемых коммерчески вместе с "улучшителем" для EPF Composer (IBM Rational Method Composer, впрочем там не слишком много улучшений за дополнительных $400): http://www-01.ibm.com/software/awdtools/rmc/, и там идти в http://www-01.ibm.com/software/awdtools/rmc/library/.
-#* Пример моделирования, который сделал vvagr: http://community.livejournal.com/incose_ru/10384.html
-#* Есть еще и русский перевод help к EFP Composer.
 # '''ISO 24744'''
 #* Не нужно путать ISO 24744 (метамодель для методов разработки) и [[ISO 24774]] (формат описания практики, использовавшийся при создании ISO 15288). Хотя ничего не мешает использовать оба этих стандарта вместе, они друг другу не противоречат. Более того ISO 24744 гармонизирован с ISO 15288.

@@ Строка 6: / Строка 6: @@
 ** '''акторов''' (люди и инструменты, являющиеся продолжением людей),
 ** '''[[Работы|работы]]''' (взятые как разворачивающиеся во времени жизненные циклы, и как практики "того, что должно делаться"),
-** '''[[Рабочий продукт|рабочие]]''' продукты aka артефакты (модели, документы), языки и нотации, руководства и т.д.
+** '''[[Рабочий продукт|рабочие продукты]]''' или артефакты (модели, документы), языки и нотации, руководства и т.д.
 Cм. [http://www.jucs.org/jucs_16_3/situational_method_engineering_state/jucs_16_03_0424_0478_henderson.pdf Последний (март 2010г.) обзор состояния ситуационной инженерии методов].
@@ Строка 16: / Строка 16: @@
 Ситуационная инженерия методов даёт описания, трудно совместимые с традиционно понимаемыми мелко детализуемыми "логическими процессами", описываемыми в [[IDEF0]], или еще более мелко детализуемыми (потому как для части из них подразумевается исполнение компьютером, которому всё нужно разжёвывать до мельчайших деталей и нельзя надеяться на понимание каких-то умолчаний) "физическими процессами", описываемыми в [[EPC]]/ARIS или [[OMG BPMN|BPMN]] 2.0. Описания методов конвертируются обычно не в workflow, а в projects - и соответствующий софт умеет выгружать ситуационные методы в виде проектов MS Project. Тем самым, реализации метода (endeavor) проще рассматривать как "проекты", а не как "процессы".
-SME конкурирует с "готовыми методами" (off-the-shelf-methodologies), которыми торгуют большие компании: методологии разработки, которые one-size-fit-all, и должны быть далее внедрены полностью для того, чтобы работать. Как правило, эти методологии нестандартно оформлены.
+SME конкурирует с "готовыми методологиями" (off-the-shelf-methodologies), которыми торгуют большие компании: методологии разработки, которые one-size-fit-all, и должны быть далее внедрены полностью для того, чтобы работать.
 == Поколения SME ==
 Появились два поколения ситуационной инженерии методов и отражающих эти поколения стандартов:
 * I поколение, ориентированное на методологов, которым нужно было описывать методы работы и систематизировать эти методы работы.
-  ''Стандарты OPF, ISO 24744 и OMG SPEM 2.0. ([http://www.jucs.org/jucs_16_3/situational_method_engineering_state/jucs_16_0%203_0424_0478_henderson.pdf см. обзор])''
+*: ''Стандарты OPF, ISO 24744 и OMG SPEM 2.0. ([http://www.jucs.org/jucs_16_3/situational_method_engineering_state/jucs_16_0%203_0424_0478_henderson.pdf см. обзор])''
 * II поколение, ориентированное на инженеров (пользователей описаний).
-  ''Стандарт OMG Essence ([http://www.omg.org/spec/Essence/ версия 1.0 была выпущена в ноябре 2014])''
+*: ''Стандарт OMG Essence ([http://www.omg.org/spec/Essence/ версия 1.0 была выпущена в ноябре 2014])''
 === I поколение SME ===
 Был разработан ряд стандартов ситуационной инженерии методов, которые определяют '''"метамодель"''' метода - из каких компонентов состоит метод, характеристики этих компонент, и связи между компонентами. Среди этих стандартов наиболее известны (см. [http://ailev.livejournal.com/763554.html краткий обзор]):
-# '''[[OPF]]''' - один из ранних стандартов. См. [http://opfro.org/ пример онлайн-каталога методов системной инженерии] (более 1100 компонент методов)
+# '''[[OPF]]''' (OPEN Process Framework) – один из ранних стандартов, представляет собой свободный набор компонентов для создания процессов ЖЦ на уровне проекта.
 # '''[[OMG SPEM 2.0]]'''
 #* К недостаткам этого стандарта можно отнести то, что в нём не проработаны вопросы соотнесения описываемого в нём метода и реального предпринятия (endeavor, актуального воплощения метода), нет никаких средств к работе с моделями как рабочими продуктами, ограничена иерархия практик.