Автор: Jansen S., Brinkkemper S.
Перевод: Соколова А.В.
Источник: Software Product Management, 2006. IWSPM ’06, — 2006, p. 44–50
Ранее планирование выпуска продукта программного обеспечения было охарактеризовано в качестве «опасной» [4] и «комплексной» [1] проблемы, для которой не существует совершенного решения. Один из элементов планирования релизов — планирование выпускаемого пакета, часто недооценивают по причине его кажущейся невинной и несложной природы. Продавцы продуктов программного обеспечения, которые не имеют большого опыта в планировании выпуска, часто издают релиз–пакеты, потому что команда экспертов в пределах организации считает их достаточно хорошими, что приводит к тому, что некоторые релизы могут быть с трудом восприняты клиентами, в то время как другие являются более популярными.
Вместе с тем, пакеты релизов создаются в течении всего жизненного цикла продукта, который предполагает, например, создание релиз–пакета, публикацию релиз–пакета, информирование клиента о новых версиях и обновлениях — это повторяющиеся процессы, которые должны быть автоматизированы, насколько это возможно, чтобы облегчить как усилия клиента по обновлению программ, так и усилия по созданию релиз–пакета поставщиком. Уменьшение этих усилий приводит к тому, что клиенты более охотно готовы к обновлениям, а поставщики — к регулярному выпуску, что предложено в гибких методах разработки ПО, таких как экстремальное программирование [2]. Тем не менее, из ряда тематических исследований, проведенных в прошлом, было обнаружено, что производители программных продуктов, как правило, не достаточно хорошо планируют свои релизы.
Мы определяем релиз продукта программного обеспечения как хранение, публикацию, идентификацию и сборку элементов продукта. Планирование релиз-пакета, как часть планирования релиза — это процесс, определяющий, какие функции и исправления каких ошибок включены в релиз–пакет, процесс определения в этих пакетах исправлений ошибок, мелких или крупных обновлений, учитывая релизы, которые были опубликованы в прошлом, и о возможном процессе обновления, необходимом для перехода от одной версии продуктов к другой. Например, на рис.1 показан снимок релиза из недавнего исследования [5], на котором отображены мелкие и крупные обновления, нововведения и исправления ошибок.
Пакет обновления — это пакет, который продвигает пользовательскую конфигурацию к более новой конфигурации. Также, пакет обновлений исправлений содержит только исправления ошибок, а пакет обновления функций состоит только из новых функций, а пакеты мелких и крупных обновлений содержат как и новые функции, так и исправления ошибок. Различия между мелкими и крупными пакетами обновлений состоит чаще в том, что крупные обновления изменяют структурные составляющие продукта, например, архитектуру модели данных. С нашей точки зрения эволюция программного обеспечения, описанная здесь, похожа на построенную модель Райлиха и Беннета [3], в которой, прежде всего, рассматриваются эволюционные изменения (мелких и крупных обновлений), после чего следует обзор патчей (пакетов исправлений) до прекращения и закрытия релизов.
Цель этой статьи — осветить этап планирования выпуска релиз–пакета при исследовании процесса управления программным обеспечением. Это достигается за счет представления функций себестоимости. Представленные функции себестоимости обеспечивают дополнительную проверку перед публикацией релиз–пакета для производителей программных продуктов. В том, что представленный метод решения является полезным расширением процесса выпуска продукта, говорят многие методы, такие как, представление программного продукта для малого бизнеса [11], метод, который поддерживает инфраструктуру базы знаний программного продукта [13], и другие методы, которые поддерживают планирование релиза [10]. Раздел «Определение функций себестоимости» представляет и описывает функции себестоимости. В разделе «Обсуждение и выводы» мы обсуждаем предложенный метод и приводим выводы.
В этом разделе описываются функции значений себестоимости для клиентов (формулы (1)–(3)) при обновлении программного обеспечения и поставщиков (формулы (4)–(6)) при выпуске новых версий продуктов. Эти функции отдельно описывают затраты на обновления для клиентов, стоимость обновления для клиентов, стоимость новой версии для поставщика и затраты на создание релиз–пакета для производителя. Функции основаны на тематических исследованиях, проведенных в семи организациях [7]. Кроме того, функции заказчика построены на основе различных документов от Организации Планирования Ресурсов Предприятий (ПРП), обновлений приложений и миграции [9], и недавних исследований, которые мы провели касательно поставщиков систем управления контентом, которые также осуществляют обновления и миграцию для клиентов [6]. Функции себестоимости схожи с функциями прибыли, разработанными Research Triangle Institute [12]. Тем не менее, эти функции прибыли используется для расчета влияния недостатков тестирования программного обеспечения на программное обеспечение бизнеса, а не специально для расчета сроков выпуска обновлений.
Функции клиентов
Решение клиента на обновление программного продукта основывается на ряде факторов. Прежде всего, клиент заинтересован в стоимости обновления. Эта стоимость может иметь различные формы, например, добавление нового уровня в игре, которые предоставляют клиенту больше развлечений, или совершенно новый модуль планирования производства, ПРП пакет сохраняющий клиенту многие миллионы. Одновременно заказчик будет принимать во внимание стоимость обновления. Такими затратами могут быть усилия, совершенные для загрузки и установки нового уровня игры или простоя системы ПРП в процессе обновлений, стоящих компании многие миллионы.
Стоимость обновлений клиента определяется как Cval (1). Функция определяет стоимость обновления для клиента, а стоимость новых функций заказчика будет использовать сумму стоимости без стоимости путей устранения ошибок. Новые функции включают в себя не только те функции, которые были добавлены в новую версию, но и те, которые просто не работали в предыдущей версии, и для которых не были доступны операции устранения ошибок.
Перед тем, как клиент примет решение обновить ПО, клиент будет рассчитывать стоимость обновления, чтобы увидеть, действительно ли оно того стоит. Ccost функция затрат (2) определяет стоимость обновления, как затраты на простой продукта, затраты на обучение людей, использующих новые/измененные функциональные возможности, стоимость работы, приложенной в процессе обновления, стоимость функциональности, которая была удалена из выпуска или затраты на настройки, которые не могут быть использованы после обновления, и, наконец, стоимость платежей поставщику для обновления.
Чтобы принять решение по обновлению для клиентов, Cval должна превышать Ccost (3), особенно если принять во внимание, что ресурсы, необходимые для выполнения обновления обычно выполняют другие задачи, дополнительной стоимости. Довольно удивительно видеть, что многие производители не вкладывают структурные средства в сокращение этих расходов для клиента, тем более что в большинстве наших тематических исследований до 70 процентов доходов поступали из существующих контрактов на обслуживание, и только 30 процентов от новых клиентов. Кроме того, если производитель видит, что Ccost превышает Cval для большого количества клиентов, выпуск обновлений становится практически бесполезным, если продавец надеется привлечь большое количество новых клиентов. Это кажется невероятным, однако, если текущие клиенты не заинтересованы в продукте, то почему бы новым быть заинтересованными?
Функции производителя
Для производителя стоимость обновления гораздо сложнее вычислить, особенно потому, что она включает в себя оценку того, сколько новых клиентов привлечено в новой версии, и сколько клиентов действительно готовы к обновлению. Стоимость поставляемого нового релиза определяется новыми клиентами, привлекаемыми релизом, специально ориентированным на новые рынки, сокращение обращений в службу поддержки за счет исправлений ошибок с коммерческой операционной системой, или клиентом, который платит поставщику за обновление своего ПРП продукта.
Функция стоимости производства Vval (4) описывает стоимость новой версии, как число новых клиентов умноженных на цену нового релиза, текущие клиенты, которые готовы обновить систему с меньшими затратами и, наконец, снижение затрат на поддержку, вызванных в связи с исправлениями в новом пакете релиза. Расчет Vval является трудным, главным образом, потому что эта величина включает в себя оценку числа новых клиентов и оценку того, сколько клиентов готовы к обновлению с предыдущей версии. Vval могла бы ввести разные цены для различных обновлений. Если версия пакета содержит большое количество исправлений, могут быть сокращены расходы на поддержку. Однако если были введены множество новых функций, это сокращение может быть отменено путем увеличения расходов на поддержку.
Vcost (5) функция определяется как затраты на разработку функциональности и исправлений ошибок в новом пакете релиза, затраты на обновления существующих клиентов, затраты связанные с увеличением вопросов, связанных с поддержкой новой версии, затраты на маркетинг, стоимость доставки нового пакета релиза для клиентов, и, наконец, стоимость упаковки релиза. Стоимость обновления существующих клиентов включает в себя такие вещи, как инструмент обновления [8], обновляющий их лицензии, а также возможные вопросы поддержки, которые возникают в процессе обновления. Затраты на маркетинг включает в себя информирование существующих клиентов о новой версии, маркетинговые кампании, создание выпуска, и поддержка веб–сайта продукта. Стоимость доставки обновлений для клиентов включает в себя создание среды поставки (CD, DVD, дискеты, USB–флешки, веб–сайт и т.д.), монтаж всех артефактов, возможность перевода языков файлов продукта и проверки полноты выпуска.
Vcost / Vval функции используются для расчета подходящего времени для создания пакета релиза. Как правило, это случай, когда Vcost превышает Vval (6), т.е. когда потенциальная стоимость выпуска обновления выше, чем затраты, требуемые на создания обновлений. Автоматизация процессов, которые составляют создание релиз–пакета и публикации может потенциально снизить Vcost, что позволяет поставщику программного обеспечения чаще осуществлять релизы. Это похоже на условие (3), где автоматизация доставки и развертывания процессов может снизить Ccost, что делает обновление более привлекательным для клиентов.
Функции в этом разделе стремятся в значительной степени изменяться, когда рассматривается исправление ошибок, мелкий или крупный пакет релиза. В случае с пакетом исправлений, который выпущен онлайн, — в отличие от основной версии, продавцу нет нужды создавать новые носители. Решение о выпуске исправлений, мелкого пакета или крупного пакета релиза можно принять с помощью этих функций. Если сокращение расходов на поддержку оправдывает усилия, приложенные на исправление количества ошибок, релиз исправлений является оправданным. Если сокращение расходов на поддержку не оправдывает усилия, приложенные на исправление массы ошибок и добавление функциональности, вы можете получить его обратно, делая следующий выпуск меньшей версией. Если производитель считает, что следующий релиз должен привлечь больше доходов от новых и старых клиентов, это может быть оправданным только в случае крупного релиз–пакета. Конечно, это не трудные понятия. В том случае, если ошибка стоила непропорционально много времени для исправления, она не может быть оправдана для публикации незначительных релиз–пакетов. Поставщик должен задать себе вопрос, стоила ли того попытка исправить эту ошибку в первую очередь.
В этой статье приведены функции стоимости и затрат для производителей программных продуктов, которые могут использовать их для оценки, насколько выгодно выпустить очередную версию своего программного обеспечения. В то же время, функции работают для того, чтобы помочь клиенту для принятия решения в обновлении программных продуктов. Наконец, эти функции показывают, что расходы могут быть сокращены как для поставщиков, так и для клиентов на часто встречающиеся исправления и незначительные обновления программных продуктов, которые могут сократить циклы обратной связи с конечными пользователями. Процесс планирования выпуска пакета значительно упрощается с использованием представленных функций себестоимости. Эти функции также защищают инвестиции производителей программного продукта в автоматизацию процессов, таких как создание релиз–пакета, публикацию релиз–пакета, информирование клиента о новой версии и обновлении.
Тот факт, что этого не происходит на практике, приводит к ряду вопросов, например, почему производители не инвестируют больше ресурсов в эти процессы? Наиболее частый ответ от поставщиков, когда они сталкивались с этим вопросом, было то, что они уже заняты созданием своих конкретных программных решений, но они уже были бы рады купить инструмент, который помогает автоматизировать эти задачи. Слабость функции себестоимости, вызванная одержимостью краткосрочной прибыли, приведет любого поставщика программных продуктов без долгосрочного видения в пропасть. Производители должны учитывать готовность клиентов предложить большие суммы денег на мелких производителей, если они просто создадут одну небольшую особенность в программном обеспечении, которая является чрезвычайно ценной функцией для клиента.