- каждая подсистема
должна реализовывать единственную функцию
системы, атомарную с точки зрения пользователя;
- функция каждой
подсистемы должна быть легко понимаема
независимо от сложности ее реализации;
- связь между
подсистемами должна вводиться только
при наличии связи между соответствующими
функциями системы;
- связи между
подсистемами (интерфейсы подсистем) должны
быть простыми, насколько это возможно,
для обеспечения независимости между
ними.
2.12
Иерархия процессов
.
2.
Второй важной идеей, лежащей
в основе структурных методов, является
идея иерархии.
Для
«понимаемости» сложной системы
недостаточно разбиения ее на части,
необходимо эти части организовать определенным
образом, а именно в виде иерархических
структур. Все сложные системы Вселенной
организованы в иерархии. Да и сама она
включает галактики, звездные системы,
планеты, …, молекулы, атомы, элементарные
частицы.
Человек
при создании сложных систем также
подражает природе. Любая организация
имеет директора, заместителей по направлениям,
иерархию руководителей подразделений,
рядовых служащих (организационно – штатная
структура предприятия).
2.13
Графические нотации
.
3.
Последним моментом использования структурных
методов является использование различных
графических нотаций, диаграммы которых
служат для облегчения понимания сложных
систем.
Известно,
что “одна картинка стоит тысячи
слов”.
Существует
наиболее устоявшийся перечень атрибутов,
которые модель бизнес-процессов должна
описывать на изобразительном уровне,
а именно:
- воздействия,
инициирующие каждый шаг бизнес - процесса;
- исполнители
каждого шага (это могут быть как люди,
так и программы и механизмы);
- воздействия,
регламентирующие данный шаг (законодательные
акты, рыночные условия и т. п.);
- результат,
получаемый на выходе конкретного шага
бизнес - процесса.
2.14
Пример
.
Анализ.
Частота
издания телефонного справочника
предприятия.
Его объем
и себестоимость.
Количество
исправлений – изменений за определенный
срок.
Количество
устанавливаемых, например, ежедневно
контактов.
Среднее
время установления контакта (нормирование).
Влияние
рассмотренных факторов на деятельность
предприятие, на его основные показатели.
Решение:
разработать электронный справочник
включающий:
- серверную
БД;
- клиентскую
часть, включая локальную БД;
- подсистему
автоматического обновления;
- подсистему
администрирования;
- подсистему
подготовки печатного издания;
- модуль аналитических
расчетов, по количеству обращений, установленных
контактов, прогнозирование увеличения
адресов электронной почты и списков рассылок;
- web – интерфейс
доступа.
Согласно
методологии структурного проектирования
необходимо:
- провести
декомпозицию, необходимое количество
уровней;
- построить
иерархическую структуру процессов;
- определить
взаимодействие процессов;
- определить
пользователя и входные/выходные данные
каждого процесса.
2.15
Стандарты
.
SPC (Software
Productivity Consortium) выделяет тот минимум
стандартов на процессы проектирования,
который рекомендуется взять за основу.
В их число включены ISO/IEC 12207, ISO/IEC
15288 CD2, ISO 15504 (SPICE), EIA/ANSI 632, EIA/IS 731 (SECM), TickIT.
Назначение
следующих нормативных документов
(НД):
- ISO/IEC 12207, Information
technology - Software life cycle processes. 1995.
- ISO/IEC TR 15271,
Information technology - Guide for ISO/IEC 12207. 1998. (Стандарт
ISO/IEC 12207 оказал революционизирующее влияние
на многие другие НД, в том числе на стандарты
моделей системного проектирования: процессы
жизненного цикла систем, модель зрелости
процессов.)
- EIA/ANSI 632, Processes
for Engineering a System. 1999. (Этот стандарт не только
заменил ряд популярных более старых американских
стандартов, но был использован как вклад
американской группы в создание ISO/IEC 15288.)
- EIA/IS-731, System
Engineering Capability Model (SECM). 1999. Part 1, SECM Model. Part
2, SECM Appraisal Method. (В области стандартов на
уровни зрелости процессов аналогично
тому, как модель SW CMM переросла в модель
и стандарт SPICE, модель SE CMM переросла в
модель и стандарт SECM.)
- ISO/IEC 15288 CD2,
Life Cycle Management - System Life Cycle Processes. 2000.
Для
обеспечения преемственности полезно
добавить в эту группу стандарты
ГОСТ 34 (не гармонизированные с новыми,
но применимые и полезные из-за совместимости
по многим базовым понятиям, по сути многих
работ, по опыту применения и др.).
Существенно,
что два «потока» стандартов - на
SE (system engineering) и на SW (software engineering), развивавшихся
параллельно, четко стыкованы посредством
указанных документов.
И дело не только в
том, что указанные документы
хорошо согласованы друг с другом
по основным понятиям и принципам. Очень
важно, что такие, казалось бы, «чисто
технические» области, как создание
ПО (SW-процессы), регламентированы стандартами,
прямо требующими их совместного применения
со стандартами на процессы системного
проектирования (SE-процессы).
2.16
Методологические принципы проектирования
ИС
.
(11 номер
КП за 2001г.)
Концептуальное
моделирование - для определения направления
развития предприятия.
Логическое
моделирование - для описания деятельности
предприятия CASE-средствами.
Физическое
моделирование - для формализации деятельности
предприятия средствами ERP-системы (то
есть для создания нормативной модели
предприятия).
Концептуальная
модель является отраслевой моделью
и, как правило, разрабатывается
для предприятия внешним консультантом
(обычно на основе эталонных моделей,
предлагаемых поставщиками ERP-систем).
В ней определяются основные направления
развития предприятия через графическое
представление передовой мировой практики
(заключенной в стандарты ISO и ERP) и через
определение несоответствий деятельности
предприятия данной практике (на основе
проведения сопоставительного анализа
- benchmarking). Концептуальная модель подразумевает
унификацию основных процессов предприятия
в соответствии со стандартами ISO 9001:2000
и ERP.
2.17
Концептуальная модель
.
Эталонная
модель с использованием ISO 9000 переводится
в IDEF0-модель, отображающую:
- декомпозицию
процессов предприятия - верхний уровень
иерархии процессов соответствует элементам
и подэлементам стандарта ISO 9001:2000, а нижние
уровни раскрываются с использованием
ERP-стандарта;
- проектирование
графического «скелета» документации
системы менеджмента качества (СМК) предприятия;
- определение
ключевых пользователей процессов и бизнес
- функций;
- определение
на базе ERP-системы основных модулей информационной
системы предприятия, обеспечивающих
выполнение процессов;
- определение
связей процессов по входам/выходам.
2.18
Логическая модель
.
Второй
уровень бизнес - моделирования
логический, необходим для уточнения основных
выводов, следующих из концептуальной
модели.
Цель
логического моделирования - построить
интегрированную модель деятельности
предприятия, являющейся связующим звеном
между бизнес - методиками и ERP-системой.
Логическая
модель описывает деятельность предприятия,
посредством объектно-ориентированного
проектирования (опираясь на методологию
бизнес - моделирования RUP9 и нотации UML10)
или структурного
проектирования.
Логическая
модель позволяет спланировать, как
нужно реорганизовать текущие способы
выполнения процессов предприятия в желаемые
- вплоть до каждого рабочего места.
Модель
помогает детально ответить на следующие
вопросы:
- кто и где
исполняет бизнес - функции (организационный
аспект деятельности);
- что перемещается
в материальных и в связанных с ними информационных
потоках (элементный аспект деятельности
предприятия);
- как предприятие
выполняет бизнес - функции (функциональный
аспект);
- когда предприятие
осуществляет бизнес - функции (динамический
аспект);
- какая информационная
платформа (какие инструменты) необходима
для поддержания бизнес - функций на предприятии.
2.19
Взаимодействие
.
На рисунке
представлено взаимодействие функционального,
организационного, элементного, динамического
аспектов логической модели и приведены
примеры наиболее часто используемых
диаграмм (диаграммы пакетов, прецедентов,
классов, деятельности).
В рамках
функционального аспекта описываются:
- иерархическая
структура процессов;
- взаимодействие
процессов (реализация процессного подхода).
Процессы
на предприятии определяются наличием
конечного продукта (не обязательно материального),
у которого есть потребитель и поставщик.
Отношения «поставщик - потребитель» рассматриваются
не только с внешними контрагентами, но
и внутри предприятия.
В рамках
организационного аспекта описываются:
- организационная
структура предприятия, включающая в себя
иерархию подразделений, отделов, участков,
должностей, рабочих мест;
- топология
предприятия: местоположения хранения
складских запасов, рабочие центры выполнения
операций, поточные линии.
Для описания
топологии и оргструктуры предприятия
предлагается использовать диаграммы
прецедентов (Use case), где отражается
иерархия подчинения действующих лиц
и организационных единиц.
В
рамках элементного аспекта описываются
единицы материального, информационного
и финансового потоков (единицы документооборота,
товарооборота и финансовые инструменты)
для каждого процесса предприятия.
Составляющие
элементного аспекта используются
при описании текущих и желаемых
способов выполнения процессов. Взаимодействие
объектов (или документооборот для информационных
объектов) одного и того же процесса зависит
от конкретной ситуации и конкретного
способа выполнения этого процесса.
Для
описания элементного аспекта предприятия
предлагается использовать диаграмму
классов (Class), а для отражения возможных
состояний элементов - диаграмму состояний
(State).
В
рамках динамического аспекта реализуется
ситуационный подход:
- определяются
способы выполнения процесса в зависимости
от конкретной ситуации, поскольку, как
известно, процесс может быть реализован
разными последовательностями действий.
Процесс может выполняться несколькими
способами, и выбор способа определяется
конкретной ситуацией с привлечением
того или иного ответственного лица. Описание
каждого процесса включает диаграмму
прецедентов (в трактовке диаграммы бизнес
- сценариев), описывающую способы выполнения
процессов и определяющую ответственных
лиц, участвующих в выполняемых действиях.
Для описания взаимодействия процессов
(в специальной папке «Сценарии») также
используются диаграммы сценариев (прецедентов),
где кроме описания способов отражаются
информационные и материальные объекты,
являющиеся результатом выполнения процесса
или использующиеся для его инициализации;
- определяются
взаимодействия организационного, элементного
и функционального аспектов, то есть раскрывается
способ выполнения процесса. Для этого
предлагается использовать диаграммы
деятельности (Activity), где отражается взаимосвязь
процессов на предприятии с ERP-системой;
- определяется
документооборот (или товарооборот) между
организационными единицами. Документооборот
описывается для каждого способа выполнения
процесса. Для описания взаимодействия
документов и исполнителей предлагается
использовать диаграммы кооперации (Collaborations).