требования удобства использования (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.

Страницы: 1, 2, 3, 4