GORE — различия между версиями
Admin (обсуждение | вклад) (Новая страница: «'''Целеориентированная системная инженерия''' (goal-oriented requirements engineering, GORE) подразумевает бо…») |
Admin (обсуждение | вклад) |
||
| Строка 1: | Строка 1: | ||
| − | '''Целеориентированная системная инженерия''' (goal-oriented requirements engineering, GORE) подразумевает более или менее формальное описание дополнительных по отношению к требованиям сущностей (таких как стейкхолдеры, цели, влияния, аргументы в защиту, альтернативы и т.д.). | + | '''Целеориентированная системная инженерия''' (goal-oriented requirements engineering, GORE) подразумевает более или менее формальное описание дополнительных по отношению к требованиям сущностей (таких как стейкхолдеры, цели, влияния, аргументы в защиту, альтернативы и т.д.). Это так называемая "ранняя инженерия требований" (early requirement engineering), в самом начале проекта, когда еще непонятно что делать: цели, намерения, концептуальное моделирование (см., например, [http://mis.sauder.ubc.ca/rigim2008/ (1)] и [http://www.cin.ufpe.br/~rigim09/ (2)] и там темы и работы авторов из оргкомитета). |
Это даёт возможность: | Это даёт возможность: | ||
| Строка 8: | Строка 8: | ||
'''Модель требования''' — получаемая сложная структура всех этих стейкхолдеров-целей-влияний-альтернатив-требований-аргументов-и_т.д. | '''Модель требования''' — получаемая сложная структура всех этих стейкхолдеров-целей-влияний-альтернатив-требований-аргументов-и_т.д. | ||
| − | Использующая такие модели инженерия требований — [[Инженерия требований#Моделеориентированная инженерия требований|моделеориентированной инженерией требований]]. | + | Использующая такие модели инженерия требований — [[Инженерия требований#Моделеориентированная инженерия требований|моделеориентированной инженерией требований]]. |
| + | Пересекаются два основных языка: use cases и собственно целеориентированные языки. Cм. например: | ||
| + | * [http://ailev.livejournal.com/800769.html редактор нотации пользовательских требований] | ||
| + | * [http://ailev.livejournal.com/810548.html список нотаций для работы социотехника в инженерии требований]. | ||
| − | [[ | + | Основная идея целеориентированности в инженерии требований: '''"требования возникают из-за того, что люди что-то хотят, у них есть цели. Давайте обсудим цели в сочетании со средствами их достижения. Заодно запишем, чьи эти цели — и при разбирательстве развилок в выборе средств будет появляться много-много традиционно выглядящих требований"'''. |
| + | |||
| + | Сюда можно отнести: | ||
| + | * [http://jucmnav.softwareengineering.ca/ucm/bin/view/UCM/UCMVirtualLibraryAllPubs URN] (User requirements notation, в которой целеориентированный язык GRL, goal requirements language). Хотя основной упор в литературе и делается на use case maps (подозрительно напоминающая BPMN нотация), в последние годы есть публикации и по GRL. | ||
| + | * чего хотят в URN=GRL+UCM? [http://www.cs.toronto.edu/km/GRL/from-r2a/fromr2a/straw01.pdf Перехода от инженерии требований к архитектурному проектированию] | ||
| + | * [http://istar.rwth-aachen.de/tiki-index.php?page_ref_id=200 подход агентского программирования i*], в котором тоже предложена неформальная нотация для инженерии требований (имеющая множество вариантов): [http://istar.rwth-aachen.de/tiki-index.php?page=Requirements%20Engineering список литературы] обрывается на 2005 году, но это далеко не конец истории. | ||
| + | * NOMOS, подход к целеориентированному моделированию требований в техническом регулировании (требования+права): [https://sites.google.com/site/albertosiena/ работы Alberto Siena] | ||
| + | * [http://www.omg.org/spec/BMM/1.1/Beta2/PDF/ OMG BMM], где дается тот же анализ "целей-средств" | ||
| + | * [http://praxos.ru/index.php/%D0%9A%D0%B0%D1%80%D1%82%D0%B0_%D0%B4%D0%B5%D0%B9%D1%81%D1%82%D0%B2%D0%B8%D0%B9_%D0%B8_%D1%80%D0%B5%D0%B7%D1%83%D0%BB%D1%8C%D1%82%D0%B0%D1%82%D0%BE%D0%B2 карты действий и результатов] Голдратта (напомню, что оригинальный язык там такой: Strategy and Tactics tree, и кроме этих Strategy и Tactic указываются разные Assumptions), которые сводятся к более-менее структурированному представлению тех же means-ends (целей-средств) с их каким-то обоснованием (но про собственно обоснования — позже, ибо карты действий и результатов Голдратта появляются не столько в начале жизненного цикла, сколько ближе к его концу — и тем самым попадают больше в "обоснования"). | ||
| + | * [http://www.cs.toronto.edu/km/goal_oriented/index.html Goal-oriented software engineering] — это опять про то же самое: [http://www.utdallas.edu/~chung/BOOK/book.html как справиться с нефункциональными требованиями в программной инженерии], тут же [http://www.cs.toronto.edu/cser/aore.html аспект-ориентированная инженерия требований] и так далее все про инженерию требований. В основе этого подхода — The tradeoffs among goals, soft-goals, tasks and resources are represented in a soft-goal interdependence graph (SIG). | ||
| + | * в [[ArchiMate]] 2.0 ([http://ailev.livejournal.com/978200.html вышел 31 января 2012г.]) требования к архитектуре задаются дополнением целеполагания (motivational) и полностью соответствуют подходу GORE. | ||
| + | |||
| + | |||
| + | [[Категория:Дисциплины]] | ||
Версия 22:32, 25 ноября 2015
Целеориентированная системная инженерия (goal-oriented requirements engineering, GORE) подразумевает более или менее формальное описание дополнительных по отношению к требованиям сущностей (таких как стейкхолдеры, цели, влияния, аргументы в защиту, альтернативы и т.д.). Это так называемая "ранняя инженерия требований" (early requirement engineering), в самом начале проекта, когда еще непонятно что делать: цели, намерения, концептуальное моделирование (см., например, (1) и (2) и там темы и работы авторов из оргкомитета).
Это даёт возможность:
- более точно документировать происхождение требований,
- обосновывать выбор требований,
- связывать выбор проектных решений (архитектурных решений) с требованиями.
Модель требования — получаемая сложная структура всех этих стейкхолдеров-целей-влияний-альтернатив-требований-аргументов-и_т.д.
Использующая такие модели инженерия требований — моделеориентированной инженерией требований.
Пересекаются два основных языка: use cases и собственно целеориентированные языки. Cм. например:
- редактор нотации пользовательских требований
- список нотаций для работы социотехника в инженерии требований.
Основная идея целеориентированности в инженерии требований: "требования возникают из-за того, что люди что-то хотят, у них есть цели. Давайте обсудим цели в сочетании со средствами их достижения. Заодно запишем, чьи эти цели — и при разбирательстве развилок в выборе средств будет появляться много-много традиционно выглядящих требований".
Сюда можно отнести:
- URN (User requirements notation, в которой целеориентированный язык GRL, goal requirements language). Хотя основной упор в литературе и делается на use case maps (подозрительно напоминающая BPMN нотация), в последние годы есть публикации и по GRL.
- чего хотят в URN=GRL+UCM? Перехода от инженерии требований к архитектурному проектированию
- подход агентского программирования i*, в котором тоже предложена неформальная нотация для инженерии требований (имеющая множество вариантов): список литературы обрывается на 2005 году, но это далеко не конец истории.
- NOMOS, подход к целеориентированному моделированию требований в техническом регулировании (требования+права): работы Alberto Siena
- OMG BMM, где дается тот же анализ "целей-средств"
- карты действий и результатов Голдратта (напомню, что оригинальный язык там такой: Strategy and Tactics tree, и кроме этих Strategy и Tactic указываются разные Assumptions), которые сводятся к более-менее структурированному представлению тех же means-ends (целей-средств) с их каким-то обоснованием (но про собственно обоснования — позже, ибо карты действий и результатов Голдратта появляются не столько в начале жизненного цикла, сколько ближе к его концу — и тем самым попадают больше в "обоснования").
- Goal-oriented software engineering — это опять про то же самое: как справиться с нефункциональными требованиями в программной инженерии, тут же аспект-ориентированная инженерия требований и так далее все про инженерию требований. В основе этого подхода — The tradeoffs among goals, soft-goals, tasks and resources are represented in a soft-goal interdependence graph (SIG).
- в ArchiMate 2.0 (вышел 31 января 2012г.) требования к архитектуре задаются дополнением целеполагания (motivational) и полностью соответствуют подходу GORE.