«Г.Н. Смирнова, Ю.Ф. Тельнов ПРОЕКТИРОВАНИЕ ЭКОНОМИЧЕСКИХ ИНФОРМАЦИОННЫХ СИСТЕМ (Часть 1) Москва 2004 Смирнова Г.Н., Тельнов Ю.Ф. Проектирование экономических информационных систем (часть 1) / Московский государственный ...»

- Комплексный подход к построению системы защиты, означающий оптимальное сочетание программных аппаратных средств и организационных мер защиты.

- Разделение и минимизация полномочий по доступу к обрабатываемой информации и процедурам обработки.

- Полнота контроля и регистрация попыток несанкционированного доступа.

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

- «Прозрачность» системы защиты информации для общего, прикладного программного обеспечения и пользователей ЭИС.

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

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

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

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

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

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

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

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

Согласно «Оранжевой книге», в комплект документации надежной системы должны входить следующие компоненты:

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

- Руководство администратора по средствам безопасности.

- Тестовая документация.

- Описание архитектуры.

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

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

- Как защищать файлы и другую информацию? Как задавать права доступа к файлам? Из каких соображений это нужно делать?

- Как импортировать и экспортировать информацию, не нарушая правил безопасности?

- Как уживаться с системными ограничениями? Почему эти ограничения необходимы? Какой стиль работы сделает ограничения необременительными?

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

- Каковы основные защитные механизмы?

';

- Как администрировать средства идентификации и аутентификации? В частности, как заводить новых пользователей и удалять старых?

- Как администрировать средства произвольного управления доступом? Как защищать системную информацию? Как обнаруживать слабые места?

- Как администрировать средства протоколирования и аудита? Как выбирать регистрируемые события? Как анализировать результаты?

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

- Как генерировать новую, переконфигурированную надежную вычислительную базу?

- Как безопасно запускать систему и восстанавливать ее после сбоев и отказов? Как организовать резервное копирование?

- Как разделить обязанности системного администратора и оператора?

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

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

Технологический процесс функционирования системы защиты информации от несанкционированного доступа, как комплекса программно-технических средств и организационных (процедурных) решений, предусматривает выполнение следующих процедур:

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

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

- оперативный контроль функционирования систем защиты секретной информации;

- контроль соответствия общесистемной программной среды эталону;

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

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

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

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

Деятельность администратора средств безопасности должна осуществляться по трем направлениям:

- администрирование системы в целом;

- администрирование функций безопасности;

- администрирование механизмов безопасности.

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

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

Обязанности администратора механизмов безопасности определяются перечнем задействованных механизмов, например, таким типовым списком:

- Управление ключами (генерация и распределение).

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

- Администрирование управления доступом (распределение информации, необходимой для управления – паролей, списков доступа и т.п.).

- Управление аутентификацией (распределение информации, необходимой для аутентификации – паролей, ключей и т.п.).

Вопросы для самопроверки:

1. Что такое «концепции безопасности» хранимых данных и ее содержание?

2. Каковы средства реализации механизма подотчетности и их содержание?

3. Какая информация должна фиксироваться в процессе протоколирования событий?

4. Каковы основные принципы защиты от НСД, сформулированные в «Концепция защиты СВТ и АС от НСД к информации»?

5. Каков состав операций, выполняемых при проектировании системы защиты данных в ИБ?

6. Каков состав операций, выполняемых на предпроектной стадии?

7. Что такое «угроза безопасности» и перечислите основные виды угроз?

8. Что понимается под «несанкционированным доступом» и каковы основные пути несанкционированного доступа?

9. Каковы методы защиты от НСД?

10. Что такое «защита от несанкционированного копирования ценной компьютерной информации» и методы ее обеспечения?

11. Каков состав подсистем, включаемых в систему защиты данных?

12. Что такое «Подсистема управления доступом должна» и состав выполняемых ею функций?

13. Каков состав функций, возлагаемых на «Подсистему регистрации и учета»?

14. Каков состав функций должна выполнять «Подсистема обеспечения целостности»?

15. В чем заключается содержание «механизма управления доступом»?

16. Каковы алгоритмы криптографической защиты данных?

17. В чем заключается содержание механизма обеспечения целостности данных?

18. Каков состав документации по системе защиты и ее содержание?

19. В чем состоит содержание процедуры администрирования системы защиты данных ИБ?

20. Что означает «гарантированность» разработанной системы защиты данных и ее назначение?

21. Проверку каких элементов включает «операционная гарантированность»?

22. Каково назначение «технологической гарантированности» и ее содержание?

Глава 11. Организационные структуры проектирования ЭИС Раздел III. УПРАВЛЕНИЕ ПРОЕКТИРОВАНИЕМ ЭИС Глава 11. Организационные структуры проектирования ЭИС 11.1. Общая структура организации работ по проектированию ЭИС Процесс проектирования ЭИС включает в себя большое количество взаимосвязанных между собой разнообразных элементов, предполагающий построение соответствующей системы управления. В качестве объекта разработки проекта могут выступать: либо вся ЭИС для предприятия заказчика, либо только отдельная подсистема или совокупность подсистем, либо отдельные работы, например, установка вычислительной сети, проведение консалтинговых работ по оценке эффективности информационной системы и т.д.

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

- направлен на достижение конкретных целей;

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

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

- все проекты в определенной степени неповторимы и уникальны.

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

- масштабы разработки ЭИС;

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

элементы проекта системы и др.);

- различные факторы старения указанных элементов;

- разный временной цикл существования и темпов обновления элементов;

- длительность процесса проектирования системы;

- индивидуальность проекта, обусловленная спецификой объекта проектирования;

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

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

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

Процесс проектирования ЭИС имеет специфические особенности, которые, в свою очередь, определяют специфику управления проектированием.

1. Прежде всего, процесс проектирования ЭИС по своему характеру является творческим. Поэтому при отсутствии достаточно полного формализованного перечня операГлава 11. Организационные структуры проектирования ЭИС ций проектирования и состояний проекта в процессе его разработки управление проектированием носит ситуационный характер.

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

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

Выделение субъекта управления связано с разделением труда в группе специалистов в процессе проектирования ЭИС. Управление проектными работами в этом случае может осуществляться на нескольких уровнях:

- руководства проектной организации;

- руководства обеспечивающих подразделений (например, планово-производственного отдела и т.п.);

- руководства функциональными подразделениями;

- руководителей проектов (главных конструкторов);

- руководителей проектных групп (ответственных исполнителей).

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

Управление проектированием, как правило, рассматривают в двух аспектах: организационном и функциональном.

В организационном аспекте управление проектированием рассматривается по уровням организационно-административной структуры с соответствующими правами и обязанностями субъектов процесса проектирования.

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

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

Организация работ по проектированию ЭИС определяется порядком взаимодействия между несколькими сторонами, участвующими в этом процессе: пользователем, заказчиком, администратором и разработчиком.

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

Пользователь выполняет следующие функции:

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

Заказчик – это ответственное лицо, под которым понимается организация или подразделение и которое выполняет функции:

- формирует требования к системе и ее частям, - выдает техническое задание, финансирует разработку ЭИС, Глава 11. Организационные структуры проектирования ЭИС - обеспечивает проведение комплекса мероприятий по ее созданию, - проводит внедрение и прием проекта ЭИС.

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

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

Разработчик – это ответственное лицо (организация или подразделение), которое выполняет следующие функции:

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

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

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

Существует несколько типов схем организации работ с участием четырех сторон, выбор которых зависит от объема заказа.

1. Если заказ имеет небольшие размеры по стоимости и по продолжительности работ, то принимают первую схему, в которой в одном лице выступает заказчик, разработчик и администратор (см. рис. 11.1).

Рис. 11.1. Схема организации работ для небольших заказов Глава 11. Организационные структуры проектирования ЭИС К преимуществу данной схемы можно отнести минимальное количество организаций – участников процесса и минимальные сроки и стоимость разработки.

Однако совмещение в одной организации функций разрабатывающей стороны и принимающей стороны имеет ряд существенных недостатков:

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

- не достигается высокого профессионального уровня разработчиков.

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

Рис. 11.2. Схема организации работ при наличии сложного заказа К преимуществам данной схемы можно отнести:

- рациональное распределение функций между сторонами, участвующими в создании и эксплуатации ЭИС;

- возникает возможность привлечения к разработке ЭИС специализированных организаций (НИИ, СКБ).

Однако и эта схема имеет недостатки:

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

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

3. В том случае, если заказчик – большая организация, которая курирует разработку нескольких проектов ЭИС, применяют следующую схему (см. рис. 11.3):

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

Преимуществами данной схемы являются:

- более высокая степень специализации работников, следовательно, более высокий профессиональный уровень;

- возможность организации контроля сроков и качества выполнения работ.

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

Глава 11. Организационные структуры проектирования ЭИС Рис. 11.4. Схема организации работ с использованием организаций-соисполнителей Основными документами, регулирующими отношения заказчика и проектировщика является техническое задание и договор на проведение работ.

Иногда заказчик курирует частные ТЗ, если организациям выделены важные функции, которые имеют достаточно сложную структуру.

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

Под термином «системный интегратор» одни авторы понимают компании, специализирующиеся на сетевых и телекоммуникационных решениях (сетевые интеграторы), имеющие в свою очередь сеть своих реселеров, или компании – программные интеграторы. Другие, например, cчитают, что компания – «системный интегратор» призвана выполнять комплексное решение задач заказчика при построении ЭИС, поскольку заказчик готов переложить детальную проработку и реализацию проекта на плечи системного интегратора, определив лишь исходные данные и задачи, которые должна решать реализуемая ЭИС. Такая компания выполняет, как правило, следующий набор функций:

- продажа (дистрибуция, поставка для проектов) аппаратного обеспечения;

- продажа (дистрибуция, поставка для проектов) программного обеспечения;

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

По структуре и выполняемым функциям выделяют две группы фирм системных интеграторов:

- малые фирмы с числом сотрудников менее 30 человек и с числом сотрудников от 30 до 50 человек, представляющие собой небольшие динамические компании, специалиГлава 11. Организационные структуры проектирования ЭИС зирующиеся на интеграции программного обеспечения и аппаратных средств нескольких бизнес-партнеров;

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

Если в структуре доходов североамериканских компаний в последние годы установились доли доходов от продажи сетевого оборудования на уровне 50 %, и ПО на уровне 17 %, то доля доходов от проектирования и консалтинговых услуг составила 33 %. В нашей стране по данным на 1996 год для малых и средних фирм эти доли составляют 60 %, 22-26 % и 14-18 % соответственно, а для крупных системных интеграторов доля работ и услуг доходит до 40% общего дохода, продажи аппаратных средств составили около 35 %, доля продажи и установки в проектах программного обеспечения также составляет 22-26 %.

Объекты, с которыми работают специалисты фирм – интеграторов, являются:

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

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

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

- проектирование топологии интегрированных вычислительных систем;

- выбирает эффективные технические решения;

- определяет оптимальный состав аппаратных и программных средств;

- осуществляет монтаж, сопровождение и гарантийное обслуживание техники в течение всего срока эксплуатации системы;

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

- разработка собственного программного обеспечения на базе современных CASEтехнологий.

Помимо этого фирмы – интеграторы создают, как правило, дилерскую сеть представительств в ряде городов России и в странах СНГ. При этом компании осуществляют техническую и информационную поддержку своих дилеров, проводя совместные семинары и презентации, регулярно рассылая им информационно-рекламные материалы о новых продуктах и перспективных технологиях, осуществляют совместное участие в крупных региональных проектах.

Глава 11. Организационные структуры проектирования ЭИС Ряд компаний – интеграторов, например, компания «Анкей» представляют собой холдинговую структуру, включающую в себя четыре самостоятельные предприятия: «Анкей/Информационные системы» (разработка программных приложений), «Анкей/Центр технической поддержки» (построение сети), «Анкей/Сетевое и компьютерное оборудование» (поставка оборудования), «Анкей/Консалтинг». Такая структура компании позволяет им гибко реагировать на потребности рынка. В связи с этим для таких компаний существует два понятия: корпоративный проект и проект дочерней компании.

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

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

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

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

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

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

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

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

Формы управления, применяемые в организациях-разработчиках ЭИС, зависят от выполняемых работ. Как правило, в организациях – разработчиках выполняются, как об этом было сказано выше, работы, связанные:

- с проектированием ЭИС;

- с поддержкой и сопровождением ЭИС.

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

Формирование организационных форм управления в организациях-разработчиках ЭИС осуществляется по функциональному, проектному (целевому) и матричному принципам.

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

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

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

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

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

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

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

Глава 11. Организационные структуры проектирования ЭИС В проектных коллективах разделение труда между специалистами осуществляется, как правило, на основе одного из двух следующих принципов: пооперационного (технологического) или подсистемного.

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

Разделение труда в коллективе разработчиков ЭИС на основе пооперационного принципа, как правило, затруднительно в силу следующих факторов:

- невысокого уровня типизации технологических операций проектирования ЭИС;

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

- отсутствие объективных критериев нормирования труда специалистов;

- низкой степени стандартизации и унификации компонентов ЭИС.

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

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

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

- потенциал коллектива разработчиков;

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

- технология проектирования системы;

- модель жизненного цикла системы.

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

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

Глава 11. Организационные структуры проектирования ЭИС Административный руководитель в группе осуществляет, как правило, следующие действия:

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

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

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

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

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

Главный специалист выполняет следующие функции:

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

Главный специалист осуществляет непосредственное управление проектом и определяет стратегию проектирования.

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

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

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

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

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

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

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

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

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

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

При этом выделяются следующие группы специалистов:

- группа системного анализа и проектирования, - группа реализации (группа программирования), - группа тестирования, - административная группа.

Ядро группы системного анализа и проектирования сохраняется на этапе реализации (рабочего или техно-рабочего проектирования), на котором специалисты группы Глава 11. Организационные структуры проектирования ЭИС возглавляют группы программистов. Разделение труда в группы системного анализа и проектирования, как правило, на основе пооперационного принципа, а в группе реализации – на основе подсистемного принципа. Данная группа выполняет системный анализ, разрабатывает спецификации к автоматизированной системе, осуществляет проектирование ЭИС, во время реализации проекта выполняет контрольные функции и документирование системы в соответствии с требованиями стандартов.

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

Административная группа выполняет технические и административные функции, включая подготовку проектной документации, контроль документации и отчетности и т.п.

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

Участие со стороны пользователя целесообразно на этапе системного анализа и разработки требований к системе, а также при проектировании пользовательского интерфейса.

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

Вопросы для самопроверки:

1. Каковы особенности разработки проекта как вида деятельности и их содержание?

2. Каковы стадии жизненного цикла проекта как вида деятельности проектной организации?

3. Что понимается под управлением проектом?

4. Каковы аспекты рассмотрения процессов управления проектированием?

5. Каков состав лиц, участвующих в разработке и эксплуатации проекта ЭИС?

6. Какие типы схем организации работ используются при проектировании ЭИС, их преимущества и недостатки?

7. Что понимается под термином «системный интегратор»?

8. С какими типами проектов работают фирмы – системные интеграторы?

9. Состав работ, выполняемых фирмами – системными интеграторами?

10. Что такое холдинговая структура и назначение ее создания?

11. Что понимается под сетевой, программной и проектной интеграцией?

12. Каковы основные организационные формы управления вы знаете?

13. Какие принципы разделения труда существуют в проектных организациях?

14. Что такое открытая организационная структура и в чем ее отличие?

15. Чем отличается централизованная организационная структура проектной группы?

16. В чем заключаются особенности децентрализованной организационной структуры проектной группы?

17. В чем состоят особенности использования метода организации труда разработчиков на принципах децентрализации – «модели большого проекта»?

Глава 12. Планирование и контроль проектных работ 12.1. Основные компоненты процесса управления проектированием ЭИС Управление проектированием ЭИС в функциональном аспекте рассматривается как совокупность взаимосвязанных процессов. Под процессами управления понимаются действия и процедуры, связанные с решением конкретных задач или реализацией функций управления, к которым относятся:

- процессы инициации, связанные с принятием решения о начале выполнения проекта или какой либо очередного этапа или фазы его;

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

- процессы исполнения предназначены для координации людей и других ресурсов для выполнения плана;

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

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

- процессы завершения – это процессы формализации выполнения проекта и составлеия отчетности.

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

Входы – документы или документированные показатели, согласно которым процесс исполняется.

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

Методы и средства – механизмы, по которым вход преобразуется в выход.

Рассмотрим состав и содержание выделенных групп процессов.

Процессы инициации. Инициация включает единственный подпроцесс – авторизацию, т.е. решение начать следующую фазу проекта.

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

К основным процессам планирования проектных работ относят [ ]:

- Планирование целей – разработка постановки задачи (проектное обоснование, основные этапы и цели проекта).

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

- Определение состава операций (работ) проекта – составление перечня операций, из которых состоит выполнение различных этапов проекта.

- Определение взаимосвязей операций – составление и документирование технологических взаимосвязей между операциями.

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

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

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

- Оценка стоимости – определение составляющих стоимости операций проекта и оценка этих составляющих для каждой операции, ресурса и назначения.

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

- Оценка бюджета – приложение оценок стоимости к отдельным компонентам проекта (этапам, фазам, срокам).

- Разработка плана исполнения проекта – интеграция результатов остальных подпроцессов для составления полного документа.

- Определение критериев успеха – разработка критериев оценки исполнения проекта.

Кроме перечисленных основных процессов планирования имеется ряд вспомогательных процессов, необходимость в использовании которых сильно зависит от природы конкретного проекта. Такие процессы включают в себя:

- Планирование качества – определение того, какие стандарты качества использовать в проекте, и того, как эти стандарты достичь.

- Планирование организации – определение, документирование и назначение ролей, ответственности и взаимоотношений отчетности в организации.

- Назначение персонала – назначение человеческих ресурсов на выполнение работ проекта.

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

- Идентификация риска – определение и документирование событий риска, которые могут повлиять на проект.

- Оценка риска – оценка вероятностей наступления событий риска, их характеристик и влияния на проект.

- Разработка методов реагирования – определение необходимых действий для предупреждения рисков и реакции на угрожающие события.

- Планирование поставок – определение того, что, как и когда должно быть поставлено.

- Подготовка условий – выработка требований к поставкам и определение потенциальных поставщиков.

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

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

Как и в планировании, процессы исполнения можно подразделить на основные и вспомогательные. К основным процессам исполнения можно отнести сам процесс исполнения плана проекта. Среди вспомогательных процессов можно отметить:

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

- подтверждение качества – регулярная оценка исполнения проекта с целью подтверждения соответствия принятым стандартам качества;

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

- выбор поставщиков – оценка предложений, выбор поставщиков и подрядчиков и заключение контрактов;

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

- развитие команды проекта – повышение квалификации участников команды проекта.

Процессы анализа. Процессы анализа включают как анализ плана, так и анализ исполнения проекта.

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

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

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

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

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

- анализ сроков – определение соответствия фактических и прогнозных сроков исполнения операций проекта директивным или запланированным;

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

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

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

Вспомогательные процессы анализа связаны с анализом факторов, влияющих на цели и критерии успеха проекта. Эти процессы включают:

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

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

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

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

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

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

К основным процессам оперативного управления, встречающимся практически в каждом проекте, относятся:

- общее управление изменениями – определение, согласование, утверждение и принятие к исполнению корректирующих воздействий и координация изменений по всему проекту;

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

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

- управление качеством – разработка мероприятий по устранению причин неудовлетворительного исполнения.

Среди вспомогательных процессов управления выделяют:

- управление рисками – реагирование на события и изменение рисков в процессе исполнения проекта;

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

Процессы завершения. Завершение проекта сопровождается следующими процессами:

- закрытие контрактов – завершение и закрытие контрактов, включая разрешение всех возникших споров;

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

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

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

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

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

Основные преимущества использования информационной системы для управления проектами включают:

- централизованное хранение информации по графику работ, ресурсам и стоимостям;

- возможности быстрого анализа влияния изменений в графике, ресурсном обеспечении и финансировании на план проекта;

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

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

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

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

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

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

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

- неспособность в полной мере отражать взаимосвязи отдельных операций;

- недостаточная гибкость линейной модели;

- трудность ее корректировки при изменившихся условиях;

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

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

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

Методика СПУ – развитая система планирования и управления, предусматривающая выявление и использование резервов времени и материальных ресурсов, дающая возможность прогнозирования и предупреждения возможных срывов в ходе выполнения программы. Она была разработана в конце 50-х годов в США в 1956 г. М. Уолкером из фирмы «Дюпон» и Д. Келли из группы планирования капитального строительства фирмы «Ремингтон Рэнд». Они попытались использовать ЭВМ для составления планов-графиков крупных комплексов работ по модернизации заводов фирмы «Дюпон». В результате был создан рациональный и простой метод описания проекта с использованием ЭВМ, который первоначально был назван методом Уолкера-Келли, а позже получил название Метода Критического Пути – МКП (или CPM – Critical Path Method).

Параллельно и независимо в США был создан метод анализа и оценки программ PERT (Program Evaluation and Review Technique). Данный метод был разработан корпорацией «Локхид» и консалтинговой фирмой «Буз, Аллен энд Гамильтон» для реализации проекта разработки ракетной системы «Поларис», объединявшего около 3800 основных подрядчиков и состоявшего из 60 тыс. операций.

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

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

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

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

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

Связи предшествования (логические зависимости) – отображают природу зависимостей между работами. Большинство связей в пpоектах относятся к типу «конецначало», когда последующая pабота может начаться только по завеpшении пpедшествующей pаботы. Связи предшествования образуют структуру сети. Комплекс взаимосвязей между работами часто также называют логической структурой проекта, поскольку он определяет последовательность выполнения работ.

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

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

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

1. Системный подход к решению вопросов организации управления процессом создания новых систем.

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

3. Применение ЭВМ с целью обработки исходных и оперативных данных для расчета плановых показателей и получения необходимых аналитических и отчетных сводок.

4. Комплексами работ, для которых применяются методы СПУ могут иметь одноцелевой или многоцелевой характер.

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

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

1. Любая работа – стрелка соединяет только два события и отражает процесс перехода от одного события к другому.

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

3. Начало стрелки показывает, с какого события данная работа начинается, а конец стрелки – в каком событии она заканчивается.

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

5. Требуемые для выполнения работы размеры ресурсов указываются на стрелках в скобках.

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

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

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

Все критические работы являются потенциально «узкими» местами плана. Критических путей может быть несколько. Пути, продолжительность которых приближается к критическому пути, называются субкритическими. Остальные пути – некритические.

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

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

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

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

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

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

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

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

Ресурсная гистограмма – гистограмма, отображающая потребности проекта в том или ином виде ресурсов в каждый момент времени.

Pесуpсное календаpное планиpование – планирование сроков начала работ при ограниченных наличных ресурсах. Пpовеpка pесуpсной pеализуемости календаpного плана тpебует сопоставления функций наличия и потpебности в pесуpсах пpоекта в целом.

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

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

Анализ реализуемости проекта – понятие реализуемости имеет ряд своих разновидностей: логическая реализуемость (учет логических ограничений на возможный порядок выполнения работ во времени); временной анализ (расчет и анализ временных характеристик работ: ранняя/поздняя дата начала/окончания работы, полный, свободный временной резерв и другие); физическая (ресурсная) реализуемость (учет ограниченности наличных или доступных ресурсов в каждый момент времени выполнения проекта); фиГлава 12. Планирование и контроль проектных работ нансовая реализуемость (обеспечение положительного баланса денежных средств как особого вида ресурса).

Параметры, по которым должно вестись управление проектом: время, стоимость, ресурсы, технико-экономические показатели (ТЭП). Время при управлении проектом учитывается всегда, остальные параметры – в необходимых случаях. В зависимости от различного сочетания параметров возникают и соответствующие разновидности системы управления комплексом работ по конечным ее параметрам и их сочетаниям, к числу которых относятся:

- время – стоимость, - время – стоимость – ресурсы, - время – стоимость – ТЭП, - время – стоимость – ресурсы – ТЭП.

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

Можно отметить, что применение методологии СПУ дает ряд преимуществ в организации управления проектами, поскольку позволяет:

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

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

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

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

- заранее анализировать результаты осуществления различных вариантов плана на ЭВМ;

- быстро обработать с помощью ЭВМ большие объемы данных и обеспечить руководство своевременной и исчерпывающей информацией о фактическом состоянии работ, облегчающих принятие обоснованных решений;

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

- систематически корректировать оперативные планы работ в соответствии с фактическим состоянием разработки;

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

12.3. Технология применения метода СПУ для разработки проекта ЭИС Перед началом разработки проекта составляется организационный план проведения работ. Он состоит из трех разделов:

1. Исходный план – план-график выполнения работ проекта, содержащий исходные сведения об основных временных и стоимостных параметрах работ, который принят к исполнению. В исходном плане обычно фиксируются объемы работ, плановые даты начала и окончания задач проекта, длительности задач, расчетные стоимости задач. Он составляется в виде сетевого графика.

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

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

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

1. Разработка первоначального исходного сетевого плана.

2. Оптимизация его и приведение в соответствии с ограничениями.

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

Рассмотрим содержание работ, выполняемых на каждом этапе.

1. Цикл управления проектированием ЭИС начинается с определения состава проектных работ по стадиям и этапам процесса проектирования. В основе такой работы лежит модель жизненного цикла системы. Состав проектных работ зависит от глубины декомпозиции процесса проектирования по уровням управления. Декомпозиция процесса проектирования может осуществляться относительно как различных частей проекта, так и проекта в целом, но всегда в соответствии с выбранной технологией проектирования ЭИС. Центральной задачей при этом является выбор единицы проектных работ. Общими требованиями для возможных вариантов определения такой единицы является:

- выполнение работы можно поручить одному специалисту или группе специалистов;

- выполнение работы должно быть удобным для планирования и контроля;

- объем и характер работы должны давать возможность объективной оценки необходимых ресурсов и результатов.

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

В зависимости от уровня управления детализация технологической сети проектирования может быть различной. Состав и содержание операции проектирования на каждом уровне зависят от применяемых методов и средств проектирования. Перечень операГлава 12. Планирование и контроль проектных работ ций проектирования в соответствии с выбранной технологией может служить основой для разработки плана создания ЭИС.

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

Последовательность разработки сетевого графика для выполнения всего объема проектировочных работ по созданию ЭИС сводится к выполнению трех совокупностей операций.

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

- на уровне главного конструктора, на котором в качестве работ выступают работы над проектом 1,2,..,10,..;

- на уровне планового отдела, где в качестве событий будут выступать отдельные этапы проектирования;

- на уровне руководителя проекта, на котором существенным является определение, в какие сроки получают составные части проекта;

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

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

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

- по отдельным наименованиям работ – по-предметный способ;

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

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

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

Каждый исполнитель формирует сеть на отведенный ему подкомплекс операций.

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

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

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

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

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

К основным показателям расчета сетевого графика относятся следующие: