Разработка автоматизированного рабочего места сотрудника оперативного учета Бюро регистрации несчастных случаев по Санкт-Петербургу и Ленинградской области

 

МИНОБРНАУКИ РОССИИ

Государственное образовательное учреждение высшего профессионального образования

«РОССИЙСКИЙ ГОСУДАРСТВЕННЫЙ ГУМАНИТАРНЫЙ УНИВЕРСИТЕТ» (РГГУ)

ИНСТИТУТА ИНФОРМАЦИОННЫХ НАУК И ТЕХНОЛОГИЙ БЕЗОПАСНОСТИ

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

Кафедра информационных технологий




Дипломная работа

Разработка автоматизированного рабочего места сотрудника оперативного учета Бюро регистрации несчастных случаев по Санкт-Петербургу и Ленинградской области













Москва 2011

ВВЕДЕНИЕ


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

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

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

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

Цель дипломного проекта - разработка автоматизированного рабочего места сотрудника оперативного учета Бюро регистрации несчастных случаев ГУВД Санкт-Петербурга и Ленинградской области.

Предмет исследования - управленческая деятельность сотрудника оперативного учета.

Объект исследования - Бюро регистрации несчастных случаев.

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

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

выполнить проектирование АРМ сотрудника оперативного учета;

произвести разработку и тестирование АРМ сотрудника оперативного учета;

разработать документацию по использованию АРМ сотрудника оперативного учета.

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

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

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

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

В работе 4 приложений, 57 рисунков, 1 таблица.

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

В работе над дипломным проектом автором использовались ГОСТ 34.601-90, 34.320-96, стандарт ISO/IEC 12207, работы российских ученых.

В работе В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкина рассмотрены методы и средства проектирования информационных систем в сфере экономики, приведены примеры использования CASE - средств как программного инструмента поддержки проектирования информационных систем. Особое внимание в работе уделено таким вопросам, как методология проектирования предметной области, моделирование бизнес-процессов средствами BPwin, информационное обеспечение информационных систем, моделирование информационного обеспечения. [11].

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

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

ГЛАВА 1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ


.1 Анализ источников и литературы


В.Д. Ковалев и В.В. Хасамудинов в своей работе раскрыли сущность автоматизированного рабочего места (АРМ) как средства реализации новых информационных технологий в организационно-экономическом управлении, сформулированы задачи, решаемые специалистами на всех уровнях управления, определены базовые понятия и общие свойства АРМ[13].

И.П. Норенков в учебнике описал сведения по различным аспектам и видам обеспечения систем автоматизированного проектирования, необходимые квалифицированным пользователям САПР в различных областях техники. Значительное внимание уделено математическому обеспечению процедур анализа и синтеза проектных решений, построению локальных и корпоративных вычислительных сетей САПР, составу и функциям системных сред САПР. Освещены также активно развиваемые в последнее время методики концептуального проектирования сложных систем, положенные в основу CALS-технологий, а также вопросы интеграции САПР с автоматизированными системами управления и делопроизводства[15].

В работе В.А. Гвоздева особое внимание уделено основам знаний по алгоритмизации, технологии программирования, языкам программирования, а также системе объектно-ориентированного программирования MS Visual Basic. Во второй части книги, "Информационные технологии", излагаются вопросы компьютерной обработки текстовой, числовой, графической информации, основы баз данных и знаний, систем управления базами данных (СУБД), даются представление о локальных и глобальных компьютерных сетях и знания о средствах создания веб-документов. Третья часть книги, "Автоматизированные информационные системы", посвящена вопросам разработки и функционирования АИС. Рассматриваются вопросы необходимости автоматизации информационных потоков, состав и структура АИС, методы и стадии их разработки, обеспечивающая и функциональные части, типы АИС, тенденции развития информационных систем[8].


.2 Анализ рынка


На сегодняшний день существует огромное количество АРМ. Приведем пример статистических программ:

АРМ "ОТ" 1.0 программное обеспечение инженера по охране труда. АРМ «ОТ» (автоматизированное рабочее место «охрана труда») предназначена для информационной поддержки деятельности инженера (специалиста) по охране труда, актуализация и анализа информации, касающейся вопросов охраны труда на предприятии. Стоимость программы 4900 руб.

Программа «ОТ» позволяет:

Вести учет персонала;

Вести учет медосмотров по охране труда;

Проводить анализ нарушений по охране труда;

Вести учет проверки знаний персонала, составлять графики проверки знаний персонала;

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

Вести учет травматизма, проводить анализ травматизма на предприятии;

Вести архив документов по охране труда;

Вести учет затрат в сфере охраны труда.

Программа АРМ «ОТ» может экспортировать различные отчеты, справки, графики в редакторы Word, Excel популярного пакета Microsoft Office.

Недостатки: Сложность работы, функциональная избыточность, сложный интерфейс.

Размер программного обеспечения 11981 кб.

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

Возможности программы:

ввод информации о больных;

первичный осмотр (используются шаблоны осмотров);

назначения с распечаткой листа назначений (используются шаблоны назначений);

запись дневников (используются шаблоны дневников);

запись операций с предоперационным эпикризом и без (используются шаблоны операций);

заполнение выписки (используются шаблоны выписок).

Недостатки: нет защиты данных (не поддерживает паролей). Размер программы 1000 Кб.

АРМ «C2000» предназначено для количественного учета заболеваемости в учреждениях санэпиднадзора всех уровней, проводящих регистрацию заболеваний.

Основные функциональные возможности:

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

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

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

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

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

Возможность непостоянной работы программы. Возможна непостоянная работа программы за счет буфера событий пульта "C2000" (до 1023 событий), например, считывание событий за ночь в начале рабочего дня.

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

Недостаток АРМ «С2000» в том, что она позволяет сортировать события по помещениям или по фамилиям, тогда как необходимо в основном просмотр совместный (по помещениям с фамилиями).

Недостатки: нет возможности сводных отчетов.

Стоимость программы 4701 руб.

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

информационный автоматизированный аccess модель

1.3 Задачи, функция и структура «Бюро регистрации несчастных

случаев ГУВД»


Бюро регистрации несчастных случаев ГУВД по г. Санкт- Петербургу и Ленинградской области (БРНС ГУВД по г. СПб и ЛО) является структурным подразделением Главного управления внутренних дел по г. Санкт- Петербургу и Ленинградской области и непосредственно подчиняется первому заместителю начальника ГУВД - начальнику криминальной милиции[1].

В своей деятельности БРНС ГУВД руководствуется[1]:

Конституцией Российской Федерации;

Общепризнанными принципами;

Нормами международного права;

Законами Российской Федерации;

Законами Санкт-Петербурга и Ленинградской области;

Положением о службе в органах внутренних дел РФ;

Положением о БРНС ГУВД;

Планами работы и приказами БРНС ГУВД;

Указами и распоряжениями Президента Российской Федерации;

Постановлениями и распоряжениями Правительства Российской Федерации;

Правительств Санкт-Петербурга и Ленинградской области;

Нормативными правовыми актами МВД России и ГУВД.

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

Деятельность БРНС ГУВД, строится в соответствии с принципами уважения прав и свобод человека и гражданина, законности, гуманизма, гласности, на основе планирования, сочетания единоначалия в решении вопросов служебной деятельности и коллегиальности при их обсуждении, персональной ответственности каждого сотрудника, работника БРНС ГУВД за состояние дел на порученном участке и выполнении отдельных поручений[4].


.3.1 Задачи БРНС[2]

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

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

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


.3.2 Функции БРНС[2]

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

. Формирует и поддерживает в рабочем состоянии банки данных:

неопознанных трупов, в том числе скелетированных и криминальных;

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

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

лиц пострадавших в результате несчастных случаев;

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

.Исполняет в пределах своей компетенции, отдельные поручения и запросы ОВД, прокуратуры, КГБ, суда.

. Обеспечивает полноту регистрации объектов, подлежащих отражению в банках данных.

. Изучает, обобщает, распространяет передовой опыт по всем направлениям деятельности БРНС. Обменивается информацией с БРНС стран СНГ.

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

Структура БРНС ГУВД представлена на рис. 1.1.


Рис.1.1. Структура БРНС ГУВД


В случае возникновения оперативной необходимости, по усмотрению начальника БРНС ГУВД, некоторые сотрудники и (или) работники дежурной смены (дежурных смен) могут быть временно переведены на ежедневную работу с рабочим днем с 9.30 до 18.15, с предоставлением обеденного перерыва продолжительностью 45 минут в удобное для них время. Дежурная смена руководствуется в работе нормативно-правовыми актами, регламентирующими деятельность БРНС ГУВД.

В стране ежегодно в розыске находятся свыше 120 тыс. без вести пропавших, и ежегодно объявляются в розыск еще свыше 70 тыс. человек. Находят каждый год более 65 тысяч - около 90% пропавших.


.3.3 Структура БРНС ГУВД

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

Сведения можно получить по телефону в круглосуточном режиме, если с момента исчезновения лица не прошло 30 суток. Данную информацию можно получить как сотрудникам милиции, так и гражданам. Если с момента исчезновения лица прошло 30 суток, то необходимо обратиться в БРНС только письменно сотрудникам милиции.

В случае если срок прошел, родственники подают письменный запрос в отделение милиции. В письменном запросе должно быть описано: фамилия, имя, отчество (если оно есть), дата и место рождения, дата ухода, приметы человека, описание внешности, во что он был одет на момент ухода, где мог находиться территориально [5]. После принятия заявления оно регистрируется и оправляется в ГУВД, там сотрудники распределяют и отправляют это заявления при помощи почты России по подразделениям и по всем отделениям милиции г. Санкт-Петербурга, в том числе и в БРНС. Запрос (далее «входящий») поступающий в БРНС получает начальник подразделения, после отдается на регистрацию в канцелярию. Канцелярия совместно с заместителем начальника распределяет «входящие» по 4 сменам. Начальник смены и операторы этого подразделения расписываются за «входящие», которые ему были расписаны.

В разработке «входящий» находится одни рабочие сутки той смены, которой они были расписаны, за это время документ должен быть проверен по всем компьютерным базам БРНС, а это:

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

База о неизвестных трупах, обнаруженных на территории Ленинградской области и транспортной милиции (операторы вводят информацию по мере её поступления);

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

База о разыскиваемых пропавших без вести гражданах подразделениями КМ, СМОБ, ПВС в период с 01.07.1996 года (операторы дополняют или удаляют информацию по мере её поступления).

Электронная фото картотека неизвестных трупов, которые были доставлены в морг № 1 (Екатерининский пр. д.10) и морги больниц города. Данная база состоит из графического изображения трупа и текстовой информации.

Обязанности сотрудника оперативного учета БРНС:

Своевременное и качественное выполнение своих должностных обязанностей, указаний и распоряжений руководства БРНС;

Соблюдения суточного режима работы согласна графика;

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

Осуществление взаимодействия с Центральной станцией «Скорой помощи»;

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

Схема функционирования БРНС ГУВД представлена на рис. 1.2.

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

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


Рис. 1.2. Схема функционирования БРНС ГУВД


В настоящее время Бюро регистрации несчастных случаев ГУВД пользуется программой FLINT (Formal language of Interactive Talk) написанной на языке Clipper ver.5.01. Инструментальное средство FLINT представляет собой программный комплекс, по созданию Баз Данных (БД) и работы с ними. Его использование призвано облегчить проектирование на персональных совместимых ЭВМ АРМ, ориентированных на обработку документов анкетного вида с формированием БД по типу картотеки.

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

Информационная система FLINT ориентировано на работу с персональным компьютером типа IBM PC/XT/AT или им подобными микро-ЭВМ.[3]

Функции программы FLINT:

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

Запоминать значение документа, групп реквизитов внутри документа и вызывать запомненные реквизиты;

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

Переходить из одной формы ввода в другую непосредственно из текущего документа;

Осуществлять поиск для коррекции;

Удалять и чистить документы БД.

Проанализировав предметную область своей деятельности, и определив основные объекты учета, разработчик осуществляет постановку задачи (проектирование АРМ) - формирует все необходимые параметры, характеризующие автоматизируемые объекты:

Взаимосвязь между Объектами;

Адреса хранения информации;

Форма ввода/вывод данных;

Ключи поиска;

Виды статистической отчётности.


.4 Обоснование выбора и системный анализ с применением CASE-

средств подлежащих автоматизации


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

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

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

На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE -средствами:


Vantage Team Builder;/2000;;+BPwin;Designor;Аналитик.


Рассмотрим подробнее каждое программное обеспечения:Team Builder представляет собой интегрированный программный продукт, ориентированный на реализацию каскадной модели жизненного цикла ПО и поддержку полного жизненного цикла ПО.

Структура и функции Team Builder обеспечивает выполнение следующих функций:

проектирование диаграмм потоков данных, "сущность-связь", структур данных, структурных схем программ и последовательностей экранных форм;

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

генерация кода программ на языке 4GL целевой СУБД с полным обеспечением программной среды и генерация SQL-кода для создания таблиц БД, индексов, ограничений целостности и хранимых процедур;

программирование на языке C# со встроенным SQL;

Управление версиями и конфигурацией проекта;

Многопользовательский доступ к депозитарию проекта;

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

Экспорт и импорт данных проекта в формате CDIF (CASE Data Interchange Format)./2000 представляет собой семейство методологий и поддерживающих их программных продуктов. Базовая методология Designer/2000 (CASE* Method) - структурная методология проектирования систем, полностью охватывающая все этапы жизненного цикла ИС.

Структура и функции

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

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

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

На этапах эксплуатации и сопровождения анализируются производительность и целостность системы, выполняется поддержка и, при необходимости, модификация ИС.Аналитик является практически единственным в настоящее время конкурентоспособным отечественным CASE-средством функционального моделирования. Его основные функции:

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

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

получение разнообразных отчетов по проекту.

С помощью отдельного программного продукта (Catherine) выполняется обмен данными с CASE-средством Erwin. При этом из проекта, выполненного в CASE. Аналитике, экспортируется описание структур данных и накопителей данных, которое по определенным правилам формирует описание сущностей и их атрибутов.

CASE-средство Silverrun американской фирмы Сomputer Systems Advisers, Inc. (CSA) используется для анализа и проектирования ИС бизнес-класса и ориентировано в большей степени на спиральную модель жизненного цикла[12]. Оно применимо для поддержки любой методологии, основанной на раздельном построении функциональной и информационной моделей (диаграмм потоков данных и диаграмм "сущность-связь").

Настройка на конкретную методологию обеспечивается выбором требуемой графической нотации моделей и набора правил проверки проектных спецификаций. В системе имеются готовые настройки для наиболее распространенных методологий: DATARUN (основная методология, поддерживаемая Silverrun), Gane/Sarson, Yourdon/DeMarco, Merise, Ward/Mellor, Information Engineering. Для каждого понятия, введенного в проекте, имеется возможность добавления собственных описателей. Архитектура Silverrun позволяет наращивать среду разработки по мере необходимости.

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

Модуль построения моделей бизнес-процессов в форме диаграмм потоков данных (BPM - Business Process Modeler) позволяет моделировать функционирование обследуемой организации или создаваемой ИС. В модуле BPM обеспечена возможность работы с моделями большой сложности: автоматическая пере нумерация, работа с деревом процессов (включая визуальное перетаскивание ветвей), отсоединение и присоединение частей модели для коллективной разработки. Диаграммы могут изображаться в нескольких предопределенных нотациях, включая Yourdon/DeMarco и Gane/Sarson. Имеется также возможность создавать собственные нотации, в том числе добавлять в число изображаемых на схеме дескрипторов определенные пользователем поля.

Модуль концептуального моделирования данных (ERX - Entity-Relationship eXpert) обеспечивает построение моделей данных "сущность-связь", не привязанных к конкретной реализации. Этот модуль имеет встроенную экспертную систему, позволяющую создать корректную нормализованную модель данных посредством ответов на содержательные вопросы о взаимосвязи данных. Возможно автоматическое построение модели данных из описаний структур данных. Анализ функциональных зависимостей атрибутов дает возможность проверить соответствие модели требованиям третьей нормальной формы и обеспечить их выполнение. Проверенная модель передается в модуль RDM.

Модуль реляционного моделирования (RDM - Relational Data Modeler) позволяет создавать детализированные модели "сущность-связь", предназначенные для реализации в реляционной базе данных. В этом модуле документируются все конструкции, связанные с построением базы данных: индексы, триггеры, хранимые процедуры и т.д. Гибкая изменяемая нотация и расширяемость источника позволяют работать по любой методологии. Возможность создавать подсхемы соответствует подходу ANSI SPARC к представлению схемы базы данных. На языке подсхем моделируются как узлы распределенной обработки, так и пользовательские представления. Этот модуль обеспечивает проектирование и полное документирование реляционных баз данных.

Менеджер репозитория рабочей группы (WRM - Workgroup Repository Manager) применяется как словарь данных для хранения общей для всех моделей информации, а также обеспечивает интеграцию модулей Silverrun в единую среду проектирования. являются наиболее популярными Case-средствами.

Функциональные возможности инструментальных средств, структурного моделирования деловых процессов будут рассмотрены на примере case-средства BPwin. поддерживает три методологии моделирования: функциональное моделирование (IDEF0); описание бизнес-процессов (IDEF3); диаграммы потоков данных (DFD)[12].

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

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

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

Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы - движение объектов, хранение объектов, поставка и распространение объектов[12].

Третий информационный разрез - последовательность выполняемых работ. Наличие в диаграммах DFD элементов для обозначения источников, приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота. Однако для описания логики взаимодействия информационных потоков более подходит IDEF3, называемая также workflow diagramming, - методология моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. Диаграммы Workflow могут быть использованы в моделировании бизнес-процессов для анализа завершенности процедур обработки информации. С их помощью можно описывать сценарии действий сотрудников организации, например последовательность обработки заказа или события, которые необходимо обработать за конечное время. Каждый сценарий сопровождается описанием процесса и может быть использован для документирования каждой функции.- это метод, имеющий основной целью дать возможность аналитикам описать ситуацию, когда процессы выполняются в определенной последовательности, а также описать объекты, участвующие совместно в одном процессе.

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


1.5 Выявление и оценка информационных потоков и структуры

информации


.5.1 Информационные потоки

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

БРНС ГУВД в соответствии с требованиями законодательных и иных нормативных правовых актов Российской Федерации, МВД - ГУВД и в пределах прав, установленных настоящим Положением, владеет, пользуется и распоряжается накапливаемыми информационными ресурсами, системами, технологиями и средствами их обеспечения[2].

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

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

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


.5.2 Информация

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


Рис. 1.3. Содержание термина "информация по поиску пропавших лиц"

Чем более полным будет это содержание, тем более информативной будет соответствующее сообщение.


.6 Структуризация и обоснование требований (заказчика) к

автоматизации, постановка задачи


В Бюро регистрации несчастных случаев ГУВД для поиска людей утратившую родственную связь используется написанная на Clipper ver.5.01 база данных FLINT. Недостатки программы FLINT являются:

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

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

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

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

Устранить вышеописанные недостатки и было целью дипломной работы. Более кратко требования к новой реализации АРМ можно обозначить так:

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

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

Минимальная нагрузка на локальную вычислительную сеть.

При выводе на печать карточки должны быть максимально похожими на стандартные бланки.


Выводы


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

Основная задача Бюро регистрации несчастных случаев - регистрация несчастных случаев и поиск пропавших лиц по СПб и ЛО.

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

Сложность работы;

Функциональная избыточность;

Высокая стоимость;

Сложный интерфейс.

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

Задачи, подлежащие автоматизации: запрос по поиску пропавших лиц, поиску по возрасту, поиск по одежде, поиск по приметам, поиск по району, поиск по дате регистрации.


ГЛАВА 2. ПРОЕКТИРОВАНИЕ АВТОМАТИЗИРОВАННОГО

РАБОЧЕГО МЕСТА «БРНС ГУВД»


.1 Разработка и сопровождение основных этапов БД


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

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

Этап анализа предметной области;

Этап проектирования БД;

Этап тестирования и сопровождения БД.

Современные платформа БД Microsoft SQL предназначена не только для хранения информации, но и способны задавать логику обработки информации.SQL (MS SQL) - это современное программное обеспечение, предназначенное для организации хранения и доступа к данным (информации) и является самым распространённым языком для работы с БД. Возможности MS SQL не ограничиваются выборкой данных из БД, в MS SQL поддерживаются разнообразные возможности для взаимодействия с БД, в том числе:

Определение структуры данных - определение конструкций, используемых при хранении данных;

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

Обработка данных - вставка, обновление и удаление информации;

Контроль доступа - возможность разрешение/запрета выборки, вставки, обновления и удаления данных на уровне отдельных пользователей;

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


.2 Выбор модели данных


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

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

Модель данных - совокупность структур данных и операций их обработки.

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

Классические модели данных:

Реляционная;

Иерархическая;

Сетевая.

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

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

К достоинствам иерархической модели данных относятся эффективное использование памяти ЭВМ и неплохие показатели времени выполнения основных операций над данными. Иерархическая модель данных удобна для работы с иерархически упорядоченной информацией.

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

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

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

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

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

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

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

Достоинство реляционной модели[20]:

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

Улучшение логической и физической независимости;

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

Оптимизация доступа к БД;

Улучшение целостности и защиты данных;

Возможности различных применений;

Обеспечение методологического подхода.

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

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


.3 Разработка и описание концептуальной и логической моделей

данных


.3.1 Концептуальная модель данных

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

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

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

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

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

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

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

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

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

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

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

Сущность имеет имя, уникальное в пределах модели. При этом имя сущности - это имя типа, а не некоторого конкретного экземпляра.

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

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

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

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

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

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

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

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

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

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

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


Описание атрибутов сущностей

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

.3.2 Логическая модель данных

Логическая модель отражает логические связи между элементами данных вне зависимости от их содержания и среде хранения. Разработка логической модели данных в BPwin основывается на понятии сущностей и связей. Применительно к БД сущности представляют собой таблицы будущей БД, а связи определяют связи между создаваемыми сущностями (таблицами). Сущности наполняются атрибутами, которые соответствуют полям таблицы будущей БД. Далее указываются первичные и внешние ключи, и проводится нормализация БД, однако имеет средства, облегчающие нормализацию. После того, как БД нормализована, BPwin предоставляет возможность проверить нормальность БД[14].

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

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

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

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

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

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

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


.4 Выбор среды СУБД


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

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

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

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

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

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


Рис. 2.1. Структура таблицы «Розыск»


В таблице «Описание человека» описаны подробные данные разыскиваемого, а это: фамилия, имя, отчество, пол человека, волосы, рост, телосложение и приметы. На рис.2.2. представлена структура таблицы «Описание человека».


Рис. 2.2. Структура таблицы «Описание человека»


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

Рис. 2.3. Структура таблицы «Неизвестные»


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

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

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

. Розыск:

«Центральное РУВД

КУСП-1234/34

.11.2010 г. уехал от друзей из г. Луга сын заявителя Иванчук Дмитрий Ярославович 12.12.1979 г.р., урож. Ленинграда, зарег. и прож. пр. Литейный д.43 кв. 82 и до настоящего времени местонахождение его неизвестно.

Приметы: на вид 34 года, ХТС, рост около 170 см., европейский тип лица волосы черные.

Особые приметы: татуировка.

Был одет: куртка синяя, сапоги черные. Другая одежда не известна.

Злоупотребляет спиртными напитками. Ранее уходил на 2-3 дня.

В настоящее время на связь не выходит.

Заявление на розыск поступило 03.12.2010 г. в 13-43 от гр. Иванчук Т.Н. 09.04.1939 г.р., урож. Ленинграда, прож. пр. Литейный д.43 кв.82, не работает.

Выезжали: отв. От рук-ва РУВД зам. Нач. ОГИБДД Мызников, 34 о/м Ермола, УР Волков, УУМ Гусев, ОРО Баранов, ЭКЦ Борисов»

. Неизвестные:

.1. «Фрунзенское РУВД

КУСП-2910/36

.01.2009 г. в 16-13 часов зарегистрирован рапорт об обнаружении признаков преступления.

.01.2009 следователями прокуратуры Шиманским на Колтушском шоссе д. 40 осмотрен труп без признаков насильственной смерти неизвестного мужчины, на вид 19 лет, ХТС, рост 169 см., волосы темно-русые, европейский тип лица.

Особые приметы: шрамы по всему телу.

Одежда: шуба коричневая, брюки черные, ботинки»

. Госпитализация неизвестного человека:

«Колпинское УВД

КУСП-3011/40

.11.2010 г. в 14-29 в 40 о/м поступило сообщение из 30 инфекционной больницы им. Боткина/ул. Миргородская д.3/. 29.11.2010г. в 12-32 с пр. Литейный д. 21 госпитализирован неизвестный мужчина № 22. Ст.17 маш. 2394, без признаков преступления.

Приметы неизвестного: на вид 34 года, ХТС, волосы черные, европейский тип лица, рост 170 см.

Одежда: куртка синяя, сапоги черные.

Приметы: татуировка (место не указано)»


.5 Выбор средств проектирования


Моделирование деловых процессов, как правило, выполняется с помощью case-средств. К таким средствам относится и BPwin. Функциональные возможности инструментальных средств, структурного моделирования деловых процессов будут рассмотрены на примере case-средств BPwin.Process Modeler 7 (BPwin) помогает четко документировать важные аспекты любых бизнес-процессов: действия, которые необходимо предпринять, способы их осуществления и контроля, требующиеся для этого ресурса, а также визуализировать получаемые от этих действий результаты. Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и её взаимодействия с внешней средой.

На рис. 2.4. представлена концептуальная диаграмма процесса работы БРНС ГУВД.

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


Рис. 2.4. Концептуальная диаграмма БРНС

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

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

На рис. 2.5. представлена функциональная декомпозиция БРНС

Рис. 2.5. Функциональная декомпозиция БРНС


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

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

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

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

Механизм - ресурсы, которые выполняют работу. Стрелка механизма рисуется как входящая в нижнюю грань работы. Оборудование и Сотрудники являются механизмом для работы БРНС ГУВД.

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

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

На рис. 2.6. представлена диаграмма дерева узлов

При проектировании структуры (логической модели) базы данных использовалось CASE-средство BPWin.


Рис. 2.6. Диаграмма дерева узлов


.6 Проектирование базы данных

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

В базе данных сведения сохраняются в отдельных таблицах.

Таблица - основной объект для хранения информации в реляционной базе данных.

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

Выбрать название таблиц;

Выбрать название строкам и столбцам;

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

База данных может состоять из одной или нескольких таблиц. На рис. 2.7. и 2.8. (продолжение) представлена таблица «Розыск».

На рис. 2.9. изображена таблица «Описание человека». На рис. 2.10. представлена таблица «Неизвестные». На рис. 2.11. представлена таблица «Описание неизвестного».

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

На Рис. 2.12.-2.15 подробно представлены конструкторы запросов на выборку. Другие примеры конструктора запросов на выборку представлены на Рис. 2.16.-2.19. в Приложении 1.

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

На рис.2.20.-2.23. подробно представлены конструкторы отчеты. Другие примеры конструктора отчета представлены на Рис. 2.24.-2.27. в Приложении 2.

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




Рис. 2.11. Таблица «Описание неизвестных»


Рис. 2.12. Конструктор запроса на выборку возраста.


Рис. 2.13. Конструктор запроса на выборку пола человека.


Рис. 2.14. Конструктор запроса на выборку номера больницы.


Рис. 2.15. Конструктор запроса на выборку штанов.

Рис.2.20. Конструктор отчета по полу человека.


Рис.2.21. Конструктор отчета по району разыскиваемого человека.


Рис.2.22. Конструктор отчета по телосложению разыскиваемого человека.


Рис.2.23. Конструктор отчета по номеру больницы.


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

На рис.2.28.-2.31. представлены конструкторы макросов. Другие примеры конструктора макроса представлены на Рис. 2.32.-2.35. в Приложении 3.


Рис.2.28. Конструктор макроса таблица «Неизвестные».


Рис.2.29. Конструктор макроса отчета «Пол неиз.».


Рис.2.30. Конструктор макроса «Закрыть БД».


Рис.2.31. Конструктор макроса отчета «Поиск по фамилии».


Связь между таблицами Access позволяет установить правила взаимодействия между таблицами. (Рис. 2.36.)

Рис. 2.36. Схема данных


.7 UML-моделирование


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

Модель - это чертеж системы: в неё может входить как детальный план, так и более абстрактное представление системы.это язык для:

Визуализировать систему;

Специфицировать систему;

Конструировать систему;

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

На рис.2.37. представлена диаграмма прецедентов, описывающая исследуемое подмножество бизнес-процессов в целом.

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

Программная система функционирует под воздействием Actor (Актер). Актер в UML- человек, машина или программа, воздействующий на систему.

Выделим актера и варианты использования в рассмотренном ранее «БРНС». Анализ постановки задачи показывает наличие одного актера: «Оператора». Определимся с вариантом использования. Принятые проектные решения определяют дальнейший выбор архитектуры системы и существенно влияют на успех всего процесса разработки[17].

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

Регистрация данных;

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

Выход документации на печать;

Ведение картотеки;

Оформление отчетов;

Обработка входящих звонков.

В сценарий «регистрация данных» входит:

Госпитализация;

База скорой помощи;

База захороненных;

База архива.

В сценарий «просмотр данных» входит:

Госпитализация;

База скорой помощи;

База захороненных;

База архива.


Рис. 2.37. Диаграмма прецедентов


Выводы


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

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

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

Обоснован выбор модели данных предметной области. Обосновано средство разработки АРМ. С использованием CASE-средств выполнено проектирование логики работы приложений.



ГЛАВА 3. РЕАЛИЗАЦИЯ АВТОМАТИЗИРОВАННОГО РАБОЧЕГО

МЕСТА «БРНС ГУВД»


.1 Создание физической модели данных

имеет очень удобный пользовательский интерфейс, позволяющий представить БД в самых различных аспектах. Например, ERwin имеет такие средства визуализации как "хранимое представление" (stored display) и "предметная область" (subject area). Хранимые представления позволяют иметь несколько вариантов представления модели, в каждом из которых могут быть подчеркнуты определенные детали, которые вызвали бы перенасыщение модели, если бы они были помещены на одном представлении. Предметные области помогают вычленить из сложной и трудной для восприятия модели отдельные фрагменты, которые относятся лишь к определенной области, из числа тех, что охватывает информационная модель. Erwin Data Modeler (ERwin) - CASE-средство для проектирования и документирования баз данных, которое позволяет создавать, документировать и сопровождать базы данных, хранилища и витрины данных. Модели данных помогают визуализировать структуру данных, обеспечивая эффективный процесс организации, управления и администрирования аспектов деятельности предприятия, как уровень сложности данных, технологий баз данных и среды развертывания. позволяет управлять данными в процессе корпоративных изменений, а также в условиях стремительно изменяющихся технологий.

Ключевые характеристики:

Синхронизация баз данных;

Автоматизированное создание структуры БД и обратное проектирование;

Публикация моделей;

Поддержка нотаций: IDEF1x, IE, Dimensional;

Документирование структур БД;

Перенос структур БД из одного типа СУБД в другой.

Окно Erwin содержит строку меню, в котором имеются режимы:

File;;;;;

Help.

Два дополнительных меню не видны, когда Erwin инсталлируется впервые:;.

Обычно разработка модели БД состоит из двух этапов: составление логической модели и создание на её основе физической модели. Erwin полностью поддерживает такой процесс, он имеет два представления модели: логическое и физическое. Таким образом, можно строить логическую модель БД, не задумываясь над деталями физическое реализации, т.е. уделяя основное внимание требованиям к информации и бизнес-процессам, которые будет поддерживать БД. , как и инструмент моделирования бизнес-процессов BPwin, интегрирован с генератором отчетов фирмы Logic Works - RPTwin. Это средство позволяет получать подробные отчеты по модели, освещая самые различные ракурсы и аспекты. Инструмент RPTwin поставляется вместе с ERwin и имеет богатый набор встроенных отчетов, позволяющих получать многогранную информацию по модели. Документирование структуры данных является очень важной частью моделирования, т.к. это позволяет другим разработчикам или лицам, которые будут сопровождать систему, быстрее начать ориентироваться во внутренней структуре и понимать назначение компонентов.тесно интегрирован с другими продуктами Logic Works. Словарь данных, созданный при анализе бизнес-процессов при помощи инструмента BPwin, может быть использован как основа для построения модели базы данных. Однако взаимосвязь между этими двумя инструментами двусторонняя, модели BPwin и ERwin можно постоянно поддерживать в согласованном состоянии. Интеграция этих двух продуктов очень важна с точки зрения их совместного использования при разработке программного обеспечения, т.к. отпадает необходимость в повторном выполнении действий и процесс создания словаря данных становится практически автоматическим.


.2 Физическая реализация системы


В подразделении БРНС ГУВД работают сотрудники оперативного учета, которые вводят и обрабатывают информацию. Для удобства автоматизации создана база данных «БРНС ГУВД».

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



В этом окне находятся главные кнопки для работы с этой программой:

База розыск;

База описание человека;

База неизвестных;

База описание неизвестных.

Для поиска пропавшего или поступившего человека, в БД созданы запросы.

Функции поиска:

Выбрать нужный запрос (по которому будет происходить поиск);

Заполнить поисковое поле;

Воспользоваться кнопкой «OK»;

Откроется окно результата поиска;

Для возврата на главное поле необходимо нажать «Выход».

Запросы на выборку:

Поиск по дате рождения Рис. 3.1. (отчет поиска рис. 3.2.);


Рис. 3.1. Поиск по дате рождения


Рис. 3.2. Отчет по запросу


Поиск по фамилии Рис. 3.3. (отчет поиска рис. 3.4.);


Рис. 3.3. Поиск по фамилии


Рис. 3.4. Отчет по запросу


Поиск по верхней одежде Рис. 3.5. (отчет поиска рис. 3.6.);


Рис. 3.5. Поиск по верхней одежде


Рис. 3.6. Отчет по запросу


Поиск по кофте Рис. 3.7. (отчет поиска рис. 3.8.);


Рис. 3.7. Поиск по кофте


Рис. 3.8. Отчет поиска по кофте


Поиск по штанам Рис. 3.9. (отчет поиска рис. 3.10.);


Рис. 3.9. Поиск по штанам


Рис. 3.10. Отчет поиска по штанам

Поиск по обуви Рис. 3.11. (отчет поиска рис. 3.12.);


Рис. 3.11. Поиск по обуви


Рис. 3.12. Отчет поиска по обуви


Поиск по району Рис. 3.13. (отчет поиска рис. 3.14.);


Рис. 3.13. Поиск по району


Рис. 3.14. Отчет поиска по району


Поиск по полу Рис. 3.15. (отчет поиска рис. 3.16.);


Рис. 3.15. Поиск по полу.


Рис. 3.16. Отчет поиска по полу


.3 Структура пользовательской части АРМ


На рис. 3.17. представлена структура пользовательской части АРМ БРНС.

Функциональные возможности программы расположены на главной форме.


Рис. 3.17. Структура пользовательской части АРМ БРНС


.4 Тестирование


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

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

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

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

Изучение спецификации. Эта стадия самая важная, её ещё называют анализом дизайна и/или требований. Иногда применяют название «тестирование спецификации», чуть ниже мы поймём, почему именно «тестирование». Тут надо внимательно прочитать документацию (спецификацию) по приложению.

Дымовое тестирование. На этой стадии надо проверить работает ли система вообще (правильно ли работает, правильно ли «ругается» при не правильной отработке и т.д.). Это делается для того, чтоб понять пригодно ли приложение для дальнейшего тестирования или оно вообще не работает (работает не правильно).

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

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

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

Уровни тестирования:

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

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

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

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

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

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

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


Этапы тестирования:

Вид тестированияСтадия, этапОбъектКритерийФункциональноеРазработкаСистема в целомСоответствие функциональным требованиям ТЗРегрессионноеРазработка, сопровождениеСистема в целомПроверка качества внесения измененийНагрузочноеРазработка, сопровождениеСистема в целомОценка статистических характеристик системы, соответствие ТЗ, ТТХ, подбор конфигурации оборудованияСтрессовоеРазработка, сопровождениеСистема в целомКорректность работы системы при предельных нагрузках

Проводя функциональное тестирование ПО, необходимо:

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

проверить производительность системы и ее устойчивость;

проверить, как работает система с входными данными;

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

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

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

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

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

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

Рассмотрим тест на примере проверки модуля. «Ввод». Тест представлен на Таблица 3.1 в Приложении 4.

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


Выводы


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

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

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



ЗАКЛЮЧЕНИЕ


В ходе данного дипломного проекта были проанализированы: анализ предметной области, проектирование БД и реализация АРМ,

В анализе предметной области были рассмотрены: анализ аналогов на рынке, показал, что существует огромное количество АРМ, но в каждом из них существуют значительные недостатки; функции, задачи и структура подразделения БРНС ГУВД, проанализировав это, были сформулированы все необходимые параметры, характеризующие автоматизируемые объекты; проанализировав CASE-средства, был сделан выбор на BPwin, выявлены информационные потоки.

В проектирование дипломного проекта разработано АРМ сотрудника оперативного учета Бюро регистрации несчастных случаев ГУВД с использованием Microsoft Access.

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

Для реализации поставленной цели дипломного проекта был проведен анализ функциональных обязанностей сотрудника оперативного учета (оператора) подразделения БРНС ГУВД и осуществлена разработка физической структуры БД для БРНС.

Цели и поставленные задачи дипломного проекта выполнены.



СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ И ЛИТЕРАТУРЫ


1. Положение о деятельности Бюро регистрации несчастных случаев ГУВД

. Приказ от 5 октября 2009 года N 1633. Об утверждении Положения о Бюро регистрации несчастных случаев ГУВД по г. Санкт-Петербургу и Ленинградской области

. Программный комплекс FLINT-4 (руководство пользователя): М.,1995. Часть первая в ред. Федерального закона от 31.03.1999 N 68-ФЗ

. Уголовно-процессуальный кодекс РФ (УПК РФ) от 18.12.2001 N 174-ФЗ

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

. ГОСТ 34.320-96 «Концепции и терминология для концептуальной схемы и информационной базы»

. Стандарт ISO/IES 12207-99

. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем-М.: Финансы и статистика,1998.-352 с.

. Вильямс А.. Системное программирование в Windows 2000.-СПб.Питер,2001.-624 с.

. Гвоздева В.А. Информатика, автоматизированные информационные технологии и системы-М.:Инфра,2007-320 с.

. Грекул В.И. Проектирование информационных систем.-М: БИНОМ, 2008.-304 с.

. Калянов Г.Н., Номенклатура CASE-средств и виды проектной деятельности//СУБД,1997.-320 с.

Ковалев В.Д., Хисамудинов В.В. Автоматизированное рабочее место экономиста-М.:Инфра,2010.-206 с.

. Маклаков С.В. ERWin и BPWin. CASE-средства разработки информационных систем/ С.В. Маклаков.-М: ДИЛОГ МИФИ,2000.-256 с.

. Норенков И.П. Основы автоматизированного проектирования-М: Изд-во МГТУ им. Н.Э. Баумана,2002.-336 с.

. Осмоловский В.В. Теория анализа хозяйственной деятельности. - Мн.: Новое знание, 2005. - 358 с.

. Саламатова М.А., Щербаков С.М. Моделирование деловых процессов в системе СИМ-UML (на примере торговой организации) // Системное управление. Выпуск 1(5),2009.- 160 с.

. Титоренко Г.А. Автоматизированные информационные технологии в экономике. - М.:ЮНИТИ,2003.-400 с.

. Хомоненко А.Д. Базы Данных: Учебник / А.Д. Хомоненко, В.М. Цыганков, В.М. Мальцев.-СПБ: КОРОНА принт 2004.-736 с.



ПРИЛОЖЕНИЯ


Приложение 1


Конструктор запросов на выборку


Рис. 2.16. Возраст больше 45 лет



Конструктор запросов на выборку


Рис. 2.17. Дата поступления


Конструктор запросов на выборку


Рис. 2.18. Возраст меньше 40 лет



Приложение 2


Конструктор отчета


Рис.2.24. Номер неизвестного


Рис.2.25. Возраст по розыску


Рис.2.26. Дата поступления



Приложение 3


Конструктор макросов


Рис. 2.32. Поиск по кофте


Рис. 2.33. Поиск по номеру


Рис. 2.34. Поиск по району

Рис. 2.35. Поиск по полу


Приложение 4


Таблица 3.1. Тест проверки модуля «Ввод»

ДействияОжидаемый результат123ВозрастВвод не правильного возрастаВыводится сообщение «Выражение неверно введено или является слишком сложным для расчета»Возраст Ввод правильного возрастаВыдает правильное значениеДата рожденияВвод не правильной датыВыводится сообщение «Выражение неверно введено или является слишком сложным для расчета»Дата рожденияВвод правильной датыВыдает правильное значение


МИНОБРНАУКИ РОССИИ Государственное образовательное учреждение высшего профессионального образования «РОССИЙСКИЙ ГОСУДАРСТВЕННЫЙ ГУМАНИТАРНЫЙ УНИВЕРСИ

Больше работ по теме:

КОНТАКТНЫЙ EMAIL: [email protected]

Скачать реферат © 2017 | Пользовательское соглашение

Скачать      Реферат

ПРОФЕССИОНАЛЬНАЯ ПОМОЩЬ СТУДЕНТАМ