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

В этой статье мы приводим результаты исследования, в ходе которого изучалась разработка и техническая поддержка различных версий одного программного продукта. Хорошо проверенные модели, такие, как COCOMO [1] и SLIM [2] имеют дело с оценкой процесса разработки программного продукта. Другие включают более широкий круг метрик, в том числе атрибуты продукта. Например, Стивен Кан отмечает, что расширенный набор инструментов и организованный сбор данных о метриках помогли проекту IBM Rochester [3], предусматривающему создание средств разработки для AS/400, получить премию Baldrige Award в области качества. Мануэль Мендоса [4] также провел обширное исследование, в котором для изучения таких характеристик, как мощность и удобство, использовал подход Goal-Question-Metric («Цель-вопрос-метрика»), предоставляющий ряд способов повышения точности измерений. Однако ни один из этих подходов не предполагает управления портфелями программных продуктов или приложений. Несмотря на то что руководители могли бы самостоятельно использовать некоторые из этих идей, мы считаем, что более формальная структура была бы весьма полезной для всей ИТ-индустрии.

Мы разработали эвристическую среду для группировки продуктов в зависимости от таких параметров, как доля на рынке, функциональность продукта и стоимость его разработки. Наша среда разработки напоминает жизненный цикл адаптации технологии, описанный Джеффри Муром [5], который классифицировал пользователей технологии как энтузиастов и мечтателей (принимающих технологию с самого начала), прагматиков, консерваторов и скептиков. Кейперс Джонс разделил не пользователей, а проекты, сгруппировав их в лидирующие, средние и балансирующие на нижней грани качества (такие проекты имеют низкое качество, тогда как лидеры отличаются очень высоким качеством) [6].

В центре внимания статьи находятся метрики, характеризующие портфель ПО на основе зрелости входящих в него продуктов (слово «продукт» здесь означает не только саму программу или приложение, но и все его версии).

Среда оценки зрелости продуктов

Уровень зрелости продукта определяется с учетом продолжительности его присутствия на рынке, его базы инсталляций и планируемых инвестиций для соответствия новым функциональным требованиям. На основе этих характеристик мы можем распределить продукты по степени зрелости: новые, растущие и стабильные [7].

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

На распределение продуктов по категориям согласно степени зрелости влияют и другие характеристики (см. табл. 1), большинство из которых определяется владельцем или производителем ПО, а некоторые — покупателем.

Владельцы и производители ПО

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

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

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

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

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

Покупатели

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

Ограничения

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

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

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

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

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

Результаты исследования

Мы собрали данные о 30 межплатформенных продуктах (связь, доставка сообщений, серверы приложений и т.д.), которые распределили по введенным нами категориям зрелости. Шесть продуктов были классифицированы нами как новые, девять — как растущие, и оставшиеся 15 — как стабильные. Показатели качества каждого из продуктов все время менялись в зависимости от его недостатков и проблем отрасли. Если проблема требовала изменений в коде или документации, она регистрировалась в базе данных IBM как дефект. Полученные данные о качестве ПО были проанализированы в ходе нескольких исследований [8-11].

При анализе полученных данных за период с января 2001 по октябрь 2003 года были выявлены некоторые тенденции изменения количества проблем и дефектов, обнаруженных у программных продуктов различной степени зрелости. Так, у новых продуктов в течение 2001 года число проблем не менялось, оставаясь на минимальном уровне. В январе 2002 года начался рост числа проблем, который продолжался вплоть до апреля 2003 года. Тогда же был достигнут максимум (превысивший показатель 2001 года примерно в два раза), на уровне которого количество проблем стабилизировалось, сохраняясь до октября 2003 года. У растущих продуктов за тот же период времени количество проблем было значительно выше, чем у новых продуктов, но к октябрю 2003 года выросло в среднем незначительно. У стабильных продуктов количество проблем не только не возросло, но и пошло на спад приблизительно с апреля 2002 года. Все эти результаты позволяют сделать следующие выводы: у новых продуктов количество проблем поначалу невелико, но со временем оно растет; у растущих продуктов наблюдается тенденция к замедлению роста числа проблем и достижению некоторого постоянного значения; стабильные продукты характеризуются постепенным снижением числа проблем.

Аналогичная картина получилась и при анализе изменений числа дефектов, выявленных у исследуемых продуктов за тот же период (с января 2001-го по октябрь 2003 года). У новых продуктов число дефектов сохранялось на минимальном уровне в течение всего 2001 года, затем произошел резкий скачок, за которым последовал существенный рост, и к январю 2003 года число выявленных дефектов превысило минимум более чем в 6 раз. У растущих продуктов на протяжении данного периода наблюдался в среднем весьма незначительный рост числа дефектов, ослабевавший со временем. У стабильных продуктов прослеживалось постепенное снижение числа выявляемых дефектов. Полученные результаты позволяют заключить, что новые продукты показывают тенденцию к резкому увеличению числа выявляемых дефектов, растущие продукты склонны к выходу числа дефектов на постоянный уровень, а число дефектов, обнаруживаемых у стабильных продуктов, со временем уменьшается. Среднемесячные значения изменений в количествах дефектов и проблем приведены в табл. 2.
Таблица 2. Среднее ежемесячное изменение количества проблем и дефектов ПО
Использование нашей рабочей среды помогло сделать несколько дополнительных выводов.

Вывод 1. Руководствуйся тенденциями, а не количеством

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

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

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

Вывод 2. Обеспечивай качественное обслуживание

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

Вывод 3. Со зрелостью приходит сложность

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

Вывод 4. Скорость достижения готовности — не всегда самое важное

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

Сценарии использования

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

Первый сценарий касается перспективы покупки ПО. Управление ИТ-системой требует установки ПО разных уровней: встроенного ПО, операционной системы, межплатформенного и прикладного ПО. На каждом уровне могут находиться продукты разной степени зрелости. Например, встроенное ПО и ОС могут быть стабильными продуктами, межплатформенное ПО может представлять собой растущий продукт, а приложения — новые. Каким образом покупателю следует управлять развертыванием такой ИТ-системы? Для анализа вопросов технической поддержки, таких как, применение доработок и обновлений продуктов, подразделение технической поддержки должно рассматривать каждый уровень системы отдельно, в зависимости от зрелости продуктов, находящихся на этом уровне. Более зрелые компоненты могут иметь более жесткий план обновлений, чем менее зрелые, обновление которых может представлять собой слишком серьезное изменение, способное нарушить стабильность системы.

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

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

ЛИТЕРАТУРА

  1. B.W. Boehm et al., Software Cost Estimation with COCOMO II. Prentice Hall, 2000.
  2. L.H. Putnam, W. Myers, Measures for Excellence: Reliable Software on Time, Within Budget. Prentice Hall, 1992.
  3. S. Kan, Metrics and Models in Software Quality Engineering. Addison-Wesley, 1996.
  4. M. Mendonca, An Approach to Improving Existing Measurement Frameworks in Software Development Organizations. Doctoral dissertation, Computer Science Dept., Univ. of Maryland, 1997.
  5. G. Moore, Crossing the Chasm. Harper Business, 2002.
  6. C. Jones, The Impact of Poor Quality and Canceled Projects on the Software Labor Shortage. Tech. report, Software Productivity Research, 1998.
  7. B. Hodges et al., Software Lifecycle Dynamics, IBM internal document. Software Group Quality champions working session, St. Louis, Missouri, 2001.
  8. S. Chulani et al., Deriving a Software Quality View from Customer Satisfaction and Service Data. Proc. 12th European Software Control and Metrics Conf. (ESCOM 01), Shaker Publishing, 2001.
  9. M. Buckley, R. Chillarege, Discovering Relationships between Service and Customer Satisfaction. Proc. 21st Int’l Conf. Software Maintenance, IEEE CS Press, 1995.
  10. J. Shaw, Customer Inspired Quality: Looking Backward through the Telescope. Jossey-Bass, 1996.
  11. C. Chakrapani, How to Measure Service Quality and Customer Satisfaction. Am. Marketing Assoc., 1997.
  12. F. Broussard, Streamlining Application Configuration for the Enterprise. White paper, IDC, 2004

Сунита Чулани (sunita@us.ibm.com) — научный сотрудник, П. Сантанам (pasanth@us.ibm.com) — директор департамента программной инженерии исследовательского центра IBM T.J. Watson Research; Брент Ходжес (hodgesb@us.ibm.com) — директор программ подразделения контроля качества IBM Corporate Software Quality; Келли Блэкстен Эндерс (kelleyb@us.ibm.com) — сотрудник IBM Software Group.

Sunita Chulani, P. Santhanam, Brent Hodges, Kelley Blacksten Anders. Metrics-Based Management of Software Product Portfolios. IEEE Software, March/April 2007. IEEE Computer Society, 2007. All rights reserved. Reprinted with permission.