Управление изменениями: неужели между качеством и скоростью разработки программного обеспечения всегда должен быть компромисс?

Качество в противовес скорости разработки

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

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

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

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

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

Проблемы в управлении изменениями

Поскольку разработка приложений становится все более сложной, лица, отвечающие за разработку, должны делать больше с меньшими затратами. Это показал недавний опрос, проведенный компанией CA.

В Австралии в октябре 2002 года¹ компания CA провела опрос организаций в Австралии и Новой Зеландии с целью определения их потребностей и проблем в управлении изменениями. Шестьдесят семь человек из различных организаций и отраслей промышленности участвовали в опросе, посвященном проблемам, с которыми они сталкиваются в управлении изменениями, и методам их решения.

В результате опроса были четко выявлены некоторые проблемы, с которыми сталкиваются организации-разработчики ПО:

• 88% — развертывание приложений на нескольких платформах;
• 44% — развертывание приложений на более чем четырех платформах;
• 61% — ведение нескольких версий программного обеспечения;
• 52% — необходимость поддержки параллельной разработки;
• 46% — сопровождение нескольких жизненных циклов для различных видов разработки;
• 39% — внесение частых изменений в серийное программное обеспечение.

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

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

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

В исследовании "Хаос"², проведенном Standish Group, приводятся результаты проектов разработки приложений:

• среднее превышение времени разработки — 222%;
• среднее превышение затрат на разработку — 189%;
• отставание в удовлетворении требований пользователя на 27 месяцев.

В исследовании "Хаос" также сообщается, что лишь 25% проектов внедрены успешно, 28% проектов остановлены, и в 46% проектов возникли значительные проблемы с поставкой.

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

Роль управления изменениями

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

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

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

Учитывая это, неудивительно, что в центре внимания опрошенных находится управление изменениями. 40% респондентов внедрили методологию или аккредитацию, и 83% респондентов уже используют инструмент управления изменениями или рассматривают вопрос о его использовании. Это соотношение было выше в больших группах разработчиков.

Является ли управление изменениями проблемой только для крупных организаций-разработчиков?

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

Как показал опрос CA, мало вероятно, что небольшие группы разработчиков будут использовать инструменты или методологии управления изменениями. Однако также мало вероятно, что они определят свои процессы изменения как повторяемые; возможно, это указывает на то, что их методологии могут быть улучшены.

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

Исследование³ организаций, в которых оценивалась аккредитация модели зрелости процесса разработки ПО (Capability Maturity Model, CMM), показало, что приблизительно в половине из этих 586 организаций работает менее 100 разработчиков, и почти в четверти из них работает менее 50 разработчиков, таким образом аккредитация модели CMM и вообще уделение большого внимания методологии управления изменениями свойственны не только организациям с очень большими группами разработчиков (более подробно модель CMM обсуждается далее в этом документе).

Направляемое процессом управление изменениями

В опросе компании CA об управлении изменениями почти половина респондентов сообщила об использовании инструментов управления изменениями; однако они использовали различные инструменты, при этом многие респонденты использовали инструменты собственной разработки.

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

Многие респонденты использовали инструменты или методы управления изменениями, но не были удовлетворены своим управлением изменениями. Вероятно, у них были действительные причины для беспокойства (код поступает в производство без надлежащего тестирования/утверждения, и процессы изменения не являются повторяемыми). Значит ли это, что инструменты управления изменениями не работают? Вероятно, нет. Ответ на вопрос следует искать в видах инструментов, используемых респондентами.

Для разных людей управление изменениями и инструменты управления изменениями могут иметь различное значение. Фактически существует три уровня инструментов управления изменениями:

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

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

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

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

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

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

Методологии разработки

Существует ряд методологий и аккредитаций, которые предлагают архитектуру для обеспечения качества в жизненном цикле разработки приложения. Методологии, включая модель CMM и стандарт Международной организации по стандартизации ISO 9000, подчеркивают важность четко регламентированных процессов.

Аналогично стандарты управления сервисом, например, библиотека инфраструктуры информационных технологий (ITIL), требуют использовать управляемое процессом управление изменениями в рамках обеспечения лучших практических методов сервиса.

Модель зрелости процесса разработки ПО

Модель зрелости процесса разработки ПО (CMM)⁴, разработанная Институтом программной инженерии в университете Carnegie Mellon, предлагает пять уровней зрелости. Она помогает организациям повысить зрелость своих процессов разработки ПО, и организации могут быть оценены и аккредитованы в соответствии с этими уровнями.

В 1999 году исследование 734 организаций⁵, оцениваемых согласно модели CMM, показало, что большинство организаций находится на начальном уровне (43%) или уровне повторяемости (34%). Это подтверждает данные опроса компании CA об управлении изменениями, согласно которому процессы управления изменениями могут быть улучшены в большинстве организаций.

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

Повышение качества и скорости разработки

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

В этом разделе приводятся исследования, показавшие, что разработка не замедляется. Управляемое процессом управление изменениями фактически может привести к существенному повышению как качества, так и скорости разработки, что в конечном счете ускоряет и удешевляет разработку.

Качество разработки

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

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

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

Скорость разработки

Управляемое процессом управление изменениями позволяет повысить скорость разработки ПО двумя способами:

Во-первых, процессы изменения выполняются более эффективно, поэтому время проекта, затраченное на управление изменениями, сокращается.

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

Эффективность процесса изменения

Исследование, проведенное CA⁶, выявило ряд затрат на управление изменениями, где отсутствует эффективный подход к управляемому процессом управлению изменениями.

• В новом проекте разработок приблизительно 15% усилий ежедневно тратится на операции управления изменениями.
• В проектах поддержки эта цифра приближается к 25%.
• В новых проектах в распределенных средах на управление изменениями может тратиться 20% усилий.
• При поддержке распределенных приложений затраты на управление изменениями могут вырасти до 40%.

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

Инструменты управляемого процессом управления изменениями могут обеспечить не только эффективное выполнение (повышение качества) этих процессов изменения, но и снизить затраты на эти операции.

Исследование показало, что эффективное решение для управляемого процессом управления изменениями позволяет снизить затраты по проекту на 30 и более процентов.

В следующей таблице показано, как можно сократить долю затрат на операции управления изменениями в общих затратах по проекту с помощью AllFusion Harvest Change Manager.

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

Сокращение числа дефектов

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

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

Подробное исследование⁷ 13 организаций, внедривших у себя улучшение процесса разработки ПО на основе модели CMM, показало среднегодовое снижение числа дефектов после выпуска ПО на 39% (повышение качества), среднегодовое сокращение времени до появления продукта на рынке на 19% и среднее повышение производительности на 35%.

Другое исследование⁸, в котором приняли участие 807 организаций, внедривших модель CMM, показало, что при переходе организации с одного уровня модели CMM на другой наблюдается снижение числа дефектов и повышение производительности. Исследование показало снижение числа дефектов на 50% при переходе с первого на второй уровень модели CMM (управление проектами функционирует) и еще на 20% при переходе на третий уровень (процессы изменения регламентированы и функционируют). Аналогично производительность повысилась на 30% при переходе с первого на второй уровень модели CMM и еще на 20% при переходе на третий уровень.

Соблюдение графика работ

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

Продемонстрированная точность графика работ по проекту позволяет организациям- разработчикам ПО получить конкурентное преимущество, а также больше доверять своим группам разработчиков.

AllFusion Change and Configuration Management

Решения для управления изменениями AllFusion компании CA — это инструменты управляемого процессом управления изменениями, интегрирующие управление изменениями с процессом разработки.

AllFusion поддерживает широкий спектр методологий разработки путем автоматизации и регламентирования процессов разработки.

Управление изменениями AllFusion предлагает инструменты для мэйнфреймов, распределенных и гетерогенных сред разработки приложений, и состоит из следующих программных продуктов:

• AllFusion Harvest Change Manager — распределенное управление изменениями и конфигурацией;
• AllFusion Endevor Change Manager — управление изменениями и конфигурацией для мэйнфреймов;
• AllFusion Change Manager Enterprise Workbench — управление разработкой для нескольких платформ.

В наборе программ AllFusion Change Management Suite имеется ряд дополнительных инструментов для:

• автоматизации управления конфигурацией;
• интеграции параллельных или совместных исходных версий;
• непосредственного редактирования кода под управлением AllFusion Endevor Change Manager;
• управления изменениями объектов и приложений DB2;
• управления разработкой с помощью среды NATURAL и PREDICT.

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

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

Когда поставлена цель повысить качество и скорость разработки ПО, очень важно, чтобы инструменты управления изменениями были полностью интегрированы с процессом (все функции управления изменениями в одном инструменте), а не располагались поверх этого процесса. AllFusion — это комплексное, полностью интегрированное решение, также предлагающее интеграцию со многими популярными инструментами разработки, включая WebSphere Studio и Visual Studio .NET. Кроме того, инструменты Unicenter ServicePlus Service Desk и Unicenter Software Delivery компании CA позволяют интегрировать управление изменениями с более широким корпоративным системным администрированием, предлагая комплексное и полное управление жизненным циклом продукта.

Контролируя сложность процесса разработки путем управления изменениями и упрощения процесса изменения, решения для управления изменениями AllFusion повышают эффективность ИТ и максимально увеличивают ценность бизнеса.

Заключение

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

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

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

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

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

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

Перевод: БНТП по заказу Interface Ltd.

¹ Computer Associates, Industry Survey — Change Management (Опрос об управлении изменениями), октябрь 2002 года.

² Standish Group, The Chaos Report (Исследование "Хаос"), 2002 год.

³ Mark C. Paulk, Charles V. Webber, Bill Curtis and Mary Beth Chrissis , The Capability Maturity Model: Guidelines for Improving the Software Process (Модель зрелости процесса разработки программного обеспечения: рекомендации по улучшению процесса разработки программного обеспечения), 1995 год.

⁴ Институт программной инженерии, Университет Carnegie Mellon, Process Maturity Profile of the Software Community 1999 Update (Профиль зрелости процесса по версии сообщества программного обеспечения 1999 г. (новая редакция)), август 1999 года.

⁵ Институт программной инженерии, Список организаций, отвечающих уровню 5.

⁶ Computer Associates, Контроллинг затрат на разработку приложений с помощью управления изменениями и конфигурацией, 2003 год.

⁷ Computer Associates, Контроллинг затрат на разработку приложений с помощью управления изменениями и конфигурацией, 2003 год.

⁸ James Herbsleb, Anita Carleton, and others, Benefits of a CMM-Based Software Process Improvement: Initial Results, Software Engineering Institute (Преимущества улучшения процесса разработки ПО на основе модели CMM: начальные результаты, Институт программной инженерии), август 1994 года.