43
II Проектная часть
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Модель жизненного цикла - структура, содержащая процессы, действия и
задачи, которые осуществляются в ходе разработки, функционирования и
сопровождения программного продукта в течение всей жизни системы, от
определения требований до завершения ее использования. Имеется несколько
моделей и стандартов, в какой-то степени регламентирующих жизненный цикл,
большая часть из них принадлежит заказному ПО (автоматизированным
системам АС, и др.) и помимо непосредственно ЖЦ регламентируют кроме того
и процессы разработки:
Custom Development Method (и, технология Oracle) по разработке
прикладных информационных систем под заказ – определенный материал,
конкретизированный вплоть до степени заготовок проектных документов,
предназначенных на применение в проектах с применением Oracle. Степень
адаптивности CDM ограничивается 3-мя моделями ЖЦ: "классическая" (учтены
все без исключения работы/задачи и этапы), "быстрая разработка" (Fast Track),
"упрощенный подход", предлагаемый в случае небольших проектов и
возможности ускоренно прототипировать приложения.
Rational Unified Process (RUP) предлагает итеративную модель разработки,
включающую четыре фазы: начало, исследование, построение и внедрение.
Прохождение через четыре ключевые фазы именуется циклом разработки, при
этом каждый цикл заканчивается генерацией версии системы.
Microsoft Solution Framework (MSF) аналогична с RUP, точно так же
содержит четыре фазы: исследование, проектирование, разработка,
стабилизация, является итерационной, подразумевает применение объектно-
ориентированного моделирования. MSF в сопоставлении с RUP в большей части
нацелена на разработку бизнес-приложений.
Extreme Programming (XP). Экстремальное программирование считается
наиболее новейшим из числа рассматриваемых методологий, сложилась в 1996
году. В основе методологии командная деятельность, результативная связь
44
между заказчиком и исполнителем на протяжении всего проекта по созданию
ИС, а создание проводится с использованием поочередно дорабатываемых
прототипов.
Главными аспектами для выбора стандарта ЖЦ будут:
• актуальность и современность применяемых методов
контролирования разработки
• разработка в итерационном режиме с возможностью осуществлять
контроль риски
• и исполнения самого проекта на некоторых контрольных точках,
отсутствие добавочных требований по моделированию процесса разработки и
внедрения.
Резюмируя представление стандартов выше итерационными из них
считаются 4 стандарта: MSF, RUP, COBIT, XP .
Стандарт COBIT не подходит, потому что основной целью его
использования “является проведения аудита и стратегического планирования ИС
и IT инфраструктуры в целом”.
Стандарт XP тоже не подходит, так как он не содержит полноценных
этапов ЖЦ, таких как выработка концепции, планирование, разработка,
стабилизация, внедрение.
Таким образом, перед выбором стоит Rup и MSF. Эти два стандарта
считаются молодыми и поддерживающими всё новейшие технологии
продуктивной разработки и контролирования их исполнения.
Ключевые характерные особенности MSF, RUP и XP объединены в
таблицу 2.1. Согласно этой таблицы по ней возможно судить, что Rational
Unified Process считается хорошо сбалансированным решением для средних по
размерам коллективов разработчиков, работающих с применением продуктов и
технологий компании Rational.
Extreme Programming хорошо подойдет для проектных групп небольшого
размера и для малых систем с зачастую модифицируемыми требованиями.
Основная трудность XP - сопровождение. В случае текучки сотрудников в
коллективе разработчиков существенная доля проектных данных может быть
45
утрачена из-за почти отсутствующей документации. В таблице 2.1 показаны
ключевые характеристики Жизненного цикла ИС
Таблица 2.1
Технологии MSF, RUP и XP
Технология
Лучший
размер
команды
Соответствие
стандартам
Допустимые
технологии и
инструменты
Удобство
модификации и
сопровождения
Rational
Unified
Process
10 - 40 чел.
стандарты
Rational
UML и
продукты
Rational
Удобно (RUP)
Microsoft
Solutions
Framework
3 - 20 чел.
адаптируема
любые
Удобно
(MSF+MOF)
XP
2 - 10 чел.
стандарты
отсутствуют
любые
Сложно
(зависимость от
конкретных
участников
коллектива)
Microsoft Solutions Framework является наиболее сбалансированной
технологией, ориентированной на проектные группы малых и средних размеров.
Разрабатываемая ИС считается небольшой. Помимо этого главным
преимуществом MSF считается итерационная модель одновременно с
уточняющими вехами (аналог каскадной модели). То есть, реализация MSF
предприняла попытку совместить каскадную и итерационную модель разработки
и внедрения ПО.
По описанным выше преимуществам, был выбран стандарт MSF как
наиболее гибкий и удобный для реализации ИС.
Этапы разработки АИС показаны в таблице 2.2
46
Таблица 2.2
Этапы разработки АИС
Этап проекта
Начало
Длительность
Конец
Фаза выработки концепции
Изучение и анализ предметной области
15.03.2019
3
19.11.2018
Изучение и анализ области внедрения
20. 03.2019
3
22.11.2018
Фаза планирования
Составление технического задания
25. 03.2019
4
26.11.2018
Фаза разработки
Построение концептуальной модели ИС
29. 03.2019
5
01.12.2018
Описание входных и выходных данных
05.04.2019
7
08.12.2018
Разработка структур данных
16. 04.2019
8
16.12.2018
Разработка технического проекта
26. 04.2019
10
26.12.2018
Написание программ, модулей утилит
10. 05.2019
10
05.01.2019
Фаза стабилизации
Отладка
24. 05.2019
7
12.01.2019
Тестирование
04. 06.2019
5
17.01.2019
Разработка документации
11. 06.2019
2
19.01.2019
Фаза внедрения
Внедрение
13. 06.2019
7
26.01.2019
Итого
71
дней
Проектная группа состоит из 1 человека.
Результатом фазы выработки концепции было следующее
Формулировка видения. Разработанная система учета проектов позволит
предприятию повысить эффективность учета выполненных платежных
поручений и анализа их выполнения.
Цели системы:
• работать с клиентами предприятия;
Задачи системы:
• работать с базой данных предприятия;
47
• учитывать проекты и этапы выполнения проекта
В нашем случае на системы накладываются следующие ограничения:
• система не является распределенной;
• интерфейс системы представлен в одном окне;
• система должна наглядно демонстрировать формы и способы
хранения и взаимодействия данных.
Функциональность решения
▪ Хранилище находится в оперативной памяти
▪ Добавление клиентов по нажатию кнопки
• Проверка корректности введены данных
o Проверка существования проекта с таким названием
• Создание визуальной формы для отображения данных клиентов
▪ Добавление проектов
• Проверка корректности введены данных
o Проверка наличия данных
• Добавление в визуальные формы поручений информации о
добавленных документах
▪ Удаление документов
• Удаление всех сопутствующих данных
Фаза планирования
Результатом данной фазы является техническое задание и план разработки
ПО, приведенный в таблице 2.2.
Фаза разработки
Результатом данной фазы явилась разработанная концептуальная модель
базы данных с указанием сущности и атрибутов каждой сущности. Приведены
входные и выходные документы. После этого разработано технический проект,
написана программа.
Фаза стабилизации
Во время фазы стабилизации было проведено тестирование
разработанного программного обеспечения. При этом тестирование проводилось
наиболее приближенно к работе предприятия .
48
Во время этой фазы была разработана инструкция пользователя по работе
с программой. Проектная группа при этом занималась приоритезацией и
устранением ошибок программирования.
Фаза внедрения
Во время этой фазы необходимо будет установить и настроить MySQL на
предприятии.
При этом при эксплуатации пользователи работают с модулем, вводя
реальные данные, но при этом параллельно используется прежняя старая
система, в которой предприятия до этого времени осуществляла свою работу.
Этот этап необходим для того, чтобы можно было сопоставить результаты
работы в новой системе с результатами, которые получены были прежним
способом.
При внедрении будет использоваться стратегия «жесткого» внедрения.
Такая стратегия позволяет внедрить быстро и требуемый функционал,
чтобы получать нужные отчеты.
При таком подходе руководителю проекта внедрения нужно быть готовым
к следующим последствиям:
• Пользователи будут жаловаться;
• Обучение работе с программой займет больше времени, так как
сразу вводится весь функционал;
• В единицу времени обращений пользователей по поводу работы
программы будет много. При этом необходимо их все обрабатывать, иначе
недовольство пользователей будет нарастать;
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
В фазе формирования концепции имеют все шансы возникнуть
последующие риски:
• Недальновидный анализ сроков проекта и его бюджета
Для ликвидации подобного рода рисков необходимо более подробно
изучать задачи и цели проекта, установить больше контрольных точек.
49
• Неправильно выбранный проектный состав исполнителей способен
спровоцировать полное отсутствие командной работы
Данный риск снижается более кропотливым выбором профессионалов в
проектную группу.
На фазе планирования возможно появление следующих рисков:
• Неправильно либо не совсем верно сформирована структура
выбираемого решения
Возможность возникновения данного риска находится в зависимости от
компетенции управляющего проектом, на котором лежит принятие решение о
выборе архитектуры разрабатываемого решения
В фазе разработки вероятны последующие риски:
• Неправильное понимание технического задания и равно как
результат некорректное программирование архитектуры и сдвиг сроков .
Минимизацией этого риска является более точное написание
технического задания, понятного программисту
• Еще одним важным риском в этом плане считается недостаток
должной квалификации у разработчика в том языке, на котором принято
решение реализовывать программу заказчика, которая будет распределять
заявки между инженерами.
В случае, если разработчик программного обеспечения не будет
укладываться в установленные временные рамки календарного плана проекта,
придеться привлекать внешнего разработчика, так называемый “аутсорсинг”
либо “фриланс”.
В фазе тестирования имеют все шансы появиться последующие риски:
• Риски неоконченного тестирования.
Может случиться ситуация что программный продукт будет
протестирован не до конца.
Решается посредством проведения повторного тестирования на
следующей итерации разработки.
В фазе внедрения имеют все шансы возникнуть последующие риски:
• Риски неверного принятия решения о законченности некой части
проекта.
50
Возникновение этих рисков приводит за собой проблему
незаконченности решения и вероятность возникновения нестыковок с иными
элементами разрабатываемой ИС. Устраняется это путем доделки при
последующей итерации.
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Необходимо учитывать возможные риски после автоматизации:
− проектные риски при создании системы,
− бизнес-риски, связанные с эксплуатацией системы (возникающие, в
конечном счете, из-за технических рисков).
− бизнес-риски, связанные с изменением бизнес-процессов. При этом
потери происходят оттого, что: а) бизнес-процессы надо изменять, а
информационная система не готова к этому, и потери связаны с неоптимальным
функционированием бизнеса, и б) оттого, что имеется стоимость модификации
системы,
− технические риски, состоящие в простоях, отказах, потере или
искажении данных и т.п.
Выделим четыре существенных риска практически любого проекта, в том
числе проекта внедрения ИС:
1. риск низкого качества результатов проекта — выполнение работ с
низким уровнем качества и неспособность удовлетворять разумные требования
конечных пользователей;
2. риск срыва сроков проекта — невыполнение работ в установленные
сроки, зависимость выполнения работ от смежных проектов и мероприятий;
3. риск увеличения затрат — недостаток определенных бюджетом
проекта средств, необходимость увеличения бюджета;
4. риск остановки проекта — изменение условий и масштабов проекта.
51
Далее следует определить факторы риска. Фактор риска — это
характеристики (события, свойства, факты) проекта, которые существенно
влияют на него и качество его результатов.
Необходимо отметить, что малозначительные риски в совокупности могут
образовать критическую массу, представляющую серьезную угрозу проекту.
Точно так же и маловероятные риски в случае возникновения могут завести
проект в тупик.
При разработке мер по обеспечению компьютерной безопасности важно
соблюдать определенный баланс между надежностью системы локальной
безопасности и эффективностью работы сотрудников компании. Например,
если для каждого действия сотруднику потребуется подтверждение
специалиста по безопасности, то безопасность будет обеспечена, но работать
компания не сможет.
Слишком слабая система защиты и открытый доступ всем сотрудникам
ко всей информации может привести к огромным информационной потерям,
если компания не сможет обеспечить конфиденциальность данных своих
клиентов.
Следует также отметить, что не существует абсолютно надежной
системы информационной безопасности. Все способы защиты, разработанные
одним человеком, может обойти другой человек. Другое дело, что время и
ресурсы, потраченные на взлом защиты, могут быть в разы выше выгоды,
полученной от взлома.
Увеличение времени и ресурсов, необходимых для взлома системы и
есть основная цель информационной безопасности.
Информационная безопасность, как было сказано выше, складывается из
нескольких составляющих:
– организационные меры;
– технические меры;
– программные меры.
Организационные меры не случайно находятся первыми в списке. Как
показывает история, огромное количество взломов информационных систем и
утечек случилось как раз потому, что сотрудники, имеющие доступ к
52
информации, проявляли небрежность и не соблюдали элементарные
требования информационной безопасности.
Поэтому, прежде всего в компании должны быть приняты
определенные стандарты безопасности и выработаны правила поведения
сотрудников в области информационной безопасности .
Основные меры, которые позволяют минимизировать вероятность
взлома локальной сети предприятия:
– использование сотрудниками надежных паролей: запрещено
использовать пароли, содержащие осмысленные слова на каком-либо из
популярных языков, пароли должны содержать символы в верхнем и нижнем
регистре, цифры и спецсимволы;
– хранение паролей на физическом или электронном носителе
нежелательно; если же сотрудник обойтись без этого не может, то необходимо
всегда держать носитель при себе;
– если работа только производится в общественном месте и
используется ноутбук, то при необходимости отлучиться нужно блокировать
текущего пользователя;
– каждому сотруднику желательно установить на своем
персональном компьютере антивирус, пусть даже и бесплатный, и регулярно
обновлять антивирусные базы;
– каждый сотрудник должен работать под своей учетной записью и
со своими правами доступа; при возникновении потребности в доступе к
какому-либо ресурсу сотрудник должен обратится к своему руководству.
Следует также отметить, что возможности администрирования не
должны быть замкнуты только на одного человека, так как в случае его
болезни или отпуска должна быть возможность передать полномочия
администратора другому сотруднику.
Для этого пароль администратора должен быть продублирован на бумаге
и храниться у руководства компании.
Технические средства защиты информации.
Это различные по типу устройства (механические, электромеханические,
электронные и др.), которые решают задачи защиты информации.