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