Вариативность: платформы и фичи.

Nov 12, 2012 21:50

Состав практик моделеориентированной системной инженерии должен учитывать, что инженерия отдельных систем происходит очень и очень редко, требования повторного использования накопленных знаний (reuse) приводят по факту к разработкам семейств систем, продуктных линеек, технологических платформ (http://ailev.livejournal.com/626229.html и там далее по ссылкам подробности и обоснования. С тех пор ещё много разного появилось -- http://www.esi.es/Families/famResults.html, и краткие справочки http://en.wikipedia.org/wiki/Product_family_engineering и http://en.wikipedia.org/wiki/Domain_engineering). Как всегда, основные идеи идут от software product lines, огрубляясь и упрощаясь для общего случая киберфизической системы.

Это означает, что практики моделеориентированной системной инженерии не просто включают в себя порождающее моделирование в целом (http://ailev.livejournal.com/728605.html) и накопление справочных данных в практике , но и расщепление жизненного цикла системы на три разных жизненных цикла её воплощения (realization), имеющих разные объекты и находящиеся в мета-отношении (отношении порождения) друг ко другу:
-- отрасль/предметная область (domain, и тут нужно понимать, что иногда это отождествляется с платформой http://en.wikipedia.org/wiki/Domain_engineering в рамках DDD, но в общем случае для одного domain имеются альтернативные платформы, хотя они обычно совместимы между собой через нейтральные стандарты)
-- платформа (общее техническое решение для линейки продуктов/семейства продуктов, обычно в рамках одного предпринятия или даже эко-системы: наследуемые системой-индивидом технические решения с общей архитектурой и набором интерфейсов, то общее знание, из которого потом делаются отдельные продукты путём добавки разных наборов фич/features -- это термин)
-- конкретная система (индивид, продукт -- и оставим онтологам разбираться с тем фактом, что речь идёт о "строчке каталога", а не об индивидуальной системе с серийным номером. Но и это может быть не так в эпоху mass customization).

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

Моделеориентированность (то есть использование моделей, по которым происходит автоматическое порождение следующих каких-то артефактов -- например, генерация моделей продукта по моделям платформы и профилю фич) проникла и сюда, что один из поставщиков соответствующего софта даже назвал "вторым поколением подхода продуктных линий" (http://www.biglever.com/learn/newsletters.html) примерно так же, как Dassault Systems пыталась поднять на щит PLM 2.0. Мы помним, что из этого вышло с PLM: это стало таким же общим местом, как и использование САПР или базы данных, и особая реклама этого подхода выглядит такой же нелепой, как реклама использования баз данных. "Все говорят прозой, ну и что? Забудьте это слово, оставьте его учёным".

Проблема reuse, которой сто лет в субботу, никак не изменяется от того, что её вдруг называют mass customization, или "созданием платформы", или семействами систем, или даже в полупроводниковой промышленности design for variability. Поэтому на конференциях по продуктным линиям появляются на семинаре по требованиям работы типа "Adopting feature-centric reuse of requirements assets: an industrial experience report" или "Automatic generation of feature models from UML requirement models", "Generating feature model from creative requirements using model driven design" (proceedings конфереции 2012г. -- http://dl.acm.org/citation.cfm?id=2364412&preflayout=flat, уж звиняйте, ежели кто не член ACM и не может прочесть). Никаких "семейств" или "линий" -- просто фичи бывают разными, но должен быть reuse всего (начиная от требований). Действительно, ни один идиот не собирает требования каждый раз "с нуля", обязательно кто-то ведь проделывал очень похожую работу для очень похожих продуктов, и можно безопасно передрать из этой работы довольно много всего. Ну, или специально разрабатывать требования так, чтобы помочь разработчикам будущих отдельных продуктов. Ничего особенного, "все делают это", каждый в меру своей извращённости.

Большинство PLM так или иначе поддерживают variant management (of modular product families) -- да, это опять про то же самое. Поставщики систем управления продуктными линиями -- нет проблем, вот примеры успехов только одного из них: http://www.biglever.com/learn/reports.html, а вот ещё: http://www.softwareproductlines.com/successes/successes.html

Итак, есть общее понимание:
-- продукты включают в себя разные наборы (профили) фич на базе общей платформы для всех продуктов,
-- модель должна быть не столько одного продукта, сколько платформы плюс фич (а некоторые договариваются, что и платформы нет -- это тоже фичи),
-- модель продукта генерируем по профилю фич (и уже предложен первый простейший стандарт CVL для этого: http://www.omgwiki.org/variability/doku.php, хотя есть и другие инициативы типа TVL -- http://www.info.fundp.ac.be/~acs/tvl/, поглядите на картинку того, как это устроено тут: http://www.cetic.be/IMG/pdf/CIEL12-Acher-tutorial.pdf).

С софтом (и даже софтом контроллеров аппаратуры -- http://www.phaedsys.com/pressreleases/pressreleasesdata/pure/purepresentation.pdf) это всё получается очень хорошо, с железом довольно плохо. Тем не менее, рынок моделей телефонов, планшетов, автомобилей, самолётов и т.д. показывает, что и с железом все уже давно "делают это": работают в терминах модульных платформ и наборов опциональных фич к ним. Реактивно (допиливая напильником проект каждого продукта для получения следующего продукта) или проактивно (предусматривая, что допиливать напильником придётся в разные стороны, и лучше бы это учесть сразу) -- это уже второй вопрос. Если вас прижмёт, то вы просто не сможете быстро сработать реактивно, при всей "экономичности" этого подхода. Опять же, если прижмёт, то денег и времени не хватит работать чисто проактивно: жизнь в плане изменения требований к профилям фич оказывается много богаче фантазии. Вот все и крутятся.

И другой моделеориентированной системной инженерии, похоже, уже нет. "Целевая система" сегодня -- это часто даже не строчка каталога, за которой скрываются одинаковые железки с разными серийными номерами. "Целевая система" -- это сам каталог, в котором можно набрать себе самых разных опций. А уж сколько после этого выбора опций будет сделано допроектирования, сколько уйдёт в пересчёт моделей с чуть изменившимися параметрами, а сколько не потребует никаких расчётов, а только решения логистической задачи сборки из не меняющихся модулей -- это уже зависит от решений системных инженеров каждого предприятия, общей практики тут пока нет. Общее только то, что одиночных изделий не бывает -- и поэтому управление конфигурацией должно быть многомерным (много продуктов, много стадий жизненного цикла, много базисов -- http://www.biglever.com/newsletters/2G_SPL_Part3.html).

Куда мы отнесём эти практики вариативности в общем наборе практик системной инженерии (http://ailev.livejournal.com/1026262.html)? Вестимо, к практикам управления конфигурацией. Это PLM в чистом виде, variant management. Ну, а дальше управление конфигурацией предъявляет свои требования к системам моделирования, и каждая практика (работа с user needs и составление профилей фич -- не забываем, что никаких ТЗ не будет с учётом развития продуктовой линии и эволюции платформы, как заметил Отставнов в http://ailev.livejournal.com/625474.html -- в софтостроении давно уже идут только багрепорты и фичереквесты как основная практика; высокоуровневое моделирование с учётом множества вариантов; низкоуровневое моделирование для отдельных конкретных продуктов; и т.д.) учитывают вариативность просто по принципу их построения.
Previous post Next post
Up
[]