Технологические риски

Риски проекта

Анализ типовых рисков проекта включает вид риска, описание источника риска, оценку его влияния на успех/неудачу проекта и выбор одной из четырех основных стратегий управления риском: 1) исключение риска (мероприятия, воздействующие на источник риска и препятствующие самому появлению риска); 2) ослабление риска (мероприятия, снижающие влияние риска в случае его реализации); 3) перемещение риска (мероприятия, перемещающие влияние риска на более высокий уровень или на объекты, лежащие за границами проекта); 4) принятие риска (эта стратегия не предусматривает никаких мероприятий, а последствия реализации риска принимаются как неизбежность).

а) Риск недостаточной скорости передачи данных в локальной сети.

Предлагаемая архитектура ИС связана с риском неудовлетворительной скорости работы клиентского приложения на рабочих станциях. Используемый механизм доступа к данным MS Jet поддерживает на самом деле сетевое взаимодействие с файл-сервером данных. То есть вся обработка данных происходит на клиентской рабочей станции. При работе с большими таблицами Access их загрузка (даже по частям) при недостаточной скорости локальной сети может выполняться с большими (до десятков секунд) задержками.

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

Предлагается стратегия отложенного исключения риска за счет повышения скорости ЛВС с существующих 100 Мб до 1000Мб. с удорожанием материального обеспечения проекта на 15%. Отложенной стратегия называется потому, что начинает осуществляться только при реализации риска. Усиление ЛВС используемой в данном проекте (не более 10 РС)

б)Риск ухудшения скорости обработки данных из-за «разбухших» от накопленных за несколько лет данных.

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

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

Предлагается стратегия исключения риска за счет ежегодного создания (например, в январе) новой копии базы данных, в которую из предыдущей копии переносятся все справочники целиком, а данные о залогах переносятся только по залогам, совершенным за предыдущие 2 года. Таким образом, объем текущей рабочей копии базы данных не буде превосходить трехлетнего накопления. Учитывая частоту добавления записей в БД ИС (табл. 2.3), и характеристики рабочих станций (рис. 2.5.) указанный риск будет исключен. Заметим, что сокращение времени создания новых залоговых билетов за счет копирования в них данных из предыдущих залогов почти не пострадает, т.к. доля заемщиков, обращающихся к услугам ломбарда реже, чем один раз в два года (их залогов может уже не быть в новой версии БД ИС) пренебрежимо мала.