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