И. Соммервилл - Инженерия программного обеспечения (1133538), страница 25
Текст из файла (страница 25)
Инженерия программного обеспечения: обзор На основе приведенных значений длительности этапов и зависимости между пимн строится сетевой график последовательности этапов (рис.4.3). На этом графике видно, какие работы могут выполняться параллельно, а какие должны выполняться последовательно друг за другом. Этапы обозначены прямоугольниками. Контрольные отметки и контрольные проектные элементы показаны в виде овалов и обозначены (как и в табл. 4.2) буквой М с соотвстствующнм поиером. Даты на данной диаграмме соответствуют началу выполнения этапов. Сетевую диаграмму следует читать слева направо и сверху вниз.
Таблица 4.2. Этапы проекта Этап Длительность (днн) Зависимость Т! (М1) 14ЛЯ9 15 дней Рис. 4З. Счэнвпя дивг!йээьив эвюивв Т1 Т2 Т5 Т4 Т5 Тб Т7 Т8 Т9 Т10 Т11 Т12 8 15 !г 10 !О 5 20 25 15 15 7 10 Т2, Т4 (М2) Т1, Т2 (М5) '1'1 (М1) т4 (М5) ТЗ, ТО (М4) Т5, Т7 (М7) Т9 (Мб) Т11 (М8) 4. Управление проектами 91 Если для создания сетевой диагрэьльмы используются програмлсные средства пошьсржки управления проектом, каждый этап должен заканчиваться контрольной отметкой. Очередной этап может начаться только тогда, когда будег получена контрольная отметка (которал может зависеть от нескольких предшествующих этапов). Поэтом> в трегьеи столбце табл.
4 2 приведены контрольные отлеетки; они бу1пт достигнуты только тогда, когда будет завершен этап, в строке которого помещена соответсгвующшь контрольная отметка. Любой этап не может начаться, пока не выполнены все агапы на всех путях, ведущих от начала проекта к данному этапу. Например, этап Тй ис может начаться, пока не булгэ жь. всршены этапы ТЗ и Тб. Отметим, что в данном случае достижение контрольной отььстки М4 говорит о том. что эти этапы завершены. Минимальное время выполнения всего проекга можно рассчитать, просуммировав э ссгзи вой диаграмме длительности этапов на самом длинном пуго' от начала ироекщ до его окопча. ния (это тзк называемый хрэьиэкиикиэу ээуиьь).
В пашем случае продолжительность проелть со. ставляст 11 недель или 55 рабочих дней. На рис. 4ед критический путь паюьззьь более толстыми линиями, чсль остальные пути. Таким образом, общая продолжительность реализации проекта зависит от этапов рабэот, находящихся па критическом пти. Любая задсржюэ я завершешш лю. бого этапа иа критическом нуги приведет к задержке всего проекта. Рис. 4.4.
Щэеиьениал диле)ииьчл диээээнльээостьс зиэляоо Дтпл идиш ээвсь имиуиемси ие каамэгивии иллики ил купи, л сээьчл)эьэия дээээпэьэьэьпеэи~и е ь ~юп иик — Прнлэ. рсл, 92 Часть 1. Инженерия программного обеспечению обзор Таблица 4.3. Распределение исполнителей по этапам Исполнитель Джейн Анна Джейн Т1 Т2 Т4 Фред Т5 Мэри Тб Т7 Т8 Фред Т9 Джейн Анна Т10 Т11 Фред Фред Т12 Приведенная таблица может быть использована программными средствами поддержки процесса управления для построения временной диаграммы занятости сотрудников на определенных этапах работ (рис, 4.5).
Персонал ие занят в работе над проектом вес время его реализации. В течение периода незанятости сотрудники могут быть в отпуске, раба- тать над другими проектами, проходить обучение и т.д. Задержка в завершении этапов, не входлших в критический путь, не влияет на продолжительность всего проекта до тех пор, пока суммарная длительность этих этапов (с учетом задержек) на каком-нибудь пути не превысит продолжительности работ на критическом пути. Например, задержка этапа Т8 на срок, меньший 20 дней, никак не влияет на обшую продолжительность проекта. На рис.4.4 представлена временная диаграмма, на которой показаны возможные задержки на каждом этапе.
Сетевая диаграмма позволясг увидеть в зависимости этапов значимость того или иного этапа для реализации всего проекта. Внимание к этапаи критического нуги часто поэзо. ласт найти способы их изменения с тем, чтобы сократить длительность всего проекта. Мспслжеры используют сетевую диаграмму для распределения работ. На рис. 4.4 показано другое предсгавленис графика работ. Это временнля диаграмма (иногда называемая по имени ее изобретателя диаграммой Гантта) может быть построена программными средствами поддержки процесса управления. Она показывает длительность выполнения каждого этапа и возможные их задержки (показаны затененными прямоугольниками), а также даты начала и окончания каждого этапа. Этапы критического пути не имеют затененных прямоугольников; это означает, что задержка с завершением данных этапов приведет к увеличению длительности всего проекта.
Подобно распределению времени выполнения этапов, менеджер должен рассчитать распределение ресурсов по этапам, в частности назначить исполнителей на каждый этап. В табл.4З приведено распределение разработчиков на калсдый этап. представленный на рис. 4,4. 4. Управление проектами 93 В больших организациях обычно работает много специалистов, которые задействуются в проекте по мере необхолимости. Конечно. такой подход может созлать определенные проблемы для менеджеров проектов.
Например, если специалист занят в проекте, который задерживается, это может создать прямые сложности для других проектов, где он также должен участвовать. Рнс. 4.5. Времен нал дипгрпммп Рпон~едглоннл Рпботникоо но этапам Первоначальный график работ неизбежно содержит какис. нибудь ошибки плн недоработки. По мере реализации проекта рассчнтанпыс оценки длительности выполнения этапов работ должны сравниваться с реальными сроками выполнения этих этапов. 1'езультаты сравнения должны использоваться в качестве основы для пересмотра графика работ еще не реализованных этапов проекта, в частности для того, чтобы попытатьсл уменьшить длительность этапов критического пути. 4.4. Управление рисками Важной частью работы менеджера прослта является оценка рисков, когорте могут по.
влиять на график работ или на качество создаваемого программного продукта, и разработка мероприятий по предотвращению рисков. Результаты анализа рисков лолжны быть отражены в плане проелга. Определение рисков и разработка мероприятий по уменынснню их влияния на ход выполнения проекта называется унутагсннпн рноим и 1149, 266, 11 н, 23'!.
Упрощенно риск можно понимать как вероятность проявленнл каких-либо псблагопрн. лтных обстоятельств, негативно влияющих на реализацию проекта. Риски мо~ут угрожать проекту в целом, создаваемому програлгмному продукту или оргапнзацнгнразработчнку. Можно выделить три типа рисков. 1. Риска онл нрогкою, которые влияют на график работ илн рсс>рсы, необходимые для выполнения проекта. 94 Часть Е Инженерия программного обеспечения: обзор 2. >>алки сил Р>л>(>обло>ыооомого я)л>х)уклю, влияющие на качество или производитель. ность разрабатываемого программного продукта.
3. 1>кзнгелискя, относящиеся к организации-разработчику или постав>цикам. Таблица 4.4. Возможные риски программных проектов Риск Текучесть разработчиков Тип риска Описание риска Опытные разработчики покидают про- ект до его завершения Рисклля проекта Изменешш вуправлснии организацией Рискдля проекта Организация меняет свои приоритеты в управлении проектом Неготовность аппарат- ньш средств Риск для проекта Аппаратные средства, которые необхо- димы для проекта, нс постл иилп вовре- мя или нс готовы к эксплуатации Измеисциетребований Рискдлл проекта н для разрабатываемого продукта Появление болыпого количества нс- предвиденных изменений в трсбовани.
ях, предъявляемых к разрабатываемому ПО Спецификации основных интерфейсов подсистем ис поступили к разработчи- кам в соответствии с графиком работ Риск для проекта и для разрабатываемого продул-га Задержка в разработке спецификации Нелооцсика размера раз- рабатываемой снстел>ы Риск для проекта и длл разрабатываемого продткта Размер систел>ы значительно превысил первоначальную оценку Недостаточная эффек.
тивиость САЯЕ средств САЯЕ-срелства, предназначенные для поддержки проекта, оказались мсисс эффективными, чем ожидалось Риск для разрабаты- ваемого продукта Основныс тсхиолоп>и построешш программной системы замснлются новылш Изменения в технологии разработки ПО Б>изнес-риск Пола>синс конлурир>ю- щего программного про- дукта На рынке программных продуктов до окончания проекта появилась конкури- рующая программная система Бизнес-риск Конечно, эти типы рисков могут пересекатьсл.
Например, если опытный программист покидает проект, это будет рискол> для проекта (поскольку задерживается срок сдачи готового продукта), риском для продукта (так как новый программист, заменивший ушедшего, может окааатьсл не слив>ком оиытньв> и сделать ошибки в программе) и бизнес-рискол> (поскольку задержка данного проелта может негативно повлиять на будущие деловые кон. такты между заказчиком и организацией-разработчиком). Конкретные типы рисков, которые могут оказать влияние на данный нроскг, завнслт от вида создаваемого программного продукта и от организационного окружеиил, где реализуется программный проект.
Вместе с тем многие типы рисков способны повлиять на любые программные проекты, эти риски приведены в табл. 4.4. 4. Управление проектами 95 Схелта процесса управления рисками показана на рис. 4.6. Этот процесс состоит из четырех стадий. 1. Олргделение рисков. Определяются возможные риски для проекта, для разрабатываемого продукта и бизнес-риски.
2. Анализ рисков. Оценивается вероятность и последовательность появления рисковлж ситуаций. 3. Лллиировпние Рисков Планируются мероприятия по предотвращению рисков илн минимизации их воздействия на проект. 4. Моттттнторитп >висков. Постоянное оцспивание вероятностей рисков н выполнение мероприятий по смягчению последствий проявления рисковых ситуаций. Мвроорннпта по Оценки предогврацпнно рисков рисков Список первостепенных рисков Слнсок потенциальных расков Риа 46. Лрвцеее упрлалеттил Риеками 4.4.1. Определение рисков Определение рисков — перван стадия процесса управления рисками. 11а этой стадии описываются риски, которые могут проявиться прн рсалцззцнн проекта.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
