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

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

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

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

Расширения:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

обратиться пользователь.

3b3. Пользователь нажимает кнопку «Ok».

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

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

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

31

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

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

Заказ билета

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

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

1.Система показывает информацию о правилах оформления заказа на резервирование и предлагает оформить заказ.

2.Клиент проходит аутентификацию в системе.

3.Клиент выбирает элемент интерфейса «Оформить заказ».

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

5.Клиентзаполняетформуивыбираетэлементинтерфейса«Отправить заявку».

6.Системавыводитполнуюинформациюозаказеизапрашивает подтверждение заказа.

7.Клиент подтверждает заказ.

8.Система ставит заказ в очередь на оформление и сообщает клиенту номер заказа, уведомляет клиента о процедуре прохождения заказа.

Расширения:

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

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

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

8а. Клиент в «черном списке».

8а1.Системавыводитсообщениеотом,чтозаказнеможетбыть принят и предлагает обратиться к администратору службы заказа билетов.

8а2. Система прекращает обработку заказа.

2а, 4а, 6а, 8в. Клиент прерывает заполнение формы. 2а1. Система прекращает обработку заказа.

32

Мониторинг состояния заказа

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

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

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

2.Клиент вводит номер и фамилию.

3.Система показывает информацию о заказе. Расширения:

2а. Неправильный номер заказа.

2а1.Системавыводитсообщениеипредлагаетоткорректировать номер.

2б. Неправильная фамилия.

2б1.Системавыводитсообщениеипредлагаетоткорректировать фамилию.

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

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

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

1.Клиент проходит аутентификацию в системе.

2.Система предлагает ввести номер заказа.

3.Клиент вводит номер.

4.Система показывает информацию о заказе.

5.Клиент выбирает элемент интерфейса «Отменить заявку».

6.Система просит подтвердить отмену.

7.Клиент подтверждает отмену.

8.Система проводит отмену заказа.

Расширения:

3а. Неправильный номер заказа.

3а1.Системавыводитсообщениеипредлагаетоткорректировать номер.

3б. Неправильная фамилия.

3б1.Системавыводитсообщениеипредлагаетоткорректировать фамилию.

7а. Клиент не подтверждает отмену.

7а1. Система выводит сообщение и прекращает процедуру отмены заказа.

33

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

Оформление билета

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

Триггер: оператор выбирает элемент интерфейса «Оформить следующий заказ».

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

1.Выполняется аутентификация оператора.

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

3.Оператор выбирает элемент интерфейса «Обработать следующий заказ», получает информацию о заказе, проводит резервирование мест в соответствии с заказом, вводит информацию о резервировании в форму заказа и выбирает элемент интерфейса «Подтвердить резервирование».

4.Система изменяет статус выполнения заказа на «Оформленный».

Расширения:

3а.Оформлениевсоответствииспараметрамизаказанеможет быть осуществлено.

3а1.Операторвводитпричинуотказавформузаказаивыбирает элемент интерфейса «Подтвердить отказ».

3а2. Система изменяет статус заказа на «Отказанный».

Администратор системы заказов: учет проданных билетов,

удаление из «черного списка», добавление нового пользователя, редактирование пользователя, удаление пользователя, получение отчетов.

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

Основноедействующеелицо:администраторсистемызаказов. Триггер: администратор выбирает элемент интерфейса «Исто-

рия».

Предусловие: администратор должен быть зарегистрирован

в системе.

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

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

34

2.Система предлагает список заказов.

3.Оператор(наоснованииинформации,полученнойизкассы) отмечает выкупленные заказы.

4.Система проводит архивацию выкупленных заказов. Расширения:

3а. Заказ не выкуплен в срок.

3а1.Оператор(наоснованииинформации,полученнойизкас-

сы) отмечает просроченные заказы.

3а2. Система отмечает заказ как просроченный и увеличивает значение счетчика просроченных заказов клиента. Если значение счетчика превышает лимит просроченных заказов, то клиент попадает в «черный список».

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

Основноедействующеелицо:администраторсистемызаказов. Триггер: администратор выбирает элемент интерфейса «Кли-

енты».

Предусловие: администратор должен быть зарегистрирован в системе.

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

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

2.Системапредлагаетсписокклиентовсуказаниемколичества невыкупленныхзаказов.Клиенты,находящиесяв«черномсписке», отмечены.

3.Администратор выбирает клиента и обнуляет счетчик невыкупленных заказов.

4.Система удаляет клиента из «черного списка».

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

Основноедействующеелицо:администраторсистемызаказов. Триггер: администратор выбирает элемент интерфейса «Поль-

зователи».

Предусловие: администратор должен быть зарегистрирован в системе.

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

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

2.Система предлагает список пользователей системы.

35

3.Администратор выбирает элемент интерфейса «Добавить нового пользователя».

4.Системапредлагаетзаполнитьформу,содержащуюфамилию, имя,отчествопользователя,парольиимяпользователяиегостатус.

5.Администраторзаполняетформуивыбираетэлементинтерфейса «Сохранить».

6.Система добавляет нового пользователя.

Расширения:

5а.Администраторзаполняеттолькочастьнеобходимыхполей. 5а1.Администраторзаполняеттолькочастьнеобходимыхполей

или ошибается при заполнении формы.

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

3а,5а. Администратор прерывает заполнение формы. 3а1. Система прекращает обработку заказа.

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

Основноедействующеелицо:администраторсистемызаказов. Триггер: администратор выбирает элемент интерфейса «Поль-

зователи».

Предусловие: администратор должен быть зарегистрирован в системе.

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

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

2.Система предлагает список пользователей системы.

3.Администраторвыбираетпользователяиэлементинтерфейса «Редактировать».

4.Системапредлагаетдляредактированияформу,содержащую фамилию, имя, отчество пользователя, пароль и статус.

5.Администраторзаполняетформуивыбираетэлементинтерфейса «Сохранить».

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

5а.Администраторзаполняеттолькочастьнеобходимыхполей. 5а1.Администраторзаполняеттолькочастьнеобходимыхполей

или ошибается при заполнении формы.

36

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

3а, 5а. Администратор прерывает заполнение формы. 3а1. Система прекращает процедуру редактирования.

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

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

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

Предусловие: администратор должен быть зарегистрирован в системе.

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

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

2.Система предлагает список пользователей системы.

3.Администраторвыбираетпользователяиэлементинтерфейса «Удалить».

4.Система проверяет возможность удаления пользователя

ипредлагает администратору подтвердить удаление.

5.Администратор подтверждает удаление.

6.Система удаляет пользователя.

Расширения:

4а. Система сообщает о невозможности удаления пользователя.

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

3а, 5а. Администратор прерывает заполнение формы. 3а1. Система прекращает процедуру удаления.

Получение отчетов

Основноедействующеелицо:администраторсистемызаказов. Триггер:администраторвыбираетэлементинтерфейса«Отчеты». Предусловие: администратор должен быть зарегистрирован

в системе.

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

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

37

2.Система предлагает список отчетов.

3.Администратор выбирает отчет.

4.Система предлагает форму, содержащую параметры отчета.

5.Администраторзаполняетформуивыбираетэлементинтерфейса «Вывести отчет».

6.Система формирует отчет и показывает его.

Расширения:

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

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

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

3а, 5а. Администратор прерывает заполнение формы.

3а1.Системапрекращаетпроцедуру«Получениеотчетов»ипереходит на предыдущий уровень.

2. ОЦЕНКА ТРУДОЕМКОСТИ РАЗРАБОТКИ ПРОГРАММНОГО ПРОЕКТА

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

38

2.1. Методика Use Case Points

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

Какидругиеметодикиоценкитрудоемкости,методикаUseCase Points имеет преимущества и недостатки [5].

Преимущества:

1.ПрииспользованииUCPможнопроводитьоценкунаранних этапах выполнения проекта разработки ПО.

2.Простота применения.

3.Варианты использования широко применяются для формирования требований.

Недостатки:

1.Методика UCP зависит от качества сценариев вариантов использования.

2.Наконечнуюоценкупроектасильноевлияниеоказываетучет технических и внешних факторов.

3.МетодикаUCPориентированананачальнуюоценкупроекта,

а не на применение проекта в процессе его выполнения.

ДляпроведенияоценкипометодикеUseCasePointsнеобходимо выполнить следующие шаги.

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

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

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

39

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

Весовой показатель выбирают по таблице (табл. 1).

2. Вычисление неурегулированного весового показателя действую-

щихлиц(UnadjustedActorsWeight,UAW).Общееколичестводейству-

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

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

Система продажи билетов – действующее лицо, взаимодействующее с системой через программный интерфейс. Тип – простое действующее лицо с весовым коэффициентом 1: UAW = 3 · 3 + 1 = 10.

3.Определение весового показателя вариантов использования.

Взависимости от количества Use Case транзакций в потоках событий(основныхиальтернативных)всевариантыиспользования делятся на три типа: простые, средние и сложные. В данном случае под транзакцией понимают атомарную последовательность

Таблица 1

Весовые показатели

40