Моделирование целей - Goal modeling

А модель цели является элементом разработка требований которые также могут быть более широко использованы в бизнес-анализ. Связанные элементы включают анализ заинтересованных сторон, контекстный анализ, и сценарии,[1] среди других деловых и технических областей.

Принципы

Цели - это задачи, которые система должна достигнуть посредством сотрудничества субъектов в предполагаемом программном обеспечении и в среде.[2] Моделирование целей особенно полезно на ранних этапах проекта. Проекты могут учитывать, как предполагаемая система соответствует целям организации (см. Также [3]), зачем нужна система и как можно учесть интересы заинтересованных сторон.[4]

Модель цели:

  • Выражает отношения между системой и ее средой (т.е. не только то, что система должна делать, но и почему). Понимание, которое это дает, причин, по которым система необходима в ее контексте, полезно, потому что «системы все чаще используются для фундаментального изменения бизнес-процессов, а не для автоматизации давно установленных практик».[5][6]
  • Разъясняет требования. Определение целей приводит к вопросу «почему», «как» и «как еще».[5] В этом процессе часто выявляются требования заинтересованных сторон, с меньшим риском либо отсутствия требований, либо чрезмерной спецификации (просьбы о вещах, которые не нужны).
  • Позволяет разложить большие цели на маленькие, достижимые:
  • Устранение конфликтов: моделирование целей может определить и помочь найти компромисс между стоимостью, производительностью, гибкостью, безопасностью и другими целями. Это может выявить различные интересы заинтересованных сторон. Он может выявлять конфликты, потому что достижение одной цели может помешать достижению других целей.[5]
  • Позволяет измерить полноту требований: требования можно считать выполненными, если они соответствуют всем целям в целевой модели.
  • Связывает требования с дизайном: например, структура i * «Нефункциональные требования (NFR)» использует цели для управления процессом проектирования.

Обозначения

Есть несколько обозначений, используемых для целевых моделей при разработке программного обеспечения, в том числе:

Другие обозначения были предложены исследователями,[10] в то время как нотация структурирования цели (GSN) и GRL иногда используются для случаи безопасности чтобы удовлетворить регулирующий орган в отраслях, связанных с безопасностью.[11][12]

Моделирование целей в i *

Основная статья: я*

Обозначение моделирования цели i * предоставляет два вида диаграмм:[13]

  • «Стратегическая зависимость» (SD), определяющая отношения между ролями с точки зрения конкретных целей, которые одна роль зависит от другой роли.
  • «Стратегическое обоснование» (SR), анализ целей, определенных в модели SD, на вспомогательные цели и задачи.

i * показывает каждую роль (актера, агента или должность) в виде большого круга, содержащего цели, задачи и ресурсы, принадлежащие этой роли. Принадлежность к i * означает, что роль желает удовлетворения своих целей либо для собственной выгоды, либо для выгоды какой-либо другой роли. Цели могут сопровождаться «препятствиями» (отрицательными целями), которые необходимо преодолеть. Нефункциональные цели можно смоделировать как «мягкие цели» в i *: они изображены в виде облаков или овалов с отступом.

Моделирование целей в KAOS

Основная статья: КАОС (разработка программного обеспечения)

Обозначение моделирования целей KAOS обеспечивает способ определения целей и препятствий, основанный на формальном (математическом) методе анализа.[8]

Моделирование целей в UML

Основная статья: Диаграмма вариантов использования

UML диаграмма вариантов использования обеспечивает простую нотацию моделирования целей. Пузырьки называют функциональные цели,[14] Таким образом, диаграмма вариантов использования формирует простую целевую модель, состоящую только из функций: как пишет Кокберн, варианты использования охватывают только поведенческие требования.[15] Роли показаны как действующие лица (человечки на диаграмме), связанные с вариантами использования, в которых они принимают участие. Сценарии использования нарисованы в виде эллиптических пузырей, представляющих желаемые поведенческие цели.[16]

С добавлением случаи злоупотребления, нотация может моделировать как желаемые цели, так и активные угрозы. Обозначение случаев неправомерного использования показывает отрицательные (возможно враждебные) заинтересованные стороны как основные действующие лица в случаях неправомерного использования; их можно сгруппировать в правой части диаграммы. Обозначение может помочь в обнаружении подходящих смягчающих или профилактических целей, показанных как дополнительные варианты использования. Они часто имеют целью повышение безопасности, защищенности или надежности, что не является функциональной целью. Нефункциональные требования в некоторой степени могут быть описаны в стиле вариантов использования с использованием случаев неправильного использования для определения отрицательных целей; но обнаруженные таким образом (положительные) цели часто являются функциональными. Например, если кража угрожает безопасность, то примерка замков - смягчение; но то, что дверь может быть заперта, является функциональным требованием.[17]

Противоположным моментом является то, что варианты использования не имеют корней когнитивной науки, в то время как i * и KAOS - корни. Действительно, литература, посвященная вариантам использования, не включает обсуждение «Намерение цели», «Уточнение цели», «Конечное средство», не упоминает Расмуссена и так далее. Может существовать склонность связывать варианты использования с целями из-за визуальной метафоры целей, а не семантики уточнения целей согласно когнитивным наукам.

Библиография

  • Александр, Ян и Беус-Дукич, Лерка. Обнаружение требований: как указать продукты и услуги. Wiley, 2009.
  • Александр, Ян Ф. и Дева, Нил. Сценарии, истории, сценарии использования. Wiley, 2004.
  • Кокберн, Алистер. Написание эффективных сценариев использования. Аддисон-Уэсли, 2001.
  • Фаулер, Мартин. UML дистиллированный. 3-е издание. Аддисон-Уэсли, 2004.
  • ван Ламсверде, Аксель. Разработка требований: от целей системы до моделей UML и спецификаций программного обеспечения. Wiley, 2009.
  • Ю, Эрик, Паоло Джорджини, Нил Мейден и Джон Милопулос. (редакторы) Социальное моделирование для разработки требований. MIT Press, 2011.

Рекомендации

  1. ^ Александр и Беус-Дукич, 2009. Стр. 17-18.
  2. ^ Линь Лю и Эрик Ю (2003). «Проектирование информационных систем в социальном контексте: подход к моделированию целей и сценариев» (PDF). Университет Торонто. Архивировано из оригинал (PDF) 5 февраля 2005 г.
  3. ^ Ellis-Braithwaite, R .; Lock, R .; Dawson, R .; Хак Б. (2013). «К подходу к анализу стратегического согласования требований к программному обеспечению с использованием количественных диаграмм целей». Международный журнал достижений в области программного обеспечения. 6: 119–130. arXiv:1307.2580. Bibcode:2013arXiv1307.2580E.
  4. ^ Э. Ю, "На пути к моделированию и обоснованию поддержки для разработки требований на ранней стадии", 1997 IEEE
  5. ^ а б c Эрик Ю и Джон Милопулос. "Почему разработка требований, ориентированная на достижение цели". Университет Торонто.
  6. ^ K.Pohl и P. Haumer, "Моделирование контекстной информации о сценариях", Proc. 3-й Int. Семинар по разработке требований: основы качества программного обеспечения REFSQ ’97, Барселона, Каталония, Испания, июнь 1997 г., стр. 187-204.
  7. ^ Ю. и др., 2011.
  8. ^ а б ван Ламсверде, 2009.
  9. ^ Fowler, 2004. Pages 99-105.
  10. ^ Роллан, Колетт; Пракаш, Навин; Бенджамен, Адольф (1999). «Многомодельный взгляд на моделирование процессов» (PDF). Разработка требований. 4 (4): 169–187. Дои:10.1007 / s007660050018.
  11. ^ Стандарт сообщества GSN
  12. ^ Федоров Р. (2016). «Преднамеренная архитектура предприятия». Ежегодная системная конференция IEEE 2016 (SysCon): 1–8. Дои:10.1109 / SYSCON.2016.7490555. ISBN  978-1-4673-9519-9.
  13. ^ Ю, Эрик (6 сентября 2011 г.). "я*". i *: среда моделирования, ориентированного на агент и цель. Университет Торонто. Получено 17 декабря, 2011.
  14. ^ Александр и Беус-Дукич, 2009. Стр. 121
  15. ^ Кокберн, 2001. Стр. 62
  16. ^ Кокберн, 2001. Стр. 221.
  17. ^ Александр и Дева, 2004. Глава 7. Страницы 119-139.

внешняя ссылка