Реинжиниринг программного обеспечения

Перейти к навигацииПерейти к поиску

Реинжини́ринг програ́ммного обеспе́чения — процесс создания новой функциональности или устранения ошибок, путём революционного изменения, но используя уже имеющееся в эксплуатации программное обеспечение. Процесс реинжиниринга описан Чиковски и Кроссом в их труде 1990 года,[1] как «The examination and alteration of a system to reconstitute it in a new form». Выражаясь менее формально, реинжиниринг является изменением системы программного обеспечения после проведения обратного инжиниринга.

Сложность реинжиниринга

Как правило, утверждается, что «легче разработать новый программный продукт». Это связано со следующими проблемами:

  1. реинжиниринг, чаще всего, дороже разработки нового программного обеспечения, так как требуется убрать ограничения предыдущих версий, при этом сохранив с ними совместимость;
  2. реинжиниринг не может сделать программист низкой и средней квалификации — даже профессионалы часто не могут качественно реализовать его, поэтому требуется работа программистов с большим опытом переделки программ и знанием различных технологий[];
  3. разработчику бывает сложно разбираться в чужом исходном коде — это вынуждает адаптироваться к восприятию незнакомого стиля программирования, расходует время на всесторонний анализ и освоение реализованных в проекте концепций, используемых в нём сторонних библиотек, требует скрупулёзно исследовать принцип действия всех плохо документированных участков кода — и всё это лишь осложняет процесс перехода продукта на новые архитектурные решения;
  4. кроме того, сам характер деятельности требует дополнительной мотивации: по сравнению с созданием новых продуктов, переработка уже имеющихся не всегда приносит столь же наглядные и впечатляющие результаты, зачастую отягощает грузом технического долга и оставляет мало места для профессионального самовыражения.

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

См. также

Примечания

  1. ↑ Chikofsky, E. и Cross, J. 7(1) // = Reverse Engineering and Design Recovery: A Taxonomy. — IEEE Software, 1990. — P. 13-18.

Ссылки