Разработка информационной системы ОВД г. Донецка

БОЛЬШАЯ ЛЕНИНГРАДСКАЯ БИБЛИОТЕКА - РЕФЕРАТЫ - Разработка информационной системы ОВД г. Донецка

Разработка информационной системы ОВД г. Донецка

Содержание

• ВВЕДЕНИЕ
• 1. Актуальность и место решаемой задачи информационного обеспечения в предметной области
• 2. Цели и задачи дипломного проектирования
• 1 РАЗРАБОТКА ТРЕБОВАНИЙ К ПРОГРАМНОМУ ОБЕСПЕЧЕНИЮ
• 1.1 Анализ предметной области
• 1.2 Анализ существующих решений по автоматизации предметной области
• 1.3 Анализ и моделирование требований
• 1.4 Сбор требований
• 1.5 Спецификация и аттестация требований
• 1.6 Выбор методологии проектирования информационной системы
• Выводы к разделу
• 2 ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ
• 2.1 Архитектурное проектирование
• 2.2 Проектирование пользовательского интерфейса
• 2.3 Проектирование баз данных
• 2.4 Обоснование выбора платформы создания информационной системы
• 2.5 Описание сценария диалога.
• Выводы к разделу
• 3 РЕАЛИЗАЦИЯ И АТТЕСТАЦИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ
• 3.1 Реализация приложения
• 3.2 Взаимодействие приложения с источниками данных
• 3.3 Тестирование приложения
• Выводы к разделу
• 4 УПРАВЛЕНИЕ ИНФОРМАЦИОННЫМ ПРОЕКТОМ
• 4.1 Выбор жизненного цикла разработки ПО
• 4.2 Определение цели и области действия программного проекта
• 4.3 Создание структуры пооперационного перечня работ
• 4.4 Идентификация задач и действий
• 4.5 Оценка длительности и затрат на разработку ПО
• 4.5.1 Оценка длительности
• 4.5.2 Оценка затрат
• 4.6 Распределение ресурсов проекта
• 4.7 Оценка экономической эффективности проекта
• 4.7.1 Чистый приведенный доход
• 4.7.2 Коэффициент возврата инвестиций
• 4.7.3 Внутренняя норма доходности
• Выводы к разделу
• ЗАКЛЮЧЕНИЕ
• THE CONCLUSION
• СПИСОК ЛИТЕРАТУРЫ
• ПРИЛОЖЕНИЕ А - ОРГАНИЗАЦИОННАЯ СТРУКТУРА
• ПРИЛОЖЕНИЕ Б - ПРОГРАММНЫЙ КОД (ФРАГМЕНТЫ)
• ПРИЛОЖЕНИЕ В - ТЕХНИЧЕСКОЕ ЗАДАНИЕ
• ПРИЛОЖЕНИЕ Г - ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ
• ПРИЛОЖЕНИЕ Д - ПЛАН ТЕСТИРОВАНИЯ ПО
• ПРИЛОЖЕНИЕ Е ? ОБОСНОВАНИЕ ВЫБОРА МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА
• ПРИЛОЖЕНИЕ Ж - ПЕРЕЧЕНЬ РАБОТ
• ПРИЛОЖЕНИЕ З - ОЦЕНКА СТОИМОСТИ РАЗРАБОТКИ ПО

Существует три основных варианта решения проблемы внедрения информационных систем.

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

Второй путь -- приобретение универсальной системы или пакета прикладных программ для построения корпоративный информационной системы (КИС). Основу КИС составляет система планирования ресурсов корпорации ERP - система (Enterprise Resource Planning), предназначенная для автоматизации основных бизнес-процессов. Перспективным является приобретение и применение таких продуктов как:

- системы управления взаимоотношениями с клиентами, CRM - системы (Customer Relationship Management);

- системы управления цепочками поставок, SCM- системы (Supply Chain Management);

- системы оперативного анализа данных OLAP-системы (Online Analytical Processing);

- корпоративные хранилища данных, DWH -системы (Data Warehouse);

- системы управления жизненным циклом продукции, PLM - системы (Product Lifecycle Management);

- системы управления бизнес-процессами, ВРМ (Business Process Management)-системы;

- системы управления документами, DM -системы (Document Management);

- информационной системы для менеджмента, EIS - системы (Enterprice Information Sysiem).

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

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

- экономия средств за счет применения решений, ядро которых прошло успешное внедрение в других фирмах. Цена таких систем ниже, чем у систем, разрабатываемых «с нуля»;

- профессионализм исполнения;

- сервисная поддержка;

- возможность развития системы в соответствии с усложнением бизнеса.

Имеются и потенциальные опасности:

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

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

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

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

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

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

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

«Информационная система МРССиСТ» разрабатывается для ведения учета поступающей новой техники, заявок на материал, ремонта техники, списания материала, техническое обслуживание, сведений о движении изделия при эксплуатации. Выбираются предложения из БД с помощью «Вкладок», в которых можно осуществлять поиск по различным комбинациям параметров.

Задачи дипломного проекта:

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

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

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

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

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

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

В своей деятельности милиция в целом подчиняется Министерству внутренних дел, а местная, кроме того, - органам местного самоуправления.

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

Расширился и круг потребителей, заинтересованных в получении информации, имеющейся в подразделениях ОВД. Если несколько лет назад ею пользовались, в основном, оперативно - следственные работники МВД, службы безопасности, прокуратуры, то в настоящее время ею пользуются сотрудники налоговой и таможенной служб, финансовых и коммерческих структур, представители администраций республик, краев, областей. [13,29]

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

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

Нормативной базой для проведения крупномасштабных работ по компьютеризации ОВД является “Концепция развития системы информационного обеспечения ОВД в борьбе с преступностью”, утвержденная приказом МВД России от 12 мая 1993 г., на основе которой разработаны основные принципы создания ИВС, предложены типовые архитектурные и программно-технические решения, разрабатываются комплексы прикладных программных средств.

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

ОВД имеет в своем составе подразделения, занимающиеся решением определенного для каждого из них круга задач. Организационная структура представлена в ПРИЛОЖЕНИИ А. Это тип структуры, строго иерархически организованной, характеризующейся разделением зон ответственности и единоначалием.

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

Рисунок 1.1 - Организационная структура инженерного отдела ОВД г.Донецка

Функции ОВД подразделяется на:

- основные;

- обеспечивающие;

- штабные.

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

К обеспечивающим функциям относится:

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

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

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

- улучшение условий труда, быта и отдыха личного состава.

К штабным функциям относятся:

- комплексный анализ в сфере правопорядка;

- координация деятельности подразделений ОВД в осуществлении комплексных правоохранительных задач;

- контроль и проверка состояния оперативно-служебной и управленческой деятельности;

- связь со средствами массовой информации;

- осуществление контроля за учетно-регистрационной и статистической работой;

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

- обобщение и внедрение в практику передового опыта работы;

- организация контроля за исполнением управленческих решений.

Начальник ОВД выполняет следующие задачи:

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

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

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

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

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

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

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

- принимает решения о поощрениях, дисциплинарных взысканиях;

- утверждает состав и руководит работой оперативного совещания.

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

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

- координирует деятельность подразделений ОВД: разрабатывает оперативные планы использования сил и средств при чрезвычайных обстоятельствах и событиях, проводит тренировки с личным составом ОВД;

- организует обеспечение связи со средствами массовой информации (СМИ;

- ведет учетно-регистрационное обслуживание;

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

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

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

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

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

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

ОБЭП обеспечивает сбор, обобщение и анализ информации о состоянии оперативной обстановки на потребительском рынке; организует реализацию комплексных программ по борьбе с преступностью в сфере экономики а также работу с другими подразделениями КМ, МОБ по борьбе с экономическими преступлениями; проводит защиту правоохранительных экономических интересов граждан, государства, организаций независимо от форм собственности на которых они основаны. [29]

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

В отделе находится 3 компьютера объединенных в общую компьютерную сеть милиции. В основном это компьютеры на базе процессора Intel Celeron с частотой от 1000 до 2.6 MHz, и оперативной памятью DIMM 256 - 512 Mb. Операционная система Windows XP. Так же инженерный отдел имеет сканер, модемы, принтеры.

Локальная сеть отдела - Switch Delinc. В качестве среды передачи используется неэкранированная витая пара 5-й категории (UTP) со скоростью передачи данных 100 Мб/с. Для соединения кабеля с оборудованием используются вилки и розетки RJ-45. Доступа в Internet нет, но имеется Intranet. В инженерном отделе используют такие программные продукты как:

1. Специализированные - используемые только в ИО - АРМ, Модуль оператора и др.)

2. Основные - это программы, устанавливаемые непосредственно на каждый компьютер - MS Office 2000, Dr. Web, Avast и т. д.)

В качестве почтовой программы используется The Bat! c возможностью рассылки и получению почты. Обновления антивирусных баз программы Dr.Web происходит из Ростова через Intranet.

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

Для проведения анализа и реорганизации процессов предназначено CASE-средство BPwin, поддерживающее методологии IDEF0 (функциональная модель) и DFD. Функциональная модель предназначена для описания существующих процессов в милиции и идеального положения вещей - того, к чему нужно стремиться. Методология IDEF0 предписывает построение иерархической системы диаграмм - единичных описаний фрагментов системы. Сначала проводится описание систем в целом и ее взаимодействия с окружающим миром, после чего проводится функциональная декомпозиция - система разбивается на подсистемы и каждая подсистема описывается отдельно. Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. [19]

DFD включает такие понятия, как «внешняя ссылка» и «хранилище данных», что делает ее более удобной для моделирования документооборота. [20]

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

Рисунок 1.2 - Контекстная диаграмма инженерного отдела

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

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

Рисунок 1.3 - Первый уровень декомпозиции

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

Рисунок 1.4 - Второй уровень декомпозиции

Как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота используют модель DFD, которая представлена на рисунках 1.5 и 1.6.

Рисунок 1.5 - Начальный уровень диаграммы потоков данных по учёту технических средств

Рисунок 1.6 - Диаграмма потоков данных. Учет техники

Из рисунка 1.6 видно как идет движение документов и информации в отделе.

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

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

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

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

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

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

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

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

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

- Функциональные требования, описывающие требуемую функциональность или прецеденты системы (F).

- Системные требования, такие как используемые платформы (C).

- Требования к представлению (P).

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

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

Таблица 1.1 - Функциональные требования

Далее описываются системные требования (С):

Среда разработки - Microsoft Access

Язык программирования - Microsoft Visual C#

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

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

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

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

Параметризация позволяет определить требования к системе, оценить существующую информационную систему, определить пригодность типовых решений в проекте ИС, выбрать проектные решения в соответствии с предъявляемыми требованиями к АИС. К основным компонентам ТЭО относятся:

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

- обоснование цели создания ИС;

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

- разработка перечня организационно-технических мероприятий по проектированию системы;

- расчёт и обоснование эффективности выбранного проекта;

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

На основании технико-экономического обоснования строится техническое задание. ТЭО и ТЗ представлены в ПРИЛОЖЕНИЯХ Б и В.

Визуальное моделирование оказало большое влияние на развитие ТС ПО вообще и CASE-средств в частности. Понятие CASE (Computer Aided Software Engineering) используется в настоящее время в весьма широком смысле. Первоначальное значение этого понятия, ограниченное только задачами автоматизации разработки ПО, в настоящее время приобрело новый смысл, охватывающий большинство процессов жизненного цикла ПО. [19]

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

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

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

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

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

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

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

Информационная система учёта техники выполнено как автономное приложение. Такой тип архитектуры объясняется тем, что на одном рабочем месте находится один сотрудник, нет необходимости одновременного доступа к данным БД с разных рабочих мест, следовательно, нет необходимости в многоуровневой архитектуре. Ещё в автономном приложении меньшее количество затрат при его использовании, так как нет необходимости приобретать и устанавливать SQL сервер, который необходим при многоуровневой архитектуре.

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

Для проектирования базы данных был использован ERwin 4.0 разработанный Computer Associates Int.

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

ERwin - не только лучший инструмент для проектирования баз данных, но и средство для их быстрого создания. ERwin оптимизирует модель в соответствии с физическими характеристиками целевой базы данных. В отличие от других инструментальных средств, ERwin автоматически поддерживает согласованность логической и физической схем и осуществляет преобразование логических конструкций, таких как отношения многие-ко-многим, в их реализацию на физическом уровне. Облегчает проектирование баз данных. Для этого достаточно создать графическую E-R модель (объект-отношение), удовлетворяющую всем требованиям к данным и ввести бизнес-правила для создания логической модели, которая отображает все элементы, атрибуты, отношения и группировки. [20]

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

Рисунок 2.9 - Логическая модель данных

База данных информационной системы учёта технических средств и средств связи разработана в Microsoft Office Access 2003. На первом этапе была разработана структура данных и построена схема данных.

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

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

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

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

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

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

Рис 2.10 - Общая структура данных учёта платежей

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

1. Таблица «Группы аппаратуры» (Рис 2.11);

Рисунок 2.11 - таблица «Группы аппаратуры»

Поля таблицы (рис. 2.12):

Рисунок 2.12 - поля таблицы «Группы аппаратуры»

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

2. Таблица «Возврат материала» (рис.2.13);

Рисунок 2.13 - Таблица «Возврат материала»

Поля таблицы (рис. 2.14):

Рисунок 2.14 - поля таблицы «Возврат материала»

В данной таблице ключевым является поле «ID». «Материал принял» и «Материал сдал» берется из таблицы «Персонал», «Наименование тех средств» из таблицы «Материалы».

3. Таблица «Должность» (рис. 2.15);

Рисунок 2.15 - таблица «Должность»

Поля таблицы (рис. 2.16):

Рисунок 2.16 - поля таблицы «Должность»

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

4. Таблица «Заявки на материал» (рис. 2.17);

Рисунок 2.17 - таблица «Заявки на материал»

Поля таблицы (рис. 2.18):

Рисунок 2.18 - поля таблицы «Заявки на материал»

В данной таблице ключевым является поле «ID заявки». «Наименование» берется из таблицы «Материалы».

5. Таблица «Изменения в конструкции во время эксплуатации» (рис. 2.19);

Рисунок 2.19 - таблица «Изменения в конструкции во время эксплуатации»

Поля таблицы (рис. 2.20):

Рисунок 2.20 - поля таблицы «Изменения в конструкции во время эксплуатации»

В данной таблице ключевым является поле «ID». «Наименование» берется из таблицы «Материалы», «Должность ответственного лица» из таблицы «Должность», «ФИО ответственного» из таблицы «Персонал».

6. Таблица «Инвентаризация средств связи» (рис. 2.21);

Рисунок 2.21 - таблица «Инвентаризация средств связи»

Поля таблицы (рис. 2.22):

Рисунок 2.22 - поля таблицы «Инвентаризация средств связи»

В данной таблице ключевым является поле «ID инвентаризации». «Наименование» берется из таблицы «Материалы».

7. Таблица «Материалы» (рис. 2.23);

Рисунок 2.23 - таблица «Материалы»

Поля таблицы (рис. 2.24):

Рисунок 2.24 - поля таблицы «Материалы»

Представленная таблица содержит поле «Наименование», она необходима для связки практически всех таблиц по полю «ID тех средства».

8. Таблица «Персонал» (рис. 2.25);

Рисунок 2.25 - таблица «Персонал»

Поля таблицы (рис. 2.26):

Рисунок 2.26 - поля таблицы «Персонал»

Представленная таблица содержит поле «Фамилия ИО», она необходима для связки таких таблиц, как «Возврат материала», «Изменения в конструкции во время эксплуатации и ремонта», «Результаты проверки инспектирующими лицами», «Сведения о движении изделия при эксплуатации», «Учет технического обслуживания» по полю «ID» «Должность» берется из таблицы «Должность».

9. Таблица «Спецификация» (рис. 2.27);

Рисунок 2.27 - таблица «Спецификация»

Поля таблицы (рис. 2.28):

Рисунок 2.28 - поля таблицы «Спецификация»

Представленная таблица содержит поле «Спецификация», она необходима для связки таблицы «Группы аппаратуры».

10. Таблица «Учет технического обслуживания» (рис. 2.29);

Рисунок 2.29 - таблица «Учет технического обслуживания»

Поля таблицы (рис. 2.30):

Рисунок 2.30 - поля таблицы «Учет технического обслуживания»

В данной таблице ключевым является поле «ID». «Должность ответственного» берется из таблицы «Должность», «ФИО ответственного» берется из таблицы «Персонал».

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

Рисунок 2.31 - Схема данных

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

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

Рисунок 2.32 - Физическая модель данных

Для реализации программы «Информационная система МРССиСт» были выбраны такие программные средства разработки как Microsoft Access 2002 и язык программирования Microsoft Visual С# .Net.

Microsoft Access - это интерактивная реляционная СУБД для WINDOWS . Это программа, которую используют для хранения и извлечения данных в зависимости от отношений, которые установлены. Работа с ней упрощена посредством манипулятора мыши. Графические возможности оболочки производят большое впечатление при изготовлении высококачественных отчетов и распечаток. Все это благодаря поддержки True-type шрифтов и встраивания OLE-объектов в рамках среды WINDOWS. OLE - объект представляет собой ссылку на определенную информацию, которая остается в своей первоначальной форме. [6]

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

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

Специально для платформы Microsoft Visual Studio .Net был разработан новый язык программирования - C#. Он впитал в себя многое из того лучшего, что есть в самых разных языках программирования. [11]

Язык C# обезоруживает своей простотой - в нем насчитывается около 80 ключевых слов и десяток встроенных типов данных. Тем не менее, он оказывается исключительно выразительным, когда дело доходит до реализации современных концепций программирования. Язык C# включает в себя самую полную поддержку структурного, компонентно-ориентированного и объектно-ориентированного программирования, которую только можно ожидать от современного языка. [25]

В C# предусмотрены встроенные синтаксические конструкции для работы с перечислениями, структурами и свойствами классов.

C# позволяет интерактивно конструировать внешний вид приложений. Можно располагать разные элементы управления (кнопки, полосы прокрутки и т.п.) на поверхности окна программы, а C# генерирует соответствующий код. [44]

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

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

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

- выбор объектов;

- ввод информации о технике;

- просмотр, редактирование и печать отчетов.

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

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

Для начала работы с программой необходимо запустить файл Mrssst.exe. Работа с системой начинается с главного меню. Структура меню представлена на рисунке 2.33. Меню включает в себя следующие пункты: Файл, Правка, Вид, Таблица, Окно.

Рисунок 2.33 - Главное меню

Далее «Открыть», а потом выбрать нужное: «Справочники», «Карточки учета», «Резервное копирование» или «Формы» (Рисунок 2.34)

Рисунок 2.34 - Меню «Открыть»

При выборе подпункта «Материалы» подменю «Справочники» появляется окно «Материалы» (рисунок 2.35).

Рисунок 2.35 - Окно «Материалы»

При выборе подпункта «Группы аппаратуры» подменю «Справочники» появляется окно «Группы аппаратуры» (рисунок 2.36).

Рисунок 2.36 - Окно «Справочник группы аппаратуры»

При выборе подпункта «Карточки учета материалов» подменю «Карточки учета» появляется окно «Карточки учета материалов» (рисунок 2.37).

Рисунок 2.37 - окно «Карточки учета материалов»

Форма «Создание новой записи» (рисунок 2.38) позволяет создавать и добавлять новые записи в таблицу.

Рисунок 2.38 - форма «Создание новой записи»

Подменю «Установка даты» позволяет установить текущую дату (рисунок 2.39).

Рисунок 2.39 - форма «Установка текущей даты»

Если нужно распечатать полученный документ, нужно выбрать в меню «Файл» - «Печать» (рисунок 2.40). Здесь же можно выбрать вид печати: предварительный просмотр или стандартная печать.

Рисунок 2.40 - окно «Печать документов»

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

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

Реализация приложения выполнена с помощью объектно-ориентированного языка высокого уровня C#.

Используются стандартные библиотеки (рисунок 3.1)

using System;

using System.Data.OleDb;

using System.Drawing;

using System.Collections;

using System.ComponentModel;

using System.Windows.Forms;

using System.Data;

using System.Xml;

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

Весь активный процесс C#-программы происходит в пределах класса. Класс является основой, для создания объектов. В классе определяются данные и код, который работает с этими данными. [45]

Типы членов классов C#:

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

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

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

- константы. Это поле, значение которого изменить нельзя.

- индексаторы. Они позволяют индексировать объекты методами-аксессорами get и set. C помощью индексатора легко проиндексировать объект для установки или получения значений.

- события. Событие вызывает исполнение некоторого фрагмента кода. События - неотъемлемая часть для программирования Microsoft Windows. [33]

Поскольку в предыдущем разделе 2.4 Обоснование выбора платформы создания информационной системы было принято решение о разработке приложения программы с помощью объектно - ориентированного языка высокого уровня C# на платформа .NET то на ее основе, определено множество типов (организованных в соответствующие пространства имен) для взаимодействия с локальными и удаленными хранилищами данных. Общее название пространств имен с этими типами -- ADO.NET.

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

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

DataSet состоит из объектов типа DataTable и объектов DataRelation. К ним можно обращаться как к свойствам объекта DataSet. Свойство Tables возвращает объект типа DateTableCollection, который содержит все объекты DataTable используемой базы. [25]

Таблица - 3.1 - Пространство имен ADO.NET

Создание DataSet осуществляется при помощи управляемого провайдера (managed provider). Управляемый провайдер -- это набор классов, реализующих интерфейсы, определенные в пространстве имен System.Data.

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

В реализованном приложении ADO.NET мы использовали одно пространство имен -- System.Data. Кроме того, нам практически во всех ситуациях потребуется использовать еще либо пространство имен System.Data.OleDb-- для установления соединения с источником данных.

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

§ открыть соединение (connection) с базой данных;

§ вызвать на исполнение метод или команду, указав ей в качестве параметра текст SQL-запроса;

§ закрыть соединение с базой данных.

Связь с базой данных остается активной только на достаточно короткий срок -- на период выполнения запроса. [45]

После записи информации из таблиц в приложение связи с БД закрывается.

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

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

В данном дипломном проекте в качестве тестирования был использован метод тестирования «черного ящика».

План тестирования ПО представлен в ПРИЛОЖЕНИИ Г.

Тестовый пример можно разделить на следующие категории:

1. Нет данных;

2. Повторное выполнение;

3. Верные данные.

Пример теста когда «нет данных» показан на рисунке 3.3.1:

Рисунок 3.3.1 - тестовый пример «нет данных»

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

Рисунок 3.3.2 - тестовый пример «Повторное выполнение»

Пример теста когда «верные данные» показан на рисунке 3.3.3.

Рисунок 3.3.2 - тестовый пример «Повторное выполнение»

Реализация и аттестация информационной системы один из самых важных процессов создания программы «Информационная система МРССиСТ». В заключении необходимо добавить, что этап реализации начинается сразу после проектирования информационной системы. На данном этапе были составлены бизнес-правила, показаны алгоритмы и циклы используемые при реализации приложения. Описано взаимодействие приложения с источниками данных ADO.NET -- это новая технология доступа к базам данных. На этапе реализации было проведено тестирование созданной системы методам «черного ящика». В результате был получен отчёт о тестировании. В целом этап прошёл успешно.

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

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

Разработка разбивается на четыре этапа:

- планирование;

- анализ риска;

- оценка заказчика;

- конструирование.

Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:

- небольшую команду программистов (от 2 до 10 человек);

- короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);

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

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

Жизненный цикл ПО по методологии RAD состоит из четырех фаз:

- фаза анализа и планирования требований;

- фаза проектирования;

- фаза построения;

- фаза внедрения.

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

На фазе проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. CASE-средства используются для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и, при необходимости, корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для каждого элементарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Определяются требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации. [37]

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

- общая информационная модель системы;

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

- точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;

- построенные прототипы экранов, отчетов, диалогов.

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

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

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

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

- определяется необходимость распределения данных;

- производится анализ использования данных;

- производится физическое проектирование базы данных;

- определяются требования к аппаратным ресурсам;

- определяются способы увеличения производительности;

- завершается разработка документации проекта.

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

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

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

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

Таблица 4.1 - Размер приложения

В качестве итога перечислим основные принципы методологии RAD:

- разработка приложений итерациями;

- необязательность полного завершения работ на каждом из этапов жизненного цикла;

- обязательное вовлечение пользователей в процесс разработки ИС;

- необходимое применение CASE-средств, обеспечивающих целостность проекта;

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

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

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

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

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

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

RAD - технология не применима для построения:

- сложных расчетов программ;

- операционных систем;

- а также приложений, от которых зависит безопасность людей. [39]

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

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

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

Структура пооперационного перечня работ разрабатывалась в приложении Microsoft Office Project 2003, как и весь проект.

Эта структура включает следующие задачи и подзадачи:

Анализ и планирование требований к программному продукту:

- анализ требований;

- создание черновой версии спецификации проекта;

- разработка графика сдачи;

- получение разрешений на продолжение (концепция, расписание).

Проектирование:

- разработка общей информационной модели системы;

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

- точное определение интерфейсов;

- построение прототипов экранных форм, диалогов, отчетов.

Разработка:

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

- Назначение персонала для разработки;

- Разработка кода.

Реализация:

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

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

Тестирование модулей:

- Ревизия кода модулей;

- Тестирование модулей компонента в соответствии со спецификацией продукта;

- Выявление ошибок в спецификациях продукта;

- Изменение кода;

- Повторное тестирование измененного кода.

Тестирование интеграции:

- Тестирование интеграции модулей;

- Выявление ошибок и недоработок;

- Изменение кода;

- Повторное тестирование измененного кода.

Разработка документации:

- Разработка справки;

- Разработка руководства пользователя;

- Ревизия всей документации для пользователей;

- Доработка документации для пользователей с учетом замечаний. [36]

Более наглядное представление структуры пооперационного перечня работ приводится в ПРИЛОЖЕНИИ Е - Перечень работ.

Для того чтобы идентифицировать задачи и действия необходимо в Microsoft Office Project 2003 выбрать команду меню Вид ¦ Использование задач. Все работы можно классифицировать по своим характеристикам: длительности, трудозатратам и количеству людских ресурсов. Данные параметры связаны друг с другом: трудозатраты задачи равны произведению длительности на количество людских ресурсов. Задачи в плане проекта могут быть трех типов: с фиксированными длительностью, трудозатратами и количеством ресурсов.

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

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

Основные проектные документы, подготавливаемые на данном этапе, -- это:

- концептуальный проект системы;

- настроенные в системе прототипы бизнес-процессов;

- уточненный объем проекта;

- уточненный план проекта.

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

- руководитель проекта;

- группа аналитиков;

- разработчики;

- тестеры;

- специалисты по распространению технической информации;

- инструкторы; [38]

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

Рис4.1 - Идентификация задач

Распределение ресурсов проекта показано на рисунке 4.2.

Рисунок 4.2 - Распределение ресурсов проекта

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

Таблица 4.2 - Исходные данные.

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

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

Центральным показателем в рассматриваемом методе является показатель NPV (net present value) - текущая стоимость денежных потоков за вычетом текущей стоимости денежных оттоков. Это обобщенный конечный результат инвестиционной деятельности в абсолютном измерении.

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

где Rk - годовые денежные поступления в течение n лет, k = 1, 2, …, n;

Rk = DPk - Zk ,

DPk - ежегодная дополнительная прибыль от реализации проекта;

Zk - ежегодные затраты на реализацию проекта;

IC - стартовые инвестиции;

i - ставка дисконтирования.

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

Если проект предполагает не разовую инвестицию, а последовательное инвестирование финансовых ресурсов в течение нескольких лет (m), то формула для расчета модифицируется:

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

- при NPV > 0 проект следует принять;

- при NPV < 0 проект не принимается,

- при NPV = 0 проект не имеет ни прибыли, ни убытков.

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

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

NPV=129 934,80 - следовательно при NPV > 0 проект следует принять.

Коэффициент возврата инвестиций ROI (Return of Investment) позволяет оценить прибыльность инвестиций, вложенных в проект.

Формула расчета ROI:

,

где NPV- чистый приведенный доход,

IC - стартовые инвестиции.

при ROI > 0 - инвестиции прибыльны,

при ROI < 0 - инвестиции убыточны.

ROI = 899,59% - следовательно при ROI > 100% - проект прибылен

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

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

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

IRR = i1 + NPV(i1) / [NPV(i1) - NPV(i2)] * (i2 - i1)

Инвестор сравнивает полученное значение IRR со ставкой привлеченных финансовых ресурсов (CC - Cost of Capital):

- если IRR > CC, то проект можно принять;

- если IRR < СС, проект отвергается;

- IRR = СС проект имеет нулевую прибыль.

При разработки информационной системы в ОВД г.Донецка я проводила расчёты экономической эффективности данного проекта.

Таблица 4.3 - Коэффициент дисконтирования

IRR = 40,13%

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

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

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

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

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

- унифицированное управление вычислительными ресурсами;

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

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

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

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

В первом разделе проведён анализ существующих решений в рассматриваемой предметной области, в результате которого было принято решение об автоматизации учета технических средств. Был произведен анализ предметной области и сбор требований затем, чтобы понять, как работает данная организация, рассмотреть процессы протекающие в ней. Следующим необходимым пунктом данного раздела стал анализ и моделирование требований методом структурного подхода. Построены IDEF0 - диаграммы, отражающие основные процессы разработки информационной системы учёта платежей. В дополнении к IDEF0 - диаграммам были созданы диаграммы потоков данных (Data flow diagrams, DFD) используются для описания документооборота и обработки информации. В заключительной части первого раздела проведена аттестация и спецификация информационной системы, которая включает в себя создание технического задания и технико-экономического обоснования.

Второй раздел дипломного проекта посвящён проектированию информационно системы учёта техники. В представленном разделе спроектирована архитектура создаваемой системы, разработан пользовательский интерфейс. Основным в данном разделе является проектирование самой информационной системы. Для этого, средствами MS Access была создана база данных и разработана схема данных. При помощи CASE-средства ERwin построена логическая и физическая модель данных. Данный раздел завершается обоснованием выбора платформы создания информационной системы, а именно, MS Access и MS Visual C#.

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

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

1. Акперов, И.Г. Управление проектами: учебно-методический комплекс/ И.Г. Акперов, В.А. Долятовский. - Ростов-на-Дону: ИУБиП, 1999.

2. Арчер Т. Основы C#. Новейшие технологии, СПб.: 2001.

3. Ахметов К. Практика управления проектами - Microsoft Project Professional 2003. М.: 2004. - 272 с.

4. Баглюк С.И., Мальцев М.Г., Смагин В.А., Филимонихин Г.В. Надежность функционирования программного обеспечения.-С.-Пб.:-1991.-78 cтр.

5. Богданов, В. Управление проектами в Microsoft Project 2002 / В. Богданов. - СПб.: Питер, 2003.

6. Вейскас Дж. Эффективная работа с Microsoft Access 2000 -СПб: Питер, 2001. - 1040 с.: ил.

7. Вендров А.М. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. Пособие. - М.: Финансы и статистика, 2004. - 192 с.: ил.

8. Гасанов Э. Э., В. Б. Кудрявцев. Теория хранения и поиска информации, М.: ФИЗМАТЛИТ, 2002. - 288 с.

9. Гетц К., Литвин П., Бэрон Р. Access. Сборник рецептов для профессионалов. 2-е изд., СПб.: Питер, 2004. - 784 с.

10. Грабауров В.А. Информационные технологии для менеджмента, СПб.: 2005.

11. Гуннерсон Э. Введение в C#, М.: 2001.

12. Дейт К. Дж. Введение в системы базы данных, М.: Издательский дом «Вильямс», 2002.

13. Закон РФ «о милиции», от 18 апреля 1991 г. N 1026-I

14. Калянов Г.Н. CASE-технологии: Консалтинг в области автоматизации бизнес-процессов., М.: Горячая линия-Телеком, 2000

15. Кортнер Д., Марквис А. Microsoft Project 2002, М.: 2006. - 621 с.

16. Крёнке Д. Теория и практика построения баз данных 9-е изд., СПб.: Питер, 2004. - 864 с.

17. Кронан А., Андерсен В. Microsoft Office Access 2003. Быстрые шаги, СПб.: 2003.

18. Культяев А.К. Microsoft Project 2002. Управление проектами, М.: 2003

19. Маклаков С.В. BPWin и ERWin. CASE-средства разработки информационных систем. Москва: Диалог-МИФИ, 2000.256 с

20. Маклаков С.В. Создание информационных систем с AllFusion Modeling Suite. - М.: ДИАЛОГ - МИФИ, 2003 - 432 с.

21. Марка Д.А., МакГоуэн К. Методология структурного анализа и проектирования. Москва, 1993 г.

22. Мармел Э. Microsoft Project 2002. Библия пользователя, М.: 2003

23. Методические указания по оформлению дипломных проектов, курсовых работ, отчетов о производственной практике / И.Г. Акперов, В.А. Долятовский, В.Н. Еременко. - Ростов н/Д: ИУБиП, 2002. - 26 с.

24. Мескон М.Х. Основы менеджмента, М.: Дело, 1997.

25. Микелсен К. Язык программирования C#. Лекции и упражнения. Учебник, СПб.: Питер, 2002. - 689 с.

26. Михеева В., Харитонова А. Microsoft Access 2003. Наиболее полное руководство, СПб.: 2002.

27. Научные работы: методика подготовки и оформления / Авт.-сост. И.Н. Кузнецов. 2-е изд., перераб. и доп. - Мн.: Амалфея, 2000. - 544 с.

28. Петров В. Н. Информационные системы. Учебник, СПб: Питер, 2002. - 668 с.

29. Положение о милиции общественной безопасности в РФ (Собрание актов Президента и Правительства).

30. Праг К., Ирвинг М. Access 2002. Библия пользователя, М.: 2003

31. Роберт Дж. Мюллер. Базы данных и UML. Проектирование. Лори. 2002. 420 стр.

32. Роберт Т.Фатреапп, Дональд Ф.Шаффер, Управление информационными проектами (достижение оптимального качества при минимуме затрат) М.: «Вильямс» 2004 год.

33. Секунов Н. Самоучитель C#, М.: 2001.

34. Сенов А. Access 2003. Практическая разработка баз данных, М.: 2005

35. Скрипкин, К.Г. Экономическая эффективность информационных систем. / К.Г. Скрипкин. - М.: ДМК Пресс, 2002.

36. Смирнов Д. Разработка и сопровождение проектов Microsoft Project 2003, СПб.: 2004

37. Смирнова Г.Н. Проектирование экономических информационных систем: Учебник/Г.Н. Смирнова, А.А. Сорокин, Ю.Ф. Тельнов; Под ред. Ю.Ф. Тельнова. - М. Финансы и статистика, 2003. - 512 с.: ил.

38. Стовер Т. Эффективная работа Microsoft Project 2002, СПб.: 2003. - 452 с.

39. Уткин В.Б. Информационные системы в экономике, М.: Академия, 2006

40. Хаммер М. Чампи Дж. Реинжиниринг корпорации: Манифест революции в бизнесе, СПб.: Изд. СПб ун-та, 1997

41. Хандхаузен Р. Знакомство с Microsoft Visual Studio 2005, М.: 2006. - 416 с.

42. Черемных, С.В. Структурный анализ систем: IDEF-технологии, М.: Финансы и статистика, 2001.

43. Шеер А. Моделирование бизнес-процессов, СПб.: Питер, 2002. 344 с.

44. Шилдт. Полный справочник по C#, М.: Вильямс, 2004. - 752 с.

45. Эндрю Троелсен. C# и платформа . NET | Книги / Компьютерная литература / Интернет. Веб-дизайн / .NET, СПб.: Питер-пресс, 2002. - 800 с.

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

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

Заказчиком системы является ОВД г.Донецка. Исполнителем выступает студентка 5 курса кафедры «Управления и Информационных технологий» института «Управления, Бизнеса и Права» Ковалева Елена.

Дата начала работ: 15.10.2005 г.

Дата окончания работ: 16.06.2006 г.

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

НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ АИС

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

Создаются следующие рабочие места:

Администратор системы - полный контроль над системой, внесение любых изменений в настройки.

Учетчик - доступ к учетным таблицам.

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

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

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

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

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

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

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

Внедряемая, АИС должна иметь русскоязычный интерфейс.

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

СОСТАВ И СОДЕРЖАНИЕ РАБОТ

Разработка программного комплекса: разработка новых программ и изменение существующих решений под требования заказчика. Сроки выполнения: 15.10.2005 - 16.06.2006

Установка и наладка программного обеспечения. Сроки выполнения: 20.05.2005 - 1.06.2006

Тестирование и доработка АИС. Сроки выполнения: 1.06.2006 - 19.06.2006

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

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

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

ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ ОБЪЕКТА К ВВОДУ В ДЕЙСТВИЕ СИСТЕМЫ

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

План тестирования определяется международным стандартом IEEE 829-1983.

1. Объект тестирования: информационная система МРССиСТ.

2. Дата тестирования: 19.05.2006

3. Составитель теста: студентка Ковалева Е.Н.

4. Цель тестирования: выполнялся для полной проверки работоспособности программы;

5. Тип тестирования: тестирование методом черного ящика. Проводится тестирование в целом свей системы учёта оргтехники и средств связи.

6. Описание среды тестирования - ОС MS Windows XP, Microsoft Access 2003, MS Visual C#.

Таблица Е.1 - Выбор модели ЖЦ на основе характеристик требований

Таблица Е.2 - Выбор модели ЖЦ на основе характеристик участников команды разработчиков

Таблица Е.З - Выбор модели ЖЦ на основе характеристик типа проектов и рисков

Таблица Е.4 - Выбор модели ЖЦ на основе характерактеристик пользователей