Вендров А.М. Проектирование программного обеспечения экономических информационных систем

Подождите немного. Документ загружается.

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

Эксплуатационные ограничения

0 Какие-либо явные или неявные ограничения отсутствуют

1 Эксплуатационные офаничения присутствуют, но не требуют ника-

ких специальных усилий

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

ностью или временем реакции

3 Должны учитываться конкретные требования к процессору со сто-

роны конкретных компонентов приложения

4 Заданные эксплуатационные ограничения требуют специальных ог-

раничений на выполнение приложения в центральном или выделен-

ном процессоре

То

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

ленные компоненты системы

Частота транзакций

0 Пиковых периодов не ожидается

1 Ожидаются пиковые периоды (ежемесячные, ежеквартальные, еже-

годные)

2 Ожидаются еженедельные пиковые периоды

3 Ожидаются ежедневные пиковые периоды

4 Высокая частота транзакций требует анализа производительности на

стадии проектирования

5 То же, кроме того, на стадиях проектирования, разработки и (или)

внедрения необходимо использовать специальные средства анализа

производительности

Ввод данных в

режиме «онлайн»

0 Все транзакции обрабатываются в пакетном режиме

1 От

до 7% транзакций требуют интерактивного ввода данных

2 От

до

15%

транзакций требуют интерактивного ввода данных

3 От

16%

до

23%

транзакций требуют интерактивного ввода данных

4 От

24%

до 30% транзакций требуют интерактивного ввода данных

5 Более

30%

транзакций требуют интерактивного ввода данных

Эффективность работы конечных пользователей^

О Ни одной из перечисленных функциональных возможностей^

^ От одной до трех функциональных возможностей

2 От четырех до пяти функциональных возможностей

3 Шесть или более функциональных возможностей при отсутствии

конкретных пользовательских требований к эффективности

^ То же, кроме того, пользовательские требования к эффективности

требуют специальных проектных решений для учета эргономичес-

ких факторов (например, минимизации нажатий клавиш, максими-

зации значений по умолчанию, использования шаблонов)

442 Глава 6

Эффективность работы конечных пользователей

5 То же, кроме того, пользовательские требования к эффективности

требуют применения специальных средств и процессов, демонстри-

рующих их выполнение

^Эффективность работы конечных пользователей определяется наличи-

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

• Средства навигации (например, функциональные клавиши, дина-

мически генерируемые меню).

• Меню.

• Онлайновые подсказки и документация.

• Автоматическое перемещение курсора.

• Скроллинг.

• Удаленная печать.

• Предварительно назначенные функциональные клавиши.

• Выбор данных на экране с помощью курсора.

• Использование видеоэффектов, цветового вьщеления, подчерки-

вания и других индикаторов.

• Всплывающие окна.

• Минимизация количества экранов, необходимых для выполнения

бизнес-функций.

• Поддержка двух и более языков.

Онлайновое обновление

0 Отсутствует

1 Онлайновое обновление от одного до трех управляющих файлов

Объем обновлений незначителен, восстановление несложно

2 Онлайновое обновление четырех или более управляющих файлов

Объем обновлений незначителен, восстановление несложно

3 Онлайновое обновление основных внутренних логических файлов

4 То же, плюс необходимость специальной защиты от потери данных

5 То же, кроме того, большой объем данных требует учета затрат на

процесс восстановления. Требуются автоматизированные процеду-

ры восстановления с минимальным вмешательством оператора

Сложная обработка^

0 Ни одной из перечисленных функциональных возможностей^

1 Любая одна из возможностей

2 Любые две из возможностей

^ Любые три из возможностей

^ Любые четыре из возможностей

5 Все пять возможностей

Сложная обработка характеризуется наличием у приложения следую-

щих функциональных возможностей:

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

• повышенная реакция на внешние воздействия и (или) специаль-

ная защита от внешних воздействий;

• экстенсивная логическая обработка;

• экстенсивная математическая обработка;

• обработка большого количества исключительных ситуаций;

• поддержка разнородных типов входных/выходных данных.

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

0 Отсутствует

1 Повторное использование кода внутри одного приложения

2 Не более 10% приложений будут использоваться более чем одним

пользователем

3 Более

10%

приложений будут использоваться более чем одним поль-

зователем

4 Приложение оформляется как продукт и (или) документируется для

облегчения повторного использования. Настройка приложения вы-

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

5 То же, с возможностью параметрической настройки приложений

Простота установки

0 К установке не предъявляется никаких специальных требований.

1 Для установки требуется специальная процедура

2 Заданы пользовательские требования к конвертированию (переносу

существующих данных и приложений в новую систему) и установке,

должны быть обеспечены и проверены соответствующие руковод-

ства. Конвертированию не придается важное значение

3 То же, однако конвертированию придается важное значение.

4 То же, что и в случае 2, плюс наличие автоматизированных средств

конвертирования и установки

5 То же, что и в случае 3, плюс наличие автоматизированных средств

конвертирования и установки

Простота эксплуатации

О К эксплуатации не предъявляется никаких специальных требова-

ний, за исключением обычных процедур резервного копирования

1—4 Приложение обладает одной, несколькими или всеми из перечис-

ленных далее возможностей. Каждая возможность, за исключением

второй, обладает единичным весом: 1) наличие процедур запуска,

копирования и восстановления с участием оператора; 2) то же, без

участия оператора; 3) минимизируется необходимость в монтирова-

нии носителей для резервного копирования; 4) минимизируется не-

обходимость в средствах подачи и укладки бумаги при печати

5 Вмешательство оператора требуется только при запуске и заверше-

нии работы системы. Обеспечивается автоматическое восстановле-

ние работоспособности приложения после сбоев и ошибок

444 Глава

Количество возможных установок на различных платформах

0 Приложение рассчитано на установку у одного пользователя

1 Приложение рассчитано на много установок

для

строго стандартной

платформы (технические средства

программное обеспечение)

2 Приложение рассчитано

на

много установок для платформ

близ-

кими характеристиками

3 Приложение рассчитано

на

много установок

для

различных плат-

форм

4 То же, что

случаях

или 2,

плюс наличие документации

планов

поддержки всех установленных копий приложения

То

же,

что в

случае

плюс наличие документации

планов под-

держки всех установленных копий приложения

П|бкость^

0 Ни одной из перечисленных возможностей^

1 Любая одна из возможностей

2 Любые две из возможностей

3 Любые три из возможностей

4 Любые четыре из возможностей

5 Все пять возможностей

Гибкость характеризуется наличием

приложения следующих воз-

можностей:

• поддержка простых запросов, например, логики

(или)

приме-

нении только

одному ILF (вес

—

1);

• поддержка запросов средней сложности, например, логики

(или)

в применении более чем

одному ILF (вес

- 2);

• поддержка сложных запросов, например, комбинации логических

связок

(или)

применении

одному или более ILF (вес

—

3);

• управляющая информация хранится

таблицах, поддерживаемых

пользователем

интерактивном режиме, однако эффект

от ее из-

менений проявляется

на

следующий рабочий день;

•

то

же,

но эффект проявляется немедленно (вес

—

2).

После определения всех значений GSC и вычисления попра-

вочного коэффициента VAF вычисляется итоговая оценка коли-

чества функциональных точек (Adjusted Function Points, AFP):

AFP = UFP

VAF.

6.2.5.

ОЦЕНКА ТРУДОЕМКОСТИ РАЗРАБОТКИ

Ниже в соответствии с данными SPR определяется количест-

во строк кода (SLOC) на одну функциональную точку в зависи-

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

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

Количество строк кода на одну функциональную точку

Язык (средство)

АВАР/4

Access

ANSI SQL

С++

Clarion

Data base default

Delphi 5

Excel 5

FoxPro 2.5

Oracle Developer

PowerBuilder

Smalltalk

Visual Basic 6

Visual C++

HTML 4

Java 2

Количество SLOC на FP

Умножая AFP на (количество SLOC на FP), получаем количе-

ство SLOC в приложении.

Далее для оценки трудоемкости и времени разработки может

использоваться один из вариантов известной модели оценки тру-

доемкости разработки ПО под названием СОСОМО и ее совре-

менной версии СОСОМО II (см. подразд. 6.3).

В табл. 6.5 приведены усредненные статистические данные

размера ПО по некоторым видам приложений.

Таблица 6.5

Размер программного обеспечения

LOC

Тип ПО

Текстовые процессоры

Электронные таблицы

Клиент-серверные приложения

ПО баз данных

Производственные приложе-

ния

Размер, FP

3500

7500

Размер,

LOG

437500

675000

937500

Количество

LOC на одну FP

125

90 1

125

446

Глава 6

Продолжение

Тип ПО

Крупные бизнес-приложения

Крупные корпоративные при-

ложения

Крупные приложения в госуч-

реждениях

Операционные системы

Системы масштаба предприя-

тий

Крупные оборонные системы

Размер, FP

10000

25000

50000

75000

150000

250000

Размер,

ШС

1050000

2625000

5250000

11250000

18750000

25000000

Количество

LOC на одну FP

105

150

125

100

На реализацию проектов размером в одну функциональную

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

ются

успешно.

Таковы, как

правило,

небольшие утилиты для вре-

менных нужд.

Объем в

функциональных точек

—

это типичный объем не-

больших приложений и дополнений, вносимых в готовые систе-

мы.

Такие проекты требуют до 1 месяца работ и тоже всегда ус-

пешны.

Объем в 100 функциональных точек близок к пределам воз-

можностей программиста-одиночки. Проект доводится до конца

за 6 месяцев в

85%

случаев. Эти цифры верны для современных

средств разработки:

лет назад

тысяч строк занимал профес-

сиональный интерпретатор Бейсика для MS-DOS, создать кото-

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

Объем проекта в 1000 функциональных точек характерен для

большинства сегодняшних коммерческих настольных и неболь-

ших клиент-серверных приложений. Заметную долю обихего объ-

ема работы начинает занимать документация. Для разработки

проекта необходима фуппа примерно из

профаммистов, про-

ектировщиков, специалистов по управлению качеством и около

года

работы.

Проваливается

15%

подобных фупповых проектов и

65%

попыток профаммистов-одиночек.

20%

случаев не удается

уложиться

срок. Перерасход средств отмечается

25%

проектов.

Для проекта объемом в

10000

функциональных точек требует-

ся около 100 разработчиков. Остро встают вопросы организации

совместной работы нескольких фупп сотрудников. Работы длят-

ся от 1,5 до

лет, при этом запланированные сроки чаще всего не

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

вьщерживаются. Хорошее качество системы невозможно обеспе-

чить без использования формальной технологии тестирования.

До 50% проектов заканчивается неудачей, а реализация таких

проектов в одиночку вообще невозможна.

Объем в 100000 функциональных точек

—

пока что предел для

большинства сегодняшних проектов. Это объем современных

операционных систем, таких как MS Windows или IBM MVS, и

крупнейших военных

систем.

На их создание уходит 5-8 лет Над

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

и эффективно координировать

их

работу не удается.

закончен-

ных системах много ошибок. До

65%

проектов завершается про-

валом. Во всех успешных проектах используются системы управ-

ления конфигурацией.

Табл. 6.6 иллюстрирует различия в распределении временных

затрат

по

стадиям жизненного цикла

случае большого

малень-

кого проекта. Маленький проект (например, приложение

Windows объемом 50000 строк исходного кода на Visual Basic, соз-

даваемое командой из 5 человек) может потребовать

месяц на

начальную стадию, 2 месяца на проектирование, 5 месяцев на

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

проект (например, бортовая профамма для летательного аппара-

та объемом 300000 строк исходного кода, создаваемая командой

из 40 человек) может потребовать 8 месяцев на начальную ста-

дию,

месяцев на проектирование, 20 месяцев на разработку

месяцев на ввод

действие.

Сравнение долей жизненного цикла,

приходящихся на каждую стадию, позволяет обнаружить очевид-

ные различия.

Таблица 6.6

Распределение временных затрат

по стадиям

для

маленьких

больших проектов

Масштаб проекта

Маленький ком-

мерческий проект

Большой, слож-

ный проект

Начальная

стадия, %

Проектирование,

Разработка,

Ввод в

действие, %

448

Глава 6

Самым значительным отличием является относительное вре-

мя,

за которое достигается контрольная точка жизненного цикла,

связанная с созданием архитектуры (завершение проектирова-

ния).

Для маленьких проектов это отношение составляет 30/70;

для большого проекта оно ближе к 45/55.

Время разработки может

быть

изменено

учетом статистичес-

ких данных, накопленных в реальных проектах и отраженных в

табл. 6.7, где сопоставлены планируемый и реальный сроки вы-

полнения проекта в зависимости от его размера, выраженного в

количестве функциональных

точек.

Частично это отставание объ-

ясняется неточной оценкой, частично

—

ростом количества тре-

бований к системе после

того,

как выполнена начальная оценка.

Таблица 6.7

Статистические данные

Размер проекта

Планируемый

срок (мес.)

Реальный срок

(мес.)

Отставание

< 100 FP

100

- 1000 FP

1000 - 10000

> 10000 FP

6.3.

АЛГОРИТМИЧЕСКОЕ МОДЕЛИРОВАНИЕ

ТРУДОЕМКОСТИ РАЗРАБОТКИ

ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

6.3.1.

ТЕОРЕТИЧЕСКИЕ (МАТЕМАТИЧЕСКИЕ) МОДЕЛИ

Математическое моделирование трудоемкости разработки

ПО основано на сопоставлении экспериментальных данных с

формой существующей математической функции.

начале 1960-х

годов Питер Норден из фирмы IBM пришел к выводу, что в про-

ектах по исследованию и разработке может применяться хорошо

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

на распределении вероятности, называемом кривой Рэлея

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

(Rayleigh distribution). Позднее, в 1970-х годах Лоуренс Патнэм^

из компании Quantitative Systems Management применил резуль-

таты Нордена к разработке ПО. Используя статистический ана-

лиз проектов, Патнэм обнаружил, что взаимосвязь между тремя

основными параметрами проекта (размером, временем и трудо-

емкостью) напоминает функцию Нордена-Рэлея (рис. 6.9), отра-

жающую распределение трудовых ресурсов проекта в зависимос-

ти от времени.

dy/dt = aKate-*"

t=0

Время

Рис. 6.9. Функция Рэлея

1*18

Функция Рэлея моделируется дифференциальным уравнением:

rfvM= 2*^*a*/*ex/?(-fl/^).

где dy/dt

—

скорость роста персонала проекта; /

—

время, прошед-

шее от начала проекта до изъятия продукта из эксплуатации; К —

область под кривой ~ представляет полную трудоемкость в тече-

ние всего жизненного цикла (включая сопровождение), выра-

женную в человеко-годах; а

—

константа, которая определяет

форму кривой (фактор ускорения) и вычисляется по формуле

a=\/2t,

где

- время разработки.

^ Putnam

L.H.

General Empirical Solution to the Macro Software Sizing and

Estimating Problem ," IEEE Transactions on Software Engineering, 1978, July.

—

345-361.

450 Глава 6

Приняв ряд допущений, Патнэм получил следующее уравне-

ние:

j^=0.4*[^/q'*l/(//,

где Е

—

трудоемкость разработки ПО, S

—

размер ПО в LOC, t^

—

планируемый срок разработки, С — технологический фактор,

учитывающий различные аппаратные ограничения, опыт персо-

нала и характеристики среды профаммирования. Он определяет-

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

согласно рекомендациям Патнэма определяется для различных

типов проектов следующим образом:

• проект, внедренный в сжатые сроки без детальной прора-

ботки, - 1500;

• проект, выполненный в соответствии с четким планом,

—

5000;

• проект, предусматривающий оптимальную организацию и

поддержку,

—

10000.

Оптимальный срок разработки определяется как

что хорошо согласуется с большинством статистических моделей.

Более подробное описание модели Патнэма приведено в кни-

ге Фатрелл Р., Шафер Д., Шафер Л. Управление программными

проектами: достижение оптимального качества при минимуме

затрат: Пер. с англ.

—

М.: Вильяме,

2003.

6.3.2.

СТАТИСТИЧЕСКИЕ (РЕГРЕССИОННЫЕ) МОДЕЛИ

Статистические модели используют накопленные хронологи-

ческие данные, чтобы получить значения для коэффициентов

модели. Для определения соотношений между параметрами мо-

дели и трудоемкостью разработки ПО используется рефессион-

ный анализ. Существуют две формы статистических моделей: ли-

нейные и нелинейные.

Линейные статистические модели имеют следующий вид:

Трудоемкость

= Ль

+ S

А-

^^t

/=1