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

Соображения, мотивы и рекомендации

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

Джоанн Л. Скоулер, архитектор учебных программ, IBM China

Джоанн Л. Скоулер (Joanne Scouler) – фотографияДжоанн Скоулер (Joanne Scouler) является архитектором учебных программ IBM и занимается бизнес-планированием и разработкой курсов по ПО для системного проектирования. На протяжении последних шести лет она разрабатывает и ведет учебные курсы по Rational Rhapsody. Имеет опыт обучения встраиваемым системам и моделированию ПО различных клиентов, включая Raytheon, Draper Lab, Pratt & Whitney, Zoll Medical и Kollmorgren. До прихода в IBM Джоан работала в Telelogic, Hewlett-Packard, 3Com Corporation, Symantec и Addison-Wesley.



Мартин Р. Бакал, менеджер по продуктам Rational, IBM China

Мартин Бакал (Martin Bakal) – фотографияМартин Бакал (Martin Bakal) имеет 15-летний опыт работы в области встраиваемого ПО в качестве специалиста по использованию IBM Rational Rhapsody, консультанта, преподавателя и т.д. Он работал преподавателем курсов по UML и SysML, а также по процессу IBM Rational Harmony и среде управляемой моделями разработки IBM Rational Rhapsody. В качестве преподавателя и консультанта по встроенным системам и моделированию ПО работал с широким кругом клиентов по всему миру, включая Lockheed Martin, General Dynamics, GM и Philips. Написал множество технических статей по моделированию, повторному использованию и линейкам продуктов, а также по другим темам.



24.10.2013

Введение

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

Основные рекомендации по проектированию продукта с учетом будущих вариантов:

  • Начинайте проектирование с качественных, чистых интерфейсов.
  • Используйте хорошее компонентное представление.
  • Используйте переменные вместо констант.

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

Для управления вариантами можно использовать не только Rational Rhapsody и ClearCase, но и другие инструменты IBM. Каждый инструмент поддерживает разные аспекты повторного использования и потому требует разного подхода к управлению. Например, ПО для управления требованиями Rational® DOORS® поддерживает версии в основном посредством базовых показателей и наборов базовых показателей, но не поддерживает варианты требований и повторное использование требований. Таким образом, чтобы управлять вариантами в DOORS, нужно использовать клонирование. При использовании IBM® Rational® Engineering Lifecycle Manager вместе с DOORS можно связывать варианты друг с другом и с ассоциированными продуктами.

Кроме того, Rational Engineering Lifecycle Manager помогает управлять вариантами. Можно определять линейки продуктов и варианты в описаниях продукта и связывать эти описания с требованиями, моделями, элементами модели, тестами и другими инженерными артефактами.


Заключение

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


Благодарности

Авторы благодарят Крейга Джекобса (Craig Jacobs) из корпорации Eaton за его вклад в статью.

Ресурсы

  • Оригинал статьи: Product Design for Variants (EN).
  • Дополнительная информация о способах использования программных продуктов Rational, упомянутых в этой статье:
    • Rational ClearCase для управления конфигурацией программного обеспечения.
    • Rational DOORS для управления требованиями.
    • Rational Engineering Lifecycle Manager для визуализации, анализа и организации технических данных и отношений данных.
    • Rational Rhapsody для управляемой моделями разработки.

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Rational
ArticleID=949997
ArticleTitle=Проектирование продукта с учетом будущих вариантов
publish-date=10242013