Программная инженерия. Теория и практика

Совершенствование процесса (software process improvement). Это деятельность по изменению существующего процесса (как текущего, в рамках одного проекта, так и стандартного, для всей компании) с целью улучшения качества создаваемых продуктов и/или снижения цены и времени их разработки. Причины актуальности этой деятельности для компаний-производителей ПО заключаются в следующем: происходит быстрая смена технологий разработки ПО, требуются изучение и внедрение новых средcтв разработки; наблюдаются быстрый рост компаний и их выход на новые рынки, что требует новой организации работ; имеет место высокая конкуренция, которая требует поиска более эффективных, более экономичных способов разработки.

Перечислим, что и каким образом можно улучшать:

1. Переход на новые средства разработки, языки программирования и т.д.

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

3. Полная, комплексная перестройка всех процессов в проекте, департаменте, компании (в соответствии, например, с CMMI).

4. Сертификация компании (CMM/CMMI, ISO 9000 и пр.).

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

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

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

Pull/Push-стратегии. В контексте внедрения инноваций в производственные процессы бизнес-компаний (не обязательно компаний по созданию ПО) существуют две парадигмы:

• organization pull – внедрение инноваций, нацеленных на решение конкретных проблем компании;

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

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

Пример использования стратегии technology push – переход компании со средств структурной разработки на объектно-ориентированные. Еще один пример использования той же стратегии – внедрение стандартов качества ISO 9000 или CMMI. В обоих случая компания не решает какую-то одну проблему или ряд проблем, она хочет радикально изменить ситуацию, выйти на новые рубежи и т.д.

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

Использование стратегии organization pull менее рискованно, вносимые ею изменения в процесс менее глобальны, более локальны, но и выгод такие инновации приносят меньше, по сравнению с удачными внедрениями в соответствии со стратегией technology push.

Необходимо также отметить, что существуют проблемы, которые невозможно устранить точечными переделками процесса, т.е. следует применять стратегию technology push. Приведем в качестве примера зашедший в тупик процесс сопровождения и развития семейства программных продуктов: компания терпит большие убытки, сопровождая уже поставленные продукты, инструментальные средства проекта безнадежно устарели и находятся в плачевном состоянии, менеджмент расстроен, все попытки руководства изменить процесс наталкиваются на непонимание коллектива, ссоры и конфликты. Возможно, что в таком случае без «революции» не обойтись.

Еще одно различие обеих стратегий заключается в том, что при использовании organization pull, как правило, возврат инвестиций от внедрения происходит быстрее, чем при technology push.

2.2. Классические модели процесса

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

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

Фазы и виды деятельности. Говоря о моделях процессов, необходимо различать фазы и виды деятельности.

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

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

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

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

Виды деятельности фактически присутствуют под разными названиями в каждом методе разработки ПО. В RUP они называются рабочими процессами (work flow), в CMM – ключевыми областями процесса (key process area). Мы будем сохранять традиционные названия, принятые в том или ином методе, чтобы не создавать путаницы.

Водопадная модель. Была предложена в 1970 г. Винстоном Ройсом. Фактически впервые в процессе разработки ПО были выделены различные шаги разработки и поколеблены примитивные представления о создании ПО в виде анализа системы и ее кодирования.

Были определены следующие шаги: разработка системных требований, разработка требований к ПО, анализ, проектирование, кодирование, тестирование, использование (рис. 2).

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

Рис. 2. Водопадная модель процесса разработки ПО

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

В 70–80-е гг. прошлого века эта модель прочно укоренилась в разработке ПО в силу своей простоты и сходности с моделями разработки иных, не программных систем. В дальнейшем в связи с развитием программной инженерии и осознанием итеративного характера процесса разработки ПО эта модель активно критиковалась в соответствующих статьях и учебниках. Стало общепринятым мнение, что она не отражает особенностей разработки ПО. Недостатками водопадной модели являются:

• отождествление фаз и видов деятельности, что влечет потерю гибкости разработки, в частности трудности поддержки итеративного процесса разработки;

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

• интеграция всех результатов разработки происходит в конце процесса, вследствие чего интеграционные проблемы дают о себе знать слишком поздно;

• невозможность ознакомления пользователей и заказчика с вариантами системы во время разработки. Тем самым они не могут повлиять на процесс создания системы, и поэтому увеличиваются риски непонимания между разработчиками и пользователями/заказчиком;

• неустойчивость модели к сбоям в финансировании проекта или перераспределению денежных средств (начатая разработка фактически не имеет альтернатив «по ходу дела»).

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