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


Содержание

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

Федеральное агентство по образованию

Государственное образовательное учреждение высшего профессионального образования

«Казанский государственный технологический университет»

Нижнекамский химико-технологический институт

Реферат на тему:

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

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

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

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

Анализ и проектирование

Преимущества и недостатки компании-разработчика перед отдельным разработчиком

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

Список использованной литературы

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

Разнообразие программного обеспечения куда больше, чем технических решений. Так как они решают самые различные задачи, начиная от связи с оборудованием (драйвера) и заканчивая автоматизацией бухгалтерского учета или 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 являются пакеты. Сложные ПС обычно включают несколько подсистем, имеющих разное целевое назначение и функциональность. Поэтому на верхнем уровне иерархии можно показать пакеты – подсистемы. Каждый из таких пакетов должен получить имя, отражающее суть соответствующей подсистемы. На этом уровне можно также показать пакеты классов, являющиеся общими для всей системы и используемые подсистемами. На начальной стадии реструктуризации логической модели можно ввести пакет верхнего уровня, куда помещаются классы, которые трудно отнести к какому-либо другому пакету. В любой ПС есть пользовательский интерфейс, связь с БД, управление, обработка, классы данных. Такого типа пакеты можно ввести в каждой подсистеме на следующем уровне иерархии.

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

Определение актеров. Для нахождения актеров следует искать ответы на следующие вопросы:

Кто является непосредственными пользователями системы? Необходимо при ответе на данный вопрос указывать роли, а не конкретных людей, исполняющих эти роли.

С каким внешним оборудованием или программами осуществляет взаимодействие система?

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

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

Актерам следует присвоить имена, отражающие их роли в работе с системой.

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

Далее выполняется детализация построенных пакетов ВИ на основе анализа экранных форм. Рекомендуемые правила:

если экран содержит меню, то это пакет ВИ. При этом каждая строка меню – это либо подпакет, либо отдельный ВИ;

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

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

Распределение по пакетам. Если число актеров или ВИ слишком велико, то для упрощения поддержки модели ВИ целесообразно разделить их по пакетам. Это также упрощает понимание модели и распределение ответственности путем назначения разработчиков, ответственных за пакеты ВИ. Можно использовать следующие критерии упаковки ВИ в один пакет:

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

имеют друг с другом отношения включения или расширения (см. статью «Варианты использования системы. Use case диаграммы»).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цели анализа и моделирования требований

Целями анализа и моделирования требований являются:

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

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

ограничение системной функциональности;

создание базиса для планирования разработки проекта;

определение пользовательского интерфейса;

составление спецификации требований.

Системный аналитик – специалист организации-разработчика, который возглавляет и координирует работы по выявлению и моделированию требований.

Разработчик ВИ – специалист организации-разработчика, который детализирует и уточняет модели требований.

Заинтересованные лица – люди, предоставляющие информацию.

Эксперт – представитель заказчика, участвующий в разработке модели требований.

Разработчик пользовательского интерфейса – специалист организации-разработчика, который создает прототип пользовательского интерфейса ПС.


Для достижения поставленных целей предусматривается создание следующих документов:

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

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

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

Прототип пользовательского интерфейса обеспечивает визуальное представление интерфейса пользователя с ПС.

Глоссарий – текстовый документ, содержащий определения основных понятий и терминов, которые должны одинаково пониматься заказчиком и разработчиком. Источниками данных для создания перечисленных артефактов могут, в частности, служить артефакты, созданные при бизнес-анализе (см. статью «RUP. Обследование организации (бизнес-анализ)».

В процессе анализа и моделирования требований можно выделить несколько основных этапов (см. рис.1).

Рис.1 Технологический процесс управления требованиями.

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

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

Построение модели требований

Эта работа предполагает выявление актеров, ВИ и взаимодействий между ними. Если было проведено обследование организации, то в качестве источника для определения актеров и ВИ может служить бизнес-модель.

Если число ВИ слишком велико, то для упрощения читаемости и поддержки модели целесообразно разделить их по пакетам. Это также упрощает понимание модели и распределение ответственности путем назначения разработчиков, ответственных за пакеты ВИ. Пакеты позволяют организовать иерархию требований. Верхний уровень иерархии обычно определяется, исходя из основных видов деятельности организации. Если был выполнен бизнес-анализ, то основные виды деятельности уже представлены в бизнес-модели в виде пакетов, и они могут быть просто скопированы в модель требований. Пакетов верхнего уровня не должно быть много. Целесообразно выделить пакет администрирования и пакет вспомогательных действий, и 2 – 4 пакета, основных видов деятельности. В свою очередь, пакеты верхнего уровня могут включать пакеты следующего уровня и т. д.

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

Детализация модели требований

Цели данной деятельности:

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

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

реструктуризация модели требований;

детальное описание потоков событий для ВИ;

задание приоритетов ВИ.

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

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

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

Составление дополнительных спецификаций

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

Проектирование пользовательского интерфейса

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

программная реализация, воспроизводящая точный вид экранных окон;

альбом экранных форм;

модель навигации экранов в виде диаграмм классов с указанием атрибутов – полей и операций – кнопок.

Создание спецификации требований

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

Анализ и проектирование

Цель и задачи анализа и проектирования

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

К числу решаемых задач при этом относятся:

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

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

адаптация проекта системы к среде реализации с целью повышения производительности разработки;

выбор механизмов реализации и определение ограничений на реализацию;

разработка компонентной структуры;

распределение компонентов по узлам.

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

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

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

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

Разработчик БД – отвечает за проектирование базы данных ПС.

В процессе анализа и проектирования создаются следующие документы:

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

Документ «Архитектура ПС», в котором собраны различные архитектурные представления ПС.

Модель данных – это описание структуры данных, хранимых в БД (например, реляционная модель данных).

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

Рис.2 Диаграмма деятельностей, описывающая процесс анализа и проектирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цели процесса реализации

Основные цели процесса можно сформулировать следующим образом:

Определить структуру кода в виде уровней;

Реализовать компоненты, классы и объекты;

Провести блочное тестирование компонент;

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

В процесс реализации не включено тестирование всей ПС, для которого в RUP предусмотрен отдельный процесс (см. следующую статью).

Особенности процесса реализации

RUP предполагает поэлементную интеграцию в течение всего жизненного цикла. Это означает, что коды пишутся небольшими блоками, после чего они объединяются в единое целое путем постепенного добавления блоков. Это упрощает процесс локализации ошибок. Предусмотрено два уровня интеграции – интеграция результатов работы группы разработчиков в подсистему и интеграция подсистем в ПС. Интеграция происходит в каждой итерации в соответствии с планом итерации, где определены ВИ, которые проектируются и реализуются в этой итерации. Таким образом, план итерации определяет классы, которые будут реализованы в этой итерации.

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

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

Конструктор (кодировщик) разрабатывает компоненты и классы, выполняет блочное тестирование.

Системный интегратор выполняет интеграцию элементов в программные конструкции (систему и подсистемы).

Архитектор определяет структуру реализации (организацию уровней и подсистем).

Рецензент кода проверяет качество программного кода и его соответствие стандартам проекта.

Подсистема реализации — это набор компонент и других подсистем реализации, используемых для образования модели реализации. Это понятие позволяет иерархически представить модель реализации.

Компонент часть программного кода (см. статью «Компонентно-базированная разработка»).

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

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

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

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

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

Интеграция системы. Выполняется интеграция системы путем последовательного добавления в нее новых подсистем, созданных в рамках текущей итерации. Интеграция подсистемы завершается созданием набора программных конструкций подсистемы, каждая из которых тестируется по отдельности. Для тестирования системы в RUP предусмотрен отдельный процесс.

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

Цели процесса тестирования

Целью тестирования является оценка качества программного продукта путем

Проверки взаимодействия компонентов;

Проверки правильности интеграции компонентов;

Проверки точности реализации всех требований и выявления дефектов.

Особенности процесса тестирования в RUP

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


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

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

Тестировщик (испытатель) отвечает за выполнение системного тестирования. В его обязанности входит настройка и выполнение тестов, оценки выполнения теста, восстановление после ошибок, регистрация выявленных дефектов.

В процессе тестирования создаются следующие документы:

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

Похожие рефераты:

Тестирование — один из важнейших этапов проверки качества разработанного ПО.

Разработка и реализация автоматизированной информационной системы «Трехмерная печать», предназначенной для организации заказов в филиале на производство трехмерных моделей. Системный анализ и анализ требований. Модели проектирования и реализации.

Построение моделей деятельности предприятия. Разработка системного проекта в соответствии с требованиями заказчика. Разработка предложений по автоматизации предприятия, его технического проекта. Этап разработки, тестирования и внедрения проекта.

Особенности основных, вспомогательных и организационных процессов жизненного цикла автоматизированных информационных систем. Основные методологии проектирования АИС на основе CASE-технологий. Определение модели жизненного цикла программного продукта.

Анализ предметной области – концептуальная модель. Разработка спецификации архитектуры системы – переход от концептуальной модели к программной модели. Сетевое планирование – Кто? Когда? Сколько?.

Министерство образования РФ Воронежский Государственный Университет Факультет Компьютерных Наук Сравнительный анализ каскадной и спиральной моделей разработки программного обеспечения

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

Описание бизнес-процесса «Химчистка» в визуальной среде Visual Paradigm UML 2.0. Основные виды взаимодействия между актерами и вариантами использования. Составление диаграммы классов, последовательности, коммуникаций и состояний. Кодогенерация на Delphi.

Определение RAD, ее сущность и особенности, основные принципы и методики, назначение, история становления и развития. Причины популярности RAD на современном этапе, ее преимущества и отличительные черты, сферы применения и инструментальные средства.

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

Описание предметной области. Организация проекта.

Функционально-модульный и объектно-ориентированный подходы к разработке CASE-технологий, принцип алгоритмической декомпозиции с выделением функциональных элементов. Основные требования к блокам анализа, проектирования, реализации и инфраструктуры.

Основные элементы объектной модели. Сущность и преимущества объектно-ориентированного подхода, понятие объекта и класса. Унифицированный язык моделирования UML. Диаграммы классов и взаимодействия: назначение, построение и примеры использования.

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

Методология DATARUN. Инструментальное средство SE Companion.

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

Технология конструирования программного обеспечения, надежно и эффективно работающего в реальных компьютерах. Модель быстрой разработки приложений (Rapid Application Development) как один из примеров применения инкрементной стратегии конструирования.

Вопросы к дисциплине: Стандартизация и проектирование программных средств. Понятие программы и программного обеспечения. Две роли программного обеспечения.

Внешние сущности. Системы и подсистемы. Накопители данных. Построение иерархии диаграмм потоков данных.

Анализ предметной области: порядок медицинского обследования донора крови и ее компонентов. Описание документооборота и обработки информации в стандарте DFD. Разработка смешанной модели описания процесса на основе стандартов IDEFO, DFD и IDEF3.

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

Исторически большинство консалтинговых фирм основывали свои подходы к реинжинирингу, исходя из CASE-технологии разработки информационных систем, таких известных компаний, как Gemini Consulting с методологией Construct и Andersen Consulting с ее Eagle. Методологии обеих компаний ориентированы на -профессионалов и направлены на разработку поддерживающих информационных систем.

Однако в проведении процесса реинжиниринга участвуют специалисты как минимум двух типов – профессионалы в области реконструируемого бизнеса и разработчики ИС.

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

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

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

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

При введении процессного управления параллельные внедрения систем автоматизации становятся не просто данью моде, но жизненно необходимой составной частью. Лидерами рынка программных средств для моделирования и интеграции деятельности предприятия являются ARIS ToolSet компании IDS Scheer AG и Ataffware одноименной компании, которые являются также и законодателями мод в этой области. К примеру, ARIS ToolSet – многопользовательская среда описания и анализов бизнес-процессов компании, поддерживающая разработку сложных гетерогенных рабочих систем и сопровождает всю цепочку «анализ – проектирование – реализация». С применением таких средств значительно сокращается длительность этапа проектирования при гарантированно высоком уровне проектных решений. Система в первую очередь предназначена для специалистов, которые анализируют и оптимизируют рабочие процессы на предприятиях.

Сегодня конкурентоспособность компании в значительной степени зависит от возможности преобразования основных процессов предприятия в поддержку стратегических инициатив, способных удовлетворить требования заказчика. Более того, не так давно в обиход вошел термин «экс-инжиниринг». Его суть заключается в расширенной перестройке бизнес-процессов, выходящей за корпоративные рамки. Несмотря на то, что большинство компаний чаще всего не успевает завершить реинжиниринг бизнес-процессов, следующим способом улучшения их работы выбирается всеобъемлющая перестройка процессов. К тому же под влиянием Интернета все чаще возникает идея виртуальных, не имеющих границ компаний, и это тоже подразумевает некий уровень готовности, к которому можно прийти при помощи экс-инжиниринга. Однако внедрение инженерных технологий не способно полностью решить проблему, а потому для построения клиентоориентированной системы с высоким уровнем адаптивности на первый план необходимо вывести построение межкорпоративных и внутриорганизационных коммуникаций, техническая часть которых действительно опирается на процессный подход и достижения в области IТ.

Контрольные вопросы

47. Дайте понятие инжиниринга бизнеса.

48. Каково соотношение инжиниринга и реинжиниринга?

49. Сформулируйтеусловия успешного реинжиниринга.

50. В чем смысл перехода к проектному подходу от функционального?

51. Каковы объекты реинжиниринга (фирмы и процессы)?

52. Перечислите факторы успеха применения метода реинжиниринга.

53. Каковы типичные ошибки при проведении реинжиниринга?

54. Каково место реинжиниринга в инновационной деятельности?

55. В чем заключается сущность процесса непрерывного совершенствования?

56. Объясните сущность бизнес-процессов?

57. В чем заключается процесс корректировка бизнес-процессов?

58. Каково место реинжиниринга в производственной деятельности предприятия?

59. Какие принципы перепроектирования бизнес-процессов Вы знаете? В чем их сущность?

60. Какие виды программного обеспечения Вы знаете, и с какой целью они применяются?

| следующая лекция ==>
Принципы перепроектирования бизнес-процессов | Сущность инновационного менеджмента

Дата добавления: 2020-06-02 ; просмотров: 429 ; ЗАКАЗАТЬ НАПИСАНИЕ РАБОТЫ

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

Основной задачей повторный анализ фазы масштаб существующих систем, архитектура, внешние функции, внутренние алгоритмы, сложность и так далее исследование и анализ. Предварительный анализ этого этапа является наиболее прямым исследования и прогнозирования целей реинжиниринга сферы. Пекинский университет Software Engineering Institute разработали «вспомогательное исследование программного обеспечения реинжиниринга инструмент — SFRE» Именно из целого для поддержки анализа фазы реинжиниринга инструменты автоматизации. Software Engineering экономики повторного использования является одним из наиболее важных принципов, повторного использования больше, тем ниже стоимость реинжиниринга, обратное проектирование, повторный анализ фазу, так что наиболее важной задачей является найти объекты многократного использования и повторного использования стратегии, и в конечном счете определяют реинжиниринг задач и нагрузки будет зависеть от объема повторно используемых объектов (повторное использование) и повторное использование стратегии.

С другой проект, а затем окончательного инженерного анализа представленных масштабов и стратегии повторного повторное использование будет решаться инженерных и реинжиниринг успеха продукта уровень ключевых факторов поддержку системы. Если вы использовать существующий код уровня объектов, конечно, идеал, однако ограниченные возможности. Однако анализ повторно инженерии повторно, если отказали, что «реформа других, как свои собственные переписать код», он сделал реинжиниринг табу. Так долго, чтобы запустить существующей системы, по крайней мере, значение и срок действия метод работы был принят пользователем. И тогда мудрый программист без аутентификации пользователя перед периодом использованием, чтобы убедиться, что их программы не являются правильными; не говоря уже о более более опытные программисты знают, частичные изменения в статусе программы переписать оригинальные программы, чем гораздо более сложный проект, потому что ему нужно соответствующие бесчисленные «побочных эффектов», называется «потрогать сухожилие в целом.» Таким образом, читать документ — даже «ветхое», чтение кода — даже «катастрофическим», но и держаться, и который показан вне повторно используемых объектов.

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

В общем, чем дольше тест процесса реорганизации нагрузка самая большая работа. Если вы можете использовать существующие тесты и результаты, смогут значительно снизить стоимость реинжиниринга. Для многоразовых частей, особенно многоразовых (независимость сильнее) местные системы, вы можете также отказаться тест, который является повторное использование технологии настоятельно реинжиниринга является одной из основных причин. Конечно, после реорганизации системы постоянно изменяется и увеличение части по всему спектру пострадавших должны быть проверены без пропусков, не оставляйте все на волю случая, с тем чтобы избежать «сто мух плохой суп.»

Практические стратегии повторного использования

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

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

● Интерфейс повторное использование стратегии

Аналоговый интерфейс будет основан на старой версии на новый интерфейс, пакет графического интерфейса. Старый интерфейс работает на терминале, новый интерфейс может быть на базе ПК графический интерфейс, его можно запустить в браузере на HTML-странице. Новый пользовательский интерфейс с помощью единого интерфейса инструмента моделирования общайтесь со старым интерфейсом. Этот показатель повторного использования метода очень высока. Но не изменяет существующую систему в то время как структурные недостатки старой системы все унаследованные.

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

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

● Logic слой упаковки принципы

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

● Уровень данных повторного использования стратегии

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

Программное обеспечение реорганизации, который разделен на две части

: Программное обеспечение реинжиниринга из двух частей: во-первых, обратный процесс: дизайн происходит от кода начинает или спецификации (понятность), во-вторых, для улучшения качества программного обеспечения статической (ремонтопригодность, возможность многократного использования, или evolvability).

Почему реализации программы реинжиниринга

(1) Реорганизация программное обеспечение может помочь организациям снизить риск эволюции программного обеспечения

(2) Реорганизация инвестиций в программное обеспечение может помочь организациям компенсации

(3) Реорганизация может сделать программу простой для дальнейшего изменения

(4) Программное обеспечение реинжиниринга имеет широкий рынок

(5) способность к расширению реинжиниринг чемоданчике набор (например: Aidedsoft)

(6) Реорганизация является содействие развитию энергетической автоматическое поддержание программного обеспечения

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

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

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

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

  • по разработке новых ИС и их интеграции с существующими ИС;
  • по разработке новых ИС с целью замены существующих ИС;
  • по модернизации (наращиванию функциональности, развитию) существующих ИС.

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

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

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

Сегодня в мире существует большое количество подходов, методов и технологических решений, напрямую или косвенно соотносимых с деятельностью по реинжинирингу ИС. Однако они не интегрированы на уровне методологий (процессов разработки). Как результат, можно наблюдать наличие огромного количества методологий, где основной акцент сделан на разработку ИС «с нуля», и практическое отсутствие «стройных» методологий, целью создания которых являлось бы комплексное, целостное решение задач реинжиниринга ИС.

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

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

  • http://www.informatik.uni-stuttgart.de/ifi/ps/reengineering/
  • http://www.iam.unibe.ch/
  • http://www.stsc.hill.af.mil/reng/
  • http://www.sei.cmu.edu/reengineering/index.html
  • http://www.tcse.org/revengr/

2. Понятие «реинжиниринга ИС», его содержание и место в ЖЦ ИС.

2.1. Понятие «реинжиниринга ИС».

Сразу следует признать, что в настоящий момент понятие «реинжиниринг ИС» не является повсеместно устоявшимся. Как следствие довольно часто возникает определенная терминологическая путаница. Авторами исследуются одни и те же проблемы, подходы, методы и технологии их решения, однако в качестве базовых понятий, наряду с «реинжинирингом ИС» [1, 9, 16, 20] употребляются «эволюция ИС» [10, 13], «миграция ИС» [15], «модернизация ИС» [2], «реструктуризация ИС» [5].

Нельзя отрицать, что деятельность по миграции ИС имеет определенную специфику (окраску) по отношению к деятельности по модернизации ИС. Однако, принимая во внимание определение реинжиниринга ИС, приводимое в [1]:

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

становится очевидным, что и миграция, и модернизация ИС являются частью деятельности по реинжинирингу ИС. Как результат, подходы, методы и технологии миграции, модернизации, эволюции ИС, следует считать частью методологического и инструментально — технологического обеспечения процесса реинжиниринга ИС.

Такой взгляд на реинжиниринг ИС согласуется с таксономией, вводимой в ряде работ [34, 36, 38-40]. В этих работах авторами делается попытка выстроить систему понятий, соотносимых с данным видом деятельности. Так, в [38] реинжиниринг ИС определяется как «исследование (изучение, обследование) и перестройка исходной системы с целью ее воссоздания в новой форме с последующей реализацией этой новой формы [1] . Далее, в контексте деятельности по реинжинирингу вводятся и определяются такие важные понятия, как

  • прямой инжиниринг (Forward engineering);
  • редокументирование (Redocumentation);
  • рефакторинг (Refactoring);
  • реструктуризация (Restructuring);
  • переориентация (Retargeting);
  • обратный инжиниринг (обратное проектирование) (Reverse engineering);
  • сопровождение программных продуктов (Software maintenance);
  • трансляция исходного кода (Source Code Translation);
  • и т.д.

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

2.2. Основное содержание реинжиниринга ИС и его место в ЖЦ ИС.

Следующим шагом на пути исследования подходов, методов и технологий реинжиниринга ИС следует считать определение основного содержания деятельности по реинжинирингу ИС, места реинжиниринга в ЖЦ ИС.


Так, в [1] авторы придерживаются следующей позиции при определении границ деятельности по реинжинирингу, и, как следствие, места реинжиниринга в ЖЦ ИС.

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

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

В контексте исследований, связанных с эволюцией ИС, авторами выделяются деятельности по сопровождению, модернизации и замещению ИС.

Илон Маск рекомендует:  Запуск программы

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

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

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

Определяя место этих видов деятельности в контексте ЖЦ ИС, авторы рассматривают следующую последовательность их выполнения (см Рис. 1).

Рис. 1 Жизненный цикл ИС.

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

Приводимые в [2] виды деятельности основаны на таксономии, вводимой в [16]. В отличие от предыдущей работы, в [16] в качестве базового понятия используется именно «реинжиниринг», а вводимая таксономия рассматривается как множество видов деятельности, соотносимых с реинжинирингом ИС. При этом применительно к унаследованным ИС выделяются соответственно деятельности по их оценке, сопровождению, трансформации, замещению, а так же смешанные стратегии, предусматривающие совместное выполнение перечисленных ранее видов деятельности.

Обеспечивая концептуальное понимание процесса реинжиниринга ИС, в ряде работ [1, 9] определяются основные виды деятельности (фазы) соотносимые с этим процессом.

Так, в [1] рассматриваются следующие основные фазы:

  • оценки показателей проекта по реинжинирингу, в том числе характеристик унаследованной информационной системы (фаза оценки);
  • анализа решений по реинжинирингу, в том числе принятие решения о необходимости проведения работ по реинжинирингу или сопровождению/разработке ИС;
  • осуществления реинжиниринга (выполнения работ по реинжинирингу);
  • внедрения системы, трансформированной в результате проведения реинжиниринга.

Другой подход к определению деятельности по реинжинирингу базируется на так называемой модели «подковы» [9, 21].

В основу данной модели положены следующие процессы (виды деятельности), соотносимые с реинжинирингом ИС:

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

Эти три основных процесса соединяются в модели в виде «подковы» (см Рис. 2).

Рис.2 Модель «подковы».

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

Второй процесс (Architecture Transformation) заключается в трансформации (реинжиниринге) восстановленной архитектуры к желаемой новой архитектуре. Полученная в результате трансформации новая архитектура оценивается с позиции ее качества с учетом накладываемых на нее организационных и экономических ограничений.

И, наконец, третий процесс (Architecture-based Development) включает деятельность по разработке системы, соответствующей новой архитектуре. Здесь решаются вопросы декомпозиции элементов системы по пакетам, осуществляется выбор стратегий взаимодействия элементов/компонентов системы. В рамках данного процесса так же обеспечивается интеграция в новую систему артефактов унаследованной системы, например, посредством переписывания части унаследованного кода и/или применения технологии построения оболочек для компонентов унаследованной системы.

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

Представление на уровне структуры кода (Code-Structure Representation) включает программный код, а так же такие артефакты, как абстрактные синтаксические деревья и графы потоков (flow graphs), получаемые на основании выполнения различного рода аналитических операций (например, разбора кода). Текстуальный перевод, а так же перевод на основе синтаксических деревьев являются примерами трансформации системы на этом уровне.

В отличие от предыдущего уровня, представление на уровне функциональности системы (Function-Level Representation) предусматривает определение связей между функциями программ (например, последовательности вызовов), данными (как частный случай, связей между сущностями данных, соотношений данных и функций) и файлами (к примеру, распределение функций и данных по файлам). Трансформация системы на данном уровне осуществляется на основании пересмотра функциональности системы и заключается, например, в переходе от функционального подхода к объектному подходу к анализу и проектированию, в переходе от реляционной БД к объектной БД.

На архитектурном уровне артефакты предыдущих уровней, объединяются в подсистемы в терминах архитектурных компонентов архитектуры ИС. Трансформация системы на этом уровне предусматривает коренные изменения в структуре программы, в том числе в части применения основных образцов взаимодействия компонентов: типов программных компонентов, используемых соединителей (connectors), вариантов декомпозиции функциональности, образцов управления и обмена данными времени выполнения.

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

Следует признать, что модель «подкова» находит широкое применение в рамках деятельности, связанной с реинжинирингом ИС. Так, в [20] на ее основе определяются требования и основной каркас для интеграции инструментальных средств реинжиниринга на архитектурном уровне и уровне программного кода. С учетом соотносимых с ней процессов и уровней представления, осуществляется расширение модели CORUM (Common Object-based Reengineering Unified Model). Эта модель, в свою очередь, разрабатывалась:

  • для представления требуемой для систем управления на основе программного кода (Code-based Management System) информации о программных средствах;
  • для обеспечения интероперабельности между системами данного класса (в том числе между средствами реинжиниринга программ на уровне программного кода).

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

Подход, предложенный в [34-36], очень близок к подходу, основанному на модели «подкова». Характеризуя жизненный цикл реинжиниринга ИС, авторы определяют следующие шаги процесса реинжиниринга:

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

В отличие от предыдущих работ, в [10, 13] деятельность по реинжинирингу рассматривается в качестве одной из форм деятельности по эволюции унаследованных ИС, когда, требуется более сильнодействующее «лекарство» для «лечения» ИС, нежели серия локальных инкрементальных изменений [13].

Так, в [13] описывается каркас (enterprise framework), характеризующий:

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

Авторами подчеркивается, что помимо технических вопросов, связанных с эволюцией унаследованных ИС, существует так же множество организационных вопросов. Например, «Как планировать эволюцию большой сложной системы, включая ее реинжиниринг?», «Какие существуют критичные факторы успеха эволюции системы?», «Как оценить, что люди, осуществляющие эволюцию системы, на правильном пути?». Кроме этого, важным является необходимость учета стратегических, организационных, и других аспектов бизнеса, влияющих на эволюцию унаследованной ИС.

Поэтому основной целью создания каркаса (enterprise framework) следует считать необходимость оценки среды, в рамках которой осуществляется эволюция унаследованной ИС, необходимость обеспечения понимания широкого спектра вопросов, как технического, так и управленческого характера, которые соотносятся с эволюцией унаследованных ИС. Важнейшим здесь становится выявление факторов, определяющих успех деятельности по эволюции ИС, а так же разработка согласованного множества технических и управленческих инструкций (действий), требуемых для эффективного планирования, оценки и управления инициативами по эволюции систем.

Отражая применительно к эволюции системы пространство проблем и пространство решений, предлагаемый в [13] каркас включает такие элементы, как организация, проект, унаследованная система, инженерия систем и программных средств, технологии, целевая система. Между этими элементами определяется связь. При этом для каждого из них приводится список вопросов (checklists), позволяющий охарактеризовать (исследовать и оценить) интересующий элемент.

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

  • исследование и анализ пространства проблем и пространства решений в контексте инициатив по эволюции системы;
  • разработка руководств по составлению стратегических и тактических планов по реинжинирингу унаследованных систем;
  • выявление технологических вопросов и потенциальных проблем на протяжении всего пути по эволюции систем;
  • рецензирование планов, ранжирование (приоритезация) технических вопросов, разработка рекомендаций по улучшениям процессов эволюции систем и результатов их выполнения (рабочих продуктов).

Общий подход к использованию каркаса представлен на Рис. 3.

Рис. 3 Общий подход к использованию каркаса.

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

В [10] авторами предлагается комплексный, основанный на рассмотренном ранее каркасе, подход к эволюции систем, который определяется в контексте унаследованных систем и современных программных технологий.

В основу подхода положены следующие положения (принципы):

  • различие между эволюцией систем и сопровождением программных средств;
  • использование описанного ранее каркаса (enterprise framework) при поддержке принятия решений в процессе эволюции системы;
  • достижение технического понимания систем на высоком уровне абстракции;
  • применение технологий распределенных объектов, технологии «wrapping» [10] для эволюции системы;
  • применение «net-centric» [10] вычислений для эволюции системы.

Определяя различие между сопровождением программных средств и эволюцией систем в части реинжиниринга ИС, авторы рассматривают сопровождение как «мелкозернистую», «краткосрочную» деятельность, направленную на планирование и внесение локализованных изменений. При сопровождении структура (архитектура) системы остается относительно неизменной, а требуемая «порция» вносимых за определенный промежуток изменений, как правило, связана с изменением какого-либо одного требования к системе. Такие изменения, обычно, не сопровождаются существенным изменением значений характеристик и атрибутов качества программных средств.

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

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

В отличие от рассмотренных ранее работ, в [15] основное внимание уделяется исследованию и решению технических проблем, связанных с миграцией унаследованных систем. Характеризуя понятие «миграция ИС» в данной работе выделяются отдельно эволюция, сопровождение и миграция ИС. Основываясь на том факте, что объектом эволюции и сопровождения является унаследованная ИС, а объектом миграции как унаследованная, так и новая (целевая) системы, авторы разделяют миграцию и другие процессы ЖЦ ИС. При этом миграция рассматривается как деятельность, которая начинается с унаследованной ИС и заканчивается сопоставимой целевой ИС.

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

  • анализ унаследованной ИС;
  • декомпозиция структуры унаследованной ИС;
  • проектирование интерфейсов (пользовательских и системных) целевой системы;
  • проектирование приложений (функциональной логики) целевой системы;
  • проектирование базы данных целевой системы;
  • развертывание среды, требуемой для эксплуатации и сопровождения целевой системы;
  • создание и развертывание необходимых шлюзов;
  • миграция унаследованных данных;
  • миграция унаследованных приложений (компонентов, реализующих функциональную логику);
  • миграция унаследованных интерфейсов (пользовательских и системных);
  • переход к использованию целевой системы.

3. Классификация подходов, методов и технологий.

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

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

  • понятие «реинжиниринг ИС» различными исследователями до сих пор трактуется по разному, существует множество близких понятий, наличие которых приводит к появлению внешне отличающихся, но по сути схожих подходов, методов и технологий;
  • предлагаемые решения не позиционируются в контексте других существующих решений;
  • решения не интегрированы на уровне методологий и технологий, большое количество методов и инструментальных средств направлено на решение отдельных локальных задач, связанных с реинжинирингом ИС;
  • наблюдается разрыв между решениями концептуального характера и решениями, направленными на решение конкретных прикладных задач.

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

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

Так, классифицируя существующие подходы, методы и технологии, можно выделить следующие уровни рассмотрения и исследования аспектов, соотносимых с деятельностью по реинжинирингу ИС (см Рис. 4).

Рис 4. Уровни рассмотрения и исследования аспектов, соотносимых с реинжинирингом ИС.

Первый уровень включает исследования, направленные на достижение концептуального понимания деятельности по реинжинирингу ИС. Именно на этом уровне исследуются вопросы адекватного определения понятия «реинжиниринг ИС», определения места реинжиниринга в жизненном цикле (ЖЦ) ИС, в том числе выявление связей процесса реинжиниринга ИС в целом с другими процессами ЖЦ ИС. Следует считать, что большая часть рассмотренных ранее аспектов, относятся к этому уровню.

В отличие от первого, второй уровень содержит исследования, основная цель которых заключается в выявлении основных шагов (действий), реализуемых в процессе реинжиниринга и в определении связей между основными шагами процесса. Здесь в сферу рассмотрения попадают потоки управления и потоки данных между основными шагами процесса, основные роли, соотносимые с исполнителями процесса, а так же правила распределения ролей среди команды исполнителей. Исследования и разработки на этом уровне проводятся как без учета, так и с учетом вводимых ограничений (например, архитектурных решений, которым должны соответствовать подлежащие реинжинирингу ИС). Следует признать, что наиболее детально вопросы, связанные с данной проблематикой, исследуются в [1, 15, 33], в меньшей степени в [8, 13, 16, 20] Так, в [1] выделяются основные фазы процесса реинжиниринга ИС, а для каждой фазы определяются действия (деятельности) и соотносимые с ними потоки управления. Процесс дается в самом общем виде и не зависит от каких-либо ограничений, например используемых программных технологий. В [15] авторами так же определяется выполняемый в рамках процесса реинжиниринга поток работ. Однако здесь основное внимание уделяется вопросам технического характера, а выполняемые при реинжиниринге шаги предусматривают декомпозицию структур, соответственно, унаследованной и целевой системы на компоненты пользовательского интерфейса, компоненты – приложения и компоненты управления базами данных. В отличие от предыдущих работ в [33] авторами основной акцент сделан на решение задач оценки унаследованных систем и поддержки принятия решений при реинжиниринге ИС. Авторами определяется процесс оценки, состоящий из следующих входящих в его состав процессов (подпроцессов):

  • технической оценки (Reengineering Technical Assessment),
  • экономической оценки (Reengineering Economic Assessment),
  • принятия управленческих решений (Reengineering Management Decision).

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

Еще одним примером процесса, направленного на решение локальной задачи, является итеративный процесс, определяющий следующую последовательность шагов, которые должны быть выполнены при планировании проектов реинжиниринга ИС [37]:

  • Определение целей, направлений деятельности организации и информационной системы.
  • Формирование объединенной команды, которая будет осуществлять реинжиниринг унаследованной системы.
  • Определение среды разработки и сопровождения, базирующейся на применении CMM (Capability Maturity Model).
  • Выбор стандартного множества метрик для оценки программных средств.
  • Анализ унаследованной системы.
  • Определение процесса реализации деятельности по реинжинирингу.
  • Разработка/Обновление стандартных средств тестирования и валидации.
  • Анализ средств реинжиниринга.
  • Обучение.

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

С некоторой условностью все методы реинжиниринга ИС можно разделить на два класса.

Методы, относящиеся к первому классу, определены на концептуальном уровне и в целом не зависят от какой-то одной программной технологии. Так, в [2] дается обзор методов модернизации и миграции унаследованных систем. Среди всего множества рассматриваемых методов к первому классу относятся метод репликации баз данных и основанный на объектно-ориентированном подходе метод построения оболочек для компонентов унаследованной системы (object – oriented wrapping), методы «белого» и «черного» ящика модернизации системы. Другими представителями данного класса являются: методы оценки вариантов реинжиниринга ИС [9, 11, 33], метод планирования миграции программных средств [8], методы извлечения знаний о существующей системе [3, 4, 17], методы трансформации (реконструкции) архитектуры ИС [3, 7, 19, 21], методы автоматизации реинжиниринга программ [6, 23] и т.д. В целом следует считать, что область применения таких методов, как правило, характеризуется некоторым классом программных технологий. А для применения в реальных проектах каждый из них адаптируется с учетом используемых в проекте технологий и инструментальных средств.

Отдельным направлением исследований, относящимся к данному классу и получившим развитие в последние годы, является исследование и разработка образцов реинжиниринга ИС [26-30, 36]. Каждый из образцов реинжиниринга ИС нацелен на решение некоторой типовой задачи (проблемы), которая сопровождает деятельность по реинжинирингу ИС. Не смотря на некоторые отличия, авторы в целом придерживаются единого подхода к описанию таких образцов. Так, в [26] определяется следующий шаблон описания.

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

Стоит заметить, что хотя последний из разделов шаблона «привязывает» шаблон к определенной среде реализации, языкам программирования, все же каждый из образцов представляет некоторое концептуальное решение проблемы. Подробную информацию об образцах реинжиниринга можно найти в книге «Object-Oriented Reengineering Patterns» [27].

В отличие от первого класса, методы второго изначально ориентированы на использование определенных программных технологий. Ко второму классу относятся так же адаптации методов из первого класса. Здесь методы в наибольшей степени приспособлены к их непосредственному (прямому) применению в конкретных проектах. Примерами методов данного класса следует считать [2]: методы интеграции с использованием CGI, методы интеграции на основе технологии XML, метод построения оболочек для компонентов унаследованной системы с использованием технологии CORBA.

И наконец, четвертый уровень включает исследование и разработку инструментальных программных средств, автоматизирующих применение подходов, методов и технологий, рассматриваемых на предыдущих уровнях. Следует признать, что в настоящий момент таких средств существует большое количество, среди которого выделяются средства [3, 4, 6, 23, 31, 32, 35]:

  • переноса приложений написанных на устаревших языках на современные языки и платформы (например, с языков PL/1, Кобол на языки C++, Java, Visual Basic);
  • средства интеграции унаследованных приложений, к примеру, на основе метода построения оболочек для компонентов унаследованной системы;
  • средства автоматизированного извлечения данных из унаследованных систем;
  • средства автоматизированного извлечения знаний об унаследованных системах;
  • средства оптимизации (реструктуризации) унаследованных систем при их переносе на современные языки и платформы (как на уровне программного кода, так и на уровне архитектуры ИС);
  • различные средства анализа программного кода.

Полезная классификация инструментальных средств дается в [31]. В рамках этой классификации выделяются такие типы средств, как

  • реинжиниринга бизнес процессов;
  • преобразования имен данных;
  • реинжиниринга данных (БД);
  • прямого инжиниринга;
  • преобразования форматов;
  • реструктуризации;
  • обратного проектирования;
  • трансляции исходного кода;
  • и др.

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

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

Следует признать, в процессе проводимых авторами настоящей статьи исследований не было обнаружено целостных методологий и технологий реинжиниринга ИС, соответствующих уровню проработки и области охвата RUP [24, 25]. В наибольшей степени эту проблема исследуется в [1, 8, 15, 33]. В тоже время, в [1] предлагается лишь каркас, определяющий основной ход работ, в [8] даются рекомендации по выполнению основных видов деятельности по реинжинирингу. В [33] определяются лишь процессы оценки унаследованных систем, а в [15] основное внимание уделяется вопросам технического характера, при этом основной акцент сделан на решение проблем интеграции систем, в то время как методы анализа унаследованной системы практически не рассматриваются.

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

  • оценку состояния в области методологического и технологического обеспечения реинжиниринга ИС;
  • адаптацию и разработку методологий и технологий реинжиниринга ИС.

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

  • по объектам применения (например, в зависимости от их типа (компонент пользовательского интерфейса, компонент данных, вычисляющий компонент (компонент бизнес — логики)));
  • по видам деятельности процесса реинжиниринга (методы извлечения знаний о существующих ИС (методы обратного проектирования), методы оценки (анализа) существующих ИС и т.д.).

4. Заключение.

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

Так, несмотря на наличие большого количества работ, охватывающих данную проблематику с различных точек зрения, следует признать, что:

  • понятие «реинжиниринг ИС» различными исследователями до сих пор трактуется по разному, существует множество близких понятий, наличие которых приводит к появлению внешне отличающихся, но по сути схожих подходов, методов и технологий;
  • существующие методы и технологии не позиционируются в контексте других существующих решений, не интегрированы на уровне методологий и технологий;
  • наблюдается разрыв между решениями концептуального характера и решениями, направленными на решение конкретных прикладных задач;
  • отсутствует четкая взаимосвязь между методами/технологиями реинжиниринга и методологиями разработки ИС «с нуля».

В сложившейся ситуации актуальной задачами становятся:

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

5. Литература.

  1. John Bergey, William Hefley, Walter Lamia, Dennis Smith A Reengineering Process Framework, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, 1995.
  2. Santiago Comella-Dorda, Kurt Wallnau, Robert C. Seacord, John Robert A Survey of Legacy System Modernization Approaches, Software Engineering Institute (Technical Note CMU/SEI-200-TN-003, 00tn003.pdf), Pittsburgh, 2000.
  3. Rick Kazman, S. Jeromy Carriere Playing Detective: Reconstructing Software Architecture from Available Evidence. Technical Report CMU/SEI-97-TR-010. Pittsburgh, 1997.
  4. Rick Kazman, S. Jeromy Carriere View Extraction and View Fusion in Architectural Understanding, Proceedings of the Fifth International Conference on Software Reuse (ICSR), June, 1998, Victoria, BC.
  5. Кротов А.А. и Лупян Е.А. Обзор методов реструктуризации и интеграции информационных систем, http://d902.iki.rssi.ru/students/alekro/Dissertation/Papers/Reengineering/my_review.html
  6. «Автоматизированный реинжиниринг программ» Сборник статей под ред. А.Н.Терехова и А.А.Терехова Издательство С.-Петербургского университета, 2000.
  7. Guo G. Y., Atlee J. M., Kazman R. A Software Architecture Reconstruction Method, Department of Computer Science, University of Waterloo, Software Engineering Institute, Carnegie Mellon University.
  8. John Bergey, Dennis Smith, Nelson Weiderman DoD Legacy System Migration Guidelines, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, September 1999.
  9. John Bergey, Dennis Smith, Nelson Weiderman, Steven Woods Options Analysis for Reengineering (OAR): Issues and Conceptual Approach, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, September 1999.

  10. Weiderman N., Nelson H., Bergey John K., Smith Denis B., & Tilley Scott R. Approaches to Legacy System Evolution, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA 15213, 1997 (CMU/SEI-97-TR-014)
  11. Ransom J., Sommerville I., & Warren I. A Method for Assessing Legacy Systems for Evolution, Proceedings of the Second Euromicro Conference on Software Maintenance and Reengineering (CSMR98), 1998
  12. Bisdal Jesus, Lawless Deirdre, Wu Bing, Grimson Jane, Wade Vincent, Richardson Ray, & O’Sullivan D. An Overview of Legacy Information System Migration, APSEC 97, ICSC 97, 1997
  13. John K. Bergey, Linda M. Northrop, Dennis B. Smith Enterprise Framework for the Disciplined Evolution of Legacy Systems, SEI CMU October 1997.
  14. Энн Мак-Крори Что такое унаследованные системы?, Computerworld, США, 1998.
  15. Michael L. Brodie, Michael Stonebraker Migrating Legacy Systems. Gateways, Interfaces & The Incremental Approach, Morgan Kaufmann Publishers, Inc., 1995
  16. Weiderman N., Northrop L., Smith D., Tilley S., Wallnau K. Implications of Distributed Object Technology for Reengineering, CMU/SEI-97-TR-005, SEI CMU June 1997.
  17. Tilley S. A Reverse-Engineering Environment Framework, SEI CMU April 1998
  18. Bergey J., Smith D., Tilley S., Weiderman N., Woods S. Why Reengineering Projects Fail, SEI CMU April 1999.
  19. Kazman R., O’Brein L., Verhoef Ch. Architecture Reconstruction Cuidelines, SEI CMU August 2001.
  20. Kazman R., Woods S., Carriere S. Requirements for Integrating Software Architecture and Reengineering Models: CORUM II, SEI CMU, October 1998.
  21. Carriere S.J., Woods S. Kazman R. Software Architectural Transformation, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, October 1999.
  22. John Bergey, Dennis Smith, Nelson Weiderman DoD Software Migration Planning, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, August 2001.
  23. www.ispras.ru
  24. Kruchten P. The Rational Unified Process: an introduction. Reading: Addison Wesley, 1999.
  25. Rational Unified Process, version 2002.05.00.25, Rational Software Corporation.
  26. Ducasse S., Richner Т, Nebbe R. Type-Check Elimination: Two Object-Oriented Reengineering Patterns, Proceedings WCRE, 1999.
  27. Demeyer S., Ducasse S. , Nierstrasz O. Object-Oriented Reengineering Patterns, Morgan Kaufmann Publishers, Inc., 2002.
  28. Ducasse S. , Demeyer S., Nierstrasz O. A Pattern Language for Reverse Engineering, Proceedings of EuroPLoP, 2000.
  29. Pooley R., Stivens P. Software Reengineering Patterns, University of Edinburg, Department of computer science, http://www.reengineering.ed.ac.uk/.
  30. Dewar R. Characteristics of Legacy System Reengineering, The University of Edinburgh, Division of Informatics, http://www.reengineering.ed.ac.uk/.
  31. Olsem M. R., Sittenauer Ch. Reengineering, Software Technology Support Center, Technology Report, Volume 2, April 1995, http://www.stsc.hill.af.mil/reng/.
  32. Ducasse S., Lanza M, Tichelaar S. The Moose Reengineering Environment, University of Berne, Software Composition Group, 2001.
  33. Software Reengineering Assessment Handbook, Technical Report, Version 3.0, 1997, http://www.stsc.hill.af.mil/
  34. Sander T. Modeling Object-Oriented Software for Reverse Engineering and Refactoring, Thesis, University of Bern, 2001.
  35. Ducasse S. Rґetro-Conception d’Application `a Objets Reengineering Object-Oriented Applications, Universitґe Pierre et Marie Curie, 2001.
  36. The FAMOOS Object-Oriented Reengineering Handbook, http://www.iam.unibe.ch/_famoos/handbook/.
  37. Olsem M. R., Sittenauer Ch. Reengineering, Software Technology Support Center, Technology Report, Volume 1, April 1995, http://www.stsc.hill.af.mil/reng/.
  38. IEEE Computer Society TCSE, 1990, http://tcse.org/.
  39. Стандарт ANSI/IEEE Std. 729-1983.
  40. Joint Logistic Commanders Computer Resources Management group (JLC/CRM), 1992, http://www.stsc.hill.af.mil/reng/.

6. Приложение А. Глоссарий понятий и терминов.

[1] Далее в настоящей работе при исследовании существующих решений употребляется оригинальная терминология, предлагаемая авторами работ. При этом в качестве рабочего варианта используется определение реинжиниринга ИС, приводимое в [1].

Реинжиниринг: сущность и методология

Современные предприятия в значительной мере все еще базируются на принципах, сформулированных Адамом Смитом в его фундаментальном труде «Благосостояние наций», опубликованном в 1776 г. Производственный процесс он предлагал разбить на элементарные, простые задания (работы), чтобы каждое из них мог выполнять один рабочий; при этом от рабочего не требовалось высокой квалификации и умения выполнять работу в целом, достаточно, чтобы он специализировался на одном или нескольких простейших заданиях. Это легко реализуемая идея, в связи с чем предложенные принципы были и остаются весьма успешными в массовом производстве типовой продукции, выполняемой силами большой армии неквалифицированных рабочих, использующих простое оборудование.

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

Мир, в котором живут современные предприниматели, за последние 10 лет существенно изменился.

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

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

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

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

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

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

Понятие «реинжиниринг бизнеса»

Инжиниринг бизнеса — это набор приемов и методов, которые компания использует для проектирования бизнеса в соответствии со своими целями.

Реинжиниринг — это фундаментальное переосмысление и радикальное перепроектирование деловых процессов для достижения резких, скачкообразных улучшений главных современных показателей деятельности компании, таких, как стоимость, качество, сервис и темпы (термин «реинжиниринг» ввел М. Хаммер).

Это определение содержит четыре ключевых слова: «фундаментальный», «радикальный», «резкий (скачкообразный)» и «процесс» (наиболее важное слово).

Фундаментальный. На начальной стадии реинжиниринга необходимо ответить на такие основные вопросы:

  • почему компания делает то, что она делает?
  • почему компания делает это таким способом?
  • какой хочет стать компания?

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

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

Резкий (скачкообразный). Реинжиниринг не применяется в тех случаях, когда необходимо улучшение либо увеличение показателей деятельности компании на 10–100%, а используются более традиционные методы (от произнесения зажигательных речей перед сотрудниками до проведения программ повышения качества), применение которых не сопряжено со значительным риском. Реинжиниринг целесообразен только в тех случаях, когда требуется достичь резкого (скачкообразного) улучшения показателей деятельности компании (500–1000% и более) путем замены старых методов управлении новыми.

Различия между совершенствованием и реинжинирингом бизнеса представлены в таблице.

Сравнительная характеристика совершенствования и реинжиниринга бизнеса

Параметр Совершенствование Реинжиниринг
Уровень изменений Наращиваемый Радикальный
Начальная точка Существующий процесс «Чистая доска»
Частота изменений Непрерывно/единовременно Единовременно
Длительность изменений Малая Большая
Направление изменений Снизу вверх Сверху вниз
Охват Узкий — на уровне функций (функциональный подход) Широкий — межфункциональный
Риск Умеренный Высокий
Основное средство Стратегическое управление Информационные технологии
Тип изменений Изменение корпоративной культуры Культурный/структурный

Можно выделить три типа компаний, для которых реинжиниринг необходим и целесообразен:

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

Таким образом, задачи реинжиниринга аналогичны задачам инновации: освоение новшеств для обеспечения конкурентоспособности продукции и в конечном счете — выживаемости предприятия.

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

Бизнес-процесс — это множество «внутренних шагов» предприятия, заканчивающихся созданием продукции, необходимой потребителю. Назначение каждого бизнес-процесса состоит в том, чтобы предложить потребителю продукцию (услугу), удовлетворяющую его по стоимости, сервису и качеству.

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

Особенности проекта реинжиниринга

Проект реинжиниринга бизнеса обычно включает четыре этапа:

1. Разработка образа-видения (vision) будущей компании. На этом этапе компания строит картину того, как следует развивать бизнес, чтобы достичь стратегических целей;
2. Анализ существующего бизнеса — проводится исследование компании и составляются схемы ее работы в настоящий момент;
3. Разработка нового бизнеса — создаются новые и (или) изменяются прежние процессы и поддерживающая их информационная система, тестируются новые процессы;
4. Внедрение проекта нового бизнеса.

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

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

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

Применяя ИТ для создания и поддержания устойчивого конкурентного преимущества, требуется:

  • встроить достигнутые преимущества в бизнес и продолжать работать над новыми «прорывными» решениями;
  • распространить уже имеющиеся достижения на весь бизнес;
  • использовать позитивный опыт и достижения других компаний.

Во многих компаниях для решения этих задач 25–50% вложений направляются на прикладное программное обеспечение. Стратегическая цель ИТ — способствовать менеджменту, реагировать на динамику рынка, создавать, поддерживать и увеличивать конкурентное преимущество.

Принципы перепроектирования бизнес-процессов

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

1. Интегрирование бизнес-процессов. Наиболее характерное свойство перепроектированных процессов — отсутствие сборочных конвейеров как способа координации работы персонала с относительно простыми трудовыми функциями. При выполнении сложных трудовых функций требуется иная организация работ. На практике, конечно, не всегда удается свести все этапы процесса к работе, выполняемой одним человеком. В этом случае создается команда, которая несет ответственность за данный процесс. Возможны сбои и ошибки, но потери будут значительно меньше, чем при традиционной организации работ.

2. Горизонтальное сжатие бизнес-процессов. Сравнительные оценки, выполненные компаниями, которые провели реинжиниринг, показывают, что переход от традиционной организации работ к выполнению процесса одним человеком позволяет снизить численность персонала и ускорить выполнение процесса примерно в 10 раз. Уменьшается количество ошибок и отпадает необходимость держать специалистов для устранения этих ошибок. За счет уменьшения численности работающих и четкого распределения ответственности между ними улучшается управляемость.

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

4. Логика реализации бизнес-процессов. Линейное выполнение работ заменяется логическим порядком (т.е. часто работы осуществляются параллельно). Это экономит время, которое тратилось на взаимоувязку работ на разных участках.

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

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

7. Рационализация горизонтальных связей. Создание линейных функциональных подразделений. Работа выполняется в том месте, где это наиболее целесообразно. Раньше в компаниях работа была организована по «тематическому» принципу в соответствующих подразделениях: расчетный отдел, транспортный отдел, отдел снабжения и т.д., поэтому если расчетному отделу требовались карандаши, то он обращался в отдел снабжения с заявкой. Этот отдел находил производителя, договаривался о цене, размещал заказ, осматривал товар, оплачивал его и передавал в расчетный отдел. Этот процесс длителен и неэкономичен. Анализ, проведенный в одной из компаний, показал, что затраты на приобретение батарейки за 3 долл. составили 100 долл. При реинжиниринге чаще всего создаются горизонтальные управленческие связи между подразделениями. Это позволяет устранить излишнюю интеграцию.

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

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

10. Рационализация связей «компания — заказчик». Совершенствование оргструктуры фирмы должно создать условия, при которых уполномоченный менеджер обеспечивает единый канал связей.

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

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

Условия успешного реинжиниринга и факторы риска

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

На процесс реинжиниринга оказывают существенное влияние следующие факторы.

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

2. Руководство. Проект должен выполняться под управлением руководителей компании; руководитель, возглавляющий проект реинжиниринга, должен иметь большой авторитет и нести за него ответственность. Для успеха проекта очень важно твердое и умелое управление. Руководитель проекта должен понимать, что возникнут трудности, неизбежные при построении новой компании: он должен сопротивляться «давлению» старых порядков и убедить своих сотрудников в том, что проект не только выполним, но и необходим для выживания компании. Он обязан прилагать все усилия для продвижения проекта и своевременного его завершения.

3. Сотрудники. В команде, выполняющей проект реинжиниринга и контролирующей его проведение, необходимо участие сотрудников, выделенных соответствующими полномочиями и способных создать атмосферу сотрудничества. Сотрудники должны понимать, почему проект приведен в действие (другими словами, они должны оценивать проблемы, которые мешают бизнесу), принимать свои новые обязанное быть способными выполнять их, посвящать реинжинирингу необходим время и обоснованно двигаться к успеху. По сути, все работники должны освоить и устойчиво реализовывать новый набор образцов поведения. Опыт показывает, что относительно просто объяснить новый способ работы персоналу нижнего уровня, но людям, занимающим должности менеджеров, намного труднее понять то, что предлагает новая компания. Группа, на которую следует обратить особое внимание специалистов,— менеджеры среднего уровня. Американский исследователь Б. Виллох определяет три категории менеджеров такого уровня:

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

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

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

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

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

Естественно, некоторые из этих факторов, например стиль отношений в коллективе, быстро сформировать невозможно, поэтому работу над созданием необходимо начинать заранее.

Типичные ошибки при проведении реинжиниринга

Риск реинжиниринга достаточно велик, однако причины неудач заключаются не в загадочности реинжиниринга, а в нарушении правил его проведения. Американские исследователи М. Хаммер и Дж. Чампи указывают, что с точки зрения риска реинжиниринг подобен игре в шахматы, а не в рулетку, т.е. участники реинжиниринга, как игроки в шахматы, в меру своих знаний и умения могут влиять на результат. Иными словами, величину результата невозможно гарантировать. Главное в стратегии управления реинжинирингом — избегать глобальных ошибок.

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

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


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

При реинжиниринге часто повторяется следующий сценарий: менеджер верхнего уровня предлагает команде, осуществляющей реинжиниринг, совершить некоторое решительное преобразование существующего процесса. Команда, проанализировав последствия предложенное преобразования, показывает, что время выполнения процесса ускорит в 10 раз, его стоимость снизится в 20 раз и в десятки раз уменьшится количество ошибок. Подобная информация радует менеджера, однако когда команда сообщает, что реализация нового процесса потребует новой системы оценки работ, объединения нескольких отделений, изменения стиля производственных отношений и пр., он говорит, что просил сократить стоимость и количество ошибок, а не переделывать всю компанию. Подобная позиция менеджера ошибочна, потому что реинжиниринг — это именно «переделывание» компании.

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

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

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

Существующая корпоративная культура и принятые в компании принципы управления в определенных случаях могут не позволить даже начать реинжиниринг. Например, если решения принимаются на основании консенсуса, то сотрудники компании могут посчитать принцип проведения реинжиниринга «сверху вниз» (т.е. от менеджеров верхнего уровня к менеджерам среднего и нижнего уровней) оскорбляющим их чувства. Демократический опыт управления придет в противоречие с административными методами реинжиниринга, которые свойственны природе перестройки управления фирмой. Компании с короткой историей существования обычно свято чтут необходимость гарантировать ежеквартальные результаты, поэтому эти компании могут посчитать преобразования, связанные с реинжинирингом, весьма рискованными.

4. Непоследовательность освоения новации. Заключается в преждевременном завершении реинжиниринга и ограниченной постановке задачи. Значительные результаты достигаются только при больших амбициях руководства компании. При реинжиниринге встречается следующая ситуация. Кто-то из менеджеров считает, что лучше синица в руках, чем журавль в небе, т.е. обещает без больших затрат и без перестройки, свойственной реинжинирингу, получить повышение эффективности работы на 10–20%. Выбор более легкого пути — усовершенствования — оказывается довольно соблазнительным. Однако легкость эта кажущаяся: усовершенствования, как правило, усложняют существующий процесс, а их наслоения делают его малопонятным.

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

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

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

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

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

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

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

Илон Маск рекомендует:  Эффект разбитого текста

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

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

8. Личностные проблемы обновления. Попытка провести реинжиниринг, не ущемив ничьих прав, не может привести к положительному результату. Выражение «нельзя приготовить омлет, не разбив яиц» весьма точно отражает суть реинжиниринга. Он приносит не только радости, поскольку в результате его проведения одним сотрудникам приходится изменять характер работы, другие могут ее потерять, третьи будут чувствовать себя некомфортно. Так как угодить всем невозможно, приходится либо откладывать реинжиниринг, либо последовательно проводить лишь частичные изменения.

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

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

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

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

Федеральное агентство по образованию

Государственное образовательное учреждение высшего профессионального образования

«Казанский государственный технологический университет»

Нижнекамский химико-технологический институт

Реферат на тему:

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

Оглавление

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

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

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

Анализ и проектирование

Преимущества и недостатки компании-разработчика перед отдельным разработчиком

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

Список использованной литературы

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

Разнообразие программного обеспечения куда больше, чем технических решений. Так как они решают самые различные задачи, начиная от связи с оборудованием (драйвера) и заканчивая автоматизацией бухгалтерского учета или 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 являются пакеты. Сложные ПС обычно включают несколько подсистем, имеющих разное целевое назначение и функциональность. Поэтому на верхнем уровне иерархии можно показать пакеты подсистемы. Каждый из таких пакетов должен получить имя, отражающее суть соответствующей подсистемы. На этом уровне можно также показать пакеты классов, являющиеся общими для всей системы и используемые подсистемами. На начальной стадии реструктуризации логической модели можно ввести пакет верхнего уровня, куда помещаются классы, которые трудно отнести к какому-либо другому пакету. В любой ПС есть пользовательский интерфейс, связь с БД, управление, обработка, классы данных. Такого типа пакеты можно ввести в каждой подсистеме на следующем уровне иерархии.

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

Определение актеров. Для нахождения актеров следует искать ответы на следующие вопросы:

· Кто является непосредственными пользователями системы? Необходимо при ответе на данный вопрос указывать роли, а не конкретных людей, исполняющих эти роли.

· С каким внешним оборудованием или программами осуществляет взаимодействие система?

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

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

Актерам следует присвоить имена, отражающие их роли в работе с системой.

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

Далее выполняется детализация построенных пакетов ВИ на основе анализа экранных форм. Рекомендуемые правила:

· если экран содержит меню, то это пакет ВИ. При этом каждая строка меню – это либо подпакет, либо отдельный ВИ;

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

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

Распределение по пакетам. Если число актеров или ВИ слишком велико, то для упрощения поддержки модели ВИ целесообразно разделить их по пакетам. Это также упрощает понимание модели и распределение ответственности путем назначения разработчиков, ответственных за пакеты ВИ. Можно использовать следующие критерии упаковки ВИ в один пакет:

· если они взаимодействуют с одним актером;

· имеют друг с другом отношения включения или расширения (см. статью «Варианты использования системы. Use case диаграммы»).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

Цели анализа и моделирования требований

Целями анализа и моделирования требований являются:

· достижение соглашения между разработчиками, заказчиками и пользователями о том, что должна делать ПС;

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

· ограничение системной функциональности;

· создание базиса для планирования разработки проекта;

· определение пользовательского интерфейса;

· составление спецификации требований.

· Системный аналитик – специалист организации-разработчика, который возглавляет и координирует работы по выявлению и моделированию требований.

· Разработчик ВИ специалист организации-разработчика, который детализирует и уточняет модели требований.

· Заинтересованные лица – люди, предоставляющие информацию.

· Эксперт представитель заказчика, участвующий в разработке модели требований.

· Разработчик пользовательского интерфейса – специалист организации-разработчика, который создает прототип пользовательского интерфейса ПС.

Для достижения поставленных целей предусматривается создание следующих документов:

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

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

· Спецификация требований (Software Requirements Specification) – основной документ, используемый при проектировании и разработке ПС. Она включает модель требований и дополнительные спецификации, которые представляют собой текстовое описание требований к конечному продукту, но не к процессу его разработки и не содержат деталей реализации требований.

· Прототип пользовательского интерфейса обеспечивает визуальное представление интерфейса пользователя с ПС.

· Глоссарий текстовый документ, содержащий определения основных понятий и терминов, которые должны одинаково пониматься заказчиком и разработчиком. Источниками данных для создания перечисленных артефактов могут, в частности, служить артефакты, созданные при бизнес-анализе (см. статью «RUP. Обследование организации (бизнес-анализ)».

В процессе анализа и моделирования требований можно выделить несколько основных этапов (см. рис.1).

Рис.1 Технологический процесс управления требованиями.

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

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

Построение модели требований

Эта работа предполагает выявление актеров, ВИ и взаимодействий между ними. Если было проведено обследование организации, то в качестве источника для определения актеров и ВИ может служить бизнес-модель.

Если число ВИ слишком велико, то для упрощения читаемости и поддержки модели целесообразно разделить их по пакетам. Это также упрощает понимание модели и распределение ответственности путем назначения разработчиков, ответственных за пакеты ВИ. Пакеты позволяют организовать иерархию требований. Верхний уровень иерархии обычно определяется, исходя из основных видов деятельности организации. Если был выполнен бизнес-анализ, то основные виды деятельности уже представлены в бизнес-модели в виде пакетов, и они могут быть просто скопированы в модель требований. Пакетов верхнего уровня не должно быть много. Целесообразно выделить пакет администрирования и пакет вспомогательных действий, и 2 – 4 пакета, основных видов деятельности. В свою очередь, пакеты верхнего уровня могут включать пакеты следующего уровня и т. д.

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

Детализация модели требований

Цели данной деятельности:

· извлечение из ВИ характерных фрагментов, которые могут рассматриваться как отдельные абстрактные ВИ. Примерами таких частей могут быть общие фрагменты, необязательные фрагменты и исключения;

· обнаружение новых абстрактных актеров, которые играют роли, разделяемые несколькими актерами;

· реструктуризация модели требований;

· детальное описание потоков событий для ВИ;

· задание приоритетов ВИ.

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

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

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

Составление дополнительных спецификаций

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

Проектирование пользовательского интерфейса

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

· программная реализация, воспроизводящая точный вид экранных окон;

· альбом экранных форм;

· модель навигации экранов в виде диаграмм классов с указанием атрибутов – полей и операций кнопок.

Создание спецификации требований

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

Цель и задачи анализа и проектирования

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

К числу решаемых задач при этом относятся:

· разработка точной архитектуры распределенной программной системы;

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

· адаптация проекта системы к среде реализации с целью повышения производительности разработки;

· выбор механизмов реализации и определение ограничений на реализацию;

· разработка компонентной структуры;

· распределение компонентов по узлам.

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

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

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

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

Разработчик БД – отвечает за проектирование базы данных ПС.

В процессе анализа и проектирования создаются следующие документы:

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

Документ «Архитектура ПС», в котором собраны различные архитектурные представления ПС.

Модель данных – это описание структуры данных, хранимых в БД (например, реляционная модель данных).

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

Рис.2 Диаграмма деятельностей, описывающая процесс анализа и проектирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цели процесса реализации

Основные цели процесса можно сформулировать следующим образом:

· Определить структуру кода в виде уровней;

· Реализовать компоненты, классы и объекты;

· Провести блочное тестирование компонент;

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

В процесс реализации не включено тестирование всей ПС, для которого в RUP предусмотрен отдельный процесс (см. следующую статью).

Особенности процесса реализации

RUP предполагает поэлементную интеграцию в течение всего жизненного цикла. Это означает, что коды пишутся небольшими блоками, после чего они объединяются в единое целое путем постепенного добавления блоков. Это упрощает процесс локализации ошибок. Предусмотрено два уровня интеграции – интеграция результатов работы группы разработчиков в подсистему и интеграция подсистем в ПС. Интеграция происходит в каждой итерации в соответствии с планом итерации, где определены ВИ, которые проектируются и реализуются в этой итерации. Таким образом, план итерации определяет классы, которые будут реализованы в этой итерации.

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

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

Конструктор (кодировщик) разрабатывает компоненты и классы, выполняет блочное тестирование.

Системный интегратор выполняет интеграцию элементов в программные конструкции (систему и подсистемы).


Архитектор определяет структуру реализации (организацию уровней и подсистем).

Рецензент кода проверяет качество программного кода и его соответствие стандартам проекта.

Подсистема реализации — это набор компонент и других подсистем реализации, используемых для образования модели реализации. Это понятие позволяет иерархически представить модель реализации.

Компонент часть программного кода (см. статью «Компонентно-базированная разработка»).

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

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

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

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

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

Интеграция системы. Выполняется интеграция системы путем последовательного добавления в нее новых подсистем, созданных в рамках текущей итерации. Интеграция подсистемы завершается созданием набора программных конструкций подсистемы, каждая из которых тестируется по отдельности. Для тестирования системы в RUP предусмотрен отдельный процесс.

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

Цели процесса тестирования

Целью тестирования является оценка качества программного продукта путем

· Проверки взаимодействия компонентов;

· Проверки правильности интеграции компонентов;

· Проверки точности реализации всех требований и выявления дефектов.

Особенности процесса тестирования в RUP

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

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

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

Тестировщик (испытатель) отвечает за выполнение системного тестирования. В его обязанности входит настройка и выполнение тестов, оценки выполнения теста, восстановление после ошибок, регистрация выявленных дефектов.

В процессе тестирования создаются следующие документы:

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

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

· Контрольная задача – набор тестовых данных, условий выполнения тестов и ожидаемых результатов.

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

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

· Тестовый скрипт является программой, выполняемой при автоматическом тестировании с помощью инструментальных средств тестирования.

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

Результаты тестирования и данные, полученные в процессе выполнения тестов.

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

Дефекты – это описания обнаруженных при проведении тестирования фактов несоответствия системы предъявляемым требованиям. Они представляют собой вид запросов на внесение изменений.

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

Фаза вхождения в проект. В этой фазе выполняется подготовка к тестированию. Она включает:

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

· Анализ объема тестирования.

· Формулирование критериев качества и завершения тестирования.

· Установку и подготовки к работе инструментальных средств тестирования.

· Формулирование требований к проекту разработки ПС, определяемых потребностями тестирования.

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

· Создание плана тестирования для каждой итерации.

· Разработка сценариев тестирования.

· Создание заготовок тестовых скриптов.

· Разработка контрольных задач.

· Разработка методики испытаний.

· Разработка модели рабочей нагрузки.

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

· Создание плана тестирования для каждой итерации.

· Уточнение и дополнение модели тестирования.

· Описание обнаруженных дефектов.

· Описание результатов тестирования.

· Оценка результатов тестирования.

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

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

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

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

RUP предусматривает три процесса поддержки:

Управление проектом. Цели

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

Планирование предполагает созданий двух видов планов:

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

· План итераций создается для каждой итерации и предназначается для определения и распределения задач между участниками проекта.

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

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

Управление проектом. Деятельности

Открытие нового проекта. Эта деятельность выполняется только в первой итерации. Осуществляется инициализация проекта, определяются и оцениваются риски, разрабатывается бизнес-план. Цель – перевод проекта в стадию, когда возможно принятие решения о продолжении или об отказе от проекта.

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

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

Планирование итерации. Разрабатывается план очередной итерации, уточняется и корректируется бизнес-план и план разработки ПС. План итерации подробно описывает, что должно произойти за время итерации. Он определяет исполнителей и выполняемые ими работы. При создании плана итерации необходимо:

· Сформулировть объективные критерии успеха итерации. Они будут использоваться при ее оценке;

· Определить конкретные, измеримые артефакты, которые требуется разработать или изменить, а также выполняемые для этого работы;

· Использовать типичную итерационную декомпозицию работ для реальных действий, которые должны быть произведены;

· Использовать смету при определении продолжительности и объема работ для каждого вида деятельности, удерживая все значения в пределах бюджета.

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

Управление итерацией. Целью этой деятельности является получение достаточных для выполнения итерации ресурсов, разделение требуемых работ, оценка результатов итерации.

Завершение фазы. Выполняются работы, завершающие выполнение фазы. Даются ответы на следующие основные вопросы:

· Решены ли все основные проблемы предыдущей итерации?

· Известно ли состояние всех основных артефактов (см. ниже управление конфигурацией)?

· Рассмотрены ли все проблемы развертывания?

При удовлетворительном состоянии проекта выдается разрешение на переход к следующей фазе.

Завершение проекта. Руководитель проекта подготавливает проект к завершению. Готовится заключительная оценка состояния. При успешной сдаче проекта заказчик получает программный продукт в пользование. Высвобождающие ресурсы могут быть перераспределены (использованы в других проектах).

Управление конфигурацией и изменениями. Цели

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

Управление конфигурацией (Configuration management).

Процесс управления конфигурацией (УК) связан с определением артефактов, зависимостей между ними и конфигураций, являющихся непротиворечивыми множествами взаимосвязанных артефактов. Сюда же относятся вопросы распределения рабочих сред между участниками проекта с целью предотвращения ненужного дублирования документов. УК декларирует, что все артефакты подчиняются версионному управлению. По мере развития проекта у каждого артефакта появляются множество версий. Все они сохраняются в архиве проекта, причем ведется история изменений, в которой указывается причины и цели создания каждой версии каждого артефакта. Записанную в архив проекта версию нельзя изменить, можно лишь создать новую версию. Кроме того, знания о зависимостях между артефактами позволяют точно повторять действия при создании наборов артефактов (например, при сборке программы из отдельных файлов). Создание версий и связей поддерживается с помощью инструментальных средств УК.

· исключить возможность потери артефактов,

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

· гарантировать точное повторение действий над группой связанных артефактов в итерациях,

· избегать дублирования артефактов и связанной с этим возможности привнесения дополнительных дефектов,

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

Управление внесением изменений

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

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

Этот процесс связан с управлением проектом и направлен на предоставление информации, полезной для оценки:

· Состояния, прогресса, общих тенденций и качества продукта;

· Издержек и расходов;

· Проблемных областей, требующих внимания;

· Того, что сделано и что необходимо сделать.

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

Планирование конфигурации проекта и управления изменениями. Описываются все виды деятельности, связанные с УК, которые надо выполнить. Описывается процесс контроля над изменениями.

Создание среды УК. Целью этой деятельности является создание рабочей среды, в которой будут доступны все артефакты, будет обеспечена разработка, интеграция и архивирование продукта.


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

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

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

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

Управление средой. Цели

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

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

· Выбор и приобретение инструментальных средств;

· Настройку инструментальных средств под требования организации-разработчика;

· Создание технических служб поддержки.

Роли и артефакты

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

Главным создаваемым артефактом является план разработки, описывающий процесс, используемый в данном проекте. В нем указывается, какие артефакты, предусматриваемые в RUP, будут использоваться в проекте и каким образом.

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

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

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

Теперь, перечислим преимущества и недостатки компании-разработчика перед отдельным разработчиком.

Преимущества компании-разработчика перед отдельным разработчиком:

· Компания может «тянуть» большие и очень большие проекты. Отдельный же разработчик крупный проект может не осилить физически.

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

· Стандартизация исходного текста в компании значительно выше, чем у отдельного разработчика, т.к. в компании работает группа разработчиков.

· Технически, компании выше оснащены, чем один разработчик.

· Источников информации у компании больше, чем у отдельного разработчика. А это отражается на результате — разрабатываемой программе.

· У компании значительно выше опыт работы с различными проектами, чем у отдельного человека.

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

· Компания может предоставить комплексный подход при наличии специалистов различных направлений.

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

· Скорость разработки компании выше, чем у одного человека, т.к. можно подключать к проекту нескольких человек.

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

· Компания не уволится.

· Компания не умрет и ее не переедет автобус.

· Компания не заболеет и по этой причине не приостановит поддержку.

· В компании всегда будут люди, которые смогут продолжить дело.

· Компания берет на себя головную боль по поиску высоко-квалифицированных и ответственных программистов.

· Компания следит за технологиями и тенденциями развития программного обеспечения.

Недостатки компании-разработчика перед отдельным разработчиком:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Илон Маск рекомендует:  Что такое код gmp_cmp

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

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

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

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

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

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

В результате получился примерно такой график рентабельности обслуживания+разработки программы (по вертикали — в тысячах $, по горизонтали — в количестве компьютеров, реально работающих с программой):

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

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

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

Список использованной литературы

2.[ http://www.newlinestudio.ru/ArticleReengirinPO.php]

3.[ http://www.codenet.ru/progr/other/reengineering.php]

Вопрос 13. Реинжиниринг программных систем.

Есть работающая программа, но как она работает, никто не знает.

Реинжиниринг – существенно более общее понятие, чем программирование.

Реинжиниринг похож на трансляцию. Но в отличие от трансляции занимается инфраструктурными преобразованиями:

o ввод-вывод (раньше перфокарты, магнитные ленты)

o диалог с человеком

o работа с базами данных

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

Реинжиниринг программного обеспечения – процесс преобразования старых программ на старых языках со старых платформ в эквивалентные на новых языках на новые платформы.

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

Пример автоматизированных средств реинж. – «Modernization WorkBench» и «RescueWare».

Часть II. Технология программирования встроенных систем реального времени

Не нашли то, что искали? Воспользуйтесь поиском:

Лучшие изречения: Как то на паре, один преподаватель сказал, когда лекция заканчивалась — это был конец пары: «Что-то тут концом пахнет». 8379 — | 8010 — или читать все.

188.64.174.135 © studopedia.ru Не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования. Есть нарушение авторского права? Напишите нам | Обратная связь.

Отключите adBlock!
и обновите страницу (F5)

очень нужно

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

Реинжиниринг программного обеспечения — процесс создания новой функциональности или устранения ошибок, путём революционного изменения, но используя уже имеющееся в эксплуатации программное обеспечение. Процесс реинжиниринга описан Чиковски и Кроссом в их труде 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.

Ссылки

  • The Program Transformation Wiki (англ.) (Проверено 26 октября 2009)
  • The Architecture-Driven Modernization website at OMG (англ.) (Проверено 26 октября 2009)

Реинжиниринг

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

На других языках

This page is based on a Wikipedia article written by authors (here).
Text is available under the CC BY-SA 3.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.


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

Коренная перестройка — в этом, прежде всего, суть реинжиниринга бизнес-процессов. Слово «перестройка» здесь как нельзя лучше ассоциируется с той перестройкой, которую пережил в 1985 — 1991 годах Советский Союз. Правда, супердержава не выдержала такой «встряски». Неожиданно для себя и всего мира развалилась. 10-летний опыт практического реинжиниринга в развитых странах свидетельствует о том, что примерно 50-70% компаний, проводивших реинжиниринг своих бизнес-процессов, если и не «развалились», то не добились тех существенных результатов, ради которых и стоило подвергать себя столь сильному «стрессу». Однако остальные 30-50% компаний, имевших мужество «перейти Рубикон», отделявший уютную и надежную гавань их бизнеса от штормов и ураганов океана жесткой конкурентной борьбы, показали всему миру, что «игра стоит свеч», добившись скачкообразного увеличения показателей эффективности функционирования бизнеса. В ближайшей перспективе все фирмы, независимо от их желания и степени осознания необходимости глубоких внутренних перемен, обусловленных объективными неотвратимыми динамичными изменениями внешней деловой среды, обречены, во избежание исчезновения, на реинжиниринг своих бизнес-процессов.

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

Реинжиниринг бизнес-процессов не предполагает осуществления постоянных, но незначительных изменений, ведущих к небольшому «приростному» (на единицы и даже десятки процентов) улучшению показателей функционирования компании. В результате успешно проведенного реинжиниринга — быстрого осуществления глубоких и всесторонних коренных изменений системы управления — компания достигает существенного, «прорывного» роста эффективности (в десятки и сотни раз). Специфика реинжиниринга состоит в том, что существующая более 250 лет узкая специализация и обусловленная ею многократная передача ответственности как в производстве, так и, особенно, в управлении, отжили свой век и реинтегрируются ныне в сквозные бизнес-процессы, ответственность за которые от начала и до конца берут на себя сплоченные командным духом группы единомышленников, способные выполнять широкий спектр работ. Причем, работа в команде предполагает не столько всеобщее и постоянное одобрение и умиление по поводу любых действий ее членов, сколько творческие дискуссии и столкновение мнений с целью выработки наилучших нестандартных решений. Как говорил знаменитый шотландский философ и экономист Дэвид Юм: «Истина возникает в результате разногласий между друзьями».

Метод революционного преобразования деятельности предприятия, коренной перестройки его бизнеса, получивший название реинжиниринг, появился на Западе в 80-е годы прошлого столетия. Основателями теории реинжиниринга являются Майкл Хаммер и Джеймс Чампи, которые выпустили книгу «Реинжиниринг корпорации: манифест для революции в бизнесе». Авторы определили реинжиниринг как «фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов для достижения существенных улучшений в таких ключевых для современного бизнеса показателях результативности, как затраты, качество, уровень обслуживания и оперативность».

Существуют следующие категории бизнес-процессов:

  • Процессы, непосредственно обеспечивающие выпуск продукции.
  • Процессы планирования и управления.
  • Ресурсные процессы.
  • Процессы преобразования.
  • Существующей технологией реализации бизнес-процесса.
  • Существующей структурой бизнес-системы.
  • Средствами автоматизации, оборудованием, механизмами, обспечивающими реализацию процесса.

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

  1. Отказ от устаревших правил и подходов и начало делового процесса с нуля, что позволяет преодолеть негативное воздействие сложившихся хозяйственных догм.
  2. Пренебрежение действующими системами, структурами и процедурами компании и радикальное изменение способов хозяйственной деятельности – если невозможно переделать свою деловую среду, то можно переделать свой бизнес.
  3. Приведение к значительным изменениям показателей деятельности (на порядок отличающихся от предыдущих).

Реинжиниринг необходим в случаях потребности очень существенных улучшений, например, таких как эти 3 основные ситуации, требующие вмешательства:

  1. В условиях, когда фирма находится в состоянии глубокого кризиса. Этот кризис может выражаться в явно неконкурентном уровне издержек, массовом отказе потребителей от продукта фирмы и т.п.
  2. В условиях, когда текущее положение фирмы может быть признано удовлетворительным, однако прогнозы ее деятельности являются неблагоприятными. Фирма сталкивается с нежелательными для себя тенденциями в части конкурентоспособности, доходности, уровня спроса и т.д.
  3. Реализацией возможностей реинжиниринга занимаются благополучные, быстрорастущие и агрессивные организации. Их задача состоит в ускоренном наращивании отрыва от ближайших конкурентов и создании уникальных конкурентных преимуществ.

Причины возникновения реинжиниринга.

С середины, а еще более — в конце 80-х годов темп изменения внешней среды промышленных предприятий ускорился, в том числе за счет внедрения информационных технологий. Во всем мире изменения в организации производственной и управленческой деятельности стали происходить все быстрее. Со стороны потребителей причины этих изменений можно понять лишь с позиции маркетингового анализа:

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

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

  1. Рост сложности новых продуктов, причем в такой степени когда, ни отдельный человек, ни даже группа людей не могут знать все технические детали продукта. Это справедливо и для автомобильной промышленности, и для страховых и инвестиционных компаний, и для ресторанов «быстрой еды». Соответственно усложняются управленческие задачи.
  2. Неэффективность дальнейшего увеличения числа сотрудников на всех уровнях предприятия для решения усложнившихся управленческих задач. Рост числа сотрудников на средних уровнях менеджмента организации США многие годы был ответом на несколько факторов, включая рост сложности продуктов и методов бизнеса, плодовитость правительственных организаций в области законодательного регулирования и глобализации коммерческой деятельности. Но возникла ситуация, когда рост числа персонала перестал сказываться на удовлетворенности клиентов. Одна из причин — стоимость труда: некоторые страны применили схему бизнеса в США при существенно меньшей стоимости рабочей силы. Другая сторона проблемы — нелинейный рост числа управленцев и их внутренних проблем по отношению к числу работников, создающих собственно сам продукт или услугу. Во-первых, возникает нелинейный рост запозданий и ошибок, во-вторых, эффект «один с сошкой. семеро с ложкой».
  3. Недостаточная отдача от инвестиций в компьютерные системы и информационные технологии (ИТ). Расчеты на то, что использование ИТ само по себе решит проблемы эффективного управления производством, не оправдались. Пример из бизнеса США: с 60-х годов, когда компьютеры стали доступны многим предприятиям, общие затраты на них составили более двух триллионов долларов, однако рост производительности, соответствующий росту инвестиций, не был получен. Основная причина: использование компьютеров не меняло ничего в то, как велись дела, не менялись объем потоков бумаг, точки принятия решений и их число и т.п. Только появление качественно новых информационных технологий изменило ситуацию, когда они стали как подталкивать к улучшению бизнес-процессов, так и давать для этого реальные средства.

По мотивам к проведению реинжиниринга бизнес-процессов можно выделить три категории предприятий, которые обдумывают и планируют для себя реконструкцию:

  1. Предприятия находятся в большой тревоге (те, например, которые теряют клиентов, объем продаж, имеют плохие финансовые показатели);
  2. Предприятия у которых текущие дела в порядке, но их руководители предвидят серьезные проблемы в будущем. если имеющаяся организация не изменится;
  3. Предприятия, которые лидируют в своей области и будут лидировать в обозримом будущем, но хотят реорганизации, для того чтобы стать недостижимыми для конкурентов.

Для России и стран СНГ можно выделить и другие, специфические конкретные мотивы. Например:

  1. Решение выйти на внешние рынки со своими товарами и услугами (банки. экспорт сырья, авиаперевозки и др.).
  2. Прогноз появления на своем рынке конкуренции иностранных фирм.
  3. Стремление создать условия, в которых были бы вероятны западные инвестиции в данное предприятие.
  4. Желание перейти к выпуску качественно новой продукции для начала конкурентной борьбы (как на национальном, так и на зарубежном рынках).

Виды реинжиниринга

В реинжиниринге обычно выделяют два существенно отли­чающихся вида деятельности:

  1. Кризисный реинжиниринг (перепроектирование и реинжиниринг бизнес-процессов), где речь идет о решении крайне сложных проблем организации, когда дела пошли совсем плохо и нужен комплекс мер, который по¬зволил бы ликвидировать «очаги заболевания».
  2. Реинжиниринг развития (совершенствование бизнес-процессов), который применим тогда, когда дела у организации идут в целом неплохо, но ухудшилась динамика развития, стали опережать конкуренты.

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

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

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

Чтобы обеспечить деятельность большинства организаций, обычно достаточно всего от 3 до 10 основных бизнес-процессов. Но определить их невозможно без соответствующего анализа и интуиции. Бизнес-процессы редко можно описать в терминах традиционных управленческих структур, а тем более отыскать среди традиционных видов деятельности. Обычно выделяют три вида типичных бизнес-процессов: выработка стратегии, разработка нового товара, выполнение заказов. Масштаб программы реинжиниринга зависит от того, сколько основных бизнес-процессов будет ею охвачено. Результаты исследования конкретных хозяйственных ситуаций, возникающих в процессе реальных попыток перепроектирования и реинжиниринга бизнес-процессов, свидетельствуют как о достигнутых в ряде случаев существенных успехах, так и о неудачах и разочарованиях.

Перепректирование и реинжиниринг бизнес-процессов может позволить организации создать возможности для более тесного взаимодействия между поставщиками и заказчиками.

Так, например, в результате успешно проведенного в течение немногим более одного года реинжиниринга своего бизнес-процесса типа «выполнение заказов» компания Bell Atlantic Corporation достигла сокращения времени реализации этого бизнес-процесса (выполнение заказов на подключение корпоративных клиентов к каналам связи, обеспечивающим высокоскоростную передачу данных и видеокоммуникации) с 30 дней до 3 и смогла, таким образом, не только сохранить существующую клиентуру, но и привлечь многих новых заказчиков, то есть значительно расширить масштабы своего бизнеса.

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

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

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

Основные этапы и принципы реинжиниринга

Процесс реинжиниринга базируется на двух основных понятиях: «будущий образ фирмы» и «модель бизнеса». Будущий образ фирмы – упрощенный образ оригинала, отражающий главные его черты и не учитывающий второстепенные детали. Модель бизнеса – это представление основных хозяйственных процессов фирмы, взятых в их взаимодействии с деловой средой фирмы. Модели составляются и просчитываются при помощи специальных компьютерных программ. Модели бизнеса позволяют определить характеристики основных процессов деловой единицы и необходимость их перестройки – реинжиниринга.

Итак, объектом реинжиниринга являются не организации, а процессы. Компании подвергают реинжинирингу не свои отделы продаж или производства, а работу, выполняемую персоналом этих отделов.

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

  • «разработка продукта» — от выработки концепции до создания прототипа;
  • «продажи» — от выявления потенциального клиента до получения заказа;
  • «выполнение заказа» — от оформления заказа до осуществления платежа;
  • «обслуживание» — от получения запроса до разрешения возникшей проблемы.

После того, как процессы идентифицированы, необходимо решить, какие именно из них требуют реинжиниринга и каким должен быть его порядок. Следовательно, весь процесс реинжиниринга можно разбить на этапы:

Основные этапы реинжиниринга:

  1. Формируется желаемый образ фирмы. Формирование будущего образа происходит в рамках разработки стратегии фирмы, ее основных ориентиров и способов их достижения.
  2. Создается модель реального или существующего бизнеса фирмы. Здесь воссоздается (реконструируется) система действий, работ, при помощи которых компания реализует свои цели. Производится детальное описание и документация основных операций компании, оценивается их эффективность.
  3. Разрабатывается модель нового бизнеса. Происходит пере-проектирование текущего бизнеса — прямой реинжиниринг.
  4. Внедрение модели нового бизнеса в хозяйственную реальность фирмы. Все элементы новой модели бизнеса воплощаются на практике. Здесь важна умелая состыковка и переход от старых процессов к новым, так, чтобы исполнители процессов не ощущали дисгармонии рабочей обстановки и не переживали состояние рабочего стресса. Эластичность перехода во многом определяется степенью тщательности подготовительных работ.

Главной целью бизнес-реинжиниринга является резкое ус­корение реакции предприятия на изменения в требованиях по­требителей (или на прогноз таких изменений) при многократ­ном снижении затрат всех видов.

Перечислим базовые принципы, положенные в основу реинжиниринга бизнес-процессов:

  1. Несколько рабочих процедур объединяются в одну. Для перепроектированных процессов наиболее характерно отсутствие технологии «сборочного конвейера», в рамках которой на каждом рабочем месте выполняются простые задания, или рабочие процедуры. Выполнявшиеся различными сотрудниками, теперь они интегрируются в одну — происходит горизонтальное сжатие процесса. Если не удается привести все шаги процесса к одной работе, то создается команда, отвечающая за данный процесс. Наличие в команде нескольких человек неизбежно приводит к некоторым задержкам и ошибкам, возникающим при передаче работы между членами команды. Однако потери здесь значительно меньше, чем при традиционной организации работ, когда исполнители подчиняются различным подразделениям компании, располагающимся, возможно, на различных территориях. Кроме того, при традиционной организации трудно, а иногда и невозможно определить ответственного за быстрое и качественное выполнение работы. По имеющимся оценкам, горизонтальное сжатие ускоряет выполнение процесса примерно в 10 раз.
  2. Исполнители принимают самостоятельные решения. В ходе реинжиниринга компании осуществляют не только горизонтальное, но и вертикальное сжатие процессов. Это происходит за счет самостоятельного принятия решения исполнителем, в тех случаях, когда при традиционной организации работ он должен был обращаться к управленческой иерархии. При традиционной организации работ, ориентированной на выпуск массовой продукции, исходили из предположения, что исполнители не имеют ни времени, ни знаний, необходимых для принятия решений. Реинжиниринг отвергает эти предположения, что вполне естественно при отказе от массового производства и современном уровне образования. Наделение сотрудников большими полномочиями и увеличение роли каждого из них в работе компании приводит к значительному повышению их отдачи.
  3. Шаги процесса выполняются в естественном порядке. Реинжиниринг процессов освобождает от линейного упорядочивания рабочих процедур, свойственного традиционному подходу, позволяя распараллеливать процессы там, где это возможно.
  4. Процессы имеют различные варианты исполнения. Традиционный процесс ориентирован на производство массовой продукции для массового рынка, поэтому он должен исполняться единообразно, независимо от исходных условий при всех возможных входах процесса. В наше время высокая динамичность рынка приводит к тому, что процесс должен иметь различные версии исполнения в зависимости от конкретной ситуации, состояния рынка и т.д. Традиционные процессы обычно оказываются довольно сложными — они учитывают различные исключения и частные случаи. Новые процессы, в отличие от традиционных, ясны и просты — каждый вариант ориентирован только на одну соответствующую ему ситуацию.
  5. Работа выполняется в том месте, где это целесообразно. В традиционных компаниях она организуется по функциональным подразделениям: отдел заказов, транспортный отдел и т.п., и если, например, конструкторскому отделу требуется новый карандаш, то он обращается с заявкой в отдел заказов. Тот находит производителя, договаривается о цене, размещает заказ, осматривает товар, оплачивает его и передает конструкторам. Все это достаточно расточительно и медленно. Проведенный в одной из компаний США анализ показал, что при традиционном распределении работ внутренние затраты компании на приобретение батарейки стоимостью 3 долл. составили 100 долл. Кроме того, было установлено, что 35% всех заказов составляют заказы стоимостью менее 500 долл. После проведения реинжиниринга отделы перешли к самостоятельному заказу дешевых товаров. Итак, реинжиниринг распределяет работу между границами подразделений, устраняя излишнюю интеграцию, что приводит к повышению эффективности процесса в целом.
  6. Уменьшается количество проверок и управляющих воздействий. Проверки и управляющие воздействия непосредственно не производят материальных ценностей, поэтому задача реинжиниринга — сократить их до экономически целесообразного уровня. Традиционные процессы насыщены подобными шагами, единственное назначение которых — контроль за соблюдением исполнителями предписанных правил. К сожалению, на практике довольно часто оказывается, что стоимость проверок и управляющих воздействий превосходит стоимость заказа требуемого продукта. Реинжиниринг предлагает более сбалансированный подход. Вместо проверки каждого из выполняемых заданий перепроектированный процесс часто агрегирует эти задания и осуществляет проверки и управляющие воздействия в отложенном режиме, что заметно сокращает время и стоимость процессов.
  7. Минимизируется количество согласований. Еще один вид работ, не производящих непосредственных ценностей для заказчика, — это согласования. Задача реинжиниринга состоит в минимизации согласований путем сокращения внешних точек контакта. Как и в п.5, речь идет о стирании граней между функциональными подразделениями.
  8. «Уполномоченный» менеджер обеспечивает единую точку контакта. Механизм «уполномоченного» менеджера применяется в тех случаях, когда шаги процесса либо сложны, либо распределены таким образом, что их не удается объединить силами небольшой команды. «Уполномоченный» менеджер играет роль буфера между сложным процессом и заказчиком. Он ведет себя с заказчиком так, как если бы был ответственным за весь процесс. Чтобы выполнить эту роль, менеджер должен быть способен отвечать на вопросы заказчика и решать его проблемы, имея для этого доступ ко всем используемым информационным системам и ко всем исполнителям.
  9. Преобладает смешанный централизованно/децентрализованный подход. Современные технологии дают возможность компаниям действовать полностью автономно на уровне подразделений, сохраняя при этом возможность пользоваться централизованными данными. Важность объединения достоинств централизации и децентрализации можно проиллюстрировать на примере работы банков. При работе с крупными корпорациями многие банки осуществляют с одним и тем же клиентом независимые финансовые отношения через различные подразделения. Подобный децентрализованный подход может приводить к хаосу, так как каждое подразделение отслеживает только ту часть рынка, которая соответствует его профилю. Приведу реальную ситуацию, в которой банк установил для одного из своих клиентов максимальный кредит в размере 20 млн. долларов. Вследствие децентрализованности этого банка каждое из его подразделений выдало этому клиенту по 20 млн., а в результате клиент получил кредит в несколько раз больший, чем планировал банк, что выяснилось только после банкротства клиента.

Участники реинжиниринга.

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

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

Методологии моделирования бизнес-процессов

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

  1. Блок-схема бизнес-процесса, состоящая из прямоугольников (обозначающих действия), ромбиков (обозначающих принимаемые решения) и стрелок, соединяющих эти элементы между собой и друг с другом.
  2. Словесное описание бизнес-процесса, отвечающая на вопросы что, кто, где, как, зачем и почему, а также каковы затраты времени и денежных средств на принятие решений, ожидание и осуществление действий в бизнес-процессе.

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

  • Методология структурного анализа и проектирования (SASD). Эта методология основана на классической и весьма успешной методологии структурного проектирования программного обеспечения и информационных систем. Так как в разработке прикладных программ и ИС приходится постоянно иметь дело с различными информационными процессами, то неудивительно, что разработанные для этого методологии оказались вполне применимыми и для моделирования бизнес-процессов.
  • Методология SADT представляет собой дальнейшее развитие методологии структурного анализа и проектирования.
  • Методология IDEF. Это, пожалуй, наиболее глубоко проработанная и наиболее обширная методология, которая позволяет описывать не только бизнес-процессы, но и функциональные блоки (например, маркетинг или финансы), различные объекты в компании и действия над ними (например, весь комплекс процессов обработки и выполнения заказа клиента), а также состояние и динамику развития бизнес-единиц компании и компании в целом.
  • Методология ARIS (Architecture of Integrated Information Systems), которая также является и программным продуктом для моделирования бизнес-процессов организаций. Любая организация в методологии ARIS рассматривается с четырёх точек зрения: организационной, функциональной, обрабатываемых данных и структуры бизнес-процессов. При этом каждая из этих точек зрения разделяется ещё на три подуровня: описание требований, описание спецификации, описание внедрения. Для описания бизнес-процессов предлагается использовать около 80 типов моделей, каждая из которых принадлежит тому или иному аспекту. ARIS предоставляет визуальный инструментарий для обеспечения наглядности моделей.

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

Исторически большинство консалтинговых фирм основывали свои подходы к реинжинирингу, исходя из CASE-технологии разработки информационных систем. Здесь можно отметить такие известные фирмы, как Gemini Consulting — методология Construct и Andersen Consulting — методология Eagle. П.Хармон отмечает их ориентацию на профессионалов в области информационных технологий и направленность на разработку поддерживающих информационных систем.

Однако в проведении реинжиниринга участвуют специалисты двух типов — профессионалы в области реконструируемого бизнеса и разработчики информационных систем. Опыт реинжиниринга показывает, что по-настоящему успешное и новаторское внедрение информационных технологий является уникальным творческим процессом: управляющие компаний и специалисты-технологи, знакомясь с методами информационных технологий, сами делают открытия относительно возможностей их использования в своем конкретном бизнесе. В то же время, создание высококачественных информационных систем требует участия профессионалов в области информационных технологий. Возникает проблема поиска общего языка, которая стоит на пути интеграции современных технологий моделирования и разработки сложных систем: объектно-ориентированные методы, CASE-технологии, инженерия знаний, имитационное моделирование процессов и методы быстрой разработки приложений RAD (Rapid Application Development). Именно эта тенденция и наблюдается сейчас в развитии методологий и инструментальных средств реинжиниринга бизнес-процессов.

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

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

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

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

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

Инструменты реинжиниринга

Использование инструментальных средств (ИС) во многом определяет успех конкретного проекта по реинжинирингу. Все используемые в бизнес-реинжиниринге ИС можно разделить на следующие группы:

1. Средства управления проектом.

Назначение: Используются на подготовительном этапе BPR для планирования хода выполнения работ, а также для сопровождения проекта (контроля и корректировки планов выполнения работ). Кроме того, средства этой категории могут быть использованы на этапах обратного и прямого инжиниринга для создания модели бизнес-процесса в виде последовательности работ.

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

Примеры : CA-SuperProject (Computer Associates International), Microsoft Project (Microsoft), Time Line (Symantec).

2. Средства создания диаграмм.

Назначение: Это средства, используемые на этапах визуализации, обратного и прямого инжиниринга для формирования статических моделей существующего и нового бизнеса. Кроме того, средства этой категории используются при разработке информационной системы (ИС) нового бизнеса.

  • формирование функциональной модели бизнеса или информационной системы. Наиболее распространенный метод реализации данной функции –метод SADT (технология IDEF0), позволяющий описать бизнес-процесс или процесс в ИС в виде иерархии функций, связанных между собой входящими/исходящими потоками (материальными, финансовыми, информационными), управляющими воздействиями, исполнителями;
  • формирование информационной модели бизнес-процессов, в том числе выделение объектов бизнеса, описание их поведения и связей друг с другом. Наиболее распространенный метод реализации данной функции – метод IDEF1X, с помощью которого создается описание информационного пространства выполнения бизнес-процессов, содержащего информационные объекты (сущности), их свойства (атрибуты), отношения с другими объектами (связи);
  • анализ эффективности организации бизнеса, включающий выделение показателей эффективности бизнес-процессов, функционально-стоимостной анализ, выделение центров затрат, анализ загрузки и распределения ресурсов. Наиболее распространенный метод реализации данной функции – метод ABC (Activity Based Costing – функционально-стоимостной анализ) – метод определения стоимости и других характ еристик изделий и услуг на основе функций и ресурсов, задействованных в бизнес-процессах.

Большинство CASE-средств поддерживает лишь одну из выше перечисленных функций.

Примеры : Design/IDEF (Meta Software), BPWin (Logic Works), EasyABC (ABC Technologies), Staffware (Staffware plc)

3. Средства имитационного моделирования/анимации.

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

  • построение потоковых диаграмм, в которых представлены основные рабочие процедуры бизнеса и описано их поведение, а также информационные и материальные потоки между ними. При описании потоков учитываются различные метрики (например, частота появления заявок, время выполнения каждой рабочей процедуры, время передачи выходных данных и т.д.);
  • «проигрывание» моделей в сжатом времени или пошаговом режиме, изменение характеристик потоков и распределения ресурсов по принципу «что — если». При этом используются анимационные эффекты для демонстрации работы модели.

Наиболее распространенный метод имитационного моделирования — CPN (Color Petri Nets – раскрашенные сети Петри) – методология создания динамической модели бизнес-процесса, позволяющая проанализировать зависящие от времени характеристики выполнения процесса и распределение ресурсов для входящих потоков различной структуры.

Примеры : ServiceModel (ProModel), ReThink (Gensym), ModSym (CASI).

4. Средства создания информационных систем

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

  • формирование функциональной структуры (архитектуры) информационной системы. Наиболее распространенный метод реализации данной функции — DFD (Data Flow Diagrams – диаграммы потоков данных) — методология структурно-функционального анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных;
  • структурирование (моделирование) данных, в том числе: создание концептуальной модели структуры базы данных, автоматическая генерация физической модели БД и др. Наибольшее распространение получили: метод построения ER (Entity-Relationship)-диаграмм Чена и методология Уорнера-Орра DSSD (Data Structured Systems Development);
  • быстрая разработка приложений (визуальное программирование). Средства, обеспечивающие данную функцию называются RAD-средствами (Rapid Application Development). Они представляют собой визуальные дизайнеры приложений с автоматической кодогенерацией и позволяют создавать приложения в интерактивном режиме с помощью набора визуальных средств.

Примеры : S-Designor (PowerSoft), CASE*Designer (Oracle), Power Builder, Rational Rose (Rational Software)

5. Интегрированные многофункциональные средства.

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

  • спецификация бизнес-процессов, построение и анализ функциональной, структурной моделей бизнеса (поддержка методологии IDEF, потоки работ в сочетании с объектной ориентацией и т.д.);
  • возможности имитационного моделирования;
  • включение средств разработки приложений или стыковка с RAD-средствами.

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

Примеры : G2 (Gensym), SPARKS (Coopers & Lybrand).

С интегрированным подходом к поддержке реинжиниринга можно ознакомиться на примере одного из перспективных инструментальных средств реинжинири нга бизнес-процессов — системы ReThink, разработанной фирмой Gensym (США). В этой системе объединены возможности ключевых современных информационных технологий: графический объектно-ориентированный язык для описания моделей и проектов, средства анимации и имитационного мо делиро вания реконструируемых процессов, методы искусственного интеллекта для полного и адекватного представления экспертных знаний о процессах. Все э то открыло доступ к непосредственному моделированию и реконструированию бизнес-процессов новой группе пользователей — менеджерам. Сочетание п розрачных средств интерактивной графики с возможностями моделирования процессов в реальном времени позволяет им самостоятельно, без помощи программистов, воплощать свои идеи в виде работающих моделей процессов.

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

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

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

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

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

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

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

Сегодня ReThink используется в ряде компаний, среди которых патентное ведомство США и компания Xerox, осуществившая реинжиниринг отделения по закупке сопутствующих материалов с годовым оборотом в 3 млрд. долларов. В компании Xerox при проведении реинжиниринга сначала использовался пакет ABC FlowCharter, а построенная модель работы отделения включала 17 процессов и 314 рабочих процедур. Анализ модели показал, что 70% процедур оказались непроизводительными. Затем была разработана новая модель процессов закупки, включающая всего 42 рабочие процедуры. Столкнувшись с таким существенным сокращением количества процедур, руководство компании поставило вопрос о работоспособности новой организации: не возникнут ли перед компанией серьезные непредвиденные проблемы после того, как она сделает основные капиталовложения в реконструкцию отделения? Чтобы обосновать предложенный проект, было решено использовать систему ReThink, с помощью которой предполагалось исследовать имитационную модель планируемой организации работы отделения. В результате несколько процессов пришлось снова перепроектировать, что привело к выигрышу в качестве проекта, а, следовательно, снизило риск неудачи при проведении реинжиниринга.

CASE (Computer-Aided Software Engineering) — совокупность методов и средств проектирования информационных систем с интегрированными автоматизированными инструментами, которые могут быть использованы в процессе разработки программного обеспечения.

  • инструменты управления конфигурацией;
  • инструменты моделирования данных;
  • инструменты анализа и проектирования;
  • инструменты преобразования моделей;
  • инструменты редактирования программного кода;
  • инструменты рефакторинга кода;
  • генераторы кода;
  • инструменты для построения UML -диаграмм.

Теория реинжиниринга на практике

Привлечение всеобщего внимания к идеям и практике реинжиниринга (так, например, только в США, где к середине 90-тых реинжиниринг применяли более двух третей крупнейших компаний, представляющих самый широкий спектр разнообразных отраслей национальной экономики, в одном лишь 1994 году на консультантов по реинжинирингу было израсходовано более $7 млрд.) объясняется, не в последнюю очередь, вхождением мировой экономики в эпоху повсеместного применения информационных технологий на основе массовой компьютеризации и широкого использования Internet.

Приведем несколько примеров реализации воз­можностей реинжиниринга на практике, в которых отражены основные осо­бенности процесса реинжиниринга, а также выделена роль ин­формационных технологий.

Так, например, компания IBM Credit могла бы на основе внедрения компьютерной сети в существовавшую организационно-управленческую систему ускорить прохождение заявок на кредиты всего лишь на 10%. В то же время компьютеризация подвергшихся прошедших реинжинирингу бизнес-процессов обеспечила более чем 90%-ный рост производительности.

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

Компания Kodak могла бы за счет использования современных рабочих станций автоматизированного проектирования всего на несколько суток сократить существовавший процесс разработки новой продукции и необходимого технологического оборудования. Однако на основе компьютеризации прошедшего реинжиниринг процесса было достигнуто 50%-ное сокращение сроков разработки.

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

В этом году Unisys Corp. завершила полугодовой проект по реинжинирингу в Отделе Транспорта. При стоимости проекта 746 тыс. долл. ожидаемый эффект от экономии составляет 2 млн. долл. ежегодно.

Заключение

Всего несколько лет назад на Западе реинжиниринг бизнес-процессов стоял на первом месте в списке приоритетов любого консультанта, а Джеймса Чампи и Майкла Хаммера, авторов супербестселлера «Реинжиниринг корпорации», в то время называли гуру. А сегодня? Многие уже думают, что реинжиниринг появился и исчез. Однако это не так.

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

Существует еще два фактора, определяющих развитие реинжиниринга сегодня. Один — это рост электронной коммерции, а второй — стремительное развитие ERP-систем (системы планирования ресурсов предприятия).

Сначала коснемся электронной коммерции. Когда вы покупаете что-либо в электронном магазине, то ожидаете, что вашу покупку доставят на следующий день. Как это происходит? В действительности, чтобы гарантированно доставлять нам именно то, что мы заказали, компаниям, торгующим через такие магазины, приходится заново создавать всю свою цепочку поставок. Им приходится строить или создавать совсем новый склад, совсем новую систему логистики и совсем новую систему доставки. Иначе компания не будет приносить прибыль.

Касательно ERP-систем. В сущности, поставщики ERP-систем говорят: пожалуйста, оставьте несколько миллионов долларов у нас, и вы получите новую компанию, которой уже не потребуется реинжиниринг. И процессы в таких системах уже другие, они более эффективны, чем старые процессы. Однако они поддерживаются системой, а не компанией. И тогда компаниям действительно приходится менять свои процессы, чтобы приспособиться к системе.

Но и это не все. Возьмем в качестве примера слияние компаний Traveler’s и Citicorp. Если все, что они сделают, сведется к устранению избыточности, то из этого ничего не выйдет. Однако если они смогут создать компанию по предоставлению финансовых услуг, которую мы будем воспринимать по-другому, то на свет появится совсем новый тип компании. Люди хотят делать с деньгами три вещи: учитывать, инвестировать и тратить. С точки зрения потребителя, существуют различные процессы, ассоциируемые с каждым из этих действий, а компании по предоставлению финансовых услуг, как правило, обслуживают всего лишь одно или два действия. Но предположим, что мы можем обратиться к по-настоящему высокоэффективной компании, которая способна помочь нам выполнять все три действия, причем в электронном виде. Но разве не этим все время являлся настоящий реинжиниринг? Проведение реинжиниринга всегда начиналось с вопросов: «Каким образом вы можете переосмыслить способ ведения вашего бизнеса? Каким образом вы можете переосмыслить вашу деятельность, чтобы добиться роста?» Именно в этом суть реинжиниринга .

Но существует и критика реинжиниринга:

  • Массовые увольнения.
  • Реинжинирнг подразумевает, что фактор ограничивающий рост эффективности предприятия, — бездейственность либо же неэффективность процессов.
  • Реинжинирнг не берет во внимание факт «скованности» фирмы.
  • Результат может не оправдать ожиданий.
  • Акцентрируется внимание на производительности и технологиях, пренебрежение людьми в компании.

Последствия реинжинирнга бизнес-процессов:

  1. Переход от функциональных поздразделений к командам процессов.
  2. Работа исполнителя изменяется от простой к многоплановой.
  3. Требования к работникам изменяются: от контролируемого исполнения предприсанных заданий к принятию самостоятельных решений.
  4. Изменяются требования к подготовке сотрудников: от курсов обучения к образованию.
  5. Изменяется оценка эффективности работы и оплаты труда: от оценки деятельности к оценке результата.
  6. Критерий продвижения в должности изменяется: от эффективности выполнения работы к способности выполнять работу.
  7. Изменяется цель исполнителя: от удовлетворения потребностей начальника к удовлетворению потребностей клиентов.
  8. Функции менеджеров изменяются от контролирующим к тренерским.
  9. Организационная структура меняется от иерархической к более «плоской».
  10. Административные функции изменяются от секретарских к лидирующим.

Список литературы

  1. Абдикеев Н.М., Киселев А.Д. Управление корпорации и реинжиниринг — М.: ИНФРА-М, 2011.— 382 с.
  2. Абдикеев Н. М., Реинжиниринг бизнес-процессов. Полный курс MBA, М.: ИНФРА-М, 2005г. — 578 с.
  3. В.А. Силич, М.П. Силич. Реинжиниринг бизнес-процессов: учеб. пособие — Томск: Томск, гос. ун-т систем управления и радиоэлектроники, 2007. — 200 с.
  4. Робсон М., Уллах Ф. Практическое руководство по реинжинирингу бизнес-процессов / Пер. с англ. под ред. НД. Эриашвили. — М.: Аудит: Юнити, 1997. — 224 с.
  5. Ю. Ф. Тельнов «Реинжиниринг бизнес-процессов», Москва — Финансы и статистика, 2005 г. – 320 с. 2-е издание, переработанное и дополненное.
  6. Л.Ю.Григорьев, Менеджмент по нотам: Технология построения эффективных компаний/ — М.: Альбина Паблишерс, 2010. – 692 с.
  7. Майкл Хаммер, Джеймс Чампи. Реинжиниринг корпорации. Манифест революции в бизнесе– М.: Манн, Иванов и Фербер, 2007 г. – 288 с.
  8. Андерсен Б. Бизнес процессы. Инструменты совершенствования /М.: РИА «Стандарты и качество», 2003. — 272 с, илл. (Серия «Практический менеджмент»).
  9. Мильнер Б. З. Управление знаниями: Эволюция и революция в организации — 178 с, 2003г.
  10. Б.А. Железко, Т.А. Ермакова, Л.П. Володько. Реинжиринг бизнес-процессов : учебное пособие. — Минск : Книжный дом : Мисанта, 2006. — 210
  11. Николенко Н.П. Реинжиниринг страховой компании. — М.: страховое ревю, 2008
  12. Практическое руководство по реинжинирингу бизнес-процессов, Майк Ротер, Джон Шук. — HE LEAN ENTERPRISE INSTITUTE, США, 2009 -144с.
  13. Ильин В. В. , Реинжиниринг бизнес-процессов с использованием ARIS, , — М.: — Вильямс, 2008 г, 256с.
  14. Оболенский Н. Н., Практический реинжиниринг бизнеса. М. — ЛОРИ, 2004, 368с.
  15. Щенников С.Ю., Реинжиниринг бизнес-процессов. Экспертное моделирование, управление и оценка. – М.: «Ось-89», 2004.-288 с.
  16. Мишурова И. В., Кутелев В. П., Кутелев П. В. Технология реинжиниринга бизнеса, — М.: МарТ Издательский центр , 2003 г., 176с.
  17. Елиферов В. Г., Репин В. В., Бизнес-процессы: Регламентация и управление. М.: Инфра-М, 2005. — 319 с.
  18. Скубченко А. И.» Рапопорт, Б. М. Инжиниринг и моделирование бизнеса — М. : Тандем, Экмос, 2001. — 239 с
  19. Журнал «Аудит и финансовый анализ» от 02.2008 — «Реинжиниринг бизнес-процессов: в поисках утраченного времени»
  20. Медынский В.Г., Ильдеменов С.В. ‘Реинжиниринг инновационного предпринимательства’, М — Юнити, 1999, 414 стр.

Статью подготовили Демченков А.А., Лапшина Е.А., Савинова В.М., Мельников В., Попов К.

Программное обеспечение для реинжиниринга бизнес-процессов

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

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

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

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

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

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL