Реферат: Информационная система управления безопасностью в программах IBM Rathional

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

Факультет экономики и менеджмента

Кафедра прикладной математики и эконометрики

Пояснительная записка к курсовой работе

по дисциплине

Проектирование информационных систем

Информационная система управления безопасностью в программах IBM Rathional

 

САМАРА, 2009

Оглавление

Введение

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

2.   Анализ требований

2.1       Глоссарий

2.2       Диаграммавариантов использования

2.3       Спецификации вариантовиспользования (Сценарий)

2.4       Матрицатребований

2.5       Диаграммадействий

3.   Проектирование

3.1 Диаграмма классов

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

3.3 Диаграмма состояний объекта«пользователь»

3.4 Диаграмма внедрения

3.5 Проектирование базы данных

3.6 Пользовательский интерфейс

4.   Оценка трудоемкости

4.1 Определение трудовых показателейдействующих лиц

4.2     Определениевесовых показателей вариантов использования

4.3     Определениетехнической сложности проекта

4.4     Определение уровняквалификации разработчиков

4.5    Оценкатрудоемкости проекта

Заключение

Список литературы

Введение

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

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

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

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

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

Информационная системауправления безопасностью

Главной задачей курсовойработы является построение целостной системы защиты автоматизированнойинформационной системы (АИС). Данная АИС осуществляет автоматизацию некоторогопроцесса обработки конфиденциальной информации, включая все аспекты этогопроцесса, связанные с обеспечением безопасности обрабатываемой информации,соответствует требованиям и критериям стандартов информационной безопасности. Разработаемпроект системы обеспечения информационной безопасности, включающей системызащиты от несанкционированного доступа на автономных компьютерах и рабочихстанциях в локальных вычислительных сетях, системы защиты отнесанкционированного доступа из глобальных сетей общего пользования. Даннаяразработка предназначена для обеспечения безопасности информации вавтоматизированной системе продаж. Данный программный продукт ориентирован навсех сотрудников магазина, работающих с автоматизированной системой. Так жеданная система позволяет её администратору вести контроль всех действийпользователей.

В системе участвуютследующие лица: администратор системы, пользователь и сама система.

2. Разработкатребований

 

2.1 Глоссарий

Администратор сети — сотрудник, отвечающий за работукомпьютерной сети предприятия в штатном режиме

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

Доступ — метод, процесс или совокупностьправил взаимодействия с сетью или системой с целью использования их ресурсов

Регистрация в системе — получение пароля и доступапользователя к системе

Безопасностьинформации — средства аутентификации и управления доступом к ресурсам системы

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

2.2     Диаграммавариантов использования для системы безопасности

 

/>

Рисунок 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 Назначениеправ пользователя

4.        Оценкатрудоемкости

4.1      Определениетрудовых показателей действующих лиц

Вседействующие лица системы делятся на три типа: простые, средние и сложные. Простоедействующее лицо представляет внешнюю систему с четко определенным программныминтерфейсом (API). Среднее действующее лицо представляет либо внешнюю систему, взаимодействующуюс данной системой посредством протокола наподобие TCP/IP, либо личность,пользующуюся текстовым интерфейсом (например, ASCII-терминалом). Сложноедействующее лицо представляет личность, пользующуюся графическим интерфейсом(GUI).

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

Таблица 4.1 «Весовыекоэффициенты действующих лиц».

Тип действующего лица Весовой коэффициент Простое 1 Среднее 2 Сложное 3

Таблица 4.2 «Типыдействующих лиц».

Действующее лицо Тип Системный администратор Сложное Пользователь Среднее Система Сложное

Такимобразом, общий весовой показатель равен:

А = 1 ∙ 2 + 2 ∙3 = 8

4.2      Определениевесовых показателей вариантов использования

Всеварианты использования делятся на три типа: простые, средние и сложные взависимости от количества транзакций в потоках событий (основных иальтернативных). В данном случае под транзакцией понимается атомарнаяпоследовательность действий, которая выполняется полностью или отменяется.Общее количество вариантов использования каждого типа умножается насоответствующий весовой коэффициент, затем вычисляется общий весовой показатель(таблица 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-F40 означает отсутствие, 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 F8 -1 ∑ 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 недели навесь проект. Врезультате всех проведенных действий был разработан проект информационнойсистемы управления безопасностью под названием «безопасность». В ходе выполнениякурсовой работы сделаны выводы, что внедрение информационных систем можетспособствовать:

·         Увеличению качестваработоспособности системы;

·         Увеличениюскорости работоспособности системы;

·         Полному контролюнад всеми действиями персонала;

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

·         Освобождениюработников от рутинной работы за счет ее автоматизации.

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

Списоклитературы

1.        Вендров А.М.Практикум по проектированию программного обеспечения экономическихинформационных систем: Учеб. пособие.— 2-е изд., перераб. и доп. — М.: Финансыи статистика, 2006. — 192 с: ил.

2.        Вендров А.М.Проектирование программного обеспечения экономических информационных систем:Учебник. — М.: Финансы и статистика, 2002. — 352 с: ил.