Page 1

Государственный комитет Российской Федерации по высшему образованию Ульяновский государственный технический университет Кафедра «Вычислительная техника»

К защите допустить «___»__________2010г. Зав. кафедрой ____________________

Пояснительная записка к выпускной работе бакалавра

Тема:

Управление рисками в вопросно-ответной среде моделирования проектной деятельности: причинноследственное представление рисков с позиций их оценивания

Бакалавр:

( Куманяев А.В.

)

Руководитель:

( Соснин П.И.

)

Консультанты:

(

)

(

)

(

)

( Святов К.В.

)

Рецензент:

Ульяновск 2010 г. 1


Оглавление АННОТАЦИЯ......................................................................................................................................... 5 ВВЕДЕНИЕ ............................................................................................................................................. 6 Постановочно-обзорная часть ............................................................................................................... 8 1.1. Задача управления рисками ....................................................................................................... 8 1.1.1. Значение управления рисками проектов............................................................................ 8 1.1.2. Определение риска ............................................................................................................. 10 1.1.3. Категории рисков ............................................................................................................... 11 1.1.4. Определение процесса управления рисками ................................................................... 14 1.1.5. Задачи процесса управления рисками. ............................................................................. 19 1.1.6. Идентификация рисков ...................................................................................................... 21 1.1.7. Качественные и количественные методики оценки риска ............................................. 24 1.1.8 Этапы разработки плана по управлению рисками ........................................................... 28 1.1.8.1. Категоризация рисков ................................................................................................. 28 1.1.8.2. Ранжирование рисков ................................................................................................. 28 1.1.8.3. Расстановка приоритетов ........................................................................................... 29 1.1.8.4. Формирование отчета ................................................................................................. 29 1.1.8.5. Мониторинг ................................................................................................................. 29 1.2. Обзор .......................................................................................................................................... 30 1.2.1. Обзор существующих методологий. ................................................................................ 30 1.2.2. Проектные риски и Институт SEI..................................................................................... 34 1.2.3. Модели управления рисками ............................................................................................ 36 1.2.4. Обзор систем управления проектами и рисками ............................................................ 41 1.2.4.1. Gantt Designer............................................................................................................... 41 1.2.4.2. GanttProject ................................................................................................................... 41 1.2.4.3. OpenProj........................................................................................................................ 43 1.2.4.4. Open Workbench........................................................................................................... 44 1.2.4.5. Gnome Planner .............................................................................................................. 45 1.2.4.6. Коллективное управление проектами ....................................................................... 45 1.2.4.7. Microsoft Enterprise Project Management Solution (EPM). ........................................ 45 1.2.4.8. Spider Project. ............................................................................................................... 46 1.2.4.9. ―Офис Управления Проектами – РМО‖. ................................................................... 46 1.2.4.10. Primavera Pertmaster. ................................................................................................. 47 1.3. Формулировка задания ............................................................................................................. 48 1.3.1. Цели и назначения.............................................................................................................. 48 1.3.2. Обобщенная постановка задачи ........................................................................................ 48 2


Проектная часть. ................................................................................................................................... 50 2.1. Анализ имеющихся средств. .................................................................................................... 51 2.1.1. Дерево контекстных атрибутов. ....................................................................................... 51 2.1.2. Плагин «Организационная структура» ............................................................................ 52 2.1.3. Плагин «Методики» ........................................................................................................... 53 2.1.3. Плагин «Прецеденты» ....................................................................................................... 53 2.2. Представление задачи управления рисками в WIQA.NET ................................................... 54 2.3. Представление риска как объекта вопросно-ответной среды............................................... 57 2.4. Факторы среды и их взаимодействие с рисками .................................................................... 63 2.4.1. Причины и условия сущностей среды ............................................................................. 64 2.4.2. Следствия и результаты сущностей среды ...................................................................... 65 2.5. Диаграмма развертывания. ....................................................................................................... 67 2.6. Диаграмма вариантов использования. .................................................................................... 68 2.7. Диаграмма процесса объявления информационного бюллетеня ......................................... 70 2.8. Методы управления рисками, применяемые в WIQA.NET .................................................. 71 Реализация проекта .............................................................................................................................. 73 3.1. Модули проекта. ........................................................................................................................ 73 3.2. Взаимодействие с пользователем. ........................................................................................... 74 3.2.1. Реализация интерфейса плагина «Управление рисками» .............................................. 74 3.2.2. Реализация поддержки механизма дополнительной атрибутики. ................................. 75 Экспериментальная часть .................................................................................................................... 76 4.1. Использование плагина «Управление рисками». ................................................................... 76 4.2. Методика идентификации рисков ........................................................................................... 78 4.3. Распределение задач процесса управления рисками ............................................................. 80 4.4. Ручное изменение и добавление информации в QA-протокол задачи управления рисками проекта. ............................................................................................................................................. 81 Расчет себестоимости разработки программного продукта ............................................................ 83 5.1. Основные статьи расходов при разработке программы ........................................................ 85 5.1.1. Расчет трудоемкости разработки программного обеспечения ...................................... 86 5.1.2. Расчет затрат на разработку программного обеспечения .............................................. 90 5.2. Дополнительные статьи расходов ........................................................................................... 91 5.3. Результирующая таблица себестоимости ............................................................................... 95 Охрана труда ......................................................................................................................................... 96 4.1. Площадь и объем рабочих помещений ................................................................................... 99 4.2. Освещение.................................................................................................................................. 99 4.2.1. Расчет освещенности рабочего места ................................................................................ 100 4.3. Планировка и оснащение рабочего места ............................................................................. 103 3


4.4. Основные способы защиты .................................................................................................... 106 4.4. Защитные фильтры.................................................................................................................. 107 4.5. Отдых глаз................................................................................................................................ 111 ЗАКЛЮЧЕНИЕ .................................................................................................................................. 112 БИБЛИОГРАФИЧЕСКИЙ СПИСОК............................................................................................... 113 ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ ........................................................................................................ 116

4


АННОТАЦИЯ Представленная бакалаврская работа посвящена рассмотрению процесса управления рисками в вопросно-ответной среде моделирования WIQA.NET. Пояснительная записка содержит следующие разделы: Постановочно-обзорная часть. В главе основное внимание уделяется описанию основных понятий и концепции рисков и процесса управления рисками. Рассматриваются методы оценки риска со стороны менеджера проекта. В этой главе содержится описание основ существующих методологий. Также, в этой главе содержится обобщенная постановка задачи, требования к работе Проектная часть. В этой главе приведѐн анализ имеющихся средств вопросно-ответной среды WIQA.NET, использование которых возможно для реализации задачи управления рисками, а также представлены UML-диаграммы, поясняющие структуру разрабатываемой системы и еѐ функциональность; Реализация проекта. В этой главе описывается реализация интерфейса и функциональных возможностей разработанного средства редактирования; Экспериментальная часть. В этой главе описывается применение нового средства управления рисками. Расчет себестоимости разработки программного продукта. В этой главе представлен расчет стоимости разработки системы. Охрана труда. В данной главе представлена техника безопасности при выполнении работы.

5


ВВЕДЕНИЕ За последние десятилетия в современном управлении проектами произошло большое количество изменений. Часть из них связано с упрощением проектной деятельности и обращение большего внимания вопросам рисков. Несмотря на то, что IT проекты могут быть связаны с большим или меньшим числом рисков, нет ни одного проекта, где бы риски полностью отсутствовали. На данный момент есть сформированные подходы к организации процесса управления рисками проектов:  инкрементная разработка;  итерационная;  спиральная;  водопадная и другие. Все подходы направлены на то, чтобы получить новую информацию как можно раньше, с тем, чтобы как можно раньше выйти на путь успеха и уменьшить стоимость и время последующих корректировок курса. Можно сформулировать универсальную стратегию снижения риска провала проекта:  внимательно следить за ходом проекта;  определять риски;  работать над устранением рисков в порядке убывания опасности для проекта; Однако, несмотря на простоту требований к процессу управления рисками, не существует методологии, применение которой гарантировало успешность проекта на 100%. Существуют методологии, которые, благодаря своим требованиям и правилам организации процесса управления рисками, позволяют продуктивно вести проектную деятельность. Примером таких методологий являются CORAS, OCTAVE, CRAMM, RUP, MSF и другие. Но при этом и эти методологии далеки от утопии.

6


Из-за отсутствия универсальной модели проблема организации процесса управления рисками сегодня все еще остро ощущается как в малых, так и крупных компаниях. Данная работа посвящена разработке системы управления рисками в вопросно-ответной среде моделирования WIQA.Net. Так как к процессу организации и осуществления управления рисками предъявляются определѐнные требования, то эти же требования должны составить базовую основу системы. Основная осуществления

цель

данного

проектной

средства

деятельности

– в

повышение

вопросно-ответной

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

7

эффективности среде


Постановочно-обзорная часть 1.1. Задача управления рисками 1.1.1. Значение управления рисками проектов. Управление рисками, связанными с разработкой ПО, представляет собой формальный

процесс,

позволяющий

систематически

идентифицировать,

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

определяется

как

совокупность

элементов

управлении

проектом,

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

с учетом графика работ.

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

Рис. 1. Интегрирование областей знаний, определенных в PMBOK и управление рисками [1]

8


На рис. 1 показано, какое место занимает управление рисками в жизненном цикле разработки ПО. Умение обрабатывать риски является основным в деятельности

любого

менеджера,

именно

эти

навыки

представляются

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

Рис. 2. Роль управления рисками в жизненном цикле разработки программного продукта 9


1.1.2. Определение риска В словаре "Толковый словарь русского языка" С.И. Ожегова риск имеет неоднозначную трактовку [12]: "Возможность опасности, неудачи"; "Действие наудачу в надежде на счастливый исход", тем самым, понятие "риск" включает в себя два по сути противоположных толкования: одно положительное, второе отрицательное. Аналогично, согласно толковому словарю Вебстера, риск – это «возможность потери или ущерба» [3]. Большинство людей ассоциирует концепцию риска с потенциальной потерей: риск может неблагоприятно сказаться на выполнении проекта. Неадекватная обработка риска может сказаться на результативности проекта и с высокой вероятностью закончиться тем, что потенциал решения не

будет реализован

полностью. Риски отличаются от проблем или ошибок, тем, что относятся к ожидаемым проблемам

и

неопределенностям

неблагоприятным

результатам,

а

или

потенциально

также

потерям

могут

привести

значения,

к

контроля,

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

являются

непременными

условиями

или

состояниями

текущей

деятельности, в то время как риски становятся проблемами или ошибками только в том случае, если не были обработаны должным образом. В MSF риск проекта (project risk) понимается именно в таком полном виде как всякое событие или условие, которое может оказать как негативное, так и позитивное влияние на итоги проекта. Такое же расширенное понимание спекулятивного риска (speculative risk) присутствует, например, в финансовой индустрии, где решения в условиях неопределенности могут привести к получению прибыли точно так же, как и к убыткам. [5]

10


1.1.3. Категории рисков План

управления

проектными

рисками

моделирует

12

категорий

потенциального риска для определенного проекта. 1.

Задачи

и

цели.

Каждый

одобренный

проект

должен

занимать

соответствующее место среди целей и задач организации. Те проекты, которые не соответствуют реальным целям организации, создают напряжение, влияющее на все проекты. Организационный менеджмент. Каждый из выбранных проектов должен вписываться в текущую или планируемую организационную структуру. Если организация не обладает подобной структурой или же еще не создана, трудно рассчитывать на успешную реализацию программного проекта. Заказчик. Все проекты должны иметь постоянную "обратную связь" с заказчиком. Проект разработки программного обеспечения требует обширных вводных данных, которые могут представить заказчики и конечные пользователи. Без подобного ввода данных самый удачный процесс разработки приведет к формированию только отлично функционирующей системы, не отвечающей реальным запросам конечных пользователей. Сокрытый здесь риск состоит в привлечении в команду неопытных сотрудников, не обладающих адекватным опытом по разрешению проблем, связанных с предметной областью. Такие сотрудники не смогут удовлетворять технические запросы разработчиков ПО. Бюджет/стоимость. Именно данная категория обычно привлекает наиболее пристальное внимание и оказывает влияние на все другие категории. Менеджеры проектов сосредотачивают внимание на бюджете и объемах затрат, поскольку именно эти рычаги позволяют задействовать широкий спектр возможностей, приводящих проект к успешному завершению. Для уменьшения риска, относящегося к этой категории, следует четко представлять размеры проекта, располагать достоверной предысторией о работе над подобными проектами, а также иметь достаточно полное представление о внешних влияниях, например, о технологии. 11


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

полного

тестирования

всех

модулей

и

их

интерфейсов.

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


процессы

фокусируются

на

процессах

конфигурационного

менеджмента,

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

Эта риска

категория

является

достигается

за

единственной, счет

где

набора

существенное опытной

и

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

Эта

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

категория

позволяет

количественно

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

13


1.1.4. Определение процесса управления рисками Управление рисками включает ясное понимание внутренних и внешних причин, влияющих на проект, которые могут привести к его срыву. Анализ рисков выполняется после формирования плана проекта. В результате начального анализа риска создается план рисков, который должен регулярно просматриваться и корректироваться. Главной целью управления рисками является идентификация и контроль за редко встречающимися факторами, которые приводят к вариациям проекта. Подобный подход отражается в формальном процессе, когда факторы риска систематически идентифицируются, оцениваются и поддерживаются. Что касается определения программы, то определение SEI довольно точно передает суть проблемы: "Риск отражает возможные существенные потери" [38]. При разработке программного проекта потери определяют негативное влияние на проект. Это влияние может привести к ухудшению качественных показателей конечного продукта, к увеличению затрат, смещению сроков или же к полному срыву проекта. Риски отражают неопределенность или же недостаточный объем знаний, касающихся спектра всех возможных будущих событий. Эти события можно разделить на благоприятные и неблагоприятные для выполнения проекта в будущем. Риск подразумевает лишь возможность появления существенных потерь или ущерба. Можно выделить следующие категории риска:  внутренний, который находится в сфере влияния менеджера проекта;  внешний, находящийся вне сферы влияния менеджера проекта. План разработки программного проекта представляет лишь прекрасно подготовленный

прогноз

относительно

запланированных

событий.

На

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

14


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

Рис. 3. Спектр неопределенности рисков [1] Менеджер проекта имеет дело с рисками, которые можно классифицировать следующим образом. 1. Известное в известном. Эти риски известны команде разработчиков проекта наравне с тем, что определена категория риска, а также реальные оценки рисков для данного проекта. В качестве примера подобного риска можно указать отсутствие исполнительного спонсора для крупных разделов проекта. Если исполнительный спонсор отсутствует, проявляющийся в этом случае риск относится к известному типу, а относительно его наличия в данном проекте также можно сделать определенные выводы. Риск, относящийся к категории "известное в известном", также может связываться с риском той категории, который можно смягчить в данном проекте. Эти риски указываются и описываются в плане по менеджменту проекта. 2. Известное в неизвестном. Эти риски известны команде разработчиков проектов, знакома категория риска, но неизвестны его реальные проявления для данного проекта. Например, отсутствие связи с конечным пользователем 15


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

в

том

случае,

если

проект

использует

специфическое

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

варьируются

от

использование

оценочных альтернативных

откликов подходов.

до На

действий, рис.

4

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


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

кто

предпочитает

избегать

рискованных

ситуаций,

воспользуются

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

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


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

включает

затраты

на

страхование

имущества,

ущерб

от

автомобильных аварий, пожаров и краж. Примером значительных косвенных потерь может служить защита участников контракта от непрямых потерь, которые можно понести по вине третьей стороны; устранение недоработок и замена оборудования. Юридическая ответственность предполагает защиту от правовых действий в случае возникновения ошибок в ходе проектирования, при формировании ложного общественного мнения и при нарушениях хода выполнения проекта. Наконец, примерами чистого персонального риска являются факторы типа компенсаций рабочим и затрат на замену служащих. [1] Среди тех понятий, которые входят в сферу изучения при обращении к управлению рисками, входит определение количественной степени риска. В этом случае используются следующие понятия:  рисковое событие: формальное описание тех событий, которые могут произойти и иметь какое-либо отношение к проекту;  вероятность риска: оценка возможности рискового события;  объем средств, "поставленных на карту": оценка потерь в случае неудовлетворительного результата;  выявление риска: потенциал полной ответственности за имеющийся риск;

18


1.1.5. Задачи процесса управления рисками. Принципиально подходы к процессу управления рисками можно описать следующей схемой: Идентификация

Извлечение уроков

Качественный анализ

Управление

Количественный анализ

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

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

Мониторинг и отчетность

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


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

разработки

методов

и

процедур,

способствующих

повышению

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

задачей

управлением

выполняется

осуществление

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

20


1.1.6. Идентификация рисков Процесс

идентификации

рисков

реализуется

с

помощью

тех

же

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


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

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


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

для

идентифицированных

рисков,

проектная

команда

может

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

Рис. 7. Диаграммный метод для представления классов и типов идентифицированных рисков 23


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

и

распространяется

перечень

вопросов,

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


4. Вероятностный анализ. Аналогичен анализу, базирующемуся на чувствительности. Добавляет вероятностное распределение для каждой переменной, что обычно уменьшает возможный оптимизм. 5. Имитация по методу Монте-Карло. Аналогична вероятностному анализу. Присваивает каждой переменной случайные значения. Имитация выполняется несколько раз для получения вероятностного распределения для результата. Необходимо сформировать диапазон вероятностных значений для результата. 6. Теория полезности. Представляет

отношение

к

риску

разработчика

решения.

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


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

проекта

от

идентифицированных

рисков.

При

этом

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

приоритетом

требуют

дополнительного

внимания

и

количественного определения зависимости от риска. Благодаря применению теории вероятности, наравне с деревьями решений, можно на основе множества альтернатив поддерживать механизм определения количественных оценок для риска. Например, если установлен бонус в размере 100 000 долларов за выполнение опережающего графика (агрессивный график, только если шанс на успех — не меньше 18%) и 250 000 долларов штрафа в случае невыполнения работы в срок в соответствии с каким-либо графиком (будем консервативны и установим 90% вероятности своевременного или более раннего завершения работ), вы будете стремиться работать по опережающему либо консервативному графику?

Рис. 8. Формула зависимости от риска С помощью дерева решения из примера на рис. 9 можно заключить, что при выборе опережающего графика потенциал для риска уменьшится 26


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

[1] Рис. 9. Дерево решений.

27


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

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

Ранжирование рисков, связанных с выполнением проекта, по категориям:  факторы риска и области;  низкая очевидность риска (L);  средняя очевидность риска (М);  высокая очевидность риска (Н);  рейтинг — уровень риска (например, Н, М, L или 3,2,1);  комментарии.

28


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

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

для

контроля

над

каждым

ключевым

риском,

устанавливая

ответственного за эти действия и дату их выполнения. Интегрируются ключевые риски в план проекта и уточняется их влияние на график и размер затрат. 1.1.8.4. Формирование отчета

Устанавливается формат отчета для регулярного риска. Этот отчет заслушивается на встречах, где рассматривается состояние проекта. Как минимум,

рассматриваются

состояние

"верхней"

десятки,

изменения

в

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

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

29


1.2. Обзор 1.2.1. Обзор существующих методологий. Сегодня существует несколько методологий управления ИТ-рисками. Суть методологии CORAS состоит в адаптации, уточнении и комбинировании таких методов проведения анализа рисков, как Event-Tree-Analysis, цепи Маркова, HazOp и FMECA. [17] CORAS

использует

технологию

UML

и

базируется

на

австралий-

ском/новозеландском стандарте «AS/NZS 4360 Менеджмент риска», выпущенном в 1999 г., и стандарте «ISO/IEC 17799-1 Свод правил по управлению защитой информации», принятом в 2000 г. В стандарте учтены рекомендации, изложенные в техническом регламенте «ISO/IEC TR 13335-1 Методы и средства обеспечения безопасности» (2001 г.) и в стандарте «IEC 61508 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью» (2000 г.) [17]. В соответствии с CORAS информационные системы рассматриваются не только с точки зрения используемых технологий, а как сложный комплекс, в котором учтен даже человеческий фактор. [20] Методология OCTAVE (Operationally Critical Threat, Asset and Vulnerability Evaluation) была разработана в Институте программной инженерии при Университете Карнеги - Меллона и предусматривает активное вовлечение владельцев информации в процесс определения критичных информационных активов и ассоциированных с ними рисков. Ключевые элементы OCTAVE:  идентификация критичных информационных активов;  идентификация угроз для критичных информационных активов;  определение уязвимостей, ассоциированных с критичными информационными активами;  оценка рисков, связанных с критичными информационными активами. «Сильной стороной OCTAVE является высокая степень гибкости, достигаемая путем выбора критериев, которые предприятие может использовать при 30


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

привела

к

созданию

версии

OCTAVE-S

для

небольших

предприятий». [18] Методология CRAMM (CCTA Risk Analysis and Management Method) разработана британским Центральным компьютерным и телекоммуникационным агентством в 1985 г. и применяется как для крупных, так и для небольших организаций

правительственного

программного

обеспечения

и

CRAMM,

коммерческого ориентированные

секторов. на

разные

Версии типы

организаций, различаются своими базами знаний, или «профилями». CRAMM предполагает использование технологий оценки угроз и уязвимостей по косвенным факторам с возможностью проверки результатов. В нее заложен механизм моделирования информационных систем с позиции безопасности с помощью обширной базы данных по контрмерам. CRAMM нацелена на детальную оценку рисков и эффективности предполагаемых к использованию комбинаций различных контрмер. [21] COBRA является средством анализа рисков и оценки соответствия стандарту BS7799, реализующим методы количественной оценки рисков, а также инструменты для консалтинга и проведения обзоров безопасности. При разработке инструментария COBRA были использованы принципы построения экспертных систем, обширная база знаний по угрозам и уязвимостям, а также множество вопросников.[10] RiskWatch - фактически американский стандарт в области анализа и управления рисками. Аналогично методу CRAMM в качестве критериев для оценки и управления рисками в нем используются предсказания годовых потерь (Annual Loss Expectancy - ALE) и оценка возврата от инвестиций (Return on Investment - ROI). [11] «АванГард» позволяет построить структурную модель АИС, модель угроз и модель событий рисков, связанных с отдельными составляющими АИС, и, таким образом, выявить те сегменты и объекты, риск нарушения безопасности которых 31


является неприемлемым, т. е. критичным. Кроме того, ПК «АванГард-Анализ» дает возможность построить модель защиты - систему мер и требований с целью обеспечения

безопасности

АИС,

и

выработать

оптимальный

комплекс

мероприятий по защите. Одной из вспомогательных функций, заложенных в данной системе, является построение профилей защиты на основании требований, сформулированных в ГОСТ Р ИСО/МЭК15408-2002. [3] Компания MethodWare разработала собственную методику оценки и управления рисками и выпустила ряд соответствующих инструментальных средств: ПО анализа и управления рисками Operational Risk Builder и Risk Advisor - методика соответствует австралийскому стандарту Australian/New Zealand Risk Management Standard (AS/NZS 4360:1999) и стандарту ISO17799; ПО управления жизненным циклом информационной технологии в соответствии с CobiT Advisor 3rd Edition (Audit) и CobiT 3rd Edition Management Advisor. [12] Рассмотренные методологии хорошо соответствуют требованиям групп «Риски» и «Менеджмент», но все они имеют недостатки в соответствии с разделами «Мониторинг» и «Управление». Все три метода не предполагают расчета оптимального баланса различных способов управления, не имеют средств интеграции способов управления и не дают механизмов управления рисками остаточного уровня. Так же во всех трех методологиях не производится оценка качества процесса реагирования на инциденты в области информационной безопасности. Ни одна из методологий не дает подробных рекомендаций по поводу составления расписания проведения повторных оценок ИТ-рисков, и в двух методологиях совершенно упущено из виду обновление величин рисков. В случае если требуется выполнить только разовую оценку уровня ИТ-рисков в компании любого размера, целесообразно применять методологию CORAS. Для управления ИТ-рисками на базе периодических оценок на техническом уровне лучше всего подходит CRAMM. Методология OCTAVE предпочтительна для использования в крупных компаниях, где предполагается внедрение управления ИТ-рисками на 32


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

российских

компаниях

ситуация

осложняется

ограничениями

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

33


1.2.2. Проектные риски и Институт SEI Институт

программного

инжиниринга

(SEI)

(входящий

в

состав

Университета Карнеги-Меллон) разработал модель оценки рисков при разработке программ,

основанную

на

цикле

Шухарта-Деминга

(Shewhart-Deming).

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

34


Рис. 10. Цикл Шухарта-Деминга (Shewhart-Deming)

35


1.2.3. Модели управления рисками Институтами управления проектами и программного инжиниринга была проведена

идентификация

нескольких

моделей

управления

рисками,

подготовленных менеджерами проектов. При рассмотрении этих моделей также использовалась работа Барри Боэма (Barry Boehm), содержащая парадоксальные выводы относительно процесса разработки ПО. На рис. 10 демонстрируется, что управление рисками, связанными с проектом, предполагает наличие следующих элементов. Идентификация риска — определение источников возникновения риска, идентификация потенциальных рисковых событий и симптоматики риска. Определение

количественных

показателей

риска

применение

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

откликов

идентификация

управление

резервов,

рисками

выраженных

и как

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

денежном

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

и

контроль

разработка

планов

корректирующих

мероприятий и просмотр результатов внедрения как части всестороннего внедрения плана управления рисками. Процесс управления рисками, описанный Барри Боэмом, первоначально излагался в справочнике "Software Risk Management", изданном IEEE Computer Society Press в 1989 году [38]. На рис. 11 показано графическое представление данной модели. Управление рисками включает два аспекта — оценивание риска и контроль. Процесс оценивания риска подразделяется на процедуры идентификации риска, анализа и установки приоритетов. 36


Идентификация рисков выполняется с помощью методик контрольных списков,

анализа

принимаемых

решений

и

устранения

проблем.

Если

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

Рис. 11. Модель Барри Боэма (Barry Boehm) С помощью этих инструментов команда разработчиков сможет более четко представлять особенности предметной области, с учетом которой разрабатывается программное обеспечение, и сосредоточить внимание на особенностях общего плана уже определенных классов риска. Анализ

идентифицированных

рисков

выполняется

с

использованием

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


размеры затрат, формировать сценарии по принципу "что, если". Значения этих переменных оцениваются на основе представлений, присущих изначально предметной области, где исследуется данная проблема. Можно добавить усовершенствованные статистические методики типа метода Монте-Карло, что позволит в дальнейшем проводить дополнительный анализ. Анализ сетевого и качественного факторов, а также фактора выбора решения позволяет команде разработчиков проекта получить расширенные представления об информации, которая разрабатывается в процессе анализа проблемы при выполнении идентификации рисков. После идентификации и анализа рисков следует определить относительный потенциал их проявления и влияния на проект. Уточнение приоритетов рисков позволяет команде разработчиков проекта обратить пристальное внимание на несколько критических факторов риска. Именно они наиболее опасны и могут послужить причиной возникновения сбоев при выполнении проекта. Для каждого риска, имеющего высокий уровень приоритета, должно проводиться вычисление его вероятности. Действие риска заключается в определении количественных показателей,

характеризующих

проявление

риска.

Сначала

вычисляется

вероятность текущего проявления риска (RE, risk exposure), а затем определяется это же значение RE после выполнения действий по смягчению риска. Определяется

стоимость затраченных

усилий

по

выполнению действий,

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

собой

простое

разложение

многофакторных

рисков

на

однофакторные компоненты, что позволяет оценить приоритеты среди рисков. Управление

рисками

включает

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

менеджмента

рисков,

определение и мониторинг рисков. Наряду с оцениванием рисков эти три компонента поддерживаются наборами инструментов и методик. 38


Рис. 12. Процесс управления рисками. [39] Меры, позволяющие избежать проявления рисков, представляют такие возможности по реструктуризации проекта и продукта, которые помогают не допустить проявления данного риска. Передача риска обычно предполагает заключение

страхового

договора,

покрывающего

издержки

этого

риска.

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


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

предлагают

дополнительные

инструменты

и

возможности.

Эти

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

рисков

и

выполнение

инструменты,

корригирующих

реализующие

действий

отслеживание

позволяет

рисков.

Эти

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

40


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

Gantt Designer — самая простая и маленькая (занимает всего 524 Кбайт) из рассматриваемых программ. Она предназначена для того, чтобы быстро и просто строить диаграммы Ганта. На такой диаграмме проект представлен столбцами полосок на оси времени, соответствующими продолжительности той или иной работы. Каждая отдельная работа может либо начаться по окончании одной или нескольких предыдущих, либо вестись параллельно и независимо от других работ. Программу Gantt Designer следует рассматривать скорее как инструмент рисования диаграмм, чем систему планирования. Она не поможет рассчитать критический путь, да и вести учет затрат в ней проблематично. Зато для оформления диаграмм предусмотрена богатая палитра цветов, штриховок и заливок, поэтому данная программа подходит лишь для быстрого оформления наглядных пособий и отчетов. Однако, несмотря на малый функционал, данная программа используется при планировании рисков из-за наглядности задач, требуемых выполнения. 1.2.4.2. GanttProject

Программа

GanttProject,

будучи

совершенно

бесплатной,

функциональности уже вплотную приблизилась к коммерческим аналогам.

41

по


GanttProject предназначена для создания расписаний и отслеживания хода выполнения проекта с помощью диаграмм Ганта и применяемых ресурсов. Причем предполагается, что пользователь хотя бы в общих чертах знаком с такими методами планирования. Если же нет, то стоит сначала просмотреть Wikipedia [13] или познакомиться с соответствующей литературой. GanttProject дает возможность создать для проекта дерево задач, выделить на каждую из них определенное количество времени и закрепить за ней людские ресурсы. В программе указываются имена исполнителей и их контактные данные. Затем можно установить зависимость между отдельными задачами. На основе всех данных GanttProject генерирует графическое представление проекта в виде диаграммы Ганта для отображения задач и диаграммы использования ресурсов. Разумеется, полученные диаграммы можно изменять, распечатывать, генерировать PDF- и HTML-отчеты. Более того, программа умеет обмениваться данными с Microsoft Project (в форматах MP и XML) и программами обработки электронных таблиц. Это делает GanttProject совместимой не только с флагманом индустрии, но и с другими аналогичными программами, поскольку в большинстве случаев они стремятся поддерживать импорт в формате Microsoft Project. Преимущества GanttProject по сравнению с коммерческими пакетами?  Широкий (и постоянно растущий) набор функций. Его можно считать оптимальным для большинства пользователей, ведь исследования показывают, что 80% пользователей Microsoft Project задействуют не более 20% его функций.  Простота освоения. Не понадобятся объемные руководства, чтобы работать с GanttProject. Если пользователь имеет представление о целях проекта, фазах выполнения, задачах и их зависимостях, то за считанные часы станет экспертом по GanttProject. Разработчики не оставили ему ни единого шанса зайти в тупик — в стандартную поставку GanttProject входят великолепный справочник и очень показательный пример проекта «Постройка дома». 42


 Стоимость. Коммерческие программы управления проектами недешевы, а GanttProject бесплатен для любых применений. Пожалуй, дешевле GanttProject может обойтись только та программа, за использование которой разработчики готовы платить деньги.  Кроссплатформенность. GanttProject написан на языке Java и работает под управлением Windows, Linux, Mac OS X и других систем, где поддерживается Java.  Открытый исходный текст. Каждый может доработать GanttProject с учетом

своих

нужд,

реализовать

новые

функции

и

добавить

специализированную отчетность.  Локализация. Большая часть программы (за исключением руководства пользователя и нескольких советов дня) переведена на русский язык. 1.2.4.3. OpenProj

Открытый и бесплатный аналог MS Project . Так же как и GanttProject, программа OpenProj написана на Java и работает на любой аппаратнопрограммной платформе, включая Windows, Linux и Mac. Она выглядит, пожалуй, даже более мощной благодаря богатому арсеналу средств для анализа проектов. В ней доступны не только диаграммы Ганта, но и сетевые графики (PERT), диаграммы освоенных объемов работ и использованных ресурсов (WBS и RBS), а также фактических затрат (Earned Value). Разработчики позиционируют OpenProj как полноценную замену Microsoft Project и другим коммерческим аналогам. Компания Projity распространяет OpenProj совершенно бесплатно с открытым исходным текстом. Видимо, персональная программа OpenProj используется в качестве «зонтичного бренда» для более мощной системы Project on Demand (POD), предназначенной для коллективной работы над проектами. Обе системы строятся на одной и той же базе исходных текстов, поэтому OpenProj и обладает такими недюжинными аналитическими способностями.

43


OpenProj — действительно мощная система управления проектами. Она переведена на множество языков, в том числе на русский, и умеет работать с файлами форматов Microsoft Project и Gnome Planner. Так, по удобству работы OpenProj явно уступает другим программам — в стандартной поставке нет ни файлов помощи, ни примеров. По внешнему оформлению она отдаленно напоминает MS Project, но большие кнопки для переключения режимов отображения проекта в левой панели сделаны настолько топорно, что возникает ощущение, будто работаешь с устаревшей версией. Да, проекты MS Project открываются в OpenProj просто великолепно, но импорт данных из других программ происходит уже не столь надежно. Например, так и не удалось открыть созданный в Gnome Planner проект. 1.2.4.4. Open Workbench

Еще одним великолепным решением в области управления проектами может стать Open Workbench. Это довольно мощная программа, функционально близкая к коммерческим продуктам. Однако у нее есть существенные недостатки. Так, она работает только в системе Windows, не имеет перевода на русский язык и последний релиз датируется декабрем 2005 г. И все же это одна из самых удобных программ в данном обзоре. В ней легко открыть проекты, сделанные в GanttProject и экспортированные в MS Project XML, правда, затем все же требуются небольшие исправления. Программу отличает бережное использование экранного пространства. В одном окне, поделенном на фреймы, помещаются дерево задач, диаграмма Ганта и список людских ресурсов. В левой части окна предустановлены режимы просмотра, а также допускается создавать собственные. Надо сказать, что Open Workbench очень гибкий и простой в освоении инструмент. Имея базовые знания английского, нетрудно быстро научиться работать в этой программе. В ее стандартный дистрибутив входит обширная справочная система, а на сайте представлены примеры и руководство пользователя в форматах MS Word и Adobe Acrobat. 44


1.2.4.5. Gnome Planner

Разработчики Gnome Planner также не торопятся с выпуском новых версий своей системы управления проектами. Последняя из них, для работы под управлением Windows, была собрана в конце 2006 г. По возможностям Gnome Planner находится на уровне GanttProject, но функционирует немного быстрее. Для использования Gnome Planner for Windows понадобится установить библиотеку GTK+, имеющуюся, например, на сайте GIMP for Windows. Когда эта программа работает под управлением Windows, то имеет те же ограничения, что и другие приложения, написанные на GTK+. Например, функции копирования вставки и замены приходится использовать через контекстное меню мыши или систему меню приложения. 1.2.4.6. Коллективное управление проектами

Все рассмотренные в данном обзоре программы являются персональными инструментами, однако и для коллективной работы над проектами создано довольно много продуктов. Коммерческие решения в этой области предлагают различные фирмы, в том числе разработчики OpenProj (Project-on-Demand) и Open Workbench (Clarity). Впрочем, есть также бесплатные многопользовательские системы управления проектами с открытым исходным текстом. К примеру, свободный вариант разработанной в Австрии программы OnePoint Project [14] успешно прижился на российской почве. Локализованный вариант можно переписать с сайта http://onepointproject.narod.ru/. По количеству функций и удобству работы этот продукт приближается к лидеру сектора — Primavera [15]. Еще одно веб-ориентированное решение, DotProject [16], предлагает независимая группа разработчиков. На сайте проекта можно переписать пакет локализации и десяток различных дополнений — от фильтров импорта MS Project до подсистемы управления рисками. 1.2.4.7. Microsoft Enterprise Project Management Solution (EPM).

В этом решении в полной мере реализованы все этапы за исключением количественного анализа. Система поддерживает работу со всеми группами 45


внутренних и внешних рисков и помогает заранее определить методы их устранения либо реагирования при возникновении таковых. 1.2.4.8. Spider Project.

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

резервов,

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

реагирования

на

риски,

контроль

изменения рисков и фиксацию трендов вероятностей успешного соблюдения директивных показателей. При этом нет никаких ограничений по видам внешних и внутренних рисков. 1.2.4.9. “Офис Управления Проектами – РМО”.

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


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

автоматическое

уведомление

руководителю

проекта

и,

при

необходимости, высшему руководству. Участники проекта через on-lineконференцию могут обсудить возникшую проблему и совместно выработать решение по ее устранению. Система автоматически уведомляет участников в случае отклонения проекта от сроков или бюджета. 1.2.4.10. Primavera Pertmaster.

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

47


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

процесса

управления

рисками

в

вопросно-ответной

среде

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

рисками.

представление

рисков

Необходимо и

представить

выделить его

в

причинно-следственное вопросно-ответной

среде

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

возможностей

вопросно-ответной

среды

WIQA.NET

для

реализации процесса управления рисками. 5. Представление рисков, проектной среды и процессов

в вопросно-

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

48


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

49


Проектная часть. В

процессе

проектирования

предстоит

описать

архитектуру

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

которое

позволяет

описать

архитектуру

системы

и

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

и

описывают

разрабатываемую

систему

с

разных

пользовательских позиций. Диаграмма вариантов использования (Use-Case diagram) применяется для описания

функциональности

применение

позволяет

системы,

описать

которая

основные

видна пользователям. Еѐ

функции,

которыми

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

50

обладает


2.1. Анализ имеющихся средств. 2.1.1. Дерево контекстных атрибутов. В

системе

предполагается

использование

механизма

контекстной

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

через

дерево

контекстных

атрибутов

c

использованием

прецедентов.

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

чтобы

обеспечить

данные

возможности

редактирования

требуется

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

51


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

Рис. 14 Плагин «Организационная структура». Выбор проекта для работы.

52


2.1.3. Плагин «Методики» В

разрабатываемой

системе

задача

управления

рисками

проекта

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

Для

методического

обеспечения

QA-протокола

предполагается

использование плагина «Методики». Для решения задачи идентификации рисков предлагается использовать методику «Мозговой штурм», при выполнении которой на основе прецедентов выполняется занесение рисков в QA-протокол проекта для обеспечения дальнейшего управления рисками. Также использование прецедентов в других методиках, например методиках анализов рисков, позволит упростить процесс управления рисками автоматизировав его. 2.1.3. Плагин «Прецеденты» В разрабатываемой системе задача управления рисками сопряжена с работой с базой знаний рисков, при которой требуется выполнять задачи сохранения информации в базе знаний рисков и извлечения единиц опыта в QAпротокол проекта. Для сохранения и контролируемого извлечения единиц опыта проектной организации предполагается использовать плагин «Прецеденты».

53


2.2. Представление задачи управления рисками в WIQA.NET Процесс управления рисками тесно связан с общим жизненным циклом проекта, соответственно, сам процесс объединяется в единое целое с другими задачами проектирования и неотделим от них на протяжении всего жизненного цикла проекта, или, по-другому говоря - объединение задач управления рисками с остальными задачами проекта не просто позволяет наиболее цело представлять картину происходящего и качественнее регулировать планирование управление проектом, оно необходимо. Риски рассматриваются непосредственно для проектов, существующих в вопросно-ответной среде. Для

управления

рисками проекта необходимо

реализовать задачу управления рисками у выбранного проекта. Сама задача управления рисками состоит из подзадач, которые позволяют реализовать определенный функционал. Пусть существует проект Z. У данного проекта существует определенный список задач, например задача документирования, коммуникации и т.п. Данные задачи обозначим Z.1, Z.2 и т.д. Задачу управления рисками будем называть Z.I – задачей, в таком случае задачами Z.I.1, Z.I.2, …, Z.I.К – будут называться подзадачи задачи управления рисками, например идентификация, качественный анализ и т.п. Каждая подзадача задачи управления имеет вопросно-ответную модель. В управлении рисками эта модель процедурного типа, где для каждой задачи фиксируется в вопросно-ответном плане методика ее решения. Данное представление проекта позволяет оценить целостную систему управления. Графически вышесказанное можно представить следующим образом (см. рис. 13):

54


Z.1 Задача коммуникации

Z.2 Задача документирования

Z.I.1 Идентификация

Z. …

Z.I.2 Качественный анализ

Z.I Задача управления рисками

Z.I.3Количественный анализ

Z.N …

Z.I.K Извлечение уроков

Z Проект

Z.I.... ...

Рис. 15. Дерево проекта Z Этап формирования рисков представлен в виде последовательных ответов на вопросы, в ходе которых заполняется соответствующая информация для рисков, и устанавливаются требуемые связи. Таким образом, этап формирования рисков позволяет, продвигаясь по QA дереву, характеризующему задачи и риски, квалифицировать

риски,

присущие

проекту,

при

этом

добавлять

им

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


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

56


2.3. Представление риска как объекта вопросно-ответной среды Формулирование риска осуществляется пользователем в процессе выполнения методики идентификации рисков и представлено в виде процесса ответа на вопросы и решения требуемых задач, в результате которого будет получена требуемая информация. Также формулирование рисков возможно на основе прецедентов. Рассмотрим задачу «Идентификация рисков». В процессе идентификации рисков выполняется выделение рисков из существующей базы знаний, если риск известен и был идентифицирован в предыдущих проектах, либо определение и формулирование рисков на основе опыта ответственных лиц и внесение новых рисков в базу знаний рисков проектов. В ходе выполнения задачи идентификации выделенным рискам устанавливается соответствующая атрибутика, которая может быть дополнена и модифицирована на следующих этапах процесса управления рисками проекта. При выделении риска для него создается вопросно-ответная модель на основе шаблонов. Данную модель будем называть «объектом риска». Для создания объекта риска команде необходимо ответить на следующие вопросы: 1. Каков класс1 риска? 2. Каков источник2 риска? 3. Какие факторы вызывают появление3 риска? 4. Какие факторы вызывают развитие4 риска? 5. На какие области5 риск оказывает воздействие? 6. На какие объекты оказывает влияние6 риск? 7. Кокой тип7 воздействия риска?

1

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

57


8. Почему8 риск оказывает влияние на объект? 9. Каков приоритет9 по отношению к другим рискам? 10. Кто обнаружил риск?10 11. Когда риск был обнаружен?11 12. Кому поручен риск?12 13. Каков статус риска?13 При этом все вопросы, на которые требуется ответить команде разработчиков, а также задачи, требуемые выполнения, хранятся в шаблоне «Определения рисков», представленный на рис. 14. Данный шаблон может быть дополнен в процессе идентификации рисков, если данных в нем не достаточно для описания определенного риска.

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

Ответ на данный вопрос на этапе идентификация риска необходим для построения взаимосвязей и идентификации нерассмотренных рисков. 9 Ответ на данный вопрос не требует рассмотрения всех рисков, их влияния и важности. Он, в идеальном случае, должен быть субъективной оценкой, выставленной по шкале с большим ранжированием. Например от стремления к 0 до 100. 10 Лицо, обнаружившее риск 11 Дата обнаружения риска 12 Ответственное за риск и контроль за риском лицо 13 Статус риска, согласно его влиянию на проект или другие сущности

58


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

При

сформулированной

этом

обязательным

причины

появления

требованием риска,

и/или

является

наличие

процесса,

которые

поддерживает активность рисков. Для всех рисков имеется класс по-умолчанию «Риск», который реализован в виде «шаблона» и обладает свойствами:  Название риска  Код риска  Описание риска  Класс риска  Источник риска  Лицо, ответственное за риск  Дерево изменений риска o Дата обнаружения риска и Лицо, обнаружившее риск o Дата начала влияния риска на проект o Дата закрытия риска и Лицо, закрывшее риск  Дерево факторов-причин  Дерево факторов катализаторов  Дерево следствий  Статус риска  Область среды проекта, на которые риск влияет  Тип риска

59


Рис. 17. Шаблон формулировки риска в QA-протоколе проекта. Название риска содержит формулировку риска, понятную человеку. Основное предназначение – быстрый поиск риска в списке рисков проекта. Названия рисков в одном и том же проекте могут быть сходными, поэтому вводится подробное описание риска, которое будет более подробно освещать суть риска. Код Риска – это уникальный код, который позволяет идентифицировать риск. Код риска может быть использован, например, в сопроводительной документации к проекту. Код риска проекта формируется автоматически из информации, известной о риске. Описание риска содержит подробное описание риска, необходимое для быстрого понимания риска персоналом, который имеет доступ к рискам и процессу управления рисками. Класс риска отражает сферу, в которой существует риск. Источник риска является конкретизацией класса риска. 60


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

Рис. 18. Контекстная атрибутика у риска. Указание идентификатора вопросноответной единицы (причины риска). 61


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

62


2.4. Факторы среды и их взаимодействие с рисками В ходе работы по идентификации рисков устанавливается множество связей с условиями возникновения и развития критичных ситуации, что в особенности усугубляется взаимосвязью процессов, протекающих в различных областях существования проекта. Это означает, что к каждому проекту должен применяться комплексный подход. Среда существования проекта может быть описана множеством факторов, между которыми можно установить причинно-следственные связи. Будем считать, что риски не могут возникать автономно и не могут существовать изолированно. Причинно-следственные связи позволяют представить развитие событий и конкретизировать политику управления рисками проекта. По мере того, как знания о проекте и его рисках будут накоплены в большей степени, становятся очевидными «узкие» места проектов и среды, которые требуют усиленного внимания и определенных действий, для стабилизации обстановки. В системе управления рисками WIQA.NET риском считается любая ситуация неопределенности, которая может повлиять на проект, или факторы среды существования проекта, или другими словами: риск - зависимость будущего состояния субъекта от неопределенности. Причиной считается условие возникновения риска. Причиной можно считать риск с вероятностным исходом до 100%, то есть очевидное событие. Следствие – это результат развития риска. Фактор катализатор – условие существования и/или развития риска. Проект – это уникальная совокупность скоординированных действий с определенными точками начала и окончания, предпринятая индивидуумом или организацией для достижения определенных целей с установленными сроками, затратами

и параметрами выполнения.

В процессе управления рисками рассматриваются следующие причинноследственные связи:  Риск – Риск 63


 Риск – Проект Это обобщенное представление отношений. Практически все условия существования среды проекта могут быть в состоянии неопределенности и иметь вероятностную оценку, тем самым могут считаться риском. При этом отношение Риск – Риск может быть представлено более подробно в виде:  Причина –> Риск  Риск –> Следствие  Фактор-катализатор –> Риск  Риск –> Риск Данные отношения могут быть сгруппированы с распределением влияния одной сущности на другую. Таким образом, возможно построение связей, которые способны описать процессы и явления проектной среды, что в свою очередь упрощает процесс управления рисками. 2.4.1. Причины и условия сущностей среды Эффективная обработка риска помогает повышать вероятность успеха проекта за счет минимизации потенциала вреда от риска и максимизации потенциала пользы от него. Для достижения требуемого эффекта в процессе управлении риском могут применяться различные стратегии. Причины появления рисков или факторы будем считать рисками со 100% вероятностью исхода. Факторы могут быть непосредственной причиной

появления риска (факторы-причины) или

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

64


2.4.2. Следствия и результаты сущностей среды Любой риск должен иметь следствие. При отсутствии следствия риск не может оказывать влияния на проект, следственно не должен рассматриваться. Часто один и тот же риск может иметь вариационный исход, из чего следует, что следствие из риска можно также назвать риском с определенной вероятностью исхода. Притом вариативность исхода может зависеть от факторов самого риска, что позволяет установить связь между причиной и следствием. Взаимосвязи и влияния сущностей друг на друга и на проект отображены на рис. 19. Причина 1 Риска 7 Фактор 1 Риска 1

Фактор 3 Причина 2 Риска 8 Риска 7

Риск 7

Фактор 1 Риска 8

Риск 1

Риск 8 Риск 2

Жизненный цикл проекта

Фактор 2 Риска 8 Фактор 1 Риска 2

Результат Фактор 1 Риска 3

Риск 3

Фактор 1 Риска 5

Риск 5 Фактор 2 Риска 5

Рис. 19. Связи сущностей.

65

Риск 4 Риск 6 Фактор 2 Риска 6

Фактор 1 Риска 4 Фактор 1 Риска 6


2.7. Концептуальное представление элементов среды проекта Концептуальная схема — это шаблон конструирования для модели объектов, который будет использоваться приложениями, построенными на основе модели Entity Data Model (модель EDM). Имя пространства имен, объявленное в концептуальной схеме, будет использоваться для уточнения имен классов сущностей и ассоциаций в сформированной модели объектов. Архитектура модели EDM предоставляет основную структуру сущностей и ассоциаций. Разработчики приложений порождают сущности и ассоциации на основе этих типов. Типы, определенные в концептуальной схеме, сопоставляются с метаданными, описывающими модель хранения. Концептуальная схема использует диалект XML, называемый языком CSDL. В метаданных хранилища используется диалект XML, называемый языком SSDL. Концептуальное представление элементов среды и связей отображено на рис. 20 на примере событий рисков: E11+E12+E13<=1 и E11+F+R13<=1. R12 изменение статуса R13 Вероятность воздействия

*

*

Е12

1

1..*

О

1..*

Следствие риска результат

*

Вероятность воздействия

1..*

Риск события

*

*

F

*

1

Е11

Вероятность воздействия

*

*

Фактор риска

*

Е13 Изменение статуса

1 R111

Реакция на риск параметры

1..* ES 1 Реализация риска

результат

Итоговый результат данные для оценки

Рис. 20. Концептуальное представление элементов среды и отношений

66


2.5. Диаграмма развертывания. На представленной ниже диаграмме развѐртывания показана схема взаимодействия системы управления рисками, базы данных рисков, вопросноответного протокола, вопросно-ответных шаблонов, методик решения задач и прецедентов. ПК под управлением WINDOWS c WIQA.NET БД рисков Плагин "QA-шаблоны"

Плагин "Управление рисками"

Плагин "Организационная структура" Плагин "Контекстная атрибутика"

Плагин "QA-протокол" Плагин "Прецеденты"

Плагин "Методики"

Рис 21. Диаграмма развѐртывания.

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

67


2.6. Диаграмма вариантов использования. Взаимодействовать с системой могут два класса пользователей – редактор, который занимается непосредственно редактированием и подготовкой шаблонов к дальнейшему использованию в системе документирования и пользователь, имеющий возможность просматривать шаблоны представления документов. Ниже приведена диаграмма вариантов использования (Use-Case Diagram), поясняющая возможности каждого из этих классов пользователей.

«uses» Обзор причин

Определение стратегии

Сотрудник «uses»

Идентификация рисков Мониторинг рисков

Анализ рисков Контроль рисков Управление риском Менеджет проекта

Рис 22. Диаграмма вариантов использования системы.

68


2.8. Интеграция системы управления рисками Разработка системы управления рисками включает в себя несколько этапов и представлена на рис. 23.

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

69


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

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


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

методы

управления

рисками

можно

разделить

на

группы:

1. Группа методов, использующих только внутренние ресурсы:  Уклонение от риска;  Ограничение объема принимаемого риска;  Предупреждение риска;  Локализация риска;  Обеспечение риска. 2. Группа методов, связанных с диверсификацией:  Непосредственная диверсификация;  Диверсификация, предполагающая принятие на себя рисков прочих лиц. 1. Группа методов управления риском, при использовании которых риск передается другим лицам:  Страхование рисков;  Взаимное страхование рисков;  Секьюритизация рисков;  Прочие способы передачи риска.

71


3. Хеджирование рисков14:  Прямое хеджирование, в том числе и через рынок производных финансовых инструментов;  Хеджирование через финансового посредника, например банк.

14

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

72


Реализация проекта 3.1. Модули проекта. Реализованное средство управления рисками охватывает следующие модули: Модуль

Файлы *.cs

PRiskManager_Client

RiskForm.cs

PRiskManager_Connector

IRiskManager.cs

PRiskManager_Server

RiskManagerServer.cs Таблица 1. Модули проекта.

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

связей,

поддержку

атрибутики рисков.

73

механизма

дополнительной


3.2. Взаимодействие с пользователем. 3.2.1. Реализация интерфейса плагина «Управление рисками» Для повышения эффективности процесса управления рисками в вопросноответных средах был разработан плагин, который позволяет отобразить информацию о рисках в виде, удобном для использования и интуитивно понятном пользователю.

Рис. 25 Плагин «Управление рисками» Информация для формы извлекается из QA-протокола проекта, управление рисками

которого

осуществляется.

В

разработанном

плагине

возможно

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

74


3.2.2. Реализация поддержки механизма дополнительной атрибутики. Одной из особенностей реализованного средства управления является поддержка связей между сущностями среды проекта на основе механизма дополнительной атрибутики, которая позволяет напрямую работать с атрибутами риска в процессе управления рисками. Данная возможность реализована через элементы управления в плагине «Управление рисками».

Рис. 26. Дерево атрибутов рисков. Функции, доступные при работе с атрибутами: 1. Сохранение атрибутов из дерева атрибутов либо его узлов в XML-файл. 2. Загрузка в дерево атрибутов новых атрибутов риска из XML-файла. 3. Создание новых атрибутов. 4. Редактирование названия, типа и описания атрибутов. 5. Удаления атрибутов из дерева атрибутов. 6. Обновление атрибутов в дереве атрибутов.

75


Экспериментальная часть 4.1. Использование плагина «Управление рисками». Для управления рисками проекта возможно использование плагина «Управление рисками» или «Вопросно-ответный протокол» из списка доступных плагинов системы WIQA.NET.

Рис. 27. Главное окно системы WIQA.Net. При вызове плагина из списка доступных плагинов необходимо сообщить проект, с которым требуется работать. В нашем случае проект будет «Разработка системы управления рисками». Рассмотрим первый вариант решения задачи управления рисками, то есть запустим плагин «Управление рисками».

76


Рис. 28. Выбор проекта для загрузки рисков в систему управления рисками. При выборе проекта будет отображен список текущих рисков для проекта. Риски импортируются из QA-протокола выбранного проекта. После выбора из данного списка можно осуществлять работу над определенным риском.

Рис. 29. Информация о риске в плагине «Управление рисками» 77


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

Рис. 30. Методика идентификации рисков

Рис. 31. Методика решения подзадачи в задаче идентификации рисков. 78


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

прецедент

для

объявления

риска.

Текст

xml

файла,

предназначенного для объявления программного прецедента, используемого для решения данной задачи приведен в листинге 1: <?xml version="1.0" encoding="windows-1251" standalone="yes"?> <Rules> <RuleGroup id="1" code="using System;&#xA;using System.Diagnostics;&#xA;using System.Collections.Generic;&#xA;using PRiskManager_Connector;&#xA;&#xA;public class risk_identification_rule_1 : RIRule {&#xA; public object makeAction(object data) {&#xA;

var

temp = (object[])data;&#xA; var risk_object = PRiskManager_Connector.get_risk_object(temt[0][idrisk]);&#xA; if(!risk_object.isExist){&#xA;

new_data =

PRiskManager_Client.HandEnterRiskObject(data);&#xA; }&#xA;

&#xA;

return new_data;&#xA;

&#xA; var attributesIndex = (List&lt;int&gt;)temp[1];&#xA;

= (String[])temp[2];&#xA; var temp2 = new List&lt;object&gt;();&#xA; index in attributesIndex) {&#xA;

var curAttributes

&#xA;

foreach (int

PRiskManager_Connector.InsertRiskResult curRisk =

PRiskManager_Connector.curAttributes.AttributesList.attribute[index].SetAttr;&#xA; temp2.Add(curRisk);&#xA; }&#xA; public float getPriority() {&#xA;

&#xA;

return temp2;&#xA; }&#xA; &#xA;

return 1;&#xA; }&#xA; &#xA; public string getName() {&#xA;

return &quot;ОпределениеРиска&quot;;&#xA; }&#xA; &#xA; public bool needBreak() {&#xA; return false;&#xA; }&#xA;}" name="main" GAC_Links="PRiskManager_Connector" ReferenceGroups=""> <RuleName>risk_identification_rule_1</RuleName> </RuleGroup> </Rules>

Листинг 1. XML файла с правилом прецедента объявления риска.

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

79


4.3. Распределение задач процесса управления рисками В процессе идентификации рисков возможна ситуация некомпетентности ответственного лица в той или иной области. В таком случае требуемая задача может быть назначена группе или отдельному лицу. На рис. 32 отображено назначение задачи оценки временных затрат для группы «Менеджеры проекта».

Рис. 32. Назначение задачи идентификации риска группе сотрудников.

80


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

внимание

при

решении

задачи

управления

рисками

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

Рис. 33. Внесение информации о причине риска. Для добавления связи требуется использовать атрибут связи к QA-единице идентифицирующей номер связи. Значением атрибута является идентификатор QA-единицы, в которой указана причина риска.

81


Рис. 34. Добавление атрибута связи причины риска с риском.

82


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

обеспечения

растут

быстрее,

чем

затраты

на

создание

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

целесообразность

разработки

и

внедрения

программного

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

ожидаемого

экономического

эффекта

принимается

решение

о

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

По

характеру

объекта

вложений

инвестиции

в

разработку

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

все

шансы

конкурентоспособно

выйти

на

рынок

программного

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

характеристики

производительности

83

труда

специалистов-


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

группа, характеризующая объем исходных текстов программ, которые

разрабатываются и анализируются программистом (это символы в исходном тексте

программы

на

любых

языках

программирования;

лексемы,

объединяющие группы символов, имеющих общее смысловое содержание в тексте программы; операторы языка программирования уровня ассемблера; строки текста программы на языке программирования высокого уровня); 

группа, отражающая объем программы, размещаемой в реализующей

ЭВМ (это байты, занятые текстом программы в памяти ЭВМ; команды или операции реализующей ЭВМ, составляющие текст программы в объектном коде; слова памяти, обусловленные структурой данной реализующей ЭВМ, используемые для хранения исполняемой программы и/или базы данных при функционировании программных средств). Объем программы, размещаемой на ЭВМ, влияет на характеристики и стоимость машин, которая зависит от необходимой памяти и производительности ЭВМ. Учитывая, что при разработке программы "Моделирование турбулентного поля" выбор ЭВМ не производился и конкретные требования к реализующей машине не предъявлялись, будем пользоваться единицами первой группы.

84


5.1. Основные статьи расходов при разработке программы Основной труд специалиста, разрабатывающего программное обеспечение, вкладывается в разработку текста программы и разработку алгоритмов, по которым текст написан. Желательно, чтобы выбранная единица измерения была бы в наибольшей степени адекватна трудоемкости разработки. Кроме того, единица измерения объема должна быть наглядной и просто измеряемой. С этих позиций применение числа лексем для характеристики объема программы пока затруднительна, тем более что отсутствует опыт использования этого показателя. Таким образом, базовым показателем для определения составляющих затрат труда является условное число операторов в программе. Разные источники советуют считать за число операторов в программе следующие величины:  число команд на языке ассемблера;  число

логических

операторов

в

программе,

операторов

перехода,

арифметических операторов и других операторов в исходном коде программы;  число строк в программе (для языков высокого уровня). Система "Управление рисками" разрабатывалась на языке высокого уровня C#. При его разработке были учтены такие современные рекомендации к структурному программированию как отсутствие условных и безусловных переходов,

запись

операторов

в

одну

строку

(за

несущественными

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

85


5.1.1. Расчет трудоемкости разработки программного обеспечения Базовый

показатель

для

определения

составляющих

затрат

труда

вычисляется по формуле: Q  q  c  1  p ,

(1)

где q – число операторов (исходных команд) в программном продукте, равно 1086; с – коэффициент сложности программы; p – коэффициент коррекции программы в ходе ее разработки, зависит от точности и корректности поставленной задачи – принимаем равным 0.06. Коэффициент сложности программы определяется из таблицы 2 на пересечении "группы сложности" и "степени новизны". При этом новизна определяется по принципу: А – разработка принципиально новых задач, Б – разработка

оригинальных

программ, B – разработка

программ

с

использованием типовых решений, Г – разовая типовая задача. А сложность определяется исходя из типа решаемых задач: 1 – алгоритмы оптимизации и моделирования

систем, 2 – задачи

учета,

отчетности

и

статистики, 3 –

стандартные

алгоритмы. Кроме того, в таблице указан коэффициент

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

Группа

Степень новизны

Коэффиц

сложности А

Б

В

Г

иент B

1

1,38

1,26

1,15

0,69

1,2

2

1,30

1,19

1,08

0,65

1,35

3

1,20

1,10

1,00

0,60

1,5

1

1,58

1,45

1,32

0,79

1,2

2

1,49

1,37

1,24

0,74

1,35

3

1,38

1,26

1,15

0,69

1,5

Таблица 2. Коэффициенты расчета трудоемкости

86


Система "Управление рисками" написана на языке высокого уровня, относится к моделированию систем и относится к принципиально новвым разработкам; то есть коэффициент сложности программы в данном случае: с = 1,38. Таким образом, находим базовый показатель: Q = 1589. Далее, рассчитаем составляющие затраты труда, среди которых выделяют: затраты труда на подготовку и описание алгоритма, затраты труда на исследование алгоритма, затраты труда на разработку алгоритма, затраты труда на программирование и отладку и затраты труда на подготовку документации. Почти все эти параметры будут зависеть от базового показателя, рассчитываемого по формуле (1). Затраты труда на подготовку и описание задачи может определяться эмпирически или по формуле (2):

t оп 

где

Tmin  4  Tнв  Tmax 26  4  52  78   52[чел.час] , 6 6

(2)

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

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

(оптимистическая

оценка);

Tнв –

трудоемкость

операции

при

нормальных условиях (наиболее вероятная оценка). Ориентировочные величины оценки трудоемкости операции подготовки описания задачи в зависимости от числа операторов q приводятся в таблице 3.

q 100 500 1000 1500 2000 2500 5000 10000

Tmin 10 20 25 30 40 50 70 100

Tнв 15 35 50 60 70 80 110 150

Tmax 20 50 75 90 100 110 150 200

Таблица 3. Оценка времени подготовки описания задачи

87


Затраты труда на исследование алгоритма решения задачи определяются формулой (3):

tис 

QB чел.час, (75  85)k

(3)

где Q – базовый коэффициент, рассчитываемый по формуле (1), В – коэффициент недостаточности описания задачи, который берется из таблицы 3 и равен 1,2; k – коэффициент квалификации программиста, зависит от стажа работника и определяется из таблицы 3.3. Опыт работы

Коэффициент квалификации

До двух лет

0.8

2-3 года

1

3-5 лет

1.1 – 1.2

5-7 лет

1.3 – 1.4

более 7 лет

1.5 – 1.6

Таблица 4. Коэффициенты квалификации программиста По таблице определяем коэффициент k = 0.8. Таким образом, находим затраты труда на исследование алгоритма решения задачи: tис = 30 [чел.час]. Затраты труда на разработку блок-схем алгоритмов (представленных на рисунках 2.7 и 2.8) вычисляются по формуле (4):

tал 

Q  88чел.час. (20  25)k

(4)

Затраты труда на программирование алгоритма по блок-схеме и отладку программы вычисляются по формулам (5, 6): 88


t пр 

Q  88чел.час, (20  25)k

(5)

t отл 

Q  397чел.час. (4  5)k

(6)

Затраты труда на подготовку документов по задаче состоят из затрат труда на подготовку рукописей и времени на оформление документов и вычисляются по формуле (7):

t д  t рук  t оф 

Q  0.75  t рук  113  85  198чел.час. 15  20k

(7)

Суммарные затраты труда рассчитываются как сумма составных затрат труда по формуле (8): t   t оп  t ис  t ал  t пр  t отл  t д  52  30  88  88  397  198  853чел.час.

89

(8)


5.1.2. Расчет затрат на разработку программного обеспечения Заработная плата складывается из двух составляющих: основной заработной платы и дополнительной. Основная заработная плата рассчитывается по формуле (9):

Зосн 

t  TC руб , tcp  8

(9)

где tΣ – суммарные затраты труда, вычисляемые по формуле (2); tср – среднее число дней в месяце, равно 21 дню, умножается на количество часов в рабочем дне – 8; ТС – тарифная ставка. Тарифная ставка представляет собой МРОТ (минимальный размер оплаты труда, по состоянию на май 2010 года равен 4330 рублей [Федеральный закон от 19.06.2000 № 82-ФЗ "О минимальном размере оплаты труда"]), увеличенный в зависимости от тарифного коэффициента, соответствующего данному виду работ. Для 12-го разряда работ [Постановления Правительства РФ от 06.01.93 N 14, от 27.02.95 N 189], который соответствует работе программиста, тарифный коэффициент равен 2.44. Таким образом, основная заработная плата будет составлять: Зосн 

853  4 330  2.44  53 643 руб . 21  8

Дополнительная заработная плата составляет 20% от основной заработной платы, рассчитывается по формуле (10): Здоп  0.2  Зосн  10 728 руб .

(10)

Суммарная заработная плата (или фонд заработной платы,

ФЗП)

вычисляется как сумма основной и дополнительной заработных плат по формуле (11): ФЗП  Зосн  Здоп  64 371 руб .

(11)

90


5.2. Дополнительные статьи расходов Среди дополнительных статей расходов на разработку программного обеспечения выделяют: расходы на материалы и комплектующие (стоимость самого оборудования, то есть компьютера, в расчет не берется), отчисления на социальное страхование, накладные расходы, амортизационные отчисления, затраты на техническое обслуживание оборудования и стоимость потраченной электроэнергии при работе на компьютере. Стоимость оборудования хоть и не включается в себестоимость разработки программного обеспечения, но все же используется при расчете некоторых других дополнительных статей расходов. При написании программы на ЭВМ в качестве оборудования предполагается персональный компьютер, стоимость которого составляет: Cобор  26 400 руб . Расходы на материалы и комплектующие, используемые в процессе написания программного продукта (СМиК), а также затраты на техническое обслуживание и ремонт (СТО) составляют, соответственно, 1.5% и 2.5% от стоимости оборудования – формулы (12 – 13): СМмК  0.015  Собор  396 руб ,

(12)

СТО  0.025  Собор  660[ руб ].

(13)

Амортизационные

отчисления,

процесс

постепенного

перенесения

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

91


Агод  Собор 

НА , 100%

(14)

где Cобор – стоимость компьютера; НА – норма амортизации, которая рассчитывается по формуле (15):

НА 

Собор  С ликв Т норм  Собор

 100%,

(15)

где Сликв – ликвидационная стоимость, составляет 5% от стоимости оборудования: C ликв  0.05  Cобор  1320[ руб ] ; Тнорм – нормативный срок службы (для персонального компьютера примем Тнорм = 6 [лет]). Таким образом, получаем: Агод = 4 180[руб]. Стоит также учитывать и затраты электроэнергии при написании программного обеспечения. Стоимость электроэнергии вычисляется по формуле (16): СЭЭ  M  k з  Fэф  СкВт .ч ,

(16)

где M – мощность ЭВМ (450 Вт); kз – коэффициент загрузки (0.8); CкВт.ч – стоимость 1 кВт-час электроэнергии (2 руб. 31 коп. на момент написания настоящей работы); Fэф – эффективный фонд рабочего времени, рассчитывается по формуле (17): f   Fэф  Д ном  d  1  ,  100% 

где

(17)

Дном = 258 – номинальное число рабочих дней в году; d = 8 –

продолжительность рабочего дня [час]; f = 2% – планируемый процент времени на ремонт ЭВМ. 92


При

данных

значениях

параметров

и

коэффициентов

стоимость

электроэнергии составит Сээ = 1 682 [руб]. Однако, полученные значения амортизационных отчислений и затрат на электроэнергию – значения годовых расходов, необходимо их скорректировать в соответствии с временным коэффициентом, который определяется исходя из суммарных годовых эксплуатационных затрат, которые рассчитываются по формуле (18):

Эз  t* 

CЭ [ руб ], Fэф

(18)

где CЭ  СЭЭ  СТО  Агод – суммарная годовая стоимость эксплуатационных затрат,

Fэф – эффективный фонд рабочего времени, вычисленный по формуле

(17), t* – общее время использования ЭВМ для решения задачи, вычисляемое аналогично

формуле (8), учитывая лишь время работы на компьютере:

t*  tпр  tотл  tд  88  397  198  683[час] .

Следовательно, составлять:

суммарные

затраты

на

эксплуатацию

ЭВМ

будут

Эз = 2 203 [руб], а сам временной коэффициент вычисляется по

формуле (19):

w

Эз  0.3377. СЭ

Таким образом,

(19)

учитывая

временной

коэффициент, из

эксплуатационных затрат скорректируем: *  затраты на электроэнергию C ЭЭ  C ЭЭ  w  568 [руб]; *  амортизационные отчисления Агод  Aгод  w  1 411 [руб].

93

суммарных


Кроме того, существуют расходы, зависящие от размера фонда заработной платы, вычисляемого по формуле (11). К ним относят отчисления на социальное страхование и накладные расходы. Отчисления на социальное страхование составляют 35.6% от всей заработной платы [Налоговый Кодекс РФ ч. 2 от 30.05.2001, статья 241], вычисляются по формуле (20): CC  0.356  ФЗП  22 916 руб .

Накладные

расходы,

(20)

связанные

с

управлением

и

обслуживанием,

содержанием и эксплуатацией оборудования и прочими дополнительными затратами на обеспечение процессов производства и обращения, составляют 50% от фонда заработной платы, вычисляются по формуле (21): Cнакл  0.5  ФЗП  32185 руб . .

(21)

94


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

Сумма, руб.

В процентах от общей суммы

Зосн

53 643

43.78

Здоп

10 728

8.76

Накладные расходы, Снакл

32 158

26.26

Социальное страхование, СС

22 916

18.71

Сээ

568

0.46

СТО

660

0.54

Агод

1 411

1.15

396

0.34

Статья расходов ФЗП

Эксплуатационные затраты

Материалы и комплектующие, СМиК Итого:

122 480

Таблица 5 – Результирующая таблица себестоимости

95


Охрана труда Внедрение вычислительной техники на производстве даѐт положительный социально-экономический

эффект,

который

выражается

в

росте

производительности, снижении доли рутинного, монотонного труда, повышения скорости расчѐтов, скорости обмена информацией. Отрицательное воздействие на человека вычислительной техники менее выражено, сглажено многими положительными моментами. Однако у людей длительно использующих ПЭВМ могут быть отмечены такие реакции как нарушение функций зрения, быстрое общее утомление. Для того чтобы избежать вредного воздействия при работе с вычислительной техникой необходимо соблюдать соответствующие меры безопасности, правильно планировать рабочее место и режим работы. Меры безопасности при работе ПЭВМ:  освещенность рабочего места в лаборатории при использовании люминесцентных ламп должна быть порядка 570–1000 лк;  правильное расположение дисплеев по

отношению к окнам и

осветительным приборам;  продолжительность работы с дисплеем без перерыва не более 1 часа, продолжительность перерыва не менее 15 минут;  нагрузка на работающего с клавиатурой не более 10-12 тысяч ударов (примерно 1700 слов) в час;  применение удобной мебели, рациональная рабочая поза;  расстояние от работающего дисплея не менее 70 см от своего и не менее 1,2 см от боковых и задних поверхностей соседних дисплеев;  применение дисплеев с антибликовым, антирадиационным покрытием или защитных экранов;  периодическое

расслабление

работающего

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

96

и

движение

в

целях


По мнению многих специалистов, работа с дисплеем не связана с вредным радиобиологическим воздействием. Допустимая мощность дозы рентгеновского излучения перед экраном на расстоянии 5 см от его поверхности равна 0.5 мр/ч. Интенсивность излучения экрана дисплея не достигает предельно допустимой дозы радиации и, следовательно, условия труда можно отнести к безопасным. Однако, желательно принимать следующие предосторожности: ограничить дневную продолжительность рабочей деятельности перед экраном, не размещать дисплеи концентрированно в рабочей зоне, применять защитные экраны для дисплеев. Результаты

исследований

показали,

что

в

наибольшей

степени

отрицательное физиологическое воздействие на операторов ПЭВМ связано с дискомфортными зрительными условиями из-за неправильно спроектированного освещения: прямая и отражѐнная от экранов блѐклость, неблагоприятное распределение яркости в поле зрения, неверная ориентация рабочего места относительно светоприѐмов. Располагать оборудованное дисплеем рабочее место необходимо таким образом, чтобы в поле зрения оператора не попадали окна или осветительные приборы; они не должны находиться и непосредственно за спиной оператора. Следует добиваться уменьшения отражений на экране от различных источников искусственного и дневного света. Когда искусственный свет смешивается с естественным, рекомендуется использовать лампы, по спектральному составу наиболее близкие к солнечному свету. Соотношение яркости экрана и непосредственно ближайшего окружения не должно превышать 3:1. Значительного эффекта в ослаблении вредных воздействий можно добиться применением для дисплеев защитных фильтров. Для примера можно привести данные из рекламного проспекта защитных экранов шотландской фирмы «Ocli», прошедших европейские стандартные испытания MIL STD 285:  небьющееся стекло;  увеличение контрастности и чѐткости изображения;  абсолютное устранение бликов и мерцания экрана; 97


 подавление электростатического поля на 99%;  подавление электромагнитного поля на 98%;  уменьшение рассеянного отражения на 99.5%;  устойчивость к парам ацетона, напиткам, косметике. Оптимальные значения температуры воздуха в помещении должны составлять 19-23 С. Рекомендуемая относительная влажность воздуха 55%. Скорость движения воздуха не более 0.1 м/с.

98


4.1. Площадь и объем рабочих помещений Помещение,

где

находятся

компьютеры,

должно

быть

достаточно

просторным и хорошо проветриваемым. Минимальная площадь на один компьютер – 6 м2 минимальный объем – 20 м3. 4.2. Освещение Работа с ПК зачастую происходит в помещениях с искусственным освещением, которое должно обеспечивать правильную работу глаз и приближать к оптимальным условиям зрительное восприятие, какое бывает при естественном солнечном освещении. Человек имеет как центральное (колбочковое), так и периферийное (палочковое) зрение. Первое - для восприятия цветов и объектов малых размеров, второе – для восприятия окружающего фона и крупных объектов. Центральное зрение требует больших яркостей, а палочковое действует в сумерках или полумраке. Учитывая, что при работе с дисплеями задействовано именно центральное

зрение,

становится

понятной

необходимость

достаточного

освещения помещения, где находится компьютер. Самые общие правила организации освещения заключаются в следующем: 1) Следует избегать большого контраста между яркостью экрана и окружающего пространства. Оптимальным считается их выравнивание. 2) Запрещается работа с компьютером в темном или полутемном помещении, Освещение в помещениях с ПК должно быть смешанным: естественным – за счет солнечного света – и искусственным. Хорошо, если окна, обеспечивающие естественное освещение, имеют северную ориентацию. Если нет, необходимо принять меры, благодаря которым интенсивный солнечный свет из южных или западных окон не мешал бы работе. Так, например, оконные проемы можно оборудовать жалюзи, занавесями, внешними козырьками. В качестве источников общего искусственного освещения лучше всего использовать

осветительные

приборы, 99

которые

создают

равномерную


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

пульсации

используйте

лампы,

укомплектованные

высокочастотными пускорегулирующими аппаратами. Следует отметить, что существуют специальные люминесцентные лампы, например, фирмы «VitaLight R», которые излучают свет различного «качества», имитируя, таким образом, полный спектр естественного солнечного света. Эти лампы меньше раздражают, чем любые другие лампы искусственного освещения. Источники света необходимо равномерно распределять по комнате, компонуя в сплошные или прерывистые линии. Линии должны располагаться сбоку от рабочих мест параллельно линии зрения пользователя – при рядном размещении компьютеров; локализовано над рабочим столом – при размещении рабочих мест по периметру помещения. Грамотная организация освещения способна повысить производительность труда при зрительной работе средней трудности – на 5-6%, при очень трудной – на 15%. Если деятельность пользователя является комбинированной, то есть предполагает работу как с компьютером, так и с документами, на рабочие места необходимо устанавливать источники местного освещения – настольные лампы с регулируемым наклоном плафона и регулируемой яркостью. В этом случае надо следить, чтобы свет от лампы не действовал раздражающе и не создавал бликов на экране. 4.2.1. Расчет освещенности рабочего места Правильный выбор и расчет освещенности рабочего места обеспечивает создание

нормальных

способствует

условий

повышению

для

зрения

обслуживающего

производительности 100

труда.

персонала, Освещение,


соответствующее санитарным нормам, является главнейшим условием гигиены труда

и

культуры

производства.

При

хорошем освещении

устраняется

напряжение зрения, ускоряется темп работы. Для рационального освещения необходимо выполнение следующих условий:  постоянная освещенность рабочих поверхностей;  достаточная и равномерно распределенная яркость освещаемых рабочих  поверхностей;  отсутствие резких контрастов между яркостью рабочей поверхностью и окружающего пространства;  отсутствие в поле зрения светящихся поверхностей, обладающих большим блеском, что достигается применением светильников с рассеянным светом и увеличением высоты их подвеса. Для рационального освещения производственных помещений и рабочих мест большое значение имеет выбор цвета для окраски потолка, стен и производственного оборудования. Рассчитаем люминесцентное освещение кабинета, предназначенного для выполнения работ с размером объекта различения от 0,3 мин до 1 мин. Размеры помещений: А=4 м, В=3 м, Н=3 м. Площадь помещения определяем по формуле: 𝑆 =𝐴∗𝐵 Подставив значения получим: 𝑆 = 4 ∗ 3 = 12 м2 Освещение проектируется при помощи светильников ШОД минимальной освещенностью Емин=200 лк, средней удельной мощностью 17-23 Вт/м2. Высота подвеса над рабочей поверхностью Нр=2 м. Освещение выполняется лампами ЛБ2*40, световой поток ламп Fл=2480 лм, длина 1.2 м, коэффициент запаса равен к=1.5. Определим показатель помещения по формуле:

101


𝐹=

𝐴∗𝐵 𝐻𝑝 ∗ (𝐴 + 𝐵)

Подставив значения получим: 𝐹=

𝐴∗𝐵 4∗3 = = 0.86 𝐻𝑝 ∗ (𝐴 + 𝐵) 2 ∗ (4 + 3)

Затем, для F=0,86, коэффициентов отражения потолка Рп=0,7, стен Рс=0,5 и расчетной плоскости Рр=0,3 находим коэффициент использования светового потока h=0,37. Потребное число светильников определяется по формуле: 𝑁=

𝐸мин ∗ 𝑆 ∗ 𝐾 𝐹л ∗ ℎ ∗ 𝑍 ∗ 𝑛

где n=2 общее число ламп в светильнике. Подставив значения получим: N = 2 штуки. Общее количество ламп равно n=2*2=4. Таким

образом,

выполнение

перечисленных

выше

требований

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

102

к


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

пространство,

где

осуществляется

деятельность

пользователя

(пользователей). Организацией рабочего места называется система мероприятий по оснащению рабочего места средствами и предметами труда и размещению их в определенном порядке. При создании рабочих мест с ВДТ и ПЭВМ должно учитываться расстояние между рабочими столами с видеомониторами, которое должно быть не менее 2 м, а расстояние между боковыми поверхностями видеомониторов - не менее 1,2 м. Рабочее место должно отвечать следующим требованиям:  оборудование рабочего места (стол, стул, подставка для ног) должны быть

специальной

конструкции,

обеспечивающей

возможность

индивидуальной регулировки;  сиденье и спинка стула должны быть покрыты не электризующимися полумягкими материалами;  расположение рабочих поверхностей должно обеспечить согласованность компоновки рабочего места и маршрута движений, а также достаточную легкость для слежения за рабочими операциями,  освещенность на поверхности стола в зоне размещения рабочего документа должна быть 300 - 500 лк (при комбинированном освещении). Для операторов на рабочем месте было выделено 21 пространственных параметров, которые представлены в таблице 6 и на рисунке 34.

103


Пространственные параметры

L, мм

1 Высота сидения

400-500

2 Высота клавиатуры от пола

600-750

3 Угол наклона клавиатура

7-15°

4 Ширина основной клавиатуры

не > 400

5 Глубина основной клавиатуры

не > 200

6 Удаление клавиатуры от края стола

80-100

7 Высота экрана от уровня пола

950-1000

8 Угол наклона экрана и нормали

0-30°

9 Удаленность экрана от края стола

500-700

10 Высота поверхностей для записей

670-850

11 Площадь поверхности для записей

600х400

12 Угол наклона поверхности для записей

0-100

13 Глубина пространства для ног в коленях

<400

14 Глубина пространства на уровне ступней

<600

15 Высота пространства для ног в коленях

<б00

16 Высота пространства на уровне ступней

<100

17 Ширина пространства для ног на уровне

<500

18 Высота подставки для ног

50-130

19 Угол подставки для ног

0-25

20 Ширина подставки для ног

300

21 Глубина подставки для ног

400

Таблица 6. Параметры рабочего места

104


9

6 3 13 2

15

1 14 16 17 Рис. 34. Организация рабочего места оператора ПЭВМ

105


4.4. Основные способы защиты В настоящее время борьба за снижение уровня вредного воздействия видеотерминалов ПК на человека ведется в нескольких направлениях. Первое – это проведение работ по созданию и внедрению стандартов, а также других регламентирующих документов, допускающих производство мониторов только с очень низкими уровнями электромагнитных излучений. Основополагающими нормативными актами, содержащими очень жесткие требования и нормы для дисплеев по эргономике и их безопасности, являются стандарты Швеции, принятые в этой стране в период с 1987 по 1991гг.(MPR 1982:2, ТСО-89, MPR 1990:8, ТСО-91). На данные стандарты опираются многие фирмы-производители мониторов для ПК. В соответствии со стандартом ТСО-91 напряженность электрического поля в диапазоне от 5 Гц до 2 кГц на расстоянии 50 см от экрана должна составлять 10 вольт/м, а в диапазоне от 2 кГц до 400 кГц - не более 1 вольт/м. Сейчас уже стало заметным влияние новых стандартов на изготовляемую и поступающую на компьютерный рынок продукцию. На задней стороне панели мониторов ставится соответствующий сертификационный знак, Второе направление предусматривает широкое использование специальных защитных

экранов-фильтров

электромагнитных

излучений.

для

мониторов

Использование

с

такого

высоким средства

уровнем является

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

106


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

в

ряде

случаев

и

полностью

подавить)

оптические

излучения

в

ультрафиолетовой и инфракрасной областях спектра. Выпускаемые ЗФ имеют стандартные размеры: 14', 15', 17', 21' и так далее Защитные фильтры:  подавляют

блики,

появляющиеся

на

стеклянных

элементах

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


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

ЗФ

(повышенный контрастность

обеспечивают контраст,

более

подавление

изображения,

оптимальные бликов),

практически

оптические

значительно полностью

свойства повышают поглощают

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

покрытий.

Антибликовые

характеристики

этих

фильтров

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


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

существенными

недостатками.

Они

имеют

слишком

низкую

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

и

электромагнитное

экранирование

(как

правило,

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

излучения,

дополнительно

ослабляет

излучения

в

ультрафиолетовой и инфракрасной областях спектра и обеспечивает высокую эффективность ослабления высокочастотного электромагнитного излучения. 109


Основной характеристикой таких экранов является электрическое сопротивление токопроводящего слоя (от 20 до 600 ОМ на квадрат). При правильном заземлении ЗФ может иметь весьма высокий коэффициент экранирования электромагнитных излучений. Оптические характеристики определяются коэффициентом отражения видимого света (0.5..8), он обуславливает подавление бликов, а также коэффициентом светопропускания, который главным образом зависит от типа применяемой подложки. 3) Смешанного типа. Имеют импрегнированную в стеклянную подложку металлическую сетку. Наиболее известны ЗФ этого типа фирмы Tecknik (США). Наиболее высокую степень защиты позволяют обеспечить ЗФ класса Total Shield. Они характеризуются коэффициентом отражения около 1% (практически не дают бликов), высоким коэффициентом экранирования электростатики 99,5%, коэффициентом

поглощения

ультрафиолета

порядка

98...99%,

мягкого

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

110


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

111


ЗАКЛЮЧЕНИЕ В результате работы над дипломным проектом были выполнены поставленные задачи и спроектирована система управления рисками в вопросноответной среде моделирования проектной деятельности WIQA.NET. Причинно-следственное представление рисков позволило разработать механизм, способный в режиме реального времени решать задачу управления рисками и моделировать развитие неопределенных процессов на базе знаний. Однако отсутствие базы знаний рисков на данном этапе не позволяет однозначно говорить об адекватности решения. Предлагаемая реализация позволяет установить связи между процессами и объектами, что на практике позволит не только описать определенный процесс, но и сопоставив с базой знаний, предложить менеджеру развитие ситуации и наличие рисков на основе опыта предыдущих проектов. Существует несколько различных методик управления рисками при проектировании. Выбор определенной методики зависит от ситуации и типа проекта, но вне зависимости от самого проекта – риски, которые будут обнаружены, вполне вероятно встречались до начала проекта и встретятся после его завершения. Для экономии ресурсов на проект необходимо рассматривать все его стадии и составляющие. Интеграция задач управления рисками в общие задачи проекта позволяют составить наиболее целостную картину проекта, что позволяет всесторонне контролировать проектную деятельность и эффективнее ей управлять.

112


БИБЛИОГРАФИЧЕСКИЙ СПИСОК 1. Милошевич Драган З. Набор инструментов для управления проектами. М.: Академия АйТи, ДМК Пресс, 2008. - 736 с. ISBN: 5-98453-013-9. 2. Руководство к своду знаний по управлению проектами. - 238 с. ISBN: 5902681-01-4 3. Ньюэлл Майкл В., Ньюэл М. Управление проектами для профессионалов. Руководство по подготовке к сдаче сертификационного экзамена. Пер. с англ.М.: КУДИЦ-ПРЕСС, 2006. - 416 с. ISBN: 5-91136-009-8 4. Р. Деннис Гиббс. Управление проектами с помощью IBM Rational Unified Process. Практические уроки. Пер. с Англ. - М.: КУДИЦ-ПРЕСС. - 2007.304с. ISBN 0-321-33639-9 5. Тернер М. Основы Microsoft Solution Framework. - М.: "Русская редакция"; СПб.: Питер, 2008. - 336с. ISBN: 5-7502-0306-2 6. www.baz.com/kjordan/swse625/intro.html. К. Джордан (K.Jordan). Введение в программные риски и управление ними, 1997. 7. www.eas.asu.edu/~riskmgrmt/intro.html. Раймонд Миллер (Raymond Miller). Управление качеством и рисками, 1997. 8. www.sei.cmu.edu/publications/documents/97/reports/97hb002/97hb002abstract.h tml. Брайан Галахер (Brian Gallagher), Кристофер Альберте (Christopher Alberts) и Ричард Барбор (Richard Barbour). Ключевая область процессов управления рисками для приобретаемого ПО (КРА) — руководство, версия 1.0. 9. www.sei.cmu.edu/publicatioris/documents/97/reports/97hb002/97hb002abstract.h tml. Джеймс С. Коллофелло (James S. Collofello). Управление рисками при разработке ПО. 10. Boehm Barry W. Tutorial: Software Risk Management. Los Alamitos, CA: IEEE Computer Society Press, 1989. 11. Karolak. Dale. Software Engineering Risk Management Los Alamitos, CA: IEEE Computer Society Press, 1996. 12. Pritchard Carl. Risk Management. Arlington, VA:ESI International, 1997. 113


13. http://en.wikipedia.org/wiki/Gantt_chart 14. http://www.onepoint.at/ 15. http://www.primavera.com 16. http://www.dotproject.net 17. Bjorn, A.G. (January 2002). CORAS, A Platform for Risk Analysis on Security Critical

Systems

Model-based

Risk

Analysis

Targeting

Security

(www.nr.no/coras) 18. Alberts, C.J. & Dorofee, A.J. (June 2001). OCTAVE Method Implementation Guide Version 2.0. Carnegie Mellon University (www.cert.org) 19. Alberts, C.J. & Dorofee, A.J. (June 2002). Managing Information Security Risks — The OCTAVE Approach. Pearson Education Ltd. 20. Model Based Security Risk Analysis for Web Applications: The CORAS Approach. EuroWeb2002. 21. Insight Consulting. (2003). CRAMM Expert Walkthrough and Overview — Flash Presentation. 22. Программы CORAS Tool 2.0 (coras.sourceforge.net). 23. AS/NZS 4360:1999 Risk management. 24. Barber, B., Davey, J. The use of the CCTA risk analysis and management methodology CRAMM. Proc. MEDINFO92, North Holland, 1589 –1593, 1992. 25. Bouti, A., Ait Kadi, D. A state-of-the-art review of FMEA/FMECA. International Journal of Reliability, Quality and Safety Engineering 1:515-543, 1994. 26. IEC 1025: 1990 Fault tree analysis (FTA). 27. IEC 61508: 2000 Functional safety of electrical/electronic/programmable safety related systems. 28. ISO/IEC 10746 series: 1995 Basic reference model for open distributed processing. 29. ISO/IEC TR 13335-1:2001: Information technology – Guidelines for the management of IT Security – Part 1: Concepts and models for IT Security. 114


30. ISO/IEC 17799: 2000 Information technology â&#x20AC;&#x201C; Code of practise for information security management. 31. Krutchten, P. The Rational unified process, an introduction. Addison-Wesley, 1999. 32. Littlewood, B. A reliability model for systems with Markov structure. Appl. Stat. 24:172-177, 1975. 33. Putman, J. R. Architecting with RM-ODP. Prentice Hall, 2001. 34. Redmill, F., Chudleigh, M., Catmur, J. Hazop and Software Hazop. Wiley, 1999. 35. Sindre, G., Opdahl, A. L. Eliciting security requirements by misuse cases. In Proc. TOOLS_PACIFIC 2000. IEEE Computer Society Press, 120-131, 2000. 36. UML proposal to the Object Management Group, Version 1.4, 2000. 37. www.sei.emu.edu/programms/sepm/risk/ 38. Boehm Barry W. Tutorial: Software Risk Management Los Alamitos, CA: IEEE Computer Society Press, 1989

115


ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ WIQA.NET (Working In Questions and Answers) - инструментальная среда, созданная

на

кафедре

«Вычислительная

техника»

Ульяновского

Государственного Технического Университета. Модель (model) - это абстракция, описывающая суть сложной проблемы или структуры, без акцента на несущественных деталях, тем самым делая ее более понятной. UML (сокр. от англ. Unified Modeling Language — унифицированный язык моделирования) —язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы. UML был создан в октябре 1995 года (первая версия 0.8). Информационная система - совокупность содержащейся в базах данных информации и обеспечивающих ее обработку информационных технологий и технических средств (определение взято из Федерального закона Российской Федерации от 27 июля 2006 г. N 149-ФЗ «Об информации, информационных технологиях и о защите информации»).

116

http://ulmt.ru/sites/default/files/adfiles/%D0%9F%D0%BE%D1%8F%D1%81%D0%BD%D0%B8%D1%82%D0%B5%D0%BB%D1  

http://ulmt.ru/sites/default/files/adfiles/%D0%9F%D0%BE%D1%8F%D1%81%D0%BD%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F%20%D0%B7%D0%B0%D0%...

Advertisement