Лекция 15. Реинжиниринг информационных систем Основные определения. Причины реинжиниринга ис. Основные пути реинжиниринга ис. Методологии реинжиниринга ис. Этапы реинжиниринга ис. Перспективы реинжиниринга ис
 Скачать 180.12 Kb.
|
|
Лекция 15. Реинжиниринг информационных систем Основные определения. Причины реинжиниринга ИС. Основные пути реинжиниринга ИС. Методологии реинжиниринга ИС. Этапы реинжиниринга ИС. Перспективы реинжиниринга ИС. 15.1. Основные определения В настоящее время существует много различных определений реинжиниринга (англ. reengineering) информационных систем (ИС). В том числе – много сходных и смежных понятий. Общепринятого определения пока не существует. Встречаются два написания самого термина: реинжиниринг и реинжениринг (первое встречается чаще). В рамках данного курса под реинжинирингом информационной системы (РИС) понимается анализ и перепроектирование информационной системы с целью реализации ее в новом качестве [1] (слайд 2). Таким образом, целью РИС устанавливается существенное улучшение качества информационной системы «в разы» (значительно более 100%). Под информационной системой понимается система, предназначенная для сбора, хранения, обработки и передачи информации. Большинство современных информационных систем реализуется с применением вычислительной техники. Поэтому, говоря о реинжиниринге информационных систем, подразумевается реинжиниринг автоматизированных информационных систем (АИС). Традиционно, в АИС выделяются две составляющие: функциональная (программное обеспечение) и информационная (хранилище данных). В современной практике принято также говорить об архитектуре (развертывании) информационной системы. Поэтому объектами перепроектирования в первую очередь являются функциональная, информационная и архитектурная модели информационной системы. Можно выделить следующие термины, сходные или смежные с термином реинжиниринга информационных систем (слайд 3): модернизация ИС – относительно небольшое улучшение информационной системы (обычно не более 100%), исправление критичных ошибок, при отсутствии кардинальных изменений1 системе; рефакторинг ИС (англ. refactoring) – полное или частичное преобразование внутренней структуры программного обеспечения информационной системы (только программного) при сохранении внешнего поведения; перевод на более современный язык программирования; редизайн ИС (англ. redesign) – переработка только пользовательских интерфейсов информационной системы без существенного вмешательства в ее устройство, обычно применим к веб-сайтам; реверс-инжиниринг ИС (англ. reverse-engineering) – исследование, восстановление (построение) структурных моделей информационной системы (например, построение информационной модели ИС на основе ее существующей базы данных); реинжиниринг бизнес-процессов (РБП) – фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов для достижения существенных улучшений в ключевых для современного бизнеса показателях результативности2. В рамках данного курса рассматривается задача реинжиниринга некоей уникальной информационной системы, разработанной для некоторого предприятия. Это обстоятельство определяет состав основных причин, приводящих к реинжинирингу. Частным случаем такой задачи может быть ситуация, когда конечным пользователем информационной системы является всего один человек (персональная ИС). Принципиальных отличий от реинжиниринга в интересах предприятия при этом может не наблюдаться. Несколько иной является ситуация реинжиниринга с точки зрения разработчика информационной системы, реализуемой и внедряемой в массовом порядке. При этом причины и характер действий по преобразованию информационной системы могут иметь существенные отличия. 15.2. Причины реинжиниринга информационных систем Главной причиной реинжиниринга информационной системы является расхождение между требованиями к информационной системе со стороны предприятия и ее действительными характеристиками. Такое расхождение имеет тенденцию к нарастанию со временем. Относительно небольшое расхождение позволяет говорить о необходимости модернизации ИС, сильное – о необходимости реинжиниринга информационной системы. Основными причинами, также приводящими к реинжинирингу информационных систем, являются (слайд 4): моральное устаревание информационной системы (информационных технологий, пользовательских и программных интерфейсов, используемых в составе ИС); физическое устаревание информационной системы (износ ее аппаратных компонентов); причины организационного характера (связанные с окружением информационной системы, бизнес-процессами предприятия, пользователями системы). Моральное устаревание ИС в основном вызвано появлением: более эффективных информационных технологий (ИТ); новых способов организации пользовательского интерфейса; новых решений в области архитектуры информационной системы; вычислительных устройств с более высокой производительностью; новых носителей информации (более дешевых, с большим быстродействием, позволяющих хранить больше информации). Физическое устаревание ИС в основном вызвано: физическим износом используемого аппаратного обеспечения (снижением надежности, увеличением количества сбоев); ухудшением характеристик производительности аппаратного обеспечения (снижение быстродействия из-за больших объемов накопленной информации). Основной причиной организационного характера для реинжиниринга информационной системы является развитие предприятия (как штатным образом, так и в результате реинжиниринга бизнес-процессов), совершенствование его бизнес-процессов. Все это требует обновления и развития информационной поддержки бизнес-процессов предприятия. Кроме того, постоянно растет квалификация персонала, что позволяет внедрять более сложные информационные технологии и проводить информатизацию все новых сфер деятельности. Со временем ситуация с расхождением между требованиями к ИС и ее характеристиками становится критической (в настоящем или будущем3) и требуется серьезное вмешательство в информационную систему. Часто причиной реинжиниринга ИС является реинжиниринг бизнес-процессов. И наоборот, реинжиниринг ИС часто приводит к РБП. В любом случае, реинжиниринг ИС требует коррекции бизнес-процессов предприятия. Первой волной реинжиниринга информационных систем в нашей стране можно считать массовый перевод систем с морально устаревшей платформы операционной системы MS DOS (частично также с MS Windows 3.x) на более современные MS Windows 9x, NT во второй половине 90-х годов прошлого века. Эта волна также вызвана началом поставки в Российскую федерацию более новых персональных компьютеров. Помимо перевода на новую платформу решалась важная задача создания единого информационного пространства предприятия, поскольку к началу волны реинжиниринга накопилось большое количество информационных систем, разрозненно автоматизирующих отдельные подразделения предприятий4. Также решалась задача вывода информационных систем в Интернет. Вторая волна, в основном, вызвана бурным развитием веб-технологий, широком распространении и удешевлении Интернет. Разработчики информационных систем перешли от использования самостоятельных инструментов (пакетов программ) к использованию сред разработки, включающих в себя, помимо традиционных компилятора и отладчика, средства организации совместной разработки, резервного копирования и т.п. В ходе реинжиниринга решалась задача интеграции уже не ИС отделов предприятия, а информационных систем целых предприятий. При этом протокол http использовался для передачи данных между информационными системами. Сменилась также парадигма информационных систем. Получили распространение концепции сервисов (веб-сервисов) и клиент-серверного взаимодействия (как отдельных подсистем, так и целых систем). 15.3. Основные пути реинжиниринга информационных систем Ситуацию, в которой требуется провести реинжиниринг информационной системы, иногда для удобства называют ситуацией РИС. Одной из основных проблем реинжиниринга информационных систем является то, что риск неудачного завершения проекта очень велик (считается, что он выше, чем у процесса разработки информационной системы). На сегодняшний день известны следующие основные пути реинжиниринга ИС (слайд 5): создание новой ИС («с чистого листа») взамен существующей; модификация существующей ИС; адаптация готовой ИС стороннего разработчика. Следует отметить, что ни один из перечисленных путей не встречается «в чистом виде». При создании новой информационной системы, так или иначе, используются какие-то готовые компоненты ИС, а при модификации часть компонентов создается заново. Обычно проект реинжиниринга информационной системы тяготеет к одному из перечисленных путей. Первый подход, который напрашивается в такой ситуации, это – разработать информационную систему заново («с чистого листа»). В пользу такого подхода говорят следующие основные доводы: процесс создания ИС достаточно хорошо изучен, существует ряд моделей, описывающие порядок действий; процесс перепроектирования ИС пока изучен хуже; процесс создания новой информационной системы лучше прогнозируется (по времени, стоимости и другим ресурсам), чем процесс перепроектирования; создание новой информационной системы позволяет отойти от устаревших концепций и применить новые ИТ. Однако этот подход обладает следующими существенными недостатками: создание новой системы требует значительных ресурсов; он очень продолжительный по времени (а к реинжинирингу часто прибегают в самый последний момент, когда резерва по времени почти не осталось); высока вероятность того, что часть задач придется решать заново; также высока вероятность, что часть задач в старой ИС была решена на хорошем или приемлемом уровне. Обычно такой подход применяется в ситуации, когда по оценкам придется перепроектировать более половины компонентов информационной системы. Поэтому, большее распространение получил путь модификации существующей информационной системы. К его основным достоинствам можно отнести: потенциально меньшие затраты; потенциально меньший срок окончания проекта; возможность широкого использования компонентов существующей информационной системы, функционирующих хорошо или удовлетворительно (тем самым сэкономить на разработке новых компонентов); минимальные затраты на переобучение пользователей; более плавный переход со старой информационной системы на новую (актуально для задачи переноса данных из старой системы в новую); возможность не останавливать информационную систему полностью (в каждый момент реинжиниринга могут быть неработоспособны отдельные подсистемы при общей работоспособности информационной системы в целом). К существенным недостаткам этого подхода можно отнести: отсутствие гарантии (и даже убежденности), что путем модификации удастся привести информационную систему в соответствие новым требованиям; сложность прогнозирования процесса, оценки необходимых ресурсов; сложность структурной модели, описывающей реинжиниринг информационной системы; довольно высокую вероятность возникновения «волны изменений» (модификация одного компонента требует модификации других компонентов, взаимодействующих с ним, те в свою очередь также требуют модификации связанных компонентов и таки образом количество компонентов лавинообразно растет). К ограничениям такого подхода следует также отнести правовой аспект. Исполнителю необходимо иметь доступ к исходным текстам информационной системы, а также иметь право исследовать и изменять информационную систему. В последнее время, с появлением открытых (свободно распространяемых) программ и информационных систем, распространение получил аналогичный подход – путем «адаптации» (доработки) готовой ИС стороннего разработчика. Обычно такие информационные системы строятся по технологии так называемых «открытых систем», что существенно упрощает модификацию системы. Этот подход можно рекомендовать в следующих случаях: наличие аналогичной информационной системы, требующей минимальной доработки; ожидание существенных выгод от использования существующей системы (например, получение совместимости с другими важными информационными системами); наличие в существующей информационной системе хорошего набора базовых функций (так называемого «ядра»), на основе которого упрощается реализация новой информационной системы. Нельзя исключать также такого варианта развития событий, при котором нет возможности провести реинжиниринг информационной системы (например, при острой нехватке ресурсов: финансовых, кадровых и т.п.). В таком случае придется компенсировать недостатки информационной системы какими-то иными организационно-техническими мерами. Можно привести несколько типовых видов такой ситуации: в настоящий момент используется готовая информационная система стороннего разработчика, который регулярно выпускает новые версии ИС (можно дождаться выпуска новой версии); стратегические планы предприятия не ясны (возможен переход на другую платформу); предприятие близко к банкротству (руководство полагает, что реинжиниринг информационной системы позволит избежать кризиса); бюджет предприятия сильно ограничен (нет возможности нанять высококвалифицированных специалистов для проведения реинжиниринга). В любом случае (в не зависимости от выбранного пути) процесс реинжиниринга информационной системы проходит через ряд характерных этапов. 15.4. Методологии реинжиниринга информационной системы В общем виде процесс реинжиниринга информационной системы можно изобразить в виде схемы, получившей название модель «подковы» [1] (слайд 6). Он наглядно показывает общую схему РИС: построение/актуализация структурных моделей ИС (исследование ИС); изменение этих моделей (перепроектирование); воплощение измененных моделей (реализация). Необходимо отметить, что в настоящее время не существует единой общепринятой методики реинжиниринга информационных систем. Имеются лишь отдельные методики реинжиниринга отдельных классов информационных систем, например [2], или реинжиниринга информационных систем в определенных ситуациях, например [3]. Однако известен ряд методологий реинжиниринга информационных систем, например [4]. Предпринимается ряд попыток создать методику реинжиниринга информационных систем на основе аналогичных методик реинжиниринга, заимствованных из других областей (например, программного обеспечения, интегральных схем, технических систем и т.п.). Интересно отметить особенности реинжиниринга в разных странах. Можно выделить (несколько условно) следующие три «идеологии», каждая из которых имеет сои отличительные черты (слайд 7): «западная»; «восточная»; «отечественная». Основными характерными чертами, отличающими «западную» идеологию реинжиниринга ИС, являются: проведение реинжиниринга по мере необходимости (т.е. когда назревает ситуация), использование экономических соображений для обоснования необходимости реинжиниринга, широкое использование готовых схем и шаблонов. «Восточную» идеологию отличает постоянное совершенствование информационной системы, ее регулярное обновление. Система рассматривается как развивающийся объект. «Отечественная» идеология реинжиниринга ИС отличается наличием специальных мер, направленных на преодоление организационных проблем, особым отношением к процедуре убеждения руководства5 (в необходимости реинжиниринга), более системным взглядом как на процесс реинжиниринга, так и на саму ИС, а также творческим подходом к генерации альтернатив реинжиниринга информационной системы. 15.5. Этапы реинжиниринга информационной системы В рамках процесса реинжиниринга ИС (в не зависимости от методологии) принято выделять следующие наиболее существенные этапы (слайд 8): формирование команды реинжиниринга; сбор претензий к системе; создание спецификации требований к системе; актуализация структурных моделей системы; генерация альтернатив реинжиниринга системы; выбор оптимальной альтернативы; реализации выбранной альтернативы. Одним из наиболее важных этапов является формирование команды реинжиниринга ИС (слайд 9). Команда обязательно должна иметь лидера, который будет принимать стратегические решения, и координатора, который будет организовывать их реализацию. Также в команду должны входить: специалисты по информационным технологиям вообще, специалисты по ИТ в этой ИС, разработчики, представители групп пользователей предприятия заказчика. Последние будут отражать интересы большинства пользователей информационной системы, а также будут способствовать внедрению обновленной системы на предприятии. Пользователи сопротивляются нововведениям и поэтому необходима их моральная подготовка, которую удобнее провести при посредничестве таких представителей групп пользователей. Рекомендуется также включать в команду реинжиниринга независимых экспертов. Численный состав команды рекомендуется ограничивать 10 членами. При необходимости сбора более многочисленной команды, необходимо выделить «ядро» (не более 10 человек) и «окружение». Члены команды РИС со стороны предприятия заказчика должны быть временно освобождены от должностных обязанностей. Перед началом проекта реинжиниринга информационной системы необходимо получить поддержку руководства предприятия. Без выделения ресурсов (своевременного и в необходимом объеме) реинжиниринг обречен на провал. При этом часто возникает задача обоснования для руководства предприятия необходимости именно реинжиниринга информационной системы, а также невозможности ограничиться только отдельными исправлениями в информационной системе. Решения команды РИС должны иметь статус приказа руководителя предприятия. Всем членам команды реинжиниринга необходимо разъяснить цели и задачи проекта, его особенности и ограничения. На следующем этапе проводится сбор и обработка претензий пользователей информационной системы. От конечных пользователей можно получить конкретные замечания по функционированию ИС, а от руководства – пожелания в плане стратегического развития информационной системы. Следует помнить, что эти замечания еще не являются требованиями к системе, а служат лишь симптомами ее несовершенства. Пользователи и руководство могут сообщить лишь о видимых проявлениях. В основном, они сводятся к замечаниям по удобству пользовательского интерфейса информационной системы, быстродействию и полноте реализации отдельных функций системы. Кроме того, обычно ни пользователи, ни руководство не видят в целом, в комплексе проблему с информационной системой. Процедур сбора претензий на сегодняшний день существует достаточно много (анкетирование, интервьюирование, наблюдение за работой и т.п.). Следует отметить, что обычно пользователи занимают пассивную позицию и необходимо их дополнительно стимулировать. Собранные претензии могут противоречить друг другу. Нужно установить их приоритеты и обоснованность. Поэтому перед составлением спецификации требований необходима обработка собранных претензий. Разработчики должны выяснить, что лежит в основе этих претензий, какие глубинные недостатки информационной системы их порождают. Составление спецификации требований можно проводить по известным методикам, например [5]. Спецификация для реинжиниринга информационной системы должна позволить с одной стороны сохранить общее назначение системы, а с другой позволить существенно развить систему, не потеряв этого назначения. При составлении спецификации рекомендуется использовать требования, сформулированные в техническом задании, по которому была разработана существующая информационная система. Требования можно разделить на два типа: функциональные и нефункциональные. К функциональным требованиям относятся: требования к бизнес-функциям (высокоуровневые цели предприятия или заказчика информационной системы); требования к целям и задачам информатизации (цели и задачи, которые помогает решать информационная система); требования к функциям информационной системы (что необходимо реализовать); системные требования (могут включать также требования к квалификации персонала). К нефункциональным относятся: бизнес-правила (корпоративная политика, постановления правительства, стандарты и т.п.); атрибуты качества информационной системы (характеристики, важные для пользователей и разработчиков); внешний интерфейс (не только пользовательский, но и программный); ограничения (дополнительные требования). Очевидно, для перепроектирования информационной системы требуются ее структурные модели (функциональная, информационная, архитектурная, объектно-ориентированная и т.п.). Причем, в актуальном состоянии, т.е. модели, описывающие информационную систему в том виде и в том состоянии, в котором она существует и эксплуатируется. Однако часто приходится сталкиваться с отсутствием таких структурных моделей или их несоответствием системе. Поэтому, перед перепроектированием требуется актуализация структурных моделей информационной системы. Такое расхождение между информационной системой и описывающими ее структурными моделями обычно вызвано некачественной работой исполнителей. Любые изменения в информационной системе, прежде всего, должны быть отражены в ее структурных моделях6. Можно выделить следующие причины, являющиеся типовыми для такой ситуации: Разработчики, ссылаясь на острую нехватку времени, корректируют только саму информационную систему, оставляя корректировку структурных моделей «на потом». В действительности, это – некачественная работа, ведущая к проблемам при реинжиниринге системы. Изменения информационной системы намеренно не отражаются в ее структурных моделях (по разным мотивам, например «модели нужны были для создания системы, а теперь она живет своей жизнью»). Это в корне неверно. Структурные модели теряются («пропадают») или уничтожаются (не обязательно по злому умыслу, возможно в результате нештатной ситуации). Такие ситуации необходимо исключить (например, путем регулярного резервного копирования моделей). Разработчики «уносят с собой» структурные модели информационной системы (обычно при увольнении). Здесь – ошибка руководителя проекта и кадровой службы предприятия. До сих пор встречаются и такие проекты, в ходе которых структурные модели информационной системы не строятся вовсе (хранятся «в головах разработчиков», рисуются на бумаге, которая позже теряется). В этом случае приходится проводить сложный анализ информационной системы с целью восстановления ее структурной модели. Очень важную роль играют комментарии разработчиков к структурным моделям (как на диаграммах, так и в виде вспомогательного текста), а также комментарии в текстах программ. Поскольку зачастую разработчикам сложно разобраться даже в собственных текстах, написанных какое-то время назад. Современные CASE-средства (такие как Rational Rose, Altova UModel, AllFusion ERWin Data Modeler, AllFusion Business Process Modeler) предоставляют не только широкие возможности построения структурных моделей информационной системы, но и некоторые функции для восстановления структурных моделей из исходных текстов (Rational Rose) или базы данных (AllFusion ERWin Data Modeler) распространенной СУБД. Кроме того, в некоторые современные средства разработки уже включены инструменты для поддержки реинжиниринга (например, в составе Borland Delphi 2009, имеется инструмент для рефакторинга программного обеспечения информационной системы). Генерация альтернатив (вариантов) реинжиниринга является наименее формализуемой (на сегодняшний день) операцией, требующей творческого подхода. Распространение получили следующие способы (слайд 10): генерация альтернатив реинжиниринга ИС в целом; генерация и комбинирование частных вариантов; использование шаблонов. Первый способ требует, чтобы альтернатива описывала реинжиниринг информационной системы в целом, учитывая все требования к системе. Как правило, удается разработать небольшое количество таких альтернатив (5-7). Это способ требует привлечения разработчиков высшей квалификации, способных охватить информационную систему в целом («одним взглядом»). Разработать такую альтернативу крайне сложно, поскольку требуется не только учитывать все требования к информационной системе, но и представлять себе систему целиком. Второй способ генерации базируется на комбинировании частных вариантов разрешения требований к информационной системе. Он основан на методе морфологического ящика (Цвикки7). Для каждого требования разрабатывается максимальное количество разных частных вариантов его разрешения. При этом альтернатива реинжиниринга ИС в целом представляет собой такое подмножество частных вариантов, которое разрешает все требования к информационной системе. Генерация вариантов для отдельных требований – более простая задача, чем генерация вариантов для всей ИС сразу. Комбинирование вариантов может быть автоматизировано. Третий способ является промежуточным между первым и вторым. Он предполагает выбор в качестве основы (шаблона) некоторой готовой альтернативы и последующей коррекции ее для условий конкретного проекта реинжиниринга конкретной информационной системы. Шаблон может описывать общую концепцию реинжиниринга информационной системы на общем уровне и требовать конкретизации. Как вариант, шаблон может также вполне конкретно описывать реинжиниринг основной части информационной системы (например, ее базовых функций) и требовать дополнения для разрешения второстепенных требований к ИС. Такой способ требует наличия «базы» шаблонных решений. Выбор оптимальной альтернативы представляет собой решение многокритериальной задачи принятия решения в условиях риска8. Для этого необходимо сначала определить критерии оптимальности, а затем оценить альтернативы (сначала частные варианты, если альтернативы генерируются по второму способу). Сложность выбора заключается в том, что альтернативы могу быть несравнимы. Чаще всего оценка проводится по таким показателям, как: стоимость реализации альтернативы; степень разрешения требования (ожидаемый эффект); сложность реализации альтернативы; время (длительность) реализации альтернативы. Для получения таких оценок приходится прибегать к экспертным методам. Статистику использовать трудно, поскольку условия выполнения проектов (и сами информационные системы) сильно различаются. Риск заключается в том, что значения показателей могут отклоняться от запланированных. Моделировать риск удобно путем описания показателей случайными величинами с некоторым законом распределения. Поскольку альтернатива представляет собой некоторое подобие комплекса работ, можно пользоваться β-распределением. Это позволяет потребовать от экспертов всего по двух оценок: минимального и максимального возможных значений показателя. При использовании второго способа генерации альтернатив показатели самих альтернатив можно рассчитывать формальными методами на основе показателей частных вариантов. Часто руководствуются следующими «граничными» альтернативами: альтернатива с минимальной стоимостью; альтернатива с минимальной сложностью реализации; альтернатива с максимальным разрешением требований; альтернатива с минимальным временем реализации. Скорее всего, ни одна из перечисленных альтернатив не будет реализована, но они служат для предварительной оценки параметров проекта реинжиниринга информационной системы. Получение оценки длительности реализации альтернативы является одной из наиболее сложных задач, поскольку один и тот же набор работ может быть выполнен по разным графикам (сетевым графикам). Показатель длительности (в отличие от показателя стоимости, например) не позволяет выполнять операцию сложения. Вообще, оценка длительности работы затруднительна сама по себе. Однако в настоящее время затраты на приобретение оборудования относительно невелики (по разным оценкам, порядка 10%). Поэтому, можно считать, что основные затраты – на зарплату разработчиков. Зная их квалификацию и почасовую ставку, можно грубо оценить продолжительность работы. Для реализации выбранной альтернативы необходимо составить технический проект, подробно описывающий необходимые технические решения. Это связано с тем, что альтернатива представляет собой опорный вариант, описывающий по большей части концепцию будущего решения. При реализации альтернативы приходится сталкиваться с целым рядом трудностей, таких как (слайд 11): необходимость перехода со старой информационной системы на новую (включая переустановку программного обеспечения, конвертирование и перенос данных и т.п.); необходимость обучения (переобучения) пользователей; необходимость подготовки окружения информационной системы (бизнес-процессов, смежных систем и т.п.); необходимость поддержки двух версий информационной системы во время перехода со старой версии на новую. Для успешного перехода необходимо учесть режим эксплуатации информационной системы. Существуют, например, такие системы, которые не предусматривают остановку на длительный период времени (например, ИС сотового оператора). 15.6. Перспективы реинжиниринга информационных систем В заключение следует отметить (слайд 12), что реинжиниринг информационных систем является не только «оборонительным оружием», но может служить «оружием наступательным». Например, при необходимости разработать новую систему не всегда нужно начинать ее создание «с чистого листа», а можно провести реинжиниринг какой-то наиболее подходящей существующей информационной системы. Похожий подход используют, например, крупные системные интеграторы. Система-конструктор, содержит в составе основные модули для автоматизации предприятий. На их основе строится базовое решение (базовая архитектура системы), а все необходимые дополнительные модули разрабатываются и интегрируются в это решение. Вообще говоря, реинжиниринг информационных систем – мера вынужденная. Это – сложный процесс, связанный с большими рисками (некоторые авторы сравнивают реинжиниринг с революцией). При реинжиниринге возникает необходимость принятия решения о расходовании значительных средств в условиях неопределенности и риска. Скорее всего, средством избавления от реинжиниринга является планирование развития информационной системы (отношение к информационным системам, как к развивающимся объектам9), а также создание информационных систем по технологиям открытых систем. 1 В разных источниках трактуется по-разному (модернизация – кардинальное улучшение ИС, а реинжиниринг – совершенствование). Иногда, считается, что модернизация и реинжиниринг – синонимы. 2 Хаммер М., Чампи Д. Реинжиниринг корпорации. Манифест революции в бизнесе. – Манн, Иванов и Фебер: 2007. – 299 с. 3 Выгоднее не дожидаться момента, когда ИС окончательно устареет, а прогнозировать этот момент и проводить реинжиниринг заранее. 4 Иногда такую автоматизацию называют «локальной» или «кусочной». 5 К сожалению, экономическое обоснование необходимости реинжиниринга информационной системы предприятия не всегда убеждает его руководство. 6 Некоторые CASE-средства, используемые для разработки информационных систем, прямо подразумевают такой порядок действий. Например, Rational Rose позволяет генерировать исходные тексты программ на базе объектно-ориентированной модели. 7 Мишукаев В.И. Основы инженерного творчества: Учеб. пособие для вузов / В.И. Мишукаев, В.Е. Токарев. – М.: Дрофа, 2005. – 254 с. 8 Строго говоря, в условиях неопределенности и риска, поскольку не все варианты развития ситуации известны, не говоря уже об их вероятности. 9 Уже имеется такое направление – теория развивающихся систем. |