Как соотносятся требования, ограничения, концепция и архитектура системы? Вот в искусстве есть такое понятие "бумажная архитектура". Это такие проекты, которые не могут быть осуществлены практически из-за своей технической сложности, стоимости масштабности, цензурных соображений и так далее. Но мы, в данном случае, говорим о проектах которые, должны быть осуществимы и нам надо быть уверенным, что те идеи, которые мы закладываем в концепцию, могут быть практически реализованы на практике. Поэтому на практике концепция не только определяет архитектуру, но и основывается на ней. По факту концепция архитектура системы часто разрабатывается совместно, в рамках единого процесса. Но концепция является в большей степени внешним документом, ориентированным на представлении идеи проекта и согласованию с заказчиком. Тогда как архитектура становится основой для последующего проектирования системы. Итак, подведем итоги. Требования и ограничения определяют как должна выглядеть система "из внешнего мира ". Как ее должны будут видеть пользователи, другие устройства, другие системы с ней взаимодействующие. Аналитик или инженер по требованиям фактически выстраивает из совокупности требований и ограничений некий внешний контур или набор проекции, по которому можно судить о внешнем виде системы. И если вы архитектор проекта, то вашей задачей станет, в свою очередь, как бы реконструировать внешний вид системы по этим ее частичным проекциям или контурам. Точно так же реконструируют внешний вид и образ жизни давно исчезнувших животных по их следам или реконструируют внешность человека по слепку его черепа. По этой аналогии, чем полнее описаны требования, ограничения - тем более четко детализированы будут контуры будущей системы. Однако, облик системы необязательно является лишь зеркальной копией контура. Архитектор может предложить любую форму, которая будет соответствовать контуру, заданному требованию, ограничению. Кроме того, предлагая облик и поведение системы, архитектор должен понимать, каким образом он может быть физически реализован. А для этого надо представлять, хотя бы в принципе, как будет устроена система внутри, причем на это тоже могут быть какие-то свои ограничения. Таким образом, концепция проекта как документ, являющаяся результатом работы архитектора, полностью основывается на документе требования, ограничения, который является результатом работы аналитика. Требования, ограничения описывают те рамки, в которые должна быть как бы встроена система. Концепция формально демонстрирует ее внешнюю форму и поведение внутри этих рамок, как некий "черный ящик". А вот архитектура делает объект прозрачным, показывает принцип его внутреннего устройства. Соответственно, утвержденная архитектура становится основанием для разработки спецификации. В практике разработки программного обеспечения концепция является обобщением требований. А поведение системы описываются через варианты или сценарии использования. И снова стоит заметить, что в разных практиках эти документы могут иметь разные названия. Так, в качестве эквивалента документа, описывающего архитектуру, часто выступают такие документы как концепт, [inaudible] дизайн и так далее. Большая путаница постоянно возникает по поводу технического задания. Часто так называют документ, в котором заказчик описывает то, что он хочет увидеть в результате, то есть, как раз концепцию и иногда и архитектуру. Но в других случаях -и это некий совместный документ о том, что нужно сделать, разрабатываемый совместно с заказчиком командой проекта. Очень часто техническое задание считают результатом работы аналитика и она выступает как некий эквивалент "Требований и ограничений". Еще больше запутывает ситуацию, то, что техническое задание выступает как документ, фиксирующий обязательства разработчика проекта перед заказчиком и именно в этом качестве он фигурирует в государственных стандартах. Так, тридцать четвертый ГОСТ определяет, что: "Техническое задание на автоматизированную систему, а к таким системам можно отнести и приложение интернета вещей, является основным документом, определяющим требования и порядок создания автоматизированной системы". В соответствии с ним проводится как разработка автоматизированной системы, так и ее приемка при вводе в действие. Получается, что то техническое задание содержит не только требования к системе, но и требования к порядку ее создания, приемки, а значит не может быть разработано без согласования требований, ограничений, концепции, архитектуры, а часто и спецификаций и даже плана выполнения работ. Это часто вызывает вопросы, поэтому в специфике разработки технического задания по ГОСТУ, как и вообще в практике использования современных методологий разработки в условиях, когда заказчик настаивает на разработке по ГОСТУ, будет посвящен отдельный раздел. Резюмируем. Выше мы обсуждали структуру деятельности как последовательности следующих шагов: потребность, мотив, цель, средства, действия, результат. Здесь концепция будет соответствовать заявлению цели, то есть представлению о том ожидаемом результате, ради которого совершается деятельность. А архитектура будет давать представление о средствах, которые и понадобятся в ходе деятельности для достижения этой цели.
