37
В основе методологии RUP содержится шесть основных
принципов:
Управление требованиями – описываются все процессы
организации и отслеживания всех необходимых требований,
документация и выбор самых наилучших решений (как в процессе
разработки, так и при ведении бизнеса);
Итеративная модель разработки – Отсутствие рисков в
каждой стадии проекта даёт возможность лучше понять и найти
проблемы и внести необходимые изменения пока не будет найдено
приемлемое решение;
Компонентная архитектура – в данной системе
архитектура разбита на отдельные компоненты, которые в свою
очередь можно использовать как в нынешнем, так и в будущих
проектах;
Визуальное моделирование ПО – данная методология
показывает, как нужно создать визуальную модель программного
обеспечения, так чтобы была понятна структура и поведение
архитектуры и его компонентов;
Проверка качества ПО – в ходе разработки ПО ведётся
тщательный контроль всех действий команды;
Контроль внесённых изменений – ведётся мониторинг
над изменениями, что позволяет построить бесперебойный процесс
разработки. Также создаётся уютная и благоприятная обстановка
для команды, и она будет защищена от изменений в рабочем
процессе.
Структура RUP
Данную методология RUP состоит из четырёх элементов:
Работники – «Кто»
38
Элемент «работник» несёт ответственность за членов команды, которые
выполняют общие цели, а именно создание объектов.. В методологии RUP
работник – это роль, которая определяет, как работники должны выполнять
свою работу. Работник производит некоторые действия, а также владеет
набором артефактов.
Действия – «Как»
Действие — это работа что выполняет работник. Каждое действие
обозначает цель. Каждое действие назначено определённому работнику. В
качестве действий можно отметить создание и изменение артефактов, например
модель, класс или план.
Артефакты (искусственные объекты) – «Что»
В методологии RUP объекты или информация, производимая и
изменяемая в процессе работы над финальным результатом. Артефакты служат
как вводными данными для действий работников, так и результатами этих
действий.
Рабочий процесс – «Когда»
Рабочий процесс представляет собой последовательность действий,
приводящих к видимому результату.
RUP Жизненный цикл
Жизненный цикл состоит из четырёх фаз, в каждой фазе ведётся работа
над новым поколение производимого продукта: первая фаза — это начало
проекта, вторая фаза — это уточнение, третья фаза — это построение,
четвёртая и последняя фаза — это внедрение.
Фаза начала проекта
В фазе начало проекта команда составляет структуру и основную идею
будущего проекта. Команда занимается решением есть ли необходимость в
39
этом проекте или же нет, исходя из денежных средств, которые им предстоит
потратить, пересмотреть все необходимые им ресурсы и те цели которых они
хотят достичь.
Уточнение
Главной целью этой фазы является провести анализ к архитектуре и
требований системы. Необходимо разработать план проекта и выявление и
устранение рисков. На данной фазе чаще всего низкие риски становятся
рисками более высокого уровня. На данной фазе вся команда решает стоит ли
переходить к следующей фазе, а именно к фазе построения или нет.
Построение
В фазе построения команда разработчиков преступает к разработке всех
компонентов и функций ПО, и создаёт последний продукт. Это
производственный процесс, в рамках которого команда сосредоточена на
управлении ресурсами, для того чтобы максимально оптимизировать расходы,
время и качество продукта.
Внедрение
На данной фазе продукт уже полностью готов и протестирован на
работоспособность и доставляется пользователю. Но не всегда пользователя
может устроить последний вид продукта и от этого появляются новые
трудности такие как поиск багов, исправление ошибок, доделывание новых
функций.
В конце каждого этапа команда оценивает, смогли ли они достигнуть
поставленных целей или нет.
На первоначальном этапе после проведения анализа деятельности
организации, необходимо поставить цели и задачи автоматизации и разработать
план проекта. После оформления документов можно приступить к разработке.
В начале следует создать базу данных потом отчётные формы для ведения
40
отчётов, пишется программный код, происходит обработка полученной
информации и полученную информацию следует сохранить, процедуры
фильтрации. После разработки системы, проходит этап тестирования. По
завершению тестирования готовится план эксплуатации и документация для
внедрения, а также различная пользовательская документация. Процесс будет
происходить следующим образом. В университете уже имеется локальная
вычислительная сеть (ЛВС) и она хорошо функционирует так что в замене или
ремонте нет никакой необходимости. В начале происходит установка
серверной части системы учёта заявок, на рабочие станции устанавливаются
клиентские приложения системы учёта заявок. После установки обязательно
программа тестируется на работоспособность и демонстрируется
работоспособность при руководстве и персонале. В качестве последней стадии
является проведение обучения для сотрудников компании. Необходимо
добавить всех сотрудников в информационную систему.
За эксплуатацию готовой системы, будет отвечать сисадмин. В его
задачу будет входить:
1. Разрабатывается инструкция по работе с данной программой.
2. Получение и документирование сведений о возникающих проблемах,
их решение и контроль за возникновением, обеспечение обратной связи с
пользователями.
3. Тестирование системе в эксплуатационной среде, кооперация со
службой сопровождения для устранения возникших проблем и модернизации
системы.
4. Поддержка и консультация пользователей.
В качестве ключевых участников выступаю я и сотрудник технического
отдела.
Входная информация — это заявки, которые поступают в технический
отдел.
Результат на выходе:
41
Автоматизированная сортировка заявок, отладка, автоматизированное
сопровождение, отчёт программы о выполненной работе.
RUP — это итеративная методология с большим количеством
всевозможных решений, в частности представляет процесс разработки.
RUP в отличие от большинства других методологий, позволяет в
широком диапазоне выбирать степень формализации и итеративности процесса
разработки в зависимости от особенностей проектов и разрабатывающей
организации.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
На каждом этапе ЖЦ ИС нам встречаются разные риски. Они могут
повлиять как на время создания системы, а также на её функциональность.
Этап подготовки проекта
Риск персонала
Риски:
• Риск нанять не обученных работников без опыта работы что
понизит шансы на успех;
• Набор «случайных» разработчиков;
• Отсутствие между разработчиками общих целей и идей что
приведёт к разобщению в коллективе;
• Отсутствие поощрений сотрудников;
• Персонал отказывается участвовать в проекте;
• Случайный план построения работ;
Методики предотвращения:
• Постоянное взаимодействие с руководством в процессе всего
проекта, оперативное принятие решений;
• Привлечение к проекту ведущих специалистов и консультантов;
• Четкая формулировка целей и задач;
• Выработка единой стратегии автоматизации компании;
• Неизменный состав рабочей группы во время подготовки проекта.
Риск ведения проекта
42
Риски:
• Ошибочное определение рамок и масштаба проекта;
• Выделение ошибочных функций системы;
• Подбор неверных технологий и методов решений задач;
• Несоблюдение приведенных заказчиком требований.
Методики предотвращения:
• Поддержать стабильность границ проекта;
• Точное планирование предстоящих работ;
• В проекте должны присутствовать все необходимые ресурсы;
• Должно быть полное согласие между сотрудниками по проектному
решению;
• Высокий порог принятия изменений.
Этап разработки
Риск персонала
Риски:
• Увольнение персонала что участвует в разработке;
• Участники проекта не могут прийти к согласию из-за слабой
коммуникации;
• Неправильное представление основной задачи проектирования;
• Найм разработчиков, которые не умеют работать с нужной
системой.
Методики предотвращения:
• Необходимо более чётче нанимать сотрудников для успешного
выполнения проекта;
• Сотрудники должны хорошо взаимодействовать между собой для
более быстрой и безошибочной разработки.
Технические риски
Риски:
• Разработка может остановиться если в разрабатываемом ПО будут
найдены ошибки;
43
• Пользовательская документация не имеет полный список описаний
всех функции системы.
Методики предотвращения:
• Работать нужно только с проверенным и лицензионным ПО оно в
свою очередь будет долго поддерживаться и без всяческих ошибок, регулярное
резервное копирование данных;
• Отслеживание полноты сведений во всех документах.
• Пользовательская документация должна имеет полный список
описаний всех функции системы
Этап внедрения
Риск персонала
Риски:
• Разработчика и специалистов предметной области не могут
коммуницировать между собой и это приводит к незаконченному проекту;
• Сотрудники отказываются использовать новую систему и обучаться
работе с ней;
• Руководства не принимает участие в создании.
Методики предотвращения:
• Обучение пользователей со стороны заказчика;
• Должен быть план по внедрению системы;
• Объяснить персоналу для чего мы делаем данную автоматизацию;
• Активное взаимодействие с руководящим персоналом во время
проведения всего проекта.
Технические риски
Риски:
• Риск потерять всю информацию при внедрении системы.
Методики предотвращения:
• Наем квалифицированных сотрудников, имеющих опыт разработки
подобных систем.
Этап эксплуатации и сопровождения
44
Технические риски
Риски:
• Баги и ошибки ПО, приводящие к невозможности использования
системы;
• Неправильное использование оборудования;
• Отсутствие функциональных возможностей системы из-за
реорганизации предприятия.
Методики предотвращения:
• Должно проходить качественная проверка на баги, ошибки, и
недочёты, и исправление их во время разработки;
• В документы должны быть занесены все технические условия и
согласования.
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Меры необходимые для защиты информации:
• В информационной системе должна быть защита от внутренних
угроз;
• В информационной системе должна быть защита от внешних угроз.
Для защиты от внутренних угроз в системе используется политика
разделения прав доступа. Характеристика политики приведена в таблице 2.1.
Таблица 0.1
Разграничение прав пользователей
Группы
пользователей
Модуль
«Авторизация»
Модуль «Учет
заявок»
Модуль
«Ввод
данных»
Модуль
«Отчеты»
Сотрудник
Чтение
Нет
Нет
Ограничен
Администратор
системы
Полный
Полный
Полный
Полный
Защита от внешних угроз осуществляется путем применения следующих
способов:
45
• использованием программно-аппаратных комплексов защиты от
несанкционированного доступа;
• разработкой и соблюдение политик безопасности;
• использованием антивирусных средств;
• физической защитой помещений с наиболее ценной информацией.
Я выбрал в качестве средства защиты систему СКУД «Elsys».
СКУД Elsys предназначена для автоматического контроля пропускного
режима и управления исполнительными устройствами (автоматическими
воротами, шлагбаумами, лифтами, турникетами, замками и т. п.) в соответствии
с заданными полномочиями и расписаниями.
Аппаратная основой у данной системы является контроллеры Elsys-MB,
которые создаются с разными характеристиками. Наличие большого
количества вариантов, а также необходимых модулей расширения встроенной
памяти различной емкости к ним. Позволяет при проектировании ускорить
технико-экономические характеристики систем различных масштабов.
Контроллеры Elsys-MB могут объединиться в сеть по двухпроводному
интерфейсу RS-485. Линии связи RS-485 подключаются к серверу
оборудования СКУД через преобразователи интерфейсов RS-232/RS-485 или
USB/232-485 (до 15 линий на один ПК), либо по компьютерной сети
предприятия через коммуникационные сетевые контроллеры (КСК) Elsys-MB-
Net (до 256 КСК на один ПК). Данная система поддерживает нахождение
нескольких серверов оборудования, объединенных вместе компьютерной
сетью, что в сою очередь может обеспечить неограниченные возможности
масштабирования системы.
В университете разработана своя система безопасности, и в неё входят
частные документы:
1. Правила парольной защиты;
2. Правила, которые защищают от вирусов и потустороннего опасного
программного обеспечения;
3. Требования по контролю за физическим доступом;
46
4. Присутствует необходимая информация для безопасного
уничтожения информации;
5. Правила осуществления удаленного доступа;
6. Требования резервного сохранения информации;
7. Слежение за доступом и ведением файлов;
8. Требования при обращении с носителями данных;
9. Требования при регистрации пользователей;
10. Требования по проверке прав пользователей;
11. Защищённый контроль доступа в операционную систему;
12. Требование ко входу в систему;
13. Правила использования системных утилит;
14. Возможность удаленной работы мобильных пользователей для
комфортной работы;
15. Необходимо распределить ответственность для лучшего
обеспечения безопасности;
16. Правила безопасности при выборе персонала;
17. Требования контроля оперативных изменений;
18. Применяются криптографические средства;
19. Контроль за доступом к исходному тексту программ;
20. Требования контроля вносимых изменений;
21. Ограничения на изменения прикладного ПО.
2.2 Информационное обеспечение задачи
2.2.1. Характеристика нормативно-справочной, входной и оперативной
информации
В качестве входной информации для разрабатываемой Информационной
Системы используются следующие документы:
- Заявка на обслуживание – поступает прямиком от
сотрудников университета по одному из каналов связи (форма
оформления заявки, телефон), содержит следующие сведения
Реквизиты клиента (ФИО, номер кабинета).