======= Software product lines adoption: an industrial case study =======

Jonatas Ferreira Bastos, Paulo Anselmo da Mota Silveira Neto, Eduardo Santana de Almeida, Silvio Romero de Lemos Meira. 2015. Software product lines adoption: an industrial case study (keynote). http://dl.acm.org/citation.cfm?id=2819317&CFID=708679712&CFTOKEN=13620638

===== Основная часть =====

В данной статье рассказывается о внедрении подхода Software Product Lines в контексте малого и среднего бизнеса. Исследование было спроектировано на основе руководящих принципов, которые предписывают выполнение пяти основных этапов процесса: проектирование, сбор данных, сбор доказательств, анализ собранных данных и отчетность, с учетом следующих перспектив: стратегии внедрения, организационные структуры, барьеры при внедрении и уровень развития организации. Наличие эмпирической базы является преимуществом данного исследования по сравнению с предыдущими попытками описания внедрения SPL.
Экспериментальный контекст состоит из трех элементов:
  * справочная информация о промышленных условиях, в котором эмпирическое исследование имеет место быть или в котором была спроектирована новая техника разработки ПО;
  * обсуждение гипотез исследования и того, как они были получены;
  * информация о проведении связанных с данным исследований.
Внедрение SPL изучается на примере организации MedicWare Systems, которая занимается разработкой ПО в сфере медицинского обслуживания.
На момент исследования организация предлагала в качестве товара четыре продукта:
  * SmartHealth - управляет всем больничным комплексом, от финансовых аспектов до пациентов;
  * SmartClin - выполняет управление клиникой, поддерживая деятельность, связанную с медицинским обучением, диагностикой и так далее.
  * SmartLab - интегрирует набор функций для управления лабораторными обследованиями и клинической патологией. 
  * SmartDoctor - веб-продукт, отвечающий за управление офисными задачами врача.
До начала внедрения SPL компания разрабатывала свои продукты независимо друг от друга, большинство из них с нуля, применяя некоторую форму подхода ad-hoc reuse.
Связь между организацией и потребителями происходит двумя способами: через бизнес-аналитика и веб-систему, собирающую запросы потребителей.

{{:mdd:схема_1.png?500|}}

Организация начала внедрения SPL в сотрудничестве с RiSE (Reuse in Software Engineering). RiSE Labs был разработан новый подход для создания линеек программных продуктов, называемый RiPLE (Reuse in Product Line Engineering), состоящий из определения области видимости, требований, управления рисками и т.д. Был предложен план внедрения, включавший в себя:
  * характеристику текущего состояния,
  * характеристику желаемого состояния,
  * стратегию и шаги для перехода от текущего состояния к желаемому.
Три вида RiPLE было применено в проекте MedicWare Systems:
  * RiPLE-SC: гибкий и систематический процесс определения области видимости, отвечает за определение потенциала SPL. 
  * RiPLE-RE: состоит из требований к инженерно-техническим мероприятиям, связанным с уточнением области видимости SPL, определение требований и прецедентов с проблемами изменчивости. 
  * RiPLE-РМ: отвечает за выявление рисков, документацию, анализ и мониторинг рисков, выявленных при выполнении.
При сборе данных были использованы несколько источников информации во избежание односторонней интерпретации. К тому же были использованы несколько методов сбора информации. Все данные обрабатывались конфиденциально. Среди техник сбора выделяются наблюдения (прямые и косвенные) и интервью.
После сбора данных необходимо проводить их качественный анализ. Для этого в ходе исследования соблюдались следующие принципы:
  * использование нескольких источников свидетельств;
  * создание базы данных тематических исследований;
  * поддержание цепочки свидетельств.
Проверка валидность проводилась в соответствии со следующими критериями:
  * Конструктивная валидность (использует следующие три стратегии: продолжительное участие, триангуляция, коллегиальное подведение итогов)
  * Внутренняя валидность
  * Внешняя валидность
  * Надежность
Таблицы ниже показывают некоторые количественные данные проекта

^ Период ^ Утвержденный план мероприятий ^
| январь 2010 - март 2010 | Создание целей/характеристик/текущего состояния/оценки MedicWare |
| апрель 2010 | Желаемая характеристика состояния/выбор стратегии перехода |
| май 2010 - январь 2011 | Выполнение плана |

^ Период ^ Вид RiPLE ^ Данные ^
| январь 2010 - май 2010 | RiPLE-SC | 831 час, 840 выявленных особенностей |
| январь 2010 - январь 2011 | RiPLE-RM | 228 часов, 43 выявленных риска |
| июнь 2010 - январь 2011 | RiPLE-RE | 478 часов, 78 выявленных особенностей, 130 требований, 289 вариантов использования |

===== Заключение =====

В ходе исследования особое внимание было направлено на выявление эффективности стратегии в контексте SME, а также определить наиболее важные организационные аспекты, чтобы лучше поддерживать этот переход. Стратегия позволила организации поддерживать свое планирование для обеспечения непрерывного "развития и поддержки продуктов при разработке продуктовой линейки".
Организации могут столкнутся со множеством барьеров:
  * Начальная стоимость. Для преодоления этого барьера нужны следующие факторы: пошаговая стратегия перехода, которая поддерживает низкую начальную стоимость, и партнерство между организацией и RiSE Labs
  * Необходимость перемен. Для минимизации этого явления была принята структура, схожая с уже использующейся в организациях, делающих постепенные изменения 
  * Отсутствие видения продуктовой линейки. Выполнение RiPLESC смоделировало видение организации и позволило найти новые возможности.
  * Недостаток документации. Для того чтобы преодолеть этот барьер, план документации был реализован в сочетании с подходом. Таким образом, используя процесс RiPLE, была определена вся документация на продукцию
  * Отсутствие процесса развития. 
Следующие вопросы связаны с передачей технологии:
  * План принятия (этот этап длился дольше, чем ожидалось)
  * Семинары и тренинги (не применялись в организации в целом)
  * RiPLE
Существуют некоторые угрозы валидности исследования:
  * Вопросы интервью: набор вопросов мог не полностью покрывать все аспекты SPL
  * Наблюдение: проводились путем наблюдения некоторых ключевых сотрудников, однако, самые важные люди могли быть не выбраны
  * Надежность: этот аспект касается того, в какой мере данные и анализ зависят от конкретных исследователей. Гипотетически, если другой исследователь позже проведет то же самое исследование, результат должны быть таким же
Сообщество инженерии программного обеспечения заявляет, что SPL может быть пригодным для крупных организаций, а не небольших организаций. Однако, основываясь на полученных результатах, можно считать, что SPL подход подходит также и малым и средним организациям.

 --- //[[lebedeva@phystech.edu|Valentine Lebedeva]] 2016/12/25 07:44//