В любом случае (в не зависимости от выбранного пути) процесс реинжиниринга информационной системы проходит через ряд характерных этапов.
15.4. Методологии реинжиниринга информационной системы
В общем виде процесс реинжиниринга информационной системы можно изобразить в виде схемы, получившей название модель «подковы» [1] (слайд 6). Он наглядно показывает общую схему РИС:

• 
  построение/актуализация структурных моделей ИС (исследование ИС);
  
• 
  изменение этих моделей (перепроектирование);
  
• 
  воплощение измененных моделей (реализация).
  

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

Интересно отметить особенности реинжиниринга в разных странах. Можно выделить (несколько условно) следующие три «идеологии», каждая из которых имеет сои отличительные черты (слайд 7):

• 
  «западная»;
  
• 
  «восточная»;
  
• 
  «отечественная».
  

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

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

«Отечественная» идеология реинжиниринга ИС отличается наличием специальных мер, направленных на преодоление организационных проблем, особым отношением к процедуре убеждения руководства⁵ (в необходимости реинжиниринга), более системным взглядом как на процесс реинжиниринга, так и на саму ИС, а также творческим подходом к генерации альтернатив реинжиниринга информационной системы.
15.5. Этапы реинжиниринга информационной системы

---

В рамках процесса реинжиниринга ИС (в не зависимости от методологии) принято выделять следующие наиболее существенные этапы (слайд 8):

1. 
   формирование команды реинжиниринга;
   
2. 
   сбор претензий к системе;
   
3. 
   создание спецификации требований к системе;
   
4. 
   актуализация структурных моделей системы;
   
5. 
   генерация альтернатив реинжиниринга системы;
   
6. 
   выбор оптимальной альтернативы;
   
7. 
   реализации выбранной альтернативы.
   

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

Рекомендуется также включать в команду реинжиниринга независимых экспертов. Численный состав команды рекомендуется ограничивать 10 членами. При необходимости сбора более многочисленной команды, необходимо выделить «ядро» (не более 10 человек) и «окружение». Члены команды РИС со стороны предприятия заказчика должны быть временно освобождены от должностных обязанностей.

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

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

---

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

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

Требования можно разделить на два типа: функциональные и нефункциональные. К функциональным требованиям относятся:

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

К нефункциональным относятся:

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

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

---

актуализация структурных моделей информационной системы.

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

• 
  Разработчики, ссылаясь на острую нехватку времени, корректируют только саму информационную систему, оставляя корректировку структурных моделей «на потом». В действительности, это – некачественная работа, ведущая к проблемам при реинжиниринге системы.
  
• 
  Изменения информационной системы намеренно не отражаются в ее структурных моделях (по разным мотивам, например «модели нужны были для создания системы, а теперь она живет своей жизнью»). Это в корне неверно.
  
• 
  Структурные модели теряются («пропадают») или уничтожаются (не обязательно по злому умыслу, возможно в результате нештатной ситуации). Такие ситуации необходимо исключить (например, путем регулярного резервного копирования моделей).
  
• 
  Разработчики «уносят с собой» структурные модели информационной системы (обычно при увольнении). Здесь – ошибка руководителя проекта и кадровой службы предприятия.
  

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

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

Современные 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). Это способ требует привлечения разработчиков высшей квалификации, способных охватить информационную систему в целом («одним взглядом»). Разработать такую альтернативу крайне сложно, поскольку требуется не только учитывать все требования к информационной системе, но и представлять себе систему целиком.

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

Третий способ является промежуточным между первым и вторым. Он предполагает выбор в качестве основы (шаблона) некоторой готовой альтернативы и последующей коррекции ее для условий конкретного проекта реинжиниринга конкретной информационной системы. Шаблон может описывать общую концепцию реинжиниринга информационной системы на общем уровне и требовать конкретизации. Как вариант, шаблон может также вполне конкретно описывать реинжиниринг основной части информационной системы (например, ее базовых функций) и требовать дополнения для разрешения второстепенных требований к ИС. Такой способ требует наличия «базы» шаблонных решений.

Выбор оптимальной альтернативы представляет собой решение многокритериальной задачи принятия решения в условиях риска⁸. Для этого необходимо сначала определить критерии оптимальности, а затем оценить альтернативы (сначала частные варианты, если альтернативы генерируются по второму способу). Сложность выбора заключается в том, что альтернативы могу быть несравнимы. Чаще всего оценка проводится по таким показателям, как:

---

Смотрите также файлы

• ыса мерзімді жоспар1.docx

• Решение Материалоемкость рассчитывается по формуле где выпуск продукции, тыс руб., материальные затраты, тыс руб.docx

• В практической части работы хотелось бы рассмотреть в сравнении опыт разных стран. Для примера возьмем сша.docx

• Содержание Введение 3 Общие сведения о споре его виды и цели 4 Тактические приемы в споре 6 Уловки в споре 10 Заключение 18 Список использованной литературы 20 Введение.docx

• Diktant ikki do'st.doc