Какие шаги следует проделать чтобы создать компьютерную модель проекта

Обновлено: 03.07.2024

Моделирование является одним из способов познания мира.

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

Для различных явлений и процессов бывают уместными разные способы моделирования с целью исследования и познания.

Объект, который получается в результате моделирования, называется моделью . Должно быть понятно, что это совсем не обязательно реальный объект. Это может быть математическая формула, графическое представление и т.п. Однако он вполне может заменить оригинал при его изучении и описании поведения.

Хотя модель и может быть точной копией оригинала, но чаще всего в моделях воссоздаются какие-нибудь важные для данного исследования элементы, а остальными пренебрегают. Это упрощает модель. Но с другой стороны, создать модель – точную копию оригинала – бывает абсолютно нереальной задачей. Например, если моделируется поведение объекта в условиях космоса. Можно сказать, что модель – это определенный способ описания реального мира.

Создание модели.
Изучение модели.
Применение результатов исследования на практике и/или формулирование теоретических выводов.

Видов моделирования огромное количество. Вот некоторые примеры типов моделей:

Математические модели . Это знаковые модели, описывающие определенные числовые соотношения.

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

Имитационные модели. Позволяют наблюдать изменение поведения элементов системы-модели, проводить эксперименты, изменяя некоторые параметры модели.

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

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

Компьютерное моделирование – это в определенной степени, то же самое, описанное выше моделирование, но реализуемое с помощью компьютерной техники.

Для компьютерного моделирования важно наличие определенного программного обеспечения.

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

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

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

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

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

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

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

К разряду сложных систем относятся крупные технические, технологические, энергетические и производственные комплексы.

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

методом синтеза оптимальной структуры системы с заданными характеристиками;
методом анализа различных вариантов структуры системы для обеспечения требуемых технических характеристик.

Оптимальный синтез систем в большинстве случаев практически невозможен в силу сложности поставленной задачи и несовершенства современных методов синтеза сложных систем. Методы анализа сложных систем, включающие в себя элементы синтеза, в настоящее время достаточно развиты и получили широкое распространение.

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

Среди известных методов анализа показателей эффективности систем и исследования динамики их функционирования следует отметить:

аналитический метод;
метод натуральных испытаний;
метод полунатурального моделирования;
моделирование процесса функционирования системы на ЭВМ.

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

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

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

Исследование функционирования сложных систем с помощью моделирования их работы на ЭВМ помогает сократить время и средства на разработку.

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

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

Основными этапами метода имитационного моделирования являются:

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

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

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

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

Следует, однако, помнить, что метод имитационного моделирования является численным методом. Его можно считать распространением метода Монте-Карло на случай сложных систем. Как любой численный метод, он обладает существенным недостатком – его решение всегда носит частный характер. Решение соответствует фиксированным значениям параметров системы и начальных условий. Для анализа системы приходится многократно моделировать процесс ее функционирования, варьируя исходные данные модели. Таким образом, для реализации имитационных моделей сложной модели необходимо наличие ЭВМ высокой производительности.

Для моделирования системы на ЭВМ необходимо записывать моделирующий алгоритм на одном из входных языков ЭВМ. В качестве входных языков для решения задач моделирования могут быть с успехом использованы универсальные алгоритмические языки высокого уровня, Си, Паскаль и др.

Анализ развития наиболее сложных технических систем позволяет сделать вывод о все более глубоком проникновении ЭВМ в их структуру. Вычислительные машины становятся неотъемлемой, а зачастую и основной частью таких систем. Прежде всего это относится к сложным радиоэлектронным системам. Среди них различные автоматические системы, в том числе системы автоматической коммутации (электронные АТС), системы радиосвязи, радиотелеметрические системы, системы радиолокации и радионавигации, различные системы управления.

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

На этапах разработки, проектирования, отладки и испытания сложных систем с высоким удельным весом аппаратно-программных средств вычислительной техники ставится задача анализа и синтеза вариантов организации структуры аппаратных средств, а также разработки и отладки специализированного ПО большого объема. Эта задача может быть решена с помощью аппаратно-программного моделирования с использованием универсальных моделирующих комплексов, построенных на базе однородных ВС с программируемой структурой.

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

Разработка аппаратно-программных моделирующих комплексов является сложной технической задачей. Несмотря на это, применение таких комплексов находит все большее распространение. При достаточной производительности вычислительных средств комплекса процесс исследования системы может вестись в реальном масштабе времени. В составе комплекса могут использоваться как универсальные микроЭВМ общего назначение, так и вычислительные средства, непосредственно входящие в исследуемую систему. Подобные моделирующие комплексы являются универсальными стендами для разработки и отладки аппаратно-программных средств, проектируемых систем заданного класса. Они могут использоваться в качестве тренажеров по обучению обслуживающего персонала.

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

В процессе подготовки IT-специалиста жизненному циклу программного обеспечения уделяется особое внимание [3]. Сфера управления проектом разработки программного обеспечения является специфической в силу следующих особенностей:

– программный продукт не является материальным объектом, увидеть и оценить степень готовности, а также оперативно повлиять на процесс разработки крайне сложно;

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

– процесс разработки ПО – процесс, который сложно оценивать как в денежном, так и во временном плане.

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

Появление программ управления проектами способствовало преобразованию управления проектами в науку, в которой имеются четкие стандарты, методы и технологии. Так, стандарт, разработанный Институтом управления проектами (Project Management Institute) принят в качестве национального стандарта в США (стандарт ANSI), появился и стандарт по качеству в управлении проектами ISO 10006. Применение этих технологий способствует своевременной реализации проектов в рамках выделенных бюджетов и с требуемым качеством. Конечно, программы управления проектами – это только инструмент менеджера проекта, а управление проектом не сводится к компьютерному моделированию.

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

Из пакетов, не представленных на нашем рынке, заслуживают упоминания Scitor Project Scheduler – пакет непрофессионального сегмента рынка, который является основным соперником MS Project на западном рынке, а также Artemis Project View – наиболее мощный из западных профессиональных пакетов управления проектами. Artemis Project View работает с базой данных Oracle, довольно дорог и при этом достаточно неэффективен. Его дополнительные возможности невелики, а стоимость в несколько раз выше стоимости других профессиональных пакетов. Потому популярность пакета не высока и на Западе.

В существующих стандартах приведены 9 процессов (областей знаний) по управлению проектами, каждый из которых состоит из определенного набора работ, и пять этапов (фаз) жизненного цикла проекта: инициация, планирование, исполнение, мониторинг и управление, завершение [3]. При этом процессы взаимосвязаны, а этапы проекта могут накладываться во времени друг на друга.

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

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

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

Каждый вопрос предлагается оценить по следующей схеме: оценка 0 проставляется, если руководитель даже не знает об этом; 1 – знает, но пока не реагирует на это; 2 – знает, но реагирует периодически; 3 – реагирует постоянно. В зависимости от численности команды, при расчете итогового балла предлагается учитывать следующие поправочные коэффициенты: для малых проектов (до 5 человек) – 1,5; для средних (от 5 до 20 человек) – 1,25. Результаты самооценки: если итоговый балл меньше 40 – завершение проекта сомнительно, 40–59 – в ходе реализации проекта следует ожидать серьезные проблемы, 60–79 – проект, скорее всего, будет успешным, 80–89 – вероятность успеха высока, больше 90–100 % шансов на успех.

Завершение проекта относится к фиксированию результатов программного проекта после передачи полученного программного продукта в эксплуатацию. На этом этапе проводятся приемо-сдаточные испытания (ПСИ) продукта на предмет соответствия его свойств определенным ранее требованиям. Критерии приемки должны определять числовые значения характеристик системы, которые должны быть продемонстрированы по результатам приемо-сдаточных испытаний или опытной эксплуатации и однозначно свидетельствовать о достижении целей проекта. Для проведения процедуры приемки-сдачи создаются специальные документы – программа и методика испытаний программного продукта [5]. Завершение наступает, когда достигнуты цели проекта, или осознано, что цели проекта не будут или не могут быть достигнуты; или исчезла необходимость в проекте, и он прекращается.

Для создания компьютерной модели проекта необходимо проделать следующие шаги:

– укрупненно описать проект – создать Иерархическую структуру работ;

– задать, какие составляющие стоимости будут использованы для финансового анализа и управления проектом;

– составить перечень операций (работ, задач) проекта и задать их характеристики;

– составить перечень ресурсов проекта и задать их характеристики;

– задать взаимосвязи (ограничения на порядок исполнения) операций проекта;

– назначить ресурсы на исполнение операций проекта;

– назначить стоимости на операции, ресурсы и назначения проекта;

– задать ограничения на финансирование, поставки, сроки исполнения операций;

– составить расписание исполнения работ проекта с учетом всех ограничений;

– оптимизировать состав используемых ресурсов;

определить бюджет и распределение во времени плановых затрат проекта;

– определить и промоделировать риски и неопределенности;

– определить необходимые резервы на сроки, стоимости и потребности в материалах для исполнения запланированных показателей с заданной надежностью;

– если заданы директивные сроки, стоимости, ограничения по поставкам, то определить вероятность их успешного соблюдения;

– представить плановую информацию руководству и исполнителям.

В процессе исполнения необходимо:

– анализировать отклонения исполнения от запланированного;

– прогнозировать будущие параметры проекта;

– моделировать управленческие воздействия;

– вести архивы проекта.

Создание компьютерной модели проекта всегда начинается с разработки Иерархической Структуры Работ (Work Breakdown Structure). Наиболее распространенный подход к структуризации – разбиение проекта на подпроекты, фазы, и т.д. исходя из объектов проекта. Подразделив проект на объекты с максимальной разумной детализацией следует описать процессы, связанные с реализацией каждого объекта.

Наиболее распространенный подход к структуризации – разбиение проекта на подпроекты, фазы, и т.д. исходя из объектов проекта. Так, чтобы произвести велосипед вы должны сделать раму, колеса, тормозную систему и т.д. Подразделив проект на объекты с максимальной разумной детализацией, вы должны описать процессы, связанные с реализацией каждого объекта. Однако возможны и другие подходы к созданию Иерархической структуры работ. Так, например, можно начать с процессов, а затем описывать, к каким объектам эти процессы следует приложить в данном проекте. Еще одна полезная структура – структура ответственности, в которой операции проекта соотносятся лицам, отвечающим за их исполнение.

Иерархические структуры работ позволяют получать отчетность по любым своим элементам. Таким образом, структура объектов позволяет подводить «Итого» по объектам проекта, структура процессов – по процессам проекта, а структура ответственности – контролировать, как участники проекта справляются с работами в своих зонах ответственности.

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

Характеристики операций проекта определяют и те показатели, который в дальнейшем используются для моделирования проекта. Перечислим основные исходные параметры, которые можно задать и использовать при моделировании исполнения операций проекта [3]:

– объем работ на операции;

– трудоемкость операции (ресурсо-часы, необходимые для ее исполнения);

– прямые затраты на операцию;

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

– ограничения на сроки исполнения операции (например, начало не раньше определенной даты).

Календарь операции определяет промежутки времени, когда операцию можно исполнять. Так, например, некоторые операции можно исполнять только в дневное время, другие – только летом и т.п. Календарь операции используется как ограничение при составлении расписания исполнения работ проекта. Задать календарь операции можно во всех пакетах, но используются они при составлении расписания по-разному. В большинстве пакетов время исполнения работы определяется или календарем операции, или календарем назначенных ресурсов.

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

Критический путь без учета ограниченности ресурсов вычисляется всеми пакетами управления проектами.

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

Использование программ управления проектами в процессе подготовки программистов позволит студентам изучить особенности разработки ПО «изнутри», понять, каким образом происходит планирование и контроль процесса реализации программы.

Рецензенты:

Долгоносов В.Н., д.т.н., доцент кафедры «МДиГ» Карагандинского государственного технического университета, г. Караганда;

Базаров Б.А., д.т.н., профессор, зав. кафедрой «СиТ» Карагандинского государственного индустриального университета, г. Темиртау.

Для создания компьютерной модели проекта необходимо проделать следующие шаги:

1) Укрупнено описать проект. создать Иерархическую структуру работ;

2) Задать, какие составляющие стоимости будут использованы для финансового анализа и управления проектом;

3) Составить перечень операций (работ, задач) проекта и задать их характеристики;

4) Составить перечень ресурсов проекта и задать их характеристики;

5) Задать взаимосвязи (ограничения на порядок исполнения) операций проекта;

6) Назначить ресурсы на исполнение операций проекта;

7) Назначить стоимости на операции, ресурсы и назначения проекта;

8) Задать ограничения на финансирование, поставки, сроки исполнения операций,

9) Составить расписание исполнения работ проекта с учетом всех ограничений;

10) Оптимизировать состав используемых ресурсов;

11) Определить бюджет и распределение во времени плановых затрат проекта;

12) Определить и промоделировать риски и неопределенности;

13) Определить необходимые резервы на сроки; стоимости и потребности в материалах для исполнения запланированных показателей с заданной надежностью;

14) Если заданы директивные сроки; стоимости; ограничения по поставкам, то определить вероятность их успешного соблюдения;

15) Представить плановую информацию руководству и исполнителям.

В процессе исполнения необходимо:

2) Анализировать отклонения исполнения от запланированного;

3) Прогнозировать будущие параметры проекта;

4) Моделировать управленческие воздействия;

5) Вести архивы проекта.

Далее мы рассмотрим перечисленные шаги по порядку и проанализируем возможности различных пакетов управления проектами.

7.1. Иерархическая структура работ проекта

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

Наиболее распространенный подход к структуризации . разбиение проекта на подпроекты, фазы, и т.д. исходя из объектов проекта. Так, чтобы произвести велосипед вы должны сделать раму, колеса, тормозную систему и т.д. Подразделив проект на объекты с максимальной разумной детализацией вы должны описать процессы, связанные с реализацией каждого объекта. Однако возможны и другие подходы к созданию Иерархической структуры работ. Так, например, можно начать с процессов, а затем описывать, к каким объектам эти процессы следует приложить в данном проекте. Еще одна полезная структура . структура ответственности, в которой операции проекта соотносятся лицам, отвечающим за их исполнение.

Иерархические структуры работ позволяют получать отчетность по любым своим элементам. Таким образом, структура объектов позволяет подводить «Итого» по объектам проекта, структура процессов . по процессам проекта, а структура ответственности контролировать, как участники проекта справляются с работами в своих зонах ответственности.

Наложение на один проект одновременно нескольких иерархических структур поддерживается пакетами Spider Project Professional и Desktop. В других профессиональных пакетах и в MS Project начиная с 2000 версии, можно заводить дополнительные иерархические коды для последующей группировки операций проекта. Это позволяет контролировать исполнение проекта с разных углов зрения, получать «итого» в произвольных разрезах.

7.2 Составляющие стоимости

Структуризация стоимости проекта позволяет проводить финансовый анализ проекта в необходимых разрезах. Однако задать не только стоимости работ и ресурсов, но и составляющие стоимости проекта, причем в разных валютах, можно только в пакетах линейки Spider Project. В качестве примера составляющих затрат приведем зарплату, накладные расходы, стоимость материалов, оборудования, механизмов, непредвиденные расходы и т.д. Обычно в качестве отдельных составляющих стоимости вводятся те, которые относятся к финансированию проекта.

Кроме отдельных составляющих стоимости, в профессиональных версиях Spider Project можно вводить центры стоимостей, объединив в них группы составляющих стоимости. При этом можно учитывать затраты только по выбранной части ресурсов и материалов. Это позволяет вести параллельный подсчет затрат в разных единицах измерения (например, вести планирование и учет затрат параллельно в разных валютах, в текущих ценах и ценах 1984 года и т.п.).

7.3. Операции проекта

- Объем работ на операции,

- Трудоемкость операции (ресурсо-часы, необходимые для ее исполнения),

- Прямые затраты на операцию,

- Тип операции (что является исходной информацией . длительность,

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

- Ограничения на сроки исполнения операции (например, начало не раньше определенной даты).

Во всех пакетах можно задать длительность операции, или ее трудоемкость (длительность будет подсчитана как частное от деления трудоемкости на количество назначенных ресурсов). В пакетах линии Spider Project (Lite, Desktop и Professional) можно также задать объем работ на операции в физических единицах, а длительность при этом будет рассчитана пакетом исходя из производительности назначенных ресурсов в процессе составления расписания работ.

Календарь операции определяет промежутки времени, когда операцию можно исполнять. Так, например, некоторые операции можно исполнять только в дневное время, другие . только летом и т.п. Календарь операции используется как ограничение при составлении расписания исполнения работ проекта. Задать календарь операции можно во всех пакетах, но используются они при составлении расписания по разному. В большинстве пакетов время исполнения работы определяется или календарем операции, или календарем назначенных ресурсов. В Spider Project играет роль и то, и другое. Только в рабочие периоды и операции, и

назначенных ресурсов операция может исполняться.

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

Основные типы операций, поддерживаемые всеми пакетами:

. с фиксированной длительностью,

- с фиксированной трудоемкостью (длительность . частное от деления

трудоемкости на количество назначенных определяющих (driving) ресурсов),

- гамак (hammock) . такие операции длятся от выполнения связи на старт до выполнения связи на финиш, то есть от события и до события,

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

В MS Project операций типа гамак нет, но зато можно использовать в качестве гамаков фазы ИСР. В отличие от других пакетов, в которых фазы . это «итого» по операциям, которые в них входят, в MS Project на фазы можно назначать ресурсы, то есть использовать их наподобие гамаков.

Вехи и ограничения на сроки исполнения операции можно задавать в любом пакете.

В Spider Project имеются также операции, у которых задается объем, а

длительность вычисляется исходя из производительности назначенных ресурсов (операция типа «производительность»).

Кроме того, в пакетах Spider Project и Open Plan можно задать, допускает ли операция прерывание своего исполнения, если ресурсы, исполняющие операцию, требуются на других, более приоритетных работах.

7.4 Ресурсы проекта

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

В большинстве пакетов те и другие ресурсы задаются вместе в едином перечне ресурсов, в пакетах Spider Project задание возобновляемых и невозобновляемых ресурсов разнесено в разные таблицы и они представляют собой разные объекты программы. Это вызвано не только тем, что по этим ресурсам задаются разные характеристики, но и тем, что в Spider Project можно задавать потребление материалов возобновляемыми ресурсами в процессе своей работы (расход электроэнергии, горюче-смазочных материалов и т.п.), чего в других пакетах делать нельзя.

В пакете MS Project общее количество ресурсов задается в процентах. Так, один ресурс можно задать как 100%, два . как 200% и т.д. Это сделано для удобства задания неполной загрузки ресурсов на работах, но не позволяет задать оба параметра одновременно . и количество назначенных ресурсов, и их загрузку на операции.

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

Иерархическую структуру ресурсов можно задать в P3e, Open Plan и Spider Project. При этом в Spider Project можно наложить на ресурсы неограниченное количество иерархических структур, что позволяет группировать ресурсы произвольным образом и получать отчетность по загрузке ресурсов во всевозможных матричных структурах управления.

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

Все большую популярность приобретает skill scheduling (поддерживается Open Plan, Spider Project и MS Project 2002), когда ресурсам присваиваются роли, которые они могут играть, а на исполнение операций проекта назначаются не конкретные ресурсы, а роли. Программа выбирает, какие именно ресурсы выгоднее использовать на тех, или иных работах. В пакете Spider Project роли задаются через создание всевозможных пулов ресурсов и главное отличие в подходах заключается в том, что в американских пакетах ресурсы с одной ролью (skill) полностью взаимозаменяемы, в то время как в Spider Project у этих ресурсов может быть разная производительность, которая учитывается при назначении исполнителей. В этом пакете (во всех версиях) можно назначать на исполнение операции или общее количество ресурсов определенной роли, или общую производительность назначенных ресурсов, чтобы программа сама подобрала нужное количество.

В P3e тоже можно задать роли ресурсов, но выбор исполнителей тем не менее осуществляет человек, а не программа.

В профессиональной и Desktop версиях Spider Project еще можно задать мультиресурсы. Мультиресурсы . это устойчивые группы ресурсов, выполняющие работы только вместе (бригады, водитель и самосвал, и т.п.). Это позволяет назначать на работы не только отдельные ресурсы, но и бригады целиком, что значительно снижает трудоемкость ввода и сокращает число потенциальных ошибок. Однако главная изюминка подхода состоит в том, что можно в любой момент в одном месте изменить состав бригады и пакет пересмотрит состав всех назначений бригады автоматически. Это позволяет легко проводить анализ «что если», подбирая оптимальный состав ресурсов проекта.

По невозобновляемым ресурсам (материалам) задается стоимость за

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

7.5. Взаимосвязи операций

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

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

Кроме самого типа связи часто задается «задержка» - промежуток времени от выполнения логического условия связи до момента, когда можно начинать исполнение последующей операции. Задержка может быть как положительной, так и отрицательной, а также иметь собственный календарь (в Open Plan и Spider Project).

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

Все перечисленные типы взаимосвязей являются связями типа «не раньше».

7.6. Поставки и финансирование

Поставки и финансирование можно моделировать в пакете Spider Project.

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

Задав финансирование, можно будет получать отчеты не только по затратам проекта, но и по cash flow, а также учитывать ограничения по финансированию и поставкам при составлении расписания исполнения работ проекта (только в профессиональной версии Spider Project).

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

7.7. Составление расписания исполнения работ проекта

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

Критический путь без учета ограниченности ресурсов вычисляется всеми пакетами управления проектами.

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

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

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

Заключительная часть занятия:

- подведение итогов и постановка задачи на следующее занятие.

Литература:

1. Информационные технологии управления: Учебное пособие /Под ред. Ю.М. Черкасова. - М.: ИНФРА-М, 2006. – 216 с.

2. Мазур И. И., Шапиро В. Д., Ольдерогге Н. Г. Управление проектами. – М.: Омега –Л, 2004. – 664 с.

3. Ньютон Р. Управление проектами от А до Я. – М. Альпина Бизнес Букс, 2009. – 226 с.

4. Управление проектом: Основы проектного управления: Учебник для вузов /Под ред. Разу М.Л. – М.: КноРус, 2007. - 768 с.

5. Попов В.Л. Управление инновационными проектами: Учебное пособие /Под ред. В.Л. Попова - М.: ИНФРА-М, 2009. – 336 с.

6. Просветов Г.И. Управление проектами: Задачи и решения: Учебно-практическое пособие – М.: Альфа-пресс, 2008. -200 с.

7. Фунтов В.Н. Основы управления проектами в компании, II издание, доп., СПб.: Издательство Питер. - 2008. – 21 п.л.

8. Фунтов В.Н. Управление проектами развития фирмы: Теория и практика – СПб. Питер, 2009.– 496 с.

б) дополнительная литература:

1. Алексеев В.И. Информационные технологии в туризме и гостиничном менеджменте. – М.: Д.А.Р.К, 2008.- 224с.

2. Мазур И. И., Шапиро В. Д., Ольдерогге Н. Г. Управление проектами. – М.: Омега –Л, 2004. – 664 с.

3. Макконнелл С. Сколько стоит программный проект - СПб.: Питер, 2007. – 297 с.

4. Морозов М.А., Морозова Н.С. Информационные технологии в социально-культурном сервисе и туризме. Оргтехника – М: Академия, 2009. – 240с.

5. Ньютон Р. Управление проектами от А до Я. – М. Альпина Бизнес Букс, 2009. – 226 с.

6. Попов В.Л. Управление инновационными проектами: Учебное пособие /Под ред. В.Л. Попова - М.: ИНФРА-М, 2009. – 336 с.

7. Просветов Г.И. Управление проектами: Задачи и решения: Учебно-практическое пособие – М.: Альфа-пресс, 2008. -200 с.

8. Родигин Л.А. Интернет технологии в туризме: Учебное пособие. – М.: Советский спорт, 2008. – 388 с.

Этап 2. Разработка проекта. Задачи этапа – сбор и уточнение информации.

Этап 3. Оценка результатов Задачи этапа – анализ выполнения проектных заданий.

Этап 4.Защита проекта. Урок – презентация Задачи этапа – коллективная защита проекта

Компьютерная модель (англ. computer model), или численная модель (англ. computational model) — компьютерная программа, работающая на отдельном компьютере, суперкомпьютере или множестве взаимодействующих компьютеров (вычислительных узлов), реализующая абстрактную модель некоторой системы. Компьютерные модели стали обычным инструментом математического моделирования и применяются в физике, астрофизике, механике, химии, биологии, экономике, социологии, метеорологии, других науках и прикладных задачах в различных областях радиоэлектроники, машиностроения, автомобилестроения и проч. Компьютерные модели используются для получения новых знаний о моделируемом объекте или для приближенной оценки поведения систем, слишком сложных для аналитического исследования. Компьютерное моделирование является одним из эффективных методов изучения сложных систем. Компьютерные модели проще и удобнее исследовать в силу их возможности проводить т. н. вычислительные эксперименты, в тех случаях когда реальные эксперименты затруднены из-за финансовых или физических препятствий или могут дать непредсказуемый результат. Логичность и формализованность компьютерных моделей позволяет выявить основные факторы, определяющие свойства изучаемого объекта-оригинала (или целого класса объектов), в частности, исследовать отклик моделируемой физической системы на изменения ее параметров и начальных условий. Построение компьютерной модели базируется на абстрагировании от конкретной природы явлений или изучаемого объекта-оригинала и состоит из двух этапов — сначала создание качественной, а затем и количественной модели. Компьютерное же моделирование заключается в проведении серии вычислительных экспериментов на компьютере, целью которых является анализ, интерпретация и сопоставление результатов моделирования с реальным поведением изучаемого объекта и, при необходимости, последующее уточнение модели и т. д.

Сравнительная компьютерная анимация двух моделей здания,[1]. К основным этапам компьютерного моделирования относятся: постановка задачи, определение объекта моделирования; разработка концептуальной модели, выявление основных элементов системы и элементарных актов взаимодействия; формализация, то есть переход к математической модели; создание алгоритма и написание программы; планирование и проведение компьютерных экспериментов; анализ и интерпретация результатов[2]. Различают аналитическое и имитационное моделирование. При аналитическом моделировании изучаются математические (абстрактные) модели реального объекта в виде алгебраических, дифференциальных и других уравнений, а также предусматривающих осуществление однозначной вычислительной процедуры, приводящей к их точному решению. При имитационном моделировании исследуются математические модели в виде алгоритма(ов), воспроизводящего функционирование исследуемой системы путем последовательного выполнения большого количества элементарных операций.

Читайте также: