ТЗ на создание АС. Шаблон_Пояснительная записка к техническому проекту на создание. Пояснительная записка к техническому проекту на создание автоматизированной системы Корпоративное хранилище данных
 Скачать 179.55 Kb.
|
|
Пояснительная записка к техническому проекту на создание автоматизированной системы «Корпоративное хранилище данных» 1. Общие положения 1.1. Наименование системы 1.1.1. Полное наименование системы Полное наименование - Корпоративное хранилище данных. 1.1.2. Краткое наименование системы Краткое наименование - КХД, Система. 1.2. Основания для проведения работ Указывается номер и дата договора. Перечень документов, на основании которых создается система, кем и когда утверждены документы. Например: Работа выполняется на основании договора № … от … между … 1.3. Наименование организаций – Заказчика и Разработчика 1.3.1. Заказчик Заказчик: ОАО Заказчик Адрес фактический: г. Москва ... Телефон / Факс: +7 (495) 2222222 1.3.2. Разработчик Разработчик: ЗАО Разработчик Адрес фактический: г. Москва ... Телефон / Факс: +7 (495) 3333333 1.4 Цели, назначение и область использования системы Определяются цели (чего хочет достичь организация Заказчика от внедрения системы); назначение (для каких пользователей предназначена); области использования АИС (какие виды деятельности организации Заказчика охватывает система). Информация для разделов "Наименование системы", "Основания для проведения работ", "Наименование организаций – Заказчика и Разработчика", "Цели, назначение и область использования системы" берется из одноименных разделов технического задания на создание корпоративного хранилища данных. 1.5. Нормативные ссылки При техническом проектировании использовались следующие нормативно-технические документы: Например: 1. Техническое задание 2. Пояснительная записка к эскизному проекту 3. ГОСТ 34 -... 4. ... 1.6 Очередность создания системы Указывается очередность создания системы и характеристики каждой очереди (функциональность, ограничения, сроки, исполнители). Решение о составе и очередности предполагаемых работ принимается исходя из рабочего план-графика Проекта, лучших практик по ведению подобных проектов, специфики данного проекта. При этом очередность работ прорабатывается более детально чем на этапе эскизного проектирования (чем детальней проработан данный раздел, тем яснее представление о последовательности действий. В данном разделе приводится именно состав работ, без привязки к срокам и без определения зависимости между работами). Например: Ниже представлена предполагаемая очередность создания системы: - Производится разработка концептуальной, логической, физической модели хранилища данных. - Согласовываются регламенты взаимодействия с системами-источниками. - Проектируется структура таблиц. - Проектируются процессы сбора данных из систем-источников в область временного хранения данных. - Проектируются процессы преобразования данных. - Определяется состав дополнительных объектов (партиций, индексов, представлений, последовательностей и др.) к спроектированной физической модели области постоянного хранения данных. - Проектируются процессы загрузки данных в область постоянного хранения данных. - ... - Проектируются права на доступ к данным на уровне отчетности, объектов базы данных и записей в таблицах. - Производится настройка активного сетевого оборудования. - Производится настройка аппаратно-технической части. - Разрабатывается план установки серверного программного обеспечения. - Производится установка серверного программного обеспечения. - Реализуется структура таблиц и дополнительных объектов (партиций, индексов и др.) области временного хранения данных. - Реализуются процессы сбора данных в область временного хранения данных. - Реализуются дополнительные формы ввода данных предметными экспертами. - Реализуются процессы обработки данных. - ... - Реализуется политика разграничения прав доступа к данным на уровне отчетности, объектов базы данных и записей в таблицах. - Производится первоначальное наполнение базы данных тестовыми данными для проведения испытаний. - Производится настройка рабочих мест для проведения испытаний. - Производятся предварительные испытания. - Производится устранение ошибок, выявленных по результатам предварительных испытаний. - Производится опытная эксплуатация. - Производится устранение ошибок выявленных по результатам опытной эксплуатации. - Производятся приемочные испытания. - Производится устранение ошибок, выявленных по результатам приемочных испытаний. - Производится наполнение базы данных данными для ввода АИС в действие. - Проводится настройка рабочих мест пользователей. 2. Основные технические решения 2.1. Решения по структуре системы, подсистем, средствам и способам связи для информационного обмена между компонентами системы 2.1.1. Логическая и компонентная архитектура систем В данном разделе приводятся программные решения, разрабатываемые на детальном уровне (с привязкой к используемым языкам программирования), а также перечень, назначение и взаимосвязи готовых (закупаемых) и вновь разрабатываемых программных компонентов, их отображение на программные классы (какие компоненты реализуют какие классы). На основании аналогичного раздела пояснительной записки эскизного проекта приводится состав программных средств, которые будут использоваться при построении хранилища данных. Состав программных средств приводится более расширенный (указываются конкретные версии; возможно, по согласованию с Заказчиком конкретные версии не указывать) на основании знаний о том, какие компоненты входят в состав программных средств, приведенных в техническом задании, в пояснительной записке к эскизному проекту, и какие из этих компонентов будут использованы на Проекте, а также на основании знаний о том, какие дополнительные компоненты нужны для реализации системы. Например:
Далее приводится техническая архитектура с описанием технологических компонентов системы. За основу данной архитектуры берется техническая архитектура решения и ее описание, приведенная в аналогичном разделе пояснительной записки к эскизному проекту. Данная архитектура может быть уточнена на основании знаний о том, какие компоненты изменились или добавились в ходе проектирования. Например:  В состав разрабатываемой системы будут включены следующие технологические компоненты: - программное обеспечение поддержки модели данных представляет собой программное обеспечение, автоматизирующее разработку и поддержку модели ХД - ERwin; - ETL-приложение – это комплексное решение Informatica Power Center, с помощью которого реализуются процессы извлечения, проверки, преобразования и загрузки данных из источников. - сервер БД представляет собой промышленную систему управления базами данных (СУБД). На данном сервере хранятся НСИ, область временного и постоянного хранения данных, агрегаты данных. Реализована система разграничений прав доступа на уровне объектов и записей в таблицах. В качестве сервера БД будет использоваться Oracle DB EE 10g rel.2; - сервер приложений – продукт, обеспечивающий поддержку промышленной инфраструктуры бизнес-приложений. Включает в себя следующий ряд приложений обеспечивающих: - стандартные подходы к организации служб каталогов, централизованные методы организации; - развертывание сервисов разработки дополнительных приложений; - развертывание сервисов анализа и отчетности. - средства администрирования и разработки – набор программных продуктов, предназначенных для администрирования системы ETL (Administrator, Manager), баз данных, сервера приложений (Enterprise Manager) и разработки отчетности (Developer Suite). - клиентские места сотрудников (внутри локальной вычислительной сети), представляющие собой автоматизированные рабочие места. Рекомендации. Желательно в данном разделе указывать конкретные версии устанавливаемого ПО. Это позволит избежать смены версии ПО на более поздних этапах, но уменьшит возможность маневра в части версионности как для Разработчика, так и для Заказчика. 2.1.2. Функциональная структура системы В данном разделе формируется техническое решение по функциональной архитектуре хранилища данных. За основу принимается аналогичный раздел из пояснительной записки к эскизному проекту и при необходимости вносятся в него уточнения (например добавляется сетевой администратор и т.п.). В первую очередь в данном разделе формируется схема функциональной структуры КХД. За основу берется схема из пояснительной записки к эскизному проекту:  После чего проводится уточнение описания подсистем и взаимосвязей между подсистемами. За основу берется описание и взаимосвязи из аналогичного раздела пояснительной записки эскизного проекта. Рекомендация. Данные по оборудованию, на котором предполагается развертывание системы, желательно четко знать до начала проекта и прилагать максимум усилий, чтобы в ходе проекта Заказчик не изменял параметры данного оборудования. 2.2. Решения по взаимосвязям АС со смежными системами, обеспечению ее совместимости Приводятся уточненные эскизные решения по взаимосвязи КХД со смежными системами, обеспечению ее совместимости (описание используемых протоколов обмена данными, средств и методов обмена данными). Например: Приводится перечень смежных систем, способы взаимодействия.
Ниже представлена детальная схема взаимодействия системы КХД и смежных систем.  2.3. Решения по режимам функционирования, диагностированию работы системы В данном разделе приводятся уточненные решения по режимам функционирования, диагностированию работы системы на основании аналогичного раздела пояснительной записки к эскизному проекту. Приводится описание решений по диагностированию системы, осуществляемых путем установления и изучения признаков, которые характеризуют состояние системы для предсказания возможных отклонений и предотвращения нарушений нормального режима ее работы. Например: Предлагается следующая реализация решений по режимам функционирования системы: - Основной режим, в котором все подсистемы выполняют свои основные функции. - Профилактический режим, в котором одна или все подсистемы не выполняют своих функций. В данный режим работы система переходит в следующих случаях: возникновение необходимости модернизации аппаратно-программного комплекса; возникновение необходимости проведения технического обслуживания; выход из строя аппаратно-программного комплекса, вызванный выходом из строя элементов аппаратной или программной базы; выход из строя сети передачи данных и другие аварийные ситуации. В основном режиме функционирования система обеспечивает: - работу пользователей в режиме – 24 часа в день, 7 дней в неделю (24х7); - выполнение своих функций – сбор, обработка и загрузка данных; хранение данных, предоставление отчетности по показателям. В профилактическом режиме система обеспечивает возможность проведения следующих работ: - техническое обслуживание; - модернизация аппаратно-программного комплекса; - устранение аварийных ситуаций. Принимается предварительное решение о том, что общее время проведения профилактических работ не должно превышать X% от общего времени работы системы в основном режиме (XX часов в месяц). Принимается предварительное решение о том, что для обеспечения высокой надежности функционирования как системы в целом, так и ее отдельных компонентов необходимо проводить регулярное диагностирование состояния компонентов. В таблице ниже представлены средства диагностики по подсистемам.
Далее для каждой подсистемы приводятся примерные сценарии проведения их диагностирования. Чтобы описать сценарии диагностирования необходимо ответить на следующие вопросы: «Кем проводится диагностирование?», «Какое программное обеспечение используется?», «Какие действия необходимо провести для диагностирования (действия прописываются общие, например, зайти, открыть, проверить)?», «Что необходимо проверить? (например, наличие свободного места на дисках)», «Как часто необходимо выполнять данные действия?». Необходимо также указывать критичность подсистемы для функционирования системы в целом. Например: Подсистема сбора, обработки и загрузки данных: - администратор подсистемы должен каждый день контролировать работоспособность серверной части прикладного программного обеспечения сбора, обработки и загрузки данных, т.к. данная подсистема является критичной для работоспособности системы в целом; - администратор подсистемы перед началом загрузки данных должен проводить контроль объема свободного места на дисках для временных файлов; - администратор подсистемы должен каждый день проводить анализ протоколов работы подсистемы на наличие ошибок и предупреждений, возникающих при ее работе. 2.4. Решения по персоналу и режимам его работы В данном разделе приводятся уточненные решения по численности, квалификации и функциям персонала создаваемой системы, режимам работы персонала на основании аналогичного раздела пояснительной записки к эскизному проекту. Например: 4.1.2.1. Требования к численности персонала В составе персонала, необходимого для обеспечения эксплуатации КХД в рамках соответствующих подразделений Заказчика, необходимо выделение ответственных лиц на следующие роли.
Лица, которым назначены данные роли, должны выполнять следующие функциональные обязанности.
4.1.2.2. Требования к квалификации персонала К квалификации персонала эксплуатирующего Систему КХД, предъявляются следующие требования.
4.1.2.3. Требуемый режим работы персонала Персонал, работающий с Системой КХД и выполняющий функции её сопровождения и обслуживания, должен работать в следующих режимах:
2.5. Сведения об обеспечении заданных в техническом задании потребительских характеристик системы, определяющих ее качество Приводятся уточненные сведения об обеспечении заданных в техническом задании потребительских характеристик системы (подсистем), определяющих ее качество. Приводится таблица трассировки требований, заданных в техническом задании, и описанных проектных решений (достигается, нет, в какой степени, за счет чего?). Например:
Приводятся сведения об обеспечении заданных в техническом задании требований к функциям, выполняемым каждой подсистемой, определяющих ее качество. Например:
2.6. Состав функций, комплексов задач, реализуемых системой Приводится наименование и назначение функциональных комплексов задач системы (или по каждой подсистеме). Функциональные задачи по мере проработки проектных решений, описываются в виде сценариев. Описания сценариев могут быть вынесены в приложение к пояснительной записке. Процесс формирования сценариев выполнения задач функций каждой подсистемы производится следующим образом: приводится наименование подсистемы, далее приводится наименование функции подсистемы, внутри каждой функции перечисляются задачи, которые выполняются в её рамках (за основу принимается аналогичный раздел из пояснительной записки к эскизному проекту), для каждой задачи формируется таблица вида:
В данной таблице для каждой задачи приводится перечень подзадач и сценарий их выполнения. Перечень подзадач формируется следующим образом: берется наименование задачи и из названия задачи выделяются подзадачи, например задача «Поддержка (разработка, модификация) модели ХД» содержит в себе две подзадачи «Разработка» и «Модификация», задача «Создание, редактирование и удаление процессов сбора, обработки и загрузки данных» содержит в себе следующие подзадачи: «Создание нового процесса», «Редактирование процесса», «Удаление процесса» и т.п. Далее для каждой выделенной подзадачи приводится описание сценариев её выполнения. Сценарий формируется путем последовательных ответов на следующие вопросы: Вопрос: «Кто производит действия для выполнения подзадачи?» Ответ: «Администратор подсистемы...» Вопрос: «Что должен сделать Администратор? К какому ПС обратиться? Какой файл выбрать?» Ответ: «Администратор подсистемы обращается к программе ... и открывает ранее разработанный ... » Вопрос: «Какие действия после открытия в рамках подзадачи должен выполнить Администратор?» Ответ. «Администратор подсистемы обращается к программе ... и открывает ранее разработанный ... Администратор вносит изменения в ..., содержащие ...» Вопрос: «Какие действия выполняет сама подсистема в момент действия Администратора? Появляется ли диалоговое окно?» Ответ: «Администратор подсистемы обращается к программе ... и открывает ранее разработанный .... Администратор вносит изменения в ..., содержащие .... Подсистема запрашивает необходимость сохранения работы в виде рабочего файла ...» Вопрос: «Какие действия выполняет Администратор после появления диалогового окна?» Ответ: «Администратор подсистемы обращается к программе ... и открывает ранее разработанный .... Администратор вносит изменения в ..., содержащие .... Подсистема запрашивает необходимость сохранения работы в виде рабочего файла ... Администратор подтверждает команду сохранения.». Например, таблица, содержащая описание сценариев для подзадач задачи "Создание, редактирование и удаление процессов сбора, обработки и загрузки данных", функции "Управление процессами сбора, обработки и загрузки данных", подсистемы "Подсистема сбора, обработки и загрузки данных", будет выглядеть следующим образом. 2.6.1 Подсистема сбора, обработки и загрузки данных 2.6.1.1 Функция «Управление процессами сбора, обработки и загрузки данных» Описание возможного сценария для последующей реализации задачи «Создание, редактирование и удаление процессов сбора, обработки и загрузки данных» приведено в таблице.
Рекомендации. Подобным образом формируется описание действий, выполняемых для реализации каждой подзадачи задач функций для каждой подсистемы. При этом детализация описания сценария более подробна, чем на этапе эскизного проектирования. Приводятся конкретные действия по настройке или разработке. Те сценарии (например, для алгоритмы разработки ETL-процессов, настройки отчетности, которые достаточно объемны, выносятся в отдельные приложения и в сценариях на них дается ссылка). Допускается при описании сценария вставка пояснительных рисунков (например, схема организации разграничения прав доступа и т.п.). При описании данных сценариев должны быть тщательно проработаны все технические решения. 2.7. Состав и размещение комплексов технических средств Уточненные решения по комплексу технических средств, его размещению на объекте. В данном разделе актуализируется схема, приведенная в аналогичном разделе пояснительной записки к эскизному проекту. В схему вносятся следующие изменения: обозначаются подсети размещения серверов и рабочих станций, актуализируется состав портов и протоколов, актуализируется набор компонентов, устанавливаемых на сервера. Например:  Ниже данной схемы приводится расшифровка использованных в ней сокращений. Также приводится описание сценария взаимодействия между компонентами системы с точки зрения сетевого взаимодействия. Например: AD Server – служба каталога Active Directory, содержащая учетные записи пользователей информационных ресурсов и являющаяся источником информации об учетных записях сотрудников Заказчика. Firewall – межсетевой экран. Application Server – сервер приложений. ETL server – сервер, на котором устанавливается ПО подсистемы извлечения, преобразования и загрузки данных. DB server – сервер, на котором устанавливается ПО подсистемы хранения данных. Ниже приведено описание сценария взаимодействия между компонентами системы: 1 – Используя WEB-браузер, пользователь заходит по адресу системы КХД. Через Firewall запрос пользователя передается на сервер приложений. 2 – Сервер проверяет наличие пользователя в группе пользователей системы в Active Directory. 3 – Для получения данных в отчетах по запросам пользователей, BI-приложение обращается к серверу базы данных. 4 – ETL server производит загрузку данных в БД системы КХД. 5 – ETL server в соответствии с регламентом производит извлечение данных из систем источников. Далее приводится перечень портов, которые необходимо открыть на межсетевых экранах между сегментами сетей. Приводятся решения по конфигурации оборудования (CPU, RAM, HDD, Network Card, Fiber Channel, ОС), разбивке дискового массива: тома, размеры томов, уровень RAID, SWAP. Определяются решения по резервному копированию: подсистема, тип копирования (холодная копия, логическое копирование, инкрементальные копирование) и его частота, приводятся решения по архивированию копий. Приводятся решения по размещению зон разработки, тестирования и промышленной эксплуатации. 2.8. Решения по составу информации, объему, способам ее организации, видам машинных носителей, входным и выходным документам и сообщениям, последовательности обработки информации и другим компонентам 2.8.1. Описание информационной базы В начале данного раздела приводится схема организации подсистемы хранения данных с указанием потоков данных между схемами. Например:  Ниже схемы приводится определение каждой из областей подсистемы хранения: область временного хранения данных, область постоянного хранения данных и область витрин данных, т.е. для хранения каких данных предназначена область. Например: ... Область постоянного хранения данных используется для хранения детализированных фактических значений показателей, нормативно-справочной информации в многомерной форме по схеме «звезда». ... Далее приводится список схем базы данных и описание прав доступа к ним. Права определяются на уровне пользователей, администраторов, предметных экспертов и т.д. По каждой из схем приводится информация о том, кто будет иметь к ней доступ и для чего данный доступ нужен. Например: DW - к данной схеме имеют доступ: пользователи КХД согласно назначенным ролям; пользователь, от имени которого запускаются ETL-процессы. ODS - к данной схеме имеют доступ: пользователь, от имени которого запускаются ETL-процессы. и т.д. Далее приводится описание каждой из областей хранения данных (обычно описание каждой области выносится в отдельный подраздел). Например: 2.8.1.1 Объекты области постоянного хранения Объекты области постоянного хранения классифицируются по принципу логической группировки таблиц (сущностей) по предметным областям – областям анализа данных. С точки зрения реализации объектов БД области постоянного хранения сущностей каждого класса, все классы сущностей реализуются в одной схеме БД – DW. Многомерная модель данной схемы реализована по принципу схемы «звезда», когда модель данных состоит из двух типов таблиц: одной таблицы фактов - центр «звезды» и нескольких таблиц измерений по числу измерений - лучи «звезды». Общий перечень всех объектов области постоянного хранения приведен в приложении №? данной пояснительной записке к техническому проекту. 2.8.1.1.1 Область анализа «Анализ клиентов» В данной области возможен анализ клиентов Заказчика (предприятия, организации и физические лица, потребляющие услуги и т.п.). Из данной области можно получить информацию на запросы следующего характера: - Общие запросы по клиентам - Организационно-правовая форма клиента - Месторасположение клиента (страна, город, почтовый адрес) - Контактная информация - Классификация отраслей промышленности - Договорные отношения с клиентами - прочее Ниже приведен рисунок, отображающий взаимосвязи между сущностями через внешние ключи.  Далее подобным образом описываются и представляются все области анализа и хранения схем базы данных хранилища. Рекомендации. В ходе формирования технической записки зачастую еще продолжаются работы по изучению источников данных и уточнению модели данных будущего хранилища. Важно этого не допускать. На данном этапе нужно уже полностью изучить источники и сформировать модель, дабы избежать в последствии значительных изменений модели данных, ETL-процессов и структуры БД. 2.8.2. Решения по пользовательскому интерфейсу В данном разделе приводится описание пользовательских интерфейсов в части преднастроенной отчетности BI приложения, интерфейсов ввода данных (при наличии таковых) и интерфейсов администраторов Системы ХКИ. Например: 2.8.2.1. Решения по пользовательскому интерфейсу в части преднастроенной отчетности Для реализации требований в части преднастроенной отчетности используется стандартная функциональность продукта BI Application. Для создания и работы с отчетами BI Application создается единственный бизнес-слой данных. Все бизнес-области будут далее создаваться с использованием одного бизнес-слоя данных. Это позволит использовать в отчетах элементы из разных бизнес-областей. Пример экранной формы отчета в BI Application представлен ниже: 1 – меню, содержащее список команд и панель инструментов. 2 – интерактивное окно редактирования отчета. 3 – таблица с данными. 4 – График, отображающий те же данные, что и в таблице, но в графическом виде.  2.8.2.2. Решения по пользовательскому интерфейсу в части интерфейсов ввода данных Пользовательский интерфейс в части ввода данных, отсутствующих в системах источниках и ведения таблиц соответствия, реализуется помощью Forms Application. Структура данных форм ввода и состав полей обычно выносится в приложение. Ниже приведен перечень интерфейсов ввода данных с указанием вида типовой формы реализации: С – форма ввода значений справочника; ДА – форма ввода дополнительных атрибутов; ДН – форма ввода данных; ТС – таблица соответствия.
Ниже приведен пример экранной формы пользовательского интерфейса форм ввода (данное приложение является «тонким» клиентом, реализованным через Java applets, и установки на компьютер пользователя не требует): 1 – меню, содержащее список команд и панель инструментов, при помощи которых возможно выполнить запрос данных, сохранить данные, произвести редактирование данных и печать данных. 2 – форма отображения и редактирования данных, на которой отображено текстовое поле ввода данных. Пользователь вводит данные в текстовое поле.  2.8.2.3. Решения по пользовательскому интерфейсу администраторов системы 2.8.2.3.1. Пользовательский интерфейс Администратора подсистемы формирования и визуализации отчетности Приводится описание интерфейсов администратора подсистемы формирования и визуализации отчетности аналогично описанию пользовательских интерфейсов. 2.8.2.3.2. Пользовательский интерфейс Администратора подсистемы сбора, обработки и загрузки данных Приводится описание интерфейсов администратора подсистемы сбора, обработки и загрузки данных аналогично описанию пользовательских интерфейсов. 2.8.2.3.3. Пользовательский интерфейс Администратора подсистемы хранения данных Приводится описание интерфейсов администратора подсистемы подсистемы хранения данных аналогично описанию пользовательских интерфейсов. 2.9. Методы и средства разработки Приводятся решения по составу программных средств, языкам деятельности, алгоритмам процедур и операций и методам их реализации. За основу данного раздела принимается аналогичный раздел пояснительной записки к эскизному проекту и проводится его уточнение. Например, наполнение может выглядеть следующим образом. Для создания ХКД будет использоваться лицензионное программное обеспечение, включающее СУБД Database EE, сетевую операционную систему Unix X.y, Application Server, BI Application, Form Application. Для работы с БД используется язык запросов SQL в рамках стандарта ANSI SQL-92 и расширений SQL для Database EE. Для разработки пользовательских интерфейсов и средств генерации отчетов (любых твердых копий) используется встроенные возможности средств генерации BI Application и средства создания пользовательских интерфейсов Form Application, а также, в случае необходимости, языки SQL, Java 1.4 и выше, язык разметки гипертекста – HTML 3.2 и выше, Java Script 1.3 и выше. Моделирование выполняется в рамках стандартов, поддерживаемых программными средствами моделирования ERWin и MS Visio: IDEF0, DFD и информационного моделирования IE, IDEF1Х. 3. Мероприятия по подготовке объекта автоматизации к вводу системы в действие В данном разделе приводят: - мероприятия по приведению информации к виду, пригодному для обработки на ЭВМ; - мероприятия по обучению и проверке квалификации персонала; - мероприятия по созданию необходимых подразделений и рабочих мест; - мероприятия по изменению объекта автоматизации; - другие мероприятия, исходящие из специфических особенностей создаваемых АС. Ниже представлен пример содержания данного раздела. За основу берется содержание соответствующих разделов из «Пояснительной записки к эскизному проекту» (при наличии таковой). 3.1 Мероприятия по подготовке информационной базы Приводится перечень мероприятий, которые должны быть проведены в целях приведения информации к виду, пригодному для использования в системе КХД. Для этого необходимо ответить на следующий вопрос: «Какие технические решения необходимо согласовать между Разработчиком и Заказчиком?». Например, форматы взаимодействия, способы взаимодействия и т.п. 3.2 Мероприятия по подготовке персонала Разрабатывается перечень, мероприятий который необходимо провести Заказчику, в целях подготовки пользователей и обслуживающего персонала системы КХД. Например, комплектация штата, назначение ответственных и т.п. 3.3 Мероприятия по организации рабочих мест Определяется перечень мероприятий, которые должны быть проведены Заказчиком в целях организации рабочих мест разработчиков, пользователей, администраторов системы. Например, организация подсети разработчиков и администраторов, организация обучения и т.п. Также в этом разделе приводятся предварительные требования к рабочим местам. Например, указывается, что на рабочих станциях пользователей должен быть установлен MS Internet Explorer не ниже версии 5.5 и т.п. 3.4 Мероприятия по изменению объекта автоматизации Приводится перечень мероприятий, которые должны быть проведены силами Заказчика в целях подготовки помещений для размещения аппаратно-технического комплекса системы и организации необходимого аппаратно-технического обеспечения. Например, организация сетевого взаимодействия, закупка оборудования и т.п. 3.5 Прочие мероприятия Указываются мероприятия по изменению объекта автоматизации, другие мероприятия, исходящие из специфических особенностей создаваемых АИС. |