Вместо заключения

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

Рис. 6. Жизненный цикл приложений с позиции компании Borland

Риски на рынке ПО

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

Анализ рисков можно представить в виде следующих этапов:

1. Определение множества возможных угроз;

2. Выделение подмножества вероятных угроз;

3. Определение потенциального ущерба по каждой угрозе;

4. Выработка контрмер;

5. Разработка общей стратегии поведения в условиях риска.

Определение множества возможных угроз

Угрозы безопасности ПО можно условно подразделить на следующие категории:

1. Угрозы технического характера:

а)

Угрозы, аналогичные угрозам безопасности ИС: 1. "Маскарад" (обман СЗПО путем ввода похищенной у легального пользователя аутентичной информации); 2. Перехват пароля (введенного с клавиатуры или переданного по ЛВС); 3. Подбор либо генерация пароля; 4. Повторное использование объектов (использование того факта, что расшифрованный/незащищенный код ППр остается в ОЗУ после завершения работы системы защиты ПО); 5. "Суперзаппинг" (использование полного контроля над функционированием ОС с целью обхода СЗПО); 6. Мониторинг работы ППр (анализ протокола обмена данными СЗПО и электронного ключа/ключевого файла/диска, анализ сетевого трафика); 7. Получение злоумышленниками несанкционированного доступа к серверу глобальной сети с дистрибутивами ППр;

б)

Угрозы, специфичные для ПО: 8. Дизассемблирование; 9. Декомпиляция; 10. Анализ алгоритмов защиты (статический и динамический); 11. Модификация кода (статическая и динамическая); 12. "Раздевание" (снятие внешних СЗПО); 13. "Отвязка" (снятие СЗПО с ключевыми дисками/файлами, электронными ключами, систем "привязки" к ЭВМ пользователя); 14. Плагиат (несанкционированное использование ППр или его частей в других коммерческих продуктах);

2. Угрозы нетехнического характера:

а)	Нелегальное распространение копий ППр легальными пользователями;
б)	Нелегальное завладение копиями ППр со стороны третьих лиц;
в)	Приобретение ППр злоумышленниками "в складчину";
г)	Приобретение ППр злоумышленниками по украденной/фальшивой кредитной карте.

Рисунок 3. Угрозы безопасности программных продуктов

Выделение подмножества вероятных угроз

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

Определение потенциального ущерба по каждой угрозе

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

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

Выработка контрмер

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

Разработка общей стратегии поведения в условиях риска

В результате анализа вышеперечисленных факторов процесс торговли ППр на рынке можно условно разбить на 3 периода:

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

Рисунок 4. Жизненный цикл программного продукта

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

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

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

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

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

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

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

Управление проектами

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

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

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

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

Дата добавления: 2014-01-14