|
1
|
ИСИМ
|
Информационные системы и информационный
менеджмент
|
|
2
|
ТЗ
|
Техническое задание
|
|
3
|
АС
|
Автоматизированная система
|
3.2 Назначение и цели создания системы
Назначение системы: вид автоматизированной деятельности -
автоматизация процесса проведения спортивного соревнования; объект
автоматизации - спортивное соревнование;
Цели создания системы: полная автоматизация операций
регистрации участников, составления расписания и ведения подробной статистики
соревнования.
Для реализации поставленной цели система должна решать
следующие задачи:
- регистрация участников;
- составление расписания соревнований;
- ведения подробной статистики соревнований.
Можно определить следующие задачи, решаемые системой для
проведения спортивных соревнований:
- Добавление соревнования и информации о
нем;
- Добавление участников соревнования и
информации о них;
- Возможность проведения соревнования из 1
или нескольких групп;
- Возможность проведения соревнований в
несколько кругов;
- Возможность определения даты, времени
проведения игр каждой группы;
- Возможность выбора мест проведения
соревнований для каждой группы;
- Возможность настройки количества очков,
начисляемых за победу, ничью, поражение;
- Возможность настройки критериев
распределения команд по местам;
- Автоматическое составление расписания игр
для каждой группы по критериям: тип проведения, набор команд, места проведения
игр, дни Проведения игр, время проведения игр;
- Просмотр расписаний игр и результатов;
- Ведение и просмотр статистики по каждому
матчу: полный счет, дата, тур, стадион;
- Ведение и просмотр статистики по каждой
команде: состав, игровая статистика;
- Редактирование любой введенной информации
с автоматическим пересчетом всей статистики;
- Автоматическое формирование таблиц
результатов соревнований;
.3 Характеристика объекта автоматизации
Краткие сведения об объекте автоматизации или ссылки на
документы, содержащие такую информацию: объектом автоматизации являются
процессы по проведению спортивного соревнования.
Процессы проведения спортивного соревнования включают в себя:
зарегистрировать участников соревнования;
составить расписание соревнования;
провести часть соревнования;
вести статистику;
3.4 Требования к системе
Требования к системе в целом
Требования к структуре и функционированию системы
Перечень подсистем, их назначение и основные характеристики:
В состав АС Спортивные соревнования должен входить набор
функций:
Подсистема хранения данных;
Подсистема настройки регламента соревнований;
Подсистема формирования расписаний;
Подсистема формирования статистики соревнований;
Подсистема хранения данных должна осуществлять хранение
данных о соревновании, участниках, данных для формирования расписаний и
статистики.
Подсистема настройки регламента соревнований должна
осуществлять настройку параметров проведения соревнований.
Подсистема формирования расписаний должна осуществлять
автоматическое составление расписания соревнования в зависимости от настроек
регламента.
Подсистема формирования статистики соревнований должна
осуществлять автоматическое составление отчетов о ходе соревнования.
Требования к способам и средствам связи для информационного
обмена между компонентами системы
Входящие в состав подсистемы в процессе функционирования
должны обмениваться информацией. В состав передаваемых данных входят:
информация о соревновании;
информация об участниках;
информация о регламенте;
расписание;
Требования к характеристикам взаимосвязей создаваемой системы
со смежными системами: требования не предъявляются.
Требования к режимам функционирования системы: требования не
предъявляются.
Требования по диагностированию системы: требования не
предъявляются;
Перспективы развития, модернизации системы: должна
реализовывать возможность дальнейшей модернизации функциональности системы.
Требования к численности и квалификации персонала системы:
для эксплуатации АС Спортивные соревнования определена роль - пользователь.
Пользователи системы должны иметь опыт работы с персональным компьютером на
уровне квалифицированного пользователя и свободно осуществлять базовые
операции. Рекомендуемая численность для эксплуатации - число штатных единиц
определяется структурой организации проводящей соревнования;
Показатели назначения: система должна обеспечивать
возможность одновременной работы нескольких пользователей.
Требования к безопасности: требования не предъявляются;
Требования к эргономике и технической эстетике: интерфейс
системы должен быть понятным и удобным, не должен быть перегружен графическими
элементами и должен обеспечивать быстрое отображение экранных форм.
Навигационные элементы должны быть выполнены в удобной для пользователя форме.
Ввод-вывод данных системы, прием управляющих команд и отображение результатов
их исполнения должны выполняться в интерактивном режиме. Интерфейс должен
соответствовать современным требованиям и обеспечивать удобный доступ к
основным функциям и операциям системы.
Требования к транспортабельности для подвижных АС: требования
не предъявляются;
Требования к эксплуатации, техническому обслуживанию, ремонту
и хранению компонентов системы: система предназначена для бесперебойной работы
при регулярной, круглосуточной эксплуатации.
Требования к защите информации от несанкционированного
доступа: компоненты подсистемы должны обеспечивать:
идентификацию пользователя;
проверку полномочий пользователя при работе с системой;
разграничение доступа пользователей к различным задачам
системы.
Требования по сохранности информации при авариях: требования
не предъявляются;
Требования к защите от влияния внешних воздействий:
требования не предъявляются;
Требования к патентной частоте: требования не предъявляются;
Требования по стандартизации и унификации: взаимодействие
пользователей с прикладным программным обеспечением, входящим в состав системы
должно осуществляться посредством визуального графического интерфейса (GUI). Экранные формы должны
проектироваться с учетом требований унификации:
все экранные формы пользовательского интерфейса должны быть
выполнены в едином графическом дизайне, с одинаковым расположением основных
элементов управления и навигации;
для обозначения сходных операций должны использоваться
сходные графические значки, кнопки и другие управляющие элементы. Термины,
используемые для обозначения типовых операций, а также последовательности
действий пользователя при их выполнении, должны быть унифицированы;
внешнее поведение сходных элементов интерфейса должны
реализовываться одинаково для однотипных элементов.
Дополнительные требования: дополнительные требования не
предъявляются.
Требования к функциям (задачам), выполняемым системой:
Хранение данных:
Хранение данных должно осуществлять хранение данных о
соревновании, участниках, данных для формирования расписаний и статистики.
Функции:
добавление соревнования и информации о нем;
добавление участников соревнования и информации о них;
ведение и просмотр статистики по каждому матчу: полный счет,
дата, тур, стадион;
ведение и просмотр статистики по каждой команде: состав,
игровая статистика;
просмотр расписаний игр и результатов;
Подсистема настройки регламента соревнований:
Подсистема настройки регламента соревнований должна
осуществлять настройку параметров проведения соревнований. Функции:
возможность проведения соревнования из 1 или нескольких
групп;
возможность проведения соревнований в несколько кругов;
возможность определения даты, времени проведения игр каждой
группы;
возможность выбора мест проведения соревнований для каждой
группы;
возможность настройки количества очков, начисляемых за
победу, ничью, поражение;
возможность настройки критериев распределения команд по
местам;
Формирования расписаний:
Функция формирования расписаний должна осуществлять
автоматическое составление расписания соревнования в зависимости от настроек
регламента. Функции:
автоматическое составление расписания игр для каждой группы
по критериям: тип проведения, набор команд, места проведения игр, дни
проведения игр, время проведения игр;
Формирование статистики соревнований:
Функция формирования статистики соревнований должна
осуществлять автоматическое составление отчетов о ходе соревнования. Функции:
ведение и просмотр статистики по каждому матчу: полный счет,
дата, тур, стадион;
ведение и просмотр статистики по каждой команде: состав,
игровая статистика;
автоматическое формирование таблиц результатов соревнований;
просмотр расписаний игр и результатов;
Требования к видам обеспечения;
Требования информационному обеспечению системы: уровень
хранения данных в системе должен быть построен на основе современных
реляционных или объектно-реляционных СУБД. Для обеспечения целостности данных
должны использоваться встроенные механизмы СУБД. Доступ к данным должен быть
предоставлен только авторизованным пользователям с учетом их служебных
полномочий, а также с учетом категории запрашиваемой информации. Структура базы
данных должна быть организована рациональным способом, исключающим
единовременную полную выгрузку информации, содержащейся в базе данных системы.
Требования к лингвистическому обеспечению системы: для
организации взаимодействия с пользователем должен использоваться русский язык.
Требования к техническому обеспечению: в состав комплекса
должны входить следующие технические средства:
Сервер БД;
Сервер приложений;
Веб сервер;
ПК пользователя;
Требования к метрологическому обеспечению: требования к
метрологическому обеспечению не предъявляются.
Требования к организационному обеспечению: к работе с
системой должны допускаться сотрудники, имеющие навыки работы на персональном
компьютере, ознакомленные с правилами эксплуатации.
4. Выбор методологии проектирования
Для выбора методологии проектирования было проведено
сравнение функционального и объектно-ориентированного подходов.
Достоинства:
Функциональный подход
. Возможность проведения глубокого анализа
бизнес-процессов
. Реализация структурного подхода к проектированию,
когда каждый функциональный блок может быть декомпозирован на множество
подфункций и т.д., выполняя, таким образом, модульное проектирование ИС.
. Процедурная строгость декомпозиции ИС и наглядность
представления.
. Применение графических языков моделирования IDEF0, IDEF3, DFD обеспечивает логическую
целостность и полноту описания, для достижения точных результатов.
. Широкое распространение среди аналитиков и разработчиков
Объектно-ориентированный подход
. Сравнительная легкость, наглядность, эффективность
моделей.
. Построение бизнес-модели организации, позволяющей
перейти от модели сценариев использования к модели, определяющей отдельные
объекты, участвующие в реализации бизнес-функций.
. Возможность автоматической генерации кода на основе
построенных моделей.
Недостатки:
Функциональный подход
. Процессы и данные существуют отдельно друг от друга
- помимо функциональной декомпозиции существует структура данных, находящаяся
на втором плане. Кроме того, отсутствует понятие времени, т.е. отсутствует
анализ временных промежутков при преобразовании данных.
. Сложность восприятия иерархически упорядоченной
информации.
. Необходимость следования определенной структуре,
которая не всегда необходима.
Объектно-ориентированный подход
1. Невозможность проведения детального
анализа процессов
2. Менее наглядны, при представлении модели
пользователю-заказчику.
Для проектирования АС для проведения спортивных соревнований
более подходящим является функциональный подход. Выбор обусловлен тем, что
анализ бизнес-процессов проектируемой системы играет важную роль, необходима
детальная декомпозиция бизнес-функций, а так же необходимо правильно, точно и в
полном объеме определить требования на начальных этапах.
4.1 Выбор средств разработки
Таблица 4.1 - Сравнение функциональных возможностей систем
|
Возможности/ Инструментальная среда
|
ARIS
|
BPWin 4.0
|
|
Поддерживаемый стандарт
|
-
|
IDEF0, IDEF3, DFD
|
|
Ограничение на количество объектов на диаграмме.
|
Нет.
|
От 2 до 8.
|
|
Возможность декомпозиции
|
Неограниченная декомпозиция. Возможно
декомпозиция на различные типы моделей.
|
Неограниченная декомпозиция. Возможен
однократный переход на другую нотацию в процессе декомпозиции.
|
|
Удобство работы по созданию моделей
|
Сложная панель управления, есть выравнивание
объектов, есть undo.
|
Простая панель управления, нет выравнивания
объектов, нет undo.
|
|
Возможность групповой работы
|
Есть. Используется ARIS Server.
|
Есть. Используется Model Mart.
|
|
Формат представления моделей
|
Не регламентируется
|
Стандартный бланк IDEF с возможностью его
отключения.
|
|
Система хранения данных модели
|
Объектная база данных
|
Модели хранятся в файлах
|
|
Ограничение на размер базы данных
|
Нет. Размер базы данных ограничивается
вычислительными ресурсами
|
Нет. Размер базы данных ограничивается
вычислительными ресурсами
|
Экспертная оценка применения систем по 5 шкале. В качестве
эксперта при сравнении выступает разработчик данной системы.
Таблица 4.2 - Экспертная оценка применения систем
|
Задача
|
ARIS
|
BPWin 4.0 / ERWin
|
|
описание функциональных возможностей системы;
|
4
|
5
|
|
создание логической модели данных;
|
-
|
5
|
|
создание физической модели данных.
|
-
|
5
|
|
Генерация программного кода, SQL-сценариев для
создания структуры базы данных.
|
-
|
5
|
Продукты BPWin 4.0 / ERWin позволяют решить весь комплекс
задач по проектированию, разработке и проекта, формированию кодов для
управления базами данными. ARIS решает тот же комплекс задач за исключением
формирования логической структуры БД и кодов приложений. Однако, решение задач
ARIS осуществляет более выразительными средствами. Так же ARIS предоставляет
большое число стандартных объектов для описания бизнес-процессов и инструментов
имитационного моделирования. Основными недостатками BPWin 4.0 / ERWin являются
отсутствие стандартных объектов для описания бизнес процессов, довольно узкие
возможности для проведения экономического анализа.
Для проектирования АС для проведения спортивных соревнований
выбраны case-средства BPWin 4.0 / ERWin, так как они предоставляют возможность
проектирования в нотациях IDEF0, IDEF3, DFD, с помощью которых возможна более
детальная декомпозиция бизнес-функций системы, а так же позволяют точно и в
полном объеме определить требования на начальных этапах разработки, что
является важным при функциональном подходе к проектированию системы. Так же
данные средства предоставляют возможность создания логической и физической
моделей данных и генерации программного кода.
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. Разработка предварительных проектных
решений по системе и её частям. 4.2. Разработка документации на АС и её
части.
|
|
5. Технический проект.
|
5.1. Разработка проектных решений по системе и
её частям. 5.2. Разработка документации на АС и её части. 5.3. Разработка и
оформление документации на поставку технической базы АС.
|
|
6. Рабочая документация.
|
6.1. Разработка рабочей документации на систему
и её части. 6.2. Разработка и адаптация программ.
|
|
7. Ввод в действие.
|
7.1. Подготовка объекта автоматизации к вводу
АС в действие. 7.2. Подготовка персонала. 7.3. Комплектация АС поставляемыми
изделиями (программными и техническими средствами, программно-техническими
комплексами, информационными изделиями). 7.4. Строительно-монтажные работы.
7.5. Пусконаладочные работы. 7.6. Проведение предварительных испытаний. 7.7.
Проведение опытной эксплуатации. 7.8. Проведение приёмочных испытаний.
|
|
8. Сопровождение АС
|
8.1. Выполнение работ в соответствии с
гарантийными обязательствами. 8.2. Послегарантийное обслуживание.
|
Учитывая выбранную методологию проектирования и специфику ИС,
для разработки и выполнения выделенных этапов необходимо выполнения уточнение
содержания проводимых работ.
. Формирование требований к АС:
.1. «Обследование объекта и обоснование необходимости
создания в АС» Происходит сбор данных о проведении спортивных соревнований.
Процесс проведения соревнований состоит из нескольких основных подпроцессов, в
которых одним из главных является автоматическое составление расписания. Эти
подпроцессы трудно выполнимы без использования специальной автоматизированной
системы. Поэтому создание автоматизированной системы для проведения спортивных соревнований
является актуальным и необходимым для эффективной работы процессов, входящих в
автоматизируемый объект.
.2. «Формирование требований пользователя к АС» - требования
формируются на основе обследований процессов, необходимых для автоматизации
проведения спортивных соревнований. Требования учитываются для определенных
компонентов системы, таких как пользовательский интерфейс, наличие
определенного функционала.
.3. «Оформление отчёта о выполненной работе и заявки на
разработку АС (технико-технического задания)» проводят оформление отчета о
выполненных работах на данной стадии и оформление заявки на разработку АС
(тактико-технического задания) или другого заменяющего её документа с
аналогичным содержанием.
. Разработка концепции АС:
На этапе 2.1. «Изучение объекта» будет проведено более
детальное изучение объекта автоматизации, т.е. будут более детально изучены
процессы, требующие автоматизации.
.2. «Проведение научно-исследовательских работ» не требуется.
Так как процессы автоматизируемые для проведения спортивных соревнований не
требуют применения сложных научно-исследовательских решений.
На этапе 2.3. «Разработка вариантов концепции АС и выбор
варианта концепции АС,» проводится разработка нескольких вариантов концепций АС
и планов их реализации. После сравнения данных концепция происходит выбор одной
из них.
На этапе 2.4. «Оформление отчёта о выполненной работе»
подготавливают и оформляют отчет, содержащий описание выполненных работ на
стадии описания и обоснования предлагаемого варианта концепции системы.
. Техническое задание:
На этапе 3.1. «Разработка и утверждение технического задания
на создание АС» проводят разработку, оформление, согласование и утверждение
технического задания на АС.
. Эскизный проект:
На этапе 4.1. «Разработка предварительных проектных решений
по системе и её частям» определяются: функции АС; функции, их цели и эффекты;
состав комплексов задач и отдельных задач; концепция информационной базы, её
укрупнённая структура; функции системы управления базой данных; состав
вычислительной системы; функции и параметры основных программных средств.
. Технический проект:
На этапе 5.1. «Разработка проектных решений по системе и её
частям» обеспечивается разработка решений по системе и её частям. На данном
этапе строиться ряд диаграмм функционально-ориентированной методологии,
отражающих функции и структуру системы. Помимо этого определяется ряд вопросов
о структуре технических средств, алгоритмам решения задач и применяемым языкам,
системе классификации и кодирования информации, программному обеспечению.
.2. «Разработка документации на АС и её части» проводят
разработку, оформление, согласование и утверждение документации необходимой для
дальнейшего выполнения работ по созданию АС.
На этапе 5.3. «Разработка и оформление документации на
поставку технической базы АС» проводят: подготовку и оформление документации на
поставку необходимого аппаратного обеспечания АС. Основное внимание на этом
этапе будет уделено выбору сервера и его компонентов для развертывания системы
и эффективного выполнения все задач системы.
. Рабочая документация:
На этапе 6.1 «Разработка рабочей документации на систему и её
части» осуществляется разработка рабочей документации, содержащей все
необходимые и достаточные сведения для обеспечения выполнения работ по вводу АС
в действие и её эксплуатации, а также для поддержания уровня эксплуатационных
характеристик (качества) системы в соответствии с принятыми проектными
решениями, её оформление, согласование и утверждение. Виды документов по ГОСТ
34.201.
На этапе 6.2 «Разработка и адаптация программ» проводятся
разработка программ и программных средств системы, а также разработка
программной документации в соответствии с ГОСТ 19.101.
.1 «Подготовка объекта автоматизации к вводу АС в действие»
проводят работы по организационной подготовке объекта автоматизации к вводу АС
в действие, в том числе: реализацию проектных решений по организационной
структуре АС; обеспечение подразделений объекта управления
инструктивно-методическими материалами; внедрение классификаторов информации.
.2 «Подготовка персонала» проводят обучение персонала и
проверку его способности обеспечить функционирование АС.
.3 «Комплектация АС поставляемыми изделиями (программными и
техническими средствами, программно-техническими комплексами, информационными
изделиями)» обеспечивают получение комплектующих изделий серийного и единичного
производства, материалов и монтажных изделий. Проводят входной контроль их
качества.
.4 «Строительно-монтажные работы» проводят: выполнение работ
по строительству специализированных зданий (помещений) для размещения
технических средств и персонала АС не требуется; сооружение кабельных каналов;
выполнение работ по монтажу технических средств и линий связи; испытание
смонтированных технических средств; сдачу технических средств для проведения
пусконаладочных работ.
.5 «Пусконаладочные работы» проводят автономную наладку
технических и программных средств, загрузку информации в базу данных и проверку
системы её ведения; комплексную наладку всех средств системы.
.6 «Проведение предварительных испытаний» осуществляют:
а) испытания АС на работоспособность и соответствие
техническому заданию в соответствии с программой и методикой предварительных
испытаний;
б) устранение неисправностей и внесение изменений в
документацию на АС, в том числе эксплуатационную в соответствии с протоколом
испытаний;
в) оформление акта о приёмке АС в опытную эксплуатацию.
.7 «Проведение опытной эксплуатации» проводят: опытную
эксплуатацию АС; анализ результатов опытной эксплуатации АС; доработку (при необходимости)
программного обеспечения АС; дополнительную наладку (при необходимости)
технических средств АС; оформление акта о завершении опытной эксплуатации.
.8 «Проведение приёмочных испытаний» проводят:
а) испытания на соответствие техническому заданию в
соответствии с программой и методикой приёмочных испытаний;
б) анализ результатов испытания АС и устранение недостатков,
выявленных при испытаниях;
в) оформление акта о приёмке АС в постоянную эксплуатацию.
. Сопровождение АС:
.1 «Выполнение работ в соответствии с гарантийными
обязательствами» осуществляются работы по устранению недостатков, выявленных
при эксплуатации АС в течении установленных гарантийных сроков, внесению
необходимых изменений в документацию по АС.
.2 «Послегарантийное обслуживание» осуществляют работы по:
а) анализу функционирования системы;
б) выявлению отклонений фактических эксплуатационных
характеристик АС от проектных значений;
в) установлению причин этих отклонений;
г) устранению выявленных недостатков и обеспечению
стабильности эксплуатационных характеристик АС;
д) внесению необходимых изменений в документацию на АС.
.2 Построение первоначального исходного сетевого
плана
На первоначальном исходном сетевом плане выполнения проектных
работ вершины обозначают события (это результат выполнения работ или
определенная дата в ходе выполнения проекта, используется для отображения
состояния завершенности работы), инициирующие начало выполнения соответствующих
работ, а стрелки - выполняемые работы (это некоторая деятельность, необходимая
для достижения конкретного результата, которая требует на выполнение время и
ресурсы).
Работа имеет временные оценки, которые проставляются над
стрелками. На рисунке 5.2. изображен первоначальный сетевой плана,
разработанный на основании стадий, выделенных в предыдущем пункте:
. Получение заказа от заказчика на разработку АС.
. Получение отчёта о результатах обследования.
. Получение отчёта с обоснованием выбора концепции
разрабатываемой АС.
. Получение технического задания на создание АС.
5. Получение эскизного проекта АС.
. Получение технического проекта АС.
7. Получение реализованной системы, рабочей документации
на неё.
8. Получение внедрённой настроенной системы.
. Выполненные гарантийные обязательства.
Рисунок 5.2-Первоначальный исходный сетевой план выполнения
проектных работ
-2. Формирование требований к АС. (2 недели).
-3. Формирование концепции АС. (3 недели).
-4. Составление ТЗ. (1 неделя).
-5. Составление эскизного проекта. (1 неделя).
-6. Составление технического проекта. (4 недели).
-7. Разработка АС и рабочей документации. (10 недель).
-8. Внедрение разработанной системы. (1 неделя).
-9. Сопровождение системы. (28 недель).
Длительность критического пути первоначального сетевого
графика составляет Tкр= 50 недель.
.3 Квалификационный план
Технология применения сетевых методов планирования управления
процессом разработки системы предполагает составление квалификационного плана,
который определяет перечень необходимых специалистов и закрепляет за
работниками соответствующие функции.
Таблица 5.3 - Квалификационный план проекта разработки ИС
|
Наименование специалиста
|
Величина ставки (тыс руб./ нед.
|
Ответственность в процессе разработки
|
Выполняемые функции
|
|
Менеджер проекта
|
8,75
|
Принимает систему внутри фирмы
|
Разрабатывает требования к системе и концепцию.
Рецензирует функциональные требования, план проекта, типовые настройки
системы и архитектуру и глоссарий.
|
|
Менеджер программы
|
8
|
Управление ходом работы
|
Разрабатывает план проекта, журнал хода проекта
и глоссарий. Рецензирует требования к ИС, концепцию ИС, типовые настройки,
архитектуру системы, технический и рабочий проект
|
|
Тестер (рецензент)
|
3,75
|
Тестирует рабочую программу
|
Разрабатывает типовые настройки системы.
|
|
Системный аналитик
|
5
|
Разработка архитектуры системы
|
Разрабатывает систему и ее компоненты.
(Диаграммы на этапах разработки, технического рабочего проекта)
|
|
Программист (3 человека)
|
3,75
|
Программирует компоненты системы
|
Пишет код. Рецензирует глоссарий, требования к
системе, концепцию и типовые настройки.
|
|
Разработчик БД
|
3,75
|
Разрабатывает БД
|
Разрабатывает схему хранения данных. Определяет
процедуры обработки информации. Настраивает сервер БД
|
|
Сервис-нженер
|
3,50
|
Настройка системы
|
Установка системы. Конфигурирование модулей и
компонентов системы. Выезд на места обслуживания в течении срока гарантийного
обслуживания.
|
5.4 Оптимизация исходного сетевого плана
Распределение финансовых ресурсов на выполнение отдельных
видов работ сетевого графика целесообразно произвести в соответствии с размером
оплаты труда задействованных специалистов. При проведении оптимизации исходного
сетевого плана по времени выполнения работ были объединены стадии «Получение
технического проекта АС» и «Получение реализованной системы, рабочей
документации на неё» в одну стадию «Получение технорабочего проекта».
Условные обозначения событий:
. Получение заказа от заказчика на разработку АС.
. Получение отчёта о результатах обследования.
. Получение отчёта с обоснованием выбора концепции
разрабатываемой АС.
. Получение технического задания на создание АС.
5. Получение эскизного проекта АС.
. Получение технорабочего проекта.
. Получение внедрённой настроенной
системы.
. Выполненные гарантийные обязательства.
Рисунок 5.4 - Скорректированный сетевой план
На стадиях разработки, некоторые отдельные работы выгодно
выполнять параллельно.
. Получение заказа от заказчика на разработку АС.
. Получение отчёта о результатах обследования.
. Получение отчёта с обоснованием выбора концепции
разрабатываемой АС.
. Получение технического задания на создание АС.
. Получение эскизного проекта АС.
. Диаграмма иерархии функций;
. Диаграмма потоков данных;
. Диаграмма сущность-связь;
. Спроектированная база данных;
. Получение программного продукта.
. Получение протестированного программного продукта.
. Получение реализованной системы.
. Получение внедрённой настроенной системы.
. Выполненные гарантийные обязательства.
Планируется параллельное выполнение работ на стадии
«Получение технорабочего проекта»
Рисунок 5.5 - Сетевой график
-2. Формирование требований к АС
-3. Формирование концепции АС
-4. Составление ТЗ
-5. Составление эскизного проекта.
-6. Разработка диаграммы иерархий функций.
-7. Разработка диаграммы потоков данных.
-8. Разработка диаграммы сущность-связь
-9. Проектирование базы данных системы
-10. Написание программного кода.
-11. Тестирование программы.
-12. Составление рабочей документации системы.
-13. Внедрение разработанной системы.
-14. Сопровождение системы.
5.4 Разработка плана контрольных мероприятий
Дата начала проектных работ в соответствии с составленным
техническим заданием 01.09.2009 г. Исходный план контрольных мероприятий при
выполнении проектных работ представлен в Таблице 5.6.
Таблица 5.6 - План контрольных мероприятий
|
Дата
|
Наименование контрольного мероприятия
|
|
01.09.2009
|
Получение заказа на разработку
|
|
28.09.2009
|
Сдача ТЗ
|
|
09.12.2009
|
Сдача технорабочего проекта
|
|
14.12.2009
|
Внедрение системы на предприятии
|
|
21.12.2009
|
Подписание акта сдачи-приемки выполненных работ
|
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 - Декомпозиция процесса «Сформировать регламент»
.3 Диаграмма потоков данных
Миниспецификация, словарь данных и DFD модель
Использование DFD-технологии позволяет
продемонстрировать, как каждый процесс преобразует свои входные данные в
выходные, а также выявить отношения между этими процессами.
На рис. 6.3.1 - 6.3.3 представлены DFD-модели последовательно
разработанные в AllFusion Process Modeler.. Провести соревнование - общая функция.
Заявка на участие - входная (внешняя) информация,
представленная в виде документа (заявочного листа).
Информация об участнике - входная (внешняя) информация,
представленная в виде документа с информацией о команде и её составе.
Информация о судьях - внешняя информация от сторонних
судейских организаций, которые выполняют какие-либо работы в рамках процессов
по проведению соревнований.
Информация о мед. персонале - внешняя информация от сторонних
медицинских организаций, которые выполняют какие-либо работы в рамках процессов
по проведению соревнований.
Информация о местах проведения игр - внешняя информация от
сторонних организаций, являющихся арендодателями спортивной инфраструктуры.
Информация о соревновании - информация о проводящихся
соревнованиях.
Законодательство РФ - законодательство Российской Федерации,
как федеральное, так и местное.
Правила судейства - официальные правила судейства в
определенном виде спорта.
Расписание - документ, содержащий расписание проведения игр
соревнования.
Регламент - документ, содержащий условия проведения
соревнования.
Статистика соревнований - информация о ходе проведения
соревнований.
Спецификации процесса
Спецификации процесса «Провести соревнование»:
ПРОЦЕСС: Провести соревнование
ВХОД: Заявка на участие; Информация об участнике; Информация
о судьях; Информация о мед. персонале; Информация о местах проведения игр;
Информация о соревновании; Правила судейства; Законодательство РФ.
ВЫХОД: Расписание; Регламент; Статистика соревнований.
ПОДПРОЦЕССЫ:
А1. Составить регламент соревнований
А2. Зарегистрировать участника
А3. Составить расписание
А4. Передать расписание и регламент участникам
А5. Провести часть соревнований
А6. Вести статистику
Рисунок 6.3.1 - DFD Провести соревнование
Спецификация микропроцессов верхнего уровня имеет следующий
вид:
Рисунок 6.3.2 - DFD Микропроцессы верхнего уровня
Рисунок 6.3.3 - DFD Составить регламент соревнований
Спецификация микропроцессов верхнего уровня имеет следующий
вид:
A0. Провести соревнование
ПРОЦЕСС: Составить регламент соревнований
ВХОД: Информация о судьях; Информация о мед. персонале;
Информация о местах проведения игр; Законодательство;
ВЫХОД: Договоры об организации соревнований; Регламент;
ПОДПРОЦЕССЫ:
- Выбрать места проведения игр
- Заключить договора с арендодателями
- Выбор мед. персонала и заключение с ним
договоров
- Выбор судей и заключение с ними договоров
- Выбрать схему проведения игр
- Выбрать критерии начисления очков в
отдельном матче
- Определить критерии распределения команд
по местам
ПРОЦЕСС: Зарегистрировать участника
ВХОД: Заявка на участие; Информация об участнике.
ВЫХОД: Зарегистрированный участник;
ПОДПРОЦЕССЫ:
- Принять заявку
- Зарегистрировать заявку
ПРОЦЕСС: Составить расписание
ВХОД: Участники соревнований; Регламент;
ВЫХОД: Расписание;
ПОДПРОЦЕССЫ:
- Анализировать данные
- Оформить расписание
ПРОЦЕСС: Передать расписание и регламент участникам
ВХОД: Расписание; Регламент;
ВЫХОД: Расписание; Регламент;
ПОДПРОЦЕССЫ:
- Передать расписание и регламент командам
- Передать расписание и регламент судьям
- Передать расписание и регламент мед.
персоналу
- Передать расписание и регламент
арендодателям мест проведения
ПРОЦЕСС: Провести часть соревнований
ВХОД: Информация о проведении игр; Правила судейства;
ВЫХОД: Протокол игр;
ПОДПРОЦЕССЫ:
- Оформить протокол на игру;
- Оформить статистические данные игры;
- Передать протоколы игр и статистические
данные на обработку;
ПРОЦЕСС: Вести статистику
ВХОД: Протоколы игр; Статистические данные;
ВЫХОД: Статистика команд; Статистка игр; Статистика
участников;
ПОДПРОЦЕССЫ:
- Принять протоколы игр;
- Обработать протоколы и статистические
данные;
.4 Модель данных
Выбор СУБД:
Таблица 6.4 - Сравнение СУБД
|
Критерии
|
MySQL
|
PostgreSQL
|
Oracle
|
MS SQL Server
|
|
Размер базы данных
|
гигабайты
|
гигабайты
|
гигабайты
|
гигабайты
|
|
Количество одновременных пользователей
|
сотни пользователей
|
сотни пользователей
|
тысячи пользователей
|
тысячи пользователей
|
|
Цена базы данных
|
полностью бесплатно
|
полностью бесплатно
|
дорогие
|
дорогие
|
|
Платформа
|
Windows+Linux
|
Unix/Linux only
|
Windows+Linux
|
Windows only
|
|
Тип программы
|
маленький web сервер
|
маленький web сервер
|
мощный web сервер
|
мощный web сервер
|
|
Мощность языка SQL
|
слабые
|
развитые
|
мощные
|
мощные
|
|
Стоимость программистов и администраторов
|
небольшая
|
небольшая
|
высокая и очень высокая
|
высокая и очень высокая
|
|
Защита данных
|
сильная
|
сильная
|
сильная
|
сильная
|
Для проектирования АС для проведения спортивных соревнований
более подходящим является MySQL. Данная СУБД удовлетворяет основным требованиям
- является бесплатной, работает на платформах Windows и Linux, позволяет
осуществлять работу с сотнями пользователей, одновременно использующих систему.
В предметной области можно выделить следующие
сущности:(соревнование) - основная сущность предметной области.(организатор
соревнования) - организация, которая проводит соревнование.(мед. персонал) -
мед. прсонл, обслуживающий соревнование.(судья) - судьи, обслуживающие
соревнование.(группа) - группы, лиги, т.е. различные зоны на которые разбиты
соревнование.(команда) - команды участвующие в соревновании.(состав команды) -
состав команд, участвующих в соревновании(игра) - игры, проводимого
турнира(протокол игры) - результаты отдельных игр.(место проведения игры) -
спортивные объекты, на которых проходят игры.(регламент) - условия и правила,
по которым проходят соревнования.
Рис. 6.4.1 - Логическая модель данных
Также была сформирована физическая модель данных (Рис.
6.4.2), по которой был сформирован скрипт создания базы данных.
Рис. 6.4.2 - Физическая модель данных
После анализа предметной области и выделения основных
сущностей была составлена физическая схема БД. Сущности Organizer (организатор
соревнования), MedPersonnel (мед. персонал) и Referi (судья) были объединены в
одну таблицу User - совокупность всех людей, участвующих в проведении
соревнования. Сущность Regulation (регламент) разделена на отдельные таблицы:
PointGame - правила начисления баллов в отельном матче, RankComammand - схема
распределения команд по местам, SchemeGame - схема проведения соревнования.
Добавлены таблицы DateGame - содержащая информацию о дате и времени каждой игры
и таблица Group_Location - для организации связи «многие ко многим».
7. Оценка надежности проектируемой системы
.1 Физическая архитектура
Проектируемая система является клиент-серверным приложением
(Рис. 7.1). Главным звеном в данной системе является сервер, на котором будет
располагаться данная система и от его работы зависит всё её функционирование.
Поэтому нужно рассматривать надёжность сервера, а не
клиентских компьютеров. Все расчёты надёжности будут производится для серверной
части системы и линий связи.
.2 Расчёт надёжности
Расчёт надёжности необходимо производить при следующих
заданных условиях:
) оценка надежности проектируемой системы
осуществляется за период работы 500 часов;
) вероятность безотказной работы (Pз) системы должна быть не
менее 0,985;
Система состоит из четырех последовательно включенных узлов:
Таблица 7.2 - Интенсивности отказов элементов системы
|
Устройство
|
Интенсивность отказов, λ(t)*10-4 1/час,
|
|
Модем
|
0,10
|
|
Процессор
|
1,00
|
|
Память
|
1,00
|
|
Линии связи
|
0,10
|
|
Интенсивность отказа всей системы
|
2,2
|
Схема соединения элементов системы
Все расчёты надёжности будут производится для серверной части
системы и линий связи.
Интенсивность отказов системы:
λ0=2,2*10-4
1/час
Вероятность исправной работы системы:
1(t)=e
-λ0*500=0,89500
Вероятность отказов системы:
1(t)=1
- P1(t)
1(t)=1-0.8950=0.10500
Частота отказов системы:
α 1(t)= λ0* P1(t)
α 1(t)= 2,2*10-4*0,8950=0,00022
Средняя наработка системы на отказ:
То1= 1/ λ0
То1=1/2,2*10-4 1/час = 4545 часов.
Резервирование
В результате расчетов вероятность исправной работы системы
равна 0,8950. По условию вероятность безотказной работы системы за 500 часов
должна быть не менее 0,9850. Следовательно, полученная вероятность не
удовлетворяет условию. В целях повышения надежности системы необходимо
применить резервирование.
Общее резервирование
1) Постоянное резервирование:
р(t)=1 - (1-e -λt)m+1р(t)=1
- (Q1(t)) m+1=1-0,01100=0,98890
Тор=То
=То1(1+0,50000)=6817
часов.
) Резервирование замещением
Облегченный режи:
λ0> λ1
;
λ0= 2,2000*10-4 1/час
λ1=1,6000*10-4 1/час(t)= 0,89500
[1+1,37500*(1-0,92311)]=0,98962
T=(1/ λ0)
; k=
λ1/λ0
Т=7176 часов
Нагруженный режим:
λ0= λ1
P(t)= 1 - [1-P1(t)]2=0,9889
Т=6817 часов
Не нагруженный режим:
λ1= 0
P(t)= e - λ0t
= 0,89500
(1+0,11000)=0.9934
T=(m+1)/ λ0=2/ 0,00022=9090 часов
Поэлементное резервирование
Вероятность безотказной работы за время t = 500 ч при
поэлементном нагруженном резервировании всех элементов сервера.
п(t)=
- [1-e-λit]m+1}
п(t)=(1-0,00237)2*(1-0,00002)2=0,99995*0,99525=0,99519
Комбинированное резервирование
m=1
Резервирование линий связи или модема:
λлинии связи = λмодем =0,1*10-4 1/час
(t) секции=1 - [1 - e-λлсt]m+1
P(t) секции= 0,99997
линий связи(t)=Pмодем(t)= e -λм*500= 0,99501процессор(t)= Pпамять(t)=
e -λпр*500= 0,95122
(t)= 0,99997*0,99501*0,951222=0,90029
Резервирование процессора или памяти:
λпроцессор = λпамять =1,0*10-4 1/час(t) секции=1 - [1 - e-λпрt]m+1
(t) секции= 0,99762
памятим(t)= Pпроцессор(t)= e -λпм*500= 0,95122линий связи(t)=Pмодем(t)=
e -λм*500= 0,99501
(t)= 0, 99762*0,95122*0,99501=0,939525
Резервирование двух элементов:
процессор(t) секции= Pпамять(t)
секции =1 - [1 - e-λt]m+1=0,99762линий
связи(t)= Pмодема(t)= e
-λм*500= 0,99501
к3(t)= 0,99762*0,99762*0,99501*0,99501=0,98534
Резервирование двух элементов в нагруженном режиме:
процессор(t)= Pпамять(t)= 1 - [1-P1(t)]2=1
- (1 - 0,95122)2=0,9976
(t)= 0,9976*0,9976*0,99501*0,99501=0,9853
Резервирование двух элементов в ненагруженном режиме:
процессор(t)= Pпамять(t)= e - λпрt
= 0,95122 (1+0,05)=0,99878
(t)= 0,998782*0,995012=0,9876
Наиболее подходящим является резервирование двух элементов -
процессора и памяти в нагруженном режиме, так как вероятность безотказной
работы в данном случае наиболее точно удовлетворяет заданным требованиям по
надежности. А так же резервирование данных элементов наиболее актуально, так
как они являются ключевыми в схеме соединения элементов системы.
8. Определение требуемых вычислительных ресурсов
.1 Расчет производительности процессора
информационный
интерфейс пользователь
Жесткий диск сервера пополняется информацией о результатах
соревнования. Перед началом соревнований на жесткий диск записываются данные о
командах, и составляется расписание игр. Помимо вышеперечисленной информации в
БД на жестком диске также хранятся данные которые не изменяются в течении
проведения соревнований. Данные из этих таблиц незначительны по объему. К такой
информации относятся: Информация об организаторах, судьях, мед. персонале, а
так о регламенте проведения игр.
Таблица 8.1 - Характеристики выполняемых задач
|
№
|
Наименование задачи
|
Входные данные
|
Выходные данные
|
Объем входной информации,  , битОбъем выходной
информации,  , битЧисло операций (N2)
|
|
|
|
1
|
Зарегистрировать участника
|
Информация о командах и их составе
|
Записи в таблицах Command и Composition
|
3 500
|
4 200
|
1,5 * 104
|
|
2
|
Составить расписание
|
Зарегистрированные каманды, места проведения,
регламент соревнований
|
Расписание (Записи в таблице Game)
|
11 300
|
800 000
|
37,2 * 104
|
|
3
|
Вести статистику
|
Результаты игр (протаколы матчей)
|
Записи в таблицах Command, Game
|
4 400
|
5 100
|
2,35 * 104
|
Задачи данной системы условно можно отнести к следующему
классу: моделирование, планирование, научные и оптимизационные задачи.
Для расчета требуемой производительности вычислителя,
выполняющего определенные классы задач, необходимо определить значения
параметров:i - средняя длительность задачи в машинных операцияхi
- средний объем вводимого сообщенияi - средняя длина выходного
сообщенияi - среднее число запросов задач формируемых в системе в
течении сутокi - среднее число обращений к вводу-выводу при
обработке запроса
di - вид обработки информации
Таблица 8.2 - Исходные данные для расчета производительности
вычислителя
|
Тип задачи
|
Vi
|
Qi, бит
|
Wi, бит
|
mi
|
Ki
|
di
|
|
моделирование, планирование, научные и
оптимизационные задачи
|
13,68 * 104
|
6 400
|
269 766
|
50
|
4
|
1
|
Таблица 8.3 - Значения параметров
|
№
|
Наименование параметра
|
Обозначение
|
Значение для сервера
|
Значение для терминала
|
|
1
|
Коэффициент неравномерности распределения
нагрузки по суткам месяца
|
Kн
|
1,4
|
1,4
|
|
2
|
Коэффициент запаса производительности на
развитие задач пользователя
|
Kр
|
1,2
|
1,2
|
|
3
|
Коэффициент перевода часов в секунды
|
Q
|
3600
|
3600
|
|
4
|
Коэффициент, учитывающий наличие процессора
телеобработки (1-есть, 0-нет)
|
s
|
0
|
1
|
|
5
|
Среднее количество операций необходимое для
организации приема и выдачи одного алфавитно- цифрового сообщения
|
g1 g2
|
20 100
|
20 100
|
|
6
|
Фонд рабочего времени ЭВМ в течении суток
|
Тф
|
24
|
3
|
|
7
|
Среднее время технического обслуживания ЭВМ с
учетом затрат на проведение работ обслуживания
|
Тто
|
2
|
2
|
|
8
|
Средняя наработка на отказ
|
То
|
4545
|
1136
|
|
9
|
Среднее время восстановления
|
Тв
|
0,6
|
0,6
|
|
10
|
Наработка ЭВМ на сбой
|
Тсб
|
12
|
10
|
|
11
|
Среднее время восстановления после сбоя
|
Тврсб = 0.1Тв
|
0,06
|
0,06
|
|
12
|
Среднесуточное время потерь из-за ошибок
оператора
|
Тп = 0,05 Тф
|
0,4
|
0,4
|
|
13
|
Период функционирования систем диалогового
режима в течении суток
|
Т
|
8
|
4
|
|
14
|
Число типов задач
|
n
|
1
|
1
|
|
15
|
Число терминалов часов при выполнении работ
i-типа (только для терминала) равно фонду рабочего времени
|
ri
|
8
|
8
|
|
16
|
Удельная нагрузка создаваемая пользователем на
сервер (операций/с)
|
ni(z) li(z)
|
109 7*108
|
5*108 15*107
|
|
17
|
Вид обработки
|
di
|
1
|
0
|
|
18
|
Число классов работ выполняемых в диалоговом
режиме - работа с БД
|
b
|
1
|
1
|
Для терминала:
Время полезной работы вычислителя в течении суток:
Тпр = 0,594 ч
Производительность процессора:
Pп = 383284 оп/с
Для сервера:
Время полезной работы вычислителя в течении суток:
Тпр = 21,487 ч
Производительность процессора:
п = 134337312
оп/с
Производительность процессора для обслуживания терминалов в
диалоговом режиме:
g =
803435002 оп/с
Требуемая производительность процессора:
тр= 1418373430 оп/с
Таким образом, для выполнения задач необходим процессор с
тактовой частотой 1,4 ГГц, без учёта необходимой производительности для
стабильной работы операционной системы, прикладного программного обеспечения и
других программных средств.
.2 Расчет требуемой оперативной памяти
Требуемый объем оперативной памяти (в битах) для
функционирования разрабатываемого программного приложения определяется
следующим образом:
Суммарный объем входной информации:вх = 19200 бит
Суммарный объем выходной информации:вых = 809300 бит
Определим общий суммарный поток входной и выходной информации:
η2*= Uвх + Uвых
η2* = 828500 бит
Количество операндов, приходящихся на один оператор программы: α
= 0,93
Определим число простых операндов в программе:
η2 = 6 * η2*
η2 = 4971000
Определим количество команд в программе:
P = 2,5* η2
P = 12427500
Определим длину программы:
N = 8/3 * Р
N= 33140000
= N1+ N2
N1 - число операторов; N2 - число операндов
N2 =
α/(α+1)*N =15969015
N1 = 17170985
Число простых операторов η1 в программе определяется
как:
2
η1=N2/(α* η1)
Используя метод подбора, определили значения η1.
Определяем объем программы в битах по следующей формуле:
Таблица 8.4 - Объем программы
|
η1
|
отношения
|
V, бит
|
V, Мб
|
|
1547300
|
18,73024546
|
1756512546
|
209,3926912
|
Таким образом, оперативная память необходимая для нормальной
работы системы составляет 210 МБ без учета памяти, которую могут занимать
другие приложения, например ОС.
Заключение
В результате проделанной работы была спроектирована
автоматизированная система для проведения спортивных соревнований.
Автоматизированная система разработана для организаций, занимающихся
проведением спортивных соревнований, и будет обеспечивать автоматизацию
основных бизнес-процессов данных организаций.
Сформулирован состав специалистов, необходимый для внедрения
системы, определены их функции, рассчитаны все предполагаемые затраты. Сетевой
план работ оптимизирован, выделены контрольные мероприятия для соблюдения
сроков поставленных работ, а так же определены технические требования.
Список используемых источников
1. Проектирование
информационных систем и технологий: Метод. указания к курсовому проектированию
/ сост. А.В. Костров, Р.И. Макаров - Владим. гос. ун-т. Владимир, 1999. 12 с.
2. Проектирование
информационных систем: Методические указания к практическим занятиям / сост.
Р.И. Макаров, В.И. Мазанова - Владим. гос. ун-т. Владимир, 2008. 152 с.
. Макаров
Р.И. Методология проектирования информационных систем: Учебное пособие -
Владим. гос. ун-т. Владимир, 2008. 152 с.
. Калянов
Г.Н. CASE-технологии: Консалтинг в автоматизации бизнес-процессов. 3-е изд.
- М.: Горячая линия - Телеком, 2002. - 320 с.
. Фаулер
М. UML. Основы. Краткое
руководство по унифицированному языку моделирования. 2-е издание / М. Фаулер,
К. Скотт. - М.: Символ-Плюс, 2002. - 192 с. ISBN 5-93286-032-4
Приложение
Скрипт базы данных
CREATE TABLE Command
(INTEGER NOT NULL,INTEGER NULL,CHAR(30)
NULL,CHAR(18) NULL,CHAR(18) NULL,TEXT NULL,INTEGER NULL,INTEGER NULL,INTEGER
NULL,INTEGER NULL,INTEGER NULL,INTEGER NULL,INTEGER NULL
);
UNIQUE INDEX XPKCommand ON Command
(
);
TABLE CommandPRIMARY KEY (commandId);
TABLE Competition
(INTEGER NOT NULL,CHAR(100) NULL,TEXT NULL
);
UNIQUE INDEX XPKCompetition ON Competition
(
);
TABLE CompetitionPRIMARY KEY (competitionId);
TABLE Composition
(INTEGER NOT NULL,INTEGER NULL,CHAR(50) NULL,DATE
NULL,INTEGER NULL,INTEGER NULL
);
UNIQUE INDEX XPKComposition ON Composition
(
);
TABLE CompositionPRIMARY KEY (compositionId);
TABLE DateGame
(INTEGER NOT NULL,INTEGER NULL,CHAR(18) NULL,TIME
NULL
);
UNIQUE INDEX XPKDateGame ON DateGame
(
);
TABLE DateGamePRIMARY KEY (dateId);
TABLE Game
(INTEGER NOT NULL,INTEGER NULL,INTEGER
NULL,INTEGER NULL,INTEGER NULL,INTEGER NULL,INTEGER NULL
);
UNIQUE INDEX XPKGame ON Game
(
);
TABLE GamePRIMARY KEY (gameId);
TABLE Group
(INTEGER NOT NULL,INTEGER NULL,INTEGER NULL,INTEGER
NULL,CHAR(30) NULL,TEXT NULL
);
UNIQUE INDEX XPKGroup ON Group
(
);
TABLE GroupPRIMARY KEY (groupId);
TABLE Group_Location
(INTEGER NOT NULL,INTEGER NULL,INTEGER NULL
);
UNIQUE INDEX XPKGroup_Location ON Group_Location
(
);
TABLE Group_LocationPRIMARY KEY (id);
TABLE LocationGame
(INTEGER NOT NULL,CHAR(18) NULL
);
UNIQUE INDEX XPKLocationGame ON LocationGame
(
);
TABLE LocationGamePRIMARY KEY (locationId);
(INTEGER NULL,INTEGER NOT NULL
);
CREATE UNIQUE INDEX XPKPointGame ON PointGame
(
);
TABLE PointGamePRIMARY KEY (pointId);
TABLE ProtakolGame
(INTEGER NOT NULL,INTEGER NULL,INTEGER NULL
);
UNIQUE INDEX XPKProtakolGame ON ProtakolGame
(
);
TABLE ProtakolGamePRIMARY KEY (protakolId);
TABLE RankCommand
(INTEGER NOT NULL,CHAR(100) NULL,TEXT NULL
);
CREATE UNIQUE INDEX XPKRankCommand ON RankCommand
(
);
TABLE RankCommandPRIMARY KEY (rankId);
TABLE SchemeGame
(INTEGER NOT NULL,CHAR(18) NULL,TEXT NULL
);
UNIQUE INDEX XPKSchemeGame ON SchemeGame
(
);
TABLE SchemeGamePRIMARY KEY (schemeId);
TABLE User
(CHAR(18) NULL,INTEGER NULL,INTEGER NOT
NULL,CHAR(18) NULL
);UNIQUE INDEX XPKUser ON User
(
);
TABLE UserPRIMARY KEY (userId);
TABLE CommandFOREIGN KEY R_16 (groupId)
REFERENCES Group (groupId);
TABLE CompositionFOREIGN KEY R_36 (commandId)
REFERENCES Command (commandId);
TABLE DateGameFOREIGN KEY R_26 (groupId)
REFERENCES Group (groupId);
TABLE GameFOREIGN KEY R_30 (commandId) REFERENCES
Command (commandId);
TABLE GameFOREIGN KEY R_31 (locationId)
REFERENCES LocationGame (locationId);
TABLE GameFOREIGN KEY R_32 (dateId) REFERENCES
DateGame (dateId);
TABLE GameFOREIGN KEY R_34 (protakolId)
REFERENCES ProtakolGame (protakolId);
TABLE GroupFOREIGN KEY R_14 (competitionId)
REFERENCES Competition (competitionId);
TABLE GroupFOREIGN KEY R_19 (rankId) REFERENCES
RankCommand (rankId);
TABLE GroupFOREIGN KEY R_23 (schemeId) REFERENCES
SchemeGame (schemeId);
TABLE Group_LocationFOREIGN KEY R_38 (groupId)
REFERENCES Group (groupId);
TABLE Group_LocationFOREIGN KEY R_39 (locationId)
REFERENCES LocationGame (locationId);
TABLE PointGameFOREIGN KEY R_24 (competitionId)
REFERENCES Competition (competitionId);
TABLE ProtakolGameFOREIGN KEY R_37
(compositionId) REFERENCES Composition (compositionId);
ALTER TABLE UserFOREIGN KEY R_41 (competitionId)
REFERENCES Competition (competitionId);