73
Рисунок 23. Сетевой график для позднего времени начала работ.
На основании полученных на схемах результатов о раннем и позднем
времени начала выполнения работ по внедрению автоматизированной системы
управления проектами, составим таблицу 14, в которой для каждой работы
впишем раннее время выполнения работы, позднее время выполнения работы, и
вычислим резерв времени, который равен разности между двумя временами
начала работ по каждой из задачи.
Работы, которые лежат на критическом пути реализации проекта
внедрения, характеризуются тем, что полученный резерв времени в данных
работах равен нулю. Это говорит нам о том, что изменение сроков начала всех
перечисленных работ напрямую влияет на сдвиг сроков всего проекта.
Таблица 14. Таблица резервов времени при раннем и позднем временах начала
работ.
№
работы
Раннее время
Позднее время
Резерв времени
0
0
0
0
1
1
9
8
2
1
1
0
3
11
11
0
4
31
31
0
5
31
62
31
6
77
77
0
7
79
79
0
8
109
109
0
109-30=79
79-2=77
77-46=31
Min(31-20;62-20)=11
77-15=62
Min(9-1;1-1)=0
11-10=1
11-2=9
0
2
3
1
4
5
6
7
8
74
На основании расчетной таблицы, требуется составить финальный сетевой
график (рисунок 24), на котором мы отобразим критический путь работ проекта
по внедрению автоматизированной системы.
Рисунок 24. Итоговый сетевой график - критический путь.
В итоге, исходя из сделанных расчетов, можно сформулировать
рекомендации для руководителя отдела и менеджера проекта о том, что задачи
разработки системных требований системы и разработки инструкции для
пользователей данного проекта не лежат на критическом пути проекта, что в свою
очередь позволяет внести изменения сроков или загруженности ресурсов в
данных работах в случае необходимости при возникновении трудностей в
задачах, которые лежат на критическом пути проекта.
Данные не критические задачи могут послужить руководителю отдела
дополнительным ресурсом при ликвидации некоторых рисков проекта. Важно
понимать, что сроки начала всех остальных работ нельзя сдвинуть из-за их
влияния на длительность и успешность выполнения проекта внедрения в целом.
2.2.2 Формирование команды проекта автоматизации
Для выполнения проекта по внедрению автоматизированной системы
управления проектами RedMine на уровнях отделов и секторов структуры ГНЦ
РФ ФГУП «НАМИ», требуется формирование опытной надежной компетентной
команды, способной осуществить внедрение и доработку системы с высоким
уровнем надежности за максимально короткий срок.
0
2
3
1
4
5
6
7
8
75
Для формирования команды изучим учебное пособие «Управление
персоналом» [7] автора В.В. Кафидова, согласно методике которого требуется
понимание в какой последовательности, какие действия должны выполняться,
чтобы процесс внедрения и доработки происходил корректно и безболезненно для
предприятия.
Необходимо исключить некорректное формирование структуры проекта
внедрения, а компетентность специалистов по доработке и внедрению
автоматизированной системы должна произвести безошибочный расчет
требуемых ресурсов и усилий команды.
Существую различные методологии формирования команды ИТ-проекта.
Наиболее популярной и эффективной выглядит методология Microsoft Solutions
Framework (MSF), согласно которой требуется сформировать шесть ролевых
кластеров команды внедрения и доработки системы:
1. Управление продуктом (product management),
2. Управление программой (program management),
3. Разработка (development),
4. Тестирование (test),
5. Удовлетворение потребителя (user experience)
6. Управление выпуском (release management).
Функции кластера «Управление продуктом» заключаются в полном
понимании целей внедряемой системы управления проектом, понимании перечня
и целей доработок системы, применительно к рассматриваемому предприятию.
Задачи сотрудников кластера управления продуктом должны на этапе
формирования требований к системе определить компромиссы между
параметрами «Возможности продукта – Время – Затраченные ресурсы».
Функции кластера «Управление программой» – управление внедрением и
доработкой системы RedMine с целью получения готового продукта для
предприятия в четко обозначенные сроки. Специалисты кластера управления
программой должны регулировать взаимоотношения между сотрудниками
команды внедрения, сформулировать спецификацию доработок информационной
системы, следить за календарным графиком проекта, на должном уровне
76
организовывать управление рисками проекта внедрения и доработки
автоматизированной системы управления проектом.
Специалисты кластера «Разработка» определяют детали процесса
внедрения и доработки системы управления проектами: оценивают необходимое
время, реализуют разработку системы, контролируют функционирование
отдельным подсистем и элементов, подготавливают систему к внедрению,
проводят консультации по технологическим вопросам.
Кластер «Тестирование» состоит из специалистов, в задачи которых
включены: обеспечение обнаружения дефектов и коллизий системы, разработка
типов и методов тестирования, планов тестирования системы, непосредственно
осуществление тестирования.
Функции специалистов из кластера «Удовлетворение потребителя» состоят
в предоставлении интересов пользователей системы управления проектами
внутри команды внедрения и доработки системы. Специалисты данного кластера
занимаются организацией работы с требованиями пользователей системы,
определением компромиссов по удобству использования и потребительским
качествам автоматизированной системы управления проектами RedMine. Одной
из важных функций данного кластера является разработка учебных материалов и
обучение руководителей отделов и разработчиков ПО пользованию системой
управления проектами.
Функции кластера «Управление выпуском» заключаются в организации
снабжения проектной группы, организации внедрения автоматизированной
системы на предприятии, компромиссы удобства сопровождения системы,
логистическое обеспечение проектной группы.
Описанные шесть ролевых кластеров модели MSF организуют направления
деятельности специалистов и их цели. Согласно данной модели, не требуется
назначение каждому кластеру отдельных сотрудников, однако модель запрещает
совмещать задачи некоторым специалистов кластера с задачами другого кластера
(например, команда разработчиков не может быть объединена с каким-либо
другим кластером, не могут быть объединены роли кластеров, имеющие
предопределенные конфликты интересов).
77
Методология Microsoft Solutions Framework позволяет объединение ролей в
проекте согласно рисунку 25:
Рисунок 25. Допустимое объединение ролей по MSF.
Исходя из стандарта MSF, команда внедрения и доработки
автоматизированной системы управления проектами RedMine на предприятии
ГНЦ РФ ФГУП «НАМИ» будет формировать следующую структуру.
В таблице 15 представлено разрешаемое стандартом MSF объединение
ролей для минимизации количества задействованных специалистов в проекте
внедрения автоматизированной системы управления проектами RedMine.
Таблица 15. Структура команды внедрения системы на предприятии.
Кластер (роль) по стандарту MSF
Должность сотрудника из проекта
внедрения и доработки системы
Управление продуктом (product
management)
Руководитель проекта
Управление программой (program
management)
Руководитель отдела
Разработка (development)
Разработчики системы (2 человека),
IT-специалисты (2 человека),
Специалисты службы безопасности (2
человека)
78
Продолжение таблицы №15.
Кластер (роль) по стандарту MSF
Должность сотрудника из проекта
внедрения и доработки системы
Тестирование (test)
Руководитель проекта,
Руководитель отдела
Удовлетворение потребителя (user
experience)
Руководитель отдела
Управление выпуском (release
management)
Руководитель отдела
Таким распределением должностей сотрудников проекта внедрения и
доработки системы по кластерам, согласно стандарту MSF, удалось добиться
минимизации числа вовлеченных в проект сотрудников предприятия, тем самым
удешевив цену проекта.
2.2.3 Средства коллективной работы над проектом автоматизации
Для внедрения системы управления проектами на предприятии ГНЦ РФ
ФГУП «НАМИ» нет необходимости пользоваться средствами коллективной
разработки (СКР). По причине того, что процесс внедрения и доработки системы
безопасности RedMine не длится месяцами, а на предприятии отсутствуют
установленные средства коллективной разработки в принципе, и отсутствует
дополнительный бюджет на СКР системы, было принято решение обойтись без
них.
СКР обычно используются на предприятиях, где для решения одной задачи
привлекаются сразу несколько специалистов. Для распараллеливания из работ, на
предприятие вводят, как правило, коммерческие СКР. Внедрение СКР в
организации оправдано только в том случае, если в каком-то определенном
процессе задействовано большое число специалистов.
Для внедрения на предприятии автоматизированной системы управления
предприятием RedMine, привлечено менее 10 человек из разных областей и с
79
конкретными определенными задачами, длительность процессов которых крайне
мала. Это веская причина не использовать СКР при внедрении RedMine.
2.3 Информационное обеспечение задачи
2.3.1 Информационная модель и её описание
Информационную модель автоматизированной системы управления
проектами RedMine можно представить в виде связей входных параметров
системы к выходным параметрам линиями, проходящими через справочники и
таблицы базы данных. Схематично модель автоматизированной системы
управления проектом выглядит следующим образом (представлена на рисунке
26):
80
Разработчик ПО
Администратор
ИС
Спр «Права польз.»
Управление
пользовате-
лями
Спр* «Права польз.»
Спр* «Пользователи»
Управление
проектом
Спр «Пользователи»
Руководитель отдела
Управление
проектом
Т* «Задачи»
Т* «Статусы задач»
Создание
проекта
Спр* «Проекты»
Спр «Проекты»
E-mail
оповещение
руководителя
отдела
E-mail
оповещение
разработчика ПО
Т* «Диаграмма Ганта»
Ф «Диаграмма Ганта»
Т «Задачи»
1
2
3
4
Т* «Аутентификация»
Разработчик ПОРуководитель отдела
Т «Аутентификация»
Т «Статусы задач»
Рисунок 26. Информационная модель.
Область 1 отображает взаимодействие пользователя (Разработчика ПО,
исполнителя) с автоматизированной системой управления проектом в части
просмотра поставленных руководителем проекта задач и возможностью
редактировать статус задачи – например, отображать текущий статус выполнения
разработки ПО. Наглядно видно, что при изменении исполнителем статуса задачи
(«Т* «Статусы задач»»), руководитель отдела получит E-mail оповещение.
Разработчик ПО может войти в систему двумя различными способами: по заранее
зарегистрированному администратором системы аккаунту, или используя LDAP-
аутентификацию, что наглядно демонстрирует связь из формы «Управление
проектом» в изменяющуюся от типа авторизации таблицу «Т*
«Аутентификация»».
81
Область 2 на модели демонстрирует возможности руководителя отдела
управлять процессом создания новых задач и контролирования статуса
выполнения текущих задач исполнителя. Руководитель отдела (как и любой
исполнитель) может в любой момент сформировать *.PDF-файл в виде
диаграммы Ганта с последующей распечаткой, например, для формирования
ежемесячных отчетов своему руководству.
Область 3 на модели отображает процесс конфигурирования
автоматизированной системы управления проектами RedMine в части добавления
новых пользователей, изменении прав зарегистрированных пользователей,
формировании новых проектов. Форма «Управление пользователями»
предполагает выполнение трех видов операций администратора системы:
Добавление новых пользователей
Изменение прав зарегистрированных пользователей
Создание новых проектов
При этом, понятно, что каждый пользователь может иметь несколько
различных ролей в разных проектах, что отражено входящей связью из «Спр*
«Проекты»» в «Спр «Проекты»».
Область 4 демонстрирует выходные параметры информационной системы:
Измененные руководителем отдела таблицы «Т* «Задачи»»
Обновленные разработчиком ПО статусы таблицы «Т* «Статусы задач»»
Измененная таблица «Т* «Диаграмма Ганта»», из полей которой
сформировывается файл «Ф «Диаграмма Ганта»»
Отправка E-mail сообщений разработчику ПО и руководителю отдела об
измененных состояниях прогресса проекта.
Согласно построенной модели, можно сделать вывод, что в системе
управления проектами на предприятии, в базе данных созданы и опубликованы
три справочника:
Справочник «Пользователи» (Спр «Пользователи» на модели)
Справочник «Проекты» (Спр «Проекты» на модели)
Справочник «Права пользователей» (Спр «Польз.» на модели)
82
2.3.2 Характеристика нормативно-справочной, входной и оперативной
информации
В задачи администратора системы в процессе функционирования системы
управления проектами на предприятии, входят регулирование состава
пользователей системы – добавление пользователей, изменение их прав доступа
к разным проектам. Администратор имеет полномочия создавать новый проект в
автоматизированной системе управления проектами RedMine.
Для добавления новых пользователей или изменении прав доступа к
проекту уже существующих пользователей системы, администратору доступна
форма «Управление пользователями» («Настройки» - «Участники») Приложение
2, рисунок 1.
На данной форме у администратора есть права на создание новых
пользователей для проекта, удалении существующих пользователей, изменении
прав доступа уже зарегистрированных пользователей: Приложение 2, рисунок 2.
Далее представлено окно «Новый участник» формы «Управление
пользователями»: Приложение 2, рисунок 3. В данном окне администратор
проекта может добавить к проекту новых пользователей: руководителей отделов
или проектов (галкой «Manager»), или разработчиков ПО (галкой «Developer»).
Система предоставления доступа пользователям к проектам устроена таким
образом, что все пользователи системы (руководители проектов/отделов,
разработчики ПО) разделены на две большие группы:
Группа «Manager». В данную группу вносятся пользователи с
повышенными правами на управление проектами: руководители проектов
и руководители отделов. Данная группа предоставляет пользователям
права на создание, удаление и изменение задач, изменение статусов задач.
Группа «Developer». В эту группу вносятся пользователи с пониженными
правами: разработчики ПО, тестировании ПО, испытатели ПО на объектах.
Пользователи данной группы имеют права в системе управления проектами
только на изменение статус проектов и отображение статусов проектов
своему руководителю: написание комментариев к задачам, прикладывание
файлов.