+7 (495) 229-0436 | shopadmin@itshop.ru | 119334, г. Москва, ул. Бардина, д. 4, корп. 3 |
|
|
Проектирование продукта с учетом будущих вариантов13.02.2014 14:53
Признание необходимости проектирования продукта с учетом будущих вариантов и создания методик управления вариантами имеет решающее значение для успешного развития продукта с течением времени. Управление вариантами позволяет составить перечень будущих вариантов и заложить их в продукт. Обычно в новых проектах разработки продуктов планирование будущих вариантов изначально не выполняется. В этой статье Джоан Скоулер (архитектор учебных программ, 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 отображают расходящиеся и вновь сходящиеся продуктыРазвертывание вариантов программного кодаВ процессе разработки варианты программного кода можно развернуть в нескольких точках:
Развертывание во время компоновки используется в случае большого объема кода. Однако вариантами, развернутыми во время компоновки, бывает трудно управлять. Например, в корпорации Eaton раньше использовали этот метод, но обнаружили, что накладные расходы слишком велики, особенно при управлении несколькими сборками и предоставлении соответствующей сборки для определенного варианта оборудования. Значительные накладные расходы связаны с выпуском новых версий ПО и номеров деталей, а также с распространением этого процесса по всей организации. По причине малых объемов, отсутствия строгих ограничений памяти и необходимости быстрого выхода на рынок в Eaton отказались от этого метода. Однако производителям медицинского оборудования и производителям в других отраслях требуется развертывание во время компоновки в связи с нормативными ограничениями или ограничениями памяти. Как избежать типичных проблем реализацииТипичная проблема при разработке вариантов - преодоление преобладающего организационного и культурного способа мышления. Для многих проектов существует явная необходимость перехода на управления вариантами, но текучка никогда не оставляет на это времени. Менеджеры по продукции соглашаются с тем, что идея хороша теоретически, но всегда хотят приступать к выполнению работы по управлению вариантами после окончания текущего проекта. Менеджеры по продукции чувствуют, что переход на цикл разработки с использованием вариантов вызовет задержки, и поэтому сопротивляются, боясь потерять контроль над своими проектами. Когда организации решаются, наконец, реализовать стратегию управления вариантами, наступает период дискомфорта и программных задержек. Переход начинается с сопротивления и сомнения в том, что решение является правильным. Но после перехода на строгий процесс управления вариантами организации получают сокращение времени выхода на рынок, более высокое качество продукции и более эффективных инженеров. Менеджеры по линейкам продуктов довольны, потому что получают более предсказуемые программы и ресурсы. Клиенты довольны, потому что получают повышение качества и сокращение время отклика. Крейг Джекобс, вспоминая свой проект трансмиссии, удивляется, как его группе удалось внедрить методологию проектирования вариантов на ранних этапах процесса разработки. Она могла потребовать больше времени, задержав выход первых систем на рынок, и возможности были бы упущены. Одним из возможных компромиссов при проектировании с учетом будущих вариантов является изначальное следование передовым методикам, которые требуют лишь незначительной работы. Такой подход облегчит разработку разнообразных вариантов позднее. Чтобы определить бизнес-стратегию управления вариантами, ответьте на следующие вопросы:
Рекомендации по проектированию продуктов с учетом будущих вариантовОсновные рекомендации по проектированию продукта с учетом будущих вариантов:
Следуя этим рекомендациям с самого начала, значительно легче адаптировать конструкцию при возникновении потребности в вариантах. Следуя этим рекомендациям, можно пометить элемент и сопоставить его с конкретными конструктивными особенностями. Затем, решив, какой процесс разработки использовать, вы увидите, что его можно легко реализовать. Без хорошего проекта это сделать гораздо труднее. Для управления вариантами можно использовать не только Rational Rhapsody и ClearCase, но и другие инструменты IBM. Каждый инструмент поддерживает разные аспекты повторного использования и потому требует разного подхода к управлению. Например, ПО для управления требованиями Rational® DOORS® поддерживает версии в основном посредством базовых показателей и наборов базовых показателей, но не поддерживает варианты требований и повторное использование требований. Таким образом, чтобы управлять вариантами в DOORS, нужно использовать клонирование. При использовании IBM® Rational® Engineering Lifecycle Manager вместе с DOORS можно связывать варианты друг с другом и с ассоциированными продуктами. Кроме того, Rational Engineering Lifecycle Manager помогает управлять вариантами. Можно определять линейки продуктов и варианты в описаниях продукта и связывать эти описания с требованиями, моделями, элементами модели, тестами и другими инженерными артефактами. ЗаключениеНезависимо от способа проектирования варианты требуют больших усилий, чем единичные продукты, но проектирование с учетом будущих вариантов часто является наиболее эффективным в долгосрочной перспективе. Ответ на вопросы, когда, почему и как нужно выполнять проектирование с учетом будущих вариантов, поможет управлять портфелем продуктов так, чтобы продукты точнее соответствовали меняющимся требованиям клиентов. Ссылки по теме |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
О нас |
Интернет-магазин ITShop.ru предлагает широкий спектр услуг информационных технологий и ПО.
На протяжении многих лет интернет-магазин предлагает товары и услуги, ориентированные на бизнес-пользователей и специалистов по информационным технологиям. Хорошие отзывы постоянных клиентов и высокий уровень специалистов позволяет получить наивысший результат при совместной работе. В нашем магазине вы можете приобрести лицензионное ПО выбрав необходимое из широкого спектра и ассортимента по самым доступным ценам. Наши менеджеры любезно помогут определиться с выбором ПО, которое необходимо именно вам. Также мы проводим учебные курсы. Мы приглашаем к сотрудничеству учебные центры, организаторов семинаров и бизнес-тренингов, преподавателей. Сфера сотрудничества - продвижение бизнес-тренингов и курсов обучения по информационным технологиям.
|
119334, г. Москва, ул. Бардина, д. 4, корп. 3 +7 (495) 229-0436 shopadmin@itshop.ru |
|
© ООО "Interface Ltd." Продаем программное обеспечение с 1990 года |