69
числе взаимодействие почтовых серверов, веб сервера, СУБД, а так же работу
инициаторов и исполнителей в разрабатываемой системе.
Следующим этап, это Фаза разработки. В ней проектная группа направлена на
создание компонентов решений (включая документацию, программный код). Но в
то же время некоторые компонены этой работы могут продолжаться и на фазе
стабилизации, если в процессе тестирования выявлена данная необходимость.
Данная фаза также включает в себя разработку инфраструктуры.
Стоит заметить, что активность проектной группы на данном этапе не
ограничивается написанием кода – все участники проекта принимают участие в
создании и тестировании решения.
Результатами данной фазы считаются: исходный и исполнимый код, скрипты
инсталяции и конфигурации, окончательное описание функционала
разрабатываемого решения, материалы поддержки решения, сценарии тестов. В
случае реализации моего проекта от разработчика на этом этапе необходимо
предоставить клиентское приложение для работы исполнителей отдела ИТ и
разработки документации к ней. От руководителя проекта требуется предоставить
работоспособную среду описанную в прошлом этапе.
На этапе фазы стабилизации идет тестирование проекта этапа разработки.
Внимание акцентировано на использование в реальной модели промышленной
среды. Проектная группа занимается расстановкой приоритетов и ликвидацией
недоработок, а также подготовкой решения к выпуску.
В самом начале фазы стабилизации оперативность выявления ошибок
тестирования превосходит скорость, устранения данных ошибок командой
разработчиков. Невозможно предугадать, сколько будет ошибок и сколько времени
потребуется для их устранение. Но существует два статистических признака,
помогающих проектной группе оценить уровень стабилизации решения. Это точка
конвергенции, где можно заметить существенный прогресс в устранении ошибок, то
есть скорость ликвидации багов превосходит скорость их обнаружения. Так как
количество найденных, но не устраненных ошибок может варьироваться даже после
того, как они начали уменьшаться, конвергенция можно рассматривать как
тенденция, нежели как фиксированный момент во времени. Вслед за этим
количество активных ошибок должно продолжать убывать, вплоть до точки нуля.
70
Точка конвергенции дает проектной группе возможность понять, что процесс
тестирования близится к завершению.
Результатами фазы стабилизации являются
Окончательный продукт;
Документация выпуска;
Материалы поддержки решения;
Результаты и инструментарий тестирования;
Исходный и исполнимый код приложений;
Проектная документация.
В моей выпускной квалификационной работе на данном этапе программистом
корректируются ошибки в разрабатываемой им программе, компилируется версия
релиз кандидат и после отсутствия критических ошибок по всем веткам
функционала программы выпускается окончательная сборка исполняемого кода,
параллельно с этим дополняется документация к работе с программой.
Руководителем проекта на данном этапе набирает группу тестирования из 2-3
инженеров, которые будут пользоваться этой программой каждый день и тестирует
все ветки функционала по разработанным ранее сценариям и формирует
дополнения, которые можно будет реализовать в следующей версии.
Следующим этапом будет Фаза внедрения
Во время этой фазы проектная группа внедряет технологии и компоненты
решения, стабилизирует внедренное решение, передает работу персоналу
поддержки и сопровождения и получает со стороны заказчика окончательное
одобрение результатов проекта. По завершению внедрения проектная группа
производит анализ выполненной работы и удовлетворенности заказчика.
Во время этой фазы по ходу переноса компонент решения из среды
тестирования в производственную среду могут продолжаться меры по стабилизации
решения. Результаты фазы внедрения включают в себя: Информационные системы
эксплуатации и поддержки, Процедуры и процессы, Базы знаний, отчеты, журналы
протоколов, Массивы данных и программный код, разработанные во время проекта.
Отчет о завершении проекта, Показатели удовлетворенности заказчика и
потребителей, Описание последующих шагов. На этом этапе Руководитель
окончательно внедряет систему в эксплуатацию, устанавливает программный
71
продукт на компьютерах Инженеров ИТ, распечатывает им инструкцию по работе с
ней или проводит обучение по её алгоритму работы. Далее Пользователем
высылается новый регламент работы ИТ отдела и информацию о новой логике
обработки заявок с просьбой в течение недели ответить о замеченных изменениях в
обслуживании службой ИТ.
Внедрение является общим понятием и для него существуют разные
стратегии реализации, которые напрямую зависят от срока исполнения и качества
ис, получаемой на выходе. Существуют четыре основные стратегии внедрения
системы:
Параллельная стратегия - когда одновременно работают старая (ручная) и
новая система, и их выходные документы сравниваются. Если они согласуются
длительное время, осуществляется переход на новую систему.
«Скачок» - это резкий переход от старой системы к новой без дополнительных
проверок и с полным отказом от старой системы.
«Пилотный проект» это наиболее часто используемая стратегия. «Пилотный
проект» - это тактика «Скачка», но применяемая к ограниченному числу процессов.
Область применения стратегии - небольшой участок деятельности. Такой подход
снижает риск и наиболее надежен.
«Узкое место» - это малая часть производственного процесса. При
использовании подхода "узкое место" план внедрения выполняется только для
«узкого места» и для людей, работающих в нем.
В данном дипломной проекте будет применена стратегия «Пилотный проект».
Мы будем проводить полный переход к автоматизированной системе для процессов
регистрации и обработки заявок Областью применения внедрения будет отдел
информационных технологий, состоящий из 4 операторов. Такой подход не затронет
работу всей ИС, а лишь автоматизирует рутинную часть. Надежность данного
внедрения обусловлена четким соответствием порядка регистрации и обработки
заявки регламенту горячей линии.
В данном дипломном проекте охарактеризовать стратегию внедрения можно
как стратегию узкого места, так как данный проект автоматизирует процесс,
связанный с работой операторов горячей линии, и узким местом является скорость
72
ручной обработки писем, согласования их и детального уточнения. автоматизация
программный информационный система
Далее наступает этап эксплуатации разработанного программного продукта.
В соответствии с написанной инструкции к применению, работу данной программы
следует отслеживать работу программы каждые 2-4 часа, ведь программа может
зависнуть или обработать не все письма, пришедшие на почтовый ящик горячей
линии из за отсутствии логики обработки данного типа заявки, в данном случае
письмо будет возвращено (переслано) на почтовый ящик горячей линии с пометкой
в теме письма "Не обработано". Данного рода риска следует анализировать 1 раз в
месяц и принимать решение о необходимости доработки логики программы, что в
рамках поддержки программы первые пол года эксплуатации будет выполняться
бесплатно программистом, реализовавшим описанную логику работы.
Под моделью жизненного цикла понимается структура, определяющая
последовательность выполнения и взаимосвязи процессов, действий и задач,
выполняемых на протяжении жизненного цикла. Модель жизненного цикла зависит
от специфики информационной системы и специфики условий, в которых последняя
создается и функционирует
К настоящему времени наибольшее распространение получили следующие
основные модели жизненного цикла:
1. Задачная модель;
2. каскадная модель (или системная) (70-85 г.г.);
3. спиральная модель (настоящее время).
Задачная модель: при разработке системы "снизу-вверх" от отдельных задач
ко всей системе (задачная модель) единый поход к разработке неизбежно теряется,
возникают проблемы при информационной стыковке отдельных компонентов. Как
правило, по мере увеличения количества задач трудности нарастают, приходится
постоянно изменять уже существующие программы и структуры данных. Скорость
развития системы замедляется, что тормозит и развитие самой организации. Однако
в отдельных случаях такая технология может оказаться целесообразной:
Крайняя срочность (надо чтобы хоть как-то задачи решались; потом
придется все сделать заново)
73
Эксперимент и адаптация заказчика (не ясны алгоритмы, решения
нащупываются методом проб и ошибок).
Общий вывод: достаточно большую эффективность информационной
системы таким способом создать невозможно.
Каскадная модель: в ранних, не очень больших по объему однородных
информационных системах каждое приложение представляло собой единое целое.
Для разработки такого типа приложений применялся каскадный способ. Его
основной характеристикой является разбиение всей разработки на этапы, причем
переход с одного этапа на следующий происходит только после того, как будет
полностью завершена работа на текущем. Смотреть Рисунок 11. Каждый этап
завершается выпуском полного комплекта документации, достаточной для того,
чтобы разработка могла быть продолжена другой командой разработчиков.
Преимущества каскадного подхода:
Формируется законченная проектная документация на каждом этапе;
Последовательность выполнения работ позволяет планировать их
сроки и затраты на каждом этапе.
Рис. 11. Каскадная модель
Каскадный подход хорошо зарекомендовал себя при построении
информационных систем, для которых в самом начале разработки можно достаточно
точно и полно сформулировать все требования, с тем, чтобы предоставить
разработчикам свободу реализовать их как можно лучше с технической точки
зрения. В данную категорию попадают сложные расчетные системы, системы
реального времени и другие подобные задачи. Однако в процессе использования
этого подхода обнаружился ряд его недостатков, вызванных прежде всего тем, что
реальный процесс создания систем никогда полностью не укладывался в такую
жесткую схему. В процессе создания постоянно возникала потребность в возврате к
74
предыдущим этапам и уточнении или пересмотре ранее принятых решений. В
результате реальный процесс создания программного обеспечения принимал
следующий вид Рисунок 12:
Рис. 12. Каскадная модель в разработке на практике
Основным недостатком каскадного подхода можно считать запоздание
получения результатов. Согласование результатов с пользователями производится
только в точках, планируемых после завершения каждого этапа работ, требования к
информационным системам "заморожены" в виде технического задания на все время
ее создания. Сущность системного подхода к разработке ИС заключается в ее
декомпозиции на автоматизируемые функции: система разбивается на
функциональные подсистемы, которые в свою очередь делятся на подфункции,
подразделяемые на задачи и так далее. Таким образом, данная модель основным
достоинством имеет системность разработки, а основные недостатки - медленно и
дорого.
Спиральная модель исключает указанные выше недостатки, делая упор на
начальные этапы жизненного цикла: анализ и проектирование. На этих этапах
реализуемость технических решений проверяется путем создания прототипов.
Каждый виток спирали соответствует созданию фрагмента или версии
программного обеспечения, на нем уточняются цели и характеристики
проекта, определяется его качество и планируются работы следующего витка
спирали. Таким образом, углубляются и последовательно конкретизируются детали
проекта и в результате выбирается обоснованный вариант, который доводится до
реализации.
75
Разработка итерациями отражает объективно существующий спиральный
цикл создания системы. Неполное завершение работ на каждом этапе позволяет
переходить на следующий этап, не дожидаясь полного завершения
работы на текущем. При итеративном способе разработки недостающую работу
можно будет выполнить на следующей итерации. Главная же задача - как можно
быстрее показать пользователям системы работоспособный продукт, тем самым,
активизируя процесс уточнения и дополнения требований.
Основной проблемой спиральной модели можно считать определение
момента перехода на следующий этап. Для устранения данного недостатка нужно
установить временные ограничения на каждом этап всего жизненного цикла.
Переход следует в соответствии с планом, даже в случае если запланированные
задачи выполнены не все. Составление плана осуществляется на основании данных,
полученных в предыдущих проектах, и квалификации разработчика. Графическое
изображение спиральной модели жизненного цикла показано на Рисунке 13.
Рис. 13. Спиральная модель
Спиральная модель наиболее оптимальный выбор, за счет отсутствия
недостатков каскадной и задачной моделей. В рамках доработки уже существующей
информационной системы зачастую возникают новые замечания от пользователей,
которые можно доработать на новом витке спиральное модели.
Ожидаемые риски на этапах жизненного цикла и их описание
76
Минимизацию рисков обеспечивает стандарт MSF, обеспечивая всего
разделение всего жизненного цикла на этапы, которые имеют роли имеющие свои
цели, которые должны быть достигнуты. Однако в данной концепции могут быть и
некоторые риски на каждом этапе.
Выработка концепции:
o Не корректные сроки проекта;
o Не верно спланированный бюджет;
Для устранения данного риска необходимо детальное рассмотрение проекта,
задачи и целей проекта. При расчетах нужно расставить больше контрольных точек.
Состав команды проекта;
Более тщательный подбор исполнителей проекта ликвидирует данный
недостаток, но необходимо смотреть не только на профессиональные, но и на
личные качества.
Планирование архитектуры выбираемого решения;
Данный недостаток может решиться за счет выбора компетентного руководителя
проекта, в задачи которого входит принятие решения выбора архитектуры
поставленной задачи.
Разработка;
Данный риск снизится к минимуму при должной квалификации разработчика
проекта и корректно поставленное техническое задание, на основании которого
разрабатывается данный проект. Четко поставленная задача залог успешного
выполнения проекта.
Тестирование;
В случае не полного завершения тестирования программного продукта, имеется
риск получения множества ошибок и не надлежащего результата. К данному шагу
нужно относится более ответственно.
Внедрение;
Внедрение незаконченного решения приводит к нестыковок между отдельными
компонентами разрабатываемой информационной системы. Данный риск можно
исключить путем доработки продукта на этапе тестирования.
2.2.2 Характеристика нормативно-справочной, входной и оперативной
информации
77
Вся входящая информация по заявкам имеет структурированный вид. Это
реализовано благодаря обязательным полям заполнения в форме обращения и
выбору прочих пунктов из перечня, с установленными ограничениями на ручной
ввод, в случаях где это необходимо. Сам текст обращения указывается в свободной
форме. Процесс написания заявки регламентирован внутренней политикой
инспекции, документ который указан в базе знаний.
Оформление обращений автоматизировано и пользователю необходимо
заполнить лишь необходимые поля:
1. Номер обращения присваивается автоматически по принципу год-дата-номер
обращения по порядку после отправки заявки. Данное поле является
уникальным (пример: 2018-0628-00001);
2. Выбирается из выпадающего списка категория обращения (консультация,
ошибка, неисправность либо программный продукт, требующий технической
поддержки)
3. Устанавливается приоритет обращения
4. Выбирается исполнитель из выпадающего списка (в данный перечень входят
специалисты, в чьей компетенции относится
администрирование/сопровождение выбранной категории)
5. Выбирается из выпадающего списка да или нет (если в регламенте указано,
что для решения выбранного вопроса требуется согласование, то
устанавливается значение да)
6. Права пользователей указаны в «Таблице №9».
«Таблица № 9»
Права доступа в системе технической поддержки
Роль
Права
Инициатор
Руководитель
Координатор
Исполнитель
Создание/
Изменение
+
+
+
-
Чтение
+
+
+
+
Согласование
-
+
+
-
Уточнение
-
-
+
+
Удаление
+
-
+
-
2.2.3 Характеристика результатной информации
Результатной информацией в данном проекте являются формируемые отчеты:
78
За период, показывает загруженность отдела, т.е. сколько обращений
поступает за определенное период времени.
o За сутки
o За неделю
o За месяц
o Настраиваемый диапазон
По исполнителю, то есть отчет формируется по отдельному исполнителю о
его компетенции.
По категории. Данный отчет показывает наиболее часто всплывающую
проблему, по решению которой следует принять те или иные меры.
По исполнению. По общему количеству исполненных или же неисполненных
обращений.
Данные отчеты имеют информационный характер, но так же могут быть приняты
и для принятия управленческих решений, с целью расширения или же уменьшения
штата отдела, а так же выявления «проблемного» ПО с целю полной замены и
перехода на другое, либо организации курсов повышения квалификации персонала
(в случае если обращения связаны с вопросами использования ПО)
2.3 Программное обеспечение задачи
2.3.1 Общие положения (дерево функций и сценарии диалога)
В данной выпускной квалификационной работе рассматривается процесс
автоматизации обращений. На Рисунке 14 предоставлен сценарий диалога, на
котором показан весь процесс автоматизации. Логика, заложенная в данный проект
автоматически выполняет, те задачи, которые ранее необходимо было выполнять
вручную (регистрация, обработка, оповещение).