Embed Size (px)
Citation preview
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
федеральное государственное бюджетное образовательное учреждение
высшего профессионального образования
«УЛЬЯНОВСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ»
П. И. Соснин, Ю. А. Лапшов, В. А. Маклаев, К. В. Святов
Программное управление потоками работ
в компьютеризованных средах
Ульяновск
УлГТУ
2014
УДК 621.397:004.738 ББК 32.973.202
С 66
Научный редактор доктор технических наук П. И. Соснин Рецензенты: доктор технических наук, профессор
Кумунжиев К. В., доктор технических наук Токмаков Г. П.
Соснин, П. И.
С 66 Программное управление потоками работ в компьютеризованных средах / П. И. Соснин, Ю. А. Лапшов, В. А. Маклаев, К. В. Святов. – Ульяновск : УлГТУ, 2014. – 308 с. ISBN 978-5-9795-1339-3
В монографии представлен программный подход к гибкому проектному управлению, в основу которого положены концептуально-алгоритмическое программирование действий проектировщиков и картотечная визуализация с использованием механизмов Kanban и Scrum. Подход специфицирован в контексте совершенствования профессиональной зрелости процессов проектирования и их исполнителей, а его реализация ориентирована на вопросно-ответную моделирующую среду WIQA.
Предназначена для ученых и специалистов, исследующих и разрабатывающих средства и системы автоматизации проектирования, а также для студентов, изучающих автоматизированное проектирование систем с программным обеспечением.
УДК 621.397:004.738 ББК 32.973.202
© Соснин П. И., Лапшов Ю. А., Маклаев В. А., Святов К. В., 2014.
ISBN 978-5-9795-1339-3 © Оформление. УлГТУ, 2014.
СОДЕРЖАНИЕ
Введение ................................................................................................................ 6
Глава 1. Проектное управление ...................................................................... 13
1.1. Успешность проектов и проектной организации ................................ 13
1.1.1. Проблема успешности в проектировании .......................................... 13
1.1.2. Нормативы профессиональной зрелости ........................................... 19
1.2. Совершенствование управления проектной деятельностью ............ 22
1.2.1. Особенности проектной деятельности ............................................. 22
1.2.2. Структура проектного управления ..................................................... 30
1.2.3. Зрелость проектного управления ......................................................... 36
1.2.4. Стандартизация знаний о проектном управлении .......................... 42
1.2.5. Методология PRINCE2 .......................................................................... 45
1.2.6. Зрелость проектного управления ......................................................... 49
1.3. Управление потоками работ ................................................................... 52
1.3.1. Рациональный унифицированный процесс .......................................... 52
1.3.2. Потоки работ .......................................................................................... 61
1.3.3. Потоки работ в проектной деятельности ........................................ 65
1.4. Гибкое проектное управление .................................................................. 68
1.4.1. Agile-версии проектной деятельности ............................................... 68
1.4.2. Введение в Kanban-технологии ............................................................. 72
1.4.3. Введение в Scrum-технологии ............................................................... 74
1.4.4. Инициатива SEMAT ............................................................................... 76
Выводы по первой главе .............................................................................. 83
Глава 2. Вопросно-ответная среда WIQA ..................................................... 86
2.1. Взаимодействие с опытом в проектировании АС ............................... 86
2.1.1. Опыт разработок АС ............................................................................. 86
3
2.1.2. Особенности комплекса WIQA ............................................................. 90
2.1.3. Вопросно-ответная память ................................................................. 96
2.2. Применение QA-памяти ......................................................................... 100
2.2.1. Отображение операционного пространства .................................. 100
2.2.2. Формализация QA-памяти .................................................................. 103
2.3. Язык и среда псевдокодового программирования ................................ 109
2.3.1. Особенности языка программирования LWIQA .................................. 109
2.3.2. Детализация особенностей языка LWIQA ........................................... 112
2.3.3. Спецификация языка LWIQA .................................................................. 117
2.3.4. Расширения языка LWIQA ...................................................................... 124
2.3.5. Интерпретатор псевдокодовых программ ....................................... 134
2.3.6. Компилятор псевдокодовых программ .............................................. 142
2.3.7. Редактор псевдокодовых программ .................................................... 146
2.4. Псевдокодовое программирование ......................................................... 149
2.4.1. Примеры псевдокодовых программ..................................................... 149
2.4.2. Система документирования DocWIQA.Net ...................................... 153
2.4.3. Документирование в системе OwnWIQA ......................................... 158
2.4.4. Прототипирование пользовательских интерфейсов ..................... 162
Выводы по второй главе ............................................................................ 172
Глава 3. Программно-картотечное управление ......................................... 174
3.1. QA-средства в исследованиях проблемы успешности ....................... 174
3.1.1. Семейство QA-систем и их версий .................................................... 174
3.1.2. Программно-картотечное управление .............................................. 178
3.2. Архитектура программно-картотечного управления ...................... 182
3.3. Формализация отображений ПКУ на QA-память ............................ 189
3.3.1. Отображение проекта и задач на память WIQA ........................... 189
3.3.2. Отображение организационной структуры .................................... 192
3.3.3. Назначение задач ................................................................................... 197
3.3.4. Отображение подсистемы контроля исполнения поручений ...... 201
3.4. Организация процесса управления ......................................................... 205
4
3.4.1. Отбор задач для оперативного выполнения ..................................... 205
3.4.2. Отображение Kanban-процессов в ПКУ ........................................... 210
3.4.3. Отображение Scrum-процессов в ПКУ.............................................. 215
3.5. Распараллеливание проектных процессов в ПКУ ............................... 224
3.5.1. Особенности распараллеливания в ПКУ ........................................... 224
3.5.2. Формализация процессов распараллеливания работ ...................... 230
3.5.3. Имитация механизмов массового обслуживания ........................... 233
3.5.4. Управление прерываниями................................................................... 240
3.5.5. Программная интерпретация очередей задач ................................. 245
3.5.6. Особенности эмпирики картотечного управления ....................... 250
3.6. Сценарная структуризация ПКУ .......................................................... 256
3.7. Методики программно-картотечного управления ............................ 268
3.8. Особенности реализации средств ПКУ ............................................... 272
3.8.1. Общие особенности реализации средств ПКУ ................................ 272
3.8.2. Особенности реализации контроля поручений ............................... 274
3.8.3. Особенности реализации Kanban ....................................................... 277
3.8.4. Особенности реализации Scrum ......................................................... 287
3.9. Размещение компонентов ПКУ ............................................................. 290
Выводы по третьей главе ........................................................................... 297
Заключение ....................................................................................................... 299
Библиографический список ............................................................................ 301
Обозначения и сокращения ....................................................................... 308
5
ВВЕДЕНИЕ
Расширяющаяся компьютеризация всех сфер современной
человеческой деятельности, обусловленная совершенствованием средств
компьютеризации и их приложений, все чаще приводит
к необходимости решения задач, сложность которых выходит за рамки
гарантированного успеха. К числу таких задач относятся задачи, для
решения которых приходится прибегать к коллективной деятельности в
компьютеризованных средах, например задачи проектирования систем,
интенсивно использующих программное обеспечение (Software
Intensive System, SIS).
Сложность систем типа SIS в общем случае обусловлена
комплексированием в их структурах аппаратных и программных
компонентов, в функциональное обеспечение и использование которых
вовлечены люди. Более того, системы типа SIS создают
в инструментально-технологических средах, каждая из которых
представляет собой специализированную SIS.
Для систем типа SIS характерно то, что с разработкой их
программного обеспечения связаны существенные расходы финансов
и времени, и принципиальную роль в этом играют достижение
необходимой функциональности и связанные с этим достижением
Вам не следует иметь любимого оружия. Владеть каким-то одним оружием очень хорошо, тогда как другими вы владеете плохо, – такой же недостаток, как и не владеть этим оружием вообще.
Самурай Миямото Мусаси
6
риски как процесса разработки, так и победы продукта в конкурентной
борьбе.
С сожалением приходится констатировать, что успешность процесса
разработки SIS, под которой в интегральном плане принято понимать
реализацию процесса в запланированных рамках (финансовых,
временных и функциональных), чрезвычайно низка (в течение
последних 20 лет не превышает 40 %).
Предположений о причинах низкой успешности достаточно.
В интегральном плане они обусловлены проблемами согласованной
коллективной деятельности в компьютеризованных средах,
нацеленной на создание продуктов, уровень сложности создания
которых для участников коллективной деятельности является
достаточно высоким.
В монографии приведены результаты исследований и разработок,
нацеленных на создание средств программно-картотечного
управления коллективной деятельностью в компьютеризованных
средах. Идеи такой версии управления деятельностью сложились у
авторов при разработке инструментально-технологических методов и
средств, применяемых при концептуальном проектировании
автоматизированных систем (АС).
В соответствии со стандартами 34-й серии АС представляют собой
«организационно-технические системы, обеспечивающие выработку
решений на основе автоматизации информационных процессов в
различных сферах деятельности или в их сочетании».
Приведенное определение АС указывает, что эти системы являются
типичными представителями класса SIS; в каждой из АС объединяются
software, hardware и peopleware. Системы типа АС создаются
коллективами разработчиков и обслуживаются коллективами
пользователей для удовлетворения потребностей заинтересованных
7
в АС лиц. Общим как для разработчиков АС, так и их пользователей
является то, что активность коллективов осуществляется в форме
потоков работ, в исполнении каждого из которых согласованно
и параллельно решаются нормативные и / или творческие задачи.
В отмеченном плане подкласс АС является самым проблемным
среди других подклассов SIS для учета человеческого фактора
в достижении успеха конкретных АС.
На создание средств программно-картотечного управления,
учитывающих человеческий фактор, оказал влияние подход
к повышению успешности (проектной) организации за счет
совершенствования используемых бизнес-процессов и повышения
профессионализма их исполнителей. Наиболее конструктивно этот
подход специфицирован в стандарте ISO/MEK 9004–2009 «Менеджмент
для достижения устойчивого успеха организации. Подход на основе
менеджмента качества» и стандартах профессиональной зрелости
процессов Capability Maturity Model Integrated for Development (CMMI
1.3) и их исполнителей People Capability Maturity Model (P-CMM 2.0).
Особенности подхода в его применении к совершенствованию
управления коллективной проектной деятельностью детально
раскрываются в таких источниках опыта, как Project Management Body
of Knowledge (PMBOK, the fifth edition).
Специфику программно-картотечного подхода определяют:
− введение в совокупность ролей, исполняемых
проектировщиками, роли «Интеллектуального процессора»,
отвечающей за включение в процессы решения проектных задач
оперативного взаимодействия проектировщиков с доступным опытом
и его моделями;
8
− использование унифицированных форм представления
проектных задач как прецедентов;
− отображение прецедентов на вопросно-ответную память,
настроенную на псевдокодовое программирование;
− возможность экспериментирования по ходу построения
и использования прецедентов с использованием механизмов
прерываний человеко-компьютерной деятельности;
− картотечная визуализация состояний процессов решения
проектных задач с возможностями «измерений» параллельно
исполняемой работы и ее оптимизации.
Текст монографии структурирован следующим образом. В первой
главе представлен материал, раскрывающий содержание проектного
управления в контексте проблемы достижения успешности
в проектировании семейств АС. Основная цель главы – представить
современное состояние исследований и разработок в предметной
области «проектного управления» и выявить перспективные
направления его развития.
Для представления состояния выбраны стандарты управления,
аккумулирующие опыт такой деятельности с ряда устоявшихся позиций.
Особое внимание уделяется вопросам совершенствования
профессиональной зрелости как в широком плане, затрагивающем все
составляющие проектирования SIS и АС, так и в более узком плане
зрелости управляющих воздействий.
Принимается в расчет и опыт современных технологий создания SIS
и АС, среди которых выделяется технология Rational Unified Process
с ее потоками работ, включая потоки работ управления проектом. Особо
выделяются гибкие технологии проектирования и управления
с детализацией Kanban- и Scrum-подхода.
9
Необходимость поиска новых решений в разработках SIS и АС,
а также в управлении такими разработками констатируется с помощью
инициативы SEMAT, целевые ориентиры которой связаны
с необходимостью переосмысления основ программной инженерии.
В главе представлена позиция авторов монографии, нацеленная на вклад
в такое переосмысление задач управления проектной деятельностью.
Во второй главе раскрываются предпосылки для поиска
возможных новаций в проектном управлении и представляется
инструментально-технологическая среда, в рамках которой авторами
монографии исследованы и материализованы новые решения,
предлагаемые для управления проектной деятельностью.
Для исследования и материализации программно-картотечного
управления выбрана вопросно-ответная моделирующая среда WIQA
(Working In Questions and Answers), в создании которой авторы
монографии принимали непосредственное участие. Принципиальной
особенностью среды WIQA является использование отображений
операционного пространства разработки семейств АС на
семантическую память, открывающую интерактивный и программный
доступ к семантическим моделям составляющих проектной
деятельности.
Представляются основные семантические модели
и специализированный концептуально-алгоритмический язык LWIQA
для их использования в решении проектных задач. Открытый язык
LWIQA, относящийся к классу языков псевдокодового
программирования, встроен в инструментарий WIQA, в том числе
и как средство его развития. Раскрыты средства, специфика и механизмы
псевдокодового программирования на языке LWIQA.
10
Содержание третьей главы сосредоточено на особенностях
программно-картотечного управления и средствах его применения
в коллективной и персональной проектной деятельности.
Осуществление такого управления требует отображения на
семантическую память практически всех составляющих операционного
пространства проектирования. Порождающая грамматика, применяемая
для декларативной формализации составляющих операционного
пространства, органически расширяется на концептуально-
алгоритмическое моделирование динамики процессов проектирования
в псевдокодовых формах. Картотечная визуализация включает в такие
процессы возможности образного восприятия состояний проектирования
и хода работ.
Особое внимание в третьей главе уделяется вопросам
распараллеливания активности проектировщиков, причем как в
персональной деятельности, так и в коллективной работе.
В выводах по каждой главе и общем заключении явно
и неявно проводится мысль о том, что предлагаемые авторские решения
по гибкому проектному направлению связаны с эмпирической
программной инженерией, а в более широком плане – с
экспериментированием в компьютеризованной деятельности, причем не
только проектного типа. Возможность экспериментирования
принципиальна для совершенствования профессиональной зрелости во
всех ее проявлениях.
Библиографический список, включенный в монографию, содержит:
− публикации, являющиеся источником информации или
заимствования;
11
− публикации, содержание которых оказало существенное влияние
на понимание авторами проблем человеко-компьютерной деятельности
и на принятые решения;
− ряд авторских публикаций, раскрывающих детали вопросно-
ответного подхода, его материализацию в рамках вопросно-ответной
инструментальной среды WIQA и применение этого инструментария при
решении ряда задач для повышения степени успешности разработок АС.
К числу таких задач относятся и задачи программно-картотечного
управления. Явные ссылки на публикации из библиографического
списка в тексте монографии отсутствуют.
12
Глава 1. Проектное управление
1.1. Успешность проектов и проектной организации
1.1.1. Проблема успешности в проектировании Как отмечалось во введении, в настоящее время существует
проблема успешной разработки систем, интенсивно использующих
программное обеспечение. На наличие этой проблемы явно указывает
статистика успешности, исследуемая корпорацией Standish Group и
публикуемая в ее регулярных отчетах с 1994 г.
Интегральное представление статистики с 1994 по 2012 год
приведено в таблице 1.1. Из показателей таблицы видно, что положение
дел, которое с 1994 г. можно оценить как крайне неудовлетворительное,
к 2012 г. изменяется в лучшую сторону, но процесс улучшений нельзя
признать управляемым (об этом свидетельствует провал,
зарегистрированный в 2008 г.).
Следует отметить, что разработка SIS в статистике относится
к классу успешных, если в ней за запланированные время и стоимость
Таблица 1.1
Доля в процентах Результат
16 27 26 28 34 29 35 32 37 39 Успех
31 40 28 23 15 18 19 24 21 18 Провал
53 33 46 49 51 53 48 44 42 43 Изменения
1994
г.
1996
г.
1998
г.
2000
г.
2002
г.
2004
г.
2006
г.
2008
г.
2010
г.
2012
г.
13
качественно материализована затребованная функциональность.
От оценок экспертов и потребителей статистика абстрагируется.
В отчетах Standish Croup и других публикациях по вопросам
успешности не только констатируется положение дел, но и приводятся
факторы, оказывающие позитивное и негативное воздействие на
успешность разработок SIS.
Так, например, в таблице 1.2 приведены позитивные факторы
(и указаны их приоритеты), которые в отчетах за 1994, 2008 и 2012 гг.
отнесены к факторам, способствующим достижению успеха.
Таблица 1.2
Фактор 1994 2008 2012 Вовлеченность пользователей 1 1 2 Поддержка руководителей высшего звена 2 2 1 Понятные формулировки требований 3 Подходящее планирование 4 Реалистичные ожидания 5 Частые контрольные точки 6 Компетентный персонал 7 8 4 Права собственности 8 Ясное видение и цели 9 3 7 Напряженная работа / нацеленный на результат персонал
10
Управление проектом 7 5 Стандартный инструментарий и инфраструктура
10 10
Гибкость работ с требованиями 6 6 Оптимизация масштаба / оптимизация 5 3 Эмоциональная зрелость 4 8 Нормативное исполнение 9 9
Следует отметить, что в научно-технической литературе по вопросам
успешности приводятся, обосновываются и оцениваются и другие
позитивные факторы, а также описываются негативные факторы,
оказывающие отрицательное воздействие на успех разработок SIS.
14
Отсутствие единой позиции по факторам, способствующим успеху
и препятствующим его достижению, объясняется, в основном,
разнообразием типологии проектов и условий, в которых они
разрабатываются. Единым в оценках положения дел остается то, что
проблема успешности разработок SIS сохраняется, несмотря на многое,
что предложено и сделано для ее решения.
Недопустимые для человечества потери, обусловленные проблемой
достижения успешности, требуют необходимости как можно быстрее
найти выход из положения, сложившегося в разработках SIS.
Это особенно важно и потому, что именно это направление деятельности
определяет глобальную информатизацию человеческой жизни.
Отметим, что результативность любых попыток, нацеленных на
решение проблемы достижения успешности, в существенной мере
зависит от того, насколько адекватно и измеримо определены понятия
«успех» и «успешность разработки SIS» и насколько конструктивны
механизмы оценивания успешности и управления разработкой SIS на
основе оцениваний.
Необходимым, но недостаточным условием успеха проектной
организации считается постоянное совершенствование процессов,
деятельности коллектива и продуктов. Более конкретные спецификации
успеха за счет совершенствования указаны в стандарте
ISO/MEK 9004–2009, обобщенное представление содержания которого
образно отражено на рисунке 1.1.
Развитие теории и практики разработок сложных SIS не доведено до состояний, позволяющих создателям SIS достаточно верно оценивать будущую успешность и управляемо продвигаться к успеху, и это определяет сущность проблемы достижения успешности, на негативные факторы которой указывают отчеты Standish Group.
15
Рис. 1.1. Схема совершенствования производственной деятельности
Устойчивый успех организации достигается за счет ее способности
отвечать потребностям и ожиданиям своих потребителей и других
заинтересованных сторон на долговременной основе
и сбалансированным образом. Устойчивого успеха можно добиться
посредством эффективного менеджмента организации, путем осознания
организацией среды своего существования, за счет обучения и должного
применения улучшений и (или) инноваций.
Стандарт ориентирован на широкий круг организаций, включая
проектные. Из-за своей широты он раскрывает пути достижения успеха
обобщенно и в рекомендательном плане, что, однако, не умаляет его
значимости для практики.
Как уже отмечалось, для обеспечения в разработках SIS управляемой
нацеленности на успех необходимо определиться с понятием «успех»
конструктивно.
Слово «успех» принято употреблять в качестве оценочной характеристики, которую приписывают результату деятельности по степени его востребованности «потребителями». Такую характеристику принято переносить и на исполнителя деятельности, приведшей к успешному результату, и на саму эту деятельность.
ОЖИДАНИЕ
ПОТРЕБИТЕЛЯ
УСПЕХ
ТОТАЛЬНЫЙ
КОНТРОЛЬ
КАЧЕСТВА
ЛУЧШИЕ
ПРАКТИКИ
СОГЛАСОВАНИЕ
СПЕЦИФИКАЦИЙ
16
В статистических исследованиях успешности разработок SIS
конкретную разработку считают успешной, если она завершена
в соответствии с запланированными требованиями в рамках
оговоренных финансовых и временных затрат. Реалии востребованности
SIS потребителями в такой оценке учитываются опосредованно – через
соответствие того, что вложено в SIS, запланированным (при
заключении контракта на разработку) функциональным и
нефункциональным требованиям. Наличие или отсутствие реального
успеха SIS на рынке в такой версии оценок не присутствует и не
прогнозируется.
Возможны и другие версии приписывания успеху значений,
например через характеристики проектной деятельности и ее
исполнителей, в первую очередь, с позиций их профессиональной
зрелости.
Одним из направлений повышения успешности разработок
программных систем и систем, в которых интенсивно используется
программное обеспечение, является совершенствование
профессиональной зрелости и зрелости осуществляемых процессов.
В таком совершенствовании различают «уровни профессиональной
зрелости», с каждым из которых связывают систему практик, где каждая
практика доведена до определенной степени совершенства. Под
практиками понимают определенные виды технологических работ,
которые в разработке следует выполнять обязательно, действуя
в соответствии с подходящими методиками, а степень совершенства
связывают с применением лучших практик (best practices).
В оценках зрелости конкретной системы процессов абстрагируются
от исполнителей работ, полагая, что их компетентность достаточна.
Для характеристики и оценки профессиональной зрелости исполнителей принято использовать их «компетентность», уровням которой приписывают определенную «квалификацию».
17
Системы процессов разработки осуществляются, и их зрелость
повышается в определенных коллективах при определенных условиях,
например в проектных организациях, что позволяет говорить
о профессиональной зрелости проектной организации и оценивать ее
в соответствии с достигнутым уровнем зрелости процессов.
Уровень зрелости является интегральной характеристикой, значения
которой приписываются в результате экспертной оценки, в которой
учитываются экспертные оценки степени определенности, степени
управляемости, измеряемости, контролируемости и эффективности.
Так, например, в степени определенности принято выделять два
значения.
Первое значение (повторяемый процесс) отражает сам факт
повторяемости совокупности действий разработчиков от одного проекта
к другому.
Второе значение (определяемый процесс) показывает: доведена ли
повторяемая совокупность действий до технологии с соответствующим
инструментарием.
В степени управления процессом также принято выделять два
значения: «управляемый процесс» и «количественно управляемый
процесс». Во второе значение вкладывается оперативная
управляемость по количественно измеряемым отклонениям
характеристик процесса от плановых значений.
В экспертных оценках профессиональной зрелости встает вопрос об
эталонах для приписывания значений. Функции таких эталонов принято
возлагать на определенные совокупности работ, которые выполняются
нормативно, то есть по определенным технологическим методикам.
Уровень зрелости производственного процесса – это степень, до которой тот или иной процесс определен, управляем, измеряем, контролируем и эффективен.
18
Каждая такая методика интерпретируется как измеряемая метрика
(эталон исполнения работы).
Отметим, что ничто не мешает расширить содержание
«профессиональной зрелости проектной организации», включив в него,
например, составляющую, которая интегрально представляет
компетенции ее коллектива, и характеристику полезности
инструментария, используемого в организации.
1.1.2. Нормативы профессиональной зрелости В теории и практике профессионально зрелых процессов накоплен
богатейший опыт, практическая часть которого нашла свое выражение
в стандарте CMMI-1.3 Development (Capability Maturity Model
Integrated), позволяющем оценить уровень организационно-
профессиональной зрелости процесса разработки SIS.
Модель стандарта CMMI-Dev обобщает передовой опыт разработки
продуктов и услуг. Сюда относятся практики, которые охватывают
жизненный цикл продукта с момента разработки концепции продукта до
его поставки и технического обеспечения. Акцент делается на
деятельности по созданию и поддержке всего продукта в целом.
Модель стандарта CMMI-Dev состоит из 22 процессных областей:
16 из них являются основными, 1 область – смежная, а 5 остальных
представляют собой специальные процессные области разработки
(табл. 1.3).
19
Таблица 1.3
Уро-вень
Код Практики CMMI 1.3 English перевод
5
OID Organizational Innovation and Deployment
Инновации в организации
CAR Causal Analysis and Resolution Анализ причин и разрешение проблем
4
OPP Organizational Process Performance
Качество процессов
QPM Quantitative Project Management
Количественное управление проектом
3
RD Requirements Development Разработка требований TS Technical Solution Технические решения PI Product Integration Интеграция продукта VER Verification Верификация VAL Validation Валидация OPF Organizational Process Focus Организация работы
внутри групп OPD Organizational Process
Definition Создание формальных моделей организационных процессов
OT Organizational Training Обучение IPM Integrated Project Management
for IPPD Интегрированное управление проектом
RM Risk Management Управление рисками DAR Decision Analysis and
Resolution Анализ и принятие решений
2
RM Requirements Management Управление требованиями PP Project Planning Планирование проекта PMC Project Monitoring and Control Мониторинг и контроль
проекта SAM Supplier Agreement
Management Управление поставщиками
MA Measurement and Analysis Измерения и анализ PPQA Process and Product Quality
Assurance Обеспечение качества процессов и продуктов
CM Configuration Management Управление конфигурацией
1 ? ?…? Героический и непредсказуемый
Состав и обобщенное содержание процессной области раскрывает
схема, представленная на рисунке 1.2.
20
Рис. 1.2. Структура процессной области
Внедрение CMMI 1.3 в проектных организациях позволяет
улучшить структуру, результативность и качество проектных процессов,
а также обеспечить успешность разработок АC. Профессионально
зрелый процесс переносит свои ценности на результат разработки.
Профессиональная зрелость в нормативах CMMI 1.3 растет от
уровня к уровню. Первый – «Начальный» (Initial) – уровень, часто
называемый «героическим», представляет разработки АC, в которых
нормативная технологическая дисциплина не используется и результат
зависит от личностей, вовлеченных в разработку, и от удачи. Результат
таких разработок непредсказуем (хотя и может оказаться
положительным).
Второй уровень, получивший название «Управляемый» (Managed),
предполагает наличие минимально необходимых средств (практик) для
Процессная область
Формулировка цели
Вступительный комментарий
Связные процессные
области
Специальные цели
Специальные практики
Общие цели
Подпрактики Подпрактики Примеры рабочих
продуктов
Разработка общей
практики
Общие практики
21
планирования работ и управления разработкой АC, включая средства для
контроля качества процесса разработки в целом и его результата. За вторым
уровнем закреплены две обязательные оценки «повторяемый процесс,
repeatable, performed» и «управляемый процесс, managed», поэтому
иногда этот уровень называют «Повторяемый» или «Исполняемый».
Средства третьего «Определяемого» (Defined) уровня обеспечивают
превентивное, интегрированное применение проектных практик (в виде
технологии), а также предшествующего опыта проектной организации.
На четвертом «Количественно управляемом» (Quantitatively
Managed) уровне как для процесса, так и для продукта в обязательном
порядке используются оценочно-расчетные практики.
На пятом «Оптимизирующем» (Optimizing) уровне
в технологические процессы включены методики, которые позволяют
проводить их непрерывное совершенствование.
1.2. Совершенствование управления проектной деятельностью
1.2.1. Особенности проектной деятельности
Такой феномен, как управление, был создан природой в процессе
эволюции жизни на Земле для решения вполне определенных задач,
в число основных из которых входят задачи саморегулирования
(в первую очередь, самосохранения) и самоорганизации (в том числе
саморазвития) живой материи. Феномен проявляется через
взаимодействие живого организма и / или их совокупности
с окружающей средой, причем в условиях, происходящих в среде
изменений.
Феномен управления осознан человечеством, и его модели активно
используются в деятельности при решении различных задач,
ориентированных на достижение определенных целей. В процессах
решения таких задач принципиальное место занимают обратные связи,
22
образующие в общем случае взаимосвязанные контуры управления.
Широко применяемая на практике схема взаимосвязи контуров
управления приведена на рисунке 1.3.
Рис. 1.3. Схема двухконтурного управления
Динамика контуров управления определяется потоками информации,
которые порождаются, обрабатываются и используются компонентами
схемы в ответ на воздействия окружающей среды. Первый контур
ABCDE обеспечивает решение задачи регулирования, в то время как
второй контур ABFGDE нацелен на развитие, одним из проявлений
которого является совершенствование объекта управления.
В реальных задачах управления информационные потоки
структурируются в переменные, характеризующие воздействия,
взаимодействия и состояния объекта управления и управляющего
субъекта, что образно отражено на рисунке 1.4, причем с каждым
набором таких переменных принято связывать их векторные
интерпретации. Так, например, составляющие вектора А – это набор
основных целевых ориентиров (характеристик) управления.
23
Рис. 1.4. Обобщенная схема управления
В принципе ничто не мешает применять обобщенную схему при
решении задач управления проектами, нацеленных на успешность
разработок. В таких применениях принципиальна цель, связанная
с повышением степени успешности создания проектов за счет
совершенствования зрелости процессов проектирования
и профессиональной зрелости лиц, вовлеченных в такие процессы.
Адаптация схемы (рис. 1.4) к названной цели как в теоретическом,
так и в практическом планах должна быть ориентирована:
− на особенности проектной деятельности как в общем смысле, так
и в привязке к проектированию SIS и их семейств;
− особенности проектного управления, но с учетом его
комплексирования с процессным управлением;
24
− конструктивный учет и применение опыта, аккумулированного
в стандартах о профессиональной зрелости, связанных как с разработкой
SIS, так и с проектным управлением в широком смысле;
− решения, вложенные в технологии проектного управления,
подтвердившие свою полезность при разработке SIS.
Особенности проектной деятельности (в общем смысле)
обусловлены тем содержанием, которое вкладывается в то, что называют
проектами. Приведем ряд определений проекта:
1. Проект – это временное предприятие, предназначенное для
создания уникальных продуктов, услуг или результатов (PMBOK до
пятой версии).
2. Проект – это комплекс взаимосвязанных мероприятий,
направленных на создание уникального продукту или услуги в условиях
временных или ресурсных ограничений (ГОСТ Р 54869–2011).
3. Проект – это уникальная совокупность процессов, состоящая
из контролируемых и управляемых видов деятельности с датами начала
и завершения, предназначенная для достижения определенных целей
(ISO 21500:2012).
Приведенные определения специально взяты из стандартов для
управления проектами, в текстах которых стараются выбрать строгие
формулировки используемых терминов. Не сложно заметить, что во всех
определениях проекта присутствует спецификация «уникальный», но если
в первых двух определениях «проект» ориентирован на продукт, сервис
или услугу, то в третьей версии – на достижение определенных целей.
Ориентация на цель позволяет связать его принципиальную
особенность проекта – «уникальность» – с уникальностью совокупности
процессов, состоящей из контролируемых и управляемых видов
деятельности. Другими словами, стандарт ISO 21500 указывает на то,
что проектное управление можно и даже рекомендуется осуществлять на
25
основе средств, в которых применяется процессное управление.
Динамика проектной деятельности обязательно приведет к созданию
уникальной версии комплексирования деятельностных единиц,
управляемых процессно. Схема типовой процессной единицы приведена
на рисунке 1.5.
.
Рис. 1.5. Обобщенная схема процесса
Следовательно, при проектировании необходимо обязательно
применять технологию и подходящий инструментарий, в основу
которых положены лучшие практики. В их число входят и практики,
управляемые процессно. Замечательным примером такого подхода
Таким образом, следует понимать, что за осуществлением проекта стоят построение и реализация уникального процесса, приводящего к достижению определенной цели или целей.
26
является технология и инструментарий «Rational Unified Process» (RUP),
созданные корпорацией IBM.
Отметим, что на схеме процесса приведен один контур управления,
однако это следует понимать как обобщение. На самом деле типичной
формой управления процессами является двухконтурное управление,
в котором управляющий субъект, формируя управляющее воздействие,
действует по определенной программе (алгоритму), которую он не имеет
права изменять. В общем случае двухконтурного управления субъект
адаптирует или совершенствует программу своих действий по
формированию управляющих воздействий на объект управления.
В нормативных схемах повышения профессиональной зрелости (при
переходах с уровня) можно использовать как модификации программ,
управляющих действиями в процессах, так и переход к использованию
более зрелых программ управления, выбираемых из библиотеки
и осваиваемых коллективом проектировщиков.
В то же время для совершенствования проектного управления
принципиальным является создание инновационных программ
управления проектами или их составляющих.
Уникальность не является единственной особенностью проектов.
Еще одна особенность связана с интерпретацией проекта как временного
предприятия в определении PMBOK.
Если исходить из того, что проект – это «временное предприятие»,
созданное в рамках проектной организации, то логична постановка
вопроса о том, как такое временное предприятие материализуется
Таким образом, одним из направлений совершенствования деятельности по управлению проектами является совершенствование программ процессного управления, которые применяются в проектной деятельности.
27
в проектных организациях. Один из ответов на этот вопрос раскрывает
схема, представленная на рисунке 1.6, которая в стандарте ISO 21500
позиционирует место проекта в рамках проектной организации.
Из представленной схемы видно, что если у организации имеются
возможности для осуществления более одного проекта, то
последовательно, или параллельно, или последовательно-параллельно
она будет выполнять такую работу.
Рис. 1.6. Место проекта в проектной организации
Более того, в стандарте ISO 21500 и ряде других вводятся формы
группирования проектов в более крупные образования: программы
и портфели, – что отражено на рисунке 1.7, который раскрывает
содержание этих образований и также взят из вышеуказанного
стандарта.
28
Рис. 1.7. Проект, программа, портфель проектов
Напомним, что в стандарте ISO 21500 в определении проекта
отсутствует акцент на временное предприятие, однако два последних
рисунка подсказывают, что в организациях, деятельность которых
структурируется в программах и портфелях, например в организациях,
осуществляющих разработки семейств SIS, для каждого очередного
проекта приходится внутри организаций создавать аналог временного
предприятия, на время, запланированное под каждый проект,
организовывать команду разработчиков проекта, выделять необходимые
ресурсы и осуществлять организационное управление работой
проектировщиков в условиях определенных ограничений.
Отметим, что выполнение программ и обязательств по портфелям
открывает дополнительные направления в части управления проектной
деятельностью, которые находят нормативное отражение в ряде
стандартов, например в ISO 21500 и ГОСТ Р 54869–2011.
29
1.2.2. Структура проектного управления
В соответствии с любым из представленных в п. 1.2.1 определений
проект имеет определенную структуру, схематическое изображение
которой зависит от точки зрения на проект как систему. Другими
словами, для представления проекта можно использовать различные
модели «block and line», отражающие тот или иной аспект его
системности.
Любая системная точка зрения на проект должна отражать его
окружение. Подробную концептуальную информацию об окружении
проекта дает схема из ГОСТ Р 54869–2011, приведенная на рисунке 1.8.
Рис. 1.8. Окружение проекта
Эта схема соответствует определению проекта как комплекса
взаимосвязанных мероприятий, направленных на создание
уникального продукта или оказание уникальной услуги.
Для обобщенной демонстрации видов групп процессов,
раскрывающих деятельностную структуру проекта, принято
30
использовать схему, приведенную на рисунке 1.9, где частично отражена
динамика комплексирования указанных групп.
Рис. 1.9. Взаимодействие групп процессов
Обобщенное представление динамики комплексирования
составляющих проектной деятельности отражает диаграмма,
приведенная на рисунке 1.10.
Рис. 1.10. Динамика групп процессов проекта
Диаграмма отражает тот факт, что в реальном проектировании
процессы групп приходится распараллеливать. Более подробное
содержание групп процессов в контексте их окружения приведено на
рисунке 1.11, заимствованном из стандарта ISO 21500. Детализация
структуры учитывает, что интересы организации не ограничены одним
проектом.
31
Рис.
1.1
1. С
одер
жан
ие г
рупп
про
цесс
ов в
кон
текс
те и
х ок
руж
ения
32
Из последней схемы проекта видно, что в стандарте ISO 21500
уделяется конструктивное внимание извлеченным урокам и выводам из
результатов, поскольку их содержание, скорее всего, будет полезным
при выполнении следующих проектных работ.
Если детализацию продолжить, то она уже будет проходить на
уровне процессов, за которыми в реализации должны стоять лучшие
практики. В стандартах в такой детализации выделяют группы
процессов. Так, например, для стандарта ISO 21500 такие группы
называют предметными.
Каждая предметная группа состоит из процессов, применимых
к любой фазе проекта. Эти процессы определяются в терминах цели,
описания и основных входов и выходов с учетом взаимозависимости.
Стандарт ISO 21500 специфицирует следующие предметные группы:
1. Интеграция (Integration). Предметная группа интеграции
включает в себя процессы, необходимые для идентификации,
определения, комбинации, унификации, координации, контроля
и завершения различных видов деятельности и процессов, связанных
с проектом.
2. Стейкхолдеры (Stakeholder). Предметная группа стейкхолдеров
включает в себя процессы, необходимые для выявления спонсоров
проекта, потребителей и других заинтересованных сторон и управления
ими.
3. Содержание (Scope). Предметная группа содержания включает
в себя процессы, необходимые для идентификации и определения работ
и результатов, а также только требуемую работу и результаты.
4. Ресурсы (Resource). Предметная группа ресурсов включает
в себя процессы, необходимые для выявления и приобретения
требуемых ресурсов проекта, таких как люди, помещения,
оборудование, материалы, инфраструктура и инструменты.
33
5. Сроки (Time). Предметная группа сроков включает в себя
процессы, необходимые для планирования деятельности по проекту
и контроля за ходом выполнения проекта с целью управления
расписанием.
6. Стоимость (Cost). Предметная группа стоимости включает
в себя процессы, необходимые для формирования и контроля
исполнения бюджета в целях управления затратами.
7. Риски (Risks). Предметная группа рисков включает в себя
процессы, необходимые для идентификации угроз и возможностей,
а также управления ими.
8. Качество (Quality). Предметная группа качества включает в себя
процессы, необходимые для планирования, обеспечения и контроля
качества.
9. Закупки (Procurement). Предметная группа закупок включает
в себя процессы, которые требуются для анализа необходимости
наличия определенных продуктов, услуг или результатов, их
приобретения, а также для управления взаимодействием
с поставщиками.
10. Коммуникации (Communication). Предметная группа
коммуникаций включает в себя процессы, необходимые для
планирования и распространения информации, имеющей отношение
к проекту, и управляет ею.
Не трудно заметить, что каждая предметная группа процессов,
обеспечивающих управление, связана с определенными составляющими
вектора управления А в схеме (на рисунке 1.4), адаптированной для
управления проектной деятельностью.
Из множества предметных групп, указанных выше, выделяют
основные составляющие, от соответствия которых установленным
требованиям зависит успешность осуществления проекта. В число
34
основных составляющих принято включать те, которые отображены на
рисунке 1.12.
Рис. 1.12. Основные ограничения проекта
Если ограничиться управлением характеристики «успешность» по
значениям вектора
A = (C, T, S, Q, F, R),
то следует определиться:
− с составляющими проектной деятельности (практиками
технологии, применяемой для создания проектов), влияющими на
компоненты вектора;
− оценками воздействия составляющих проектной деятельности на
компоненты вектора;
− правилами учета влияния оценок воздействия на каждый
компонент вектора;
− механизмом вычисления интегральной оценки успешности на
основании компонентов вектора.
Кроме того, в соответствии с рекомендациями стандарта
ISO/MEK 9004–2009 для достижения устойчивого успеха проектной
организацией ее производственные процессы (практики, отраженные на
рисунке 1.1) следует непрерывно совершенствовать, например, от
проекта к проекту. Непрерывное совершенствование процессов
35
приводит к необходимости нормирования такой характеристики, как
«успех проектной организации», а также создания механизмов
интегральной оценки.
Реализация нормирования и механизмов, указанных выше, на
практике вызывает сложность, поэтому в практической деятельности
конструктивная работа с характеристикой «успешность проектов,
проектной деятельности и проектной организации» осуществляется
в упрощенной форме с использованием характеристики
«профессиональная зрелость».
1.2.3. Зрелость проектного управления
Создатели стандарта CMMI 1.3 старались отобразить проектную
деятельность по созданию программных систем в процессных областях
и их практиках с учетом управления такой деятельностью. Это означает,
что стандарт содержит в себе спецификации для модели зрелости
процессов управления проектной деятельностью, которые могут быть
извлечены из текста стандарта.
В области управления процессами CMMI-Dev содержит общие для
нескольких проектов организации активности: определение,
планирование, развертывание, реализацию, мониторинг, контроль,
оценку, измерение и улучшение процессов.
Управление процессами в CMMI-Dev состоит в следующем:
− организационное определение процесса (OPD);
− сосредоточение на организационном процессе (OPF);
− производительность организационного процесса (OPP);
− управление организационной производительностью (OPM);
− организационная подготовка (OT).
Основная деятельность по управлению процессами в организации
(рисунок 1.13) позволяет реализовать возможности документирования
36
и распространения передового опыта, активных организационных
факторов, а также обучения в рамках всей организации. Сосредоточение
на организационных процессах помогает организации планировать,
реализовывать и внедрять улучшения организационных процессов,
основанные на понимании сильных и слабых сторон процессов
организации и технологических активов.
Рис. 1.13. Основные процессы управления
Сведения о совершенствовании организационных процессов могут
быть получены:
− из соответствующих предположений;
− уроков, извлеченных при совершенствовании;
− результатов оценки процессов и программных продуктов.
Определение организационного процесса устанавливает
и поддерживает набор стандартных процессов организации, стандартов
Руководство
Поддержка проекта и инжениринговые области процесса OPF OPD
OT
Тренинг для проектоа и поддежки групп в стандартных процессах
Потребности и цели процессов в организации
Стандартный прорцесс и другие активы
Предложения по совершенствованию процессов, участие в спецификациях, оценках и развертывании
процессов
Стандартный процесс, работа, стандарты и
другие активы
Улучшающая информация
Ресурсы и координация
Бизнес-цели организации
37
рабочей среды и других активов, включающих описания моделей
жизненного цикла, процессов адаптации и документирования.
Области расширенного управления процессами позволяют
организации использовать усовершенствованную возможность
достижения количественных целей и необходимого уровня качества. На
рисунке 1.14 изображено взаимодействие областей расширенного
управления процессами с другими категориями процессов. Каждый
процесс из расширенной области зависит от возможностей организации
по разработке и внедрению процессов, что, в свою очередь, реализуется
при помощи базовых процессов.
Рис. 1.14. Расширенное управление процессами
В области управления проектами CMMI охватывает активности
по планированию, мониторингу проекта и контролю над ним.
Непрерывное представление процессов управления проектом
определяется следующими активностями:
Руководство
Поддержка проекта и инжениринговые области процесса
OPP
OPM
Данные о стоимости и преимущества
Данные о производительности
и возможностях
Качество и цели процессов
Способность развертывания стандартных процессов и
других активов
Измерения качества процесса, цели
производительности и модели Производительность
Улучшения
Бизнес-цели
Управление
Общие области процнссов базового
управления проектами
Общие измерения
38
− интегрированное управление проектом (IPM);
− мониторинг и контроль проекта (PMC);
− планирование проекта (PP);
− количественное управление проектом (QPM);
− управление требованиями (REQM);
− управление рисками (RSKM);
− управление соглашениями с поставщиками (SAM).
Пошаговое представление процессов управления проектом
определяется уровнями модели зрелости, предлагаемой CMMI.
Уровень 1. Бессистемный.
Уровень 2. Базовое управление проектами:
− планирование проекта;
− управление проектами и контроль их исполнения;
− управление соглашениями с поставщиками.
Уровень 3. Стандартизация процесса интегрированное управление
проектами:
− создание проекта и управление им, вовлечение
соответствующих заинтересованных сторон согласно интегрированному
и определенному процессу, адаптированному к стандартным процессам
организации;
− управление рисками: идентификация потенциальных проблем
до того, как они возникнут, чтобы запланировать действия при
возникновении этих проблем для снижения неблагоприятного влияния
на проект;
− интегрированное построение команды (IPPD);
− интегрированное управление поставщиками (SS): ранняя
идентификация поставщиков ресурсов для проекта, которые могут
использоваться для удовлетворения требований проекта, управление
выбранными поставщиками и поддержание отношений с ними.
39
Уровень 4. Количественное управление:
− количественное управление проектами: управление
процессами проекта с использованием метрических показателей для
достижения целей исполнения процессов с заданным качеством;
− базовые процессы управления проектами включают в себя
определение плана, проверку соответствия работ плану проекта,
принятие корректирующих действий и установление соглашений
с поставщиками (рисунок 1.15).
Рис. 1.15. Базовые процессы управления проектами
Расширенное управление проектами включает в себя адаптацию
стандартных процессов организации к выполнению конкретного
проекта, формирование рабочей среды проекта, координацию работ
и сотрудничество с заинтересованными сторонами проекта,
Область инжинирингп и
поддержки
SAM PP
PMC
Статус, проблемы, результаты процесса и оценки продуктов, измерения и оценки
Статус, проблемы, результаты прогресса и анализ этапов
Соглашение с поставщиком
Предложения по совершенствованию процессов, участие в спецификациях, оценках и
развертывании процессов
Потребность измерений
Планы
Что создавать?
Что делать?
Что отслеживать?
Корректирующие действия
Поставщик
Корректирующие действия
Перепланирование
40
формирование и поддержку команды, количественное управление
проектом и рисками (рисунок 1.16).
Рис.1.16. Расширенное управление проектами
Применение моделей процессов управления, предлагаемых
CMMI, позволяет достичь следующих качественных показателей:
− гибкость: процессы определяются в соответствии с бизнес-
целями, характеристиками продукции;
− модульность: модели делятся на области действия процессов
и уровни;
Такономия рисков и параметоро, смягчение условий и коррекция
SAM
PP PMC
Координирование и объединение
Усвоенные уроки
Идентифицированные риски
Цели производительности процессов, базовые уровни и модели
Процессы для количественного управления
SAM
Области процессов
инжинирингп и поддержки
Рискозависимость из-за нестабильности
процессов
Область инжинирингп и
поддержки
Область базового
управления проектом
Стандартные процессы
организации
Координирование, фиксация проблемы,
архитектура продукта
Данные статистического управлени
Процесс, определённый
для проекта
Управление ИТ для процессов инжиниринга
Интегрирование практик
41
− масштабируемость: возможность использовать модели для
проектов с различными размерами;
− комплексность: проблемы управления и инженерные проблемы
объединяются;
− упрощение формирования дорожной карты проекта: возможность
использовать пошаговые модели процессов или непрерывные.
Использование моделей процессов управления проектами,
предлагаемыми CMMI, способствует достижению следующих
преимуществ:
− сокращение временных затрат при выходе на рынок;
− сокращение трудовых затрат на разработку;
− увеличение степени удовлетворенности потребителя;
− повышение качества продукта;
− высокий уровень культуры разработки у сотрудников.
1.2.4. Стандартизация знаний о проектном управлении
Самым известным стандартом проектного управления считается
стандарт PMBOK, который изначально и во всех своих версиях
(до PMBOK 5:2012) создавался как свод знаний о проектном
управлении или, как часто говорят, как энциклопедия по этой
предметной области. Содержимое этой энциклопедии структурировано
и представлено в таблице 1.4.
В каждом столбце таблицы распределены названия процессов,
причем за конкретным процессом может скрываться либо реализация
практики (определенной проектной задачи), либо поток практик (поток
задач, решение которых должно осуществляться согласованно).
42
Таблица 1.4
Структура стандарта РМВОК
Области знаний
Группы процессов
Ини
циац
ия
Пла
ниро
вани
е
Исп
олне
ние
Мон
итор
инг
и ко
нтро
ль
Заве
ршен
ие
Интеграция Содержание
Сроки Стоимость Качество Персонал
Коммуникации Риски
Покупки Заинтересованные стороны
Так, например, в группу процессов мониторинга и управления входят
следующие процессы:
− мониторинг работ проекта и управление ими;
− общее управление изменениями;
− подтверждение содержания;
− управление содержанием;
− управление расписанием;
− управление стоимостью;
− процесс контроля качества;
− управление командой проекта;
− отчетность по исполнению;
− управление участниками проекта;
43
− наблюдение за рисками и управление ими;
− администрирование контрактов.
Для каждого процесса в документах PMBOK указаны обобщенные
спецификации его входных данных (но не шаблоны данных),
спецификации их обработки (связанные с методами, показавшими свою
эффективность) и результатов обработки (спецификации выходных
данных). PMBOK считается документом, в котором наиболее полно
изложены знания, признаваемые специалистами по управлению
проектами. Стандарт задает определенные рамки для практических
и узконаправленных методологий, но сам методологией, пригодной
к непосредственному практическому применению, не является. Другими
словами, PMBOK является основой для создания практических
методологий.
PMBOK прямолинеен в ориентации на успех. В этой ориентации,
которая отражена на рисунке 1.17, для PMBOK 4 успешность связана
с применением лучших практик, аккумулированных в методическом
сопровождении стандарта.
Рис. 1.17. Структуризация методического сопровождения
44
Идея совершенствования материализуется в структуре и содержимом
стандарта, которые обогащаются от версии к версии. Так, например,
в PMBOK 5 по отношению к PMBOK 4 появилась дополнительная
область знаний «Заинтересованные стороны», большая часть задач
которой в предыдущих версиях была распределена между девятью
изначально существовавшими областями знаний.
Энциклопедичность PMBOK используется разработчиками
прикладных технологий и других стандартов как источник полезных
решений, потенциальных процессов и практик или для сравнений
выбранных решений с PMBOK (например, в виде «Наша технология
и PMBOK»).
1.2.5. Методология PRINCE2
PRINCE2 (Projects IN Controlled Environment) – это мастер-
методология, а также структурированный метод управления проектами,
основанный на управлении процессами. Метод предлагает семь
ключевых принципов и семь тем, которые, при адаптации
к специфическим требованиям проекта, могут снизить риски в проектах
всех видов и объемов. Имея ту же основу, что и руководство PMBOK,
PRINCE2 выдвигает ряд моментов на первый план, чтобы
конкретизировать руководство PMBOK, и отвечает на вопрос: «Как
применить эти концепции в проектах на практике?».
В публикациях о PRINCE2 или его применении часто используют
следующее расширение его аббревиатуры «PRINCE2-7-7-7», указывая на
особую роль числа 7 в его структуре и содержании. Эта роль обобщенно
раскрыта на рисунке 1.18.
45
Рис. 1.18. Обобщенное представление PRINCE2
В PMBOK аналогом тем является набор областей знаний, которых
больше, чем 7. Это объясняется тем, что PRINCE2 сосредоточена на
критически важных областях, что в реальном проектировании может
привести к необходимости обратиться к глубине и диапазону
руководства PMBOK и другим источникам, чтобы завершить некоторые
части управления проектом.
Считается, что используется псевдоPRINCE2, если не принимается
в расчет хотя бы один из следующих 7 его принципов:
1. Целостное экономическое обоснование, которое поясняется на
примере экономического обоснования проекта. Этот принцип
гарантирует, что проект соответствует целям бизнеса, стратегии
и ожидаемой прибыли.
2. Ориентация на опыт: уроки извлекаются, фиксируются и ведут
к дальнейшим действиям в течение всего жизненного цикла проекта.
46
3. Определение ролей и ответственности. Этот принцип
гарантирует, что в проект вовлекаются нужные люди и участники
понимают, что от них ожидается.
4. Управление по стадиям: поскольку планирование существует
только на том уровне, на котором можно управлять и прогнозировать,
проекты планируются, отслеживаются и контролируются на поэтапной
основе, при этом на протяжении всего проекта предусмотрены
контрольные точки на основных этапах работы.
5. Управление по отклонениям: в проектах PRINCE2 для каждого
уровня проектной команды устанавливаются четкие границы
полномочий, основанные на поставленных задачах по срокам, стоимости
и объему (три классических ограничения), а также по качеству, риску
и прибыли. Это позволяет получить полную картину всех факторов
успеха проекта.
6. Ориентация на продукт: поскольку успешные проекты
ориентированы на результат (а не на процесс), проект PRINCE2 ставит
особый акцент на определение, производство и утверждение конечного
результата.
7. Адаптация к проектной среде: поскольку проектами нельзя
управлять по строгим (неизменным) формулам, процессы и темы
должны отражать конкретные условия.
Цель PRINCE2 состоит в следующем: организовать
и сконцентрировать знания по управлению проектами таким образом,
чтобы их легко было адаптировать к различным типам проектной среды.
В основу PRINCE2 заложена процессно-ориентированная модель, схема
которой отражена на рисунке 1.19, причем ориентированная на
результат – продукт проекта.
47
Рис. 1.19. Процессно-ориентированная модель PRINCE2
Отметим, что одним из важных понятий и конструктов в PRINCE2
является «Пакет работ», ориентированный на внедрение автоматизации
в технологию управления. Пакет содержит одно или несколько описаний
продукта, которые служат основой для выполнения работы. В описания
полезно включать:
− сроки, стоимость, взаимодействие менеджера проекта с теми, кто
отвечает за ресурсы;
− информацию о рисках;
48
− предлагаемые (или необходимые) инструменты, техники
и стандарты выполнения работы;
− разъяснения, каким образом провести обзор и оценить текущую
работу, как управлять проблемами, сложными моментами и текущим
состоянием проекта и отражать все это в отчете.
Завершая пункт, отметим, что руководство PMBOK указывает
специалистам по проектному управлению на необходимость применения
методологии управления проектами (как инструмента), тогда как
PRINCE2 предоставляет эту методологию. При их совместном
использовании четкость процессов и сильные стороны метода PRINCE2
дополняются глубиной руководства PMBOK.
1.2.6. Зрелость проектного управления
Методология PRINCE2, как и стандарт PMBOK, не затрагивает
вопросы повышения профессиональной зрелости процессов проектного
управления. Этот пробел устраняет группа стандартов: P1M3 (для
проектов), P2M3 (для программ и проектов) и P1M3 (для портфелей,
программ и проектов). Поскольку стандарты взаимосвязаны
и взаимоувязаны, представим из них только стандарт P1M3
(The Portfolio, Programme, and Project Management Maturity Model).
Эта модель разрабатывалась создателями стандарта PRINCE2 для
того, чтобы представить рекомендации по повышению
профессиональной зрелости организаций, деятельность которых
структурируется в портфелях, программах и проектах.
Модель имеет иерархическое строение и включает 5 уровней
зрелости и 7 процессных областей (представлены в таблице 1.5). Задача
этой модели – помочь компаниям оценить уровень развития
менеджмента на данный момент и разработать план совершенствования.
49
Таблица 1.5
Процессные области
Уровни зрелости
Нач
альн
ый
Пов
торя
ющ
ийся
Опр
едел
енны
й
Упр
авля
емы
й
Опт
имиз
ация
Управленческий контроль
Управление выгодами
Финансовый менеджмент
Управление заинтересованными сторонами
Управление риском
Организационное управление
Управление ресурсами
Каждый уровень зрелости состоит из нескольких атрибутов.
Специальные атрибуты относятся к определенным процессным
областям, в то время как общие одинаковы для всех. К общим относятся:
планирование, информационный менеджмент, обучение и развитие.
Еще одним стандартом, регламентирующим конструктивную работу
организаций по вопросам профессиональной зрелости, является стандарт
OPM3:2008 (Organizational Project Management Maturity Model).
Рекомендации стандарта также распространяются на портфели,
программы и проекты.
Метод, предлагаемый OPM3, обеспечивает возможность оценки
процессов проектного управления в организации для дальнейшего их
50
усовершенствования. Стандарт помогает организациям разработать план
развития проектного управления в компании, следуя которому можно
поэтапно усовершенствовать процессы проектного управления.
Инструментальная составляющая стандарта состоит из трех
взаимосвязанных частей:
1. Знание о том, что такое управление проектами в организации, как
определить уровень зрелости управления проектами и что представляют
собой лучшие практики в управлении проектами. Эта часть включает
базу лучших практик по управлению проектами: около 600 практик,
относящихся к разным объектам управления (портфель проектов,
программа и проект) и к разной степени зрелости описания процессов.
2. Оценка текущего уровня зрелости управления проектами на базе
инструментов, помогающих пользователям при ответе на вопросы
опросного листа (более 150 вопросов) самостоятельно оценить текущую
зрелость управления проектами в организации, определить основные
области компетенций и существующих практик.
3. Способы улучшения процессов управления проектами для
достижения более высокого уровня зрелости. Инструментарий этой
части стандарта помогает компаниям выбрать стратегию и определить
последовательность развития системы управления проектами.
Для описания шагов по совершенствованию управления проектами
в организации используется концепция последовательного улучшения
процессов, лежащая в основе тотального контроля качества TQM
(стандартизация, измерение, контроль, совершенствование). Большую
часть стандарта представляет собой пошаговое описание применения
модели, включая инструментарий оценки (опросник)
и совершенствования (директории лучших практик и способностей).
51
Нормативная база, используемая в практике проектного управления,
не ограничивается стандартами, представленными выше. В эту базу,
например, входят следующие российские стандарты:
− ГОСТ Р ИСО 10006–2005. Системы менеджмента качества.
Руководство по менеджменту качества при проектировании;
− ГОСТ Р 52806–2007. Менеджмент рисков проектов. Общие
положения;
− ГОСТ Р 53892–2010. Руководство по оценке компетентности
менеджеров проектов. Области компетентности и критерии
профессионального соответствия.
1.3. Управление потоками работ
1.3.1. Рациональный унифицированный процесс
Опыт, аккумулированный в стандартах проектного управления,
составляет только часть того, что должно найти свое представление
в зрелой технологии (совокупности технологий), которая применяется
в проектной организации, разрабатывающей семейства SIS.
В условиях, когда проектная организация ориентирована на успех, ее
инструментально-технологическую базу целесообразно строить с учетом
следующих инструментариев:
− моделей зрелости (CMMI, P-CMM, P3M3, OPM3) или их
аналогов;
− аналогов моделей зрелости или библиотек лучших практик для
конструкторско-технологического проектирования аппаратных
составляющих SIS;
− стандартов, аккумулирующих опыт разработок SIS, включая
стандарты, ориентированные на качество, например стандарт ISO 9126;
52
− заимствований опыта, вложенного в родственные
инструментально-технологические средства других проектных
организаций;
− библиотек лучших практик предметной области
разрабатываемого семейства SIS.
Одним из особо полезных источников заимствований
инструментально-технологического опыта считается мастер-
методология RUP (Rational Unified Process, IBM).
Представляя RUP, говорят, что это:
− формализованный подход к определению задач и обязанностей
по их решению внутри организации – разработчика программного
обеспечения;
− четко структурированное описание процесса разработки
программного обеспечения, содержащее перечень работ и задач,
выполняемых в ходе разработки, а также создаваемых при этом
документов и моделей;
− процесс из девяти дисциплин и четырех фаз, предполагающий
выполнение определенной командой (в зрелой инструментальной среде)
нескольких сотен различных типовых задач и разработку почти сотни
различных детально специфицированных артефактов;
− лучшие практические методы (итеративная разработка,
управление требованиями, использование компонентной архитектуры,
визуальное моделирование, непрерывный контроль качества, управление
изменениями) и десять элементов, представляющих квинтэссенцию RUP
(разработка концепции, управление по плану, снижение рисков
и отслеживание их последствий, тщательная проверка экономического
обоснования, использование компонентной архитектуры,
прототипирование, инкрементное создание и тестирование продукта,
регулярные оценки результатов, управление изменениями, создание
53
продукта, пригодного к употреблению, адаптация RUP под нужды
проекта);
− база знаний, представленная в виде гипертекстового
справочника, просматриваемого через браузер и оформленного в виде
Web-сайта.
Если в первых версиях создатели RUP определяли его как
итеративный, архитектурно ориентированный и управляемый
прецедентами использования процесс разработки программного
обеспечения, то в последней версии они указывают, что RUP – это
бизнес-ориентированный процесс, соответствующий набору ABCDEF
из шести принципов (Adapt the Process, Balance Competing Stakeholder
Priorities, Collaborate Across Teams, Demonstrate Value Iteratively, Elevate
Level of Abstraction и Focus Continuously On Quality).
Как готовый продукт RUP состоит из следующих частей:
− лучшие практические методики, предоставляемые
разработчикам;
− Web-сайт, содержащий описание процесса и интегрированный
с набором специализированных инструментальных средств;
− средства конфигурации, позволяющие настраивать процесс под
нужды конкретного проекта;
− средства, позволяющие создавать собственные процессы (IBM
Rational Workbench в ранних версиях и IBM Rational Method
Composer в последней версии);
− сообщество пользователей RUP, вступив в которое, можно
обмениваться опытом (в том числе и готовыми описаниями процессов)
с другими разработчиками.
Как уже отмечено, описание конструируемого по образцам
и исполняемого процесса оформляется в виде Web-сайта (в Интранет-
среде), доступного в качестве справочно-методического материала для
54
всех участников процесса сопровождения. Сайт вводится в действие
с момента начала разработки очередного проекта.
Оформление методических материалов в виде Web-сайта позволяет
облегчить внедрение процесса сопровождения работ в организации
(в команде) за счет следующего:
− все участники внедрения имеют доступ к одним и тем же
методическим материалам, то есть к единому глоссарию терминов,
и единое представление о методах и средствах внедрения процесса
сопровождения;
− материалы Web-сайта могут быть использованы в качестве
справочника с удобным рубрикатором;
− используется единая точка входа, и любое обновление или
коррекция материалов одновременно становятся доступными всем
участникам проекта.
В качестве языка моделирования в общей базе знаний используется
Unified Modeling Language (UML), являющийся международным
стандартом. Особенностью RUP является то, что в результате работы
над проектом создаются и совершенствуются модели. Вместо создания
громадного количества документов на бумажных носителях, RUP
опирается на разработку и развитие семантически обогащенных
моделей, всесторонне представляющих разрабатываемую систему.
RUP – это руководство по тому, как эффективно использовать UML.
Стандартный язык моделирования, используемый всеми членами
группы, делает понятными всем описания требований, проектирование
и архитектуру системы.
Систему RUP часто называют мастер-методологией из-за глубины
проработки деятельностных процессов и эффективного
инструментального обеспечения. Статика и динамика RUP обобщенно
представлены на рисунке 1.20.
55
Рис.
1.2
0. К
онце
птуа
льна
я мо
дель
тех
ноло
гии
RU
P
56
Схема RUP на рисунке представлена в двух измерениях:
вертикальном и горизонтальном.
Вертикальное измерение отражает статические аспекты процессов
и оперирует такими понятиями, как виды деятельности, рабочие
продукты, исполнители и дисциплины. По данному направлению
измерений специфицированы и интерактивно доступны активы RUP
(структуризация процесса, руководства, примеры и шаблоны проектных
решений, шаблоны документов и другие составляющие RUP).
Горизонтальное измерение отражает время и представляет
динамические аспекты процессов, оперируя такими понятиями, как
стадии, итерации и контрольные точки.
На схеме (образно по фазам и итерациям) отражена интенсивность
использования ресурсов на данный момент времени («горбы»
и «впадины») по каждой из групп потоков работ.
Статику RUP определяют шесть групп (дисциплин) потоков работ
процесса разработки и три группы потоков работ поддержки, так что за
каждой группой закреплено определенное содержание действий. Одной
из групп потоков работ поддержки является группа «Управление
проектом» (рис. 1.21).
Схема приведена только для того, чтобы показать достаточно
сложную конструкцию, образованную из лучших практик, отобранных
для решения задач проектного управления, объединенных в группы
согласованных задач, которые, в свою очередь, тоже сгруппированы.
Объединение определенной группы активностей проектировщиков
в поток работ обусловлено взаимосвязанностью задач и взаимоувязкой
их решения во времени.
57
Рис.
1.21
. Пот
оки
рабо
т «У
прав
лени
е пр
оект
ом»
58
В документации и публикациях по RUP широко используются
схемы, отражающие группирование на множестве типовых задач RUP
и их связность. Схемы такого рода относятся к классу визуализируемых
концептуальных моделей. Одной из таких схем является интерактивная
схема взаимодействия проектировщика с задачей, представленная на
рисунке 1.22.
Исполнитель (роль)
Постановка задачи
Методика
Инструменты
Объекты сопровождения
Контрольные точки
Шаблон Руководство по артефактам
Документы
Выполняет
Артефакт
Активность
Ответственный за
Рис. 1.22. Операционная обстановка задачи
Каждая задача любого из потоков представляется унифицированным
способом (с использованием интерактивной визуальной формы)
и нацелена на построение определенного артефакта. На концептуальном
этапе артефакты представляют собой либо документы, либо
концептуальные модели, в том числе модели, построенные на базе
языка UML. Проектировщик, исполняющий определенную роль,
оперативно взаимодействует с задачей, используя ее интерактивную
пиктографику (рис. 1.23).
59
Рис.
Пот
оки
рабо
т «У
прав
лени
е пр
оект
ом»
Рис.
1.2
3. В
заим
освя
зи а
ртеф
акто
в в
RU
P
Д
елов
ой п
ортф
ель
(Bus
ines
s C
ase)
Зап
росы
сов
лад
ельц
ев
(Sta
keho
lder
Req
uest
s)
Док
умен
т-ко
нцеп
ция
(Vis
ion)
С
пеци
фик
ация
тре
бова
ний
к
ПО
(Sof
twar
e R
equi
rem
ents
S
peci
ficat
ion)
Доп
олни
тел
ьная
спе
циф
икац
ия
(Sup
plem
enta
ry S
peci
ficat
ion)
Пре
цед
ентн
ая м
одел
ь (U
se C
ase
Mod
el)
Мод
ель
анал
иза
(Ana
lysi
s M
odel
)
Мод
ель
прое
ктир
ован
ия
(Des
ign
Mod
el)
Мод
ель
разв
ёрты
вани
я (D
eplo
ymen
t Mod
el)
Мод
ель
дан
ных
(D
ata
Mod
el)
Кар
та н
авиг
ации
(N
avig
atio
n M
ap)
Про
тоти
п по
льз
оват
ельс
кого
ин
терф
ейса
(U
ser-
Inte
rfac
e P
roto
type
)
Пл
ан р
азра
ботк
и П
О
(Sof
twar
e D
evel
opm
ent P
lan)
Оце
нка
сост
ояни
я (S
tatu
s A
sses
smen
t)
Пл
ан у
прав
лен
ия к
онф
игур
ацие
й (C
onfig
urat
ion
Man
agem
ent P
lan)
Пл
ан и
тера
ции
(Iter
atio
n P
lan)
Пл
ан р
ешен
ия п
робл
ем
(Pro
blem
Res
olut
ion
Pla
n)
Пл
ан у
прав
лен
ия р
иска
ми
(Ris
k M
anag
emen
t Pla
n)
Пл
ан о
бесп
ечен
ия к
ачес
тва
(Qua
lity
Ass
uran
ce P
lan)
П
лан
изм
ерен
ий
(Mea
sure
men
t Pla
n)
Пл
ан п
риня
тия
прод
укта
(P
rodu
ct A
ccep
tanc
e P
lan)
Пл
ан у
прав
лен
ия т
ребо
вани
ями
(Req
uire
men
ts M
anag
emen
t Pla
n)
Док
умен
т «А
рхи
тект
ура
ПО
» (S
oftw
are
Arc
hite
ctur
e D
ocum
ent)
Пл
ан р
азвё
рты
вани
я (D
eplo
ymen
t Pla
n)
Упр
авле
ние
прое
ктом
Тре
бова
ния
Ана
лиз
и
прое
ктир
ован
ие
Упр
авле
ние
конф
игу-
раци
ей и
изм
енен
иям
и
60
1.3.2. Потоки работ
При решении задач, связанных с бизнес-процессами, за которыми
стоят определенные деятельностные образования, бизнес-процессы
моделируют, применяя различные полезные средства, чаще всего
диаграммные модели и соответствующие им формальные языки
диаграмматики. К числу таких средств, например, относятся
диаграммные средства структурного анализа SADT и унифицированного
моделирования UML.
Наиболее полезным и популярным переходом от бизнес-процессов
реальности к их представлению в модельной действительности является
моделирование бизнес-процессов и их совокупностей в форме потоков
работ (workflows).
Определяя потоки работ и строя их как модели, опираются на
следующие точки зрения:
− функциональную, фокусирующую внимание на исполняемых
активностях как на сущностях (работах), которые перетекают от одной
единицы к другой по определенной схеме;
− поведенческую, акцентирующую внимание на том, когда и при
каких условиях деятельностные единицы исполняются (особое внимание
в данном случае уделяется управлению процессами);
− структурную, раскрывающую моделируемый бизнес-процесс
с системной точки зрения с учетом как объектов деятельности, так
и деятельностных процессов.
В зависимости от специфики бизнес-процессов в построениях их
моделей в форме потоков работ применяют различные подходы
и средства. В наиболее общем плане различают:
− технологические потоки работ (business workflows), для которых
характерно выполнение работ по отлаженным методикам;
61
− научно-исследовательские потоки работ (scientific workflows),
которые обычно приходится строить и использовать в условиях,
подобных научному экспериментированию;
− человеческие потоки работ (human workflows), в которых доля
и значимость действий человека приводит к полезности абстрагирования
от инструментальной составляющей действий.
Основные различия между первыми двумя типами потоков работ
представлены в таблице 1.6. Следует обратить внимание на то, что
существенная разница в особенностях, при сохранении достаточного
объема общности, указывает на необходимость специализирования
инструментальных средств, предоставляемых разработчикам
и пользователям потоков работ, под эти два типа.
Выделение третьего типа – человеческих потоков – отражает тот
факт, что в профессиональной деятельности специалист активно
использует совокупность действий, которые входят в его компетенции
и которые он повторяет, используя инструмент, или не повторяет,
ориентируясь на память.
Реальность человеческой деятельности такова, что в общем случае она собирается из составляющих, для моделирования которых может оказаться полезным создавать модели всех трех названных типов, комбинируя их и интегрируя в более сложные модели.
62
Табл
ица
1.6
Разл
ичия
меж
ду п
оток
ами
рабо
т
63
Одним из важнейших вопросов, связанных с потоками работ,
является следующий: «Каким образом осуществляется управление
потоками работ?»
Ответы на этот вопрос не одинаковы для различных типов потоков.
В настоящее время наиболее детально проработаны методы и средства
управления технологическими потоками работ, на основе которых
разработана нормативная схема управления «Workflow Reference Model
Diagram 2010», представленная на рисунке 1.24.
Рис. 1.24. Нормативная схема управления потоками работ
Приведенная на рисунке 1.24 схема отражает разнообразные версии
материализации технологических потоков работ, включая сервис-
ориентированные приложения и распределенные приложения других
типов. Центральное место в схеме занимает «машина» управления
(workflow engines), под которой понимается программный комплекс,
64
обеспечивающий исполнение потоков работ в соответствии с системой
правил (workflow enactment), которым должны подчиняться
управляемые потоки.
Опыт разработок и внедрения научно-исследовательских потоков
еще не доведен до нормативов, подобных нормативам технологических
потоков. В настоящее время такой опыт материализован в системах
инструментальных средств, таких как Kepler и PtolomeyII.
Завершая пункт, представим этапы жизненного цикла научно-
исследовательских потоков:
− порождение гипотезы;
− проектирование потока с использованием экспериментирования;
− связывание данных и настройка параметров для версии потока;
− исполнение экземпляра потока работ;
− анализ результатов;
− повторение до построения подходящей версии и достижения
необходимых результатов.
1.3.3. Потоки работ в проектной деятельности
Для определения специфики потоков работ в проектной
деятельности вернемся к проблеме успешности разработок SIS
с позиций стандарта ISO/MEK 9004–2009 «Менеджмент для
достижения устойчивого успеха организации. Подход на основе
менеджмента качества» в части, требующей осуществления
и совершенствования «Согласования спецификаций» для
применяемых проектировщиками лучших практик.
В проектной деятельности, нацеленной на разработку SIS,
принципиальное место занимает фронт работ с требованиями
к проектируемой SIS. В общем случае требования поступают в проект из
различных источников. Требования, например, предъявляются
65
заказчиками SIS, выявляются проектировщиками или диктуются
условиями эксплуатации будущей системы.
В технологии, например типа RUP, за этот фронт работ отвечает
группа нормативных практик, применение которых в определенные
моменты приводит к необходимости согласованной спецификации
требований.
Проведем анализ того, кому с кем, что с чем, каким образом
и в каких формах приходится согласовывать для достижения
согласованной спецификации системы требований к разрабатываемой
SIS.
Так, например, в концептуальном проектировании DCD(SIS),
применяя задачи технологии {ZNj}, необходимо заново или повторно
(с учетом полезных модификаций) решить каждую из предметных задач
ZDi любого бизнес-процесса БП будущей SIS.
В такой работе бизнес-процессы разрабатываемой SIS и бизнес-
процессы технологии Т представляют с помощью моделей типа «поток
работ», так что от проектировщиков требуется согласованно решить
группы задач {ZSmi} для каждого из потоков работ {Wm} создаваемой
SIS, решая при этом группы задач {ZNnj}, объединенные в потоки работ
{Wn} технологии T({Wn}). Более того, обычно потоки работ SIS образуют
группы, а потоки работ технологии объединены в группы Gr({Wn}) для
обслуживания этапов проектирования.
Так как исполнение потоков работ и их групп предполагает
согласованное решение групп задач, с каждым потоком работ Wn
и с каждой группой Gr({Wn}) потоков работ можно связать составные
задачи ZWn и ZG
r, приписав им тип W или G. Следовательно, в наиболее
общем плане приходится согласовывать решения задач из множеств
{ZSim} и {ZN
in}, а также решения задач из множеств {ZWm}, {ZW
n}
и {ZGr({ZW
n})}.
66
Фронт работ по согласованию, за которым стоят задачи типа ZC,
разнородный, сложный и очень важный. По этой причине лучшие
практики согласований включают в систему практик технологий.
К числу таких практик относится, например, комплекс практик
построения архитектуры SIS, обслуживающий согласование
требований и их спецификаций на стратегическом уровне разработки.
Однако нормативно предусмотреть все, что приходится делать для
согласования, невозможно. Так, например, невозможно предусмотреть
фронт работ при согласовании каждой конкретной предметной задачи
типа ZS с задачами из множества {ZNnj}.
Таким образом, при решении очередной предметной задачи ZSmi
проектировщик должен перенести ее содержание в применяемые им
нормативные задачи технологии, формулируя и решая подходящие
задачи адаптации ZАq. Заметим, что задачи адаптации {ZА
q} образуют
подкласс ZA класса задач согласования ZC.
Заметим, что отсутствие в технологии практик, на которые
возложены задачи адаптации, не является следствием того, что такую
активность проектировщиков нельзя автоматизировать.
Для того чтобы адаптация к задаче ZSmi оказалась успешной,
проектировщик, в первую очередь, должен понять ее содержание,
то есть достижение адекватного понимания является основной
составляющей адаптации, которая при переносе понятого
проектировщиком в нормативные задачи закрепляется
и регистрируется в нормативных задачах. В результате понимание,
вложенное в используемые задачи технологии, становится доступным
для проверок и использования другими проектировщиками, а также
лицами, заинтересованными в успешности разработки SIS.
67
Ориентируясь на достижение согласованного понимания, можно
обобщенно ответить на вопросы: «кто» и «с кем» осуществляет
согласование требований и их спецификаций.
Во-первых, согласование осуществляет проектировщик сам
с собой, а вернее, проектировщик M, решающий назначенную ему
задачу ZSmi, со своим персональным опытом и его моделями, если они
имеются. В таком согласовании проектировщик выступает в двух ролях –
«специалист, решающий задачу» и «субъект, являющийся
носителем определенного опыта».
Во-вторых, проектировщик осуществляет согласование с другими
членами команды проектировщиков и доступными им моделями опыта,
разумеется, если в этом имеется необходимость.
В-третьих, проектировщик осуществляет согласование
с пользователями и другими лицами, заинтересованными в успешности
проекта.
Отметим, что во всех версиях персонификации согласований,
причем как для процесса согласований, так и для проверки его
результатов, применяются доступный опыт и понимание.
1.4. Гибкое проектное управление
1.4.1. Agile-версии проектной деятельности
Представленная в п. 1.3.1 технология RUP относится к классу
тяжеловесных технологий, которые представляют их пользователям
большое разнообразие практик и их композиций, что приводит
к необходимости настройки технологии как на специфику семейства
проектов, так и на специфику проектной организации.
Для тяжеловесной технологии характерна сложная структура
потоков работ, в осуществление которых вовлечены многие тысячи
экземпляров работ из сотен типовых практик. Такова структура потоков
68
RUP, два фрагмента которой (для двух групп потоков работ из девяти)
были приведены на рисунках 1.21 и 1.23.
Одной из существенных характеристик тяжеловесной технологии
является сложный документооборот с явным применением стандартов
и нормативных схем. Важной характеристикой технологий такого класса
является и строгое следование выбранной или построенной версии
проектного управления, которая соответствует функциям управления,
представленным выше.
Тяжеловесные технологии предусматривают слишком многое, с чем,
возможно, и не придется столкнуться создателям проектов
определенного класса, а возможно, у проектировщиков и нет
возможности для использования тяжеловесной технологии. Практика
показывает, что тяжеловесные методологии зачастую неэффективны, но
для таких случаев есть выход.
Одним из актуально и конструктивно развивающихся
технологических направлений в разработках программного обеспечения
или систем типа SIS является создание и использование гибких
технологий, в основе которых лежат Agile-подходы, а также методы
и средства их материализации (Agile – эджайл – подвижный, проворный,
быстрый, верткий, живой).
Одно из определений гибкой методологии и технологии разработки
говорит, что это «серия подходов к разработке программного
обеспечения, ориентированных на использование итеративной
разработки, динамическое формирование требований и обеспечение их
реализации в результате постоянного взаимодействия внутри
самоорганизующихся рабочих групп, состоящих из специалистов
различного профиля».
69
Однако чаще всего для характеристики гибких технологий
используют Agile Manifesto, состоящий из следующих принципов:
− удовлетворение клиента за счет ранней и бесперебойной
поставки ценного программного обеспечения;
− приветствие изменений требований даже в конце разработки (это
может повысить конкурентоспособность полученного продукта);
− частая поставка рабочего программного обеспечения (каждый
месяц, неделю или чаще);
− тесное ежедневное общение заказчика с разработчиками на
протяжении всего проекта;
− привлечение к работе над проектом мотивированных
специалистов с созданием необходимых условий, оказанием поддержки
и выражением доверия;
− применение такого метода передачи информации, как личный
разговор;
− использование работающего программного обеспечения, что
является лучшим показателем прогресса;
− предоставление спонсорам, разработчикам и пользователям
возможности поддерживать постоянный темп работы;
− постоянное внимание улучшению технического мастерства
и удобному дизайну;
− предоставление возможности выполнять работу без лишних
действий (простота – искусство);
− стремление к самоорганизации: лучшие технические требования,
дизайн и архитектура получаются у самоорганизованной команды;
− постоянная адаптация к изменяющимся обстоятельствам.
Указывают и то, что в Agile-подходы и в их реализацию вложены
следующие идеи:
− люди и их взаимодействие важнее процессов и инструментов;
70
− работающий продукт важнее исчерпывающей документации;
− сотрудничество с заказчиком важнее согласования условий
контракта;
− готовность к изменениям важнее следования первоначальному
плану.
Названные принципы и идеи существенно отличаются от системы
требований к дисциплинированным проектным технологиям
с проектным управлением, о котором говорилось в п.п. 1.2 и 1.3
монографии. Следует отметить, что ничто не мешает использовать (где и
когда это полезно) или дисциплинированные технологии, или гибкие
технологии, или их композиции.
В настоящее время разработан ряд гибких технологий, доля каждой
из которых в применении отражена на рисунке 1.25. Рисунок приведен
в основном для того, чтобы указать на доминирующее использование на
практике средств Scrum и их модификаций. За одной из модификаций
стоит Agile-подход, получивший название Kanban.
Рис. 1.25. Востребованность гибких технологий
SCRUM 58 % SCRUM + XP
17 %
XP 4 %
SCRUMBUN 3 % AUP 2 % FDD 2 %
LEAN 2 %
ДРУГИЕ
71
Разработанные авторами средства программно-картотечного
управления потоками работ построены с использованием
Kanban- и Scrum-подходов, введение в которые представлено ниже.
1.4.2. Введение в Kanban-технологии
Изначально методология и комплекс средств Kanban создавались как
система организации непрерывного потока производства без создания
запасов. Это так называемая система «точно в срок», в результате
работы которой продукты производства поставляются небольшими
партиями напрямую к необходимым пунктам процесса производства, не
попадая на склад. При этом готовая продукция сразу перенаправляется
потребителям.
В дальнейшем эта система была адаптирована к решению задач
управления в разработках программного обеспечения. В настоящее
время накоплен богатейший опыт применения системы Kanban для
управления деятельностью в различных областях, в том числе и для
управления проектной деятельностью в проектировании SIS и их
семейств. Системы управления по образцу Kanban относятся
к Agile-средствам, которые существенным образом отличаются от
традиционных средств проектного управления. Основные идеи,
заложенные в Kanban, раскрывает его доска, обобщенно представленная
на рисунке 1.26.
72
Рис. 1.26. Динамика Kanban-визуализации
Версия обработки заявок, представленная на рисунке, допускает
распараллеливание обработки по следующим состояниям решения
задач: «в процессе решения», «решена», «решение проверено
(оттестировано)» и «работа с задачей завершена (готово)». По ходу
распараллеливания формируются и визуализируются очереди на
обработку по каждому из состояний. Распараллеливание обусловлено
............................................................................................
73
коллективной работой, в которой задачи распределяются между
проектировщиками в соответствии с ролями, выполняемыми ими
в группе. Из-за обнаруженных ошибок, изменений или по другим
причинам допускается возврат обработки.
В представленной версии работы с задачами модель работы
(решения задач группой) в виде системы массового обслуживания
(СМО) можно квалифицировать как многофазную (очереди состояний)
и многоканальную (очереди к членам группы). На практике для очередей
вводят ограничения, причем так, чтобы согласовать потенциал группы
с основным целевым ориентиром работ – уменьшить объем
невыполненной работы. Более детально Kanban-подход с его привязкой
к программному управлению потоков работ будет представлен в третьей
главе.
1.4.3. Введение в Scrum-технологии
Как это констатирует диаграмма на рисунке 1.25, Scrum – это
наиболее востребованный на практике Agile-подход. Изначально он
разрабатывался для создания программного обеспечения, в том числе
и для разработок SIS. В то же время этот подход применим для
инструментальной поддержки коллективной разработки сложных
продуктов.
Как и в Kanban-подходе, команде проектировщиков, применяющих
Scrum, доступен фронт работ, например, в форме потока задач или
в форме пользовательских историй (Бэклог проекта), из которого
проектировщики отбирают определенную совокупность единиц работ
(Бэклог спринта) для их согласованного исполнения (Спринт) на
определенном промежутке времени. Обобщенная схема Scrum
c указанием названных его составляющих приведена на рисунке 1.27.
74
Рис. 1.27. Обобщенная схема Scrum
Scrum-проекты развиваются сериями «спринтов», каждый из
которых представляет собой жестко фиксированную
и непродолжительную по времени итерацию работ, приводящую
к реализации определенной функциональности, выбранной владельцем
проекта из Бэклога проекта по приоритетности. Операционная
обстановка выбора приведена на рисунке 1.28.
Рис. 1.28. Подготовка спринта
75
На практике основной спринт (обычно 2–4 недели) разбивают на
подчиненные спринты (обычно сутки), что повышает гибкость работ
и открывает для проектировщиков возможность вводить в процесс
новые задачи, если в этом появляется необходимость.
Работы в рамках спринтов проводят в соответствии со следующим
набором правил:
− правила, согласно которым проводится управление требованиями
к продукту;
− правила планирования итераций;
− основные правила взаимодействия участников команды;
− правила анализа и корректировки процесса разработки.
Принципиальное место в Scrum-процессах занимает
экспериментирование, по результатам которого выявляются
производительность команды и другие характеристики коллективной
работы.
Одной из особенностей Scrum-процесса являются регулярные
(зачастую ежедневные) совещания, во время которых происходит
обсуждение результатов предыдущих спринтов (итераций) и ставятся
задачи на следующие. Это позволяет команде держать под контролем
процесс разработки и при необходимости направлять его в нужное
русло.
Scrum-процессы принято визуализировать по образцу визуальной
доски Kanban. Более того, эти два подхода принято интегрировать
в единую систему Scrum_Bun.
1.4.4. Инициатива SEMAT
Практически все, что рассматривалось выше, создавалось для выхода
из кризиса программной инженерии, явным индикатором которого
является недопустимо низкая степень успешности изделий и систем,
76
в которых используется программное обеспечение. Однако, несмотря на
все усилия и решения последних двадцати лет, кризис сохраняется,
о чем убедительно говорит статистика корпорации Standish Group.
Более того, специалистами ожидается, что если в индустрии разработки
программ не произойдет кардинальных изменений, то мир неизбежно
начнут сотрясать техногенные катастрофы, вызванные ошибками в коде
или сбоями при управлении сложными программными продуктами.
Таким образом, делать что-то следует, опираясь на опыт,
полученный в разработках и при использовании громаднейшего
«зоопарка» подходов, методов и средств, незначительная часть которых
аббревиатурно представлена на рисунке 1.29.
Рис.1.29. «Зоопарк» подходов и средств
В настоящее время (как и раньше) существует множество инициатив,
направленных на то, чтобы усовершенствовать способы разработки
программного обеспечения и средств на его базе. К числу таких
инициатив относятся и те, в которых осуществляется совершенствование
Agile-подходов, а также инициатива SEMAT (Software Engineering
Methods and Theory).
Инициатива SEMAT направлена на формирование научных основ
программной инженерии, получивших признание специалистов
в области информационных технологий и являющихся основой развития
77
индустрии создания программного обеспечения для разных прикладных
областей разными методами.
Авторы инициативы исходили из следующей совокупности проблем
программной инженерии:
− распространенность увлечений, более характерная для индустрии
моды, нежели для инженерных дисциплин;
− отсутствие основательной, широко признанной теоретической
базы;
− огромное число методов и их вариантов, разница между
которыми плохо понимается и искусственно преувеличивается;
− отсутствие заслуживающих доверия экспериментальных оценок
и подтверждений;
− разрыв между научными исследованиями и практическим
применением.
В своих решениях SEMAT поддерживает процесс переопределения
программной инженерии на основе убедительной теории, проверенных
принципов и лучших практик, которые:
− включают ядро, состоящее из общепринятых элементов,
с возможностью расширения под конкретные нужды;
− затрагивают как вопросы технологии, так и человеческий фактор;
− поддержаны индустрией, наукой, исследователями
и пользователями;
− поддерживают расширение, вызванное изменениями
в требованиях и технологиях.
В настоящее время инициатива SEMAT получила свое нормативное
выражение в свободном стандарте «Essence of Software Engineering»,
содержащем описание фреймворка для отслеживания прогресса
и «самочувствия» деятельности по разработке программных средств.
78
Принципиальной составляющей фреймворка является его ядро, схема
которого приведена на рисунке 1.30.
Рис. 1.30. Схема ядра SEMAT
Ядро состоит из совокупности взаимосвязанных «альф» (alpha –
специальный графический примитив на схеме), под каждой из которых
понимается обязательный элемент деятельности, используемый для
оценки прогресса и продуктивности состояния работ в сфере конкретной
альфы.
Инициаторы SEMAT исходили из того, что ядро должно состоять из
наиболее распространенных элементов, универсальных для всех работ
по разработке программного обеспечения. Ядро должно быть выделено
за счет абстракции из большого количества методов.
Такие установки привели к следующим спецификациям ядра:
− ядро исполнимо, единицей исполнимости является альфа;
− ядро расширяемо, то есть содержит способ, которым оно может
быть расширено для поддержки разных проектов;
79
− ядро практично, то есть является ясным, осознанным способом
мышления, сфокусированным на поддержке профессионалов в области
разработки ПО в том, как они выполняют свою работу.
Так любой проект, который следует рекомендациям и правилам
SEMAT, начинается с настройки ядра на его особенности, после чего,
при необходимости, оно расширяется по образцу, схема которого
приведена на рисунке 1.31.
Рис.1.31. Оперативное формирование технологии
Стандарт SEMAT допускает расширение ядра за счет включения
в него полезных альф, которые, разумеется, должны быть связаны
с альфами базового ядра. Как это должно осуществляться, в стандарте
демонстрируется на примере включения в ядро проектного управления
по схеме Scrum (рис. 1.32).
80
Рис. 1.32. Scrum-расширение SEMAT
Подводя итог пункта, подведем итог и главы. Практически все, что
связано выше с профессиональной зрелостью, относится к знаниям,
умениям и навыкам проектировщиков, выполняющих назначенные им
роли в осуществлении нормативных бизнес-процессов, или, что то же
самое, в решении нормативных технологических задач, которые
в рассматриваемом случае приводят к созданию АС.
В такой деятельности коллектив проектировщиков может выполнять
работы в двух принципиально различных вариантах технологических
условий.
В первом варианте коллектив работает, применяя определенную
технологию, для комплектации которой был осуществлен отбор
существующих лучших практик, их настройка на согласованность,
возможно, с учетом совершенствования профессиональной зрелости.
81
Во втором варианте полезная технология строится по ходу
выполнения проектных работ в соответствии с первым вариантом,
но с учетом рекомендаций стандарта SEMAT.
И в первом и во втором вариантах проектной деятельностью,
разумеется, необходимо управлять, применяя опыт проектного
и процессного управлений, о котором говорилось выше.
Большое количество разнородных лучших практик, которые следует
включать в успешные технологии разработки SIS, указывает на то, что
нельзя рассчитывать на их запоминание проектировщиками, а следует
создавать библиотеки практик, в которых каждая из практик
представлена в форме, обеспечивающей ее эффективное применение.
Более того, проектировщикам, освоившим интегральные
совокупности нормативных практик, придется оперативно адаптировать
каждый из экземпляров используемых практик к предметной области
разрабатываемой SIS.
Следовательно, эффективное представление практик в библиотеках
необходимо ориентировать на решение задач адаптации в процессах
настройки библиотечных единиц к их применению как экземпляров.
В монографии для решения задач адаптации предлагается
использовать методы и средства псевдокодового программирования
(п. 4.2), а для представления рабочих практик целесообразно
использовать их псевдокодовые программные модели. Предлагаемое
решение способствует совершенствованию производственного процесса
проектной организации, нацеленной на управляемое повышение уровня
зрелости. Программные представления практик во всех предметных
областях, охваченных проектной деятельностью, способствуют не
только адаптации и совершенствованию рабочих практик, их
применения позволяют ввести в управление проектной деятельностью
дополнительные позитивные эффекты, ряд из которых входит
82
в интересы авторов монографии, содержание которой нацелено на
программное управление потоками работ в проектировании АС и их
семейств.
Выводы по первой главе
1. Разработка систем, интенсивно использующих программное обеспечение, считается одним из наиболее проблемных видов деятельности, степень успешности которой недопустимо низка.
2. За чрезвычайно низким процентом успеха в разработках систем SIS стоят определенные причины, обусловленные, в основном, тем, что освоение (человечеством) такого вида деятельности еще не достигло уровня гарантийной предсказуемости ее результатов.
3. Слово «успех» принято употреблять как оценочную характеристику, которую приписывают результату деятельности по степени его востребованности «потребителями». Такую характеристику принято переносить и на исполнителя деятельности, приведшей к успешному результату, и на саму эту деятельность.
4. В инвариантное содержание понятия «успех деятельности», независимо от ее вида, разумно включить целевую составляющую, ориентирующую ее исполнителей на постоянное совершенствование деятельностных процессов, обусловленное желанием выиграть в конкурентной борьбе за потребителя продуктов деятельности.
5. Уровень зрелости производственного процесса – это степень, до которой тот или иной процесс определен, управляем, измеряем, контролируем и эффективен.
6. В теории и практике зрелых процессов накоплен богатейший опыт, практическая часть которого нашла свое отражение в стандарте CMMI Development 1.3 (Capability Maturity Model Integrated), позволяющем оценить уровень зрелости процесса разработки SIS.
7. Популярность стандарта CMMI 1.3, начиная с его ранних версий и их эволюции, привела к построению родственных схем группирования нормативных практик, которые либо детализируют деятельность по разработке SIS, либо относятся к другим видам деятельности.
8. Результат процесса разработки в существенной мере зависит от технологической дисциплины и ее потенциала, который определяется системой практик, включенной в технологию. Достижение положительного результата от применения зрелой технологии, разумеется, в существенной мере зависит от
83
профессиональной зрелости разработчиков, исполняющих практики технологии.
9. При характеристике и оценке профессиональной зрелости исполнителей принято исходить из уровня их «компетентности». Каждому уровню приписывают определенную «квалификацию».
10. Логическим развитием детализации профессиональной зрелости в ее приложении к разработкам SIS является так называемое «Колесо компетенций», объединяющее (с позиции компетенций) 11 направлений, в которых около 400 ключевых областей деятельности.
11. Важнейшим направлением достижения успешности разработок SIS считается эффкктивное управление процессом проектирования нв стратегическом, тактическом и оперативном уровнях коллективной деятельности.
12. С управлением проектами связан определенный фронт работ, выполняемых проектировщиками, а значит, и необходимость применения соответствующих «лучших практик» и использования подходящих инструментов.
13. Опыт управления проектами аккумулируется в стандартах, наиболее популярными и полезными из которых считаются стандарты PMBOK 5, PRONCE2 и P3M3.
14. Особое направление в управлении проектами связывают с гибкими технологиями, среди которых популярное место занимают технологии Kanban и Scrum.
15. Управление проектами немыслимо без измерений характеристик выполняемых работ, результаты которых используются по обратной связи и определяют качество коллективной проектной деятельности
16. Необходимость внимательного отношения к характеристикам качества практически на любом интервале жизненного цикла SIS привела к созданию «метрологии качества SIS», включающей достаточно строгий понятийный аппарат, библиотеки метрик, а также подходы, методы и средства измерений и их использования в процессе проектирования SIS.
17. Измерения помогают в достижении необходимой степени понимания, в выявлении и оценивании свойств процессов и продуктов проектирования, в планировании и управлении процессами, в том числе их совершенствовании.
18. Заказчик, настаивая на включении в состав требований определенной характеристики качества, должен знать, что это имеет определенную цену, которая зависит от того, какое значение характеристики должно быть достигнуто.
84
19. В работе с качеством выделяют этап отбора действительно важных для потребителя характеристик качества и оценки из допустимых значений. В такой работе полезен метод «Goal-Question-Metrics», который применим не только к работе с характеристиками качества программных составляющих SIS.
20. Одним из важнейших направлений экспериментирования в разработках SIS является выявление ошибок, недочетов и дефектов, обусловленных действиями проектировщиков, что приводит к задачам управления изменениями.
21. Появление дефектов носит случайный характер, как и моменты их обнаружения. Такой характер открывает возможность использования результатов статистики в работах с дефектами, включая действия по снижению частоты их появления.
22. Для того чтобы подчеркнуть разнородность и глубину компетенций, без наличия которых невозможно разработать качественную SIS, представим нормативную базу, обслуживающую процесс обеспечения качества по направлению «Информационная безопасность».
23. Как уже отмечалось выше, интересы авторов монографии связаны с разработкой семейств SIS организациями, в деятельности которых существенное место занимает проектирование. Практика создания семейств SIS демонстрирует, что и в этом случае справедливо все, что имеет отношение к успешности, но в условиях, когда в очередных проектах приходится учитывать и применять опыт предыдущих проектов, включая опыт управления проектами.
85
Глава 2. Вопросно-ответная среда WIQA
2.1. Взаимодействие с опытом в проектировании АС
2.1.1. Опыт разработок АС В предыдущей главе разработка SIS и роль проектного управления
в такой работе были специально представлены с позиции базовых
стандартов, имеющих непосредственное отношение к проблеме
достижения успешности проектной деятельности. Выбор позиции
обусловлен интересами авторов монографии, в которой представлена
совокупность их решений, нацеленных на вклад в повышение
успешности разработок АС как класса SIS за счет инновационных
методов и средств программного управления потоками работ,
ориентированных на Kanban и Scrum.
Класс АС выбран из-за того, что методы и средства материализованы
в инструментально-моделирующей среде WIQA, которая изначально
создавалась для автоматизации процессов концептуального
проектирования АС и их семейств. По этой причине в дальнейшем, когда
речь зайдет об авторских решениях, для обозначения продуктов
проектирования будет использоваться символика АС, а в общих
рассуждениях – символика SIS.
Перечисленные стандарты и другие, обобщающие опыт разработки
SIS и их семейств, являются, в первую очередь, богатейшей коллекцией
методов проектирования, а также процессов и практик их реализации.
Коллекция создавалась в результате исследований и разработок
конкретных ученых и практиков, в числе которых особое место
86
занимают работы S.W. Ambler, V.R. Basili, G. Booch, L. Constantine,
A. Cockburn, W.S. Humphrey, Ph. Kruchten, D. Parnas, H.D. Rombach.
Анализ содержания стандартов, ориентированных на конструктивное
достижение успеха проектной организации, и практики их внедрения
в проектную деятельность приводят к следующим двум группам
выводов.
Группа 1.
1. Применение нормативных моделей профессиональной зрелости
на практике представляет собой долгий и трудоемкий процесс.
2. В содержании стандартов типично описание только структуры
лучших практик, трактовку элементов применительно к конкретной
организации и их наполнение (регламентами и методиками)
осуществляет компания.
3. Для внедрения стандартов в организации необходимо иметь
специалистов высокой квалификации в сфере управления проектами.
4. Просматривается сложность адаптации нормативных процессов,
зарегистрированных в базах практик, к специфике организации и ее
проектной деятельности.
5. Механизмы оценки профессиональной зрелости являются
субъективными, что может привести к занижению либо завышению
реального уровня зрелости.
Группа 2.
6. Содержание стандартов представляет достаточную информацию
для того, чтобы разработать комплексный подход к совершенствованию
профессиональной зрелости организации на разных уровнях управления
от отдельного проекта и программы до портфеля проектов.
7. Применение стандартов позволяет выработать направление
и конкретные шаги совершенствования профессиональной зрелости
87
и повышения степени успешности производственной деятельности
проектной организации.
8. Разработанные в стандартах модели предлагают критерии оценки
уровня зрелости и ключевые действия, которые необходимо выполнить
для продвижения на следующий уровень.
9. Ориентация на стандарты позволяет оценить требуемый уровень
менеджмента, необходимый для достижения целей.
10. Внедрение системы управления совершенствованием
в проектной организации задает конструктивное направление для
продолжительного ее развития.
И все же сложившийся опыт, интегрирующий опыт,
аккумулированный в полезных стандартах, в том числе в стандартах
профессиональной зрелости, а также опыт из других источников,
в первую очередь, вложенный в технологии проектирования успешных
проектных организаций и корпораций (например, таких как Microsoft,
IBM, APPLE, ORACLE), еще не достиг состояния, которое позволяет
снять проблему чрезвычайно низкой успешности разработок SIS.
Поиск инновационных решений в предметной области создания SIS
продолжается. Исследования и разработки, в которых предпринимаются
попытки повысить степень успешности, считаются актуальными.
Именно с такими целевыми ориентирами связаны научно-практические
интересы коллектива, членами которого являются авторы настоящей
монографии.
В коллективе исследуются и разрабатываются подходы, методы
и средства, в основе которых лежит оперативное использование
в проектной деятельности опыта, доступного проектировщикам. В такой
работе коллектив ориентируется на вопросно-ответные процессы
формирования и применения доступного опыта, в который входят
88
личный и коллективный опыт проектировщиков, а также модели опыта,
в том числе вложенного в технологии и инструменты.
В исследованиях и разработках коллектива, в который входят авторы
монографии, сложился и собственный опыт, принципиальная часть
которого нашла свое материальное выражение в вопросно-ответной
моделирующей среде WIQA.
Как уже было отмечено, изначально комплекс WIQA разрабатывался
для инструментально-технологического сопровождения процессов
решения задач в концептуальном проектировании АС. Этот этап
разработки особо критичен к дорогостоящим ошибкам и промахам,
причем основной причиной их возникновения являются проблемы
с пониманием, которое всегда строится с учетом использования
доступного опыта.
Решая любую задачу, проектировщик вкладывает в свою работу
и в ее результаты определенное понимание, которое в конструктивном
плане должно выводить на те единицы опыта, которые привели
к решению.
Исходя из такой установки был задуман комплекс WIQA
и разработан ряд его версий, последними из которых являются комплекс
WIQA.Net для коллективной работы и комплекс OwnWIQA для
индивидуальной работы. У комплексов единая концептуально-
методологическая основа, что позволяет представить их архитектурно
просто как комплекс WIQA. Ниже, там, где возникнет необходимость
Если решение задачи, которая поставлена перед проектировщиком, будет им конструктивно представляться и интерпретироваться в единицах опыта, связанных с решением, то это будет способствовать пониманию решения самим проектировщиком и его коллегами, а следовательно, будет способствовать предотвращению дорогостоящих семантических ошибок и их обнаружению.
89
указать на особенности реализации, эти версии комплекса WIQA будут
называться собственными именами.
2.1.2. Особенности комплекса WIQA
Наиболее общим видом задач, с которым связаны интересы авторов
монографии, является задача Z* разработки очередной АС из их
семейства. За этой задачей стоят все остальные задачи проекта (как
технологические, так и предметные), отношения подчиненности между
которыми фиксируются деревом задач.
Особое место в комплексе WIQA занимает та его часть, которая
предназначена для отображения процесса решения задачи Z* и его
результата, то есть проекта АС, на семантическую память вопросно-
ответного типа – QA-память. К особенностям QA-памяти, структура
и спецификации которой детально раскрыты в монографии, относится
то, что она специфицирована и материализована для обслуживания
взаимодействий проектировщиков с доступным опытом.
За учет особенностей проектирования АС в отображениях Z* на
QA-память отвечает вопросно-ответная модель этой задачи, которая
построена на основе анализа типологии потоков работ и задач в потоках
технологии RUP, а также анализа моделей задач из других источников.
В построениях QA-модели задачи Z* были использованы
рекомендации стандарта IEEE Std 1471-2000. IEEE Recommended
Practice for Architectural Description of Software-Intensive Systems. Этот
стандарт рекомендует использовать в создании SIS (а значит, и АС)
интегральную совокупность архитектурных видов. Так как решение
задачи Z* представляет собой соответствующий проект АС,
то применение рекомендаций стандарта IEEE 1471 правомерно.
90
Применение указанных рекомендаций к информационной базе,
полученной в результате анализа RUP и других источников, привело
к архитектурной модели задачи Z*, отображенной на рисунке 2.1.
Отметим, что центральное место как в архитектуре, так и в самой
модели занимают задачный и логико-лингвистический виды. Задачный
вид введен в модель для того, чтобы представить иерархию
подчиненных задач как для задачи Z*, так и для любой другой задачи
Zi из дерева задач Т(Z*, t) = Т({Zi}, t) в его состоянии на момент времени
t процесса разработки АС.
Рис. 2.1. Архитектура типовой QA-модели
Логико-лингвистический вид фиксирует (в вопросно-ответной
форме) рассуждения проектировщика, которые привели его
к построению концептуального решения задачи Zi. Задачный и логико-
лингвистический виды являются родственными, поскольку то, что
91
называют задачами, является определенным видом вопросов. Одной
из версий ответов на вопрос-задачу является совокупность действий по
ее решению.
Задачный и логико-лингвистический виды определяют ядро
интегральной системы видов QA(Zi), из-за чего такое образование
и названо QA-моделью. Остальные виды развивают модель,
надстраиваясь над их содержанием и открывая новые направления работ
по построению решения и его повторному использованию:
− интеллектуально-организационный вид раскрывает назначение
ответственных за решение задачи Zi и ее подзадач {Zij};
− деятельностный вид фиксирует динамические отношения
процессов решения совокупности Zi∪{Zij} с использованием потоков
работ;
− коммуникативный вид выделяет коммуникативные задачи,
которые пришлось решать в работе с задачей Zi;
− остальные виды, как и коммуникативный вид, выводят на
соответствующие группы задач, решение которых способствует
построению и использованию схемы решения задачи Zi.
Инструментарий WIQA обеспечивает информационно-процедурное
овеществление архитектурных видов, представленных на рисунке 2.1,
в форме, интерактивно доступной проектировщикам для использования
модели QA(Zi) по назначению.
В схеме архитектуры отражен тот факт, что модель построена на базе
задач технологии RUP, вернее, технология RUP использовалась как
важнейший источник требований к реализации QA-моделей. Отметим,
что типовая QA-модель, в первую очередь, представляет собой
совокупность образцов (артефактов, моделей, процедур), которая для
каждой задачи и любой из ее подзадач шаг за шагом (пошаговая
детализация + итерация) наполняется информационным содержанием,
92
извлекаемым из реальных рассуждений разработчиков АC. Специфика
типа задачи учитывается в настройке архитектурных видов экземпляра
модели.
Как было отмечено выше, за формирование и использование
QA-модели задачи Z*i конкретного проекта ACi отвечает только часть
комплекса WIQAK – его ядро (kernel), которое можно виртуально
объединить с QA(Z*i). Образованный таким образом конструкт (WIQAK,
QA(Z*i)) представляет собой специализированную АСWIQA,
обеспечивающую создание концептуального проекта для ACi.
Типовая модель, приведенная на рисунке 2.2, определяет требования
к комплексу ядра WIQA, в соответствии с которыми он был построен в
первых своих версиях и развит до его текущих версий. Компонентный
состав версии WIQA.Net приведен на рисунке 2.2.
Рис. 2.2. Компонентная структура комплекса WIQA.Net
93
На рисунке 2.2 обобщенно представлен компонентный состав
инструментария WIQA.Net, в котором выделены наследуемые базовые
средства комплекса и дополнительные компоненты, включающие:
− набор трансляторов псевдокодовых программ, куда введены два
интерпретатора и два компилятора, специфика которых будет раскрыта
ниже;
− формирователь интерфейсных сборок, предназначенный для
создания интерфейсных форм, объединяющих псевдокодовые
программы и исполняемые коды других типов в целостные образования;
− инструментальная среда псевдокодового программирования,
обеспечивающая создание псевдокодовых программ, их отладку
и сборку в более сложные комплексы, в том числе сборку образцов
прецедентов.
Возможны две версии размещения компонентов: с сохранением
клиент-серверной структуры и без. Для однопользовательской версии
OwnWIQA все функциональности сервера и клиента размещены на
одном компьютере и оптимизированы. Web-оболочка, разработанная
только для версии комплекса WIQA.Net, позволяет осуществлять его
комплектацию, в которой клиенты связаны с сервером через Интранет.
Такая возможность предусмотрена для подключения к сети WIQA.Net
рабочих мест, управляемых операционными системами, отличными от
Windows.
Одной из специфик комплексов WIQA.Net и OwnWIQA является
поддержка псевдокодового программирования, ориентированного на
прецеденты. Такая возможность, во-первых, позволяет расширять
функционал комплекса WIQA, а во-вторых, – строить на основе этого
комплекса приложения.
94
В расширениях потенциала и в приложениях этот комплекс
допускает ряд полезных интерпретаций, основными из которых
являются следующие:
− инструментальная интерпретация, позволяющая выделить
в комплексе WIQA набор средств (компонентов), инвариантный по
отношению к потенциальным приложениям, и использовать такой набор
как ядро разрабатываемого приложения, которое адаптируется
к приложению и наполняется необходимым предметным содержанием;
− интерфейсная интерпретация, в соответствии с которой
оболочка обеспечивает взаимодействие интеллектуального процессора
(интеллектуальных процессоров) с компьютерным процессором
(компьютерными процессорами) в выполнении распределенной между
ними работы;
− процессорная интерпретация, позволяющая проводить
параллели и конструктивно использовать аналогии с компьютерными
процессорами и программированием.
Инструментальная точка зрения акцентирует внимание на том, что
комплекс (инструментарий) WIQA предоставляет его пользователям
необходимые декларативно-процедурные средства (вопросно-ответные
формы, операции, методики) для построения полезных QA-моделей
и проведения с ними полезных экспериментов в формах вопросно-
ответного моделирования (QA-моделирования).
Интерфейсная интерпретация настраивает пользователей на то, что
комплекс (среда) WIQA обеспечивает взаимодействие человека,
использующего свой интеллектуальный потенциал и доступный опыт,
с компьютерными средствами в процессах решения проектных задач.
Другими словами, среда WIQA выполняет функции посредника,
обслуживающего взаимодействие человека, выполняющего роль
95
интеллектуального процессора (I-процессора), с компьютерным
процессором (К-процессором).
Процессорная точка зрения фокусирует внимание на том, что для
обеспечения взаимодействий I-процессоров с доступным опытом
с К-процессорами комплекс (среда) WIQA представляет возможности
программирования на специализированном псевдокодовом языке,
встроенном в комплекс WIQA.
2.1.3. Вопросно-ответная память
В любых версиях интерпретации комплекса WIQA их содержание
и особенность определяет память для хранения QA-моделей и их
составляющих следующих типов: вопрос Q, ответ А и задача Z. Каждый
из этих типов в среде WIQA специфицирован как визуализируемый
интерактивный объект. Вопросно-ответная память (QA-память)
предназначена для хранения в своих ячейках экземпляров объектов
типов Q, А и Z.
Для того чтобы пояснить особенности QA-памяти, ответим на
следующие вопросы:
1. В чем проявляется сходство QA-памяти и компьютерной памяти?
2. В чем состоит различие QA-памяти и компьютерной памяти?
3. Какие имеются положительные результаты от применения
QA-памяти для деятельности проектировщиков?
4. Какие направления развития QA-памяти были проверены
и выполнены, а какие могут оказаться перспективными?
При ответе на эти вопросы будем учитывать как оперативную память
процессора, так и внешнюю память компьютера.
Сходство QA-памяти и компьютерной памяти
Начнем сопоставления с внешней памяти. По сути дела, QA-память
создается за счет преобразования реляционной модели данных,
96
овеществляемого с помощью средств MS SQL Server, в совокупность
иерархических моделей со структурой, представленной на рисунке 2.3.
Рис. 2.3. Формирование QA-памяти
На рисунке для интерактивных объектов специально введены
обозначения X и Y. Это объясняется тем, что Q- и A-объекты могут быть
разных типов. Так, например, Z-объекты определены как тип вопросов.
Тип объекта является одной из важнейших характеристик, которая
визуализируется как часть системного имени N(X) объекта <имя
объекта> ::= <тип объекта> <уникальный составной индекс>.
Системное имя способно выполнять роль «адреса» объектов QA-памяти.
Имена X и Y введены и для того, чтобы в сопоставлениях
максимально абстрагироваться от содержания, которое приписывают
вопросам и ответам.
Иерархическая модель данных во внешней памяти активно
применялась в теории и практике баз данных и сохраняет свою
значимость и в настоящее время, уступая по широте применений
X11 X12 X1m
Xp1
X2n X22 X21
X2
X1 Y1 Y11 Y12 Y1m
Y21 Y22 Y2n
Yp1 Yp2 Ypr
X
Y2
Xp Ap
Xp2 Xpr
X11 X12 X1m
Xp1
X2n X22 X21
X2
X1 Y1 Y11 Y12 Y1m
Y21 Y22 Y2n
Yp1 Yp2 Ypr
X
Y2
Xp Ap
Xp2 Xpr
X11 X12 X1m
Xp1
X2n X22 X21
X2
X1 Y1 Y11 Y12 Y1m
Y21 Y22 Y2n
Yp1 Yp2 Ypr
X
Y2
Xp Ap
Xp2 Xpr
97
реляционной модели. Такая модель может служить полезным
источником требований для развития QA-памяти.
Каждой иерархической модели, с позиций оперативной памяти,
соответствует широко используемая на практике структура данных
«дерево», узлами которой в рассматриваемом случае являются объекты
X- и Y-типов. Практика представления объектов в оперативной памяти
имеет богатейшую историю, закрепившуюся в объектно-
ориентированном программировании.
Различие QA-памяти и компьютерной памяти
Вернемся к сопоставлениям. Отметим, что при переходе от структур
хранения в реляционной базе данных к иерархическим структурам
с содержанием X- и Y-объектов никаких изменений не происходит, если
не считать возможности их визуализации.
В то же время в процессе преобразования реляционной модели
формируется совокупность иерархических моделей, которую нельзя
считать просто заменой реляционной модели ее аналогом в форме
иерархической модели.
Традиционная иерархическая модель является константной схемой
базы данных, в то время как иерархические модели QA-памяти
представляют задачи в динамике поиска и построения схемы их
решения, то есть способны изменяться во времени. Их структура не
определяет характеристики QA-базы, то есть схемы отношений
соответствующей реляционной модели.
Важным отличием является и то, что атрибутику любого узла
проектировщик может расширить, добавив к системным атрибутам,
определяющим реляционные отношения QA-базы, дополнительные
атрибуты с помощью специального плагина, включенного
в инструменты WIQA.
98
С позиций оперативной памяти отметим только специфику дерева –
наличие соответствия между двумя типами вершин, а именно – каждому
X-узлу соответствует родственный и дополнительный к нему Y-узел.
Позитивы от применения QA-памяти
В число позитивов от введения интерпретации структур хранения
QA-базы в форме QA-памяти входят следующие:
− QA-память ориентирована на хранение в ней совокупности
иерархически связанных объектов двух типов, второй из которых
дополняет содержание первого, например, следующим образом:
<вопрос> + <ответ>, <задача> + <решение>, <причина>
+ <следствие>, <переменная> + <значение> или <тема> + <тема>;
− любые информационные объекты, загружаемые в QA-память,
наследуют богатую атрибутику ее «ячеек», ориентированную на
интерпретацию этих объектов с позиций вопросов и ответов;
− любой объект, загруженный в такую память, может быть
доопределен, предварительно или оперативно, дополнительными
атрибутами, например, расширяющими его семантику или
выполняющими служебные задачи;
− память предназначена для хранения и предъявления по
оперативным запросам проектировщиков моделей вопросно-ответных
рассуждений, использовавшихся в процессах концептуального решения
задач;
− память позволяет загружать в нее любые совокупности данных
любых традиционных типов и псевдокодовые программы в форме,
ориентированной как на их исполнение проектировщиками, так и на
исполнение компьютером.
99
2.2. Применение QA-памяти
2.2.1. Отображение операционного пространства
QA-память введена в комплекс WIQA, в первую очередь, для
представления в ее структурах (отображения на QA-память) проекта АС
и процесса его создания на концептуальном этапе проектирования.
Отметим, что в настоящее время потенциал этого комплекса позволяет
отображать на QA-память не только работу с одним проектом,
но и операционное пространство разработки семейства АС, что
обобщенно показано на рисунке 2.4.
Рис. 2.4. Операционное пространство разработки семейства SIS
На схеме обобщенно показан «треугольник деятельности», для
«вершин» которого учтено особое место опыта и его моделей в среде
WIQA, настроенной на способ работы WQA, в основу которого положено
формирование и применение отображения RQA операционного
пространства S на QA-память, включающего модели применяемого
опыта EQA(tj) и развивающего его аддитивно:
WQA(S, P, {SIS i}, K, EN, EQA(tj), tj+1) EQA(tj+1) = EQA(tj)∪∆EQA(tj+1). (2-1)
100
Отметим, что в символической записи отображения
RQA используются обозначения составляющих рисунка 2.3.
Отображение RQA реализовано в двух версиях, первая из которых
ориентирована на представление моделей опыта только с помощью
QA-протоколов, а вторая– на построение и использование Базы Опыта,
ориентированной на представление типовых активностей в форме
прецедентов. Вторая версия, в которой названы типовые активности
и введены их символические обозначения, приведена на рисунке 2.5.
Рис. 2.5. Детализация операционной обстановки
Для реализации второй версии способ WQA дополнен способом
WPr, обеспечивающим построение прецедентно-ориентированной Базы
Опыта EPr, в котором используются следующие отображения:
WQA(S, P, {SIS i}, K, EN, EQA(tj), EPr(tj), tj+1) EQA(tk+1) = EQA(tj)∪∆EQA(tj+1),
WPr(S, P, {SIS i}, K, EN, EQA(tk), EPr(tk), tk+1) EPr(tk+1) = EPr(tk)∪∆EPr(tk+1).
Линейность отображений RQA и RPr согласована с естественными
формами накопления опыта в коллективной разработке SIS, что
(2-2)
101
существенно облегчает моделирование естественного, персонального
и коллективного опыта EN и его интеграцию c моделями типов EQA и EPr.
Для отображений RQA и RPr, ввиду того что в их осуществлении
участвуют проектировщики, важное значение приобретают вопросы их
корректности. Конструктивные ответы на эти вопросы находят свое
выражение в средствах обеспечения корректности составляющих,
входящих в EN, EQA и EPr. В число этих средств включены:
− средства, обеспечивающие многократное повторное
использование составляющих опыта и его моделей в команде
проектировщиков;
− средства, обслуживающие экспериментирование с такими
составляющими;
− средства коммуникативного обеспечения корректности.
В авторских решениях считается, что опыт проектной организации
EPO объединяет ED, EQAи EPr с помощью средств коммуникативного
взаимодействия, предоставляемых членам коллектива К.
Формирование Базы Опыта происходит на основе того, что за любой
приобретенной в деятельности единицей опыта EPri, размещаемой в Базе
Опыта, стоит решенная задача Zi, подготовленная к повторным
использованиям в виде модели соответствующего прецедента Pri,
например, в проектировании очередной SIS (отражено на схеме
стрелками внутреннего контура). Отметим, что в процессе
первоначального или повторного решения любой задачи
Zi взаимодействие с доступным опытом EPO осуществляется
с использованием вопросно-ответных рассуждений (QA-рассуждений),
модели которых включаются в модель прецедента Pri.
К числу задач, представляемых в Базе Опыта моделями прецедентов,
относятся и задачи освоения активов, заимствованных проектной
102
организацией из полезных источников, например задачи освоения
стандартов в формах их изучения и практического применения.
Детали интерпретации и спецификации опыта и его моделей
раскрыты с помощью вопросно-ответного анализа обобщенного задания
на проект Базы Опыта:
1. Проект должен быть нацелен на повышение степени успешности
проектной организации, разрабатывающей семейства АС (как подкласса
SIS), за счет совершенствования производственных процессов,
обусловленного конструктивным вопросно-ответным взаимодействием
проектировщиков АС с прецедентно-ориентированной Базой Опыта,
в основу теоретических обоснований которой положены аналогии между
прецедентами и условными рефлексами человека.
2. Конструктивное вопросно-ответное взаимодействие с Базой
Опыта должно осуществляться с помощью моделей QA-рассуждений,
использовавшихся в создании, развитии и применении составляющих
Базы Опыта, для построения которых используется нормативная модель
прецедента.
3. Проект должен быть реализован в инструментально-
моделирующей среде WIQA, основным предназначением которой
является вопросно-ответное моделирование (QA-моделирование)
и вопросно-ответное программирование (QA-программирование) задач
в процессах концептуального проектирования АС.
С помощью детального анализа выявлены основные требования
к теоретизации и материализации прецедентно-ориентированного
подхода.
2.2.2. Формализация QA-памяти
Так как основным предназначением QA-памяти является ее
использование в отображении операционной среды проектирования АС,
103
которая эволюционно развивается, причем с использованием
возможности псевдокодового программирования, то для формального
представления QA-памяти в монографии выберем порождающую
грамматику (обозначим ее как GQA), а ее конструкты будем записывать
с помощью средств расширенной БНФ-нотации (Бекус-Науровых
Форм). Более того, грамматику GQA будем применять не только для
описания QA-памяти, но и для описания отображений на эту память
составляющих операционной среды проектирования семейства АС.
Грамматику GQA как целое определим традиционно:
GQA= (ST, SNT, PG, W),
где ST – множество терминальных символов, SNT – множество
нетерминальных символов, PG – правила грамматики, W – цель
грамматики (порождение отображения операционного пространства на
QA-память).
Особое место в этой грамматике занимают порождающие правила
PG, основу которых определяют правила порождения QA-памяти. Как
отмечалось выше, ячейки QA-памяти создаются и включаются в нее
проектировщиками сразу, как только у них возникает в этом
необходимость. Структура ячейки, общий вид которой приведен на
рисунке 2.6, определяется ее содержимым. Для определенности будем
считать, что ячейка на данном рисунке используется для представления
интерактивного объекта Q- или А-типа.
Отметим, что прикрепленные рисунки (любое их количество)
присоединяются к ячейке как класс файлов, в то время как ссылки
выводят на различные информационные источники в Интернете.
(2-3)
104
Рис. 2.6. Структура содержимого ячейки QA-памяти
На примере простого QA-объекта, структура которого приведена на
рисунке 2.7, показано, что возможность семантических расширений
удваивается, так как присоединить расширения можно как к «вопросу»,
так и к «ответу».
Рис. 2.7. Отношения между ячейками памяти
105
Рисунок 2.7 демонстрирует не только структуру QA-объекта, но и его
операционный потенциал, составляющие которого в среде WIQA
реализованы как команды управления содержимым ячеек QA-памяти.
Напомним, что составные QA-объекты создаются из простых, но
любой составной объект имеет иерархическую структуру, с корнем
которой проектировщик должен связывать особенность составного
объекта. Именно к корневому QA-объекту следует прикреплять
семантические расширения, специфицирующие эту особенность.
Выше не раз отмечалось и то, что только пара согласованных
«вопроса» и «ответа» образует взаимодополнительную целостность.
По этой причине QA-память среды WIQA структурируется в единицах
хранения QA-объектов, что приводит к следующему набору правил
грамматики, специфицирующих структуру такой памяти:
QA-память {QA-объект}, Команды;
QA-объект Вопрос, “←”, Ответ;
Вопрос Q│(Q,“↓”,{Q});
Ответ A│(A, “↓”, {A});
Q (BA, [AA], [FILES]);
A (BA, [AA], [FILES]);
BA (адрес, тип, описание, владелец, ..., статус);
AA {aa};
FILES {f};
Команды базовые, плагинные, программные,
где «↓» – операция подчинения, а «←» – операция «ответить на вопрос»,
а остальные составляющие набора правил были определены выше.
Отметим, что в наборе правил отражено (декларативное) содержание
конструктов QA-памяти, а все операции над ними, встроенные
=
=
=
=
=
=
=
=
=
=
(2-4)
106
в инструментарий WIQA, объединены нетерминальным символом
«Команды».
Совокупности команд содержат следующие подмножества:
1. Базовые команды, включающие действия, интерфейсно
доступные проектировщикам для порождения Q-, A- и QA-объектов, их
загрузки в память, а также их связывания и систематизации,
визуализации и модификации. В частности, к этому подмножеству
команд относятся операции «↓» и «←». Для обозначения базовых
команд в грамматике используются специальные символы,
а в инструментальной среде их интерфейсные имена и «горячие
клавиши». Базовые команды доступны в рамках ядра инструментария
WIQA, получившего название «вопросно-ответный протокол».
2. Подмножество плагинных команд включают действия над
объектами QA-памяти, предусмотренные в системных расширениях
инструментария WIQA, реализованных с помощью нормативного
механизма плагинов. К этому подмножеству относятся, например,
команды плагинов «Оргструктура» и «Документирование», а также
«Дополнительная атрибутика».
3. Подмножество программных команд составляют операторы
псевдокодового языка программирования LWIQA, основным
предназначением которого является расширение потенциала
инструментария WIQA, в том числе за счет разработки
программируемых приложений на его основе.
Отметим, что в дальнейшем, в том числе и в правилах грамматики,
основное назначение команд будет связываться с порождением
вопросно-ответных моделей (QA-моделей) для составляющих
операционного пространства проектирования, отображаемых
на QA-память.
107
Любая QA-модель, как конструкт, образующийся в результате
отображения определенной составляющей операционной среды,
создается из простых QA-объектов, каждый из которых является
вопросом, или ответом, или их согласованной парой. Принципиальным
и для объектов, и для моделей, существующих в QA-памяти (рисунок
2.8), является то, что и они, и отношения между ними «нагружены»
необходимой для проектировщиков семантикой. Более того, для
проектировщиков доступна конструктивная работа с семантикой,
причем часть такой работы может быть перенесена на компьютерную
обработку.
Рис. 2.8. Содержимое QA-памяти
Другими словами, любые QA-объекты и QA-модели, а также любые
их составляющие, включая и те, которые выражают семантику, являются
программно-доступными по запланированным или ситуативным
запросам в реальном времени.
108
2.3. Язык и среда псевдокодового программирования
2.3.1. Особенности языка программирования LWIQA
Как уже отмечалось, отображение составляющих операционной
среды проектирования на семантическую QA-память открывает
возможность для программирования задач проектирования,
ориентированного на особенности такой памяти.
Для того чтобы запрограммировать решение любой проектной
задачи, следует предварительно построить модель ее решения в таком
виде, чтобы она была понятной и отражала его алгоритмическую
реализуемость. Предварительное решение определенной задачи Zi
должно быть понятным не только тому проектировщику, на которого
возложена ответственность за ее решение, но и тем лицам, которых
задача Zi затрагивает прямо или опосредованно (коллеги по группе,
будущие пользователи задачи или разрабатываемой системы, другие
стейкхолдеры).
На основании вышеизложенного предварительное решение задач
с названными свойствами (назовем такое решение концептуально-
алгоритмическим) целесообразно программировать, применяя язык
псевдокодового типа, спецификации данных и операторов которого
ориентированы на QA-память. Именно поэтому в состав средств среды
WIQA введен псевдокодовый язык LWIQA.
Привязка языка LWIQA к семантической памяти вопросно-ответного
типа не является единственной его особенностью и отличием от
известных языков псевдокодового типа. К особо важным особенностям,
которые были включены в требования к этому языку и версии его
применения, относятся следующие:
1. Псевдокодовые программы понятийно-концептуальных решений
задач {Zi} должны быть не только понятны заинтересованным лицам,
109
но и исполняться ими в среде WIQA с помощью средств,
обеспечивающих применение ее процессорной интерпретации. В число
таких средств входят те, которые поддерживают исполнение человеком
роли I-процессора (п. 2.2), то есть конструкты языка LWIQA
специфицированы и материализованы исходя из исполнения
псевдокодовых программ I-процессорами, взаимодействующими
с K-процессорами. Это означает, что быстродействие в исполнении
операторов языка должно быть согласовано с психофизиологическими
моторными характеристиками человека.
2. Важной особенностью роли I-процессора является его
взаимодействие с доступным опытом, в состав которого входит
естественный опыт лица, исполняющего роль, и модели опыта,
хранящиеся в базе опыта среды WIQA. При исполнении псевдокодовых
программ взаимодействие с опытом может потребоваться до исполнения
оператора программы и / или после его исполнения, что и привело
к решению о включении в состав инструментальной среды
псевдокодового программирования интерпретатора с пошаговой
обработкой операторов в условиях, когда обработка может быть
прервана для обращения к доступному опыту.
3. Решая задачи с использованием доступного опыта,
проектировщики развивают его, приобретая личный опыт и расширяя
тем самым коллективный опыт. Создание новых единиц опыта,
полезных в деятельности, сопровождается освоением новых
прецедентов, которое принято трактовать как обучение, основанное на
опыте (experiential learning). В представления освоенных новых
прецедентов как результатов обучения полезно включать понятийно-
концептуальные решения задач соответствующих прецедентов. В среде
WIQA такие решения оформляются в виде псевдокодовых программ на
110
языке LWIQA, ориентированном на моделирование прецедентов
в QA-памяти.
4. Ориентация языка LWIQA на моделирование единиц опыта
предполагает, что при исполнении операторов прерывания работы до
и после операторов полезно использовать с позиций
экспериментирования, нацеленного на формирование единиц опыта как
моделей экспериментов, способствующих их повторному
использованию. Такая ориентация в требованиях к языку LWIQA
указывает на то, что его применение должно способствовать
концептуальному экспериментированию.
5. Инструментально-моделирующая среда WIQA инвариантна по
отношению к предметным областям АС, для проектирования которых
она используется. Так как операторы языка LWIQA должны отражать не
только соответствующие им действия, но и семантику предметной
области, то язык LWIQA определен и материализуется в его применениях
как язык открытого типа. Другими словами, язык допускает
включение в его состав не только традиционных, но и дополнительных
предметно-ориентированных типов данных и операторов. Более того,
он допускает встраивание в его состав, а вернее, в библиотеки, кодов,
построенных на других языках программирования.
6. Общий случай решения проектной задачи предполагает
включение в процесс решения действий проектировщика. В режиме
пошаговой интерпретации псевдокодовой программы, кодирующей
решение, исполнение каждого оператора инициируется человеком
(в первую очередь, создателем программы, проводящим эксперимент с
решением). Если в процессе экспериментов выявляется, что исполнение
определенной группы операторов доведено до «навыка», то есть
в прерываниях между операторами группы нет необходимости, то для
111
исполнения группы предусмотрен режим интерпретации
с автоматическим исполнением выделенных групп операторов.
7. Для автоматического исполнения всех операторов псевдокодовых
программ на языке LWIQA в состав средств интегрированной среды
программирования на этом языке включен компилятор таких программ,
в частности, псевдокодовых процедур.
8. Так как данные и операторы языка LWIQA погружаются
в QA-память, но имеют специфику их использования по сравнению
с другими конструктами, представляемыми в памяти, то для
формирования и работы с исходными кодами псевдокодовых программ
в состав среды программирования включен специализированный
редактор. Исходные коды из этого редактора могут быть загружены
в дерево задач проекта, и наоборот, модели задач из дерева проекта
могут быть загружены в редактор исходных кодов.
2.3.2. Детализация особенностей языка LWIQA
Детализацию особенностей языка LWIQA начнем с интерпретации
содержимого ячеек QA-памяти как данных с управляемой семантикой.
В предыдущем параграфе представлено отображение операционного
пространства проектирования АС на QA-память, в котором уже
использовалось понятие «QA-данные» с позиций процессорной
интерпретации инструментария WIQA. Но это понятие использовалось
только с позиций возможностей представления данных с помощью
структур для кодирования «вопросов» и «ответов». Понятие затрагивало
только интерпретацию «символьного кода» интерактивных объектов
«вопрос» и «ответ» как данных, в то время как ячейка, которая
используется в простейшей версии такого объекта, содержит и другие
базовые атрибуты.
112
Для любого вопроса и любого ответа, связанных в пару, в вопросно-
ответной базе используется следующая базовая атрибутика:
− индексное имя (устанавливается автоматически при создании);
− тип единицы (первый выделенный в визуализации индексного
имени символ, который устанавливается создателем единицы);
− идентификатор основной задачи (проекта, к которому относится
QA-единица);
− идентификатор родительской QA-единицы;
− содержательное представление (текстовая строка, раскрывающая
информационное содержание единицы);
− «владелец» (имя субъекта, который создал единицу и / или несет
за нее ответственность);
− время последней модификации поля содержания (предыдущие
состояния могут сохраняться);
− состояние завершенности (с набором типовых значений);
− черновик (текстовая строка, регистрирующая полезную
информацию о единице, в частности ретроспективу ее создания, которая
регистрируется проектировщиком, ответственным за единицу).
Для QA-пары, которая состоит из вопроса Q и ответа А на него,
ничто не мешает связать с вопросом «название» определенного данного,
использовав для этого символьную строку описания вопроса,
а с ответом – «значение» названного данного. Такую версию
представления данных с помощью простейшей QA-пары можно
использовать для кодирования скалярных данных любых типов.
Более сложные типы данных можно представлять из иерархически
связанной совокупности QA-пар, общая схема которых приведена
на рисунке 2.9.
113
На рисунке специально введена ось времени t, показывающая, что
вопросно-ответные структуры предоставляют возможность вложения
в них не только статических, но и динамических данных любых типов.
Рис. 2.9. Общий случай вопросно-ответных данных
Анализ различных применений QA-модели данных, а также их
различных применений в развитии комплекса WIQA и в построениях
приложений на его базе показал, что QA-данные (из-за их богатой
атрибутики и операций над ней), если отвлечься от их интерпретации
в форме «задач», «вопросов» и «ответов», обладают следующими
потенциальными возможностями:
− унификация с использованием автоматически порождаемых
индексных имен объектов (QA-единиц);
− содержательное определение или толкование QA-единиц
(с возможностью преобразования используемых текстов на язык логики
предикатов);
− автоматическая регистрация изменений QA-единиц во
времени с сохранением измененных версий и констатацией момента
времени;
− персонификация каждого объекта с указанием ответственного
лица и группы «поддержки»;
− визуализация QA-единиц на экране монитора;
B
t
Q1
A1
Qn
An
QN
AN
Q2
A2
114
− возможность объявления подтипов QA-единиц;
− возможность использования наследования;
− возможность оперативного дополнения атрибутики (с помощью
механизмов дополнительной атрибутики);
− наличие «черновика» в определениях и толкованиях для
присоединения полезной текстовой информации;
− образование иерархической совокупности групп QA-единиц,
в том числе и таких, которым может быть приписан статус
«целостности»;
− серверная форма размещения базы данных с клиентским
доступом в корпоративной сети с возможностью санкционирования
доступа из Интернета;
− другие полезные возможности.
Ко всем названным возможностям можно (и целесообразно)
относиться с позиций программирования, что и привело к разработке
языка LWIQA, встроенного в инструментарий WIQA. Более того,
псевдокодовое программирование на языке LWIQA открыло
принципиальное направление совершенствования инструментально-
технологической среды WIQA, согласно которому создан ряд ее
расширений, в том числе и описанные ниже средства программно-
картотечного управления (ПКУ) потоками работ в проектировании АС.
Направление принципиально тем, что оно вводит
в программирование возможность работы с семантикой данных.
Поэтому оно открывает возможность параллельно с данными
программно обрабатывать и их семантические атрибуты.
Для расширения возможностей работы с семантикой данных, кроме
базовых атрибутов, раскрывающих базовую семантику QA-данных,
в состав средств инструментария WIQA введены средства, позволяющие
приписывать ячейкам QA-памяти, а значит, и данным, которые в них
115
хранятся, дополнительные атрибуты, если в этом появляется
необходимость.
Важнейшим направлением расширения системы WIQA является
разработка новых приложений на основе ее потенциала. По этой
причине в создании средств дополнительной атрибутики учтены два
основных направления ее применения: применение, инвариантное к
содержанию приложений (инвариантные атрибуты), и применение,
учитывающее содержательную специфику приложений
(специализированные атрибуты).
В приведенном содержательном определении дополнительного
атрибута не называются алгоритмические языки, для которых могут
создаваться дополнительные атрибуты. Для системы WIQA.Net таким
языком может быть любой язык платформы .Net или язык
QA-программирования.
Приписывания дополнительных атрибутов в версиях WIQA.Net
и OwnWIQA имеют различия, но в общем плане за реализацией
возможностей дополнительной атрибутики в этих системах стоит
расширение SQL-базы версий, над которыми работает механизм
введения в QA-базу виртуальных отношений. Схема такого расширения
для WIQA.Net приведена на рисунке 2.10.
За созданием каждого дополнительного атрибута независимо от того, является он инвариантным или специализированным, стоит объектно-реляционное преобразование, приводящее к образованию программного объекта для его использования в программе или псевдокодовой программе.
116
Рис. 2.10. Приписывание дополнительных атрибутов
Набор отношений R(АА) выбран и материализован из расчета на
объявление оказавшегося необходимым дополнительного атрибута ААi,
возможно, включающего в себя подчиненные атрибуты ААij, с учетом
типа и необходимых свойств, причем, принадлежащих не только
к виртуальному отношению Rk. Созданный атрибут ААi связывается
с определенным узлом дерева задач или вопросно-ответного протокола
или узлами тех конструктов, которые QA-данные представляют.
Приписывание дополнительных атрибутов возможно как для ячеек
QA-памяти, а вернее, для объектов, загруженных в эти ячейки, так и для
данных в программах на языке LWIQA.
2.3.3. Спецификация языка LWIQA
Перейдем к спецификации языка, для этого будем использовать
расширенную БНФ-грамматику.
Псевдокодовая программа LWIQAp оформляется в виде блока
инструкций, расположенных в ячейках QA-памяти: LWIQAp = блок.
Базовые QA-атрибуты
Виртуальное отношение Rk
сервер
клиент
Механизмы доступа АА
Отношения R(АА)
Отношение QAReg
Набор классов
АА
Механизмы QA-доступа
пользователь и / или новая функциональность
117
Блок программы состоит из последовательности инструкций, каждая
из которых может быть декларативной Idec или операторной Iop. Каждая
инструкция блока записывается в отдельной ячейке вопросного типа: блок = {Idec | Iop}.
Декларативные инструкции включают в себя объявления
переменных, меток, а также объявления процедур. Операторные
инструкции включают в себя набор операторов языка.
Таким образом, Idec = (метка|переменная|процедура).
Метка служит для обозначения определенного места в программе,
с которого нужно продолжать выполнение программы в случае
требования того алгоритмом. Метка = (LABEL, Имя_Метки);
Имя_Метки = "&", символьное_имя, "&";
символьное_имя = Буква|{Буква|Цифра|"_"}.
Переменная является именованным хранилищем данных
определенного типа. Таким образом, переменная характеризуется ее
именем, типом и значением. Имя переменной содержится в тексте
Q-единицы инструкции, содержащей объявление переменной Ivar. Для
хранения типа используется дополнительная атрибутика, а для хранения
значения – ответная единица, подчиненная этому вопросу. Ivar = (Имя_Переменной, Тип_Переменной), "←",
Значение;
Имя_Переменной = "&", символьное_имя, "&".
Типы данных в языке LWIQA подразделяются на простые
и структурированные. Простые типы данных включают в себя
скалярные типы и строки. К структурированным относятся одно-, двух-
и трехмерные массивы, а также записи.
Для данных простых типов кодирование начинается с их имени.
Такая часть объявляемого данного кодируется в атрибуте «символьная
118
строка» QA-пары. Выбранная версия объявления имени опирается на
теги, которые указывают трансляторам о начале и о конце имени.
Значение, например, устанавливаемое по умолчанию, кодируется во
втором объекте QA-пары. Так что в процессе исполнения программы на
языке LWIQA значения объявленной переменной извлекаются
и записываются в атрибут «символьная строка» ответа, например:
число, строка, булевское значение. Для числовых данных разрешено
использовать цифры от 0 до 9, а также единственный разделитель «,»
целой и дробной части в случае работы с вещественными числами.
Для более строгой спецификации представим объявление скаляров
в расширенной БНФ-грамматике: Цифра = "0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9";
НатуральноеЧисло = Цифра, {Цифра};
ЦелоеЧисло = ["+"|"-"], НатуральноеЧисло;
Число = ["+" |"-"], НатуральноеЧисло, [",",
[НатуральноеЧисло]];
Булевское_значение = "TRUE"|"FALSE".
Для типа «строка» значение хранится в ответе QA-пары в виде
заключенной в кавычки последовательности любых символов. Сам
символ «кавычки» хранится в строке в виде последовательности символов
«\"». Символ «\» хранится в строке в виде последовательности «\\».
Типизация переменных осуществляется с использованием
дополнительной атрибутики узлов QA-дерева. Для хранения типа
переменной используется дополнительный атрибут вопросной части
QA-пары, в котором хранится объявление имени переменной. Этот
дополнительный атрибут имеет системное имя «VarType», значением
которого является строка, содержащая название типа переменной. Этими
типами могут быть:
− ЦелоеЧисло;
119
− ДробноеЧисло;
− Логический;
− Строка;
− ДатаВремя;
− ОдномерныйМассив;
− ДвухмерныйМассив;
− ТрехмерныйМассив;
− Запись.
Одномерный массив в языке LWIQA представляет собой ветвь
QA-дерева (рис. 2.10), корнем которой является вопрос, содержащий имя
массива, записываемое как имя переменной.
Его дочерние узлы представляют собой элементы массива,
являющиеся переменными простых типов, имена которых состоят
из имени переменной массива и индекса элемента, заключенного
в квадратные скобки. Индексы элементов массива начинаются с нуля,
и каждый следующий индекс больше предыдущего на единицу.
Рис. 2.10. Пример одномерного массива в QA-памяти WIQA
120
Расширенная БНФ-грамматика имени элемента массива: Имя_элемента_массива = "&", Символьное_имя,
"[", ЦелоеЧисло, "]", "&".
Значением строкового дополнительного атрибута с системным
именем «VarType» для одномерного массива является
«ОдномерныйМассив», для двух- и трехмерного соответственно
«ДвухмерныйМассив» и «ТрехмерныйМассив».
Для хранения двухмерных массивов используется подобная
структура, но вместо объявлений элементов массива как переменных
простых типов стоят объявления одномерных массивов. Также
и с трехмерными. Ветками, выходящими из узла, содержащего
объявление трехмерного массива (рисунок 2.11), являются объявления
двухмерных массивов.
Рис. 2.11. Пример хранения трехмерного массива
Записи в языке LWIQA объявляются сходным с одномерными
массивами образом. Вместо элементов массива дочерними элементами
узла-вопроса, объявляющего переменную-запись, являются узлы,
121
задающие поля вида &имя_записи.имя_поля&, которые объявляются
аналогично переменным любого типа. Значением дополнительного
атрибута с системным именем «VarType» для узла-записи
устанавливается строка «Запись».
Процедуры в языке LWIQA записываются следующим образом:
в Q-единице QA-памяти указывается имя процедуры с использованием
ключевого слова PROCEDURE, в последующих единицах – блок
инструкций процедуры, и завершается она Q-единицей с ключевым
словом ENDPROC и именем процедуры: Процедура = "PROCEDURE", имя_процедуры, блок,
"ENDPROC".
Для операторов ядра сохранились традиционные ключевые слова их
названий, такие как BEGIN, END, IF, THEN, ELSE, LABEL, GOTO,
INPUT, OUTPUT, CALL.
Операторная инструкция Iop содержит в себе описание оператора Op.
К базовым операторам языка относятся: оператор присваивания,
оператор вызова процедуры CALL, оператор вызова функции, условный
оператор IF, оператор безусловного перехода GOTO, оператор ввода
INPUT и оператор вывода OUTPUT.
Код их регистрируется в атрибуте «символьная строка» вопросной
составляющей QA-пары, в то время как второй объект кодирует или
результат, или завершение выполнения.
Не приводя всех версий грамматики операторов, раскроем операторы
присваивания, GOTO и IF.
Оператор присваивания осуществляет запись нового значения для
переменной по ее имени. Этот оператор в расширенной
БНФ-грамматике представлен следующим образом: Оператор_присваивания = Имя_Переменной, ":=",
Выражение.
122
В процессе его выполнения сначала происходит вычисление
выражения, а затем его значение устанавливается как значение
переменной, имя которой указано в операторе присваивания.
Оператор GOTO предназначен для безусловного перехода по метке,
установленной с помощью оператора LABEL в другом месте кода
программы.
Формат оператора – GOTO&имя_метки&. В расширенной БНФ-
грамматике он представлен следующим образом: Безусловный_переход = GOTO, Имя_Метки.
Оператор IF представляет собой оператор ветвления, который может
иметь полную или сокращенную форму. В сокращенной форме он
указывает на действия, осуществляемые при выполнении условия,
в полной же форме – на действия, производимые как в случае
истинности условия, так и в случае его ложности.
Расширенная БНФ-грамматика сокращенной и полной форм
условного оператора: Условный_оператор = "IF", Логическое_выражение,
"THEN", Подблок, ["ELSE", [Подблок]].
В данном случае Подблок представляет собой или отдельный
оператор, или блок операторов, заключенный между Q-единицами,
содержащими ключевые слова BEGIN и END. В этом случае стоящие
после END элементы условного оператора должны располагаться
в следующей Q-единице. Подблок = Op | ("BEGIN", блок, "END").
Циклы не рассматриваются, так как в их эмуляции используются
GOTO и условный оператор.
Язык LWIQA является расширяемым, и разработанная версия
не ограничена базовыми типами данных и операторами.
123
Расширить язык можно путем добавления в него дополнительных
операторов и пользовательских функций. Функции и операторы
добавляются путем программирования дополнительных подключаемых
библиотек. Формат дополнительного оператора Opa: Opa = имя_оператора, "(", [Параметр,
{",", Параметр}], ")";
имя_оператора = символьная_строка.
Примеры пользовательских операторов представлены в п. 2.3.4.
2.3.4. Расширения языка LWIQA
Язык изначально определялся как открытый, к базовому ядру
которого, специфицирующему традиционные данные и операторы,
добавлялись и добавляются расширения. В своем текущем состоянии
структура языка LWIQA с расширениями, применяемыми в авторской
версии проектного управления, приведена на рисунке 2.12.
Рис. 2.12. Язык LWIQA с расширениями
Одним из расширений является расширение для работы
с реляционными базами данных. Это расширение добавляет в язык LWIQA
табличные типы данных, а также элементы языка SQL для манипуляции
этими данными.
124
База данных в вопросно-ответном протоколе представляется в виде
дерева, где узел базы данных – вопрос, имеющий ветки,
соответствующие таблицам, которые, в свою очередь, содержат
дочерние узлы-ответы со значениями. Для управления типами данных,
целостностью базы данных используется дополнительная атрибутика.
Контроль целостности осуществляется интерпретатором псевдокода.
В качестве примера рассмотрим псевдокодовые реализации таблиц
«Субъект» и «Рабочая группа».
Таблица «Субъект» содержит 4 колонки:
− ID – уникальный идентификатор субъекта;
− ID группы – идентификатор группы, к которой принадлежит
данный субъект;
− ФИО;
− контакты.
Таблица «Рабочая группа» также содержит 4 колонки:
− ID – уникальный идентификатор группы;
− номер группы;
− номер поручения;
− название группы.
В таблице «Субъект» есть колонка «ID группы», являющаяся
ForeignKey и указывающая на таблицу «Рабочая группа». PrimaryKey
и ForeignKey задаются как дополнительные атрибуты единиц.
Вопросно-ответное представление «шапок» таблиц приведено
на рисунке 2.13.
125
Рис. 2.13. Пример табличных структур
Для обозначения PrimaryKey узлу дерева, соответствующему
заголовку колонки данных, назначается дополнительный атрибут,
имеющий системное имя «PrimaryKey». При определении ForeignKey
назначается дополнительный атрибут «ForeignKey», строковым
значением которого является ссылка на столбец другой таблицы базы
данных, представленная в виде <Имя таблицы> / <Имя столбца>.
Строки данных в таблицах хранятся в ответных единицах,
являющихся дочерними по отношению к вопросным, в которых
хранятся заголовки столбцов. Количество дочерних элементов в каждом
столбце должно быть одинаковым.
Для работы с базами данных язык был дополнен рядом функций по
формированию структуры базы данных, ее модификации, а также по
работе с данными. Описание этих функций представлено в таблице 2.1.
126
Таблица 2.1
Функция Выходное значение Параметры Описание
CreateDB Id базы данных
Id проекта, Id родительского узла
Функция создает вопросно-ответную структуру, соответствующую базе данных, и возвращает идентификатор базы данных для последующей работы
OpenDB Id базы данных
Id проекта, Id родительского узла
Функция возвращает идентификатор базы данных по ее положению в вопросно-ответном протоколе для последующей работы
CloseDB - Id базы данных
Функция завершает работу с базой данных и освобождает идентификатор
ExecuteSQL Строка Текст запроса
Функция выполняет команду языка SQL и возвращает результат, упакованный в строку. Если возвращается набор значений, можно воспользоваться функциями, распаковывающими его в псевдокодовый массив
Также были реализованы вспомогательные функции распаковки из
строки результатов запросов в псевдокодовые массивы (табл. 2.2).
Таблица 2.2
Функция Выходное значение Параметры Описание
UnpackColumn Одномер-ный массив
Упакованный в строку ряд значений
Функция распаковывает в одномерный массив упакованный в строку ряд значений. Такой ряд значений может быть получен на выходе функции ExecuteSQL с запросом SELECT
127
UnpackTable Двухмер-ный массив
Упакованная в строку таблица значений
Функция распаковывает в одномерный массив упакованный в строку ряд значений. Такой ряд значений может быть получен на выходе функции ExecuteSQL с запросом SELECT
После распаковки упакованных в строку данных возможно их
дальнейшее использование в псевдокодовой программе в качестве
значений элементов массива.
Для работы с данными, содержащимися в псевдокодовой базе
данных, используется язык SQL, команды которого выполняются
с помощью функции ExecuteSQL.
Для создания таблицы в базе данных используется оператор
CREATE TABLE <Имя_Таблицы> (<Имя_Колонки><Тип>, …). Этот
оператор вызывается мастером создания таблиц. Его интаксис
в расширенной БНФ-грамматике имеет следующий вид: CREATE_TABLE = "CREATETABLE", символьное_имя,
"(", описание_колонки, {",",
описание_колонки>, ")",
описание_колонки = символьное_имя,
(ЦЕЛОЕЧИСЛО | ДРОБНОЕЧИСЛО |
СТРОКА | ДАТАВРЕМЯ |
ЛОГИЧЕСКИЙ).
Для удаления таблицы используется оператор DROP TABLE
<Имя_Таблицы>.
Для добавления записи в таблицу используется оператор INSERT
INTO <Имя_Таблицы> (<Имя_Колонки1>, <Имя_Колонки2>,…)
VALUES (<Значение1>, <Значение2>,…).
В операторе требуется указать все колонки и значения для них,
кроме той, которая является первичным ключом. Если колонка
128
первичного ключа не указана, то значение устанавливается как
автоинкрементное (MAX + 1).
Выбор из таблиц
Для выбора из таблиц используется оператор SELECT
<tid>.<Колонка1>, <tid>.<Колонка>,… FROM <Имя_Таблицы1> AS
<tid1>, <Имя_Таблицы2> AS <tid2>,… WHERE <tid1>.<Колонка1>
=(<,>,<>) <Значение1>, <tid2>.<Колонка2> =(<,>,<>) <Значение2>,…
В том случае, когда запрос возвращает больше одного значения,
возврат осуществляется в виде упакованного в строку массива.
Изменение данных в таблице
Для изменения записи используется оператор UPDATE
<Имя_Таблицы> SET (<Имя_Колонки1> = <Значение1>,
<Имя_Колонки2> = <Значение2>) WHERE <Колонка1> = (<,>,<>)
<Значение1>, <Колонка2> =(<,>,<>) <Значение2>, …
Удаление данных из таблицы
Для удаления используется оператор DELETE FROM
<Имя_Таблицы> WHERE <Колонка1> = (<,>,<>) <Значение1>,
<Колонка2> = (<,>,<>) <Значение2>, …
Еще одним расширением языка LWIQA является расширение,
предназначенное для псевдокодового программирования графических
диаграмм. Это расширение содержит ряд пользовательских операторов,
предназначенных для рисования графических примитивов.
Для создания графического примитива используется оператор
DD_Create в следующем формате:
DD_Create({TemplateName}, “ShapeName” = {ShapeName},
[{PropertyName = PropertyValue}]),
где TemplateName – имя шаблона, на основе которого создается
графический примитив (форма), указывается строка в формате
«TemplateName», например «RoundedBox» или «TextBox».
129
В расширенной БНФ-грамматике этот оператор отображается
следующим образом: DD_Create = "DD_Create", "(",
TemplateName, ",", ShapeName,
{",", Property}, ")";
ShapeName = "\"", "ShapeName", "\"", "=",
"\"", строка, "\";
Property = "\"", строка, "\"", "=", "\"",
строка, "\".
Здесь последовательностью символов «\"» обозначен символ
двойной кавычки.
После указания имени шаблона прописываются свойства
создаваемого графического примитива, разделенные запятыми,
в формате «PropertyName» = «PropertyValue». Свойств может быть
неограниченное количество. Первым необходимо прописать свойство
«ShapeName» – наименование создаваемой фигуры. Значение данного
свойства записывается в качестве значения атрибута «ShapeName»
к вопросно-ответной единице, создаваемой автоматически при
выполнении инструкции DD_Create, соответствующей создаваемому
графическому примитиву. В связи с этим в средствах псевдокодового
программирования редактора диаграмм имеется ограничение: перед
выполнением псевдокодовой программы редактор диаграмм необходимо
связать с вопросно-ответным протоколом.
После указания имени создаваемой фигуры следует прописать
остальные свойства и их значения. Перечень свойств ограничен
стандартными свойствами графических примитивов редактора
диаграмм. Общие для всех примитивов свойства:
− X – положение фигуры по оси X;
130
− Y – положение фигуры по оси Y;
− Width – ширина фигуры;
− Height – высота фигуры;
− Angle – угол поворота фигуры;
− Text – текст, присутствующий на фигуре;
− CharacterStyle – стиль текста (используется редактируемый
средствами графического редактора список: необходимо указать
текстовое наименование элемента списка). Список доступных по
умолчанию значений свойств: Caption, Heading1, Heading2, Heading3,
Link, Normal, Subtitle;
− FillStyle – стиль заливки графического примитива: Black, Blue,
BlueSolid, GrayFileFillStyle, GrayFill, Green, GreenSolid, LightBlueSolid,
Red, RedSolid, Transparent, White, WindowStyle, Yellow;
− LineStyle – стиль линий графического примитива: Blue, Dashed,
Dotted, Green, HighLight, HighLightDashed, HighLightDotted,
HighLightThick, None, Normal, Red, Thick, ThickWhite, Yellow;
− ParagraphStyle – стиль расположения текста в параграфе: Label,
LinkStyle, Text, Title.
Значения свойств поддерживают указание в качестве значения
арифметического выражения с использованием переменных
псевдокодовой программы, например: «X = &xval& * 10»,
где &xval& – переменная псевдокода xval.
Наименование и значения свойств регистронезависимы – при
обработке данных они преобразуются в верхний регистр.
Изменение графического примитива осуществляется при помощи
оператора DD_Update, формат которого выглядит следующим образом:
DD_Update({ShapeName}, [{PropertyName=PropertyValue}]).
131
Первый параметр – «ShapeName» – имя фигуры, свойства которой
необходимо изменить, затем следует через запятую прописать свойства
для изменения.
В расширенной БНФ-грамматике этот оператор представлен
следующим образом: DD_Update = "DD_Update", "(", "\"",
строка, "\"", ",", Property,
{",", Property}, ")".
Связывание графических примитивов осуществляется
с использованием оператора DD_Link(“ShapeNameSrc”,
“ShapeNameDst”, “LinkTemplate”),
где ShapeNameSrc – наименование фигуры-источника;
ShapeNameDst – наименование фигуры-назначения;
LinkTemplate – имя шаблона, используемого для обозначения связи
(шаблон стрелки).
Расширенная БНФ-грамматика для этого оператора представлена
следующим образом: DD_Link = "DD_Link", "(", "\"", строка,
"\"", ",", "\"", строка, "\"",
",", "\"", строка, "\"", ")".
Связывание двух диаграмм осуществляется с использованием
оператора DD_LinkDiagram({ShapeName}, {QAIDDst}),
где ShapeName – наименование фигуры, при клике на которую должен
быть осуществлен переход на другую диаграмму;
QAIDDst – идентификатор вопросно-ответной единицы,
соответствующей диаграмме, на которую должен быть осуществлен
переход.
Расширенная БНФ-грамматика для этого оператора:
132
DD_LinkDiagram = "DD_LinkDiagram", "(",
"\"", строка, число, ")".
Также данное расширение позволяет рисовать произвольные
ломаные линии. Создание линии осуществляется пи помощи оператора
DD_CreateLine({TemplateName},“ShapeName={ShapeNameValue}”,
[{PointParamName=PointParamValue}]),
где TemplateName – имя шаблона, на основе которого создается линия
(Polyline, CircularArc, RectangularLine);
ShapeNameValue – уникальное имя создаваемой линии.
Массив координат создаваемой линии в случае с Polyline задается
в виде набора параметров, разделенных запятыми. Каждая координата
задается двумя параметрами с одинаковым цифровым признаком,
например, параметры “X5 = 100” и “Y5 = 200” задают пятую координату
[100,200]. В качестве параметров можно задать не более 100 точек
в одной команде.
Расширенная БНФ-грамматика отражает оператор создания линии
следующим образом: DD_CreateLine = "CreateLine", "(", "\"",
строка, "\"", ShapeName
{, PointParam}, ")";
PointParam = "\"", (X | Y), число, " =
", число, "\"".
Обновление координат ломаной линии осуществляется при помощи
оператора DD_UpdateLine([{ShapeCoord=Value}]),
где ShapeCoord – имя параметра, задающего имя линии и тип
координаты (X или Y), разделенные двоеточием;
Value – значение новой координаты.
В случае вызова DD_UpdateLine все координаты точек линии
удаляются и добавляются новые.
133
Расширенная БНФ-грамматика для этого оператора следующая: DD_UpdateLine = "DD_UpdateLine", "(",
ShapeCoord, {",",
ShapeCoord}, ")";
ShapeCoord = "\"", строка, (X|Y), число,
"=", число, "\"".
2.3.5. Интерпретатор псевдокодовых программ
Трансляция и исполнение программ на языках программирования
обычно осуществляются посредством или компилирования, или
интерпретации. И компилирование, и интерпретация имеют свои
недостатки и достоинства.
С целью достижения легкой расширяемости языка LWIQA было
принято решение отказаться от традиционной синтаксической версии
разбора. Разбор и выполнение каждого оператора языка осуществляются
по отдельности.
Интерпретатор может работать в двух режимах: в режиме
выполнения одиночного оператора и в режиме выполнения групп
операторов. Режим выполнения одиночных операторов является
наиболее естественным в двух случаях:
− при выполнении программы, содержащей инструкции для
I-процессора: в этом случае время выполнения человеком инструкции не
может быть измерено машиной, соответственно, интерпретатор не
может определить время перехода к исполнению следующего оператора;
− при отладке псевдокодовой программы: в этом случае бывает
необходимо отслеживать на каждом шаге изменение значений
переменных, а также, на какие ветки происходит переход в случае
выполнения условных операторов.
134
Работа интерпретатора в режиме исполнения групп операторов
применяется в том случае, если псевдокодовая программа может
работать без участия человека, или в случае интерактивного
взаимодействия с ним посредством диалоговых окон. Во время работы
человека с пользовательским интерфейсом диалогового окна
выполнение программы приостанавливается до тех пор, пока окно не
будет закрыто.
Если режим выполнения одиночных операторов не требует каких-
либо дополнительных атрибутов операторов языка, то при
автоматическом выполнении групп операторов возникает
необходимость обозначения границ этих групп, то есть должен быть
обозначен последний оператор группы, на котором автоматическое
выполнение должно прекращаться и интерпретатор должен переходить
в режим выполнения одиночных операторов. Для этого в реализации
интерпретатора существуют два механизма:
− точки прерывания;
− дополнительный атрибут с системным именем «NoAutoexec».
Механизм точек прерывания позволяет временно обозначать узлы,
на которых интерпретатор должен останавливать автовыполнение. Он
реализован посредством создания списка, в который заносятся
идентификаторы узлов с установленными точками прерывания. При
снятии точки прерывания с узла дерева программы его идентификатор
удаляется из списка. В процессе автовыполнения программы
интерпретатор проверяет текущий узел дерева программы на предмет
нахождения его идентификатора в списке точек остановки. При
обнаружении идентификатора происходит остановка автовыполнения
и переход интерпретатора в режим выполнения одиночных операторов.
При закрытии интерпретатора список точек прерывания очищается.
135
Такой механизм предполагает использование его для отладки
псевдокодовых алгоритмов.
Другим механизмом является включение дополнительного атрибута
«NoAutoexec» в узел QA-дерева программы и установка его строкового
значения в «TRUE». В этом случае такая точка остановки является
постоянной, она сохраняется даже после перезапуска псевдокодовой
программы. Этот механизм предполагает применение его в местах
запланированного пооператорного выполнения программы, например,
в случае реализации операторов, предназначенных для исполнения
человеком.
Кроме точек прерывания, автоматическое выполнение группы
операторов прекращается при обнаружении оператора FINISH или при
завершении псевдокодовой программы.
Интерпретация псевдокодовой программы выполняется в два этапа.
На первом этапе происходит преобразование псевдокода
в промежуточный паскалеподобный код, в процессе которого
происходят следующие действия:
− замена всех применяемых синонимов ключевых слов самими
ключевыми словами с использованием словаря синонимов;
− из текста оператора удаляются все комментарии и инструкции,
выполнять которые должен человек; при этом оператор может оказаться
пустым, в этом случае его выполнение не приводит к выполнению
каких-либо операций.
На втором этапе осуществляется разбор и выполнение оператора,
представленного в форме промежуточного паскалеподобного кода.
В процессе его выполнения происходит разделение строки кода на
последовательность слов и сравнение первого слова с ключевыми
словами операторов из набора ключевых слов. В случае обнаружения
136
совпадения происходит вызов функции, осуществляющей разбор
и выполнение оператора, определяемого этим словом.
Отдельным случаем является обнаружение в первом слове
идентификатора – имени переменной. В этом случае вызывается
функция разбора выражения с идентификатором. Возможно три
варианта:
− идентификатор представляет собой переменную простого типа,
следовательно, после ее имени должен находиться оператор
присваивания ":=" и должна выполняться операция присваивания;
− идентификатор представляет собой запись или объект, после
которого стоит оператор доступа к его полю: в этом случае после
идентификатора поля должен находиться оператор присваивания,
операция присваивания в этом случае применяется к полю;
− идентификатор представляет собой объект, после которого стоит
оператор вызова метода этого объекта, в этом случае необходимо
осуществить вызов метода.
В случае если первое слово не является идентификатором-именем
переменной и не является ключевым словом, определяющим какой-либо
базовый оператор языка, происходит поиск его в списке
пользовательских операторов, подключенных как дополнительная
подключаемая библиотека. При обнаружении пользовательского
оператора происходит вызов функции обработки пользовательских
операторов.
Каждая функция обработки того или иного оператора или выражения
возвращает код ошибки. В случае успешного выполнения оператора
функция возвращает ноль. При неуспешном выполнении пользователю
программы необходимо просигнализировать о наличии ошибки, за что
отвечает класс графического пользовательского интерфейса окна
интерпретатора.
137
Приведем пример разбора условного оператора: _ЕСЛИ выполняется выражение &a& + 1 ==
&b& то _ТОГДА _ПЕРЕХОД по метке &Метка1&.
Объявлены следующие синонимы ключевых слов:
Ключевое слово Синонимы IF _ЕСЛИ THEN _ТОГДА GOTO _ПЕРЕХОД
Установлены следующие значения переменных:
Имя переменной Тип Значение &a& Целое число 9 &b& Целое число 10
На первом этапе происходит преобразование в промежуточный код.
Сначала синонимы заменяются ключевыми словами. Итоговая
строка следующая: IF выполняется выражение &a& + 1 == &b& то
THENGOTO по метке &Метка1&.
Далее происходит очистка выражения от комментариев, не
являющихся идентификаторами, операторами, значениями или другими
ключевыми словами: IF &a& + 1 == &b& THEN GOTO &Метка1&.
Данное выражение уже представляет собой промежуточный код
и пригодно для передачи в интерпретатор промежуточного кода.
Интерпретатор промежуточного кода разбивает выражение на набор
слов:
Индекс 0 1 2 3 4 5 6 7 8 Слово IF &a& + 1 == &b& THEN GOTO &Метка1&
138
Далее происходит сравнение первого слова (с индексом 0)
с ключевыми словами языка. Когда обнаруживается, что оно является
ключевым словом «IF», происходит вызов функции разбора условного
оператора.
Функция разбора условного оператора начинает свое выполнение со
сборки условия. Условие собирается, начиная с индекса 1,
и продолжается до тех пор, пока не встретится слово «THEN». В данном
случае этим выражением становится "&a& + 1 == &b&".
Далее происходит замена идентификаторов переменных в этом
выражении их значениями по таблице. В результате получаем строку:
"9 + 1 == 10".
Эта строка передается в функцию вычисления логических
выражений, реализованную с использованием обратной польской
нотации. В результате вычисления данного выражения функция вернет
значение истинности.
В этом случае происходит сборка строки, выполняемая в случае
истинности условия. Эта строка собирается, начиная от следующего
после «THEN» слова, и заканчивается или словом «ELSE», или
окончанием набора слов условного оператора. В данном случае слово
«ELSE» отсутствует, поэтому условный оператор считается
сокращенным.
Выполняемая строка принимает значение "GOTO &Метка1&".
Для ее выполнения происходит создание нового экземпляра класса
интерпретатора промежуточного кода, в который переносятся все
атрибуты первоначального класса интерпретатора, включая таблицы
переменных, меток, стек вызова процедур и другие.
Новый экземпляр класса интерпретатора осуществляет разбиение
этой строки на слова:
139
Индекс 0 1 Слово GOTO &Метка1&
Потом также происходит поиск первого слова в списке ключевых
слов, соответствующих стандартным операторам языка. Обнаруживается
его соответствие слову «GOTO», для которого вызывается функция
разбора оператора GOTO. Данная функция отыскивает метку,
представленную словом с индексом 1, в таблице меток и осуществляет
перенос указателя выполняемого оператора на позицию,
соответствующую указанной метке. Далее она возвращает 0,
сигнализируя об успехе выполнения оператора. Управление
возвращается к функции разбора условного оператора, который также
возвращает 0. На этом выполнение условного оператора завершается.
Еще одной отличительной особенностью интерпретатора языка LWIQA
является то, что имеется возможность в любое время прервать
выполнение псевдокодовой программы и в нужный момент продолжить
ее выполнение. В процессе прерывания не происходит потери значений
переменных, так как сохранение значений переменных в вопросно-
ответной базе данных происходит при каждом их изменении. Для
прерывания кроме значений переменных необходимо также хранить
указатель на текущий выполняемый оператор. Для этого также
используется дополнительная атрибутика b.
Основной особенностью языка LWIQA является его расширяемость,
благодаря которой пользователи вопросно-ответной среды WIQA
получают возможность дополнить язык необходимой
функциональностью.
Рассматривая псевдокодовую программу как инструкцию, можно
выделить ее базовую единицу – оператор. Используя эти операторы,
можно запрограммировать любой алгоритм. Однако в некоторых
случаях использование операторов для программирования алгоритмов
140
может привести к тому, что фрагменты кода будут повторяться
и программа, как следствие, будет работать недостаточно оптимально.
Одним из способов расширения языка является представление группы
операторов в виде одного оператора. Одним из вариантов такого
расширения является программирование псевдокодовых процедур.
Вызов процедуры осуществляется путем использования оператора
CALL <идентификатор процедуры>: <вызов_процедуры> ::= CALL <идентификатор>.
В этом случае <идентификатор> представляет собой имя процедуры.
Сама же процедура должна быть запрограммирована в области
видимости оператора вызова.
Программирование процедуры осуществляется между оператором
объявления процедуры и оператором ее окончания. Когда интерпретатор
в процессе выполнения программы доходит до объявления процедуры,
он пропускает ее тело, так как вызов данной процедуры не был
произведен.
Оператор вызова процедуры работает следующим образом:
− по имени процедуры отыскивается позиция ее начала в вопросно-
ответном дереве программы;
− текущая позиция указателя выполняемого оператора помещается
в стек вызовов процедур;
− указатель выполняемого оператора помещается к началу тела
процедуры.
Оператор окончания процедуры извлекает из стека вызовов процедур
позицию указателя выполняемого оператора и перемещает
его на следующую после него позицию.
Другим способом расширения языка является программирование
операторов. Оператор программируется на любом .NET языке
программирования как дополнительная подключаемая библиотека
141
и представляет собой метод класса FuncLib в пространстве имен
ExtFunctions. Такая библиотека компилируется в .dll файл
и подключается к интерпретатору, что позволяет использовать
содержащиеся в ней операторы. Операторы могут иметь любое число
параметров или не иметь их вообще.
За счет программирования на языках .NET пользовательские
операторы позволяют существенно расширить возможности языка LWIQA,
в том числе включить интерфейсы взаимодействия с аппаратными
средствами. В пользовательский оператор также с использованием
компилятора может быть скомпилирована псевдокодовая процедура.
Кроме операторов, программирование дополнительных
подключаемых библиотек позволяет реализовать пользовательские
функции, возвращающие определенные значения, которые могут быть
присвоены переменным.
В этом случае идентификатор обозначает переменную, в которой
после вызова функции окажется результат ее выполнения. Символьное
имя в данном случае обозначает имя функции. Количество
ее параметров, также как и у пользовательского оператора, может быть
любым, в том числе и нулевым.
2.3.6. Компилятор псевдокодовых программ
Другим способом исполнения кода, написанного на языке LWIQA,
является компилирование процедур. С помощью компилирования
процедура преобразовывается в быстроисполняемый байт-код
платформы Microsoft.NET, что позволяет выполнять ее как один
оператор или вызов одной функции. Компилирование предполагает
использование его с целью преобразования в оператор или функцию
реализованного на языке LWIQA алгоритма, не требующего для своей
работы участия человека.
142
Для компилирования псевдокода происходит сначала
преобразование его в код на языке C#.
Перед компилированием пользователю необходимо указать, какие
именно процедуры требуется скомпилировать. Далее происходит
сканирование этих процедур с поиском всех используемых ими
переменных. Все переменные в языке LWIQA являются глобальными,
и область их видимости не ограничена рамками процедур. Далее
пользователю предоставляется возможность указать, какую именно
переменную выбрать в качестве выходного значения функции,
в которую компилируется псевдокодовая процедура, а также
переменные, используемые в качестве входных параметров.
Пользователь может не указать такую переменную, тогда она
компилируется в пользовательский оператор.
После этого взаимодействие с пользователем закончено,
и компилятор начинает формировать C#-файл подключаемой
библиотеки, которая будет содержать разрабатываемые функции
и операторы.
Сначала в текст C#-файла добавляется заголовок, содержащий
подключение необходимых для его работы .NET библиотек, задает
пространство имен библиотеки FuncLib и объявляет класс ExtFunctions.
Далее в классе ExtFunctions происходит формирование массива
Functions, содержащего имена компилируемых функций, типы
возвращаемых параметров и их текстовые описания, указанные
пользователем для каждой процедуры.
Затем в класс помещается статическое строковое поле LibName,
хранящее в себе имя библиотеки.
Поскольку все переменные являются глобальными, для работы
с ними происходит создание статического класса Variables, поля
которого соответствуют именам псевдокодовых переменных, и каждой
143
переменной присваивается значение, соответствующее ее значению
в QA-дереве.
После этого в класс ExtFunctions происходит добавление
статических методов, соответствующих компилируемым процедурам.
При этом имя метода соответствует имени процедуры, тип его
соответствует типу переменной, значение которой функция возвращает.
Если происходит компилирование процедуры в пользовательский
оператор, то генерируемый метод возвращает void. Типы входных
переменных метода выбираются в соответствии с типами переменных,
выбранных в качестве входных параметров.
После этого происходит формирование тела метода. В его начало
помещается присваивание полям класса Variables соответствующих
значений переменных – входных параметров.
Далее построчно псевдокод операторов с помощью класса-
интерпретатора псевдокода преобразуется в промежуточный код,
который пословно преобразуется в код на языке C#. При этом
используемые переменные заменяются на соответствующие им поля
класса Variables.
В конце тела метода указывается return, возвращающий значение
поля класса Variables, соответствующего переменной, выбранной
в качестве выходного значения.
После формирования C#-методов, соответствующих компилируемым
процедурам, формирование класса ExtFunctions завершается
добавлением в него стандартных методов дополнительной
подключаемой библиотеки, отвечающих за взаимодействие
ее с интерпретатором: GetFunctions, возвращающего массив Functions,
и GetLibName, возвращающего имя библиотеки.
Рассмотрим работу компилятора процедур на примере.
Пусть имеется псевдокодовая процедура вычисления факториалов:
144
Q1.1. PROCEDURE &Factor& Q1.1.1. &mul& := 1 A1.1.1.1. 1 Q1.1.2. &fact& := 1 A1.1.2.1. 1 Q1.1.3. LABEL &FactBegin& Q1.1.4. &fact& := &fact& * &mul& Q1.1.5. &mul& := &mul& + 1; Q1.1.6. IF &mul&<= &x& THEN GOTO &FactBegin& Q1.1.7. ENDPROC&Factor& При сканировании данной процедуры обнаруживаются следующие
переменные: &mul&, равная 1, &fact&, равная 1, &x&, объявленная где-
то в другом месте за пределами процедуры и равная, допустим, 0.
В качестве входного параметра пользователь выбирает &x&,
а в качестве результирующего значения – &fact&.
После формирования заголовка и класса ExtFunctions происходит
формирование массива Functions, который выглядит следующим
образом: privatestaticFunctions[,] = {{"INTEGER",
"FACTOR", "Факториал"}}.
В статический класс Variables попадают все используемые
процедурой переменные: private static class Variables { public static int mul = 1; public static int fact = 1; public static int x = 1; }.
Далее путем построчного преобразования формируется метод
FACTOR: public static FACTOR (int x) { Variables.x = x; Variables.mul = 1; Variables.factor = 1;
145
FactBegin: Variables.fact = Variables.fact *
Variables.mul; Variables.mul = Variables.mul + 1; if (Variables.mul <= Variables.x) goto
FactBegin; return Variables.fact; }.
Класс ExtFunctions завершается добавлением в него двух
стандартных методов GetLibName и GetFunctions.
После этого файл C#-кода скомпилированной функции сохраняется
и для него происходит вызов компилятора csc из пакета Microsoft.NET
Framework. В результате компилирования получается .dll файл, который
можно подключать к интерпретатору псевдокода и использовать
функцию FACTOR для вычисления факториала в любой псевдокодовой
программе: &f& := FACTOR (&val&).
Функция произведет вычисление факториала числа &val&,
а полученное значение будет помещено в переменную &f&.
2.3.7. Редактор псевдокодовых программ
Процесс псевдокодового программирования на языке LWIQA должен
быть удобным для программиста. Поскольку среда WIQA интегрирует
в себе вопросно-ответную базу данных и инструментарий выполнения
псевдокодовых программ, логичным представляется дополнить
инструментарий псевдокодового программирования в среде WIQA
редактором, который может раскрыть вопросно-ответное дерево
программы в виде текста, а также осуществить связь между редактором
и другими инструментами работы с псевдокодовыми программами.
Реализация такого редактора позволяет говорить о построении
интегрированной среды разработки (IDE) для языка LWIQA.
146
Интерфейс редактора предоставляет возможность набирать код
псевдокодовой программы, а также, поскольку реализация редактора
имеет доступ к вопросно-ответной базе данных, осуществить запуск
интерпретатора и компилятора для псевдокодовой программы. Редактор
позволяет объявлять и инициализировать переменные и формировать
псевдокодовые базы данных. Также он дает возможность указать, какие
операторы можно интерпретировать в режиме блочного выполнения,
а какие должны выполняться только в пошаговом однооператорном
режиме. Кроме того, редактор обеспечивает взаимодействие
с библиотекой шаблонов WIQA, позволяя сохранить фрагменты
программы как шаблоны с целью повторного их использования в других
программах.
В основе редактора лежит компонент ParagraphEditor,
реализованный для редактирования текста одного из узлов дерева.
Также этот компонент содержит элементы пользовательского
интерфейса для изменения типа узла дерева, его дополнительных
атрибутов и вызова мастера объявления переменной. На рисунке 2.14
представлен внешний вид компонента ParagraphEditor.
Рис. 2.14. Внешний вид компонента ParagraphEditor
Поле qaIdx отображает индекс узла дерева. Справа (слева направо)
отображаются элементы управления узлом: тип узла (вопрос, ответ,
задача или другой поддерживаемый тип), кнопка добавления дочернего
элемента (+), кнопка добавления соседнего элемента (=) и кнопка
удаления узла. Узел удаляется вместе со всеми узлами, для которых он
является родительским.
Сам текст псевдокодовой программы формируется как набор
компонентов ParargaphEditor, расположенных один под другим, что
147
создает впечатление работы с деревом как с текстом программы.
При запуске редактора для задачи происходит формирование списка
компонентов ParagraphEditor, который затем отображается в окне
редактора. Каждый такой компонент может держать фокус.
Следовательно, имеется возможность определить узел дерева,
включающий компонент, с которым происходит работа в данный
момент. Это позволяет осуществить для него вызов интерпретатора,
компилятора функций, мастера объявления переменных в том случае,
если текст содержит имя новой переменной.
Мастер объявления переменных представляет собой набор форм,
первая из которых определяет имя и тип переменной. Схема типов
приведена на рисунке 2.15.
Рис. 2.15. Схема мастера объявления переменных
Выбор дальнейшей формы зависит от выбранного типа переменной:
если переменная простого типа, форма предлагает указать его значение,
если же это запись – отображается форма, предлагающая задать набор
полей и их типы. В случае массивов предлагается выбрать тип элементов
массива и задать его размерность. Мастер объявления переменных
можно представить в виде дерева, в котором корнем будет определение
148
типа переменной, а листьями – формы, на которых работа мастера будет
завершена и будет произведено формирование структур создаваемой
переменной.
После создания переменной в мастере происходит изменение
содержимого QA-дерева программы, следовательно, возникает
необходимость в обновлении списка редакторов ParagraphEditor. Для
этого запоминается положение фокуса на определенном компоненте
ParagraphEditor по его индексу, после чего список перестраивается
и фокус опять устанавливается на выбранном компоненте. Аналогичное
обновление дерева происходит при всяком изменении в QA-дереве
программы.
В процессе расширения языка LWIQA функциональностью по работе
с базами данных редактор был дополнен инструментарием
формирования псевдокодовой базы данных. Он реализован в виде
мастера, аналогичного мастеру объявления переменных.
Таким образом, разработанный редактор является интегрированной
средой разработки, позволяющей получить доступ практически ко всем
инструментам работы с псевдокодовыми программами.
2.4. Псевдокодовое программирование
2.4.1. Примеры псевдокодовых программ
Для демонстрации употреблений языка LWIQA, а вернее, особенностей
записи исходных кодов представим (не вдаваясь в объяснения) ряд
псевдокодовых фрагментов, используемых в комплексе WIQA и его
приложениях.
1. Каталогизация конструктов программных комплексов
(используется для формирования активов базы опыта проектной
организации).
149
Z 10.3.5.1.2.1 Извлечение активов из cpp-файла;
Q 10.3.5.1.2.1.1 &cur_par& := &Current_Parent&;
Q 10.3.5.1.2.1.2 &methodflag& := 0;
Q 10.3.5.1.2.1.3 &qtflag& := 0;
Q 10.3.5.1.2.1.4 LABEL &CYCLE1&;
Q 10.3.5.1.2.1.5 &parid& := QA_GetParent(&Current_ Project&,
&cur_par&);
Q 10.3.5.1.2.1.6 IF &parid& == 0 THEN GOTO &CHECK& ELSE
GOTO &GOUP&;
Q 10.3.5.1.2.1.7 LABEL &GOUP&;
Q 10.3.5.1.2.1.8 &partxt& := QA_GetQAText(&parid&);
Q10.3.5.1.2.1.9 &clc& := STRCMP(&partxt&,"Свойства, процедуры,
функции");
Q 10.3.5.1.2.1.10 IF &clc& == 0 THEN &methodflag& := 1;
Q 10.3.5.1.2.1.11 &qtc& := STRCMP(&partxt&,"QT 4");
Q 10.3.5.1.2.1.12 IF &qtc& == 0 THEN &qtflag& := 1;
Q 10.3.5.1.2.1.13 &cur_par& := &parid&;
Q 10.3.5.1.2.1.14 GOTO &CYCLE1&;
Q 10.3.5.1.2.1.15 LABEL &CHECK&;
Q 10.3.5.1.2.1.16 &cur_txt& := QA_GetQAText(&cur_par&);
................................................................................................
Q 10.3.5.1.2.1.75 GOTO &FIN&;
Q 10.3.5.1.2.1.76 LABEL &ERROR&;
Q 10.3.5.1.2.1.77 ERRORBOX("Извлечение активов","Методика
запущена в неверном задачном контексте!");
Q 10.3.5.1.2.1.78 LABEL &FIN&;
Q 10.3.5.1.2.1.79 FINISH;
150
2. Контроль и диагностика работоспособности прибора
(компонента аппаратно-программного обеспечения диагностики
продукции предприятия).
Q 1.22 Процедуры автономного тестирования;
Q 1.22.1 PROCEDURE &Выполнить_автономное_тестирование&;
Q 1.22.1.1 CALL &Выполнить_предпусковое_тестирование&;
Q 1.22.1.2 CALL &Выполнить_контроль_выборочными_тестами&;
Q 1.22.1.3 ENDPROC &Выполнить_автономное_тестирование&;
Q 1.22.2 PROCEDURE &Выполнить_предпусковое_тестирование&;
Q 1.22.2.1 INPUT &redVMZ1CUVS&
При предпусковом тестировании на изображении структурной
схемы прибора на экране ВМЦ1 или ВМС одна из плат или один из
контроллеров УВС.01 отображается красным цветом?
0 – нет;
1 – да.
A 1.22.2.1.1 0;
Q 1.22.2.2 IF &redVMZ1CUVS& == 0 THEN GOTO &pptNO1&;
Q 1.22.2.3 CALL &Отключить_прибор&;
Q 1.22.2.4 Подождать 20-30 секунд;
Q 1.22.2.5 CALL &Включить_прибор&;
Q 1.22.2.6 INPUT &redVMZ1CUVS&;
При предпусковом тестировании на изображении структурной
схемы прибора на экране ВМЦ1 или ВМС одна из плат или один из
контроллеров УВС.01 отображается красным цветом?
0 – нет;
1 – да.
………………………………….
Q 1.22.7.23 RETURN;
Q 1.22.7.24 LABEL &LASTMG&;
151
Q 1.22.7.25 Нажать комбинацию клавиш "CTRL-P";
Q 1.22.7.26 ENDPROC &Тест_МГ&;
3. Диагностика неисправностей персонального компьютера
(утилита, помогающая пользователю компьютера разобраться
с возможными причинами ряда неполадок).
Q 1.6 PROCEDURE &CheckOverheat&;
Q 1.6.1 ENDPROC &CheckOverheat&;
Q 1.6.2 &temp& Перегрев процессора часто является причиной
снижения производительности, возникновения ошибок и зависаний
в работе компьютера.
A 1.6.2.1 36;
Q 1.6.3 INPUT &choose&;
Вы хотите проверить температуру процессора на этом
компьютере или на другом? (1 – на этом, 2 – на другом).
Q 1.6.4 IF &CHOOSE& == 2 THEN GOTO &OTHERPC&;
Q 1.6.5 &temp& := CpuTemp();
Q 1.6.6 GOTO &EXAMINE&;
Q 1.6.7 LABEL &OTHERPC&;
Q 1.6.8 Чтобы проверить температуру процессора, зайдите в BIOS
Setup Utility;
Q 1.6.9 Перейдите в меню PC Health Status;
Q 1.6.10 INPUT &temp&;
Введите температуру.
Q 1.6.11 LABEL &EXAMINE&;
Q 1.6.12 IF &temp& < 30 THEN GOTO &OK&;
Q 1.6.13 Температура процессора повышена. Проверьте
вентиляторы, почистите от пыли системный блок, в случае
необходимости замените термопасту на процессоре.
152
Q 1.6.14 CALL &ASK&;
Q 1.6.15 RETURN;
Q 1.6.16 LABEL &OK& Температура процессора в норме.
2.4.2. Система документирования DocWIQA.Net
Представленные выше коды программ демонстрируют
императивный потенциал языка LWIQA. В то же время в этот язык
вложены и возможности декларативного программирования, одним из
приложений которого является программирование работы с проектными
документами, отображаемыми на QA-память. Такую работу обслуживает
система документирования DocWIQA, предназначенная для
автоматизированного формирования проектной документации
и поддержания в актуальном состоянии множества документов
в проектной организации, разрабатывающей семейства АС.
В создании DocWIQA учитывался не только потенциал ядра
комплекса WIQA.Net, но и опыт разработок и эксплуатации средств
работы с документами, обеспечивающих регистрацию документов,
редактирование файлов (документов), работу с поручениями, работы
с проектами документов, прием и внешнюю рассылку документов,
движение документов внутри организации, формирование дел,
информационно-справочную работу и удаленный доступ.
Среди современных систем, реализующих такую функциональность,
можно выделить следующие наиболее популярные и богатые по своим
функциональным возможностям: «Босс-референт», «Дело», «Евфрат-
документооборот», «Летограф», «Мотив», «CompanyMedia»,
«CorporateBusiness», «Directum», «DocsVision», «Globus», «LanDocs»,
«OptimaWorkflow», «Paydocs».
153
Однако в этих системах не предусмотрены средства для
автоматизированного формирования документов на основе проектных
решений.
Такую функциональность предоставляют системы генерации
проектной документации, самой известной из которых является Rational
SoDA, собирающая информацию для документов из продуктов
семейства Rational. Основным недостатком SoDA является
ее возможность генерирования только документов RUP. В российских
проектных организациях в большинстве случаев используются
документы ГОСТ. Перевод документов RUP в ГОСТ занимает
значительное время и осуществляется вручную.
Является целесообразным использование системы
документирования в составе средств WIQA.Net, предоставляющей
возможности автоматического формирования проектной документации
в соответствии с ГОСТ или другими стандартами из единого хранилища
данных, ассоциированного с рабочей областью инструментария
проектной деятельности организации.
Система документирования предоставляет возможности:
1. Определения библиотеки шаблонов документов для хранения
типовых форм документов в следующем составе:
− шаблоны данных для документов, представляющих собой
древовидное, вопросно-ответное отображение типовой структуры
документов (плагин «Вопросно-ответные шаблоны»);
− шаблоны представления документов в виде визуальных
шаблонов документов в текстовом варианте с форматированием (плагин
«Шаблоны отчетов»).
2. Редактирования содержимого документов (плагин «Вопросно-
ответный протокол»).
154
3. Формирования визуального представления документов,
их хранения, печати и экспорта во внешние программы (плагин
«Проектная документация»).
4. Взаимоувязки шаблонов представления и данных в вопросно-
ответном протоколе для обеспечения генерации документов (плагин
«Система атрибутики»).
Комплекс средств автоматизированного построения проектных
документов предоставляет возможности для формирования шаблонов
данных документов, шаблонов оформления документов, редактирования
реальных данных, автоматического формирования документов
и передачи их во внешние приложения или вывода на печать. Общая
схема взаимодействия модулей, обеспечивающих документирование,
представлена на рисунке 2.16.
Рис. 2.16. Взаимодействие модулей
Связующим звеном между данными документа и его представлением
выступают атрибуты (плагин «Система атрибутики»), которые
приписываются содержательным частям документа и местам в шаблонах
оформления, куда они должны быть вставлены.
Процесс составления шаблонов и экземпляров документа,
представленный на рисунке 2.17, состоит в следующем:
QA-шаблоны QA-протокол
Шаблоны оформления
Проектные документы
Атрибуты
155
1. Формирование шаблонов данных документа (плагин «Вопросно-
ответные шаблоны») – один раз для каждого документа проектной
организации. На этом этапе формируются типовые вопросно-ответные
структуры каждого документа – по сути, определяется содержательная
часть типового документа: разделы, главы, абзацы.
2. Формирование шаблона оформления документа (плагин
«Шаблоны отчетов») – один раз для проектной организации:
формирование внешнего вида документа, определение точек вставки
содержательных частей в документ, их представление (шрифт, цвет,
список и т. д.). Шаблоны отчетов, позволяющие создать шаблоны
представления документов, содержащие текст шаблона и обозначение
точек включения данных, заданных атрибутами. Точки включения
данных выглядят в виде тегов [#attrname], где #attrname – символьное
имя атрибута. Включение тега с указанием символьного имени атрибута
осуществляется в визуальном режиме путем простого перетаскивания из
компонента «Дерево атрибутов» в текстовый редактор.
3. Перенесение шаблонов данных в вопросно-ответный протокол
текущего РЕАЛЬНОГО проекта, внесение РЕАЛЬНЫХ данных для
каждого проектного решения. На этом этапе шаблоны содержательной
части переносятся в область данных реального проекта (плагин
«Вопросно-ответный протокол»), вместо шаблонных данных вносятся
реальные данные конкретного проекта.
4. Формирование документа в плагине «Проектная документация»
(для каждого экземпляра документа):
− выбор задачи документирования в вопросно-ответном протоколе;
− выбор шаблона оформления;
− определение имени документа, его описания;
− генерация документа.
156
Система атрибутикиШаблон спецификации ФИО:
Шаблон служебной записки ФИО:
Служебная записка ФИО: И.И.Иванов
Спецификация ФИО: И.И.Иванов
Спецификация ФИО: П.П.Петров
Спецификация ФИО: С.С.Сидоров
Служебная записка ФИО: П.П.Петров
Служебная записка ФИО: С.С.Сидоров
Рис. 2.17. Связывание шаблона и данных
5. Просмотр документа, передача в систему документооборота,
печать.
В плагине «Проектная документация» осуществляется назначение
задачи вопросно-ответного протокола с вложенными вопросно-
ответными единицами с назначенными атрибутами определенному
шаблону представления. При генерации документа осуществляется
разбор шаблона, определение позиции атрибута, помеченного тегом
[#attrname], рекурсивный обход поддерева вопросно-ответных единиц
с целью поиска найденного атрибута и встраивание его в шаблон
с заменой тега атрибута. Диаграммное представление всех видов работ
и их связность приведены на рисунке 2.18.
157
Рис. 2.18. Общий порядок работы с системой документирования
2.4.3. Документирование в системе OwnWIQA
Основные возможности системы документирования в персональной
версии WIQA.Net заключаются в автоматизированной генерации
проектной документации на основе данных, хранящихся в вопросно-
ответных единицах с назначенными атрибутами, соответствующими
атрибутам разметки документа.
158
Механизм формирования представления документа – язык HTML.
В качестве редактора был выбран редактор CKEditor, встроенный
в форму WPF с компонентом WebBrowser.
Рассмотренная выше версия системы документирования обладала
рядом существенных недостатков.
Во-первых, для каждой «точки» вставки данных в документ
необходимо было разрабатывать свой семантический атрибут. В итоге
количество атрибутов многократно возрастало, и появилась проблема
поддержания их актуальности. Во-вторых, вставка таблиц влекла
за собой дополнительные действия по ручному добавлению
соответствующих «разметочных атрибутов»: подобная ситуация
возникает при необходимости вставки нумерованных и ненумерованных
списков.
Для решения этих проблем была разработана новая версия системы
документирования, в которой работа с атрибутами скрыта
от пользователя. При этом он имеет возможность «ручного»
редактирования атрибутов стандартными средствами.
Атрибуты используются только специальные, соответствующие
схеме HTML 1.0: тег со свойствами. Причем наименование тега может
быть любым.
Работа с документом заключается в простом формировании
документа визуальными средствами (наподобие MSWord). При этом сам
документ может быть автоматически сохранен в вопросно-ответном
протоколе через пункт меню «Документирование» –> «Сохранить
шаблон в QA». Сохранение производится автоматически. При этом
создается вопросно-ответная структура, соответствующая структуре
документа. Вопросно-ответные единицы могут быть изменены
штатными средствами во вкладке «Вопросно-ответный протокол», при
этом все изменения отобразятся в визуальном редакторе документов при
159
открытии документа в редакторе (для этого необходимо выбрать
в QA-дереве единицу и выбрать пункт меню «Документирование» –>
«Загрузить шаблон из QA»).
Во встроенном редакторе WYSIWYG используются стили
документа. Для изменения набора стилей для документа можно
воспользоваться пунктом меню «Документирование» –> «Редактировать
стили». Редактирование осуществляется на языке CSS2 во встроенном
редакторе с подсветкой синтаксиса.
Сама схема трансформации представлена на рисунке 2.19.
Рис. 2.19. Схема трансформации
Ключевое преимущество такого подхода заключается в том, что
источниками данных для документа могут являться любые источники
в вопросно-ответном протоколе: мы можем посмотреть любой вопросно-
160
ответный протокол в редакторе и при необходимости дополнить его
форматированием.
Рабочая область системы документирования представлена
на рисунке 2.20 и выглядит следующим образом:
1. Вопросно-ответный протокол.
2. Область визуального редактора документов.
3. Атрибуты, соответствующие разделам документа (единицам
вопросно-ответного протокола).
Рис. 2.20. Рабочая область системы документирования
В данной версии системы документирования шаблоны и документы
хранятся в вопросно-ответном протоколе. Такая унификация позволяет
упростить систему и сделать ее более «логичной».
161
Механизм трансформации документов в протокол реализован
следующим образом: рекурсивный метод SaveToQA реализует
преобразование HTML-документа в вопросно-ответный протокол,
соответствующий DOM-модели HTML-документа, формируемого
в WYSIWYG редакторе. Это, по сути, копия структуры дерева.
Для взаимно-однозначного соответствия QA-единиц объектам DOM-
модели документа QA-единице назначается атрибут HTMLElement
со следующими свойствами:
− WIQA.Documentation.Tag – имя тега элемента HTML;
− WIQA.Documentation.Style – CSS-стиль элемента: хранит
информацию о внешнем представлении элементов (цвете, шрифте,
размере и т. д.);
− WIQA.Documentation.Class – класс CSS для элемента, если он
существует;
− WIQA.Documentation.Id – это уникальный идентификатор;
− WIQA.Documentation.Src – путь к файлу изображения;
− WIQA.Documentation.Title – заголовок;
− WIQA.Documentation.File – массив байтов для изображения.
Если документ содержит изображение, метод генерации
QA-протокола для документа автоматически считывает его в массив
байт и сохраняет этот массив в качестве вложения QA-единицы.
2.4.4. Прототипирование пользовательских интерфейсов
Наряду с простыми средствами формирования диаграмм (в том числе
прототипов пользовательских интерфейсов) в среде WIQA.Net
реализованы средства автоматизированной генерации пользовательских
интерфейсов на основе диаграммы пользовательских сценариев и ролей
с применением пополняемой библиотеки прецедентов, основанной на
практиках Microsoft в области проектирования пользовательских
162
интерфейсов. Данную функциональность предоставляет среда UXWIQA,
встроенная в комплекс WIQA.Net.
В общем виде процесс вопросно-ответного прототипирования
пользовательских интерфейсов состоит из следующих этапов:
1. Формирование интерфейсных диаграмм вариантов
использования проектируемой системы с применением встроенного
в WIQA.Net редактора.
2. Автоматическое формирование на базе созданной интерфейсной
диаграммы вопросно-ответной структуры задачи по прототипированию
интерфейсов программ на основе прецедентов, представляющей собой
абстрактную модель проектируемой системы.
3. Определение графических элементов прототипа (элементов
управления), созданных на основе прецедентов, составляющих
конкретную модель.
4. Автоматическая генерация исходных кодов прототипов
на псевдокодовом языке, основанном на XML.
5. Преобразование XML-файлов в исходные коды прототипов для
целевой технологии (WindowsForms, HTML, WPF, Silverlight, ASP.NET).
6. Компиляция исходных кодов прототипов в исполняемое
приложение средствами WIQA.Net для просмотра и тестирования или их
импорт в интегрированные средства разработки приложений для их
дальнейшего изменения.
Интеграция с WIQA.Net позволяет достичь ряда положительных
эффектов:
− применение средств вопросно-ответного моделирования при
представлении рассуждения разработчиков на естественном языке
и использовании инструментальных средств управления ими;
− применение системы методик и прецедентов для вызова внешней
функциональности, не имеющей программной реализации, но доступной
163
на этапе концептуального проектирования для оперативного
тестирования логики и сценариев проектируемой АС;
− обеспечение разграничения прав доступа для различных
участников проектной группы;
− использование артефактов псевдокодового прототипирования,
представленных в вопросно-ответном протоколе, для дальнейших этапов
проектной деятельности средствами WIQA.Net.
Разработанный комплекс средств представляет собой набор плагинов
к системе WIQA.Net (ЭС юзабилити проектирования, система
атрибутики) и ряд отдельных приложений, интегрированных с ней
(редактор интерфейсных диаграмм, модуль генерации исполняемых
прототипов для технологии WindowsForms).
Разработка осуществлена с использованием технологий WPF,
.NETRemoting, XML на платформе Microsoft.NET, так как система
WIQA.Net реализована с использованием данных технологий. Общая
схема преобразований моделей для генерации прототипов проектных
решений представлена на рисунке 2.21.
Из данной схемы видно, что часть функциональности комплекса
средств псевдокодового прототипирования проектных решений
заимствуется из WIQA.Net. Другими блоками обозначены
разработанные плагины WIQA.Net.
Система псевдокодового прототипирования проектных решений
представлена в виде плагина к системе WIQA.Net, реализована
с использованием технологии WPF платформы Microsoft.NET
и предоставляет визуальные средства для управления
функциональностью разработанного комплекса средств: модуль
трансформации интерфейсной диаграммы представляет собой часть
разработанного плагина, осуществляющего автоматический перевод
XML-представления интерфейсной диаграммы в вопросно-ответный вид
164
(дерево QA-единиц с назначенными им атрибутами); модуль
трансформации абстрактной модели в конкретную – набор средств,
осуществляющий загрузку элементов библиотеки интерфейсных
прецедентов в рабочее пространство и внедрение этих прецедентов
в QA-протокол на основе правил; библиотека интерфейсных
прецедентов – это набор файлов формата XML, описанных на языке
интерфейсных прецедентов.
Редактор интерфейсных диаграмм
Модуль генерации
исполняемых прототипов для Windows Forms
Система псевдокодового прототипирования проектных решений
Библиотека интерфейсных прецедентов
Модуль трансформации
интерф. диаграмм в абстр. модель
Модуль трансформации
абстрактной модели в конкретную
Модуль формирования
псевдокода
Система визуального управления
функциональностью
WIQA.NET
QA-протокол
Управление проектами
Система атрибутики
Управление атрибутами
Назначение атрибутов
Cl
СS
Cl
СS
Cl
СS
Cl
СS
Cl
С
СС
С
С
Cl
Рис. 2.21. Архитектура предлагаемых решений
Система атрибутики представляет универсальные механизмы
определения метаданных для сущностей таблиц базы данных,
реализованные в виде плагина (клиентского, серверного, сетевого)
к WIQA.Net. В реализованных решениях атрибутика применяется для
хранения дополнительных сведений о единицах вопросно-ответного
165
протокола, используемых для объектно-вопросно-ответных
преобразований, осуществляемых на разных стадиях и в разных
методиках интерфейсного прототипирования проектных решений.
Редактор интерфейсных диаграмм является отдельным
приложением, реализованным на технологии WPF и представляющим
собой визуальные средства создания, редактирования, импорта
и экспорта модели интерфейсных диаграмм.
Модуль генерации исполняемых прототипов для WindowsForms
является компонентом клиентской части WIQA.Net, принимающим на
вход псевдокодовое представление пользовательского интерфейса
проектных решений и генерирующим на его основании исходный код
исполняемого прототипа на целевой платформе.
Редактор интерфейсных диаграмм – визуальное средство создания,
модификации, импорта из XML-формат и экспорта в XML-формат
моделей интерфейсных диаграмм. Он основан на редакторе с открытыми
исходными кодами DiagramDesigner и расширяет его функциональные
возможности путем ассоциирования элементов диаграммы с объектами,
свойства которых определяются в визуальном режиме расширенной
палитрой компонентов, возможностью редактирования нескольких
связанных диаграмм в одной рабочей области и увеличенными
возможностями импорта и экспорта (рисунок 2.22).
Рис. 2.22. Визуальные элементы редактора интерфейсных диаграмм
Связь с визуальными элементами диаграммы позволяет осуществить
редактирование свойств объектов, которые в дальнейшем будут
166
перенесены в абстрактную модель пользовательского интерфейса
проектных решений (рис. 2.23).
Рис. 2.23. Пример простых вопросно-ответных преобразований
Существует два вида объектно-вопросно-ответных преобразований:
прямые и обратные. Прямые предназначены для формирования
вопросно-ответного протокола, исходя из XML-описания правил
трансформации и объекта, который необходимо представить в вопросно-
ответном виде. Объект получается из XML-описания с помощью
сериализации .NET. В настоящее время разработан универсальный
интерпретатор этого языка. Обратные преобразования позволяют
из вопросно-ответного протокола сформировать объект, который может
быть в дальнейшем использован в приложении.
В разработанном комплексе средств прямые преобразования
используются для формирования абстрактной и конкретной моделей,
а обратные – для формирования конкретной модели и псевдокода.
167
В общем виде схема потоков данных при автоматическом
формировании абстрактной модели представлена на рисунке 2.24.
Рис. 2.24. Схема потоков данных формирования абстрактной модели
Из схемы видно, что для формирования абстрактной модели
проектных решений используются XML-описания вопросно-ответных
шаблонов, по образцу которых будут формироваться QA-протокол
и данные в объектном виде, получаемые из XML-описания
интерфейсных диаграмм, генерируемого средствами редактора этих
диаграмм в автоматическом режиме.
Интерпретатор загружает шаблоны в объектный вид путем
десериализации и осуществляет сопоставление данных шаблона
с данными модели, а на последнем этапе совмещенные иерархические
данные встраивает в вопросно-ответный протокол.
В общем виде процесс трансформации заключается в следующем:
1. Автоматически загружается архив с XML-представлением
интерфейсной диаграммы.
2. Восстанавливается объектная модель интерфейсной диаграммы,
представленная классами Attribute, Parameter, QA, QATemplate.
3. Загружается вопросно-ответный шаблон.
168
4. Шаблон наполняется данными из модели интерфейсной
диаграммы.
5. Заполненный шаблон встраивается в вопросно-ответный
протокол выбранной задачи с использованием классов
QAProtocolEmbedder.
Система вопросно-ответных шаблонов позволяет осуществить
автоматическое формирование вопросно-ответного протокола на основе
заданной объектной модели, которая может содержать коллекции
элементов. При этом в шаблоне описывается только один элемент.
Каждому элементу шаблона приписываются дополнительные атрибуты,
значение которых также может браться из объектной модели.
Интерпретатор рекурсивно обходит загруженный вопросно-ответный
шаблон и для каждого его элемента обнаруживает в загруженных
объектах необходимый элемент или коллекцию элементов.
Библиотека прецедентов и метрик
Формирование конкретной модели осуществляется в два этапа:
автоматический выбор прецедентов, созданных на основе описания
элементов управления и хранящихся в библиотеке прецедентов,
и автоматизированный выбор.
Автоматический выбор осуществляет селекцию нескольких
интерфейсных прецедентов для одного типа точек интерактивного
взаимодействия. Это может быть редактирование свойств объектов
предметной области, или запуск операции, или отображение группы
элементов управления.
Правила автоматического выбора записываются на расширенном
языке объектно-вопросно-ответных преобразований и бывают двух
типов:
169
1. Устанавливающие простое соответствие древовидных структур
для поиска в QA-протоколе единиц с определенными атрибутами.
2. Осуществляющие проверку связанности поддеревьев через
атрибуты для определения QA-единиц, ссылающихся на другие единицы
посредством системы атрибутики, например, для поиска пар «элемент-
действие» (рис. 2.25).
Интерпретатор правил конкретной модели
Выборка данных по атрибутам
Внесение данных с атрибутами
XML-Описания прецедентов
<Precedent Name="TextBox" Description=""> <Selection> <Automate> <SelectionRule> <QATemplate> <QA Select="false"> <Attribute Name="object"></Attribute> <QA Select="true"> <Attribute Name="propertyname"></Attribute>
Рис. 2.25. Схема потоков данных формирования конкретной модели
Генератор псевдокодового представления интерфейсного
обеспечения АС
В общем виде алгоритм составления псевдокодового представления
пользовательского интерфейса выглядит следующим образом:
1. Выбираются акторы системы (выбираются те вопросно-ответные
единицы, которые имеют атрибут Actor), из них формируется экземпляр
класса Actor, имеющий следующие свойства: Name (имя), Description
(описание), Key (уникальный идентификатор объекта в псевдокодовом
представлении).
2. Определяются те вопросно-ответные единицы, у которых
в конкретном прототипе выбран элемент управления Window (окно)
170
на основании атрибутики, формируется экземпляр класса Window и его
свойства: тип (диалоговое, модальное, форма, мультимодальное),
ширина, высота, наличие кнопок, текст заголовка окна. Все данные
берутся из вопросно-ответного протокола на основании механизмов
атрибутики.
3. Устанавливаются те вопросно-ответные единицы, с которыми
соотнесены управляющие и информативные элементы управления,
формируется экземпляр класса Control, у которого определено
свойство – тип (кнопка, текстовое поле, выпадающий список и т. д.).
4. Выбираются вопросно-ответные единицы, которым приписаны
командные элементы (кнопки, панели инструментов, ленты).
5. Определяется, какие команды выполняются при задействовании
этих элементов:
− без обработчика NotImplementedHandler;
− переход на новую форму NavigationHandler;
− начало действия StartHandler;
− конец действия EndHandler;
− закрытие формы.
6. Создаются экземпляры классов элементов, соответствующие
командным элементам, и обработчики событий, в которых
прописывается тип действий при срабатывании события в командном
элементе управления.
Все объекты сериализуются в XML-файл, являющийся
псевдокодовым представлением пользовательского интерфейса.
Генерация псевдокодового прототипа осуществляется на основе
данных конкретной модели путем вопросно-ответных
XML-преобразований. При этом в псевдокод встраиваются элементы
XML, представляющие собой формы (окна), элементы управления,
171
их свойства и события, параметры для вызова методов внешних
библиотек, параметры для вызова методик из системы WIQA.Net
и параметры для вызова функциональности, запрограммированной
в системе прецедентов WIQA.Net.
Выводы по второй главе
1. В профессионально-зрелой разработке АС обязательно создается ее концептуальное представление (концептуальный проект), основу которого составляет совокупность задач, без концептуального решения которых успешность программно-конструкторско-технологической реализации АС сомнительна. Концептуальный проект АС – это, прежде всего, система задач, решенных концептуально.
2. Под концептуальным решением задачи принято понимать ее решение, зарегистрированное на естественно-профессиональном языке в его алгоритмическом употреблении и содержащее при необходимости диаграммные модели и табличные конструкты.
3. Инструментально-моделирующая среда WIQA разрабатывалась для поиска концептуальных решений проектных задач и экспериментирования с решениями в семантической памяти вопросно-ответного типа (QA-памяти).
4. Исследования QA-рассуждений в процессах решения задач привели к вопросно-ответной модели задачи, подтвердившей свою полезность как в индивидуальной, так и в коллективной проектной деятельности.
5. Практика применения QA-моделей задач привела к типовой структуре такой модели, в которой интегрируются базовые для автоматизированного проектирования архитектурные виды на QA-модель задачи, что позволяет материализовать ее как специализированную интерактивную АС.
6. В ячейки QA-памяти можно загружать любые информационные объекты, но после загрузки эти объекты наследуют базовую атрибутику ячеек. Кроме того, загруженным объектам можно приписать необходимые по каким-то причинам дополнительные атрибуты.
7. Данные и операторы псевдокодовых программ, загруженные в QA-память процессора WIQA, приобретают свойства, позволяющие создавать программы активности проектировщиков, причем программы, которые ими же и исполняются.
172
8. Построение псевдокодовых программ в среде WIQA осуществляется на псевдокодовом языке LWIQA, получившем название WIQA, во-первых, из-за того что средства его употребления встроены в комплекс WIQA, а во-вторых, потому, что этот инструментарий можно считать интегрированной средой псевдокодового программирования коллективной деятельности проектировщиков в концептуальном проектировании АС.
9. Язык LWIQA специально приближен к естественному языку в его алгоритмическом употреблении, обслуживающему взаимодействие человека с доступным опытом в концептуальном проектировании АС.
10. Язык LWIQA в существенной мере ориентирован на исполнение псевдокодовых программ, построенных на этом языке, I-процессором.
11. Язык LWIQA может использоваться для программирования задач разных типов, но в средствах его употребления существенное место занимает ориентация на задачи, за которыми стоят прецеденты. Этот язык можно квалифицировать как «прецедентно-ориентированный».
12. Исполнение роли «интеллектуальный процессор», как и любой роли, исполнение которой поддерживается в технологиях разработки SIS и АС – это активность человека, рационально применяющего в решении определенного класса задач инструменты, предназначенные для такой работы. Основными из таких инструментов являются средства, обслуживающие QA-программирование и помогающие проектировщику в исполнении QA-программ.
13. В работе с данными и операторами QA-программ I-процессор имеет возможность запланировано или оперативно изменить их спецификацию, рационально использовав для этого механизмы дополнительной атрибутики, если в этом имеется необходимость.
14. Вложенные в комплекс WIQA средства QA-программирования обеспечивают создание QA-программ всех типов, о которых говорилось в монографии, среди них вопросно-ответные псевдопрограммы наиболее приближены как к N-программам, так и к К-программам.
173
Глава 3. Программно-картотечное управление
3.1. QA-средства в исследованиях проблемы успешности
3.1.1. Семейство QA-систем и их версий Изначально QA-средства исследовались и разрабатывались для их
применения в автоматизированном проектировании как средств
интеллектуализации человеко-компьютерных взаимодействий при
создании автоматизированных систем. В теоретических обобщениях
принятые решения переносились на более широкий план – человеко-
компьютерную деятельность, в рамках которой приходится решать
задачи.
Существующий опыт реализаций QA-средств позволяет перейти
к практическим обобщениям и представить их в виде спецификаций
семейства QA-систем, наследуемых при разработке новых QA-систем,
а также позиционирующих место семейства в классе АС, которые
обеспечивают процессы человеко-компьютерной деятельности. Для
решения такой задачи пригодны нормативы рабочей схемы Framework
for Software Product Line Practice-Version 5.0 (FSPLP.5.0). По сути,
FSPLP.5.0 является общепризнанным «стандартом», разработанным
Институтом Программной Инженерии (SEI) университета Карнеги-
Меллон, признанным мировым лидером в предметной области АС,
интенсивно использующих программное обеспечение.
В нормативной схеме FSPLP.5.0 вместо термина «семейство
продуктов» используется термин «линия продуктов» в его применении
174
к продукции, нашедшей на рынке своего массового потребителя. По
этой причине в дальнейшем будем использовать термин «семейство
QA-систем», подчеркивая тем самым опытно-конструкторский характер
опыта реализаций QA-систем.
Логично считать, что употребление термина «семейство QA-систем»
как родственного термину «линия продуктов» правомерно в том случае,
когда:
− явно сформулирована задача разработки такого семейства,
например, с учетом требований FSPLP.5.0 или другой родственной
рабочей схемы;
− разработан ряд QA-приложений, в создании которого неявно
использовались принципы, лежащие в основе создания семейств
продуктов.
Реальность разработок QA-средств такова, что при создании всех
версий комплекса WIQA до 2007 года использовались механизмы
развития и реализации, согласованные с принципами создания семейств
продуктов, но без явного акцента на семействе продуктов. С 2007 года
опыт разработок всех предшествующих версий комплекса WIQA
используется для разработок очередных версий комплекса, включая
версии WIQA.Net и OwnWIQA, с явной ориентацией на семейство
QA-систем.
В связи с переходом к разработкам очередных версий
QA-приложений с позиций семейства QA-систем было решено
использовать имена {x}WIQA.yyy, где {x} указывает на специфику
QA-системы, а yyy либо отсутствует либо указывает на сетевую версию
Net. Переход к новым именам отражал и тот факт, что в реализациях
было решено использовать инструментально-технологические средства
«Microsoft.NET».
175
Явная ориентация на разработку семейства QA-систем привела
к решению пересмотреть подходы к реализации QA-систем, в первую
очередь, с позиций развития QA-семейства как единого целого, так
и развития каждой из его составляющих. Именно по этим причинам
в состав компонентов комплекса WIQA включены средства развития,
представленные на рисунке 2.2.
За период с 2007 по 2014 год созданы и прошли проверку следующие
QA-системы:
1. CdWIQA.Net, обслуживающая процессы концептуального
проектирования (Сonceptual designing) автоматизированных систем.
2. DocWIQA.Net, обеспечивающая оперативное документирование
(Documenting) проектных работ в соответствии с используемыми
в организации стандартами.
3. EduWIQA, предназначенная для обучающего сопровождения
(Educational maintenance) коллективной проектной деятельности,
а также для создания обучающих курсов по разрабатываемым АС и их
составляющим.
4. DmWIQA, ориентированная на поддержку принятия проектных
решений (Decision-making) с использованием механизмов экспертных
систем.
5. EmWIQA, моделирующая процессы экспертного мониторинга
(Expert monitoring) окружающей обстановки морского судна (проверены
возможности реализации многоагентных приложений и использования
моделей прецедентов).
6. TechWIQA.Net, предназначенная для автоматизации
технологической (Technological preparing) подготовки производства.
7. OwnWIQA, ориентированная на использование потенциала
инструментария WIQA в персональной (Own) работе.
176
Опыт разработки перечисленных QA-систем, причем ряда из них
в нескольких версиях, позволяет утверждать следующее:
1. QA-системы открыты для их полезного использования в любой
человеко-компьютерной деятельности, в том числе и в коллективной,
в процессе осуществления которой приходится решать определенные
задачи.
2. По сравнению с другими вариантами осуществления человеко-
компьютерной деятельности QA-системы отличаются тем, что
в процессах решения задач они способны обеспечить интеграцию
интеллектуальных усилий группы лиц, если это окажется необходимым.
3. Принципиальным плюсом применения QA-систем является то,
что они способствуют поиску и построению концептуальных решений
задач, а если концептуальные решения построены, то и их
представлению в формах, облегчающих их использование, в том числе
и повторное, при необходимости – с адаптацией.
Сформулированные утверждения не только отражают общее
в разнородных QA-приложениях, но и подтверждают:
− во-первых, правомерность (достаточная общность и весомые
различия) образования из них QA-семейства, соответствующего
нормативной рабочей схеме FSPLP.5.0;
− во-вторых, существование для QA-семейства вполне
определенного места (интеграция интеллектуальных усилий,
концептуальное решение задачи) среди других родственных систем или
их семейств, сущность которых определяют процессы решения задач.
Выбор нормативной схемы FSPLP.5.0 для спецификаций семейства
QA-систем позволяет использовать ее для детализации общности
и различий между членами семейства, а значит, и для уточнения места
QA-семейства среди родственных систем.
177
Анализ и определение спецификаций семейства QA-систем, исходя
из рабочей схемы FSPLP.5.0, можно было бы продолжить, но и уже
представленных спецификаций достаточно для выделения семейства
QA-систем и целесообразности его формирования и развития
с использованием схемы FSPLP.5.0.
Приведенные спецификации QA-семейства подсказывают один из
подходов к развитию семейства QA-систем, в основу которого положены
не сферы человеко-компьютерной деятельности, в которых приходится
решать задачи, а методы решения задач. Другими словами, одним
из направлений развития семейства QA-систем является разработка
QA-оболочек, каждая из которых способна обеспечить решение задач
определенным методом, а возможно, настроена на группу родственных
методов. Разумеется, каждую QA-оболочку придется настраивать
на специфику задач, для решения которых она будет выбрана. Один
из вариантов потенциальных QA-оболочек может быть связан с
оболочкой, позволяющей создавать экспертные системы.
3.1.2. Программно-картотечное управление На момент публикации монографии комплекс WIQA применялся
и применяется для исследований проблемы достижения успешности по
направлениям, основные из которых приведены на рисунке 3.1 на фоне
факторов, способствующих достижению успеха (табл. 1.2). На этом же
рисунке указано направление исследований, которому соответствует
содержание монографии. Наличие стрелки на направлении отражает тот
факт, что исследования активно расширяются.
178
Рис. 3.1. Направления исследований проблемы достижения успешности
Содержание и результаты выделенных на рисунке 3.1 основных
направлений взаимосвязаны, а также поддерживают и развивают друг
друга. Цель каждого из них – внести определенный вклад в повышение
степени успешности разработки семейства АС и тем самым в повышение
успешности проектной организации, создающей определенное
семейство.
В монографии представляется комплекс решений, нацеленный на
вклад в успешность за счет новаций в проектном управлении.
Более конкретно представляемые в монографии решения ее авторов
нацелены на повышение степени успешности разработок АС за счет
включения в систему средств управления персональной и коллективной
активностью проектировщиков дополнительных технологических
средств программно-картотечного управления теми ее составляющими,
за которыми стоит нормативно-творческая активность проектировщиков
SIS.
179
Специфику предлагаемых новаций определяет вопросно-ответное
(псевдокодовое) программирование проектных задач на языке LWIQA
и картотечное представление процессов их решений с использованием
механизмов Kanban и Scrum, причем согласованного оперативного
решения в рамках потоков работ. Новации связаны с гибким проектным
управлением, которое предлагается использовать дополнительно
к другим средствам управления, подтвердившим свою полезность
в проектной организации. Предлагаемые средства гибкого проектного
управления прошли проверку и материализованы в инструментальной
вопросно-ответной моделирующей среде WIQA.
Напомним, что в нормативах SEMAT-подхода, представленного
в пункте 1.4, «техника работы» определена как «адаптированная
к специфике исполняемого проекта совокупность методов
и инструментов, используемых командой проектировщиков в процессе
проектирования», причем адаптация подразумевает не только настройку
методов и инструментов, выбранных командой для выполнения проекта,
но и создание членами команды новых методов, оказавшихся
им необходимыми.
Как было отмечено в пункте 1.4, в документах SEMAT команде
проектировщиков предлагается начинать разработку очередного проекта
с адаптации к его специфике «ядра SEMAT», дополняя его, как пазлами,
тем, что способствует реализации проекта.
По глубокому убеждению авторов монографии, в число таких
«пазлов» следует включать методы и средства, обеспечивающие
экспериментирование с «техниками работы» проектировщиков, причем
экспериментирование, в котором используются аналогии с научным
экспериментом. Эта установка согласуется с тем, что одно
из перспективных направлений поиска новаций в программной
инженерии связывают с ее эмпирической природой, открывающей
180
возможность использования аналогий между работой проектировщиков
и ученых-экспериментаторов.
То, что «техники работы» имеют алгоритмическую природу, привело
авторов монографии к идее представлять их в виде программ
на концептуально-алгоритмическом языке, версией которого является
язык псевдокодового программирования LWIQA. Именно такое понимание
(и ожидание позитивных эффектов) вкладывается в «программное
управление техниками работы (методиками исполнения лучших
практик) в компьютеризованных средах».
Картотечная составляющая предлагаемого подхода расширяет
применение программного управления до согласованного решения
проектных задач коллективом проектировщиков в потоках проектных
работ. Для позиционирования предлагаемой версии гибкого проектного
управления на множестве других технологий управления эта версия
получила название программно-картотечного управления.
Вышеизложенное позволяет детализировать цель «внести вклад
в повышение степени успешности», включив в совокупность целевых
ориентиров следующие подчиненные цели:
1. Повысить естественность программного управления
проектными действиями (и тем самым снизить негативные проявления
человеческого фактора в проектировании АС) за счет кодирования
лучших практик, включенных в технологический «багаж» проектной
организации из полезных источников (часть из которых приведена
в первой главе монографии) в виде псевдокодовых программ
на концептуально-алгоритмическом языке LWIQA, исполнение
которых возложено на «интеллектуальные процессоры».
2. Повысить эффективность программного управления проектными
действиями за счет предоставления проектировщикам возможностей
экспериментирования с запрограммированными техниками работы
181
с использованием проектировщиками правил и механизмов научного
экспериментирования, включая экспериментирование в действиях по
программному управлению проектными процедурами, что способствует
предотвращению и обнаружению ошибок, в том числе за счет повторных
экспериментов.
3. Повысить эффективность программного управления за счет
картотечной визуализации потоков работ, состояния которой отражают
процесс проектирования в формах, позволяющих измерять
характеристики его выполнения и использовать их с полезными целями.
3.2. Архитектура программно-картотечного управления
Определимся с совокупностью средств ПКУ, учитывая, что она
является дополнением к традиционному управлению в разработках АС.
Будем принимать во внимание и то, что для реализации ПКУ
принято решение об использовании среды WIQA. Это решение
подсказывает необходимость отображения ПКУ, а вернее, его
структуры, процессов построения и использования ПКУ на
семантическую память этой среды.
Осуществление такого отображения начнем со структуры ПКУ,
представив ее в виде архитектурной модели. Обобщенная версия такой
модели с позиций управления оперативной работы проектировщика
приведена на рисунке 3.2.
182
Рис. 3.2. Архитектурная модель ПКУ
Перейдем к обобщенным спецификациям компонентов системы
ПКУ.
В верхней части рисунка 3.2 представлено схематичное изображение
потоков работ. Поток работ состоит из наборов разнотипных проектных
работ (обозначены как ZX), где каждой работе соответствует задача,
за которой, возможно, стоит подчиненный поток работ. На рисунке
выделен один из потоков работ, соответствующий задаче Zi. Задачи Zij
этого потока работ образуют связную совокупность, составляющие
которой должны решаться согласованно, например, в формах
183
управления данными. Реальность потоков работ такова, что некоторые
из работ допускают их параллельное выполнение.
Как уже было сказано, структура и процесс ПКУ отображается на
семантическую память WIQA. В процессе работы в среде WIQA уже
освоены способы отображения на QA-память организационной
структуры предприятия и набора задач. Этот процесс приводит к
формированию в памяти WIQA дерева коллектива проектировщиков,
включающего в себя иерархическую структуру предприятия и его
сотрудников, а также – к формированию древовидного представления
наборов проектных задач.
Для процесса проектирования принципиальное значение имеет не
только организационная структура, но и заполняющие эту структуру
сотрудники организации. В процессе разработки АС сотрудники
выполняют возложенные на них функции в рамках штатного расписания
согласно потенциальным ролям, за которыми стоят определенные
компетенции.
Достаточно полное представление о тех ролях, которые приходится
выполнять сотрудникам организаций, разрабатывающих АС и их
комплексы, дает система ролей методологии RUP, специфицирующая
исполнение 42 ролей, распределенных по группам, например:
менеджеры, аналитики, разработчики, тестировщики.
К группе менеджеров относятся такие роли, как менеджер проекта,
менеджер тестирования, инженер по процессу и другие.
К аналитикам относятся: аналитик бизнес-процессов, системный
аналитик и другие, деятельность которых связана с аналитикой.
В группу разработчиков входит значительное количество ролей,
таких как разработчик пользовательского интерфейса, разработчик
баз данных, интегратор. В реальном проектировании все эти роли чаще
всего объединяются в две: архитектор ПО и кодировщик.
184
К группе тестировщиков относятся роли, связанные
с тестированием разработанного ПО, – это такие роли, как аналитик
и разработчик тестов, а также непосредственно тестировщик,
выполняющий тестирование разработанного ПО. Кроме того, в RUP
имеются отдельные «вырожденные» роли, то есть такие, без которых
можно обойтись или которые нечасто требуются в проектах. Примером
может служить роль менеджера управления изменениями,
организующего процесс внесения в проект затребованных изменений.
Подсистема оргструктуры WIQA реализует инвариантную
интерактивную модель группы проектировщиков, которая
в корпоративной среде обеспечивает оперативную адаптацию,
рациональное использование и развитие индивидуального
и коллективного опыта. Эта подсистема позволяет установить связи
между сотрудниками и задачами проекта, а также между сотрудниками
и ролями, которые они выполняют в проектном процессе. Наборы ролей
могут быть адаптированы под конкретный коллектив и конкретный
проект.
Напомним, что роль – это потенциальная возможность
проектировщика решить определенный набор задач. Любая роль
актуализируется только после того, как перед проектировщиком,
исполняющим роль, будет поставлена хотя бы одна из ее задач.
После постановки задач в организационной структуре требуется
указать для каждой из них примерные сроки выполнения
и сформировать поручение о выполнении. Для этих целей служит
подсистема контроля поручений.
Выбор такой версии привязки решения задач ко времени обусловлен
тем, что предлагаемые средства ПКУ позиционируются и используются
как дополнительные к традиционным средствам управления, к которым,
например, относится комплекс MSProject, зарекомендовавший себя
185
в проектном управлении на стратегическом и тактическом уровнях.
На оперативном уровне требуются более гибкие механизмы управления,
использующие более простые средства привязки работ ко времени
и учету их исполнения. Именно поэтому при реализации ПКУ было
принято решение упростить связывание выполнения работ со временем
и осуществлять такую привязку по образцу действия систем контроля
поручений. Разработанная подсистема контроля поручений позволяет не
только связать поручения с исполняемыми задачами, но и открыть
зарегистрированные задачи и их характеристики во времени для
программного доступа.
Для осуществления привязки в системе контроля поручений
необходимо:
− провести ассоциацию между сотрудником или группой
сотрудников и задачей совместно со связанной с ней ролью;
− назначить ориентировочную дату выполнения задачи;
− задать значения набору дополнительных атрибутов поручения,
таких как ответственные лица, контролеры, приоритет задачи;
− проинформировать сотрудника о новом поручении.
При выдаче поручений возникает необходимость определения
набора задач для их выполнения в определенный период времени.
На рисунке 3.2 для этого предусмотрены работы по отбору задач из тех,
которые уже назначены проектировщиком для оперативного исполнения
в установленные сроки. Такой отбор в разработанных средствах связан
с использованием в распараллеливании работ средств Kanban- и Scrum-
управления.
В средствах, поддерживающих такие виды управления,
потенциально доступный набор задач для решения называют бэклогом.
Подсистема контроля поручений включает в себя компонент,
который осуществляет отслеживание установления связей между
186
задачами и сотрудниками в организационной структуре и при
обнаружении новых связей формирует соответствующие им поручения.
Этот компонент также отвечает за установку связи с подсистемой
контроля. В основе подсистемы Kanban лежит визуализация хода работ
(в соответствии с Kanban-правилами) на интерактивной доске, которую
можно представить в виде таблицы, столбцам которой соответствуют
шаги выполнения работы над проектами, а строкам – исполнители задач.
В ячейках таблицы размещаются карточки, за каждой из которых стоит
решение определенной задачи на соответствующем карточке шаге
процесса проектных работ. Для регистрации на карточках состояний
работ используется цвет. В предлагаемой версии управления структура
доски Kanban подобна схеме, приведенной на рисунке 3.3.
Рис. 3.3. Доска Kanban
Программная реализация Kanban позволяет визуализировать доску,
а также дает возможность проектировщикам просматривать
ассоциированные с ними проектные задачи и переходить к их
выполнению через графический интерфейс интерактивной доски.
187
В предлагаемой версии ПКУ проектировщикам дополнительно
к Kanban-механизмам предоставляются функциональности подсистемы
Scrum, обобщенная схема которой соответствует Scrum-схеме,
приведенной в первой главе монографии. Проектировщики могут
использовать средства Kanban и Scrum либо альтернативно, либо
дополнительно.
В процессе оперативного выполнения потока работ
проектировщикам приходится распараллеливать работы над задачами,
если это допускает логика времени потоков, а также использовать
псевдопараллельное решение задач, если в этом появляется
необходимость. Для возможных распараллеливаний в ПКУ включена
подсистема прерываний, построенная с использованием аналогий
с реализацией мультизадачности в компьютерах. В реализации
прерываний центрального процессора используются такие механизмы,
как приоритетизация задач, очередь прерываний, запрет прерывания.
В той или иной степени эти механизмы полезно реализовать
и в управлении активностью I-процессора (то есть человека).
За это отвечает подсистема управления распараллеливанием,
изображенная на рисунке 3.4.
Эта подсистема обеспечивает следующую функциональность:
− определение очередности задач;
− прерывание задачи и помещение ее в очередь с рассчитанным
или заданным приоритетом;
− сохранение оперативного контекста прерванной задачи;
− переход к задаче, хранящейся в очереди;
− восстановление оперативного контекста задачи в том случае,
если она была прервана.
188
Рис. 3.4. Псевдопараллельное выполнение работ человеком
С помощью этой функциональности подсистема управления
распараллеливанием реализует рациональный механизм
псевдопараллельного выполнения задач I-процессором (человеком).
3.3. Формализация отображений ПКУ на QA-память
3.3.1. Отображение проекта и задач на память WIQA Перейдем к формализации отображений на вопросно-ответную
память основных составляющих ПКУ, представленных на рисунке 3.5.
В отображениях, как и для QA-памяти, будем использовать нотации
расширенных БНФ.
189
Рис. 3.5. Отображение среды ПКУ на память WIQA
В среде WIQA данные, с которыми работает среда, подразделяются
на два основных типа: данные, хранимые в реляционной БД на сервере
WIQA, и данные, хранимые в виде файлов на локальной файловой
системе. Данные WIQA = БД, файлы.
Данные, хранимые в файлах на локальной файловой системе, могут
быть произвольными, и их формат зависит только от решаемой задачи.
В свою очередь, данные, которые хранятся в БД, подразделяются на два
основных типа: QA-память WIQA и табличные данные,
190
не укладывающиеся в формат вопросно-ответных структур. Таким
образом, БД = QA-память, табличные данные.
В QA-памяти применительно к системе ПКУ хранятся данные
проекта, проектных работ, поручения, Kanban, Scrum, псевдокодовые
программы. В виде табличных данных представляется организационная
структура.
Формализацию отображений начнем с QA-модели и проекта.
Отображение проектов и задач на семантическую память WIQA было
освоено и успешно применено в ряде предшествующих исследований
проблемы достижения успешности, которые на рисунке 3.1 отмечены
как завершенные. Основным из этих исследований является
«концептуальное проектирование АС».
В памяти WIQA проект П содержит основную задачу проекта ZP.
Основная задача проекта, в свою очередь, является задачей, содержащей
поток работ проекта. П = ZP;
ZP = (Z | "↓", {Поток работ}).
При этом поток работ состоит из иерархически связанного набора
задач ZW, каждая задача Z которого представлена в виде наборов
QA-объектов, формулирующих задачу.
Проект WIQA предполагает следующие совокупности задач:
− совокупность задач ZS = {Zmi} предметной области АС, которые
в проектируемой АС будут решать ее пользователи;
− совокупность нормативных задач ZT = {Zni} технологии, в рамках
которой коллектив проектировщиков К({Dv}) создает АС;
− совокупность задач адаптации ZА = {ZАq}, решаемых
проектировщиками для настройки задач типа ZT, инвариантных
191
к проблемной области АС, в их использовании при решении задач типа
ZS;
− совокупность задач управления ZW = {Wm({Zmi})}∪{Wn({Zni})}
и ZC = {ZWr}, решение которых обслуживает работу с задачами в потоках
работ, а также согласованное управление в группах потоков работ.
Таким образом, Поток работ = ZW; ZW = {{ZS}, {ZT}, {ZА}, {ZW}}; ZS = Z | (Z, "↓", {Z}); ZT = Z | (Z, "↓", {Z}); ZA = Z | (Z, "↓", {Z}); ZW = Z | (Z, "↓", {Z}); Z = {QA-объект}.
3.3.2. Отображение организационной структуры Одной из важнейших составляющих операционной обстановки,
отображаемой на QA-память, является та часть коллектива K проектной
организации, которая вовлечена в процессы проектирования семейства
АС, то есть коллектив проектировщиков K*.
Для представления коллектива принято использовать
организационные диаграммы, визуально раскрывающие структуру
организации, чаще всего в названиях её структурных подразделений. В
практике построения и использования организационных структур
сложился определённый набор их базовых типов, среди которых
наибольшее распространение получили следующие типы оргструктур:
− иерархические (бюрократические) типы структур;
− линейная организационная структура;
− линейно-штабная организационная структура;
− дивизионная (дивизиональная) структура управления;
− бригадная (кросс-функциональная) структура;
− проектная структура управления;
192
− матричная (программно-целевая) структура управления;
− многомерная организационная структура.
Для организаций, особеннло проектных, типично становление их
оргструктуры в процессе профессиональной деятельности, причём
становление может быть обусловлено спецификой продукции,
развитием портфеля заказов, стремлением повысить профессионализм
успешность. В таком становлении, особенно в крупных организациях,
типовые оргструктуры комбинируются и смешиваются, в результате
чего формируется специфическая для предприятия его оргструктура.
Для создания и модернизации оргструктур проектных организаций в
состав инструментальной среды WIQA включён специализированный
плагин «Оргструктура», который позволяет строить и модифицировать
любую подходящую оргструктуру, регистрируя её форму и содержание
в определённой области базы данных инструментария. Концептуальная
модель этой области обобщённо (для демонстрации разнообразия
отношений и атрибутов) приведена на рисунке 3.6.
Для реализации концептуальной схемы области используются
средства СУБД MS SQL, а для доступа ̶ система интерфейсов.
Структура и содержание концептуальной модели выбраны так, чтобы
информацию об оргструктуре можно было использовать для различных
целей, например, визуализировать оргструктуру или создавать
её «твёрдые» копии, что образно показано в левом нижнем угле рисунка.
193
Рис. 3.6. Концептуальные модели оргструктуры
В правом нижнем угле рисунка приведено отображение
оргструктуры на QA-память, причём в виде модели типа бригадной
структуры, ориентированной на потоки работ. Другими словами,
коллектив проектировщиков К* представляется совокупностью групп,
каждвая из которых ответственна за согласованное решение групп задач,
которые ей назначаются. Именно для указания на это на рисунке «дерево
коллектива» объединено с деревом задач проекта.
В инструментарии WIQA за такое отображение MS SQL-структур
на QA-память отвечает программный агент, который отслеживает любые
194
изменения в оргструктуре с учётом назначений задач. Отметим, что
отображение K* создаётся как модель, более того, как QA-модель,
предназначенная для определённых целей. В принципе, такую модель
можно построить в виде, который позволит зарегистрировать в
QA-модели всю информацию из MS SQL-структур Но с QA-памятью
связаны механизмы дополнительной атрибутики, которые позволяют
ввести в QA-модель коллектива любые единицы информации из MS
SQL-структур, если в этом появится необходимость. Напомним, что
составляющие любой QA-модели, а значит и QA-модели коллектива,
программно доступны.
Учитывая вышесказанное, представим коллектив K* следующими
правилами грамматики GQA: K* = Организация, D*; D* = {Сотрудник}; Сотрудник = D; O = {GS | (GS, "↓", GS)}.
Каждая группа сотрудников состоит из подразделения
G и ассоциированных с ней сотрудников D. GS = G, "←", {D}.
Каждая группа определена как набор ее атрибутов, включающих код
группы Gc, состояние ее активности Gs, наименование
Gn, руководителя Gd. G = Gc, Gs, Gn, Gd.
Набор сотрудников D*представляет собой их линейный список,
в котором каждому сотруднику Dсоответствует набор характеризующих
его основных атрибутов Da: Фамилия Ds; Имя, Dn; Отчество Dp; Дата
рождения Db; Табельный номер Dnum; Руководитель Dc.
Кроме основных, каждый сотрудник имеет набор атрибутов
Dsg, обеспечивающих его доступ к системе ̶ логин и пароль.
195
Для каждого сотрудника формируется набор его контактных данных
(контакты), содержащий телефоны, факсы, e-mail, www, icq.
Также для каждого сотрудника формируется перечень его
должностей (должности) – список групп, в которых он состоит, а также
набор задач Dnz, выполняя каждую из которых, он играет определенную
роль Dr в проектном процессе. D = Da, Dsg, контакты, должности; Da = Ds, Dn, Dp, Db, Dnum, Dc; Dsg = логин, пароль; Dcd = телефоны, факсы, e-mail, www, icq.
Перечень должностей сотрудника выбирается из общего перечня
должностей Pd*. Должность = Pd; Pd* = {Pd}; Dpd = {Pd}.
В оргструктуре больших проектных организаций представлено более
300 должностей Pd, каждая из которых представлена ее кодом
и наименованием. Pd = код, наименование.
Кроме должностей, атрибутом каждого проектировщика является
набор его компетенций CD, характеризующих умение проектировщика
выполнять тот или иной класс проектных работ. Каждая проектная
работа при этом характеризуется набором компетенций, которыми
должен обладать проектировщик для выполнения данной работы. CD = D, {Компетенция}.
В процессе выполнения проектной работы проектировщик (или их
группа) в проектном процессе играет определенную роль, которая
образуется из набора компетенций проектной работы. Таким образом,
проектировщик или группа проектировщиков в процессе работы играют
набор определенных ролей Rd. Роли в WIQA представлены в виде
справочника ролей R*.
196
Rd = {R}.
Каждой роли соответствует определенный набор компетенций, также
она представлена ее кодом Rc и наименованием Rn. Роль = R;
R = {Компетенция}, Rc, Rn.
3.3.3. Назначение задач В методологии RUP существуют такие основные проектные
процессы, как:
− моделирование бизнес-процессов;
− управление требованиями;
− анализ и проектирование;
− реализация;
− тестирование;
− развертывание.
Кроме основных проектных процессов существует ряд
дополнительных:
− конфигурационное управление и управление изменениями;
− управление проектом;
− управление средой.
Каждый из этих процессов образует определенный класс задач,
решая которые проектировщики играют ту или иную роль в проектном
процессе. Перед руководителем проекта встает задача распределения
проектных работ между участниками проектного процесса. Эта задача
заключается в подборе сотрудников и групп, имеющих возможность
сыграть определенную роль в процессе.
Перед началом выполнения проектной работы в организации
осуществляется анализ проекта с целью определения набора потоков
проектных работ, результатом выполнения которых становится
197
реализованный проект. В процессе этого анализа каждый поток работ
представляется в виде набора проектных задач Zp0...Zpn, каждая
из которых относится к тому или иному проектному процессу.
Процесс проектирования в рамках методологии RUP разбивается
на четыре фазы:
1) разработка технического задания;
2) разработка технического проекта;
3) создание системы;
4) внедрение системы.
Эти фазы разнесены по времени, и в каждой из них существуют
определенные, присущие только ей задачи в каждом из проектных
процессов RUP. Причем наборы этих задач зависят от результатов
решения проектных задач предыдущей фазы.
Кроме того, методология RUP является итеративной. Следовательно,
на каждой итерации происходит уточнение требований, предъявляемых
к проекту, и соответственно этому уточнению перед коллективом
организации неизбежно возникают новые задачи. Эти задачи могут
относиться к любому из проектных процессов RUP и к любой фазе
процесса проектирования.
Из этого следует, что в самом начале работы над проектом
невозможно полностью сформировать все потоки работ проектного
процесса и каждый из этих потоков может пополняться новыми
работами, необходимыми для решения возникших новых задач. Поэтому
можно говорить о том, что набор потоков работ проекта является
динамической структурой, которая непрерывно изменяется во время
проектного процесса.
Для осуществления поддержки динамического управления набором
потоков работ проекта в комплекс средств ПКУ включена подсистема
назначения задач, схематически изображенная на рисунке 3.8.
198
Рис. 3.8. Назначение задач
Из рисунка видно, что подсистема назначения является
ответственной за формирование связи между потоками работ и
оргструктурой.
Проект в среде WIQA состоит из набора проектных работ,
оформленных в виде задач. Набор задач проекта, каждая из которых
выполняется определенным участником проектного процесса,
обеспечивает формирование рабочей силы (workforce) организации
(схематично представлена на рисунке 3.9).
199
Рис. 3.9. Рабочая сила
Каждому сотруднику приписывается определенный набор задач,
выполняя каждую из которых сотрудник играет ту или иную роль
в организации. Рабочая сила = K*, Набор назначений; Набор назначений = {Назначение}.
Как и отдельные сотрудники, задачи, особенно состоящие
из множества подзадач, могут быть назначены группе сотрудников G.
Под назначением здесь подразумевается сотрудник или группа
и ассоциированный с ними набор задач Z*d . Назначение = (D | G), Z*d.
В процессе проектной деятельности неизбежно возникают новые
проектные задачи, которые необходимо включить в проект. Затем
требуется связать с их выполнением определенных сотрудников,
поэтому можно говорить о том, что рабочая сила проекта является
динамической структурой, на которой определена операция включения
в нее нового назначения.
Включение новой задачи Zn в набор назначений: Набор назначений = NP; NP = NP, "включение", Zn.
200
После выполнения операции «включение»: NP = NP, Zn.
После того как новая задача возникла в проекте, появляется
необходимость поручить ее выполнение участнику или группе
участников. При таком назначении происходит выбор соответствующей
роли проектировщика, поэтому можно говорить об образовании новой
пары <Задача, Роль> и, соответственно, нового назначения: Назначение = D | G, Zn.
3.3.4. Отображение подсистемы контроля исполнения поручений
Все современные проектные организации не обходятся без
исполнения подчиненными поручений руководства. Руководство,
формируя план работ над проектом, осуществляет не только назначение
сотрудников, которые будут заниматься их исполнением, а также
устанавливает сроки выполнения той или иной проектной работы. Кроме
планирования, перед руководителями проектной деятельности стоит
задача донесения своих планов до исполнителей проектной работы,
а также контроль за ее исполнением. Для достижения этих целей в среде
WIQA в комплекс средств ПКУ была включена система контроля
исполнения поручений. Она позволяет своевременно и качественно
выполнять поручения, содержащиеся в документах, получать
аналитическую информацию, необходимую для оценки деятельности
подразделений и отдельных исполнителей, помогает оптимизировать
работу аппарата управления, дисциплинирует работников, повышает
ответственность исполнителей за порученное дело. Подсистема
контроля исполнения поручений позволяет представить план проектных
работ в виде набора поручений. На рисунке 3.10 представлен жизненный
цикл поручения в работе над проектом.
201
Рис. 3.10. Жизненный цикл поручения
Каждое поручение является своего рода заданием, которое
руководитель проектной работы дает сотруднику или группе
сотрудников. Таким образом, поручение характеризуется следующими
атрибутами:
− автор поручения;
− исполнитель поручения;
− задание.
202
В контексте разрабатываемых средств ПКУ задание является
проектной работой, отображаемой на память WIQA в виде задачи.
Как было указано в п. 3.3.3, пара <Исполнитель поручения, задание>
представляется в виде назначения.
Из схемы (рис. 3.10) следует, что кроме этих атрибутов каждое
поручение обладает статусом, который может иметь одно из трех
значений:
− на выполнении;
− выполнено;
− закрыто.
Этот статус в процессе работы над поручением может неоднократно
меняться. Из этой схемы также следует, что контролировать исполнение
поручения может не только его автор, но и другие лица, являющиеся его
помощниками. Таким образом, поручение дополняется еще одним
атрибутом, характеризующим лиц, контролирующих исполнение:
− контролеры.
В зависимости от задач, выполняемых в процессе проектирования,
в том случае, если проектные задачи являются типовыми, поручение
также может характеризоваться его типом. Введем и эту характеристику:
− тип поручения.
По результатам исполнения поручения лицом резолюции, которым
может быть как автор поручения, так и его помощник, выставляется
оценка за выполненное поручение, которая может говорить как об
успешности его выполнения – в этом случае оно приобретает статус
«закрыто», отправляется в архив и снимается с контроля, так и о
потребности в доработке. При этом дата исполнения поручения
изменяется и появляется новая – дата переноса. Таким образом,
возникают еще четыре атрибута поручения:
203
− лицо резолюции;
− снято с контроля;
− дата переноса;
− оценка.
В некоторых случаях, таких как, к примеру, поручение сразу
нескольких работ одному сотруднику, поручения должны
характеризоваться приоритетом их выполнения, что приводит
к появлению у поручения еще одного атрибута: приоритет.
Таким образом, можно сказать, что подсистема контроля поручений
дополняет собой процесс назначения задач, при этом характеризуется
набором атрибутов, таких как причина, содержание, автор,
руководитель, тип, приоритет, контролеры, снято (флаг снятия
поручения с контроля), дата исполнения, дата переноса, оценка и статус
поручения. Таким образом, происходит формирование поручения TC,
представляемого следующим образом: Поручение = TC TC = Назначение, Атрибуты; Атрибуты = причина, автор, руководитель, тип,
приоритет, контролеры, снято, дата исполнения, дата переноса, лицо резолюции, оценка, статус;
статус = на выполнении | выполнено | закрыто.
Поручения отображаются на память WIQA в виде таблицы
поручений TC*: TC* = {Поручение}.
При этом TC* в QA-память WIQA отображается как QA-объект
TC*qa, состоящий из одного вопроса «Поручения» QTC, включающего
вопросы назначения Qназн (вопрос cубъекта назначения QDG и вопрос
объекта назначения QZ) и набор вопросов «Атрибуты» QАтр, каждый из
которых соответствует определенному атрибуту поручения:
204
TC*qa = QTC, "↓", Qназн, QАтр; Qназн = QDG, QZ; QАтр = Qпричина, Qавтор, Qруководитель,
Qтип, Qприоритет, Qконтролеры, Qснято, Qдата_исполнения, Qдата_переноса, Qоценка, Qлицо_резолюции, Qстатус.
Сами поручения при этом отображаются в виде ответов на вопросы
назначения и атрибутов. Таким образом, Поручение в QA-памяти WIQA
раскрывается как ПоручениеQA, представляющее собой набор ответов на
эти вопросы. ПоручениеQA = (QDG, "←",ADG),(QZ, "←",AZ),
({QАтр},"←", {AАтр}).
3.4. Организация процесса управления
3.4.1. Отбор задач для оперативного выполнения В первой главе, представляющей обобщенное введение
в Kanban- и Scrum-технологии, было отмечено, что для каждой из них
должен быть сформирован пакет задач, который в данных технологиях
принято обозначать словом Бэклог (Backlog). В этих технологиях
понятия бэклога имеют как общие черты, так и некоторые отличия.
Количество задач бэклога в обеих технологиях является ограниченным,
и этот набор задач выбирается в соответствии с расставленными
приоритетами.
В технологии Kanban размер каждой очереди ограничен. Технология
Scrum не накладывает принципиальных ограничений на общий объем
бэклога и на объем работ каждого отдельного проектировщика, но в то
же время этот объем должен быть таким, который Scrum-команда
в состоянии выполнить за заданный отрезок времени.
Таким образом, основным критерием для отбора задач в бэклог
является приоритет. Каждый поток работ содержит определенный набор
205
задач, результаты выполнения которых требуется получить в первую
очередь, то есть приоритет этих задач является наибольшим. Здесь также
следует учитывать и то, что для выполнения определенных задач
требуется решить и другие, результаты выполнения которых
необходимы. Таким образом, в бэклог Bl попадают задачи: Bl = ({Pf, Zmax}, {BZnecc}, {Ptime, Ztime},
{BZTnecc}}); BZnecc = {Pf+n+i, Znecc, BZnecc}; BZTnecc = {Ptime+m+j, Ztime, BZTnecc}.
Здесь Pf – приоритет задач Zmax, выполнение которых является
необходимым в течение этапа разработки, для которого формируется
бэклог. В процесс выполнения этих задач вовлекаются результаты
других, из которых отбирается блок еще не выполненных задач Znecc,
каждая из которых тоже может иметь задачи, от выполнения которых
она зависит. При этом их приоритет Pf+n+i должен быть больше
приоритета задач Zmax, чтобы эти задачи оказались выполнены ранее.
Кроме этих задач, бэклог проекта наполняется задачами Ztime,
которые соответствуют определенному критерию, зависимому от
особенностей проекта. Эти задачи образуют блок задач BZTnecc. Таким
критерием может быть, например, назначенный срок выполнения задач
tmax с помощью подсистемы контроля исполнения поручений, который
не должен превышать определенного значения. Приоритет этих задач
ниже приоритета задач «первой необходимости» Zmax. В связи со
спецификой потока работ при решении каждой из задач можно
использовать результаты выполнения других задач Ztnecc. Приоритеты
этих задач Ptime+m+j также должны быть выше приоритетов задач,
являющихся зависимыми, с целью их более раннего выполнения.
Важным является то, чтобы общий объем работ бэклога не превышал
ограничения, устанавливаемого методологией проектирования.
206
Следовательно, одним из верных вариантов распределения является
линейный:
− наибольший приоритет Pf+n имеют задачи Znecc;
− после их выполнения должны выполняться задачи Zmax;
− далее идет выполнение задач Ztnecc;
− и в последнюю очередь выполняются задачи Ztime.
Поэтому справедливым является следующее неравенство:
Pf+n > Pf > Ptime+m > Ptime .
Такой вариант распределения представлен на рисунке 3.11.
Рис. 3.11. Линейный вариант распределения задач в бэклоге
На рисунке 3.11 задачи Zmax выделены жирным контуром, а задачи
Ztime – двойным контуром. Как видно из этого рисунка, сначала должны
выполняться все задачи Znecc и только после этого начинается процесс
выполнения задач Zmax.
Другим вариантом распределения приоритетов является блочный,
при котором формируются блоки Zb, состоящие из задач Zmax
и зависимых от них задач Znecc, а также блоки Zbt, состоящие из задач
Ztime и зависимых от них задач Znecc: Bl = ({Zb}, {Zbt}); Zb = (Pb, (Pf, Zmax, BZneccb)); Zbt = (Pbt, (Ptime, Ztime, BZTneccb)).
207
Блоки задач BZneccb и BZTneccb содержат задачи, от выполнения
которых зависит выполнение задач PZmax и PZtime соответственно. Эти
блоки формируются аналогично блокам задач Zb и Zbt и содержат свои
подблоки задач, от которых зависит их выполнение. BZneccb = (Pneccb, (Pf+n+i, Zneccb, BZneccb)); BZTneccb = (PTneccb, (Pf+n+i, Zneccb, BZneccb)).
Блочный вариант распределения приоритетов задач бэклога показан
на рисунке 3.12.
Рис. 3.12. Блочный вариант распределения задач в бэклоге
У каждого блока в этом случае формируется свой приоритет Pb / Pbt,
а приоритеты задач для каждого k-го блока соответствуют следующим
условиям:
Pbk > Pf > Pneccb1..Pneccbn > Pbk+1;
Pbtk > Ptime > PTneccb1..PTneccbn > Pbtk+1.
Таким образом, отбор этих задач по любому из параметров несложно
запрограммировать по содержимому таблиц контроля поручений.
208
Рис. 3.13. Пример алгоритма отбора задач
В процессе формирования бэклога происходит построение
распределенного в соответствии с их приоритетами списка задач,
подлежащих выполнению в течение заданного времени. В качестве
примера на рисунке 3.13 приведен алгоритм отбора задач
с распределением их по приоритетам по линейной схеме. Условие
отбора задач Ztime – время выполнения не более одного месяца.
209
Комплекс средств ПКУ предполагает программирование алгоритма
формирования бэклога на языке псевдокодового программирования
LWIQA.
3.4.2. Отображение Kanban-процессов в ПКУ Обзор Kanban-технологии представлен в п. 1.4.2. Все участники
проектного процесса видят доску Kanban и содержащиеся на ней
карточки. При этом каждый участник может найти представляющие его
работу карточки на текущем шаге проектного процесса с набором задач,
которые предстоит ему выполнять параллельно на данном этапе
проектного процесса.
Система Kanban применяется в том числе и для разработки
программных продуктов. Поскольку в среде WIQA осуществляется
коллективное проектирование автоматизированных систем, в данном
процессе оно также оказывается применимым. В контексте ПКУ
рассматривается реализация средств визуализации доски Kanban в среде
WIQA.
Подсистема Kanban в системе ПКУ визуализирует для группы
сотрудников G доску Kanban в виде таблицы KT. Доска делится на
набор колонок – шагов, соответствующих этапам выполнения
проектного процесса. KT = G, Колонки.
Шаги представляют собой этапы проектного процесса, которые
доска Kanban отображает в виде столбцов. Каждый шаг содержит в себе
карточки, соответствующие задачам члена группы GD, которым может
быть как подгруппа, так и сотрудник. Колонки = {Колонка}; Колонка = I, {GD}.
210
I в данном случае характеризует индекс колонки, соответствующей
шагу выполнения проектной работы. Таким образом формируются
ячейки таблицы, расположенные на доске Kanban. На рисунке 3.13
представлена схема доски Kanban в версии, реализованной в средствах
ПКУ.
Рис. 3.13. Доска Kanban в ПКУ
Каждая ячейка содержит набор карточек, соответствующих
проектным задачам, выполняемым членом группы на определенном
этапе работы над проектом. Таким образом, член проектной группы
видит набор задач, который ему будет необходимо выполнить
параллельно в течение времени шага проектного процесса. GD = {Карточка};
Карточка = Cr.
Карточка Kanban характеризуется определенным набором
атрибутов. Карточка Cr является визуальным представлением задачи,
поэтому одним из важнейших ее атрибутов является ссылка
Zref на задачу, которую она визуализирует. Для задачи карточка
211
описывает ее имя Desc. Также карточка характеризуется цветом
Cc и может быть отмечена флажком Cr. Cr = Zref, Zdesc, Zc, Cf.
Флажок может быть установлен или снят: Cf = Установлен | Снят.
Каждая карточка может быть раскрыта, то есть представлена
в увеличенном масштабе, отображая детальную информацию о задаче. Раскрытая карточка = CrO;
CrO = Cr, "раскрытие".
Раскрытая карточка увеличивается в размере и отображает ряд
дополнительной информации о задаче. Карточка имеет две стороны –
лицевую CrF и обратную CrB, а также ряд элементов управления OCC,
позволяющих перевернуть карточку на другую сторону, перейти
к выполнению задачи и отметить задачу как выполненную. Лицевая
сторона карточки отображает ее детальное описание DescD.
Рис. 3.14. Карточки Kanban в ПКУ
На рисунке 3.14 схематично изображены карточки Kanban.
Рисунок 3.14а содержит схематичное изображение карточки Cr. На
рисунке 3.14б представлена лицевая сторона карточки CrF,
а 3.14в показывает схему обратной стороны карточки CrB.
212
CrO = (CrF | CrB), Cf, OCC;
CrF = DescD;
CrB = Desc, Автор, Дата исполнения;
OCC = Перевернуть, К задаче, Выполнена.
С помощью этих элементов управления сотрудник имеет
возможность перевернуть карточку, переключив изображение с лицевой
стороны на обратную, или наоборот, перейти к выполнению задачи,
а также отметить ее выполнение.
Доска Kanban отображается на память WIQA в виде двух таблиц:
таблицы задач TZ*, содержащей сведения о задаче, отображаемые на
карточке, и таблицы ассоциаций TA*, устанавливающей соответствие
между карточкой и ее положением на доске Kanban.
В таблице задач каждая строка представлена ее идентификатором
ZDescId и набором атрибутов ZDesc. TZ* = {ZDescId, Zdesc}.
Идентификатор ZDescId в данном случае является числовым кодом,
соответствующим описанию задачи для организации ссылки на нее из
таблицы ассоциаций. Zdesc = Поручение, Desc, DescD, Zref.
Поручение – это ссылка на поручение из подсистемы контроля
поручений в виде натурального числа.
Desc – краткое текстовое описание задачи, DescD – детальное
текстовое описание. Desc = Строка;
DescD = Строка.
Zref является ссылкой на задачу Z, которую представляет карточка.
Перейдем к таблице ассоциаций, отвечающей за размещение
карточек на доске. Таблица ассоциаций представлена набором строк As,
содержащих ссылку на описание задачи ZDescId, номер колонки таблицы,
213
состояние задачи Asst, группу G, которой назначена задача и отметка
о выполнении Asmk. TA* = {As};
As = ZDescId, Колонка, Asst, G, Asmk.
Описание задачи ZDescId в данном случае представляет собой ссылку
в виде идентификатора на описание задачи из таблицы TZ*.
Шаг соответствует номеру шага проектного процесса, иными
словами, номеру колонки в таблице доски Kanban, в которой будет
располагаться карточка.
Состояние характеризует выполнение задачи и влияет на цвет
карточки в отображении. Asst = Выполняется | Выполнено.
G представляет собой ссылку на группу, которой назначено
выполнение задачи. Эта ссылка представляется в виде числового кода.
G может быть как группой проектировщиков, так и одним
проектировщиком. G = Gref.
Отметка позволяет отмечать карточки для выполнения групповых
операций над ними. Примером такой операции служит формирование
отчета по нескольким задачам. Asmk = TRUE | FALSE;
Теперь рассмотрим отображение этих таблиц на QA-память WIQA.
В ней для хранения таблиц формируется QA-объект TKanbanQA,
представляющий собой вопрос QKanban «БД Kanban», содержащий в себе
подчиненные QA-объекты обеих таблиц: TKanbanQA = QKanban, "↓", (TZ*qa, TA*qa).
При этом TZ* в QA-памяти WIQA отображается как QA-объект
TZ*qa, состоящий из одного вопроса «Задачи» QTZ, включающего в себя
ряд вопросов, соответствующих атрибутам описания задачи:
214
TZ*qa= QTZ, "↓", QАтрZ;
QАтрZ = QZDescId, QПоручение, QDesc, QDescD,
QZref.
Сами описания задач при этом отображаются в виде ответов
на вопросы атрибутов описания задачи. Таким образом, описание задачи
в QA-памяти WIQA раскрывается как ОписаниеZQA, представляющее
собой набор ответов на эти вопросы. ОписаниеZQA = ({QАтрZ},"←", {AАтрZ});
Рассмотрим отображение TA* на QA-память WIQA.
TA* в QA-памяти WIQA отображается как QA-объект TA*qa,
состоящий из одного вопроса «Ассоциации» QTA, включающего в себя
ряд вопросов, соответствующих атрибутам ассоциации: TA*qa= QTA, "↓", QАтрA;
QАтрA = QZDescId, QКолонка, QAsst, QG, QAsmk.
Ассоциации при этом отображаются в виде ответов на вопросы
атрибутов ассоциации аналогично тому, как это организовано для
описаний задач. Таким образом ассоциация в QA-памяти WIQA
раскрывается как АссоциацияQA, представляющая собой набор ответов
на эти вопросы. АссоциацияQA = ({QАтрZ},"←", {AАтрZ}).
3.4.3. Отображение Scrum-процессов в ПКУ Scrum представляет собой итеративный, инкрементальный процесс
для разработки любого продукта или управления любой работой.
Он производит потенциально готовый продукт после каждой итерации.
Для формирования набора задач итерации и команды, выполняющей
работы над этими задачами, учитываются особенности выполнения
командами предыдущих итераций, что приводит к возможности более
рационального формирования новой итерации.
215
Итерация в Scrum именуется спринтом (Sprint). Длительность
такого спринта фиксированна. Для его формирования производится
выбор задач из общего объема проектных задач, подлежащих
выполнению Scrum-командой в заданное время для выполнения. Этот
общий объем задач проекта в терминологии Scrum называется бэклог
проекта (ProjectBacklog). Набор задач для выполнения в течение
времени спринта называется бэклогом спринта (SprintBacklog).
Итеративный процесс работы Sproc по методологии Scrum состоит
из следующих основных частей:
− формирование бэклога спринта (SBf);
− выполнение спринта (SBw);
− расчет метрик спринта и их анализ (SBa). Sproc = {SBf, SBw, SBa}.
SBf заключается в формировании спринта SS, представляющего
собой бэклог спринта SB и команду, выполняющую спринт ST.
Для формирования бэклога спринта используются метрики,
полученные в результате анализа выполнения предыдущих спринтов.
Таким образом, можно говорить о возникновении обратной связи,
соединяющей результаты метрик с новым бэклогом спринта: SS = SB, ST.
Бэклог спринта, в свою очередь, является набором задач, каждая
из которых имеет оценку трудозатратности Zv, распределенную
по приоритетам. Каким именно образом осуществляется формирование
бэклога спринта, описано в п. 3.3.1: SB = {SBa}, {Z, Zv}.
Кроме бэклога спринта на формирование команды также
воздействует обратная связь. Например, в процессе выполнения
спринтов может выясниться, что проектировщики работают
недостаточно эффективно из-за выполнения непривычных им ролей.
216
В этом случае для рационализации проектного процесса может
потребоваться изменение состава команд, например, путем
осуществления частичного обмена сотрудниками в разных командах. ST = {{SBa}, ST}.
В связи с этим для формирования команды ST также должны
учитываться метрики, полученные в результате выполнения
предыдущих спринтов. На рисунке 3.16 схематически показаны
обратные связи в Scrum-процессе.
Рис. 3.16. Обратная связь в Scrum-процессе
Команда по правилам Scrum не должна содержать более
9 участников (рекомендуется 7 плюс-минус 2 участника). Меньшие
команды более продуктивны хотя бы по той причине, что между
участниками возникает меньше путей коммуникации.
Следующая формула позволяет рассчитать количество
коммуникационных путей в команде, в которой все участники
равноправны:
CP = [N * (N - 1) / 2],
217
где CP – количество путей коммуникации, N – количество участников
команды.
В процессе планирования спринта происходит оценка трудозатрат на
выполнение каждой задачи. Для такой оценки команда может
воспользоваться техникой, получившей название покер планирования
(PlanningPoker). Суть ее заключается в том, что каждый член команды
имеет набор карточек, пронумерованных числами ряда Фибоначчи
(в Scrum используются значения 1, 2, 3, 5, 8, 13, 21, 34, 55).
Использование этих чисел облегчает процесс оценки трудозатратности
задачи, так как с каждым следующим числом ее значение резко
возрастает. Каждый проектировщик при этом оценивает трудозатраты
на выполнение задачи одним из этих чисел и представляет
соответствующую карточку. Проектировщики, показавшие очень
низкую и очень высокую оценку задачи, объясняют свое решение.
После оценки пользователем происходит вычисление
трудозатратности задачи в единицах очков (StoryPoints) с учетом
коэффициентов:
Zv = X (1 + (Diff + DF + EF + FMC)),
где X – оценочная трудозатратность задачи, Diff – сложность требований
и используемых технологий. Она определяется в соответствии
со следующей таблицей. Таблица 3.1
Сложность требований и технологий
Сложность Коэффициент Простая (Simple) 0 Усложненная (Slightly Complicated) 0.1 Сложная (Complicated) 0.2 Очень сложная (Very Complicated) 0.6
218
DF-Замедление (DragFactor) определяется в зависимости от навыков
группы и опыта ее совместной групповой работы. Таким образом, для
каждой задачи формируется атрибут ее объема работы ZV. Zs = Z, Zv.
Далее представлена таблица 3.2 для определения значения
замедления. Таблица 3.2
Коэффициент DragFactor
DF Опыт командной работы
Технические навыки
Бизнес-навыки
0.8 < 3 месяцев низкие низкие 0.75 < 3 месяцев низкие средние 0.7 < 3 месяцев низкие высокие 0.75 < 3 месяцев средние низкие 0.5 < 3 месяцев средние средние 0.5 < 3 месяцев средние высокие 0.75 < 3 месяцев высокие низкие 0.5 < 3 месяцев высокие средние 0.35 < 3 месяцев высокие высокие 0.6 < 1 года низкие низкие 0.55 < 1 года низкие средние 0.5 < 1 года низкие высокие 0.55 < 1 года средние низкие 0.3 < 1 года средние средние 0.25 < 1 года средние высокие 0.5 < 1 года высокие низкие 0.25 < 1 года высокие средние 0.2 < 1 года высокие высокие 0.5 > 1 года низкие низкие 0.45 > 1 года низкие средние 0.4 > 1 года низкие высокие 0.45 > 1 года средние низкие 0.35 > 1 года средние средние 0.20 > 1 года средние высокие 0.4 > 1 года высокие низкие 0.2 > 1 года высокие средние 0 > 1 года высокие высокие
219
На основе определенных объемов работ по каждой задаче
происходит расчет общего объема работ спринта Sv, который учитывает
не только сумму временных затрат на решение задач, но также и ряд
коэффициентов:
− EF – фактор среды, который равен 0, если вся группа
располагается в одном кабинете или офисе, иначе он равен 0.1;
− FMC – фактор множественности команд. FMC также добавляет
0.1, если в спринте задействовано несколько устоявшихся отдельных
групп, не работавших ранее вместе как одна группа.
Теперь перейдем к описанию процесса выполнения спринта.
SBw представляет собой итеративный процесс выполнения работы
над спринтом, в течение которого осуществляются краткосрочные
24-часовые спринты: SBw = {SBt}.
Во время этого краткосрочного 24-часового спринта происходят
следующие процессы:
− ежедневный Scrum (DailyScrum) DSc;
− выполнение проектных задач.
Таким образом, SBt = DSc, {(Zi, "выполнение")}.
В свою очередь, ежедневный Scrum представляет собой
15-минутное обсуждение, в ходе которого происходит оценка
проделанной работы и внесение изменений в диаграмму выгорания Pob.
Диаграмма выгорания представляет собой график, на котором по оси
абсцисс отмечены дни – каждая отметка соответствует ежедневному
Scrum, а по оси ординат отмечается оставшийся объем работы Sv – ZVi
для i-го дня: DSc = (Pob, "отметка");
Pob = Sv, {Sv – ZVi};
220
"отметка" = Pob, Sv – Zvn.
Здесь ZVi обозначают выполненный на данный момент объем работ
спринта.
После завершения времени выполнения спринта происходит
вычисление метрик, к которым относятся:
− скорость работы сотрудника (IndividualVelocity, IV);
− скорость работы команды (TeamVelocity, TV);
− оценка стоимости выполненной работы (ValueDelivered, VD);
− оценка планирования (On-timeDelivery, TD).
Таким образом, SBa =(IV, TV, VD, TD), "вычисление".
Метрика скорости работы сотрудника определяется как отношение
трудозатратности выполненных им работ к длительности спринта.
,
где nd – количество выполненных задач проектировщика в спринте;
Zvi – трудозатратность задачи i;
t – продолжительность спринта.
Скорость работы сотрудника является его индивидуальной
характеристикой, зависящей от набора задач и особенностей их оценки.
Ее нельзя применять для сравнения производительности сотрудников.
Скорость работы команды определяется как отношение
выполненного объема работ в единицах трудозатратности
к продолжительности спринта:
,
где ns – общее количество выполненных задач в спринте;
Zvi – трудозатратность задачи i;
t – продолжительность спринта.
221
Скорость работы команды также является индивидуальной
характеристикой команды, измеренной в единицах, зависимых от самой
команды. Поэтому ее нельзя использовать для сравнения
производительности команд.
Оценка стоимости выполненной работы осуществляется совместно
со стейкхолдерами (stakeholder) проекта. Стейкхолдеру демонстрируют
историю выполнения спринта, и он ставит оценку M эффекта,
в зависимости от использования результата выполнения каждой задачи
спринта, в денежном эквиваленте или в любом другом виде для каждой
задачи.
Таким образом, VD = {Z, M}.
Эту метрику можно использовать для определения приоритетов при
формировании бэклога нового спринта.
Оценка планирования определяет то, насколько тщательно было
произведено оценивание скорости работы команды и объемов работ
на спринт (рис. 3.17).
Рис. 3.17. Формирование метрик
222
Она рассчитывается следующим образом. Максимальное количество
баллов TDmax устанавливается команде в том случае, если весь объем
спринта оказался выполненным точно в срок. За каждые n дней спринта,
на которые весь его объем работ оказался выполнен раньше, из этого
количества вычитается x баллов. Если команда не успевает выполнить
спринт в срок, из TDmax вычитается y баллов за каждые
m невыполненных единиц трудозатрат. При этом нужно учитывать, что
результат TD не может оказаться меньше нуля. В этом случае
он приравнивается к нулю, что говорит или о неправильном подборе
коэффициентов TDmax, x и y, или о крайне неудачном планировании
спринта: TD = TDmax – nx – ny.
Полученные в результате выполнения спринтов метрики влияют как
на формирование новой Scrum-команды для работы над следующим
спринтом, так и на формирование бэклога следующего спринта
(рис.3.18).
Рис. 3.18. Связь метрик с построением нового спринта
223
Стоит отметить, что список этих метрик можно расширить путем
программирования алгоритмов их вычисления на языке LWIQA.
3.5. Распараллеливание проектных процессов в ПКУ
3.5.1. Особенности распараллеливания в ПКУ Поток проектных работ состоит из множества отдельных, связанных
между собой работ, представленных в виде задач. Выполнение каждой
из задач назначается определенному участнику проектного процесса:
группе проектировщиков или отдельному проектировщику. Каждая из
этих задач состоит из определенного набора подзадач или вопросов.
Решая эти подзадачи или отвечая на поставленные вопросы, участник
проектного процесса движется по направлению к решению главной
задачи. Очевидно, что зачастую возникают ситуации, когда в один и тот
же период времени перед участником проектного процесса встает
необходимость выполнения нескольких задач.
В случае если участником проектного процесса является группа
проектировщиков, эта группа представляет собой набор отдельных
участников, являющихся независимыми I-процессорами, каждый из
которых может решать свой набор задач. Таким образом,
распараллеливание проектных процессов при решении их группой
проектировщиков достигается естественным образом путем разделения
потока работ проектного процесса на отдельные потоки, каждый из
которых поручается отдельному члену группы проектировщиков.
Такой процесс распараллеливания изображен на рисунке 3.19. Здесь
показано назначение потока работ группе проектировщиков Gm. При
этом происходит разбиение потока работ на отдельные группы,
содержащие задачи для назначения их подгруппам. Из каждой такой
подгруппы задач происходит формирование набора распределенных
в соответствии с их приоритетами задач, подлежащих выполнению
224
определенной подгруппой. При этом логические связи между
результатами выполнения одной задачи и возможностью начать
выполнение другой задачи сохраняются. Пример сохранения таких
связей представлен в назначении фрагмента потока работ группе Qm2.
Аналогичным образом распараллеливание происходит и в том случае,
когда членами группы являются отдельные проектировщики. Такая
ситуация представлена на рисунке 3.20.
Рис. 3.19. Распараллеливание потока работ по подгруппам
225
Рис. 3.20. Распараллеливание потока работ по проектировщикам
В случае распараллеливания задач по проектировщикам, каждый
проектировщик получает набор проектных задач, выполнение которых
поручено именно ему. Этот набор задач формирует очередь. Важно
отметить, что задачи могут оказаться зависимыми от выполнения других
задач, и в такой ситуации, как она представлена у проектировщика Dm2,
ее несложно решить, расставив приоритеты выполнения таким образом,
чтобы он зависимые задачи выполнил позже тех, от выполнения
которых зависит выполнение других задач. Таким образом, можно
говорить о том, что каждая группа проектировщиков или отдельный
проектировщик получает свой фрагмент потока проектных работ в виде
очереди задач с приоритетами.
При распараллеливании может возникнуть такая ситуация, при
которой задачи, связанные между собой зависимостью от результатов,
оказываются порученными разным исполнителям (рис. 3.21).
226
Рис. 3.21. Выполнение связанных задач различными исполнителями
Более того, эти задачи могут оказаться в разных группах
G проектировщиков. Это происходит в том случае, когда для
выполнения таких задач требуются разные компетенции, которыми
обладают разные участники проектного процесса, находящиеся в разных
группах. В такой ситуации необходимо или тщательно планировать
проектный процесс таким образом, чтобы у сотрудника не оказалось
простоев в связи с невозможностью приступить к выполнению
следующей в очереди задачи, или приступить к выполнению следующей
задачи после нее, но в этом случае может оказаться, что следующая
задача не будет завершена до тех пор, пока отложенная не станет
доступной. Здесь также возможно два варианта:
− изменить приоритет задачи, выполнение которой оказалось
невозможным;
− прервать выполнение следующей задачи и перейти
к выполнению ставшей доступной, имеющей более высокий приоритет
в очереди задач.
Из первого варианта следует, что очередь задач в процессе
проектирования не является статичным объектом, ее содержимое
изменяется. Такое изменение также может вызвать возникшая
в процессе работы над задачами межзадачная связь, которая не была
227
выявлена во время планирования. Второй вариант требует
специфической функциональности средств ПКУ, связанной
с обработкой прерываний. Обработка прерываний будет рассмотрена
ниже.
Kanban-процесс для каждого шага проектного процесса
представляет определенный набор задач для каждого участника. Таким
образом, распараллеливание задач между группами в Kanban-процессе
отображается в виде соответствующих группам строк Kanban-таблицы.
При этом очередь задач оказывается отображенной в виде набора
карточек в ячейке таблицы для каждого шага Kanban-процесса.
Карточки отсортировываются в порядке их приоритета в очереди. Таким
образом, карточка, лежащая сверху, содержит задачу, выполнение
которой имеет наивысший приоритет. Распараллеливание
применительно к Kanban-методологии в комплексе средств ПКУ
схематично изображено на рисунке 3.22.
Рис. 3.22. Распараллеливание в Kanban-процессе
228
Специфика параллельного процесса в Scrum заключается в том, что
параллельно могут работать несколько Scrum-команд, каждая из
которых выполняет свой спринт. При этом время запуска спринта для
каждой команды может быть своим (рис. 3.23).
Рис. 3.23. Распараллеливание в Scrum-процессе
Кроме группового параллелизма, который характеризуется наличием
нескольких исполнителей, каждый из которых выполняет работу
в соответствии со своей очередью задач, также в проектном процессе
могут возникать и ситуации индивидуального параллелизма, в которых
участнику проектного процесса приходится в одном и том же интервале
времени параллельно выполнять несколько проектных работ. Такой вид
параллелизма несвойственен I-процессору, и попытки одновременного
выполнения нескольких задач могут привести к ошибкам. Поэтому
индивидуальный параллелизм осуществляется по аналогии
с мультизадачностью, реализованной на ЭВМ. Этот параллелизм
осуществляется путем последовательного переключения между
229
задачами. Такое переключение сопряжено с прерываниями
в человеческой деятельности.
3.5.2. Формализация процессов распараллеливания работ Как было отмечено в п. 3.5.1, выполнение потока проектных работ
осуществляется несколькими группами проектировщиков G или
отдельными проектировщиками. Для этого поток проектных работ
разбивается на отдельные фрагменты WFF, каждый из которых отдается
на выполнение определенной группе или проектировщику. Таким
образом, проектный процесс Pp можно представить как набор
соответствий фрагмента потока работ его исполнителю: Pp = {WFF, (G | D)}.
Здесь важным является тот момент, что работы W, содержащиеся
в WFf, могут быть зависимыми от других работ или даже от задач,
содержащихся в другом WFf. Поэтому WFf можно представить
следующим образом: WFf = {{WFf}, ({W}, W)}.
В свою очередь, каждая работа характеризуется проектной задачей,
описывающей эту работу, и приоритетом этой задачи. W = (P, Z).
Таким образом, фрагменты потока работ, назначенные
определенному исполнителю, представляют собой очереди
с приоритетами задач: Q = ((P1, Z1), (P2, Z2), …, (Pn, Zn)).
Особенности формирования приоритетов для каждой задачи
раскрыты в п. 3.4.1.
В процессе проектной работы вне зависимости от методологии
проектирования каждому исполнителю приходится последовательно
выполнять фрагменты потоков работ, сформированные в виде очередей.
230
В связи с этим участие исполнителя в проектном процессе PpGD можно
представить в виде набора его очередей, исполняемых последовательно.
Эти очереди также формируют очередь, действующую по принципу
FIFO. PpGD = ((D | G), (Q1, Q2, …, Qn)).
Параллелизм в таблице Kanban PpK представлен в виде
одновременного нахождения на каждом этапе проектного процесса,
изображенном в виде колонки Kanban-таблицы, нескольких
исполнителей, которые обозначаются набором строк Kanban-таблицы.
Все карточки, расположенные в столбце Kanban-таблицы,
характеризуют параллельное исполнение этих задач различными
исполнителями в течение шага проектного процесса. Набор ячеек
столбца таблицы представляет собой параллельное выполнение
очередей задач исполнителями.
Таким образом, параллельный процесс Kanban PpK заключается
в последовательном выполнении шагов проектного процесса, на каждом
из которых происходит параллельное решение задач исполнителями: PpK = (Колонка1, Колонка2, …, Колонкаn).
Из п. 3.4.2: Колонка = I, {GD}.
В этом случае на ячейку GD отображается очередь Q в виде набора
карточек. Таким образом, в контексте управления очередями ячейка GD
содержит в себе очередь Q: GD = (Cr1, "отображение", (P1, Z1), Cr2,
"отображение", (P2, Z2), …, Crn,
"отображение", (Pn, Zn)).
Параллелизм Scrum-процесса PpS предполагает отображение очереди
проектных задач Q на бэклог спринта. В этом случае в проектной
231
организации может происходить параллельное выполнение сразу
нескольких спринтов одновременно.
В п.3.3.3 Scrum-процесс представлен следующим образом: Sproc = {SBf, SBw, SBa}.
В контексте параллелизма каждая проектная группа осуществляет
свой собственный Scrum-процесс: PpS = {G, Sproc}.
При этом формирование бэклога спринта SBf осуществляется путем
отображения на бэклог очереди Q. SBf = SB, "отображение", Q.
Если же говорить об индивидуальном параллелизме PpI, то в этом
случае за один период времени t человеку приходится выполнять сразу
несколько проектных задач, представленных набором задач ZZ: PpI = D, t, ZZ, "выполнение".
Набор задач содержит в себе задачи, имеющие одинаковый
приоритет для выполнения: ZZ = {Z, Pf}.
Каждая из этих задач содержит элементарные неделимые действия
Zd, последовательно выполняя которые проектировщик решает задачу.
Параллельное решение задач осуществляется путем поочередного
выполнения определенных наборов элементарных действий для каждой
задачи: Z = {Zd}.
Таким образом, параллельное выполнение набора задач Z1, Z2, …, Zn
проектировщиком можно рассматривать как последовательное
выполнение элементарных действий ZZd, которые относятся к разным
задачам: ZZd = {({Zd1}, {Zd2}, …, {Zdn})}.
232
3.5.3. Имитация механизмов массового обслуживания Поток работ как задание для выполнения его группой
проектировщиков можно охарактеризовать как набор заявок на
выполнение этих работ. Поскольку проектные работы
взаимосвязаны, эти заявки поступают в определенной
последовательности, а значит, можно говорить о потоке работ как
о потоке заявок на выполнение этих работ.
Выполняя работы, группа тем самым выполняет поток заявок.
Таким образом, группа проектировщиков имитирует СМО этих
заявок.
Существует ряд метрик, вычисляемых в процессе проектной работы
по методологии Kanban. Средние значения для этапа проектного
процесса этих метрик естественным образом вычисляются как
характеристики системы массового обслуживания. Таблица 3.3
Имитация основных характеристик СМО в ПКУ
Характеристика СМО
Компонент ПКУ Имитация в ПКУ
Комментарий
Режим обслуживания
Поток работ группы проектировщиков
Параллельно-групповое обслуживание
Одновременно поступает набор работ, что имитирует параллельное поступление группы заявок в СМО
Поток работ проектировщика
Время пребывания заявок в очереди
Поток работ группы проектировщиков, поток работ проектировщика
Ограниченное ожидание
Каждая задача должна быть выполнена в течение времени, ограниченного длительностью этапа проектной работы или всего проекта. После превышения этого времени происходит отказ в выполнении задачи
233
Продолжение таблицы 3.3
Характеристика СМО
Компонент ПКУ Имитация в ПКУ
Комментарий
Дисциплина очереди
Поток работ группы проектировщиков, поток работ проектировщика
Очередь с отбором заявок по критерию приоритетности
Каждая проектная задача имеет определенный приоритет относительно других задач. Очередь задач имитирует очередь заявок с приоритетами
Канальность Поток работ группы проектировщиков
Многоканальная Группа проектировщиков, параллельно выполняя набор задач, имитирует работу многоканальной СМО
Поток работ проектировщика
Одноканальная Один проектировщик не выполняет в один момент времени более одной задачи
Интенсивность поступления заявок λ
Поток работ группы проектировщиков
Интенсивность постановки новых проектных задач
Новые задачи ставятся в проекте с определенной интенсивностью, которая имитирует λ
Поток работ проектировщика
Интенсивность постановки задач
Формирование бэклога определяет интенсивность
Интенсивность обслуживания заявки одним каналом µ
Поток работ группы проектировщиков
Скорость выполнения задач членом группы
Скорость выполнения задач членом группы имитирует µ в СМО
Время обслуживания заявки tобс
Kanban Метрика Throughput (пропускная способность)
Пропускная способность характеризуется отношением 1/tобс, где tобс имитирует время выполнения одной задачи
Число каналов n Оргструктура Количество проектировщиков в группе
Каждый проектировщик в группе имитирует канал в СМО
Длина очереди m Отбор задач Длина бэклога Очередь задач для исполнения имитирует очередь заявок в СМО
Методология Kanban предполагает вычисление ряда метрик,
которые имитируют характеристики СМО. Эти метрики отображены
в таблице 3.4.
234
Таблица 3.4
Метрики Kanban как характеристики СМО
Метрика Описание Характеристика СМО Время цикла (Cycle Time)
Время, которое задача находилась в разработке от момента, когда ей начали заниматься, до момента, когда она прошла фазу конечной поставки
Среднее время обслуживания
Работы в процессе (WIP)
Количество задач, одновременно находящихся в разработке
Среднее число заявок, находящихся в СМО
Время обработки (Lead Time)
Время от появления задачи до ее конечной поставки. Включает Cycle Time и время ожидания в очереди на реализацию
Среднее время ожидания в очереди на реализацию характеризуется средним временем нахождения заявки в очереди
Пропущенное время (Waste Time)
Включает в себя все время, в течение которого задача ожидает своего выполнения
Среднее время нахождения заявки в очереди каждой СМО
Эффективность (Effectiveness)
Процент времени, которое тратится непосредственно на работу с задачей, а не на ожидания в различных очередях
Отношение среднего времени нахождения заявки в очереди к среднему времени пребывания заявки в СМО
Пропускная способность (Throughput)
Количество задач, которое может выполнять команда за единицу времени
Пропускная способность СМО
Группа проектировщиков работает со связанными между собой
наборами задач, следовательно, заявки поступают в нее также группами.
Поэтому речь идет о группе проектировщиков как о СМО
с параллельно-групповым обслуживанием.
Для успешного выполнения всей проектной работы каждая из этих
заявок должна быть обработана, поэтому формируют очередь заявок и
дожидаются их обработки. Таким образом, группа проектировщиков как
СМО является СМО с ожиданием.
235
Длительность этого ожидания зависит как от пропускной
способности группы, так и от общего объема проектной работы, то
есть от длины очереди заявок. Проектная организация в общем случае не
имеет ограничений по размеру и длительности проекта. Однако из
самого определения проекта следует, что он является ограниченным по
длительности. Таким образом, группа проектировщиков является СМО с
ограниченным ожиданием.
Расположение заявок в очереди зависит от приоритета проектных
работ. Таким образом, дисциплина очереди СМО группы
проектировщиков определяется как очередь с отбором заявок по
критерию приоритетности.
Каждая группа проектировщиков состоит из набора подгрупп или
проектировщиков, между которыми распределяются проектные задачи.
Таким образом, заявки внутри СМО делятся на несколько потоков, что
позволяет говорить о СМО группы проектировщиков
как о многоканальной СМО.
Исходя из вышеизложенного, можно сделать вывод о том, что группа
проектировщиков имитирует многоканальную СМО с параллельно-
групповым обслуживанием и неограниченным ожиданием.
Схематично группа проектировщиков как СМО представлена
на рисунке 3.23.
236
Рис. 3.23. Группа проектировщиков как СМО
СМО группы проектировщиков MG характеризуется набором заявок
MZ*, очередью MQ и внутренней структурой MS: MG = (MZ*, MQ, MS).
MZ* представляет собой фрагменты, на которые разбивается поток
работ в процессе отбора задач для оперативного выполнения (подробнее
механизм отбора задач рассмотрен в п. 3.4.1). Каждый из этих
фрагментов характеризуется набором компетенций С, которые
требуются для выполнения работ. MZ* = {MZf};
MZf = {C}, {Z}.
MQ представляет собой упорядоченную по приоритетам Pf очередь
заявок, поступающих на вход СМО:
237
MQ = ((MZf1, Pf1), (MZf2, Pf2), …, (MZfn, Pfn)).
Структура MS СМО группы проектировщиков представляет собой
набор каналов MC, в котором каждый канал является или подгруппой
проектировщиков, или проектировщиком – членом проектной группы.
Важной особенностью каждого канала является то, что он
характеризуется рядом компетенций, позволяющих ему решать
определенный набор задач. Этот набор компетенций ограничивает
возможности канала СМО принимать на обслуживание ту или иную
заявку, поэтому они распределяются между каналами с учетом
возможности их выполнения. MS = {MC}; MC = {C}, (G | D).
Рассматривая отдельного проектировщика, можно отметить, что он,
так же как и группа, выполняет набор проектных работ – заявок. Таким
образом, отдельного проектировщика также можно рассматривать
в качестве имитации СМО. Но, в отличие от группы, эта система будет
иметь некоторые особенности.
Во-первых, в очереди работ проектировщика задачи расположены по
одной и поступают туда по отдельности, поэтому данная СМО работает
с единичными заявками.
Во-вторых, проектировщик представляет собой один канал
обслуживания, значит, СМО проектировщика является одноканальной.
Наконец, в-третьих, в зависимости от используемой методологии
проектирования, время на выполнение одного этапа проектного
процесса, которым может быть, например, спринт в Scrum, является
ограниченным, поэтому при нахождении заявки в очереди на
исполнение в течение длительного времени, превышающего время этапа
проектного процесса, происходит отказ от обслуживания этой заявки.
238
Таким образом, эта СМО является системой смешанного типа.
Схематично она представлена на рисунке 3.24.
Рис. 3.24. Проектировщик как СМО
СМО проектировщика MD характеризуется, также, как и для СМО
группы, набором заявок MZD*, очередью MQD и внутренней структурой
MSD: MG = (MZD*, MQD, MSD).
MZD* представляет собой набор заявок, характеризующих задачи,
для выполнения которых проектировщик обладает требуемыми
компетенциями. MZ* = {({C}, Z)}.
MQD – очередь с приоритетами задач сотрудника. Такая
очередь была рассмотрена в п. 3.5.2. MQD = Q.
239
Структура СМО проектировщика в данном случае
представляет собой всего один канал обработки заявок –
собственно проектировщика. MSD = MC; MC = D.
Имитация механизмов массового обслуживания позволяет внедрить
в процесс проектирования наборы метрик, характерные для СМО, такие,
как среднее время обслуживания, среднее время в очереди,
интенсивность, коэффициенты нагрузки, среднее количество свободных
и занятых каналов и многие другие.
3.5.4. Управление прерываниями В процессе проектирования неизбежно возникновение ситуаций, в
которых человеку приходится прерывать выполнение текущей задачи и
переключаться на другую, после чего возвращаться к прерванной задаче.
Такие ситуации могут возникать в том случае, если перед человеком
поставлена задача, имеющая более высокий приоритет, чем задача,
выполняемая в данный момент, или в случае псевдопараллельного
выполнения нескольких задач. Кроме того, возникают прерывания,
не связанные с проектным процессом.
Мак Фарлайн дал общее определение прерывания человеческой
деятельности: «Прерывание человеческой деятельности есть процесс
координации быстрой перемены человеческой деятельности».
Из этого определения следует, что прерывание – это процесс,
координация, внезапность, изменение деятельности человека.
Обработка прерываний проектировщика как I-процессора
осуществляется во многом аналогично обработке прерываний
центральным процессором (ЦП) ЭВМ.
240
В однозадачном режиме обработка прерывания ЦП осуществляется
в три этапа:
1. Прекращение выполнения программы. Данный этап прекращает
работу текущей программы так, чтобы потом можно было вернуться
к ней и продолжить работу. При этом происходит сохранение блока
регистров, содержащего значения регистров процессора, в стек,
работающий в режиме LIFO.
2. Переход к выполнению обработчика прерывания.
3. Возврат к выполнению прерванной программы. Для этого из
стека извлекается блок данных программы, восстанавливаются значения
регистров, в том числе и регистра указателя команд, что приводит
к продолжению выполнения прерванной программы.
На рисунке 3.25 изображена общая схема прерывания человеческой
деятельности.
Рис. 3.25. Общая схема прерывания человеческой деятельности
Из схемы прерывания, отображенной на рисунке 3.25 видно, что
с точки зрения человека процесс прерывания Int делится на две
основные части:
241
Выполнение прерывания Iex, которое заключается в реакции на
возникшее прерывающее событие, приостановке выполняемой основной
задачи и выполнении прерывающей задачи.
Переключение на основную задачу SW, состоящее
из переключения фокуса внимания SWf, на прерванную задачу
и ориентации в прерванной задаче Zo. Int = Iex, SW;
SW = SWf, Zo.
Каждое прерывание сопровождается связанными с ним
негативными эффектами, такими как: − увеличение общего времени выполнения задачи за счет времени
переключения внимания на прерванную задачу;
− увеличение общего времени выполнения задачи и вероятности
возникновения ошибок за счет необходимости ориентации в основной
задаче.
Для минимизации этих негативных эффектов в состав средств ПКУ
был включен инструментарий управления прерываниями. Данные
средства позволяют минимизировать влияние обоих негативных
эффектов.
Минимизация первого из них достигается за счет включения
прерванной задачи в очередь задач проектировщика Q. Причем,
поскольку приоритет выполняемой задачи заведомо выше, чем
приоритеты остальных задач, находящихся в этой очереди, приоритет ее
устанавливается большим, чем у задачи, имеющей в Q наибольший
приоритет. Таким образом, после завершения прерывающей задачи (а ее
выполнение может быть длительным), проектировщику не придется
ориентироваться в проектных задачах и вернуться к прерванной как к
первоприоритетной. Поскольку прерывающая задача может также
прерываться, возникает каскад прерываний. При этом очередь
242
прерванных задач начинает работать в режиме, близком к LIFO, то есть
по аналогии со стеком.
Минимизация второго эффекта достигается путем сохранения
текущего состояния прерванной задачи c целью помощи
проектировщику в его восстановлении путем автоматизации процесса
восстановления.
Обработка прерывания человеческой деятельности осуществляется
по аналогии с прерыванием ЦП, при этом она содержит те же самые
этапы обработки. К особенности первого этапа можно отнести то, что
вместо блока данных программы необходимо сохранять текущее
состояние прерываемой задачи.
Текущее состояние Zoc состоит из следующих компонентов:
− текущий решаемый вопрос задачи Qc;
− состояние переменных задачи Zv;
− протокола работы над задачей Zk;
− представление решения задачи проектировщиком Dc.
Таким образом, Zoc = Qc, Zv, Zk, Dc.
Состояние переменных для каждой задачи постоянно сохраняется
в QA-памяти WIQA, следовательно, при прерывании выполнения задачи
их значения не теряются.
Для обеспечения автоматизации процесса восстановления состояния
задачи, поскольку в I-процессоре отсутствует аналог регистра указателя
команд, необходимо сохранять набор компонентов прерывания Zsc для
каждой прерванной задачи в виде списка прерываний IL. IL = {Zref, Zsc};
Zsc = Qc, Zk, Dc.
Здесь Zref представляет собой ссылку на прерванную задачу
в очереди, Qc – ссылку на решаемый в ней вопрос, Zk хранит в себе
243
ссылку на протокол работы над задачей. Поскольку представление
решения задачи проектировщиком невозможно сохранить напрямую,
при возникновении прерывания проектировщик имеет возможность
привести его текстовое описание, которое и сохраняется как Dc.
Список прерываний отображается на вопросно-ответную память
в виде таблицы TIL, содержащей столбцы ссылки на задачу TZref, ссылки
на вопрос TQc, ссылки на протокол решения TZk и текстового описания
собственного представления решения задачи TDc. TIL = {TZref, TQc, TZk, TDc}.
В QA-памяти WIQA для хранения этой таблицы формируется
QA-объект TIntDataQA, представляющий собой вопрос QIntData «Данные
прерываний», содержащий в себе подчиненный QA-объект таблицы
списка прерываний: TIntDataQA = QIntData, "↓", (TILqa).
При этом TIL в QA-память WIQA отображается как QA-объект TILqa,
состоящий из одного вопроса «Список прерываний» QIL, включающего в
себя ряд вопросов, соответствующих атрибутам описания прерывания: TILqa = QTZ, "↓", QАтрIL; QАтрIL = QZref, QQc, QZk, QDc.
Сами элементы списка прерываний при этом отображаются в виде
ответов на вопросы атрибутов описания задачи. Таким образом описание
задачи в QA-памяти WIQA раскрывается как ILElemQA, представляющее
собой набор ответов на эти вопросы.
ILElemQA = ({QАтрIL},"←", {AАтрIL});
Этап восстановления прерванной задачи осуществляется следующим
образом.
При получении из очереди следующей по приоритету задачи
происходит проверка наличия ее в списке прерванных задач. Если она
там отсутствует, то решение задачи начинается сначала. В противном
244
случае осуществляется переход к вопросу задачи, на котором возникло
прерывание, а также отображение пользователю протокола его работы
по ссылке Zk и данного им описания Dc, что помогает ему быстрее
сориентироваться в задаче. После этого пара <Zref, Zsc> удаляется
из списка прерываний IL.
3.5.5. Программная интерпретация очередей задач Вернемся к спецификатору «Программно-» представленной выше
версии «Программно-картотечное управления». В основе содержания
этого спецификатора лежит представление о практиках решения
проектных задач, причем как о «лучших практиках» используемых
технологий, так и о «практиках решения задач» предметной области
семейства АС, разрабатываемых в проектной организации.
В реализации «Программно-картотечного управления»
предусмотрены следующие режимы исполнения таких программ:
1. Пошаговый режим исполнения программы «интеллектуальным
процессором», по ходу которого проектировщик может прервать
исполнение до или после любого шага (оператора программы)
с полезными целями, например для проверки предусловий или
постусловий, складывающихся в процессе исполнения программы.
В таких проверках он может экспериментировать, а затем вернуться
к исполнению следующих шагов программы.
2. Пошаговый режим исполнения, по ходу которого группа
операторов (или ряд групп) компилируется для автоматического
исполнения, что подобно использованию «навыков» проектировщика
с помощью компилированных групп.
3. Режим компиляции, результат которого исполняется
автоматически компьютерным процессором.
245
Наличие названных режимов и возможность выбора любого из них
с помощью прерываний нацелены, в первую очередь, на оперативное
взаимодействие с любым оператором псевдокодовой программы
в формах экспериментирования (рисунок 3.26).
Рис. 3.26. Обстановка экспериментирования
Более того, одним из направлений развития потенциала
инструментария WIQA, нацеленного на поиск средств, способствующих
повышению степени успешности в разработках АС, является
предоставление проектировщикам возможностей концептуального
экспериментирования.
Концептуальный эксперимент – это мысленный эксперимент,
содержание и процесс которого оперативно отображается
на семантическую память вопросно-ответного типа, а результаты
отображения используются по ходу экспериментирования с полезными
целями. В число таких целей входит и управление активностью
проектировщиков в решении проектных задач. Необходимость
в проведении концептуальных экспериментов возникает ситуативно, что
246
невозможно без прерываний работ, выполняемых проектировщиками,
а значит, ведет к распараллеливанию их активностей.
Отмеченная причина распараллеливания не является единственной.
Феномен распараллеливания объективен. Основные источники причин
распараллеливания – человеко-компьютерные прерывания,
представленные выше. К конструктивной организации и осуществлению
распараллеливаний активности проектировщиков также можно подойти
с позиций программирования.
В параллельной и / или псевдопараллельной обработке очередей
задач, о которых говорилось выше, может использоваться любое
полезное комплексирование возможных режимов, следовательно
обработка любой заявки из их очередей может быть прервана
в определенном промежуточном состоянии. Это значит, что
параллельной работой группы проектировщиков или
псевдопараллельной работой любого из них управляет текущее
состояние очередей, с которыми взаимодействует каждый из них.
Такое положение дел позволяет обогатить содержание
спецификатора «Программно-», введя для последовательностей кодов
«состояний очередей» во времени их интерпретацию как программ,
управляющих активностью проектировщиков. Такая интерпретация
обобщенно представлена на рисунке 3.27, где показан только один
проектировщик из их группы, который взаимодействует с очередью
исполняемых им псевдопараллельных работ (решаемых задач) с одной
стороны и участвует в выполнении параллельной работы с другими
членами группы.
247
Рис. 3.27. Взаимодействие I-процессора с очередями задач
В программной интерпретации очередей проектировщик,
выполняющий роль I-процессора, выступает в двух лицах. С одной
стороны, он взаимодействует с очередью стоящих перед ним задач Zp,
Zq, …, Zr как член группы с обязательствами участвовать в решении
задач (потока задач) согласованно (в том числе и во времени) с другими
членами группы. Необходимую согласованность для каждой задачи
очереди логично закрепить условием: пусть для задачи Zx условием
будет U1(Zx). Отметим, что за условием согласованности, включающим
индикаторы приоритетности, стоит критерий выбора задачи
проектировщиком из доступных ему альтернатив в очереди задач.
С другой стороны, проектировщик, работая с той же самой
очередью, прерывается на назначенных ему задачах для полезных
действий в моменты времени t1, t2, …, tk, а после этого возвращается
Средства QA-программирования
V2-программа
…………
…………
Оператор_j
Система прерываний
…………
…………
Оператор_i
I-процессор
Kanban-система
V1-программа
Очередь задач
U1,U2,Zr,t1 U1,U2,Zq,t1 … U1,U2,Zp,t1
U1,U2,Zr,t2 U1,U2,Zq,t2 … U1,U2,Zp,t2
… … … …
U1,U2,Zr,tk U1,U2,Zq,tk … U1,U2,Zp,tk
248
к прерванным задачам. В число полезных действий могут входить,
например, работа с другой задачей из очереди или решение полезной
ситуативной задачи, которую ему логично внести в очередь собственных
распараллеливаний (так как она тоже может быть прервана). Такое
положение дел образно отображено на рисунке, где для очереди
собственных распараллеливаний введены моменты времени прерываний
и условия выбора U2(Zx) задачи Zx из этой очереди.
Так, в любой момент времени tx из набора t1, t2, …, tk складывается
определенная ситуация, в которой перед проектировщиком встает задача
выбора ZV(tx) из очереди задач (U1,U2,Zp,tx, U1,U2,Zq,tx, … , U1,U2,Zr,tx)
с учетом логических значений условий типов U1 и U2 в данный момент.
В задаче ZV(tx) следует различать и согласованно решать две
подзадачи, одна из которых ZV1(tx) отвечает за выбор по условиям типа
U1, а вторая ZV1(tx) – за выбор по условиям типа U2. Задачи ZV
1(tx)
и ZV1(tx) можно решать, запрограммировав их (на языке псевдокодов)
явно, или ориентируясь на правила выбора, оговоренные в коллективе,
или рассчитывая на мысленные действия. Но для любого случая
решения приходится признать, что состояние очереди задач в любой
момент tx активизирует исполнение двух программ действий. Тип одной
из таких программ на рисунке отмечен как V1-программы, а тип второй –
как V2-программы.
Различия между очередями V1- и V2-типов состоят в следующем: в
V1-программах условия доступа регистрируют логику отношений между
задачами потока во времени, управляя тем самым параллельно-
согласованным решением задач группой проектировщиков, в то время
как условия операторов V2-программ управляют псевдопараллельным
решением задач конкретным проектировщиком, каждая из которых
может быть прервана по ходу решения, если в этом возникла
необходимость.
249
Использование очередей двух типов позволяет отделить:
визуализацию общей картины решения задач группой проектировщиков
от интерактивных взаимодействий проектировщика с задачами, которые
он может выполнять псевдопараллельно.
Для формирования очередей в расширение языка LWIQA введен
оператор QUEUE. Основное назначение оператора – зарегистрировать
условие, истинность которого открывает возможность для начала работы
с задачей.
3.5.6. Особенности эмпирики картотечного управления
В предыдущих разделах неоднократно отмечалось, что предлагаемая
версия гибкого управления в виде ПКУ относится к классу
эмпирических. Ее эмпиричность проявляется в следующих
возможностях, предоставляемых проектировщикам:
1. Решая назначенную ему задачу в ее псевдокодовом
представлении, проектировщик может прервать исполняемую им работу
до или после любого оператора и провести концептуальный эксперимент
или концептуальный анализ и оценивание, если он видит в этом
необходимость.
2. По ходу исполнения параллельных или псевдопараллельных
работ имеется возможность вычисления совокупности метрик, значения
которых можно и следует использовать для воздействий
на формирование групп проектировщиков, отбор задач в бэклоги
и на выбор задач из их очередей.
Первый класс возможностей связан с ситуациями процесса
проектирования, в которых проектировщик, ответственный за
прерываемую задачу (пусть Zi), столкнулся с необходимостью или
целесообразностью уточнения, прежде чем продолжить работу.
250
В уточнении, а значит, и соответствующем ему снижении
неопределенности, различаются два случая, в одном из которых
проектировщик, активизировав прерывание, проводит подходящий
концептуальный эксперимент, связывая с ним задачу Zij , подчиненную
задаче Zi. В этом случае задача Zij включается в общее дерево задач с
автоматическим назначением для нее как ответственного за решение, так
и плановых характеристик времени их решения (значения наследуются
от родительской задачи).
Во втором случае проектировщик реагирует на ситуацию, то есть
проводит потребовавшиеся ему концептуальные действия без
оформления и регистрации их как задачи, но в условиях явного
использования системы прерываний.
В любом из выделенных случаев либо по результату эксперимента,
либо по результатам анализа и оценивания проектировщик принимает
определенное решение о продолжении работы c Zij, следовательно,
первый класс возможностей связан с ситуациями, реагирование на
которые помогает принять полезное управленческое решение.
Потребность в таком решении появляется оперативно. Возможность
управленческого реагирования на подобные ситуации следует связать с
одним из специфических проявлений гибкости ПКУ.
Отметим, что предоставляемый проектировщикам инструментарий
реагирования на рассмотренный класс управленческих решений
допускает либо возврат к работе с прерванной задачей Zij , либо переход
к задаче по результатам взаимодействия с доступными очередями задач.
Второй класс возможностей связан с определением значений метрик
параллельной и псевдопараллельной работы проектировщиков,
представленных выше, после чего по полученным значениям метрик
также принимаются управленческие решения. Эмпирика в этом классе
возможностей проявляет себя в измерениях значений метрик, причем
251
ничто не мешает считать данные, по которым вычислены значения
метрик, данными, полученными в результате «экспериментов»,
за которыми стоят определенные объемы работ, выполненных
в процессе проектирования. Так, например, осуществленный Scrum-
спринт можно интерпретировать как «эксперимент».
Для вычислений метрик в состав средств ПКУ включена
совокупность псевдокодовых программ (а вернее, процедур). В качестве
примера приведем запрограммированное на языке LWIQA вычисление
метрики CYCLE_TIME для Kanban и метрики Velocity для Scrum.
Для вычисления значения метрики CYCLE_TIME – среднего
значения времени, которое задача проходит от момента ее постановки до
завершения работы над ней, – необходимо выполнить следующие
действия:
− отобрать из таблицы контроля поручений выполненные задачи;
− для каждой задачи вычислить длительность выполнения в днях
и подсчитать среднее арифметическое этих длительностей.
Данную работу выполняет псевдокодовая процедура
&CountCycleTime& со следующим исходным кодом: Q 4 PROCEDURE &CountCycleTime&
Q 4.1 &dbqa& := QA_GetQAId(¤t_project&, "БД
поручений")
A 4.1.1 44694
Q 4.2 &dbid& := OpenDB (¤t_project&, &dbqa&)
A 4.2.1 0
Q 4.3 &tasks& := ExecuteSQL(&dbid&, "SELECT
Дата_исполнения, Дата_поручения FROM Задачи WHERE
Статус = 1");
A 4.3.1 ""
Q 4.4 &ntasks& := DB_GETROWCOUNT(&tasks&);
Q 4.5 &NCNT& := 0
252
A 4.5.1 0
Q 4.6 LABEL &CCT_L1&
Q 4.6.1 IF &NCNT& >= &ntasks& THEN GOTO &CCT_L2&
Q 4.6.2 &DSTART& := DB_GETCELLDATETIME(&tasks&,
&NCNT&, 1);
A 4.6.2.1
Q 4.6.3 &DEND& := DB_GETCELLDATETIME(&tasks&,
&NCNT&, 0);
A 4.6.3.1
Q 4.6.4 &NDAYS& := &NDAYS& +
DT_GETDATEDIFFERENCE(&DEND&, &DSTART&);
Q 4.6.5 &NCNT& := &NCNT& + 1
Q 4.6.6 GOTO &CCT_L1&
Q 4.7 &NDAYS& := 0
A 4.7.1 0
Q 4.8 LABEL &CCT_L2&
Q 4.9 &CYCLE_TIME& := &NDAYS& / &NCNT&
A 4.9.1 0.
На первом шаге данная процедура с помощью встроенной функции
QA_GetQAId определяет индекс единицы, содержащей базу данных
поручений, по ее имени «БД поручений». Следующее действие
с помощью функции работы с базами данных OpenDB открывает базу
данных для работы с ней, и в переменную &dbid& сохраняется
идентификатор открытой базы данных. Затем выполняется SQL-запрос
«SELECT Дата_исполнения, Дата_поручения FROM Задачи WHERE
Статус = 1», осуществляющий выбор даты исполнения и даты
назначения поручения для всех выполненных задач, находящихся в базе
данных поручений. Результат запроса сохраняется в виде строки. Затем
с помощью функции работы с базами данных DB_GETROWCOUNT для
результата запроса SELECT происходит определение количества
253
возвращенных строк. Это количество соответствует числу
обнаруженных выполненных задач. Далее с помощью меток, условий
и операторов перехода реализован цикл, осуществляющий обход
возвращенных в результате SQL-запроса значений дат. Для каждой
задачи с помощью дополнительной функции работы с датами
DT_GETDATEDIFFERENCE вычисляется количество дней от момента
постановки задачи до момента ее выполнения. Сами эти даты
извлекаются из результата запроса с помощью функции работы с базами
данных DB_GETCELLDATETIME. Полученные значения в цикле
суммируются в переменной &NDAYS&. После завершения цикла
переменной &CYCLE_TIME& присваивается вычисленное значение
метрики.
За определением Scrum-метрики «Скорость работы команды»,
вычисляемой как среднее количество выполненных в течение дня
единиц трудозатратности StoryPoints, стоит следующая работа:
− подсчитать сумму единиц трудозатратности, выполненных
во время спринта;
− разделить ее на количество отработанных дней.
Такую работу выполняет процедура CountVelocity: Q 5 PROCEDURE &CountVelocity&
Q 5.1 &dbqa& := QA_GetQAId(¤t_project&, "БД
поручений")
A 5.1.1 44694
Q 5.2 &dbid& := OpenDB (¤t_project&, &dbqa&)
A 5.2.1 0
Q 5.3 &res& := ExecuteSQL(&dbid&, "SELECT Дата FROM Спринты
WHERE ID = "+ &nsprint&);
A 5.3.1 ""
Q 2.4 &date& := DB_GETCELLDATETIME (&res&, 0, 0);
Q 5.5 IF DT_GETDATEDIFFERENCE (NOW(), &date&) > 28 THEN
&ndays& := 28 ELSE &ndays& := DT_GETDATEDIFFERENCE (NOW(),
&date&);
254
Q 5.6 &res& := ExecuteSQL(&dbid&, "SELECT Дата FROM
ЛогСпринта WHERE ID = "+ &nsprint& + ", StoryPoints < 0");
A 5.6.1 ""
Q 2.7 &NCNT& := 0
A 5.7.1 0
Q 5.8 LABEL &CV_L1&
Q 5.8.1 IF &NCNT& >= &nrecords& THEN GOTO &CV_L2&
Q 5.8.2 &nrecords& := &nrecords& - DB_GETCELLINT(&res&,
&NCNT&, 0);
A 5.8.2.1
Q 5.8.3 &NCNT& := &NCNT& + 1
Q 5.8.4 GOTO &CV_L1&
Q 2.9 &nrecords& := DB_GETROWCOUNT(&tres&);
A 5.9.1 0
Q 5.10 &scores& := 0
A 5.10.1 0
Q 5.11 &Velocity& := &nrecords& / &ndays&
A 2.2.5.11.1 0
Q 5.12 ENDPROC &CountVelocity&
Процедура &CountVelocity& вычисляет среднюю скорость работы
команды для спринта с индексом, записанным в переменную &nsprint&,
причем, сначала определяет время от начала спринта до настоящего
момента. Если оно оказывается больше 28 дней, то это означает, что
спринт завершен и все время спринта равно 28 дням, что заносится
в переменную &ndays&. В противном случае спринт выполнен
частично, и в &ndays& заносится количество прошедших от начала
выполнения спринта дней. Далее с помощью SQL-оператора «SELECT
Дата FROM ЛогСпринта WHERE ID = nsprint, StoryPoints < 0» происходит выбор из лога спринта всех записей с отрицательным
значением StoryPoints для спринта &nsprint&. Отрицательное значение
говорит о том, что эта запись соответствует не начальному
формированию бэклога спринта, а трудозатратности выполненных
задач. В переменной &scores& сохраняется сумма по модулю
255
выполненной трудозатратности. Данная сумма впоследствии делится на
количество дней спринта и присваивается переменной &Velocity&,
в которой оказывается вычисленное значение метрики.
Отметим, что процедуры CountCycleTime и CountVelocity приведены
в большей мере для того, чтобы в очередной раз продемонстрировать
программирование на языке LWIQA.
Как уже отмечалось, значения метрик, вычисляемых с помощью
совокупности специализированных процедур, в число которых входят
процедуры CountCycleTime и CountVelocity, используются для
управляющих решений, нацеленных:
− на потенциальную корректировку групп проектировщиков или на
повышение степени профессиональной зрелости их членов;
− рациональный отбор работ (задач) в бэклоги, учитывающий
специфику каждой группы;
− корректировку правил, вложенных в программы взаимодействия
с очередями задач, с которыми работают проектировщики конкретных
групп.
3.6. Сценарная структуризация ПКУ
Программно-картотечное управление осуществляется путем решения
набора задач управления, осуществляемого на протяжении всего
проектного процесса. Проведем систематизацию этих задач,
рассматривая их с детализацией, достижимой путем построения общей
диаграмм вариантов использования. Для этого сначала произведем
построение общей диаграммы вариантов использования всей системы
ПКУ, а затем более детально рассмотрим ряд вариантов использования
её составных частей.
Процесс управления потоком проектных работ можно представить
как задачу управления Zc, решение которой начинается
с формирования потока проектных работ. Обозначим эту задачу как
256
ZF. Поток проектных работ формируется на основе проектных задач,
решение которых ведет к выполнению проекта. Введем обозначение ZFZ
для задачи определения набора проектных задач. В этом процессе
принимает участие как непосредственный руководитель проекта DB,
так и другие стейкхолдеры проекта DS, в частности, заказчики. Далее
в процессе работы над потоком проектных работ перед руководителем
проекта встают задачи формирования групп проектировщиков ZFG из
коллектива проектной организации и назначения проектных задач ZFZa
группам с учетом их взаимосвязанности путем назначения поручений
ZFBa. Этот процесс не является единовременным для проекта, так как
в процессе проектной работы могут возникать новые проектные задачи.
После формирования потока проектных работ организация
переходит к его выполнению. При этом в соответствии с используемой
методологией проектирования (такой, как Kanban или Scrum)
происходит формирование бэклога этапа проектной работы ZFB.
В этом процессе принимает участие как руководитель проекта,
ответственный за выбор задач для этапа проектной работы, так
и проектировщики. Это формирование осуществляется с учетом
метрик, рассчитанных при выполнении предыдущих этапов проектной
работы.
В вычислении метрик могут участвовать другие стейкхолдеры
проекта. К примеру, заказчик может оценить финансовый эффект от уже
выполненных проектных задач. Далее в рамках используемой
методологии проектирования участники выполняют проектную работу.
После завершения этапа данной работы и в ее процессе происходит
вычисление метрик, характеризующих особенности выполнения данного
этапа. В процессе выполнения проектных задач проектировщики
постоянно отчитываются о проделанной ими работе перед
руководителем проекта.
257
Таким образом, можно выделить трех основных акторов,
участвующих в проектном процессе:
− руководителя проекта DB;
− проектировщика DD;
− других стейкхолдеров проекта DS.
Эти акторы решают следующие основные задачи ПКУ:
− формирование потока работ проекта ZF;
− выполнение проектной работы ZW.
Задача формирования потока работ проекта, в свою очередь,
включает в себя следующие подзадачи:
− формирование набора задач проекта ZFZ;
− формирование групп проектировщиков, ответственных
за решение этих задач ZFG;
− назначение задач проектировщикам и их группам ZFZa.
Задача выполнения проектной работы ZW представляет собой
итеративное выполнение следующих подзадач:
− формирование бэклога этапа проектной работы ZWB;
− выполнение этапа проектной работы ZWE;
− формирование отчетов о выполненной работе ZWR.
Задача формирования бэклога этапа проектной работы включает
в себя задачу назначения поручений.
В свою очередь, выполнение этапа проектной работы включает
в себя:
− выполнение проектных задач ZWEt;
− вычисление метрик ZWEm;
− формирование отчетов о проделанной работе ZWRp.
Удобнее всего представить все эти задачи в виде UML-диаграммы
вариантов использования, представленной на рисунке 3.28.
258
.
Рис. 3.28. Диаграмма вариантов использования системы ПКУ
Каждая из этих задач выполняется с помощью определенного
средства, описание таких средств представлено в главе 2. Перейдем
к более детальному рассмотрению задач, выполняемых с помощью
данных средств
Задача формирования набора задач проекта является полностью
проектно-зависимой, ее автоматизация сопряжена со значительными
трудностями. Поэтому в комплексе средств ПКУ инструмент
формирования набора проектных задач по техническому заданию
отсутствует.
259
Теперь перейдем к задачам управления организационной структурой
и назначения задач проектировщикам. Управление группами
проектировщиков ZFG включает в себя следующие задачи, выполняемые
руководителем проекта:
− создание группы проектировщиков ZFGC;
− удаление группы проектировщиков ZFGD;
− добавление проектировщика в группу ZFGA;
− перемещение проектировщиков между группами ZFGM;
− удаление проектировщика из группы ZFGDp;
− назначение задач ZFGS.
При добавлении проектировщика в группу руководителю проекта
необходимо определить для него роли, значит, он решает задачу
определения ролей проектировщика. Диаграмма вариантов
использования организационной структуры и подсистемы назначения
задач в ПКУ представлена на рисунке 3.29.
Рис. 3.29. Диаграмма вариантов использования для формирования групп
и назначения задач
260
Рассмотрим задачу формирования бэклога для выполнения этапа
проектной работы. Руководителю проектного процесса необходимо
сначала определить набор задач для выполнения их в рамках данного
этапа. При этом группа проектировщиков выполняет оценку объема
затрат труда на решение проектных задач.
Одним из вариантов такой оценки является покер планирования,
использование которого сводится к задачам оценки трудоемкости задачи
и обсуждения этой оценки. Таким образом, из набора задач
формирования бэклога можно выделить основную задачу – определение
набора задач для выполнения на данном этапе проектирования
и их приоритетов ZWB.
Эта задача содержит в себе следующие подзадачи:
− определение задач Zmax, которые необходимо выполнить
на данном этапе ZZmax;
− определение задач Znecc, от выполнения которых зависит
выполнение задач Zmax, но которые еще не выполнены ZZnecc;
− определение задач Ztime, подлежащих выполнению,
соответствующих определенному критерию ZZtime.
− определение задач ZTnecc, от выполнения которых зависит
выполнение задач Ztime, но которые еще не выполнены ZZTnecc;
− определение приоритетов задач ZWBP;
− определение трудоемкости каждой задачи и сопоставление
общего объема работы с возможностями проектной группы ZWBE;
− назначение поручений для выполнения задач проектировщиками
ZWBP.
При использовании покера планирования определение трудоемкости
каждой задачи включает в себя следующие задачи:
− определение каждым сотрудником трудоемкости задачи ZWBEZ;
261
− обсуждение выставленных оценок трудоемкости ZWBED;
− вычисление общей трудоемкости набора задач и отбор задач для
бэклога с учетом возможностей группы проектировщиков ZWBEW.
Представим набор задач формирования бэклога этапа проектной
работы в виде диаграммы вариантов использования (рисунок 3.30).
Рис. 3.30. Диаграмма вариантов формирования задач бэклога проектного этапа
Далее рассмотрим задачи работы с поручениями. Руководитель
проекта в данном случае является инициатором поручений, который
имеет возможность создавать, редактировать, удалять, просматривать
поручения, проверять их выполнение, а также перемещать выполненные
поручения в архив. Проектировщик может использовать поручения для
самоконтроля, при этом он должен иметь возможность просмотра
поручений.
262
Таким образом, работа с поручениями включает в себя следующие
задачи:
− создание поручения ZWBPC;
− редактирование поручения ZWBPE;
− удаление поручения ZWBPD;
− просмотр поручения ZWBPV;
− выполнение поручения ZWBPX;
− проверка выполненного поручения ZWBPK.
По результатам проверки выполнения поручения руководитель
имеет возможность отправить поручение на доработку ZWBPR или в архив
ZWBPA.
Работа с поручениями представлена на рисунке 3.31. в виде
диаграммы вариантов использования.
Рис. 3.31. Диаграмма вариантов использования работы с поручениями
263
Выполнение проектных задач ZWEZ зависит от выбранной
методологии проектирования, и в рамках применения средств ПКУ оно
может осуществляться с использованием средств Scrum или Kanban,
а также обоих этих инструментов одновременно. Также в процессе
параллельного выполнения задач проектировщиком неизбежны
прерывания, и проектировщику необходимо решать связанные
с прерываниями задачи.
Таким образом, выполнение проектных задач (рисунок 3.32)
включает в себя задачи Kanban ZWEK и задачи Scrum ZWES, а также
задачи прерываний ZWEI.
Рис. 3.32. Диаграмма вариантов использования выполнения задач
В процессе работы с использованием методологии Kanban
проектировщик, просматривая карточки, контролирует набор задач,
которые ему назначены. С карточки он имеет возможность перейти
непосредственно к выполнению задачи, отметить нужные ему карточки,
перевернуть карточку, просмотрев дополнительную информацию
о задаче, а также сообщить о выполнении задачи для отметки
информации об этом на доске, изменив цвета карточки. Как
264
руководитель, так и проектировщик имеют возможность просматривать
доску Kanban.
Таким образом, основной задачей Kanban является просмотр доски и
находящихся на ней карточек.
Эта задача включает в себя ряд подзадач:
− отметка карточек ZWEKM;
− отметка выполнения задачи ZWEKX;
− просмотр детальной информации о задаче ZWEKD;
− переход к выполнению задачи ZWEKG.
Просмотр детальной информации о задаче, в свою очередь, включает
в себя задачи:
− просмотр детального описания задачи ZWEKV;
− просмотр дополнительной информации о задаче ZWEKE.
Другой методологией проектирования является методология Scrum.
В процессе выполнения работы участники проектного процесса
проводят ежедневные 15-минутные встречи ZWEM, на которых
обсуждается результат работы 24-часового суточного спринта.
Проектировщики отчитываются о проделанной работе, и на диаграмме
выгорания Scrum появляется новая точка, характеризующая
произошедшее изменение трудоемкости остатка задач спринта. Таким
образом, к задачам Scrum выполнения проектных задач относится
15-минутная встреча ZWEM.
Эта задача включает в себя следующие подзадачи:
− обсуждение результатов работы за прошедший 24-часовой
спринт ZWEMR;
− добавление точки на диаграмму выгорания ZWEMP;
− обсуждение бэклога следующего 24-часового спринта ZWEMB;
− расчет метрик, изменяющихся при выполнении спринта ZWEMM.
265
Диаграмма вариантов использования задач Scrum в процессе
выполнения задач бэклога показана на рисунке 3.33.
Рис. 3.33. Диаграмма вариантов использования Scrum в процессе выполнения
проектных задач
Рассмотрим более детально задачу вычисления метрик. В процессе
работы над проектом могут быть вычислены как специфические метрики
Kanban и Scrum, так и любые другие метрики, вычисление которых
запрограммировано с использованием псевдокода. К базовым метрикам
Scrum, описанным в главе 2, относятся скорость работы
сотрудника (IV), скорость работы команды (TV), оценка
планирования (TD) и оценка стоимости (VD). К базовым метрикам
Kanban относятся время цикла (Cycle Time), работы в процессе (WIP),
время обработки (Lead Time), пропущенное время (Waste Time),
эффективность (Effectiveness) и пропускная способность (Throughput).
Все эти метрики не являются обязательными к вычислению, также они
могут быть дополнены другими метриками.
На рисунке 3.34 представлена диаграмма вариантов использования
для задачи вычисления метрик.
266
Рис.3.34. Диаграмма вариантов использования задач вычисления метрик
Рассмотренные выше задачи и задачи других потоков ПКУ
представляют собой системное образование, структура которого
приведена на рисунке 3.35.
Рис. 3.35. Поток работ ПКУ
267
При выполнении потоков работ ПКУ происходит формирование ряда
артефактов, схема которых представлена на рисунок 3.36.
Рис. 3.36. Взаимосвязи артефактов в ПКУ
3.7. Методики программно-картотечного управления Рассмотрим примеры методик выполнения работ ПКУ. В качестве
оного из примеров рассмотрим методику прерывания выполнения
задачи, выполняемой в соответствии с методикой, содержащей элементы
псевдокода. Данная методика представляется в виде диаграммы
активности, представленной на рисунке 3.37.
268
Рис. 3.37. Прерывание выполнения задачи
Из рисунка 3.37 видно, что выполнение данной методики
предполагает параллелизм выполнения. Однако выполнение всех этих
задач является программируемым, что не приводит к дополнительным
временным затратам проектировщика. Это позволяет выполнить
действия методики последовательно, без реализации параллелизма. Эту
методику можно представить в виде последовательности шагов, каждый
шаг которой может содержать вложенные шаги. 1. Сохранение сведений о прерванной задаче;
2. Вычисление приоритета прерванной задачи;
2.1. Поиск в очереди задач для выполнения той задачи, которая
имеет наибольший приоритет Pmax;
2.1.1. &dbqa& := QA_GetQAId(¤t_project&, "БД очереди");
2.1.2. &dbid& := OpenDB(¤t_project&, &dbqa&);
2.1.3. &userstr& := INTTOSTR(¤t_user&);
2.1.4. &sql& := "SELECT Приоритет FROM Очередь WHERE
Пользователь = ";
269
2.1.5. &sql& := STRCAT (&sql&, &userstr&);
2.1.6. &res& := ExecuteSQL (&sql&);
2.1.7. &nP& := DB_GETROWCOUNT (&res&);
2.1.8. &pcnt& = 0;
2.1.9. &pmax& = DB_GETCELLINT(&res&, 0, 0);
2.1.10. LABEL &pCycle&;
2.1.11. IF &pcnt& >= &nP& THEN GOTO &pFinal&;
2.1.12. IF DB_GETCELLINT(&res&, &pcnt&, 0) > &pmax&
THEN &pmax& := DB_GETCELLINT(&res&, &pcnt&, 0);
2.1.13. &pcnt& := &pcnt& + 1;
2.1.14. GOTO &pCycle&;
2.1.15. LABEL &pFinal&;
2.2. Вычисление приоритета прерванной задачи Pnew как Pmax +
Pn, где Pn – произвольный коэффициент, зависящий от
необходимости впоследствии добавлять задачи
2.2.1. &pNew& := &pMax& + Pn;
3. Помещение прерванной задачи в очередь с приоритетом Pnew;
4. Конец методики.
Шаг 2 данной методики выполняется как последовательность
псевдокодовых операторов языка LWIQA. В приведенном выше примере
эти операторы представлены как вложенные в шаги 2.1 и 2.2 действия.
В качестве другого примера методики можно взять методику
создания поручения. Представим эту методику в виде
последовательности шагов для их выполнения.
1. Просканировать отображения назначений задач на QA-дерево
и обнаружить новые задачи;
2. Для обнаруженной задачи отобразить окно создания нового
поручения;
3. Установить даты поручения;
270
4. Проверить по таблице Kanban, не возникает ли превышения
числа выполняемых задач на данном этапе проектной работы;
5. Указать зависимости исполнения этого поручения от
результатов выполнения других задач;
6. Установить исполнителя поручения;
7. Указать лиц, ответственных за контроль поручений;
8. Зарегистрировать поручения в структурах ПКУ;
8.1. Зарегистрировать поручение в QA-представлении таблицы
поручений;
8.2. Сформировать карточку на доске Kanban;
8.2.1. Зарегистрировать информацию о карточке Kanban в QA-
представлении доски Kanban;
Данная методика задействует сразу несколько компонентов системы
ПКУ и использует результаты работы этих компонентов. Представим
набор этих компонентов в виде UML-диаграммы компонентов,
представленной на рисунке 3.38.
Рис. 3.38. Компоненты ПКУ, задействованные в создании нового поручения
В некоторых случаях выполнение потоков работ системы ПКУ
можно представить в виде последовательности переходов из одного
271
состояния в другое. Например, процесс выполнения потока работ
проекта происходит поэтапно: 1. Сформировать бэклог этапа проектной работы;
2. Выполнить этап проектной работы;
3. Сформировать отчетов о выполненной работе.
Каждое из этих действий можно представить как состояние,
в котором находится группа проектировщиков. На рисунке 3.39
представлена диаграмма состояний для процесса выполнения этапа
проектной работы.
Рис. 3.39. Компоненты ПКУ, задействованные в создании нового поручения
3.8. Особенности реализации средств ПКУ
3.8.1. Общие особенности реализации средств ПКУ Комплекс средств ПКУ реализован в двух версиях среды
WIQA: − многопользовательская сетевая WIQA.Net;
272
− OwnWIQA, рассчитанная на одного пользователя.
Эти две системы объединяет то, что они содержат универсальные
для них инструменты выполнения псевдо кодовых программ на языке
LWIQA. На этом языке реализованы все структуры данных средств ПКУ
за исключением структур данных, хранящие в себе проект
и организационную структуру.
Подсистемы ПКУ объединяет то, что их реализация опирается
на следующие элементы:
− Описанная на языке LWIQAили отображаемая в QA-память
WIQAструктура данных подсистемы;
− Реализованный на LWIQAалгоритм работы подсистемы;
− Набор диалоговых окон, реализованный в виде дополнительной
подключаемой библиотеки для языкаLWIQA.
Такие подсистемы ПКУ, как Kanban, Scrumопираются на модель
организации, реализованной в виде оргструктуры WIQA.Net. Однако эти
инструменты могут быть применены не только для представления
работы групп проектировщиков, но также и для представления
индивидуальной работы проектировщика в том случае, если он
участвует в нескольких проектах, параллельно в нескольких проектных
группах или играет несколько ролей, выполняя проектные задачи.
Чтобы иметь возможность воспользоваться этими инструментами в
среде OwnWIQA, возникла необходимость в имитации оргструктуры в
этой среде. В этом случае корнем дерева оргструктуры становится сам
проектировщик, узлами дерева – группы, соответствующие его
проектам, группам и ролям.
273
3.8.2. Особенности реализации контроля поручений Общий вид дерева баз данных в вопросно-ответном протоколе
представлен на следующем рисунке:
Рис. 3.40. БД поручений в QA-памяти WIQA
Теперь перейдем к реализации процедурной части подсистемы
контроля поручений. В соответствии с использованием системы
управления поручениями, реализуется ряд псевдо кодовых функций,
каждая из которых ответственна за выполнение того или иного действия.
Пользователь в процессе работы с системой вызывает ту или иную,
необходимую ему в данный момент процедуру.
274
Псевдо кодовые процедуры, используемые в реализации приведены
в таблице 3.5.
Таблица 3.5. Псевдо-кодовые процедуры системы контроля исполнения поручений Название процедуры Описание &Получить_Индексы& Процедура отыскивает QA-индексы таблиц и
заголовков столбцов в псевдокоде и помещает их в переменные для быстрого доступа к ним. Эта процедура используется в других процедурах
&Добавить_группу& Добавление группы в таблицу групп &Добавить_субъект& Добавление сотрудника в группу &Создать_поручение& Создание поручения &Просмотр_поручений& Просмотр поручений, их состояний, отчетов
по поручениям &Редактировать_поручение& Редактирование поручений &Поиск_назначений& Поиск назначений в оргструктуре и
формирование на их основе новых поручений
Рассмотрим псевдо кодовую реализацию этих псевдо кодовых
процедур на примере процедуры &Просмотр_поручений&:
Процедура просмотра поручений и аналогичная ей процедура
редактирования поручений также выполнены как процедуры работы
с базой данных на расширенном языке LWIQA. Далее представлен код
этих процедур: Q 2.5 PROCEDURE &Просмотр_поручений&
Q 2.5.1 CALL &Получить_индексы& Q 2.5.2 &groups& := ExecuteSQL(&dbid&, "SELECT ID,
Названиегруппы FROM Группа") Q 2.5.3 &tasks& := ExecuteSQL(&dbid&, "SELECT ID,
Содержание FROM Поручение") Q 2.5.4 &Query& := AC_FINDTASK(&groups&, &tasks&) Q 2.5.5 &foundtasks& := ExecuteSQL(&dbid&, &query&) Q 2.5.6 &Query& := AC_SelectTask(&foundtasks&) Q 2.5.7 &task& := ExecuteSQL(&Query&) Q 2.5.8 &persons& := ExecuteSQL(&dbid&, "SELECT ID,
ФИО FROM Участник") Q 2.5.9 AC_VewTasks(&persons&, &groups&, &task&) Q 2.5.10 ENDPROC &Просмотр_Поручений&.
Данная процедура осуществляет вызов ряда функций, таких, как
AC_FINDTASK, AC_SELECTTASKS, AC_VIEWTASKS, которые
275
запрограммированы в виде дополнительной подключаемой библиотеки
TaskControlInt. Эти функции отвечают за отображение диалоговых окон,
причем в качестве входных параметров они используют результаты
SQL-запросов к БД поручений.
Рассмотрим реализацию дополнительной подключаемой библиотеки
TaskControlInt. В этой библиотеке реализованы следующие функции:
Таблица 3.6. Функции библиотеки отображения диалоговых окон системы
контроля поручений. Функция Описание AC_CREATEPERSON Окно добавления участника AC_CREATEGROUP Окно добавления рабочей группы AC_ADDTASK Окно добавления поручения AC_EDITTASK Окно редактирования поручения (окно
добавления поручения с измененным заголовком окна)
AC_VIEWTASK Окно просмотра поручения (Окно добавления поручения с измененным заголовком окна и с неизменяемыми полями)
AC_FINDTASK Окно поиска поручения по заданным параметрам
AC_SELECTTASK Окно выбора поручения
В качестве примера рассмотрим реализацию на языке C# функции
AC_SELECTTASK: public static string AC_SELECTTASK(string Tasks) { string[] sTasks = Tasks.Split(new string[] { "&&" }, StringSplitOptions.None); List<string> TaskIds = new List<string>(); List<string> TaskContents = new List<string>(); foreach (string sTask in sTasks) { TaskIds.Add(sTask.Split(new string[] { "||" }, StringSplitOptions.None)[0]); TaskContents.Add(sTask.Split(new string[] { "||" }, StringSplitOptions.None)[1]); } SelectTaskDialog std = new SelectTaskDialog(); std.SelectTaskBox.Items.AddRange(TaskContents.ToArray());
276
if (std.ShowDialog() == DialogResult.OK) { return "SELECT * FROM Поручение WHERE ID=" + TaskIds[std.SelectTaskBox.SelectedIndex]; } else return "CANCEL"; }.
3.8.3. Особенности реализации Kanban Реализация доски Kanban состоит из следующих двух основных
частей – главного окна доски и базы данных, содержащей информации
о задачах. Главное окно представляет собой пользовательский
интерфейс доски Kanban. В верхней части окна представлена
инструментальная полоса, а основное пространство окна занимает
визуализация доски.
Визуализация доски Kanban разработана как дополнительная
подключаемая библиотека функций языка LWIQA в реализации которых
используется совокупность классов, (назначение которых отражено
в таблице 3.7, а связность определяется диаграммой представленной на
рисунке 3.41. Таблица 3.7
Описание классов доски Kanban
Класс Описание ExtFunctions Основной класс дополнительной подключаемой библиотеки Task Класс-описание задачи. Этот класс соответствует записи в
таблице базы данных UserGroup Класс-описание группы разработчиков. Этот класс
соответствует записи в таблице базы данных Column Класс-описание колонки. Этот класс соответствует записи в
таблице базы данных CardAssoc Класс-описание ассоциации между задачей и колонкой. Этот
класс соответствует записи в таблице базы данных KanbanForm Класс основной формы средства визуализации доски Kanban BigCard Класс, представляющий собой визуальное отображение
раскрытой карточки, содержащей подробное описание задачи Card Класс, представляющий собой визуальное отображение
карточки доски Kanban DrawClass Класс, содержащий дополнительные графические функции
277
Рис. 3.41. Диаграмма классов доски Kanban
278
Основным классом дополнительной подключаемой библиотеки
является класс ExtFunctions. Далее подробно рассмотрим его элементы
в таблице 3.8. Таблица 3.8
Члены класса ExtFunctions
Тип Элемент Описание Поле LibName Имя библиотеки. «KanbanLib» Метод Kanban_SHOW Метод, отображающий доску Kanban по
результатам разбора запросов к базе данных, передающихся в метод в качестве параметров
Метод Kanban_QUERIESCOUNT Метод подсчета количества запросов изменения базы данных доски
Метод Kanban_GETTASKID По строке-результату выполнения Kanban_SHOW возвращает QAId задачи, который требуется открыть в интерпретаторе, или 0 – если не требуется открывать никаких задач
Метод Kanban_ROWSCOUNT Вспомогательный метод для заполнения базы данных доски Kanban по содержимому базы данных системы управления поручениями
Метод Kanban_GET_QUERY Получение запроса под указанным номером для изменения базы данных доски Kanban
При разборе строк-результатов запросов к базе данных
содержащаяся в них информация попадает в классы Task, UserGroup,
Column, CardAssoc. Рассмотрим элементы этих классов (табл. 3.9 –
3.12). Таблица 3.9
Члены класса Task
Тип Элемент Описание Поле id Идентификатор задачи в базе данных Поле id_TaskCtrl Идентификатор задачи в базе данных системы
управления поручениями Поле name Имя задачи Поле descr Подробное описание задачи Поле qaid QAId-идентификатор задачи в вопросно-ответном
дереве.
279
Таблица 3.10
Члены класса Group
Тип Элемент Описание Поле id Идентификатор группы в базе данных Поле number Номер группы Поле name Название группы
Таблица 3.11
Члены класса Column
Тип Элемент Описание Поле id Идентификатор колонки в базе данных Поле name Название колонки таблицы Поле max Максимальное количество карточек в колонке
Таблица 3.12
Члены класса CardAssoc
Тип Элемент Описание Поле id Идентификатор сопоставления задаче колонки в базе
данных Поле id_Task Идентификатор задачи Поле id_Col Идентификатор колонки, в которой находится
карточка Поле state Состояние выполнения задачи Поле id_Group Идентификатор группы, которой задача назначена Поле isChecked Карточка отмечена флажком или нет
Класс KanbanForm представляет собой класс основного окна
средства визуализации доски Kanban. Рассмотрим его поля и методы
(таблица 3.13). Таблица 3.13
Члены класса KanbanForm
Тип Элемент Описание Поле sAssocs Список ассоциаций Поле sColumns Список колонок Поле sGroups Список групп разработчиков Поле sTasks Список задач Поле Cards Двумерный массив карточек Поле RetVal Строка, содержащая выходное значение доски
Kanban. Здесь может быть QAId задачи, который требуется открыть в интерпретаторе, либо запросы к базе данных для изменения
Поле bigCard Объект, представляющий собой раскрытую карточку с подробным описанием задачи
Поле visibleGroups Список видимых групп
280
Поле bigCardText TextBox с текстом подробного описания задачи Поле kanbanPicture PictureBox, отображающий доску Kanban Поле curColumn Колонка с выделенной карточкой Поле curGroup Строка с выделенной карточкой Метод KanbanForm Конструктор. Подготовка окна и заполнение
структур данных Метод GetGroupPos Определение группы по порядковому номеру
ассоциации Метод GetCardText Определение имени задачи по порядковому номеру
ассоциации Метод GetCardDescr Определение детального описания задачи по
порядковому номеру ассоциации Метод GetCardQAId Определение QAId задачи по порядковому номеру
ассоциации Метод KanbanPicture_Pa
int Отображение доски Kanban
Метод KanbanPicture_MouseDown
Реакция на щелчок мышью. Определение нажатой клавиши, места попадания и соответствующая обработка события
Метод KanbanPicture_DoubleClick
При двойном щелчке на карточку открытие bigCard с детальным описанием задачи выделенной карточки
Метод ShowBigCard Показать bigCard Метод ScrollPanel_Scroll Определение смещения, возникшего из-за
скроллинга, и позиционирование элементов Метод DOCExport Экспорт содержимого выделенных карточек в
документ Microsoft Word
Классы BigCard и Card представляют собой визуальное отображение
карточек. Рассмотрим поля и методы этих классов (таблица 3.14). Таблица 3.14
Члены класса BigCard
Тип Элемент Описание Поле text Короткое текстовое описание (имя) задачи Поле descr Детальное текстовое описание задачи Поле x Положение карточки по оси абсцисс Поле y Положение карточки по оси ординат Поле qaid Идентификатор задачи в вопросно-ответном
протоколе Поле done Задача выполнена или нет Поле isChecked Карточка отмечена флажком или нет Поле backward Если true, то карточка отображается перевернутой Метод Show Этот метод делает карточку видимой Метод ReverseSwitch «Перевернуть» карточку Метод onCard Определяет, попадает ли точка, заданная
переданными в метод в качестве параметров координатами, в карточку
Метод onSwitch Определяет, попадает ли точка, заданная переданными в метод в качестве параметров
281
координатами, во флажок отметки карточки Метод onBackward Определяет, попадает ли точка, заданная
переданными в метод в качестве параметров координатами, на кнопку переворота карточки
Метод onOpenTask Определяет, попадает ли точка, заданная переданными в метод в качестве параметров координатами, на кнопку запуска интерпретатора для выбранной задачи
Метод Draw Отрисовка карточки
Для отображения карточек используется класс DrawClass,
содержащий следующие методы (таблица 3.15). Таблица 3.15
Члены класса DrawClass
Тип Элемент Описание Метод DrawRoundRect Отрисовка контура прямоугольника с
закругленными углами Метод FillRoundRect Заполнение цветом прямоугольника с
закругленными углами
База данных Kanban реализуется как вопросно-ответная
псевдокодовая база данных с целью облегчения доступа к ней
из разработанных на языке LWIQA средств управления потоками работ.
База данных содержит две таблицы: «Задачи» и «Ассоциации».
Далее представлены поля этих таблиц (таблицы 3.16 и 3.17). Таблица 3.16
Таблица «Задачи» БД Kanban
Поле Тип Описание Id [PK] Целое число Уникальный идентификатор записи id в поручениях Целое число Идентификатор этой задачи в базе данных
системы управления поручениями Описание Строка Название задачи Детальное описание
Строка Детальное описание задачи
QAId_задачи Целое число Идентификатор задачи в вопросно-ответном дереве
Таблица 3.17
Таблица «Ассоциации» БД Kanban
Поле Тип Описание Id [PK] Целое число Уникальный идентификатор записи id_задачи [FK] Целое число Идентификатор ассоциированной задачи
282
id_колонки Целое число Порядковый номер колонки, к которой относится задача
Состояние Целое число Состояние выполнения задачи: 0 – в процессе, 1 – готово
id_группы Целое число Идентификатор группы разработчиков из системы контроля поручений
Отметка Целое число 0 – задача не отмечена флажком, 1 – отмечена.
В вопросно-ответном протоколе эта база данных выглядит
следующим образом (рисунок 3.42):
Рис. 3.42. База данных доски Kanban
Для визуализации доски разработана псевдокодовая процедура
ShowKanban, выполняющая запросы к базам данных и вызывающая
функцию визуализации доски. Ниже представлен исходный код этой
процедуры: Q 2.2.1 PROCEDURE&ShowKanban&
//Поиск базы данных Kanban
Q 2.2.1.1 &dbqa& := QA_GetQAId(¤t_project&,
"БД_Kanban")
A 2.2.1.1.1 34183
//ОткрытиебазыданныхKanban
Q 2.2.1.2 &dbid& := OpenDB (¤t_project&, &dbqa&)
A 2.2.1.2.1 0
283
//ВыборвсейтаблицыЗадачи
Q 2.2.1.3 &tasks& := ExecuteSQL(&dbid&, "SELECT * FROM
Задачи")
A 2.2.1.3.1 ""
//ВыборвсейтаблицыАссоциации
Q 2.2.1.4 &assoc& := ExecuteSQL(&dbid&, "SELECT * FROM
Ассоциации")
A 2.2.1.4.1 ""
//Поиск базы данных системы контроля поручений
Q 2.2.1.5 &por_db& := QA_GetQAId(¤t_project&, "БД
поручений")
A 2.2.1.5.1 34067
//Открытие базы данных системы контроля поручений
Q 2.2.1.6 &pdbid& := OpenDB(¤t_project&, &por_db&);
A 2.2.1.6.1 1
//Выбор всей таблицы групп из БД поручений
Q 2.2.1.7 &groups& := ExecuteSQL(&pdbid&, "SELECT * FROM
Группа")
A 2.2.1.7.1 ""
//Вызов визуализации Kanban
Q 2.2.1.8 &res& := Kanban_SHOW (&tasks&, &assoc&, &groups&)
//Подсчет количества запросов изменения таблиц БД
Q 2.2.1.9&QCNT& := Kanban_QUERIES_COUNT(&RES&)
Q 2.2.1.10&ITER& := 0
Q 2.2.1.11 LABEL &L1&
Q 2.2.1.12 IF &ITER&>= &QCNT& THEN GOTO &L2&
//Выделение одного запроса
Q 2.2.1.13&QUERY& := Kanban_GET_QUERY(&RES&, &ITER&)
//Выполнение запроса
Q 2.2.1.14 ExecuteSQL(&dbid&, &QUERY&)
Q 2.2.1.15 GOTO &L1&
Q 2.2.1.16LABEL&L2&
//Если требуется – запуск интерпретатора для выбранной задачи
Q 2.2.1.17 QA_OpenInterpreter(¤t_project&, &res&)
Q 2.2.1.18 FINISH
Q 2.2.1.19 ENDPROC&ShowKanban&.
284
При вызове процедуры &ShowKanban& после осуществления
работы с базами данных происходит вызов функции Kanban_SHOW,
отображающей окно, представленное на рисунке 3.43. В данном окне
находится сетка, в которой по вертикали расположены группы
разработчиков, а по горизонтали – шаги выполнения задач. В ячейках
сетки располагаются карточки. Синий цвет соответствует задаче,
находящейся на данном этапе в состоянии работы, а зеленый –
завершенной на данном этапе задаче. Сверху имеется панель
инструментов. Окно содержит полосы прокрутки, при передвижении
которых происходит перемещение по доске. Выделение карточки
осуществляется при щелчке по ней мышью. Выделенная карточка
обводится пунктирной рамкой и отображается поверх остальных
карточек.
Рис. 3.43. Визуализация доски Kanban
285
Выбранная карточка раскрывается, как показано на рисунке 3.44.
Щелкая по иконкам внизу, можно открыть псевдокодовый
интерпретатор на выбранной задаче, отметить карточку или перевернуть
ее. На обратной стороне отображается дополнительная информация
о задаче (рисунок. 3.45).
Рис. 3.44. Раскрытая карточка Kanban
Рис. 3.45. Обратная сторона карточки Kanban
286
3.8.4. Особенности реализации Scrum Для реализации подсистемы Scrum была разработана псевдокодовая
база данных, а также набор псевдокодовых процедур, осуществляющих
взаимодействие подсистемы с пользователем. Пользователем в этом
случае может выступать как руководитель подразделения, так
и разработчик.
БД подсистемы Scrum представлена двумя таблицами. Одна из
таблиц – «Спринты» – представляет собой описание спринтов, вторая –
«ЛогСпринта» отображает бэклог спринта и динамику Scrum-процесса
(табл. 3.18 и 3.19). Таблица 3.18
Спринты
Колонка Описание ID Идентификатор спринта, первичный ключ Ответственный Идентификатор ответственного за спринт лица Наименование Текстовое наименование спринта Состояние Состояние спринта Дата Дата запуска спринта Коэффициент Коэффициент, используемый при расчете трудозатратности
задач и всего спринта, полученный в зависимости от характеристик команды
Таблица 3.19 ЛогСпринта
Колонка Описание ID Идентификатор записи в логе, первичный ключ Спринт Идентификатор спринта, к которому относится запись День Спринта Порядковый номер дня спринта, к которому относится
сделанная запись ID_задачи Идентификатор задачи, с которой связана запись StoryPoints Количество StoryPoints, на которое произошло изменение
Во время создания нового спринта в таблицу «Спринты»
помещается характеризующая его запись. Далее в таблице
«ЛогСпринта» формируется его бэклог. Для этого по каждой задаче
в «ЛогСпринта» вносится запись, в которой поле «Спринт» содержит
ссылку на созданный спринт. В поле «День Спринта» указывается
287
значение 0, поскольку эти значения оказались в логе спринта до начала
его выполнения. В поле «StoryPoints» записывается положительное
число, характеризующее вычисленную трудоемкость задачи.
Далее в процессе выполнения спринта ежедневно в «ЛогСпринта»
вносятся записи, характеризующие произошедшее изменение
трудоемкости задачи. При выполнении задачи в поле «StoryPoints»
записывается отрицательное число, по модулю равное трудоемкости
задачи. Таким образом, если спринт полностью выполнен, при
суммировании всех значений «StoryPoints» лога этого спринта должен
получиться ноль.
В таблице 3.20 представлены псевдокодовые процедуры,
обеспечивающие функционирование подсистемы Scrum,
с их предназначениями. Таблица 3.20
Процедуры подсистемы Scrum
Процедура Описание &AddSprint& Формирование нового спринта &ShowBurnout& Отображение диаграммы выгорания &AddTaskRes& Внесение изменений в оставшуюся трудоемкость задачи.
Используется для добавления в «ЛогСпринта» информации о выполнении задачи
&ShowSprintRes& Отображение результатов выполнения спринта, в том числе значений автоматически вычисляемых метрик
&ShowSprintInfo& Отображение информации о состоянии спринта. Эта процедура позволяет руководителю вносить изменения в статус спринта
Перейдем к описанию реализации процедур. В качестве примера
рассмотрим процедуру &ShowBurnout&, псевдокод которой
представлен следующим образом: Q 2.2.3 PROCEDURE&ShowBurnout&
Q 2.2.3.1 &dbqa& := QA_GetQAId(¤t_project&,
"БД_Kanban")
Q 2.2.3.2 &dbid& := OpenDB (¤t_project&,
&dbqa&)
288
Q 2.2.3.3 &tasks& := ExecuteSQL(&dbid&, "SELECT *
FROM Задачи")
Q 2.2.3.4 &assoc& := ExecuteSQL(&dbid&, "SELECT *
FROM Ассоциации")
Q 2.2.3.5 &sprints& := ExecuteSQL(&dbid&, "SELECT *
FROM Спринты")
A 2.2.3.5.1 ""
Q 2.2.3.6 &sprintlogs& := ExecuteSQL(&dbid&, "SELECT
* FROM ЛогСпринта")
A 2.2.3.6.1 ""
Q 2.2.3.7 &por_db& := QA_GetQAId(¤t_project&,
"БД поручений")
Q 2.2.3.8 &pdbid& := OpenDB(¤t_project&,
&por_db&);
Q 2.2.3.9 &groups& := ExecuteSQL(&pdbid&, "SELECT *
FROM Группа")
Q 2.2.3.10 &subj& := ExecuteSQL(&pdbid&, "SELECT *
FROM Субъект")
Q 2.2.3.11 &res& := Scrum_SHOWOUTBURN (&tasks&,
&assoc&, &groups&, &subj&, &sprints&, &sprintlogs&)
Q 2.2.3.12 FINISH
Данная процедура осуществляет вызов функции
Scrum_SHOWOUTBURN дополнительной подключаемой библиотеки
ScrumLib, реализующей пользовательские интерфейсы. В таблице 3.21
представлено описание всех реализованных в ней функций.
Таблица 3.21
Функции библиотеки ScrumLib
Функция Описание Scrum_ADDSPRINT Отображает пользовательские интерфейсы, отвечающие
за формирование спринта и его бэклога. Возвращает набор SQL-запросов для внесения новых данных в таблицы подсистемы Scrum
Scrum_SHOWOUTBURN Отображает окно, визуализирующее диаграмму
289
выгорания спринта Scrum_ADDRES Отображает окно добавления информации о
выполненной задаче спринта. Формирует SQL-запрос для отображения этого результата в таблице «ЛогСпринта»
Scrum_SHOWSPRINTRES Осуществляет вычисление метрик спринта и отображение информации о его выполнении
Scrum_SHOWSPRINTINFO Отображает окно с возможностью просмотра статуса спринта. При его изменении формирует SQL-запрос для внесения соответствующего изменения в таблицу «Спринты»
На рисунке 3.46 представлено окно, отображающее диаграмму
выгорания спринта.
Рис. 3.46. Окно отображения диаграммы выгорания спринта
3.9. Размещение компонентов ПКУ Комплекс средств ПКУ реализован в двух версиях среды WIQA –
многопользовательской сетевой WIQA.Net и однопользовательской
WIQA. В большинстве своем компоненты ПКУ являются
универсальными и используются в обеих средах за небольшими
отличиями.
Рассмотрим реализацию ПКУ в среде WIQA.Net. В этом случае среда
WIQA размещается на трех типах устройств:
290
− Сервер баз данных;
− Сервер WIQA.Net;
− Клиент WIQA.Net.
Сервер баз данных содержит СУБД MS SQL, в которую
отображается память WIQA для её хранения. Сервер WIQA.Net
взаимодействует как с базой данных, так и с клиентом, таким образом,
он является интерфейсом между клиентом WIQA и сервером баз
данных.
Устройство Клиент WIQA.Net отвечает непосредственно
за выполнение алгоритмов компонентов системы ПКУ. Клиент включает
в себя приложение WIQA клиент, а также ряд дополнительных
подключаемых библиотек, отвечающих за графический
пользовательский интерфейс псевдокодовых компонентов ПКУ:
− Дополнительная подключаемая библиотека GUI поручений;
− Дополнительная подключаемая библиотека GUI очередей;
− Дополнительная подключаемая библиотека GUI Kanban;
− Дополнительная подключаемая библиотека GUI Scrum.
Приложение WIQA-клиент содержит следующие компоненты,
связанные с функционированием ПКУ:
− Вопросно-ответный протокол;
− Демон отображения оргструктуры;
− Интерпретатор псевдокода.
Вопросно-ответный протокол применяется для создания, просмотра
и редактирования данных, хранящихся в QA-памяти WIQA, в том числе
– и задач проекта. Демон отображения оргструктуры осуществляет
преобразование оргструктуры в QA-формат и отображение её на QA-
память WIQA. Интерпретатор псевдокода позволяет выполнить
псевдокодовые алгоритмы ПКУ.
291
Теперь рассмотрим компоненты ПКУ, относящиеся к серверу WIQA.
Эти компоненты представлены тремя типами: QA-данные,
QA-программы (компоненты ПКУ, запрограммированные на языке
псевдокода), а также данные, не имеющие вопросно-ответной
структуры. Из используемых в подсистеме ПКУ к таким данным
относятся данные оргструктуры.
К серверным компонентам ПКУ относятся:
− QA-БД проекта – вопросно-ответное представление проекта,
с которым работают средства ПКУ;
− Оргструктура – представление данных оргструктуры в памяти
WIQA;
− QA-отображение оргструктуры – отображение, полученное
с помощью демона отображения оргструктуры;
− QA-БД поручений – QA-представление таблиц подсистемы
управления поручениями;
− Псевдокоды поручений – программные коды на языке LWIQA,
отвечающие за работу подсистемы поручений;
− QA-БД очередей – QA-представление таблиц подсистемы
управления очередями и прерываниями;
− Псевдокоды очередей и прерываний – псевдокодовая
программная составляющая подсистемы управления очередями
и прерываниями в ПКУ;
− QA-БД Kanban – QA-представление доски Kanban;
− Псевдокоды Kanban – алгоритмическое обеспечение Kanban;
− QA-БД Scrum – QA-представление данных Scrum;
− Псевдокоды Kanban – алгоритмическое обеспечение Scrum;
− Псевдокоды метрик – алгоритмы вычисления метрик Kanban
и Scrum.
292
Перечисленные выше компоненты ПКУ в среде WIQA.Net
объединены на диаграмме размещения, представленной на рисунке 3.47.:
Рис. 3.47. Диаграмма размещения компонентов ПКУ в среде WIQA.Net
Все эти устройства WIQA.Net могут находиться как на различных
физических машинах, объединенных с помощью сети, работающей на
основе протоколов TCP/IP, так и могут быть расположены на одной
машине. В системе WIQA.Net сервер баз данных и сервер WIQA.Net
находятся в единственном экземпляре, а клиентов может быть больше
одного, при этом для рационального использования средств ПКУ
293
количество клиентов WIQA.Net не должно быть меньше количества
участников проектного процесса – каждый участник взаимодействует со
всей системой ПКУ через клиента WIQA.Net.
На рисунке 3.48 схематично представлено взаимодействие
пользователей с системой ПКУ в многопользовательском режиме:
Рис. 3.48. Взаимодействие разработчиков и системы WIQA.Net
Перейдем к особенностям размещения компонентов ПКУ в среде
OwnWIQA. Эта среда предполагает работу в ней одного
проектировщика, и, соответственно, все её компоненты размещены на
одном устройстве. При этом теряется необходимость размещения
клиента WIQA и сервера WIQA в различных устройствах, что
294
позволяет объединить их функциональность в одном приложении. Среда
OwnWIQA не содержит в себе инструментария для работы
с оргструктурой, соответственно, в ней не требуется использования
каких-либо демонов для работы с ней. В то же время, для выполнения
программных средств ПКУ требуется наличие имитации оргструктуры,
реализованной в виде QA-модели оргструктуры, а также – набора
псевдокодовых инструментов для работы с ней. Для обеспечения
взаимодействия этих инструментов с пользователем была также
реализована дополнительная подключаемая библиотека GUI имитации
оргструктуры.
Кроме этого, для обеспечения взаимодействия между сотрудниками
был введен инструментарий синхронизации, обеспечивающий
синхронизацию данных ПКУ посредством репликации базы данных
WIQA.
Итак, компоненты клиента и сервера WIQA, которые были
исключены из набора компонентов ПКУ для реализации в среде
OwnWIQA:
− Оргструктура;
− Демон отображения оргструктуры;
При этом в объединенное приложение WIQA были добавлены
следующие компоненты:
− QA-БД имитации оргструктуры – вопросно-ответное
представление оргструктуры для обеспечения функционирования
средств ПКУ;
− Псевдокоды имитации оргструктуры – программные
компоненты, обеспечивающие работу с данными, имитирующими
оргструктуру;
295
− Синхронизатор – инструментарий, обеспечивающий
репликацию БД WIQA для обеспечения взаимодействия средств ПКУ
со средствами ПКУ других участников проекта.
− Кроме этого, была реализована ещё одна библиотека:
− Дополнительная подключаемая библиотека GUI имитации
оргструктуры.
Диаграмма размещения компонентов ПКУ в среде OwnWIQA
представлдена на рисунке 3.49.
Рис. 3.49. Диаграмма размещения компонентов ПКУ в среде OwnWIQA
296
Каждый участник проектного процесса в среде OwnWIQA работает
с собственным экземпляром машины WIQA, которые синхронизируются
между собой путем репликации их баз данных. Этот процесс показан на
рисунке 3.50.
Рис.3.50. Взаимодействие разработчиков и системы OwnWIQA
Выводы по третьей главе
1. Одной из специфик инструментария WIQA является то, что он способен выполнять функции оболочки, которая включается в приложения, разработанные в среде WIQA.
2. Оболочка, наследуемая приложением, адаптируется под его предметные задачи, исходя из двух версий ее интерпретации – интерфейсной и инструментальной.
3. Специфика инструментальной интерпретации заключается в том, что средства разработки приложений наследуются из комплекса WIQA как инвариантное ядро (комплекс базовых программных, обслуживающих концептуальное решение задач), к которому добавляются программные расширения, учитывающие специфику создаваемых приложений.
4. Инструментальный потенциал комплекса WIQA подтвердил свою полезность не только в приложениях к концептуальному
297
проектированию АС, но и в разработке ряда приложений с помощью этого инструментария.
5. В интерфейсной интерпретации QA-процессор выполняет функции посредника между активностями человека и компьютера, который настроен на построение и использование моделей QA-рассуждений, способствующих естественному программи-рованию, с одной стороны, и обслуживает запросы человека к компьютеру – с другой стороны.
6. В создании и совершенствовании комплекса WIQA использовалась его интерпретация как специализированной АС, архитектура которой интегрирует в единое целое совокупность точек зрения на комплекс, доведенных в системе WIQA до материального воплощения.
7. Комплексирование различных интерпретаций, материализацию которых логично считать режимами использования WIQA, приводит к использованию единообразных средств (ресурсов) в процессах взаимодействия проектировщиков с процессом концептуального проектирования АС, что не может не упрощать сложность взаимодействия.
8. Одно из важных приложений комплекса WIQA связано с управлением потоками работ в коллективном проектировании семейств АС.
9. Совокупность средств инструментария WIQA, обслуживающих управление процессами коллективного решение задач, ориентирована на программно-картотечные версии с использованием механизмов Kanban- и Scrum-управления.
10. Выбор программно-картотечных версий управления открывает возможность использования измерений, причём, как для потоков работ, так и для управления их исполнением, что способствует способствует их совершенствованию с позиций профессиональной зрелости .
11. Программная составляющая средств управления, встроенных в инструментарий WIQA, не только настроена на распраллеливание рпабот в группах проектировщиков, но и на псевдопараллельное решение задач каждым из членов группы..
298
Заключение Создание современных АС, интенсивно использующих ПО,
невозможно без наукоемкой профессиональной деятельности,
осуществляемой коллективно в компьютеризованных
инструментально-технологических средах. К исследовательской
специфике такой деятельности относится необходимость
экспериментирования с моделями структурных элементов АС и
процессов, в которых участвуют ее пользователи.
Инженерия АС носит принципиально эмпирический характер.
Разработчикам АС приходится, решая задачи, явно или неявно
экспериментировать с моделями предметной области АС в условиях
отсутствия достаточной компетенции в этой сфере. Следовательно,
профессионалам в области технологии необходимо приобретать
отсутствующую компетенцию, обучаясь на опыте, полученном при
решении ими предметных задач АС.
Более того, разработчикам АС следует повышать свою
профессионально-технологическую компетенцию, участвуя
в постоянном совершенствовании используемых ими технологий
и инструментов. В таких процессах возникает потребность регулярно
экспериментировать, применяя и развивая персональный
и коллективный опыт, а также его модели, подготовленные
к повторному использованию.
Экспериментируя в компьютеризованных средах, разработчикам АС
целесообразно использовать опыт научно-исследовательской
экспериментальной деятельности. В технологии разработок АС следует
внедрять методы и средства компьютеризации научно-исследовательской
деятельности, в первую очередь те, которые обслуживают
взаимодействие исследователей с опытом, – его приобретение,
моделирование, систематизацию и повторное использование.
299
Все это особенно важно для проектных организаций,
разрабатывающих наукоемкие АС и их семейства. В то же время
автоматизация взаимодействия разработчиков АС с доступным опытом в
современных технологиях разработок АС осуществляется в
недостаточной мере.
В монографии представлен программно-картотечный подход к
реализации проектного управления в разработках АС на этапе
концептуального проектирования системы. Выбор этого этапа обусловлен
тем, что он является наиболее проблематичным для разработок и
наименее обеспеченным инструментами для экспериментов с
моделями АС и процессами их создания.
Подход доведен до его материализации, в которую дополнительно к
псевдокодовому программированию «практик», применяемых в
решении проектных задач, включены картотечные механизмы,
заимствованные из технологий Kanban и Scrum, открывающие
возможности для экспериментирования в процессах управления
процессами решения задач.
В результате реализации подхода разработан комплекс средств
«Программно-картотечное управление», построенный на базе
инструментально-технологической среды WIQA.
Выбранные средства реализации согласованы с системой средств,
обеспечивающих создание и использование Базы Опыта проектной
организации, разрабатывающей семейства АС.
300
Библиографический список 1. Арлоу Д., Нейштадт А. UML 2 и Унифицированный процесс: Практический
объектно-ориентированный анализ и проектирование / Д. Арлоу, А. Нейштадт – СПб.: Символ-Плюс, 2007. – 624 с.
2. Архипенков С. Лекции по управлению программными проектами / С. Архипенков – М., 2009, 128 с.
3. Бергстрём С., Роберг Л. Rational Unified Process – Путь к успеху. Руководство по внедрению RUP/ С. Бергстрём, Л. Роберг Пер. с англ. – М. Бином, 2004, 256 с
4. Вольфсон Б. Гибкие методологии разработки : электронная книга. – 2012. – 112 c. [Электронный ресурс] URL: http://adm-lib.ru/books/10/Gibkie-metodologii.pdf (Дата обращения 25.12.2014)
5. Вумек Дж. П., Джонс Д. Т. Бережливое производство. Как избавиться от потерь и добиться процветания вашей компании [Книга] / Дж. П. Вумек, Д. Т. Джонс. - М.: Альпина Бизнес Букс. - 2004. - 473 с.
6. Гиббс Р.Д. Управление проектами с помощью IBM Rational Unified Process / Р.Д. Гиббс Практические уроки. – М.: КУДИЦ-ПРЕСС, 2007. – 277 с.
7. Книберг Х, Скарин М. Scrum и Kanban: выжимаем максимум [Книга] / Хенрик Книберг, Маттиас Скарин.- C4Media, 2010. - 78 с.
8. Книберг Х. Scrum и XP: заметки с передовой. - 2008 [Электронный ресурс] 9. Кон М. Scrum. Гибкая разработка ПО / М. Кон. – М.: Вильямс, 2013. – 576 с. 10. Кролл, П. Rational Unified Process – это легко: Руководство по RUP для
практиков / П. Кролл, Ф. Крачтен. – М.: КУДИЦ-Образ, 2004. – 427 с. 11. Ларичев, О.И. Теория и методы принятия решений / О. И. Ларичев. – М.: Логос,
2000. – 296 с. 12. Лебедев В.Н. Введение в системы программирования / В.Н. Лебедев. – М.:
Статистика, 1975. – 327 с. 13. Леффингуэлл, Д. Принципы работы с требованиями к программному
обеспечению. Унифицированный подход / Д. Леффингуэлл. – М.: «Вильямс», 2002. – 448 с.
14. Липаев, В. В. Системное проектирование сложных программных средств для информационных систем / В. В. Липаев. – М.: Синтег, 2002. – 268 с.
15. Норенков, И. П. Основы автоматизированного проектирования: учебник для вузов / И. П. Норенков. – М.: МГТУ им. Н.Э.Баумана, 2002. – 336 с.
16. Макконнел С. Сколько стоит программный проект / С. Макконнел. – СПб.: Питер, 2007. – 304 с.
17. Маклаев, В. А. Подход к представлению и оперативному использованию профессиональных активов проектной организации / В. А. Маклаев // Автоматизация процессов управления – № 1(23) –2011. – С. 5-12.
18. Маклаев, В. А. Представление активов программного обеспечения в репозитории базы опыта проектной организации / В. А. Маклаев // Автоматизация процессов управления – № 3(29) – 2012. – С. 50-55.
301
19. Маклаев, В.А. Нормативы профессиональной зрелости процессов разработки автоматизированных систем / В. А. Маклаев, А. А. Перцев – Ульяновск : УлГТУ, 2012. – 343 с.
20. Марка, Д. А., Методология структурного анализа и проектирования SADT / Д. А. Марка. – М.: Метатехнология, 1993. – 546 c.
21. Разработка программных проектов. На основе Rational Unified Process / Г. Поллис, Л. Огастин, К. Лоу, Д. Мадхар. – М.: Бином-Пресс, 2009. – 256 с.
22. Поспелов, Д. А. Логико-лингвистические модели в системах управления / Д. А. Поспелов – М.: Энергоатомиздат, 1981. – 231 с.
23. Поспелов, Д. А. Моделирование рассуждений. Опыт анализа мыслительных актов / Д. А. Поспелов – М.: Радио и связь, 1989. – 184 с.
24. Саати, Т. Принятие решений. Метод анализа иерархий. / Т. Саати. – М.: Радио и связь. 1993. – 347 с.
25. Соммервилл, И. Инженерия программного обеспечения / И. Соммервилл. – М.: Вильямс, 2002. – 624 с.
26. Соснин, П. И. Проблемно-ориентированные диалоговые среды / П. И. Соснин. – Саратов : СГУ, 1995. – 100 с.
27. Соснин, П. И. Человеко-компьютерная диалогика / П. И. Соснин – Ульяновск : УлГТУ, 2000. – 286 с.
28. Соснин, П. И. Архитектурное моделирование автоматизированных систем: учебное пособие / П. И. Соснин. – Ульяновск : УлГТУ, 2007. – 146 с.
29. Соснин, П. И. Вопросно-ответное моделирование в разработке автоматизированных систем / П.И.Соснин. – Ульяновск : УлГТУ, 2007. – 333 с.
30. Соснин, П. И. Концептуальное моделирование компьютеризованных систем: учебное пособие / П. И. Соснин. – Ульяновск : УлГТУ, 2008. – 198 с.
31. Соснин, П. И. Инструментальные средства для спецификации концептуализаций в проектировании автоматизированных систем / П. И. Соснин. // Онтология проектирования. № 2, 2012.
32. Хассан Гома. UML-проектирование систем реального времени параллельных и распределенных приложений / Г. Хассан. – М.: ДМК Пресс, 2011. – 704 с.
33. Abrahamsson P. Agile Software Development Methods: Review and Analysis / P. Abrahamsson, O. Salo, J. Ronkainen, J. Warsta. – VTT Publications, 2002.
34. Abmler S. W. Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process. – New York: Wiley Computer Publishing, 2002. – 402 c.
35. Assessment Maturity Model [Электронный ресурс] URL: http://www.assessment maturitymodel.org (Дата обращения 23.12.2014).
36. Basili, A.V. Implementing the experience factory concepts as a set of experience bases / A. V. Basili, M. Lindvall, P. Costa // In Proc. of the 13-th International Conference on Software Engineering & Knowledge Engineering, 2001, pp. 102-109.
37. Empirical Software Engineering Issues: Critical Assessment and Future Directions / V. Basili, H. D. Rombach, K. Schneider, B. Kitchenham, D. Pfahl, R. W.Selby // LNCS vol. 4336, Springer, 2006.
302
38. Borges, P. Mapping RUP Roles to Small Software Development Teams / P. Borges P, R. J. Machado, P. Ribeiro // In Proc. of International Conference on Software and System Process (ICSSP), Portugal, 2012, pp. 190-199.
39. Burger, J. Issues, Tasks and Program Structures to Roadmap Research in Question & Answering (Q&A)/ J. Burger // Tech. Rep. NIST, 2001.
40. Capability Maturity Model Integration (CMMI) [Электронный ресурс] URL: http://www.sei.cmu.edu/cmmi (Дата обращения 05.01.2015)
41. Charette, R. N. Why software falls / R. N. Charette // IEEE Spectrum, Vol. 42(9), 2005, pp. 36-43.
42. Cohn M. Prioritizing Your Product Backlog. – 2010 [Электронный ресурс] URL: http://www.mountaingoatsoftware.com/system/presentation/file/127/Prioritizing-Product-Backlog-Cohn-ADP2010.pdf (Дата обращения 25.01.2015)
43. Curtis, B. People Capability Maturity Model (P-CMM) Version 2.0 / B. Curtis, B. Hefley, S. Miller // Technical Report CMU/SEI-2009-TR-003, 2009.
44. David J. A. Kanban System for Sustaining Engineering on Software Systems. / J. A. David, R. Garber. – Corbis Corporation – 2007
45. David J. Kanban for Software Engineering. – 2009 [Электронный ресурс] URL: http://leanandkanban.files.wordpress.com/ 2009/04/kanban-for-software-engineering- apr-242.pdf (Дата обращения 24.01.2015)
46. Ghosh S. Enhance PMBOK® by Comparing it with P2M, ICB, PRINCE2, APM and Scrum Project Management Standards / S. Ghosh, D. Forrest, T. DiNetta et al. // PM World Today. – Jan 2012. – Vol. 14 Issue 1, Special section - p1-77.
47. Johnson P. Where’s the Theory for Software Engineering? / P. Johnson, M. Ekstedt, I. Jacobson // IEEE Software – September/October 2012 – P. 94-95.
48. Heiss, J. The Poetry of Programming / J. Heiss [Электронный ресурс] URL: http://java.sun.com /features/2002/11/ gabriel_qa.html (Дата обращения 08.01.2015)
49. Held, M. W. Structured collaborative workflow design, Future Generation Computer Systems/ M. Held, W. Blochinger. – Vol. 25(6), 2009, pp. 638-653.
50. Henninger S. Tool Support for Experience-based Software Development Methodologies / S. Henninger // Advances in Computers, Vol. 59, 2003, pp. 29-82.
51. Hirschman, L. Natural language question answering: the view from here / L. Hirschman, R. Gaizauskas // Natural Language Engineering, 2001, pp. 767-876.
52. Hollingsworth D. The Workflow Reference Model. Workflow Management Coalition, 1995. [Электронный ресурс] URL: http://www.wfmc.org/standards/docs/tc003v11. pdf (Дата обращения 24.01.2015)
53. Human-Computer Interaction: Overview on State of the Art / F. Karray, M. Alemzadeh, J. A. Saleh, M. N. Arab // Smart sensing and intelligent systems, 2008, Vol. 1(1), pp 138-159.
54. Kroll P. The Rational Unified Process Made Easy: A Practitioners Guide to the RUP / P. Kroll, Ph. Kruchten. // Addison-Wesley, 2003.
55. Larman C. Agile and Iterative Development: A Manager's Guide / C. Larman. – Addison-Wesley, 2004.
303
56. Marca, D. A. SADT: structured analysis and design technique/ D. A. Marca, C. L. McGowan // McGraw-Hill Co, 1988.
57. Mehta A. Programming as a mathematical discipline / A. Mehta [Электронный ресурс] URL: http://www.mathmeth.com/arm/arms/arm0.pdf (Дата обращения 05.12.2014)
58. Mettler, T. Maturity Assessment Models: A Design Science Research Approach / T. Mettler // International Journal of Society Systems Science Vol. 3(1.2), 2011, pp. 81-98
59. Murray A. PRINCE2® in one thousand words / A. Murray // Axelos Global Best Practice — 2011 [Электронный ресурс] URL: http://www.best-management-practice.com/gempdf/prince2_in_one_thousand_words.pdf (Дата обращения 15.01.2015)
60. Naur P. Computing: A Human Activity/ P. Naur // Selected Writings From 1951 To 1990. – ACM Press / Addison-Wesley, New York, 1992.
61. Pew, R. W. Some history of human performance models/ R. Pew // In W. Gray (Ed.), Integrated models of cognitive systems. New York: Cambridge University Press, 2007. pp. 29–47
62. Precedent [Электронный ресурс] URL: http://dictionary.reference.com/browse/ precedent. (Дата обращения 15.01.2015)
63. Question-Answering [Электронный ресурс] URL: http://www.wordiq.com/ definition/Question_answering.
64. Ras, E. Knowledge services for experience factories / E. Ras, J. Rech, S. Weber // In Proc. of the 5th Conference on Professional Knowledge Management, 2009, pp. 232-241.
65. Robertson, K. Project Management Maturity Model / K.Robertson [Электронный ресурс] URL: http://www.klr.com/white_papers/pdfs/pm_ maturity_model.pdf (Дата обращения 17.01.2015)
66. Roglinger, M. Maturity models in business process management / M. Roglinger, J. Poppelbuth, J. Becker // Business Process Management Journal, Vol. 18 (2), 2012, pp. 328 –346.
67. Rosenberg D. Agile Development with ICONIX process: People, Process and Pragmatism / D. Rosenberg, St. Matt and Collins. – Cop Mark. – 2005
68. Schwaber K., Beedle M. Agile Software Development with Scrum (Series in Agile Software Development) / K. Schwaber, M. Beedle. – Upper Saddle River : Prentice Hall. – 2001
69. Sjoberg, D. I. K. The Future of Empirical Methods in Software Engineering Research/ D. I. K. Sjoberg, T. Dyba, M. Jorgensen // In Proceeding of the 2007 workshop Future of Software Engineering (FOSE '07), 2007,- 358-378.
70. Sosnin, P.I. Question–answer analysis in concurrent engineering / Sosnin P.I. // In Proc. of Concurrent Engineering: The Vision for the Future Generation in Research and Applications, Portugal, 2003, pp. 961-964.
304
71. Sosnin, P. Question-Answer Processor for Cooperative Work in Human-Computer Environment/ Sosnin P.I. // In Proc. of the 2d International IEEE conference Intelligent System Varna, Bulgaria, 2004, pp. 452-456.
72. Sosnin, P.I. , Question-Answer System for Object-Oriented Analysis and Design/ P.I.Sosnin, E.P. Sosnina // In Proc. of 22nd Conference on Infomatio Technology in Constructio, Dresden, Germany, CIB W78, 2005, pp.199-204.
73. Sosnin, P. Question-Answer Modeling in Conceptual Design of Automated Systems/ P.I. Sosnin // In Proc. of the 13th IEEE Mediterranean Electrotechnical Conference – MELECON 2006, Malaga, Spain, 2006, pp.121-124.
74. Sosnin, P. Question-Answer Means for Collaborative Development of Software Intensive Systems / Sosnin P.I. // Collection of scientific paper Complex Systems Concurrent Engineering, Part 3, Springer London, 2007, 151-158.
75. Sosnin, P.I. Question-Answer Models of Decision-Making Tasks in Automated Designing/ P.I. Sosnin // In Proc. of the 22nd European Conference on Modelling and Simulation – ECMS’2008, Nocosia, Cyprus, 2008, pp. 173-180.
76. Sosnin, P. Question-answer programming and modeling in expert systems/ P.I. Sosnin // In Proc. of Artificial Intelligence and Applications – AIA’2009, Vienne, Austria, pp. 117-123.
77. Sosnin, P. Means of question-answer interaction for collaborative development activity/ P.I. Sosnin // Hindawi Publishing Corporation, Advances in Human-Computer Interaction , Volume 2009, Article ID 619405, USA, 2009, 18 pages.
78. Sosnin, P. Question-Answer Expert System for Ship Collision Avoidance / P. I. Sosnin // In Proc of 51st International Symposium ELMAR – 2009, Zadar, Croatia, 2009. pp.185-188.
79. Sosnin, P. Question-Answer Programming in Collaborative Development Environment/ P.I. Sosnin // In Proc. of The third IEEE conference Cybernetics and Intelligent Systems – CIS-RUM’2010, Singapore, 2010, pp. 273-278.
80. Sosnin, P. Question-Answer Shell for Personal Expert System/ P. I. Sosnin. - Chapter in the book “Expert Systems for Human, Materials and Automation.” Published by Intech, 2011, pp. 51-74.
81. Sosnin, P. Question-Answer Approach to Human-Computer Interaction in Collaborative Designing / P.I. Sosnin. Chapter in the book “Cognitively Informed Intelligent Interfaces: Systems Design and Development” Published IGI Global, 2012, pp. 157-176.
82. Spinuzzi, C. Context and consciousness: Activity theory and human-computer interaction/ C.Spinuzzi - Nardi, Bonnie (Ed.). Cambridge, MA: MIT Press, 1996.
83. The Standish group, Charting the Seas of Information Technology-Chaos, The Standish Group International, 1994.
84. Turley F. An Introduction to PRINCE2®. // Project Smart – 2009 [Электронный ресурс] URL: http://www.projectsmart.co.uk/docs/prince2-introduction-ps.pdf (Дата обращения 15.01.2015)
85. Williams G. Prince2 Maturity Model // AXELOS Global Best Practice — 2013 [Электронный ресурс] URL: https://www.axelos.com/Corporate/media/Files/
305
P3M3%20Model/ PRINCE2_ Maturity_ Model_ P2MM.pdf (Дата обращения 11.01.2015)
86. Workflow patterns. Distributed and Parallel Databases / Van der Aalst, A.H.M.Hofstede, B.Kiepuszewski, A.Barros. - 14, 2003, pp. 5–51.
87. Competency Maturity Model Wheel/ M.Von Rosing, S.Moshiri, K.Gräslund, A.Rosenberg. [Электронный ресурс] URL: http:// www.valueteam.biz/downloads/ model_cmm_wheel.pdf (Дата обращения 12.12.2014)
88. Wang J. X . Kanban : Align Manufacturing Flow with Demand Pull / J. X .Wang // Chapter in the book: Lean Manufacturing Business Bottom-Line Based. – CRC Press, 2010, pp. 185-204.
Стандарты:
1. ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы. – М.: Изд-во стандартов, 1990. – 18 с.
2. ГОСТ Р ИСО/МЭК 12207-99. Информационная технология. Процессы жизненного цикла - М.: ИПК Издательство стандартов, 2000. – 48 с.
3. ГОСТ Р ИСО 9004-2010 «Менеджмент для достижения устойчивого успеха организации. Подход на основе менеджмента качества» - М.: СТАНДАРТИНФОРМ, 2011 – 40 с.
4. ГОСТ Р 54869-2011. Проектный менеджмент. Требования к управлению проектом [Электронный ресурс] URL: http://docs.cntd.ru/document/gost-r-54869-2011 (Дата обращения 08.12.2014)
5. ГОСТ Р 52806–2007. Менеджмент рисков проектов. Общие положения [Электронный ресурс] URL: http://expert.gost.ru/ME/DOC/TXT_GOST_R_52806-2007.pdf (Дата обращения 08.12.2014)
6. ГОСТ Р 53892-2010. Руководство по оценке компетентности менеджеров проектов. Области компетентности и критерии профессионального соответствия [Электронный ресурс] URL: http://protect.gost.ru/v.aspx? control=8&page= 0&id=168699 (Дата обращения 08.12.2014)
7. ГОСТ Р ИСО/МЭК 12207. Информационная технология. Процессы жизненного цикла программных средств. – М.: Издательство стандартов, 2003.
8. ГОСТ Р ИСО 10006–2005. Системы менеджмента качества. Руководство по менеджменту качества при проектировании [Электронный ресурс] URL: http:// ohranatruda.ru/ot_biblio/normativ/data_normativ/46/46262/index.php (Дата обращения 11.01.2015)
9. IEEE Std 1471-2000. IEEE Recommended Practice for Architectural Description of Software-Intensive Systems. Institute of Electrical and Electronics Engineers, Sept. 2000. [Электронный ресурс] URL: http://www.win.tue.nl/~wsinmak/ Education/2II45/ software- architecture-std1471-2000.pdf (Дата обращения 10.01.2015)
10. ISO 15288:2002. – Systems Engineering – System Life Cycle Processes.
306
11. ISO/IEC 9126 – 1:2001 Software engineering – Product quality. 12. ISO/IEC-15408 «Критерии оценки безопасности информационных технологий»
(Evaluation criteria for IT security). 13. ISO 21500:2012. Руководство по управлению проектами. [Электронный ресурс]
URL: http://www.bureauveritas.com.ua/wps/wcm/connect/ef87c5e5-32b6-4aa3-a0ad-6d392dfe17ed/ISO+21500.pdf (Дата обращения 15.01.2015)
14. IEEE Std 1490-2011. IEEE Guide – Adoption of the Project Management Institute (PMI(R)) Standard A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) – Fourth Edition. [Электронный ресурс] URL: http://deltarobot.wikispaces.com/file/view/IEEE%20Std%201490.pdf (Дата обращения 25.12.2014)
15. CMMI® for Development, Version 1.3 : CMMI Product Team. — 2010 — November [Электронный ресурс] URL: http://www.sei.cmu.edu/reports/10tr033.pdf (Дата обращения 25.12.2014)
16. P3M3 Portfolio Model // AXELOS Global Best Practice — 2013 [Электронный ресурс] URL: https://www.axelos.com/Corporate/media/Files/P3M3%20Model /P3M3_Portfolio_Model.pdf (Дата обращения 26.12.2014)
17. P3M3 Programme Model // AXELOS Global Best Practice — 2013 [Электронный ресурс] URL: https://www.axelos.com/Corporate/media/Files/P3M3%20Model/ P3M3_Programme_Model.pdf (Дата обращения 26.12.2014)
18. P3M3 Project Model // AXELOS Global Best Practice — 2013 [Электронный ресурс] URL: https://www.axelos.com/Corporate/media/Files/P3M3%20Model/ P3M3_ Project_Model.pdf (Дата обращения 26.12.2014)
19. Organization project management maturity model (OPM3®) - Third Edition : Knowledge Foundation // Project Management Institute — 2003 [Электронный ресурс] URL: http://strelaconsult.com/upload/page/files/4_Organizational_Project_ Management_Maturity_Model_%28OPM3%29.pdf (Дата обращения 27.12.2014)
307
308
Обозначения и сокращения
AC Автоматизированная Система
CMMI Capability Maturity Model Integrated
GQM Goal-Question-Metrics
GOMS Goals, Operators, Methods and Selection rules
EF Experience Factory
MSF Microsoft Solution Framework
MHP Model of Human Processor
QA Question-Answer
RUP Rational Unified Process
SIS Software Intensive System
UML Unified Modeling Language
WIQA Working In Questions and Answers
Научное электронное издание
СОСНИН Петр Иванович ЛАПШОВ Юрий Александрович МАКЛАЕВ Владимир Анатольевич
СВЯТОВ Кирилл Валерьевич
ПРОГРАММНОЕ УПРАВЛЕНИЕ ПОТОКАМИ РАБОТ В КОМПЬЮТЕРИЗОВАННЫХ СРЕДАХ
Редакторы: О.П. Бояркина, К.А. Ларькина
ЭИ № 697. Объем данных 7,94 Мб.
Печатное издание ЛР № 020640 от 22.10.97.
Подписано в печать 25.12.2014. Формат 70100/16. Усл. печ. л. 24,83. Тираж 150 экз. Заказ 249.
Ульяновский государственный технический университет
432027, г. Ульяновск, ул. Северный Венец, д. 32. ИПК «Венец» УлГТУ, 432027, г. Ульяновск, ул. Северный Венец, д. 32.
Тел.: (8422) 778-113 E-mail: [email protected]
http://www.venec.ulstu.ru
–
–
–
–
–
–
–
–
–
–
–
–
