42
Цель этой фазы состоит в образовании и сплочении проектной
группы на базе создания единого видения. Проектная группа должна четко
понимать, что нужно сделать для клиента и поставить цель.
В идеологии MSF команда проекта разбивается на шесть
участников, каждому из которых отводится свое значение в проекте,
обязанности и ответственности. Данные роли в MSF именуются
кластерами, за каждым из которых может стоять не один человек. В
каждой фазе для каждого ответственного лица, закреплённого за
кластером, фиксируются установленные задачи.
Рассмотрим задачи, выполняются при разработке концепций.
Управление продуктом регулирует концептуальный и логический дизайн;
функциональная спецификация; сводный план и сводный календарный
график проекта; бюджет. Кластер «Управление программой» определяет
цели дизайна, концепцию решения, структуру проекта. Кластер
«Разработка» оценивает технологии; логический и физический дизайн;
план и календарный график разработки; смету разработки.
Кластер «Удовлетворение потребителя» анализирует сценарии и
примеры применения, пользовательские требования, требования
локализации и общедоступности; пользовательскую документацию и план
обучения.
Кластер «Тестирование» оценивает дизайн; требования
тестирования; план и календарный график тестирования.
Кластер «Управление выпуском» изучает эксплуатационные
требования; план и календарный график пилотного и финишного
внедрения. Так или иначе, в рамках разработки и эксплуатации проекта
силами ИТ-штата использовать шесть и более человек для фоновой задачи,
бюджет которого ограничен только премией, совсем нецелесообразно.
Ввиду этого задачи кластеров объединяются, и из них выделяются два
ответственных лица, составляющих команду проекта: программист и
менеджер проекта.
43
Выходными данными и результатами этой фазы является подбор
кандидатов и определение самых подходящих из них к установленным
задачам на исполнение двух ролей, т.е. создание команды, несмотря на то,
что включает только двух человек. В данном проекте на этом этапе
устанавливается состав и роли участников. Помимо всего прочего,
составлена смета по времени и планирование бюджета этого проекта.
Дальше идет фаза планирования. Ключевой её целью является
составление планов проекта. Она включает подготовку проектной группой
функциональной спецификации, создание дизайнов, рабочих планов,
оценку проектных затрат и сроков проектирования разнообразных
компонентов проекта.
Процесс проектирования – это систематический метод
продвижения от абстрактных концепций к определенным техническим
деталям.
Результатами фазы планирования являются: функциональная
спецификация, описание вероятных рисков, сводный план и календарный
график проекта, развернутые среды проектирования и тестирования. От
программиста здесь необходим обзор и выбор языка программирования, на
котором будет выполнение решение, а также календарный план по срокам
и графикам проектирования.
Далее идет фаза разработки. Здесь проектная группа сосредоточена
на формировании компонента решения (как документацию, так и
программный код). Но определенная часть данной деятельности может
продолжаться и на фазе стабилизации, но, если такую потребность
определили в ходе тестирования. Также здесь разрабатывается
инфраструктура.
Необходимо сказать о том, что активность проектной команды
здесь не ограничивается написанием кода – все ролевые кластеры
участвуют в проектировании и тестировании решения.
44
Результатами на данной фазе являются: исходный и исполнимый
код приложений, скрипты установки и конфигурирования, окончательное
описание функционала выполняемого решения, материалы поддержки
решения, сценарии тестов. В данной ситуации программисту нужно
разработать программу-клиент, а также написать полную программу к ней.
Руководителю проекта нужно сформировать работоспособную среду.
Далее идет фаза стабилизации. Здесь осуществляется тестирование
проектируемого решения. В данном случае внимание сосредоточено на его
применении в реалистичной модели производственной среды. Проектная
группа занимается приоритезацией и ликвидацией ошибок, а также
подготовкой решения к выпуску.
Чаще всего в начале данной фазы скорость идентификации ошибок
командой тестирования быстрее скорости их устранения командой. Нельзя
точно предположить то, сколько будет найдено ошибок, а также то время,
за которое их получится устранить. Но есть 2 статистических признака,
помогающих проектной группе понять уровень стабилизации решения.
Это точка конвергенции. В ней виден существенный прогресс в
ликвидации ошибок, т.е. скорость их устранения становится быстрее
скорости идентификации. Т.к. число найденных, но не ликвидированных
ошибок способно меняться даже после своего уменьшения, конвергенция
представляет собой все же тенденцию, а не установленный временной
промежуток. Следуя за этой вехой, число активных ошибок должно
уменьшаться и далее, дойдя до нуля. Точка конвергенции позволяет
проектной группе установить, что процесс тестирования скоро завершится.
Результатами данной фазы являются: окончательный продукт,
документация выпуска, материалы поддержки решения, результаты и
инструментарий тестирования, исходный и исполнимый код приложений,
проектная документация. На этой стадии программистом исправляются
ошибки в создаваемой им программе, компилируется версия «релиз-
кандидат» и после отсутствия критических ошибок по всем веткам работы
45
программы формируется итоговая сборка реализуемого кода, вместе с
этим дополняется документация к работе с программой. Руководитель
здесь набирает группу тестирования, которые будут использовать эту
программу ежедневно и тестирует все ветки работы по созданным ранее
сценариям и создает дополнения, которые можно будет выполнить в
следующей версии.
Далее идет фаза внедрения. Здесь проектная группа внедряет
технологии и элементы решения, стабилизирует его, передает работу
персоналу поддержки и сопровождения и получает согласование проекта
клиентом. По окончании данной фазы проектная группа осуществляет
анализ осуществленной деятельности и удовлетворенности клиента.
В течение данной фазы по ходу переноса элемента решения из
среды тестирования в производственную среду могут идти меры по
стабилизации решения.
Результаты данной фазы: ИС эксплуатации и
поддержки, процедуры и процессы, базы знаний, отчеты, журналы
протоколов, массивы информации и программный код, созданные в
процессе проекта. Здесь руководитель окончательно внедряет систему в
работу, устанавливает программный продукт на ПК, обучает сотрудников
работе с системой. Затем пользователем высылается новый регламент
деятельности ИТ-отдела и данные о новой логике анализа заказов с
просьбой за 7 дней дать ответ об установленных изменениях в ИТ-сервисе.
Внедрение является общим понятием и для него есть различные
стратегии реализации, которые находятся в зависимости от срока
исполнения и качества итоговой ИС. Есть 4 ключевые стратегии внедрения
системы:
- параллельная стратегия – в данном случае единовременно
функционируют старая (ручная) и новая система, а их выходные
документы сопоставляются. Если они долго согласовываются, то
реализуется переход на новую систему;
46
- скачок – резкий переход от старой системы к новой без каких-
либо проверок. Тут реализуется полный отказ от старой системы;
- пилотный проект – самая популярная стратегия. Это тактика
скачка, но используемая при ограниченном количестве процессов. Сфера
использования стратегии – небольшой участок деятельности. Данный
подход уменьшает риск и обладает максимальной надежностью;
- узкое место – малая часть производственного процесса. В данном
случае план внедрения реализуется только для такого места, а также для
людей, работающих в нем.
В работе выбрана стратегия «Пилотный проект». Будет
осуществляться полный переход к автоматизированной системе обработке
заявок службой технической поддержки. Сферой использования внедрения
будет отдел, состоящий из 5 сотрудников службы сопровождения АСУД.
Данный подход не повлияет на работу всей ИС, а только автоматизирует
рутинную часть. Надежность такого внедрения аргументирована четким
соответствием порядка регистрации и анализа обращения установленному
регламенту.
В работе охарактеризовать стратегию внедрения можно как
стратегию узкого места, поскольку этот проект автоматизирует процесс,
связанный с работой сотрудников службы технической поддержки, а
узким местом является скорость ручной обработки заявок, согласования их
и подробного уточнения.
Затем идет этап эксплуатации разработанного программного
продукта. По инструкции такой программы нужно отслеживать ее работу
каждые 2 часа, поскольку она способна зависнуть или обработать не все
заявки по e-mail ввиду отсутствия логики анализа такого типа заявки, в
такой ситуации письмо вернется обратно на почтовый ящик с пометкой в
теме письма «Не обработано». Такой риск нужно анализировать
ежемесячно и выносить решение о необходимости доработки логики
программы.
47
2.2. Информационная модель и ее описание
В качестве входной информации используются следующие
документы:
1. данные пользователя;
2. письмо (проблема, ошибка);
Данные пользователя указываются при регистрации его в системе.
При этом из нее используются следующие реквизиты:
1. ФИО;
2. Дата рождения;
3. Наименование филиала.
В системе разработан ряд экранных форм, среди которых можно
выделить:
Начальная страница – появляется при входе сотрудника службы
сопровождения АСУД в 1C: Itilium;
Форма регистрации обращения – содержит вкладки со всеми
необходимыми кнопками, открывающими справочники;
Форма просмотра действующих заявок с текущими результатами по
ним.
В системе предусмотрены следующие справочники, которые также
будут отображены через экранные формы:
1. Справочник «Клиент» («Инициатор);
2. Справочник «Классификация»;
3. Справочник «Ответственный» («Рабочая группа»);
4. Справочник «Оператор» («Источник»);
5. Оперативная таблица обращений «Начальная страница».
В таблице 6 представлены основные требования к справочникам
системы.
Таблица 7
Основные тредования к справочникам
48
Название
справочн
ика
Ответствен
ный за его
ведение
Средний
объём
справочн
ика в
записях
Среднюю
частоту
актуализа
ции
Средний
объем
актуализа
ции (%)
Клиент
Администра
тор
500 строк
1раз в
месяц
5%
Классифик
ация
Администра
тор
100 строк
1раз в
месяц
15%
Ответствен
ный
Администра
тор
50 строк
1 раз в
квартал
100%
Оператор
Администра
тор
50 строк
1 раз в
квартал
100%
В таблицах 8-12 представлены составы реквизитов справочников.
Таблица 8
Состав справочника «Клиент»
№
Реквизит
Назначение
1
Код
Необходим для присвоения уникального кода
записи в базе данных
2
ФИО
Фамилия и инициалы пользователя
3
Дата рождения
Дата рождения пользователя
4
Филиал
Название рабочего филиала пользователя
5
Подразделение
Название рабочего подразделения
пользователя
Таблица 9
Состав справочника «Классификация»
№
Реквизит
Назначение
1
Код
Необходим для присвоения уникального кода
записи в базе данных
2
Тип
Необходимо выбрать, исходя из описания
проблемы
3
Услуга
Необходимо выбрать, исходя из описания
проблемы
4
Состав услуги
Необходимо выбрать, исходя из описания
проблемы
Таблица 10
Состав справочника «Ответственный»
№
Реквизит
Назначение
1
Код
Необходим для присвоения уникального кода
записи в базе данных
2
ФИО
Фамилия и инициалы ответственного
исполнителя
49
4
Рабочая группа
Наименование рабочей группы ответственного
исполнителя
Таблица 11
Состав оперативной таблицы обращений «Начальная
страница»
№
Реквизит
Назначение
1
Код
Необходим для присвоения уникального кода
записи в базе данных
2
Дата
Дата поступления/обработки заявки
3
ФИО клиента
ФИО клиента
4
ФИО оператора
ФИО оператора
5
ФИО
ответственного
исполнителя
ФИО ответственного исполнителя
6
Состояние
Статус обращения (В работе)
7
Сроки
Сроки выполнения обращения
8
Классификация
Тип обращения
9
Описание
Описание проблемы
Таблица 12
Состав справочника «Оператор»
№
Реквизит
Назначение
1
Код
Необходим для присвоения уникального кода
записи в базе данных
2
ФИО
Фамилия и инициалы оператора
3
Рабочая группа
Наименование рабочей группы оператора
4
Должность
Наименование должности
Результатной для задачи автоматизации обработки заявок является
следующая информация:
- Принятия в Работу обращения;
- Назначение Ответственного исполнителя;
- Зарегистрированное обращение;
- Отчет обработанных обращений
Таблица 13
Характеристика «Зарегистрированное обращение»
№
Показатель
Содержание
1
Название документа
Зарегистрированное обращение
2
Реквизитный состав
1.
ID
2. Номер обращения
50
3.
ФИО клиента
4. ФИО оператора
5. ФИО ответственного
исполнителя
6. Состояние обращения
7. Сроки
8. Описание проблемы
9. Описание решения
10. Дата
поступления/создания
обращения
3
Частота формирования
50 раз в сутки
4
Предназначение (кому
предназначен)
Для пользователя, клиента и
администратора
5
Формируется на основе
Формируется на основе
поступающих данных, справочника
клиенты, справочника
ответственного исполнителя,
справочника оператора.
Таблица 14
Характеристика «Отчет обработанных обращений»
№
Показатель
Содержание
1
Название документа
Отчет обработанных обращений
2
Реквизитный состав
1.
ID
2. Номер обращения
3. ФИО клиента
4. ФИО оператора
5. ФИО ответственного
исполнителя
6. Состояние обращения
7. Сроки
8. Описание проблемы
9. Описание решения
10. Дата
поступления/создания
обращения
3
Частота формирования
1 раз в сутки
4
Предназначение (кому
предназначен)
Для, администратора
5
Формируется на основе
Формируется на основе
зарегистрированных обращений.
51
Рисунок 8 Дерево функций
Сценарий диалога сотрудника службы сопровождения АСУД при
работе с информационной системой представлен на рисунке 9.