Понятийный аппарат теории систем.

Понятие бизнес-процесса.

БП – повторяющийся, последовательный, взаимоувязанный набор мероприятий (операций, действий), который потребляет некие ресурсы, создает некую ценность и выдает результат потребителю.

 

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

· То, что приносит прибыль

· Имеет повторяемость

· Имеет начало и завершение

 

 

Классификация систем.

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

 

По предметному принципу. Выделение основных видов конкретных систем, существующих в природе и обществе:

· с учётом вида отображаемого объекта (технические, биологические, экономические итп);

· с учётом вида научного направления (математические, физические, химические итп).

 

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

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

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

· Открытые системы постоянно обмениваются веществом, энергией или информацией со средой. Система закрыта (замкнута), если в неё не поступают и из неё не выделяются вещество, энергия или информация.

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

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

· По степени организованности выделяют класс хорошо организованных, класс плохо организованных (диффузных) систем и класс развивающихся (самоорганизующихся) систем.

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

· По типу описания закона (законов) функционирования системы:

Ø "Черный ящик" (неизвестен полностью закон функционирования системы; известны только входные и выходные сообщения);

Ø не параметризованные (закон не описан; описываем с помощью хотя бы неизвестных параметров; известны лишь некоторые априорные свойства закона);

Ø параметризованные (закон известен с точностью до параметров и его возможно отнести к некоторому классу зависимостей);

Ø "Белый (прозрачный) ящик" (полностью известен закон).

 

Понятие информационной системы. Требования, предъявляемые к информационной системе. Классификация информационных систем.

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

 

К ИС предъявляются следующие требования:

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

· своевременность предоставления информации;

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

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

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

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

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

 

Классификация информационных систем:

Все ИС можно классифицировать по степени автоматизации обрабатываемой информации и по сфере применения (рис. 1.1).

Рис. 1.1. Классификация информационных систем

В зависимости от степени автоматизации обрабатываемой информации ИС разделяются на:

· ручные;

· автоматизированные;

· автоматические.

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

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

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

По сфере применения можно выделить следующие классы ИС:

· системы поддержки принятия решений;

· системы автоматизированного проектирования;

· системы организационного управления;

· системы управления технологическими процессами.

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

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

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

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

· создание графической документации (чертежей, схем, планировок);

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

· создание управляющих программ для станков с программным управлением.

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

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

 

 

БИЛЕТ №____2____

1. Определение целей, задач и критериев для реорганизации бизнес-процессов.

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

· Для решения какой проблемы (каких проблем) мы хотим реорганизовать наши бизнес-процессы?

· Можем ли мы решить данные проблемы, не прибегая к реорганизации бизнес-процессов? Какие есть альтернативы решению наших проблем?

· Какие именно бизнес-процессы необходимо реорганизовать?

· Что мы хотим добиться в результате проведения проекта реорганизации? Какое должно быть целевое состояние нашей системы? Какие ожидаются результаты?

· Какие основные задачи стоят перед нами при выполнении данного проекта?

· Какие ресурсы будут привлечены для выполнения проекта? Достаточны ли они?

· Сколько времени отводится на выполнение проекта?

· Кто отвечает за выполнение проекта?

· Есть ли какие либо ограничения либо дополнительные условия, связанные с реорганизацией?

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

Документ в сжатой форме содержит все ключевые моменты проекта реорганизации:

· · Предпосылки к проведению проекта;

· · Целевое состояние организации;

· · Задачи (как декомпозицию цели проекта);

· · Ресурсы;

· · Сроки;

· · Ответственные лица.

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

Критерии

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

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

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

 

 

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

Анкетирование.

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

Анкета должна быть составлена таким образом, чтобы ее заполнение заняло не более 1 часа у анкетируемого лица, в противном случае внимание рассеивается и человек отвечает на вопросы анкеты по принципу «лишь бы отписаться», либо вообще игнорирует многие вопросы. Вопросы анкеты должны быть таковы, чтобы:

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

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

· Предполагаемый ответ на вопрос был кратким по объему, но достаточно полным по содержанию;

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

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

Интервьюирование

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

Сбор документов

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

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

Наблюдение

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

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

Таблица 1

Методология	Программное обеспечение
IDEF	AllFussion Business Modeler (BPwin), MS Visio
ARIS	ARIS Toolset
UML	Rational Rose, MS Visio, ARIS Toolset

Семейство стандартов IDEF

Стандарт моделирования бизнес-процессов IDEF0 был принят в качестве такового в 1981 году. Исторически он возник из стандарта SADT (Structured Analysis and Design Teqnique), активно применявшегося с конца 60-х годов, в частности, Министерством обороны США. IDEF является аббревиатурой от ICAM DEFinition. ICAM - Integrated Computer Aided Manufacturing.

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

· IDEF0 - стандарт описания бизнес-процессов;

· DFD - диаграмма потока данных (DataFlow Diagram);

· IDEF3 - стандарт моделирования потока работ (workflow).

Семейство стандартов ARIS

ARIS расшифровывается как Arhitecture of Integrated Information Systems (архитектура интегрированных информационных систем). В методологию ARIS входит пять типов представлений моделей:

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

· Функциональные модели, описывающие функции (процессы, операции), выполняемые в организации;

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

· Модели процессов/управления, представляющие комплексный взгляд на реализацию деловых процессов в рамках системы и объединяющие вместе другие модели;

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

В каждом из этих типов моделей есть ряд нотаций, отличающихся методами моделирования, и число этих нотаций довольно велико. В частности, ARIS Toolset поддерживает ряд нотаций языка моделирования UML (Unified Modeling Language).

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

Нотация ARIS eEPC расшифровывается следующим образом: Extended Event Driven Process Chain - расширенная нотация описания цепочки процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером. В таблице ниже приводятся основные используемые в рамках нотации графические объекты.

Таблица 2

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

Кроме этих правил, существуют и другие важные правила формирования моделей в ARIS. Эти правила можно изучить при помощи методического материала «Методы ARIS», который устанавливается на компьютер одновременно с демо-версией продукта.

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

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

Семейство стандартов UML

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

Язык UML был создан в компании Rational одним из ведущих идеологов объектно - ориентированного подхода к программированию Гради Бучем (Grady Booch), совместно с Джимом Рамбо (Jim Rumbaugh) и Иваром Джекобсоном (lvar Jacobson) в 1994 году.

UML включает в себя ряд типов диаграмм, некоторые из которых могут быть использованы для моделирования бизнес-процессов. В частности, это диаграмма прецедентов (Use-case diagram) и диаграмма действий (Activity Diagram).

Диаграмма прецедентов состоит из прецедентов (use-case) - типичных взаимодействий между пользователем и компьютерной системой - и субъектов (actor) - ролей, которые пользователи играют относительно системы. Также на ней могут быть указаны отношения между прецедентами: связь расширения (extends) и связь использования (uses).

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

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

Понятие методологии, методов и технологии моделирования ИС. Требования, предъявляемые к современным технологиям моделирования ИС.

 

 

БИЛЕТ №_____9___

1. Внедрение нового бизнес-процесса.

 

 

2. Энтропия источника дискретных сообщений и сложных систем.

 

 

3. Понятие сущности и типы сущностей. Способы отражения сущностей в диаграммах IDEF1Х. Признаки сущности. Понятие потенциального и первичного ключа. Роль первичного ключа для проектирования БД.

 

БИЛЕТ №____10____

1. Проблемы при внедрении новых бизнес-процессов.

 

 

2. Процедуры декомпозиции, анализа, синтеза.

 

 

3. Атрибуты и типы атрибутов. Способы отображения атрибутов в диаграммах Чена и IDEF1Х. Понятие доменов атрибутов. Требования, предъявляемые для проектирования доменов на разных этапах проектирования БД.

 

 

БИЛЕТ №___11_____

1. Понятие функционально-стоимостного анализа.

 

Примеры сложной системы.

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

 

 

3. Понятие связи и типы связей. Степень связи. Типы связей и отражение связей в среде Erwin. Окно «Свойство связи».

 

 

БИЛЕТ №____12____

1. Практический подход к проведению ФСА.

 

2. Определения процедур анализа и синтеза.

 

 

3. Показатель кардинальности. Правило нахождения и особенности связи с показателем кардинальности 1:м. Отображение связи с показателем кардинальности 1:м в среде Erwin. Примеры идентифицирующей и неидентифицирующей связей с показателем кардинальности 1:1.

 

БИЛЕТ №___13_____

1. Система сбалансированных показателей.

 

2. Модель общей задачи принятия решений.

 

3. Понятие показателя кардинальности. Правило нахождения и особенности связи с показателем кардинальности 1:1. Отображение связи с показателем кардинальности 1:1 в среде Erwin. Примеры идентифицирующей и неидентифицируещей связей с показателем кардинальности 1:1.

 

БИЛЕТ №____14____

1. Реинжиниринг и реструктуризация предприятия.

 

2. Понятие качества и эффективности системы.

 

 

3. Правило нахождения и особенности связи с показателем кардинальности M:N. Признаки ассоциативной таблицы.

 

БИЛЕТ №____15____

Обратный инжиниринг.

 

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

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

В настоящее время под словами «reverse engineering» чаще всего понимается т. н. «clean room reverseengineering», то есть процесс, при котором одна группа разработчиков анализирует машинный кодпрограммы (в сленге хакеров для этого процесса используется также выражение «обратный инжиниринг» или«реверсный инжиниринг»), составляет алгоритм данной программы на псевдокоде, либо, если программаявляется драйвером какого-либо устройства, составляет исчерпывающие спецификации интересующегоустройства. После получения спецификаций другая группа разработчиков пишет собственный драйвер наоснове полученных спецификаций или алгоритмов. Такой подход позволяет избежать обвинений внарушении авторских прав на исходную программу, так как по законам, к примеру в США, подпадает подпонятие «fair use», то есть добросовестного использования оригинальной программы. Результат обратнойразработки редко идентичен оригиналу, что и позволяет избежать ответственности перед законом

Понятие «обратный инжиниринг» является современной формулировкой прежнего понятия – копирование, усовершенствование…

 

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

 

Однако, если немного поразмыслить, то все новое это хорошо забытое, невостребованное в той или иной форме старое. Немного усовершенствовав двигатель или проект – и, готово новое современное изобретение, с новым объемом и новым внешним видом.

 

И так, что же такое «обратный инжиниринг» в наше время?

 

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

 

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

 

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

 

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

 

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

Электроника

Копирование различных электронных блоков без фактической разработки. Известно, что часть советскойцифровой электроники копировалась. Например, американская серия интегральных схем 74 и её советскийаналог К(Р)155.

Ещё один пример обратной разработки — создание компанией AMD процессора Intel 80386.

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

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

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

Одним из широко известных примеров обратной разработки является исследование IBM, ставшее серьёзнымшагом на пути развития производства IBM-совместимых компьютеров сторонними производителями.Создание сервера GNU/Linux и работающего с серверами на базе ОС Microsoft Windows) также потребовалообратной разработки используемого SMB.

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

1. Анализ обмена данными, наиболее распространённый в обратной разработке протоколов обмена данными,который производится с помощью анализатора шины и пакетного сниффера для прослушивания шины компьютера и компьютерной сети соответственно.

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

3. Декомпиляция с помощью декомпилятора — процесс создания исходного кода на некотором языкепрограммирования высокого уровня.

Базы данных

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

Промышленность

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

Военная промышленность

Самыми известными фактами обратной разработки во время второй мировой войны являлись:

· Немецкие канистры для бензина — британские и американские войска заметили, что немцы имели оченьудобные канистры. Они скопировали эти канистры, и те получили название Jerry cans (от слова «gerrys» — от«Germans»).

· Туполев Ту - 4 — некоторое количество американских бомбардировщиков B - 29 при совершении вылетов в Японию были вынуждены садиться в СССР. Советские военные, которые не имели подобных стратегическихбомбардировщиков, решили скопировать B-29. Через несколько лет они разработали Ту-4, практическиполную копию.

ПО

Для анализа исходного кода

С широким применением SADT) связано возникновение основных идей популярного ныне понятия - BPR(бизнес-процесс реинжиниринг).

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

· Rational Rose (фирмы Rational Software)

· Visual Paradigma

· StarUML