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

1.Определение границ ПС.

2.Идентификацияиоценкафункциональностиданных(ILF,EIF).

3.Идентификация и оценка функциональности транзакций

(EI, EO, EQ).

4.Определение значения нормирующего фактора (VAF).

5.Подсчетнормированногоколичествафункциональныхточек. Напрактикепоследовательностьшаговсовторогопочетвертый

неимеетзначения.Длявыполненияпятогошаганужнаинформация, полученная на предыдущих шагах.

Длявыполнениявсехшаговиспользуютследующиеисточники информации [6]:

– общая спецификация ПС (техническое задание, ТЗ), включающаявсебяфункциональнуюспецификациюиспецификацию качества.

71

–Use Case документ;

–имеющаясянамоментоценкидокументациянаинтерфейсы;

–имеющаяся на момент оценки документация разработчика;

–отчеты о метриках ПС;

–общение с пользователем;

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

–результаты функционального моделирования;

–логическая модель данных;

–результатысистемногоанализа,полученныесиспользованием различных методик, например таблицы решений, сети Петри, диаграммы UML и т. п.

Пример 13.Оценкатрудоемкостиразработкисистемызаказабилетов

спомощью методики Function Points

Идентификацияиоценкафункциональностиданных(ILFиEIF)(табл.14).

Всистеме надо хранить следующую информацию:

–ILF-пользователи: ID пользователя; статус пользователя, имя; фамилия; день рождения; пол; телефон; e-mail; имя пользователя (логин); пароль; вопрос, который будет задан, в случае если пользователь забыл пароль; ответ на вопрос. Число типов элементов записей (RET) может быть равно 1 (только символьная информация). Число типов элементов данных (DET) 11. Уровень сложности низкий (Low);

–ILF-заявки: номер заказа, статус заказа, ID пользователя, тип билета, дата, количество билетов, место получения билетов, контактная информация. Число типов элементов записей (RET) может быть равно 2 (символьная информация и целое число (количество билетов)). Число типов элементов данных (DET) 8. Уровень сложности низкий (Low);

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

сложность средней.

Идентификацияиоценкафункциональноститранзакций(EI,EO,EQ). Уровеньсложностидлявнешнихвводов,внешнихвыводовивнешнихзапросов

Уровеньсложностивнешнихвводов(EI) (табл. 15).Внешнийввод«Ре-

гистрацияпользователя»ссылаетсянаодинвнутреннийлогическийфайл иимеет10элементовданных(поля«Логин»,«Пароль»,«Подтверждение пароля»,«Фамилия»,«Имя»;деньрождения;пол;е-mail;телефон;кноп- ки«Зарегистрироваться»,«Отменазаказа»,«Забылпароль»;сообщение,

72

подтверждающее факт регистрации). Уровень сложности этого ввода низкий (Low).

Регистрация пользователя – 13 DET, 1 FTR Low. Аутентификация – 4 DET, 1 FTR Low.

Добавление нового пользователя – 10 DET, 1 FTR Low.

Заказ билета – 9 DET, 2 FTR. Средний уровень сложности (Average).

Уровеньсложностивнешнихвыводов(EO)(табл.16).Получениеотчетов

(статистики о работе системы) – 25 DET, 2 FTR. Низкий уровень слож-

ности (High).

Уровень сложности внешних запросов (EQ) (табл. 17)

Внешний запрос «Получение справочной информации» – ссылается на один внутренний логический файл и имеет четыре входных элемента данных (тип билета; дата; кнопки «Справка», «Отмена») и один элемент выходныхданных(количествобилетов).Уровеньсложностиэтогозапроса низкий (Low).

Получение справочной информации – 5 DET, 1 FTR Low. Внешний запрос «Забыл пароль» – 2 DET, 1 FTR. Низкий уровень

сложности.

Внешний запрос «Мониторинг исполнения заказа» – 5 DET, 2 FTR. Низкий уровень сложности.

73

Внешний запрос «Отмена заказа» – 11 DET, 2 FTR. Средний уровень сложности.

Внешний запрос «Оформление заказа» – 15 DET, 1 FTR. Низкий уровень сложности.

Внешний запрос «Учет проданных билетов» – 5 DET, 1 FTR. Низкий уровень сложности.

Внешний запрос «Удаление клиента из "черного списка" – 5 DET, 1 FTR. Низкий уровень сложности.

Внешний запрос «Редактирование пользователя» – 16 DET, 1 FTR. Низкий уровень сложности.

Внешний запрос «Удаление пользователя» – 6 DET, 1 FTR. Низкий уровень сложности.

Подсчетобщегоколичестваненормированныхфункциональныхточек представлен в табл. 18.

74

Итого: UFP = 69.

РасчетзначенияфакторавыравниванияпроизводитсяпоформулеVAF=

=(TDI·0,01) + 0,65, где TDI – сумма параметров для системы заказов.

Втабл. 19 представлены параметры для системы заказов.

75

Итак, TDI = 14. В этом случае фактор выравнивания VAF = (14·0,01) + + 0,65 = 0,79.

Дляпрограммногоприложенияоценкаколичествавыровненныхфункцио-

нальных точек AFP = UFP·VAF = 69·0,79 = 54,5.

РазмерразрабатываемогоПОрассчитываемпоформулеРР=AFP·Кп/1000. При реализации системы заказов на С++ коэффициент Кп = 50; РР =

= 54,5·50/1000 = 2,7.

Трудозатраты определяют по формуле OTp= A PPB П7i=1MTi.

ДлявсехMTi установимсреднийуровеньравным1;А = 5,17; В=0,94.Тогда ОТр = 5,17·2,7·0,94·1 = 13,1 чел.-мес.

Получившаяся по методике функциональных точек оценка трудоемкости13,1чел.-меснемногобольше,чемоценкапомето- дикеUseCasePoints(10,8чел.-мес).Однакообеоценкивыполне- ны на самом раннем этапе реализации проекта и такая разница допустима.

ЗАКЛЮЧЕНИЕ

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

основанныйнаметодикахUseCasePointsиFunctionPoints.Приве-

денпримерформированиятребованийввидеUseCaseдокумента для системы заказа билетов и пример определения трудоемкости разработки для этой системы по двум методикам.

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1.Коберн А. Современные методы описания функциональных требований к системам / А. Коберн. – М. : Изд. дом «Лори», 2002. – 263 с.

2.Вигерс К. Разработка требований к программному обеспечению / К. Вигерс. – М. : Изд.-торг. дом «Русская редакция», 2004. – 576 с.

3.МацяшекЛ.Анализтребованийипроектированиесистем.Разработ- каинформационныхсистемсиспользованиемUML/Л.Мацяшек.–М.: Изд. дом «Вильямс», 2002. – 432 с.

76

лицами или СУБД; 2 – ПС готовит данные, которые затем передаются

для обработки (но не для конечной) другому компоненту системы; 3 – ПС поддерживает распределенную обработку

и передачу данных в режиме реального времени (online), но только в одном направлении;

4 – ПС поддерживает распределенную обработку и передачу данных в режиме реального времени (online) в обоих направлениях;

78

79

Продолжение

80