BC/NW 2013, №2 (23):10.3
РАЗРАБОТКА ГРАФИЧЕСКОГО ИНТЕРФЕЙСА АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ ВЕДЕНИЯ ПРОЕКТОВ В СООТВЕТСТВИИ С PMBOK
Пирогова М.А., Хохлова О.И.
(ФГБОУ ВПО «Национальный исследовательский университет «МЭИ», Москва, Россия)
Эффективность и устойчивость деятельности любой современной организации во многом определяется качеством осуществляемых управленческих мероприятий в сфере руководства проектным циклом [1]. Для систематизации знаний в области управления проектами было создано множество национальных и международных предложений по стандартизации. В процессе практического освоения выяснилось, что наиболее полным и универсальным является набор предложений по стандартизации управленческой деятельности для широкого круга типовых задач, разработанный PMI[2]. Этот свод постоянно уточняется и совершенствуется, регулярно издаются актуальные версии этого свода, известного под названием PMBOK (A Guide to the Project Management Body of Knowledge).
Практическая ценность предложений PMBOK для управленческой деятельности в настоящее время уже не дискутируется, а на повестку дня выносится вопрос широкого внедрения этих предложений для автоматизации управленческой деятельности в точном соответствии с этими рекомендациями PMI. В связи с этим, актуальной является задача разработки графического интерфейса и прототипа автоматизированной системы управления проектом в соответствии с PMBOK. Графический интерфейс предназначается для облегчения организации и синхронизации совместной работы проектных менеджеров и исполнителей по направлениям, для управления выполнением совокупности всех необходимых процессов по управлению проектом. В данной статье описываются принципы построения графического интерфейса автоматизированной системы управления проектом в соответствии с PMBOK.
Управление проектами – это приложение знаний, навыков, инструментов и методов к операциям проекта для удовлетворения требований, предъявляемых к проекту. Управление проектами, как это определяется в PMBOK, выполняется с помощью применения и интеграции логически сгруппированных 42 процессов управления проектами, объединенных в 5 групп процессов: инициация проекта, планирование проекта, исполнение проекта, мониторинг проекта и управление проектом, завершение проекта [2].
Рис.1. Взаимодействие между группами процессов управления проектом
Все вышеописанные группы процессов взаимодействуют через соответствующие документы между собой и с заинтересованными сторонами проекта, такими как: инициатор или спонсор проекта, предприятие (организация), заказчик, продавцы. Каждая группа процессов включает составляющие ее процессы, которые связаны соответствующими входами и выходами. Процесс – это набор взаимосвязанных действий и операций, осуществляемых для получения заранее определенного продукта, результата или услуги. Каждый процесс характеризуется своими входами, инструментами и методами, и конечными выходами [2].
Каждый сотрудник обеспечивает жизнедеятельность конкретных бизнес-процессов, непосредственно участвуя в них. Обязанности, область ответственности, критерии успешной деятельности сотрудника сформулированы и имеют смысл лишь в контексте конкретной задачи или процесса.
Процессы управления проектами можно распределить по 9-ти областям знаний по управлению проектами: управление интеграцией проекта, управление содержанием проекта, управление сроками проекта, управление стоимостью проекта, управление качеством проекта, управление человеческими ресурсами проекта, управление коммуникациями проекта, управление рисками проекта, управление поставками [2]. Таким образом, каждый из процессов управления проектом относится к одной из групп процессов и к одной из областей знаний и представляется в виде планшета, в котором отображены: область знаний, наименование процесса, перечислены входы, инструменты и методы, а также выходы (см. рис. 2).
Рис.2. Планшет одного из процессов управления проектом
Каждой из 42 задач соответствует свой интерфейс, внешний вид которого определяется списком входов, выходов и инструментов и методов задачи, а также состоянием выполнения заданий. Эти интерфейсы однотипны, имеют одинаковую структуру, но различное содержание. По каждой из задач определена роль исполнителя, например, роль по процессу 6.5 - "Разработчик расписания". Дополнительно разрабатывается интерфейс администрирования, который отслеживает использование системных ресурсов.
Разработка интерфейса администрирования.
Разработана структура данных, предназначенная для ведения списка проектов организации и списка сотрудников организации с соответствующими должностями. Текстовый файл Projects.txt содержит список названий проектов организации, отделенных разделителем - специальным тэгом, позволяющим программе лексического разбора входного потока правильно разобрать текст. Например:
<name>Имя проекта 1</name>
<name>Имя проекта 2</name>...
Текстовый файл Users.txt - список сотрудников организации. Он содержит множество наборов ФИО - Должность - Пароль, также отделенных разделителями. Например:
<employ>
<fio>Иванов Иван Иванович</fio>
<job>главный бухгалтер</job>
<pwd>Пароль</pwd>
</employ>...
В дальнейшем планируется разработать внешний вид интерфейса администрирования и дополнить его функционал.
Разработка пользовательских интерфейсов.
Создается текстовый файл Roles.txt, устанавливающий соответствие между сотрудниками и их ролями в конкретном проекте. Он имеет вид:
<item>
<proj>Название проекта</proj>
<fio>ФИО сотрудника</fio>
<role>Имя роли</role>
<task>Имя файла задания</task>
</item>...
Имя файла задания представляется в виде N_xx, где N - номер области знания (от 4 до 12 по [2]), а N_xx соответственно код в списке задач области знания. На первом этапе в этом файле содержится только информация для роли "Разработчик Устава Проекта", т.к. назначение остальной команды проекта входит в его обязанности. Затем при выполнении задачи 4.1. "Разработка Устава Проекта" в соответствии с [2], помимо разработки непосредственно Устава, дополняется файл Roles.txt. Таким образом, файл Roles.txt позволяет отслеживать назначения сотрудников на определенную роль проекта.
Рис.3. Интерфейс пользователя при входе в систему
При запуске приложения в выпадающий список "Название проекта" заносятся все названия проектов из файла Projects.txt.На начало ввода поля "Выбрать роль" и "Введите пароль" неактивны, т.к. сначала нужно получить доступ к проекту. При нажатии кнопки "Доступ к проекту" просматривается файл Roles.txt и проверяется, работает ли данный сотрудник над данным проектом. Если соответствующая пара значений не найдена, то выдается сообщение об ошибке. Если пара значений найдена, то соответствующее Имя роли заносится в выпадающий список "Выбрать роль". Затем происходит поиск дальше по файлу этой же пары значений, т.к. у одного сотрудника может быть несколько ролей в проекте.
После выбора пользователем роли и ввода пароля, выполняется действие "Войти в систему". При этом в файле Roles.txt выполняется поиск соответствующей записи, заключенной в <item>... </item> по имени проекта, пользователя и выбранной роли. Затем следует проверка пароля по файлу Users.txt. Если пароль верный, происходит считывание имени файла N_xx, и на экран вызывается окно, вид которого определяется содержимым этого файла. Если неверный - появляется сообщение "Неверный пароль".
В папке каждого проекта существует текстовый файл Files.txt со списком всех документов, которые являются входами и/или выходами задач проекта. Его вид:
<file>
<nom>Номер документа в списке</nom>
<ver>Текущая версия документа</ver>
<in>
<task><N_xx></task>...
</in>
<out>
<task><N_xx></task>...
</out>
</file>...
Здесь после директивы in перечислены коды задач, для которых данный документ находится в списке входов, а после out - в списке выходов. Все создаваемые документы носят названия типа File_nom_ver.txt. Здесь File - стандартное начало имени файла, nom - номер в общем списке, ver - текущая версия.
Для каждой задачи есть текстовый файл N_xx.txt. Он имеет вид:
<in>
<kod>N_xx_1_n</kod>
<nom>Номер документа в Files.txt</nom>
<ind1>Состояние индикатора</ind1>
<capt>Строка с названием входа</capt>;
</in>...
<method>
<kod>N_xx_2_k</kod>
<ind>Состояние индикатора</ind>
<capt>Строка с названием метода</capt>;
<addr>Адрес ехе-файла</addr>
</method>...
<out>
<kod>N_xx_3_m</kod>
<nom>Номер документа в Files.txt</nom>
<ind2>Состояние индикатора</ind2>
<capt>Строка с названием выхода</capt>;
</out>...
Здесь N_xx_1_n, N_xx_2_k, N_xx_3_m - коды входа под номером n, метода под номером k и выхода под номером m задачи N_xxсоответственно.
Рис.4. Вид интерфейса пользователя для работы с задачей проекта
Источники - это входы задачи. Состояние источника отображается цветом: зеленый (готов), красный (не готов), желтый (в разработке), фиолетовый (обновлен). Кнопка "Открыть" доступна только если актуально состояние "готов" или "обновлен". Если кнопка активна, то при нажатии на нее в файле N_xx.txt находится номер соответствующего документа в общем списке. Затем в файле Files.txt по этому номеру определяется версия и открывается документ с данной версией. Затем в файле N_xx.txt проверяется состояние индикатора открытого документа, если состояние "обновлен", то сбрасывается обратно в состояние готов.
Инструменты и методы.
Кнопки "Выполнить" становятся активны только когда все источники в состоянии "готов" или "обновлен". Состояния индикаторов: красный (не выполнено), зеленый (выполнено), серый (не активно - не все источники готовы). При нажатии кнопки "Выполнить" в файле N_xx.txt находится адрес соответствующего ехе-файла, и этот файл запускается. Индикатор метода переходит в состояние "выполнено".
Индикатор введен для того, чтобы пользователь видел, какие методы он применял, а какие еще нет. Чтобы начать применять методы заново предусмотрена кнопка сброса индикаторов в состояние "не выполнено".
Каталог рабочих документов.
Для просмотра файлов, полученных в результате выполнения методов пользователю достаточно открыть рабочий каталог.
Список заданий - это выходы задачи. Состояния индикаторов: красный (уже закреплено за сотрудником), желтый (в разработке), зеленый (выполнено), серый (не активно - не все источники готовы).
Кнопки "К выполнению" становятся активны, когда индикаторы всех входов находятся в состоянии "готов" или "обновлен". При нажатии кнопки "К выполнению":
1) В файле N_xx.txt находится номер соответствующего документа в общем списке и по нему в Files.txt находится текущая версия. Если версия -1, т.е. документ еще не создавался, то создается документ. Если документ уже создавался другим пользователем или задание выполняется повторно, то открывается файл по номеру и версии.
2) В файле N_xx.txt у соответствующегоN_xx_3_m индикатор переводится в состояние "в разработке";
3) Из Files.txt считываются имена задач, для которых данный файл является входным (в тэгах <in></in>). Открываются файлы этих задач (N_xx.txt). В них по номеру находится нужный вход и его индикатор переводится в состояние "в разработке". Файлы закрываются.
4) Становится активной соответствующая кнопка "Выполнено".
При нажатии на кнопку "Выполнено":
1) В файле N_xx.txt у соответствующегоN_xx_3_m считывается номер, в Files.txt версия, соответствующая данному номеру увеличивается на 1. Документ сохраняется с новой версией. Соответствующий индикатор переводится в состояние "выполнено".
2) Из Files.txt считываются имена задач, для которых данный файл является входным. Открываются файлы этих задач (N_xx.txt). В них по номеру находится нужный вход, и его индикатор переводится в состояние "готов" (если версия документа 0) или "обновлен" (если версия выше 0). Становится активной соответствующая кнопка "Открыть". Затем в каждом файле N_xx.txt проверяются состояния индикаторов всех входов. Если все они в состоянии "готов" или "обновлен", то над задачей можно начинать работать. Поэтому:
a. Проверяются состояния индикаторов всех методов. Если они в состоянии "не активно", то переводятся в "не выполнено". Активируются кнопки "Выполнить".
b. Проверяются индикаторы всех выходов. Если их состояние "не активно", то переводятся в "не взято на выполнение". Активируются кнопки "К выполнению".
3) Закрываются все открытые файлы N_xx.txt.
Описанные в данной статье подходы построения графического интерфейса пользователя планируется в дальнейшем применить для всех 42 процессов 9 областей знаний процессного менеджмента, определенных в PMBOK.
Литература
1. Краюшкин В. А., Лешихина И. Е., Пирогова М.А. Система PLM - корпоративная информационная среда предприятия по автоматизации совокупности процессов проектирования, изготовления, сопровождения и утилизации изделия. Научно-технический журнал «Информационные технологии в проектировании и производстве», №1, 2010 г., с. 3 – 23.
2. «A Guide to the Project Management Body of Knowledge», edition 4, Project Management Institute Inc., 2008. – 459 p.