Порядок контроля и приемки системы
В данном разделе указывают: виды, состав, объем и методы испытаний системы и ее составных частей (виды испытаний в соответствии с действующими нормами, распространяющимися на разрабатываемую систему); общие требования к приемке работ по стадиям (перечень участвующих предприятий и организаций, место и сроки проведения), порядок согласования и утверждения приемочной документации; ЗУ статус приемочной комиссии (государственная, межведомственная, ведомственная).
Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
В данном разделе необходимо привести перечень основных мероприятий и их исполнителей, которые Следует выполнить при подготовке объекта автоматизации к вводу АС в действие.
В перечень основных мероприятий включают: приведение поступающей в систему информации (в соответствии с' требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ; изменения, которые необходимо осуществить в объекте автоматизации; создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ; создание необходимых для функционирования системы подразделений и служб; сроки и порядок комплектования штатов и обучения персонала.
Например, для АСУ приводят: изменения применяемых методов управления; создание условий для работы компонентов АСУ, при которых гарантируется соответствие системы требованиям, содержащимся в ТЗ.
Требования к документированию
В данном разделе приводят: согласованный разработчиком и Заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201 и НТД отрасли заказчика; перечень документов, выпускаемых на машинных носителях; требования к микрофильмированию документации; требования по документированию комплектующих элементов межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД; при отсутствии государственных стандартов, определяющих требования к документированию элементов системы, дополнительно включают требования к составу и содержанию таких документов.
Источники разработки
В данном разделе должны быть перечислены документы и информационные материалы (технико-экономическое обоснование, отчеты о законченных научно-исследовательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др.), на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы.
Архитектуры программных систем
Планирование архитектуры
Современные методы разработки программного обеспечения предполагают обратную связь между всеми действующими лицами, от проектировщика до аналитика. Все эти лица являются участниками процесса создания архитектуры программной системы. Под архитектурой системы будем понимать структуру компонентов программной системы, взаимосвязи, а также принципы и нормы их проектирования и развития во времени. Прежде чем начать изучение процесса планирования архитектуры, давайте познакомимся с понятием архитектурно-экономического цикла (АЭЦ).
Архитектурно-экономический цикл
Взаимоотношений между производственными задачами, требованиями к продукту, опытом архитектора, архитектурами и созданными системами образуют цикл с цепями обратной связи. Упомянутые цепи обратной связи изображены на рис. 5.1. Частично обратная связь поступает от самой архитектуры, частично – от построенной на ее основе системы.
Рисунок 4.1 – Архитектурно-экономический цикл (АЭЦ)
Цикл этот выглядит следующим образом.
1. Архитектура влияет на структуру компании-разработчика. Архитектура обусловливает структуру системы; в частности (в этом мы сможем убедиться), она устанавливает набор блоков программного обеспечения, которое надлежит реализовать (или обеспечить их наличие другим путем), а затем интегрировать в рамках системы. Эти блоки составляют основу разработки структуры проекта. Группы разработчиков укомплектовываются именно по блокам; операции в рамках процессов разработки, тестирования и интеграции также выполняются в отношении блоков. Согласно графикам и бюджетам, ресурсы выделяются частями в расчете на отдельные блоки. Если компания наработала опыт конструирования семейств сходных систем, она будет вкладывать средства в повышение профессионального уровня участников сформированных по блокам групп разработчиков. Следовательно, группы встраиваются в структуру организации. Такой представляется обратная связь от архитектуры к компании-разработчику.
2. Архитектура способна оказывать воздействие на задачи компании-разработчика. Сконструированная на ее основе успешная система предоставляет компании возможность укрепиться в данном сегменте рынка. Такая архитектура предусматривает дальнейшее эффективное производство и размещение сходных систем, вследствие чего компания может откорректировать свои задачи и, воспользовавшись новым преимуществом, занять рыночную нишу. Так выглядит обратная связь от системы к компании-разработчику и конструируемым ею системам.
3. Архитектура может оказывать воздействие на требования, выдвигаемые заказчиком относительно следующей системы, — ее (если она основана на той же архитектуре, что и предыдущая) он может получить в более надеж ном варианте, быстрее и экономичнее, чем в том случае, если бы она конструировалась «с чистого листа». Возможно, заказчик откажется от некоторых требований в пользу повышения экономичности. Готовые программные продукты несколько изменили требования, предъявляемые заказчиками, — не предназначенные для удовлетворения индивидуальных потребностей, они недороги и отличаются высоким качеством. На заказчиков, не слишком гибких по части своих требований, аналогичное воз действие оказывают линейки продуктов.
4. Процесс конструирования систем пополняет опыт архитектора, который он может применить при работе над последующими архитектурами, и, соответственно, расширяет базу опыта компании. Успех системы, построенной на основе инструментальных магистралей, .NET или инкапсулированных конечных автоматов, стимулирует построение аналогичных систем в дальнейшем. С другой стороны, неудачные варианты архитектуры редко используются повторно.
5. Иногда оказать сильное воздействие, и даже внести изменения в культуру программной инженерии (техническую базу, в рамках которой обучаются и работают конструкторы), способны отдельные системы. Такой эффект на индустрию в 1960-х и начале 1970-х годов оказали первые реляционные базы данных, генераторы компиляторов и табличные операционные системы; в 1980-х — первые электронные таблицы и системы управления окнами. В 1990-х годах в качестве такого рода катализатора выступила Всемирная паутина — с ней, между прочим, связан конкретный пример, приведенный в главе 13. В главе 16 мы предполагаем, что в первом десятилетии XXI века аналогичный эффект окажет J2EE. Подобные инновации всегда находят отражение в последующих системах.
Из этих и некоторых других механизмов обратной связи и образуется архитектурно-экономический цикл. На рисунке 11.1 изображены факторы влияния культуры и экономики компании-разработчика на программную архитектуру. В свою очередь архитектура оказывается основным определяющим фактором при задании свойств разрабатываемой системы или систем.