Особенности сетевого планирования

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Введение

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

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

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

Таким образом, методы сетевого моделирования относятся к методам принятия оптимальных решений.

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

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

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

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

Наиболее распространенными направлениями применения сетевого планирования являются:

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

· планирование и управление основной деятельностью разрабатывающих организаций;

· планирование комплекса работ по подготовке и освоению производства новых видов промышленной продукции;

· строительство и монтаж объектов промышленного, культурно-бытового и жилищного назначения;

· реконструкция и ремонт действующих промышленных и других объектов;

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

1. Сетевые методы планирования и управления (СПУ). Процесс создания хранилища данных

1.1 Основы построения сетевой модели

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

В основе СПУ лежит сетевая модель разработки.

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

Преимущество СПУ: они позволяют из всего перечня работ выделить те работы, от своевременности выполнения которых зависит срок сдачи объекта в эксплуатацию (критические работы).

СПУ позволяют установить, какими запасами времени располагают работы, не лежащие на критическом пути. Знания этих резервов используются при корректировке планов.

Основная область применения СПУ - строительство объектов и организация производственных процессов.

Основными элементами СГ являются:

- работа;

- событие;

- путь.

Работа - это процесс или действие, приводящее к определенному результату.

Существует три вида работ:

o действительная - протяженный во времени процесс, требующий затрат ресурсов и времени;

o работа-ожидание - протяженный во времени процесс, не требующий затрат;

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

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

Любая работа соединяет только два события.

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

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

Все остальные события являются промежуточными.

Путь - это непрерывная последовательность работ между двумя событиями.

Полный путь - непрерывная последовательность работ от исходного события до завершающего.

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

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

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

1.2 Правила построения сетевых графиков

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

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

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

4. Построение СГ нужно осуществлять слева направо.

5. На СГ не должно быть так называемых “тупиковых” и “хвостовых” событий

Рис. 1

6. На СГ не должно быть изолированных участков, замкнутых контуров и петель.

Рис. 2

7. Любые два события могут быть связаны не более, чем одной работой. Если на СГ обнаружены параллельные работы, то нужно ввести фиктивное событие и фиктивную работу.

Рис. 3

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

Рис. 4

9. На СГ по возможности необходимо избегать многочисленных пересечений работ или стрелок.

10. На СГ не должно быть ни работ, ни событий, имеющих одинаковые номера или коды.

11. События на СГ нумеруются слева направо и сверху вниз после его построения и упорядочения следующим образом:

o исходному событию присваивается 0 или 1;

o затем вычеркиваются все выходящие работы из данного события;

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

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

Рис. 5

Существует два вида сетевых графиков:

1. Детерминированные (определенные) (временные параметры такого СГ установлены на основе действующих норм и нормативов).

2. Стохастические (неопределенные) (СГ, в которых продолжительность выполнения каждой из работ устанавливается экспертным путем, норм и нормативов нет)

1.3 Процесс создания и разработки хранилища данных (ХД)

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

*планирование;

*формулирование требований к системе складирования данных;

*анализ;

*проектирование;

*конструирование;

*внедрение;

*поддержка.

Планирование

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

Рис. 6

сетевой проектный планирование хранилище

Целью этого этапа является идентификация задач ХД, выбор способа решения этих задач, определения программно-технологического объекта и того, как, в какие сроки и за какие деньги этот объект будет реализоваться.

Выбор стратегии реализации определяет подход, который будет использован при создании ХД. Обычно используют следующие подходы: Top Down ("сверху вниз"), Bottom Up ("снизу вверх"), Middle In ("из середины") и комбинированный подход, который в последнее время становится все более популярным. Подход "сверху вниз" выбирается для вновь создаваемого ХД, т.е. когда "с нуля" принимаются все решения о технологической реализации объекта (аппаратура, программное обеспечение и т.д.). Подход "снизу вверх" используется, когда уже есть определенная вычислительная среда и объекты, из которых можно построить новый объект. Подход "из середины" предполагает эволюционное, поэтапное создание объекта, когда сначала разрабатывается так называемое ядро объекта, которое на следующих этапах наращивается новой функциональностью. Комбинированный подход применяет комбинацию выше перечисленных подходов.

Разработка требований

Этап разработки требований к ХД включает в себя следующие стадии:

* определение требований владельца ХД;

*определение требований конечных пользователей;

*определение технологических требований;

*определение архитектурных требований.

Требования владельца связаны с уточнением предметно-ориентированной направленности ХД, требованиями потенциального роста предметной области по:

* целям бизнеса;

*масштабу и целям хранилища данных/киосков данных, по клиентам и посредникам;

*требованиям клиентов;

*источникам данных;

*плану -- бюджет, календарный план-график, ресурсы;

*влиянию на текущие инвестиции -- люди, технология, обучение.

Рис. 7

Анализ

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

Рис. 8

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

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

Проектирование

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

Рис. 9

Проектирование ХД можно разложить на две равноценных стадии - проектирование архитектуры данных (логическое и физическое проектирование) и архитектуры приложений (анализ запросов и фиксация процессов взаимодействия хранилища данных с внешними источниками и пользователями).

Детальное проектирование архитектуры данных включает в себя:

* логическое проектирование. Разработка логических моделей данных для ХД и киосков данных в рабочем пространстве базы данных. Отображение логических моделей данных источников данных в логические модели ХД и киосков данных;

* физическое проектирование. Отображение логических объектов в физическое описание ХД. Денормализация логической модели. Создание табличного пространства, секционирование, создание индексов и ограничений. Оценка объема физического ввода-вывода.

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

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

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

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

* процессов, которые являются внутренними для источников данных и связаны с процедурами очистки и частичной экстракции информации;

* процессов, которые связывают источники данных с ХД и киосками данных;

* процессов, которые являются внутренними по отношению к ХД и предназначены исключительно для обслуживания данных в хранилище;

* процессов, которые связывают ХД и киоски данных;

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

* процессов, которые связывают хранилище и киоски данных со средствами конечного пользователя;

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

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

Целью этой стадии является получение спецификаций всех приложений ХД.

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

Построение хранилища данных

Рис. 10

Следующий этап проекта создания ХД -- это построение ХД

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

* программы, которые создают и модифицируют БД для ХД и киосков данных;

* программы, которые экстрагируют данные из источников данных;

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

*программы, которые выполняют обновление реляционных БД;

*программы, которые реализуют поиск в очень больших БД.

Результатом выполнения этого этапа является комплекс программ, работающих с ХД.

Внедрение

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

Рис. 11

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

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

Результатом выполнения этого этапа является всесторонняя подготовка перехода ХД в промышленную эксплуатацию.

Поддержка

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

На этом этапе ИТ-служба организации обеспечивает:

* поддержку работоспособности и масштабируемости программно-аппаратного обеспечения ХД;

* сбор, очистку, преобразование, загрузку и актуализацию данных в соответствии с установленными бизнес-процедурами;

*поддержку автоматизированных мест пользователей.

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

Этот этап является также испытанием ХД "на прочность". Конечные пользователи, как правило, не являются ИТ-профессионалами. Они решают свои задачи. Они будут использовать ХД только в том случае, если оно будет эффективно помогать им решать их задачи.

В проектный цикл разработки ХД обычно включаются следующие типовые процессы (этапы):

* формулирование требований;

*создание вычислительной среды;

*моделирование данных;

*определение процедур извлечения преобразования и загрузки данных;

*проектирование аналитических отчетов;

* разработка приложений ХД;

*настройка производительности;

*проверка качества;

*передача системы складирования данных в эксплуатацию

Рис. 12

2. Описание процесса создания хранилища данных при помощи модели сетевого планирования

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

Как уже говорилось ранее, в проектный цикл разработки ХД обычно включаются следующие типовые процессы (этапы):

* формулирование требований;

*создание вычислительной среды;

*моделирование данных;

*определение процедур извлечения преобразования и загрузки данных;

*проектирование аналитических отчетов;

* разработка приложений ХД;

*настройка производительности;

*проверка качества;

*передача системы складирования данных в эксплуатацию

На основе этих процессов построим сетевой график, представленный на рисунке ниже.

Рис. 13

где события:

1 - формулирование требований;

2 - моделирование данных;

3 - определение процедуры извлечения, преобразования и загрузки данных;

4 - создание вычислительной среды;

5 - разработка приложений ХД;

6 - проектирование аналитических отчетов;

7 - настройка производительности;

8 - проверка качества;

9 - сдача ХД в эксплуатацию.

Для определения ожидаемого времени выполнения работ, необходимо рассчитать три временные оценки:

- соответствующее наиболее благоприятным условиям выполнения работы;

- с учетом наихудшего стечения обстоятельств;

- может иметь место в реальных условиях, при обычном ходе работы.

Вероятность выполнения работы в минимальные и максимальные сроки мала. Обычно продолжительность работы бывает близка к наиболее вероятной оценке. Учитывая закон распределения вероятности продолжительности работы, ожидаемое время ее выполнения определяется по формуле:

Табл. 1

Дней
1-2	1	5	3	3
1-3	1	2	1	2
1-4	3	7	4	4
2-5	7	14	8	9
2-6	2	5	3	3
2-7	5	18	10	11
3-7	7	18	9	10
4-7	10	14	10	11
5-6	9	14	10	11
6-8	3	7	4	4
7-9	0,5	2	1	1
8-9	0,5	3	1	1

Перенесем полученные значения на график

Рис. 14

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

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

Продолжительность пути (L) равно сумме продолжительности входящих в нее работ.

= 3+9+11+4+1 = 28

= 3+3+4+1 = 11

= 3+11+1 = 15

= 2+10+1 = 13

= 4+11 = 15

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

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

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

Заключение

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

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

Воснове сетевого планирования лежит построение сетевых диаграмм, которые бывают двух типов - типа "вершина-работа" и "вершина-событие" или "дуги-работы".

При создании сетевого графика в основе построения сети лежат понятия "работа", "событие" и "путь".

Методики сетевого планирования были разработаны в конце 50-х годов в США. В СССР начало работ по сетевому планированию относят к 1961 году. Тогда методы сетевого планирования нашли применение в строительстве и научных разработках.

В настоящее время происходит расширение методов и приемов использования сетевых методов.

Сетевая модель позволяет:

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

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

· проводить многовариантный анализ разных решений с целью улучшения плана;

·использовать для обработки больших массивов информации компьютеры и компьютерные системы.

Литература

1. Кудрявцев Е.М. Microsoft Project. Методы сетевого планирования и управления проектом. - М.: ДМК Пресс, 2005. - 240 с., ил.

2. https://siblec.ru/telekommunikatsii/menedzhment-v-telekommunikatsiyakh/6-setevye-metody-planirovaniya-i-upravleniya-spu#6.3

3. https://www.intuit.ru/studies/courses/599/455/lecture/10159

4. http://upr-proektom.ru/setevoe-planirovanie

5. Видео-материал на тему «Сетевое планирование и управление»

6. https://www.osp.ru/winitpro/2012/06/13033234/

7. Управление проектом. Основы проектного управления: ученик/ кол. авт.: под ред. проф. М.Л.Разу. - М.: КНОРУС, 2006. - 768 с.

8. Сетевое планирование. http://www.inventech.ru/lib/glossary/netplan/

9. Ивасенко А.Г. Управление проектами: учебное пособие/ А.Г. Ивасенко, Я.И. Никонова, М.В. Каркавин - Ростов н/Дону: Феникс, 2009. - 330 с. - Высшее образование.

Размещено на Allbest.ru

...