Jump to content

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

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

Библиография [ править ]

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

См. также [ править ]

Ссылки [ править ]

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

Внешние ссылки [ править ]

Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 49cfca5d388845f27e95f13e6b6eaac9__1693845420
URL1:https://arc.ask3.ru/arc/aa/49/c9/49cfca5d388845f27e95f13e6b6eaac9.html
Заголовок, (Title) документа по адресу, URL1:
Goal modeling - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)