Разработка технического задания на создание функционального модуля по учету выпуска обновлений стандартных компонентов в ООО "Корпоративные системы Плюс"

Опишем структуру таблиц схемы базы данных более подробно.

Таблица «Пользователь» предназначена для сохранения результатов о зарегистрированных в системе пользователей (сотрудников). Таблица содержит в себе такие данные как: логин и пароль, фамилия и имя, а также отдел и должность пользователя. В Таблице 7 представлена структура архитектуры данных таблицы «Пользователь».

Таблица 7 - Структура архитектуры данных таблицы «Пользователь»

№	Наименование поля в БД	Тип поля	Значение по умолчанию
1	ID_пользователя (PK)	Integer	NOT NULL
2	Логин	Text (18)	NULL
3	Пароль	Text (10)	NULL
4	Фамилия	Text (40)	NULL
5	Имя	Text (20)	NULL
6	Отдел	Text (35)	NULL
7	Должность	Text (30)	NULL

Таблица «Обновление» предназначена для именования файлов обновления, а также их описания. Таблица содержит в себе такие данные как: наименование обновления, его дату и время выпуска, комментарий к обновлению, информацию о разработчике (ID). В Таблице 8 представлена структура архитектуры данных таблицы «Обновление».

Таблица 8 - Структура архитектуры данных таблицы «Обновление»

№	Наименование поля в БД	Тип поля	Значение по умолчанию
1	Код обновления	Integer	NOT NULL
2	Наименование	Text (18)	NULL
3	Дата выпуска	Text (10)	NULL
4	Время выпуска	Text (40)	NULL
5	Комментарий	Text (20)	NULL
6	ID_разработчика (FK)	Integer	NOT NULL
7	ID_пользователя (FK)	Integer	NOT NULL

Таблица «Разработчик» предназначена для сохранения результатов о зарегистрированных в системе разработчиках (сотрудников). Таблица содержит в себе такие данные как: логин и пароль, фамилия и имя, а также отдел и должность разработчика. В Таблице 9 представлена структура архитектуры данных таблицы «Разработчик».

Таблица 9 - Структура архитектуры данных таблицы «Разработчик»

№	Наименование поля в БД	Тип поля	Значение по умолчанию
1	ID_разработчика (PK)	Integer	NOT NULL
2	Логин	Text (18)	NULL
3	Пароль	Text (10)	NULL
4	Фамилия	Text (40)	NULL
5	Имя	Text (20)	NULL
6	Отдел	Text (35)	NULL
7	Должность	Text (30)	NULL

Архитектура приложения. Приложение по учету выпуска обновлений будет реализовано в среде разработки Visual C++ в виде программного модуля. Функциональные подмодули будут определены в рамках документов технического и эскизного проекта, а также в проектной документации на модуль учета.

В соответствии со сформированными требованиями к модулю, для осуществления удобного и эффективного взаимодействия пользователя с системой был разработан пользовательский интерфейс [19].

Описание интерфейса

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

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

Форма авторизации представляет собой всплывающее окно, с полями для ввода логина и пароля.

Кнопка Ok, расположенная в нижней части формы, позволяет пользователю, после ввода данных, выполнить Вход в систему. В случае если данные учетной записи были введены неверно, система выдаст сообщение об ошибке. Форма сообщения Ошибка авторизации представлена на Рисунке 10. Закрытие формы Ошибка авторизации позволит пользователю вернуться к повторному вводу данных.

Кнопка Отмена позволяет очистить введенные данные. Для полного закрытия Формы авторизации в верхней правой ее части расположена кнопка Закрыть.

Рисунок 8 - Форма авторизации

Рисунок 9 - Форма сообщения Ошибка авторизации

На главной форме системы расположена Новостная лента выпуска обновлений.

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

Рисунок 10 - Главная форма пользователя



Рисунок 11 - Главная форма разработчика

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

Кнопка Скачать позволит разработчику сохранить файлы обновлений к себе в компьютер, с указанием пути его сохранения. Файлы обновлений хранятся в системе в формате rar.

Горящие клавиши Показать обновления, в зависимости от выбранного срока, позволят отобразить более ранние выпуски файлов обновлений.

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

Кнопка Добавить обновление расположена в правом верхнем углу главной формы. При нажатии на нее, на экране отображается Форма новое обновление Рисунок 13.



Рисунок 12 - Форма новое обновление

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

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

Кнопка Прикрепить файл позволит, непосредственно, загрузить файлы обновлений с компьютера. Загруженные файлы отобразятся в дополнительном окне Формы новое обновление Рисунок 14. Это окно позволяет просматривать файлы для отправки, в случае ошибочной загрузки - удалять из списка к отправке.



Рисунок 13 - Новое обновление. Загрузка файлов обновлений Кнопка Отправить разместит новое оповещение в новостной ленте, с указанием автора выпуска, даты/времени, комментарием, количеством прикрепленных файлов

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

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

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

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

Рисунок 14 - Выход из системы

Описание Системы на концептуальном уровне представлено на Рисунке 6.

Рисунок 15 - Описание Системы на концептуальном уровне

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

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

Модуль учета выпуска обновлений построен на базе платформы MS VC++,. Исходя из архитектуры платформы, на системном уровне система создана на основе клиент-серверной технологии и состоит из следующих компонентов:

• сервер БД;

• пользовательское рабочее место.

Сервер БД и пользовательские рабочие места связаны через локальную сеть, посредством организации защищенного соединения.

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

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

• подсистема авторизации пользователей;

• подсистема хранения объектов (хранилище);

• подсистема создания, редактирования и исполнения объектов в системе;

• подсистема оповещений, в том числе и во внешние информационные системы;

• подсистема справочной информации; ? подсистема безопасности.

Взаимодействие подсистем происходит в рамках единой информационной системы модуля. Связь с внешними приложениями осуществляется посредством коммуникационного протокола SOAP.

В качестве серверной операционной системы возможно использовать серверную операционную систему семейства Windows: ? MS Windows Server 2005;

• MS Windows Server 2008.

Для всех компонентов системы используется единое средство хранения данных БД My SQL. Такой способ организации хранилища позволяет хранить данные в файлах и каталогах.

Пользовательский интерфейс системы организован с помощью программных форм, доступных в приложении. Использование технологии VC++ позволяет хранить пароли в системе, осуществлять продуктивное взаимодействие с приложением.

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

Заключение

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

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

Предпроектное обследование (анализ предметной области) позволило сформулировать управленческое решение о целесообразности разработки собственной системы для ООО «Корпоративные системы Плюс».

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

В работе активно использовались такие методологии проектирования как MS Visio и ERwin Data Modeler. Что позволило в полной мере представить функции системы, участников и взаимодействие между ними, а также описать документооборот основного бизнес-процесса.

Литература

1. Корпоративные системы Плюс [Электронный ресурс] Режим доступа: http://sike.ru/about , свободный;

2. ГОСТ 34.602-89. Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

3. ГОСТ 19.201-78. Техническое задание. Требования к содержанию и оформлению.

4. ГОСТ 7.1-2003. Библиографическая запись. Библиографическое описание. Общие требования и правила составления.

5. ГОСТ 34.03-90. Информационные технологии. Комплекс стандартов на автоматизированные системы. Термины и определения.

6. Википедия [Электронный ресурс] Режим доступа: https://ru.wikipedia.org/wiki/%C2%E8%EA%E8%EF%E5%E4%E8%FF

7. ИНТЕРФЕЙС: Информационные технологии [Электронный ресурс] / Система электронного документооборота «БОСС-Референт», - Режим доступа: http://interface-kzn.ru/products-and-solutions/30/174/ , свободный.

8. Электронные офисные системы [Электронный ресурс] / Система электронного документооборота «ДЕЛО», - Режим доступа: http://www.eos.ru/eos_products/eos_delo/, свободный

9. Е1: ЕВФРАТ [Электронный ресурс] / Система электронного документооборота и автоматизации бизнес-процессов «ЕВФРАТ», - Режим доступа: http://www.evfrat.ru/?utm_expid=70481137-22.tTulRtoYRdOhwMcOyngq6w.0, свободный.

10. Летограф: управление документами, автоматизация бизнес-процессов, интеграция приложений [Электронный ресурс] / Система электронного документооборота «Летограф», - Режим доступа: http://www.letograf.ru/, свободный

11. МОТИВ: Система оперативного управления компанией [Электронный ресурс] / Система электронного документооборота и контроля исполнения поручений «МОТИВ», - Режим доступа: http://www.tribuna.ru/publications/sied-motiv.html, свободный

12. InterTrust [Электронный ресурс] / Система электронного документооборота «CompanyMedia», - Режим доступа: http://www.intertrust.ru/products/companymedia/, свободный

13. DIRECTIUM [Электронный ресурс] / Система электронного документооборота с расширенным функционалом «DIRECTIUM», - Режим доступа: http://www.directum.ru/, свободный

14. Docsvision: Комплексная автоматизация управления [Электронный ресурс] / Система электронного документооборота «Docsvision», - Режим доступа: http://www.docsvision.com/, свободный

15. Rissoft: Промышленные информационные системы [Электронный ресурс] / Система электронного документооборота «Globus Professional», - Режим доступа: http://www.rissoft.ru/, свободный

16. LanDocs [Электронный ресурс] / Программная платформа построения корпоративных систем управления контентом и электронного документооборота «LanDocs», - Режим доступа: http://www.docva.ru/offer/intro/, свободный

17. Э.Р. Ипатова, Ю.В. Ипатов Практикум по проектированию информационных систем. Магнитогорск, 2004. 116 с.

18. Г.Н. Калянов Информационные системы [Электронный ресурс] / Построение архитектуры предприятия, - Режим доступа: http://www.management.com.ua/ims/ims110.html

19. АИС: Академия информационных систем [Электронный ресурс] / Проектирование пользовательских интерфейсов, - Режим доступа: http://infosystems.ru/index.php?id=6519

Приложение А

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

ТЕХНИЧЕСКОЕ ЗАДАНИЕ на разработку Модуля учета выпуска обновлений в ООО «Корпоративные системы Плюс»

СПИСОК ПРИНЯТЫХ СОКРАЩЕНИЙ

АС - Автоматизированная система

ПС - Программное средство

АСУ - Автоматизированная система управления

БД - База данных

НСД - Несанкционированный доступ

1. ОБЩИЕ СВЕДЕНИЯ

Настоящее Техническое задание на создание Модуля учета выпуска обновлений для ООО «Корпоративные системы Плюс» разработано в соответствии с ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы».

В настоящем Техническом задании описаны общие требования к Системе в целом. Требования к отдельным компонентам Системы должны быть разработаны в рамках Частных технических заданий.

1.1 ПОЛНОЕ НАИМЕНОВАНИЕ И УСЛОВНОЕ ОБОЗНАЧЕНИЕ СИСТЕМЫ

1.1.1 Полное наименование

Полное наименование системы: «Модуль учета выпуска обновлений».

1.1.2 Краткое наименование

Краткое наименование системы: «Модуль учета».

1.2 НАИМЕНОВАНИЕ ЗАКАЗЧИКА И ИСПОЛНИТЕЛЯ, ИХ РЕКВИЗИТЫ

1.2.1 Наименование заказчика

Заказчик: IT-компания ООО «Корпоративные системы Плюс» Юридический адрес заказчика:

г. Магнитогорск, ул. Завенягина, 1/2

Телефон: +7 (902) 865-40-04

E-mail: info@sike.ru

1.2.2 Наименование исполнителя

Исполнитель: ООО «Специалист ИС-Центр разработки» Юридический адрес исполнителя: г. Магнитогорск, пр. Ленина, 114

Телефон: (3519) 38-96-55

Факс: (3519) 38-49-38

1.3 ОСНОВАНИЕ ДЛЯ РАЗРАБОТКИ

Основанием для проведения работ по созданию Модуля послужил Договор № 239325 от 16.02.2014 г. между IT-компанией ООО «Корпоративные системы Плюс»и ООО «Специалист ИСЦентр разработки».

1.4 СВЕДЕНИЯ ОБ ИСТОЧНИКАХ И ПОРЯДКЕ ФМНАНСИРОВАНИЯ

1.4.1 Источник финансирования

Источником финансирования является IT-компания ООО «Корпоративные системы Плюс».

1.4.2 Порядок финансирования

Финансирование производится в соответствии с Договором № 239325

1.5 ПЛАНОВЫЕ СРОКИ НАЧАЛА И ОКОНЧАНИЯ РАБОТ

Сроки проведения работ по созданию Модуля определены Договором № 239325:

• начало работ запланировано на 16.03.2014 г.;

• создание Системы планируется произвести в течение 2,5 месяцев;

• окончание работ определено не позднее 29.05.2014 г.

1.6 ПОРЯДОК ОФОРМЛЕНИЯ И ПРЕДЪЯВЛЕНИЯ РЕЗУЛЬТАТОВРАБОТ

1.6.1 Выполнение работ по разработке Модуля

Порядок выполнения, оформления и предъявления результатов работ регламентирован комплексом стандартов и руководящих документов:

• ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания»;

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

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

1.6.2 Сроки предъявления результатов работ Результаты предъявления работ по созданию Модуля определены Договором № 239325.

Разработка Системы должна быть проведена в 3 этапа, по окончанию работ на каждом из этапов Заказчику должен быть представлен сводный отчет о проделанной работе:

• предпроектное обследование - не более 2 недель; ? проектирование/создание АС - не более 1 месяца; ? послепроектная стадия - не более 3 недель.

1.6.3 Приемка результатов работ

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

2. НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ СИСТЕМЫ

2.1 НАЗНАЧЕНИЕ СИСТЕМЫ

2.1.1 Функциональное назначение

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

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

• несвоевременный обмен информацией в процессе выпуска обновлений между отделами;

• дублирование и несовместимость обновлений; ? трудоемкость выпуска обновлений.

2.1.2 Эксплуатационное назначение

При создании Модуля должны быть решены следующие задачи:

• обеспечение информационной поддержки по всем видам вопросов процесса выпуска обновлений для сотрудников компании;

• создание условий для осуществления контроля по установке выпущенных обновлений;

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

• обеспечение надежной защиты содержащихся в Модуле данных о выпущенных ранее обновлениях.

2.2 ЦЕЛИ СОЗДАНИЯ СИСТЕМЫ

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

• снижение трудовых и временных затрат на разработку обновлений;

• формирование полного и достоверного отчета по процессу выпуска обновлений за установленные сроки.

3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ

3.1 СВЕДЕНИЯ ОБ ОБЪЕКТЕ АВТОМАТИЗАЦИИ

3.1.1 Объект автоматизации

Объектом автоматизации является деятельность отделовпрограммирования и обучающих систем компании «Корпоративные системы Плюс». 3.1.2 Общие сведения об объекте автоматизации

Отдел обучающих систем и отдел программирования являются структурными подразделениями компании «Корпоративные системы Плюс». Всего в организации 5 отделов.

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

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

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

3.2 СВЕДЕНИЯ ОБ УСЛОВИЯХ ЭСПЛУАТАЦИИ ОБЪЕКТА АВТОМАТИЗАЦИИ

3.2.1 Общая характеристика используемых программных и технических средств

Состав используемого общесистемного программного обеспечения приведен в Таблице 1.

Таблица 10 - Общесистемное программное обеспечение

Тип программного средства	Название ПС
Офисные программные средства общего назначения	Программы обработки текстов: Microsoft Office 2010; Corel WordPerfect Office. Программы планирования рабочего времени (органайзеры): MS Outlook. Телекоммуникационные программы: Terminal; Microsoft At Work PC Fax. Средства деловой графики: Microsoft Visio 2010; ? 3Ds max 2008. Система управления реляционными базами данных: Microsoft SQL Server 2005/2008
Информационно-поисковые системы	Поисковые системы Интернет
Системы автоматизированного проектирования	Autodesk
ПО решения задач прикладной математики и статистики	MatLab;Matematica
Системы программирования	Visual C++; Delphi XE

В состав технического обеспечения компании входят:

1. Средства сбора и регистрации информации (персональные компьютеры для ввода информации документов и записи ее на носители; сканеры для автоматического считывания данных с документов и их преобразования в графическое, цифровое и текстовое представление);

2. Комплекс средств передачи информации (компьютерная локальная сеть; GPS связь);

3. Средства хранения данных (оптические диски CD, DVD; USB-накопители; жесткие диски);

4. Средства обработки данных или компьютеры (ноутбуки; карманные компьютеры);

5. Средства вывода информации (мониторы; принтеры);

6. Средства организационной техники (средства изготовления, копирования, обработки и уничтожения документов).

4. ТРЕБОВАНИЯ К СИСТЕМЕ

4.1 ТРЕБОВАНИЯ К СИСТЕМЕ В ЦЕЛОМ

4.1.1 Требования к структуре и функционированию Модуля учета

В соответствии с требованиями Заказчика Система должна представлять собой АСУ между подразделениями компании (отдел обучающих систем и отдел программирования). При создании Модуля необходимо адаптировать для использования ранее созданное и эксплуатируемое в настоящее время в подразделениях компании программное обеспечение и данные.

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

4.1.1.1 Техническая архитектура Модуля

Модуль должен быть реализован в соответствии с двухуровневой архитектурой (клиент-сервер).

Соответственно, в основе технической архитектуры должны быть следующие компоненты:

4. Компонент управления базой данных;

5. Компонент обработки данных (прикладной логики или бизнес-логики); 6. Компонент представления (визуализации) данных.

Ядром архитектуры Модуля является компонент управления БД, реализованный с использованием СУБД Access. Основным назначением данного компонента является управление данными таблиц, на основании правил поддержании ссылочной целостности. Второй компонент реализуется с помощью запросов и средств автоматизации обработки данных -- макросов и процедур VBA. Третий компонент представляет собой формы, отчеты, страницы доступа к данным, объединенные в единый интуитивно понятный и легкодоступный пользователю АС интерфейс с помощью панелей команд, макросов и процедур.

На Рисунке 15 изображено графическое представление двухуровневой клиент-серверной архитектуры.

Рисунок 16 - Двухуровневая архитектура

4.1.1.2 Требования к программно-аппаратному комплексу Модуля

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

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

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

Обмен данных должен осуществляться посредством файлов в формате Rar.

4.1.2 Требования к численности и квалификации персонала системы

Общими требованиями к численности и квалификации персонала Модуля и режиму его работы являются:

4.1.2.1 Эксплуатация программного комплекса должна осуществляться персоналом, имеющим численность и квалификацию для выполнения работ в соответствии с ролями, перечисленными ниже (Таблица 2).

4.1.2.2 Для эксплуатации программного комплекса необходимо выполнение следующих ролей:

• системный администратор;

• администратор безопасности;

• администратор баз данных;

• инженер технической поддержки.

Таблица 11 - Роли эксплуатирующего персонала Модуля учета

Роли	Выполняемые функции
Системный администратор	обеспечение бесперебойного функционирования системы в целом управление программно-аппаратным комплексом
Администратор безопасности	обеспечение информационной безопасности обеспечение от несанкционированного доступа к информационным ресурсам
Администратор базы данных	обеспечение функционирования БД резервное копирование БД восстановление БД в случае сбоя мониторинг основных показателей функционирования БД настройка и оптимизация производительности БД
Инженер технической поддержки	установка, настройка и поддержка оборудования и специального программного обеспечения

4.1.2.3 Режим работы персонала, эксплуатирующего программный комплекс - в установленное рабочее время.

4.1.2.4 Пользователями Модуля могут быть сотрудники отделов обучающих систем и программирования.

4.1.3 Показатели назначения

4.1.3.1 Степень приспособляемости системы к изменению процессов и методов управления:

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

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

4.1.3.2 Производительность системы

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

4.1.4 Требования к надежности

Общими требованиями к надежности Модуля являются:

4.1.4.1 Программно-технический комплекс Модуля должен функционировать в течение рабочего дня ООО «Корпоративные системы Плюс» (8 часов), в непрерывном режиме, кроме времени проведения работ по резервному копированию данных, восстановлению данных, смене версий программного комплекса, других профилактических работ по техническому обслуживанию, требующих остановку технических средств.

4.1.4.2 Должно производиться регулярное (не реже одного раза в сутки) резервное копирование БД. Необходимо наличие как минимум двух резервных копий всех данных. Данные копии должны храниться в физически удаленных местах.

4.1.4.3 Неправильные действия пользователей не должны приводить к возникновению аварийной ситуации.

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

4.1.4.5 Требования к надежности Модуля должны быть уточнены в документации Технического проекта.

4.1.5 Требования к безопасности

4.1.5.1 К эксплуатации оборудования Модуля должен допускаться персонал, имеющий достаточную теоретическую и практическую подготовку. Эксплуатационная документация должна содержать указания по безопасности при эксплуатации и техническом обслуживании.

4.1.5.2 Условия эксплуатации объекта автоматизации и характеристики окружающей среды определяются в соответствии с Гигиеническими требованиями к терминалам, персональным электронно-вычислительным машинам и организации работы (СанПиН 2.2.2/2.4.1340-03).

4.1.5.3 Технические средства, входящие в состав Системы, должны удовлетворять требованиям ГОСТ 12.1.002-84 по уровням напряженности электрических полей.

4.1.5.4 Уровень шума на рабочих местах пользователей и обслуживающего персонала, создаваемый оборудованием, должен соответствовать требованиям, установленным ГОСТ 12.1.003-83.

4.1.6 Требования к эргономике и технической эстетике

4.1.6.1 Структура размещения информации и представление этой структуры в программном комплексе должны соответствовать следующим требованиям:

• пункты меню в пользовательских интерфейсах должны быть сгруппированы в соответствии с тематикой информации, функциональными задачами и технологией работы;

• каждому пункту меню должна соответствовать только одна выполняемая функция;

• действие должно выполняться только одним способом;

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

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

4.1.7 Требования к защите информации от несанкционированного доступа

4.1.7.1 Общие требования

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

• защищенный обмен информацией между различными компонентами Системы;

• на этапе технического проектирования должны быть разработаны модель нарушителя и модель угроз Системы;

• на основании анализа моделей должны быть определены уровни и механизмы криптозащиты информации, а также уровень защиты информации в каналах связи в зависимости от конкретных условий;

• конкретные требования по информационной безопасности должны уточняться на этапе технического проектирования;

• в компонентах системы должно быть обеспечено использование доверенной программно-аппаратной среды;

• все применяемые в системе не криптографические средства защиты информации должны быть сертифицированы на соответствие требованиям РД ФСТЭК России;

• в состав средств защиты от НСД должны входить современные аппаратные и программные комплексы, ориентированные на применение новых методов обеспечения информационной.

4.1.7.2 Требования по защите информации от утечки по техническим каналам связи

Для элементов системы, обрабатывающих конфиденциальную информацию, должны выполняться требования документа СТР-К-2002 г. ФСТЭК России.

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

• при проведении монтажных, пуско-наладочных работ;

• во время испытаний и штатной эксплуатации;

• при использовании штатных и привлекаемых средств обеспечения.

4.1.7.3 Требования к организационным мероприятиям по защите информации Для объектов автоматизации должны быть:

• разработана политика безопасности (совокупность норм и правил, регламентирующих взаимодействие субъектов и объектов системы);

• разработаны должностные инструкции пользователей по информационной безопасности;

• проведено обучение пользователей;

• разработаны правила эксплуатации технических и программных средств защиты информации и правила работы с конфиденциальной информацией;

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

4.1.8 Требования по сохранности информации при авариях

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

• отказ аппаратуры сервера;

• отключение питания на рабочем месте и/или на сервере БД; ? отказ оборудования рабочей станции.

Для обеспечения сохранности информации Модуля должно использоваться:

резервное копирование;

• восстановление данных в непротиворечивое состояние при программно-аппаратных сбоях, влекущих внеплановую остановку специального программного обеспечения или его компонент, таких как остановка системы при отключении электрического питания, сбоях операционной системы и других;

• восстановление данных в непротиворечивое состояние при сбоях в работе сетевого, программного и аппаратного обеспечения.

Резервное копирование, архивирование и восстановление данных должно осуществляться с использованием стандартных средств СУБД и сервера приложений в соответствии с утвержденным регламентом.

Меры по обеспечению сохранности информации при авариях должны быть описаны в документации Технического проекта.

4.2 ТРЕБОВАНИЯ К ФУНКЦИЯМ (ЗАДАЧАМ), ВЫПОЛНЯЕМЫМ СИСТЕМОЙ

Детальное описание требований к функциямМодуля должно быть представлено в документах технического проекта.

При работе с Системой сотрудники отдела обучающих систем должны иметь возможность реализовать следующие функции и задачи:

• вход в Систему обновлений;

• просмотр новостной ленты доступных обновлений;

• сохранение на компьютер рабочего места нового пакета обновлений;

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

Графическое представление интерфейса программы, с наличием вышеперечисленных требований изображено на Рисунке.

Рисунок 17 - Интерфейс пользователя Системы

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

• вход в Систему обновлений;

• просмотр новостной ленты доступных обновлений;

• сохранение на компьютер рабочего места нового пакета обновлений;

• информационное взаимодействие с сотрудником технической поддержки;

• загрузка/редактирование/удаление файлов обновлений в новостной ленте Системы.

Графическое представление интерфейса программы, с наличием вышеперечисленных требований изображено на Рисунке.

Рисунок 18 - Интерфейс разработчика Системы

Описание Системы на концептуальном уровне представлено на Рисунке

Рисунок 19 - Описание Системы на концептуальном уровне

4.2.1 Требования к обработке данных

Модуль должен обеспечивать:

1. Обработку и выдачу информации на основе поиска пользователя;

2. Обработку и выдачу информации на основе критериев формирования отчета ответственного лица;

3. Обработку запросов в составе клиентской части.

4.3 ТРЕБОВАНИЯ К ВИДАМ ОБЕСПЕЧЕНИЯ

4.3.1 Требования к информационному обеспечению

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

Уровень хранения данных в системе должен быть построен на основе реляционной СУБДAccess. Для обеспечения целостности данных должны использоваться встроенные механизмы СУБД.

Средства СУБД, а также средства используемых операционных систем должны обеспечивать документирование и протоколирование обрабатываемой в системе информации.

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

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

4.3.2 Требования к математическому обеспечению

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

4.3.3 Требования к лингвистическому обеспечению

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

Язык взаимодействия пользователя с Системой должен быть организован с помощью формализованного подмножества естественного языка.

Способ организации диалога с пользователем должен обеспечивать: ? минимизацию случайных ошибочных действий оператора; ? логический контроль ввода данных.

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

4.3.4 Требования к программному обеспечению

Общее (системное) программное обеспечение программных комплексов Модуля должно соответствовать следующим основным принципам:

• использование сертифицированных программных средств, обеспечивающих реализацию требований, предъявляемых к комплексной системе защиты информации;

• минимальная номенклатура используемых программных средств;

• масштабируемость и высокая производительность;

• совместимость;

• наличие встроенной системы безопасности;

• надежность и отказоустойчивость;

• наличие механизмов поддержки коммуникационных средств.

Сетевые ОС должны позволять организовать работу пользователя на рабочих станциях в рамках одной локальной сети, иметь встроенные средства электронной почты, обеспечивать возможность реализации Intranet-технологий, систем электронного документооборота, отвечать требованиям контроля доступа к ресурсам системы.

4.3.5 Требования к техническому обеспечению

Комплекс технических средств Модуля учета должен обладать вычислительной мощностью, достаточной для:

• хранения и обработки требуемых объемов информации;

• устойчивой работы в условиях пиковой нагрузки;

• обслуживания пользователей Системы с приемлемым временем отклика Системы.

Типовые конфигурации должны строиться на основе стандартизованных элементов:

• стационарное автоматизированное рабочее место сотрудника подразделения;

• мобильное автоматизированное рабочее место сотрудника подразделения;

• сервер БД;

• серверы специальных технологий (Web-сервер, централизованное страховочное копирование данных и т.п.);

• сервер телекоммуникаций/почтовый сервер;

• внешний дисковый массив, обслуживающий сервер или группу серверов;

• автоматизированные рабочие места администраторов Системы.

4.3.6 Требования к организационному обеспечению

При создании Системы должны быть разработаны организационно-распорядительные документы регламентирующие:

• порядок эксплуатации системы;

• работу пользователей с элементами системы; ? модернизацию и развитие системы.

Организационная структура Системы должна предусматривать:

• проведение скоординированных мероприятий по управлению Системой;

• подбор и назначение персонала Системы соответствующего установленным квалификационным требованиям;

• подготовку персонала по вопросам эксплуатации и администрирования Системы, использования средств защиты информации, криптографических средств и т.п.;

• соблюдение правил техники безопасности персоналом Системы.

4.3.6.1 Функционирование Модуля должно обеспечиваться сотрудниками компании. 4.3.6.2 Обработка информации выполняется пользователями программно- технического комплекса Модуля самостоятельно, при наличии соответствующих полномочий и в соответствии с утвержденным регламентом.

4.3.6.3 Контроль над обработкой информации осуществляют руководители соответствующих подразделений компании.

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

4.3.6.5 Установка и обновление программно-технического комплекса Модуля должны выполняться обслуживающим персоналом соответствующих подразделений компании.

5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО СОЗДАНИЮ СИСТЕМЫ

Состав и содержание этапов по созданию Модуля учета определяется в соответствии с ГОСТ 34.601-90«Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания».

Работы по созданию Системы должны быть проведены в 3 этапа. Последовательность этапов и состав работ на стадиях разработки Системы представлены в Таблице.

Таблица 12 - Стадии создания АС

Стадии		Состав работ
1. Формирование требований к АС	1.1. 1.2. 1.3.	Обследование объекта и обоснование необходимости создания АС Формирование требований пользователя к АС Оформление отчёта о выполненной работе и заявки на разработку АС (тактико-технического задания)
2. Разработка концепции АС	2.1. 2.2. 2.3. 2.4.	Изучение объекта Проведение необходимых научно-исследовательских работ Разработка вариантов концепции АС, удовлетворяющего требованиям пользователя Оформление отчёта о выполненной работе
3. Техническое задание		Разработка и утверждение технического задания на создание АС.
4. Эскизный проект	4.1. 4.2.	Разработка предварительных проектных решений по системе и её частям Разработка документации на АС и её части
5. Технический проект	5.1. 5.2. 5.3. 5.4.	Разработка проектных решений по системе и её частям Разработка документации на АС и её части Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку Разработка заданий на проектирование в смежных частях проекта объекта автоматизации
6. Рабочая документация	6.1. 6.2.	Разработка рабочей документации на систему и её части Разработка или адаптация программ
7. Ввод в действие	7.1. 7.2. 7.3. 7.4. 7.5. 7.6. 7.7. 7.8.	Подготовка объекта автоматизации к вводу АС в действие Подготовка персонала Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями) Строительно-монтажные работы Пусконаладочные работы Проведение предварительных испытаний Проведение опытной эксплуатации Проведение приёмочных испытаний
8. Сопровождение АС	8.1. 8.2.	Выполнение работ в соответствии с гарантийными обязательствами Послегарантийное обслуживание

Предварительная длительность по разработке Системы была определена в программном средстве MS Project. Результаты ожидаемой длительности представлены на Рисунке.

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Рисунок 20 - Ожидаемая длительность по созданию Модуля учета

6. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ СИСТЕМЫ

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

В соответствии с требованиями ГОСТ 34.601-90 испытания проводят на стадии «Ввод в действие» с целью проверки соответствия создаваемой системы требованиям технического задания и частных технических заданий на подсистемы.

Для обеспечения проведения испытаний создается комиссия. В состав комиссии входят представители Заказчика и Исполнителя.

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

Для проверки выполнения заданных функций системы устанавливаются следующие виды испытаний:

• предварительные испытания; ? опытная эксплуатация;

• приемочные испытания.

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

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

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

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

При испытаниях системы необходимо проверить:

• качество выполнения комплексом программных и технических средств своих функций во всех режимах функционирования системы согласно техническому заданию;

• знание персоналом эксплуатационной документации и наличие у него навыков, необходимых для выполнения установленных функций во всех режимах функционирования системы, согласно техническому заданию;

• полноту содержащихся в эксплуатационной документации указаний персоналу по выполнению им функций во всех режимах функционирования

• системы согласно техническому заданию;

• количественные и/или качественные характеристики выполнения автоматизированных функций системы в соответствии с техническим заданием;

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

6.2 ПРЕДВАРИТЕЛЬНЫЕ ИСПЫТАНИЯ

Предварительные испытания системы должны проводиться в 2 этапа:

автономные испытания;

комплексные испытания.

6.2.1 Предварительные автономные испытания

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

• перечень функций, подлежащих испытаниям;

• описание взаимосвязей объекта испытаний с другими частями системы;

• условия, порядок и методы проведения испытаний и обработки результатов;

• критерии приемки частей системы по результатам испытаний.

К программе автономных испытаний прилагается график проведения автономных испытаний.

Подготовленные и согласованные с Заказчиком тесты методики испытаний на этапе автономных испытаний должны обеспечить:

• полную проверку функций и процедур по перечню, согласованному с Заказчиком;

• необходимую точность вычислений, установленную в техническом задании;

• проверку основных временных характеристик функционирования программных средств;

• проверку надежности и устойчивости функционирования программных и технических средств.

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

Результаты автономных испытаний частей системы фиксируются в протоколах испытаний. Протокол должен содержать заключение о возможности (невозможности) допуска части системы к комплексным испытаниям. Акт о допуске системы к предварительным комплексным испытаниям создается в случае, если в протоколах испытаний всех составных частей Системы содержится заключение о возможности допуска к комплексным испытаниям.

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

6.2.2 Предварительные комплексные испытания

Предварительные комплексные испытания проводят с целью определения работоспособности Системы в целом и решения вопроса о возможности ее приемки в опытную эксплуатацию.

Предварительные комплексные испытания Системы производятся на основании программы и методики испытаний в сроки, согласованные с Заказчиком.

Результаты испытаний отражают в протоколе. Работу завершают оформлением акта приемки в опытную эксплуатацию.

В программе комплексных испытаний указывают:

• перечень объектов испытания;

• состав предъявляемой документации;

• описание проверяемых взаимосвязей между объектами испытаний;

• очередность испытаний частей системы;

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

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

• программа комплексных испытаний;

• заключение по автономным испытаниям соответствующих частей системы и устранение ошибок и замечаний, выявленных при автономных испытаниях;

• методика испытаний;

• программные и технические средства и соответствующая им эксплуатационная документация.

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

Комплексные тесты методики испытаний должны:

• быть логически увязанными;

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

• в том числе всех связей между ними;

• обеспечивать проверку реакции системы на некорректную информацию и аварийные ситуации.

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

После устранения недостатков проводят повторные комплексные испытания в необходимом объеме.

В результате проведения предварительных комплексных испытаний оформляются следующие документы:

• Протоколы предварительных испытаний;

• Акт приемки в опытную эксплуатацию;

• Акт сдачи-приемки работ.

6.3 ОПЫТНАЯ ЭКСПЛУАТАЦИЯ

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

Для проведения опытной эксплуатации системы Заказчик издает приказ о проведении опытной эксплуатации с указанием ответственных лиц и мест ее проведения.

Опытную эксплуатацию проводят в соответствии с программой, в которой указывают:

• условия и порядок функционирования частей системы и системы в целом;

• продолжительность опытной эксплуатации, достаточную для проверки правильности функционирования системы при выполнении каждой функции системы и готовности персонала к работе в условиях функционирования системы;

• порядок устранения недостатков, выявленных в процессе опытной эксплуатации.

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

...