46
- проведение тестирования;
- управление всем выпуском.
При прохождении каждой из этих фаз для каждого лица, ответственного
за кластер, устанавливаются конкретные задачи.
Так, на фазе подготовки концепции устанавливаются следующие задачи:
Управление продуктом:
- логический и концептуальный дизайн;
- сводный план и календарный график всего проекта;
- функциональная спецификация;
- бюджет.
Управление программой:
- выработка цели дизайна;
- подготовка концепции решения;
- определение структуры проекта.
Разработка:
- оценивание технологий;
- физический и логический дизайн;
- план и график выполнения разработки;
- общая смета.
Удовлетворение потребителя:
- рассмотрение примеров/сценариев использования;
- требования пользователей;
- запросы общедоступности и локализации;
- пользовательская документация (график тестирования, план обучения,
удобства применения);
- обучение.
Тестирование:
- оценивание дизайна;
- запросы тестирования;
- план и график проведения тестирования.
47
Управление выпуском:
- оценивание дизайна;
- эксплуатационные запросы;
- план и график как пилотного, так и окончательного введения.
Тем не менее, в рамках разработки и внедрения проекта лишь силами
работников ИТ департамента, применять шесть или даже больше человек для
решения фоновой задачи с бюджетом в виде премии совершенно
нецелесообразно. Именно поэтому были объединены задачи кластеров и
выбраны два ответственных лица, являющихся одновременно командой
данного проекта:
Программист, который должен выполнить такие кластеры:
- реализация управления всей программой;
- выполнение разработки;
- удовлетворение пользователей.
Менеджер/внедренец/тестировщик проекта, который обязан реализовать
следующие кластеры:
- осуществление управления продуктом;
- проведение тестирования;
- реализация управления выпуском.
Выходными сведениями и результатами этой фазы является выбор
кандидатов и назначение из их числа самых способных к выполнению
поставленных задач. Другими словами, осуществляется формирование
команды, невзирая на то, что она состоит лишь из двух человек. На указанном
этапе данного проекта определяется состав и главные роли участников. Также
составляется смета по временному принципу и общее планирование бюджета
проекта [29].
После выполнения этих задач следует фаза планирования. Ее главной
целью выступает подготовка планов проекта. Также она предполагает
подготовку функциональной спецификации, рабочих планов, разработку
дизайнов, оценивание проектных затрат, а также установление сроков
48
разработки всех составных элементов проекта.
Под процессом проектирования следует понимать систематический
способ перемещения от концепций абстрактного характера к конкретным
техническим тонкостям.
Фаза планирования имеет следующие итоги:
- функциональная спецификация;
- характеристика вероятных рисков;
- общий план и календарный график данного проекта;
- детализирование среды разработки и дальнейшего тестирования.
На данном этапе программист должен подготовить обзор и выбрать язык
программирования, с помощью которого и будет осуществлено решение. Также
он должен составить календарный план по всем графикам и срокам разработки.
Задача менеджера проекта состоит в планировании архитектуры ИС,
включая взаимодействие веб-сервера, почтового сервера, СУБД, работу
инженеров в создаваемой системе.
После данного этапа следует фаза разработки, в ходе которой проектная
группа концентрирует свое внимание на подготовке компонент решения
(программного кода и документации). Но определенная часть данной работы
может выполняться и во время фазы стабилизации, если необходимость в этом
будет обнаружена при тестировании. Кроме того, указанная фаза предполагает
разработку инфраструктуры [40].
Необходимо отметить, что на данном этапе активность проектной
команды не ограничивается лишь написанием программистами кода. Активное
участие в подготовке и тестировании решения принимают все кластеры.
Итогами фазы разработки выступают:
- скрипты конфигурирования и установки;
- исходный и исполнимый код приложений;
- описание функционала создаваемого решения;
- материалы по дальнейшей поддержке решения;
- сценарии для тестов.
49
При подготовке данного проекта на указанном этапе программист
должен предоставить готовую программу клиент для инженеров ИТ, а также
полный список документов к ней. В целом, руководитель проекта обязан
предложить работоспособную среду, представленную на предыдущем этапе.
Далее следует фаза стабилизации, в ходе которой осуществляется
тестирование готового решения. Внимание в первую очередь фокусируется на
его применении в реалистичной модели той или иной производственной среды.
Также проектная группа уделяет внимание приоритезации, ликвидации ошибок
и окончательной подготовке созданного решения к выпуску.
Как правило, в самом начале фазы стабилизации ошибки
обнаруживаются командой тестирования намного быстрее по сравнению со
скоростью, с которой данные ошибки могут быть устранены командой
разработчиков. Также невозможно спрогнозировать, сколько погрешностей
будет обнаружено, и как долго будет длиться их устранение. Но можно
выделить один статистический признак, который помогает проектной группе
дать оценку уровню стабилизации создаваемого решения. Этим признаком
является точка конвергенции, в которой становится заметным значительный
прогресс в ликвидации ошибок (т.е. скорость устранения погрешностей
начинает преобладать над скоростью их выявления). В связи с тем, что
количество обнаруженных, но не ликвидированных ошибок часто колеблется
даже после его уменьшения, конвергенцию стоит рассматривать в качестве
тенденции, а не фиксированного момента. После прохождения этой точки
число активных ошибок должно и дальне уменьшаться до достижения нуля. В
целом, точка конвергенции позволяет проектной группе осознать, что процесс
тестирования уже приближается к завершению [32].
Итогами фазы стабилизации вступают:
- полностью готовый продукт;
- полный комплект документации выпуска;
- материалы для осуществления поддержки решения;
- инструментарий и результаты тестирования;
50
- код приложений (исходный и исполнимый);
- документация по проекту.
В нашем проекте на рассматриваемом этапе программист исправляет
ошибки в программе, осуществляет компилирование версии релиз кандидат, а
после устранения критических погрешностей по всему функционалу
программы реализует окончательную сборку исполняемого кода. Также
параллельно с указанными задачами происходит пополнение документации к
работе с этой программой.
В это время руководитель проекта собирает группу тестирования (2-3
менеджера), которые должны ежедневно применять эту программу и
тестировать разные ветки функционала по ранее составленным сценариям.
Также он должен подготовить дополнения, которые при необходимости будут
выполнены в следующей версии.
После фазы стабилизации идет фаза внедрения, когда проектная группа
начинает вводить технологии и разные компоненты решения, реализует
стабилизацию внедренного решения, затем передает всю работу специальному
персоналу сопровождения и поддержки, а также получает от заказчика
одобрение итогов проекта. Вместе с тем, проектная группа по окончанию
внедрения должна выполнить анализ, как своей работы, так и
удовлетворенности заказчика [30].
В ходе данной фазы в процессе переноса компонент решения,
находящихся в среде тестирования, в производственную среду могут и дальше
осуществляться меры по стабилизации данного решения. Итоги фазы
внедрения содержат в себе:
- процессы и процедуры;
- информационные системы поддержки и эксплуатации;
- базы знаний;
- журналы протоколов и отчеты;
- программный код и массивы данных, разработанные во время
реализации проекта;
51
- показатели удовлетворенности потребителей и заказчика;
- отчет об окончании проекта;
- описание дальнейших шагов.
На данном этапе руководитель внедряет готовую систему в
эксплуатацию и устанавливает на компьютерах инженеров ИТ данный продукт.
Затем он предоставляет им инструкцию для работы и знакомит их с алгоритмом
функционирования системы. Вслед за этим пользователям отправляется
обновленный регламент деятельности отдела ИТ, а также сведения о новой
логике работы с заявками, где указывается просьба на протяжении недели дать
ответ относительно отмеченных изменений в обслуживании ИТ службой.
Необходимо указать, что внедрение – это общее понятие, и его
реализация может осуществляться с помощью разных стратегий, напрямую
зависящих от срока выполнения и качества получаемой на выходе ИС.
Выделяют четыре главные стратегии внедрения системы:
«Скачок» – предполагает резкий переход к новой системе без каких-
либо дополнительных проверок. При этом старая система полностью
отбрасывается.
Параллельная – предусматривает параллельное действие ручной
(старой) и новой систем, а их выходные документы сопоставляются. Если
длительное время они согласуются, тогда полностью внедряется новая система.
«Пилотный проект» – используется наиболее часто. Эта система
представляет собой тактику «скачка», которая применяемая лишь к
небольшому числу процессов (т.е. область применения данной стратегии –
ограниченный участок работы). Этот подход значительно снижает риски и
считается самым надежным [26].
«Узкое место» – предполагает использование плана внедрения лишь для
«узкого места» и тех людей, которые в нем работают.
Для этого проекта выбрана стратегия «Пилотный проект».
Соответственно, для процессов регистрации и последующей обработки заявок
планируется полное внедрение автоматизированной системы. Но этот подход
52
не будет касаться функционирования всей ИС, а только ее отдельной рутинной
части. Такое внедрение является надежным благодаря точному соответствию
порядку выполнения регистрации и дальнейшей обработки заявки.
После этого следует этап эксплуатации нового программного продукта.
Согласно написанной инструкции к его применению действие программы
необходимо проверять каждые 2-4 часа, так как программа может потерять
некоторые данные либо зависнуть. Подобные риски нужно анализировать один
раз в месяц, после чего принимать решение касаемо потребности в доработке
логики программы. В рамках поддержки новой программы эти задачи
выполняются в первые шесть месяцев эксплуатации бесплатно тем
программистом, который реализовывал представленную логику работы.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Стандарт MSF предоставляет определенную гарантию на минимизацию
рисков, ведь ЖЦ проекта делится на этапы, и на каждом из них присутствуют
роли, осуществляющие конкретные цели. Они должны быть достигнуты, но все
равно остаются незначительные риски.
Так, в фазе подготовки концепции вероятны такие риски:
Недостаточно точный анализ сроков и бюджета проекта.
Для устранения подобного риска необходимо внимательнее работать
над целями и задачами проекта, а также ставить большее количество
контрольных точек.
Плохо подобранный проектный состав исполнителей, что может
привести к невозможности реализации командной работы.
Этот риск сокращается при помощи более скрупулезного подбора
специалистов: посредством тестирования, как профессиональных навыков, так
и личностных качеств исполнителей.
Во время фазы планирования возможны следующие риски:
Некорректно или неправильно сформированная архитектура решения.
Появление данного риска зависит от уровня компетенции руководителя,
53
который ответственен за выбор архитектуры создаваемого решения.
В ходе фазы разработки можно ожидать таких рисков:
Неверная интерпретация поставленного технического задания, что
приводит к ошибочному программированию архитектуры и смещению сроков.
Чтобы минимизировать этот риск, нужно более четко и понятно
составлять техническое задание.
Отсутствие надлежащей квалификации у программиста именно в том
языке, который был избран для реализации программы клиент,
предназначенной для распределения между инженерами заявки.
Если программист будет не в состоянии уложиться в установленные
календарным планом временные рамки, тогда понадобится помощь внешнего
разработчика (т.е. «фриланс» или «аутсорсинг»).
В ходе реализации фазы тестирования могут возникнуть такие риски:
Вероятность неоконченного тестирования.
Эта проблема решается при помощи повторного тестирования данной
разработки на следующей итерации.
Во время фазы внедрения возможно появление следующих рисков:
Принятие неверного решения о завершенности некоторой части проекта.
Указанный риск может привести к проблеме незавершенности всего
решения и вероятности появления противоречий с иными частями создаваемой
ИС.
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Для данного комплекса задач существует несколько реализации
информационной безопасности
Защита от внутренних угроз. Подразумевает разграничение прав
пользователей. Подробные права пользователей описаны в таблице 8.
54
Таблица 8
Разграничение прав пользователей
Группы
пользовател
ей
Создание
заявки
Возможность
редактирова
ния своей
заявки
Возможность
переназначит
заявку
Работа с базой
знаний
Сетевая
группа
Чтение
Есть
Есть
Чтение/создание/
удаление
Группа
поддержки
пользователей
Чтение
Есть
Нет
Чтение/создание/
удаление
Горячая линия
Чтение/созда
ние/удаление
Есть
Есть
Чтение
2. Защита от внешних угроз реализуется следующими параметрами:
В компании используются все возможные методы защиты информации,
так как нет уникального одного метода, который смог бы обеспечить полную
информационную безопасность, а сочетание всех методов позволяет
реализовать максимальную информационную безопасность.
2.2. Информационное обеспечение задачи
2.2.1. Информационная модель и её описание
Для того чтобы определить главные нюансы информационной системы,
сформировали диаграмму потоков информации, что отображена в приложении
А.
На ней можно увидеть функционирование Заведующего склада
эксплуатационных материалов и техники.
Накладная с данными касательно сырья, а также техники, что поступает
от вышестоящего органа управления, а точнее из отделения области
анализируется и принимается в работу заведующим склада. Он с помощью
формируемой ИС заносит информацию, что отображена в накладной: номер,
когда она была выдана, создание справочников типов, а также наименование
материалов и оборудования, иные характеристики - серийный, инвентарный
55
номер, а также штрих код, количественные показатели. После осуществления
данных действий, создается накладная касательно приема, потом данные
прописываются в справочнике техники и материалов, потом уже направляются
на склад ОСП. В будущем указанные данные можно применять в качестве
основы при формировании отчетов о приеме [1].
Заявки, которые поступают от клиента, анализирует заведующий склада.
С использованием ИС осуществляется поиск необходимых материалов и
техники, которые запрашиваются. Когда указанные товары существуют, то
заведующий создает накладную на распределение, все данные отображаются в
справочнике склада с отсылкой к отделу. Также данные имеют отношение и к
местонахождению [24].
Работники отделения, которые находятся в комиссии о годности
определенного товара или техники, направляют заявку на данный запрос для
формирования Акта касательно списания либо формирования дефектной
ведомости. Заведующий склада осуществляет поиск и выявляет где находится
данный товар, потом запрашивает его на склад, а в то же время формируется
накладная о возврате. После создания такой накладной, заведующий формирует
или акт касательно списания, или же дефектную ведомость, которые
отсылаются комиссии. Данные должны быть учтены в ИС.
Отделение имеет возможность отправить накладную касательно
возврата товара. Заведующий склада работает с поступившей накладной и
осуществляет поиск необходимого товара. Затем формируется накладная
касательно возврата либо акта о списании.
Чтобы лучше отобразить необходимые данные была сформирована
Диаграмма сущностей связи базы данных, которую можно увидеть на рисунке
4.
На данной диаграмме отображены характеристики обеспечения
сохранности информации, которая была обработана в итоге создания входных
документов, и формируемых для разработки выходных.
На базе входных данных, а точнее «накладная из отделения» согласно