Главная База знаний "Allbest" Программирование, компьютеры и кибернетика Разработка информационной системы учета призывников в администрации (на примере администрации с. Казинка)

Разработка информационной системы учета призывников в администрации (на примере администрации с. Казинка)

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

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 30.11.2010
Размер файла 1,3 M

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

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

Страница:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Visual Studio 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 необходимой для работы данной системы. Рассмотрена методика взаимодействия информационной системы с СУБД MS SQL Server 2005.

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

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

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

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

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

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

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

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

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

Характеристика

Каскадная

V-образная

Прототипирование

Спиральная

RAD

Инкрементная

Требования

5

4

2

2

4

2

Участники команды разработчиков

6

5

4

5

7

6

Коллектив пользователей

4

5

0

3

3

2

Типы проектов и рисков

8

6

6

4

7

6

Итого

23

20

12

14

21

16

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

< 1000 функциональных элементов

один человек

1000-4000 функциональных элементов

одна команда разработчиков

> 4000 функциональных элементов

4000 функциональных элементов на одну команду разработчиков

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ѕ отладка.

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

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

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

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

Задачи

Ресурсы

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

Разработчик

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

Разработчик

Создание предварительного бюджета

Разработчик

Обсуждение спецификаций программного продукта

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

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

Разработчик

Получение разрешений на продолжение

Разработчик

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

Разработчик

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

Разработчик

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

Разработчик

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

Разработчик

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

Разработчик

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

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

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

Разработчик

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

Инженер-испытатель

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

Инженер-испытатель

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

Инженер-испытатель

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

Инженер-испытатель

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

Инженер-испытатель

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

Разработчик

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

Инженер-испытатель

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

, (4.1)

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

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

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

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

, (4.2)

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

Vi - оценка, баллы.

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

(4.3)

где Vi - оценка, баллы;

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

Ri - сумма рангов, баллы.

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

, (4.4)

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

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

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

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

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

, (4.5)

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

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

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

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

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

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

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

Цель

Показатель

Уровень достижения, баллы

g1 - технический уровень

y11 - минимизация количества ошибок при выполнении лабораторных исследований

0,9

y12 - автоматизированный ввод результатов ручных методов исследований

1,0

y13 - автоматизация получения заказов, выдачи результатов и отчетов

0,85

g2 - коммуникация

y21 - оперативность

0,75

y22 - удобство использования

0,89

g3 - социальные цели

y31 - улучшение условий труда

0,80

y32 - внедрение групповых форм работы

0,75

y33 - уменьшение времени выполнения исследований

0,95

g4 - получение отчетности

y41 - автоматическое получение отчетов

0,87

y42 - уменьшение объема рутинной работы персонала лаборатории

1,0

g5 - простота использования

y51 - легко понимаемый интерфейс пользователя

0,91

y52 - возможность поиска

0,75

y53 - возможность сохранения, извлечения и редактирования документов

0,87

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

.

.

.

.

.

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

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

ѕ Люди;

ѕ Техника;

ѕ Механизмы;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

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

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

В третьем разделе дипломного проекта рассмотрена реализация программного продукта и вопросы связанные с реализацией. Реализованы функции и классы взаимодействия с базой данных. Приведены методы и свойства классов. Продемонстрирован фрагментарно исходный код. Так же рассмотрена и продемонстрирована методика взаимодействия приложения с СУБД MS SQL Server 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 и Rational Rose. 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. Джесс Либерти. Microsoft Visual C# Создание Net приложений: Пер. с англ. - К.: ВЕК+, М.: ЭНТРОП, 2002. - 704 с.

26. Visual Studio Documentation. MSDN Library -2005.

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

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

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

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

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

32. Справочник по Microsoft OLE DB 1.1. / Пер. с англ. - М.: Издательский отдел «Русская редакция» ТОО «Channel Trading Ltd». 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. Инспектор ВУС

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

2. Начальник отдела

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

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

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

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

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

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

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

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

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

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

Функция

Требование

1. Создать карточку

Сохранить в базе данных сведения о гражданине, внесенные с помощью формы

2. Получить список всех призывников

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

3. Найти запись

Найти необходимые сведения по введенным критериям предлагаемых ИС

4. Сформировать отчет

Сформировать отчет по конкретному гражданину

5. Снять с учета

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

6. Изменить запись

Провести корректировку уже сохраненной записи в базе данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Имя поля

Тип

Значение

Атрибуты таблицы «Grazdanin» -Гражданин

ID

int

Уникальный номер гражданина

Name

text

Имя гражданина

SecondName

text

Фамилия

LastName

text

Отчество

GerlsName

text

Девичья фамилия

Rozd_Oblast

text

Название региона

Rozd_Raion

text

Название района

Rozd_Gorod

text

Название города/села

DataRozd

datetime

Дата рождения

CreateDay

datetime

Дата записи

ID_Relatives

int

Уникальный номер гражданина

ID_Father

int

Уникальный номер гражданина

ID_Mother

int

Уникальный номер гражданина

ID_Adress_Pasport

int

Уникальный номер гражданина

ID_Adress_Fuctual

int

Уникальный номер гражданина

Foto

image

Хранимая фотография гражданина

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

Имя поля

Тип

Значение

Атрибуты таблицы «Passport_Data» -Паспортные данные

ID

int

Уникальный номер гражданина

Pas_Ser_1pole

nchar(10)

Серия паспорта

Pas_Ser_2pole

nchar(10)

Серия паспорта

Nomer

nchar(10)

Номер паспорта

Vidan

text

Подразделение выдавшее паспорт

DateVidathi

datetime

Дата выдачи

Kod_1pole

Страница:


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены