Курсовая работа: Информационная система управления безопасностью в программах IBM Rathional
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
Факультет экономики и менеджмента
Кафедра прикладной математики и эконометрики
Пояснительная записка к курсовой работе
по дисциплине
Проектирование информационных систем
Информационная система управления безопасностью в программах IBM Rathional
САМАРА, 2009
Оглавление
Введение
Постановка задачи
Анализ требований
Глоссарий
Диаграмма вариантов использования
Спецификации вариантов использования (Сценарий)
Матрица требований
Диаграмма действий
Проектирование
3.1 Диаграмма классов
3.2 Диаграмма последовательности действий
3.3 Диаграмма состояний объекта «пользователь»
3.4 Диаграмма внедрения
3.5 Проектирование базы данных
3.6 Пользовательский интерфейс
Оценка трудоемкости
4.1 Определение трудовых показателей действующих лиц
Определение весовых показателей вариантов использования
Определение технической сложности проекта
Определение уровня квалификации разработчиков
Оценка трудоемкости проекта
Заключение
Список литературы
Введение
В настоящее время приобретает большую значимость процесс компьютеризации всех видов деятельности человечества: от традиционных интеллектуальных задач научного характера до автоматизации производственной, торговой, коммерческой, банковской и других видов деятельности.
Этой всеобщей тенденции способствовали такие факторы, как появление и массовое применение персональных компьютеров, а также средств телекоммуникаций и вычислительных сетей, в том числе сети Интернет. Эти факторы сделали актуальной проблему развития и эффективного использования информационных ресурсов – как локальных, в рамках одного предприятия, так и глобальных, в рамках нескольких предприятий. Стало ясно, что устоять в конкурентной борьбе смогут только те предприятия, которые будут применять в своей деятельности современные информационные технологии (ИТ). Именно ИТ, наряду с прогрессивными технологиями материального производства, позволяют существенно повысить производительность труда и качество выпускаемой продукции одновременно со значительным сокращением сроков постановки на производство и выпуска новых, более совершенных изделий, отвечающих запросам и ожиданиям потребителей.
Процесс информатизации управления на предприятиях с использованием современных компьютерных технологий идет нарастающими темпами. Предприятие тратит огромные деньги на технику, программное обеспечение, оплату поставщиков готовых решений и услуг системных интеграторов. Но взамен, как правило, получает лишь ускорение документирования различных бизнес-процедур. Причина кроется в отсутствии системного подхода при создании информационных управленческих систем. Системный же подход требует осознания руководством целей информатизации и средств их достижения.
На сегодняшний день внедрение современных методов управления с использование ИТ является очень актуальной темой в связи с быстро развивающейся конъюнктурой рынка. Целью курсовой работы является закрепление и углубление знаний, полученных при изучении дисциплины, а также получение практических навыков при разработке проекта информационной системы управления безопасностью на основе новейших достижений науки и техники, используя при этом стандарты и справочные данные, ГОСТы и технические условия, каталоги изделий и др. информационные материалы.
1. Постановка задачи
Информационная система управления безопасностью
Главной задачей курсовой работы является построение целостной системы защиты автоматизированной информационной системы (АИС). Данная АИС осуществляет автоматизацию некоторого процесса обработки конфиденциальной информации, включая все аспекты этого процесса, связанные с обеспечением безопасности обрабатываемой информации, соответствует требованиям и критериям стандартов информационной безопасности. Разработаем проект системы обеспечения информационной безопасности, включающей системы защиты от несанкционированного доступа на автономных компьютерах и рабочих станциях в локальных вычислительных сетях, системы защиты от несанкционированного доступа из глобальных сетей общего пользования. Данная разработка предназначена для обеспечения безопасности информации в автоматизированной системе продаж. Данный программный продукт ориентирован на всех сотрудников магазина, работающих с автоматизированной системой. Так же данная система позволяет её администратору вести контроль всех действий пользователей.
В системе участвуют следующие лица: администратор системы, пользователь и сама система.
2. Разработка требований
2.1 Глоссарий
Администратор сети — сотрудник, отвечающий за работу компьютерной сети предприятия в штатном режиме
Пользователь — лицо или организация, которое использует действующую систему для выполнения конкретной функции
Доступ - метод, процесс или совокупность правил взаимодействия с сетью или системой с целью использования их ресурсов
Регистрация в системе - получение пароля и доступа пользователя к системе
Безопасность информации - средства аутентификации и управления доступом к ресурсам системы
Автоматизированная система продаж - система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций
Диаграмма вариантов использования для системы безопасности
Рисунок 2.1 Диаграмма Вариантов использования для системы «безопасность».
2.3 Спецификации вариантов использования (Сценарий)
Сценарий ВИ «вход в систему»:
Актёры: пользователь, администратор сети
Цель: войти пользователю в систему
Основной ход событий:
1.Пользователь/администратор запускает систему (вводит свой логин и пароль). Исключение№1:Логин или пароль пользователя/администратора неверный.
Исключение№1:Пользователь повторно пытается войти в систему или обращается к системному администратору/Сис.администратор взламывает систему для выяснения верного логина или пароля.
Сценарий ВИ «блокировка терминала»:
Актёры: Пользователь, системный администратор
Цель: заблокировать терминал
Основной ход событий:
1.Пользователь/администратор определенным сочетанием клавиш блокирует терминал, вследствие чего в системе запускается заставка с запросом пароля.
Сценарий ВИ «создание файлов»:
Актёры: пользователь
Цель: создать файлы для работы
Основной ход событий:
1.Пользователь в системе нажимает на кнопку «создать новый файл».
2.В системе автоматически создается чистый документ. Исключение№1: отказ в системе.
3.Пользователь назначает права доступа.
Исключение№1: вызвать системного администратора.
Сценарий ВИ «пометка документов на удаление»:
Актёры: пользователь
Цель: выделить ненужные файлы для удаления
Основной ход событий:
1.Пользователь при необходимости удаления ненужных файлов нажимает на кнопку «пометить на удаление». Исключение№1: пользователь пометил не тот файл.
2.Система автоматически отправляет помеченный файл в журнал, который после определенной очистки удаляется. Исключение№2: отказ в системе.
Исключение№1: Снять галочку с помеченного файла и выбрать нужный файл.
Исключение№2: Отправить уведомление на восстановление файлов для системного администратора.
Сценарий ВИ «добавление пользователя»:
Актёры: Системный администратор
Цель: добавить нового пользователя в систему
Основной ход событий:
1.Системный администратор нажимает на кнопку «добавить новую учетную запись»
2.Система запрашивает данные о новом пользователе.
3.Системный администратор заполняет окно данных о пользователе и нажимает на кнопку «ок».
Сценарий ВИ «удаление пользователя»:
Актёры: Системный администратор
Цель: удалить пользователя из системы
Основной ход событий:
1.Системный администратор в системе заходит в раздел пользователей.
2.Сис. администратор выбирает нужного пользователя
3.Сис.администратор нажимает на кнопку «удалить учетную запись».
4.Система удаляет существующую учетную запись.
Сценарий ВИ «Изменение прав доступа пользователей»:
Актёры: Системный администратор
Цель: изменить ограничения прав пользователей
Основной ход событий:
1.Системный администратор на своем сервере открывает средство локальной политики безопасности.
2.Системный администратор выбирает из существующих учетных записей нужную и расширяет, либо сужает критерии пользования системой.
Сценарий ВИ «смена пароля пользователей»:
Актёры: Системный администратор
Цель: сменить пароль к входу в систему пользователя
Основной ход событий:
1.Системный администратор на своем сервере открывает средство локальной политики безопасности.
2.Системный администратор выбирает из существующих учетных записей нужную и меняет пароль к ней.
Сценарий ВИ «удаление документов, помеченных на удаление»:
Актёры: Системный администратор
Цель: удалить помеченные файлы
Основной ход событий:
1.Системный администратор на своем сервере открывает журнал, в котором хранятся документы, помеченные на удаление пользователями.
2.Системный администратор нажимает на кнопку «удалить файлы»
Сценарий ВИ «просмотр журнала операций»:
Актёры: Системный администратор
Цель: просмотр журнала операций
Основной ход событий:
1.Системный администратор на своем сервере открывает журнал операций, проведенных пользователями системы.
2.Системный администратор просматривает все операции. Исключение№1: Существует операция с неверным содержанием.
Исключение№1: Заблокировать операцию до выяснения обстоятельств.
Сценарий ВИ «запись времени работы пользователя в системе»:
Актёры: система
Цель: вести учет рабочего времени пользователя
Основной ход событий:
1.Система при входе пользователем в систему начинает вести отсчет времени присутствия пользователя.
2.При нажатии блокировки терминала пользователем система приостанавливает отсчет времени работы.
3.При выходе из блокировки система начинает снова отсчет времени работы.
2.Система сохраняет отсчитанное время работы в журнале.
Сценарий ВИ «ведение журнала операций пользователя»:
Актёры: система
Цель: ведение журнала операций пользователя
Основной ход событий:
1.Система при входе пользователем в систему сохраняет все операции, проделанные пользователем за рабочее время.
2.4 Матрица требований
Рисунок 2.2 Матрица требований «варианты использования» для системы
Рисунок 2.3 Матрица нефункциональных требований для системы
Рисунок 2.4 Матрица функциональных требований для системы
Рисунок 2.4 Матрица трассировки для системы
2.5 Диаграмма действий
Рисунок 2.5 Диаграмма действий для системы
3. Проектирование
3.1 Диаграмма классов
Рисунок 3.1 Диаграмма классов для системы
Таблица 3.1 Описание класса «Система».
| № | Атрибуты | Операции | Примечание |
| 1 | название | Запись времени работу пользователя | Сколько времени пользователь находился в системе |
| 2 | Дата создания | Ведение журнала операций | Сохранение операций |
| 3 | лицензия | регистрация | |
| 4 | Запись времени блокировки |
Таблица 3.2 Описание класса «Администратор сети».
| № | Атрибуты | Операции | Примечание |
| 1 | ФИО | Изменение прав доступа | |
| 2 | Логин | Вход в систему | |
| 3 | Пароль | Смена пароля | |
| 4 | Телефон | Удаление документов | |
| 5 | Просмотр журнала операций | ||
| 6 | Добавление пользователя | ||
| 7 | Удаление пользователя | ||
| 8 | Выход из системы | ||
| 9 | Блокировка терминала |
Таблица 3.3 Описание класса «журнал операций».
| № | Атрибуты | Операции | Примечание |
| 1 | Тип | ||
| 2 | Дата | ||
| 3 | Время | ||
| 4 | Источник | ||
| 5 | Состояние | ||
| 6 | Компьютер |
Таблица 3.4 Описание класса «терминал».
| № | Атрибуты | Операции | Примечание |
| 1 | Состояние |
Таблица 3.5 Описание класса «файл».
| № | Атрибуты | Операции | Примечание |
| 1 | Тип | ||
| 2 | Приложение | ||
| 3 | Размещение | ||
| 4 | Размер | ||
| 5 | Дата |
Таблица 3.6 Описание класса «пользователь».
| № | Атрибуты | Операции | Примечание |
| 1 | ФИО | Вход в систему | |
| 2 | Логин | Блокировка терминала | |
| 3 | Пароль | Выход из системы | |
| 4 | Телефон | Создание файлов | |
| 5 | Должность | Пометка документов на удаление |
3.2 Диаграмма последовательности действий
Рисунок 3.2 Диаграмма последовательности действий процесса выполнения
3.3 Диаграмма состояний объекта «Пользователь»
Рисунок 3.3 Диаграмма состояний объекта «Пользователь».
3.4 Диаграмма внедрения
Рисунок 3.4 Диаграмма внедрения для системы
3.5 База данных
Рисунок 3.5 «База данных для системы «безопасность»».
Таблица 3.5.1 «Администратор (Admin)»
| № | Название поля | Тип данных | Размер | Комментарий |
| 1 | Имя | Smallint | 50 | Естественный первичный ключ |
| 2 | Учетная запись | Smallint | 20 | Логин и пароль |
Таблица 3.5.2 «Журнал (Zhurnal)»
| № | Название поля | Тип данных | Размер | Комментарий |
| 1 | Код | Smallint | 10 | Первичный ключ |
| 2 | операция | Smallint | 10 | Название |
| 3 | Дата | Smallint | 10 |
Таблица 3.5.3 «Операция (Operaciya)».
| № | Название поля | Тип данных | Размер | Комментарий |
| 1 | Код операции | Smallint | 10 | Первичный ключ |
| 2 | Дата | Smallint | 10 |
Таблица 3.5.4 «терминал (terminal)».
| № | Название поля | Тип данных | Размер | Комментарий |
| 1 | Код | Smallint | 10 | Первичный ключ |
Таблица 3.5.5 «Файл (fail)».
| № | Название поля | Тип данных | Размер | Комментарий |
| 1 | Код файла | Smallint | 10 | Первичный ключ |
| 2 | Дата создания | Smallint | 50 |
Таблица 3.5.6 «Пользователь (pol’zovatel)».
| № | Название поля | Тип данных | Размер | Комментарий |
| 1 | Код пользователя | Smallint | 10 | Первичный ключ |
| 2 | Учетная запись | Smallint | 20 | Логин и пароль |
| 3 | Имя | Smallint | 50 | ФИО |
3.6 Пользовательский интерфейс
Рис. 3.6.1 Параметры безопасности
Рис. 3.6.2 Назначение прав пользователя
Оценка трудоемкостиОпределение трудовых показателей действующих лиц
Все действующие лица системы делятся на три типа: простые, средние и сложные. Простое действующее лицо представляет внешнюю систему с четко определенным программным интерфейсом (API). Среднее действующее лицо представляет либо внешнюю систему, взаимодействующую с данной системой посредством протокола наподобие TCP/IP, либо личность, пользующуюся текстовым интерфейсом (например, ASCII-терминалом). Сложное действующее лицо представляет личность, пользующуюся графическим интерфейсом (GUI).
Подсчитанное количество действующих лиц каждого типа умножается на соответствующий весовой коэффициент, затем вычисляется общий весовой показатель A.
Таблица 4.1 «Весовые коэффициенты действующих лиц».
| Тип действующего лица | Весовой коэффициент |
| Простое | 1 |
| Среднее | 2 |
| Сложное | 3 |
Таблица 4.2 «Типы действующих лиц».
| Действующее лицо | Тип |
| Системный администратор | Сложное |
| Пользователь | Среднее |
| Система | Сложное |
Таким образом, общий весовой показатель равен:
А = 1 ∙ 2 + 2 ∙ 3 = 8
Определение весовых показателей вариантов использованияВсе варианты использования делятся на три типа: простые, средние и сложные в зависимости от количества транзакций в потоках событий (основных и альтернативных). В данном случае под транзакцией понимается атомарная последовательность действий, которая выполняется полностью или отменяется. Общее количество вариантов использования каждого типа умножается на соответствующий весовой коэффициент, затем вычисляется общий весовой показатель (таблица 4.3).
Таблица 4.3 «Весовые коэффициенты вариантов использования».
| Тип варианта использования | Описание | Весовой коэффициент |
| Простой | 3 или менее транзакций | 5 |
| Средний | От 4 до 7 транзакций | 10 |
| Сложный | Более 7 транзакций | 15 |
Для системы безопасности сложность вариантов использования определяется следующим образом (таблица 4.4).
Таблица 4.4 «варианты использования».
| Вариант использования | Тип |
| вход в систему | Простой |
| Выход из системы | Простой |
| блокировка терминала | Простой |
| создание файлов | Простой |
| пометка документов на удаление | Простой |
| добавление пользователя | Средний |
| удаление пользователя | Простой |
| Изменение прав доступа пользователей | Средний |
| смена пароля пользователей | Простой |
| удаление документов, помеченных на удаление | Простой |
| просмотр журнала операций | Простой |
| запись времени работы пользователя в системе | Простой |
| ведение журнала операций пользователя | Простой |
Таким образом, общий весовой показатель равен:
UC = 11 ∙ 5 + 2 ∙ 10 = 75
В результате получаем показатель UUCP (Unadjusted Use Case Points):
UUCP = A + UC = 75 + 8 = 83
4.3 Определение технической сложности проекта
Техническая сложность проекта (TCF – Technical Complexity Factor) вычисляется с учетом показателей технической сложности (табл.6). Каждому показателю присваивается значение Ti в диапазоне от 0 до 5 (0 означает отсутствие значимости показателя для данного проекта, 5 – высокую значимость). Значение TCF вычисляется по формуле
TCF = 0,6 + (0,01 (ΣTi Весi))
Вычислим TCF для системы регистрации (табл.).
TCF = 0,6 + (0,01 44) = 1,04
Таблица 4.5 «Показатели технической сложности проекта TCF».
| Показатель | Описание | Вес |
| Т1 | Распределенная система | 2 |
| Т2 | Высокая производительность | 1 |
| Т3 | Работа конечных пользователей в режиме онлайн | 1 |
| Т4 | Сложная обработка данных | 1 |
| Т5 | Повторное использование кода | 1 |
| Т6 | Простота установки | 0,5 |
| Т7 | Простота использования | 0,5 |
| Т8 | Переносимость | 2 |
| Т9 | Простота внесения изменений | 1 |
| Т10 | Параллелизм | 1 |
| Т11 | Специальные требования к безопасности | 1 |
| Т12 | Непосредственный доступ к системе со стороны внешних пользователей | 1 |
| Т13 | Спец. требования к обучению пользователей | 1 |
Таблица 4.6 «Показатели технической сложности системы регистрации».
| Показатель | Вес | Значение | Значение с учетом веса |
| Т1 | 2 | 3 | 6 |
| Т2 | 1 | 4 | 4 |
| Т3 | 1 | 4 | 4 |
| Т4 | 1 | 3 | 3 |
| Т5 | 1 | 3 | 3 |
| Т6 | 0,5 | 5 | 2,5 |
| Т7 | 0,5 | 5 | 2,5 |
| Т8 | 2 | 1 | 2 |
| Т9 | 1 | 5 | 5 |
| Т10 | 1 | 5 | 5 |
| Т11 | 1 | 4 | 4 |
| Т12 | 1 | 2 | 2 |
| Т13 | 1 | 1 | 1 |
| ∑ | 44 |
4.4 Определение уровня квалификации разработчиков
Уровень квалификации разработчиков (EF – Environmental Factor) вычисляется с учетом следующих показателей (таблица 4.7).
Таблица 4.7 «Показатели уровня квалификации разработчиков».
| Показатель | Описание | Вес |
| F1 | Знакомство с технологией | 1,5 |
| F2 | Опыт разработки приложений | 0,5 |
| F3 | Опыт использования объектно-ориентированного подхода | 1 |
| F4 | Наличие ведущего аналитика | 0,5 |
| F5 | Мотивация | 1 |
| Показатель | Описание | Вес |
| F6 | Стабильность требований | 2 |
| F7 | Частичная занятость | -1 |
| F8 | Сложные языки программирования | -1 |
Каждому показателю присваивается значение в диапазоне от 0 до 5. Для показателей F1-F4 0 означает отсутствие, 3 – средний уровень, 5 – высокий уровень. Для показателя F5 0 означает отсутствие мотивации, 3 – средний уровень, 5 – высокий уровень мотивации. Для F6 0 означает высокую нестабильность требований, 3 – среднюю, 5 – стабильные требования. Для F7 0 означает отсутствие специалистов с частичной занятостью, 3 – средний уровень, 5 – все специалисты с частичной занятостью. Для показателя F8 0 означает простой язык программирования, 3 – среднюю сложность, 5 – высокую сложность. Значение EF вычисляется по формуле
EF = 1,4 + ( -0,03 (ΣFi Весi))
Вычислим EF для системы «безопасность» (таблица 4.8).
Таблица 4.8 Показатели уровня квалификации разработчиков системы
| Показатель | Вес | Значение | Значение с учетом веса |
| F1 | 1,5 | 2 | 3 |
| F2 | 0,5 | 4 | 2 |
| F3 | 1 | 2 | 2 |
| F4 | 0,5 | 4 | 2 |
| F5 | 1 | 5 | 5 |
| F6 | 2 | 3 | 6 |
| F7 | -1 | 0 | 0 |
| F8 | -1 | 0 | 0 |
| ∑ | 20 |
EF = 1,4 + (-0,03 ∙ 20) = 0.8
В результате получаем окончательное значение UCP (Use Case Points):
UCP = UUCP TCF EF = 83 1,04 0.8 = 69,01
4.5 Оценка трудоемкости проекта
В качестве начального значения предлагается использовать 20 чел.-ч на одну UCP. Эта величина может уточняться с учетом опыта разработчиков.
Приведем пример возможного уточнения.
Рассмотрим показатели F1-F8 и определим, сколько показателей F1-F6 имеют значение меньше 3 и сколько показателей F7-F8 имеют значение больше 3. Если общее количество меньше или равно 2, следует использовать 20 чел.-ч на одну UCP, если 3 или 4 – 28. Если общее количество равно 5 или более, следует внести изменения в сам проект, в противном случае риск провала слишком высок.
Для системы «безопасность» получаем 28 чел.-ч на одну UCP, таким образом, общее количество человеко-часов на весь проект равно 69,01*28=1932,28, что составляет 48 недель при 40-часовой рабочей неделе. Допустим, что команда разработчиков состоит из трех человек, и добавим 3 недели на различные непредвиденные ситуации, тогда в итоге получим 17 недель на весь проект.
Заключение
На первом этапе выполнения курсовой работы ознакомлены с задачами и обязанностями, выполняемыми для обеспечения безопасности. На основании этого во второй части работы была разработана спецификация требований к информационной системе «безопасность». В курсовом проекте для сбора требований использовались методики от Rational Unified Process (RUP). Для разработки функциональных требований RUP – модель вариантов использования (ВИ), которая состоит из диаграммы ВИ и подробно описанных потоков событий (сценариев) для каждого ВИ. Также была освоена работа в Rational RequisitePro и построены матрица функциональных, нефункциональных требований, матрица трассировки и матрица вариантов использования. Так же работа включает глоссарий – устанавливает общую терминологию для всех моделей и описаний требований к системе.
В третьей части курсовой сформированы требования к составу выполняемых функций, организации входных и выходных данных и включает: диаграмму последовательности действий, диаграмму состояний объекта «пользователь», диаграмму деятельности, диаграмму внедрения. Проектный раздел содержит проектные предложения о путях и методах решения сформулированной в начале проекта задачи. Проектная часть описывает процедуру разработки проекта и включает: диаграмму классов, схему и описание информационной базы данных, прототипы экранных форм (пользовательский интерфейс). Пятая часть работы содержит оценку трудоемкости проекта. Сделан вывод, что для разработки системы «безопасность» при условии, что команда разработчиков состоит из трех человек, и добавлено 3 недели на различные непредвиденные ситуации, требуется 23 недели на весь проект. В результате всех проведенных действий был разработан проект информационной системы управления безопасностью под названием «безопасность». В ходе выполнения курсовой работы сделаны выводы, что внедрение информационных систем может способствовать:
Увеличению качества работоспособности системы;
Увеличению скорости работоспособности системы;
Полному контролю над всеми действиями персонала;
Проведению многокритериального анализа и прогнозированию результатов деятельности;
Освобождению работников от рутинной работы за счет ее автоматизации.
В ходе эксплуатации данной информационной системы, ее можно усложнять, совершенствовать, добавляя новые функциональные возможности.
Список литературы
Вендров А.М. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. пособие.— 2-е изд., перераб. и доп. — М.: Финансы и статистика, 2006. - 192 с: ил.
Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. — М.: Финансы и статистика, 2002. - 352 с : ил.