Определение и этапы реинжиниринга

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

Обеспечивается переход  от анализа к проектированию путем  определения из элементов и механизмов анализа элементов и механизмов проектирования;

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

Осуществляется плавный  переход от проектирования к реализации;

Анализ поведения. Эта  деятельность включает анализ ВИ, определение  элементов проекта и обзор  проекта. Эта деятельность имеет  целью преобразование описаний поведения  в виде ВИ в набор элементов  проекта (классы, отношения, операции и  др.).

Проектирование компонентов. Цели данной деятельности состоят в:

Определении и уточнении элементов проекта путем подробного описания того, как эти элементы реализуют требуемое поведение.

Определении и уточнении реализации ВИ на основе новых элементов проекта.

Контроле и рецензировании проекта по мере его развития.

Проектируются ВИ, подсистемы, классы и компоненты ПС. Точно описываются  интерфейсы компонентов и их реализация.

Проектирование БД. Данная деятельность выполняется для проектов, использующих базы данных. Она включает:

Определение персистентных (постоянно хранимых) классов;

Проектирование структуры  БД для хранения таких классов;

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

Анализ и проектирование связывает управление требованиями и реализацию. В этом технологическом  процессе создается модель проектирования. Одно из ее представлений – логическая модель – отражает декомпозицию ПС в набор логических элементов (классы, подсистемы, взаимодействия). Процедурное  представление отображает эти элементы в процессы и подпроцессы системы. Представление развертывания отображает эти процессы в набор узлов вычислительного комплекса, на которых они выполняются.

 

 

 

 

 

 

 

 

 

 

 

Почему компании-разработчики не любят реинжиниринг

 

Не много компаний реально  занимается реинжинирингом программ. Если Вы закажете реинжиниринг, то вероятней всего Вам скажут: « легче разработать новый программный продукт» и пойдут именно этим путем. В результате Вы получите другую программу, которая может, решит те проблемы, которые были, но которая уже, возможно, будет обладать новыми проблемами... И не обязательно программного решения...

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

Вот они причины:

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

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

 

 

 

Заключение

 

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

Рассмотрим примера реинжиниринга  из жизни.

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

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

Решение: Исходный текст пришлось полностью переформатировать. Проекты объединять в один exe-файл, а одинаковые юниты удалять. Пришлось построить схему базы данных. В результате оказалось, что база данных избыточная, а структура безграмотно составлена. Систему от копирования организовали. Но перевод в Firebird оказался практически не возможным, экономически не выгодным. Программа постоянно сбоила. Надежность ее была очень низкая.

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

Переделка программы стоит  на начальном этапе значительно  больше, но в результате получается стабильно работающий программный  продукт и с значительно более дешевым обслуживанием.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

 

1.  Верников Г. Что такое реинжиниринг? // Еженедельный ж-л Консалтинг.ру
2. Зиндер Е. Реинжиниринг бизнес-процессов и автоматизация офиса // Тезисы к конференции
3. Ойхман Е.Г., Попов Э.В. Реинжиниринг бизнеса: Реинжиниринг организаций и информационные технологии. – М.: Финансы и статистика, 1997
4. Райзберг Б.А., Лозовский Л.Ш., Стародубцева Е.Б. Современный экономический словарь. – М.: Инфра-М, 1998
5. Хаммер М., Чампи Дж. Реинжиниринг корпорации: манифест революции в бизнесе. – СПб.: Издательство С.-Петербургского университета, 1997
6. Шумахер В. Устранение препятствий для успеха реинжиниринга // Еженедельный ж-л Консалтинг.ру
7. Орлов С.А. Технологии разработки программного обеспечения. СПб.:Питер, 2002. –322 с.
8. Подкаменный Д.В. Вычислительный сервер для решения задач оптимального управления / Современные технологии. Системный анализ. Моделирование. Иркутск: ИрГУПС. – 2008.- 3 (19) . – С. 109-113
9. Е.А. Жоголев. Система программирования с использованием библиотеки подпрограмм. // Система автоматизация программирования. – М. : Физматгиз, 1961.