Пояснительная записка к техническому проекту ас

Пояснительная записка к техническому проекту

Пояснительная записка к техническому проекту — это один из основных документов, входящих в число документации, составляемой на этапе технического проектирования. В пояснительной записке содержатся общие сведения о проектируемой системе, обоснования технических решений, которые были выбраны для ее создания, а также план действий, благодаря которым планируется ввести систему в эксплуатацию.

Структура и оформление

Пояснительная записка оформляется согласно межгосударственному стандарту ГОСТ 2.106-96, описывающему общие требования к составлению текстовой и конструкторской документации, содержание ее разделов описано в руководящем документе РД 50-34.698-90, регламентирующем требования к содержанию документов на АСУ.

Этот документ, согласно стандартам и руководящим документам, должен состоять из нескольких разделов:

«Общие положения»
С указанием названия разрабатываемой АСУ, документов, на основании которых система разрабатывается – технического задания, договора — организаций, которые принимают участие в проектировании, стадий и сроков выполнения работ, целей разработки системы, ее назначения и сферы применения, технической и нормативной документации, а также очередности работ по проектированию.

«Описание процесса деятельности»
Пояснительная записка к техническому проекту содержит общие сведения о функционировании разрабатываемой системы.

«Базовые технические решения»
Приводится структура системы с перечнем подсистем, способов и средств обмена компонентов системы данными, взаимосвязи АС с другими системами, режимов функционирования. Также здесь следует перечислить квалификацию и количество работников, функции системы, технические средства, обеспечивающие ее работу, потребности в информационном и программном обеспечении.

«Действия по подготовке системы к эксплуатации»
Приводится список работ по подготовке персонала, приведения выходных данных системы к пригодному для дальнейшего использования виду, организации мест работы, а также других мероприятий, отвечающих специфике ввода в эксплуатацию конкретной системы.

Пояснительная записка, служащая для пояснения и перечисления практически всех работ, произведенных во время технического проектирования, составляется на любую программу или автоматизированную систему управления. Вместе с тем, разработка пояснительной записки сама по себе является важным этапом технического проекта, избежать которого невозможно.

Как разработать?

Пояснительная записка к ТП – это один из самых сложных документов из пакета конструкторской документации. Ее разработка осложняется тем, что она должна соответствовать всем строгим современным стандартам не только по форме и смыслу передаваемых сведений, регламенту графического выполнения документации, но и по стилистике текста, употребляемой терминологии.

Зачастую именно пояснительная записка, разрабатываемая к техническому проекту, становится камнем преткновения даже квалифицированных специалистов, не один раз сталкивавшихся в своей работе с оформлением конструкторской документации.

Оформите заявку и задавайте все интересующие вас вопросы по телефону +7(499)755-74-33 e-mail Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра. или через форму заказа.

Корпоративные хранилища данных. Интеграция систем. Проектная документация.

РД 50-34.698-90 Пояснительная записка к техническому проекту на создание автоматизированной системы (пример технического проекта)

Ниже представлен пример (образец) проектного документа «Пояснительная записка к техническому проекту на создание автоматизированной системы«, основанный на методических указаниях РД 50-34.698-90. Данный документ формируется IT-специалистом на стадии технического проектирования информационной системы.

В качестве примера разработки информационной системы использован проект внедрения информационно-аналитической системы «Корпоративное хранилище данных».

На странице ниже приведено содержание пояснительной записки технического проекта в соответствии с ГОСТ, внутри каждого из разделов кратко приведены требования к содержанию и текст примера заполнения (выделяется вертикальной чертой).

Пояснительная записка к техническому проекту на создание автоматизированной системы «Корпоративное хранилище данных»

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.6 Очередность создания системы

Указывается очередность создания системы и характеристики каждой очереди (функциональность, ограничения, сроки, исполнители).

Решение о составе и очередности предполагаемых работ принимается исходя из рабочего план-графика Проекта, лучших практик по ведению подобных проектов, специфики данного проекта. При этом очередность работ прорабатывается более детально чем на этапе эскизного проектирования (чем детальней проработан данный раздел, тем яснее представление о последовательности действий. В данном разделе приводится именно состав работ, без привязки к срокам и без определения зависимости между работами).

Например:
Ниже представлена предполагаемая очередность создания системы:
— Производится разработка концептуальной, логической, физической модели хранилища данных.
— Согласовываются регламенты взаимодействия с системами-источниками.
— Проектируется структура таблиц.
— Проектируются процессы сбора данных из систем-источников в область временного хранения данных.
— Проектируются процессы преобразования данных.
— Определяется состав дополнительных объектов (партиций, индексов, представлений, последовательностей и др.) к спроектированной физической модели области постоянного хранения данных.
— Проектируются процессы загрузки данных в область постоянного хранения данных.
— .
— Проектируются права на доступ к данным на уровне отчетности, объектов базы данных и записей в таблицах.
— Производится настройка активного сетевого оборудования.
— Производится настройка аппаратно-технической части.
— Разрабатывается план установки серверного программного обеспечения.
— Производится установка серверного программного обеспечения.
— Реализуется структура таблиц и дополнительных объектов (партиций, индексов и др.) области временного хранения данных.
— Реализуются процессы сбора данных в область временного хранения данных.
— Реализуются дополнительные формы ввода данных предметными экспертами.
— Реализуются процессы обработки данных.
— .
— Реализуется политика разграничения прав доступа к данным на уровне отчетности, объектов базы данных и записей в таблицах.
— Производится первоначальное наполнение базы данных тестовыми данными для проведения испытаний.
— Производится настройка рабочих мест для проведения испытаний.
— Производятся предварительные испытания.
— Производится устранение ошибок, выявленных по результатам предварительных испытаний.
— Производится опытная эксплуатация.
— Производится устранение ошибок выявленных по результатам опытной эксплуатации.
— Производятся приемочные испытания.
— Производится устранение ошибок, выявленных по результатам приемочных испытаний.
— Производится наполнение базы данных данными для ввода АИС в действие.
— Проводится настройка рабочих мест пользователей.

2. Основные технические решения

2.1. Решения по структуре системы, подсистем, средствам и способам связи для информационного обмена между компонентами системы

2.1.1. Логическая и компонентная архитектура систем

В данном разделе приводятся программные решения, разрабатываемые на детальном уровне (с привязкой к используемым языкам программирования), а также перечень, назначение и взаимосвязи готовых (закупаемых) и вновь разрабатываемых программных компонентов, их отображение на программные классы (какие компоненты реализуют какие классы).

На основании аналогичного раздела пояснительной записки эскизного проекта приводится состав программных средств, которые будут использоваться при построении хранилища данных.
Состав программных средств приводится более расширенный (указываются конкретные версии; возможно, по согласованию с Заказчиком конкретные версии не указывать) на основании знаний о том, какие компоненты входят в состав программных средств, приведенных в техническом задании, в пояснительной записке к эскизному проекту, и какие из этих компонентов будут использованы на Проекте, а также на основании знаний о том, какие дополнительные компоненты нужны для реализации системы.

Например:

Наименование
1 Oracle Enterprise Edition Database Server 10g rel.2 (10.2.0.4)
2 Oracle Label Security (10.2.0.4)
3 Oracle Application Server Enterprise Edition 10g rel.2 (10.1.2.2)
3.1 Oracle Discoverer Server 10g
3.2 Oracle Internet Directory 10g
. .

Далее приводится техническая архитектура с описанием технологических компонентов системы. За основу данной архитектуры берется техническая архитектура решения и ее описание, приведенная в аналогичном разделе пояснительной записки к эскизному проекту. Данная архитектура может быть уточнена на основании знаний о том, какие компоненты изменились или добавились в ходе проектирования.

Например:

В состав разрабатываемой системы будут включены следующие технологические компоненты:
— программное обеспечение поддержки модели данных представляет собой программное обеспечение, автоматизирующее разработку и поддержку модели ХД — ERwin;
ETL-приложение – это комплексное решение Informatica Power Center, с помощью которого реализуются процессы извлечения, проверки, преобразования и загрузки данных из источников.
сервер БД представляет собой промышленную систему управления базами данных (СУБД). На данном сервере хранятся НСИ, область временного и постоянного хранения данных, агрегаты данных. Реализована система разграничений прав доступа на уровне объектов и записей в таблицах. В качестве сервера БД будет использоваться Oracle DB EE 10g rel.2;
сервер приложений – продукт, обеспечивающий поддержку промышленной инфраструктуры бизнес-приложений. Включает в себя следующий ряд приложений обеспечивающих:
— стандартные подходы к организации служб каталогов, централизованные методы организации;
— развертывание сервисов разработки дополнительных приложений;
— развертывание сервисов анализа и отчетности.
средства администрирования и разработки – набор программных продуктов, предназначенных для администрирования системы ETL (Administrator, Manager), баз данных, сервера приложений (Enterprise Manager) и разработки отчетности (Developer Suite).
клиентские места сотрудников (внутри локальной вычислительной сети), представляющие собой автоматизированные рабочие места.

Рекомендации. Желательно в данном разделе указывать конкретные версии устанавливаемого ПО. Это позволит избежать смены версии ПО на более поздних этапах, но уменьшит возможность маневра в части версионности как для Разработчика, так и для Заказчика.

2.1.2. Функциональная структура системы

В данном разделе формируется техническое решение по функциональной архитектуре хранилища данных. За основу принимается аналогичный раздел из пояснительной записки к эскизному проекту и при необходимости вносятся в него уточнения (например добавляется сетевой администратор и т.п.).

В первую очередь в данном разделе формируется схема функциональной структуры КХД. За основу берется схема из пояснительной записки к эскизному проекту:

После чего проводится уточнение описания подсистем и взаимосвязей между подсистемами. За основу берется описание и взаимосвязи из аналогичного раздела пояснительной записки эскизного проекта.

Рекомендация. Данные по оборудованию, на котором предполагается развертывание системы, желательно четко знать до начала проекта и прилагать максимум усилий, чтобы в ходе проекта Заказчик не изменял параметры данного оборудования.

2.2. Решения по взаимосвязям АС со смежными системами, обеспечению ее совместимости

Приводятся уточненные эскизные решения по взаимосвязи КХД со смежными системами, обеспечению ее совместимости (описание используемых протоколов обмена данными, средств и методов обмена данными).

Например:
Приводится перечень смежных систем, способы взаимодействия.

Наименование смежной системы Предпочтительный способ взаимодействия Прикладной протокол взаимодействия Регламент взаимодействия
Информационная система управления предприятием Использование ПБД Протокол MS SQL Server Дается ссылка на детальный регламент взаимодействия (обычно отдельный документ или приложение к техническому проекту)
Информационно-справочная система Файлы ОС определенного формата FTP Дается ссылка на детальный регламент взаимодействия (обычно отдельный документ или приложение к техническому проекту)
. . . .

Ниже представлена детальная схема взаимодействия системы КХД и смежных систем.

2.3. Решения по режимам функционирования, диагностированию работы системы

В данном разделе приводятся уточненные решения по режимам функционирования, диагностированию работы системы на основании аналогичного раздела пояснительной записки к эскизному проекту.
Приводится описание решений по диагностированию системы, осуществляемых путем установления и изучения признаков, которые характеризуют состояние системы для предсказания возможных отклонений и предотвращения нарушений нормального режима ее работы.

Читайте так же:  Длительное пребывание в долгах

Например:
Предлагается следующая реализация решений по режимам функционирования системы:
Основной режим, в котором все подсистемы выполняют свои основные функции.
Профилактический режим, в котором одна или все подсистемы не выполняют своих функций. В данный режим работы система переходит в следующих случаях: возникновение необходимости модернизации аппаратно-программного комплекса; возникновение необходимости проведения технического обслуживания; выход из строя аппаратно-программного комплекса, вызванный выходом из строя элементов аппаратной или программной базы; выход из строя сети передачи данных и другие аварийные ситуации.

В основном режиме функционирования система обеспечивает:
— работу пользователей в режиме – 24 часа в день, 7 дней в неделю (24х7);
— выполнение своих функций – сбор, обработка и загрузка данных; хранение данных, предоставление отчетности по показателям.
В профилактическом режиме система обеспечивает возможность проведения следующих работ: — техническое обслуживание;
— модернизация аппаратно-программного комплекса;
— устранение аварийных ситуаций.

Принимается предварительное решение о том, что общее время проведения профилактических работ не должно превышать X% от общего времени работы системы в основном режиме (XX часов в месяц).
Принимается предварительное решение о том, что для обеспечения высокой надежности функционирования как системы в целом, так и ее отдельных компонентов необходимо проводить регулярное диагностирование состояния компонентов.

В таблице ниже представлены средства диагностики по подсистемам.

Подсистема Средства диагностирования
Подсистема сбора, обработки и загрузки данных ETL Administrator – диагностика и настройка ETL-приложения, управление критериями извлечения, установка NLS;
ETL Manager — просмотр и редактирование репозитория.
Подсистема хранения данных DB Manager – диагностика и настройка и конфигурация одной или более БД
Подсистема отображения отчетности BI Administrator – диагностика и настройка бизнес-описания и представления витрин данных

Далее для каждой подсистемы приводятся примерные сценарии проведения их диагностирования. Чтобы описать сценарии диагностирования необходимо ответить на следующие вопросы: «Кем проводится диагностирование?», «Какое программное обеспечение используется?», «Какие действия необходимо провести для диагностирования (действия прописываются общие, например, зайти, открыть, проверить)?», «Что необходимо проверить? (например, наличие свободного места на дисках)», «Как часто необходимо выполнять данные действия?». Необходимо также указывать критичность подсистемы для функционирования системы в целом.

Например:
Подсистема сбора, обработки и загрузки данных:
— администратор подсистемы должен каждый день контролировать работоспособность серверной части прикладного программного обеспечения сбора, обработки и загрузки данных, т.к. данная подсистема является критичной для работоспособности системы в целом;
— администратор подсистемы перед началом загрузки данных должен проводить контроль объема свободного места на дисках для временных файлов;
— администратор подсистемы должен каждый день проводить анализ протоколов работы подсистемы на наличие ошибок и предупреждений, возникающих при ее работе.

2.4. Решения по персоналу и режимам его работы

В данном разделе приводятся уточненные решения по численности, квалификации и функциям персонала создаваемой системы, режимам работы персонала на основании аналогичного раздела пояснительной записки к эскизному проекту.

Например:
4.1.2.1. Требования к численности персонала
В составе персонала, необходимого для обеспечения эксплуатации КХД в рамках соответствующих подразделений Заказчика, необходимо выделение ответственных лиц на следующие роли.

Роль Количество
Руководитель эксплуатирующего подразделения 1 человек
Администратор подсистемы сбора, обработки и загрузки данных 2 человека
Администратор подсистемы хранения данных 2 человека
Администратор подсистемы формирования и визуализации отчетности 1 человек

Лица, которым назначены данные роли, должны выполнять следующие функциональные обязанности.

Роль Функциональные обязанности Период выполнения
Руководитель эксплуатирующего подразделения Обеспечение работы системы в целом и ответственность за достоверность хранимых данных Весь период внедрения и эксплуатации
Обеспечение общего руководства группой сопровождения Весь период внедрения и эксплуатации
Администратор подсистемы сбора, обработки и загрузки данных Обеспечение загрузки данных из внешних источников в хранилище данных Весь период внедрения и эксплуатации
Контроль работы процессов ETL Весь период внедрения и эксплуатации
Разработка новых и модификация существующих ETL-процессов По запросу администратора подсистемы формирования и визуализации отчетности
Администратор подсистемы хранения данных Распределение дисковой памяти и планирование будущих требований системы к памяти Весь период внедрения и эксплуатации
Модификация структуры базы данных в соответствии с потребностями приложений По запросу администратора подсистемы формирования и визуализации отчетности или по запросу администратора подсистемы сбора, обработки и загрузки данных
Отслеживание и оптимизация производительности базы данных Весь период внедрения и эксплуатации
Планирование и проведение резервного копирования и восстановления В соответствии с регламентом резервного копирования и восстановления
Администратор подсистемы формирования и визуализации отчетности Разработка витрин данных По результатам формализации требований к витрине
Разработка отчетности По результатам формализации требований к отчетности
Разграничение прав доступа на уровне витрин данных и отчетности По результатам формализации требований к разграничению прав доступа, разработки необходимых структур и объектов

4.1.2.2. Требования к квалификации персонала
К квалификации персонала эксплуатирующего Систему КХД, предъявляются следующие требования.

Роль Требования к квалификации
Конечный пользователь Знание соответствующей предметной области; знание основ многомерного анализа; знания и навыки работы с аналитическими приложениями
Администратор подсистемы сбора, обработки и загрузки данных Знание методологии проектирования хранилищ данных; знание методологии проектирования ETL-процедур; знание интерфейсов интеграции ХД с источниками данных; знание СУБД; знание языка запросов SQL
Администратор подсистемы хранения данных Глубокие знания СУБД; знание архитектуры «Звезда» и «Снежинка»; опыт администрирования СУБД; знания и навыки операций архивирования и восстановления данных; знания и навыки оптимизации работы СУБД
Администратор подсистемы формирования и визуализации отчетности Понимание принципов многомерного анализа; знания методологии проектирования хранилищ данных; знание и навыки администрирования приложения; знание языка запросов SQL; знание инструментов разработки

4.1.2.3. Требуемый режим работы персонала
Персонал, работающий с Системой КХД и выполняющий функции её сопровождения и обслуживания, должен работать в следующих режимах:

Роль Режим работы Подразделение
Руководитель эксплуатирующего подразделения В соответствии с основным рабочим графиком подразделений Заказчика. Предусматривается ненормированный рабочий день. Департамент информационных технологий
Конечный пользователь В соответствии с основным рабочим графиком подразделений Заказчика Отдел анализа
Администратор подсистемы сбора, обработки и загрузки данных Двухсменный график, поочередно Департамент информационных технологий
Администратор подсистемы хранения данных Двухсменный график, поочередно Департамент информационных технологий
Администратор подсистемы формирования и визуализации отчетности В соответствии с основным рабочим графиком подразделений Заказчика. Предусматривается ненормированный рабочий день. Департамент информационных технологий

2.5. Сведения об обеспечении заданных в техническом задании потребительских характеристик системы, определяющих ее качество

Приводятся уточненные сведения об обеспечении заданных в техническом задании потребительских характеристик системы (подсистем), определяющих ее качество.
Приводится таблица трассировки требований, заданных в техническом задании, и описанных проектных решений (достигается, нет, в какой степени, за счет чего?).

Например:

Требование Метод реализации
Взаимодействие со смежными системами Реализуется за счет наличия интерфейсов с системами – источниками данных. Планируется использование промежуточных баз данных; интеграция «точка – точка» (point-to-point); интерактивная загрузка информации из файлов определенного формата.
Диагностирование системы Реализуется путем определения перечня работ по диагностированию подсистем.
Сохранение работоспособности системы в различных вероятных условиях Реализуется путем разработки процедур резервного копирования, подготовки персонала, использования современных методов разработки и проверенных на практике стандартных программных средств.
На объекте автоматизации обязательно ведение журналов инцидентов в электронной форме, а также графиков и журналов проведения ППР, в соответствии с утвержденными для каждого объекта ХД мероприятиями по поддержанию его работоспособности.
. .

Приводятся сведения об обеспечении заданных в техническом задании требований к функциям, выполняемым каждой подсистемой, определяющих ее качество.

Например:

Подсистема Функция Метод реализации
Подсистема сбора, обработки и загрузки данных Управление процессами сбора, обработки и загрузки данных Путем внедрения комплексного ETL-приложения
Запуск процессов сбора, обработки и загрузки данных из источников в ХД Путем разработки и внедрения регламентов запуска ETL-процессов
. .
Подсистема хранения данных Создание и сопровождение структур базы данных Путем применения CASE средства и средств администрирования СУБД
Осуществление резервного копирования данных Путем применения следующих видов копирования: полное холодное копирование; логическое копирование; инкрементальное копирование
. .

2.6. Состав функций, комплексов задач, реализуемых системой

Приводится наименование и назначение функциональных комплексов задач системы (или по каждой подсистеме).
Функциональные задачи по мере проработки проектных решений, описываются в виде сценариев. Описания сценариев могут быть вынесены в приложение к пояснительной записке.

Процесс формирования сценариев выполнения задач функций каждой подсистемы производится следующим образом: приводится наименование подсистемы, далее приводится наименование функции подсистемы, внутри каждой функции перечисляются задачи, которые выполняются в её рамках (за основу принимается аналогичный раздел из пояснительной записки к эскизному проекту), для каждой задачи формируется таблица вида:

Подзадача Действие
. .

В данной таблице для каждой задачи приводится перечень подзадач и сценарий их выполнения. Перечень подзадач формируется следующим образом: берется наименование задачи и из названия задачи выделяются подзадачи, например задача «Поддержка (разработка, модификация) модели ХД» содержит в себе две подзадачи «Разработка» и «Модификация», задача «Создание, редактирование и удаление процессов сбора, обработки и загрузки данных» содержит в себе следующие подзадачи: «Создание нового процесса», «Редактирование процесса», «Удаление процесса» и т.п.

Далее для каждой выделенной подзадачи приводится описание сценариев её выполнения. Сценарий формируется путем последовательных ответов на следующие вопросы:
Вопрос: «Кто производит действия для выполнения подзадачи?»
Ответ: «Администратор подсистемы. »
Вопрос: «Что должен сделать Администратор? К какому ПС обратиться? Какой файл выбрать?»
Ответ: «Администратор подсистемы обращается к программе . и открывает ранее разработанный . »
Вопрос: «Какие действия после открытия в рамках подзадачи должен выполнить Администратор?»
Ответ. «Администратор подсистемы обращается к программе . и открывает ранее разработанный . Администратор вносит изменения в . содержащие . »
Вопрос: «Какие действия выполняет сама подсистема в момент действия Администратора? Появляется ли диалоговое окно?»
Ответ: «Администратор подсистемы обращается к программе . и открывает ранее разработанный . Администратор вносит изменения в . содержащие . Подсистема запрашивает необходимость сохранения работы в виде рабочего файла . »
Вопрос: «Какие действия выполняет Администратор после появления диалогового окна?»
Ответ: «Администратор подсистемы обращается к программе . и открывает ранее разработанный . Администратор вносит изменения в . содержащие . Подсистема запрашивает необходимость сохранения работы в виде рабочего файла . Администратор подтверждает команду сохранения.».

Например, таблица, содержащая описание сценариев для подзадач задачи «Создание, редактирование и удаление процессов сбора, обработки и загрузки данных», функции «Управление процессами сбора, обработки и загрузки данных», подсистемы «Подсистема сбора, обработки и загрузки данных», будет выглядеть следующим образом.

2.6.1 Подсистема сбора, обработки и загрузки данных
2.6.1.1 Функция «Управление процессами сбора, обработки и загрузки данных»
Описание возможного сценария для последующей реализации задачи «Создание, редактирование и удаление процессов сбора, обработки и загрузки данных» приведено в таблице.

Подзадача Действие
Создание нового процесса — Администратор обращается к модулю разработки подсистемы на сервере разработки.
— Подсистема предоставляет инструментальные средства для создания нового процесса.
— Администратор подсистемы создает схему нового процесса ETL. На схеме указываются компоненты процесса: источники данных, компоненты преобразования данных, таблицы БД.
— Администратор подсистемы инициирует команду сохранения созданного процесса.
— Подсистема размещает созданный процесс на сервере среды разработки.
— Администратор подсистемы выполняет запуск, тестирование и отладку создаваемого процесса. На вход процесса подаются тестовые данные. Анализируя итоговые таблицы БД среды разработки, Администратор принимает решение о готовности нового процесса.
— Готовый процесс переносится на продуктивный сервер.
Редактирование процесса — Администратор подсистемы вызывает подсистему среды разработки на сервере разработки.
— Используя инструментальные программные средства подсистемы, Администратор изменяет схему процесса ETL, размещает измененный процесс на сервере среды разработки.
— Подсистема размещает редактируемый процесс на сервере среды разработки.
— Администратор подсистемы выполняет запуск, тестирование и отладку редактируемого процесса. На вход процесса подаются тестовые данные. Анализируя итоговые таблицы БД среды разработки, Администратор принимает решение о готовности редактируемого процесса.
— Готовый процесс переносится на продуктивный сервер.
Удаление процесса — Администратор подсистемы вызывает подсистему среды разработки на сервере разработки.
— Используя инструментальные программные средства подсистемы, Администратор удаляет процесс ETL, размещает изменения на сервере среды разработки.
— Подсистема размещает внесенные изменения на сервере среды разработки.
— Изменения переносятся на продуктивный сервер.
Читайте так же:  В совместную собственность супругов включается

Рекомендации. Подобным образом формируется описание действий, выполняемых для реализации каждой подзадачи задач функций для каждой подсистемы. При этом детализация описания сценария более подробна, чем на этапе эскизного проектирования. Приводятся конкретные действия по настройке или разработке. Те сценарии (например, для алгоритмы разработки 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 Прочие мероприятия

Указываются мероприятия по изменению объекта автоматизации, другие мероприятия, исходящие из специфических особенностей создаваемых АИС.

Шаблон пояснительной записки к техническому проекту по ГОСТ 34

Структура и содержание документа

Требования к структуре пояснительной записки к техническому проекту по ГОСТ 34 устанавливаются РД 50-34.698-90. В общем случае документ должен состоять из следующих разделов:

1 Общие положения
1.1 Наименование проектируемой АС и наименования документов, их номера и даты утверждения, на основании которых ведется проектирование АС
1.2 Перечень организаций, участвующих в разработке системы, сроки выполнения стадий
1.3 Цели, назначение и области использования АС
1.4 Подтверждение соответствия проектных решений действующим нормам и правилам техники безопасности, пожаро- и взрывобезопасности
1.5 Сведения об использованных при проектировании нормативно-технических документах
1.6 Сведения о НИР, передовом опыте, изобретениях, использованных при разработке проекта
1.7 Очередность создания системы и объем каждой очереди
2 Описание процесса деятельности
3 Основные технические решения
3.1 Решения по структуре системы, подсистем, средствам и способам связи для информационного обмена между компонентами системы, подсистем
3.2 Решения по взаимосвязям АС со смежными системами, обеспечению ее совместимости
3.3 Решения по режимам функционирования, диагностированию работы системы
3.4 Решения по численности, квалификации и функциям персонала АС, режимам его работы, порядку взаимодействия
3.5 Сведения об обеспечении заданных в техническом задании (ТЗ) потребительских характеристик системы (подсистем), определяющих ее качество
3.6 Состав функций, комплексов задач (задач) реализуемых системой (подсистемой)
3.7 Решения по комплексу технических средств, его размещению на объекте
3.8 Решения по составу информации, объему, способам ее организации, видам машинных носителей, входным и выходным документам и сообщениям, последовательности обработки информации и другим компонентам
3.9 Решения по составу программных средств, языкам деятельности, алгоритмам процедур и операций и методам их реализации
4 Мероприятия по подготовке объекта автоматизации к вводу системы в действие
4.1 Мероприятия по приведению информации к виду, пригодному для обработки на ЭВМ
4.2 Мероприятия по обучению и проверке квалификации персонала
4.3 Мероприятия по созданию необходимых подразделений и рабочих мест
4.4 Мероприятия по изменению объекта автоматизации
4.5 Другие мероприятия, исходящие из специфических особенностей создаваемых АС

Читайте так же:  Новые требования к закупкам по 223 фз

Содержание документов является общим для всех видов АС и, при необходимости, может дополняться разработчиком документов в зависимости от особенностей создаваемой АС. Допускается включать в документы дополнительные разделы и сведения, объединять и исключать разделы.

Содержание документов, разрабатываемых на предпроектных стадиях по ГОСТ 34.601, и организационно-распорядительных определяют разработчики в зависимости от объема информации, необходимой и достаточной для дальнейшего использования документов.

Примечание

Оформление документа

Документ выполняют на формах, установленных соответствующими стандартами Единой системы конструкторской документации (ЕСКД).

Для размещения утверждающих и согласующих подписей к документу рекомендуется составлять титульный лист и (или) лист утверждения.

Текст документа при необходимости разделяют на разделы и подразделы. Разделы, подразделы должны иметь заголовки. Пункты, как правило, заголовков не имеют. Заголовки должны четко и кратко отражать содержание разделов, подразделов.

Текст документа должен быть кратким, четким и не допускать различных толкований.

Документ «Пояснительная записка (Технический проект)»

РД 50-34.698-90. Автоматизированные системы. Требования к содержанию документов: .

УКАЗАНИЯ ГОСТ:
Настоящие методические указания распространяются на автоматизированные системы (АС), используемые в различных сферах деятельности (управление, исследование, проектирование и т. п.), включая их сочетание, и устанавливают требования к содержанию документов, разрабатываемых при создании АС.

Пояснительная записка

1 ОБЩИЕ ПОЛОЖЕНИЯ

УКАЗАНИЯ ГОСТ:
В разделе «Общие положения» приводят:
1) наименование проектируемой АС и наименования документов, их номера и дату утверждения, на основании которых ведут проектирование АС;
2) перечень организаций, участвующих в разработке системы, сроки выполнения стадий;
3) цели, назначение и области использования АС;
4) подтверждение соответствия проектных решений действующим нормам и правилам техники безопасности, пожаро- и взрывобезопасности и т. п.;
5) сведения об использованных при проектировании нормативно-технических документах;
6) сведения о НИР, передовом опыте, изобретениях, использованных при разработке проекта;
7) очередность создания системы и объем каждой очереди.

1.1 Наименование проектируемой автоматизируемой системы

ПРИМЕР СОДЕРЖАНИЯ:
Наименование разрабатываемой системы приводится в техническом задании, раздел «1.1 Полное наименование системы и ее условное обозначение».

1.2 Документы, на основании которых ведется проектирование

ПРИМЕР СОДЕРЖАНИЯ:
Документы, на основании которых ведется проектирование, приводятся в техническом задании, раздел «1.4 Перечень документов, на основании которых создается система»

1.3 Организации, участвующие в разработке

ПРИМЕР СОДЕРЖАНИЯ:
Организации, участвующие в разработке, приведены в техническом задании, раздел «1.3 Наименования организации-заказчика и организаций-участников работ»

1.4 Стадии и сроки исполнения

ПРИМЕР СОДЕРЖАНИЯ:
Стадии и сроки исполнения приведены в техническом задании, раздел «1.5 Плановые сроки начала и окончания работы по созданию системы»

1.5 Цели, назначение и области использования

ПРИМЕР СОДЕРЖАНИЯ:
Цели, назначение и области использования можно взять из технического задания, разделы «2.1 Назначение системы» и «2.2 Цели создания системы»

1.6 Соответствие проектных решений нормам и правилам техники безопасности, пожаро- и взрывобезопасности

ПРИМЕР СОДЕРЖАНИЯ:
Соответствие проектных решений нормам и правилам техники безопасности, пожаро- и взрывобезопасности приведены в техническом задании, в разделе «4.1.5 Требования к безопасности»

1.7 Нормативно-технические документы

ПРИМЕР СОДЕРЖАНИЯ:
Перечень документов можно взять в техническом задании, в разделе 1.8.

1.8 НИРы и изобретения, используемые при разработке системы

ФОРМАЛЬНОЕ СОДЕРЖАНИЕ:
При разработке системы никакие НИРы и изобретения не использовались.

1.9 Очередность создания системы

ФОРМАЛЬНОЕ СОДЕРЖАНИЕ:
Очередность создания системы описана в разделе 1.4. «Стадии и сроки исполнения».

2 ОПИСАНИЕ ПРОЦЕССА ДЕЯТЕЛЬНОСТИ

УКАЗАНИЯ ГОСТ:
В разделе «Описание процесса деятельности» отражают состав процедур (операций) с учетом обеспечения взаимосвязи и совместимости процессов автоматизированной к неавтоматизированной деятельности, формируют требования к организации работ в условиях функционирования АС.
ПРИМЕР СОДЕРЖАНИЯ:
2.1 Описание постановки задачи:
АИС «Кадры» предназначена для комплексного информационно-аналитического обеспечения процессов федерального агентства «Государственные Кадры», в части исполнения следующих процессов:
— планирование структуры организаций, штатных расписаний и кадровых политик;
— произведение расчета заработной платы;
— оперативного учета движения кадров;
— ведение административного документооборота по персоналу и учету труда, аттестации и определению потребностей (обучение, повышение квалификации) работников;
— рекрутинг персонала на вакантные должности;
— ведение архивов без ограничения сроков давности;
— публиковать открытую часть информации системы гражданам Российской Федерации.
Внедрение разрабатываемой АС Кадры должно обеспечить выполнение административных процессов в соответствии с описанием, приведенном в п.2.2-2.3.
2.2 Планирование структуры организаций, штатных расписаний и кадровых политик
Планирование структуры организаций, штатных расписаний и кадровых политик осуществляется в центральном аппарате федерального агентства «Государственные Кадры», и представляется собой выполнение следующих операций:
— Составление структуры;
— Утверждение структуры;
— т.д.;
— пр.;
Составление структуры представляет собой:
— Указание имени структуры;
— Задание параметров;
— т.д.;
— пр.

Далее необходимо перечислить все процессы, и функции, которые выполняются, и действия, которые при этом автоматизирует АС Кадры
. — т.д.;
— пр.
— т.д.;
— пр.

3 ОСНОВНЫЕ ТЕХНИЧЕСКИЕ РЕШЕНИЯ

УКАЗАНИЯ ГОСТ:
В разделе «Основные технические решения» приводят:
1) решения по структуре системы, подсистем, средствам и способам связи для информационного обмена между компонентами системы, подсистем:
2) решения по взаимосвязям АС со смежными системами, обеспечению ее совместимости;
3) решения по режимам функционирования, диагностированию работы системы;
4) решения по численности, квалификации и функциям персонала АС, режимам его работы, порядку взаимодействия;
5) сведения об обеспечении заданных в техническом задании (ТЗ) потребительских характеристик системы (подсистем), определяющих ее качество;
6) состав функций, комплексов задач (задач) реализуемых системой (подсистемой);
7) решения по комплексу технических средств, его размещению на объекте;
8) решения по составу информации, объему, способам ее организации, видам машинных носителей, входным и выходным документам и сообщениям, последовательности обработки информации и другим компонентам;
9) решения по составу программных средств, языкам деятельности, алгоритмам процедур и операций и методам их реализации. В разделе приводят в виде иллюстраций другие документы, которые допускается включать по ГОСТ 34.201.

3.1 Структура системы, перечень подсистем

ПРИМЕР СОДЕРЖАНИЯ:
Наполнение этого раздела можно взять в ТЗ, пункте «4.1.1.1 Перечень подсистем, их назначение и основные характеристики».
Содержание необходимо переписать в императиве (не «В состав АС Кадры должны входить следующие подсистемы», а «В состав АС Кадры входят следующие подсистемы»).

3.2 Способы и средства связи для информационного обмена между компонентами подсистем

ПРИМЕР СОДЕРЖАНИЯ:
Наполнение этого раздела можно взять в ТЗ, пункте «4.1.1.2 Требования к способам и средствам связи для информационного обмена между компонентами системы».
Содержание необходимо переписать в императиве (не «должны использовать», а «используют»).

3.3 Взаимосвязь АС со смежными системами

ПРИМЕР СОДЕРЖАНИЯ:
Наполнение этого раздела можно взять в ТЗ, пункте «4.1.1.3 Требования к характеристикам взаимосвязей создаваемой системы со смежными системами».
Содержание необходимо переписать в императиве (не «должна взаимодействовать «, а «взаимодействует»).

3.4 Режимы функционирования системы

ПРИМЕР СОДЕРЖАНИЯ:
Наполнение этого раздела можно взять в ТЗ, пункте «4.1.1.4 Требования к режимам функционирования системы».

3.5 Численность, функции и квалификация персонала

ПРИМЕР СОДЕРЖАНИЯ:
Пример содержания можно взять в ТЗ, пункте «4.1.2 Требования к численности и квалификации персонала системы».
Также содержание можно взять в документе «Схема организационной структуры» (в случае составления данного документа).

3.6 Обеспечение потребительских характеристик системы

ПРИМЕР СОДЕРЖАНИЯ:
В состав основных потребительских характеристик системы входят:
— надежность;
— безопасность;
— производительность;
— масштабируемость.
Масштабируемость:
Масштабируемость АС Кадры обеспечивается следующими основными способами:
— .
— .

Производительность:
Общая производительность АС Кадры определяется следующими основными характеристиками:
— .
— .

3.7 Функции, выполняемые системой

ПРИМЕР СОДЕРЖАНИЯ:
Наполнение этого раздела можно взять в документе «Описание автоматизируемых функций».

3.8 Комплекс технических средств

ПРИМЕР СОДЕРЖАНИЯ:
Наполнение этого раздела можно взять в документе «Схема структурная комплекса технических средств».

3.9 Информационное обеспечение системы

ПРИМЕР СОДЕРЖАНИЯ:
Наполнение этого раздела можно взять в документе «Описание информационного обеспечения системы».

3.10 Программное обеспечение системы

ПРИМЕР СОДЕРЖАНИЯ:
Программное обеспечение системы состоит из системного и базового программного обеспечения и прикладного программного обеспечения.
Системное и базовое программное обеспечение:
В качестве операционной системы серверов баз данных используется: .
В качестве операционной системы клиентский ПК могут быть использованы: .
Прикладное программное обеспечение:
Прикладное программное обеспечение состоит из клиентских приложений, приложений формирования отчетов и печати и т.д.
Клиентское приложение АС Кадры:
Файловый состав приложения:
Главный Модуль.ехе — исполняемый файл приложения, отвечает за запуск клиентского приложения АС Кадры.
.
.

4 МЕРОПРИЯТИЯ ПО ПОДГОТОВКЕ ОБЪЕКТА АВТОМАТИЗАЦИИ К ВВОДУ СИСТЕМЫ В ДЕЙСТВИЕ

УКАЗАНИЯ ГОСТ:
В разделе «Мероприятия по подготовке объекта автоматизации к вводу системы в действие» приводят:
1) мероприятия по приведению информации к виду, пригодному для обработки на ЭВМ;
2) мероприятия по обучению и проверке квалификации персонала;
3) мероприятия по созданию необходимых подразделений и рабочих мест;
4) мероприятия по изменению объекта автоматизации;
5) другие мероприятия, исходящие из специфических особенностей создаваемых АС.

4.1 Приведение информации к виду, пригодному для обработки на ЭВМ

ФОРМАЛЬНОЕ СОДЕРЖАНИЕ:
Мероприятия по приведению информации к виду, пригодному для обработки на ЭВМ не проводятся.

4.2 Мероприятия по подготовке персонала

ПРИМЕР СОДЕРЖАНИЯ:
Необходимо составить следующие программы обучения:
– для пользователя системы;
– для администраторов системы.

Для сотрудников центрального представительства необходимо провести обучение по следующим дисциплинам:
— описание общей концепции АС Кадры;
— описание структуры АС Кадры;
— ввод данных в систему;
— т.д.;
— пр.
Для сотрудников региональных подразделения провести обучение по следующим дисциплинам:
— т.д.;
— пр.

4.3 Организация необходимых подразделений и рабочих мест

ПРИМЕР СОДЕРЖАНИЯ:
Наполнение раздела можно взять в документе «Схема организационной структуры».

4.4 Изменение объекта автоматизации

ПРИМЕР СОДЕРЖАНИЯ:
Система функционирует на базе СВТ Заказчика. Для организации новых рабочих мест проводятся строительно-монтажные и пуско-наладочные работы, включая:
— размещение оборудования;
— прокладка ЛВС;
— установка серверных приложений;
— установка клиентских приложений;
По завершению перечисленных работ составляется акт приемки в опытную эксплуатацию.

4.5 Дополнительные мероприятия

ПРИМЕР СОДЕРЖАНИЯ:
При подготовке объекта автоматизации существуют следующие дополнительные мероприятия:
— Импорт данных из старой системы в АС Кадры;
— Обновление импортированных данных.