1

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

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

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

Ресурсы корпораций включают:

1. материальные (материалы, готовая продукция, основные средства)

2. финансовые

3. людские (персонал)

4. знания (ноу-хау)

5. КИС

2

Классификация КИС.

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

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

3

Характеристики КИС:

1. Архитектура информационной системы - состав элементов и их взаимодействие;

2. Сетевые технологии, их масштабы и топология сети;

3. Функциональная структура управления, реализованная в информационной системе (состав подсистем, комплексов задач);

4. Организационная форма хранения информации (централизованная или распределенная база данных);

5. Пропускная способность системы - скорость обработки транзакций;

6. Объем информационного хранилища данных;

7. Системы документов и документооборот;

8. Количество пользователей КИС;

9. Пользовательский интерфейс и его возможности;

10. Типовые информационные технологии процессов сбора, передачи, обработки, хранения, извлечения, распространения информации.

4

Требования, предъявляемые к КИС

1.Системность;

2.Комплексность.

3.Модульность;

4.Адаптивность;

5. Надежность(защита данных от потер);

6. Сохранение ценности и непротиворечивости данных;

7.Безопасность(предотвращение несанкционированного доступа к данным внутри системы и из вне);

8.Масштабируемость;

9.Мобильность (переход на более производительную аппаратно-программную платформу);

10.Простота в изучении;

11.Поддержка внедрения и сопровождения со стороны разработчика.

5

Архитектура КИС

состоит из нескольких уровней.

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

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

Системный уровень.Операционные системы и сетевые средства.

Аппаратный.Средства вычислительной техники.

Транспортный.Активное и пассивное сетевое оборудование, сетевые протоколы и технологии.

6

История развития Корпоративных ИС

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

7

«Жизненный цикл» информационных систем.

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

ЖЦ можно разделить на след. стадии:

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

2.проектирования – результатом стадии проектирования явл-ся системный проект. Самая длительная по времени.

3.стадия разработки . Разработка ИС.

4.стадия внедрения. Опытная эксплуатация сис-мы. Выявление и исправление ошибок.

5. стадия промышленной эксплуатации.

6.Стадия модернизации.

8

Стадии проектирования информационных систем.

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

Этапы ЖЦ: 1) анализ требований1.1 проверка аппаратных и программных ресурсов, внеш.усл.функционирования, состав людей и работ1.2 очистка функций системы 1.3 ограничение в процессе 2) СТАДИЯ ПРОЕКТИРОВАНИЯ 2.1 обследование деятельности предприятия: определение организац.штабной и дивизионной структуры; определение основных задач деятельности предприятия; построение функциональной модели деятельности предприятия;2.2 разработка системного проекта: разработка структурной функциональной модели деятельности методами IDEF0,DFD.(BPWin); разработка информационной модели предприятия IDEF1X, ERD(ERWin); разработка событийной модели предприятия.2.3 разработка предложений по автоматизации предприятия: системного перечня автоматизированных рабочих мест и способов взаимодействия между ними; анализ применимости существующих систем предприятия; решение о выборе конкретных систем управления предприятия; разработка требований к техническим средствам; -//- персоналу; разработка предложений по этапам и срокам реализации.2.4 разработка технического проекта: проектирование архитектуры системы(авто раб мест); детальное проектирование; проектирование программного модуля 3. Программирование 4. Тестирование и отладка 5. Эксплуатация и сопровождение.

9Модель жизненного цикла по

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

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

Преимущества: Полная и согласованная документация на каждом этапе; Легко определить сроки и затраты на проект. Недостатки: 1) реальный процесс создания ПО некогда полностью не укладывается в жесткую схему. 2) возникает потребность возвращается к предыдущим этапам.

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

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

10

Методолгии и технологии проектирования ИС:

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

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

-Технология должна поддерживать полный ЖЦ ПО;

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

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

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

11

Case-технологии

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

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

Системы интеллектуального проектирования и совершенствования систем управления предназначены для использования так называемых CASE-технологий, ориентированных на автоматизированную разработку проектных решений по созданию и совершенствованию систем организационного управления (например, CASE-Аналитик, Ideff/Desing, Selviran).

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

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

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

12

Классификация case-средств:

1) средства анализа предназначены для построения и анализа модели предметной области(Design/ IDEF, BPWin).

2) средства анализа и проектирования (Design\ 2000, PROIV)

3) средства проектирования БД, обеспечивающие моделирование данных и генерацию схе БД (ERION, data base designer) 4) средства разработки приложений (uniface, poker builder.)

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

1) По поддерживаемым методологиям проектирования: функ­ционально (структурно)-ориентированные, объектно-ориентированные и комплексно-ориентированные (набор методологий проектирования);

2) По поддерживаемым графическим нотациям построения диаграмм: с фиксированной нотацией, с отдельными нотациями и наиболее распространенными нотациями;

3) По степени интегрированности: tools (отдельные локальные средства), toolkit (набор неинтегрированных средств, охватывающих большинство этапов разработки ЭИС) и workbench (полностью интегрированные средства, связанные общей базой проектных данных - репозиторием);

4) По типу и архитектуре вычислительной техники: ориентированные на ПЭВМ, ориентированные на локальную вычислительную сеть (ЛВС), ориентированные на глобальную вычислительную сеть (ГВС) и смешанного типа;

5) По режиму коллективной разработки проекта: не поддерживающие коллективную разработку, ориентированные на режим реального времени разработки проекта, ориентированные на режим объединения подпроектов;

6) По типу операционной системы (ОС): работающие под управлением WINDOWS 3.11 и выше; работающие под управлением UNIX и работающие под управлением различных ОС (WINDOWS, UNIX, OS/2 и др.).

13

Структурный подход к проектированию ИС:

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

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

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

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

• принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;

• принцип непротиворечивости - заключается в обоснованности и согласованности элементов;

14

Методология функционального моделирования SADT

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

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

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

• ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);

• связность диаграмм (номера блоков);

• уникальность меток и наименований (отсутствие повторяющихся имен);

• синтаксические правила для графики (блоков и дуг);

• разделение входов и управлений (правило определения роли данных).

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

15

Быстрая разработка приложений - Rapid Application Development (RAD)

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

Этапы: 1) бизнес-моделирование 2) моделирование данных – индентификация характеристик каждого объекта(св-ва, атрибуты) и отношений между ними.3) моделирование обработки – создаются описания обработки для нахождения, добавления, модификации, управления или нахождения объектов, данных.4) генерация приложений 5) тестирование и определение.

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

Основные принцмпы построения RAD:

1. Разработка приложений интерациями(блоками).

2. Обязательное вовлечение пользователей в процесс разработки системы.

3. Необходимое применение case-средств, обеспечивающих целостность проекта.

4. Использование генераторов кода.

5. Тестирование и развитие проекта осущ-ся одновременно с разработкой.

6. Ведение разработки

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

16

Функциональное моделирование бизнес-процесссов(типы моделей, типы диаграмм.)

Бизнес-процесс – это логичный, последовательный, взаимосвязанный набор мероприятий, который потребляет ресурсы, создаёт ценность и выдаёт результат

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

Типы моделей:

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

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

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

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

Наиболее распространенные виды моделей(диаграмм):

• SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;

• DFD (Data Flow Diagrams) диаграммы потоков данных;

• ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".

17

Основные строительные блоки для диаграмм IDEF0

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

• Управляющая информация входит в блок сверху.

• Входная информация входит в блок слева.

• Результаты выходят из блока справа.

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

Каждый компонент модели может быть декомпозирован (расшифрован более подробно) на другой диаграмме. Рекомендуется прекращать моделирование, когда уровень детализации модели удовлетворяет ее цель. Общее число уровней в модели не должно превышать 5-6. Построение диаграмм начинается с представления всей системы в виде одного блока и дуг, изображающих интерфейсы с функциями вне системы. Затем блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами. Каждая детальная диаграмма является декомпозицией блока из диаграммы предыдущего уровня. На каждом шаге декомпозиции диаграмма предыдущего уровня называется родительской для более детальной диаграммы. На таких диаграммах не указаны явно ни последовательность, ни время. Метод обладает рядом недостатков: сложность восприятия (большое количество дуг на диаграммах и большое количество уровней декомпозиции), трудность увязки нескольких процессов.

18

Методология IDEF3.

Этот метод предназначен для моделирования последовательности выполнения действий и взаимозависимости между ними в рамках процессов. Логическая последовательность выполнения процедур. IDEF3 предполагает построение 2-х типов моделей: 1) модель может отражать некоторые процессы в их логической последовательности. 2) модель может показать сеть переходных состояний объекта.

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

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

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

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

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

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

19

Основные блоки диаграмм IDEF3.

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

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

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

3 ) связь-предшествования показывает, что прежде, чем начнется работа-приемник, должна закончится работа-источник.

4 ) связь-отношения показывает связь между 2-мя работами и объектом ссылки.

5 ) связь «поток-объектов» показывает участие некоторого объекта в 2-х или более работах.

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

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

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