Разработка семейства продуктов

Проектирование семейства продуктов ( PFE ), также известное как проектирование продуктовых линеек , основано на идеях « инжиниринга предметной области », созданных Институтом программной инженерии , термин, придуманный Джеймсом Нейборсом в его диссертации 1980 года. ^[1] в Калифорнийском университете в Ирвайне . Линии программных продуктов довольно распространены в нашей повседневной жизни, но прежде чем успешно создать семейство продуктов , необходимо выполнить обширный процесс. Этот процесс известен как проектирование семейства продуктов.

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

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

Несколько исследований доказали, что использование подхода к разработке продуктов, основанного на семействе продуктов, может иметь несколько преимуществ. ^[2] Вот список некоторых из них:

Более высокая производительность
Более высокое качество
Ускоренный выход на рынок
Снижение потребности в рабочей силе

Упомянутый ниже случай с Nokia также иллюстрирует эти преимущества.

Общий процесс

Процесс разработки семейства продуктов состоит из нескольких этапов. Три основных этапа:

Процесс смоделирован на более высоком уровне абстракции. Преимущество этого метода заключается в том, что его можно применять ко всем видам линеек и семейств продуктов, а не только к программному обеспечению . Модель может быть применена к любому семейству продуктов. На рисунке 1 (ниже) показана модель всего процесса. Ниже процесс описан подробно. Описание процесса содержит подробное описание действий и используемых важных концепций. Все понятия, выделенные курсивом, поясняются в Таблице 1.

Этап 1: управление продуктом

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

Оцените видение бизнеса

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

Определить объем продуктовой линейки

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

Можно утверждать, что фаза 1, управление продуктами, является частью процесса разработки семейства продуктов, поскольку ее можно рассматривать как отдельный бизнес-процесс, который больше ориентирован на аспекты управления, а не на аспект продукта. Однако этап 2 требует некоторого важного вклада на этом этапе, поскольку на этом этапе определяется большая часть объема работ. Поэтому с этой точки зрения важно включить этап управления продуктом (этап 1) во весь процесс в качестве основы для процесса проектирования предметной области.

Этап 2: разработка предметной области

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

Анализ требований к домену

Эта деятельность включает в себя все действия по анализу предметной области с точки зрения концептуальных требований. Требования классифицированы и разделены на два новых вида деятельности. На выходе получается документ с анализом предметной области .

Как видно на рисунке 1, процесс определения общих требований является параллельным процессом с определением переменных требований. Оба действия происходят одновременно.

Определить общие требования

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

Определить требования к переменным

Включает все действия по выявлению и документированию переменных требований к продуктовой линейке, в результате чего создается документ с переменными требованиями .

Область проектирования

Этот этап процесса состоит из действий по определению эталонной архитектуры линейки продуктов. Это создает абстрактную структуру для всех продуктов в линейке продуктов.

Внедрить домен

На этом этапе создается подробный проект повторно используемых компонентов и реализация этих компонентов.

Тестовый домен

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

Этап 3: разработка продукта

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

Определить требования к продукту

Разработка спецификации требований к отдельному продукту и повторное использование требований предыдущего этапа.

Дизайнерский продукт

продукта Все действия по созданию архитектуры . Использует эталонную архитектуру из этапа «Область проектирования», выбирает и настраивает необходимые части эталонной архитектуры и включает адаптации для конкретного продукта.

Создать продукт

В ходе этого процесса продукт создается с использованием выбранных и конфигураций повторно используемых компонентов .

Тестовый продукт

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

Доставка и поддержка продукта

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

На следующем рисунке показан общий процесс разработки семейства продуктов, описанный выше. Это полный обзор процесса со всеми концепциями, связанными с различными этапами.

Диаграмма данных процесса

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

Список концепций

Ниже будет пояснен список концепций. Большинство определений понятий взято из Pohl, Bockle & Linden (2005), а также добавлено несколько новых определений.

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

Таблица 1: Список концепций

Пример

Есть несколько хороших примеров использования семейства продуктов, которые оказались весьма успешными. Абстрактная модель разработки семейства продуктов допускает различные виды использования, большинство из которых связаны с рынком бытовой электроники . Ниже приведен пример применения процесса проектирования продуктовой линейки, основанный на реальном опыте Nokia.

Nokia производит разные виды продукции. Среди них — семейство продуктов для мобильных телефонов , которое в настоящее время содержит от 25 до 30 новых продуктов каждый год. Эти продукты продаются по всему миру, что требует поддержки множества разных языков и пользовательских интерфейсов. Основная проблема здесь заключается в том, что необходимо поддерживать несколько различных пользовательских интерфейсов, а поскольку новые продукты очень быстро сменяют друг друга, это следует делать как можно эффективнее. Разработка семейства продуктов позволяет создавать программное обеспечение для различных продуктов и использовать вариативность для настройки программного обеспечения для каждого мобильного телефона.

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

Использование линейки продуктов дало Nokia возможность увеличить производство новых моделей мобильных телефонов с 5-10 примерно до 30. ^[3]

См. также

Ссылки

^ https://escholarship.org/uc/item/5687j6g6 Создание программного обеспечения с использованием компонентов, дата обращения 9 января 2021 г.
^ Клементс П. и Нортроп Л.М. (2003). Линии программных продуктов. Презентация Института программной инженерии Карнеги-Меллона. Получено 26 марта 2006 г. с сайта: http://www.sei.cmu.edu/.
^ Институт программной инженерии Карнеги-Меллона (SEI). Линии программных продуктов. Получено 17 февраля 2006 г. по адресу: https://web.archive.org/web/20171005173029/http://www.sei.cmu.edu/productlines/ .

Ян Бош , Проектирование и использование архитектур программного обеспечения: принятие и развитие подхода к линейке продуктов, ACM Press/Addison-Wesley Publishing Co., Нью-Йорк, Нью-Йорк, 2000 г. ISBN 978-0201674941 https://www.amazon.com/Design-Use-Software-Architectures-Bosch/dp/0201674947
Европейский институт программного обеспечения (ESI). Получено 17 февраля 2006 г. по адресу: https://web.archive.org/web/20070203151901/http://www.esi.es/Families/famResults.html .
Пол К., Бокл Г. и Линден Ф. ван дер (2005). Разработка линейки программных продуктов. Берлин, Гейдельберг, Нью-Йорк: Springer Verlag. ISBN 978-3-540-28901-2 https://www.amazon.com/Software-Product-Line-Engineering-Foundations-dp-3540243720/dp/3540243720

Внешние ссылки

[1] ttps://escholarship.org/uc/item/5687j6g6 Создание программного обеспечения с использованием компонентов, дата обращения 9 января 2021 г.

[2] Клементс П. и Нортроп Л.М. (2003). Линии программных продуктов. Презентация Института программной инженерии Карнеги-Меллона. Получено 26 марта 2006 г. с сайта: http://www.sei.cmu.edu/.

[3] Институт программной инженерии Карнеги-Меллона (SEI). Линии программных продуктов. Получено 17 февраля 2006 г. по адресу: https://web.archive.org/web/20171005173029/http://www.sei.cmu.edu/productlines/ .

[1]

[2]

[3]