Software & Systems

В процессах коллективной разработки сложных автоматизированных систем особое место занимает конструктивное управление организационными ресурсами, нашедшее свое нормативное представление в стандарте People Capability Maturity Model (CMM) (http://www.sei.cmu.edu/cmmi). Этот стандарт регламентирует работу сотрудников проектной организации, ориентируясь на модель профессиональной зрелости процессов CMM и адаптируя ее к процессам управления рабочей силой (work force) и ее совершенствования.

Конкретная организация на основе данного стандарта должна специфицировать свою систему компетенций, необходимых для успешной деятельности, создавать условия для материализации компетенций (подбор кадров, профессиональное обучение и т.д.), а также распределять ответственность между сотрудниками организации за использование компетенций в процессах разработки автоматизированных систем.

В настоящее время серьезное внимание уделяется спецификациям компетенций при разработке систем, к которым относятся и автоматизированные системы, интенсивно использующие ПО (Software Intensive Systems, SIS). Одним из результатов работ по спецификации компетенций яв- ляется так называемое колесо компетенций (Competence Wheel) [1], объединяющее (с позиции компетенций) 11 процессных областей по уровням зрелости, в которые собрано около 400 ключевых областей деятельности. Это колесо с аббревиатурами направлений обобщенно представлено на рисунке 1. В число направлений, например, входят бизнес-процессы (CMM-BP, Business Processes) и бизнес-модели (CMM-BM, Business Models), в рамках которых перечислены компетентности с группированием. Данные компетентности принято обязательно называть, в частности, в должностных инструкциях сотрудников организации.

Распространенной формой группирования компетенций являются роли. С каждой ролью связывают не только группу компетенций, но и инструментально-технологическое обеспечение, обслуживающее ее исполнение сотрудником (проектировщиком).

Понятие «роль» является одним из центральных в технологии Rational Unified Process (RUP), обслуживающей исполнение совокупности ролей, в которую входят роли «руководитель проекта», «системный аналитик», «архитектор» и др. [2].

Роль в рамках какой-либо технологии – это нормативная спецификация профессиональных действий, исполнение которых в инструментально-технологической среде нацелено на решение задач, приводящих к созданию определенной совокупности артефактов. За исполнением роли всегда стоит экспериментирование в процессах решения определенного круга задач, причем решения в соответствии с определенными нормативными правилами и сценариями (методиками). Полезной формой описания роли является ее представление в виде должностной инструкции, доведенной в деталях до возможности результативного и эффективного применения должностной инструкции компетентными исполнителями роли.

Реальность проектирования такова, что конкретную роль по разным причинам могут исполнять несколько проектировщиков, а конкретный проектировщик – исполнять несколько ролей. В таких условиях для юридического закрепления ответственности конкретного сотрудника проектной организации должностные инструкции персонифицируют и закрепляют в договорных обязательствах за исполнителями работ, названных в персонифицированных документах. В статье представлено автоматизированное формирование персонифицированных должностных инструкций в инструментально-моделирующей среде Working In Questions and Answers (WIQA) [3], на основе которой создается база опыта проектной организации [4].

Компетентность проектной организации

Результативность любой проектной организации во многом определяется тем, какой профессиональный опыт E*(t) ей необходим и в каком объеме E(t) этот опыт на текущий момент времени t освоен членами {Dv} коллектива K({Dv}, t). Динамика выделенных сущностей обусловлена рядом причин, в первую очередь совершенствованием производственных процессов, разработкой новых проектов и текучестью кадров, что указывает на необходимость управления уменьшением различий между E*(t) и E(t) и распределением E(t) между членами коллектива K({Dv}, t). Более того, в управлении отмеченными процессами следует учитывать не только единицы опыта E*(t), но и то, в каком количестве каждая из них необходима для решения задач организации.

В реализации отмеченного управления важное место занимает структуризация опыта E(t) с позиций его представления как компетентности проектной организации, что позволяет ввести в структуризацию элементы знаний, умений и навыков, а с их помощью специфицировать компетенции, необходимые для решения каждой из нормативных задач {ZNip} технологий {Tp}, используемых в проектной организации. Именно такой способ используется в технологии RUP для спецификации ролей, которые она поддерживает методически и инструментально.

В колесо компетенций его создателями введены названия компетенций, абстрагированные от технологий и распределенные по 11 процессным областям, обеспечивающим разработку SIS. Одна из таких областей (CMM-BP) обобщенно изображена на рисунке 2 с демонстрационными целями, без объяснения и перевода, только для того, чтобы отметить, что подобные формы существуют и удобны для моделирования направлений деятельности проектной организации с точностью до уровня должностных инструкций работников. С другой стороны, формализация задач в цепочке стратегия развития организации – положения о подразделениях – должностные инструкции работников позволяет распределить ответственность каждого отдельно взятого работника, а самое главное, ответственность закрепляется юридически и финансово. Графически источники информации для формализации задач можно представить в виде схемы (рис. 3).

Ориентация на онтологию рисунка 3 приводит к следующему представлению системы должностных инструкций: JD=S({JDp, JDc, JDd, JDwp, JDins, JDi}, t), где JDp – представление должности в оргструктуре; JDc – компетенции, необходимые для данной должности; JDd – весь набор необходимых документов для обеспечения деятельности; JDwp – множество плановых заданий; JDins – необходимый набор инструкций; JDi – используемое множество инструментов; t – время.

Позиция JDp определяется организационной структурой предприятия и связана со следующими атрибутами: уровень иерархии, функциональное подчинение, административное подчинение, функциональное управление, административное управление, задачи.

Компетенции JDc, с одной стороны, определяются соответствием процессным областям колеса компетенций, с другой – личностными качествами человека, например, стремление к лидерству, способность анализировать и решать проблемы, инициативность, инновативность, нацеленность на результат, настойчивость, работа в команде, планирование деятельности.

Каждый документ JDd однозначно определяется набором атрибутов. Приведем минимально необходимый набор: уровень иерархии выпуска документа; статус документа (нормативный, распорядительный, информационный); область использования; актуальность; назначение документа; основные термины и определения; область применения документа (кому предназначен); контролирующие органы применения документа; классификация информации, используемой при применении документа; требования к информации; источники получения информации; технология и технические средства получения (сбора), обработки, передачи, накопления и использования информации.

Плановые задания JDwp характеризуются атрибутами: источник возникновения, задача (конечный результат), срок выполнения, приемщик, ресурсы для выполнения.

Прежде всего инструкция JDins – это документ, содержащий правила, указания или руководства, устанавливающие порядок и способ выполнения или осуществления чего-либо.

Инструменты JDi определяются следующими атрибутами: объект воздействия, способ применения, решаемая задача, полезный эффект, вспомогательный материал, необходимая инструкция.

Предложенная формализация должностной инструкции представима как задача класса задач Z*. Одним из инструментов моделирования задач типа Z* является инструментальная среда WIQA.

Формирование должностных инструкций в среде процессора WIQA

Для создания персонифицированных должностных инструкций JD был разработан комплекс специализированных средств и встроен в систему WIQA.NET. К настоящему времени в WIQA.NET реализована подсистема документирования, позволяющая формировать любые документы по их шаблонам в Microsoft Word (MS Word) и шаблонам в виде дерева вопросно-ответных единиц, а на ее основе реализована подсистема формирования должностных инструкций.

Сама задача формирования должностных инструкций подразумевает, что пользователь, ответственный за выполнение данной работы, простыми действиями в системе WIQA может создать отформатированный документ MS Word, оформленный в соответствии с нормативами, установленными в проектной организации. Для реализации данной задачи были использованы возможности подсистемы документирования в сочетании с надстройкой над плагином оргструктур, в котором реализована возможность выбора позиций JDp для должностной инструкции конкретного сотрудника из справочника. Справочник представлен в виде проекта в вопросно-ответном протоколе в проекте «Архив активов». Общий вид подсистемы фор- мирования должностных инструкций дан на рисунке 4.

Из рисунка видно, что центральным хранилищем для должностных инструкций конкретного сотрудника является вопросно-ответный протокол, в котором для каждого сотрудника назначается отдельная задача. Сами документы (MS Word) генерируются на основе данных вопросно-ответ­ного протокола и шаблона оформления документа (MS Word) в системе документирования.

Все множество доступных должностных инструкций JD* хранится в вопросно-ответном протоколе в проекте «Архив активов» в задаче «компетенции». При этом при редактировании данного архива следует учитывать следующие правила назначения атрибутов (чтобы список инструкций для конкретной должности отображался корректно).

1.     Каждая QA-единица, являющаяся укрупненной компетенцией JDc, должна иметь атрибут «групповая компетенция».

2.     Каждая QA-единица, являющаяся должностью JD, должна иметь атрибут «должность».

3.     Каждая единица, которая в качестве дочерних содержит конкретные компетенции JDc, должна иметь атрибут «компетенция».

Для адресации точек вставки данных в шаблон были разработаны контекстно-зависимые атрибуты, которые используются только при формировании шаблона отчета (в среде Microsoft Word) [5].

В общем виде работа оператора по формированию должностных инструкций состоит из этапов, представленных на рисунке 5.

Формирование и изменение документа должностной инструкции

Практическая работа с должностными инструкциями осуществляется в плагине «Организационная структура». В основном окне «Данные сотрудника» необходимо выбрать пункт меню «Сотрудники», в появившемся диалоговом окне необходимо выбрать работника, для которого формируется должностная инструкция. Назначив должность работника на вкладке «Работа», можно просматривать и редактировать должностные обязанности работника на вкладке «Должностные инструкции». На вкладке «Роль» можно уточнить роль, выполняемую данным работником.

Должностные обязанности выбираются выделением в соответствующем поле маркером. Первоначально обязанности работника определяются ролью, затем могут корректироваться в процессе работы.

Для сохранения внесенных изменений необходимо выбрать проект и задачу в QA-протоколе, для которой предполагается сохранить инструкцию. Также необходимо выбрать шаблон с общими данными для документа и шаблон отчета в MS Word. При нажатии на кнопку «сохранить» происходит следующее.

1.     Вопросно-ответный шаблон копируется в выбранную задачу вопросно-ответного протокола вместе со всеми своими подчиненными шаблонами и атрибутами.

2.     Измененные элементы инструкций скопируются в качестве дочерних к QA-единице, созданной на основе шаблона. Причем скопируется структура компетенций, отфильтрованная также (кроме пользовательского выбора элементов) по должности.

3.     В плагине «Проектная документация» создастся папка «Должностные инструкции», если ее не было (если была, она откроется), в которой сгенерируется должностная инструкция на основе выбранного шаблона представления и выбранной задачи вопросно-ответного протокола.

После формирования инструкцию можно посмотреть в плагине «Проектная документация» в папке «Должностные инструкции».

Для изменения или дополнения общих данных документа (номер, информация о подписывающих и согласующих и т.п.) в плагине «Вопросно-ответный протокол» необходимо открыть вновь добавленную задачу и измененить сведения. После внесения изменений документ будет содержать обновленные данные, так как при каждой генерации используется информация из конкретного экземпляра. Дополнительно предусмотрено формирование шаблона на основе конкретного экземпляра QA-протокола.

Структура вопросно-ответного протокола с должностными инструкциями полностью соответствует структуре самого документа.

Подводя итоги, отметим, что представленные в статье средства автоматизированного формирования должностных инструкций нацелены на персонификацию профессиональной ответственности сотрудников проектной организации. В разработке средств учтены современные стандарты профессиональной зрелости процессов и их организационного сопровождения. Предложенные и материализованные решения ориентированы на их включение в базу опыта проектной организации.

Литература

1.     Von Rosing M., Moshiri S., Gräslund K. & Rosenberg A. Competency Maturity Model Wheel. URL: http://www.value­team.biz/downloads/ model_cmm_wheel.pdf (дата обращения: 13.09.2013).

2.     Borges P., Machado R.J. & Ribeiro P. Mapping RUP Roles to Small Software Development Teams. Proc. Intern. Conf. on Software and System Process (ICSSP). Portugal, 2012, pp. 190–199.

3.     Соснин П.И. Вопросно-ответное программирование человеко-компьютерной деятельности. Ульяновск: УлГТУ, 2010. 240 с.

4.     Маклаев В.А. Подход к представлению и использованию профессиональных активов проектной организации // Автоматизация процессов управления. 2011. № 1 (23). С. 5–12.

5.     Sosnin P. Pseudo-code programming of designer activity in development of software intensive systems. Proc. 25th Intern. Conf. on Industrial Engineering and other Applications of Applied Intelligent Systems (IEA/AIE 2012). Dalian, Chine, 2012, pp. 457–466.

References

1.     Von Rosing M., Moshiri S., Gräslund K., Rosenberg A. Competency Maturity Model Wheel. Available at: http://www.va­lueteam.biz/downloads/ model_cmm_wheel.pdf (accessed 13 September 2013).

2.     Borges P., Machado R.J., Ribeiro P. Mapping RUP roles to small software development teams. Proc. int. conf. on software and system process (ICSSP). Portugal, 2012, pp. 190–199.

3.     Sosnin P.I. Voprosno-otvetnoe programmirovanie chelove­ko-kompyuternoy deyatelnosti. Ulyanovsk, Ulyanovsk St. Tech. Univ. Publ., 2010, 240 p.

4.     Maklaev V.A. Podkhod k predstavleniyu i ispolzovaniyu professionalnykh aktivov proektnoy organizatsii. Avtomatizatsiya protsessov upravleniya [Automation of management processes]. 2011, no. 1 (23), p. 5–12.

5.     Sosnin P. Pseudo-code programming of designer activity in development of software intensive systems. Proc. 25th intern. conf. on Industrial Engineering and other Applications of Applied Intelligent Systems (IEA/AIE 2012). Dalian, Chine, 2012, pp. 457–466.