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

На рисунке 9 представлена логическая структура БД программного комплекса, которая является реализацией диаграммы сущностных классов, представленных на рисунке 5.

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

Рисунок 9 - Логическая структура БД

1.9 Оценка характеристик системы

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

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

1.9.1 Оценка требуемой внешней памяти

Расчеты характеристик для сервера:

Для расчета внешней памяти воспользуемся формулой (1) :

, Мбайт (1)

- общий объем внешней памяти;

- объем внешней памяти, требуемый для хранения файлов операционной системы и её нормальной работы;

- объем внешней памяти, требуемый для хранения файлов СУБД;

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

- объем внешней памяти, необходимой для хранения текстов и библиотек приложений;

Система работает под управлением операционной системы Microsoft Windows XP с использованием MS Access.

= 1500 Мбайт; = 10 Мбайт.

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

Таблица 3 - Расчет объема данных

Таблица БД	Размер записи, байт	Мах количество записей	Размер индекса, байт	Итого, байт
Competence	100	100	101	10100
Dependence	10	5000	65	325000
Faculty	100	30	65	1950
Group	50	7	65	455
Period	50	10	14	140
Student	50	6300	42	264600
Student-competence	10	630000	14	8820000
Student-subject	10	315000	138	43470000
Subject	100	50	10	500
User	20	860	42	36120
			Итого	185 228 865

= 185,2 Мбайт;

= 14 Мбайт;

Сложив данные, получим:

= 1500+10+185,2+14= 1709,2 Мбайт.

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

объемом 40 Гб.

Расчеты характеристик для клиента:

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

= 0 Мбайт;

= 0 Мбайт;

= 3 Мбайт;

По формуле 1 получим:

= 1500+0+0+3= 1503 Мбайт.

Таким образом, для сервера нам потребуется жесткий диск объемом 40 Гб.

1.9.2 Оценка требуемой оперативной памяти

Формула, используемая для расчета требуемой оперативной памяти, аналогична формуле (1).

Расчеты характеристик для сервера:

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

Таблица 4 - Расчет объема буферизации

Таблица БД	Размер записи, байт	Мах количество записей	Размер индекса, байт	Итого, байт
Competence	100	100	101	10100
Dependence	10	5000	65	325000
Recommend	100	1500	42	63000
Student	50	30	42	1260
Student-competence	10	3000	14	42000
Student-subject	10	1500	138	207000
Subject	100	50	10	500
			Итого	648 860

= 14 Мбайт.

= 0,65 Мбайт;

= 256+10+14+0,65=280,65 Мбайт.

Поскольку оперативная память комплектуется модулями стандартного размера от 128 Мбайт до 4 Гбайт, мы выбираем один модуль на 512 Мбайт для сервера.

Расчеты характеристик для клиента:

= 0 Мбайт;

= 0,65 Мбайт;

= 256+10+0+0,65=264,65 Мбайт.

Поскольку оперативная память комплектуется модулями стандартного размера от 128 Мбайт до 4 Гбайт, мы выбираем один модуль на 512 Мбайт для клиента.

1.9.3 Расчет времени реакции системы

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

Проведём расчет времени реакции системы при построении отчёта «Готовность студентов к изучению дисциплины». В запросе участвуют таблицы grp, std, sbj, cnct, sbj_rslt.

Общее время реакции системы на выполнение запроса рассчитывается по формуле (2):

,

,

,

,

,

.

- время на ввод входных данных запроса;

- коэффициент ошибок при вводе, для расчетов можно принять равным 1,5;

- количество символов, вводимых в качестве исходных данных запроса.

- время ввода одного символа, при ручном вводе с клавиатуры в некоторую экранную форму можно принять в среднем равным 2 с;

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

- количество считываемых физических блоков, зависит от количества обрабатываемых таблиц (файлов) и объема таблиц (файлов);

=0,006 сек - время позиционирования головок;

=0,001 сек - время считывания физического блока;

- время, затрачиваемое процессором на обработку информации с учетом выполнения циклов;

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

- среднее количество тактов машинных команд на одну операцию, для большинства случаев можно принять = 60;

= 1600*10⁶ - тактовая частота процессора, Гц;

= cредний объем таблицы, байт;

= 5 - количество таблиц, обрабатываемых в запросе;

= 512 байт - объем физического блока носителя, байт;

- время на вывод результата на устройство вывода. Для дисплея можно принять 0,5 с. (зависит от видеокарты и дисплея).

Результаты расчета времени реакции системы приведены в таблице 4.

Таблица 5- Расчет времени реакции системы

Параметры	Значения
Vтабл=	2048
Nбл=	1600
tввода=	30
tсчитыв=	11,2
tвычисл=	0,0000375
tреакции=	41,7

По формуле 2.1:

tввода = 1,5*30*2=30с.

По формуле 2.2:

tсчитыв= 1600*(0,006+0,001)=11,2

По формуле 2.3:

tвычисл= 1000*60/(1600*10^6)= 0,0000375

По формуле 2:

tреакции=30+11,2+0,0000375+ 0,5=41,7

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

1.9.4 Скорость передачи данных

7п= Vд / Vпр

7п - скорость передачи данных

Vд - объем данных

Vпр - пропускная способность

Vпр = 56 Кбит/с (как наихудшее соединение)

Vд = 30 символов*2 бита=60бит = 0,06 Кбит

7п = 0,06 Кбит / 56 Кбит/с = 0,001071 c.

0,001071 c. - скорость передачи данных при наихудшем соединении.

1.9.5 Требования к комплексу технических средств

С учетом проведенных расчетов, система должна быть:

Сервер: процессор класса Pentium с тактовой частотой 1,8 ГГц и выше, рекомендуемый объем (ОЗУ) 512 Мбайт; жесткий диск емкостью не менее 40 Гбайт, видеокарта может быть любой, т.к. нет требований к производительности видеосистемы.

Клиент: процессор класса Pentium с тактовой частотой 1,4 ГГц и выше, рекомендуемый объем (ОЗУ) 512 Мбайт, жесткий диск емкостью не менее 40 Гбайт, видеокарта может быть любой, т.к. нет требований к производительности видеосистемы.

2. КОНСТРУКТОРСКО-ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬ

2.1 Выбор и обоснование архитектуры системы

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

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

Выбор архитектуры производился из нескольких основных типов:

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

- клиент-серверная трехзвенная (частный случай multi-tier) - этот тип характеризуется наличием, кроме вышеперечисленных, промежуточного, третьего звена - сервера приложений. В этом случае, клиентские приложения не будут обращаться к СУБД напрямую - они будут взаимодействовать с промежуточным звеном;

- локальная - при использовании этой архитектуры все компоненты системы находятся на одном компьютере [9].

- автономная - это система IP-сетей и маршрутизаторов, управляемых одним или несколькими операторами, имеющими единую политику маршрутизации с Интернетом.

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

Многоинтерфейсная (multihomed) AS -- это AS, которая имеет соединения с более чем одним Интернет-провайдером. Это позволяет данной AS оставаться подключенной к Интернету в случае выхода из строя соединения с одним из Интернет-провайдеров. Кроме того, этот тип AS не разрешает транзитный трафик от одного Интернет-провайдера к другому.

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

Транзитная (transit) AS -- это AS, которая пропускает через себя транзитный трафик сетей, подключенных к ней. Таким образом, сеть A может использовать транзитную AS для связи с сетью B.

Сделана попытка определения принципов организации

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

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

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

2.2 Краткое описание средств реализации проекта

При выборе средств разработки системы, необходимо выбрать такие средства, при которых разработка была бы эффективной и базировалась на современных информационных технологиях. В этой связи, для программирования был выбран язык программирования C#, ADO (от англ. ActiveX Data Objects -- «объекты данных ActiveX») как интерфейс программирования приложений для доступа к данным.

2.2.1 Краткое описание языка программирования C#

C# разрабатывался как язык программирования прикладного уровня для CR и, как таковой, зависит, прежде всего, от возможностей самой CLR. Это касается, прежде всего, системы типов C#, которая отражает BCL. Присутствие или отсутствие тех или иных выразительных особенностей языка диктуется тем, может ли конкретная языковая особенность быть транслирована в соответствующие конструкции CLR. Так, с развитием CLR от версии 1.1 к 2.0 значительно обогатился и сам C#; подобного взаимодействия следует ожидать и в дальнейшем. (Однако эта закономерность была нарушена с выходом C# 3.0, представляющим собой расширения языка, не опирающиеся на расширения платформы .NET.) CLR предоставляет C#, как и всем другим .NET-ориентированным языкам, многие возможности, которых лишены «классические» языки программирования. Например, сборка мусора не реализована в самом C#, а производится CLR для программ, написанных на C# точно так же, как это делается для программ на VB.NET, J# и др [7].

2.2.2 Краткое описание технологии ADO .NET

ADO (от англ. ActiveX Data Objects -- «объекты данных ActiveX») -- интерфейс программирования приложений для доступа к данным, разработанный компанией Microsoft (MS Access, MS SQL Server) и основанный на технологии компонентов ActiveX. ADO позволяет представлять данные из разнообразных источников (реляционных баз данных, текстовых файлов и т. д.) в объектно-ориентированном виде [8].

ADO.NET -- это часть новой архитектуры .NET, разработанной компанией Microsoft. Архитектура .NET является попыткой компании Microsoft заново перепроектировать средства и инструменты разработки программного обеспечения для того, чтобы сделать их более удобными для создания веб-приложений. ADO.NET является новым развитием ADO, ориентированным на решение проблем, связанных с разработкой веб-систем и устраняющим многие недостатки устаревшей технологии ADO. Проблема ADO состоит в том, что эта технология основана на COM. Для одно- и двухзвенных приложений COM является вполне приемлемой платформой, однако в мире Веб использовать COM в качестве транспортного механизма фактически невозможно. Для COM характерны три основные проблемы, которые ограничивают использование этой технологии в Веб: во-первых, COM функционирует только в среде Windows, во-вторых, передача наборов записей требует маршализации COM, в-третьих, вызовы COM не могут проникать через корпоративные брандмауэры. Технология ADO.NET решает все три проблемы благодаря использованию XML.

2.3 Разработка программного обеспечения

2.3.1 Описание программных модулей системы

Данный дипломный проект содержит:

Модуль авторизации содержит описание процесса авторизации пользователя. После успешного ввода логина и пароля, перед пользователем

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

Модуль редактирования справочников. Этот модуль доступен пользователю с правами Администратора БД и позволяет редактировать справочники:

- «Студент»;

- «Группа»;

- «Факультет»;

- «Компетенции»;

- «Виды внеучебной деятельности»;

- «Связь компетенций с видами внеучебной деятельности»;

Основной класс данного модуля - SQL.cs, который был описан выше. Так же используется класс SorvClient.cs, который характеризует клиентскую часть программного комплекса. Кроме этого используется класс FormAddValue.cs - форма, позволяющая добавлять записи в базу данных;

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

Модуль оптимизации. Этот модуль доступен пользователю с декана и позволяет просматривать текущие компетенции, вводить ограничение времени на следующий период, затрачиваемое на внеучебную деятельность каждым студентом группы в среднем и получить прогнозируемые компетенции на конец периода. Основной класс данного модуля - lpsolve55.cs. Этот класс используется для оптимизации данных. Так же используется класс Teacher.cs - позволяет производить оптимизацию, просматривать компетенции, проводить анализ;

2.3.2 Обоснование принятых интерфейсных решений

Интерфейс пользователя, он же пользовательский интерфейс (UI -- англ. user interface) -- разновидность интерфейсов, в котором одна сторона представлена человеком (пользователем), другая -- машиной/устройством. Представляет собой совокупность средств и методов, при помощи которых пользователь взаимодействует с различными, чаще всего сложными, с множеством элементов, машинами и устройствами.

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

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

1) Интерфейс оптимизации (рисунок 10)

Рисунок 10 - Интерфейс оптимизации

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

Так же не маловажный интерфейс, используемый в программном комплексе - интерфейс рекомендаций для студента (рисунок 11)

Рисунок 11 - Рекомендации времени

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

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

2.4 Разработка диаграмм физического уровня

2.4.1 Диаграмма последовательности

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

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

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

На ней приведена последовательность действий системы при формировании таблицы студент-компетенция. Эту таблицу может формировать пользователь, владеющий правами Декана. Для того что бы сформировать такую таблицу, необходимо выбрать в выпадающем списке факультет, затем группу, затем период обучения, после чего сформируется таблица компетенций (рисунок 8). В запросе, для построения таблицы, участвуют 6 таблиц: факультет (из неё мы получаем список факультетов), группа (получаем список групп), студент (получаем список студентов), компетенции (получаем список компетенций), период (получаем периоды обучения) и значения компетенций (из неё получаем значения каждой компетенции для каждого студента выбранной группы). Таблица выводится на основное меню декана. Таблица компетенций изображена на рисунке 14.



Рисунок 12 - Диаграмма последовательности

Рисунок 13 - Значения компетенций группы

2.4.3 Диаграмма компонентов

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

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

Клиентская часть:

- Proxy.cs - класс для работы с серверной частью;

- SorvClient.cs - клиентская часть программного комплекса;

- Teacher.cs - позволяет производить оптимизацию, просматривать компетенции, проводить анализ;

- ReportTimeAllocation.cs - позволяет просматривать распределение времени студентов;

- ReportTimeDifference.cs - позволяет просматривать совпадение рекомендуемого времени с временем, введенным студентом;

- Student.cs - предоставляет интерфейс главного меню пользователя для пользователя с уровнем доступа «студент»;

- DataBaseEditor.cs - форма редактирования базы данных;

- FormAddValue.cs - форма, позволяющая добавлять записи в БД;

Серверная часть:

- SorvService.cs - серверная часть программного комплекса;

- lpsolve55.cs - класс для работы с оптимизационным модулем;

- UsersValidator.cs - класс валидации пользователей;

- SQL.cs - класс, позволяющий производить запросы на базу данных.

Рисунок 14 - Диаграмма компонентов (клиентская часть)

Рисунок 15 - Диаграмма компонентов (серверная часть)

2.4.4 Диаграмма развёртывания

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

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

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

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

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

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

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

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

Диаграммы развертывания разрабатываются совместно системными аналитиками, сетевыми инженерами и системотехниками.

На диаграмме развёртывания (рисунок 12) представлены 2 узла системы: клиент и сервер содержащий БД, а также соединение, представляющее собой сеть.

Рисунок 16 - Диаграмма развёртывания

2.5 Разработка программы и методики испытаний программного комплекса

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

2.5.1 Программа испытаний

Программа испытаний состоит из перечня требований:

1) определение объекта испытаний;

2) определение цели испытаний;

3) определение объема и порядка проведения испытаний;

4) определение методики испытаний;

5) описание условия проведения испытаний;

6) описания используемых программных и аппаратных средств, для проведения испытаний.

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

Объект испытаний.

Объектом испытаний является программный комплекс оптимизации.

Цель испытаний.

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

Основные положения.

Испытания проводятся на основании графика разработки дипломного проекта, установленного деканом ФИСТ.

Документ разрабатывается согласно главе 6 РД 50-34.698-90.

Приемо-сдаточные испытания программы должны проводиться на кафедре ПМ и ВТ в сроки с 1.05 по 31.05 2012г.

Приемо-сдаточные испытания программы должны проводиться согласно разработанным и согласованным с деканом ФИСТ программного комплекса и методикам испытаний.

Испытания проводятся комиссией, в состав которой входят представители кафедры ПМ и ВТ и исполнителя программы.

Состав программной документации должен включать в себя:

- техническое задание;

- программу и методики испытаний;

- руководство пользователя.

- Объем испытаний

Перечень проверок, проводимых на первом этапе испытаний, должен включать в себя:

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

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

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

2.5.2 Методика испытаний

1. Методика проведения проверки комплектности программной документации:

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

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

2. Методика проведения проверки комплектности и состава технических и программных средств:

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

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

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

Перечень проверок, проводимых на втором этапе испытаний, должен включать в себя:

- проверку соответствия технических характеристик программы;

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

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

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

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

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

- комплектность программной документации;

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

В ходе проведения приемо-сдаточных испытаний оценке подлежат качественные характеристики программного комплекса. Проверке подлежит возможность выполнения АИС перечисленных ниже функций (весь перечень функций системы взят из задания на дипломный проект):

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

- ввод классификаций, деятельность-компетенция;

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

- оптимизационная математическая модель (выдает рекомендации по виду деятельности студентов);

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

- ввод сведений о степени согласия студентов с конкретными рекомендациями.

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

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

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

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

3. Требования к программной документации.

Состав программной документации должен включать в себя:

- задание на дипломный проект;

- пояснительную записку;

- программу и методики испытаний;

- руководство оператора.

4. Средства и порядок испытаний.

В состав технических средств должен входить IBM-совместимый персональный компьютер, включающий в себя:

- процессор не менее с тактовой частотой 2400 МГц;

- оперативную память объемом не менее 1Гб;

- тип ОС: MS Windows 98, Me, 2000, XP, Vista.

Испытания должны проводиться поэтапно в следующем порядке:

1. Проверка комплектности программной документации на программное изделие.

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

3. Проверка соответствия технических характеристик программы.

4. Проверка функции авторизации пользователей, разграничение прав доступа.

5. Проверка функции ведения информационных справочников.

6. Проверка проведения оптимизации.

7. Проверка расчета адекватности системы.

8. Проверка функции формирования отчетов.

9. Условия и порядок проведения испытаний.

Испытания должны проводиться в нормальных климатических условиях по ГОСТ 22261-94. Условия проведения испытаний приведены ниже:

- температура окружающего воздуха, С0 - от 20 до 25;

- относительная влажность, % - от 30 до 80;

- атмосферное давление, кПа - от 84 до 106;

- частота питающей электросети, Гц - 50;

- напряжение питающей среды переменного тока, В - 220.

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

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

При проведении испытаний работники кафедры ПМ и ВТ должны обеспечить соблюдение требований безопасности, установленных ГОСТ 12.2.007.0-75, ГОСТ 12.2.007.3-75, «Правилами техники безопасности при эксплуатации электроустановок потребителей» и «Правилами технической эксплуатации электроустановок потребителей».

2.6 Описание испытаний программы

2.6.1 Работа с авторизацией

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

Работа СОРВ осуществляется в основном с двумя интерфейсами: меню оптимизации и меню рекомендаций.

2.6.2 Работа с меню оптимизации

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

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

б) «Отчет». Данная кнопка выводит таблицу, в которой отображен список студентов группы и процент сходства мнения студентов с рекомендациями программы. Таблица выводится в отдельном окошке и доступна только для просмотра.

в) «Распределение времени». Эта кнопка выводит таблицу «Студент- вид внеучебной деятельности», в которой отображается список студентов выбранной группы и распределение времени между видами деятельности, рекомендованное каждому студенту. Таблица выводится в отдельном окошке и доступна только для просмотра.

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

2.6.3 Работа с формой рекомендаций

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

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

2.7 Описание контрольного примера

Цель разработанного контрольного примера - оценить функциональность программного комплекса.

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

Контрольным примером для данной программного комплекса будет являться кластеризация группы ГИП-105 факультета ИСТ.

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

Запуская систему, перед нами появляется начальное окно программы (рисунок 17).

Рисунок 17 - Начальное окно программы

Для просмотра данных всех курсов по всем семестрам (рисунок 18) мы можем воспользоваться кнопкой «Показать всех».



Рисунок 18 - Вывод данных за пять лет

В программном комплексе реализована сортировка по семестрам/годам и курсам (рисунок 19), которой мы воспользуемся для выбора нужной нам группы ГИП-105.

Рисунок 19 - Сортировка студенческого коллектива

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



Рисунок 20 - Выбор пределов творческих работ

Теперь создадим уровни творческого рейтинга, опираясь на нормативы форматки для ТЗ на КР в ТПД (рисунок 21)

Рисунок 21 - Уровни творческой деятельности

Для этого нажимаем кнопку «Создать кластеры» и вписываем нужные значения пределов творческого рейтинга для данного курса (рисунок 22). Предусмотрен ввод своих значений, так как было бы некорректным сделать фиксированные значения каждого уровня по отношению к разным курсам и при условии изменения данных значений с каждым годом.



Рисунок 22 - Задание уровней творческого рейтинга

Из исследования видно, что в худший уровень попали 5 студентов, никто не попал в нормальный уровень, в хороший попали 4 и в лучший - 8 (рисунок 23,рисунок 24).

Рисунок 23 - Результаты кластеризации

Рисунок 24 - Диаграмма процентного соотношения учащихся по рейтингу

У данной группы мы видим достойный творческий уровень

у большинства, хотя и есть к чему стремиться в целом.

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

2.7 Разработка руководства пользователя

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

1. Инженер-программист для внедрения, наладки и сопровождения оборудования и программных продуктов в качестве системного программиста, а так же для администрирования программного комплекса. Руководство администратора по работе с данным программным комплексом приведено в Приложении А. Описание функции администрирования представлено в руководстве администратора.

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

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

3 ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ РАЗРАБОТКИ

3.1 Планирование и организация процесса разработки

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

В первую очередь необходимо оценить трудоемкость. Трудоемкость выполнения каждой работы оценивается экспертным путем в человеко-днях, и носит вероятностный характер. Применяются оценки минимально возможной трудоемкости выполнения отдельных видов работ -- aj, максимально-возможной -- bj и наиболее вероятной -- mj. По этим величинам оценивается ожидаемое значение трудоемкостей , и продолжительность каждой работы Dj следующим образом:

; D_j = / n,

где n -- численность исполнителей, чел.

Экспертные оценки и расчетные величины трудоемкости и дисперсии приводятся в таблице 6.

Таблица 6 - Оценка трудоемкости отдельных видов работ

Вид работ

Размещено на http://www.allbest.ru/

Оценка трудоемкости	Расчетные величины
	aj	mj	bj	tj	Dj
Разработка технического задания на разработку АС	4	5	6	5	5,0
Обзор литературы и анализ предметной области	9	10	11	10	10,0
Учет требований потенциальных пользователей	4	5	7	5,1	5,1
Разработка информационно-логической структуры (UML - диаграммы вариантов использования, классов, последовательности и кооперации, активности для основных отчетов и состояний для системы в целом)	14	15	16	15	15,0
Описание логической структуры БД	8	9	11	9,1	9,1
Обоснование выбора среды и КТС (на качественном уровне)	6	7	9	7,1	7,1
Детализация логического проекта. Расчеты	8	9	10	9	9,0
Разработка программного модуля: Отчеты	10	11	12	11	11,0
Подготовка контрольного примера	17	18	19	18	18,0
Проработка удобства интерфейса	5	6	7	6	6,0
Отладка всей системы на реальных данных	7	8	9	8	8,0
Отладка и развертывания на сервере	8	9	10	9	9,0
Подготовка тех. документации на систему	4	5	6	5	5,0
Обучение пользователей	5	6	7	6	6,0
Всего				171	171

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

Таблица 7 - Планирование работ

№ п/п	Наименование работы	Предшествующие работы	Количество исполнителей (чел.)	Трудоемкость (чел./дн.)	Продолжительность, (дн.)
1	Разработка технического задания на разработку АС	-	1	5	5,0
2	Обзор литературы и анализ предметной области, описание процессов	1	1	10	10,0
3	Учет требований потенциальных пользователей	2	1	5,1	5,1
4	Разработка информационно-логической структуры (UML - диаграммы вариантов использования, классов, последовательности и кооперации, активности для основных отчетов и состояний для системы в целом)	3	1	15	15,0
5	Описание логической структуры БД	2, 3, 4	1	9,1	9,1
6	Обоснование выбора среды и КТС (на качественном уровне)	3, 4, 5	1	7,1	7,1
7	Детализация логического проекта. Расчеты	6	1	9	9,0
8	Разработка интерфейса администратора	7	1	8,8	8,8
9	Разработка интерфейса преподавателя	7	1	11	11,0
10	Разработка интерфейса студента	7	1	11	11,0
12	Подготовка контрольного примера	8, 9, 10, 11	3	18	18,0
13	Проработка удобства интерфейса	13	1	6	6,0
14	Отладка всей системы на реальных данных	14	1	8	8,0
15	Отладка и развертывания на сервере	15	1	9	9,0
16	Подготовка тех. документации на систему	8, 9, 10, 11, 12, 13	1	5	5,0
17	Всего	-	-	171	171

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

Примерный вид плана выполнения работ представлен в таблице 8.

Таблица 8- Линейный график работ

Код рабо- ты	Наименование работы	Трудо-емкость чел.-дн.	Продол- житель- ность, дн.	Календарь, мес.
				1 февр.	2 март	3 апрель	4 май	5 июнь
1	Разработка технического задания на разработку АС	5	5,0	-
2	Обзор литературы и анализ предметной области, описание процессов	10	10,0	-
3	Учет требований потенциальных пользователей	5,1	5,1
4	Разработка информационно-логической структуры (UML - диаграммы вариантов использования, классов, последовательности и кооперации, активности для основных отчетов и состояний для системы в целом)	15	15,0		-
5	Описание логической структуры БД	9,1	9,1		-
6	Обоснование выбора среды и КТС (на качественном уровне)	7,1	7,1
7	Детализация логического проекта. Расчеты	9	9,0
8	Подготовка контрольного примера	18	18,0
9	Проработка удобства интерфейса	6	6,0					-
10	Отладка всей системы на реальных данных	8	8,0					-
11	Отладка и развертывания на сервере	9	9,0					-
12	Подготовка тех. документации на систему	5	5,0					-

3.2 Расчет затрат на разработку программного комплекса

Затраты на разработку АС (Кп) определяются по формуле:

К_п = К_пр + К_по + К_ио + К_о ,

где К_пр -- затраты на проектирование АС, р.;

К_по -- затраты на создание программных изделий, образующих программное обеспечение АС, р.;

К_ио -- затраты на подготовку информационного обеспечения длительного пользования, создания базы данных АС, р.;

К_о -- затраты на отладку АС, р.

Укрупненный расчет затрат на разработку АС можно выполнить по формуле:

К_п = Ф_з/п [(1+?_д)(1+?_с)+??_н+?_пр]+t_ЭВМ С_м-ч ,

где Ф_з/п -- фонд основной заработной платы разработчиков и других исполнителей работ, р.;

?_д -- коэффициент дополнительной зарплаты, можно принимать 0,10...0,15;

?_с -- коэффициент отчислений на социальные нужды от основной и дополнительной заработной платы, равен 0,26;

?_н -- коэффициент накладных расходов организации, разрабатывающей проект, можно принимать 0,6...0,8;

?_пр -- коэффициент прочих расходов, принимать 0,1...0,2;

t_ЭВМ -- машинное время, затраченное для отладки программного обеспечения АС, ч.;

С_м-ч -- стоимость машино-часа работы ЭВМ, р.

Укрупненный расчет фонда основной заработной платы исполнителей работ по разработке АС производится по формуле:

Ф_з/п = ,

где -- суммарная трудоемкость работ по разработке АС, чел.ч. (чел.-дн.), расчет проводится, используя данные о трудоемкости работ -- таблица 4;

С -- тарифная ставка часовая (дневная) разработчиков и других исполнителей работ, р.

,

где ЗП_м - среднемесячная заработная плата разработчиков и других исполнителей работ, равно 10000 р.;

Д - количество рабочих дней в месяце, равно 22 дня.

Дневная тарифная ставка С численно равна

р.

Таким образом, фонд основной заработной платы Ф3/П численно равен:

Ф_{3 / П} =171*454,5 = 77719,5 р.

Машинное время tЭBM численно равно tЭBM = 300 ч.

Себестоимость машино-часа работы ЭВМ См-ч определяется по формуле:

С_м-ч = ,

где З_п - затраты на заработную плату обслуживающего персонала с учетом всех отчислений, р.;

А - годовая сумма амортизации, р.;

З_э - затраты на силовую электроэнергию, р.;

З_р - затраты на ремонт и обслуживание оборудования в год, р.;

З_н - накладные расходы, р.;

З_м - затраты на материалы в год, р.;

Ф_д - действительный годовой фонд времени работы КСА, ч.

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

,

где n - количество работников,

l_i - месячный оклад работника, р.,

k_д - коэффициент, учитывающий дополнительную заработную плату, примем равным 1,1,

k_с.н. - коэффициент, учитывающий отчисления на социальные нужды, примем равным 1,26,

N - количество ЭВМ.

З_п=6000*12*1,1*1,26/12=8316 р.

Годовые амортизационные отчисления по КСА считаются по формуле:

,

где С_КСА - стоимость ЭВМ и прочего оборудования, входящего в КСА (комплекс средств автоматизации), используемого при отладке АС;

Н_а - норма амортизации равна 25 процентов.

Стоимость ЭВМ, необходимой для разработки проектируемой системы СКСА в Самаре составляет около 20 000 р.

Амортизационные отчисления по КСА численно равны:

р.

Затраты на электроэнергию в год Зэ определяются следующим образом:

Зэ = Wу · Cэ · Tв,

где W_у -- установленная мощность, кВт;

С_э -- стоимость силовой электроэнергии, 1,3 р. / кВт;

Т_в -- время, в течение года, когда КСА потребляет электроэнергию, равно 2000 ч.

Суммарная потребляемая мощность комплекса средств автоматизации составляет 300 Вт/ч. Стоимость 1 кВт/ч составляет 2,8 коп...