«ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ ОБРАЗОВАТЕЛЬНАЯ ПРОГРАММА ДИСЦИПЛИНЫ (рабочая учебная программа дисциплины) Направление подготовки: 230100 Информатика и вычислительная техника Профили подготовки: 230101 ...»

Министерство образования и науки Российской Федерации

ФГБОУ ВПО

«ИРКУТСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ

УНИВЕРСИТЕТ»

Факультет кибернетики

Кафедра вычислительной техники

ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ

ОБРАЗОВАТЕЛЬНАЯ ПРОГРАММА ДИСЦИПЛИНЫ

(рабочая учебная программа дисциплины) Направление подготовки: 230100 «Информатика и вычислительная техника»

Профили подготовки: 230101 «Вычислительные машины, комплексы, системы и сети»

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

1.Информация из ФГОС, относящаяся к дисциплине 1.1. Вид деятельности выпускника Дисциплина охватывает круг вопросов относящихся к виду деятельности выпускника:

- проектно-конструкторская деятельность;

- проектно-технологическая деятельность;

- научно-исследовательская деятельность;

- научно-педагогическая деятельность.

1.2. Задачи профессиональной деятельности выпускника В дисциплине рассматриваются указанные в ФГОС задачи профессиональной деятельности выпускника:

Проектно-конструкторская деятельность:

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

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

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

Проектно-технологическая деятельность:

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

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

Научно-исследовательская деятельность:

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

- проведение экспериментов по заданной методике и анализ результатов;

- составление отчета по выполненному заданию.

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

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

готов к кооперации с коллегами, работе в коллективе (ОК-3);

умеет использовать нормативные правовые документы в своей деятельности (ОК-5);

использует основные законы естественнонаучных дисциплин в профессиональной деятельности, применяет методы математического анализа и моделирования, теоретического и экспериментального исследования (ОК-10);

осознает сущность и значение информации в развитии современного общества; владеет основными методами, способами и средствами получения, хранения, переработки информации (ОК-11);

имеет навыки работы с компьютером как средством управления информацией (ОК-12);

осваивать методики использования программных средства для решения практических задач (ПК-2);

разрабатывать интерфейсы «человек-ЭВМ» (ПК-3);

разрабатывать модели компонентов информационной системы, включая модели базы данных (ПК-4);

- разрабатывать компоненты программных комплексов (ПК-5);

- готовить презентации, научно-технические отчёты по результатам выполненной работы, оформлять результаты исследований в виде статей докладов на научно- технических конференциях (ПК-7);

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

1.4. Перечень умений и знаний, установленных ФГОС После освоения программы настоящей дисциплины студент должен:

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

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

принципы организации и управления проектом ИС;.

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

разрабатывать модели с помощью CASE-средств на всех этапах проектирования;

ставить и решать задачи, связанные с организацией диалога между человеком и информационной системой;

анализировать и оценивать производительность ИС.

владеть:

современными технологиями проектирования объектов профессиональной деятельности;

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

';

Основными задачами изучения дисциплины являются:

1. Дать представление о процессе проектирования 2. Познакомить с принципами проектирования систем управления, организации и экономики 3. Ознакомить с отечественными стандартами проектирования информационных экономических систем 4. Ознакомить с международными стандартами проектирования 5. Привить навыки использования современных CASE- средств 3. Место дисциплины в структуре ООП Для изучения дисциплины необходимо освоение содержания дисциплин:

- Информатика;

- Теория систем и системный анализ;

- Программирование;

- Операционные системы;

- Базы данных;

- Основы теории управления.

Знания и умения, приобретаемые студентами после освоения содержания дисциплины, будут использоваться при изучении дисциплины основы IT-менеджмента.

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

4. Основная структура дисциплины Общая трудоемкость дисциплины составляет 3 ЗЕТ(108 уч. часов) Самостоятельная работа (в том числе контрольная работа) 5. Содержание дисциплины 5.1. Перечень основных разделов и тем дисциплины Введение.

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

Тема 1.2.Система, информационная система (ИС) Определение системы, состав, цель. Цели и состав информационной системы. Функциональные и обеспечивающие подсистемы.

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

Тема 1.4.Принципы разработки информационных систем Принципы разработки, сформулированные ак. Глушковым, их трактовка для современных условий.

Тема 1.5.Жизненный цикл систем Рабочие процессы проектирования и фазы проектирования. Рабочие процессы проектирования. Основные процессы. Вспомогательные процессы. Процессы управления.Фазы проектирования. Модели ЖЦ как соотношение рабочих процессов и фаз проектирования. Достоинства и недостатки каскадной и спиральной модели ЖЦ. Условия использования каскадной и спиральной модели ЖЦ.

Тема 2.1.Моделирование предметной области Структурный и объектно-ориентированный подходы при проектировании ИС: соотношение, отличительные черты. Понятие функции, бизнес-процесса. Методология SADT (IDEF0).Состав функциональной модели. Иерархия диаграмм. SADT-методология. Блоки, дуги. Принципы моделирования. Виды связей в моделях. Примеры прямых и обратных связей. Туннелирование. Этапы проектирования. Правила проведения экспертиз. Понятие стратегии декомпозиции. Стратегии декомпозиции: по стабильным подсистемам, по жизненному циклу, функциональная, стратегия 3Р. Стратегия декомпозиции, основанная на методике выделения функций производственных систем Тема 2.2.Реинжиниринг бизнес-процессов реинжиниринга. Участники реинжиниринговой деятельности. Пути перепроектирования. Ошибки при BPR.

Тема 2.4.Разработка требований Понятиетребования. Классификация требований. Уровни требований. Процесс выявления требований. Атрибуты требований.

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

проектирование Проектирование архитектуры. Структура архитектуры. Модель Захмана. Техники проектирования. Проектирование информационного обеспечения. Проектирование документации.

Тема 2.6.Конструирование Основы конструирования. Стандарты в конструировании.

Управление конструированием Тема 2.7.Тестирование Основные термины. Уровни тестирования. Цели тестирования.

Техники тестирования. Измерение результатов тестирования.

Документирование тестов и рабочего продукта Раздел 3. Технологии проектирования Тема 3.1. Требования к технологиям проектирования Функциональные и объектные технологии проектирования. Стандарты технологий. Методы и средства проектирования ИС. Краткая характеристика применяемых технологий проектирования. Требования, предъявляемые к технологии проектирования ИС. Выбор технологии проектирования ИС Тема 3.2. Каноническое проектирование ИС Стандарты, регламентирующие технологию канонического проектирования. Предпроектная стадия. Стадия технического проектирования. Состав технического проекта. Правила разработки постановок задач. Стадия рабочего проектирования. Состав работ на стадии рабочего проектирования. Виды рабочей документации. Стадия ввода в эксплуатацию Состав работ на стадии ввода в эксплуатацию. Виды испытаний. Методы тестирования систем. Документация на этапе ввода в эксплуатацию. Эксплуатация и сопровождения автоматизированных систем Тема 3.3. Типовое проектирование ИС Понятие типового элемента. Элементный, подсистемный и объектный методы типового проектирования.

Тема 3.4. Технология DATARUN Основные процессы стандарта ISO/IEC 12207. Модель деятельности организации. Модель проектируемой ИС. Этапы технологии DATARUN Тема 3.5. Технология RUP Объектно-ориентированный подход к проектированию ИС. Язык UML. Диаграммы использования системы (UseCases), диаграммы классов, временная диаграмма (Sequences).

Краткое описание содержания теоретической части разделов и 5. Тема 1. Введение. Понятие о процессе проектирования Литература о проектировании начинает появляться в 50-60-е годы 19в. В то время считалось, что проектирование - это то, чем занимаются архитекторы, инженеры, художники - прикладники и т.д., когда создают чертежи для своих клиентов или для производства.

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

Но что же представляет собой процесс проектирования? Какие общие черты ему свойственны?

Вот некоторые определения, взятые из книги Дж.К.Джонса "Инженерное и художественное конструирование. Современные методы проектного анализа":

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

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

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

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

Заказ - анализ – проектирование – внедрение - эксплуатация (производство, сбыт) С уверенностью можно утверждать, что общество станет иным, чем оно было до появления данного спроектированного и изготовленного объекта. Если проект оказался удачным, то его влияние совпадет с надеждами заказчика. Если же неудачным, то его влияние будет расходиться с прогнозами заказчика, но оно все же будет происходить.

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

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

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

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

Самая интересная и сложная часть разработки - формулировка задачи.

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

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

1) Целенаправленность. Процесс проектирования является целенаправленной деятельностью, формулировка цели (требований и ограничений)- отправная точка процесса проектирования.

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

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

4) Сочетание: искусство+ наука+ ремесло+ интуиция. Процесс проектирования требует от проектировщика проявления разносторонних качеств, является творчеством.

5) Требование оптимальности. Конечный результат должен быть достигнут с минимальными затратами.

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

В 1995 году группа комиссии ISO/IEC JTC (ISO – International Organization for Standardization; IEC – International Electrotechnical Commission; JTC 1 – Joint Technical Committee 1, Information technology) “Software Engineering” выпустила первую версию международного стандарта ISO/IEC 12207 “Software Lifecycle Processes”. Этот стандарт стал первым опытом создания единого общего взгляда на программную инженерию. Соответствующий национальный стандарт России – ГОСТ Р ИСО/МЭК 12207-99 [ГОСТ 12207, 1999] содержит полный аутентичный перевод текста международного стандарта ISO/IEC 12207-95 (1995 года).

К 2004 году сформулировали описание того, что сегодня мы и называем основами программной инженерии – Software Engineering:

Guideto the Software Engineering Body of Knowledge (SWEBOK), Руководство к своду знаний по программной инженерии, относящихся к вопросам создания программного обеспечения.

SWEBOK описывает 10 областей знаний:

Software requirements – программные требования Software design – дизайн (архитектура) Software construction – конструирование программного обеспечения Software testing - тестирование Software maintenance – эксплуатация (поддержка) программного обеспечения Softwareconfigurationmanagement – конфигурационное управление Software engineering management – управление в программной инженерии Software engineering process – процессы программной инженерии Software engineering tools and methods – инструменты и методы Software quality – качество программного обеспечения В дополнение к ним, SWEBOK также включает обзор смежных дисциплин, связь с которыми представлена как фундаментальная, важная и обоснованная для программной инженерии:

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

Основными задачами изучения дисциплины являются:

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

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

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

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

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

В Большой Советской Энциклопедии система определяется прямым переводом с греческого: "со-став, т. е. составленное, соединенное из частей.

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

где Z – цель, совокупность или структура целей.

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

"Система – это конечное множество функциональных элементов и отношений между ними, выделенное из cpеды в соответствии с определенной целью в рамках определенного временного интервала":

Далее, в определение системы начинают включать, наряду с элементами, связями и целями, наблюдателяN, т.е. лицо,представляющее объект или процесс в виде системы при их исследовании или принятии решения:

На необходимость учета взаимодействия между изучаемой системой и исследователем указывал еще У.Р.Эшби. Но первое определение, в которое в явном виде включен наблюдатель, дал Ю.И.Черняк: "Система есть отражение в сознании субъекта (исследователя, наблюдателя) свойств объектов и их отношений в решении задачи исследования, познания".

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

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

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

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

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

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

В связи с этим, необходимо дать еще одно определение.

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

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

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

Цель информационной системы конкретизируется заказчиком.

Далее, чтобы дать определение системы, необходимо выяснить состав системы, то есть ее подсистемы, компоненты, элементы.

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

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

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

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

при этом указанные объекты можно сгруппировать в следующие классы (обеспечивающие подсистемы):

Информационное обеспечение, в свою очередь состоящее из таких элементов, как:

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

Информационные технологии, то есть последовательность этапов сбора, обработки, передачи и хранения данных, включаемых в информационную модель, со всеми характеристиками этих этапов;

Кадровые ресурсы, отвечающие за формирование и развитие информационной модели.

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

Составляющие ПО:

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

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

Правила использования ПК и пользовательские пользователей.

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

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

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

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

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

Типовые функциональные подсистемы:

Управление персоналом;

Сбыт и реализация продукции;

Материальное снабжение (логистика);

Техническая подготовка производства;

оперативное управление;

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

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

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

Информационные системы можно классифицировать по целому ряду различных признаков:

по степени автоматизации информационных процессов;

по уровню государственного управления;

по характеру обработки данных ИС;

в зависимости от временного горизонта;

по степени интегрированности.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Информационная система оперативного уровня является связующим звеном между фирмой и внешней средой.

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

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

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

Основные функции этих информационных систем:

сравнение текущих показателей с прошлыми;

составление периодических отчетов за определенное время, а не выдача отчетов по текущим событиям, как на оперативном уровне;

обеспечение доступа к архивной информации и т.д.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нарушение принципов приводит к проблемам создания и эксплуатации системы.

Периодически появляются различные издания принципов, принадлежащие различным коллективам. Исторически первыми в СССР появились принципы проектирования АСУ, предложенные академиком В.М.Глушковым :

применении системного подхода:

деятельности системы и ее основных функций;

выявление структурных элементов и взаимосвязей между ними:

макроанализ: выделяются функции и связи элемента, микроанализ: выделяется и изучается структура элемента;

подсистемы, ….

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

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

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

Принцип эффективности - создание АСУ должно быть экономически выгодным.

Кроме перечисленных общих принципов были предложены более детальные частные принципы:

Принцип декомпозиции - разделение системы на части для последующего анализа и реализации.

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

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

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

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

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

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

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

Существуют специальные методы привлечения пользователей совместная разработка (Joint Application development).

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

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

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

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

5. Не бойтесь прекратить или переосмыслить разработку.

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

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

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

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

Понятие жизненного цикла информационных систем. Стандарты организации ЖЦ.

Технология создания крупных информационных систем (далее - ИС) связана с понятием жизненного цикла (ЖЦ).

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

Стадии жизненного цикла ИС рассматриваются в стандартах на разработку ИС. Из большого числа таких стандартов выделим международный стандарт ISO/IEC12207 и отечественную группу стандартов ГОСТ 34, поскольку именно они широко используются на практике.

ISO (Международная организация стандартизации) и IEC (международная электротехническая комиссия) образуют специализированную систему мировой стандартизации. Национальные органы, являющиеся членами ISO или IEC, участвуют в разработке международных стандартов при помощи технических комитетов, образованных соответствующими организациями, чтобы рассматривать отдельные разделы технической деятельности. В области информационной технологии ISO и IEC образовали объединенный технический комитет ISO /IEC JTC1. Проекты международных стандартов, принятые объединенным техническим комитетом, рассылаются национальным органам с целью их принятия. Публикация в качестве международного стандарта требует подтверждения от не менее, чем 75% национальных органов, принимавших участие в принятии решения.

Международный стандарт ISO/IEC 12207 был подготовлен объединенным техническим комитетом ISO/IEC JTC1,"Информационные технологии, подкомитет SC7, проектирование программного обеспечения".

Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов:

основные процессы ЖЦ ПО (приобретение, поставка, разработка (проектирование), эксплуатация, сопровождение);

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

организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).

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

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

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

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

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

каскадная модель (70-80 г.г.);

итерационная модель (80-85г.г.) спиральная модель (86-90 г.г.).

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

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

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

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

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

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

Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ [10] (рис. 5), делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.

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

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

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

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

Значительный вклад в теорию проектирования и разработки информационных систем внесла компания IBM, предложив еще в середине 1970-х годов методологию BSP (Business System Planning - методология организационного планирования). Метод структурирования информации с использованием матриц пересечения бизнес-процессов, функциональных подразделений, функций систем обработки данных (информационных систем), информационных объектов, документов и баз данных, предложенный в BSP, используется сегодня не только в ИТ-проектах, но и проектах по реинжинирингу бизнес-процессов, изменению организационной структуры. Важнейшие шаги процесса BSP, их последовательность (получить поддержку высшего руководства, определить процессы предприятия, определить классы данных, провести интервью, обработать и организовать данные интервью) можно встретить практически во всех формальных методиках, а также в проектах, реализуемых на практике.

Среди наиболее известных стандартов можно выделить следующие:

ГОСТ 34.601-90 - распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе.

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

ISO/IEC 12207:1995 - стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов.

Custom Development Method (методика Oracle) по разработке прикладных информационных систем - технологический материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle.

Применяется CDM для классической модели ЖЦ (предусмотрены все работы/задачи и этапы), а также для технологий "быстрой разработки" (FastTrack) или "облегченного подхода", рекомендуемых в случае малых проектов.

Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP - это создание и сопровождение моделей на базе UML.

Microsoft Solution Framework(MSF) сходна с RUP, также включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектноориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений.

Лекция 4. Основные рабочие процессы: Моделирование Метод структурного моделирования SADT (IDEF SADT (аббревиатура выражения Structured Analysis and Design Technique - методология структурного анализа и проектирования) - это методология, разработанная специально для того, чтобы облегчить описание и понимание искусственных систем, попадающих в разряд средней сложности. SADT была создана и опробована на практике в период с 1969 по 1973 г.

Затем эта методология была принята в качестве стандарта в ВВС США и получила название IDEF0. Настоящее время IDEF0 получил статус международного стандарта.

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

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

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

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

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

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

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

SADT-модели, реализованные в CASE средствах, ориентированы именно на функции, то есть эти модели являются функциональными.

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

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

Если модель отвечает не на все вопросы или ее ответы недостаточно точны, то мы говорим, что модель не достигла своей цели.

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

Принцип первый – принцип «черного ящика»

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

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

1. Стрелки слева Вход (Input) отображают необходимые для исполнения процесса входы.

Стрелки справа Выход(Output) отображают результаты исполнения Рис.6. Контекст системы “Образовательная деятельность” процесса (выходы).

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

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

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

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

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

Принцип третий «функции – объекты»

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

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

Объекты изображаются дугами (стрелками) и именуются существительными: «деталь», «студент», «станок», «паспорт» и т.д.

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

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

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

Контекстная диаграмма подвергается разбиению на несколько новых диаграмм. При этом уровень, следующий непосредственно за контекстной, обозначается А0. Каждому блоку на диаграмме присваивается номер, и диаграмма, являющаяся декомпозицией данного блока получит номер этого блока. На рис. представлено дерево диаграмм из модели образовательной деятельности вуза. Верхняя диаграмма (контекст) описывает образовательную деятельность. Диаграмма А0 детализирует контекст, указывая на три главные функции: организацию учебного процесса, выполнение учебного процесса и управление учебным процессом. Следующий уровень будет состоять из трех диаграмм, каждая из которых будет являться декомпозицией одной из трех функций и иметь номер соответственно А1, А2 и А3. Дальнейшая декомпозиция приведет к появлению десяти диаграмм, которые будут именоваться А11, А12, А13, А21, А22, А23, А31, А32, А33, А34. Это пример того, как SADT организует описание системы, создавая иерархию добавляющихся на каждом уровне деталей.

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

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

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

Так на рис. дуга «сотрудники института», разветвилась на две ветви:

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

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

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

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

Кроме того, что дуги могут разветвляться, они могут и сливаться.

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

метка ветви ясно указывает, что содержит ветвь).

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

Диаграмме дается название, которое располагается в центре нижней части ее бланка. На каждой диаграмме написана стандартно идентифицирующая ее информация: автор диаграммы, частью какого проекта является работа, дата создания или последнего пересмотра диаграммы, статус диаграммы (рабочая версия (working), эскиз (draft), рекомендовано (recommended), принято (publication). Указывается, кто являлся экспертом диаграммы и когда он ее проверял (reader, date). Вся идентифицирующая информация располагается в верхней части бланка диаграммы(рис.7.).

В правом верхнем углу указывается место диаграммы в модели, а в нижней части бланка расположен номер диаграммы А-0 (то есть, контекст) и ее название, в данном примере это «Образовательная деятельность».

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

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

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

1.1. Выход – вход, то есть связь между выходом предыдущей функции и входом последующей:

Такие связи присутствуют в случае моделирования различных стадий жизненного цикла какого-то процесса. Функции относятся к одному типу.

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

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

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

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

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

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

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

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

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

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

Сложность объектов автоматизации определяется числом элементов и связей между ними. Число элементов можно оценить количеством персонала, номенклатурой средств труда, предметов труда, готовой продукции и т.п., а количество связей - количеством информации, используемой для управления. Количество связей зависит от количества элементов.

Современные объекты автоматизации – это сложные системы, состоящие из тысяч элементов и связей.

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

Декомпозицию можно рассматривать как один из способов борьбы со сложностью.

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

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

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

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

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

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

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

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

Основные известные стратегии декомпозиции.

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

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

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

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

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

СтратегияРЗ (people, papers, procedures). Стратегия, основанная на описании взаимодействия персонала и функций, выполняемых каждым отдельным лицом. Данную стратегию рекомендуется использовать только в начале работы, в тех случаях, когда объем сведений о системе не достаточен.

На рис. 8,9,10 показаны результаты применения различных стратегий к одной и той же исходной системе – «Выполнение учебного процесса».

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

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

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

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

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

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

стратегический (от 5 до 20 лет), тактический, или среднесрочный,(от 1года до 5 лет) и оперативный, или краткосрочный (от одного дня до 1 года). Может быть и другая, более уточняющая градация.

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

специализированные функции управления (бизнес-функции) функции организации и общие функции управления Рис.10 Пример использования стратегии «по жизненному циклу»

Построив матрицу, менеджер может увидеть полный набор всех функций, а после этого заняться проектированием этих функций, то есть приданием им смыслового содержания и описанием с использованием CASEсредств. Данный подход полезен и в процессе реинжиниринга. В этом случае в рамках указанного подхода строится модель TO-BE и сравнивается с моделью AS-IS, построенной на основе функций, выполняемых на фирме. Сравнение двух указанных моделей дадут ключ к реформированию процесса стратегического менеджмента, реструктуризации дерева целей и, возможно, переосмысления миссии.

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

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

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

Данная методика помогает проводить анализ моделей.

На этапе обследования предприятия с помощью Bpwin строятся диаграммы AS-IS, то есть описывается реальное состояние дел на предприятии. На этапе анализа строится уже «идеальная» функциональная модель с применением описанной методики (модель TO-BE). Построенные модели сравниваются между собой, и принимается решение по изменению функций предприятия и автоматизации некоторых из них. Как правило, автоматизации подлежат функции учета, контроля и анализа (функции управления), а также функции планирования, и отчасти функции проектирования технологических процессов (функции организации). Опыт разработки информационных систем позволяет утверждать, что уже на первых этапах проектирования, можно говорить об эффекте от проделанной работы, так эти этапы позволяют упорядочить выполняемые функции и избежать их дублирования.

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

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

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

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

Реинжиниринг бизнес-процесса (BPR— Business process reengineering) появился в зарубежной практике в начале 1990-х годов и рассматривался как дальнейшее развитие инжиниринга и, в частности, системно-технического подхода к развитию проектирования бизнеспроцессов.

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

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

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

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

Основателями теории реинжиниринга являются Майкл Хаммер и Джеймс Чампи, которые выпустили книгу «Реинжиниринг корпорации:

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

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

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

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