5. Чому компанії-розроблювачі не люблять реінжиніринг

Не багато компаній реально займається реінжинірингом програм. Якщо ви замовите реінжиніринг, то ймовірніше усього Вам скажуть: < легше розробити новий програмний продукт > і підуть саме цим шляхом. У результаті ви одержите іншу програму, яка може і розв'яже ті проблеми, які були, але яка вже, можливо, буде мати нові проблеми... І не обов'язково програмного розв'язку...

Чому ж так не охоче компанії беруться за реінжиніринг?

От вони причини:

• Програмісти не люблять розбиратися в чужому вихідному тексті. Це однаково, що розбиратися в карлючках, написаних іншою людиною (і часто лівою ногою).

• Реінжиніринг найчастіше дорожче розробки нового програмного забезпечення тому що потрібно переломити обмеження попередніх версій, але при цьому дотримувати сумісності по зростанню версій, тобто надати можливість конвертувати дані зі старих версій у нову.

• Реінжиніринг не може зробити програміст низкою й середньою кваліфікацією. Навіть професіонали часто не можуть якісно реалізувати його. Для грамотного реінжинірингу потрібні експерти - програмісти з великим досвідом переробки програм і знанням різних технологій.

• Виправляти чужу програму - велика відповідальність, тому що можна не помітити або не зрозуміти призначення якихось алгоритмів, реалізованих попереднім програмістом.

• Програмістові може знадобитися розбиратися з технологіями, з якими він не працює, але які використовуються в програмі.

5. Рентабельність реінжинірингу

Найчастіше, реінжиніринг програм обходиться дорожче, ніж розробка програми. Причиною цього є те, що потрібно дотримувати сумісності нової версії зі старою або ж реалізовувати конвертер старих даних у нові, а також необхідність обходити обмеження, нав'язані попередніми версіями програм.

Розглянемо два приклади реінжинірингу з життя.

1-й приклад: На одному великому підприємстві з великою кількістю філій працювала програма, розроблена штатним програмістом. На деякому етапі, даний програміст не зміг продовжувати роботу. У результаті, на підприємстві було 2 версії програми: одна стара версія, що працює на BDE і одна нова, але не до кінця працююча й доступ до даних у якій був зовсім інший: компоненти прямого доступу. Стару версію намагалися встановити на філіях, але безуспішно, а в центральному офісі вона працювала з великими помилками. Через це виникали великі черги із замовників, і в результаті компанія зазнавала великих збитків. Програма була розроблена на Delphi з використанням сервера бази даних Interbase 6. Таблиць у програмі було 10-11 штук, а збережених процедур і тригерів практично не використовувалося.

Завдання: Розробити нову версію програми в якій би були реалізовані нові потреби компанії, виправлені помилки, що виникають у центральному офісі й на філіях і яка б змогла працювати на філіях. Так само важливо, щоб програма швидко працювала й не створювалася черга із замовників. Передбачити значно більший сервіс, чим є в даній програмі, а надалі забезпечити систему безпеки на потрібному рівні програми й обмін даними між філіями.

Розв'язок: Технологія побудови первинного додатку повністю задовольняє всім поточним і майбутнім потребам, тому змінювати ні засоби розробки, ні базу даних немає необхідності. Таблиць у проекті небагато, форм теж, тому можна спробувати не створювати програму заново (особливо враховуючи, що програма вже працює), а узятися за реінжиніринг програми. Вихідний текст програми написаний порівняно грамотно (хоча й було багато зауважень), тому повністю переписувати текст не довелося.

У даному проекті реінжиніринг пройшов повністю успішно. І програма пішла на подальший розвиток.

2-й приклад: Один інститут більш 10 років розробляв програму розрахунків, CAD-систему. Програма була написано одним інженером, який сам вивчив Delphi і написав програму, взявши алгоритми з програми на Fortran. У якості бази даних використовувалися dbf-файли. Вихідний текст програми написаний дуже погано, без форматування, без найменування компонентів людськими назвами (назви часто взагалі не змінювалися й залишалися такими, як призначав Delphi). Крім того, система складалася з ряду dll (на кожну форму), вихідний текст яких перебував у різних каталогах, а файли юнітів називалися однаково. Проекти креслень зберігалися в окремих каталогах окремих баз даних.

Завдання: Привести програму до комерційного виду. Організувати систему захисту від копіювання. Організувати систему безпеки на сучасному рівні. Переробити базу даних на Firebird. Організувати можливість імпорту/експорту інформації. Збільшити можливості графічного редактора (наприклад, відкат змін). А також багато чого іншого такого ж типу.

Розв'язок: Вихідний текст довелося повністю переформатувати. Проекти поєднувати в один exe-файл, а однакові юніти видаляти. Довелося побудувати схему бази даних. У результаті виявилося, що база даних надлишкова, а структура безграмотно складена. Систему від копіювання організували. Але переклад в Firebird виявився практично неможливим, економічно невигідним. Програма постійно збоїла. Надійність її була дуже низька.

На початковому етапі, реінжиніринг програми обходився дешевше. Але у процесі експлуатації, підприємство почало би втрачати величезні гроші через погану роботу програми.

Дана система не працювала ніде. Тому ми порахували, що в цьому випадку повна переробка програми виявилася б більш вигідної в результаті, ніж реінжиніринг програми.

Переробка програми коштує на початковому етапі значно більше, але в результаті отримуємо стабільно працюючий програмний продукт і зі значно більш дешевим обслуговуванням.

28