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

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

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

Введение

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

Руководствующими стандартами при написании технического задания являются ГОСТ 34.602.89 «Техническое задание на создание автоматизированной системы» [2] и ГОСТ 19.201-78 «Техническое задание [3]. Требования к содержанию и оформлению». В первом случае стандарт предназначен для автоматизации различных видов деятельности (управление, проектирование, исследование и т. п.), включая их сочетания, и устанавливает состав, содержание, правила оформления документа «Техническое задание на создание (развитие или модернизацию) системы». Во втором случае стандарт устанавливает непосредственно порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения.

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

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

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

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

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

Для достижения поставленной цели необходимо решение следующих задач:

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

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

3) выполнить разработку и обоснование концепции и проектных решений по видам обеспечения модуля учета;

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

Материалы работы были апробированы на XXI Студенческой международной научно-практической конференции (научное сообщество студентов XXI столетия, раздел экономических наук, г. Новосибирск, СиБАК).

1. Обследование объекта информатизации

1.1 Технико-экономическая характеристика деятельности отдела обучающих систем

Направления и сфера деятельности компании

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

Сегодня деятельность компании концентрируется на следующих основных направлениях:

1. Автопарк

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

Задачи направления:

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

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

2. Зарплата и кадры

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

Задачи направления:

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

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

3. Обучающие системы

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

Задачи направления:

• накопление и передача производственного опыта;

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

4. Финансы и бухгалтерский учёт

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

Задачи направления:

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

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

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

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

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

Во главе компании стоит директор. Под его непосредственным руководством находится 5 отделов:

• «Автопарк»;

• «Зарплата и кадры»;

• «Обучающие системы»;

• «Финансы и бухгалтерский учет»; ? Программирования.

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

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

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

Таблица 1 - Организационная структура управления компании

		Директор
Начальник отдела «Автопарк»	Начальник отдела «Зарплата и кадры»	Начальник отдела Обучающих систем	Начальник отдела «Финансы и бухгалтерский учёт»	Начальник отдела Программирования

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

Организационная структура управления рассматриваемых отделов, смоделированная в MS Visio [6], представлена на Рисунке 1.

Рисунок 1 - Организационная структура управления отдела обучающих систем

Основные понятия и функции отдела Обучающих систем

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

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

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

Как было рассмотрено раннее (Рисунок 1), отдел обучающих систем состоит из трех бюро, каждое из которых имеет свои функции. Ниже представлены функции рассматриваемых бюро.

Основные функции бюро разработки тренажеров в области металлургии и нефтегазовой промышленности:

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

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

Основные функции бюро разработки тренажеров в области металлургии и машиностроении:

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

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

Основные функции бюро сопровождения и развития ИТ-проектов:

• доработка тренажеров, сданных в промышленную эксплуатацию (усовершенствование по желанию Заказчика, обновление компонентов и т.д.);

• ведение гарантийного сопровождения;

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

• доработка стандартных компонентов.

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

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

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

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

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

• Тестировщик (отдел программирования): исследование, испытание компонента, с целью получения информации о качестве продукта. Проверка на соответствие продукта технической документации.

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

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

Выпуск обновлений стандартных компонентов включает в себя 5 основных этапов: выявление проблемы, постановка задачи, выпуск файлов обновлений, тестирование, ручная рассылка по почте (оповещение об обновлении).

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

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

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

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

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

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

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

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

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

• входные - договор на оказание услуг (от заказчика), требования (от начальника бюро);

• внутренние - техническое задание, файл с замечаниями;

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

На Рисунке 2 представлен процесс выпуска обновлений «как есть» (as-is).

Рисунок 2 - Выпуск обновлений стандартных компонентов (as-is) В рамках поставленных цели и задач необходимо определить, что будет находиться в границах проекта информационной системы. Воспользуемся методикой «будет/не будет»

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

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

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

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

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

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

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

1.3 Анализ существующих ИТ-решений систем электронного документооборота

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

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

Важно, чтобы права доступа к защищенным данным были разграничены. Значительно сокращает время работы и автоматическое заполнение разделов типовых документов по существующим справочным данным. Руководителю важно иметь удобные средства контроля сроков исполнения задач и сводную отчетность. Для поддержания информативности в работе компании СЭД должна легко интегрироваться с существующей почтовой системой и с существующими в компании учетными системами (кадровыми, финансовыми, бухгалтерскими и системами управления производственной деятельностью).

Также все больше организаций обращают внимание на возможность удаленной работы в системе. К важным критериям оценки системы относятся возможность формирования отчетности по документам, исполнителям, статусам документов и др.; быстрое внедрение системы; стоимость установки и поддержки системы; простота развития системы; возможность использования программного обеспечения системы для решения дополнительных задач [6].

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

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

БОСС-Референт (БР). Разработчик «БОСС-Референт» входит в группу компаний IT. Предназначена для автоматизации управленческого документооборота и делопроизводства. Существует на рынке с 1996 года. Преимуществами системы являются использованием платформы IBM Lotus, высокотехнологичной архитектурой и длительным опытом внедрения [7].

ДЕЛО (Д). Разработчик - «Электронные Офисные Системы». Представляет собой промышленное решение для обеспечения автоматизации процессов делопроизводства. Выпущена в 1996 году. Первая отечественная система автоматизации документооборота, получившая государственный сертификат наивысшего качества ЦСЦР Госстандарта РФ [8].

ЕВФРАТ-Документооборот (ЕД). Разработчик - «Cognititve Technologies». Система позволяет реализовать разные схемы автоматизации работы с документами и автоматизировать ключевые бизнес-процессы организации. Существует на рынке с 1997 года. К основным преимуществам разработчики относят возможность использовать систему как коробочное, так и проектное решение [9].

ЛЕТОГРАФ (Л). Разработчик - «ЛЕТОГРАФ». Является комплексным решением для управления документами, автоматизации бизнес-процессов и интеграции приложений. Разрабатывается с 2004 года. К преимуществам относят webориентированность, гибкость настройки и готовность к развитию [10].

МОТИВ (М). Разработчик - «Мотив». Система представляется как инструмент управления предприятием. На рынке с 2004 года. Одним из основных преимуществ является сочетание в себе возможностей систем различных классов и понятный функционал [11].

CompanyMedia (CM). Разработчик - «ИнтерТраст». Является универсальной системой электронного документооборота. Выпущена в 1997 году. Преимуществами называют реализацию на IBM Lotus, функциональность и длительную промышленную эксплуатацию [12].

DIRECTUM (D). Разработчик - «DIRECTUM». Представляет собой систему электронного документооборота и управления взаимодействием. На рынке с 2003 года. К преимуществам относят широкую функциональность и простые принципы работы [13].

DocsVision (DV). Разработчик - «DocsVision», компания выделилась из «Digital Design». Система электронного документооборота, позволяющая решить задачи управления документами и процессами. Разрабатывается с 1998 года. Преимущества системы заключаются в разнообразии приложений и возможности развития функционала [14].

Globus Professional (GP). Разработчик - «Промышленные информационные системы». Является корпоративной системой для автоматизации деятельности компании. На рынке с 2006 года. К преимуществам системы относят высокую функциональность, масштабируемость и гибкость [15].

LanDocs (LD). Разработчик - «Ланит». Технологическая платформа для создания информационно-технологических решений. Разрабатывается с 1996 года.

Среди главных преимуществ: функциональность и масштабируемость [16].

Так как все вышеперечисленные СЭД обладают примерно одинаковым функциональным набором возможностей (управление электронными документами и деловыми процессами, отчетность и др.), обзор будет направлен, в первую очередь на работу, непосредственно, с документом, и, на не менее важный фактор при выборе СЭД, - стоимость.

В Таблице 2 представлен сравнительный обзор рассматриваемых СЭД по возможности поддержания полного жизненного цикла документов.

Таблица 2 - Возможность поддержания полного жизненного цикла документов

*1 - функция есть *0 - функция отсутствует	БР	Д	ЕД	Л	М	CM	D	DV	GP	LD
Регистрация документа	1	1	1	1	1	1	1	1	1	1
Ведение иерархической структуры документов	0	0	1	1	1	0	1	1	1	0
Ведение журналов работы с документами	0	1	1	1	1	1	0	0	1	1
Ведение номенклатуры дел	1	1	1	1	1	1	1	1	1	1
Сканирование документов	1	0	1	1	0	1	1	1	1	1
Совместимость с ПО, обеспечивающим распознавание образов документов	1	1	1	1	0	1	1	1	1	1
Переход на документ по ссылке	0	0	0	0	0	0	1	0	1	0
Наличие шаблонов создаваемых документов	1	1	1	1	1	0	1	1	1	1
Ведение истории работы с документами	1	1	0	1	0	0	1	1	1	1
Маршрутизация	1	1	1	0	1	1	1	1	1	0
Работа с поручениями контроль	1	1	1	1	1	1	1	1	1	1
Поиск документов по различным параметрам	0	0	1	0	0	0	1	0	0	0
Разграничение прав доступа	1	1	1	1	1	1	1	1	1	1
Ведение архивов электронных документов	1	0	1	0	1	1	0	0	1	1
Генерация отчетов	1	1	1	1	1	0	1	1	1	1

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



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

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

Рисунок 3 - Возможность поддержания полного жизненного цикла документов

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

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

• Регистрация документа;

• Ведение истории работы с документами;

• Поиск документов по различным параметрам;

• Разграничение прав доступа;

• Ведение архивов электронных документов.

Далее проведем обзор рассматриваемых СЭД по ценовой политике, а также полноте наполнения предлагаемых пакетов ПО. Результаты обзора представлены в Таблице 3.

Таблица 3 - Доступность и затраты на обслуживание

Как видно из Таблицы 3, стоимость систем варьируется достаточно в ощутимых пределах. Как и ранее, для наглядности, построим диаграмму цен, с учетом полного комплекта пакета ПО.

Рисунок 4 - Доступность и затраты на обслуживание

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

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

Рассмотренные системы позволили отследить функционал возможностей работы с документами, оценить затраты на предполагаемые варианты систем. В рамках рассматриваемой задачи можно сделать вывод о том, что выбор ООО «Корпоративные системы Плюс» в пользу собственной разработки является вполне целесообразным. Большая часть функционала СЭД не является необходимой для поддержания основного бизнес-процесса. Из этого также следует вывод о том, что столь высокие затраты на внедрение полномасштабной системы будут абсолютно нерентабельны.

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

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

2. Разработка проектных решений

2.1 Разработка концепции модуля учета

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Возможности в системе пользователя. К возможностям пользователя системы необходимо отнести: просмотр доступных обновлений; просмотр информации об обновлениях; скачивание файлов обновлений; просмотр обновления за более ранний период (вчера, 7дней, 30 дней, 3 месяца, 1год); поиск обновлений.

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

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

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

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

Модель «как должно быть» (to-be), смоделированная в MS Visio, представлена на Рисунке 4.



Рисунок 5 - Выпуск обновлений стандартных компонентов (to-be)

Нефункциональные требования к системе Требования к системе в целом [3] Требования к структуре и функционированию модуля

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

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

Тип программного средства	Название ПС
Офисные программные средства общего назначения	Программы обработки текстов: 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

Технологии модуля должны обеспечивать:

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

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

• возможность поиска информации в системе по различным критериям запроса;

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

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

Модуль должен быть реализован на платформе MS VC++, в соответствии с двухуровневой архитектурой (клиент-сервер).

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

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

2. Компонент обработки данных (прикладной логики или бизнес-логики);

3. Компонент представления (визуализации) данных.

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

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

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

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

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

Таблица 5 - Характеристика общесистемного программного комплекса

Функциональное предназначение программного обеспечения	Наименование программного обеспечения
Серверная операционная система	MS Windows Server 2005/2008
Операционная система рабочего места	Windows ХР/Vista
СУБД	Microsoft SQL Server
Почтовый сервер	Microsoft Exchange Server 2003
Почтовый клиент	Microsoft Office Outlook 2007.

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

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

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

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

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

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

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

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

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

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

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

Таблица 6 - Роли эксплуатирующего персонала

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

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

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

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

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

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

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

Время обмена данными между подразделениями определяется техническими возможностями аппаратного обеспечения, на которых размещены ресурсы (300 Мбит/с; 37,5 МБ/c), и пропускной способностью каналов сети передачи данных (1 Гбит/c; 125 МБ/c).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для объектов автоматизации должны быть:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Используемые при разработке программного комплекса модуля языки программирования высокого уровня (Visual C++; Delphi XE) и платформы разработки должны обеспечивать решение задач по реализации функций и задач системы.

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

Способ организации диалога с пользователем должен обеспечивать:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• сервер БД;

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

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

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

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

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

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

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

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

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

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

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

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

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

Функционирование модуля должно обеспечиваться сотрудниками компании.

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

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

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

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

2.3 Разработка системной архитектуры проектируемого модуля

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

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

Этап разработки архитектуры данных содержит четыре шага:

• формирование списка кандидатов в сущности;

• определение сущностей, атрибутов и отношений;

• сопоставление сущностей и бизнес-функций; ? анализ результатов.

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

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

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

Целью четвертого шага является подготовка, распространение и анализ отчета по архитектуре данных.

Смоделированная архитектура данных разрабатываемой системы представлена на Рисунке 6. Модель разработана с использованием Case-средства AllFusion ERwin Data Modeler в нотации IDEF1X.

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

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

Рисунок 7 - Архитектура данных модуля учета

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

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

...