CC BY
68
ИССЛЕДОВАНИЕ ПРОЦЕССОВ РАЗРАБОТКИ ПРОГРАММНЫХ СИСТЕМ С ИСПОЛЬЗОВАНИЕМ MS PROJECT
А.А. Зарафьянц
В работе сформулированы рекомендации по применению MS Project для сбора метрик и графического исследования процессов в целях автоматизации управления разработкой программного обеспечения (ПО).
Введение
Целью проектов разработки программного обеспечения, в том числе и программного обеспечения САПР, является: в заданный срок, с заданными бюджетом и ресурсами разработать программную систему, удовлетворяющую определенным спецификациям (требованиям заказчика).
Управление проектом разработки ПО
Один из наиболее распространенных подходов к стандартизации управления проектом - подход Project Management Institute (PMI) [1]. Данный подход описывает задачи, которые необходимо выполнить для успешного выполнения проекта в любой сфере, в том числе и в сфере разработки программного обеспечения. Подход PMI нацелен на качественное выполнение проекта с заданными ограничениями ресурсов в срок. Он не исключает, а наоборот, дополняет специфические требования к проектам разработки ПО, описанные в [2].
Одной из важнейших задач управления проектом является задача контроля качества. Современные системы контроля качества строятся на основе сбора различных метрик (числовых и графических характеристик) процессов [3]. Качество ПО должно обеспечивать возможность решения сформулированных в спецификациях задач, качество необходимо для обеспечения конкурентоспособности.
Спецификации и план
Наиболее распространенное средство управления проектами MS Project в целом отражает подход [1] и обеспечивает возможность графической репрезентации некоторых метрик проекта.
Вкратце остановимся на терминологии, за детальным описанием программы необходимо обращаться к специальной литературе, такой как [4] и документация MS Project.
Проектный план обычно задается в виде таблицы задач и диаграммы Ганта. Проект состоит из задач, связанных между собой в некоторые последовательности. Тип связи по умолчанию - FS (finish-to-start).
Существует важная возможность сохранить базовый план проекта и далее отслеживать корректировки этого плана. Также MS Project позволяет задавать процент выполнения задач и наглядно представляет стадии выполнения работ по проекту.
Исследование процессов MS Project
Использование MS Project наиболее оправдано для проектов, где необходимо жесткое отслеживание исполнения графика работ и (или) отслеживание исполнения бюджета.
Анализ критического пути. В водопадной модели жизненного цикла ПО [5] по результатам этапа анализа спецификаций составляется структура разбиения работ (на этапе дизайна системы). После разбиения проекта на подзадачи необходимо установить связи между ними и оценить время их выполнения. Время выполнения обычно оценивается по формуле:
Estimate = (Pessimistic + 4* Likely + Optimistic) / 6.
Для получения средней оценки берется пессимистическая, оптимистическая и учетверенная наиболее вероятная оценка. Сумма делится на шесть.
После оценки времени выполнения задач появляется возможность проводить оценку снизу вверх (bottom-up) сроков выполнения проекта и выполнять корректировки плана для его сокращения. Критический путь - наиболее длинный путь по последовательно связанным задачам от начала проекта к его завершению. Очевидно, что проект не может быть короче, чем его критический путь. MS Project автоматически выделяет критический путь на диаграмме Ганта или сетевой диаграмме. Работа по сокращению сроков проекта сводится к переоценке и перегруппировке задач критического пути.
Вариация плана. Проектный план редко бывает идеальным. Он постоянно корректируется как до, так и после начала выполнения его этапов. Для обеспечения возможности визуального исследования отклонения плана необходимо сохранять базовые планы проекта.
Анализ достижения вех (Milestones). При разработке ПО мы создаем план, ориентированный на deliverables - промежуточные результаты. Проект необходимо разбивать на этапы, разделенные вехами (milestones), к которым и приурочены эти промежуточные результаты (deliverable).
Визуализация хода выполнения плана, линии продвижения работ. По мере выполнения проектного плана необходимо вводить процент выполнения каждой из задач. Линии продвижения работ позволяют исследовать визуальное отображение состояния проекта на определенную дату.
Автоматизация контроля за назначением ресурсов.Для распределения задач по разработчикам необходимо вести учет ресурсов, корректно назначать их на задачи. Присвоение стоимости ресурсам позволяет строить бюджетные индикаторы проекта.
Анализ бюджетных характеристик._Объемы затрат на реализацию задач автоматически оцениваются MS Project. Их можно вычислять как для проектов внутри организации, так и учитывать альтернативные затраты на аутсорсинг, консалтинг и покупку компонентов.
Пример применения MS Project
Исследование вариации диаграммы Ганта для выполненного проекта разработки программной системы - на примере базы данных учета комплектующих в производстве - проведем на основе рис. 1. С помощью этого реального примера проиллюстрируем основные приемы использования MS Project для автоматизации разработки ПО.
Как видно из рис. 1, проект начался 1 июня, и первоначальный план предполагал завершение и внедрение первой его версии к 1 сентября. В ходе разработки выяснилось, что первоначальная оценка трудоемкости не была точной (для задачи номер №4 потребовалось 4 вместо одного дня). На рисунке показана линия хода работ на 20 июля, за месяц до поставки готовой версии системы. К этому моменту выяснилось, что требуется выполнение дополнительных задач (с номерами 10 и 11), что ставит под угрозу реализацию проекта 20 августа (задача-веха номер 13). В реальности для выполнения задачи №4 в срок были привлечены дополнительные ресурсы (разработчик) к выполнению параллельной задачи №12 (реализации печатных форм). Это замедлило выполнение задач основным разработчиком, но позволило уложиться в срок.
Рис.1. Отслеживание хода выполнения плана работ на примере реализации системы
учета комплектующих
Данный пример иллюстрирует графическое исследование продвижения проекта на пути к достижению важных промежуточных результатов, совмещенных с вехами (milestones). Пример также иллюстрирует использование линий продвижения работ и процента выполнения задач для визуальной оценки состояния процесса разработки.
Ограничения применимости и рекомендации
Жизненный цикл. Общая концепция априорного построения плана в виде диаграммы Ганта наиболее подходит для программного обеспечения, разрабатываемого по водопадной модели жизненного цикла, аналогичной моделям, применяемым при строительстве или ремонте. Различные варианты жизненного цикла программного обеспечения представлены в работе [5].
Обычно разработка ПО - это изобретение по требованию, где нет четкого представления о сроках, последовательности и трудоемкости задач. Жизненный цикл систем далеко не всегда свободно проецируется на водопадную модель, такой план зачастую будет постоянно перекраиваться, и дополнительные расходы ресурсов на его поддержание в актуальном состоянии перевесят выгоду от использования MS Project. Поэтому на ранних этапах разработки необходимо оценить выбранный жизненный цикл
ПО, и в некоторых случаях вовремя отказаться от использования MS Project. При этом MS Project все еще можно использовать в более крупных масштабах, например, когда в качестве задач ставится реализация подпроектов. Таким образом, существует баланс детальности плана: оптимальная детальность декомпозиции задач определяет, будут ли оправданы накладные расходы на поддержание плана в MS Project в актуальном состоянии. В таком случае для детального отслеживания выполнения задач приоритетным становится использование трекинговых систем и других систем автоматизации, описанных в [6], а также систем сбора метрик, описанных в [3].
Нелинейность зависимости длительности задачи от количества ресурсов. При использовании MS Project разработчики перечисляются в таблице ресурсов и назначаются для выполнения задач в соответствии с типом этих задач. Задачи бывают FD (fixed duration), FU (fixed units) и FW - (fixed work). Задачи могут иметь установленный флажок Effort Driven.
Рассмотрим, например, изменение сроков выполнения задач с фиксированной трудоемкостью (FW) с установленным флажком Effort Driven. Настройки MS Project по умолчанию обеспечивают линейную зависимость между трудоемкостью и длительностью задач, что приводит к классической ошибке менеджеров программных проектов, описанной еще Бруксом в «Мифическом человеко-месяце» [7]: увеличение числа разработчиков, занятых в реализации некоторой задачи, зачастую лишь замедлит ход ее выполнения! Менеджерам необходимо очень аккуратно работать в поисках уменьшения длительности критического пути. Рекомендуем использовать сетевые диаграммы (network diagrams), в которых представление плана сфокусировано на зависимостях между задачами, вместо их продолжительности.
Использование систем автоматизации разработки. Для решения задач разработки ПО наряду с MS Project, используются следующие системы автоматизации процессов: системы учета изменений и дефектов (Tracking systems), системы совместного использования исходных кодов (Version control systems), специализированные системы поддержки процессов разработки, такие как RUP (Rational Rose) и специализированные инструменты и средства разработки и моделирования (Bpwin, Erwin, другие CASE средства).
Все эти средства, как и MS Project, позволяют автоматизировать сбор различных метрик процессов проекта.
Заключение
При применении приведенных рекомендаций, учитывая особенности жизненного цикла программного обеспечения, MS Project может эффективно использоваться для задач анализа критического пути, вариации плана, исследования хода работ с помощью вех (milestones) и графиков выполнения задач, автоматизации водопадной модели жизненного цикла. Рекомендуется использовать MS Project для управления набором под-проектов, построения графиков и таблиц загрузки ресурсов, бюджетных индикаторов.
Литература
1. A guide to the project management body of knowledge (Pmbook guide). Project management Institute Inc, 2000.
2. IEEE Standard for Developing Software Life Cycle Processes, IEEE Computer Society, New York, NY, 1995.
3. Software Measurement Process standard for Software Engineering (ISO/IEC 15939, 2002).
4. Гультяев. MS Project 2003 Professional. Управление проектами. М.: КОРОНА, 2004.
5. Зарафьянц А.А. Документирование жизненного цикла информационных систем. // Сборник трудов XXXIII научной и учебно-методической конференции СПбГУ ИТМО, 2004.
6. Технологии автоматизации управления жизненным циклом компьютерных программ. / Труды международных научно-технических конференций «Интеллектуальные системы (IEEE AIS'04) и «Интеллектуальные САПР» (CAD-2004) Научное издание в 3-х томах. М.: ИФМЛ, 2004. Т. 2. 468 c.
7. P. Brooks. The mythical man-month. Adisson- Wessley Longman Inc, 1995.
