Software & Systems

Важнейшим компонентом жизненного цикла проекта программного изделия (ПИ) [1,2] является фаза планирования (фаза разработки проектного плана). Проектный план с точки зрения руководителя любого ранга является эталонной моделью хода выполнения проекта. Такая модель строится в начале проекта с целью обеспечения руководителям возможности своевременного обнаружения отклонений от плановых (эталонных) показателей при отслеживании хода его выполнения. Выявленные отклонения служат количественной базой в цепи обратной связи при организации процесса управления проектом. Наличие хорошо составленного проектного плана (эталонной модели, реально отражающей условия проведения проекта) обусловливает возможность завершения проекта в установленные сроки с заданным качеством. Проектный план также обеспечивает создание условий для нахождения и исправления ошибок и дефектов, допускаемых в проекте в ходе его выполнения.

Проектный план после его утверждения (в АОЗТ «Информационные деловые услуги» (ИДУ) план утверждают заказчик и администрация) становится исходной точкой (началом координат) для измерения изменений величин ресурсов проекта (трудоемкости, технических, программных, информационных, финансовых, организационных и др.). В этом возникает необходимость, когда в дальнейшем поступают новые пожелания заказчика по проекту. В утвержденном плане все его объекты (стоимость проекта, срок его окончания, его ресурсы и качество конечного продукта) согласованы друг с другом. Изменения в любом из согласованных объектов утвержденного плана в ходе выполнения проекта неизбежно приводят к отклонениям в утвержденных плановых (эталонных) показателях. Поэтому утвержденный проектный план в таком случае обеспечивает руководителю проекта возможность обоснованного общения с заказчиком при обсуждении необходимости корректировки некоторых ресурсов проекта, так как он может сравнивать вызванные отклонения от показателей утвержденного проектного плана.

Как отмечалось, проектный план является базой для управления проектом. К сожалению, проектный план представляет собой сложную, труднообозримую систему. Известно, что степень сложности любой системы определяется количеством безошибочно перебираемых человеком элементов системы и числом взаимодействий элементов между собой (оценкой количества перестановок из элементов системы), то есть объемом информации, с которым приходится работать одновременно. Для того чтобы упростить обозримость системы, прибегают к иерархической модели ее представления. В иерархической модели стараются снизить сложность каждого уровня иерархии системы (ограничить подробность описаний элементов системы на каждом уровне модели). При этом стремятся, чтобы на каждом иерархическом уровне был примерно одинаковый объем информации, с которым приходится одновременно работать.

Поэтому для превращения проектного плана в эффективное средство управления проектом целесообразно его представить в виде многоуровневой модели, в которой уровни планирования отличались бы друг от друга степенью детализации задач. Опыт, накопленный в АОЗТ ИДУ, показывает, что в иерархической модели проектного плана необходимо иметь четыре уровня. Годовой – высший уровень иерархии (полное, но не обязательно подробное описание проектного плана), ежеквартальный, ежемесячный и еженедельный. Еженедельный план является низшим уровнем иерархии, самым подробным описанием проектного плана с почасовой загрузкой каждого исполнителя. Фрагмент такой иерархии планов показан на рисунке 1.

В АОЗТ ИДУ сначала составляется укрупненный годовой проектный план, который подлежит обязательному утверждению. После утверждения годового плана осуществляется его декомпозиция в квартальные планы. Далее производится декомпозиция квартальных планов в месячные, а на первый текущий календарный месяц составляется понедельный план. В конце каждой текущей календарной недели осуществляется уточнение плана на следующую и последующую календарные недели. При этом детальный недельный план на следующий календарный месяц должен быть подготовлен к окончанию предпоследней недели текущего календарного месяца. Все перечисленные уровни описания проектного плана должны быть тесно связаны друг с другом. Каждое последующее описание должно являться уточнением предыдущего и быть более детализированным.

Такой способ планирования использовался и продолжает использоваться в АОЗТ ИДУ при проведении более 12 проектов по созданию ПИ для различных предметных областей в течение четырех лет, причем каждый выполненный проект закончился в назначенный срок с заданным качеством и без превышения выделенных ресурсов. Наличие представленной на рисунке 1 иерархии проектного плана дало руководителям проектов в АОЗТ ИДУ возможность ежедневного оценивания объемов выполненных работ каждым исполнителем и реальных трудоемкостей запланированных работ. В результате этого у руководителей появилась возможность еженедельной корректировки загрузки исполнителей, уточнения месячных и квартальных планов, предвидения приближения критических ситуаций и своевременного принятия необходимых действий по их предотвращению. Иными словами, в руках руководителя появился эффективный инструмент для управления проектом.

Наличие многоуровневого проектного плана является необходимым условием превращения его в эффективный инструмент управления проектом ПИ. Для того чтобы это условие стало не только необходимым, но и достаточным, следует осуществить в ходе выполнения проекта ежедневный сбор и накопление реальных данных (метрик) [3,7] о состоянии всех показателей проектного плана.

Ключевыми метриками проектного плана являются данные о количестве затраченных ресурсов; о реальных трудоемкостях, потребовавшихся для выполнения каждой плановой работы; о сроках окончания выполненных работ; о размерах создаваемых продуктов проекта; о количестве допущенных, устраненных и оставшихся ошибок и дефектов в ПИ. Именно анализ этих метрик и сопоставление их на текущий момент с плановыми показателями (сопоставление с данными эталонной модели) позволяют руководителю судить о реальном ходе выполнения проекта (определять отставания и опережения графика, отслеживать темпы расходования ресурсов, предвидеть возможность приближения критических ситуаций и многое другое, что необходимо для успешного управления проектом ПИ).

Для повышения эффективности выполнения проектов ПИ в АОЗТ ИДУ принята единая технология их проведения (стандартный процесс) [4,5,8]. Внедрение стандартного процесса потребовало некоторых дополнительных затрат, времени и терпения [9]. Однако соблюдение всеми сотрудниками в своей работе единой методики труда (процедур, правил, стандартов и т.п.), определенной стандартным процессом, сторицей окупило затраченные усилия. При соблюдении стандартного процесса каждый проект в АОЗТ ИДУ выполнялся слаженно, строго поддерживалась запланированная последовательность в появлении отдельных продуктов проекта, повысилась производительность труда исполнителей, улучшилось качество создаваемых продуктов.

Обязательными мероприятиями стандартного процесса являются обзоры результатов разработки проектного плана [10], которые в соответствии со стандартным процессом осуществляются в проектной группе, администрацией ИДУ и заказчиком. Такие обзоры предназначены для повышения качества проектного плана, то есть для повышения вероятности получения эталонной модели хода выполнения проекта, реально отражающей условия проведения проекта. Это достигается путем выявления и устранения возможных ошибок планирования, выяснения реальности графиков выполнения плановых работ, достаточности планируемых ресурсов.

Автоматизация разработки проектного плана

Для обеспечения ускорения внедрения стандартного процесса в АОЗТ ИДУ была создана автоматизированная система управления проектом ПИ, получившая название "Система-советчик для руководителя проекта" (РLA) [6,11,12].

С использованием системы PLA возможно выполнение автоматизированных модельных расчетов численности исполнителей при заданных сроках выполнения проекта и качестве ПИ; составление и редактирование проектных планов различной степени детализации (годовых, квартальных, месячных, недельных) и ведение базы данных проектных планов; осуществление сбора установленных стандартным процессом метрик и ведение метрической базы данных проекта; выполнение автоматической генерации принятых метрических отчетов и отчетов о ходе выполнения проекта. Система PLA реализована на программных пакетах MS Excel и MS Project с использованием языка программирования Visual Basic for Application в среде Windows-95.

При планировании проектных работ в АОЗТ ИДУ введены ограничения, которые обусловлены накопленным полезным опытом по выполнению проектов ПИ и спецификой применения пакета MS Project. Эти ограничения следующие:

-     каждая плановая работа должна иметь свое уникальное имя;

-     каждая работа на недельном уровне планирования должна планироваться для выполнения только одним исполнителем, то есть одна работа на недельном уровне планирования не может выполняться двумя и более исполнителями;

-     для каждого исполнителя в недельных планах необходимо предусматривать не менее двух работ, завершающихся на текущей неделе;

-     все работы, выполняемые в течение проекта, должны быть в обязательном порядке запланированы, то есть ни одна незапланированная работа не должна приниматься к исполнению в ходе выполнения проекта.

Исходными данными для составления проектного плана являются: предполагаемый объем ПИ; согласованные с заказчиком длительность проекта и штатное расписание проектной группы, аппаратные и программные средства для выполнения проекта, все поставки заказчику в ходе выполнения проекта и их сроки; другие обязательства по проекту (например, обязательства по управлению конфигурацией ПИ, по периодичности отчетов о ходе выполнения проекта, по подаче патентных заявок, подготовке статей и публичных выступлений и т.п.). Кроме того, к исходным данным для планирования относятся все данные, полученные при анализе возможных рисков в проекте.

Разработка проектного плана с использованием системы PLA осуществляется в режиме "Планирование" по принципу сверху вниз. В результате этой работы создаются последовательно четыре вида проектного плана: годовой, квартальный, месячный, недельный. Все создаваемые планы в этом случае автоматически записываются и хранятся в базе данных проектного плана.

Годовое планирование в системе PLA (рис. 2) начинается с составления полного описания годового проектного плана, в котором не указываются все детали. В годовом плане определяются роли и осуществляется разграничение обязанностей каждого исполнителя проекта. В нем также строятся графики выполнения и взаимоувязки выполняемых работ; определяются способы разрешения рисков, сопровождающих выполнение плана проекта.

В годовом проектном плане детализируются основные работы на фазах жизненного цикла разработки ПИ с учетом их трудоемкости, с разбивкой сроков начала и окончания по кварталам, с указанием команды, выполняющей указанные работы, и ответственного за планируемые работы. В него включаются все поставки заказчику в ходе выполнения проекта с разбивкой сроков окончания по кварталам (ответственным за поставки должен быть руководитель проекта).

В годовой план должны быть включены также все повторяющиеся (по определению в пакете MS Project – рекурсивные) работы с указанием их трудоемкости, периода повторения и ответственных за выполнение. К ним относятся мероприятия по управлению конфигурацией и представлению отчетов о ходе выполнения проекта; по улучшению качества ПИ и другие работы, предусмотренные стандартным процессом. Кроме того, в годовой план должны быть включены обязательства по подаче патентных заявок, подготовке статей и публичных выступлений также с указанием их трудоемкости, ответственных и сроков окончания с разбивкой по кварталам.

Процесс создания проектного плана является итерационным, на каждом шаге итерации должны выделяться и устраняться допущенные при планировании ошибки. При составлении плана устранение выявленных ошибок на каждом шаге итерации является основной задачей, поскольку их устранение пока не поддается автоматизации.

Для автоматизации процесса обнаружения ошибок, допущенных при планировании, используются средства системы PLA, которые расширяют и дополняют возможности имеющихся в ней соответствующих средств пакета MS Project. Процесс создания годового проектного плана считается законченным тогда и только тогда, года в нем учтены все исходные данные планирования и все другие работы, предусмотренные стандартным процессом, а средствами системы PLA больше не удается обнаружить ошибок годового планирования.

На рисунке 2 справа расположена диаграмма годовой загрузки каждого исполнителя из проектной группы, которая автоматически вычисляется по трудоемкости планируемых работ. Для обеспечения возможности сравнения загрузки планируемой с допустимой на диаграмме показаны допустимая загрузка исполнителей, обусловленная законодательством РФ и условиями контракта. На этапе годового планирования следует следить лишь за тем, чтобы планируемая загрузка не превышала допустимую или не слишком отличалась от нее в сторону уменьшения. Корректировку баланса загрузки каждого исполнителя руководитель проекта обычно выполняет на уровнях квартального и месячного планирования, а полного баланса добивается на уровне недельного планирования.

После завершения составления и утверждения годового проектного плана можно приступить к разработке квартальных планов. Для выполнения декомпозиции годового плана в квартальные используется соответствующая секция системы РLA, которая вызывается на экран монитора подобно годовой, но с указанием номера требуемого квартала. В квартальную секцию планирования из годового плана (из базы данных проектного плана) автоматически заносятся работы, ранее спланированные на выбранный квартал. После этого можно приступить к разукрупнению вызванных позиций годового плана. Квартальные планы должны быть: более подробными, чем годовой, разнесенными по месяцам планируемого квартала, и содержать перечень работ по фазам жизненного цикла проекта ПИ. Для каждой работы необходимо уточнить ее трудоемкость, состав исполнителей и дату ее завершения. Контроль загрузки сотрудников в планируемом квартале осуществляется так же, как и при годовом планировании.

Для повышения точности и качества планирования к месячному планированию следует переходить только после завершения квартальных планов. Для осуществления месячного планирования на экран монитора вызывается соответствующая секция планирования системы РLA с указанием порядкового номера месяца, для которого предполагается разработка плана. При этом из годового и квартального планов в вызванную секцию из базы данных проектного плана автоматически помещаются только те работы, которые в ранее созданных планах относились к выбранному месяцу. Степень подробности месячного плана определяется руководителем проекта, но с непременными условиями: в месячном плане перечень работ должен быть более подробным, чем в квартальном; все работы должны быть разнесены по неделям; определена трудоемкость каждой работы, срок ее завершения и ответственный за ее выполнение. При месячном планировании достаточно следить лишь за тем, чтобы планируемые трудоемкости на исполнителей не превышали их допустимых значений.

Недельный план является самым подробным в иерархии проектного плана (см. рис. 1). Недельное планирование начинается с вызова недельной секции, где указывается первый день недели, для которой предполагается создание или корректировка почасового плана. В вызванную секцию из базы данных проектного плана автоматически помещаются приходящиеся на нее работы из ранее созданных планов (годового, квартального, месячного или недельного).

При исходном (проводящемся впервые) недельном планировании следует осуществить декомпозицию месячного плана минимум на первые две недели указанного месяца. При этом целесообразно планировать для каждого исполнителя не менее двух работ, завершающихся на каждой текущей неделе. В недельном плане устанавливается почасовая загрузка каждого исполнителя, поэтому именно при недельном планировании выполняется окончательная балансировка загрузки всех исполнителей. С целью облегчения такой балансировки в режиме планирования системы РLA предусмотрена специальная экранная форма, которая показана на рисунке 3.

Экранная форма (рис. 3) состоит из трех частей. Справа расположена диаграмма недельной загрузки всех исполнителей проекта. Недельная загрузка вычисляется как суммарная трудоемкость всех планируемых работ на неделю для каждого исполнителя в отдельности. Если для кого-либо из исполнителей не достигнуто баланса загрузки, то на диаграмме будет наблюдаться отклонение плановой загрузки от допустимой в сторону уменьшения или увеличения.

Диаграмма плановых работ на неделю расположена слева, она состоит из дух частей – верхней и нижней. Данные на верхней и нижней диаграмме автоматически генерируются из базы данных проектного плана. Причем верхняя часть включает только работы исполнителя, инициалы которого были указаны при вызове секции. Для первого дня недели автоматически строится диаграмма Ганта, минимальным временным отрезком которой является один час. Вызывая поочередно работы исполнителя, запланированные для каждого дня недели, по диаграмме Ганта руководитель проекта может визуально быстро найти, где именно (при выполнении какой работы) произошел разбаланс загрузки этого исполнителя и произвести уточнение недельного плана.

Нижняя часть диаграммы (рис. 3) включает в себя все работы, запланированные на неделю, указанную при вызове недельной секции. Эта часть диаграммы обеспечивает возможность осуществления обзора работ, планируемых (или запланированных ранее) для всех исполнителей проекта, что обусловливает ускорение процесса уточнения недельного плана при балансировке загрузки. При необходимости можно вызвать в верхнюю часть диаграммы недельные работы для другого исполнителя, используя для этого средства системы PLA, и произвести балансировку загрузки этого исполнителя.

Балансировка плановой загрузки всех исполнителей проекта ПИ, которая выполняется на недельном уровне планирования, является заключительным этапом создания проектного плана. После завершения этапа балансировки загрузки исполнителей получается проектный план, который представляет собой описание многоуровневой эталонной модели хода выполнения проекта со степенью подробности, доведенной до уровня почасовой загрузки каждого исполнителя. Такая модель призвана обеспечить руководителю не только успешное управление проектом, но и успешное его завершение в назначенный срок с заданным качеством.

Оценка рисков в проектном плане

Залогом успешного проведения проекта ПИ является обязательное выявление и планирование эффективных мер для разрешения критических ситуаций (рисков), которые могут возникнуть во время осуществления проектного плана. Выявление возможности возникновения и планирование разрешения рисков (управление рисками) осуществляется на фазе жизненного цикла разработки ПИ "Планирование" при создании проектного плана.

В стандартном процессе АОЗТ ИДУ риски подразделены на четыре основных категории:

·          технические (например, связанные с возможным невыполнением обязательств заказчика или поставщика по требуемому аппаратному, программному, информационному, финансовому и другому обеспечению);

·          организационные (административные) риски (например, неправильная организация разделения работ между исполнителями);

·          риски, связанные с недооценкой сложности разрабатываемого ПИ (например, подбор недостаточно квалифицированной команды исполнителей, что может привести к срыву графика выполнения проекта);

·          форс-мажорные риски (например, обусловленные изменением политики правительства в области налогообложения, что может привести к закрытию проекта).

Выявление рисков, то есть предвидение и классификация в начале проекта критических ситуаций, которые могут возникнуть во время его проведения, осуществляется на основе предшествующего накопленного опыта. Если подобного опыта недостаточно, то целесообразно привлекать к этой работе независимых экспертов (как правило, не менее трех) и строить стратегию управления рисками на основе усредненных экспертных данных.

После выявления возможных рисков необходимо определить оценку вероятности их возникновения и степень серьезности их влияния на ход выполнения проекта. Степень серьезности риска определяется дробным числом из интервала 0-1 и характеризуется возможным влиянием риска на срыв сроков выполнения отдельных работ по проекту или проекта в целом. После того как определены оценки вероятности возникновения выявленных рисков и степень их серьезности, необходимо определить значения их весов. Величина веса риска определяется как произведение вероятности его возникновения на степень его серьезности.

После этого следует упорядочить риски по убыванию их весов и тщательно спланировать управление наиболее опасными рисками. Риски, которые имеют наибольший вес, считаются наиболее опасными. На эти риски необходимо обращать особое внимание.

Далее необходимо уточнить возможный момент возникновения каждого риска в ходе выполнения всего проекта и мероприятия по его разрешению, включить мероприятия по разрешению рисков в соответствующие разделы годового проектного плана. В первую очередь и особо тщательно необходимо планировать мероприятия по разрешению рисков с большими весами (наиболее опасные риски).

В ходе выполнения проекта необходимо выполнять анализ рисков (риск-анализ) на регулярной основе, то есть необходимо планировать периодический риск-анализ. По результатам периодического риск-анализа каждый раз важно определять новые веса каждого риска, поскольку они могут изменяться, заново упорядочивать риски по убыванию их весов и тщательно перепланировать управление наиболее опасными рисками.

Уточнение проектного плана в ритме выполнения проекта

Опыт работы АОЗТ ИДУ показывает, что создание четырехуровневой совокупности описаний проектного плана в начале работы над проектом является сложной задачей для некоторых руководителей проекта. Кроме того, часто возникает необходимость в быстром перепланировании работ по проекту. Это случается, когда проявляется запланированный риск или во время проведения проекта поступают указания от заказчика на необходимость изменений в нем.

Для таких случаев в АОЗТ ИДУ разработан специальный метод планирования, который был назван методом уточнения проектного плана в ритме выполнения проекта. Этот метод заключается в следующем.

Сначала разрабатывается новый годовой план с использованием возможностей системы PLA, а для случая перепланирования осуществляется перепланирование оставшейся невыполненной части ранее разработанного годового плана.

Далее годовой план разукрупняется в полный план только для одного квартала (первого – для нового плана, текущего – при перепланировании (см. рис. 1)). Только после этого можно приступить к разработке месячных планов. При этом в первую очередь создается полный месячный план только для первого месяца первого квартала для нового проекта или план на текущий месяц в случае перепланирования.

После завершения разработки месячного плана создаются полные недельные планы для первых двух недель подготовленного месячного плана. По окончании такой разработки проектного плана (по принципу сверху вниз) он становится подробным только для первых двух недель и пригодным для управления проектом только на их протяжении.

Для того чтобы была возможность эффективного управления проектом в течение всего времени его выполнения, необходимо:

*         в конце каждой текущей недели осуществлять уточнение ранее составленного плана на следующую неделю и разрабатывать подробный план на последующую неделю (см. рис. 1) и так поступать до последней недели текущего месяца;

*         в конце каждого месяца текущего квартала (для которого уже создан квартальный план), но не позднее чем в начале последней недели месяца, разрабатывать подробный план для следующего месяца (вернуться наверх);

*         по окончании разработки очередного месячного плана продолжить последующее недельное планирование (вернуться вниз);

*         в конце каждого текущего квартала разрабатывать план для следующего квартала (вернуться наверх);

*         далее разрабатывать план первого месяца, первой недели следующего квартала и так поступать до последнего квартала, последнего месяца и последней недели годового проектного плана.

Таким образом, периодически возвращаясь при планировании наверх и выполняя декомпозицию годового плана сверху вниз, постепенно, в ритме выполнения проекта будут создаваться подробные квартальные, месячные и недельные планы (на текущую неделю и неделю вперед), которые следует использовать в повседневном управлении проектом.

Список литературы

1. Brooks F.P.Jr. The Mythical Man-Month. - S.L.: Addison-Wesley, 1975. Брукс Ф.П.мл. Как проектируются и создаются программные комплексы. /Пер. с англ. - М.: Наука, 1979. – 152 с. - (Библиотечка программиста).

2. Гантер Р. Методы управления проектированием программного обеспечения: /Пер. с англ. - М.: Мир. – 1981. - 392 с.

3. Grady R.B. Practical Software Metrics for Project Management and Process Improvement. - Englewood Cliffs: Prentice Hall, 1992. - 270 p.

4. Humphrey G. Managing the Software Process - Reading: Addison-Wesley, 1989. - 494 p.

5. Paulk M.C., Curtis B., Chrissis M.B., Weber Ch.V. Capability Maturity Model for Software, Version 1.1. CMU/SEI-93-TR-24; ESC-TR-93-177. Key Practices of the Capability Maturity Model, Version 1.1. CMU/SEI-93-TR-25; ESC-TR-93-178. - Pittsburgh: Software Engineering Institute, 1993. - 533 p.

6. Baranoff S., Domaratsky A., Lastochkin N., Morozov V.. An automated system for software project planning. International Conference on Informatics and Control (ICI&C'97 June 9-13, 1997 St.Petersburg). Proceedings. Volume 2 of 3. St.Petersburg. SPIIRAS, 1997 - P.785-795 (1353c.).

7. Баранов С.Н., Домарацкий А.Н., Ласточкин Н.К., Морозов В.П. Сбор и анализ метрик при выполнении проектов программных изделий. //Программные продукты и системы. - 1998. - № 4. - С.24-29.

8. Баранов С.Н., Домарацкий А.Н., Ласточкин Н.К., Морозов В.П. Практическая модель процесса разработки программных изделий. // Там же. - С.7-14.

9. Домарацкий А.Н., Морозов В.П. Паспорт стандартного процесса. // Там же. - С.14-18.

10. Домарацкий А.Н. Управление улучшением стандартного процесса и качеством программных изделий. // Там же. - С.20-24.

11. Баранов С.Н., Домарацкий А.Н., Ласточкин Н.К., Морозов В.П. Автоматизация процесса управления проектом ПИ. // Там же. - С.46-48.

12. Баранов С.Н., Домарацкий А.Н., Ласточкин Н.К., Морозов В.П. Предотвращение дефектов при разработке ПИ.// Программные продукты и системы. – 1998. - № 2. - С.2-6.