Аннотация

Данный дипломный проект содержит 86 листов текста диплома, 18 рисунков, 4 таблицы, 5 приложений, 39 источников литературы.

ИНФОРМАЦИОННАЯ СИСТЕМА, РАБОТА С ДАННЫМИ, ИНТЕФЕЙС, ТРЕБОВАНИЯ, МОДЕЛЬ ЖИЗНЕННОГО ЦИКЛА, МОДЕЛИРОВАНИЕ, ПРОЕКТИРОВАНИЕ, РЕАЛИЗАЦИЯ, ЛОГИЧЕСКАЯ МОДЕЛЬ СТРУКТУРЫ ДАННЫХ, ФИЗИЧЕСКАЯ МОДЕЛЬ СТРУКТУРЫ ДАННЫХ, БАЗА ДАННЫХ, ТЕСТИРОВАНИЕ, ФИЗИЧЕСКОЕ ПРЕДСТАВЛЕНИЕ СИСТЕМЫ, ЛОГИЧЕСКОЕ ПРЕДСТАВЛЕНИЕ СИСТЕМЫ.

Темой дипломного проекта является «Информационная система учета призывников в администрации (на примере администрации с. Казинка)».

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

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

СОДЕРЖАНИЕ

Введение

1. Разработка требований к программному обеспечению

1.1 Анализ существующих решений по автоматизации предметной области

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Тестирование приложения

3.4Методика развертывания приложения

4.Управление информационным проектом

4.1Выбор жизненного цикла разработки ПО

4.2 Определение цели и области действия программного проекта

4.3Создание структуры пооперационного перечня работ

4.4Идентификация задач и действий

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

4.6Оценка длительности и стоимости разработки проекта

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

4.8 Оценка экономической эффективности проекта

ЗАКЛЮЧЕНИЕ

Список литературы

ПРИЛОЖЕНИЕ А - Спецификация требований к программному обеспечению

ПРИЛОЖЕНИЕ Б – Прототиты пользовательского интерфейса

ПРИЛОЖЕНИЕ В – Атрибуты управляющих таблиц проектируемой ИС

ПРИЛОЖЕНИЕ Г - Выбор модели жизненного цикла

ПРИЛОЖЕНИЕ Д – Диаграмма Гантта

ВВЕДЕНИЕ

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

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

Далее описывается значимость ИС для данной сферы деятельности. Основные решаемые задачи.

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

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

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

¾ получение выходных документов (структурированная информация содержащая вcе необходимые сведения о военнообязанных лицах);

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

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

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

¾ провести анализ бизнес-процессов воинского учета;

¾ исследовать информационные потоки, возникающие в системе;

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

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

¾ провести оценку экономической эффективности информационной системы.

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

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

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

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

1. РАЗРАБОТКА ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

1.1 Анализ существующих решений по автоматизации предметной области

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

Из существующих информационных систем можно выделить программную разработку "1С:Предприятие 8.0 Управление персоналом " компании 1С. предназначена для реализации кадровой политики компании по следующим направлениям: планирование потребностей в персонале, обеспечение бизнеса кадрами, кадровый учет, ведение регламентированного документооборота [1].

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

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

¾ Федеральный закон от 26 февраля 1997 года № 31-ФЗ "О мобилизационной подготовке и мобилизации в Российской Федерации";

¾ Постановление Правительства РФ от 25 декабря 1998 года № 1541 "Об утверждении положения о воинском учете".

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

¾ Данные для постановки на учет в военкомате;

¾ Численность граждан запаса (формы №6 и 11/МУ);

¾ Список граждан, подлежащих постановке на воинский учет;

¾ Список принятых и уволенных военнообязанных;

¾ Список юношей 15-16 лет;

¾ Список для первоначальной постановки юношей на воинский учет;

¾ Список принятых и уволенных призывников

Недостатками данной системы является:

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

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

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

К еще одной информационной системе на которую стоит обратить внимание, можно отнести программный продукт ООО Научно-производственного центра «КОСМОС-2», Автоматизированная информационная система (АИС) Сельского Административного образования (САО) сокращенно (АИС САО) [2]. Система служит для автоматизации хозяйственной деятельности, похозяйственной книги, операций, выполняемых работниками муниципальных сельских администраций:

¾ ведение похозяйственного учета (в объеме книги похозяйственного учета)

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

¾ учет земельных участков и объектов недвижимости на территории, прав жителей на эти объекты,

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

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

¾ оформление и печать справок, выписок, постановлений,

¾ регистрации пребывания граждан с подготовкой пакета документов,

¾ воинский учет с подготовкой пакета документов (повестки, акты, анкета).

Система имеет многоуровневую структуру, объединяя 9 Автоматизированных Рабочих Мест (АРМ), в число которых входит АРМ «Данные о жителях»

АРМ «Данные о жителях» позволяет реализовать следующие функции на основании реестра населения, формируемого системой:

¾ Подготовка и печать произвольных списков жителей. Как частный случай – подготовка списка призывников.

¾ Получать данные о собственности как отдельных персоналий, так и всей семьи (т.е. для членов хозяйства как для сельских подворий, так и для подворий МКД).

¾ Подготовка списков юбиляров.

¾ Учет и оформление документов по регистрации граждан.

В том числе:

¾ Учет и оформление документов по воинскому учету.

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

¾ Относительно высокая стоимость продукта;

¾ Наличие специалиста для конфигурирования системы.

К последней информационной системе, которая будет рассмотрена в данном дипломном проекте, относится программный продукт ЗАО ИВЦ ИНСОФТ «Система Персонального Учета Населения» (СПУН).
Система Персонального Учета Населения создана с целью формирования информационной базы для реализации процедур регистрации в рамках решаемых различными ведомствами задач Российской Федерации. В рамках данной системы имеется конфигурация для регистрация граждан, имеющих статус военнообязанных. Система обладает необходимым набором средств для учета и оформление документов по воинскому учету[
3].

Недостатками данной информационной системы является:

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

¾ Наличие высокоскоростного подключения в Интернет для режима постоянного доступа (on-line).

1.2 Анализ предметной области

Анализ предметной области необходимо проводить для:

¾ Определения функциональной направленности предприятия;

¾ Определения перечня структурных звеньев предприятия.

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

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

Рисунок 1.1 – Организационная структура администрации

Ниже перечислены функции подразделений администрации:

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

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

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

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

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

Основными функциональными задачами отдела воинского учета являются:

¾ Постановка граждан на первоначальный воинский учет;

¾ Снятие с учета по причине смены места жительства;

¾ Снятие с учета по достижении возраста 50 лет;

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

Моделирование бизнес процессов отдела воинского учета проведено с использованием CASE-средства RanionalRose [5,6]. Разработанная диаграмма бизнес-вариантов использования представлена на рис. 1.2. Она отображает перечисленные выше функциональные задачи отдела и показывает основные бизнес-актеров данного процесса.

Рисунок 1.2 – Диаграмма бизнес-вариантов использования отдела воинского учета.

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

1.3 Сбор требований

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

В данном проекте для сбора требований была выбрана методика «Интервьюирование» которая рассматривает следующие этапы:

1. Разрабатываются вопросы

2. Производится выбор опрашиваемых пользователей.

3. Планируются контакты.

4. Проводится интервью.

5. Завершается встреча.

6. Определяются последующие действия.

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

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

¾ Глава администрации;

¾ Инспектор ВУС (Военно-учетного стола отдела воинского учета);

¾ Специалист первой категории администрации.

На рисунке 1.3 представлена диаграмма вариантов использования ИС [5], представляющая процессы, происходящие в ИС отдела воинского учета.

Рисунок 1.3 – Диаграмма вариантов использования ИС отдела воинского учета.

1.4 Спецификация требований

Определение корректных требований — ответственный этап программного проекта. Формат проекта должен соответствовать требованиям к ПО, собранным командой разработчиков или одним разработчиком, в противном случае эти требования не смогут быть поддержаны и представлены в программном продукте. Спецификация требований к ПО - SoftwareRequirementsSpecification(SRS) имеет ключевое значение для всего жизненного цикла разработки программного продукта. Это не только производный документ, в котором определены спецификации программного проекта, но и основной документ, применяемый с целью проведения аттестационных и приемочных испытаний. Аттестация — это оценка качества работы менеджеров проекта. Она определяет степень соответствия программного продукта установленным требованиям. Спецификация SRS выступает в роли некоего механизма фиксирования системных требований, которые используются в качестве критериев при аттестации [7].

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

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

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

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

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

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

В SRS документе рассматривается сам продукт, а не процесс разработки проекта, поэтому на ее основании можно производить расширение завершенного продукта.

Спецификация требований к реализуемому программному обеспечению представлена в ПРИЛОЖЕНИИ А.

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

1.5 Аттестация требований

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

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

Прототип основного меню данного модуля представлен на рисунке 1.4.

Рисунок 1.4 – Схема основного меню программы

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

¾ Создание новой записи о гражданине.

¾ Загрузки данных из базы данных «Призывник» и действия с данными;

¾ Загрузки данных из базы данных «Запасник» и действия с данными;

¾ Загрузки данных из базы данных «Снятые с учета» и действия с данными;

¾ Загрузки данных из базы данных «Служащие в армии» и действия с данными;

¾ Загрузки данных из базы данных «Непригодные к службе» и действия с данными.

Прототипы диалоговых окон программы представлены в Приложении Б.

1.6 Выбор методологии проектирования информационной системы

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

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

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

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

Наиболее подходящей методологией проектирования ИС отдела воинского учета является объектно-ориентированная.

Выводы

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

2. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ

2.1 Архитектурное проектирование

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

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

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

¾ соответствие с миссией организации;

¾ определенность в требованиях;

¾ направленность в разработке;

¾ возможность к адаптации;

¾ необходимость гибкости.

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

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

¾ файл-серверная;

¾ клиент-серверная;

¾ многоуровневая.

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

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

2. Многопользовательская работа с OLAP-приложениями и исходными данными в виде локальных таблиц на файл-сервере. Тогда на компьютере пользователя устанавливается только Контур Стандарт с OLAP-машиной. Такая архитектура обеспечивает работу группы пользователей (например, бухгалтерии) с одним и тем же аналитическим приложением. Доступ пользователей группы к файлу OLAP-приложения регламентируется средствами операционной системы [4].

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

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

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

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

На рисунке 2.1 представлена схема клиент-серверной архитектуры.

Рисунок 2.1 – клиент-серверная архитектура.

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

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

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

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

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

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

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

Архитектура приложения, разделяющая пользовательские и прикладные сервисы и сервисы данных. Другое название - трехуровневая архитектура, однако термин «многоуровневая» корректнее, поскольку он предполагает, что при логическом проектировании может возникнуть более трех уровней сервисов. МНОГОУРОВНЕВАЯ АРХИТЕКТУРА ПРИЛОЖЕНИЯ (multi-tiered architecture), способ организации взаимодействия программ или компонентов программы. Как правило, Многоуровневая архитектура приложения используется в распределенных приложениях, компонеты которых выполняются на разных компьютерах. Частным случаем Многоуровневая архитектура приложения является архитектура клиент-сервер. В последнее время в информационных системах получила распространение архитектура, в которой распределенное приложение состоит из компонентов трех уровней:

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

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

¾ компонент, реализующий интерфейс с пользователем, исполняется на рабочей станции [4].

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

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

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

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

¾ спецификации исполнимого варианта программной системы;

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

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

Диаграмма компонентов системы представлена на рисунке 2.2.

Рисунок 2.2 – диаграмма компонентов информационной системы.

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

Диаграмма размещения представлена ниже на рисунке 2.3.

Рисунок 2.3 – диаграмма размещения информационной системы.

2.2 Проектирование интерфейса информационной системы

Разработка пользовательского интерфейса включает те же основные этапы, что и разработка программного обеспечения:

1. Определение типа интерфейса и общих требований к нему.

2. Определение сценариев использования.

3. Определение пользовательской модели интерфейса.

4. Программирование и тестирование программных интерфейсов.

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

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

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

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

Пользовательский интерфейс проектируемой информационной системы имеет следующую структуру: после запуска приложения открывается главная форма, которая содержит основное меню, состоящее из 3-ти пунктов меню: Файл, Данные, Помощь. Прототип пользовательского интерфейса ПРИЛОЖЕНИИ Б.

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

Основными целями проектирования базы данных являются:

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

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

¾ разработка предварительного варианта проекта, структура которого позволяет удовлетворить все основные требования, предъявляемые к производительности системы — например, ко времени реакции системы [16].

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

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

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

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

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

На рисунке 2.4 пример концептуальной модели, на базе анализа сущностей

Рисунок 2.4 – Концептуальная модель данных ИС.

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

На рисунке 2.5 пример логической модели, на базе анализа сущностей

Рисунок 2.5 – Логическая модель данных ИС.

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

Физической СУБД для ИС отдела воинского учета выбрана СУБД MicrosoftSQLServer 2005 . Этот выбор осуществлен потому, что приложение будет функционировать на нескольких рабочих станциях используя базу данных одновременно по локальной сети. Также следует отметить, что СУБД MSSQLServer положительно зарекомендовала себя в процессе эксплуатации.

СУБД MSSQLServer компании Microsoft начала разрабатываться в 1988 и изначально предназначалась для платформы OS/2 [19,20]. Последующие версии этого сервера баз данных предназначались для платформы WindowsNT и со временем были тесно интегрированы с этой операционной системой. Для других платформ версии этого сервера не выпускаются и не выпускались.

Удобный пользовательский интерфейс утилит администрирования в сочетании с достаточно высокой производительностью и относительно невысокой стоимостью эксплуатации сделал эту серверную СУБД второй по популярности - после Oracle.

Клиентские приложения для MicrosoftSQLServer и MSDE можно создавать как с помощью средств разработки Microsoft - VisualBasic, VisualC++, С#, Access и VisualFoxPro, так и с помощью средств разработки других производителей. Для этой цели имеются ODBC-драйвер и OLEDB-провайдер, а также содержащий их набор библиотек MicrosoftDataAccessComponents (MDAC), позволяющий использовать в средствах разработки объекты ActiveXDataObjects (ADO) - COM-объекты для доступа к данным. MDAC является составной частью WindowsXP, а для пользователей других Windows-платформ доступен отдельно на Web-сайте Microsoft.

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

В настоящее время наиболее широко используемой является версия MSSQLServer 2005. В состав MicrosoftSQLServer 2005 входят простые утилиты администрирования (EnterpriseManager), сервисы преобразования данных (DataTransformationServices), облегчающие перенос данных в SQLServer из других типов СУБД, поддержка распределенных запросов и транзакций, OLAP-сервер и утилиты для создания хранилищ данных (в том числе данных из других серверных СУБД.

¾ масштабируемость и надежность. SQL Server 2005 обеспечивает практически неограниченный рост объемов данных за счет увеличения надежности и масштабируемости системы, используя все преимущества мультипроцессорной обработки данных. SQL Server 2005 Enterprise Edition обеспечивает параллельность обработки данных

¾ высокая скорость построения решений. SQL Server 2005 уменьшает время создания, развертывания и выхода на рынок современных приложений для задач бизнеса, электронной коммерции, использует встроенный отладчик T-SQL. Совершенствует и ускоряет процесс поиска данных, упрощает управление, позволяет использовать создаваемые пользователем функции в других приложениях [22,26].

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

Рисунок 2.6 – Схема физической модели данных для ИС отдела воинского учета

2.4 Обоснование выбора платформы создания информационной системы

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

Чтобы средства разработки и технологии отвечали требованиям разработчиков, в корпорации Майкрософт была создана совершенно новая модель программирования для доступа к данным, основанная на .NETFramework. Построение на основе .NETFramework гарантирует единообразие доступа к данным: компоненты используют систему общих типов, общие шаблоны разработки и соглашения о пространствах имен [24,25].

В .NETFramework поддерживается прямая и обратная совместимость. В контексте .NETFramework обратная совместимость означает, что любое приложение, созданное в .NETFramework более ранней версии, будет выполняться и в более поздней версии[29]. Прямая совместимость означает возможность выполнения приложения, созданного в более поздней версии .NETFrameworkSDKv 2.0, в .NETFramework более ранней версии.

Классы ADO.NET были разработаны для поддержки возможностей новой модели программирования: интеграции с XML, единого представления данных с возможностью комбинирования данных из различных источников, а также средств оптимизации взаимодействия с базой данных, представленных в .NETFramework [29].

Структура ADO.NET создана для решения задач современной модели разработки приложений. В то же время модель программирования по возможности приближена к ADO, что упрощает переход разработчиков ADO к новой среде. ADO.NET является неотъемлемой частью .NETFramework, оставаясь понятной программистам ADO[28].

.NET представляет собой совершенно новый способ создания распределенных настольных и встроенных приложений. Для типов .NET не нужны ни фабрики классов, ни поддержка IUnknown, ни регистрация в системном реестре. Эти основные элементы СОМ не скрыты – их просто больше нет.

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

Платформа .NET является полностью независимой от используемых языков программирования. Можно использовать несколько .NET-совместимых языков программирования даже в рамках одного проекта.

Основные возможности .NET следующие:

¾ Полные возможности взаимодействия с существующим кодом;

¾ Полное и абсолютное межъязыковое взаимодействие, межъязыковая обработка исключений и межъязыковая отладка;

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

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

¾ Отсутствует сложность СОМ;

¾ Действительное упрощение процесса развертывания приложения.

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

MicrosoftVisualStudio 2005 продолжает поддерживать технологии Microsoft .NETFramework уже в версии Microsoft .NETFrameworkSDKv2.0, которые предоставляют общеязыковую среду выполнения и унифицированные классы программирования. Также в VisualStudio включена библиотека MSDN, содержащая документацию по данным инструментам разработки.

Платформа Microsoft.NET для отображения данных на компьютере конечного пользователя и его интерактивного взаимодействия с системой. предоставляет класс System.Windows.Forms.Form и большое разнообразие классов элементов управления, дочерних от класса Control. Функциональность уровня представления во многом определяется составом элементов управления, входящих в коллекцию Controls для конкретной формы [29].

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

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

Бизнес-логика описывается набором методов, реализующих бизнес-транзакцию. Для платформы Microsoft.NET это типовое решение сценарий транзакций использует прямой доступ к базе данных и базируется на использовании объектов классов DataCommand и DataReader технологии ADO.NET, а так же используя bindingSource, TableAdapter, DataSet . Класс, реализующий сценарий транзакций, обеспечивает прямой доступ к источнику данных и необходимую функциональность бизнес-логики. Для данного типового решения все обязанности по реализации бизнес-логики возлагаются на методы сценария транзакций.

Для разрабатываемой информационной системы выбрана платформа MicrosoftVisualStudio 2005. В качестве языка реализации приложения выбран C# [23,26].

2.5 Проектирование модулей (объектно-ориентированные модели)

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

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

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

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

Определение с учётом ограничений налагаемые на архитектуру компонентов проектируемой системы, построение диаграммы компонентов.

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

Рисунок 2.7 - Диаграммы Состояний (Statechart) Информационной системы

Рисунок 2.8 - Диаграммы Компонентов (Component) Информационной системы

Выводы к разделу

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

3. РЕАЛИЗАЦИЯ И АТТЕСТАЦИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ

3.1 Реализация приложения

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

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

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

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

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

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

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

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

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

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

3.2 Взаимодействие приложения с источниками данных

Взаимодействие приложения с источником данных осуществляется при помощи запросов языка SQL. SQL (Structured Query Language) является инструментом для выборки и обработки информации, содержащейся в базе данных. SQL является языком программирования, который применяется для организации взаимодействия пользователя с базой данных [21]. Если пользователю необходимо получить информацию из базы данных, он запрашивает её у СУБД при помощи SQL. СУБД обрабатывает запрос, находит требуемые данные и посылает их пользователю [16]. Процесс запрашивания данных и получения результата называется запросом к базе данных. SQL используется для реализации всех функциональных возможностей, которые СУБД предоставляют пользователю:

¾ организация данных;

¾ выборка данных;

¾ обработка данных;

¾ совместное использование данных;

¾ управление доступом;

¾ целостность данных.

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

¾ последовательная, безопасная модификация данных;

¾ уменьшение сетевого трафика;

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

¾ перестройка и повторное использование схемы выполнения;

¾ автоматическая настройка параметра запроса;

¾ обеспечение модульной структуры приложения;

¾ совместное использование в нескольких приложениях;

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

3.3 Тестирование приложения

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

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

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

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

¾ тестирование дефектов обусловленных ошибками в программе(синтаксические ошибки, ошибки периода выполнения, логические ошибки);

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

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

Тестирование приложения проводилось с помощью стандартных инструментов предоставляемых Microsoft Visual Studio 2005.

Режим пошагового исполнения кода позволяет построчно анализировать программу для диагностики и исправления ошибок. VisualStudio 2005 предоставляет несколько вариантов пошагового исполнения:

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

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

¾ Step Out исполняет текущую функцию до конца и останавливается (если возможно) на следующей строке функции, из которой была вызвана текущая процедура;

¾ Run To Cursor позволяет установить курсор в некоторую строку и исполнить весь код до этой строки;

¾ Set Next Statement (назначить следующий оператор) позволяет назначить следующий оператор для исполнения, при этом все строки до этого оператора будут пропущены.

Точки прерывания — это строки кода, назначенные во время отладки, по достижении которых исполнение останавливается, а приложение переходит в режим пошагового исполнения. Для точек прерывания можно назначать дополнительные условия, определяющие обстоятельства, при которых эти точки активируются. Для управления точками прерывания предназначено окно Breakpoints,позволяющее создавать, отключать и удалять их [25,26,29].

VisualStudio 2005 предоставляет ряд инструментов для наблюдения за исполнением программы. Окна Locals, Autos и Watch позволяют отслеживать значения переменных программы во время ее исполнения; окно Command позволяет исполнять код и получать значения переменных и свойств. Имеются также дополнительные окна для наблюдения за самыми разными данными приложения [26].

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

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

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

¾ Проверка типичных значений аргументов;

¾ Проверка обработки минимальных и максимальных значений аргументов;

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

¾ Комбинированные примеры.

3.4 Методика развертывания приложения

Чтобы приложение оценили по достоинству, оно прежде всего должно оказаться на компьютерах своей целевой аудитории. Microsoft Visual Studio 2005 поддерживает самые разные способы развертывания проектов: от простейшего с использованием команды XCOPY до самого сложного и гибкого с применением программы Microsoft Windows Installer.

Простые приложения .NET Framework позволяет развертывать, просто копируя их каталоги на клиентские компьютеры. Для развертывания более сложных приложений в Visual Studio 2005 предусмотрена технология Windows Installer, позволяющая создавать проекты установочных программ с широкими возможностями настройки [24,26,34].

Но для того чтобы приложение работало на компьютере клиента должна быть установлена требуемая версия общеязыковой среды исполнения Frameworks, в данном случае под данную информационную систему необходимо установить Microsoft .NET Framework SDK v2.0. В данном наборе библиотек классов есть все классы которые потребуются разработанной информационной системе. Для развертывания приложения были использованы инструменты с использованием команды XCOPY и установки на компьютер клиентам Microsoft .NET Framework SDK v2.0 [26].

Выводы к разделу

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

4. УПРАВЛЕНИЕ ИНФОРМАЦИОННЫМ ПРОЕКТОМ

4.1 Выбор жизненного цикла разработки ПО

Жизненный цикл – совокупность стадий и этапов, которые проходит информационная система в своём развитии от момента принятия решения о создании системы до момента прекращения её функционирования [35, 39].

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

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

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

Таблицы с вопросами, ответы на которые будут определять оптимальную модель жизненного цикла для информационной системы приведено в ПРИЛОЖЕНИИ Г.

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

Таблица 4.1 – Определение оптимальной модели жизненного цикла в баллах.

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

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

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

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

В последнее время широкое распространение методология быстрой разработки приложений RAD (RapidApplicationDevelopment). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 4.2 – определение размера приложения по методологии RAD

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

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

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

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

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

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

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

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

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

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

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

4.2 Определение цели и области действия программного проекта

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

К модулям относятся:

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

¾ Отчеты, создаваемые по введенным критериям;

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

4.3 Создание структуры пооперационного перечня работ

Процесс создания Информационной системы для отдела Воинского учета представляется в виде перечня работ, реализованном в прикладном пакете MicrosoftOfficeProject 2003 и включающий следующие этапы:

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

¾ изучение бизнес-цели проекта;

¾ постановка задач;

¾ создание технического задания;

¾ определение спецификаций проекта;

¾ оценка стоимости проекта;

¾ проектирование;

¾ определение логических объектов;

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

¾ определение функций системы;

¾ определение вариантов использования;

¾ проектирование уровня данных;

¾ проектирование уровня бизнес-логики;

¾ проектирование пользовательского интерфейса

¾ реализация;

¾ разработка уровня данных;

¾ разработка уровня бизнес-логики;

¾ разработка пользовательского интерфейса;

¾ интеграция системы;

¾ тестирование;

¾ отладка.

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

4.4 Идентификация задач и действий

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

Таблица 4.3 – Ресурсы проекта

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

Для оценки размера описываемого приложения был применен метод оценки количества строк кода LOC(LinesofCode). Данный метод заключается в подсчете созданных классов, а так же определенных методах в классах приложения. В данной разрабатываемой системе количество созданных классов будет равняться 10, а количество методов приходящихся на каждый класс будет рано в среднем 12. Так же необходимо определить какое количество строк кода(LOC) приходится на один метод. В зависимости от функций выполняемых определенным методом, количество строк кода будет колебаться от 10 – до 30. В общем же количество строк кода разрабатываемой системы равно 1700. Данные цифры являются усредненными, т.к. невозможно подсчитать точную цифру на этапе проектирования или разработки информационной системы.

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

4.6 Оценка длительности и стоимости разработки проекта

Проект – это уникальный процесс, в ходе выполнения которого получают уникальный продукт. Управление проектом – это процесс планирования, организации и контроль состояния задач и ресурсов проекта, направленный на своевременное достижение цели проекта [7].

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

¾ соблюдение директивных сроков завершения проекта;

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

¾ своевременная коррекция исходного плана в соответствии с реальным положением дел.

Для автоматизации управление проекта использовался пакет MicrosoftProject 2003. Автоматизированное средство MicrosoftProject является широко распространённой системой управления проектами. К тому же данная система проста в применении. Проект состоит из серии взаимосвязанных задач, составляющих основу плана работ. Задача должна представлять определённую часть работы с ясной постановкой, но в тоже время должна быть достаточно короткой, чтобы иметь возможность регулярно отслеживать её исполнение и идентифицировать проблемы на ранних этапах [7].

Управление проектами в пакете MicrosoftProject 2003 первым шагом подразумевает построение календарного графика работ. Календарный график строится на основе диаграммы Гантта. Диаграмма Гантта – это линейный график, задающий сроки начала и окончания взаимосвязанных работ, с указанием ресурсов, используемых для их выполнения [7]. ПРИЛОЖЕНИЕ Д.

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

Рисунок
4.1 – Фрагмент сетевого графика

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

Рисунок
4.2 – Свойства проекта

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

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

1. Выделить цели работы системы.

2. Определить наборы показателей, характеризующих определенную цель.

3. Определить уровень достижения показателя.

4. Рассчитать степень достижения каждой цели по выдвинутым показателям.

5. Определить весовые коэффициенты целей.

6. Рассчитать общий показатель эффективности разрабатываемой информационной системы.

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

, (4.1)

где u(g_i
) – степень достижения цели, баллы;

– значение показателя, баллы;

K – количество показателей.

Весовой коэффициент вычисляется по формуле:

, (4.2)

где – весовой коэффициент, баллы;

V_i
– оценка, баллы.

Расчет оценки ведется по формуле:

(4.3)

где V_i
– оценка, баллы;

R_min
– минимальное значение ранга, баллы;

R_i
– сумма рангов, баллы.

Для расчета суммы рангов воспользуемся формулой:

, (4.4)

где R_i
– сумма рангов, баллы;

r_i
– значение, выставленное экспертом, баллы;

n – количество экспертов.

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

Общий показатель эффективности рассчитывается как:

, (4.5)

где E_m
– показатель эффективности, баллы;

w_i
– весовой коэффициент, баллы;

u(g_i
) – степень достижения цели, баллы.

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

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

Все это сведем в таблицу (таблица ).

Таблица – Цели, показатели и уровень достижения работы ИС

На основе формулы 4.1 рассчитаем степень достижения целей. Расчет:

.

.

.

.

.

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

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

¾ Люди;

¾ Техника;

¾ Механизмы;

¾ Различные расходные материалы.

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

Рисунок
4.3 – Список ресурсов

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

¾ оценить потребность в ресурсах;

¾ спланировать рациональное распределение потребности в ресурсах во времени;

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

¾ контролировать расходование ресурсов при реализации проекта.

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

Пример назначения ресурса задачи можно видеть из рисунка 4.4.

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

Рисунок
4.4 – Ресурс для задачи «Построение физической модели данных системы»

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

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

Рисунок
4.5 – Таблица использования ресурса «Инженер испытатель»

MSProject 2003 предоставляет возможность просмотра календаря ресурса. Календарь ресурса – это распределение рабочего и нерабочего времени для конкретного ресурса. Используя диалоговое окно «Календарь ресурса», менеджер может задавать различные параметры, отражающие характеристики Рабочего времени ресурсов. Так для каждого ресурса определяется тип календаря, количество рабочих и выходных дней, ежедневный график работы. На рисунке 4.6 представлен пример календаря для ресурса «Инженер испытатель».

Рисунок
4.6 – Календарь ресурса « Инженер испытатель»

4.8 Оценка экономической эффективности проекта

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

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

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

¾ получение выходных документов (структурированная информация содержащая вcе необходимые сведения о военнообязанных лицах);

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

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

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

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

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

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

Выводы к разделу

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

Физическое представление системы заключалось в построении диаграммы компонентов системы и диаграммы развертывания. Программа была спроектирована как трехзвенное приложение состоящее из: модулей Systems.Windows.Forms, сервера и сервера базы данных MSSQLServer 2005.

В ходе осуществления процесса проектирования выполнено моделирование структуры данных (логическая и физическая модели). Программное средство используемое для создания CASE-средства использовался программный продукт Rational Rose 2000 Enterprise Edition. Был рассмотрен использованный программный инструментарий. В качестве среды разработки программного обеспечения была использована MicrosoftVisualStudio 2005 и язык программирования C#. Для управления контроля версиями программного продукта использовалось стандартное средство из свойств проекта PublishVersion.

В третьем разделе дипломного проекта рассмотрена реализация программного продукта и вопросы связанные с реализацией. Реализованы функции и классы взаимодействия с базой данных. Приведены методы и свойства классов. Продемонстрирован фрагментарно исходный код. Так же рассмотрена и продемонстрирована методика взаимодействия приложения с СУБД MSSQLServer 2005. Проведено тестирование программного кода с использованием стандартных средств предоставляемых Microsoft Visual Studio 2005.

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

В четвертом разделе дипломного проекта определялась цель и область действия программного продукта. Осуществлен выбор модели жизненного цикла процесса разработки по результатам, представленным в таблице 4.1 – «Определение оптимальной модели жизненного цикла в баллах». Составлена структура пооперационного перечня работ с использованием пакета управления проектами Microsoft Project 2003, на её основе построен график выполнения работ, приведена диаграмма Гантта.

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

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

СПИСОК ЛИТЕРАТУРЫ

1. 1C
: Предприятие [Электронный документ] (http://v8.1c.ru.) Проверено 07.06.2007

2. ООО Научно-производственный центр «КОСМОС-2» [Электронный документ] (http://www.cosmos2.aaanet.ru/
) Проверено 07.06.2007

3. ЗАО ИВЦ ИНСОФТ [Электронный документ] (http://projects.economy.gov.ru/
) Проверено 07.06.2007

4. Визуальный словарь [Электронный документ] (http://i.viwo.ru/ ) Проверено 07.06.2007

5. Боггс У., Боггс М. UML и RationalRose. 2002. / Боггс У., Боггс М. – М.: ЛОРИ. - 2002. - 582 с.

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

7. Вигерс, К. Разработка требований к программному обеспечению.: Пер. с англ. / К. Вигерс.:– М.: Издательско-торговый дом «Русская редакция», 2004

8. Фатрелл, Т. Управление программными проектами: достижение оптимального качества при минимуме затрат.: Пер. с англ. / Р.Т. Фатрелл, Д.Ф. Шафер, Л.И. Шафер. – М.: Издательский дом "Вильямс", 2003.

9. Вигерс, К. Разработка требований к программному обеспечению.: Пер. с англ. / К. Вигерс.:– М.: Издательско-торговый дом «Русская редакция», 2004.

10. Мацяшек, Л.А. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML
. ./ Л. А. Мацяшек. Пер. с англ. – М.: Издательский дом «Вильямс». – 2002.

11. Атре, Ш. Структурный подход к организации баз данных / Ш. Атре.: Пер. с англ. А.А. Александрова и В.Ш. Будзко; под ред В.И. Будзко. – М.: Финансы и статистика. 1983. – 468 с.

12. Алехина, Г.В. Информационные технологии в экономике и управлении. / Г.В. Алехина.– М.:МЭСИ, 2002. – 635 с.

13. Буч Г. Объектно-ориентированный анализ и проектирование. / Буч Г.: Пер. с англ. – М: «Издательство Бином», 1999.

14. Буч Г., Рамбо Д., Джекобсон А. UML
– руководство пользователя. / Буч Г., Рамбо Д., Джекобсон А.: Пер с англ. – М: «ДМК», 2001

15. Избачков, Ю.С. Информационные системы. Учебник для вузов / Ю.С. Избачков, В.Н. Петров. 2-е изд. – СПб.: Питер, 2005.
– 739 с.

16. Microsoft Corporation
Проектирование и реализация баз данных Microsoft SQL Server 2000. Учебный курс MCAD/MCSE, MCDBA/Пер. с англ. — 2-е изд., испр. — М.: Издательско-торговый дом Русская Редакция,

17. 2003. - 512стр.

18. Конноли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. / Конноли Т., Бегг К.: Пер. с англ. – М.: Изд. Дом «Вильямс», 2001. – 1120 с.

19. Дейт, К. Дж. Введение в системы баз данных. / К. Дж. Дейт.: Пер. с англ. – М.: Изд. Дом «Вильямс», 2002. – 1072с.

20. Диго, С.М. Проектирование и использование баз данных. / С.М. Диго. - М.: Финансы и статистика. 1995. – 216с.

21. Когаловский, М.Р. Энциклопедия технологий баз данных / М.Р. Когаловский. – М.: Финансы и статистика, 2002. – 800с.

22. Грофф, Дж. Р. Энциклопедия SQL. / Дж. Р. Грофф, П. Н. Вайнберг.: Пер. с англ. – СПб: «Питер», 2003. – 896 с.

23. Страуструп Б. Язык программирования С++, 3-е изд./Пер. с англ. – М.: «Издательство Бином», СПб: «Невский диалект», 1999. – 991 с.

24. Лабор В.В., Си Шарп: Создание приложений для Windows
/ В. В. Лабор.— Мн.: Харвест, 2003. -384 с.

25. Джесс Либерти. MicrosoftVisualC# Создание Net приложений: Пер. с англ. – К.: ВЕК+, М.: ЭНТРОП, 2002. – 704 с.

26. Visual Studio Documentation. MSDN Library –2005.

27. А. Горев, С. Макашарипов, Р. Ахаян. Эффективная работа с СУБД - 2004

28. Сеппа Д. MicrosoftADO.NET/Пер. с англ. — М.: Издательско-торговый домРусская Редакция, 2003- — 640 стр.

29. Троелсен. Э. С# и платформа .NET. Библиотека программиста. — СПб.: Питер, 2004. —796 с.:

30. Трельсен Э. Модель COM и применение ATL 3.0. / Пер. с англ. – СПб: BHV. 2000. – 926 с.

31. Армстронг Т. ActiveX: создание Web-приложений. / Пер. с англ. – К.: BHV. 1998. – 592 с.

32. Справочник по MicrosoftOLEDB 1.1. / Пер. с англ. – М.: Издательский отдел «Русская редакция» ТОО «ChannelTradingLtd». 1997. – 624 с.

33. Ван Тассел Д. Стиль, разработка, эффективность, отладка и испытание программ. – М.: Мир. – 1981

34. Коллинз Г. Структурные методы разработки систем: от стратегического планирования до тестирования. / Коллинз Г., Блей Дж. Пер. с англ. – М.: Финансы и статистика, 1986. 264 с.

35. Богдатских, В.А. Экономика, разработка и использование программного обеспечения ЭВМ: Учебник. / В.А. Богдатских. - М.: Финансы и статистика, 1995. – 288 с.

36. Корнеев, И.К. Информационные технологии в управлении / И.К Корнеев, В.А. Машурцев . – М.:ИНФРА – М, 2001. – 651 с.

37. Хубаев, Г.Н. Экономическая оценка потребительского качества программных средств: Текст лекций / Г.Н. Хубаев. - РГЭА.: Ростов-на-Дону, 1997. – 94 с.

38. Хубаев, Г.Н. Экономика проектирования и применения банков данных / Г.Н. Хубаев. - Ростов-на-Дону: Изд-во РИСХМ, 1989. – 69 с

39. RAD материал из Википедия – свободная энциклопедия [Электронный документ] (http://ru.wikipedia.org/) Проверено 07.06.2007

ПРИЛОЖЕНИЯ

Приложение А - Спецификация требований к программному обеспечению

Введение

Назначение

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

Объем проекта и функции продукта

Продукт позволит осуществить:

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

¾ Структурировать хранящиеся данные;

¾ Уменьшить площадь хранимой информации за счет использования информационных технологий;

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

¾ .Гражданине подлежащего воинскому призыву;

¾ Родителях гражданина;

¾ Ближайших родственниках;

¾ Паспортные данные;

¾ Месте рождения;

¾ Месте регистрации и фактическом месте проживания;

¾ Категориях граждан;

¾ Гражданах снятых с учета по причине смены места жительства;

¾ Гражданах снятых с учета по достижении 50 лет.

Общее описание

Общий взгляд на продукт

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

¾ Минимизировать сроки создания индивидуальной карточки гражданина;

¾ Формировать необходимых отчетов по заданным критериям;

¾ Получать необходимые сведения по конкретному лицу;

¾ Ускорить поиск данных;

¾ Вести реестр категорий граждан;

¾ Получать сведения о лицах снятых с учета по достижении 50 лет или сменивших место жительства;

¾ Получать сведения о лицах проходящих действительную воинскую службу;

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

Классы и характеристики пользователей

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

Операционная среда

Операционная среда-1. Минимальные требования к операционной системе - WindowsXP.

Ограничения дизайна и реализации

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

Ограничения дизайна и реализации-2. База данных должна быть спроектирована в MSSQLServer 2005

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

Документация для пользователей

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

Функции системы

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

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

Интерфейсы пользователя

Интерфейсы пользователя-1.Экраны вывода должны соответствовать общепринятым стандартам.

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

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

Программные интерфейсы

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

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

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

Требования к производительности-1. Загрузка данных из БД не должна превышать более чем 5 сек

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

Требования к охране труда не определены.

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

Требования к безопасности не определены.

Атрибуты качества ПО

Доступность-1. Система должна быть доступна в рабочее время с 08.00 до 17.00 для инженера разработчика и во время проведения испытаний

Надежность-1. Система не должна нарушать целостность данных.

Приложение Б. Прототиты пользовательского интерфейса

Рисунок Б.1 – Внешний вид основного окна программы.

Рисунок Б.2 – Окно медицинской карты призывника.

Приложение В. Атрибуты управляющих таблиц проектируемой ИС

Таблица В.1 – Спецификация таблиц базы данных

Таблица В.2 – Спецификация таблиц базы данных

Таблица В.4 – Спецификация таблиц базы данных

Таблица В.5 – Спецификация таблиц базы данных

Таблица В.6 – Спецификация таблиц базы данных

Таблица В.7 – Спецификация таблиц базы данных

Таблица В.8 – Спецификация таблиц базы данных

Таблица В.9 – Спецификация таблиц базы данных

Таблица В.10 – Спецификация таблиц базы данных

Таблица В.11 – Спецификация таблиц базы данных

Таблица В.12 – Спецификация таблиц базы данных

Приложение Г - Выбор модели жизненного цикла

(обязательное)

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

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

Таблица Г.3 – Выбор модели ЖЦ на основе характеристик типа проектов и рисков

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

Приложение Д – Диаграмма Гантта