47
2. ПРОЕКТНАЯ ЧАСТЬ
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Под жизненным циклом проекта автоматизации в сфере разработки
информационных систем подразумевается совокупный набор различных этапов
разработки итогового проекта, каждый из которых, в конечном счете, в
некотором виде, изменяет представленный проект информационной системы.
Цикл включает, но не ограничивается, этапами проектирования,
разработки и "деплоя" (от английского слова "Deploy", означающий
"Развертывание") проекта.
Жизненный цикл нового программного обеспечения обязательно
начинается в момент, когда становится кристально ясно, что существующие
бизнес-процессы требуют изменений в инклюзивных этапах. Именно начиная с
этого момента, пройдя этапы проектирования, разработки, внутреннего и
внешнего тестирования, рабочего развертывания, информационная система
начинает менять эти бизнес-процессы.
Для решения поставленной в рамках данного дипломного проекта задачи
было определено, что будет использоваться итерационная модель разработки
программного обеспечения, поскольку это позволит вести разработку в виде
коротких циклов, на каждом из которых можно будет вводить новый
функционал и отслеживать уже существующий. Это, в свою очередь, позволит
повысить качество выпускаемых обновлений, стабильность работы
программного обеспечения, улучшит обратный отзыв от сотрудников и, что не
менее важно, позволит плавно переводить бизнес-процесс на новую
информационную систему. Подобная модель активно применяется в разработке
практически во всех современных компаниях, а учитывая то, что "Норс Студиос"
является компанией, чья основная деятельность базируется на разработке
программного обеспечения, то работа по данной модели уже отлажена.
48
Отсюда можно выявить основные преимущества системы, а именно:
1. Итерационную модель можно масштабировать в нескольких
плоскостях. Это позволит использовать мелкие итерации (в
профессиональной терминологии часто обозначаются как спринты)
в рамках крупных итераций (коими являются так называемые
"апдейты");
2. Повышение качества разработанного программного обеспечения.
Благодаря тому, что все внимание концентрируется на разработке
небольшого участка и отсутствует крайняя необходимость в
спешке (поскольку каждый спринт имеет свое расписание в общей
схеме), то сводится к минимуму вероятность архитектурных
ошибок на этом уровне;
3. Постепенный ввод функционала позволяет сотрудникам освоиться
с новым программным обеспечением и работе с ним.
С учетом опыта компании, для данной модели можно определить
следующие этапы:
1. Анализ и построение по нему требований к разрабатываемому
продукту;
2. Проектирование системы;
3. Тестирование;
4. Интеграция в бизнес-процесс (иначе говоря внедрение);
5. Эксплуатация;
Технически, на этапе эксплуатирования происходит переход на новый
цикл, который начинается с анализа и проектирования новых требований к
продукту.
49
Каждый из вышеназванных этапов характеризируется следующими
особенностями:
Анализ и построение по нему требований:
Работы, которые будут выполнены в ходе данного этапа:
Изучение существующего процесса (в рамках данного дипломного
проекта таким процессом является контроль исполнения задач по
проектам), включая:
Сбор необходимых сведений о бизнес-процессе;
Идентификация проблем, которые необходимо решить;
Оценка проекта разработки исходя из финансовых
соображений.
Построение требований конечного пользователя в лице "Норс
Студиос" включая:
Формулировка технических требований к новой системе;
Формулировка ожидаемого финансового эффекта;
Формулировка иных требований, не входящих в
вышеуказанные формулировки.
Разработка концепт-дизайна программного обеспечения, что
подразумевает:
Разработку группы концепт-дизайнов программного
обеспечения, которые включают в себя (но не ограничиваются)
оценкой технических возможностей, финансовых затрат
необходимых для реализации проекта;
Осуществление выбора конечно используемого концепт-
дизайна, который будет реализовываться в рамках разработки
информационной системы.
Итоговая разработка технического задания, включая его
утверждение.
В результате выполнения вышеназванных работ будет осуществлен этап
анализа и построения требований, в рамках которого будет сформирован и
50
согласован технический проект, являющий собой техническое задание на
проектирование информационной системы.
Проектирование системы:
Работы, которые будут выполнены в ходе данного этапа:
Разработка предварительного проектного решения, которое будет
включать в себя:
Определение используемых в реализации подсистем;
Определение функциональных частей продукта;
Определение вида используемых структур хранения данных.
Разработка решения для информационной системы и ее составных
частей, включая:
Разработка архитектуры программного обеспечения системы;
Разработка алгоритмов решения поставленных задач;
Разработка системы классификации.
Разработка документации на программное обеспечение
информационной системы, включая:
Согласование документации
Разработка документации
Оформление документации
В результате выполнения вышеназванных работ будет осуществлен этап
проектирования информационной системы, в рамках чего будет разработана
информационная система и прилагающаяся к ней документация.
Тестирование системы:
Работы, которые будут выполнены в ходе данного этапа:
Проведение внутренних тестов, во время которых будут выявлены
возможные риски обвала информационной системы
Исправление выявленных ошибок в архитектуре и алгоритмах
программы для понижения вероятностных рисков.
51
В результате исполнения работ, указанных выше, будет выполнен этап
тестирования, который позволит укрепить внутренние алгоритмические
конструкции системы, в результате чего повысится стабильность и
отказоустойчивость всей системы.
Интеграция в бизнес-процесс (иначе говоря – внедрение):
Работы, которые будут выполнены в ходе данного этапа:
Подготовка бизнес-процесса, подверженного автоматизации к
осуществлению операции внедрения разработанной в рамках
данного дипломного проекта системы, которая включает в себя
внедрение классификаторов, используемых в информационных
потоках системы;
Интеграция пайплайна сотрудников в разработанную систему;
Проведение опытной эксплуатации системы;
Прием информационной системы компанией "Норс Студиос";
В результате выполнения вышеназванных работ будет осуществлен этап
интеграции в бизнес-процесс, который ознаменует начало полноценного
функционирования информационной системы.
Эксплуатация:
Работы, которые будут производиться в ходе данного этапа:
Обновление элементов безопасности информационной системы по
мере необходимости;
Обновление графического интерфейса в рамках соответствии
внутренним документам компании "Норс Студиос";
Устранение технических неисправностей и элементов, приводящих
в прямом или косвенном виде к данным неисправностям;
Обновление сопутствующей документации по мере обновления
программного обеспечения до степени, которая будет явно
соответствовать актуальности используемого программного
52
обеспечения, разработанного в рамках данного дипломного
проекта и являющегося неотъемлемой частью информационной
системы.
Результатом выполнения перечисленных работ является полноценное
функционирование разработанной программно-информационной системы на
соответствующих техническим требованиям мощностях в течение всего периода
эксплуатации данной системы.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
В ходе разработки информационной системы может возникнуть
множество различных рисков. Тем не менее, используя современные подходы к
проектированию и разработке и учитывая существующий опыт в данной сфере
(включая не только свой, но и чужой), можно избежать бóльшую часть из них.
Однако, даже не смотря на это, все еще остается вероятность того, что некоторые
отдельные вероятные риски все же могут повлиять на проект.
Для удобства, такие риски были приведены в соответствии этапам, в ходе
которых они могут проявиться.
Анализ и построение по нему требований к разрабатываемому продукту:
Риск размытого описания требований к разработке или неверное
восприятие этих требований разработчиками. Данный риск наиболее
распространен в компаниях, где управленческий состав не до конца
сформировал видение будущего бизнес-процесса. Тем не менее, возникновению
данного риска благоволит и такие проблемы, как слабосвязанная документация
требований, использование сугубо профильной и узкоспециализированной
терминологии, которая может быть неверно воспринята разработчиками ввиду
отсутствия необходимого для этого опыта или познаний. Данный риск весьма
опасен, поскольку он с самого начала выводит разработку системы в неверном
направлении, что, в конечном счете, будет означать потерю огромного
количества времени и ресурсов, а возможность выправить этот курс будет
сведена к минимуму. Для того, чтобы не допустить этого, необходимо детально
53
обсудить с заказчиком информационной системы все нюансы по каждому
принимаемому пункту требований, иной раз включая повторение обсуждения.
Риск искажения сроков выполнения поставленной задачи является
вторым по опасности и первым по встречаемости в разработке программного
обеспечения. Данный риск, как правило, исходит из результатов переоценки или
же наоборот, недооценки своих возможностей разработчиками. В результате
этого реальный срок разработки может быть сдвинут на много недель (а скорее
даже месяцев) вперед, что сулит финансовые потери со стороны заказчика в
первую очередь, либо же сдвинут назад, что приведет к проблемам с интеграцией
системы (конечный пользователь может не быть готов к началу интеграции
системы). Для избегания данного риска необходимо составить
детализированный список поставленных задач и (учитывая современные
методики разработки) использовать покер-планирование (если методология
разработки позволяет) или его аналоги.
Проектирование системы:
Риск несоответствия графику разработки. Данный риск обусловлен
скачущим реальным графиком работ по сравнению с установленным рамками
проектной реализации. Зачастую происходит это из-за того, что сотрудники
теряют свою производительность на определенных вершинах разработки
(обуславливается, как правило, неверным представлением сотрудников о
скорости выполнения задач) в результате чего случается падение
производительности и соответствующее ему отставание из-за необходимости
наверстывания графика. Данный риск может быть исключен, если будет
производится своевременный контроль за ходом разработки и предоставление
сотрудникам наглядной информации об их успехах.
Тестирование:
На данном этапе не представлено каких-либо рисков, которые не были бы
описаны ранее.
54
Интеграция в бизнес-процесс (иначе говоря – внедрение):
Риск нарушение графика ввода системы в эксплуатацию. Данный риск
может негативно сказаться на работоспособности компании, а соответственно
снижении финансовой выгоды. Снижение данного риска можно добиться при
помощи контроля каждого этапа интеграции.
Эксплуатирование:
Риск неполного использования введённой программно-информационной
системы в эксплуатацию. Подобное может произойти в случае, если сотрудники,
использующие данную информационную систему, не до конца перешли и
привыкли к новой системе. В результате этого может произойти ситуация, при
которой будет введена не полная или неверная информация, что приведет к
нарушению целостности информации в компании и начать скатывание так
называемого снежного кома. В итоге может произойти утечка чувствительной
информации. Для снижения риска необходимо в полной мере произвести
обучение использованию новой системой и полный отказ от использования
старой системы или иных потоков, которые могут привести к возникновению
подобного риска
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Для обеспечения должного уровня безопасности и защиты информации в
программно-информационной системе контроля исполнения задач по проектам
будут использоваться различные методы. Среди них в обязательном порядке:
1. Демаркация доступа к системе;
2. Использование средств аутентификации в системе;
3. Активное отслеживание и логирование действий пользователя;
4. Резервное копирование данных на защищенные, выделенные
сервера.
55
Демаркация представляет собой различением определенных
должностных позиций, которые отвечают за свои участки информационной
системы. К таким позициям относятся:
1. Неавторизованный пользователь;
2. Сотрудник компании;
3. Администратор сервера базы данных (DBS Administrator);
4. Администратор сервера сети доставки контента (CDNS
Administrator);
5. Администратор центрального сервера (CS Administrator);
В таблице 7 представлена схема типа предоставленного доступа в
зависимости от должностной позиции. При этом, обозначение участков системы
соответствует названным выше должностям. Таким образом, DBS является
аббревиатурой для Database Server, что соответствует Серверу Базы Данных.
Также необходимо учесть, что под термином частичного удаления в
данной таблице подразумевается пометка об удалении, которая к настоящему
удалению объекта из информационной системы не ведет.
Таблица 7.
Предоставляемый доступ в зависимости от должностной позиции
Участок
системы
Должностная позиция
Неавторизованный
пользователь
Сотрудник
компании
DBSA
CDNSA
CSA
DBS
удаление
Нет
Есть/Части
чно
Есть
Нет
Нет
DBS чтение
Есть/Частично
Есть
Есть
Нет
Нет
DBS запись
Нет
Есть
Есть
Нет
Есть/
Частично
CDN
удаление
Нет
Есть/Части
чно
Нет
Есть
Нет
CDN чтение
Есть/Частично
Есть
Есть/Част
ично
Есть
Нет
CDN запись
Нет
Есть
Нет
Есть
Есть/
Частично
56
Продолжение таблицы 7
Неавторизованный пользователь является внешним пользователем,
который проявляет желание узнать текущий статус разработки и эксплуатации
продуктов компании. Данный вид пользователя является самым ограниченным,
поскольку кроме отображения публично доступной информации иного
функционала системы он получать не должен. Доступ таких пользователей
должен соответствовать регламенту компании о публикации публичных
сведений и осуществляться при помощи сайта компании или сайтов продуктов.
Сотрудник компании имеет наибольший функционал в вопросе
добавления сведений. Поскольку именно данный вид пользователя (или
должностной позиции) эксплуатирует систему в полной мере. Тем не менее, не
смотря на возможность добавлять и читать информацию, пользователь не может
в действительности ее удалить, поскольку это будет являться уязвимостью в
вопросе безопасности и целостности информации.
Администратор Сервера Базы Данных отвечает за работоспособность
соответствующего программного сервера информационной системы. Он имеет
доступ к хранимой на нем информации и возможность ее удаления. Тем не
менее, он не сможет получить доступ к серверу раздачи контента и его
содержимому, кроме ограниченного чтения (под которым подразумевается
информация о контенте передаваемая в базу данных).
Администратор Сервера Сети Доставки Контента отвечает за свой
программный сервер и его работоспособность. Данный сервер является наиболее
ограниченным по функционалу, поэтому права и доступ к нему наименее строги,
а хранимая информация не является чувствительной.
Участок
системы
Должностная позиция
Неавторизованный
пользователь
Сотрудник
компании
DBSA
CDNA
CSA
CS
авторизация
Нет
Есть
Есть
Есть
Есть
CS
обращение
Есть/Частично
Есть
Есть
Есть
Есть