Рентабельність реінжинірингу
Найчастіше, реінжиніринг програм обходиться дорожче, ніж розробка програми. Причиною цього є те, що потрібно дотримувати сумісності нової версії зі старою або ж реалізовувати конвертер старих даних у нові, а також необхідність обходити обмеження, нав'язані попередніми версіями програм.
Розглянемо два приклади реінжинірингу з життя.
1-й приклад: На одному великому підприємстві з великою кількістю філій працювала програма, розроблена штатним програмістом. На деякому етапі, даний програміст не зміг продовжувати роботу. У результаті, на підприємстві було 2 версії програми: одна стара версія, що працює на BDE і одна нова, але не до кінця працююча й доступ до даних у якій був зовсім інший: компоненти прямого доступу. Стару версію намагалися встановити на філіях, але безуспішно, а в центральному офісі вона працювала з великими помилками. Через це виникали великі черги із замовників, і в результаті компанія зазнавала великих збитків. Програма була розроблена на Delphi з використанням сервера бази даних Interbase 6. Таблиць у програмі було 10-11 штук, а збережених процедур і тригерів практично не використовувалося.
Завдання: Розробити нову версію програми в якій би були реалізовані нові потреби компанії, виправлені помилки, що виникають у центральному офісі й на філіях і яка б змогла працювати на філіях. Так само важливо, щоб програма швидко працювала й не створювалася черга із замовників. Передбачити значно більший сервіс, чим є в даній програмі, а надалі забезпечити систему безпеки на потрібному рівні програми й обмін даними між філіями.
Розв'язок: Технологія побудови первинного додатку повністю задовольняє всім поточним і майбутнім потребам, тому змінювати ні засоби розробки, ні базу даних немає необхідності. Таблиць у проекті небагато, форм теж, тому можна спробувати не створювати програму заново (особливо враховуючи, що програма вже працює), а узятися за реінжиніринг програми. Вихідний текст програми написаний порівняно грамотно (хоча й було багато зауважень), тому повністю переписувати текст не довелося.
У даному проекті реінжиніринг пройшов повністю успішно. І програма пішла на подальший розвиток.
2-й приклад: Один інститут більш 10 років розробляв програму розрахунків, CAD-систему. Програма була написано одним інженером, який сам вивчив Delphi і написав програму, взявши алгоритми з програми на Fortran. У якості бази даних використовувалися dbf-файли. Вихідний текст програми написаний дуже погано, без форматування, без найменування компонентів людськими назвами (назви часто взагалі не змінювалися й залишалися такими, як призначав Delphi). Крім того, система складалася з ряду dll (на кожну форму), вихідний текст яких перебував у різних каталогах, а файли юнітів називалися однаково. Проекти креслень зберігалися в окремих каталогах окремих баз даних.
Завдання: Привести програму до комерційного виду. Організувати систему захисту від копіювання. Організувати систему безпеки на сучасному рівні. Переробити базу даних на Firebird. Організувати можливість імпорту/експорту інформації. Збільшити можливості графічного редактора (наприклад, відкат змін). А також багато чого іншого такого ж типу.
Розв'язок: Вихідний текст довелося повністю переформатувати. Проекти поєднувати в один exe-файл, а однакові юніти видаляти. Довелося побудувати схему бази даних. У результаті виявилося, що база даних надлишкова, а структура безграмотно складена. Систему від копіювання організували. Але переклад в Firebird виявився практично неможливим, економічно невигідним. Програма постійно збоїла. Надійність її була дуже низька.
На початковому етапі, реінжиніринг програми обходився дешевше. Але у процесі експлуатації, підприємство почало би втрачати величезні гроші через погану роботу програми.
Дана система не працювала ніде. Тому ми порахували, що в цьому випадку повна переробка програми виявилася б більш вигідної в результаті, ніж реінжиніринг програми.
Переробка програми коштує на початковому етапі значно більше, але в результаті отримуємо стабільно працюючий програмний продукт і зі значно більш дешевим обслуговуванням.