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.