Общие положения автоматизации риск-менеджмента в страховых компаниях

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

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

Символами "+", "+-" и "++" показаны примерные оценки доли наличия каждого компонента на каждой стадии

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

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

Чаще всего в качестве основного недостатка называлось существенное запаздывание с получением результатов

, которое имело несколько аспектов:

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

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

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

В [19] об этом сказано так: "В конце 1960-х гг. появилась идея о создании полностью интегрированной базы данных (БД) организации. Она оказалась практически недостижимой". Правда, Дж. Мартин указывал в качестве причины практического краха идеи сложность и размер задачи. Мы будем далее анализировать еще одну, самую актуальную причину – динамику изменений в требованиях к базе данных и информационной системе в целом. Показательно, что в настоящее время эта идея продолжает жить до сих пор.