Быстрый поиск

Дипломная работа: Автоматизированная система утверждения электронных документов на основе MS SharePoint 2007

1.12 Требования к техническому и программному обеспечению

1.12.1 Требования к техническому обеспечению

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

· процессор Intel или AMD – 2000 МГц;

· объём оперативной памяти – 1024 Мб;

· объём свободного места на HDD - 1 Гб;

· доступ к локальной сети.

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

· процессор Intel или AMD с тактовой частотой 500 МГц;

· объём оперативной памяти – 128 Мб;

· объём свободного места на HDD – 10 Мб;

· доступ к локальной сети.

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

1.12.2 Требования к программному обеспечению

Требования к программному обеспечению на сервере следующие:

· операционная система MS Windows 2003 Server;

· СУБД MS SQL Server 2005;

· Internet Information Services 6.0 или выше;

· MOSS 2007;

· поддержка ASP .Net.

Требования к программному обеспечению на клиенте:

· операционная система: семейство MS Windows 98/2000/XP/Vista.

· браузер, поддерживаемый операционной системой (Internet Explorer 6.x и выше, Firefox 2.x и выше, Opera 7 и выше, Safari 1.x и выше, Camino 1.x и выше).

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

1.13 Требования к интерфейсам информационной системы

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

· выдержанная в спокойных тонах цветовая гамма;

· простой и очевидный порядок выполнение действий;

· удобная навигация;

· эргономичное расположение полей ввода и элементов управления.

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

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

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

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

· редактирование процессов – редактирование должно обеспечить удаление и остановку процессов;

· редактирование разрешений пользователей – редактирование должно обеспечить назначение пользователям прав;

· загрузка документа – окно загрузки документа и оставления комментария к версии документа;

· поиск в системе – должно позволять задание критерия поиска и области произведения поиска.

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

1.14 Расчет надежности системы

Рассмотрим модель надежности архитектуры системы. Система состоит из следующих компонентов: клиентских машин, Web-сервера и сервера БД. В качестве еще одного компонента будем рассматривать локальную сеть.

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

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

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

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

Определим вероятности Ri безотказной работы модулей Ni. Для этого проведем серию испытаний модуля и, подсчитав количество успешных запусков mi и количество испытаний ni, воспользуемся формулой статистической вероятности:

(1.1)

Проведем серию из ni=50 испытаний для каждого модуля. Результаты испытаний отразим в гистограммах, причем «0» соответствует сбою, а «1» - успешному завершению испытания. Итоговые данные о статистической вероятности отразим в таблице.

Рис. 1.1. Гистограмма испытаний для модуля 1 (клиентская машина)

Рис. 1.2. Гистограмма испытаний для модуля 2 (сервер MOSS 2007)

Рис. 1.3. Гистограмма испытаний для модуля 3 (сервер БД)

Рис. 1.4. Гистограмма испытаний для модуля 4 (локальная сеть)

Таблица 1.3 Вероятности безотказной работы компонентов архитектуры системы
Компонент архитектуры	Вероятность безотказной работы
Локальная сеть	0,98
Клиентская машина	0,96
Web-сервер	0,98
Сервер БД	0,98

Построим граф моделирующий взаимодействие узлов в системе (рис. 1.5).

Рис.1.5. Граф, моделирующий взаимодействие узлов в системе

· «N1» – клиентская машина;

· «N2» – локальная сеть;

· «N3» – Web-сервер;

· «N4» – локальная сеть;

· «N5» – сервер БД;

· «N6» – локальная сеть;

· «N7» – Web-сервер;

· «N8» – локальная сеть;

· «N9» – клиентская машина.

Для любой из клиентских машин граф моделирующий взаимодействие узлов в системе будет идентичным. На основе построенной модели взаимодействия узлов системы построим марковскую модель надежности системы, путем добавления двух узлов – С (успешное завершение работы) и F (отказ), а так же соответствующих ребер (рис. 1.6).