Оценка трудоемкости разработки программного обеспечения. Учебное пособие

Расширения:

2а. Пользователь не принимает соглашение.

2а1. Система выходит из процесса регистрации.

8а. Пользователь неправильно заполняет форму.

8а1. Система выводит сообщение об ошибке и предоставляет форму еще раз.

8б. Пользователь вводит существующее имя пользователя.

8б1. Система выводит сообщение и предоставляет форму еще раз.

Аутентификация

Основное действующее лицо: клиент.

Гарантия успеха: пользователь аутентифицировался в системе. Триггер: пользователь входит в систему.

Основной сценарий:

1.Система предоставляет форму для аутентификации.

2.Пользователь вводит имя пользователя и пароль.

3.Пользователь подтверждает введенную информацию.

4.Система аутентифицирует пользователя. Расширения:

3а. Пользователь отказывается от аутентификации.

3а1. Система возвращается на предыдущий уровень.

3b. Пользователь забыл пароль.

3b1. Пользователь выбирает элемент интерфейса «Забыл пароль».

3b2.Системапредоставляетформу«Восстановлениезабытогопароля», содержащую информацию об адресе администратора, к которому может обратиться пользователь.

3b3. Пользователь подтверждает получение информации.

3b4. Система возвращается на предыдущий уровень.

4a.Пользовательвводитнеправильныеимяпользователяилипароль.

4a1. Система выводит сообщение об ошибке и предоставляет форму еще раз.

4b. Пользователь превышает лимит попыток аутентификации.

4b1. Система выводит сообщение, блокирует имя пользователя и возвращается на предыдущий уровень.

Формирование функциональных требований. Для формирова-

ния функциональных требований рассматривают сценарии вариантовиспользованияивыделяюттедействия,которыедолжна осуществлять система. Эти действия и являются основой для функциональныхтребований.Ихнеобходимопроанализировать, детализировать слишком крупные, обобщить слишком мелкие,

21

исключитьповторяющиесяиорганизовать.Подорганизациейпо- нимаютгруппировкутребованийпокакому-либопризнаку.Одна из наиболее популярных группировка по вариантам использования. Рассмотрим ее более подробно. Требования формируются в виде: Номер требования. Формулировка требования. Например: 1. В системе должны быть предусмотрены средства регистрации пользователя.

П р и м е р 5. Пользовательские функциональные требования по вари- антам использования «Регистрация» и «Аутентификация». Система должна предоставлять:

1. Возможность регистрации.

1.1.Пользователь выбирает уникальное имя пользователя и пароль.

1.2.Пользователь вводит дополнительную информацию: имя, фамилию, день рождения, пол.

1.3.Пользователь вводит дополнительную информацию в ситуации, если забыл пароль.

2.Возможностьаутентификациизарегистрированныхпользователей.

2.1.Пользователь идентифицируется с помощью уникального имени пользователя и пароля.

2.2.Проводитсяпроцедураблокировкиименипользователя,есличисло попыток ввода превысило лимит попыток аутентификации.

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

1.3. Нефункциональные требования

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

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

Так как многие нефункциональные требования относятся к системевцелом,тоонимогутбытьболеекритичны,чемфункциональные.

22

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

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

ксистеме.

Воснове классификации требований, как отмечалось ранее, лежит модель FURPS+.

Типытребований,относящиесякURPS+(сдетализацией,позволяющей получить их количественную оценку), выглядят следующим образом:

U. Удобство, практичность

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

U2.Требованияпростотыиспользования:времявыполнения типичных задач (т. е. задач, которые чаще всего будут выполняться при работе системы), осуществляемых конечным пользователем.

U3. Требования соответствия соглашениям и стандартам для человеко-машинногоинтерфейса(наличиесредствнавигации,на- борсредствграфическогоинтерфейса,наличиесредствподдержки разных языков и т. д.).

U4. Наличие процедур для startup, backup, recovery и т. д. U5. Наличие документации на программное обеспечение. U6. Требования к средствам инсталляции.

23

R. Надежность

R1. Доступность: время (в процентном выражении), в течение которого пользователи должны иметь возможность использовать услуги, предоставляемые системой.

R2. Среднее время между отказами.

R3. Среднее время восстановления.

P. Производительность

P1. Время ответа для различных типов операций.

P2. Пропускная способность: число транзакций в секунду.

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

P4. Время реакции на действия пользователя.

P5. Время обновления экрана.

S. Возможность обслуживания

S1. Адаптивность.

S2. Возможность конфигурирования.

S3. Возможность обслуживания, требования к простоте внесения изменений.

+. Дополнительные требования

Архитектурные требования:

+1. Требования распределенной обработки.

+2. Ориентация на повторное использование.

+3. Ориентация на многоплатформенную работу.

+4. Требования к безопасности.

Ограничения проектирования:

+5. Операционные среды: платформы, языки, инструментальные средства.

+6. Требования, накладываемые необходимостью взаимодействия с другими системами.

+7. Соответствие отраслевым стандартам.

+8. Соответствие прикладным стандартам: использование существующих библиотек.

+9. Корпоративные наработки и стандарты: работа с существующей базой данных, использование стандартов кодирования.

24

Внешние требования:

+10. Юридические вопросы.

+11. Этические вопросы.

+12. Требования о сохранении конфиденциальности.

Пример 6.Нефункциональныетребованиядлясистемызаказабилетов.

Приведем несколько примеров требований, относящихся к производительности системы:

1.Прирегистрациивремяответапользователянедолжнопревышать2с.

2.Время ответа при аутентификации пользователя не должно превышать 2 с.

3.Системадолжнапозволятьработатьодновременно100пользователям.

1.4. Пользовательские требования

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

П р и м е р 7. Пользовательскиетребованияксистемезаказов.Система должна предоставлять:

1. Возможность регистрации.

1.1.При регистрации пользователь получает уникальное имя пользователя и пароль.

1.2.Пользователь вводит дополнительную информацию: имя, фамилию, день рождения, пол.

1.3.Пользователь вводит дополнительную информацию в ситуации, когда забыт пароль.

1.4.При регистрации пользователя время ответа не превышает 2 с.

2.Возможностьаутентификациизарегистрированныхпользователей.

2.1.Пользователь идентифицируется с помощью имени пользователя

ипароля.

2.2.Проводитсяпроцедураблокировкиименипользователя,есличисло попыток ввода превысило лимит попыток аутентификации.

2.3.Проводится процедура определенных действий в ситуации, когда пользователь забыл пароль.

2.4.При аутентификации время ответа пользователя не должно пре-

вышать 2 с.

25

1.5. Разработка специфицированных требований

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

П р и м е р 8. Фрагмент специфицированных требований (SRS) раздела

«Аутентификация»

26

Окончание

1.6. Описание проекта заказа билетов через Интернет

Введение. Описание требований к проекту выполнено в виде совокупностисценариев,описывающихвзаимодействиеклиентов и сотрудников с системой заказа билетов.

Система: программно-аппаратный комплекс, предоставляющий справочную информацию и обеспечивающий возможность заказа билетов с участием оператора через Интернет. К основным функциям системы относятся:

1.Предоставлениесправочнойинформациионаличиибилетов.

2.Ведение базы данных клиентов (добавление, изменение).

3.Ведение «черного списка» клиентов.

4.Ведениебазыданныхзаказов(добавление,изменение,удаление).

27

5.Мониторинг исполнения заказов (обработка, оплата).

6.Ведение базы данных мест продажи билетов (добавление, изменение, удаление).

7.Ведениебазыданныхпользователей(добавление,изменение, удаление).

8.Предоставление статистики работы системы.

Врамкахописываемойтехнологииопределеныследующиедействующие лица (роли).

Клиент: пользователь системы, желающий заказать билеты. Оператор: сотрудник, выполняющий оформление заказа.

Администраторсистемызаказов:сотрудник,выполняющийконт-

рольные функции.

Исполнителиролейоператораиадминистраторасистемызаказов назначаются в соответствии с должностными обязанностями и наличием ресурсов. При необходимости один сотрудник может совмещать роли оператора и администратора.

Действующим лицам система предоставляет следующие возможности.

Клиент:

1.Получение справочной информации.

2.Регистрация пользователя.

3.Заказ билетов.

4.Мониторинг исполнения заказа.

5.Отмена заказа.

Оператор: оформление заказа.

Администратор системы заказов:

1.Учет проданных билетов.

2.Удаление клиента из «черного списка».

3.Добавление нового пользователя.

4.Редактирование пользователя.

5.Удаление пользователя.

6.Получение отчетов (статистики работы системы).

Диаграмма вариантов использования системы заказа билетов че-

рез Интернет. Диаграмма вариантов использования представлена на рис. 8.

28

Рис. 8. Диаграмма вариантов использования системы заказа билетов через Интернет

29

Сценарии технологии заказа билетов через Интернет

Клиент:получениесправочнойинформации,регистрацияпользователя, аутентификация, заказ билета, мониторинг состояния заказа, отмена заказа.

Получение справочной информации

Основное действующее лицо: клиент.

Триггер: клиент выбирает элемент интерфейса «Справочная информация о наличии билетов».

Основной сценарий:

1.Система выводит форму параметров запроса.

2.Клиент заполняет форму.

3.Система предоставляет запрошенную справку.

4.Клиентпереходиткзаказубилетовиливозвращаетсяксправке. Расширения:

3а. Клиент заполняет только часть необходимых полей.

3а1. Клиент заполняет только часть необходимых полей или ошибается при заполнении формы.

3а2. Система выводит сообщение об ошибке и предлагает заполнить форму еще раз или уточнить информацию.

2а, 4а. Клиент отказывается от просмотра справочной информации.

4а1. Система возвращается на предыдущий уровень.

Регистрация пользователя

Основное действующее лицо: пользователь. Гарантия успеха: пользователь зарегистрировался.

Триггер: пользователь выбирает элемент интерфейса «Регистрация».

Основной сценарий:

1.Система предоставляет пользователю условия пользовательского соглашения.

2.Пользователь принимает соглашение.

3.Система предоставляет регистрационную форму.

4.Пользователь выбирает имя пользователя и пароль.

5.Пользователь выбирает или отмечает вопрос, который будет задан, в случае если он забыл пароль.

30