Создание информационной системы для ООО 'Восточный Экспресс'

Создание информационной системы для ООО 'Восточный Экспресс'

РЕФЕРАТ

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

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

Процесс разработки описан с помощью методологии UML объектно-ориентированного подхода.

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

Приложение реализовано в среде программирования MicrosoftVisualStudio 2010 на языке C#, база данных - с помощью СУБД MicrosoftSQLServer 2008R2.

В настоящем отчете применяют следующие термины с соответствующими определениями:

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

Профилирование - сбор характеристик работы программы, таких как время выполнения отдельных фрагментов (обычно подпрограмм), число верно предсказанных условных переходов, число кэш промахов и т. д. [4]

Репликация (англ. replication) - механизм синхронизации содержимого нескольких копий объекта (например, содержимого базы данных). Репликация - это процесс, под которым понимается копирование данных из одного источника на другой (или на множество других) и наоборот.[5]

Тестирование программного обеспечения - процесс исследования, испытания программного продукта, имеющий две различные цели:

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

выявить ситуации, в которых поведение программы является неправильным, нежелательным или не соответствующим спецификации[9].

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

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

Утилита (англ. utility или tool) - вспомогательная компьютерная программа в составе общего программного обеспечения для выполнения специализированных типовых задач, связанных с работой оборудования и операционной системы (ОС)[11].

ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ

ПО - программное обеспечение.

КИС - корпоративная информационная система.- JSON (JavaScriptObjectNotation) - простой формат обмена данными, удобный для чтения и написания как человеком, так и компьютером. [7]- (англ.BinaryJavaScriptObjectNotation) это компьютерный формат обмена данными. Это бинарная форма представления простых структур данных и ассоциативных массивов (которые называют объектами или документами). Имя «BSON» основано на определении JSON и значит «Binary JSON» (бинарный JSON). Формат является надмножеством JSON, включая дополнительно регулярные выражения, двоичные данные и даты[8].

АИП - автоматизированная информационная подсистема.

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

ПК - персональный компьютер.

СУБД - система управления базой данных.

ТЗ - техническое задание.

ОС - операционная система.

ВВЕДЕНИЕ

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

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

Функциональные.

Нефункциональные.

Связанные с изменениями.

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

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

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

Преимущества автоматизации тестирования:

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

Быстрое выполнение - автоматизированному скрипту не нужно сверяться с инструкциями и документациями, это сильно экономит время выполнения.

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

Отчеты - автоматически рассылаемые и сохраняемые отчеты о результатах тестирования.

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

Недостатки автоматизации тестирования:

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

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

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

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

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

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

1. ФОРМИРОВАНИЕ ТРЕБОВАНИЙ К ИС

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

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

Сложная система предполагает большой объем тестирования, следовательно, у предприятия существуют следующие проблемы:

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

Человеческий фактор, то есть предоставление результатов анализа специалистом тестирования непосредственно руководству, вероятность допущения ошибок.

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

Повышенные требования к специалистам тестирования.

Объектом автоматизации является процесс анализа результатов тестирования, а именно, получение информации:

о рекомендации релизов на разные периоды времени;

о результатах прохождения конкретного теста;

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

о времени прохождения теста, группы тестов;

о времени прохождения тестов на разных релизах;

о динамике выявления ошибок;

о времени устранения ошибок;

о количестве выявленных ошибок в группах тестов;

о рекомендации релиза.

1.2 Формирование требований пользователя к ИС

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

1.3 Разработка концепции системы

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

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

Для хранения данных необходимо использовать СУБД: MongoDB. MongoDB - документо-ориентированная система управления базами данных (СУБД) с открытым исходным кодом, не требующая описания схемы таблиц. Написана на языке C++. СУБД управляет наборами JSON-подобных документов, хранимых в двоичном виде в формате BSON. Подобно другим документо-ориентированным СУБД, MongoDB не является реляционной СУБД.

Основные возможности данной СУБД:

Документо-ориентированное хранилище (простая и мощная JSON-подобная схема данных).

Динамические запросы.

Полная поддержка индексов.

Профилирование запросов.

Быстрые обновления «на месте».

Эффективное хранение двоичных данных больших объёмов, напр., фото и видео.

Репликация и поддержка отказоустойчивости.

2. ТЕХНИЧЕСКОЕ ЗАДАНИЕ

.1 Общие положения

.1.1 Полное наименование системы и ее условное обозначение

Полное наименование подсистемы: EasyAnalitic.

Краткое наименование подсистемы: EA.

2.1.2 Наименование организации заказчика и участников работ

Заказчиком подсистемы является ООО «Восточный экспресс» Адрес заказчика: г. Иваново, ул. Палехская, д. 10 Разработчиком системы является Станкова Н.М., студентка кафедры информационных технологий ИГХТУ.

2.1.3 Перечень документов, на основании которых создается система

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

ГОСТ 34.601-90. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания;

ГОСТ 34.201-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплексность и обозначение документов при создании автоматизированных систем.

2.1.4 Плановые сроки начала и окончания работы по созданию системы

Плановый срок начала работы - 10.02.2014.

Плановый срок окончания работы - 06.06.2014.

2.1.5 Источники и порядок финансирования работ

Источником финансирования является ООО «Восточный экспресс».

2.1.6 Порядок оформления и предъявления заказчику результатов работ по созданию системы

По завершению работ по разработке и созданию системы исполнитель обязан:

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

подсистема передается в виде функционирующего комплекса на базе средств вычислительной техники Заказчика и Исполнителя в сроки, установленные в п.3.1.4 Приемка системы осуществляется комиссией в составе уполномоченных представителей Заказчика и Исполнителя. Порядок предъявления системы, ее испытаний и окончательной приемки определен в п.6 настоящего ТЗ. Совместно с предъявлением системы производится сдача разработанного Исполнителем комплекта документации согласно п.8 настоящего ТЗ.

По завершению работ по разработке и созданию системы заказчик обязан:

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

2.2 Назначение и цели создания системы

Назначение системы

АИП «EasyAnalitic» предназначена для комплексного информационно-аналитического обеспечения процесса тестирования:

получение информации о рекомендации релизов на разные периоды времени;

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

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

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

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

получение информации о динамике выявления ошибок;

получение информации о времени устранения ошибок;

получение информации о количестве выявленных ошибок в группах тестов;

получение информации о рекомендации релиза;

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

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

АИП «EasyAnalitic» предполагается использовать в системе «Система управления тестированием», задействованной в исполнении вышеперечисленных процессов.

Цели системы

Основными целями создания АИП «EasyAnalitic» являются:

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

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

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

Данные цели будут достигнуты:

в случае уменьшении времени на получение сведений о состоянии тестирования до 0,5 часа;

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

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

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

Анализ результатов тестирования.

Построение разноцелевых отчетов.

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

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

2.3 Характеристика объекта автоматизации

предприятие информационный система

Объектом автоматизации является процесс анализа результатов тестирования, а именно, получение информации:

о рекомендации релизов на разные периоды времени;

о результатах прохождения конкретного теста;

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

о времени прохождения теста, группы тестов;

о времени прохождения тестов на разных релизах;

о динамике выявления ошибок;

о времени устранения ошибок;

о количестве выявленных ошибок в группах тестов;

о рекомендации релиза.

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

2.4 Требования к системе

Требования к системе в целом.

Требования к структуре и функционированию системы.

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

В состав «EasyAnalitic» должны входить следующие модули:

Отчет «Состояние релиза».

Отчет «Динамика прохождения тестов».

Отчет «Динамика выявления и устранения ошибок».

Отчет «Сравнение логов».

Отчет «Анализ производительности».

Отчет «Состояние релиза» содержит информацию о выбранных релизах на определенный момент времени (день).

В отчете отображается:

Общая информация по ошибкам в системе.

Итоговая таблица, в которой отображаются результаты о состоянии выбранных релизов.

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

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

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

Общую информацию по выявленным ошибкам.

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

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

Отчет «Анализ производительности» содержит информацию о времени прохождения тестов или группы тестов за периоды времени.

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

Входящие в состав «EasyAnalitic» модули в процессе функционирования должны обмениваться информацией с Системой Управления Тестирования. Форматы данных будут разработаны и утверждены на этапе технического проектирования.

Требования к режимам функционирования системы.

«EasyAnalitic» определены следующие режимы функционирования:

Нормальный режим функционирования.

Аварийный режим функционирования.

Основным режимом функционирования EA является нормальный режим. В нормальном режиме функционирования системы:

клиентское программное обеспечение и технические средства пользователей и администратора системы обеспечивают возможность функционирования в течение рабочего дня (с 09:00 до 18:00) пять дней в неделю;

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

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

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

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

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

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

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

Требования не предъявляются.

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

Требования не предъявляются.

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

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

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

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

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

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

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

Все внешние элементы технических средств системы, находящиеся под напряжением, должны иметь защиту от случайного прикосновения, а сами технические средства иметь зануление или защитное заземление в соответствии с ГОСТ 12.1.030-81 и ПУЭ.

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

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

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

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

Взаимодействие пользователей с прикладным программным обеспечением, входящим в состав системы должно осуществляться посредством визуального графического интерфейса (GUI). Интерфейс системы должен быть понятным и удобным, не должен быть перегружен графическими элементами и должен обеспечивать быстрое отображение экранных форм. Навигационные элементы должны быть выполнены в удобной для пользователя форме. Средства редактирования информации должны удовлетворять принятым соглашениям в части использования функциональных клавиш, режимов работы, поиска, использования оконной системы. Ввод-вывод данных системы, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен соответствовать современным эргономическим требованиям и обеспечивать удобный доступ к основным функциям и операциям системы. Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление системой должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен используется главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме системных сообщений) должны быть на русском языке.

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

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

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

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

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

Требования к транспортабельности для подвижных ИС

Требования не предъявляются.

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

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

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

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

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

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

Требования к защите от внешних влияний

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

Требования к функциям системы

Задачи системы представлены на Диаграмме вариантов использования Рис. 1.

Рис. 1 - Диаграмма вариантов использования

Требования к видам обеспечения.

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

Требования не предъявляются.

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

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

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

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

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

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

Для хранения данных необходимо использовать СУБД: MongoDB MongoDB - документо-ориентированная система управления базами данных (СУБД) с открытым исходным кодом, не требующая описания схемы таблиц.

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

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

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

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

Обязательное ПО на сервере: ОС WindowsXP, Windows 7, Windows 8 .netframework 3.5 и выше, СУБД MongoDB 2.4.

Обязательное ПО на Клиенте: ОС Windows XP, Windows 7, Windows 8 .netframework 3.5 и выше.

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

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

В состав комплекса (Рис. 2) должны входить следующие технические средства:

Сервер БД.

Серверы приложения.

ПК пользователей.

ПК администраторов.

Рис. 2 - Состав комплекса

Серверы БД и серверы приложений должны быть объединены одной локальной сетью, с пропускной способностью не менее 10 Мбит.

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

Процессор - наличие как минимум 1 процессора с частотой ядра 2,0 ГГц.

Объем оперативной памяти - не менее 2 Гб.

Дисковая подсистема - не менее 50Гб свободного места.

Сетевой адаптер - не менее 10 Мбит.

Требования к техническим характеристикам ПК пользователя и ПК администратора:

Процессор - наличие как минимум 1 процессора с частотой ядра 2,0 ГГц.

Объем оперативной памяти - не менее 100 Мб свободной оперативной памяти.

Дисковая подсистема - 40 Гб.

Сетевой адаптер - 10 Мбит.

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

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

обработку информации EA;

администрирование EA;

обеспечение безопасности информации EA;

управление работой персонала по обслуживанию EA.

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

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

Нормативно-техническая документация системы должна содержать:

Техническое задание на разработку информационной системы;

Технический проект системы;

Руководство пользователя системы.

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

2.5 Состав и содержание работ по созданию системы

Таблица 1 - Наименование и сроки выполнения работ

2.6 Порядок контроля и приемки системы

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

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

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

3. ТЕХНИЧЕСКИЙ ПРОЕКТ

.1 Общесистемные решения

Схема функциональной структуры

С системой взаимодействуют следующие действующие лица:

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

табельщик. Имеет право просматривать данные о проходах и рабочем времени всех сотрудников в общем списке по своему отделу, а также формировать отчет на основании полученных данных;

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

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

Система условно разделена на 2 подсистемы:

подсистема подготовки данных;

подсистема представления данных.

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

Рис. 3 - Диаграмма вариантов использования

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

3.2 Описание автоматизируемых функций

Функция «Интеграция файла с данными от проходной в БД системы»

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

Рис. 4 - Диаграмма деятельности функции интеграции файла

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

Функция «Просмотр данных о проходах и рабочем времени всех сотрудников»

Данную функцию могут использовать администратор системы или табельщик. Алгоритм данной функции описывает Рисунок 5:

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

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

Функция «Просмотр данных о проходах и рабочем времени одного сотрудника»

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

Рис. 6 - Диаграмма деятельности просмотра личных данных одного сотрудника

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

Функция «Формирование отчетов»

Данная функция формирует для табельщиков отчеты по выбранным параметрам.

Программа и методика испытаний

Объект испытаний

Предварительные испытания проводятся для всей разработанной информационной системы согласно ГОСТ 34.603-92 и являются комплексными.

Цель испытаний

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

Объем испытаний

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

Таблица 2 - Перечень функций системы, подлежащих испытаниям

.3 Условия и порядок проведения испытаний

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

Таблица 3 - Шапка таблицы из файла с входными данными

Описание контрольного примера

Оценить работоспособность разработанной информационной системы можно с помощью описанного ниже контрольного примера.

При запуске приложения открывается окно настроек подключения к базе данных (Рисунок 7):

Рис. 7 - Настройки подключения

Перед началом работы в главном окне приложения необходимо выбрать пункт «Авторизация» и ввести данные о пользователе (Рисунок 8).

Рис. 8 - Авторизация

Для подключения к базе данных необходимо выбрать «База данных»-> «Подключение».

Выберем пункт «Подготовка данных» (Рисунок 9).

Рис. 9 - Главное окно приложения

Потребуется выбрать файл с данными от проходной (Рисунок 8).

Рис. 10 - Выбор файла с данными

При успешном завершении операции интеграции будет выведено сообщение (Рисунок 11).

Рис. 11 - Сообщение

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

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

Рис. 12 - Указание промежутка времени

Будет выведена таблица с результатами (Рисунок 13).

Рис. 13 - Таблица результатов

Отчет будет сформирован в файле MSExcel и будет выглядеть так (Рисунок 14).

Рис. 14 - Отчет

3.4 Решения по организационному обеспечению

Схема организационной структуры

Схема организационной структуры представлена на рисунке 5. Описание приведено в пункте 4.2.4 в пункте настоящего ТЗ.

Рис. 15 - Схема организационной структуры

Организация информационного обеспечения

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

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

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

Организация сбора и передачи информации

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

Описание организационной структуры

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

Решения по техническому обеспечению

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

Решения по информационному обеспечению

Описание информационного обеспечения системы

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

Описание организации информационной базы

В состав данных БД входят следующие сущности:

сотрудник;

проход;

рабочее время;

подразделение;

нормы;

отклонение.

Логическая модель базы данных приведена на рисунке 16:

Рис. 16 - Логическая модель базы данных

Внутримашинная база данных организована в виде реляционной табличной структуры, обслуживаемой специализированным программным обеспечением - СУБД MSSQL.

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

Физическая структура базы данных системы разработана на основе логической модели предметной области и представлена на следующем рисунке 17:

Рис. 17 - Физическая модель базы данных

Ниже приведен перечень и краткое описание основных таблиц базы данных (Таблица 4):

Таблица 4 - Описание основных таблиц базы данных

Далее приведено описание данных для каждой из таблиц (таблицы 5-8).

Таблица 5 - Структура таблицы Employee

Таблица 6 - Структура таблицы Passage

Таблица 7 - Структура таблицы Devaition

Таблица 8 - Структура таблицы Working_time

Таблица 9 - Структура таблицы Norms

Таблица 10 - Структура таблицы Division

3.5 Решения по программному обеспечению

Структура программного обеспечения

Разработка приложения ведется на языке C# на платформе .NET Framework 4 для операционной системы Windows с помощью MicrosoftVisualStudio 2010.

Для хранения данных используется СУБД MicrosoftSQLServer 2008R2.

Методы и средства разработки программного обеспечения

Проектирование модели предметной области системы выполнялось с использованием программного средства MagicDraw UML.

Разработка приложения велась в среде разработки MicrosoftVisualStudio 2010 на языке программирования C#.

Операционная система

Для работы приложения необходима операционная система Windows XP ServicePack 3 и выше.

Решения по математическому обеспечению

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

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

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

4. РАБОЧИЙ ПРОЕКТ

.1 Руководство администратора

Назначение и условия применения

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

4.2 Подготовка к работе

Подключение к базе данных системы

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

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

Рис. 18 - Параметры

Имя сервера совпадает с именем сервера на котором установлена база данных системы. Имя базы данных - Checkpoint. Учетная запись пользователя имеет логин Adm и пароль 1111.

Для подключения к базе данных необходимо выбрать «База данных»-> «Подключение» в главном меню приложения.

4.3 Авторизация

Перед началом работы в главном окне приложения необходимо выбрать пункт «Авторизация» и ввести данные о пользователе (Рисунок 19).

Рис. 19 - Авторизация

Для администратора используются Имя пользователя - Administrator и пароль - 34278341.

Интеграция файла с данными в базу данных системы.

Выберем пункт «Подготовка данных» (Рисунок 20).

Рис. 20 - Главное окно приложения

Потребуется выбрать файл с данными от проходной (Рисунок 21).

Рис. 21 - Выбор файла с данными

При успешном завершении операции интеграции будет выведено сообщение (Рисунок 22).

Рис. 22 - Сообщение

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

4.4 Руководство пользователя

Назначение и условия применения

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

Подготовка к работе

Подключение к базе данных системы

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

Рис. 23 - Параметры

Имя сервера совпадает с именем сервера на котором установлена база данных системы. Имя базы данных - Checkpoint. Учетная запись пользователя имеет логин Adm и пароль 1111. Пользователь так же может выбрать пункт «Проверка подлинности Windows».

Для подключения к базе данных необходимо выбрать «База данных»-> «Подключение» в главном меню приложения.

Авторизация

Перед началом работы в главном окне приложения необходимо выбрать пункт «Авторизация» и ввести данные о пользователе (Рисунок 24).

Рис. 24 - Авторизация

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

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

Просмотр данных

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

Рис. 25 - Указание промежутка времени

Будет выведена таблица с результатами (Рисунок 26).

Рис. 26 - Таблица результатов

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

Создание отчета

Для создания отчета необходимо выбрать в главном меню приложения пункт «Представление данных»-> «Сформировать отчет». Необходимо так же выбрать промежуток времени, за который будет сформирован отчет (Рисунок 27).

Отчет будет сформирован в файле MSExcel и будет выглядеть так (Рисунок 27).

Рис. 27 - Отчет

ЗАКЛЮЧЕНИЕ

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

Преимуществами разработанной подсистемы являются:

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

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

.ГОСТ 34.601-90 Информационная технология. Автоматизированные системы. Стадии создания.

. Требования к оформлению квалификационных работ: метод. указания для студентов по направлению 230200 «Информационные системы» / Сост.: А.П. Власов, Н.А. Марчук: Иван. гос. хим.-технол. ун-т. - Иваново, 2010, 35 с.

4. <http://ru.wikipedia.org/wiki/Профилирование_(информатика)> (02.03.14)

.<http://ru.wikipedia.org/wiki/Репликация_(вычислительная_техника)>(02.03.14)

. <http://ru.wikipedia.org/wiki/Отказоустойчивость> (02.03.14)

. <http://www.json.org/json-ru.html> (02.03.14)

. <http://ru.wikipedia.org/wiki/BSON> (02.03.14)

. <http://ru.wikipedia.org/wiki/Тестирование_программного_обеспечения> (02.03.14)

. <http://www.protesting.ru/testing/> (21.05.2014)

. <http://ru.wikipedia.org/wiki/Утилита> (22.05.2014)