надо. Методические указания к выполнению лабораторных работ по курсу «. Методические указания к выполнению лабораторных работ по курсу инструментальные средства информационных систем Для студентов бакалавриата
 Скачать 1.81 Mb.
|
|
График работ Составление графика - одна из самых ответственных работ, выполняемых менеджером проекта. Здесь менеджер оценивает дли- тельность проекта, определяет ресурсы, необходимые для реализации отдельных этапов работ, и представляет их (этапы) в виде со- гласованной последовательности. Если данный проект подобен ранее реализованному, то график работ последнего проекта можно взять за основу для данного проекта. Но затем следует учесть, что на отдель- ных этапах нового проекта могут использоваться методы и подходы, отличные от использованных ранее. Если проект является инновационным, первоначальные оценки длительности и требуемых ресурсов наверняка будут слишком опти- мистичными, даже если менеджер попытается предусмотреть все воз- можные неожиданности. С этой точки зрения проекты создания ПО не отличаются от больших инновационных технических проектов. Новые аэропорты, мосты и даже новые автомобили, как правило, появляются позже первоначально объявленных сроков их сдачи или поступления на рынок, чему причиной являются неожиданно возникшие проблемы и трудности. Именно поэтому графики работ необходимо постоянно обновлять по мере поступления новой информации о ходе выполне- ния проекта. В процессе составления графика (рис. 5.2) весь массив работ, необходимых для реализации проекта, разбивается на отдельные эта- пы и оценивается время, требующееся для выполнения каждого этапа. Обычно многие этапы выполняются параллельно. График работ дол- жен предусматривать это и распределять производственные ресурсы между ними наиболее оптимальным образом. Нехватка ресурсов для выполнения какого-либо критического этапа - частая причина задерж- ки выполнения всего проекта. Длительность этапов обычно должна быть не меньше недели. Если она будет меньше, то окажется ниже точности временных оце- Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко нок этапов, что может привести к частому пересмотру графика работ. Также целесообразно (в аспекте управления проектом) установить максимальную длительность этапов, не превышающую 8 или 10 не- дель. Если есть этапы, имеющие большую длительность, их следует разбить на этапы меньшей длительности. При расчете длительности этапов менеджер должен учиты- вать, что выполнение любого этапа не обойдется без больших или ма- леньких проблем и задержек. Разработчики могут допускать ошибки или задерживать свою работу, техника может выйти из строя либо ап- паратные или программные средства поддержки процесса разработки могут поступить с опозданием. Если проект инновационный и техни- чески сложный, это становится дополнительным фактором появления непредвиденных проблем и увеличения длительности реализации проекта по сравнению с первоначальными оценками. Требования к ПО Диаграммы процессов и временные диаграммы Рис. 5.2.- Процесс составления графика работ Кроме временных затрат, менеджер должен рассчитать другие ресурсы, необходимые для успешного выполнения каждого этапа. Особый вид ресурсов — это команда разработчиков, привлеченная к выполнению проекта. Другими видами ресурсов могут быть необ- ходимое свободное дисковое пространство на сервере, время исполь- зования какого-либо специального оборудования и бюджетные сред- ства на командировочные расходы персонала, работающего над про- ектом. Существует хорошее эмпирическое правило: оценивать вре- менные затраты так, как будто ничего непредвиденного и "плохого" не может случиться, затем увеличить эти оценки для учета возможных проблем. Возможные, но трудно прогнозируемые проблемы сущест- венно зависят от типа и параметров проекта, а также от квалификации и опыта членов команды разработчиков. К исходным расчетным оценкам рекомендуется добавлять 30% на возможные проблемы и за- тем еще 20%, чтобы быть готовым к тому, что невозможно предви- деть. Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко График работ по проекту обычно представляется в виде набора диаграмм и графиков, показывающих разбиение проектных работ на этапы, зависимости между этапами и распределение разработчиков по этапам. Временные и сетевые диаграммы Временные и сетевые диаграммы полезны для представления графика работ. Временная диаграмма показывает время начала и окончания каждого этапа и его длительность. Сетевая диаграмма ото- бражает зависимости между различными этапами проекта. Эти диа- граммы можно создать автоматически с помощью программных средств поддержки управления на основе информации, заложенной в базе данных проекта. Рассмотрим этапы некоего проекта, представленные в табл. 2, из которой, в частности, видно, что этап Т3 зависит от этапа Т1. Это значит, что этап Т1 должен завершиться прежде, чем начнется этап Т3. Например, на этапе Т1 проводится компонентный анализ созда- ваемого программного продукта, а на этапе Т3 — проектирование системы. На основе приведенных значений длительности этапов и зави- симости между ними строится сетевой график последовательности этапов (рис. 5.3). На этом графике видно, какие работы могут выпол- няться параллельно, а какие должны выполняться последовательно друг за другом. Этапы обозначены прямоугольниками. Контрольные отметки и контрольные проектные элементы показаны в виде овалов и обозначены (как и в табл. 5.2) буквой М с соответствующим номером. Даты на данной диаграмме соответствуют началу выполнения этапов. Сетевую диаграмму следует читать слева направо и сверху вниз. Таблица 5.2 - Этапы проекта Этап Длительность (дни) Зависимость Т1 8 Т2 15 Т3 15 Т1 (М1) Т4 10 Т5 10 Т2, Т4 (М2) Т6 5 Т1, Т2 (М3) Т7 20 Т1 (М1) Т8 25 Т4 (М5) Т9 15 Т3, Т6 (М4) Т10 15 Т5, Т7 (М7) Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко Т11 7 Т9 (М6) Т12 10 Т11 (М8) Рис. 5.3. Сетевая диаграмма этапов Если для создания сетевой диаграммы используются про- граммные средства поддержки управления проектом, каждый этап должен заканчиваться контрольной отметкой. Очередной этап может начаться только тогда, когда будет получена контрольная отметка (ко- торая может зависеть от нескольких предшествующих этапов). По- этому в третьем столбце табл. 2 приведены контрольные отметки; они будут достигнуты только тогда, когда будет завершен этап, в строке которого помещена соответствующая контрольная отметка. Любой этап не может начаться, пока не выполнены все этапы на всех путях, ведущих от начала проекта к данному этапу. Например, этап Т9 не может начаться, пока не будут завершены этапы ТЗ и Т6. Отметим, что в данном случае достижение контрольной отметки М4 говорит о том, что эти этапы завершены. Минимальное время выполнения всего проекта можно рассчи- тать, просуммировав в сетевой диаграмме длительности этапов на са- мом длинном пути (длина пути здесь измеряется не количеством эта- пов на пути, а суммарной длительностью этих этапов) от начала про- Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко екта до его окончания (это так называемый критический путь). В на- шем случае продолжительность проекта составляет 11 недель или 55 рабочих дней. На рис. 5.3 критический путь показан более толстыми линиями, чем остальные пути. Таким образом, общая продолжитель- ность реализации проекта зависит от этапов работ, находящихся на критическом пути. Любая задержка в завершении любого этапа на критическом пути приведет к задержке всего проекта. Задержка в завершении этапов, не входящих в критический путь, не влияет на продолжительность всего проекта до тех пор, пока суммарная длительность этих этапов (с учтом задержек) на каком- нибудь пути не превысит продолжительности работ на критическом пути. Например, задержка этапа Т8 на срок, меньший 20 дней, никак не влияет на общую продолжительность проекта. На рис. 5.4 пред- ставлена временная диаграмма, на которой показаны возможные за- держки на каждом этапе. Рис. 5.4. Временная диаграмма длительности этапов Сетевая диаграмма позволяет увидеть в зависимости этапов значимость того или иного этапа для реализации всего проекта. Вни- мание к этапам критического пути часто позволяет найти способы их Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко изменения с тем, чтобы сократить длительность всего проекта. Ме- неджеры используют сетевую диаграмму для распределения работ. На рис. 4 показано другое представление графика работ. Это временная диаграмма (иногда называемая по имени ее изобретателя диаграммой Гантта) может быть построена программными средствами поддержки процесса управления. Она показывает длительность вы- полнения каждого этапа и возможные их задержки (показаны затенен- ными прямоугольниками), а также даты начала и окончания каждого этапа. Этапы критического пути не имеют затененных прямоугольни- ков; это означает, что задержка с завершением данных этапов приве- дет к увеличению длительности всего проекта. Подобно распределению времени выполнения этапов, менед- жер должен рассчитать распределение ресурсов по этапам, в частно- сти назначить исполнителей на каждый этап. В табл. 5.3 приведено распределение разработчиков на каждый этап, представленный на рис. 5.4. Таблица 5.3 - Распределение исполнителей по этапам Этап Исполнитель Т1 Джейн Т2 Анна Т3 Джейн Т4 Фред Т5 Мэри Т6 Анна Т7 Джим Т8 Фред Т9 Джейн Т10 Анна Т11 Фред Т12 Фред Приведенная таблица может быть использована программны- ми средствами поддержки процесса управления для построения вре- менной диаграммы занятости сотрудников на определенных этапах работ (рис. 5.5). Персонал не занят в работе над проектом все время его реализации. В течение периода незанятости сотрудники могут быть в отпуске, работать над другими проектами, проходить обучение и т.д. Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко Рис. 5.5. Временная диаграмма распределения работников по этапам В больших организациях обычно работает много специали- стов, которые задействуются в проекте по мере необходимости. Ко- нечно, такой подход может создать определенные проблемы для ме- неджеров проектов. Например, если специалист занят в проекте, кото- рый задерживается, это может создать прямые сложности для других проектов, где он также должен участвовать. Первоначальный график работ неизбежно содержит какие- нибудь ошибки или недоработки. По мере реализации проекта рассчи- танные оценки длительности выполнения этапов работ должны срав- ниваться с реальными сроками выполнения этих этапов. Результаты сравнения должны использоваться в качестве основы для пересмотра графика работ еще не реализованных этапов проекта, в частности для того, чтобы попытаться уменьшить длительность этапов критического пути. Управление рисками Важной частью работы менеджера проекта является оценка рисков, которые могут повлиять на график работ или на качество соз- даваемого программного продукта, и разработка мероприятий по пре- дотвращению рисков. Результаты анализа рисков должны быть отра- жены в плане проекта. Определение рисков и разработка мероприятий по уменьшению их влияния на ход выполнения проекта называется управлением рисками. Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко Упрощенно риск можно понимать как вероятность проявления каких-либо неблагоприятных обстоятельств, негативно влияющих на реализацию проекта. Риски могут угрожать проекту в целом, созда- ваемому программному продукту или организации-разработчику. Можно выделить три типа рисков. 1. Риски для проекта, которые влияют на график работ или ре- сурсы, необходимые для выполнения проекта. 2. Риски для разрабатываемого продукта, влияющие на качест- во или производительность разрабатываемого программного продукта. 3. Бизнес-риски, относящиеся к организации-разработчику или поставщикам. Конечно, эти типы рисков могут пересекаться. Например, если опытный программист покидает проект, это будет риском для проекта (поскольку задерживается срок сдачи готового продукта), риском для продукта (так как новый программист, заменивший ушедшего, может оказаться не слишком опытным и сделать ошибки в программе) и биз- нес-риском (поскольку задержка данного проекта может негативно повлиять на будущие деловые контакты между заказчиком и органи- зацией-разработчиком). Конкретные типы рисков, которые могут оказать влияние на данный проект, зависят от вида создаваемого программного продукта и от организационного окружения, где реализуется программный про- ект. Вместе с тем многие типы рисков способны повлиять на любые программные проекты, эти риски приведены в табл.5.4. Таблица 5.4 - Возможные риски программных проектов Риск Типы риска Описание риска Текучесть разра- ботчиков Риск для проекта Опытные разработчики по- кидают проект до его за- вершения Изменение в управлении орга- низацией Риск для проекта Организация меняет свои приоритеты в управлении проектом Неготовность ап- паратных средств Риск для проекта Аппаратные средства, ко- торые необходимы для проекта, не поступили во- время или не готовы к экс- плуатации Изменение требо- ваний Риск для проекта и для разрабатывае- мого продукта Появление большого коли- чества непредвиденных из- менений в требованиях, Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко предъявляемых к разраба- тываемому ПО Задержка в разра- ботке специфика- ции Риск для проекта и для разрабатывае- мого продукта Спецификации основных интерфейсов подсистем не поступили к разработчикам в соответствии с графиком работ Недооценка раз- мера разрабаты- ваемой системы Риск для проекта и для разрабатывае- мого продукта Размер системы значитель- но превысил первоначаль- ную оценку Недостаточная эффективность CASE-средств Риск для разраба- тываемого продук- та CASE-средства, предназна- ченные для поддержки про- екта, оказались менее эф- фективными, чем ожида- лось Изменения в тех- нологии разработ- ки ПО Бизнес-риск Основные технологии по- строения программной сис- темы заменяются новыми Появление конку- рирующего про- граммного про- дукта Бизнес-риск На рынке программных продуктов до окончания проекта появилась конку- рирующая программная система Схема процесса управления рисками показана на рис. 5.6. Этот процесс состоит из четырех стадий. 1. Определение рисков. Определяются возможные риски для про- екта, для разрабатываемого продукта и бизнес-риски. 2. Анализ рисков. Оценивается вероятность и последовательность появления рисковых ситуаций. 3. Планирование рисков. Планируются мероприятия по предот- вращению рисков или минимизации их воздействия на проект. 4. Мониторинг рисков. Постоянное оценивание вероятностей рисков и выполнение мероприятий по смягчению последствий проявления рисковых ситуаций. Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко Рис. 5.6. Процесс управления рисками Процесс управления рисками, как и другие процессы планиро- вания, является итерационным, выполняемым в течение всего срока реализации проекта. Сначала разрабатываются планы управления рисками, затем постоянно отслеживается ситуация вокруг реализации проекта. При поступлении новой информации о возможных рисках заново проводится анализ рисков и первостепенное внимание уделя- ется новым рискам. По мере поступления новой информации также изменяются планы мероприятий по предотвращению и смягчению рисков. Результаты процесса управления рисками документируются в виде планов управления рисками. Они должны включать описание возможных проектных рисков, их анализ и перечень мероприятий, необходимых для управления рисками. Определение рисков Определение рисков — первая стадия процесса управления рисками. На этой стадии описываются риски, которые могут про- явиться при реализации проекта. В принципе на этой стадии не долж- на оцениваться вероятность и значимость рисков, но на практике ма- ловероятные риски с незначительными последствиями обычно отбра- сываются сразу. Определение рисков может выполняться в режиме командной работы с использованием подхода "мозговой штурм" либо основы- ваться на опыте менеджера. При определении рисков может помочь приведенный ниже список возможных категорий рисков. 1. Технологические риски. Проистекают из программных и аппа- ратных технологий, на основе которых разрабатывается сис- тема. 2. Риски, связанные с персоналом. Связаны с членами команды разработчиков. 3. Организационные риски. Проистекают из организационного окружения, в котором выполняется проект. Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко 4. Инструментальные риски. Связаны с используемыми CASE- средствами и другими средствами поддержки процесса созда- ния ПО. 5. Риски, связанные с системными требованиями. Проявляются при изменении требований, предъявляемых к разрабатываемой системе. 6. Риски оценивания. Связаны с оцениванием характеристик про- граммной системы и ресурсов, необходимых для реализации проекта. В табл. 5.5 представлены некоторые примеры, относящиеся к каждой из описанных категорий рисков. Результатом этапа определе- ния рисков будет длинный список возможных рисков, которые могут повлиять на разрабатываемый программный продукт, проект или ор- ганизацию-разработчика. Таблица 5.5 - Категории рисков Категория рисков Примеры рисков Технологические риски База данных, которая используется в про- граммной системе, не обеспечивает обработку ожидаемого объема транзакций. Программные компоненты, которые использу- ются повторно, имеют дефекты, ограничиваю- щие их функциональные возможности Риски, связанные с персоналом Невозможно подобрать работников с требуе- мым профессиональным уровнем. Ведущий разработчик заболел в самое крити- ческое время. Невозможно организовать необходимое обу- чение персонала Организационные риски В организации, выполняющей разработку ПО, произошла реорганизация, в результате чего изменились приоритеты в управлении проек- том. Финансовые затруднения в организации приве- ли к уменьшению бюджета проекта Инструментальные риски Программный код, генерируемый CASE- средствами, не эффективен. CASE-средства невозможно интегрировать с другими средствами поддержки проекта Риски, связанные с системными требо- ваниями Изменения требований приводят к значитель- ным повторным темными требованиями ра- ботам по проектированию системы. Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко Первоначальная нечеткая формулировка поль- зовательских требований привела к значитель- ным изменениям системных требований, про- явившихся на поздних стадиях разработки про- екта Риски оценивания Недооценки времени выполнения проекта. Скорость выявления дефектов в системе ниже ранее запланированной. Размер системы значительно превышает пер- воначально рассчитанный |