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

Знаниявобластиформированиятребованийимеютприкладной характер.Всвязисэтиммногиеособенностиразличныхподходов необходимообъяснятьнаконкретныхпримерах.Дляиллюстрации процессов разработки требований и оценки трудозатрат рассмотрим проект разработки системы заказа билетов через Интернет.

Проблема,которуюрешаетсистемазаказа,выглядитследующим образом. Заказчик предоставляет услугу продажи билетов. Чтобы не усложнять систему деталями предметной области, не оговаривается, какие именно билеты (авиа, железнодорожные, в кино, театрит.д.)продаются.Заказчикимеетсистемупродажибилетов, которая выполняет следующие основные функции:

–справка о наличии билетов;

–резервирование билетов;

–продажа билетов.

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

1.2. Функциональные требования

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

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

Действующее лицо – это лицо, определяющее роли, которые пользователисистемымогутигратьпривзаимодействиисданной

11

системой. Пользователем может быть человек или внешняя система. Действующее лицо – кто-то или что-то, обладающее поведением.

Основноедействующеелицо–действующеелицо,инициирующее взаимодействие с системой для достижения некоторой цели.

Сценарий варианта использования – последовательность дей-

ствий, при которых система приносит действующему лицу полезный и понятный результат (основной сценарий) и различные отклонения от этой последовательности (расширения).

Процесс формирования модели вариантов использования состоит из следующих основных шагов:

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

2.Поиск вариантов использования.

3.Разработка модели вариантов использования.

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

1.Какимгруппампользователейтребуетсяпомощьсистемыпри решении их задач?

2.Какие группы пользователей необходимы для выполнения наиболее очевидных главных функций системы?

3.Какиегруппыпользователейтребуютсядлявыполнениявторичных функций, например эксплуатации и администрирования системы?

4.Взаимодействуетлисистемасвнешнейаппаратнойилипрограммной системой?

Любойиндивидуум,группаилиявление,ответившиехотябы наодинизэтихвопросов,–кандидатнарольдействующеголица.

П р и м е р 1. Поиск действующих лиц

Поиск действующих лиц системы заказа билетов. Главные функции си-

стемы–получениеинформациионаличиибилетов,ихзаказиоформление.

12

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

Ответим на второй вопрос. Для выполнения функций получения информации о наличии билетов и для оформления билетов надо иметь систему продажи билетов. Ее необходимость подтверждается и ответом на последний, четвертый вопрос.

Следующий вопрос, на который нужно ответить: кто будет осуществлять вторичные функции администрирования и эксплуатации? Необходимо добавить еще одно действующее лицо – администратора системы.

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

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

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

ксистемезаказовинеотноситсякосновнымдействующимлицам.

Врезультате выполнения первого шага выделяют следующие основные действующие лица:

– клиент;

– оператор;

– администратор.

Кромеэтогоимеетсяодновспомогательноедействующеелицо– система продажи билетов.

Поисквариантовиспользования.Этовыделениепотребностейос-

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

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

13

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

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

Какие первичные задачи должна выполнять система?

Хочет ли действующее лицо создавать, сохранять, изменять, удалять или читать данные в системе?

Будетлидолжнодействующеелицосообщатьсистемеовнезапных внешних изменениях?

Должнолидействующеелицобытьинформированоонекоторых событиях в системе?

Хочет ли действующее лицо выполнять запуск или закончить работу системы?

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

Для того чтобы определить это, для вариантов использования введено понятие уровня цели.

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

Пользовательский уровень – это уровень целей, которые преследует действующее лицо.

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

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

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

14

объясняютсмыслэтоговзаимодействия.Именавариантовиспользования должны быть уникальными.

П р и м е р 2. Выявление потребностей основных действующих лиц

Клиент

Первичные задачи:

–справка о наличии билетов;

–заказ билетов;

–отказ от билета (сообщение о внезапных внешних изменениях);

–мониторинг заказа (информирование о некоторых событиях в системе).

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

–справка о наличии билетов;

–заказ билетов;

–отказ от билетов;

–мониторинг заказа;

–регистрация.

Вариантиспользования«Аутентификация»имеетуровеньподфункции и служит для достижения других потребностей пользователя.

Оператор

Первичная задача – оформление заказа.

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

Витоге к потребностям администратора следует отнести:

–регистрацию оператора;

–редактирование информации о пользователе (операторе, клиенте);

–удаление пользователя (оператора, клиента);

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

15

Разработкамоделивариантовиспользования.Вмодельвариантов использования включена диаграмма вариантов использования (Use Case Diagram) и сценарии (по каждому из вариантов использования).

Диаграмма вариантов использования. На диаграмме изобража-

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

Вариант использования обозначается эллипсом, внутри которого содержится его краткое имя в форме существительного или глагола с пояснительными словами (рис. 3).

Действующее лицо – фигурка человечка, под которой записывается имя действующего лица.

Между компонентами диаграммы вариантов использования могут существовать различные отношения, которые описывают взаимодействие между действующими лицами и вариантами использования.

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

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

Кратностьуказываетсярядомскомпонентомипоказываетколичествоэкземпляровданногокомпонента,которыемогутвыступать в качестве элементов ассоциации.

16

Наиболее распространены:

–целоенеотрицательноечисло(включая0).Количествоэкземпляров действующих лиц или вариантов использования, которые могут выступать в качестве элементов отношения ассоциации, равно указанному числу;

–дванеотрицательныхчисла,разделенныхдвумяточками(1..5);

–два символа, разделенных точками. Первый символ – целое неотрицательное число или 0, второй – *;

–*–произвольноенеотрицательноечисло,значениекоторогоне- известнонамоментзаданияотношения(эквивалентнозаписи«0..*»).

Отсутствие кратности эквивалентно 1.

Отношение расширения определяет взаимосвязь экземпляров варианта использования с общим вариантом, свойства которого определяютсянаосновеспособасовместногообъединенияданных экземпляров.

Отношение расширения между вариантами использования обозначается пунктирной линией со стрелкой, направленной от тоговариантаиспользования,которыйявляетсярасширениемдля исходного варианта использования. Стрелка помечается словом

«Extend» («Расширяет»).

Отношение расширения отмечает тот факт, что один из вариантов использования может присоединять к своему поведению дополнительное поведение, определенное для другого варианта использования(рис.4).Призаданиирасширенияустанавливается условиеданногоотношения.Выполнениеэтогоусловиявлияетна использование расширения.

Можетбытьнесколькорасширений,условиякоторыхпроверяются последовательно.

Отношение включения между двумя вариантами использования указывает,чтонекотороезаданноеповедениедляодноговарианта использования включается в качестве составного компонента в последовательность действий, определяющую поведение другого варианта использования (рис. 5).

Отношениевключениямеждувариантамииспользованияобозначается пунктирной линией со стрелкой, направленной от базового

17

Рис. 4. Пример отношения расширения

Рис. 5. Пример отношения включения

Клиент

Регистрация

Рис. 7. Пример диаграммы вариантов использования для системы заказа билетов

18

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

«Include» («Включает»).

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

П р и м е р 3.Фрагментдиаграммывариантовиспользованиядлясистемы заказов. На рис. 7 представлена диаграмма вариантов использования для одного действующего лица – клиента.

Сценарии вариантов использования. Диаграмма вариантов ис-

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

Основные элементы, содержащиеся в этом шаблоне:

1.Имя варианта использования. Основное действующее лицо – этолицо,потребностькоторогоудовлетворяетсясоответствующим вариантом использования.

2.Предусловие. Определяет условие, выполнение которого гарантируется перед запуском варианта использования.

3.Триггер–событие,котороезапускаетвариантиспользования.

4.Гарантия успеха. Устанавливает, что интересы участников удовлетворены.

5.Область действия. Идентифицирует рассматриваемую систему.

19

6.Уровеньцели.Онбываетобобщенный(описаниебизнес-про- цесса),уровеньцелипользователя(цель,которуюможнодостигнуть за один сеанс), уровень подцели.

7.Основной сценарий. Успешный сценарий приводит к достижению цели. Основной сценарий состоит из шагов, каждый из которых отражает действия системы или действующего лица. Для каждого шага рекомендуется формулировать действие так, чтобы оно представляло собой законченную операцию (Use Case транзакцию).

8.Расширения–отклоненияотосновногосценария.Расширения включаютвсебяописаниеситуации,котораявызвалаотклонения,

ишаги, отражающие действия системы и действующих лиц при появлении этой ситуации.

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

П р и м е р 4. Разработка сценариев вариантов использования для си-

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

Регистрация

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

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

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

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

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

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

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

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

6.Пользователь вводит ответ на вопрос.

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

8.Система регистрирует пользователя.

20