Содержание к диссертации
Введение
Глава 1. Обзор состояния проблем, методов, моделей и инструментальных средств предметной области «Управление проектом»
1.1. Современная нормативно-техническая документация 12
1.2. Методическое обеспечение «Управления проектом» 17
1.2.1. Модели, методы оценок программных систем 19
1.2.2. Классификация методов оценки разработки и управления разработкой ПС
1.2.3. Конкретные модели 20
1.2.3.1. Модель жизненного цикла ПС (SLIM) 20
1.2.3.2. Метод контрольных точек 22
1.2.3.3. Модели, связанные с функциональной оценкой процесса 23
1.2.4. Методы, основанные на экспертных оценках 34
1.2.5. Подходы, ориентированные на изучение законченных проектов 35
1.2.6. Динамические модели 3 8
1.2.7. Регрессионные модели 39
1.2.8. Смешанные подходы 41
1.3. Инструментальные средства процесса «Управление проектом» 43
1.4. Анализ проблем состояния моделей и инструментальных средств системы «Управления проектом» Основные результаты и выводы к 1 главе 57
Глава 2. Системная модель процесса «Управление проектом» программной инженирии
2.1. Предметная область: особенности и характеристики 58
2.2. Динамика процесса «Управление проектом» 70
2.3. Системная формализация 84
2.4. Методологические парадигмы системных задач управления проектом
2.5. Уровень систем данных «Управления проектом» 100
2.6. Порождающие системы с поведением 106
2.7. Упрощение системы «Управление проектом» уровня порождающих систем с поведением 115
Основные результаты и выводы ко 2 главе 129
Глава 3. Системные задачи структурированных систем «Управление проекто» 130
3.1. Идентификация переменных и параметров системных задач синтеза структурированных систем
3.2. Системы, подсистемы и суперсистемы процесса «Управление проектом» 139
3.3. Структурированные системы с поведением 146
3.4. Разрешение локальных несогласованностей 150
3.5. Проверка согласованности элементов через проекции функций поведения подсистемы 156
3.6. Определение коэффициентов реконструктивной нечеткости и идентифицируемости обобщенной системы 159
3.7. Формализация выбора несмещенной реконструкции 162
3.7.1. Задача реконструкции обобщенной системы 162
3.7.2. Условие неизбыточности 164
3.7.3. Формализация выбора несмещенной реконструкции системы 164
3.7.4. Постановка задачи оптимального выбора из реконструктивного семейства обобщенной системы по критерию максимума энтропии 167
3.7.5. Определение функций поведения для вероятностных и возможностных систем 171
3.7.6. Формализация перехода от системы данных к системам с поведением 173
3.7.7. Выбор из реконструктивного семейства - гипотеза о реальной системе
Основные результаты и выводы к 3 главе 193
Глава 4. Структура программных средств (ПС) «Иерархический метод синтеза системы «Управление проектом» 194
Основные результаты и выводы к 4 главе 199
Заключение 200
Список литературы
- Методическое обеспечение «Управления проектом»
- Динамика процесса «Управление проектом»
- Системы, подсистемы и суперсистемы процесса «Управление проектом»
- Постановка задачи оптимального выбора из реконструктивного семейства обобщенной системы по критерию максимума энтропии
Введение к работе
Актуальность работы. На начальных этапах формирования ИТ-стратегии (стратегии информационных технологий) возникает необходимость в определении не только функциональных, но и качественных и количественных требований к ИТ и системам. Количественная оценка результатов разных стадий и этапов проектирования систем дает возможности для контроля над ходом разработки или внедрения, оценки состояния проекта не только по стоимостным и временным параметрам, но и по возможности и степени достижения ожидаемых количественных характеристик систем и ИТ. На практике заказчики, раз- л работчики и пользователи сложных систем нередко оказываются не в состоя ний количественно оценить риски, вероятности выполнения в срок и с нужным качеством, стоящих перед ними технических задач и спрогнозировать соответствующие затраты. В основном это связано с тем, что ответы на подобные вопросы возможны лишь на основе системного моделирования процессов, происходящих в системе и вокруг нее. Но таких моделей всегда недостает, особенно универсальных моделей, которые могут быть применены для систем разных классов и на всех этапах их жизненного цикла. Одной из ключевых технологий, применяемой в ИТ-системах - это управление проектом, проектами, программами и организацией в целом.
Процесс управления проектом включает: j. - оценку стоимости, формирование планов и параметров проекта по данным вводимым пользователем;
управление действием и ресурсами, т.е. возможностями поддержки ввода пользователем данных для планирования проекта, данных о фактических действиях и анализа этих данных включая: планы, ресурсы компьютеров, персонал, бюджет и т.д., а также возможность условий выполнения проекта, включая календарный план; ц - управление тестовыми процедурами, т.е. возможность поддержки управления действиями по тестированию, регистрации результатов тестирования, генерации отчетов о состоянии тестируемых программ;
1V - управление качеством разрабатываемого ПС, т.е. возможность по лучать данные о качестве, генерировать отчеты об управлении качеством;
корректирующие действия, т.е. возможность управления действиями по корректировке проекта, включая отчеты о проблемах, возникающих в ходе выполнения проекта.
По мере развития информационных технологий, проблема создания и управления созданием опускается до уровня процессов, работ и задач с одной стороны, с другой - возникают новые проблемы: разработка средств управления созданием комплексными, полностью распределенными системами с по j всеместным использованием систем искусственного интеллекта и услуг, а так же построением и управления построением виртуальных пространств. Все это предопределяет значимость и актуальность исследования вопросов и задач процессов управления в проектах, процессах и работах.
В настоящее время многие задачи управления проектом, анализа и моделирования можно классифицировать по следующим направлениям:
- разработка бюджета проекта (важна точность общей оценки);
- анализ степени риска и выбор компромиссного решения;
- планирование и управление проектом;
- анализ затрат на улучшение качества программных средств. Подходя к решению этих задач обобщены в виде:
, \ - параметрических моделей;
- методов на основе экспертных оценок;
- методов основанных на изучении опыта выполненных проектов;
- динамических моделей;
- регрессионных моделей;
- смешанных Байесовских методов, сочетающих в себе элементы регрессионных моделей и моделей, основанных на экспертных оценках.
( Известно большое число исследований, затрагивающих различные вопро сы управления проектом, например Л. Путнэм (L. Putnam), К. Джонс, Г. Рубин (Н. Rubin), Р. Йенсен, Б. Боэм (В. Boehm), С. Макдонел (S. Мс Donell), Дж. М Форрестер (J. Forester) и др. Среди отечественных ученых это М. Каменнова, А. Крохин, М. Воропаев, Н. Мартынов, С. Бураков, А. Королев, М. Феропонтов, А. Баженов, А. Громов, А. Шмоталюк и др. К числу наиболее известных инструментальных средств управления проектом можно отнести SLIM, метод контрольных точек, COSMIS, ESTIMACS, SEER-SEM, SELECT, СОСОМО и СО-СОМО И, метод Дельфи и метод декомпозиции работ (МДР), нейронные сети, динамические модели Т. Абдель-Хамида, Open Plan и т.п.
Кроме того, к настоящему времени накоплен (пока еще не большой) опыт оценки качества управления отдельными проектами и проектного менеджмента і компании в целом, модели зрелости (SEI СММ, ESI, PMSolutions, модель Керц нера и РМІ ОРКіЗ). Деятельность международных организаций по стандартизации ИТ-систем охватывает и управленческую деятельность: ISO/IEC 9000-3-2000; IEEE 1220; EIA-632; ISO/IEC 15704; ISO/IEC 18529 и т.д. Однако в целом нормативно-техническая база не обеспечивает современных проектных требований стадий жизненного цикла изделия, т.к. степень обеспечения стандартами и доля творческого труда распределены по стадиям неравномерно. Наиболее стандартизованы и документированы рутинные этапы создания программных средств и систем. Отсутствуют детальные стандарты для творческих этапов системного анализа, предварительного и детального проектирования, на долю которых приходится 80% работ, а технические работы определяются не стан ,1 дартами, а инструкциями применяемых средств автоматизации проектирова ния. Также велик процент творческого труда на стадии интеграции, комплекс-1 ной отладки и испытаний ИТ-систем. Здесь степень стандартизации не превышает 50% и в значительной степени покрывается только общими положениями стандартов на жизненный цикл систем. В целом, в настоящее время, стандартизованы работы выполняемые большим числом специалистов относительно невысокой квалификации, и почти не стандартизованы особо творческие работы, .ц требующие наивысшей квалификации, такие как концептуальный выбор и оценка системы, синтез архитектуры, моделирование и анализ структуры системы и т.п.
Итак, несмотря на обилие методов и средств, задачи синтеза ИТ-системы, ее архитектуры, состава элементов и их согласованности являются актуальными и в настоящее время т.к.:
- данные по процессам разработки ИТ-систем и программных средств, скудны и неполны;
- классические статистические методы даже при использовании априорной и неэмпирической информации не всегда достигают цели;
- номенклатура параметров процессов расширяется за счет включения в эту номенклатуру новых критических параметров;
- тип временной шкалы, на которой разворачиваются процессы разработки, видоизменяются;
- возникает потребность корректно синтезировать архитектуру объекта на ранних стадиях;
- сложность и масштаб проекта увеличиваются;
- появляются новые типы интегрированных технологий типа CALS и CASE, которые вносят специфику в реализацию процессов управления проектом.
Таким образом, актуальность работы определяется необходимостью иметь в распоряжении руководителя проекта (владельца процесса) адекватный и мобильный инструмент системного синтеза и анализа работ и задач проекта на первых, наиболее критичных, фазах процесса разработки и управления, объединяющих преимущества нескольких уже существующих методик, разработки математического, программного и алгоритмического обеспечения, автоматизированных проектных процедур создания и управления созданием ИТ-систем.
Цель работы - сокращение сроков проектирования ИТ-систем, уменьшение расхода ресурсов и повышение качества проектных решений путем разработки математического и программного обеспечения средств моделирования и синтеза архитектурных решений ИТ-системы, анализа, сравнения и выбора систем, удовлетворяющих заданным ограничениям; синтез оптимальных проектных решений по уточнению архитектуры; решение задач оценки локальной со гласованности подсистем структурированной системы и снижения размерности ее модели.
Задачи исследования. Для достижения целей диссертационной работы необходимо решение следующих задач:
1. Постановка и формализация задачи синтеза в предметной области управления проектом как задачи общей теории систем.
2. Обоснование и выбор методологических особенностей предметной области управления проектом.
3. Формализация задачи синтеза как многоуровневого, иерархического представления видов абстракции, которые упорядочиваются посредством обобщения и специализации.
4. Разработка алгоритма порождения системы с поведением.
5. Разработка алгоритма оценки локальной согласованности элементов структурированной системы.
6. Разработка алгоритма упрощения порождающих систем с поведением.
7. Разработка модели и алгоритма решения задачи синтеза структурированной системы как многокритериальной задачи линейного программирования.
8. Инструментальная и программная поддержка моделей и алгоритмов синтеза.
Научная новизна. В диссертации получены оригинальные методы формализации и решения системных задач синтеза структур процесса «Управление проектом» программной инженерии, модели предметной области на разных иерархических уровнях описания, позволяющие существенно сократить сроки проектирования и повышения качества проектных процедур на различных фазах жизненного цикла системы, более точного и корректного выполнения требований технического задания. Все это позволяет также более полно и удобно описать проектируемую систему в терминах различных моделей, обеспечивая (vi адаптацию проекта к требованиям заказчика, различным моделям жизненного цикла, типу временной шкалы, минимизацию рисков и ошибок управления.
При проведении исследований в рамках диссертационной работы, получены новые научные результаты.
1. Разработаны системные модели процесса «Управление проектом» на разных эпистимологических уровнях иерархии видов.
2. Разработан аналитический метод порождения выборочных переменных системы эпистимологического уровня порождающих систем с поведением.
л 3. Разработан прямой метод синтеза обобщенной системы с поведени ем по элементам структурированной системы с поведением и обратный метод -синтез элементов структурированной системы по функции поведения обобщенной системы.
4. Разработан алгоритм локальной согласованности подсистем структурированной системы.
5. Разработан алгоритм снижения размерности исходных порождающих систем исходя из классов эквивалентности выборочных переменных.
6. Формализована и решена задача синтеза несмещенной оценки обобщенной системы как системная многокритериальная задача линейного программирования.
7. Результаты работы в форме алгоритмов реализованы программно в форме инструментария для управления проектом и зарегистрированы в фонде программ.
Достоверность научных положений определяется: корректностью полученных формул и алгоритмов, сравнением расчетных значений и результатов, полученных в практике создания СМК предприятия и реализации договоров ОКБ «Спектр». f \ Практическая значимость работы. На основе полученных результатов созданы инженерные методики и проектные процедуры синтеза системы «Управление проектом». Наибольшее применение они нашли в практике созда ния системы менеджмента качества (СМК) и системы управления проектной деятельностью ОКБ «Спектр». Адаптируемость, универсальность и легкость освоения делает возможным их широкое применение в управлении проектной деятельностью информационных систем типа СМК, систем управления логистикой и систем управления конфигурацией. Широкое применение разработанные средства нашли в учебном процессе при изучении курсов «Разработка САПР», «Программный инжиниринг», «Проектирование открытых информационных систем», «Информационное обеспечение», «Программный инжиниринг» и т.п.
Апробация работы. Результаты данной работы докладывались и обсуждались на 8 всероссийских и международных конференциях и семинарах, в том числе на конференциях «Гагаринские чтения» 1995г., 1996г.; «Научная сессия МИФИ» 2002г.; международных научно-технических конференциях «Космонавтика. Радиоэлектроника. Геоинформатика», Рязань 2000, 2003; «Проблемы передачи и обработки информации в сетях и системах телекоммуникаций», Рязань 2001, 2002,2004.
Публикации. По итогам исследований опубликована 21 работа, в том числе 3 статьи, 11 тезисов докладов, 2 программы зарегистрированные в Отраслевом фонде алгоритмов и программ.
Структура работы. Диссертация содержит 205 страниц основного текста и состоит из введения, четырех глав, заключения, библиографического списка из 93 наименований и приложений на 6 страницах. В диссертацию включено 72 рисунка, 37 таблиц.
Методическое обеспечение «Управления проектом»
Общемировой тенденцией развития инженерии информационных систем и программотехники - усложнение процессов фаз жизненного цикла систем и программных средств и особенно фазы разработки, где реализуется параллельно-последовательно целая сеть основных процессов (по классификации ГОСТ РИСО/МЭК 12207-99) вспомогательных и организационных. Среди вспомогательных (поддерживающих) процессов одним из важнейших, особенно для проектов средней и высокой размерности, является процесс «Управления проектом». Процесс управления проектом включает: оценку стоимости, формирование планов и параметров проекта по данным вводимым пользователем; управление действиями и ресурсами, т.е. возможностями поддержки ввода пользователем данных для планирования проекта, данных о фактических действиях и анализа этих данных включая: планы, ресурсы компьютеров, назначение персонала, бюджет проекта и т.д., а также возможность определения условий выполнения проекта, включая календарь, рабочие часы, выходные и праздничные дни; управление тестовыми процедурами, т.е. возможность поддержки управления действиями по тестированию, регистрации результатов тестирования, генерация отчетов о состоянии тестируемых программ; управление качеством разрабатываемого ПС, т.е. возможность поддержки ввода данных о качестве, их анализа и генерации отчетов об управлении качеством; корректирующие действия, т.е. возможность управления действиями по корректировке проекта, включая отчеты о проблемах, возникших в ходе выполнения проекта.
По мере развития информационных технологий проблема создания и управления созданием опускается до уровня процессов, работ и технологий с одной стороны, с другой - возникают новые проблемы: разработка средств управления созданием комплексными, полностью распределенными системами с повсеместным использованием систем искусственного интеллекта и услуг, а также построение, управление построением и создание виртуальных информационных пространств. Последние два направления были объявлены как приоритетные в Шестой Рамочной программе Европейского Союза по научным исследованиям и технологическому развитию (6 РП) и в программе «Электронная Европа» (e-Europe) и Российских инициатив по обеспечению НКТ (национальных контактных точек). Участок нашей страны в этой программе - в частности седьмой тематический приоритет 6 РП «Население и вопросы управления в обществе, основанном на знаниях». Все это предопределяет значимость и актуальность исследования вопросов и задач процессов управления в проектах, процессах и работах.
Актуальность этого поддерживается еще и тем, что существующая к настоящему времени нормативно-техническая база не обеспечивает потребности современных проектных требований стадий жизненного цикла изделия, т.к. степень обеспечения стандартами и доля творческого труда распределены по стадиям неравномерно. Наиболее стандартизованы рутинные этапы создания ПС и документирования ПС. Отсутствуют детальные стандарты для творческих этапов системного анализа предварительного и детального проектирования, на которых доля творческих работ составляет до 80%, а технические работы определяются не стандартами, а инструкциями применимых средств автоматизации проектирования. Также велик уровень творческого труда (79-80%) на этапах интеграции, комплексной отладки и испытаний ПС. Здесь степень стандартизации не превышает 50%) и в значительной степени покрывается только общими положениями стандартов на жизненный цикл ПС. Итак, в настоящее время стандартизованы работы, выполняемые большим числом специалистов относительно невысокой квалификации, и почти не (W, тельно невысокой квалификации, и почти не стандартизованы особо творческие работы, требующие наивысшей квалификации.
Модели поведения и управление проектом ПС зародились с методов оценки затрат на фазах жизненного цикла ПС. В настоящее время многие задачи управления, анализа и моделирования можно классифицировать по следующим направлениям: разработка бюджета проекта (важна точность общей оценки); анализ степени риска и выбор компромиссного решения; (г планирование и управление проектом; анализ затрат на улучшение качества программных средств. Сложившиеся в настоящее время подходы к решению этих задач обоб щены в виде: параметрических моделей; подходов, основанных на экспертных оценках; подходов, ориентированных на изучение опыта выполненных проектов; динамических моделей; регрессионных моделей; смешанных Байесовских подходов, сочетающих в себе элементы регрессионных моделей и моделей на основе экспертных оценок.
Динамика процесса «Управление проектом»
Проект - это временное предприятие, целью которого является создание уникального продукта или предоставление уникальной услуги. Проект включа ет в себя группу людей, ресурсы и события, имеющие следующие общие характеристики: основные цели: создание продуктов, оказание услуг и получение результатов; проект имеет известное начало и конец, т.е. ограничен во времени; проект не является частью обычной постоянной работы организации, т.е. проект имеет, как правило, уникальное требование. Некоторые организации (например, организации, занимающиеся исследованиями и разработкой) существуют только для выполнения проектов.
Второй важнейшей составляющей проекта, наряду с конфигурацией проекта, изложенной в ТЗ, является выбор модели жизненного цикла продукта (каскадная, пошаговая, спиральная модель). Выбор модели влияет на плановые периоды оценок и принятие решений, т. е. предопределяется выбор точек на временной шкале, представляющих плановые события, во время которых можно произвести корректировку курса выполнения проекта и определение текущего состояния масштаба и стоимости на будущее. Жизненный цикл проекта состоит из этапов, которые должны определяться в зависимости от масштаба требований, оценок ресурсов проекта и характера самого проекта. Более крупные проекты могут иметь множество этапов, таких как изучение концепции, разработка, производство, эксплуатация, снятие с эксплуатации. Этап разработки в свою очередь включает подэтапы: анализ требований, проектирование, изготовление, интеграция, верификация, валидация. В зависимости от стратегии разработки могут использоваться промежуточные этапы для создания прототипов, пошаговая реализация возможностей или циклы модели разработки по спирали. Контрольные точки основываются на событиях, в том числе и на календарных сроках или на критериях. Атрибуты и факторы, характеризующие гибкость возможностей управления, определяются на основе изучения атрибутов рабочих продуктов и задач. Такие атрибуты могут включать длительность выполнения задач, ресурсы, входные данные и выходные данные.
Рассмотрим более подробно вторую составляющую общих характеристик проекта, что обуславливается следующими соображениями: этой характеристике проекта уделяется наименьшее внимание, как в нормативных документах, так и в методологиях, хотя все процессы, задачи и работы разворачиваются во времени; последующие за «Планированием» участки процесса - «Мониторинг и контроль проекта» используют план как базис мониторинга работ с целью извлечения информации о состоянии проекта, измерения достигнутого прогресса по мере продвижения проекта по фазам и этапам жизненного цикла и последующего выполнения корректирующих воздействий, и от того, какова модель жизненного цикла изделия, зависит и временная шкала; системная формализация задач требует четкого и корректного определения и классификации временной шкалы по существующим в программотехнике критериям.
Это необязательно должны быть количественные изменения в привычном понимании. Это могут быть и количественные оценки, позволяющие судить о происходящих изменениях, об их динамике.
Согласно [12] существует пять типов шкал: 1. Номинальная шкала АЇ-Р(М), где F - любое взаимно однозначное состояние. Включает, например, классификацию типов программных ошибок (данных, управление). 2. Порядковая шкала где F - монотонно возрастающее отображение, т.е. М(х)= М(у) означает М/(х)= М/(у). Сюда входят всевозможные упорядочивания, например, программных сбоев по степени серьезности (незначительный, граничный, критический, катастрофический). 3. Интервальная шкала М =аМ+Ь (а 0). Сюда входят типы искусственной рейтинговой шкалы, например, рейтинговая шкала быстрого вопросни X ка по удобству применения; 4. Шкала отношений М =аМ (а 0). Сюда входят временные интер валы, например, время между программными сбоями, а также время между процедурами типа мониторинг, контроль, аудит, испытание и т.п. 5. Абсолютная шкала М =М. Сюда входят плотность и частота, например, плотность выявленных программных ошибок.
Рассматриваемая временная шкала, на которой разворачивается проект, является, согласно вышеприведенной классификации, шкалой отношений, т.е.-частным случаем номинальной шкалы. Без потери общности можно считать временную шкалу проекта номинальной.
В качестве примера приведем отображение процессов модели жизненного цикла эволюционной разработки программных средств на временную шкалу. Маркированные позиции обозначают реализацию работы или задачи. В случае необходимости это отображение можно получить и на более высоком уровне детализации [6].
Системы, подсистемы и суперсистемы процесса «Управление проектом»
Множества потенциальных значений переменных как {0,1} так и (0, 1, 2} частично упорядочены.
Так как в работе введены обобщенные переменные, трансформированные из конкретных переменных, которые в свою очередь в основном получены посредством соотношений фактических значений конкретных переменных к плановым, что в итоге влечет за собой значения шкал в относительно небольших пределах с одной стороны, с другой - потенциальные значения их ограничены множествами небольшой мощности, что позволит в дальнейшем упростить отслеживание и фиксацию динамики переменных и, соответственно, экономное хранение в памяти машины.
Все эти изменения накладывают некоторые особенности и на абстрагирование исходной системы объекта. В связи с чем, как указывалось ранее, введем три примитивные системы: систему объекта, конкретную представляющую систему и общую представляющую систему, которые вместе с отношениями между ними образуют исходную систему. Тогда, в дальнейшем к системе объекта (2.1), введем I- конкретную и 7- общую представляющую систему. Их компонентами являются уже не свойства и базы, а переменные и параметры. где обозначения те же, что и в формуле (2.1). Зададим отношение между систе мами 0,1,1 в виде полного канала наблюдений по одному для каждого свойства или базы из системы объекта. Для любых i&N„u jeNm свойство а\ соответ ствуетпеременным v;, v/} абаза- параметрам WJ,WJ.
Для практического использования обычно используют четкий канал наблюдения для баз Wj (особенно если В} - время, т.к. оно всегда контролируется исследователем), а для свойств применимы как четкие, так и нечеткие каналы наблюдения (О, и 0( ).
В рассматриваемом случае Vj, V2 , Уз ,К/, V5 У9,У и Уп » У із имеют четкий канал наблюдений, так как все переменные находятся под наблюдением и управлением администрации и исполнителями проектных работ.
Переменные Уб, У?, У&, Ую отнесем к переменным с нечетким каналом измерения. Обоснованность этого утверждения вытекает из вероятностного характера проявления этих свойств, что влечет то, что разрешающие формы, определяющие шкалу потенциальных значений переменных, не могут быть определены математически.
Для нижнего уровня методологические отличия определяются для уровня переменных и параметров. Методологические отличия - это вторичные критерии классификации системной задачи и, от того, как они определены, зависит адекватность системной задачи предметной области с одной стороны, с другой - достижение корректного решения задачи, да и разрешимость в целом. Методологические отличия имеют место не только для систем, но и для требований. Однако для систем они должны выбираться в первую очередь. Среди методологических отличий исследуемой системной задачи следует указать прежде тип шкалы параметра, относительно которого отслеживаются переменные.
Как уже было показано ранее, это номинальная шкала, относительно которой и отслеживаются значения вышеуказанных переменных, если у них четкий полный канал измерений. Если же нечеткий, то к потенциальному значению переменной необходимо добавить его достоверность исходя из номенклатуры идентифицированных переменных и функциональности системы "Управления проектом". Целесообразно её рассмотрение как структурированной системы (рис. 3.1).
Структурированная система - набор исходных систем, систем данных или порождающих систем, имеющих общее параметрическое множество, причем это множество вполне упорядочено.
Системы, образующие структурированную систему, называют его элементами. Некоторые переменные у них могут быть общими. Общие переменные обычно называются связывающими переменными. Они представляют взаимодействие между элементами. В соответствии с принятой классификацией [2, 10, 56, 58, 59] следует различать: структурированные исходные системы; структурированные системы данных; структурированные порождающие системы. Более частные типы структурированных систем: структурированные представляющие системы; структурированные системы с поведением; структурированные ST-системы.
Для структурированной системы любого из перечисленных типов существует связанная с ней система, определяемая всеми переменными, входящими в её элемент. Эта система называется полной системой или суперсистемой. Элементы интерпретируются как подсистемы полной или суперсистемы. Статус системы как полной не является абсолютным. Любая исходная система, система данных или порождающая система существует в двух «лицах». В одном контексте она имеет статус подсистемы, а в другом - статус суперсистемы. Рассматриваемый случай не исключение. Так, известно, что подсистемы, входящие в систему «Управление проектом» как на методологическом уровне, так и на уровне технологической реализации являются либо частью интегрированной системы, либо локальных систем «Конфигурационное управление», «Управление качеством» и т.п. Подобная двойственность дает возможность представить любую полную систему как иерархию структурированных систем, т.е. как структурированную систему, элементами которой являются структурированные системы, элементами которой также являются и т. д... вплоть до элементов, состоящих из отдельных переменных. Причин для подобного абстрагирования несколько: - если параметр - время, то иногда целесообразно наблюдать (измерять) все переменные, имеющие отношение к цели исследования. Можно собрать их частично для наиболее возможного подмножества переменных. В других случаях используются чужие данные, собранные разными людьми (специалисты по качеству, специалисты по конфигурационному управлению, специалисты по бюджету и т.п.); - сложность системы и, как следствие, её обозримость. Объём памяти компьютера лимитирует размерность полной системы. Так, в случае п переменных с к состояниями каждая, для запоминания состояния понадобиться nkn ячеек памяти, а уже при п=10 число ячеек памяти будет 10п. Число структурированных систем заметно меньше. Так, при п=10 и к=2 число бинарных подсистем 720, а полных систем 10308; -структурированная система дает сведения, не содержащиеся в соответствующей полной.
Постановка задачи оптимального выбора из реконструктивного семейства обобщенной системы по критерию максимума энтропии
Чтобы определить систему с поведением, представляющую заданную систему данных и обладающих подходящими дополнительными свойствами, необходимо для систем данных X с номинальными данными и Y — множество всех систем с поведением с вероятностными или возможностными функциями поведения, совместимыми с X, задать набор требований Q. Этот набор должен состоять из подмножества Yr множества N, определенного пользователем (либо по умолчанию); требования, чтобы несогласованность между соответствующими переменными заданной системы данных и системы с поведением была минимальной из множества Уд, требования, чтобы степень неопределенности при порождении данных системой с поведением из подмножества YQ была как можно меньше; требования, чтобы система из подмножества Уд была как можно проще.
Среди четырех требований, второе - наиболее предпочтительное, а для детерминированной системы она единственна и решается полным перебором данных с помощью маски без памяти и определения для каждого состояния выборочных переменных с (для маски без памяти они совпадают с основными переменными) числа N(c) появления в данных. Это частоты состояний с. Они и есть числа, используемые для вычисления функций вероятностей или возможностей. Если вероятности рассматривать как характеристики данных, то относительные частоты — отклонение N(c) к общему числу имеющихся выборок из данных по выбранной маске N(a):
Для нечетких каналов измерения простой подсчет N(c) невозможен, поэтому здесь учитывается еще степень достоверности агрегатирующей отдельных степеней достоверности. Степень достоверности для четких данных равно либо 0, либо 1. а: [0, 1]2- [0, 1] Функция а называется агрегатирующей функцией отдельных степеней достоверности d itje , связанной с компонентами с.
Простые примеры агрегатирующих функций являются а{х, у) = ху и а(х, у) = min(jc у), aCiW идентифицируется значением параметра w и состоянием сеС. Эти значения суммируются для каждого с. Полученные числа аналогичны частотам N(c), но называются псевдочастотами (так как нецелые). Итак, W где суммирование осуществляется по всем содержательным выборкам данных, каждая соответствует значению параметра w, определяемому положением справочника используемой маски на параметрическом множестве. После вычисления псевдочастот их используют в вышеприведенных формулах.
В данные (переменные) сложно вводить дополнительную информацию, в частности ограничения на переменные. Например, требование - переменная качества должна иметь значение 1 в соответствии со стандартами ISO 900Х/2000, или индекс бюджетирования должен быть также равен единице, так как работы по проекту в обоих случаях будут просто остановлены.
Берем систему данных «Управления проектом» и соответствующую маску, форма которой была обоснована ранее, при 18 значениях параметра спра вочника и 13 базовых переменных, область значений которых и характер измерения указан в предыдущем изложении (рис. 3.8).
Задаем систему данных D с полностью упорядоченным параметрическим множеством и с наибольшей допустимой маской М, совместимой с D. Ставится задача определить все системы с поведением, удовлетворяющие условиям согласованности, детерминированности и простоты. Причем требования согласованности имеют более высокий приоритет, чем остальные. На структурном уровне можно определить подходящим образом (будет рассмотрено далее) функции поведения как обобщенной системы по заданным функциям поведения подсистем, так и решить обратную задачу - по функциям поведения обобщенной системы определить функции поведения подсистем. Таким образом, для заданной функции , определенной через полные состояния неких выборочных переменных, любая из ее проекций также является функцией поведения, основанной на определенном подмножестве выборочных переменных. Пусть SK (к є N,M,) - выборочные переменные, определяющие (для маски М). Пусть Од JZ] - проекция Уд, для подмножества множества N(A/) идентификаторов выборочных переменных, т.е.ZcN. Тогда \/АА- 3,-Ф.і], KeZ так что [fB±z\x) = a[f(c)\cyx], где а - агрегатирующая функция, определяемая характером функции /в. Для распределений вероятностей эта функция следующая
Далее будем обозначать % функции поведения для наибольшей маски М. Остальные соответственно через %(/=2,3,4...) обозначим функции поведения ма сок подсистем М, каждая из которых связана с множеством Z d N идентификаторов выборочных переменных.
