Автоматизированная система управления услугами компьютерного сервис-центра

/

/

Введение

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

С проектированием данной системы связан ряд процессов:

- Обследование объекта автоматизации. Составление технического задания. Выбор методологии проектирования;

- Составление сетевого плана работ;

- Проектирование системы в соответствии с выбранной методологией;

- Определение требуемых вычислительных ресурсов;

- Оценка надежности системы.

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

1. Постановка задачи

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

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

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

- составление расписания выездов мастеров;

- ведения учета о проделанных работах;

- отслеживание стадий ремонта.

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

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

- добавления новой заявки на ремонт;

- возможность изменения статуса выполнения ремонта;

- возможность ведения статистики;

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

- возможность оповещение клиентов о завершении ремонта;

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

2 Результаты обследования объекта автоматизации

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

Эта модель обеспечивает описание статических отношений между различными структурными элементами - участниками бизнес-процесса.

Данная модель состоит из следующих элементов:

- директор;

- операторы;

- бухгалтерия;

- мастера.

Рисунок 1 - Организационная структура компьютерного сервис центра

2. Описание бизнес-процесса

2.1 Бизнес-процесс - «Выполнить ремонт»

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

Рисунок 2 - Диаграмма бизнес-процесса «Провести соревнование»

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

Рисунок 2.3 - Декомпозиция бизнес процесса «Провести соревнование»

2.2 Существующие аналоги системы

Sport Tables:

Основные возможности программы:

- Неограниченное количество турниров, организованных в виде «дерева турниров».

- Виды спорта: футбол, футзал (мини-футбол), хоккей, баскетбол, теннис и шахматы.

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

- Турниры в 1-8 кругов.

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

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

- Возможность настройки критериев распределения команд по местам.

- Турнирные таблицы: шахматка, показатели команд (дома/в гостях / всего).

- Календарь игр / список матчей и результатов.

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

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

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

- Графики по командам (дома/в гостях / всего): накопление очков по турам / датам, гистограмма результатов, посещаемость.

- Настройка внешнего вида турнирных таблиц (раскраска цветами, шрифты) и размеров.

- Информация по судьям, стадионам, командам.

- Импорт (загрузка) календаря и результатов из текстовых и CSV файлов.

- Экспорт в форматы HTML, CSV, ТXT, BMP, GIF, JPEG, WMF, EMF, возможность копирования таблиц в буфер обмена.

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

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

League Tracker:

Основные возможности примерно те же, что и у «Спортивных таблиц»: подробная статистика матчей, игроков, команд, импорт-экспорт в текстовый, html, csv формат. К особенностям можно отнести создание различных групп команд. Есть желание - программа покажет таблицу только московских команд с матчами между ними, или матчи между собой лидеров и т.д. Программа бесплатна.

«Футбольные чемпионаты»:

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

Основные возможности программы:

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

- возможность выбора правил расстановки (сортировки) команд по местам;

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

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

- возможность ведения многогрупповых турниров, например Лиги Чемпионов;

- редактирование любой введенной информации с автоматическим пересчетом всей статистики;

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

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

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

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

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

- разнообразная статистика по каждому чемпионату, команде, игроку, судье;

- составление прогнозов на матчи по оригинальным алгоритмам;

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

- печать данных;

- экспорт данных в html-файл;

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

Таблица 2.1 - Сравнение аналогов

«+» - система предоставляет функцию

«+-» - система предоставляет функцию, но известны более совершенные решения в других аналогах

«-» - система не предоставляет функцию

Все рассматриваемые аналоги предоставляют подробную информацию о соревновании и его участниках. Также все рассмотренные аналоги позволяют производить настройку регламента проведения соревнований. Но League Tracker предоставляют меньший набор параметров. «Футбольные чемпионаты» оказались лучшей из рассмотренных систем по разнообразию выбора типа соревнований по сравнению с другими. Так, например, Sport Tables и League Tracker не предоставляют возможности проведения соревнований «на выбывание». Не один из рассмотренных аналогов не предоставляет возможность автоматического составления расписания игр, а лишь позволяет добавлять его в ручном режиме, что является не совсем удобным. Sport Tables позволяет проводить экспорт в форматы HTML, CSV, ТXT, BMP, GIF, JPEG, WMF, EMF, «Футбольные чемпионаты» позволяют проводить экспорт лишь в html-файл;

3 Техническое задание

3.1 Общие сведения

Полное наименование системы и ее условное обозначение: Автоматизированная система для проведения спортивных соревнований (АС Спортивные соревнования).

Наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты: разработчик системы - студент гр. ИСТ-105 Ананьев А.С; заказчик системы - организации по проведению спортивных соревнований;

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

Плановые сроки начала и окончания работы по созданию системы: 17.09.2009 - 09.12.2009.

Сведения об источниках и порядке финансирования работ: не оплачивается.

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

Определения, обозначения и сокращения:

Таблица 3.1 - Определения, обозначения и сокращения

3.2 Назначение и цели создания системы

Назначение системы: вид автоматизированной деятельности - автоматизация процесса проведения спортивного соревнования; объект автоматизации - спортивное соревнование;

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

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

- регистрация участников;

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

- ведения подробной статистики соревнований.

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

- Добавление соревнования и информации о нем;

- Добавление участников соревнования и информации о них;

- Возможность проведения соревнования из 1 или нескольких групп;

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

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

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

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

- Возможность настройки критериев распределения команд по местам;

- Автоматическое составление расписания игр для каждой группы по критериям: тип проведения, набор команд, места проведения игр, дни Проведения игр, время проведения игр;

- Просмотр расписаний игр и результатов;

- Ведение и просмотр статистики по каждому матчу: полный счет, дата, тур, стадион;

- Ведение и просмотр статистики по каждой команде: состав, игровая статистика;

- Редактирование любой введенной информации с автоматическим пересчетом всей статистики;

- Автоматическое формирование таблиц результатов соревнований;

3.3 Характеристика объекта автоматизации

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

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

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

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

- провести часть соревнования;

- вести статистику;

3.4 Требования к системе

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

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

Перечень подсистем, их назначение и основные характеристики:

В состав АС Спортивные соревнования должен входить набор функций:

- Подсистема хранения данных;

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

- Подсистема формирования расписаний;

- Подсистема формирования статистики соревнований;

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

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

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

Подсистема формирования статистики соревнований должна осуществлять автоматическое составление отчетов о ходе соревнования.

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

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

- информация о соревновании;

- информация об участниках;

- информация о регламенте;

- расписание;

Требования к характеристикам взаимосвязей создаваемой системы со смежными системами: требования не предъявляются.

Требования к режимам функционирования системы: требования не предъявляются.

Требования по диагностированию системы: требования не предъявляются;

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

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

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

Требования к безопасности: требования не предъявляются;

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

Требования к транспортабельности для подвижных АС: требования не предъявляются;

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

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

- идентификацию пользователя;

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

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

Требования по сохранности информации при авариях: требования не предъявляются;

Требования к защите от влияния внешних воздействий: требования не предъявляются;

Требования к патентной частоте: требования не предъявляются;

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

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

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

- внешнее поведение сходных элементов интерфейса должны реализовываться одинаково для однотипных элементов.

Дополнительные требования: дополнительные требования не предъявляются.

Требования к функциям (задачам), выполняемым системой:

Хранение данных:

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

- добавление соревнования и информации о нем;

- добавление участников соревнования и информации о них;

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

- ведение и просмотр статистики по каждой команде: состав, игровая статистика;

- просмотр расписаний игр и результатов;

Подсистема настройки регламента соревнований:

Подсистема настройки регламента соревнований должна осуществлять настройку параметров проведения соревнований. Функции:

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

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

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

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

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

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

Формирования расписаний:

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

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

Формирование статистики соревнований:

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

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

- ведение и просмотр статистики по каждой команде: состав, игровая статистика;

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

- просмотр расписаний игр и результатов;

Требования к видам обеспечения;

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

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

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

- Сервер БД;

- Сервер приложений;

- Веб сервер;

- ПК пользователя;

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

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

4. Выбор методологии проектирования

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

Достоинства:

Функциональный подход

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

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

3. Процедурная строгость декомпозиции ИС и наглядность представления.

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

5. Широкое распространение среди аналитиков и разработчиков

Объектно-ориентированный подход

1. Сравнительная легкость, наглядность, эффективность моделей.

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

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

Недостатки:

Функциональный подход

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

2. Сложность восприятия иерархически упорядоченной информации.

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

Объектно-ориентированный подход

1. Невозможность проведения детального анализа процессов

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

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

4.1 Выбор средств разработки

Таблица 4.1 - Сравнение функциональных возможностей систем

Экспертная оценка применения систем по 5 шкале. В качестве эксперта при сравнении выступает разработчик данной системы.

Таблица 4.2 - Экспертная оценка применения систем

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

Для проектирования АС для проведения спортивных соревнований выбраны case-средства BPWin 4.0 / ERWin, так как они предоставляют возможность проектирования в нотациях IDEF0, IDEF3, DFD, с помощью которых возможна более детальная декомпозиция бизнес-функций системы, а так же позволяют точно и в полном объеме определить требования на начальных этапах разработки, что является важным при функциональном подходе к проектированию системы. Так же данные средства предоставляют возможность создания логической и физической моделей данных и генерации программного кода.

5. Сетевой план выполнения проектных работ

5.1 Определение стадий и состава работ

Таблица 5.1 - Стадии и этапы создания ИС

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

1. Формирование требований к АС:

1.1. «Обследование объекта и обоснование необходимости создания в АС» Происходит сбор данных о проведении спортивных соревнований. Процесс проведения соревнований состоит из нескольких основных подпроцессов, в которых одним из главных является автоматическое составление расписания. Эти подпроцессы трудно выполнимы без использования специальной автоматизированной системы. Поэтому создание автоматизированной системы для проведения спортивных соревнований является актуальным и необходимым для эффективной работы процессов, входящих в автоматизируемый объект.

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

1.3. «Оформление отчёта о выполненной работе и заявки на разработку АС (технико-технического задания)» проводят оформление отчета о выполненных работах на данной стадии и оформление заявки на разработку АС (тактико-технического задания) или другого заменяющего её документа с аналогичным содержанием.

2. Разработка концепции АС:

На этапе 2.1. «Изучение объекта» будет проведено более детальное изучение объекта автоматизации, т.е. будут более детально изучены процессы, требующие автоматизации.

2.2. «Проведение научно-исследовательских работ» не требуется. Так как процессы автоматизируемые для проведения спортивных соревнований не требуют применения сложных научно-исследовательских решений.

На этапе 2.3. «Разработка вариантов концепции АС и выбор варианта концепции АС,» проводится разработка нескольких вариантов концепций АС и планов их реализации. После сравнения данных концепция происходит выбор одной из них.

На этапе 2.4. «Оформление отчёта о выполненной работе» подготавливают и оформляют отчет, содержащий описание выполненных работ на стадии описания и обоснования предлагаемого варианта концепции системы.

3. Техническое задание:

На этапе 3.1. «Разработка и утверждение технического задания на создание АС» проводят разработку, оформление, согласование и утверждение технического задания на АС.

4. Эскизный проект:

На этапе 4.1. «Разработка предварительных проектных решений по системе и её частям» определяются: функции АС; функции, их цели и эффекты; состав комплексов задач и отдельных задач; концепция информационной базы, её укрупнённая структура; функции системы управления базой данных; состав вычислительной системы; функции и параметры основных программных средств.

5. Технический проект:

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

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

На этапе 5.3. «Разработка и оформление документации на поставку технической базы АС» проводят: подготовку и оформление документации на поставку необходимого аппаратного обеспечания АС. Основное внимание на этом этапе будет уделено выбору сервера и его компонентов для развертывания системы и эффективного выполнения все задач системы.

6. Рабочая документация:

На этапе 6.1 «Разработка рабочей документации на систему и её части» осуществляется разработка рабочей документации, содержащей все необходимые и достаточные сведения для обеспечения выполнения работ по вводу АС в действие и её эксплуатации, а также для поддержания уровня эксплуатационных характеристик (качества) системы в соответствии с принятыми проектными решениями, её оформление, согласование и утверждение. Виды документов по ГОСТ 34.201.

На этапе 6.2 «Разработка и адаптация программ» проводятся разработка программ и программных средств системы, а также разработка программной документации в соответствии с ГОСТ 19.101.

7. Ввод в действие:

7.1 «Подготовка объекта автоматизации к вводу АС в действие» проводят работы по организационной подготовке объекта автоматизации к вводу АС в действие, в том числе: реализацию проектных решений по организационной структуре АС; обеспечение подразделений объекта управления инструктивно-методическими материалами; внедрение классификаторов информации.

7.2 «Подготовка персонала» проводят обучение персонала и проверку его способности обеспечить функционирование АС.

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

7.4 «Строительно-монтажные работы» проводят: выполнение работ по строительству специализированных зданий (помещений) для размещения технических средств и персонала АС не требуется; сооружение кабельных каналов; выполнение работ по монтажу технических средств и линий связи; испытание смонтированных технических средств; сдачу технических средств для проведения пусконаладочных работ.

7.5 «Пусконаладочные работы» проводят автономную наладку технических и программных средств, загрузку информации в базу данных и проверку системы её ведения; комплексную наладку всех средств системы.

7.6 «Проведение предварительных испытаний» осуществляют:

а) испытания АС на работоспособность и соответствие техническому заданию в соответствии с программой и методикой предварительных испытаний;

б) устранение неисправностей и внесение изменений в документацию на АС, в том числе эксплуатационную в соответствии с протоколом испытаний;

в) оформление акта о приёмке АС в опытную эксплуатацию.

7.7 «Проведение опытной эксплуатации» проводят: опытную эксплуатацию АС; анализ результатов опытной эксплуатации АС; доработку (при необходимости) программного обеспечения АС; дополнительную наладку (при необходимости) технических средств АС; оформление акта о завершении опытной эксплуатации.

7.8 «Проведение приёмочных испытаний» проводят:

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

б) анализ результатов испытания АС и устранение недостатков, выявленных при испытаниях;

в) оформление акта о приёмке АС в постоянную эксплуатацию.

8. Сопровождение АС:

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

8.2 «Послегарантийное обслуживание» осуществляют работы по:

а) анализу функционирования системы;

б) выявлению отклонений фактических эксплуатационных характеристик АС от проектных значений;

в) установлению причин этих отклонений;

г) устранению выявленных недостатков и обеспечению стабильности эксплуатационных характеристик АС;

д) внесению необходимых изменений в документацию на АС.

5.2 Построение первоначального исходного сетевого плана

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

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

1. Получение заказа от заказчика на разработку АС.

2. Получение отчёта о результатах обследования.

3. Получение отчёта с обоснованием выбора концепции разрабатываемой АС.

4. Получение технического задания на создание АС.

5. Получение эскизного проекта АС.

6. Получение технического проекта АС.

7. Получение реализованной системы, рабочей документации на неё.

8. Получение внедрённой настроенной системы.

9. Выполненные гарантийные обязательства.

Рисунок 5.2-Первоначальный исходный сетевой план выполнения проектных работ

1-2. Формирование требований к АС. (2 недели).

2-3. Формирование концепции АС. (3 недели).

3-4. Составление ТЗ. (1 неделя).

4-5. Составление эскизного проекта. (1 неделя).

5-6. Составление технического проекта. (4 недели).

6-7. Разработка АС и рабочей документации. (10 недель).

7-8. Внедрение разработанной системы. (1 неделя).

8-9. Сопровождение системы. (28 недель).

Длительность критического пути первоначального сетевого графика составляет T_кр= 50 недель.

5.3 Квалификационный план

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

Таблица 5.3 - Квалификационный план проекта разработки ИС

5.4 Оптимизация исходного сетевого плана

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

Условные обозначения событий:

1. Получение заказа от заказчика на разработку АС.

2. Получение отчёта о результатах обследования.

3. Получение отчёта с обоснованием выбора концепции разрабатываемой АС.

4. Получение технического задания на создание АС.

5. Получение эскизного проекта АС.

6. Получение технорабочего проекта.

7. Получение внедрённой настроенной системы.

8. Выполненные гарантийные обязательства.

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

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

1. Получение заказа от заказчика на разработку АС.

2. Получение отчёта о результатах обследования.

3. Получение отчёта с обоснованием выбора концепции разрабатываемой АС.

4. Получение технического задания на создание АС.

5. Получение эскизного проекта АС.

6. Диаграмма иерархии функций;

7. Диаграмма потоков данных;

8. Диаграмма сущность-связь;

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

10. Получение программного продукта.

11. Получение протестированного программного продукта.

12. Получение реализованной системы.

13. Получение внедрённой настроенной системы.

14. Выполненные гарантийные обязательства.

Планируется параллельное выполнение работ на стадии «Получение технорабочего проекта»

Рисунок 5.5 - Сетевой график

1-2. Формирование требований к АС

2-3. Формирование концепции АС

3-4. Составление ТЗ

4-5. Составление эскизного проекта.

5-6. Разработка диаграммы иерархий функций.

5-7. Разработка диаграммы потоков данных.

7-8. Разработка диаграммы сущность-связь

8-9. Проектирование базы данных системы

9-10. Написание программного кода.

9-11. Тестирование программы.

10-12. Составление рабочей документации системы.

12-13. Внедрение разработанной системы.

13-14. Сопровождение системы.

5.4 Разработка плана контрольных мероприятий

Дата начала проектных работ в соответствии с составленным техническим заданием 01.09.2009 г. Исходный план контрольных мероприятий при выполнении проектных работ представлен в Таблице 5.6.

Таблица 5.6 - План контрольных мероприятий

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

6.1 Глоссарий

Заявка на участие - входная (внешняя) информация, представленная в виде документа (заявочного листа).

Информация об участнике - входная (внешняя) информация, представленная в виде документа с информацией о команде и её составе.

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

Информация о мед. персонале - внешняя информация от сторонних медицинских организаций, которые выполняют какие-либо работы в рамках процессов по проведению соревнований.

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

Информация о соревновании - информация о проводящихся соревнованиях.

Законодательство РФ - законодательство Российской Федерации, как федеральное, так и местное.

Правила судейства - официальные правила судейства в определенном виде спорта.

Расписание - документ, содержащий расписание проведения игр соревнования.

Регламент - документ, содержащий условия проведения соревнования.

Статистика соревнований - информация о ходе проведения соревнований.

6.2 Диаграмма иерархии функций

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

Рисунок 6.1 - Контекстная диаграмма

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

Спецификации процесса «Провести соревнование»:

ПРОЦЕСС: Провести соревнование

ВХОД: Заявки участников; Информация о местах поведения; Информация о судьях; Информация о мед. персонале;

ВЫХОД: Итоговая статистика.

ПОДПРОЦЕССЫ:

А1. Сформировать регламент

А2. Зарегистрировать участников

А3. Составить расписание

А4. Вести статистику

А5. Просматривать статистику

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

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

Рисунок 6.2 - Модель верхнего уровня

Спецификация верхнего уровня:

A0. Провести соревнование

ПРОЦЕСС: Сформировать регламент

ВХОД: Информация о местах поведения; Информация о судьях; Информация о мед. персонале;

ВЫХОД: Регламент;

ПОДПРОЦЕССЫ:

- Заполнить информацию о соревновании

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

- Заполнить список мест проведения

- Заполнить список судей, мед. персонала и информацию о них

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

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

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

- Выбрать схему проведения матчей отдельной группы

- Выбрать дни и время проведения матчей отдельной группы

- Выбрать места проведения для отдельной группы

- Заполнить начисление очков в матче

- Выбрать критерии распределения команд по местам

ПРОЦЕСС: Зарегистрировать участника

ВХОД: Регламент; Заявки участников;

ВЫХОД: Регламент; Зарегистрированные участники;

ПОДПРОЦЕССЫ:

- Принять заявку

- Зарегистрировать заявку

ПРОЦЕСС: Составить расписание

ВХОД: Регламент; Зарегистрированные участники;

ВЫХОД: Расписание;

ПРОЦЕСС: Вести статистику

ВХОД: Протоколы игр; Статистические данные;

ВЫХОД: Статистика команд; Статистка игр; Статистика участников команд;

ПРОЦЕСС: Просматривать статистику

ВХОД: Промежуточная статистика;

Выход: Просмотренная статистика;

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

Рисунок 6.3 - Декомпозиция процесса «Сформировать регламент»

6.3 Диаграмма потоков данных

Миниспецификация, словарь данных и DFD модель

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

На рис. 6.3.1 - 6.3.3 представлены DFD-модели последовательно разработанные в AllFusion Process Modeler.

A0. Провести соревнование - общая функция.

Заявка на участие - входная (внешняя) информация, представленная в виде документа (заявочного листа).

Информация об участнике - входная (внешняя) информация, представленная в виде документа с информацией о команде и её составе.

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

Информация о мед. персонале - внешняя информация от сторонних медицинских организаций, которые выполняют какие-либо работы в рамках процессов по проведению соревнований.

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

Информация о соревновании - информация о проводящихся соревнованиях.

Законодательство РФ - законодательство Российской Федерации, как федеральное, так и местное.

Правила судейства - официальные правила судейства в определенном виде спорта.

Расписание - документ, содержащий расписание проведения игр соревнования.

Регламент - документ, содержащий условия проведения соревнования.

Статистика соревнований - информация о ходе проведения соревнований.

Спецификации процесса

Спецификации процесса «Провести соревнование»:

ПРОЦЕСС: Провести соревнование

ВХОД: Заявка на участие; Информация об участнике; Информация о судьях; Информация о мед. персонале; Информация о местах проведения игр; Информация о соревновании; Правила судейства; Законодательство РФ.

ВЫХОД: Расписание; Регламент; Статистика соревнований.

ПОДПРОЦЕССЫ:

А1. Составить регламент соревнований

А2. Зарегистрировать участника

А3. Составить расписание

А4. Передать расписание и регламент участникам

А5. Провести часть соревнований

А6. Вести статистику

Рисунок 6.3.1 - DFD Провести соревнование

Спецификация микропроцессов верхнего уровня имеет следующий вид:

Рисунок 6.3.2 - DFD Микропроцессы верхнего уровня

Рисунок 6.3.3 - DFD Составить регламент соревнований

Спецификация микропроцессов верхнего уровня имеет следующий вид:

A0. Провести соревнование

ПРОЦЕСС: Составить регламент соревнований

ВХОД: Информация о судьях; Информация о мед. персонале; Информация о местах проведения игр; Законодательство;

ВЫХОД: Договоры об организации соревнований; Регламент;

ПОДПРОЦЕССЫ:

- Выбрать места проведения игр

- Заключить договора с арендодателями

- Выбор мед. персонала и заключение с ним договоров

- Выбор судей и заключение с ними договоров

- Выбрать схему проведения игр

- Выбрать критерии начисления очков в отдельном матче

- Определить критерии распределения команд по местам

ПРОЦЕСС: Зарегистрировать участника

ВХОД: Заявка на участие; Информация об участнике.

ВЫХОД: Зарегистрированный участник;

ПОДПРОЦЕССЫ:

- Принять заявку

- Зарегистрировать заявку

ПРОЦЕСС: Составить расписание

ВХОД: Участники соревнований; Регламент;

ВЫХОД: Расписание;

ПОДПРОЦЕССЫ:

- Анализировать данные

- Оформить расписание

ПРОЦЕСС: Передать расписание и регламент участникам

ВХОД: Расписание; Регламент;

ВЫХОД: Расписание; Регламент;

ПОДПРОЦЕССЫ:

- Передать расписание и регламент командам

- Передать расписание и регламент судьям

- Передать расписание и регламент мед. персоналу

- Передать расписание и регламент арендодателям мест проведения

ПРОЦЕСС: Провести часть соревнований

ВХОД: Информация о проведении игр; Правила судейства;

ВЫХОД: Протокол игр;

ПОДПРОЦЕССЫ:

- Оформить протокол на игру;

- Оформить статистические данные игры;

- Передать протоколы игр и статистические данные на обработку;

ПРОЦЕСС: Вести статистику

ВХОД: Протоколы игр; Статистические данные;

ВЫХОД: Статистика команд; Статистка игр; Статистика участников;

ПОДПРОЦЕССЫ:

- Принять протоколы игр;

- Обработать протоколы и статистические данные;

6.4 Модель данных

Выбор СУБД:

Таблица 6.4 - Сравнение СУБД

Для проектирования АС для проведения спортивных соревнований более подходящим является MySQL. Данная СУБД удовлетворяет основным требованиям - является бесплатной, работает на платформах Windows и Linux, позволяет осуществлять работу с сотнями пользователей, одновременно использующих систему.

В предметной области можно выделить следующие сущности:

Competition (соревнование) - основная сущность предметной области.

Organizer (организатор соревнования) - организация, которая проводит соревнование.

MedPersonnel (мед. персонал) - мед. прсонл, обслуживающий соревнование.

Referi (судья) - судьи, обслуживающие соревнование.

Group (группа) - группы, лиги, т.е. различные зоны на которые разбиты соревнование.

Command (команда) - команды участвующие в соревновании.

Composition (состав команды) - состав команд, участвующих в соревновании

Game (игра) - игры, проводимого турнира

ProtakolGame (протокол игры) - результаты отдельных игр.

LocationGame (место проведения игры) - спортивные объекты, на которых проходят игры.

Regulation (регламент) - условия и правила, по которым проходят соревнования.

Рис. 6.4.1 - Логическая модель данных

Также была сформирована физическая модель данных (Рис. 6.4.2), по которой был сформирован скрипт создания базы данных.

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

После анализа предметной области и выделения основных сущностей была составлена физическая схема БД. Сущности Organizer (организатор соревнования), MedPersonnel (мед. персонал) и Referi (судья) были объединены в одну таблицу User - совокупность всех людей, участвующих в проведении соревнования. Сущность Regulation (регламент) разделена на отдельные таблицы: PointGame - правила начисления баллов в отельном матче, RankComammand - схема распределения команд по местам, SchemeGame - схема проведения соревнования. Добавлены таблицы DateGame - содержащая информацию о дате и времени каждой игры и таблица Group_Location - для организации связи «многие ко многим».

7. Оценка надежности проектируемой системы

7.1 Физическая архитектура

Проектируемая система является клиент-серверным приложением (Рис. 7.1). Главным звеном в данной системе является сервер, на котором будет располагаться данная система и от его работы зависит всё её функционирование.

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

7.2 Расчёт надёжности

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

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

2) вероятность безотказной работы (Pз) системы должна быть не менее 0,985;

3) достоверность выдаваемой информации 0,99.

Система состоит из четырех последовательно включенных узлов:

Таблица 7.2 - Интенсивности отказов элементов системы

Схема соединения элементов системы

Все расчёты надёжности будут производится для серверной части системы и линий связи.

Интенсивность отказов системы:

л₀=2,2*10^-4 1/час

Вероятность исправной работы системы:

P₁(t)=e ^-л0*500=0,89500

Вероятность отказов системы:

Q₁(t)=1 - P₁(t)

Q₁(t)=1-0.8950=0.10500

Частота отказов системы:

б ₁(t)= л₀* P₁(t)

б ₁(t)= 2,2*10^-4*0,8950=0,00022

Средняя наработка системы на отказ:

Т_о1= 1/ л₀

Т_о1=1/2,2*10^-4 1/час = 4545 часов.

Резервирование

В результате расчетов вероятность исправной работы системы равна 0,8950. По условию вероятность безотказной работы системы за 500 часов должна быть не менее 0,9850. Следовательно, полученная вероятность не удовлетворяет условию. В целях повышения надежности системы необходимо применить резервирование.

Общее резервирование

1) Постоянное резервирование:

P_р(t)=1 - (1-e ^-лt)^m+1

P_р(t)=1 - (Q₁(t)) ^m+1=1-0,01100=0,98890

Т_ор=Т_о=Т_о1(1+0,50000)=6817 часов.

1) Резервирование замещением

Облегченный режи:

л₀> л₁

;

л₀= 2,2000*10^-4 1/час

л₁=1,6000*10^-4 1/час

P(t)= 0,89500 [1+1,37500*(1-0,92311)]=0,98962

T=(1/ л₀); k= л₁/л₀

Т=7176 часов

Нагруженный режим:

л₀₌ л₁

P(t)= 1 - [1-P₁(t)]²=0,9889

Т=6817 часов

Не нагруженный режим:

л₁₌ 0

P(t)= e - ^л0t= 0,89500 (1+0,11000)=0.9934

T=(m+1)/ л₀=2/ 0,00022=9090 часов

Поэлементное резервирование

Вероятность безотказной работы за время t = 500 ч при поэлементном нагруженном резервировании всех элементов сервера.

P_п(t)= - [1-e^-лit]^m+1}

P_п(t)=(1-0,00237)²*(1-0,00002)²=0,99995*0,99525=0,99519

Комбинированное резервирование

m=1

Резервирование линий связи или модема:

л_{линии связи} = л_модем =0,1*10^-4 1/час

P(t) _секции=1 - [1 - e^-ллсt]^m+1

P(t) _{секции=} 0,99997

P_{линий связи}(t)=P_модем(t)= e ^-лм*500= 0,99501

P_{процессор}(t)= P_память(t)= e ^-лпр*500= 0,95122

P(t)= 0,99997*0,99501*0,95122²=0,90029

Резервирование процессора или памяти:

л_{процессор} = л_память =1,0*10^-4 1/час

P(t) _секции=1 - [1 - e^-лпрt]^m+1

P(t) _{секции=} 0,99762

P_{памятим}(t)= P_{процессор}(t)= e ^-лпм*500= 0,95122

P_{линий связи}(t)=P_модем(t)= e ^-лм*500= 0,99501

P(t)= 0, 99762*0,95122*0,99501=0,939525

Резервирование двух элементов:

P_{процессор}(t) _секции= P_память(t) _секции =1 - [1 - e^-лt]^m+1=0,99762

P_{линий связи}(t)= P_модема(t)= e ^-лм*500= 0,99501

P_к3(t)= 0,99762*0,99762*0,99501*0,99501=0,98534

Резервирование двух элементов в нагруженном режиме:

Pпроцессор(t)= Pпамять(t)= 1 - [1-P₁(t)]²=1 - (1 - 0,95122)²=0,9976

P (t)= 0,9976*0,9976*0,99501*0,99501=0,9853

Резервирование двух элементов в ненагруженном режиме:

Pпроцессор(t)= Pпамять(t)= e - ^лпрt= 0,95122 (1+0,05)=0,99878

P(t)= 0,99878²*0,99501²=0,9876

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

8. Определение требуемых вычислительных ресурсов

8.1 Расчет производительности процессора

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

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

Таблица 8.1 - Характеристики выполняемых задач

Задачи данной системы условно можно отнести к следующему классу: моделирование, планирование, научные и оптимизационные задачи.

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

V_i - средняя длительность задачи в машинных операциях

Q_i - средний объем вводимого сообщения

W_i - средняя длина выходного сообщения

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

K_i - среднее число обращений к вводу-выводу при обработке запроса

_i - вид обработки информации

Таблица 8.2 - Исходные данные для расчета производительности вычислителя

Таблица 8.3 - Значения параметров

Для терминала:

Время полезной работы вычислителя в течении суток:

Т_пр = 0,594 ч

Производительность процессора:

P_п = 383284 оп/с

Для сервера:

Время полезной работы вычислителя в течении суток:

Т_пр = 21,487 ч

Производительность процессора:

P_п = 134337312 оп/с

Производительность процессора для обслуживания терминалов в диалоговом режиме:

P_g = 803435002 оп/с

Требуемая производительность процессора:

P_тр= 1418373430 оп/с

Таким образом, для выполнения задач необходим процессор с тактовой частотой 1,4 ГГц, без учёта необходимой производительности для стабильной работы операционной системы, прикладного программного обеспечения и других программных средств.

8.2 Расчет требуемой оперативной памяти

Требуемый объем оперативной памяти (в битах) для функционирования разрабатываемого программного приложения определяется следующим образом:

Суммарный объем входной информации:

U_вх = 19200 бит

Суммарный объем выходной информации:

U_вых = 809300 бит

Определим общий суммарный поток входной и выходной информации:

з₂^*= U_вх + U_вых

з₂^* = 828500 бит

Количество операндов, приходящихся на один оператор программы: б = 0,93

Определим число простых операндов в программе:

з₂ = 6 * з₂^*

з₂ = 4971000

Определим количество команд в программе:

P = 2,5* з₂

P = 12427500

Определим длину программы:

N = 8/3 * Р

N= 33140000

N = N₁+ N₂

N₁ - число операторов; N₂ - число операндов

N₂ = б/(б+1)*N =15969015

N₁ = 17170985

Число простых операторов з1 в программе определяется как:

log₂ з₁=N₂/(б* з₁)

Используя метод подбора, определили значения з₁.

Определяем объем программы в битах по следующей формуле:

Таблица 8.4 - Объем программы

Таким образом, оперативная память необходимая для нормальной работы системы составляет 210 МБ без учета памяти, которую могут занимать другие приложения, например ОС.

Заключение

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

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

Список используемых источников

1. Проектирование информационных систем и технологий: Метод. указания к курсовому проектированию / сост. А.В. Костров, Р.И. Макаров - Владим. гос. ун-т. Владимир, 1999. 12 с.

2. Проектирование информационных систем: Методические указания к практическим занятиям / сост. Р.И. Макаров, В.И. Мазанова - Владим. гос. ун-т. Владимир, 2008. 152 с.

3. Макаров Р.И. Методология проектирования информационных систем: Учебное пособие - Владим. гос. ун-т. Владимир, 2008. 152 с.

4. Калянов Г.Н. CASE-технологии: Консалтинг в автоматизации бизнес-процессов. 3-е изд. - М.: Горячая линия - Телеком, 2002. - 320 с.

5. Фаулер М. UML. Основы. Краткое руководство по унифицированному языку моделирования. 2-е издание / М. Фаулер, К. Скотт. - М.: Символ-Плюс, 2002. - 192 с. ISBN 5-93286-032-4

Приложение

Скрипт базы данных

CREATE TABLE Command

(

commandId INTEGER NOT NULL,

groupId INTEGER NULL,

name CHAR(30) NULL,

country CHAR(18) NULL,

city CHAR(18) NULL,

description TEXT NULL,

game INTEGER NULL,

victory INTEGER NULL,

tie INTEGER NULL,

loss INTEGER NULL,

gainBall INTEGER NULL,

missBall INTEGER NULL,

point INTEGER NULL

);

CREATE UNIQUE INDEX XPKCommand ON Command

(

commandId

);

ALTER TABLE Command

ADD PRIMARY KEY (commandId);

CREATE TABLE Competition

(

competitionId INTEGER NOT NULL,

name CHAR(100) NULL,

description TEXT NULL

);

CREATE UNIQUE INDEX XPKCompetition ON Competition

(

competitionId

);

ALTER TABLE Competition

ADD PRIMARY KEY (competitionId);

CREATE TABLE Composition

(

compositionId INTEGER NOT NULL,

commandId INTEGER NULL,

fio CHAR(50) NULL,

birthday DATE NULL,

game INTEGER NULL,

gainBall INTEGER NULL

);

CREATE UNIQUE INDEX XPKComposition ON Composition

(

compositionId

);

ALTER TABLE Composition

ADD PRIMARY KEY (compositionId);

CREATE TABLE DateGame

(

dateId INTEGER NOT NULL,

groupId INTEGER NULL,

day CHAR(18) NULL,

time TIME NULL

);

CREATE UNIQUE INDEX XPKDateGame ON DateGame

(

dateId

);

ALTER TABLE DateGame

ADD PRIMARY KEY (dateId);

CREATE TABLE Game

(

gameId INTEGER NOT NULL,

commandId INTEGER NULL,

locationId INTEGER NULL,

dateId INTEGER NULL,

protakolId INTEGER NULL,

result1 INTEGER NULL,

result2 INTEGER NULL

);

CREATE UNIQUE INDEX XPKGame ON Game

(

gameId

);

ALTER TABLE Game

ADD PRIMARY KEY (gameId);

CREATE TABLE Group

(

groupId INTEGER NOT NULL,

competitionId INTEGER NULL,

rankId INTEGER NULL,

schemeId INTEGER NULL,

name CHAR(30) NULL,

description TEXT NULL

);

CREATE UNIQUE INDEX XPKGroup ON Group

(

groupId

);

ALTER TABLE Group

ADD PRIMARY KEY (groupId);

CREATE TABLE Group_Location

(

id INTEGER NOT NULL,

groupId INTEGER NULL,

locationId INTEGER NULL

);

CREATE UNIQUE INDEX XPKGroup_Location ON Group_Location

(

id

);

ALTER TABLE Group_Location

ADD PRIMARY KEY (id);

CREATE TABLE LocationGame

(

locationId INTEGER NOT NULL,

name CHAR(18) NULL

);

CREATE UNIQUE INDEX XPKLocationGame ON LocationGame

(

locationId

);

ALTER TABLE LocationGame

ADD PRIMARY KEY (locationId);

CREATE TABLE PointGame

(

competitionId INTEGER NULL,

pointId INTEGER NOT NULL

);

CREATE UNIQUE INDEX XPKPointGame ON PointGame

(

pointId

);

ALTER TABLE PointGame

ADD PRIMARY KEY (pointId);

CREATE TABLE ProtakolGame

(

protakolId INTEGER NOT NULL,

compositionId INTEGER NULL,

amountGainBall INTEGER NULL

);

CREATE UNIQUE INDEX XPKProtakolGame ON ProtakolGame

(

protakolId

);

ALTER TABLE ProtakolGame

ADD PRIMARY KEY (protakolId);

CREATE TABLE RankCommand

(

rankId INTEGER NOT NULL,

name CHAR(100) NULL,

description TEXT NULL

);

CREATE UNIQUE INDEX XPKRankCommand ON RankCommand

(

rankId

);

ALTER TABLE RankCommand

ADD PRIMARY KEY (rankId);

CREATE TABLE SchemeGame

(

schemeId INTEGER NOT NULL,

name CHAR(18) NULL,

description TEXT NULL

);

CREATE UNIQUE INDEX XPKSchemeGame ON SchemeGame

(

schemeId

);

ALTER TABLE SchemeGame

ADD PRIMARY KEY (schemeId);

CREATE TABLE User

(

fio CHAR(18) NULL,

competitionId INTEGER NULL,

userId INTEGER NOT NULL,

status CHAR(18) NULL

);

CREATE UNIQUE INDEX XPKUser ON User

(

userId

);

ALTER TABLE User

ADD PRIMARY KEY (userId);

ALTER TABLE Command

ADD FOREIGN KEY R_16 (groupId) REFERENCES Group (groupId);

ALTER TABLE Composition

ADD FOREIGN KEY R_36 (commandId) REFERENCES Command (commandId);

ALTER TABLE DateGame

ADD FOREIGN KEY R_26 (groupId) REFERENCES Group (groupId);

ALTER TABLE Game

ADD FOREIGN KEY R_30 (commandId) REFERENCES Command (commandId);

ALTER TABLE Game

ADD FOREIGN KEY R_31 (locationId) REFERENCES LocationGame (locationId);

ALTER TABLE Game

ADD FOREIGN KEY R_32 (dateId) REFERENCES DateGame (dateId);

ALTER TABLE Game

ADD FOREIGN KEY R_34 (protakolId) REFERENCES ProtakolGame (protakolId);

ALTER TABLE Group

ADD FOREIGN KEY R_14 (competitionId) REFERENCES Competition (competitionId);

ALTER TABLE Group

ADD FOREIGN KEY R_19 (rankId) REFERENCES RankCommand (rankId);

ALTER TABLE Group

ADD FOREIGN KEY R_23 (schemeId) REFERENCES SchemeGame (schemeId);

ALTER TABLE Group_Location

ADD FOREIGN KEY R_38 (groupId) REFERENCES Group (groupId);

ALTER TABLE Group_Location

ADD FOREIGN KEY R_39 (locationId) REFERENCES LocationGame (locationId);

ALTER TABLE PointGame

ADD FOREIGN KEY R_24 (competitionId) REFERENCES Competition (competitionId);

ALTER TABLE ProtakolGame

ADD FOREIGN KEY R_37 (compositionId) REFERENCES Composition (compositionId);

ALTER TABLE User

ADD FOREIGN KEY R_41 (competitionId) REFERENCES Competition (competitionId);