Материал: Sb97307
1.Проект разработки «Автоматизированной системы заказа товаров»
1.1.Разработка постановки задачи
1.1.1.Проведение аналитического обследования
1.1.2.Разработка функциональных требований
1.1.3.Разработка требований к базовому ПО
1.1.4.Постановка задачи утверждена
1.2.Поставка и установка базового ПО
1.2.1.Разработка спецификаций на базовое ПО
1.2.2.Закупка базового ПО
1.2.3.Развертывание и настройка базового ПО
1.2.4.Базовое ПО установлено у заказчика
1.3.Установка и конфигурирование рабочей среды
1.4.Проектирование и разработка ПО
1.4.1.Авторизация и аутентификация пользователей
1.4.2.Разработка подсистемы заказа
1.4.2.1.Просмотр каталога продуктов
1.4.2.2.Поиск продуктов по каталогу
1.4.2.3.Подсистема заказа передана в тестовую эксплуатацию
1.4.3. Разработка подсистемы сопровождения каталога. Подготовка и сопровождение каталога продукции
1.4.4.Тестирование ПО
1.4.5.Документирование прикладного ПО
1.5.Обучение пользователей
1.5.1.Подготовка учебных курсов
1.5.2.Обучение сотрудников отдела продаж
1.5.3.Обучение администраторов АС
1.6.Ввод в опытную эксплуатацию
1.6.1.Развертывание и настройка прикладного ПО
1.6.2.Проведение приемо-сдаточных испытаний
1.6.3.Акт передачи системы в опытную эксплуатацию утвержден
1.7.Сопровождение системы в период опытной эксплуатации
Рис. 2.1
Описание содержания проекта, ИСР и словарь ИСР называют базовым планом по содержанию, он определяет один из компонентов тройственного ограничения.
Контроль содержания – это процесс, в результате которого определяется, нет ли отклонений в содержании продукта, и не требуются ли изменения.
Подтверждение содержания – это процесс формальной приемки результатов проекта заказчиком. До этого завершенные результаты должны пройти контроль качества, который осуществляется исполнителем, и в результате
11
которого могут потребоваться изменения – исправления ошибок. После ис-
правления ошибок и повторного контроля качества проверенные результаты представляются заказчику. Заказчик осуществляет формальную приемку или требует провести доработку.
3. РАЗРАБОТКА РАСПИСАНИЯ ПРОЕКТА, ОПРЕДЕЛЕНИЕ
СТОИМОСТИ ПРОЕКТА И УПРАВЛЕНИЕ РИСКАМИ
После того как сформирован базовый план по содержанию (описание содержания проекта, ИСР и словарь ИСР), можно приступать к определению временных и далее стоимостных затрат на осуществление проекта.
Почти все процессы из области знаний по управлению расписанием проекта находятся в группе процессов планирования. Их пять: определение опе-
раций, определение последовательности операций, оценка ресурсов и длительности для операций, составление расписания. Один процесс, контроль расписания, находится в группе процессов мониторинга и контроля.
Во все процессы планирования как можно раньше должна быть вовлечена команда проекта, поскольку именно команда может наиболее точно оценить, сколько ресурсов потребуется для выполнения той или иной операции, а также сможет наиболее оперативно откорректировать планы в случае необходимости изменений.
Итак, пакеты работ из ИСР разбиты на операции, такие, что их может выполнить один человек не более чем за неделю, определена их последовательность и длительность; теперь пора составлять расписание.
Одна из техник составления расписания это – метод критического пути. Строится сетевая диаграмма, которая является направленным графом с узлами – операциями проекта. Дуги определяют последовательность выполнения операций. Есть и другие виды сетевых диаграмм, но здесь они рассматриваться не будут. Например, на рис. 3.1 представлена сетевая диаграмма проекта, в котором предусмотрены операции с длительностью A= 6, B = 12, С = 5, D = 7, E = 7, H = 5 и G = 8. Длительность операций S и F равна нулю.
12 |
5 |
|
7 |
|
|
8 |
|
||||
|
B |
|
|
|
C |
|
E |
|
|
G |
|
|
|
|
|
|
|
|
|
5 |
|
|
F |
S |
7 |
|
|
|
|
|
|
||||
6 |
|
D |
|
|
|
H |
|
|
|
||
|
|
|
|
|
|
|
|
||||
|
A |
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Рис. 3.1 |
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
||||
|
|
12 |
|
|
|
|
|
|
|||
Посчитаем длительность всех путей в диаграмме, получим 3 пути, один |
|||
из которых имеет наибольшую длительность – 33, его называют критиче- |
|||
ским. Говорят, что все операции на критическом пути имеют нулевой запас |
|||
времени (Float). На рис 3.1 это путь S-A-D-C-E-G-F. Самый короткий путь |
|||
здесь S-A-D-H-F имеет длительность 18. Для разработки расписания требует- |
|||
ся узнать запас времени для каждой операции. Для этого используют алго- |
|||
ритм прохода сетевых путей сначала в прямом направлении, затем – в обрат- |
|||
ном. На прямом пути (рис. 3.2) рассчитывают точки «раннего старта» (ES) и |
|||
«раннего финиша» (EF), а на обратном – «позднего финиша» (LS) и «поздне- |
|||
го старта» (LF). Для сетевой диаграммы, представленной на рис. 3.1, эти зна- |
|||
чения, а также значения запасов времени (Float) будут следующими: |
|||
– A: ES=0, EF=6, LS=0, LF=6, Float=0; |
ES |
EF |
|
– B: ES=0, EF=12, LS=1, LF=13, Float=1; |
|||
|
Float = LS-ES |
||
– С: ES=13, EF=18, LS=13, LF=18, Float=0; |
|
||
– D: ES=6, EF=13, LS=6, LF=13, Float=0; |
|
Float = LF-EF |
|
– E: ES=18, EF=25, LS=18, LF=25, Float=0; |
LS |
LF |
|
– H: ES=13, EF=18, LS=28, LF=33, Float=15; |
|||
– G: ES=25, EF=33, LS=25, LF=33, Float=0. |
|
Рис. 3.2 |
|
Зная запасы времени для каждой операции, |
|
||
|
|
||
можно принять решение начинать операцию раньше или позже и составить |
|||
расписание проекта. |
|
|
|
Важной частью расписания служат вехи, которые уже были зафиксиро- |
|||
ваны на этапе разработки устава проекта, а теперь их перечень можно допол- |
|||
нить. Вехи, или контрольные события, не имеют длительности, они конста- |
|||
тируют достижение проектом некоторого статуса и могут означать переход |
|||
проекта в новую фазу. Напомним, что вехи, зафиксированные в уставе про- |
|||
екта, изменять крайне нежелательно. |
|
|
|
Если расписание проекта уже составлено, можно сформировать бюджет |
|||
проекта. Это соответствует области знаний управления стоимостью проекта, |
|||
которая содержит оценку стоимости, формирование бюджета и контроль |
|||
стоимости. В рамках дисциплины управление стоимостью рассматривается в |
|||
общих чертах, отметим лишь, что оценка стоимости происходит снизу вверх. |
|||
Сначала оценивается стоимость каждой операции из списка, полученного на |
|||
выходе процесса «определение операций проекта», затем сумма этих стоимо- |
|||
стей дает стоимость пакета работ как нижнего уровня ИСР, далее формиру- |
|||
13
ются «контрольные счета» (Control Account Estimates), которые представляют собой оценку стоимости для элементов ИСР верхнего уровня, сумма которых дает оценку стоимости проекта. Бюджет получается добавлением к оценке стоимости проекта резервов на непредвиденные расходы и накладные расхо-
ды организации.
Вернемся теперь к сетевой диаграмме. Что делать, если сроки, которые были рассчитаны, не устраивают заказчика и требуется их изменение? Не-
обходимо применить одну из техник сокращения сроков проекта. Могут быть выбраны, например, следующие техники: быстрый проход (Fast Track),
сжатие (Crash), сокращение содержания (Reduce Scope).
Быстрый проход – это параллельное выполнение нескольких операций.
Сжатие – добавление ресурсов, например, более опытных исполнителей, на операции критического пути. Сокращение содержания – исключение неко-
торых операций из сетевого графика проекта. В таблице приведены послед-
ствия применения каждой техники.
Наименование |
Описание влияния на проект |
|
|
Быстрый проход |
Всегда добавляет риски |
|
|
Сжатие |
Всегда увеличивает стоимость |
|
|
Сокращение содержания |
Может негативно воздействовать на выполнение ожиданий |
заказчика |
Таким образом, нет идеальной техники сокращения сроков проекта. Необходимо проводить анализ влияния действий по сокращению расписа-
ния проекта и сопоставлять негативные последствия по увеличению стоимости, рисков и несоответствию ожиданиям заказчика потенциальной выго-
де от соблюдения сроков разработки.
Предварительные планы по содержанию, срокам и стоимости сформи-
рованы. Самое время перейти к работе с рисками, так как только на основании анализа рисков можно определить, принять ли разработанные планы как базовые в настоящий момент.
Команда проекта уже определила высокоуровневые риски, когда зани-
малась разработкой устава проекта. Теперь, после того как разработаны первоначальные планы, необходимо перейти к более детальной идентификации рисков. В области знаний управления рисками выделяют следующие процес-
14
сы группы процессов планирования: идентификация рисков, качественный анализ рисков, количественный анализ рисков, планирование реагирования на риски. Один процесс, мониторинг и контроль срабатывания рисков, на-
ходится в группе процессов мониторинга и контроля.
Для программных проектов характерны следующие риски (в соответст-
вии с [2]):
1)дефицит специалистов;
2)нереалистичные сроки и бюджет;
3)реализация несоответствующей функциональности;
4)разработка неправильного пользовательского интерфейса;
5)«золотая сервировка», ненужная оптимизация и оттачивание деталей;
6)непрекращающийся и неуправляемый поток изменений;
7)нехватка информации о внешних компонентах, определяющих окру-
жение системы или вовлеченных в интеграцию; 8) недостатки в работах, выполняемых внешними по отношению к про-
екту ресурсами;
9)недостаточная производительность получаемой системы;
10)«разрыв» в квалификации специалистов разных областей знаний.
В [3] приводится несколько иной список наиболее важных источников рисков любого проекта разработки ПО:
1)изъяны календарного планирования;
2)текучесть кадров;
3)раздувание требований;
4)нарушение спецификаций;
5)низкая производительность.
Результатом идентификации рисков должен стать список рисков с описанием их основных характеристик: причин, условий, последствий и ущерба.
В процесс идентификации рисков должна быть вовлечена вся команда, пересмотру перечня рисков следует уделять внимание на каждом совещании.
Когда перечень составлен, проводят качественный анализ рисков, для того, чтобы осуществить ранжирование. Количественной оценке, или расче-
ту, во что количественно выльется тот или иной риск, если он сработает, подвергаются не все, а только имеющие наиболее высокий приоритет риски.
Наконец, команда планирует стратегию реагирования на выявленные риски. Причиной наиболее часто срабатывающего и наиболее дорогостоящего риска – появления новых требований в конце проекта – является невнимание
15