Существующие методологии

В мире существует довольно много типовых процессов производства программного обеспечения. ISO9001, ISO12207, ISO15504, CMM (Capability Maturity Model), MSF (Microsoft Solution Framework), RUP (Rational Unified Process), SCRUM, XP (eXtremal Programming), Crystal Clear, ASD (Adaptive Software Development), Lean Development – все это разновидности процессов производства программного обеспечения, семейства процессов и методологии. Под методологией понимается набор методов, практик, метрик и правил, используемых в процессе производства ПО. Согласно Алистеру Кобурну [1], методология нужна для того, чтобы:

· Облегчить процедуру введения новых людей в курс процесса производства

· Обеспечить взаимозаменяемость людей

· Распределить ответственность

· Произвести впечатление на спонсора/заказчика

· Демонстрировать видимый прозрачный процесс

· Создать учебную базу для своих сотрудников

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

Согласно Алистеру Кобурну:

· Размер методологии – это количество элементов управления, включающих в себя промежуточные релизы, стандарты, виды деятельности, вехи, метрики качества и т.д.

· Плотность методологии – это уровень детальности и целостности, требуемый для элементов методологии.

· Вес проекта – это размер методологии, умноженный на ее плотность.

· Размер проекта – это количество людей, вовлеченных в реализацию проекта.

Первая категория методологий появилась на свет раньше всех и является неотъемлемой частью моделей качества программного обеспечения. Тяжелые методологии отличаются тем, что охватывают все аспекты деятельности компании, производящей программное обеспечение – от управления требованиями и планирования процесса до регламентирования взаимоотношений с субподрядчиками и описания требований к вспомогательным процессам. Все методологии данной категории нетерпимы к изменениям и рассматривают людей как обычный ресурс. Примеры: CMM, ISO9000, SPICE.

Вторая категория методологий появилась на свет в качестве некоторой совокупности методов и практик, применявшихся небольшими командами разработчиков в успешных проектах. Здесь огромное значение уделяется взаимоотношениями между людьми внутри команды, учитываются вопросы терпимости и другие психологические аспекты. Все процессы данной категории предусматривают итерационный жизненный цикл разработки ПО. Если попытаться сформулировать основной смысл легких методологий, то получится следующее: «Обеспечение максимальной скорости и качества разработки ПО при минимуме ограничений и условностей». В частности, во всех легких методологиях предусмотрен лишь необходимый минимум документов, т.к. отдается должное принципу «Документация – это не есть понимание». Существенным отличием данных методологий от методологий первого типа является отношение к планированию.

В третью категория методологий попадают так называемые «универсальные» процессы. Самым ярким и известным представителем данной категории является RUP. Основной характеристикой подобных процессов является масштабируемость – т.е. процесс может быть настроен как на работу в малой команде над небольшим проектом, так и в большой команде над большим и серьезным проектом.

Алистер Кобурн, автор Crystal, является одним из наиболее известных современных специалистов, сделавших объектом своих исследований методологии. Результатом его исследований в данной области является книга «Agile Software Development»[1], в которой автор анализирует процесс производства ПО с различных точек зрения. Алистер Кобурн является автором концепции «Разработка программного обеспечения – это совместная игра изобретения и взаимодействия». Он выделяет 2 цели:

· Первая цель: разработать и внедрить работающее программное обеспечение.

· Вторая цель: обеспечить все условия для успешного протекания следующей игры.

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

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

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

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

Рисунок 3 отражает потолок возможностей команды при использовании методологий разного веса.

Кобурн разработал классификацию [1] типов проектов, основываясь на двух параметрах – размер проекта и его степень критичности. Различаются следующие степени критичности:

· Потеря комфорта (Loss of comfort). Потеря комфорта означает, что в случае ошибки в системе, жизнь людей немного осложнится, они должны буду делать больше ручной работы, или звонить друг другу, чтобы восполнить прерванный канал связи. Программы поддержки корпоративной инфраструктуры обычно лежат в этой области.

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

· Невосполнимая потеря денег (Irreplaceable money, essential money). Означает потерю денег или их эквивалента в объемах, сравнимых с банкротством предприятия. Система управления национальным банком лежит в этой области.

· Потеря жизни (Loss of life). Означает, что в случае ошибки такой системы возникает опасность для жизни человека. Системы управления атомной станцией, космическим кораблем и самолетом лежат в данной области.

Какие типы методологий наиболее целесообразно использовать в том или ином случае.

Свой заказчик

Самый благоприятный тип проекта для внедрения легких методологий, поскольку заказчик всегда доступен и особых требований к качеству программного обеспечения не предъявляются. Однако, необходимо учитывать количество разработчиков и степень их распределенности. Необходимости в сертификации, как правило, у таких команд не бывает, поэтому, по большому счету, обращать внимание на CMM и другие тяжелые методики в качестве основных, не стоит.

Продукт под заказ

Самый уязвимый тип проекта. Фирма целиком зависит от количества заключенных договоров. Постоянно производится поиск новых заказчиков. В таких условиях, конечно же, наличие сертификата ISO или CMM является очень желательным, особенно если речь идет о западных заказчиках. Однако, внедрение ISO9001, SPICE или CMM является достаточно трудоемким процессом, который не всегда себя оправдывает. Поэтому, видимо, целесообразно начать внедрение RUP, с прицелом на дальнейшую сертификацию.

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

Тиражируемый продукт

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

Аутсорсинг

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

Дата добавления: 2015-07-25