В статье предлагается новый подход для решения задачи выбора проектной методологии разработки программного обеспечения (ПО). В основе предлагаемого подхода лежит идентификация принципов, заложенных в основу методологий и их верификация в зависимости от специфических условий проект и, особенностей компании-разработчика.
Проектный характер деятельности, технологическая гибкость процесса разработки, неопределенность требований в отношении ожидаемого результата и существенно более высокие риски отличают разработку программного обеспечения. Технология создания ПО предоставляет значительную степень свободы в выборе различных вариантов организации процессов. Проектный характер разработки ПО и высокий уровень рисков обусловили развитие специализированных проектных методологий, призванных обеспечить качество ПО, повысить производительность труда разработчиков и снизить проектные риски за счет повторяемости процессов, использования количественных методов оценок и наличия процедур контроля и оптимизации.
Разнообразие организации процессов разработки в компаний, технологические особенности проектов предполагает использование различных подходов к организации работы, и, следовательно, различных проектных и процессных методологий. В связи с этим возникает проблема выбора проектных методологий.
Для решения задачи эффективного выбора существующих методологий управления проектами разработки программного обеспечения необходимо выполнить их классификацию, провести сравнительный анализ, определить, какие задачи они решают, какова их область применения. Предлагаемая нами классификация методологий, моделей и стандартов, представлена в [1].
Принцип (от лат. principium основа, начало) – это основное, исходное положение какой-либо теории, учения и т.п.; руководящая идея, основное правило деятельности. Принципы являются концентрированным обобщением разностороннего опыта и подходов на уровне структуры деятельности (framework). Их содержание и смысл: в краткой форме дать практическое руководство для конкретных действий по проекту и/или быть основой для разработки стандартов или алгоритмов работы.
Принципы представляют собой предположения, как правило, неявно выраженные, относительно которых не существует единогласного мнения в индустрии. Наилучший результат даст использование методологии, основанной на принципы, адекватных для компании и проекта. Следовательно, необходимо не только определить, какие принципы лежат в основе применяемой методологии, каким образом эти принципы реализованы в компонентах методологии, но и постоянно верифицировать адекватность этих принципов для компании в текущий момент. Непрерывная проверка адекватности принципов определяет развитие методов управления. Многие укоренившиеся принципы, лежащие в основе разработки ПО, меняются благодаря новыми технологиями, заменяются более совершенными методами или более высоким уровнем автоматизации. [2, стр. 3].
Под принципами будем понимать предположения относительно фундаментальных законов разработки ПО. Современные принципы касаются процессов разработки, использования инструментальных средств, организации команды проекта и т.д.
Необходимость явной формулировки принципов содержится в Модели зрелости процессов разработки ПО (Capability Maturity Model, CMMI) [3]. Цель GP 2.1 “Установление организационной политики” (Establish an Organizational Goal) предусматривает определение целей организации, ожиданий и руководящих принципов.
Сторонники методологии Agile Software Development сформулировали 12 принципов, которым они обязуются следовать [3]. В этом случае принципы носят характер декларации о том, каким образом будет вестись работа над проектом. По мнению сторонников манифеста именно такие подходы к проектам обеспечивают успех, но авторы не проводили специальных исследований, опираются, в основном, на свой собственный опыт и опыт коллег.
А. Дэвис сформулировал 15 принципов программной инженерии в статье «Fifteen principles of software engineering», а затем расширил количество принципов до 201 в своей известной работе «201 Принципы программной инженерии» [5, 6].
В основу каждой методологии заложен набор принципов, который определяет рекомендуемую модель процессов, методы минимизации рисков, роли участников проекта и т.д. Для выбора адекватной методологии с использованием метода верификации принципов необходимо: определить набор принципов, который наилучшим образом отражает существующие цели проекта и компании, зависимости между ресурсами, методами управления и результатами, и выбрать методологию, которая наиболее соответствует этим принципам.
Набор принципов меняется со временем из-за развития технологий разработки, повышения квалификации сотрудников компании и клиентов, изменения традиций. Процедура верификации принципов должна проводиться при выборе методологии управления новым проектом, а также в контрольных точках проекта (особенно в случае существенных отклонений от плана).
В Табл. 1. представлены результаты анализа наиболее существенных на момент проведения исследования принципов разработки ПО. Для каждого принципа приведены наиболее типичные модели и стандарты, в которых он содержится в том или ином виде, определены ограничения области действия принципа, а также модели и стандарты, опирающиеся на противоположный подход.
| Принцип | Реализация | Необходимые условия | Противоположный подход |
| Приоритет архитектуры (упреждающая разработка архитектуры). | Во всех методологиях | Нет | Нет. Часто на практике имеет место приоритет требований. |
| Ориентация на выпуск в срок. | MSF | Должна существовать возможность поставки продукта с ограниченной функциональностью | TQM, управление качеством. Ориентация на выполнение всех требований |
| Основа успешного выполнения проекта – зрелые процессы разработки. | CMM, SPICE, ISO 9000 | Значительная техническая и управленческая сложность проекта | Управление «критическими» проектами |
| Определить проблему до того, как записывать требования. | Классическая водопадная модель. MSF. (Понимание бизнес-перспективы) | Требования должны быть понятны самому заказчику | XP, SCRUM.Определение требований по мере нахождения решения |
| Минимизация семантического разрыва между требованиями и реализацией. | Объектно-ориентированное проектирование и разработка | Структура ПО повторяет структуру предметной области – возможно для заказных бизнес-систем, но не для системного ПО или систем класса ERP | Структурное Программирование. Объектная разработка системного ПО, настройка систем класса workflow. |
| Устанавливать приоритеты требований. | MSF. Ориентация на выпуск в срок. | Требования должны отличаться по приоритетности, не все требования должны быть обязательными | Для систем с высоким уровнем рисков (рисков для жизни и существенных финансовых рисков) целесообразно |
| Разрабатывать приложение за несколько итераций. | MSF, RUP (разработка бизнес-приложений) | Наличие интегрированной среды, поддерживающей круговую разработку и соответствующей организационной структуры проекта. Соответствующие возможности, предусмотренные контрактом. | Водопадная модель (чаще всего: разработка ПО для оборудования, военных технологий, космоса). |
| Ранняя демонстрация и поставка продукта клиенту (связанные сценарии использования). | Прототипы (Rapid Application Development | Верно в том случае, если клиент обладает возможностью проверки ПО (например, бизнес-приложения). | Водопадная модель |
| Промежуточные версии должны поставляться клиенту как можно чаще. | Итерационная разработка (RUP, MSF) | Водопадная модель | |
| Изменения в требования не должны вноситься в проект на поздних этапах разработки. | Водопадная модель | Требования должны быть определены.Требования не должны меняться в ходе разработки | Agile Software Process |
| Необходимо вовлекать клиента в разработку продукта. | eXtreme Programming, RUP | Клиент должен обладать необходимыми людскими ресурсами | Водопадная модель |
| Разрабатывать, планируя повторное использование. | ООП, ООР | Достаточно временных и финансовых ресурсов – дополнительные затраты. | Модульное проектирование и разработка |
| Сразу полностью определять все требования. | Водопадная модель | eXtreme Programming, RUP | Фокусироваться на основных требованиях |
| Разработчики не должны тестировать собственный код. | Классический подход | Команда разработки должна состоять более чем из двух человека. | XP, PSP |
Использованием предлагаемого метода позволяет структурировать дискуссию в проектной команде, связанную с обсуждением вопроса выбора проектной методологии.
Литература
- Колтунова Е. В Классификация методологий, моделей и стандартов управления разработкой программным обеспечением для решения задачи их адекватного выбора. Математическое моделирование в экономике. Сборник научных трудов. с. 267-276 СПбГИЭУ, 2006 г – 320 с.
- Ройс У. Управление проектами по созданию программного обеспечения. Унифицированный подход. М.: Лори, 2002. – 434 с.
- Manifesto for Agile Software Development http://agilemanifesto.org/
- Capability Maturity Model® Integration (CMMI SM), Version 1.1 Continuous Representation CMU/SEI-2002-TR-011 ESC-TR-2002-011 CMMI Product Team Copyright 2002 by Carnegie Mellon University. 725 p
- Davis A. «Fifteen Principles of Software Engineering», — IEEE Software, Vol. 11, N.6, 1994, pp.94-101
- Davis A. 201 Principles of Software Developmen McGraw-Hill, 1995, 240 p.
0 комментариев