И. Соммервилл - Инженерия программного обеспечения (1133538), страница 24
Текст из файла (страница 24)
В таком плане обнзательно присутствуют ссылки на планы других видов, по <нш разрабатьн>аются отдельно от плана прося па. План. сгруктуру которого л прслставлю ниже, принадлежит именно к последнему типу планов. Детализация планов проскгов очень разнится в зависимости от типа разрабатываемого программного продукта и организации-разработчика, Но в любом случае больш<шство планов содержат следуюн1нс разделы. 1.
Вкгдгллг. Краткое описание целей проекта и проектных ограничений (бюджстных, временных н тщ,), которые важны длл управления проектом. 4. Управление проектами 87 2. ОРгшгкзлцмл вигимкгнил я(лххпш. Описание способа подбора команды разработчиков н распределение обязанностей между членами команды. 3. Аиалкз ушскаа. Описание возможных проектных рисков, веролтпости их проявленил и стратегий, направленных иа их уменьшение. Тема управления рисками рассмотрена в разделе 4.4. 4. Алнпрпжкые и п~~аг~пьитме умг>умм, левбходкчые длл лемизлвкн лРескэю. Перечень аппаратных средств и программного обеспечеиил, необходимого для разработки программного продукта. Если аипаратныс средства требустсл закупать, приводится их стоимость совместно с графиком закупки и поставки. 5.
Разбиение Рядил нл юаляы Процесс реализации проекта разбивается на отдельные процессы, определяются этапы вьшолненил проекта, приводится описание результатов ("выходов") каждого этапа и контрольные отметки. Эта тема представлена в разделе 4.2.2. 6. РРпфик рлбат В этом графике отображаются зависимости между отдельными про. цессами (этапалш) разработки ПО, оценки времени их выполнения и распределение членов команды разработчиков по отдельным этапам. 7. Мгханкзяи моииггшрикгл к кокэфаал зп ходом вмлзалгкия гфсгхэю. Описываютсл предоставляемые менеджером отчеты о ходе выполнения работ, сроки ик предоставления, а также механизмы мониторинга всего проекта.
План должен регулярно пересматриваться в процессе реализации проекта. Олпи части плана, например график работ, измспяютсл часто. другие более стабильны. Длн внесения изменений в илам требуется специальная органиэация докумснтопотока, позволяющая отслеживать эти изменения. 4.2.2. Контрольные отметки этапов работ Менеджер> для организации процесса создания ПО н управления им необходима инфорлшция. Поскольку само программное обеспечение неосязаемо, эта управлснческал ииформацил мокнет быть получена только в виде документов, отображающих выполнение очередного этапа разработки программного продукта.
Без этой информации нельзя судить о степени готовности создаваемого пропукта, невозможно оценить произведенные затраты или изменить график работ. При планировании процесса определяются хонэфолькые ожмежки — вехи, отмечающие окончание определенного этапа работ. Для каждой контрольной отметки создасзтя отчет, который предоставляется руководству проекта. Эти отчеты нс должны быть болыними объемнььеи долумептамп; они должны полволить краткие итоги окончания отдельного логически завершенного этапа проекта. Этапом не может быть, например, "! (апнсанис 80% кода программ", поскольку невозможно проверить завершение такого "этапа"; кроме того. подобная информ'щия практически бесполезна для управления, поскольку здесь пе отображаетсл связь этого "этапа" с другими этапами создания ПО.
Обычно по завершении основных больших этапов. таких как разработка спецификации. проектирование и т.п., заказчику ПО предоставляются результаты их выполнения, так пазы. ваемые кокзролъяме я(югктхиг злелелциы. Это можег быть долумснтшиш, прототип про. грачмиого продукта, закопченные подсистемы ПО и т.д. Контрольные проектные элементы, предоставляемые заказчику ПО, мо~>т совпадать с контрольными отметками (точнее, с резулиштами выполнения какого-либо этапа). ~о обратное >твсрждение неверно. Коитрольныс отметки — это внутренние проектные результаты, которые используются для контроля за ходом выполнения проекта, и опи, как правгио, нс прсдоставзюотся заказчику ПО. 88 л1асть 1.
Инженерия программного обеспечення: обзор Для определения контрольных отметок весь процесс создания ПО должен быть разбит на атделылыс этапы с указаннылг "выходом" (результатом) каждого этапа. Например, на рис. 4.1 показаны этапы разработки спецификации требований в случае, когда для ее про. верки используется прототип системы, а также представлены выходные результаты (контрольные отметки) каждого этапа, Здесь контрольными проектными элементами являются требования и спецификация требований.
КОНТРОЛЬНЫЕ ОТМЕП(И Риа 4 д Эмияы лл)лоцгсси )ииРаботки спецификации 4.3. График работ Составление графика — одна иэ самых ответственных работ, выполняемых менеджером проекта. Здесь менеджер оценивает длительность проекта, определяет ресурсы, необходимые для реализации отдельньш этапов работ, и представляет их (этапы) в виде согласованной последовательности. Если данный проект подобен ранее реализованному, то график работ последнего проекта можно 'взять за основу для данного проекта. Но затем следует учесть, что па отдсльшах этапах нового проекта могут использоваться методы и подходы, отли шые от использованных ранее.
Если проект является инновационным, первоначальные оценки длительности и требуемых ресурсов наверняка будут слишком оптимистичными, даже если менеджер попытается предусмотреть все возможные неожиданности. С этой точки зрения проекты создания ПО пе отличаются от больших инновационных технических проектов. Новые аэропорты, мосты и даже лювые автомобили, как правило, появляются позже первоначально объявленных сроков нх сдачи пли поступления на рынок, чему причиной являются неожиданно возникшие проблемы и трудности.
Именно поэтому графики работ необходимо постоянно обновлять по мере поступленпл новой информации о ходе выполнения проекта. Б процессе составления графика (рис. 4.2) весь массив работ, необходимых для реализации проекта, разбивается на отдельные этапы и оценивается время, требующееся для выполнения каждого этапа. Обычно многие агапы выполняются параллельно.
График работ должен прсдуслгатрнвать это и распределять производственные ресурсы между ними наиболее оптимальным образом. Нехватка ресурсов для выполнения какого-либо критического этапа — частая причина задержки выполнения всего проекта. Ллитсльпость этапов обычно должна быть не меньше недели. Если она будет меньше, та окажется ниже точности временных оценок этапов, что может привести к частому пересмотр> графика работ. Также целесообразно (в аспекте управления проектом) установить максимальну|а длительность этапов, не превышающую 8 или 1О недель.
Если есть этапы, имеющие большую длительность, их следует разбить иа этапы меньшей дли- тельности. 4. Управление проектами 89 При расчете длительности этапов менеджер должен учитывать, что выполнение любого этапа не обойдется без больших или маленьких проблем н задержек. Разработчики могут допускать ошибки или задерживать свою работу, техника может выйти из строя либо аппаратные или программные средства поддержки процесса разработки могут поступить с опозданием.
Если проект инновационный и технически сложный, это становится дополнительным фактором появления непредвиденных проблем и увеличения длительносги реализации проекта по сравнению с первоначальными оценками. Требовании к ПО Рис. 4.2. Лроыгсг сосэюлынил графики Рлйни Диаграммы процессов и временные диаграммы 4.3.1. Временные и сетевые диаграммы Врелгсггные и сетевыс диаграмлгы полезны для представления графика работ. Времен.
ноя диаграмма показывает время начала и окончания каждого этапа и его длительность. Сетевая диаграмма отображает зависимости между различными этапами проекта. Эти диаграммы можно создать автоматически с помощью программных средств подлсржкн управления на основе информации, заложенной в базе данных проекта. Рассмотрим этапы некоего проекта, представленные в табл. 4.2, из которой, в частности, видно, что этап ТЗ зависит от этапа Т1. Это значит, что этап Т! должен завсрглиться прежде, чем начнется этап ТЗ. Например, на этапе Т1 проводится компонентный анализ создаваемого программного пролукта, а на этапе ТЗ вЂ” проектирование системы. Кроме временных затрат, менеджер должен рассчитать другие ресурсы, необходимые для успешного выполнения каждого этапа. Особый вид ресурсов — зто команда разработчиков, привлеченная к выполнению проекта.
Другими видами ресурсов могут быть необ. ходимос свободное дисковое пространство на сервере, время использования какого-либо специального оборудования и бюджстныс средства на командировочные расходы персонала, работающего над проектом. Более детально виды н методы оцсниванпя необходимых ресурсов рассматриваются в главе 2З. Существует хорошее эмпирическое правило: оценивать временные затраты так, ьэк б!дто ничсто непредвиденного и "плохого" не может сл!читьсл, затем увеличить этн оценки для учета возможных проблем. Возможные, но трудно пропюзируеиые проблелгы существенно зависят от типа и параметров проекта, а также от квалификации и опыта членов команды разработчиков.
Так как зто правило эмпирическое, позволю дать совет, основанный на моем опыте. К исходным риючетныы оценкам я всегда добавляю З0% на эозможныс проблемы и затем еще 20%, чтобы быль готовым к тому, что я не могу предвидсп График работ по проекту обычно представляется в виде набора диаграмм и графиков. показывающих разбиение проектных работ на этапы, зависимости между этапалги и рас. пределение разработчиков по этапам. Эти диаграммы рассматриваются в следующем раз. деле. Отмечу, что в настоян!се время существует мгюго различных программных средств поддержки управления проектами, например М!сгозой Рго!ось 90 Часть 1.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
