CC BY
187
Сравнительный анализ методологий разработки программного обеспечения Геркушенко Г. Г.1, Ткаченко А. В.2
1Геркушенко Георгий Геннадьевич / Gerkushenko Оеог%у Оеппа^еу1ек - кандидат технических
наук, доцент,
2Ткаченко Александр Владимирович / Тка^епко А1ек$ап& У1аШш1гоу(Л - студент
магистратуры,
кафедра системы автоматизированного проектирования и поискового конструирования, факультет электроники и вычислительной техники, Волгоградский государственный технический университет, г. Волгоград
Аннотация: процессы управления проектами могут быть стандартизированы, используя определенные хорошо проверенные и предопределенные модели для проектирования, планирования и реализации проекта. Эти модели называются методологии управления проектами. Некоторые методологии могут быть использованы для всех типов проектов, т. е. во всех сферах бизнеса. Другие подходят только для конкретных типов проектов. Например, одна методология может быть использована для проекта дорожного строительства, а другая методология была бы более подходящей для проекта разработки программного обеспечения. Ключевые слова: методология, проект, управление проектами.
Введение
В основе проектной деятельности лежат стандарты по управлению проектами. Данные стандарты являются сборником лучших практик в области управления проектами, формируют основу взаимодействия между собой проектных команд, создают базу для сертификации специалистов в области управления проектами, помогают объединить знания в конкретной области воедино. Так же, стандарты управления проектами, зачастую, не содержат ясных инструкций, что необходимо сделать для выполнения определенных задач. Стандарты определяют, что должно быть сделано, чтобы эффективно управлять проектом, и как это должно быть сделано, определяется в корпоративных документах, разработанных на основе этих стандартов.
Как правило, стандарт определяет основные понятия предметной области, описывает участников управления проектами, необходимые области знаний и исполняемые процессов.
Результаты исследования
Перечислим несколько основных методологий разработки проектов для понимания специфики работы автоматизированных систем управления проектами.
Название Автор Предметная область
Методология PMI Международный некоммерческий институт управления проектами Не привязана к предметной области
Методология IPMA Международная ассоциация управления проектами Не привязана к предметной области
Методология PRINCE2 Центральное компьютерное и телекоммуникационное агентство Великобритании В настоящий момент не привязана к предметной области (исходно ориентирована на ИТ-проекты)
Методология MSF Корпорация Майкрософт Ориентирована на разработку ПО
Методология RUP Корпорация Rational Software Ориентирована на разработку ПО
Группа методологий Agile Альянс agile (глобальная некоммерческая организация) Ориентированы на разработку ПО
Набор моделей CMMI Университет Карнеги-Мелона Ориентированы на разработку ПО
Методология ASAP Корпорация SAP AG Ориентированы на разработку ПО
Разберем более подробно некоторые из них.
1. Методология PMI, сформулированная в виде стандарта PMBoK [3], базируется на концепции управления проектами через группу стандартных процессов. Однако последняя версия стандарта PMBoK отражает существенную коррекцию методологии в сторону интерактивных методик.
Свод знаний по управлению проектами PMBoK (Project Management Body of Knowledge) представляет собой сумму профессиональных знаний по управлению проектами. Руководство PMBOK фиксирует части Свода знаний по управлению проектами, который обычно считается хорошей практикой.
В рамках данного стандарта управление проектами рассматривается сквозь призму 5 ключевых групп процессов и 9 областей знаний.
• Группы процессов согласно PMBOK:
• Группа процессов инициации. Процессы, которые выполняются для определения нового проекта или новой фазы существующего проекта путем получения разрешения для начала проекта или фазы.
• Группа процессов планирования. Процессы, требуемые для определения общего содержания проекта, уточнения целей и определения последовательности действий, требуемых для достижения целей проекта.
• Группа процессов исполнения. Процессы, применяемые для выполнения работ, определенных в плане управления проектом, для удовлетворения спецификаций проекта.
• Группа процессов мониторинга и управления. Процессы, требуемые для отслеживания, анализа и регулирования хода и эффективности исполнения проекта, выявления тех областей, в которых требуется внесение изменений в план, и инициации соответствующих изменений.
• Группа процессов завершения. Процессы, выполняемые для завершения всех действий в рамках всех групп процессов и формального завершения проекта или фазы.
Области знаний PMBOK:
• Управление интеграцией;
• Управление содержанием;
• Управление временем;
• Управление стоимостью;
• Управление качеством;
• Управление ресурсами;
• Управление коммуникациями;
• Управление рисками;
• Управление закупками;
2. PRojects IN Controlled Environments 2 (PRINCE2) [1] представляет собой структурированный метод управления проектами, одобренный правительством Великобритании в качестве стандарта управления проектами в социальной сфере. Методология PRINCE2 включает в себя подходы к менеджменту, контролю и организации проектов.
Методология описывается «сверху — вниз». От абстрактных уровней, к конкретному их наполнению.
Состоит из трех важных компонентов (Планирование, управление изменениями и управление качеством).
Весь процесс состоит из стадий, подстадий и связей.
При этом важно заметить, что описание стадий и подстадий не являются чистыми критериями. Они отвечают не на вопрос чего надо добиться, а на вопрос как этого добиться. Просто делают это, не вдаваясь в конкретные детали. Например, утверждается, что должен быть написан план и выявлен критический путь, но не указывается, как именно план составлять (это описано уже в технике).
3. Microsoft Solutions Framework (MSF) [2] — методология разработки программного обеспечения, опирается на практический опыт Microsoft и описывает управление людьми и рабочими процессами в процессе разработки решения.
Модель процессов MSF представляет собой общую методологию разработки и внедрения IT-решений. Благодаря своей гибкости данная модель может использоваться для разработки широкого круга IT-решений, она охватывает весь жизненный цикл создания решения, с самых ранних этапов до внедрения. Модель процессов MSF сочетает в себе качества двух классических моделей: каскадной и спиральной.
Процесс MSF ориентирован на "вехи" (milestones). Вехи - ключевые точки процесса разработки, которые характеризуют достижение какого-либо существенного результата.
Модель процессов MSF учитывает постоянные изменения требований к конечному продукту, процесс разработки состоит из коротких циклов и представляет собой поступательное движение от простейших ранних версий продукта к его окончательному виду.
Модель процессов описывает последовательность действий при реализации проекта, по сути, модель процессов определяет жизненный цикл проекта.
В настоящее время существует множество различных моделей. Рассмотрим подробнее каскадную и спиральную модели, положения которых легли в основу модели процессов MSF.
Каскадная модель
Каждый этап разработки заканчивается точкой оценки и перехода к следующему этапу. Каждый следующий этап может начаться только после завершения предыдущего. Фиксированные точки перехода между этапами облегчают распределение ответственности, создание отчетности и следование календарному графику.
Модель выделяет семь последовательных этапов проектного управления:
Определение требований
Проектирование
Реализация
~Г
Внедрение
Тестирование и отладка
Установка
Эксплуатация и сопровождение
Рис. i. Каскадная модель (waterfall)
Применяется в небольших проектах, в которых строго установлены требования, бюджет и сроки. Основными недостатками данной модели является невозможность возврата на предыдущий этап разработки, а также сложностью внесения изменений в работу.
Рис. 2. Спиральная модель
Данная модель предпочтительна для быстрой разработки небольших решений. В ней учитываются постоянные изменения и пересмотр проектных требований к конечному продукту. Имеет место постоянное и тесное взаимодействие разработчиков с заказчиком, который оценивает ход и результаты работы на протяжении всего процесса работы над проектом. К недостаткам спиральной модели можно отнести низкую степень формализации, порой тяжело понять на какой конкретной стадии (планирование, разработка т пр.) находится проект.
Модель процессов MSF объединяет в себе упорядоченность каскадной модели с гибкостью спиральной.
Базовые принципы:
Единое видение проекта. Изначально и у заказчика и у проектной группы имеется свое понимание целей и задач проекта, а также того, что должно быть достигнуто в ходе работы над проектом. Успех проекта невозможен без наличия единого видения и понимания проекта у заказчика и проектной группы, поскольку отсутствие ясности делает невозможным цели.
Поскольку выработка единого видения проекта и следование ему настолько важны, MSF выделяет для этих целей отдельную фазу (этап) разработки - «Выработка концепции».
Проявляйте гибкость - будьте готовы к переменам. В противоположность каскадной модели MSF основывается на принципе непрерывной изменяемости условий проекта при неизменной эффективности управления.
Концентрируйтесь на бизнес - приоритетах. Разрабатываемый продукт должен приносить определенную выгоду или отдачу конечным пользователям. В случае организаций - бизнес-отдачу.
Поскольку программный продукт способен привнести отдачу только после своего внедрения в среду организации, MSF включает в жизненный цикл создания решения фазу внедрения.
Поощряйте свободное общение. Исторически многие организации строили свою работу по принципу need-to-know, то есть сведения к минимуму информированности сотрудников.
Модель процессов MSF предлагает свободный и открытый обмен информацией между всеми участниками проекта, как внутри команды разработчиков, так и с ключевыми заинтересованными лицами. Это должно служить средством снижения недопонимания, неопределенности и необоснованных затрат.
Поэтому, MSF предлагает проводить анализ хода работ в определенных временных точках. Обязательное документирование результатов иллюстрирует прогресс работы над проектом, как для разработчиков, так и для заказчика.
4. ASAP являет собой внедрение и методологию жизненного цикла, которая оптимизирует сроки, качество и эффективность использования ресурсов. ASAP используется для оптимизации времени, качества и эффективного использования ресурсов в ходе осуществление проектов. Выводы
Не бывает лучшей методологии - выбор зависит от типа проекта и конкретных обстоятельств.
При работе над проектом, в котором изначально сформированный проект не подлежит никаким изменениям, например, популярно в строительной деятельности, стоит выбрать способ водопад.
При разработке программного обеспечения, графического дизайна и прочих сервис-ориентированных проектов, лучше воспользоваться гибким управлением проектами.
Для минимизации рисков большого проекта лучше использовать PRINCE2. Данная методология определяет организацию, управление и контроль над исполнением проектов.
Не стоит бояться использовать менее популярные методологии, если они подходят для Вашего проекта лучше всего.
Литература
1. Методология PRINCE 2. [Электронный ресурс]: URL: http://www.12manage.com/m ethods_ccta_prince2_ru.html (дата обращения: 17.02.2016).
2. Обзор Microsoft Solutions Framework (MSF) [Электронный ресурс]: Microsoft Developer Network. URL: msdn.microsoft.com/ru-ru/library/jj161047.aspx (дата обращения: 17.02.2016).
3. Свод знаний по управлению проектами (Руководство PMBOK®). Американский национальный стандарт / Пятый выпуск. - Институт управления проектами, Inc. 2013 - 614 стр.
