Содержание к диссертации
Введение
1. Методы планирования и управления проектами по разработке компьютеризированных средств обучения 10
1.1. Традиционные методы управления и планирования проектами 10
1.1.1. Задача управления проектами 11
1.1.2. Процедуры и техника планирования 12
1.1.3. Недостатки и проблемы традиционных методов 13
1.2. Общая характеристика проектов KCO/ISD 15
1.2.1. Эволюция проектов KCO/ISD 15
1.2.2. Инструментальные средства поддержки проектов KCOASD 19
1.2.3. Особенности и проблемы управления проектами по созданию КПО 19
1.2.4. Проблема переработки и распределения ресурсов . 21
1.3. Динамические модели в управлении проектами..., 22
1.3.1. Метод системной динамики 23
1.3.2. Управление проектами с динамической точки зрения „..26
1.3.3. Основные динамические подструктуры в управлении проектами 28
1.3.4. Использование системной динамики в управлении проектами ...30
1.3.5. Последовательность применения динамических моделей в управлении проектом 31
1.4. Выводы 33
2. Динамическая модель типичного проекта по разработке компьютеризированных средств обучения 35
2.1, Общая структура модели 35
2.1.1. Моделируемые фазы проекта и отображение процесса разработки 35
2.1.2. Границы модели и основные предположения 36
2.1.3. Подсистемы модели 37
2.2. Формальное описание модели проекта 38
2.2.1. Процесс разработки 38
2.2.1.1. Идентификация заданий 40
2.2.1.2. Обработка и переработка заданий 43
2.2.2. Подсистема ресурсов 48
2.2.2.1. Распределение ресурсов 49
2.2.2.2. Состав проектной группы , 50
2.2.2.3. Текущая производительность группы , 51
2.2.2.4. Выделение ресурсов 52
2.2.3. Подсистема контроля 54
2.2.3.1. Статус развития и предполагаемая производительность 56
2.2.3.2. Оценка объёма работ 58
2.2.4. Подсистема планирования 60
2.3. Адекватность модели 62
2.4. Выводы 63
3. Методика оценки объемов работ и переработки в проекте .64
3.1. Задача оценки объёма работ 64
3.1.1. Последовательность оценки в цикле управления 64
3.1.2. Предварительные предположения и исходная метрика 65
3.1.3. Оценка длительности, затрат и объёма работ 66
3.1.4. Планирование 67
3.1.5. Контроль и мониторинг 67
3.1.6. Пост-проектная оценка 69
3.2. Исследование и оценка объёма работ в типичном проекте 70
3.2.1. Спецификация проекта и основных параметров 70
3.2.2. Влияние структуры процесса разработки 71
3.2.2.1. Однофазный проект 71
3.2.2.2. Двухфазный проект.. 73
3.2.3. Влияние ресурсов. 76
3.2.3.1. Постоянное распределение ресурсов 77
3.2.3.2. Относительное распределение ресурсов 79
3.2.4. Показатели выполнения проекта в зависимости от вьщеленных ресурсов 81
3.3. Выводы 82
4. Практическое использование разработанной модели в интерактивной обучающей среде 83
4.1. Интерактивная обучающая среда 83
4.1.1. Цель обучающей среды 83
4.1.2. Требования к инструктору и студентам 84
4.1.3. Роли в проекте , 84
4.2. Структура интерактивной обучающей среды 86
4.2.1. Принцип построения и структура обучающей среды 86
4.2.2. Инструментальные средства и принципы разработки 88
4.2.3. Пользовательский интерфейс и принципы работы 98
4.2.4. Использование обучающей среды 100
4.3. Выводы 101
Заключение 102
Литература 104
Приложения 110
- Недостатки и проблемы традиционных методов
- Обработка и переработка заданий
- Относительное распределение ресурсов
- Принцип построения и структура обучающей среды
Введение к работе
Актуальность проблемы. Увеличение сложности и информативности образовательных программ и возрастание важности аспектов экономического характера определяют высокие требования как к процессу разработки, так и оперативности и качеству управления проектами по созданию обучающих программ. В настоящее время все большее распространение получают курсы и программы, использующие средства компьютерной поддержки, включая средства мультимедиа. Подобные программы часто именуются системами курсового программного обеспечения (КПО), а проекты по их созданию -проектами компьютеризированных средств обучения (КСО, в английской терминологии «courseware» или «Instructional Systems Development» - ISD проекты). Успешность решения проблемы управления подобными проектами напрямую зависит от того насколько глубоко и полно исследованы динамические характеристики процессов разработки проектов, насколько полны и адекватны используемые модели.
Компьютеризированные системы обучения требуют значительных и дорогостоящих разработок методического и программного обеспечения, что приводит к дополнительным сложностям нехарактерным для типичных проектов по разработке бизнес-ориентированного программного обеспечения. Концептуально процесс разработки обучающих программ достаточно хорошо структурирован и отлажен. Как правило, проекты KCO/ISD содержат несколько фаз процесса разработки, аналогичных тем, которые обычно описывают проекты по созданию программного обеспечения. Процессы разработки KCO/ISD последнего поколения описываются концептуальной моделью четвертого поколения - KCO/ISD . В этой модели вводится понятие итеративного процесса разработки в форме прототипов. Процесс разработки KCO/ISD проектов описан в терминах эволюции нескольких фаз: анализ — дизайн — производство — внедрение — поддержка, с постоянной ситуационной оценкой статуса развития в каждой из фаз. Фазы анализа и дизайна считаются наиболее критическими, сложными и дорогостоящими из всего процесса разработки курсового обеспечения. В ходе развития фаз могут происходить внутренние и внешние итерации работ/заданий, количество которых может меняться в зависимости от локальных условий и ограничений.
Определение количества возможных заданий и вероятного объёма переработки в проекте - одни из основных вопросов, возникающих в проектах KCO/ISD. Количество заданий изначально неизвестно, а определяется или идентифицируется по ходу проекта. В процессе разработки возможны неоднократные возвращения на предыдущие этапы и повторное выполнение работ не только в пределах одной фазы, но также между фазами. Количество возвращений во многом зависит от опыта и уровня знаний группы
разработчиков, которые, как правило, меняются в ходе разработки проекта. Большинство методов моделирования и планирования, используемых в управлении проектами, достаточно эффективно отражают структуру проектов и взаимосвязи различных фаз разработку но не динамику процесса разработки и не динамику рабочей группы. Поэтому для исследования динамики процесса разработки проектов необходимо создать и использовать модели, отражающие внутренние динамические характеристики и взаимосвязи в проекте.
Целью диссертационной работы является разработка системно-динамической модели развития и управления проектами создания КПО для оценки результатов принимаемых управленческих решений на основе имитации процесса разработки с учетом характеристик проекта и проектной группы.
Основные задачи, решаемые в работе:
Разработка системно-динамической модели процессов разработки и управления проектами по созданию КПО.
Разработка методов исследования и оценки объёмов работ в проектах КПО.
Исследование методов распределения ресурсов.
Разработка структуры обучающей среды с использованием' динамической модели для обучения руководителей проектов на основе имитации процесса разработки проекта.
Используемые методы. Для решения поставленных в работе задач используются методы системной динамики, элементы теории управления, интегрального и дифференциального исчисления, теории графов и теория познавательного обучения.
Научная новизна заключается в следующем:
Разработана системно-динамическая модель на основе концептуальной модели проектов четвертого поколения KCO/ISD, описывающая динамику процессов разработки проекта исходя из структуры причинно-следственных взаимосвязей между элементами процесса, состава и характеристик группы исполнителей, процессов планирования и управления для двух начальных фаз анализа и дизайна.
Разработана методика оценки объёма работ, сроков завершения и затрат на основе динамической модели проектов КПО. Формализована метрика, необходимая для связи с реальным проектом, включающая параметры и нелинейные характеристики проекта.
Исследовано на основе динамической модели влияние характеристик проектной группы и процесса разработки на появление и объем заданий требующих возврата
на предыдущие стадии процесса в пределах двух начальных фаз типичного проекта КПО. 4) Предложена методика планирования и мониторинга проекта на основе разработанной модели и методики оценки проекта.
На защиту выносятся следующие результаты:
Динамическая модель развития и управления фазами анализа и дизайна в проекте КПО, отражающая динамику процессов разработки, состава и характеристик группы исполнителей и управления.
Методика оценки объёмов работ и переработки, сроков завершения и затрат на основе динамической модели проектов КПО,
Полученные оценки влияния распределения ресурсов с учетом характеристик проектной группы и процесса развития на появление, объём и количество итераций заданий, требующих переработки, в пределах двух начальных фаз типичного проекта КПО.
Структура интерактивной обучающей среды, предназначенной для практического обучения технологиям распределения ресурсов в проекте.
Практическая значимость. На основе результатов диссертации была разработана интерактивная обучающая среда для обучения менеджеров проектов разработки КПО обеспечивающая приобретение навыков распределения ресурсов в процессе управления проектом. Основу работы составляют результаты исследований, проводимых по планам научно-исследовательских работ Института информатики и математического моделирования технологических процессов Кольского научного центра РАН в сотрудничестве с Институтом информационных наук Университета Бергена (Норвегия).
Реализация и внедрение результатов. Результаты исследований нашли практическое применение в следующих разработках, в которых автор принимал непосредственное участие:
Результаты работы использованы в проекте РФФИ № 02-07-90074 «Интеллектуальная система поддержки создания концептуальных моделей сложных систем и синтеза адекватных им имитационных моделей».
ИОС используется в рамках проекта «Изучение эффектов использования динамических моделей в обучающих программах» при группе «Информационные науки и технологии в образовании» (Educational Information Science and Technology) в Институте информационных наук Университета Бергена (Норвегия).
Апробация работы. Основные положения и некоторые результаты диссертационной работы докладывались и обсуждались на Международной конференции European Simulation
Mu/ticonference - ESA/'PS, (Manchester, England, 1998), Международной конференции J(f International System Dynamics Conference, (Quebec, Canada, 1998), Международной конференции European Concurrent Engineering Conference^ (Erlangen, Germany, 1999), Международной конференции EUROMED/A'PP (Mimchen, Germany, 1999), Международной конференции ENABLE'99, (Espoo, Finland, 1999), Международной конференции 7th European Con'current Engineering Conference^ (Leicester, United Kingdom, 2000), 14th European Simulation Mu/ticonference-ESM"2000, (Ghent, Belgium, 2000).
Публикации. По теме диссертации опубликовано 9 работ.
Структура и объем работы. Диссертация состоит из введения, четырех глав, заключения, списка литературы (77 наименований), имеет общий объем 159 машинописных страниц, содержит 22 рисунка и 10 таблиц. Приложение к диссертации содержит модели процессов разработки KCO/ISD (4 рисунка), диаграммы уровней и потоков (22 диаграммы), листинг уравнений модели и графики поведения, демонстрирующие результаты исследования в третьей главе (10 рисунков и 1 таблица).
В первой главе дается общая характеристика решаемой в работе проблемы. Рассматриваются задачи управления проектами, методы, используемые для планирования и управления проектами, выделяются их особенности и недостатки. Затем следует описание особенностей проектов по разработке компьютеризированных средств обучения (KCO/ISD), их эволюция, этапы разработки и специфические характеристики управления и развития, Вьщелепы проблемы и противоречия в использовании традиционных методов планирования и управления в применении к современному процессу разработки KCO/ISD.
Выделяется динамический характер управления проектом, в связи с чем рассматриваются методы системной динамики в применении к моделированию динамических аспектов развития и управления проектами. Рассмотрена техника интеграции и использования динамических моделей в управлении проектами совместно с традиционными методами. На основе выявленных недостатков выделены потенциальные улучшения, которые могут быть сделаны в процессе и средствах управления проектами по созданию компьютеризированных средств обучения.
Во второй, главе разрабатывается динамическая модель развития и управления проектами по созданию КПО, использующая в качестве теоретической основы модель четвертого поколения KCO/ISD . Структура управления проектом представлена в виде диаграммы, описывающей потоки информации между организационными подсистемами, входящими в процесс управления и разработки КПО. Каждой подсистеме соответствует модель уровней и потоков, которая отражает причинно-следственные связи между переменными, входящими в отдельные подсистемы. Разработанная компьютерная
имитационная модель, представляет собой систему нелинейных дифференциальных уравнений, интегрирование которых позволяет моделировать развитие и управление проектом во времени, при заданных параметрах характеризующих процесс разработки, организацию и руководство проектом,
В третьей главе описываются методы оценки и результаты исследования на основе системно-динамической модели проекта KCO/ISD . Сформулирована задача оценки объёма работ, показатели оценки и метрика проекта, параметризация модели. Исследование и оценка проекта разбито на два этапа. На первом этапе рассматривается влияние структуры процесса разработки на появление переработки, проводится анализ поведения однофазного и двухфазного проекта и выявляются факторы, определяющие динамику возникновения и итерации переработки в фазах проекта. На втором этапе рассматривается влияние ресурсов на появление переработки, изучается влияние методов распределения ресурсов, а также взаимодействие ресурсов со структурой процесса разработки. На основе исследования предлагаются наиболее подходящие методы использования и распределения ресурсов в фазах проекта. Формализуется метрика данных для согласования с реальным развитием проекта.
В четвертой главе в качестве практических результатов описывается создание интерактивной обучающей среды на основе построенной системно-динамической модели проектов КПО. Описываются цель, основные модули обучающей среды, их назначение и пользовательский интерфейс.
Недостатки и проблемы традиционных методов
Согласно исследованиям [12] в области информационных проектов, около 90% проектов не были успешно выполнены из-за перерасхода средств или отклонения от сроков. Более того, 33% проектов были прекращены до того, как дошли до стадии завершения. Примерно треть проектов, выполняемых мелкими, средними и крупными компаниями, сообщали о превышении бюджета в среднем на 150-200%. По срокам выполнени более чем треть из обследуемых компании сообщали о превышении сроков на 200-300%. Т.о., статистика свидетельствует о том, что методы и средства управления проектами используются недостаточно эффективно.
Традиционная практика управления проектами требует, чтобы операции были строго определены прежде, чем они могут быть запланированы или оценены [1,4]. Тем не менее, декомпозиция поставляемых продуктов, реализация которых заплаїіирована на будущее, не представляется возможной. Таким образом, всегда присутствует элемент неопределенности, обусловленный сложностями в определении и описании всех элементов и поставок проекта, а так же сущностью самого проекта как единовременного уникального усилия. На практике это означает, что при управлении проектом необходимо принимать во внимание постоянно меняющиеся условия проекта: производительность, количество и качество ресурсов, и соответственно корректировать существующий план [9], что позволит динамически контролировать развитие проекта. Контроль проекта обеспечивает информацию о статусе проекта, включая данные о достижение намеченных целей и задач, Традиционно развитие проекта определяется тремя величинами/мерами; временем, стоимостью и объемом работ. Прогресс, стоимость и отклонения от плана оцениваются сравнением фактически прилагаемых усилий использования ресурсов и стоимости с тем, что было выделено на выполнение задания бюджетом проекта, например, по методу освоенного объёма [5,7]. Однако контроль по объему выполнения является неадекватным средством при управлении сложными проектами [14-16], Проблемы заключается в недостатке видимости требуемых затрат, т.е. знании реальных издержек в определенный момент времени. Особенно трудно оценивать затраты на разработку, измерять прогресс и планировать развитие проекта для продуктов, которые являются сравнительно неосязаемыми в большинстве фаз разработки. К подобным продуктам относятся программное обеспечение [5] и КПО, Оценка объемов работы и меры прогресса являются критическими факторами для эффективного управления проектом [5,7,15]. Разработано немало моделей для оценки объемов работ, тем не менее, они оказывается весьма неточными. Проблема измерения достижений в проекте часто вызывается трудностью оценки статуса промежуточной работы, которая может быть вызвана как человеческими факторами, так и факторами обусловленными типом разрабатываемого продукта [5,15]. Первый тип факторов обусловлен тем, что люди имеют тенденцию сообщать благоприятную информацию о ходе развития и скрывать неблагоприятную, которая, однако, является критической, если необходимы какие-то корректировки. Второй тип факторов связан с осязаемостью и степенью идентификации создаваемого продукта.
Традиционные методы (СРМ, GERT, PERT и т.д.) не допускают возможности планирования появления необнаруженных ошибок, и связанного с этим повторного выполнения уже завершенных заданий. При этом затраты на повторное выполнение задания закладываются в предполагаемую оценку длительности его выполнения [14], Эти методы не могут описывать «сдвоенные циклы», обратную связь и итерации в системе, рассматривают проект как статический, и не могут отразить причины влияющие на процесс разработки. Эти методы не позволяют моделировать изменяющиеся во времени внутренние факторы, такие как квалификация персонала и его производительность, степень подготовки, задержки в распределении ресурсов, изменение опыта и т.п. Традиционные методы управления проектами являются линейными и статическими, поэтому для эффективного управления необходимы модели, учитывающие динамические аспекты развития на основе взаимосвязей между различными составляющими проекта. 1.2. Общая характеристика проектов KCO/ISD
Проекты KCO/ISD направлены на создание педагогических материалов (пособия, методические указания и т.п.). В этих проектах возможна разработка средств технологической поддержки обучения и создание комплексных сред обучения. Процесс разработки обучающих программ достаточно хорошо структурирован и отлажен [17]. В настоящее время обучающие программы все чаще используют средства технологической поддержки, включающие средства мультимедиа, а также средства компьютерной поддержки, и часто именуются системами курсового программного обеспечения (КПО - courseware), а проекты по их созданию - проектами компьютеризированных средств обучения (КСО, в английской терминологии Instructional Systems Development - ISD) [17, 18]. Соответственно такие системы требуют объемных и дорогостоящих разработок программного и курсового обеспечения, что составляет дополнительный уровень сложности, не характерный для типичных проектов по разработке бизнес-ориентированного программного обеспечения.
Процесс разработки КПО/KCO/ISD эволюционировал через несколько стадий характеризующих различные уровни сложности и использования различных технологий в разработке обучающих материалов и в управлении проектами по разработке KCO/1SD. Процесс разработки обучающей системы/программы обычно описывается с помощью так называемой инструкционной модели процесса разработки KCO/ISD, которая является концептуальной моделью последовательности разработки и описывает этапы деятельности в ходе разработки образовательного материала. Модели KCO/ISD также эволюционировали через несколько стадий от интуитивного процесса, который использовал простые линейные модели, к более сложному системному подходу [19]. В настоящее время в процессе разработки, реализации и оценки КПО используются методы системного проектирования, достижения теории управления [20], образовательные технологии [21], основы психологии [22, 18] и техника оценивания [23].
С эволюцией моделей KCO/ISD развивались и методы управления проектами КПО, принимая во внимание такие аспекты как: размер и состав группы, управление потоком работ, используемые технологии и контроль качества [24]. Проекты KCO/ISD, как правило, характеризуются несколькими фазами процесса разработки [18]. Эти фазы аналогичны фазам, встречающимся в моделях проектов по разработке программного обеспечения. Целью управления проектами КПО является минимизация риска при подходящей комбинации ресурсов и существующих ограничений для достижения максимального качества, минимальной стоимости и времени создания эффективного образовательного материала. Исходная роль разработчика, как автора и эксперта в предметной области (Subject Matter Expert - SME), теперь включает такие задания как управление проектом, проектирование системы, технологическая и техническая поддержка для проекта [17,19]. Структура {Рис. 1 -1 по 1 - 4) и характеристики поколений (Таблица 1-1) моделей процессов разработки KCO/1SD в соответствии с [17] приведены в Приложении 1.
Обработка и переработка заданий
Разработанная компьютерная имитационная модель представляет собой систему нелинейных дифференциальных уравнений, интегрирование которых позволяет моделировать развитие и управление проектом во времени при заданных параметрах, характеризующих процесс разработки, организацию и руководство проектом.
Моделирование процесса разработки КПО сосредоточенно на двух начальных фазах анализа и дизайна типичного проекта KCO/ISD . Как отмечалось, эти фазы считаются наиболее критическими, сложивши и дорогостоящими. Они содержат большое количество итераций и требуют наибольших затрат, в особенности экспертных знаний и услуг, из всего процесса разработки [52,55]. Так как идентификация является существенной частью процесса разработки, то полный процесс разработки состоит из следующих этапов (Рис. 6): идентификация, обработка, генерирование анализом заданий дизайна, опознавание и переработка неверно завершенных заданий. Процесс обработки или переработки ведет к завершению заданий либо верно, либо неверно. Ошибки, унаследованные дизайном из анализа, не могут быть обработаны правильно в дизайне и должны быть возвращены обратно в анализ. Диаграмма на Рис. 6 описывает поток работ и взаимосвязь заданий между фазами.
Границы модели отражают область и фокус модели. Наиболее важным ограничением является то, что моделируется процесс разработки только одного проекта. При этом предполагается устойчивость среды разработки, процессов и организации в ходе исполнения проекта. Т.е. величины внешних параметров и функций, которые описывают такие характеристики как минимальное время разработки заданий, время распределения ресурсов, время принятия решений и т.п., остаются постоянными в ходе всего проекта.
Необходимым ограничением является форма описания работ проекта. Фазы проекта, как правило, можно описать с точки зрения заданий или работ выполняемых персоналом, где под заданием понимается дискретная часть работы или специфической деятельности, для завершения которой необходимы определенные затраты ресурсов. Задание, т.о., можно определить как единицу работы имеющую, отчетливо выраженный объем, который, с точки зрения распределения ресурсов, измеряется в человеко-днях. Задания могут быть взаимозависимы как в пределах одной фазы, так и между фазами. Задания рассматриваются, как единое целое и предполагается, что они могут быть выполнены либо верно, либо неверно, т.е. задания не могут быть частично неверными. Данное предположение является основным отличием от других моделей проектов, в частности по созданию программного обеспечения [7,42]. В этих моделях задания описаны с точки зрения количества строк кода, а недостатки в завершенной работе ошибками в программном коде, т.е. задания могут содержать более чем одну ошибку. Количество недостатков или ошибок и, следовательно, необходимой переработки, характеризуется плотностью ошибок в коде. Переработка в программном коде может быть описана коррекцией единственной ошибки в строке, которая может потребовать небольших затрат, по сравнению с затратами на исходное задание (например, написание строки кода). В процессе разработки КПО неверное задание должно быть переработано полностью (например, проведение интервью с заказчиком или экспертом), что может потребовать затрат, сравнимых с исходными затратами на первоначальное завершение задания. Все последующие обращения к тому же заданию с целью исправления ошибок рассматриваются как переработка. Процесс опознавания выявляет задания, которые должны быть завершены заново или переработаны для корректировки недостатков. В разработанной модели нет деятельности, посвященной обнаружению недостатков, а предполагается, что разработка проекта ведет к обнаружению заданий, которые необходимо переработать. Данное предположение отражает отличительную особенность последнего поколения проектов KCOASD, а именно намеренное повторение заданий в виде прототипов.
Ресурсы проекта агрегированы и представлены только в форме рабочей силы, которая является основным источником затрат. Можно допустить, что другие ресурсы разработки, такие как, оборудование, административная поддержка, и т.п., используются в пропорции к рабочей силе в проекте [55]. Предположения можно обобщить следующим образом: - Разработка проекта состоит из двух фаз: анализа и дизайна. - Разработка проекта описывается потоком заданий в пределах фаз и между ними. - Заданием является идентифицируемая часть работы, требующая определенных ресурсов. Задания считаются гомогенным в требованиях ресурсов. - Задания могут быть обработаны либо верно, либо неверно. - Процесс разработки включает идентификацию, обработку, опознавание и переработку неверных заданий. - Идентификация заданий и опознавание неверных заданий не требует затрат ресурсов, но происходит по ходу развития проекта с тем, как компоненты системы становятся видимыми/осязаемыми. - Ресурсы проекта могут быть описаны только рабочей силой. - Затраты проекта задаются в человеко-днях. В соответствии с основными структурами, задействованными при управлении проектом и описанными в первой главе, модель состоит из следующих подсистем: процесс разработки, персонал/человеческие ресурсы, контроль и планирование. Подсистемы контроля и планирования отражают менеджмент (рукодство) проекта. Процесс разработки описывает физический поток заданий. При этом процесс разработки находится под влиянием человеческих ресурсов и управляющих воздействий менеджмента в ответ на информацию о ходе работы. Под воздействием менеджмента и человеческих ресурсов темп обработки заданий может изменяться в зависимости от типа и количества распределенных ресурсов.
Персонал реагирует на выдвигаемые руководством условия и текущее восприятие статуса развития проекта, прилагая время, знания и способности. Это приводит к определенной производительности в разработке проекта, которая определяет темпы обработки заданий. От персонала к менеджменту поступает информация о воспринимаемом объеме работ, которая оценивается руководством, приводя к возможным изменениям плана.
Руководство проекта контролирует процесс разработки, оценивая завершение заданий и, в соответствии с этой информацией, выделяет ресурсы для разработки согласно выбранным методам распределения ресурсов. Руководство оказывает давление на группу разработчиков (человеческие ресурсы) планируя время завершения и выделяя допустимое количество ресурсов для разработки (человеко-дни). Руководство проекта влияет на количество задействованных человеческих ресурсов, вводя дополнительных разработчиков или выводя незадействованных, а также распределяя ресурсы между различными видами деятельности. Руководство, основываясь на количестве завершенных и переработанных заданий, оценивает статус и процент выполнения проекта.
Относительное распределение ресурсов
Исследование динамики поведения однофазного проекта отображает основные процессы, происходящие в пределах разработки одной фазы. Структура однофазного проекта может быть представлена подсистемой модели, описывающей идентификацию и разработку заданий в фазе анализа. Рис. 4-1 приложения 4 демонстрирует пример поведения нескольких однофазных проектов: серия #0 соответствует безошибочному выполнению, серия #1 базовой и серия #2 запаздывающей функции доли верно обрабатываемых заданий /(FS/y см. Рис. 10, гл. 2. С точки зрения ресурсов, случай без возникновения переработки в фазе соответствует «идеальной» группе, которая не совершает ошибок, т.е. все задания проходят только через успешную обработку. Базовый случай нелинейной функции, может соответствовать группе с высоким уровнем экспертных знаний. Группа способна быстро распознать специфику проекта, поэтому доля успешно обработанных заданий быстро растет по мере развития проекта. Случай запаздывающей -кривой отражает позднее накопление опыта для группы, состоящей из неопытных разработчиков (кривая 2 на Рис. 10 гл. 2), показывая, что в начале проекта группа допускает больше ошибок и приобретает опыт очень медленно ближе к концу проекта. Результаты развития для трех случаев следующие:
Очевидно, что с понижением опыта растет количество неопознанной переработки, выражаемой в разнице между количеством предполагаемо завершенных и верно завершенных заданий (см. Рис. 4 - 1). Замедление реального прогресса ведет к более низкой идентификации заданий и соответственно меньшему количеству заданий в обработке. Максимум переработки приходится на момент верного завершения примерно 50% заданий (#1-31 день, #2 - 72 день), при этом оставшиеся задания обрабатываются за приблизительно одинаковое время (#1 - 127,5 дней, #2 - 138 дней), В обоих случаях за пиком переработки следует увеличение идентификации и соответственно рост заданий в обработке. Во всех трех случаях характерно, что на обработку порядка 20% заключительных заданий уходит более 50% времени разработки.
Исследуем влияние доли опознаваемых неверно обработанных заданий yfT ecJ (см. Рис. 11 гл. 2) на развитие однофазного проекта. Эта кривая, согласно [44], является одним из определяющих факторов цикла переработки и времени завершения проекта. Рассмотрим три случая, где эта функция принимается за постоянную величину и случай нелинейной зависимости от реального прогресса, но с предположением о более ранней способности группы к распознаванию неудач (кривая 2 на Рис. 11). Результаты обобщены в таблице 1.
Из результатов видно, что в каждом из случаев показатели завершения проекта лучше, чем в основном случае, как по времени завершения, так и по количеству переработки. При этом количество переработки более чувствительно к этой функции, чем время завершения. Использование ранней s-кривой ведет к почти 10% снижению появившейся переработки. Это может быть объяснено структурой процесса следующим образом: позднее опознавание переработки не позволяет проекту развиваться успешно, следовательно, доля заданий, которые обрабатываются неверно остаётся высокой в течение большего периода времени, генерируя больше переработки в фазе. Результаты согласуются с выводами в [44], о том, что более раннее опознавание переработки ведет к уменьшению времени завершения и к меньшему количеству переработки. Интересен результат дляJfj ecj= 0.9, что подразумевает быструю идентификацию неудач. Результат близок к минимальному времени завершения без переработки. Это можно объяснить тем, что переработка идет параллельно с обработкой без ограничений ресурсов и есть только небольшая задержка в опознавании неудач, ведущей к незначительной разнице двух случаев.
Исследуем влияние вероятности верной переработки Х2.23), которая характеризует долго правильно перерабатываемых группой разработчиков опознанных неверных заданий или эффективность и качество переработки. Рассмотрим три случая постоянной величины и случай нелинейной зависимости от реального прогресса, на основе функционального отношения доли успешно обработанных заданий (Рис. 10). Выполнение проекта оценивается по времени завершения 99% заданий, количеству переработки и среднему числу итераций переработки в проекте (#it). Количество итераций определено как отношение совокупной переработки (сколько всего заданий прошло через переработку) и успешной переработки. Результаты сведены в таблице 2. Очевидно увеличение переработки, появившейся в проекте, с соответствующим увеличением времени завершения. Для постоянных вероятностей переработки, количество итераций определяется как ffi=J/prob. Однако для случая нелинейной зависимости, количество итераций не может быть определено заблаговременно. Для нелинейного случая #it=l,104 итераций и означает, что 10,4 процента заданий были повторены неоднократно. Для целей оценки и планирования вероятность успешной переработки является показателем количества переработки, которая может возникнуть, и предоставляет возможность оценки необходимых ресурсов и времени завершения проекта.
Моделирование поведения двухфазного проекта отображает основные процессы взаимодействия между фазами. Первоначально считается, что все процессы разработки и переработки идут с максимально возможной скоростью и не зависят от количества распределенных ресурсов или других структур управления. При данном условии и выбранных характеристиках процесса (метрике) моделирование поведения показывает минимально возможное время завершения проекта СГ„,Я и объём работ GenTD и FrJ?wji .
Типичное поведение двухфазного проекта изображено на Рис. 4 - 2. В анализе на первом этапе идет начальная идентификация, обработка заданий и передача этих заданий в дизайн. Второй этап характеризуется медленной идентификацией новых заданий и, следовательно, небольшим количеством заданий в обработке. Уровень успешно обработанных заданий анализа стремится к насыщению. Это обусловлено пределом идентифицируемых заданий, так как новые задания нельзя идентифицировать из-за низкого реального прогресса, что вызвано высоким количеством неопознанной переработки. Конец этого этапа характеризуется увеличением заданий в опознанной переработке. Третий этап характеризуется завершением опознанной переработки, что позволяет продвинуть реальный прогресс. Это позволяет идентифицировать завершающие задания анализа и обработать их. В дизайне первый этап содержит сравнительно небольшое и постоянное количество заданий в обработке. На втором этапе обнаруживается большое количество неверных заданий, которые должны быть переработаны. Корректировка заданий ведет к опознаванию недостатков из анализа и новых заданий в дизайне.
Принцип построения и структура обучающей среды
Интерактивная обучающая среда «On Time, Within Budget» [72] представляет собой «кооперативную» имитационную игру по управлению исполнением проекта, созданную для использования в сетевом либо индивидуальном варианте. В сетевом варианте обучаемые/пользователи должны совместно завершить проект, выполняя одну из обозначенных ролей. В индивидуальном варианте пользователь (группа) выполняет одну из ролей, а остальные будут имитироваться компьютером в соответствии с заложенными в модель линиями поведения для каждой из ролей.
Интерактивная обучающая среда состоит из двух модулей: 1) вводный модуль с описанием целей и задач ИОС; 2) основной модуль проведения проекта. Для каждой из ролей в проекте создан индивидуальный файл, содержащий оба модуля, который загружается на компьютер, выделенный для соответствующей роли. Функцией вводного модуля является ознакомление пользователя с целями и задачами ИОС, требованиями к предварительным знаниям и навыкам. Этот модуль кратко описывает структуру проекта и составляющих фаз, стадии разработки заданий и условия завершения проекта, процесс разработки и управления человеческими ресурсами. Здесь также даются задачи и управляющие параметры участников проекта. Основной модуль предоставляет информацию на нескольких уровнях сложности описания отдельных секторов. В этом же модуле осуществляется связь между участниками проекта посредством обмена принятых решений, воспроизводится поведение проекта в соответствии с принятыми решениями и отображаются графически и численно результаты проекта. Структура ИОС является многоуровневой и организована по принципу нарастающей сложности [75], Общий подход, использованный при создании обучающей среды, использует познавательную учебную модель (cognitive apprenticeship model)1 [73], иногда социально ориентированную [74] (если не играть индивидуально с компьютером), с последовательно нарастающей сложностью материала. Познавательность осуществляется предоставлением пользователям индивидуального выбора необходимой информации и уровня сложности ее отображения. Принцип нарастающей сложности в среде осуществляется посредством создания трех уровней для объяснения аспектов управления проектом. Проблема управления разбита на несколько подструктур, в соответствии с подсистемами входящими, в процесс управления проектом: 1) сектор решений по распределению ресурсов - Human Resource Allocation, 2) сектор планирования проекта для управляющего проектом - Schedule, и блок сообщения установленных временных рамок для управляющих фазами - Calendar, 3) сектор информации о процессе разработки и потоке заданий — Tasks information, 4) сектор информации о рабочих ресурсах/персонале - Personnel information, 5) сектор информации о статусе развития или оценки прогресса - Progress Perceptions. Структура основного модуля ИОС изображена на Рис. 16. Она отражает пять секторов, указанных выше, и три уровня сложности, которые включают: символическое описание — первое от центра (Главный офис - Main Office) кольцо информации; причинно-следственные диаграммы - второе кольцо информации (ПСД/CLD); и упрощенные диаграммы уровней и потоков - внешнее кольцо информации (ДУП/SFD). Структура основного модуля обучающей среды «On Time, Within Budget» Интерактивность осуществляется посредством символического представления аспектов управления, обратной связи со стороны самой ИОС в виде графического и численного отображения результатов развития проекта и информационных сообщений, появляющихся в определенных условиях или на определенных стадиях проекта.
Пользователям ИОС предоставляется два режима взаимодействия с моделью: «Стратегический» и «Принятие Решений». «Стратегический» режим предоставляет возможность испытания некоторой линии поведения, делая предположения о поведении других участников. В режиме «Принятия решений» выбранные решения сообщаются всем участникам, и когда все участники предоставляют свои решения, модель воспроизводит поведение проекта на очередной период времени.
В качестве инструментального средства разработки ИОС использовалась програмная среда Powersim Constructor версии 2.5d. Кроме средств имитационного моделирования динамических систем данный пакет позволяет создавать пользовательский интерфейс «поверх» имитационной модели, а также сетевые версии обучающих сред для одновременного взаимодействия с моделью нескольких участников. Т.о., имитационная модель, которая для многих может оказаться сложной для понимания всех деталей, служит мнимой реальностью действительности, в данном случае - проекта, а пользовательский интерфейс представляет собой упрощенную картину «реальности», описываемой моделью. Задача состоит, с одной стороны, в приближении данной картины к реальности и действительно доступной информации, и, с другой стороны, в раскрытии структуры, обуславливающей поведение системы, и предоставлении дополнительной информации, способной подчеркнуть основные элементы структуры и соответствующего ей поведения.
На Рис. 17 в виде графа изображена схема передачи данных между компьютерами участников проекта через сервер локальной сети. Узлы представляют собой компьютеры участников и сервер (РМ, ATL, DTL, Server), а дуги использование и передачу информации.
