Концепция использования (а раньше – сделанные на её основе требования, от разработки которых отказались) прежде всего содержит информацию о функциях системы по отношению к её рабочему/целевому/операционному/функциональному окружению, поэтому она состоит из самых разных моделей, которые описывают поведение системы на её границе во взаимодействии с системами снаружи (системами в составе надсистемы). Наиболее подробные модели поведения называют сценариями использования. В некоторых школах системной инженерии сценарии использования считают отдельными от концепции использования (ибо они разрабатываются позже сжатых описаний функциональности системы в концепции использования), в некоторых – входящими в концепцию использования, просто сама концепция использования потихоньку меняется в ходе проекта: она конкретизируется, уточняется, детализируется, в неё входит всё больше всё более детальных сценариев использования по мере развития системы. Мы принимаем второй подход: сценарии использования входят в состав концепции использования, это один из видов моделей, которые в неё входят. Подробней об этом – в курсе «Системная инженерия» и предлагаемой курсом литературе.
Когда говорим о концепции использования как об описании «чёрного ящика», то говорим именно про описание времени эксплуатации в части получения необходимой функции от системы. Система должна бы при эксплуатации в части её поведения или осмысленно мигать лампочками, или давать какой-то результат вычисления, или нагреваться, или оставлять бороздку правильных размеров: всё, что предполагается, что будет делать система (гипотезы!), чтобы в момент её эксплуатации говорили, что она делает то, что от неё ожидают и не делала того, что от неё не ожидают, то есть описывается ожидаемое поведение успешной системы. Ожидаемое поведение системы – это предсказание того, что должно бы произойти при эксплуатации. В случае требований раньше говорили поэтому о функциональных требованиях (деонтика), а сейчас это просто гипотезы о функциональности (докса), поэтому нет «должна», только «должна бы» (а жизнь потом покажет, оправдалась ли гипотеза).
«Нефункциональных требований» не было, хотя такой термин часто встречался в литературе, но обычно разъясняли, что его использовать неправильно. Чаще говорили просто о других видах требований – например, требованиях качества (-ости/-ilities, типа доступность, ремонтопригодность, надёжность), которые интересны не только разработчику, но и другим ролям в проекте, прежде всего роли архитектора. Сейчас стало очевидно, что архитектура имеет дело с архитектурными характеристиками (прежде всего эти -ости), но они относятся к системе не в части выполнения своих прикладных функций, а к общему какому-то поведению и в момент работы/operations (например, характеристики надёжности работы) или даже на момент создания и развития (например, характеристики возможности лёгкого изменения в ходе непрерывных улучшений, evolvability). И эти характеристики хотя и разные, но всё-таки более-менее одинаковые у самых разных видов систем. Например, масштабируемость/scalability: насколько легко поднять производительность системы, если это надо – нужно будет только добавить какие-то дополнительные модули (скажем, добавлять ещё пару колёс на каждую новую тонну грузоподъёмности тележки, или придётся всё разрабатывать по-новой с самого начала – ибо для увеличения грузоподъёмности менять надо в тележке и раму, и колёса, и вообще всё?). Архитектурные характеристики – описание поведения системы при работе в необычных условиях или не в момент эксплуатации: способность работать под высокой нагрузкой, ремонтопригодность, доступность по цене/affordability (помним, что совокупная стоимость владения затрагивает и стоимость расходников и обслуживания при эксплуатации, но ещё и стоимость изготовления включает не только стоимость материалов, но и стоимость работ системы создания, то есть затрагивает описание ещё и систем не из окружения, а из цепочки систем, создающих целевую систему), лёгкость монтажа. Курс «Системная инженерия» подробно разбирает работу архитектора, архитектурные характеристики, способы достижения приемлемых значений для метрик, которыми измеряют архитектурные характеристики.
Конечно, во многих и многих моделях пересекаются и концепция использования (что делает система на её внешней границе, чтобы вписаться в окружающие её системы в момент её работы, принося какую-то пользу этому миру), и архитектурные характеристики (надёжность, лёгкость изменений системы разработчиками, устойчивость к разрушению, и прочие характеристики, непосредственно не связанные с функциями системы), и концепция системы как описание внутреннего устройства системы, «прозрачного ящика». Как концепция использования при детализации превращается в набор сценариев использования, так концепция системы при детализации превращается в проект/design системы, который уточняется вплоть до описаний прозрачного ящика, достаточно детальных для изготовления системы.
Если говорить о таком же наборе описаний, но на уровне надсистемы (скажем, описывать не концепцию использования шестерёнки в механических часах, а концепцию часов с шестерёнкой в их составе как концепцию системы), то можно обнаружить, что концепция использования шестерёнки по факту – часть концепции часов, ибо в устройстве часов важна шестерёнка и что она делает безотносительно устройства самой шестерёнки.
Конечно, терминология для всех этих описаний чёрного и прозрачного ящика может меняться, особенно если смотреть не на описания, а на документы, выражающие эти описания: легко концепцию использования насоса, описывающую поведение насоса, назвать «опросным листом», рассылаемым поставщикам насосов с вопросом «можете ли вы изготовить насос с вот такими характеристиками?» В «опросном листе» не будет ни слов «концепция использования», ни более древнего слова «требования». Если и будут какие-то указания на то, что именно должно бы быть в составе насоса, то не будет и слов «концепция системы». Архитектурные характеристики (типа надёжности) будут или не будут указаны, название документа будет «опросный лист». Вы должны уметь поглядеть на такой «опросный лист» – и определить тип описания: «опросный лист»::«концепция использования» насоса (а если там есть архитектурные характеристики, то отметить и их тоже).
Почему нужно выделять отдельно описание чёрного ящика как концепцию использования (что делает система вовне, от границы системы в окружение), а не сразу рассказывать про концепцию системы – как она устроена внутри себя (какие подсистемы выполняют какие функции и из чего они сделаны)? Различение чёрного и прозрачного ящиков нужно, чтобы иметь возможность предложить самые разные варианты того, как устроена система, из чего она сделана – предложить разные аффордансы для выполнения функции системы.
Скажем, концепция использования дверного ключа будет описывать, что ключ переводит дверь из состояния «заперта» в «отперта» и обратно. Это будет главное, функция ключа. Архитектурные характеристики (срок службы до первой поломки, ремонтопригодность и т.д.) тут не так важны, важно для чего нужен ключ, какие изменения (поведение – это изменения, «в один момент времени было одно состояние, в другой момент времени стало другое состояние») вызывает система в своём окружении. Тут важно, не какие изменения вызывает окружение в системе, а какие изменения вызывает система в окружении. Подробней об этом будет говориться в курсе «Системная инженерия», рассказ о действиях системы на окружение – в том числе реагировании на воздействия извне, а не о действиях окружения на систему.
Если вы подробно описали ключ и его функциональность как «чёрный ящик», дальше вы можете предлагать разные конструкции ключа, которые оказываются неразделимыми с конструкцией замка. То есть вы 1. Понимаете, что ошиблись и меняете рассмотрение ключа::система на замок::система, в который входит ключ::подсистема, а уже замок::система входит в дверь::надсистема. Рассматриваете варианты механического замка с поворотным ключом, механического замка с нажимным ключом, электрического замка с программируемым электронным ключом-«таблеткой», электрического замка с управлением через приложение в смартфоне, электрического замка с управлением через биометрию (отпечаток пальца или распознавание лица), и так далее: вариантов много, можно выбирать.
Главное – это соблюсти функцию замка (ибо оказывается, это делает не ключ, а замок) в его окружении: перевод двери из состояния «заперта» в состояние «отпёрта» и обратно. А дальше рассматриваем и ключ тоже, только там будет перевод замка из состояния «заперт» в состояние «отпёрт» и обратно. И вот тут возможны варианты: например, перевод замка в состояние «заперт» может быть сделан ключом, а может быть сделан захлопыванием двери. В замке может быть переключатель режима захлопывания двери и запирания ключом, но и ключ может быть хитрым – этот переключатель может быть в ключе, если ключом служит приложение в смартфоне! Всегда рассматриваем вначале функцию::поведение системы в мире, потом выявляем аффорданс для этой функции (и тут возможны варианты, и легко можно обнаружить смену целевой системы, как в примере с ключом: оказывается, надо было рассматривать замок как целевую систему, а ключ как подсистему). По возможности откладываем рассмотрение того, как устроена система как роль/«функциональный объект», ибо если непонятно, что система должна была бы делать (непонятная функция системы) – бесполезно обсуждать устройство системы, которая будет выполнять эту функцию.
Концепция использования – это набор моделей системы, модели абстрактны и не явлены никак в физическом мире. Чтобы на них посмотреть, или кому-нибудь переслать, нужно иметь их на носителе (неважно, бумажном, электронном или оптическом), то есть иметь документацию концепции использования (а если вы находитесь в предприятии, где придерживаются идей уже устарелой системной инженерии, то вам потребуется ещё и для концепции использования разработать требования и документировать уже требования). Документация концепции использования может найтись (или быть подготовлена) в самом разном виде: документы стандартов, технические задания, файлы с диаграммами сценариев использования на каких-то языках, фрагменты базы данных с информационной моделью. Если во всех этих документах содержится описание поведения целевой системы как «чёрного ящика» в окружении в момент эксплуатации, то это и будет концепция использования. И если вы при этом слышите слово «требования», то первым делом интересуйтесь насколько это гипотезы, а насколько и впрямь «очень надо именно так, можем обосновать», интересуйтесь сценариями (поведением), и проверяйте, чего в требованиях может не хватать или быть искажено, если их готовили «аналитики». Бойтесь «испорченного телефона», поинтересуйтесь ситуацией использования системы в ходе её работы, поймите сценарии/поведение, не принимайте «требования» слепо на веру – помним, что это просто «гипотеза, которую утвердили и назвали требованием, а потом гипотеза может оказаться неверна – и что будем делать?». Не верьте, если вас будут заверять, что «это требования, выполните их, и всё у вас будет хорошо». Это рассуждения из старой системной инженерии, старого системного подхода.
Конец ознакомительного фрагмента.
Текст предоставлен ООО «Литрес».
Прочитайте эту книгу целиком, купив полную легальную версию (https://www.litres.ru/pages/biblio_book/?art=70915633&lfrom=174836202&ffile=1) на Литрес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.
notes
Примечания
1
https://classifikators.ru/ (https://classifikators.ru/)
2
https://www.pnas.org/doi/10.1073/pnas.1807890115 (https://www.pnas.org/doi/10.1073/pnas.1807890115)
3
https://en.wikipedia.org/wiki/Open-world_assumption (https://en.wikipedia.org/wiki/Open-world_assumption)
4
http://en.wikipedia.org/wiki/Holon_%28philosophy%29 (http://en.wikipedia.org/wiki/Holon_%28philosophy%29)
5
https://en.wikipedia.org/wiki/Rendering_(computer_graphics) (https://en.wikipedia.org/wiki/Rendering_(computer_graphics))
6
https://www.pnas.org/doi/10.1073/pnas.1807890115 (https://www.pnas.org/doi/10.1073/pnas.1807890115)
7
https://en.wikipedia.org/wiki/Meme (https://en.wikipedia.org/wiki/Meme)
8
https://en.wikipedia.org/wiki/Connectionism (https://en.wikipedia.org/wiki/Connectionism)
9
https://www.frontiersin.org/articles/10.3389/frobt.2019.00153/full (https://www.frontiersin.org/articles/10.3389/frobt.2019.00153/full)
10
https://en.wikipedia.org/wiki/Geometrical_frustration (https://en.wikipedia.org/wiki/Geometrical_frustration) – и посмотрите на видео, которое очень хорошо объясняет суть этой «неустроенности/неустаканенности».
11
https://www.pnas.org/doi/10.1073/pnas.1807890115 (https://www.pnas.org/doi/10.1073/pnas.1807890115)
12
https://ru.wikipedia.org/wiki/Эргодичность (https://ru.wikipedia.org/wiki/%D0%AD%D1%80%D0%B3%D0%BE%D0%B4%D0%B8%D1%87%D0%BD%D0%BE%D1%81%D1%82%D1%8C)
13
https://ru.wikipedia.org/wiki/Экологическая_ниша (https://ru.wikipedia.org/wiki/%D0%AD%D0%BA%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B0%D1%8F_%D0%BD%D0%B8%D1%88%D0%B0)
14
https://en.wikipedia.org/wiki/Geometrical_frustration (https://en.wikipedia.org/wiki/Geometrical_frustration) – и посмотрите на видео, которое очень хорошо объясняет суть этой «неустроенности/неустаканенности».
15
https://www.pnas.org/doi/10.1073/pnas.1807890115 (https://www.pnas.org/doi/10.1073/pnas.1807890115)
16
https://www.pnas.org/doi/full/10.1073/pnas.2120042119 (https://www.pnas.org/doi/full/10.1073/pnas.2120042119)
17
https://www.pnas.org/doi/10.1073/pnas.2120037119 (https://www.pnas.org/doi/10.1073/pnas.2120037119)
18
https://ru.wikipedia.org/wiki/Эргодичность (https://ru.wikipedia.org/wiki/%D0%AD%D1%80%D0%B3%D0%BE%D0%B4%D0%B8%D1%87%D0%BD%D0%BE%D1%81%D1%82%D1%8C)
19
https://ailev.livejournal.com/1622346.html (https://ailev.livejournal.com/1622346.html)
20
