Диаграмма последовательности системы. Методология IDEF3

 

IDEF3 - методология моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. Цель IDEF3 - дать аналитикам описание последовательности выполнения процессов, а также объектов, участвующих совместно в одном процессе.[2]

На диаграмме последовательности (Приложение E рисунок E1) рассматривается процесс организации проведения турнира.

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

 

3.5 С – требования

 

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

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

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

1. Администратору системы:

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

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

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

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

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

· Система должна предоставлять возможность автоматического вычисления статистики по соревнованию (по его завершению соответственно);

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

· Система должна предоставлять возможность изменять права доступа любого пользователя в системе;

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

2. Участнику турнира:

· Система должна предоставлять возможность быстрой и удобной регистрации/авторизации в системе;

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

· Система должна предоставлять возможность записываться на необходимый турнир и в дальнейшем участвовать в нем;

· Система должна предоставлять возможность просматривать предварительные результаты и конечные (по завершению турнира);

· Система должна предоставлять возможность просматривать архив прошедших турниров и их результатов (список участников и занятых ими мест);

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

Для выражения взаимодействия приложения с внешним пользователем воспользуемся диаграммами вариантов использования (Use Case) UML. [10] Общая схема Use Case представлена в приложении J на рисунке J1.

1. Варианты использования для актера «Участник» представлены на рисунке 7:

 

Рисунок 7. Варианты использования для актера «Пользователь»

 

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

2. Варианты использования для актера «Администратор» представлены на рисунке 8.

Рисунок 8. Варианты использования для актера «Администратор»

 

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

3.6 D – требования

 

Разработчикам программного обеспечения нужна база для проектирования и разработки. Эта база представляет собой детальные требования (D – требования). D – требования состоят из полного списка конкретных свойств и функциональности, которую должна иметь программа. D – требования должны быть согласованы с С – требованиями. [2]

Существует несколько типов D – требований:

1) Функциональные требования.

Функциональные требования определяют работы, которые должна выполнять проектируемая система. Согласно проведенному обследованию к ним относятся все функции, описанные в пункте 3.5 «C – требования».

2) Нефункциональные требования. [2]

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

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

· Надежность и безопасность. Требования надежности определяют надежность в измеряемых величинах. Для решения вопроса обеспечения безопасности системы, связанного с несанкционированным доступом в систему, должна быть предусмотрена предварительная идентификация пользователей перед началом работы, посредством ввода личного логина и пароля. Также необходимо, чтобы клиент - серверное приложение удерживало 100 запросов в секунду и функционировало 24 часа в сутки.

· Обработка ошибок. Система должна проверять корректность введенных пользователем данных. На всех формах две проверки " клиентская" (написанная на Javascript) и " серверная" на уровне приложения. В случае возникновения ошибки выдавать соответствующее информационное сообщение. Также, дополнительно, необходимо использовать триггеры в БД.

· Интерфейсные требования. Создать панель администрирования для удобного управления.

· Ограничения. Не обозначены.

3) Обратные требования. [2]

Обратные требования – это тот функционал, который система не обеспечивает.

К данным требованиям относятся:

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

 

3.7 Оценка затрат и предварительный расчет ожидаемой эффективности АСОИУ. Методология DFD: TO - BE

 

Для оценки затрат и предварительного расчета ожидаемой эффективности АСОИУ точно также воспользуемся методологией оценивания функционального размера, которая заключается в единообразном измерении всех возможностей приложения и выражении размера приложения в виде одного числа. [2] Было принято решение отталкиваться от внешних хранилищ данных, так как в процессе создания диаграммы потоков данных по методологии DFD (TO - BE) их количество уменьшилось.

Информационные характеристики и их ранг представлены в таблице 7.

 

Таблица 7. Информационные характеристики и их ранг

Хранилища	Информационная характеристика	Ссылки	Элементы данных	Ранг
Текущий турнир	Внут. лог. файл			Средний (10)
Текущий турнир	Внешний ввод			Высокий (6)
Текущий турнир	Внешний вывод			Средний (5)
Текущий турнир	Внешний запрос			Высокий (6)
Жалобы	Внут. лог. файл			Низкий (7)
Жалобы	Внешний ввод			Низкий (3)
Жалобы	Внешний вывод			Низкий (4)
Участники турнира	Внут. лог. файл			Низкий (7)
Участники турнира	Внешний ввод			Высокий (6)
Участники турнира	Внешний вывод			Средний (5)
Участники турнира	Внешний запрос			Низкий (3)
Список вопросов, ответов турнира	Внут. лог. файл			Низкий (7)
Список вопросов, ответов турнира	Внешний ввод			Низкий (3)
Список вопросов, ответов турнира	Внешний вывод			Средний (5)

 

Перейдем к расчету метрики — количества функциональных указателей FP. В таблицу 8 заносятся количественное значение характеристики каждого вида (по всем уровням сложности). Полученные в каждой характеристике значения суммируются, после чего формируется общее количество информационных характеристик. [2]

 

Таблица 8. Исходные данные для расчета FP – метрик

Имя характеристики	Количество
Низкий	Средний	Высокий	Итого
Внешние вводы	2 * 3 = 6	0 * 4 = 0	2 * 6 = 12
Внешние выводы	1 * 4 = 4	3 * 5 = 15	0 * 7 = 0
Внешние запросы	1 * 3 = 3	0 * 4 = 0	1 * 6 = 6
Внутренние логические файлы	3 * 7 = 21	1 * 10 = 10	0 * 15 = 0
Внешние интерфейсные файлы	0 * 5 = 0	0 * 7 = 0	0 * 10 = 0
Общее количество:

 

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

FP = Общее количество × (0, 65+ 0, 01 × ), (1)

где Fi – коэффициенты сложности. Каждый коэффициент может принимать следующие значения: 0 – нет влияния, 1 – случайное, 2 – небольшое, 3 – среднее, 4 – важное, 5 – основное.

Значение каждого – ого коэффициента определяется эмпирически в результате ответа на 14 вопросов, которые характеризуют системные параметры приложения (см. таблицу 9).

 

Таблица 9. Определение системных параметров приложения

№	Системный параметр	Значение
	Передача данных
	Распределенная обработка данных
	Производительность
	Распространенность используемой конфигурации
	Скорость транзакций
	Оперативный ввод данных
	Эффективность работы конечного пользователя
	Оперативное обновление
	Сложность обработки
	Повторная используемость
	Легкость инсталляции
	Легкость эксплуатации
	Разнообразные условия размещения
	Гибкость
Итого:

 

Подставив значения из таблицы 8 в формулу 1, получим количество функциональных указателей:

FP = 77 × (0, 65+ 0, 01 × 43) = 83, 16, (2)

Подсчитаем количество строк для языка C#. Для этого количество функциональных указателей умножим на количество операторов языка C# на один FP, которое равно 53.

(3)

Для оценивания затрат труда и продолжительности проекта необходимо использовать конструктивную модель стоимости СОСОМО Барри Боэма. [2]

Подмодели СОСОМО могут применяться к трем типам программных проектов. В нашем случае ведётся разработка распространённого типа программного проекта. Уравнения базовой подмодели COCOMO имеют вид:

Е = [чел - мес]; (4)

D = [мес], (5)

где Е – затраты в человеко - месяцах, D – время разработки, KLOC – количество тысяч строк в программном продукте.

Коэффициенты а, b, с, d определяются по таблице 10.

 

Таблица 10 – Коэффициенты для базовой подмодели COCOMO

Тип проекта	а	b	c	d
Распространенный	2, 4	1, 05	2, 5	0, 38
Полунезависимый	3, 0	1, 12	2, 5	0, 35
Встроенный	3, 6	1, 20	2, 5	0, 32

 

Подставив коэффициенты a, b, c и d для распространенного типа проекта в формулы 4 и 5 получим:

[чел/мес]

[мес] 6 месяцев и 9 дней

Полученные оценки позволят скорректировать сроки выполнения проекта.

 

⇐ Предыдущая12345Следующая ⇒

Поделиться: