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

/

/

Реферат

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

Дипломный проект выполнен на тему «Разработка автоматизированной информационной системы учета и анализа деятельности руководящего аппарата частно-государственного партнерства «Форсайт центр»».

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

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

Abstract

KEY WORDS: INFORMATION SYSTEM, INTERFACE, REQUIREMENTS, LIFE-CYCLE MODEL, MODELING, DESIGN, IMPLEMENTATION, MODEL STRUCTURE, DATABASE, TESTING, PHYSICAL REPRESENTATIONS SYSTEM, LOGICAL PRESENTATION SYSTEM.

The degree project is executed on the theme 'Development of an automated information system of accounting and analysis of the governing apparatus of public-private partnership 'Forsyth Center'.

The data sources were books, periodicals and electronic resources, which were used as the theoretical foundations of the issues addressed, and as practical guides for the project.

The project developed software for accounting and analysis of the governing apparatus.

Введение

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

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

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

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

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

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

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

осуществить тестирование АИС;

провести оценку эффективности технологии разработки.

Данная система позволит:

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

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

предоставление, сохранение отчетов голосования.

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

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

В данном разделе я постарался рассмотреть внутреннее голосование по комитетам для членов ТК/ПК ИСО (Committee Internal Balloting - CIB), автоматизирующий в той или иной степени систему голосования.

Голосование CIB проходит по первым трем стадиям разработки международного стандарта ИСО. Доступ к голосованию пользователь получает в случае, если он зарегистрирован в Глобальной директории ИСО в качестве эксперта ГОСТ по интересующей его тематике с правом голосования. Обязательным является голосование в тех ТК/ПК ИСО, где ГОСТ Р. имеет статус P-member. Пользователь, зарегистрированный в ГД ИСО, получает уведомление о голосовании по электронной почте. Вход в систему электронного голосования CIB производиться путем авторизации в системе посредством ввода имени пользователя и пароль.

Рисунок 1.4 - Система электронного голосования CIB

Интерфейс электронной системы голосования CIB. представлен на рисунке 1. Перед пользователем системы отображается список всех документов, по которым в настоящее время проходит голосование. Если пользователь имеете право голосования только в определенных ТК/ПК ИСО, перед ним будут только те документы, которые касаются работы этих ТК/ПК ИСО. Так же в данной системе есть возможность просмотра документа, по которому в данный момент времени идет голосование, после чего пользователь принимает решение о непосредственном голосовании. Для голосования в системе представлено три варианта ответа:

«За».

«Против».

«Воздержаться».

Плюсы данной системы:

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

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

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

Защита от мошенничества со стороны администраторов. Администратор не должен иметь возможности изменить, или подделать результаты голосования.

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

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

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

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

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

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

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

На диаграммах бизнес - вариантов использования представлены основные направления деятельности секретаря, председателя собрания и членов руководящего аппарата (рис. 1.1 - 1.3).

Рисунок 1.1 - Бизнес - варианты использования деятельности председателя

Рисунок 1.2 - Бизнес - варианты использования деятельности секретаря

Рисунок 1.3 - Бизнес - варианты использования деятельности членов руководящего аппарата

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

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

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

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

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

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

К основным достоинствам ООП относится:

сравнительная легкость, наглядность;

эффективность моделей;

использование методологии UML;

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

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

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

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

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

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

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

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

Данный продукт должен обеспечивать:

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

непосредственное голосование по повестке дня;

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

хранение решений по заседаниям в базе данных;

вывод отчета по решениям заседаний на заданный период времени.

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

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

Рисунок 1.4- Диаграмма деятельности системы

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

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

функциональные требования (Functionality)

требования удобства использования (Usability)

требования надежности (Reliability)

требования производительности (Performance)

требования возможности сопровождения (Supportability)

При этом в модели FURPS+ так же обозначены дополнительные условия, к которым относятся:

проектные ограничения;

требования управления системой;

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

физические требования;

юридические требования.

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

Таблица 1.1 - Категории описания требований

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

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

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

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

После того, как были определены и собраны требования для реализации программного модуля, спроектированные диаграммы бизнес-вариантов использования, представленные на рисунках 1.1 - 1.3, необходимо рассмотреть непосредственные требования, относящиеся к разрабатываемой АИС.

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

Рисунок 1.5 - Диаграмма вариантов-использования

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

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

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

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

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

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

исследование альтернативных решений;

создание конечного продукта.

Перед началом создания прототипов создадим диаграмму состояний системы. Диаграмма используется для изучения взаимосвязей между основными элементами.[9,]

Рисунок 1.5 - Диаграмма состояний системы голосования

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

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

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

Рисунок 1.6 ? Диаграмма пользовательского интерфейса

Выводы

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

Проведен анализ бизнес-процессов деятельности руководящего аппарата, для которого разрабатывается АИС. Построены бизнес-варианты использования, описывающие основные направления деятельности сотрудников в целом и выявлены направления деятельности сотрудников руководящего аппарата ЧГП «Форсайт-центр».

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

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

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

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

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

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

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

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

Клиент-сервер. В основе этой концепции лежит идея о том, что помимо хранения файлов базы данных, центральный сервер должен выполнять основную часть обработки данных. Пользователи обращаются к центральному серверу с помощью специального языка структурированных запросов (SQL, Structured Query Language), на котором описывается список задач, выполняемых сервером. Запросы пользователей принимаются сервером и порождают в нем процессы обработки данных. В ответ пользователь получает уже обработанный набор данных. Между клиентом и сервером передается не весь набор данных, как это происходит в технологии файл-сервер, а только данные, которые необходимы клиенту. Запрос пользователя длиной всего в несколько строк способен породить процесс обработки данных, затрагивающий множество таблиц и миллионы строк. В ответ клиент может получить лишь несколько чисел. Технология клиент-сервер позволяет избежать передачи по сети огромных объемов информации, переложив всю обработку данных на центральный сервер.[24] Кроме того, рассматриваемый подход позволяет избежать конфликтов изменений одних и тех же данных множеством пользователей, которые характерны для технологии файл-сервер. Технология клиент-сервер реализует согласованное изменение данных множеством клиентов, обеспечивая автоматическое соблюдение целостности данных. Эти и некоторые другие преимущества сделали технологию клиент-сервер очень популярной. К недостаткам этой технологии можно отнести высокие требования к производительности центрального сервера. Чем больше клиентов обращается к серверу, и чем больше объем обрабатываемых данных, тем более мощным должен быть центральный сервер.

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

Рисунок 2.1 ? Традиционное решение в архитектуре клиент-сервер

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

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

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

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

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

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

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

На рисунке 2.2 изображена диаграмма компонентов АИС.

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

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

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

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

Модули, с одной стороны, являются сервером для клиентского приложения, обеспечивающего управление объектами предметной области, а с другой стороны, выступают как клиенты при взаимодействии с MS SQL Server. Для осуществления взаимодействия модулей с сервером БД используется модель доступа.NET-приложений к данным - ADO.NET, которая для доступа к источникам данных, использует провайдер OLE DB. Архитектура доступа к данным этих модулей представлена на рисунке 2.4.

Рисунок 2.4 - Универсальная архитектура доступа к данным в ado.net

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процесс проектирования базы данных состоит трех основных фаз:

концептуального проектирования;

логического проектирования;

физического проектирования.

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

Концептуальная модель данных представляет собой набор ее сущностей и связей (отношений), другими словами, это доменная модель, которая содержит только сущности системы и взаимосвязи между ними.[1]

Сущность (entity) - это отдельный тип объекта (сотрудник, место или вещь, понятие или событие) организации, который должен быть представлен в базе данных. Отношением называется связь между элементами. (relationship). Иначе связь - это то, что объединяет несколько сущностей. На рисунке 2.5 изображена концептуальная модель данных разрабатываемой АИС.

Рисунок 2.5 - Концептуальная модель данных

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

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

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

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

Атрибутом (attribute) называется свойство, которое описывает некоторую характеристику описываемого объекта.[20] Класс (объект) может, иметь любое число атрибутов или не иметь их вовсе.

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

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

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

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

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

На основе логической модели данных составляется физическая модель данных. Физический уровень модели данных, в отличие от логического уровня, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физическом уровне модели содержится информация о всех объектах базы данных. Поскольку стандартов на объекты базы данных не существует, физический уровень модели зависит от конкретной реализации СУБД. Исходя из выше сказанного, составляется физическая модель базы данных системы.

На рисунке 2.7 изображена физическая модель данных, реализованная в MS SQL Server 2005 при помощи инструмента SQL Server Management Studio, входящий в пакет инструментов MS SQL Server 2005.

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

В качестве базы данных была выбрана СУБД Microsoft SQL Server 2005. Данный выбор был обусловлен наличием у этой версии СУБД развитых средств службы уведомлений и службы отчетности. Данные средства необходимы для реализации полного соответствия работы системы голосования и принципа осуществления данного бизнес-процесса руководящего аппарата частно-государственного партнерства «Форсайт центр». Кроме того, в настоящее время наиболее широко используемой является версия MS SQL Server 2005. В состав Microsoft SQL Server 2005 входят простые утилиты администрирования (Enterprise Manager), сервисы преобразования данных (Data Transformation Services), облегчающие перенос данных в SQL Server из других типов СУБД, поддержка распределенных запросов и транзакций, OLAP-сервер и утилиты для создания хранилищ данных (в том числе данных из других серверных СУБД).

Из особенностей так же можно выделить:

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

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

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

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

высокоуровневый язык программирования MS Visual C# 2008;

MS SQL Server 2005;

Rational Rose Enterprise Edition 2007;

ERWin Data Modeler 7.3.

Для разрабатываемой информационной системы выбрана платформа Microsoft Visual Studio 2008. В качестве языка реализации приложения выбран C#.

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

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

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

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

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

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

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

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

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

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

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

Проектирование ИС предполагает решение следующих вопросов:

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

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

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

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

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

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

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

Рисунок 2.8 - Диаграмма состояний системы

Рисунок 2.9 - Диаграмма классов системы

Таблица 2.1 - Соответствие между сущностями, формами и таблицами в БД

Выводы

Во втором разделе проектирование автоматизированной системы учета и анализа деятельности руководящего аппарата ЧГП «Форсайт-центр». Разработана архитектурная модель проектирования и компонентная модель. Так же на данном этапе были построены модели логического и физического представления подсистемы. На основе данных моделей была разработана база данных подсистемы.

Описано проектирование модулей подсистемы, показано логическое представление основных компонентов системы как независимых *.exe файлов, реализующих функциональность основных понятий предметной области. Разработаны диаграммы классов для системы учета и анализа деятельности. Для разрабатываемой информационной системы была выбрана платформа Microsoft Visual Studio 2008, так же в качестве СУБД было выбрано Microsoft SQL Server 2005. В качестве языка реализации приложения выбран высокоуровневый язык программирования C#.

3. Реализация и аттестация информационной системы

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

Реализация программного обеспечения - это процесс перевода системной спецификации в работоспособную систему.[26]

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

высокоуровневый язык программирования MS Visual C# 2008;

MS SQL Server 2005.

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

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

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

/

/

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

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

При отображении формы во время выполнения программы, этот класс будет использоваться как шаблон для отображения окна. Файлы С# имеют расширение «.cs». Код главной формы модуля информационной системы содержит в себе файл MainForm.cs (рисунок 3.2). Остальные фрагменты кода приложения приведены в приложении Г. Данная форма является главной, запускающей дочерние окна данного модуля. Класс реализации формы MainForm.Designer.cs изображен на рисунке 3.2.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Взаимодействие приложения с базой данных осуществляется через модель ADO.NET, обеспечивающего соединение с источником данных. В основе модели ADO.NET лежит простой набор классов, наиболее важным из них является DataSet - образ реляционной базы данных. Так же ADO.NET использует объект типа TableAdapter как мост между DataSet и источником данных. TableAdapter содержит метод Fill() для обновления данных из базы и заполнения DataSet. [29]

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

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

Следующим шагом является создание запроса, удовлетворяющего нашим условиям. Запрос создается по таблице «Agenda» (Повестка дня). Суть запроса состоит в том, что бы добавить в таблицу такие данные как повестка дня, председатель, место заседания и дату заседания. На рисунке 3.4 показан составленный запрос.

Рисунок 3.4 - Запрос на формирование плана заседаний

В тексте программы следующий запрос реализуется следующим образом:

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

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

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

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

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

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

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

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

Тестирование приложения проводилось с помощью стандартных инструментов предоставляемых 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 позволяет исполнять код и получать значения переменных и свойств. Имеются также дополнительные окна для наблюдения за самыми разными данными приложения.

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

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

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

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

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

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

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

Существует так же еще несколько методов тестирования, рассмотрим два из них. Этот метод «черного ящика» и метод «белого ящика».

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

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

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

План тестирования:

система будет тестироваться методом «белого ящика»;

должно быть соблюдено соответствие между данными, хранящимися в БД, и данными появляющимися при тестировании программного модуля:

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

должна быть соблюдена проверка связи компонента с БД;

приложение отправляется на доработку, если найдено несоответствие. При исправлении ошибки приложение снова отправляется на тестирование.

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

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

информация о пользователях (ФИО, логин, пароль);

информация о повестке дня;

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

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

Запуск программного модуля в режиме отладки при недоступном сервере баз данных, как и следовало ожидать, отладчик выдал ошибку - «Невозможно открыть базу данных, не удалось выполнить вход» (рисунок 3.5).

Рисунок 3.5 - Запуск программы в режиме отладки

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

Рисунок 3.6 - Ошибка в приложении

Последующий запуск приложения с доступной базой данных приводил к корректной работе приложения (рисунок 3.7).

Рисунок 3.6 - Корректная работа приложения

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

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

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

секретарь;

члены руководящего аппарата ЧГП «Форсайт-центр».

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

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

Microsoft® Windows® XP/Vista/7;

Standard Resolution 640 x 480;

1024 MB RAM;

Windows® compatible mouse, keyboard;

Microsoft.NET Framework SDK v2.0.

Кроме этого на сервере должна быть установлена база данных Microsoft SQL Server 2005.

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

Установочный файл создавался при помощи инструментов Visual Studio.NET. Данный выбор был обусловлен возможностью избегания таких проблем как: при выборе других инструментов вероятен отказ приложения после установки в запуске, созданный конфликт DLL новой программой с другой программой, отказ деинсталлирующей программы, оставление файлов DLL в реестре и других файлов поддержки после удаления программы. В Visual Studio.NET процесс установки упрощен, так как приложения Visual Studio в основном используют функциональность библиотек классов.NET Framework, а не компоненты COM и вызовы функций Windows API. Кроме того, приложения Visual Studio компилируются как сборки - единицы развертывания, состоящие из одного или более файлов, необходимых для запуска программы.

Выводы

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

Продемонстрирована реализация взаимодействия компонента с СУБД и с клиентским приложением.

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

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

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

Жизненный цикл программного обеспечения (ПО) -- период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Этот цикл -- процесс построения и развития ПО.

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

На основе этого результата будет определена наиболее приемлемая модель ЖЦ. На основе этого результата будет определена наиболее приемлемая модель модели жизненного цикла АИС учета и анализа деятельности управляющего аппарата ЧГП «Форсайт-центер».

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

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

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

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

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

дефицит специалистов;

нереалистичные сроки и бюджет;

реализация несоответствующей функциональности;

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

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

непрекращающийся поток изменений;

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

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

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

«разрыв» в квалификации специалистов разных областей знаний.

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

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

оценка и разрешение рисков;

определение целей;

разработка и тестирование;

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

На каждом витке спирали могут применяться разные модели процесса разработки ПО. В конечном итоге на выходе получается готовый продукт. Модель сочетает в себе возможности модели прототипирования и водопадной модели (процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований). Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем этапе. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная задача -- как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Основная проблема спирального цикла -- определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. Одним из возможных подходов к разработке программного обеспечения в рамках спиральной модели жизненного цикла является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки программного обеспечения, содержащий 3 элемента:

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

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

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

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

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

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

фаза реализации;

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

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

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

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

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

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

Задачи проекта:

выполнить сбор, спецификацию и аттестацию требований

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

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

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

Программный проект должен быть:

продуктом для внутреннего использования в ЧГП «Форсайт-центер»;

проектом для осуществления многопользовательского доступа;

Программный проект не должен быть:

проектом, доступным для посторонних лиц.

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

Проект будет:

сетевым;

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

применяться в операционных системах Windows.

Проект не будет:

локальным;

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

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

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

Процесс создания Автоматизированной информационной системы анализа и учета деятельности руководящего аппарата ЧГП «Форсайт-центр» представляется в виде перечня работ, реализованном в прикладном пакете Microsoft Office Project 2007.

Рисунок 4.1 -- Пооперационный перечень работ АИС

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

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

планирование и активизация проекта;

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

фаза описания пользователя;

фаза «расчистки».

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

установку соответствия между действиями и планом;

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

установку среды проекта;

планирование управлением проекта.

Данный жизненный цикл разработан для полноценно функционирующей АИС.

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

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

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

разработку системной архитектуры;

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

уточнение и разработку требований к ПО;

определение требований к интерфейсу;

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

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

создание БД - идентификация предварительных элементов БД;

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

- планирование следующей фазы.

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

планирование и активизация проекта;

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

фаза описания пользователя;

фаза «расчистки».

Фаза планирование и активизация проекта включает в себя:

установку соответствия между действиями и планом;

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

установку среды проекта;

планирование управлением проекта.

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

процесс определения структуры системы:

анализ функций;

разработка архитектуры системы;

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

процесс определения требований:

определение и разработка требований к ПО;

определение требований к интерфейсу;

расстановка приоритетов и интеграция требований к ПО;

Фаза описания пользователя так же разделена на три основные задачи с подзадачами:

процесс разработки проекта:

разработка проекта архитектуры;

проектирование базы данных;

проектирование интерфейсов;

выбор либо разработка алгоритмов;

разработка модуля секретаря;

разработка модуля члена руководящего аппарата;

фаза конструирования.

Процесс внедрения:

генерирование тестовых данных;

создание исходного кода;

генерирование объектного кода;

создание оперативной документации;

планирование интеграции;

выполнение интеграции;

планирование тестирования;

разработка тестовых требований;

выполнение тестов.

Фаза «расчистки» включает процесс установки, который делится на:

план установки;

распространение ПО;

инсталляция ПО;

установка ПО в операционной среде;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Одним из наиболее важных свойств любого ресурса является стоимость его использования в проекте. В MS Project выделяется два типа стоимости ресурсов: повременная ставка и стоимость за использование. Повременная ставка (Rate) выражается в стоимости использования ресурса в единицу времени, например 50 рублей в час или 500 рублей в день. Повременная ставка используется для людских, а также для каких-либо материальных ресурсов. В таком случае стоимость участия ресурса в проекте составит время, в течение которого он работает в проекте, умноженное на почасовую ставку. В разработанном мной проекте использовалась повременная ставка, а так же были назначены следующие ресурсы: руководитель, проектировщик, разработчик, аналитик и тестировщик (рисунок 4.3) Общие же затраты на использование ресурсов по всему проекту можно увидеть на рисунке 4.5.

Рисунок 4.3 -- Повременная ставка в использовании ресурса

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

Рисунок 4.5 -- Общие затраты на использовании ресурсов проекта

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

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

Распределение ресурсов проекта при создании системы учета и анализа деятельности руководящего аппарата можно представить в виде перечня представленного на рисунке 4.6.

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

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

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

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

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

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

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

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

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

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

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

Рисунок 4.7 -- Ресурс для задачи «Проектирование базы данных»

Рисунок 4.8 -- Таблица использования ресурса «Руководитель»

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

Рисунок 4.8 -- Календарь ресурса «Руководитель»

Оценка эффективности проекта

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

АИС должна обеспечивать:

- работу с входными данными;

- получение выходных документов;

- формирование отчетов.

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

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

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

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

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

выделение цели работы системы;

определение наборов показателей, характеризующих определенную цель;

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

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

определение весовых коэффициентов целей;

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

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

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

, (4.1)

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

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

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

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

, (4.2)

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

, (4.3)

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

, (4.3)

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

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

, (4.4)

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

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

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

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

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

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

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

На основе формулы 4.1 рассчитаем степень достижения целей (таблица 4.4)

Таблица 4.4 - Расчет степени достижения показателей

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

Результаты опроса представлены в таблице 4.5.

Таблица 4.5 - Результаты опроса

На основании полученных оценок рассчитаем весовые коэффициенты (формула 4.2, формула 4.3, формула 4.4).

Таблица 4.6 ? Расчет суммы рангов

Таблица 4.7 ? Расчет оценок

Таблица 4.8 ? Расчет весового коэффициента

Представленные расчеты сведем в таблицу.

Таблица 4.9 - Сводная таблица расчетов

Коэффициент конкордации мнений экспертов составил 0,87 баллов (q=0,87), что позволяет считать достоверными, поскольку, нормативное значение его должно составлять больше 0,7 баллов (q>0,7).

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

Таблица 4.10 ? Общий показатель эффективности

Таким образом, можно сказать, что эффективность работы разработанной нами информационной системы по отношению к заданным целям составляет 0,9 баллов, то есть на 90% система работает оптимально. Неэффективность работы ИС составляет 10%.

Выводы

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

Заключение

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

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

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

Проведен анализ бизнес-процессов деятельности руководящего аппарата, для которого разрабатывается АИС. Построены бизнес-варианты использования, описывающие основные направления деятельности сотрудников в целом и выявлены направления деятельности сотрудников руководящего аппарата ЧГП «Форсайт-центр».

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

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

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

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

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

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

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

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

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

Список сокращений

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

ЖЦ - жизненный цикл;

ИС - информационная система;

АИС - автоматизированная информационная система;

ЧГП - частно-государственное партнерство;

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

ПП - программный продукт;

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

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

COM - component object model;

OLAP - Online Analytical Processing, система обработки аналитической информации;

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

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

2. Visual Studio Documentation. MSDN Library -2005.

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

4. Аглицкий Д.С. Российский рынок информационных технологий: проблемы и решения Д.С. Аглицкий, И.С. Аглицкий - М.: 2000. - 208с.

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

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

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

8. Баронов В.В. Автоматизация управления предприятием В.В. Баронов - М.: ИНФРА-М, 2000.- 239с.

9. Боггс У. Боггс М. UML и Rational Rose. 2002. Боггс У., Боггс М. - М.: ЛОРИ. - 2002. - 582 с.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

27. Маклаков С.В. BPwin и ERwin. CASE - средства разработки информационных систем. Учебник С.В. Маклаков. - М.: ДИАЛОГ-МИФИ, 2000.

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

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

30. Справочник по Microsoft OLE DB 1.1. Пер. с англ. - М.: Издательский отдел «Русская редакция» ТОО «Channel Trading Ltd». 1997. - 624 с.

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

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

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

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

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

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

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

Введение

Назначение

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

Область действия

Областью применения данного программного продукта являются руководящий аппарат частно-государственного партнерства «Форсайт центр».

ОБЩЕЕ ОПИСАНИЕ

Описание продукта

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

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

непосредственное голосование по повестке дня;

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

хранение решений по заседаниям в базе данных;

вывод отчета по решениям заседаний.

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

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

В таблице приведены основные категории пользователей:

Таблица А.1 ? Основные категории пользователей

Общие ограничения

Операционная среда-1. Минимальные требования к операционной системе - Windows XP/Vista/7, наличие платформы.NET Framework.

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

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

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

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

Специфические требования

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

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

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

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

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

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

Основными системными требованиями к системе являются:

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

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

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

система должна иметь возможность наращивания в программной части.

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

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

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

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

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

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

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

Рисунок Б.1 - Внешний вид окна авторизации

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

Рисунок Б.3 - Внешний вид окон формирования плана заседания

Приложение В. ? АТРИБУТЫ УПРАВЛЯЮЩИХ ТАБЛИЦ ПРОЕКТИРУЕМОЙ ИС

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

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

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

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

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

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

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

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

Приложение Г. -- ВЫБОР МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА

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

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

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

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