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

специалистовсчастичнойзанятостью,3–среднийуровеньвли- яния, 5 – все специалисты с частичной занятостью; для показателя F8 0 – простой язык программирования, 3 – язык программирования средней сложности, 5 – высокую сложность языка программирования.

Рассмотрим более подробно технические факторы F1–F8:

0Знакомство с проектом отсутствует

1Проект знаком на 20 %

2Проект знаком на 40 %

3Проект знаком на 60 %

4 Проект знаком на 80 %

5Проект знаком на 100 %

Фактор F2. Опыт разработки приложений

0Опыт разработки приложений отсутствует

1Опыт разработки приложений может быть оценен в 20 %

2Опыт разработки приложений может быть оценен в 40 %

3Опыт разработки приложений может быть оценен в 60 % 4 Опыт разработки приложений может быть оценен в 80 %

5Экспертный уровень. Опыт разработки приложений может быть оценен в 100 %

Фактор F3. Опыт использования объектно-ориентированного подхода

0Опыт использования объектно-ориентированного подхода отсутствует

1Есть только теоретические знания в объектно-ориентиро- ванном подходе

22 года опыта использования объектно-ориентированного подхода

34 года опыта использования объектно-ориентированного подхода

410 лет опыта использования объектно-ориентированного подхода

515 лет опыта использования объектно-ориентированного подхода

51

Продолжение

Фактор F4. Наличие ведущего аналитика

0Нет ведущего аналитика в проекте

1Ведущий аналитик проекта имеет 3-летний опыт работы

впроектах для этой предметной области

2Ведущий аналитик проекта имеет 5-летний опыт работы

впроектах для этой предметной области

3Ведущий аналитик проекта имеет 8-летний опыт работы

впроектах для этой предметной области

4Ведущий аналитик проекта имеет 10-летний опыт работы в проектах для этой предметной области

5Ведущий аналитик проекта имеет 15-летний опыт работы в проектах для этой предметной области

Фактор F5. Мотивация

0Нет мотивации

1Низкаямотивация.Командаработаеттолькоподуправлением.Нетпроявленийинициативысосторонычленовкоманды

25%командыимеютвысокуюмотивациюипроявляютинициативу.Остальнаякомандаработаеттолькоподуправлением.Нет проявленийинициативысостороныэтойчастичленовкоманды

320%командыимеютвысокуюмотивациюипроявляютинициативу. Остальная команда работает только под управлением. Нет проявлений инициативы со стороны этой части членов команды

450%командыимеютвысокуюмотивациюипроявляютинициативу. Остальная команда работает только под управлением. Нет проявлений инициативы со стороны этой части членов команды

5100 % команды имеют высокую мотивацию и проявляют инициативу

Фактор F6. Стабильность требований

0Нетстабильноститребований.Каждоесовещаниесзаказчиком приводит к изменению 80 % требований

1Каждоесовещаниесзаказчикомприводиткизменению60% требований

2Каждоесовещаниесзаказчикомприводиткизменению40% требований

52

Окончание

3Каждоесовещаниесзаказчикомприводиткизменению20% требований

4Каждое совещание с заказчиком приводит к изменению 5 % требований

5Требования стабильны

Фактор F7. Частичная занятость

0Всечленыкомандыработаютнаусловияхполнойзанятости

110 % членов команды работают на условиях частичной занятости

230 % членов команды работают на условиях частичной занятости

350 % членов команды работают на условиях частичной занятости

480 % членов команды работают на условиях частичной занятости

5100 % членов команды работают на условиях частичной занятости

Фактор F8. Сложные языки программирования

0Длязнакомствасязыкомпрограммированиятребуетсяодна неделя

1Для знакомства с языком программирования требуется две недели

2Для знакомства с языком программирования требуется по крайней мере месяц

3Для знакомства с языком программирования требуется специальный тренинг

4Для знакомства с языком программирования требуется специальный тренинг и помощь в процессе выполнения проекта

5Сложность языка такова, что работать могут только специалисты, имеющие опыт использования этого языка

Значение EF вычисляется по формуле

53

8.Окончательное значение UCP (Use Case Points). Вычисляется следующим образом: UCP = UUCP · TCF · EF.

9.Оценка трудоемкости проекта. В качестве начального значе-

нияпредлагаетсяиспользовать20чел.-чнаоднуUCP.Этозначение можетуточнятьсясучетомопытаразработчиков.Приведемпример уточнения.

Рассмотрим показатели F1–F8 и определим, сколько показателей F1–F6 имеют значение менее 3 и сколько показателей F7–F8 имеют значение более 3. Если общее количество равно 0, следует использовать15чел.-чнаоднуUCP,если1или2–20чел.-чнаодну UCP,если3или4–28чел.-чнаоднуUCP.Еслиобщееколичество равно5илиболее,следуетвнестиизменениявпроект,впротивном случае риск провала проекта слишком велик.

П р и м е р 12. Применение методики Use Case Points. Для проведения оценки трудоемкости разработки системы заказа билетов с помощью методики Use Case Points необходимо выполнить следующие действия.

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

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

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

UAW = 3ˑ3 + 1 = 10.

3.Определение весовых показателей вариантов использования. Весовые показатели вычисляются для всех сценариев вариантов использования

(табл. 5).

54

55

4.Определениенеурегулированныхвесовыхпоказателейвариантовисполь-

зования. В соответствии с табл. 5 UUCW = 170.

5.Определение неурегулированного общего показателя Total UUCP: Total UUCP = Total UAW + Total UUCW = 10 + 170 = 180.

6.Определениетехническойсложностипроекта.Всоответствиистабл.6

рассчитаем показатель технической сложности TCF:

7. Определение влияния условий разработки. В соответствии с табл. 7

рассчитаем показатель влияния условий разработки EF:

8.Расчет UCP: UCP = UUCP · TCF · EF = 180 · 0,825 · 0,815 = 121.

9.Оценкатрудоемкостипроекта.ТаккакколичествопоказателейF1– F6, имеющих значение менее 3, и показателей F7–F8, имеющих значение более3,равно0,примемпроизводительность15чел.-чнаоднуUCP.Тогда трудозатраты на проект составят 1815 ч.

10.Оценка срока выполнения проекта. Количество человеко-часов на выполнениепроектаравно1815.При40-часовойрабочейнеделеэточуть больше 45 недель, или 10,8 месяца.

56

2.2. Методика Function Points

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

(ПС).

Функциональныеточки–мерафункциональности,т.е.полез- ностипрограммнойсистемыспозициипользователя.Общаяфункциональность определяется и измеряется в процессе анализа [6]:

–логическихгруппданных,которыеиспользуются,поддерживаются ПС и характеризуют по сути функциональность данных;

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

Такимобразом,общаяфункциональностьявляетсясуммойдвух составляющих (рис. 9): Функциональность = Функциональность данных + Функциональность транзакций.

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

ОпределениеграницПС. ГраницыПСмогутбытьустановлены на ранних этапах жизненного цикла продукта. Например, если ПС разрабатывается в рамках замещающего проекта, то его границы,очевидно,должныбытьподобны(авозможно,исовпадать) границам ранее существовавшего ПС. Если ПС принципиально новая, то, чтобы правильно определить ее границы, необходимо установить границы других ПС, работающих совместно с рассматриваемым.

Для приложений Internet/Intranet-границы определяются так же, как и для обычных ПС: границы формируются относительно непользовательскогоинтерфейсаилинесколькихэкранов,авсего приложения. Часто Internet/Intranet приложение разрабатывается

вкачестве замены или расширения существующего ПС. В этом случае,очевидно,некорректнорассматриватьInternet/Intranet-при- ложение как принципиально новое ПС.

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

57

Рис. 9. Функциональность ПС

чтониклиент,нисерверневыполняютвотдельноститребования пользователя.Тоестьпоотдельностионинеявляютсязавершенным ПС.

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

1.Внутренний логический файл (Internal Logical File, ILF) –

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

инаходящаяся внутри границ ПС (рис. 10, а).

2.Внешнийинтерфейсный файл(ExternalInterface File,EIF) –

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

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

1.Внешний ввод (External Input, EI) – процесс ввода данных и управляющейинформациивПС(рис.11,а).Управляющаяинформациянеобходимадляобработкиданных.ПоступающиенавходПС

58

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

2.Внешнийвывод(ExternalOutput,EO)–процесс,генерирую- щийданныеилиуправляющуюинформацию,которыепоступают на выход ПС (рис. 11, б). Обычно процесс вида EO представляет собой способ формирования экранов, отчетов, сообщений.

3.Внешний запрос (External Inquiry, EQ) – диалоговый ввод, которыйприводиткнемедленномуответуПСвформедиалогового вывода (рис. 11, в). Диалоговый ввод в самом ПС не сохраняется,

адиалоговый вывод не требует выполнения вычислений. В этом заключается главное отличие EQ от EI и EO.

КаждойизхарактеристикфункциональностиПС(EI,EO,EQ,ILF илиEIF)ставитсявсоответствиенизкий,среднийиливысокийуровеньсложности,азатемвыноситсяопределеннаячисловаяоценка.

Длявнешнихивнутреннихфайлов(ILFиEIF)сложностьопределяется и ранжируется с помощью количества типов элементов записей(RecordElementTypes,RET)иколичестватиповэлементов данных (Data Element Types, DET), входящих в соответствующие логические группы данных.

Уровнисложностидлявнутреннихивнешнихфайлов(ILFиEIF) в зависимости от количества RET и DET представлены в табл. 8.

Рис. 10. Функциональность данных ПС: а – внутренние логические файлы; б – внешние интерфейсные файлы

59

Рис. 11. Функциональность транзакций ПС: а – внешний ввод; б – внешний вывод; в – внешний запрос

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

Как отмечалось ранее, ILF и EIF являются логически связанными группами данных (файлами, таблицами баз данных и т. п.), определяемыми пользователем и необходимыми для работы ПС. Оба эти типа файлов могут использоваться ПС при генерации внешних выводов (EO), а также при обслуживании внешних запросов (EQ). Разница между ними состоит лишь в том, что ILF поддерживаются самим ПС с помощью внешних вводов (EI), а EIF – любым другим ПС.

Функциональность логических файлов (ILF и EIF) оценивается в результате подсчета количества типов элементов записей (RET) и количества типов элементов данных (DET), входящих в соответствующие логические группы данных. Под количеством RET обычно понимают количество логических подгрупп данных, выделяемыхвфайлесточкизренияпользователя,иликоличество используемых форматов записей, а под количеством DET – количество элементарных полей в этих записях.

60