Проектирование семейства продуктов ( PFE ), также известное как проектирование линейки продуктов , основано на идеях « инжиниринга домена », созданных Институтом программной инженерии , термин, введенный Джеймсом Нейборсом в его диссертации 1980 года [1] в Калифорнийском университете в Ирвайне . Линейки программных продуктов довольно распространены в нашей повседневной жизни, но прежде чем семейство продуктов может быть успешно создано, необходимо выполнить обширный процесс. Этот процесс известен как проектирование семейства продуктов.
Проектирование семейства продуктов можно определить как метод, который создает базовую архитектуру платформы продуктов организации . Он обеспечивает архитектуру, основанную на общности, а также запланированных вариациях. Различные варианты продуктов могут быть получены из базового семейства продуктов, что создает возможность повторного использования и дифференциации продуктов в семействе. Проектирование семейства продуктов концептуально похоже на широко распространенное использование платформ транспортных средств в автомобильной промышленности.
Проектирование семейства продуктов — это относительно новый подход к созданию новых продуктов. Он фокусируется на процессе проектирования новых продуктов таким образом, чтобы можно было повторно использовать компоненты продукта и применять вариативность с меньшими затратами и временем. Проектирование семейства продуктов — это все о повторном использовании компонентов и структур в максимально возможной степени.
Несколько исследований доказали, что использование подхода к проектированию семейства продуктов для разработки продукта может иметь ряд преимуществ. [2] Вот список некоторых из них:
Упомянутый ниже случай Nokia также иллюстрирует эти преимущества.
Процесс проектирования семейства продуктов состоит из нескольких этапов. Три основных этапа:
Процесс был смоделирован на более высоком уровне абстракции. Это имеет то преимущество, что его можно применять ко всем видам линеек и семейств продуктов, а не только к программному обеспечению . Модель может быть применена к любому семейству продуктов. На рисунке 1 (ниже) показана модель всего процесса. Ниже процесс описан подробно. Описание процесса содержит детализацию действий и важных используемых концепций. Все концепции, напечатанные курсивом, поясняются в таблице 1.
Первая фаза — это запуск всего процесса. На этой фазе определяются некоторые важные аспекты, особенно в отношении экономических аспектов. Эта фаза отвечает за определение рыночных стратегий и определение области действия , которая говорит, что должно и не должно быть внутри семейства продуктов.
В ходе этого первого действия собирается и оценивается вся контекстная информация, относящаяся к определению области действия линейки продуктов. Важно определить четкую рыночную стратегию и принять во внимание внешнюю рыночную информацию, такую как потребительский спрос. Действие должно предоставить контекстный документ , содержащий руководящие принципы , ограничения и продуктовую стратегию .
Методы определения области применения применяются для определения того, какие аспекты входят в область применения. Это основано на предыдущем шаге процесса, где были учтены внешние факторы. Результатом является описание портфеля продуктов , которое включает список текущих и будущих продуктов , а также дорожную карту продукта .
Можно спорить, является ли фаза 1, управление продуктом, частью процесса проектирования семейства продуктов, поскольку ее можно рассматривать как отдельный бизнес-процесс, который больше сосредоточен на аспектах управления, а не на аспекте продукта. Однако фаза 2 нуждается в некотором важном вкладе от этой фазы, поскольку большая часть объема определяется на этой фазе. Поэтому с этой точки зрения важно включить фазу управления продуктом (фазу 1) во весь процесс в качестве основы для процесса проектирования домена.
На этапах проектирования домена собираются переменные и общие требования для всей линейки продуктов. Цель состоит в том, чтобы создать повторно используемую платформу. Результатом этого этапа является набор общих и переменных требований для всех продуктов в линейке продуктов.
Эта деятельность включает в себя все виды деятельности по анализу домена с точки зрения требований концепции. Требования категоризируются и делятся на два новых вида деятельности. Выходом является документ с анализом домена .
Как видно на рисунке 1, процесс определения общих требований является параллельным процессом с определением переменных требований. Оба действия происходят одновременно.
Включает в себя все мероприятия по выявлению и документированию общих требований к линейке продукции, в результате чего получается документ с общими требованиями, пригодными для повторного использования .
Включает в себя все действия по выявлению и документированию переменных требований к линейке продукции, в результате чего получается документ с переменными требованиями .
Этот шаг процесса состоит из действий по определению референтной архитектуры линейки продуктов. Это создает абстрактную структуру для всех продуктов в линейке продуктов.
На этом этапе создается детальный проект повторно используемых компонентов и реализация этих компонентов.
Проверяет и проверяет возможность повторного использования компонентов. Компоненты тестируются на соответствие их спецификациям. После успешного тестирования всех компонентов в различных вариантах использования и сценариях фаза проектирования домена завершается.
На заключительном этапе разрабатывается продукт X. Этот продукт X использует общности и изменчивость из этапа проектирования домена, поэтому продукт X выводится из платформы, созданной на этапе проектирования домена. По сути, он берет все общие требования и сходства из предыдущего этапа плюс свои собственные переменные требования. Используя базу из этапа проектирования домена и индивидуальные требования этапа проектирования продукта, можно создать полный и новый продукт. После того, как продукт будет полностью протестирован и одобрен, продукт X может быть поставлен.
Разработка спецификации требований к продукту для отдельного продукта и повторное использование требований из предыдущего этапа.
Все действия по созданию архитектуры продукта . Использует эталонную архитектуру из шага «область проектирования», выбирает и конфигурирует необходимые части эталонной архитектуры и включает адаптации, специфичные для продукта.
В ходе этого процесса продукт создается с использованием выбранных и конфигурированных повторно используемых компонентов .
На этом этапе продукт проверяется и подтверждается на соответствие его спецификациям. Отчет об испытаниях содержит информацию обо всех проведенных испытаниях, что дает обзор возможных ошибок в продукте. Если продукт на следующем этапе не принимается, процесс возвращается к «созданию продукта», на рисунке 1 это обозначено как «[неудовлетворительно]».
Последний шаг — приемка готового продукта. Если он успешно прошел испытания и был одобрен как готовый, его можно поставлять. Если продукт не соответствует спецификациям, его необходимо переделать и снова испытать.
На следующем рисунке показан общий процесс проектирования семейства продуктов, как описано выше. Это полный обзор процесса со всеми концепциями, прикрепленными к различным шагам.
С левой стороны нарисован весь процесс сверху вниз. Все действия с левой стороны связаны с концепциями с правой стороны пунктирными линиями. Каждая концепция имеет номер, который отражает связь с другими концепциями.
Ниже будет дано объяснение списка с концепциями. Большинство определений концепций взяты из Pohl, Bockle, & Linden (2005), а также были добавлены некоторые новые определения.
Таблица 1: Список концепций
Есть несколько хороших примеров использования проектирования семейства продуктов, которые были довольно успешными. Абстрактная модель проектирования семейства продуктов допускает различные виды использования, большинство из которых связаны с рынком потребительской электроники . Ниже приведен пример применения процесса проектирования линейки продуктов, основанный на реальном опыте Nokia.
Nokia производит различные типы продуктов. Среди них есть семейство продуктов мобильных телефонов , в настоящее время содержащее от 25 до 30 новых продуктов каждый год. Эти продукты продаются по всему миру, что делает необходимым поддерживать множество различных языков и пользовательских интерфейсов. Основная проблема здесь заключается в том, что необходимо поддерживать несколько различных пользовательских интерфейсов, и поскольку новые продукты сменяют друг друга очень быстро, это должно быть сделано максимально эффективно. Проектирование семейства продуктов позволяет создавать программное обеспечение для различных продуктов и использовать изменчивость для настройки программного обеспечения под каждый отдельный мобильный телефон.
Случай Nokia можно сравнить с обычной линейкой программного обеспечения . На первом этапе, управление продуктом , можно определить область действия различных серий мобильных телефонов. На втором этапе, проектирование домена , определяются требования для семейства и для отдельных типов телефонов, например, серии 6100/8300. На этом этапе составляются требования к программному обеспечению, которые могут служить основой для всего семейства продуктов. Это ускоряет общий процесс разработки программного обеспечения. Последний этап, проектирование продукта , больше ориентирован на отдельные типы телефонов. Требования из предыдущего этапа используются для создания индивидуального программного обеспечения для типа телефона, который затем разрабатывается.
Использование линейки продуктов дало Nokia возможность увеличить производство новых моделей мобильных телефонов с 5–10 до примерно 30. [3]