5.​ Прототипы и обоснование идеи. Этот артефакт приводится для лучшего осмысления проекта и оценки технических идей. Как правило используется, если есть несколько вариантов и нужно выбрать один из них.

6.​ План итерации. Описывает что предстоит делать на первой итерации фазы развития.

7.​ План на следующую фазу и план разработки. Приблизительный план фазы развития. Описания средств, человеческих ресурсов, необходимых навыков и других ресурсов.

8.​ Набор инструментов. Описание этапов унифицированного процесса и артефактов данного проекта.

20. Понятие требования к информационной системе, типы и категории требований

Требование – возможности или условия, которым должны соответствовать система или проект. Основной задачей этапа определения требований является поиск, обсуждение и фиксация того, что действительно требуется от системы в форме понятной и клиентам, и членам команды разработчиков.

В контексте унифицированного процесса изменение требований считается главным двигателем прогресса. Таким образом унифицированный процесс предлагает систематизированный подход к поиску, документированию, организации и отслеживанию изменчивых требований к системе.

Типы и категории требований.

Существуют несколько принципов систематизации требований. Самый часто используемые это стандарт ISO 9126, и во многом аналогичный ему модель FURPS+. Хотя можно использовать любой принцип в рамка унифицированного процесса принято пользоваться моделью FURPS+.

Согласно модели FURPS+ требования делятся на следующие категории:

1.Функциональные требования. Functionality Свойства,

возможности и вопросы безопасности.

2.Удобства. Usability. Человеческий фактор, справочная система и документация.

3.Надежность Reliability. Частота сбоев, возможность восстановления и предсказуемость поведения.

4.Производительность. Performance. Время отклика, точность, доступность, использования ресурсов.

5.Возможность поддержки. Supportability. Адаптивность,

соответствие международным стандартам,

6.Символ “+” означает дополнительные (не определяющие)

факторы:

A.Реализация – требования к ресурсам, языки и средства, аппаратное обеспечение.

B.Интерфейс – ограничение, накладываемое необходимостью взаимодействия с внешними системами.

C.Операция – управление системой и ее параметрами

D.Юридические вопросы, например, авторское право.

Категории данной модели используются при формулировании требований, чтобы не упустить важные аспекты жизнедеятельности системы. Некоторые из этих требований (удобство, надежность, производительность, возможность поддержки называются атрибутами качества.) Не смотря на то, что атрибуты качества не являются функциональными требованиями они оказывают значительное влияние на архитектуру системы. Кроме того, существует более грубое деление (классификация) требований на функциональные и нефункциональные. Функциональные требования относятся к поведению системы, нефункциональные это все остальные.

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

1.Модель прецедентов.

2.Дополнительная спецификация.

3.Словарь терминов.

4.Видение.

5.Бизнес правила.

21. Понятие прецедента в процессе моделирования требований к информационной системе, модель прецедентов.

Прецедент (use case) — это описание поведения системы с точки зрения пользователя: какие действия она выполняет, как взаимодействует с внешними субъектами, приносит ли пользователю ценность.

Описывает функциональные требования.

Представляет собой сценарий, который начинается с действия актора и заканчивается достижением цели.

Может быть представлен как основной сценарий и

альтернативные пути.

Модель прецедентов — графическое представление всех прецедентов и их связей в виде диаграммы UML.

Элементы модели прецедентов:

●​ Акторы – субъекты, взаимодействующие с системой. ●​ Функциональные блоки.

●​ Связи между ними :

●​ Ассоциация (актор ↔ прецедент)

●​ Расширение (<<extend>>)

●​ Использование (<<include>>) ●​ Наследование

22. Понятие исполнителя в процессе формализации

требований к информационной системе

Исполнитель (actor) – сущность, обладающая поведением, компьютерная система или организация.

К числу исполнителей может относится сама система, если она вызывает службы других систем. Различают три типа внешних по отношению к разрабатываемой системе исполнителя:

1.Основной исполнитель (primary) – его задача выполняется с использованием системы. Этот тип используется для определения целей пользователя, на основе которых формулируются прецеденты.

2.Вспомогательный исполнитель (supporting) – обслуживает систему, например предоставляет информацию. Используется для определения внешних интерфейсов и протоколов.