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

При оценке трудоемкости и времени разработки обычно ориентируются на жизненный цикл данной IT /IS. Для этого используются различные модели.

Трудоемкость, длительность разработки и внедрения IT /IS может определяться с использованием регрессионных моделей. Метод регрессии применяется для прогнозирования количественной переменной на основе других переменных. Модель представляется в виде математических функций.

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

Процедуры, применяемые при поиске математической функции, лучше всего описывают взаимодействия между зависимой переменной и одной или большим количеством независимых переменных. При использовании метода линейной регрессии взаимосвязь ограничена прямой линией, а метод наименьших квадратов нужен для определения наиболее применяемых значений констант этой функции. В статистических линейных моделях значение параметра для данного значения вычисляется по формуле: f=a + bx, где а и b являются константами. При использовании множественной регрессии зависимая переменная рассматривается в качестве зависящей от более чем одного независимого значения.

Модель СОСОМО (Constructive COst MOdel — модель издержек разработки), представленная в 1981 г. Б. Боэмом, разработана для каскадной модели жизненного цикла на основе анализа статистических данных разработки IT-проектов. Она ориентирована на применение в трех фазах жизненного цикла программного обеспечения: при разработке спецификаций (базовая — Basic), после определения требований (расширенная — Intermediate), после окончания проектирования программного обеспечения (углубленная — Advanced).

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

где Е — затраты труда на проект (в человеко-месяцах); S — размер кода (в KLOC kilo lines of code, тысяча линий кода); EAF — фактор уточнения затрат (effort adjustment factor). Параметры а и b зависят от вида разрабатываемого приложения (простой проект, средней сложности и т. п.).

Регрессионная модель СОСОМО разработана на основе анализа 63 программных проектов различных типов. В модели производилась оценка фактического размера (показатель LOC), трудозатрат, фактической длительности разработки ПО.

В формулах модели СОСОМО используются некоторые допущения^[1]:

• • исходные инструкции конечного продукта включают в себя все (кроме комментариев) строки кода, обрабатываемого компьютером;
• • начало жизненного цикла проекта совпадает с началом разработки продукта, окончание — с окончанием приемочного тестирования, завершающего стадию интеграции и тестирования. (Работа и время, затрачиваемые на анализ требований, оцениваются отдельно как дополнительный процент от разработки в целом);
• • виды деятельности включают в себя только работы, направленные непосредственно на выполнение проекта; в них не входят обычные вспомогательные виды деятельности, такие как административная поддержка, техническое обеспечение и капитальное оборудование;
• • человеко-месяц состоит из 152 ч;
• • проект управляется надлежащим образом, в нем используются стабильные требования;
• • жизненный цикл в модели СОСОМО состоит из пяти основных стадий: планирование и определение требований, проектирование продукта, детальное проектирование, кодирование и тестирование отдельных модулей, интеграция и тестирование;
• • модель СОСОМО дает рекомендации, но распределению работ и времени по основным стадиям традиционной «водопадной» модели;
• • модель СОСОМО позволяет оценить работу и время, необходимые для получения решения (разработки продукта с помощью итераций и тестирования);
• • затраты на формулировку проблемы (планирование и определение требований) оцениваются в виде дополнительного процента от и сверх работы и времени, затрачиваемого на разработку;
• • декомпозиция работ при традиционном подходе обычно строится вокруг подсистем продукта на более высоких уровнях и вокруг подробного плана работ на более низких уровнях;
• • к стандартным видам деятельности, оцениваемым по модели СОСОМО и включаемым в WBS по созданию ПО, относятся: анализ требований, проектирование продукта, программирование, планирование тестирования, верификация и аттестация, канцелярские функции проекта (управление и администрирование), управление конфигурацией, обеспечение качества и создание руководств;
• • модель СОСОМО также рекомендует самый верхний уровень распределения работ по различным видам деятельности WBS;
• • в модели СОСОМО вид деятельности, называемый «программированием», включает в себя детальное проектирование, кодирование, тестирование модулей и интеграцию.

В модели СОСОМО используются три режима^[2], с помощью которых классифицируется сложность системы, а также среды разработки.

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

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

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

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

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

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

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

Трехуровневая иерархия программных продуктов состоит из системы, подсистем и модуля, подобно тому, как реализовано расположение в структуре WBS. Большие аспекты могут разбиваться, как минимум, на три уровня, причем каждый из драйверов затрат, введенный на промежуточном уровне модели СОСОМО, назначается на уровне таким образом, чтобы он мог подвергаться воздействию вариаций. Например, опыт инженера в области языков программирования может применяться только на уровне модулей, в то время как способности аналитика — на уровнях подсистем и модулей. Требуемый уровень надежности может применяться на уровне системы, подсистемы и модуля. Как и в случае с множителями, чувствительными к фазе, повышенная чувствительность проявляется после описания драйверов затрат. Как и в случае с множителями, чувствительными к фазе, солидные организации, обладающие автоматизированными инструментами, являются наиболее серьезными пользователями.

Оценка трудозатрат. Показатель KLOC касается исключительно входной переменной. Для вычисления трудозатрат используется экспоненциальная формула:

трудозатраты (Е) = а ?( размер)*, (3.1).

где а и b — константы, определенные на этапе регрессионного анализа (в зависимости от проекта).

Трудозатраты измеряются в человеко-мес. (19 дней в месяце либо 152 рабочих часа в месяце). Константы а и b определяются с помощью регрессионного анализа при достаточном количестве данных.

Оценка длительности и стоимости разработки ПО в модели СОСОМО'. В случае использования различных режимов проекты одинакового масштаба требуют различных трудозатрат.

Предположим, что размер проекта равен 200 KLOC. Подставим данные в формулу (3.1). Базовые формулы оценки трудозатрат для трех режимов:

• • трудозатраты для органического режима — Е = 2,4 -(размер)^[3]'⁰⁵;
• • трудозатраты для сблокированного режима —? = 3,0-(размер)^[3]'¹²;
• • трудозатраты для внедренного режима — Е = 3,6-(размер)'. Трудозатраты для органического режима подсчитываются по формуле

Для сблокированного режима может применяться следующая формула:

Для внедренного режима —

После завершения оценки трудозатрат для определения периода внедрения проекта либо времени завершения (времени разработки, TDEV) может применяться экспоненциальная формула. Длительность проекта выражается в месяцах.

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

Оценка длительности проекта при использовании базовой модели СОСОМО:

О 38.

• • длительность проекта в органическом режиме — TDEV = 2,5-(E) ' ;
• 0 35
• • длительность проекта в сблокированном режиме — TDEV = 2,5-(E) ;
• • длительность проекта во внедренном режиме — TDEV = 2,5-(E) .

Если известны трудозатраты (Е) и время разработки (TDEV), может быть вычислена средняя численность персонала (55), необходимого для завершения проекта:

Если известна средняя численность персонала, может быть определен уровень производительности:

Пример расчета этих параметров приведен в табл. 3.1.

Таблица 3.1

Пример расчета показателей по модели СОСОМО.

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

Модель СОСОМО II, в отличие от СОСОМО, может использоваться как для спиральной, так и для итеративной моделей жизненного цикла информационных систем. Она включает три модели: композиционную прикладную (Application Composition Model, ACM), ранней разработки проекта (Early Design Model, EDM), постархитектурную (Post Archi-tecture Model, PAM).

Модель СОСОМО II является улучшенной версией исходной модели СОСОМО. Она позволяет производить оценку для объектно-ориентированного программного обеспечения, для программ, при проектировании которых использована спиральная или эволюционная модель проектирования. В ней поддерживаются вероятностные диапазоны оценок, представляющие одно стандартное отклонение на фоне наиболее благоприятных оценок, оценивается процентное соотношение показателей повторного применения и расчет ожидаемой производительности.

Фактически СОСОМО II включает три различные модели.

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

Модель ранней разработки проекта применяется для получения приближенных оценок проектных затрат и периода выполнения проекта перед тем, как будет определена архитектура в целом. В этом случае используется небольшой набор новых драйверов затрат и новых уравнений оценки. Также в качестве базы используется набор не настраиваемых функциональных точек либо KLOC.

Пост-архитектурная модель — наиболее детализированная модель СОСОМО II, которая используется после разработки общей архитектуры проекта. В состав этой модели включены новые драйверы затрат, новые правила подсчета строк, а также новые уравнения.

Модель СОСОМО II интегрирует фазы и основные стадии с аналогичными объектами, разрабатываемыми фирмой Rational Unified Process, которая, в свою очередь, поддерживает распределение фаз и действий для оценщиков, использующих модель СОСОМО II.

Использование систем сетевого планирования и управления для определения длительности и трудоемкости выполнения IT-проекта. Моделирование с использованием PERT-системы предполагает построение сетевого графика на основе выбранной модели жизненного цикла по следующим этапам:

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

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

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

Оптимизация осуществляется в основном за счет:

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

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

К частной оптимизации относятся:

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

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

В работе Д. Ф. Шаффера даются довольно детальные рекомендации по разработке структуры пооперационного перечня работ (WBS)¹. Далее на основе WBS разрабатывается график выполнения проекта. На основе этого графика можно переходить от действий верхнего уровня (наподобие «сделать») к легко управляемым действиям. Эта структура позволяет убедиться, что представлены все рабочие действия (операции), и увидеть, какова их детализация. Структура WBS консолидирует информацию из различных источников, формирует единый формат, что позволяет использовать ее при планировании, оценивании и мониторинге:

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

Методы создания структуры пооперационного перечня работ включают:

• 1) подход «сверху вниз». Он предполагает последовательную декомпозицию (например, в форме дерева), обычно осуществляется на первых этапах разработки проекта. Команда разработчиков хорошо представляет этапы проекта. Разбиение продолжается до тех пор, пока работы (или их фрагменты) не смогут быть выполнены одной единицей ресурса (один человек, один отдел и т. п.) за относительно короткий период времени (день, неделя или другая единица, с помощью которой могут производиться измерения в процессе выполнения проекта). Применяется метод экстраполяции;
• 2) подход «снизу вверх» используется при разработке проектов нового типа. Применяется метод «мозгового штурма». Используется группирование всех действий до тех пор, пока не будет достигнут элемент верхнего уровня, — таким образом создается «диаграмма связности».

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

Процессы и действия, выполняемые в рамках жизненного цикла, согласно стандарту IEEE 1074, приведены в табл. 3.2¹.

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

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

Фазы разработки программного обеспечения

Таблица 3.2

При оценке стоимости проекта и количества времени, требуемого для его выполнения, следует выполнить два основных этапа:

• 1) оценивание размера проекта;
• 2) оценивание общего объема трудозатрат и стоимости работ (учитываются затраты времени, количество штатных единиц и т. п.).

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

Примеры единиц измерения:

• • количество строк кода (Lines Of Code, LOC);
• • функциональные точки;
• • точки свойств;
• • количество «пузырьков» на диаграмме потока данных (Data flow diagram, DFD);
• • количество сущностей на диаграмме сущностей (Entity relationship diagram, ERD);
• • количество «квадратиков», соответствующих процессу/конгролю (PSPEC)/(CSPEC) на структурном графике;
• • количество различных элементов в составе управленческой спецификации;
• • объем документации;
• • количество объектов, атрибутов и служб на объектной диаграмме.

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

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

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

Рассмотрим подробнее эти методы.

Метод функциональных точек {Function point, FP)^{ основан на том, что размер ПО лучше всего оценивать в терминах количества и сложности функций, реализованных в данном программной коде:

• 1) подсчитываются функции в каждой категории (перечень категорий — вывод, ввод, опросы, структуры данных, интерфейсы);
• 2) определяется сложность каждой функции (простая, средняя, сложная);
• 3) устанавливаются требования к каждой категории;
• 4) каждая функция умножается на соответствующий ей параметр, а затем суммируется с целью получения общего количества функциональных точек;
• 5) производится преобразование функциональных точек в единицы измерения (количество строк кода) по следующей формуле:

где ADJ обозначает настройку общих характеристик приложения.

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

Также в работе Д. Ф. Шафера рассматривается метод точек свойств, который представляет собой расширение метода функциональных точек, применяемого для измерений в приложениях различного типа, в том числе для таких, как встроенные системы и (или) системы реального времени.

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

Также в этой работе представлены: метод объектных точек, блиц-модель, метод оценивания Wideband Delphi (метод Дельфи)^[3].

Метод объектных точек. В этом случае оценка выполняется на более обобщенном уровне, чем при применении метода функциональных точек. Каждому уникальному классу или объект}' (экран, отчет и т. п.) назначается одна объектная точка. Далее — аналогично методу функциональных точек или точек свойств при условии, что применяются другие факторы преобразования.

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

Компоненты любой модели («пузырьки» процесса, потоки данных, сущности, взаимосвязи, объекты, атрибуты и т. п.) умножаются на множитель, который вычисляется как результат выполнения аналогичных проектов. Например: каждый «пузырек» процесса на уровне О DFD приблизительно соответствует четырем фактическим программам на языке SQL, а также известно, что средний размер программ в библиотеке SQL равен 350 строкам кода (LOC), поэтому прос тое умножение будет достаточным для подсчета начального размера. Известно, что в данном случае существует семь основных «пузырьков» процесса:

Метод оценивания Wideband Delphi {метод Дельфи). Этот метод основывается на использовании опыта многих экспертов с целью выполнения оценки, которая отражает всю сумму знаний.

Рассмотрим улучшенный метод, предполагающий проведение групповых дискуссий. Основные его шаги:

• 1) представление проблемы и ответной формы на рассмотрение экспертов;
• 2) проведение групповой дискуссии;
• 3) анонимный сбор мнений экспертов;
• 4) обратная связь по сводке результатов с каждым экспертом;
• 5) поддержка других групповых дискуссий;
• 6) выполнение итераций до тех пор, пока не будет достигнут консенсус.

Есть довольно много методик по организации проведения этого метода. Большое влияние оказывает эффект повторного использования на размер ПО. Повторному использованию подлежат: код, тестовый код, тестовые условия, тестовые процедуры, документация, дизайн, спецификации дизайна, спецификации требований и т. п. Для этого вводится новая терминология.

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

• [1] Ройс У. Управление проектами по созданию программного обеспечения. М.: ЛОРИ, 2002.
• [2] Рейс У. Указ. соч.
• [3] Шафер Д. Ф., Фатрелл Р. Т., Шафер Л. И. Указ. соч.
• [4] Шафер Д. Ф., Фатрелл Р. Т., Шафер Л. И. Указ. соч.
• [5] Шафер Д. Ф., Фатрелл Р. Т., Шафер Л. И. Указ. соч.