Оглавление
Управление длительностью
проекта ИС
1. Понятие и цели
управления длительности проекта
2. Сетевой график работ
по проекту
3. Календарное
планирование проекта ИС
Длительность
проекта – это временная характеристика,
являющаяся одним из трех главных взаимосвязанных компонентов менеджмента любого
проекта: «стоимость-время-качество».
Управление
длительностью проекта должно осуществятся на всем протяжении его ЖЦ. На стадии
планирования необходимо определить предполагаемый срок окончания работ по
проекту, что позволяет:
1. построить
план управления временными рисками проекта,
2. уточнить
стоимость и трудоемкость проекта,
3. сформировать
график работ,
4. Длительность
Ресурсы Досягаемый уровень Желаемый уровень
Стоимость
Рис. Парадигма количественного оценивания проекта
Количественная оценка длительности проекта должна
выполняться много раз, с целью уменьшения проектных рисков.
К
факторам затрудняющим достижение целей проекта относятся:
·
Отсутствие адекватного оборудования,
программного обеспечения;
·
Отсутствие квалифицированного персонала;
·
Замедление цикла утверждения;
·
Плохая координация с другими компаниями;
·
Недостаточная компетенция менеджеров
проекта.
Количественные
показатели «стоимость,C», «трудоемкость,Т» и «длительность,Д» являются
взаимосвязанными величинами и характеризуют проект с количественной стороны.
С=Т×Сср,
Где Срс –
средняя заработная плата персонала проекта в месяц;
Д=Т/N
где N –численность
команды проекта.
Под «трудоемкость» в процессе оценки ИС
понимается объем труда, который необходимо выполнить для достижения цели –
внедрение ИС на предприятии. В качестве стандарта используют человеко-месяцы
(персональные месяцы) – один человек работает на протяжении одного месяца.
При определении трудоемкости проекта ИС учитывают:
·
Структура
пооперационного перечня задач (WBS):
Ø Задачи по сравлению технического задания;
Ø Задачи по
разработке программного и технологического обеспечения (архитектура, код,
тестирование);
Ø Задачи по внедрению ИС;
Ø Задачи, требующие дополнительных затрат (менеджмента
и документирования);
·
Дополнительные
затраты на переговоры, договоры купли-продажи, консалтинг;
·
Хронологические
данные по трудоемкости и производительности;
·
Среда разработки
(операционная система для целевой ИС, языки программирования, использование
инструментов (CASE-средств)
проектирования);
·
Уровень
профессионального опыта и др.
В
общем виде длительность проекта можно представить как сумму продолжительности
работ по составлению технического задания ДТЗ, собственно разработки
Драз и внедрения Двн.
ДТВ
Драз Системный
анализ Проектирование
ПО Испытание,
внедрение Кодирование
ПО Тестирование
и интеграция Разработка
требований ДВН
Тогда
трудоемкость проекта ИС можно представить как сумму трудоемкостей решения задач
проекта, определенных структурой WBS, по выполнению следующих основных этапов
ЖЦ: составление требований (техническое задание, ТТЗ); собственно
разработка ИС (Траз); внедрение
(ТВН).
Таким
образом, общая трудоемкость проекта (Тобщ) с учетом дополнительных
затрат, связанных с менеджментом (km), средой разработки (kc), уровнем
профессионального опыта может быть представлена следующей формулой (kp):
где
Предварительная
оценка длительности проекта основывается на оценке трудоемкости проекта ИС
предприятия и определяется прежде всего типом проекта ИС.
В
таб. представлены показатели трудоемкости и длительности работ по разработке
технического задания и внедрению ИС для различных типов конфигурации ИС.
Примерные показатели длительности работ по
адаптированному проекту ИС
|
Этапы |
Длительность
процесса создания интегрированных систем по адаптированному проекту ИС |
|||
|
локальные
системы |
Малые
системы |
Средние
системы |
Крупные
системы |
|
|
Техническое
задание |
1мес (1
аналитик) |
1-2мес. (2-3
аналитика) |
3 мес. (4-5
аналитиков) |
4-5 мес.
(6-8 аналитиков) |
|
Внедрение |
Простое,
коробочный вариант. До 4 мес. |
Поэтапное
или коробочный вариант. Более 4 мес. |
Только
поэтапное. Более 6-9 мес. |
Поэтапное
сложное. Более 12 мес. |
Если
реализуется уникальный проект ИС, то в этом случае для оценки трудоемкости
разработки ТЗ и внедрения можно воспользоваться показателями, приведенными в
таб., а для оценки трудоемкости этапов создания программного продукта,
являющегося основой ИС. – методами программного инжиниринга.
Программный инжиниринг (
научно-технологическое направление, изучающее и разрабатывающее технологию
создания сложных программных продуктов) предлагает комплекс методов оценки
сложных программных продуктов:
·
Метод аналогий
(Delphi), применяющий бета-распределения;
·
Метод «COCOMO»,
применяющий регрессионный анализ;
·
Метод Software Lifecycle Management (SLIM), применяющий математическую
функцию Нордена-Рейлаха;
·
Эмпирические
методы.
Метод
аналогий (Delphi) основан на использовании опыта предыдущих проектов. Для
проекта рассчитывают оптимистическую (Тmin), пессимистическую (Тmax) и реалистическую (вероятностную, Тp) оценки трудоемкости проекта. Затем формируется бета-распределение
путем умножения реалистической оценки на четыре, прибавляются оптимистическая и
пессимистическая оценки и выполняется операция деления на шесть:
Та
же последовательность действий выполняется для определения длительности
проекта:
Подобное
взвешенное среднее значение является удобным в условиях естественной
неопределенности процесса оценивания.
Методики
«COCOMO» (Constructive Cost MOdel) содержат совокупность методов, в основу
которых положена регрессионная модель, предложенная доктором Барри В. Боэмом в
начале 1970-х гг. Она устанавливает связь размера программного продукта (V),
понесенных затрат (T) и длительности его разработки (Д). Модель «COCOMO»
создается на базе статистической интеграции хронологических данных, описывающих
типичную взаимосвязь между переменными.
Для
оценки размера программного продукта используются метрики, в измерении качества
строк исходного программного кода LOC-Line OF Code (KLOC кило LOC). В рамках
методик «COCOMO» осуществляется ряд моделей: базовая модель, промежуточная и
модель «COCOMO-2», включающие: композиционную модель, модель ранней разработки
проекта, постархитектурную модель. Указанные модели используются для разных
типов программных проектов: органического, сблокированного, внедренного.
Органический тип проекта –малый характеризуется небольшой командой, небольшими
нововведениями, нестрогими ограничениями, стабильной средой разработки;
сблокированный тип – средний и характеризуется некоторыми инновациями, средней
по величине командой, а среда разработки несколько нестабильны. Для
программного обеспечения целесообразно использоватьтак назваемый внедренный
тип, характеризующийся большой командой разработчиков, большим объемом
требуемых инноваций с достаточно жесткими ограничениями на сроки и бюджет;
объем программного обеспечения:
15-35
KLOC – локальная информационная система;
35-100
KLOC – малая информационная система;
100-300
KLOC – средняя ИС;
Более
300 KLOC – крупная ИС.
(LOC — англ. lines of code — количество строк кода — мера сложности программного обеспечения Исхо́дный код (также исхо́дный текст) — текст компьютерной программы на каком-либо языке программирования или языке разметки, который может быть прочтён человеком. В обобщённом смысле — любые входные данные для транслятора. Исходный код транслируется висполняемый код целиком до запуска программы при помощи компилятора или может исполняться сразу при помощи интерпретатора.)
Модель SLIM основана на
анализе ЖЦ программного обеспечения, производимого с использование функции
Нордена-Рейлиха, установивших связь между уровнем квалификации персонала и
затраченным временем. Было выявлено, что размер программного продукта V , от
которого зависит трудоемкость и длительность проекта, может быть уменьшена
несколькими способами (изменение требований, разбиение на фазы и т.п.), которые
может осуществлять только высококвалифицированный специалист.
|
Наименование
метода |
Общая
характеристика |
Формулы
для оценки трудозатарат Траз и длительности Драз |
|
Базовый
«COCOMO»(8.4) |
Используется
лишь значение размера ПО. Пригоден для быстрых и приближенных оценок
локальных ИС |
Где
a,b,c,d
– константы , принимающие следующие значения для внедренного режима:
a=3,6;b=1,2;c=2,5;d=0,32 |
|
Промежуточная
модель «COCOMO»(8.5) |
Кроме
размера ПО используются 15 переменных, называемых драйверами затрат Сi, которые характеризуют дополнительные
затраты, связанные с программным
продуктом, аппаратурой, персоналом и проектом и оцениваются экспертами в
пределах от 0,7 до1,46 |
Где
Сj=1 – драйвер не применяется; Сj >1 – драйвер увеличивает затараты; Cj<1 – драйвер уменьшает
затраты. |
|
Модель
раннего проектирования «COCOMO»2.0 (8.6) |
Используется
для получения приближенных оценок трудоемкости проекта, когда стабилизированы
требования, но архитектура еще не определена. Облегчает выполнение оценки
объектно-ориентированного программного обеспечения. |
Где Мe –
множитель поправки, зависит от семи драйверов затрат, отражающих продукт,
аппратуру, проект, персонал; В – вычисляемый показатель, зависящий от типа
проекта; Тauto – отражает затраты на автоматически
генерируемый код. |
|
Модель
постархитектуры «COCOMO»2.0 (8.7) |
Используется
а период, когда уже сформирована архитектура системы и выполняется детальная
разработка программного продукта. Обеспечивает учет дополнительной информации
на поздних стадиях проекта |
Где коэффициент Кreq учитывает возможные изменения в требованиях; Me – показатель, учитывающий 17 драйверов дополнительных карт, Где G% - процент расширения/сжатия
номинального времени проекта. Номинальная длительность, когда G=100% |
|
Модель SLIM (8.8) |
Позволяет
настроить фазы ЖЦ и включенные стадии для данной среды. Реализует анализ типа
«что если». Может использоваться для спирального ЖЦ и больших проектов. |
Где
V – объем продукта; P – параметр производительности персонала (определяется
экспертом) |
Как видно из анализа
приведенных методов оценки трудозатрат, в основе каждого из ин лежит оценка
объема разрабатываемого программного продукта (V, KLOC). В свою очередь для
предварительной оценки этого основополагающего показателя могут быть
использованы следующие методы:
·
Метод аналогий (Delphi), основанный на применении
бета-распределений, так же, как показано при определении трудозатрат;
·
Функционально-ориентированные методы.
Метод функциональных
точек (function point, FP) основан на том, что размер ПО оценивается в терминах
количества и сложности, реализованных в данном программном коде.
Этот метод
функциональных точек решает следующие задачи: оценивает категории
пользовательских бизнес-функций; определение количества и сложности входных и
выходных данных, запросы к базе данных, файлы либо структуры данных, а также
внешние интерфейсы, связанные с программной системой.
В
качестве характеристик используют пять категорий FP: количество внешних вводов;
количество внутренних файлов данных (таблиц) – структуры данных, количество
внешних интерфейсных файлов.
Приведем
алгоритм расчета объема ПО методом функциональных точек:
·
Подсчет количества функциональных точек
в каждой категории (вывод, ввод, запросы, структура данных, интерфейсы);
·
Определение сложности (ранга) каждой FP - низкая, средняя, сложная;
·
Установление требований для каждой
категории;
·
Подсчет общего количества функциональных
точек N
(FP)
путем умножения каждой на соответствующий параметр суммирования;
·
Преобразование функциональных точек в
основные единицы измерения программного продукта (line of code, LOC),
количества строк программного кода – N(LOC)=Vloc;
где k – количество операторов языка
программирования на одну функциональную точку.
С
целью учета системных параметров положения (скорость транзакции,
производительность, сложность обработки и т.п.) используется уточненная формула
где - i-й системный
параметр, который может принимать значения: 0- нет влияния, 1 – случайное
влияние, 2 – небольшое влияние, 3 – среднее влияние, 4 – важное, 5 – основное
влияние.
Для аналитических
программных приложений учитываются также количество и сложность алгоритмов.
Алгоритм здесь определяется как ограниченная программа-вычисление.
Функционально-ориентированные
методики учитывают языки программирования и вычисляются на любой стадии
проекта, но для оценки используются субъективные данные, основанные на
косвенных измерениях.
Таким образом,
общий алгоритм оценки длительности проекта ИС включает следующие этапы:
·
Расчет объема программного продукта и
его приложений;
·
Определение и учет факторов среды
проектирования (дополнительных затрат);
·
Оценка дополнительных затрат;
·
Расчет трудоемкости по формулам в
соответствии с выбранной методикой;
·
Расчет длительности проекта по
соответствующим формулам.
Перейдем
от оценки затрат к приблизительной
оценки стоимости программного обеспечения и требуемых ресурсов:
Стоимость=Трудозатраты×Среднюю
зароботную плату;
Средняя
численность персонала=Трудозатраты×Длительность;
Производительность=Трудозатраты/Объем.
В базовой модели «COCOMO» предлагается следующее
распределение трудоемкости оп этапам: разработка проекта – 30%; кодирование
30%; тестирование и интеграция – 40%
Распределение трудоемкости работ по созданию
программного обеспечения объемом 32/512 KLOC, %
|
Этап |
Планирование |
Проектирование |
Кодирование |
Испытание
и интеграция |
|
Анализ
требование и их корректировка |
46/45 |
12/12,5 |
4/4 |
2,5/5 |
|
Проектирование |
17/17 |
41/41 |
8/8 |
5/5 |
|
Кодирование |
4,5/5,6 |
13/13,5 |
56/57 |
37/40 |
|
Тестирование,
интеграция |
10,5/12,9 |
12,5/13,5 |
13/13 |
33/31 |
|
Управление
работами |
13,5/12,4 |
7/7,5 |
6,5/6 |
7,7/7 |
|
Оценка
качества |
3,3 |
11/10 |
6,5/6,5 |
8/8 |
|
Документирование |
5,5/5 |
2,5/2,5 |
5/5,5 |
7,5\7 |
Сетевой
график работ по проекту служит средством анализа и планирования проекта и
заключается в описании состава и взаимосвязи работ, которые необходимо
выполнить для реализации проекта.
Известны
следующие методы построения сетевых графиков работ.
1. PERT – метод программной оценки и
обзора;
2. CPM – метод критического пути;
3. PDM – метод предшествования;
4. ADM – метод стрелочных диаграмм.
Методы 1 и 2 имеют
отношение к анализу, а методы 3 и 4 – это просто методы построения диаграмм.
Методы PERT
(Program
Evaluation
and
Review
Technique) и CPM (Critical
Method)
были изобретены почти одновременно в 1950-х гг., поэтому их называния иногда
объединяют PERT/CPM.
Под методом PERT/CPM подразумевается общий процесс
анализа с использование сетевых графиков работ. Сетевой график работ,
называемый также логическими диаграммами, или PERT-диаграммами, содержит
упорядоченный набор условных графических обозначений: окружностей (узлов) и
стрелок (направленных дуг). Окружности (узлы) обозначают события, а стрелки
работы, которые должны быть выполнены для достижения событий. Событие – это
момент времени, когда заканчивается одна работа и в соответствие с логикой
проекта может быть начата другая. Таким образом , сетевой график отображает
взаимосвязь между работами внутри проекта и порядок их выполнения. С
математической точки зрения сетевой график является направленным графом, в
котором каждая работа отображается
направленной дугой (стрелкой), а каждое событие –вершиной (узлом). Метод PERT позволяет проводить только
вероятностную оценку продолжительности работ. Метод CPM позволяет фиксировать
продолжительность действий и определять приоритеты.
Правила метода PERT/CPM:
1. Каждая
работа определяется только одной дугой и недолжна появляться дважды.
2. Ни
одна пара работ не должна определяться одинаковыми начальными и конечными
событиями.
3. Ни
одно событие не может произойти до тех пор, пока не будут закончены все
входящие в него работы;
4. Ни
одна работа, выходящая из данного события, не может начинаться до тех пор,
пока не произойдет данное событие.
5. Для
исключения неоднозначности вводят фиктивную работу и фиктивное промежуточное
событие. Затраты времени и ресурсов на выполнение фиктивной работы
приравниваются нулю.
Пример фрагмента
сетевого графика работ на рис. 1 2 3 4 6 i j 5 7 t12=3 t25=5 t23=6 t24=7 t46=6 t36=5 t57=7 0 t7j=6 t6i=3 tij=5
Сетевой график считается описанным, если установлены следующие
элементы:
·
Назначение всех видов работ или
идентификаторы узлов, установленные на основе структуры перечня работ (при этом
часто используется код WBS);
·
Длительность всех работ (tij);
·
tinmin
–
время наискорейшего начала работы, которое определяется на основе времени
завершения предыдущего действия или какого-либо другого ограничения ( например,
даты, фиксированной в проекте);
·
toutmin-
время наискорейшего окончания работ;
·
tinmax-
максимально возможный срок, когда работа может быть начата, не затронув стадию
следующего действия;
·
toutmax
– максимально возможный срок, когда работа может быть завершена, не затронув
стадию следующего действия.
При определении длительности работ по методу PERT
используется вероятностное бета-распределение. При этом производится три вида
оценки продолжительности действий: оптимистическая, наиболее вероятностная и
пессимистическая. Средневзвешенная величина PERT фактически соответствует
середине треугольного распределения, которое используется в качестве
аппроксимации для бета-распределения. Средневзвешенная величина длительности
работ равна:
Оптимистическая+4×(Наиболее
вероятностная+Пессимистическая)/6
В
основу метода CPM положены два понятия: «критическая работа» и «критический
путь». Работа считается критической, если задержка ее начала приводит к
задержке срока окончания проекта в целом.
Промежуток времени между ранним началом критической работы и поздним ее
окончанием равен нулю, т.е. критическая работа не имеет резерва времени в
отличие от некритической работы. Критический путь – это непрерывная
последовательность критических работ, связывающая начало проекта и его
завершающее событие. Метод критического пути используется для прогнозирования
общей продолжительности проекта и производится на оснгове анализа приоритетов
работ. При этом запас времени (floar)
между двумя действиями может определяется как «резерв времени» (slack),
«свободный запас времени» (free floar)или «запас пути» (path). Критический путь
с нулевым запасом времени (на графе выделен жирным) превышает по длительности
все другие возможные пути.
Метод
CPM заключается в определении последовательности работ (путь в сетевом
графике), которая обладает наименьшей гибкостьюв составе рабочего графика
(flexibility).
Анализ
по методу CPM начинается со структуры WBS (перечня задач), в котором для
каждого действия существует только одна величина оценки. Затем для установления
соотношения в соответствии с приоритетами работ строится сетевой график
проекта. После построения сетевого графика выполняется двунаправленный проход
по нему для анализа работ и вычисления оценочных значений для каждого узла. При
двунаправленном анализе сначала выполняется прямой подход по расчету величины
критического пути сетевого графика от начального узла, для которого время
наискорейшего начала и время наискорейшего завершения равны нулю. Затем
выполняется обратный проход с целью расчета наиболее поздних допустимых сроков
наступления события в сети; при этом предполагается, что время наискорейшего
начала и наискорейшего завершения последнего события равно величине
критического пути, вычисленного при прямом подход.
При прямом подходе:
·
процесс начинается с начального события;
·
вычисления производятся для пары
чисел, tinmin
и toutmin, определенных для
каждой работы;
·
продолжительность работы (tij) всегда прибавляется
ко времени наискорейшего завершения работы для наступления последующего
события;
При обратном подходе:
·
процесс начинается с конечного события
(узла);
·
вычисления производятся для пары чисел tinmax
и toutmax;
·
продолжительность прохождения узла (tij) всегда вычисляется из
времени наискорейшего начала работы подключаемого узла.
Диаграмма
Ганта
Для
представления графика работ используют диаграмму Ганта, которую наз.
Гистограммой. Она была изобретена Генри Гантом во время Первой мировой войны и
применялась для оставления графиков салдат и техники из тыла на побережье США.
Диаграмма Ганта –
горизонтальная линейная диаграмма, на которой задачи проекта представляются
протяженными во времени отрезками, характеризующимися датами начала и
окончания, задержками и, возможно, другими временными параметрами.
На
простой диаграмме Ганта слева представлены производственные действия, а справа
– изображены полоски, длина которых соответствует длительности выполнения
каждого этапов соответствии с временной
шкалой. В диаграммах Ганта взаимосвязи не используются, однако многие средства
формирования рабочих графиков позволяют изображать между полосками этапов
связующие линии.
Календарное
планирование – это разработка инструмента управления работами по проекту для
реализации его в установленные сроки с учетом стоимостных ограничений и
требуемого качества. Результатом календарного планирования является календарный
план.
Календарный
план – это документ, с помощью которого устанавливаются сроки
выполняемых по проекту работ, юридические отношения, между всеми участниками
разработки проекта, включая менеджеров и разработчиков, касающиеся объема,
сроков, ресурсов и заказчиков.
Типовая
форма календарного плана проекта
|
Наименование
работ |
Сроки
начала/окончания работ, план/факт |
Ответственный
исполнитель и исполнители, роли |
Требуемые
ресурсы |
Сроки
предоставления ресурсов, план/факт |
|
1 |
2 |
3 |
4 |
5 |
Календарный
план позволяет менеджеру проекта решить следующие задачи:
1. распределить
время и осуществлять контроль над ним;
2. распределять
и контролировать как трудовые, так и материальные ресурсы;
3. планировать
и контролировать деятельность коллектива разработчиков проекта, организовать
взаимодействие между членами команды проекта.
Для создания календарного плана проекта ИС менеджеру
проекта необходимы следующие данные:
·
пооперационный перечень работ, требуемых
по проекту WSB;
·
состав исполнителей и их роли в ходе
проекта;
·
оценки трудозатрат и длительности
проекта в целом и отдельных его компонентов.
Основными задачами календарного планирования
являются:
·
рациональное распределение и
перераспределение трудовых и временных
ресурсов по работам проекта;
·
привязка рабочего графика к реальному
календарю
Для решения первой
задачи перераспределения ресурсов необходимо предпринять следующие действия:
сдвиг работ – смещение дат «начала» и «окончания»
вперед или назад с целью избежания назначения ресурсов;
·
разбиение работ на ряд этапов с целью
оптимизации потребления ресурсов;
·
растягивание работ- увеличение их
продолжительности, за счет чего уменьшается нагрузка;
·
назначение сверхурочных часов –
приспособление к нагрузке.
Решение второй задачи –
привязка рабочего графика к реальному календарю
- это установление соответствия между следующими компонентами любой
работы, включенной в рабочий график:
·
работа – временные затраты;
·
единицы – количество ресурсов,
необходимое для завершения выполняемой работы;
·
даты – календарное время, необходимое
для завершения выполняемой работы.
Для построения
календарного плана необходимо выполнить следующие действия:
1. Разработка
структуры пооперационного перечня работ (WSB), при этом определить:
·
Какие работы должны быть выполнены?
·
Кто будет выполнять каждый вид работ?
·
Какие материалы и оборудование
требуются?
·
Какова стоимость выполнения каждой
работ?
2. Установить
взаимосвязи между работами, при этом определить:
·
Какие работы должны быть выполнены в
первую очередь?
·
Какие работы будут выполнены в
дальнейшем?
·
Какие работы можно выполнить
параллельно?
3. Разработать
(PERT/CPM) на основе структуры WSB и информации о связях между
работниками.
4. Выполнить
анализ полученной диаграммы:
·
Прямой подход для определения времени наискорейшего
начала и завершения работ по проекту;
·
Обратный подход для определения
максимально возможного срока начала и завершения работ по проекту;
·
Определить приемлема ли общая
продолжительность.
5. Выполнить
анализ работ, включенных в состав критического пути, и принять следующие
решения по оптимизации процесса проектирования:
·
Можно ли сократить какие-либо
критические работы?
·
Если можно, то как измениться при этом
критический путь?
6. Выполнить
распределение ресурсов, при этом:
·
Перераспределить ресурсы, если
потребуется;
·
Проверить, как изменится общая
продолжительность.
7. Преобразовать
сетевую диаграмму в диаграмму Ганта.
8. Выполнить
анализ затрат.