1.56M

Category:

software

Проектирование корпоративных информационных систем (КИС)

1.

7 Проектирование КИС
1. Жизненный цикл (ЖЦ) КИС.
2. Стандарты разработки КИС.
Этапы и модели разработки КИС,
формируемые документы.
3. Подходы к проектированию КИС.
Методологии проектирования КИС.
4. Реинжиниринг КИС и его место в ЖЦ
информационной системы.
Методы и технологии реинжиниринга ИС.

2.

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

3.

7.2 Стандарты разработки КИС
ISO/IEC 12207 – стандарт на процессы и
организацию жизненного цикла, который
распространяется на все виды программного
обеспечения;
Rational Unified Process (RUP) –
итеративная методология разработки
включающая четыре фазы: начало,
исследование, построение и внедрение;

4.

Rapid Application Development (RAD) –
методология быстрой разработки приложений,
представляющая комплекс специальных
инструментальных средств, позволяющих
оперировать с определенным набором
графических объектов, функционально
отображающих отдельные компоненты
приложений;
Custom Development Method (CDM) –
методология по разработке прикладных ИС,
рассчитанных на использование в проектах с
применением компонентов Oracle.

5.

Процессы разработки КИС
Стандарт ISO/IEC 12207 определяет структуру жизненного
цикла, включая процессы, работы и задачи, выполняемые при
создании ИС.
Процессы, в рамках которых могут
выполняться работы в ЖЦ ИС :
основные;
вспомогательные;
организационные.

6.

К основным процессам относятся:
ЗАКАЗ
ПОСТАВКА
РАЗРАБОТКА
ЭКСПЛУАТАЦИЯ
СОПРОВОЖДЕНИЕ

7.

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

8.

ПОСТАВКА –
принятие решения о подготовке
предложения в ответ на заявку,
присланную заказчиком,
или с подписания договора по поставке
ИС;
определение процедур и ресурсов,
необходимых для выполнения проекта,
включая разработку проектных планов и
их выполнение посредством поставки ИС
(выполняется поставщиком);

9.

РАЗРАБОТКА –
анализ требований,
проектирование, программирование,
сборка, тестирование,
ввод в действие и приемка ИС
(выполняет разработчик);
ЭКСПЛУАТАЦИЯ –
подготовка процесса;
эксплуатация системы;
поддержка пользователя
(выполняет разработчик);

10.

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

11.

К вспомогательным процессам жизненного
цикла относятся:
ДОКУМЕНТИРОВАНИЕ
УПРАВЛЕНИЕ КОНФИГУРАЦИЕЙ
ОБЕСПЕЧЕНИЕ КАЧЕСТВА
ВЕРИФИКАЦИЯ
АТТЕСТАЦИЯ
СОВМЕСТНЫЙ АНАЛИЗ
АУДИТ
РАЗРЕШЕНИЕ ПРОБЛЕМ

12.

ДОКУМЕНТИРОВАНИЕ –
формализованное описание информации,
созданной в процессе ЖЦ
(набор работ, при помощи которых
планируют, проектируют, разрабатывают,
выпускают, редактируют, распространяют и
сопровождают те документы,
в которых нуждаются заинтересованные лица,
т.е. администраторы, инженеры и пользователи
ИС);

13.

УПРАВЛЕНИЕ
КОНФИГУРАЦИЕЙ –
административные и технические процедуры на
всем протяжении ЖЦ программных средств
определение и установление состояния ПО ИС;
управление изменениями объектов ИС;
обеспечение полноты, совместимости и
правильности объектов ИС;
управление хранением, обращением и поставкой
объектов ИС

14.

ОБЕСПЕЧЕНИЕ КАЧЕСТВА –
обеспечение гарантий, что программные
продукты и процессы в жизненном цикле
соответствуют установленным требованиям и
утвержденным планам.
Для обеспечения качества могут использоваться
результаты других вспомогательных процессов
(верификация, аттестация, совместный анализ,
аудит и решение проблем);
ВЕРИФИКАЦИЯ –
подтверждение соответствия конечного
продукта предопределенным эталонным
требованиям;

15.

АТТЕСТАЦИЯ – определение полноты
соответствия созданной ИС установленным
требованиям и функциональному назначению;
СОВМЕСТНЫЙ АНАЛИЗ – оценка состояний
и при необходимости результатов работ по
проекту;
АУДИТ – определение соответствия
разработанной ИС требованиям, планам и
условиям договора;
РАЗРЕШЕНИЕ ПРОБЛЕМ – анализ и
решение проблем, обнаруженных при реализации
проекта по созданию ИС

16.

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

17.

К организационным процессам жизненного
цикла относятся:
УПРАВЛЕНИЕ
СОЗДАНИЕ
ИНФРАСТРУКТУРЫ
УСОВЕРШЕНСТВОВАНИЕ
ОБУЧЕНИЕ

18.

УПРАВЛЕНИЕ – планирование и
управление процессами, включая контроль,
проверку и оценку выполненных работ с
формированием отчетности;
СОЗДАНИЕ ИНФРАСТРУКТУРЫ –
установление и обеспечение инфраструктуры,
необходимой для любого процесса (технических
и программных средств, инструментальных
средств, методик, стандартов и условий для
разработки, эксплуатации и сопровождения);

19.

УСОВЕРШЕНСТВОВАНИЕ –
установление, оценка, измерение,
контроль и улучшение любого
процесса жизненного цикла
программных средств;
ОБУЧЕНИЕ – планирование и
проведение обучения персонала,
разработка учебных материалов.

20.

Этапы и модели разработки ИС,
формируемые документы.
Стандарт ISO 12207 описывает структуру процессов ЖЦ ИС, но не
конкретизирует в деталях, как реализовать или выполнить действия и
задачи, включенные в эти процессы.
Модель ЖЦ ИС –
структура, определяющая
последовательность выполнения и
взаимосвязи процессов, действий и задач,
выполняемых на протяжении ЖЦ ИС.

21.

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

22.

Под стадией понимается определенный
этап процесса разработки ИС.
Наиболее распространено деление
следующие четыре этапа:
1) начало;
2) проектирование;
3) разработка;
4) внедрение.
ЖЦ
на
Границы каждой стадии задаются временными моментами, в
которые необходимо принимать определенные критические решения и
достигать определенных ключевых целей.

23.

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

24.

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

25.

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

26.

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

27.

Наиболее распространенными моделями ЖЦ
являются: КАСКАДНАЯ МОДЕЛЬ;
СПИРАЛЬНАЯ МОДЕЛЬ.
Каскадная модель ЖЦ ИС предусматривает
последовательную организацию работ.
Ее основной особенностью является
разбиение всей разработки на этапы,
переход с одного этапа на следующий происходит только
после того, как полностью завершены все работы на
предыдущем.
Каждый этап завершается выпуском полного комплекта
документации, достаточной для того, чтобы разработка
могла быть продолжена другой командой разработчиков.

28.

Основные этапы разработки ИС по
каскадной модели:
1) АНАЛИЗ ТРЕБОВАНИЙ ЗАКАЗЧИКА;
2) ПРОЕКТИРОВАНИЕ;
3) РАЗРАБОТКА;
4) ТЕСТИРОВАНИЕ И ОПЫТНАЯ
ЭКСПЛУАТАЦИЯ;
5) ВВОД В ДЕЙСТВИЕ ГОТОВОГО
ПРОДУКТА.

29.

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

30.

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

31.

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

32.

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

33.

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

34.

КАСКАДНАЯ МОДЕЛЬ
Анализ
Проектирование
Разработка
Тестирование
Ввод в действие

35.

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

36.

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

37.

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

38.

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

39.

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

40.

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

41.

СПИРАЛЬНАЯ МОДЕЛЬ

42.

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

43.

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

44.

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

45.

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

46.

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

47.

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

48.

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

49.

ПОДХОДЫ К ПРОЕКТИРОВАНИЮ ИС:
канонический и типовой.
Каноническое проектирование ИС
применяется для сравнительно небольших,
локальных ИС;
использует инструментальные средства
универсальной компьютерной поддержки
проектирования;
ориентировано на использование, главным
образом, каскадной модели ЖЦ ИС.

50.

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

51.

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

52.

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

53.

Этапы параметрически-ориентированного
проектирования:
1) определение критериев оценки пригодности
ТПР для решения поставленных задач;
2) анализ и оценка доступных ТПР по
сформулированным критериям;
3) выбор и закупка наиболее подходящего ТПР;
4) настройка параметров (доработка) закупленного
ТПР;
5) интеграция нескольких ТПР (при
необходимости);
6) обучение персонала;
7) эксплуатация и адаптация (при необходимости).

54.

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

55.

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

56.

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

57.

Этапы модельноориентированного проектирования:
1) анализ требований к конкретной ИС;
2) оценка и выбор ТПР, удовлетворяющих
требованиям;
3) построение предварительной модели ИС на базе
имеющихся в ТПР типовых моделей;
4) выбор типовой модели системы;
5) определение перечня компонентов, которые
будут реализованы с использованием других
программных средств или потребуют разработки с
помощью имеющихся в составе типовой ИС
инструментальных средств.

58.

Модели деятельности организации создаются
в двух вариантах:
модель «как есть» («as-is»), фиксирующая
существующие в организации бизнес-процессы;
модель «как должно быть» («to-be»),
отражающая необходимые изменения бизнеспроцессов с учетом внедрения ИС.

59.

Методологии проектирования КИС
существуют различные подходы к
моделированию ИС
СТРУКТУРНЫЙ,
ФУНКЦИОНАЛЬНЫЙ,
ОБЪЕКТНООРИЕНТИРОВАННЫЙ.

60.

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

61.

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

62.

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

63.

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

64.

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

65.

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

66.

67.

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

68.

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

69.

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