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

 

СОДЕРЖАНИЕ

 

ВВЕДЕНИЕ                                                                                                                     3

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

Цели и задачи реинжиниринга                                                                                           8

Проблемы при реинжиниринге                                                                                          9

Управление требованиями                                                                                                  9

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

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

ЗАКЛЮЧЕНИЕ                                                                                                                  14

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

 

 

 

 

 

 

 

 

 

 

Введение

 

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

Для решения данной проблемы предприятие, как правило, находит  программиста, который пытается реализовать  данную программу. Проходит время, программа  внедряется на предприятии и с  ней начинает работать большое количество персонала. Привыкнув к программе, сотрудники уже не представляют себя без столь удобного инструмента, как программа. Проходит еще время, а программист берет и увольняется, идет на другую работу или вообще уезжает  за рубеж (или умирает) и больше продолжать и поддерживать проект не может. В  результате, предприятие сталкивается с большой проблемой: есть программа, с которой привык работать персонал и подобной на рынке не найти, но нет ее дальнейшего совершенствования  и поддержки. Данная программа начинает резко устаревать. Вначале, в ней, оказывается, нет каких-то возможностей, которые нужны стали после  увольнения программиста, а потом - она не может эффективно работать с современным оборудованием  или вообще, начинает "тормозить" из-за большого количества введенной  информации. Проходит еще немного  времени - от полугода до 2-х лет и  оказывается, что на данной программе  больше нельзя работать, так как  она "глючит", "тормозит" и  вообще перестает работать... Столкнувшись с данной проблемой, предприятие начинает искать нового программиста или компанию, которая способна привести данную программу к удовлетворяющему предприятие виду. Однако, как оказывается не все так просто... Оказывается, большое количество программистов, которые хоть что-нибудь умеют сделать уехало за рубеж. А на рынке остались те, кто уехать не смог или кому не было в этом потребности. Предприятию очень повезет, если оно сразу найдет грамотного и ответственного программиста. Как правило, придется перебрать 2-3 человека, прежде, чем они найдут достойную кандидатуру. Однако, грамотные программисты дешево не стоят и постоянно хотят перспектив. Поэтому, если вы не быстро развивающееся программное предприятие, да еще не так уж и много платите, то придет момент, что данный программист уйдет тоже. И опять начинается все снова: 2-3 безответственных программиста, потом один профессиональный и ответственный, который 2-3 месяца будет вникать в курс дела и через 2-3 года уйдет...

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

 

 

 

 

 

 

 

 

 

 

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

 

Реинжиниринг программного обеспечения — процесс создания новой функциональности или устранения ошибок, путём революционного изменения, но используя уже имеющееся в  эксплуатации программное обеспечение. Процесс реинжиниринга описан Chikofsky и Кроссом в их труде 1990 года, как «The examination and alteration of a system to reconstitute it in a new form». Выражаясь менее формально, реинжиниринг является изменением системы программного обеспечения после проведения обратного инжиниринга. Реинжиниринг программного обеспечения, можно разделить на несколько этапов: Начальная фаза. Начать процесс реинжиниринга следует с определения того, что есть по существующей системе (исходные тесты, БД, описания и т. д.). При этом фиксируется текущее состояние наследуемой системы (все изменения, вносимые в нее после этого момента, при выполнении реинжиниринга не учитываются). Если есть возможность выполняется развертывание наследуемой ПС у разработчика.

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

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

Реинжиниринг БД выполняется  с помощью инструментальных средств проектирования БД. Результатом является реляционная модель данных, которая может графически отображаться этим средством. Полученная реляционная модель может по усмотрению разработчиков переведена в диаграмму классов UML путем использования применяемого инструментального средства разработки БД или программных мостов со средствами визуального ОО моделирования. Редактирование диаграмм моделей. Модели, полученные автоматически, весьма сложно читать и анализировать, поскольку элементы модели размещаются без учета наглядности диаграмм. Поэтому построенные модели должны быть отредактированы. В процессе редактирования не следует выполнять содержательные преобразования (удалять или добавлять элементы модели). Главной целью редактирования на этом этапе является достижение наглядности диаграмм. Для этого используется перемещение элементов диаграмм. В процессе редактирования могут вноситься комментарии к элементам модели. Например, можно прокомментировать назначение отдельных классов. Комментарии заносятся в поля спецификаций элементов моделей.

Если диаграмма содержит слишком много элементов, то анализировать  ее сложно. Попробуйте проанализировать диаграмму, содержащую более 100 классов! Поэтому целесообразно разбить  такую диаграмму на несколько  отдельных диаграмм, оставляя в каждой примерно по 7 – 10 элементов.

Метод повышения наглядности  диаграмм хорошо известен. Это иерархическая  реструктуризация. Средством ее осуществления  в UML являются пакеты. Сложные ПС обычно включают несколько подсистем, имеющих  разное целевое назначение и функциональность. Поэтому на верхнем уровне иерархии можно показать пакеты – подсистемы. Каждый из таких пакетов должен получить имя, отражающее суть соответствующей  подсистемы. На этом уровне можно также  показать пакеты классов, являющиеся общими для всей системы и используемые подсистемами. На начальной стадии реструктуризации логической модели можно ввести пакет верхнего уровня, куда помещаются классы, которые трудно отнести к какому-либо другому пакету. В любой ПС есть пользовательский интерфейс, связь с БД, управление, обработка, классы данных. Такого типа пакеты можно ввести в каждой подсистеме на следующем уровне иерархии. Построение функциональной модели. Модель функционирования описывается с помощью диаграмм ВИ и детализирующих их диаграмм последовательностей и деятельностей. Источником для ее построения является работающая наследуемая система и проводимые с ней эксперименты. На этом этапе особенно эффективно привлечение к работам по реинжинирингу эксперта организации заказчика. С его помощью можно быстрее и точнее определить состав актеров наследуемой системы и основные ВИ. Эксперт заказчика может словесно описать, кто использует систему и что она должна делать для пользователей каждого типа. Он может также информировать, с какими другими системами взаимодействует наследуемая ПС, какие работы осуществляются периодически. Все эти сведения будут способствовать более точному пониманию функциональности системы разработчиками.

Определение вариантов использования. Определение ВИ выполняется на основе анализа экранов работающей системы. Сначала определяются пакеты ВИ. Для  этого следует найти все первичные  экраны и для каждого из них  в модели на головной диаграмме ВИ завести отдельный пакет. Таким  образом, на этой диаграмме будет  пакет актеров и несколько  пакетов ВИ. Далее выполняется  детализация построенных пакетов  ВИ на основе анализа экранных форм. Рекомендуемые правила: если экран  содержит меню, то это пакет ВИ. При  этом каждая строка меню – это либо подпакет, либо отдельный ВИ;

если основной экран –  форма, то это отдельный ВИ.

 

 

 

 

Цели и задачи реинжиниринга

 

     Цели проведения реинжиниринга заключаются в следующем:

получение представления  о составе существующей системы;

моделирование существующей системы;

определение фрагментов программного кода, которые могут быть использованы в разрабатываемой новой системе;

определение наследуемых  данных.

   

Задачи реинжиниринга

 

Задачи, решаемые при реинжиниринге, включают:

определение системных архитектур;

определение актеров существующей системы;

определение функциональности существующей системы;

определение логической структуры  системы;

восстановление реляционной  модели данных.

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

Проблемы при реинжиниринге

 

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

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

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

 

Управление требованиями

 

Требования к ПС

Требование – это характеристика или условие, которому должна удовлетворять  ПС.

Функциональные требования определяют действия, которые должна выполнять ПС, без учета физических ограничений. Тем самым они определяют поведение системы при вводе  и выводе. Процесс выявления функциональных требований весьма сложный и трудоемкий. Это объясняется следующими причинами:

таких требований к системе  обычно много,

заказчик не всегда способен четко сформулировать, чего он хочет  от системы,

требования в итоговом документе должны быть изложены так, чтобы они одинаково понимались заказчиком и исполнителем и не допускали  неоднозначности,

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

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

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

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

неочевидны,

исходят из многих источников,

трудно формулируются (язык неоднозначен),

состоят из множества различных  деталей,

неравнозначны,

связаны друг с другом,

лежат не только в функциональной области.

могут изменяться в течение  разработки и при сопровождении.

 

 

 

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

 

Определение потенциальной  архитектуры. Данная деятельность включает архитектурный анализ и анализ ВИ. Определяется первоначальный набор  архитектурно значимых элементов и  механизмов реализации, выполняется  начальное разбиение на уровни, определяется структура системы, выбираются ВИ, которые  будут реализовываться в первой итерации фазы развития проекта. В результате создается эскиз архитектуры  ПС. На основе анализа архитектурно значимых ВИ определяются основные классы, которые включаются в модель анализа. В модель анализа включаются диаграммы, описывающие взаимодействие основных классов.