Системное мышление 2024. Том 2. Анатолий Левенчук

Чтение книги онлайн.

СКАЧАТЬ использования (ибо они разрабатываются позже сжатых описаний функциональности системы в концепции использования), в некоторых – входящими в концепцию использования, просто сама концепция использования потихоньку меняется в ходе проекта: она конкретизируется, уточняется, детализируется, в неё входит всё больше всё более детальных сценариев использования по мере развития системы. Мы принимаем второй подход: сценарии использования входят в состав концепции использования, это один из видов моделей, которые в неё входят. Подробней об этом – в курсе «Системная инженерия» и предлагаемой курсом литературе.

      Когда говорим о концепции использования как об описании «чёрного ящика», то говорим именно про описание времени эксплуатации в части получения необходимой функции от системы. Система должна бы при эксплуатации в части её поведения или осмысленно мигать лампочками, или давать какой-то результат вычисления, или нагреваться, или оставлять бороздку правильных размеров: всё, что предполагается, что будет делать система (гипотезы!), чтобы в момент её эксплуатации говорили, что она делает то, что от неё ожидают и не делала того, что от неё не ожидают, то есть описывается ожидаемое поведение успешной системы. Ожидаемое поведение системы – это предсказание того, что должно бы произойти при эксплуатации. В случае требований раньше говорили поэтому о функциональных требованиях (деонтика), а сейчас это просто гипотезы о функциональности (докса), поэтому нет «должна», только «должна бы» (а жизнь потом покажет, оправдалась ли гипотеза).

      «Нефункциональных требований» не было, хотя такой термин часто встречался в литературе, но обычно разъясняли, что его использовать неправильно. Чаще говорили просто о других видах требований – например, требованиях качества (-ости/-ilities, типа доступность, ремонтопригодность, надёжность), которые интересны не только разработчику, но и другим ролям в проекте, прежде всего роли архитектора. Сейчас стало очевидно, что архитектура имеет дело с архитектурными характеристиками (прежде всего эти -ости), но они относятся к системе не в части выполнения своих прикладных функций, а к общему какому-то поведению и в момент работы/operations (например, характеристики надёжности работы) или даже на момент создания и развития (например, характеристики возможности лёгкого изменения в ходе непрерывных улучшений, evolvability). И эти характеристики хотя и разные, но всё-таки более-менее одинаковые у самых разных видов систем. Например, масштабируемость/scalability: насколько легко поднять производительность системы, если это надо – нужно будет только добавить какие-то дополнительные модули (скажем, добавлять ещё пару колёс на каждую новую тонну грузоподъёмности тележки, или придётся всё разрабатывать по-новой с самого начала – ибо для увеличения грузоподъёмности менять надо в тележке и раму, и колёса, и вообще всё?). Архитектурные характеристики – описание поведения СКАЧАТЬ