Проектирование продукта с учетом будущих вариантов

Источник: IBM

Признание необходимости проектирования продукта с учетом будущих вариантов и создания методик управления вариантами имеет решающее значение для успешного развития продукта с течением времени. Управление вариантами позволяет составить перечень будущих вариантов и заложить их в продукт. Обычно в новых проектах разработки продуктов планирование будущих вариантов изначально не выполняется. В этой статье Джоан Скоулер (архитектор учебных программ, IBM China) и Марти Бакал (менеджер по продуктам Rational, IBM China)объясняют, с чего начать работу с вариантами. Они иллюстрируют свои мысли примерами из опыта корпорации Eaton по разработке вариантов трансмиссий для сверхмощных гибридных транспортных средств. Авторы также рассказывают, как могут использовать при этом различные программные продукты Rational.

Введение

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

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

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

Выявление потребности в вариантах

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

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

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

Рисунок 1. Элементы транспортных средств, выпускаемые Eaton

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

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

Разработка бизнес-стратегии управления вариантами

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

При создании хорошего бизнес-сценария необходимо учитывать следующие факторы:

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

Повышение эффективности посредством управления вариантами

Компании переходят на управление вариантами, чтобы уменьшить время выхода на рынок и снизить эксплуатационные расходы. Эффективность можно обеспечить за счет использования в процессе проектирования ПО для моделирования, IBM® Rational® Rhapsody®, предназначенного для проектирования с возможностью повторного использования и визуализации вариантов в линейке продуктов. Rhapsody помогает анализировать и проверять требования, ускорять проектирование с помощью прототипов и унифицировать приложения посредством использования языка моделирования систем (Systems Modeling Language - SysML) и унифицированного языка моделирования (Unified Modeling Language - UML). Такой подход облегчает интеграцию вариантов для OEM-производителей и поставщиков новых компонентов. Для поставщиков гибридных двигателей, например, спецификации интерфейса компонентов должны быть написаны в предположении, что физические параметры будут варьироваться. ПО компонентов и системное ПО должны предоставлять возможность настройки для эффективного расширения линейки продуктов. Системные функции должны легко включаться и отключаться.

Рисунок 2. Диаграмма компонентов конкретного варианта в Rhapsody

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

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

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

В сочетании со стратегией загрузки можно использовать инструмент Rational ClearCase® (ПО для управления конфигурациями), позволяющий проверять варианты кода как отдельные ветви дерева. При помощи ClearCase эти ответвления можно легко объединять. Автомобильные компании могут объединять региональные требования в глобальные, а также включать и отключать варианты (см. рисунок 3). Они могут создавать варианты, а затем объединять их в одну поставку. ClearCase поддерживает представления различных потоков программного кода. Используя свои собственные представления, инженеры могут сосредоточиться на конкретных вариантах.

Рисунок 3. Представления ClearCase отображают расходящиеся и вновь сходящиеся продукты

Развертывание вариантов программного кода

В процессе разработки варианты программного кода можно развернуть в нескольких точках:

Во время генерации кода. Rational Rhapsody может генерировать код для варианта конкретного продукта. Этот код специфичен для продукта и может быть быстрее прочитан без кода других вариантов.
Во время компоновки. Используются следующие опции компоновки:
1. Директивы компилятора, такие как #ifdef.
2. Наследование, где одна сборка включает различных потомков другой.
Во время выполнения (обычно при инициализации). При инициализации конфигурационные файлы продукта загружаются в приложение, заставляя его использовать только указанные варианты.

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

Как избежать типичных проблем реализации

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

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

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

Чтобы определить бизнес-стратегию управления вариантами, ответьте на следующие вопросы:

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

Заключение

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

Ссылки по теме