Основний зміст реінжинірингу ІС і його місце в ЖЦ ІС.
Наступним кроком на шляху дослідження підходів, методів і технологій реінжинірингу ІС слід уважати визначення основного змісту діяльності по реінжинірингові ІС, місця реінжинірингу в ЖЦ ІС.
Реінжиніринг ІС займає проміжне місце розташування стосовно розробки й супроводу ІС. При цьому супровід ІС розглядається як діяльність, що передбачає виконання змін, спрямованих на корекцію, удосконалення й адаптацію ІС, а розробка ІС як діяльність, що включає реалізацію нових можливостей, додавання нової функціональності, здійснення таких істотних поліпшень, як перехід на використання нових комп'ютерів, впровадження нових інформаційних технологій. Реінжиніринг характеризується діяльністю, як по супроводу, так і по розробці ІС. При цьому ці два види діяльності в контексті реінжинірингу ІС можуть суттєво перекриватися.
При огляді різних методик модернізації успадкованих систем, треба відзначити роль модернізації систем у процесі керуваннях їх еволюцією. Комерційний ринок пропонує різноманітні розв'язки проблеми модернізації успадкованих систем, яка стає усе більш актуальною. У ситуації, що склалася розуміння переваг і слабких місць кожної такої методики є надзвичайно важливим, оскільки обумовлює вибір правильного розв'язку, і як наслідок успіх діяльності по модернізації системи.
У контексті досліджень, пов'язаних з еволюцією ІС, виділемо діяльності по супроводу, модернізації й заміщенню ІС.
Визначається, що супровід являє собою інкрементальний ітеративний процес, у рамках якого виконуються малі зміни в системі, що не зачіпають структурної організації системи (архітектури системи).
На відміну від супроводу модернізація характеризується як діяльність, яка передбачає значні зміни існуючої системи ( у тому числі в її структурі), але не її утилізацію або заміщення новою системою.
І, нарешті, заміщення розглядається як процес, який полягає у впровадженні нової системи, здатної повністю замінити існуючу ІС. Заміщення звичайне застосовується до систем, які недокументовані, застаріли або не розширювані, розходяться з вимогами бізнесу й для яких модернізація неможлива або економічно не вигідна.
Визначаючи місце цих видів діяльності в контексті ЖЦ ІС, можна розглядати наступну послідовність їх виконання (див рис. 1).
Рис. 1 Життєвий цикл ІС.
Спочатку, здійснюється розробка (побудова) ІС. Далі виконується діяльність по її супроводу. У процесі супроводу виникає необхідність у реструктуризації системи і як наслідок виконується діяльність по її модернізації. Після цього знову здійснюється діяльність по супроводу системи. У той момент, коли ІС перестає задовольняти замовника, здійснюється її заміщення на нову систему й послідовність виконуваних видів діяльності повторюється. Безумовно, у реальному житті може виникати й інша послідовність, коли, відразу, не прибігаючи до модернізації, здійснюється заміщення однієї ІС іншої. Однак загальний підхід до послідовності виконання супроводу, модернізації й заміщення залишиться незмінним.
Забезпечуючи концептуальне розуміння процесу реінжинірингу ІС, визначаються основні види діяльності (фази), що співвідносяться із цим процесом.
Розглядаються наступні основні фази:
оцінки показників проекту по реінжинірингові, у тому числі характеристик успадкованої інформаційної системи (фаза оцінки);
аналізу розв'язків по реінжинірингові, у тому числі ухвалення рішення про необхідність проведення робіт з реінжинірингу або супроводу/розробці ІС;
здійснення реінжинірингу (виконання робіт з реінжинірингу);
впровадження системи, трансформованої в результаті проведення реінжинірингу.
Інший підхід до визначення діяльності по реінжинірингу базується на так званій моделі «підкови» [9, 21].
В основу даної моделі покладені наступні процеси ( види діяльності), що співвідносяться з реінжинірингом ІС:
аналіз існуючої системи, заснований на одному або більш її логічних описів;
трансформація цих логічних описів у новий, поліпшений логічний опис системи.
розробка нової системи, заснованої на нових логічних описах системи.
Ці три основні процеси з'єднуються в моделі у вигляді «підкови» (див Рис. 2).
Рис.2 Модель «підкови».
Перший процес (Architecture Recovery) передбачає відновлення архітектури існуючої системи за допомогою і на підставі успадкованого ісходного коду артефактів, що їх характеризують. Отримана архітектура аналізується на предмет відповідності вимогам до змінюваності, надійності, захищеності і так далі.
Другий процес (Architecture Transformation) полягає в трансформації (реінжинірингу) відновленої архітектури до бажаної нової архітектури. Отримана в результаті трансформації нова архітектура оцінюється з позиції її якості з урахуванням економічних та організаційних обмежень.
І, нарешті, третій процес (Architecture-based Development) включає діяльність по розробці системи, яка відповідає новій архітектурі. Тут вирішуються питання декомпозиції елементів системи по пакетах, здійснюється вибір стратегій взаємодії елементів/компонентів системи. У рамках даного процесу так само забезпечується інтеграція в нову систему артефактів успадкованої системи, наприклад, за допомогою переписування частини успадкованого коду й/або застосування технології побудови оболонок для компонентів успадкованої системи.
З моделлю «підкова» співвідноситься три рівні, на кожному з яких може здійснюватися трансформація існуючої системи.
Представлення на рівні структури коду (Code-Structure Representation) включає програмний код, а так само такі артефакти, як абстрактні синтаксичні дерева й графи потоків (flow graphs), одержувані на підставі виконання різного роду аналітичних операцій (наприклад, розбору коду). Текстуальний переклад, а так само переклад на основі синтаксичних дерев є прикладами трансформації системи на цьому рівні.
На відміну від попереднього рівня, представлення на рівні функціональності системи (Function-Level Representation) передбачає визначення зв'язків між функціями програм (наприклад, послідовності викликів), даними ( як окремий випадок, зв'язків між сутностями даних, співвідношень даних і функцій) і файлами ( приміром, розподіл функцій і даних по файлах). Трансформація системи на даному рівні здійснюється на підставі перегляду функціональності системи й полягає, наприклад, у переході від функціонального підходу до об'єктного підходу до аналізу й проектуванню, у переході від реляційної БД до об'єктної БД.
На архітектурному рівні артефакти попередніх рівнів, поєднуються в підсистеми в термінах архітектурних компонентів архітектури ІС. Трансформація системи на цьому рівні передбачає корінні зміни в структурі програми, у тому числі в частині застосування основних зразків взаємодії компонентів: типів програмних компонентів, використовуваних з'єднувачів (connectors), варіантів декомпозиції функціональності, зразків керування й обміну даними часу виконання.
Згідно з моделлю «підкова» трансформація системи, залежно від ситуації, може здійснюватися на кожному із представлених рівнів, при цьому більш низький рівень підтримує трансформацію на більш високому рівні.
Слід визнати, що модель «підкова» знаходить широке застосування в рамках діяльності, пов'язаної з реінжинірингом ІС. На її основі визначаються вимоги й основний каркас для інтеграції інструментальних засобів реінжинірингу на архітектурному рівні й рівні програмного коду. З урахуванням процесів, що співвідносяться з нею, і рівнів представлення, здійснюється розширення моделі CORUM (Common Object-based Reengineering Unified Model). Ця модель, у свою чергу, розроблялася:
для представлення необхідної для систем керування на основі програмного коду (Code-based Management System) інформації про програмні засоби;
для забезпечення інтероперабельності між системами даного класу ( у тому числі між засобами реінжинірингу програм на рівні програмного коду).
У контексті розширень для моделі «підкова» можна визначити семантичну модель, що забезпечує на підставі сформульованих уніфікованих властивостей семантичний зв'язок між архітектурним рівнем і рівнем програмного коду.
Є підхід, запропонований в [34-36], дуже близький до підходу, заснованого на моделі «підкова». Характеризуючи життєвий цикл реінжинірингу ІС, автори визначають наступні кроки процесу реінжинірингу:
аналіз вимог для виявлення конкретних цілей реінжинірингу успадкованої системи;
відновлення моделі, у тому числі документування й розуміння структури успадкованої системи;
виявлення проблем, пов'язаних з успадкованою системою;
аналіз проблем, що включає вибір архітектури, що дозволяє усунути виявлені в успадкованій системі дефекти;
реорганізація, що включає вибір і застосування оптимального підходу трансформації успадкованої системи;
поширення змін.
На відміну від попередніх поглядів, можна розглядати [10, 13] діяльність по реінжинірингу в якості однієї з форм діяльності по еволюції успадкованих ІС, коли потрібно більш сильнодіюче «ліки» для «лікування» ІС, ніж серія локальних інкрементальних змін [13].
Розглядається [13] каркас (enterprise framework), що характеризує:
глобальне середовище, у якому здійснюється еволюція системи;
дії, процеси й робочі продукти (артефакти), які супроводжують діяльність по еволюції системи.
Підкреслюється, що крім технічних питань, пов'язаних з еволюцією успадкованих ІС, існує так само безліч організаційних питань. Наприклад, « Як планувати еволюцію великої складної системи, включаючи її реінжиніринг?», «Які існують критичні фактори успіху еволюції системи?», « Як оцінити, що люди, що здійснюють еволюцію системи, на правильному шляху?». Крім цього, важливим є необхідність урахування стратегічних, організаційних, і інших аспектів бізнесу, що впливають на еволюцію успадкованої ІС.
Тому основною метою створення каркаса (enterprise framework) слід уважати необхідність оцінки середовища, у рамках якої здійснюється еволюція успадкованої ІС, необхідність забезпечення розуміння широкого спектра питань, як технічного, так і управлінського характеру, які співвідносяться з еволюцією успадкованих ІС. Найважливішим тут стає виявлення факторів, що визначають успіх діяльності по еволюції ІС, а так само розробка погодженої безлічі технічних і управлінських інструкцій (дій), необхідних для ефективного планування, оцінки й керування ініціативами по еволюції систем.
Відображкючи стосовно до еволюції системи простір проблем і простір рішень, пропонований в [13] каркас включає такі елементи, як організація, проект, успадкована система, інженерія систем і програмних засобів, технології, цільова система. Між цими елементами визначається зв'язок. При цьому для кожного з них приводиться список питань (checklists), що дозволяє охарактеризувати (досліджувати й оцінити) елемент, що цікавить.
Слід визнати, що покладена в основу каркаса концепція є розширенням концепції розробки ІС із урахуванням діяльності по впровадженню, повсякденних операцій і діяльності по супроводу. Каркас може бути використаний для виконання наступних видів діяльності:
дослідження й аналіз простору проблем і простору рішень у контексті ініціатив по еволюції системи;
розробка опису по складанню стратегічних і тактичних планів по реінжинірингові успадкованих систем;
виявлення технологічних питань і потенційних проблем протягом усього шляху по еволюції систем;
рецензування планів, ранжирування (приоритезація) технічних питань, розробка рекомендацій з поліпшень процесів еволюції систем і результатів їх виконання ( робочих продуктів).
Загальний підхід до використання каркаса представлений на Рис. 3.
Рис. 3 Загальний підхід до використання каркаса.
У рамках підходу виділяються дві значні складові: основна фаза й фаза еволюції. Основна фаза сфокусована на таких елементах, як організація, проект і успадкована система. Фаза еволюції концентрується на цільовій системі, інженерії систем і програмних засобів, технологіях, використовуваних для побудови цільової системи. Іншими словами перша фаза сфокусована на просторі проблем, а друга на просторі рішень.
В [10] пропонується комплексний, заснований на розглянутому раніше каркасі, підхід до еволюції систем, який визначається в контексті успадкованих систем і сучасних програмних технологій.
В основу підходу покладені наступні положення (принципи):
відмінність між еволюцією систем і супроводом програмних засобів;
використання описаного раніше каркаса (enterprise framework) за підтримки прийняття розв'язків у процесі еволюції системи;
досягнення технічного розуміння систем на високому рівні абстракції;
застосування технологій розподілених об'єктів, технології «wrapping» [10] для еволюції системи;
застосування «net-centric» [10] обчислень для еволюції системи.
Визначаючи відмінність між супроводом програмних засобів і еволюцією систем у частині реінжинірингу ІС, можна розглядати супровід як «дрібнозернисту», «короткострокову» діяльність, спрямовану на планування й внесення локалізованих змін. При супроводі структура (архітектура) системи залишається відносно незмінної, а необхідна «порція» внесених за певний проміжок змін, як правило, пов'язана зі зміною якої-небудь однієї вимоги до системи. Такі зміни, звичайно, не супроводжуються істотною зміною значень характеристик і атрибутів якості програмних засобів.
На відміну від супроводу, еволюція систем розглядається як «грубозерниста», «високорівнева», форма змін на рівні структури (архітектури) системи. Внесені в процесі еволюції зміни, приводять до змін значень атрибутів якості, що, як правило, суттєво спрощує супровід систем. Для цього при внесенні змін у структуру системи можуть використовуватися стратегії «знизу нагору» і «зверху вниз», застосування яких засновано на ревізії програмного коду, відновленні опису архітектури успадкованої системи, проектуванні нової структури, нової форми документації і т.д. Треба підкреслити, що еволюція дозволяє адаптувати систему відразу з урахуванням великої кількості висунутих до неї вимог (включаючи придбання нових можливостей), що в остаточному підсумку збільшує стратегічну й економічну значимість програмних засобів. При цьому акцент зміщується від розуміння програм до розуміння систем, від супроводу до еволюції й міграції, від стратегій «знизу нагору» до стратегій «зверху вниз».
На відміну від розглянутих раніше робіт, в [15] основна увага приділяється дослідженню й вирішенню технічних проблем, пов'язаних з міграцією успадкованих систем. Характеризуючи поняття «міграція ІС» у даній роботі виділяються окремо еволюція, супровід і міграція ІС. Ґрунтуючись на тому факті, що об'єктом еволюції й супроводу є успадкована ІС, а об'єктом міграції як успадкована, так і нова (цільова) системи, розділяють міграцію й інші процеси ЖЦ ІС. При цьому міграція розглядається як діяльність, яка починається з успадкованої ІС і закінчується цільової ІС, з якої порівнюється.
В основу пропонованого авторами підходу покладена декомпозиція структури системи на компоненти користувацького інтерфейсу, компоненти – додатка й компоненти керування базами даних. При цьому в якості основних інкрементально виконуваних кроків міграції виступають:
аналіз успадкованої ІС;
декомпозиція структури успадкованої ІС;
проектування інтерфейсів (користувацьких і системних) цільової системи;
проектування додатків ( функціональної логіки) цільової системи;
проектування бази даних цільової системи;
розгортання середовища, необхідної для експлуатації й супроводу цільової системи;
створення й розгортання необхідних шлюзів;
міграція успадкованих даних;
міграція успадкованих додатків (компонентів, що реалізують функціональну логіку);
міграція успадкованих інтерфейсів (користувацьких і системних);
перехід до використання цільової системи.