Logo GenDocs.ru

Поиск по сайту:  


Загрузка...

Лекции - Курс лекций по автоматизированным системам управления - файл 1.doc


Лекции - Курс лекций по автоматизированным системам управления
скачать (8603.5 kb.)

Доступные файлы (1):

1.doc8604kb.18.12.2011 02:37скачать

содержание
Загрузка...

1.doc

1   2   3   4   5   6   7   8   9   10   ...   20
Реклама MarketGid:
Загрузка...

ЛЕКЦИЯ 6


^ Прогнозирование экономических процессов

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

Для систем управления предприятием наиболее важными мо­ментами являются:

• иерархия прогнозов;

• структура формирования прогнозов;

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

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

• сочетание прогнозирования и планирования. Ниже приводятся примеры основных прогнозов.

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

2. Среднесрочные прогнозы. Горизонт прогнозирования — месяцы. Объекты прогнозирования' новые типы или группы продукции;

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

3. Краткосрочные прогнозы. Горизонт прогнозирования — недели. Объекты прогнозирования: отдельные наименования продукции;

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

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

Ниже приводятся основные качественные методы.

^ 1. Мозговой штурм. Рабочей группе предоставляется любая необ­ходимая информация из БД предприятия и внешних БД. Участники группы создают индивидуальные прогнозы. Крайние прогнозы от­брасываются, а роль компромиссного выполняет прогноз, основан­ный на оставшихся индивидуальных прогнозах.



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

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

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

^ 5. Исторические аналогии. Маркетинговые исследования, опро­сы, интервью, пробные продажи позволяют сформировать основу для проверки гипотез относительно поведения реального рынка.

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

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

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

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

^ Тренд — это постоянная, долговременная тенденция.

Циклическая составляющая описывает ту часть процесса, кото­рая повторяется с низкой частотой.

^ Сезонная составляющая описывает циклы, повторяющиеся с высокой частотой в течение года.

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

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

Наиболее часто применяются следующие количественные моде­ли прогнозирования.

^ 1. Линейная регрессия. Модель направлена на выявление связи между зависимой переменной (т. е. прогнозируемой величиной) и одной или более независимыми переменными, которые представ­лены в виде данных о предыстории. В простой регрессии имеется только одна независимая переменная, а во множественной рег­рессии их несколько. Если предыстория представлена в виде вре­менного ряда, то независимая переменная — это временной период, а зависимая — прогнозируемая величина, например объем продаж.

^ 2. Методы скользящего среднего. Прогностическая модель для краткосрочных прогнозов, основанная на временных рядах. В ней среднее арифметическое фактических показателей, вычисленное для принятого числа последних прошедших временных периодов, принимается за прогноз на следующий временной период.

^ 3. Метод взвешенного скользящего среднего. Эта модель работает подобно предыдущей модели, но в ней вычисляется не среднее, а средневзвешенное значение, которое и принимается за прогноз на ближайший временной период. Меньшие веса приписываются бо­лее отдаленным периодам.

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

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

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

Вариант 1. Потребности вычисляются на основе фактического имеющегося спроса.

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

Вариант 3. Материальные потребности определяются на основе прогнозируемого спроса.

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

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

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

ПРИМЕЧАНИЕ:

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

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

  • ограниченность конечной цели;

  • ограниченность продолжительности;

  • ограниченность бюджета;

  • ограниченность требуемых ресурсов;

  • новизна для предприятия, для которого реализуется проект;

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

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

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

  • материалов;

  • оборудования;

  • человеческих ресурсов.

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



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

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

  • объем работ;

  • сроки выполнения;

  • себестоимость;

  • экономическая эффективность, обеспечиваемая реализацией проекта;

  • социальная и общественная значимость проекта.


Классификация проектов

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

Класс проекта определяется по составу и структуре проекта. Обычно различают:

  • монопроект (отдельный проект, который может быть любого типа, вида и мас­штаба);

  • мультипроект (комплексный проект, состоящий из ряда монопроектов и тре­бующий применения многопроектного управления).

Тип проекта определяется по основным сферам деятельности, в которых осуще­ствляется проект. Можно выделить пять основных типов проекта:

  • технический;

  • организационный;

  • экономический;

  • социальный;

  • смешанный.

ПРИМЕЧАНИЕ:

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

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

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


Масштаб проекта определяется по размерам бюджета и количеству участников:

- мелкие проекты;

- малые проекты;

- средние проекты;

- крупные проекты.

Можно также рассматривать масштабы проектов в более конкретной форме — отраслевые, корпоративные, ведомственные проекты, проекты одного предпри­ятия.

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

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

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

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

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

Сетевое планирование и управление включает три основных эта­па: структурное планирование, календарное планирование, опера­тивное планирование.

В структурное планирование входит: разбиение проекта на опера­ции; оценка продолжительности операций и построение сетевой модели; анализ модели на непротиворечивость.

^ Календарное планирование включает: расчет критического пути с выявлением критических операций; определение ранних и поздних времен завершения операций; определение резервов времени для некритических операций.

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

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

На рис. 7 показан пример сетевой модели.

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

Критические операции в примере, показанном на рис. 7: (0,2), (2,3), (3,4), (4,5), (5,6).



Рис. 7

Для некритических операций вычисляются резервы времени. Раз­личают два основных вида резервов времени:

^ 1. Полный резерв. Он определяется соотношением:

Полный резерв = (позднее время завершения операции — ран­нее время начала операции) — длительность операции.

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

Резервы важны, потому что, сдвигая работы в рамках резервов, можно добиться удовлетворения ограничений на ресурсы или их наиболее равномерного использования. При распределении ресур­сов возникает многовариантная задача, которая может быть описа­на как оптимизационная. В ряде базовых систем ERP и самостоя­тельных систем управления проектами имеются эвристические ме­тоды получения удовлетворительного решения задачи. Сущность за­дачи иллюстрируется рис. 7, а ее возможное решение — рис. 8, 9, 10.

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

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

t0 — оптимистическая (минимальная) оценка;

tp — пессимистическая (максимальная) оценка;

tm — наиболее вероятная оценка.

Из этих трех оценок получаются математическое ожидание te и дисперсия V no формулам:





Три оценки для каждой операции позволяют вычислить характе­ристики нормального распределения — длительность и дисперсию для каждого пути в сети, а затем высказать вероятностные суждения относительно пути. Например:

• вероятность того, что критический путь будет больше 3,5 не­дель, равна 0,1;

• вероятность того, что проект можно будет завершить раньше

чем за 50 недель, равна 0,35.

На рис. 8 показаны потребности в ресурсах для крайнего левого расписания, а на рис. 9 — для крайнего правого расписания.

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

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

Расчет с учетом стоимостных факторов направлен на поиск оп­тимального соотношения «затраты - время» для всего проекта.

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

Подход к решению задач на данном шаге описан на рис. 12.

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

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


Рис. 8

Рис. 9



Рис. 10



Рис. 11

Dn —- нормальная длительность операции;

Dc — минимальная длительность операции (дальнейшее уменьшение не имеет смысла);

Сn. Сc —- затраты при нормальной и минимальной длительности опе­рации.


Рис. 12

А — план максимальной интенсивности; Б — прямые затраты; В — план с минимумом затрат; Г — план нормального режима; Д — кос­венные затраты; Е — общие затраты.

ЛЕКЦИЯ 7


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

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

^ 2. Сведение воедино в общий прогноз данных по всем отдель­ным видам продукции и услуг.

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

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

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

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

Центральное место в планировании производства занимают сле­дующие вопросы:

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

• Какой уровень мощности обеспечивает ресурс каждого вида?

• Каким образом определяется мощность исходя из имеющихся ресурсов?

• Сколько стоит изменение мощностей в сторону увеличения или уменьшения?

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

Различают следующие виды среднесрочных планов: сбалансиро­ванный и план с фиксированным уровнем мощности.

^ Сбалансированный план. В каждый момент времени располагае­мые мощности равны потребностям, вытекающим из прогнозируе­мого спроса.

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

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

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

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

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

При составлении графика определенные ранее объемы произ­водства распределяются в виде заказов на выпуск продукции.

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

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

График выпуска продукции создается на основе информации о заказах, прогнозах спроса, состоянии запасов и производственных мощностях. В ходе построения графика выполняется проверка вари­антов графика на недогрузку или перегрузку производственных мощ­ностей.

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

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

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

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

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

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

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

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

системы с расходом запасов (pond-draining approach), системы с «проталкиванием» (push systems), системы с «протягиванием» (pull systems) и системы, сконцентрированные на «узких местах» (bottlenecks).

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

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

^ Системы с «протягиванием» ориентированы прежде всего на со­кращение уровня запасов на каждой производственной фазе. Если в предыдущей системе роль графика состояла в определении того, что делать дальше, то в данной системе просматривается только следующая стадия, выясняется, что необходимо делать для ее вы­полнения, и производятся необходимые действия. Партии в произ­водстве перемещаются от ранних стадий к поздним без промежу­точного складирования. Существует немало разновидностей и наи­менований для подобных систем: «точно-в-срок» (Just-in-Time), производство с коротким циклом, системы с визуальным управлением, производство без промежуточных складов, поточное произ­водство, синхронизированное производство, система фирмы «Тойота». Как правило, в литературе применяется аббревиатура первого наименования — JIT.

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

Управление в системах четвертого типа сконцентрировано на так называемых «узких местах» — операциях, станках или стадиях про­изводственного процесса, которые тормозят производство, поскольку их производительность меньше, чем в других участках производ­ственной системы.
^ Управление запасами (независимые системы)
В ходе управления производством сталкиваются две тенденции. Первая заключается в том, что запасы материальных ресурсов раз­личного вида необходимы. Вторая заключается в том, что они неже­лательны. Каждая из них порождена определенными причинами и находит отражение в методах управления запасами. Подходы к уп­равлению во многом зависят от вида материального ресурса. В роли такого ресурса могут выступать: конечная продукция, незавершен­ное производство, материалы и полуфабрикаты.

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

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

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

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

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

Рис. 13 иллюстрирует решение задачи об оптимальном объеме заказа на качественном уровне. С ростом объема одного заказа уве­личиваются затраты на хранение и снижаются затраты на приобре­тение и обработку заказов. Суммарные затраты на складирование могут иметь точку минимума, соответствующую оптимальному объе­му заказа (EOQ — Economic order quantity).



Рис. 13
Различают системы с фиксированным объемом заказа и системы с фиксированным временем заказа.

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

В системе FOQ обычно предполагается непрерывный учет за­пасов. Этот учет обеспечивается немедленным отражением в базе данных всех операций, прихода и расхода ресурсов. Для системы FOQ основными являются две задачи: об объеме заказа и о точке заказа.

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

• модель 1 — базовая модель определения EOQ;

• модель 2 — определение EOQ для производственных партий;

• модель 3 — определение EOQ с учетом ценовой политики. Модель 1 имеет следующий вид. Предположения:

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

2. Средний уровень запасов равен 0,5 величины заказа. Это рав­носильно введению следующих упрощающих предположений:

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

3. Потери от дефицита и неудовлетворенного спроса отсутствуют.

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

где ^ D — годовой спрос на материал; С — затраты на хранение единицы материала в течение года; S — средние затраты на работы по приобретению материала по одному заказу (условно-постоянные расходы).

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

Модель 2 имеет следующий вид. По сравнению с моделью 1 вве­дено только одно предположение — заказы производством или по­ставщиком выполняются не единовременно, а представляют собой процесс с равномерным поступлением материальных ресурсов.

В результате для модели 2 получена формула:

где р — ставка (rate) производства; d — ставка (rate) спроса.

Поставщики, работающие в условиях рыночной экономики, как правило, предоставляют скидки в зависимости от объема закупок (quantity discounting). В этих условиях возникает необходимость опти­мизации объема заказа с целью воспользоваться скидками, но не проиграть при этом за счет роста затрат на хранение. Модель 3 по­зволяет оценить влияние скидок на размер партии.

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

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

Спрос во время выполнения заказа (demand during lead time (DDLT)) представляет собой количество материального ресурса, которое будет запрошено во время ожидания прибытия заказанного количества и пополнения запаса.

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

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

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

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

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

Верхний Текущий

Объем заказа = уровень - уровень + Ожидаемый спрос

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

^ Самый важный момент для систем с фиксированным перио­дом — выбор оптимального момента времени (точки) заказа.

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

Ниже представлены предпосылки, при которых построена опти­мизационная модель для систем с фиксированным периодом:

^ 1. Годовой спрос, затраты на хранение, затраты на обработку заказа известны.

2. Средний уровень запаса равен 0,5 от среднего размера заказа. Это предположение соответствует: отсутствию страхового за­паса; немедленному выполнению заказа в полном объеме;

равномерному и одинаковому расходу материалов.

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

^ 4. Скидки в зависимости от объема заказа не учитываются.

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

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

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

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

В табл. 1 показан пример АВС-классификации.

Все виды анализа, связанные с управлением запасами, должны чаще применяться к группе А, реже — к группе В, еще реже — к группе С.

Модели оптимизации размера партии при сохранении общего подхода развиваются в трех направлениях — увеличение числа со­ставляющих затрат, обобщение модели для стохастического случая, адаптация к изменяющимся условиям.
Таблица 1

Материал

Стоимость запасов, %

Количество в запасах, %

Группа в классификации

Материал 1

75

20

А

Материал 2

20

30

В

Материал 3

5

50

С


^ Статистическое Управление Складскими запасами (SIC)

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

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

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

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



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

  • Экономическое количество (величина) заказа

  • Фиксированное количество (величина) заказа

  • Пополнение к максимальному уровню запасов

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



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

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

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

Сегодня существуют многочисленные прикладные системы, ком­плексно решающие задачи управления запасами. В качестве таких систем можно назвать системы IBM, BAAN, R/3.

ЛЕКЦИЯ 8



^ Планирование потребностей в ресурсах
Объединенная система планирования MRP-CRP получила название MRP II.

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

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

Ниже описываются два основных элемента систем планирова­ния потребностей в ресурсах — планирование материальных потреб­ностей (MRP) и планирование потребностей в мощностях (CRP).

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

Подсистема MRP выполняет следующие функции:

• воспринимает информацию MPS;



Рис. 14
• рассчитывает на основе MPS потребности в материалах, по­луфабрикатах, DCE по интервалам планового горизонта;

• уменьшает эти потребности для тех материальных ресурсов, которые есть в запасах;

• строит график заказов на приобретение и производство в планируемом периоде.

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

На рис. 15 показана динамика уровня запасов при использовании системы МRР. Когда объем заказа фиксирован, применяется поли­тика «точки заказа». При этом заказанное количество плюс страхо­вой запас хранятся в запасах до тех пор, пока конечная продукция, в которой данные материалы и полуфабрикаты применяются, не попадет в график выпуска продукции. Но так как в ожидании попа­дания в график может пройти длительное время, то в итоге боль­шую часть времени система будет работать с высоким уровнем запа­сов, а время с низким уровнем будет относительно невелико. Напротив, в MRP заказы на материальные ресурсы возникают синх­ронно с появлением изделия в графике выпуска продукции. Итогом является значительное снижение среднего уровня запасов и затрат на них.



Рис. 15

а) системы с фиксированным объемом и точкой заказа;

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

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

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

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

Проверка на допустимость графика по мощностям в некоторых системах ERP выполняется в модуле «Формирование графика вы­пуска продукции». Таким образом, в MRP попадает допустимый с этой точки зрения план верхнего уровня. Однако это не отменяет необходимость проверки на допустимость и на уровне MRP. Вообще в большинстве современных систем проверка планов на допусти­мость выполняется практически на всех уровнях планирования.

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

Данные о составе изделия и применяемости материалов (bill of material или product structure file) представляют собой полный список всех выпускаемых изделий, количество материалов на еди­ницу продукции, структуру продукции. Данные поддерживаются в актуальном состоянии по мере проектирования и конструиро­вания изделий и внесения проектно-конструкторских изменений. Актуализированное состояние данных является одним из основ­ных условий работы подхода MRP. При условии, что данные ак­туализированы и точны, график выпуска продукции сразу после его подготовки может быть преобразован в материальные потреб­ности.

Основные входные данные в MRP системе следующие:

  • Данные изделия, включая BOM и маршрутизацию

  • Данные потребности, сформированные MPS, из системы продаж и\или системы управления проектами

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



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

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

Обычно, прогнозирование потребности - часть функции Объемно-календарного планирования, использующее "историю товара" для статистического анализа и прогноза движения товара на рынке. Если специфический бизнес не использует процесс Обьемно-календарного планирования, сбыт может быть cпрогнозирован для MRP компонент, основываясь на бюджетах сбыта (то есть плановых цифрах продаж, полученных из любых соображений). В некоторых случаях (запасные части, например) сбыт может быть спрогнозирован для MRP компонент на основании бюджета сбыта , даже если процесс прогнозирования потребности в системе Обьемно-календарного планирования используется для готовых изделий. Типичных примером такой ситуации является например замена одного изделия в пределах товарной группы другим (например лазерного принтера на принтер другой марки, или замена в стандартной комплектации компьютера винчестера 6Гб. на 12Гб.)

"Изделие" (item)- базовое понятие MRP системы. "Изделие" -это может быть сырье, компонента, "сборка", или законченная продукция, или любая другая материальная "вещь". В руссом языке для Item, так же как и для BOM нет полностью адекватного перевода, в рамках данного материала будем употреблять термины Изделие и Компонента как взаимозаменяемые эквиваленты Item. Все "компоненты" в пределах MRP системы должны сначала быть определены путем создания "главной записи изделия". Главная запись изделия включает (точнее задает в рамках автоматизированной системы) большинство общих данных относительно каждого изделия, типа единиц измерения, всевозможного описания, уникального номера изделия, и т.д. Данные, связывающие каждую компоненту изделия в главной записи изделия, используются всеми модулями, функциями и процессами в пределах MRP системы. Главная запись изделия как правило включает четыре компоненты специфических для управления плановым процессом в MRP системе: тип изделия, политика заказа, метод заказа и система заказа. Отношения между типом изделия, политикой заказа, системой заказа, и методом заказа очень важны в MRP системе.

MRP система может использовать пять типов изделия или более:

  • Производимое (производственное)

  • Покупное (заказное)

  • Обобщенное

  • Фантомное (стоимостное)

  • Субподрядное (субподрядный договор)

Потребность (объем заказа) для производимых и покупных компонент может быть сформирована MPS, MRP, SIC, FAS, и PS (проектной системой).

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

Общая схема MRP-процесса



Информация о спросе (потребности) может быть сформирована четырьмя источниками:

  • Заказы на продажу (включая полученные из заключенных контрактов и заказов на продажу, а в отдельных случаях и из коммерческих предложений)

  • "Запланированные" в системе MPS заказы

  • Фактический производственный заказ (например, переходящий из предыдущих периодов)

  • Потребности из системы управления проектами (планирования проектов)



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

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

Информация в главной записи изделии используется чтобы определить, является ли политика заказа анонимной (anonymous) или "по заказу" (to order) или производственной (MRP), чтобы определить систему заказа, соответствующую изделию. Система заказа определяет каким образом (в частности какой системой планирования) формируется потребность в данном компоненте готовой продукции.

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

Например, запланированный производственный заказ в объеме 33 автомобилей поступает от функции MPS к функции планирования потребности. Состав изделия (BOM) показывает, что для каждого автомобиля требуются 4 колеса. Планирование потребности будет генерировать "запланированный" заказ приобретения (если это закупаемая компонента) или производственный заказ (если колеса планируются и производятся в рамках единого технологического процесса) в размере 33 x 4, то есть 132 колеса. Частным случаем такой ситуации может быть вариант когда требуемые колеса являются субконтрактным изделием, причем контрактором по данному заказу выступает "родственное" или "дочернее" предприятие.

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

Хотя тип изделия определит, что необходимо сформировать: запланированный производственный заказ или запланированный Заказ на закупку в ходе процесса планирования, диктуемый данным атрибутом выбор не окончателен. В случае необходимости, производимые компоненты могут быть приобретены. Приобретаемые компоненты также, если это необходимо, могут быть произведены. Однако, MRP система не будет позволять определять BOM или маршрутизацию для данной компоненты или изделия, если тип изделия установлен как "приобретаемое". Следовательно, компонентам, которые могут быть как произведены, так и приобретены, должен быть назначены "производимый" тип изделия, так, чтобы было возможно использовать BOM и маршрутизацию для "дуального" планирования.

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

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

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

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

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

При наличии модуля APS (advanced planning and scheduling - расширенное управление производственными заданиями) возможно производить процесс планирования хоть при каждом появлении нового заказа, а также устанавливать приоритеты выполнения заказов.

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

Период

MPS изделие

1

2

3

4

5

6

7

8

Коврик

86

93

119

100

100

100

100

100

Подставка

0

50

0

50

0

50

0

50

Маркеры

75

120

47

20

17

10

0

0

Карандаши

125

125

125

125

125

125

125

125

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

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



Затем запускается функция модельного планирования потребности, чтобы подготовить детализированные, время-структуированные вычисления потребности в материалах и потребности в производственных мощностях, необходимые для того, чтобы удовлетворить плановой потребности MPS. MRP часто планируется для более коротких периодов времени чем MPS. Например, если MPS обычно рассматривает месячные периоды времени как основу планирования, планирование потребности может быть основано на недельных или даже суточных (сменных) интервалах (периодах). Требуемые плановые периоды времени должны быть выбраны основываясь на среднем производственном цикле и\или на среднем цикле продаж (динамике движения запасов). Так, если "в среднем", от момента предварительного согласования спецификации до заключения договора проходит несколько недель - то это требует одного горизонта планирования. Если же клиент готов забирать товар на следующий день или даже через несколько часов - то, соответственно, другого. При этом и в том, и в другом случае производственный цикл может составлять 1-2 дня.

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

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

^ Таким образом, подсистема MRP работает следующим образом:
1. Из MPS получается количество изделий, которые необходи­мо выпустить в каждом интервале планируемого периода.

2. К изделиям присоединяются сервисные изделия, которые не были включены в график, но исходя из заказов клиентов рассмат­риваются как конечная продукция.

3. Информация об изделиях, определенных выше, преобразует­ся в общие потребности по всем материальным ресурсам по всем периодам заданного горизонта с учетом информации о составе из­делия и применяемости материалов.

^ 4. С помощью информации о состоянии запасов вычисляются для каждого периода чистые потребности по формуле:
Чистые = Общие - Запас в + Страховой + Запасы, предназначенные

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

5. Заказы сдвигаются на ранние временные периоды в соответ­ствии с производственными циклами или циклами выполнения за­казов поставщиками. Так определяется время запуска заказа в про­изводство или подачи заказа поставщику.

Из MRP выдаются транзакции в подсистему управления запаса­ми (перечень запускаемых заказов, изменения в заказах и т. п.), ко­торые используются для корректировки файла состояния запасов. Всякий раз, когда возникают чистые потребности в материальных ресурсах, в MRP должно вырабатываться решение об оптимальном размере партии заказа (lot-sizing decision). Существуют различные методы ее решения. В их числе, в частности, метод нормативного заказа (lot-for-lot (LFL)) и метод периодического пополнения запа­сов (period order quantity (POQ)). Первый заключается в том, что размер партии принимается равным чистым потребностям. Во вто­ром размер партии принимается равным чистым потребностям за период, длительность которого является параметром системы. Прак­тическое применение в реальных системах находят указанные мето­ды или их модификации.

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

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

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



^ Рис. 1. Схема MRP

Довольно часто составляющей MRP-систем являлась система планирования производственных мощностей CRP (Capacity Requirements Planning) (рис. 2)



^ Рис. 2. Схема CRP

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

По этой причине на предприятиях, осуществляющих сборку под заказ, график выпуска продукции и план материальных потребнос­тей MRP обрабатываются отдельно от графика сборки под заказ (final assembly schedule (FAS)). График FAS обычно разрабатывается на одну-две недели, и в него включается уникальная продукция, заказанная клиентами. В то же самое время график выпуска продук­ции, MRP и все другие элементы системы планирования потребно­стей в ресурсах имеют дело с более длительными производственны­ми циклами и не базируются на уникальных заказах. В системе MPS при построении FAS обрабатывается так называемый модульный состав изделия (modular bill of material), который отражает свойства семейства продукции. Он представляет собой список с указанием прогнозируемого в процентах спроса клиентов на варианты, кото­рые создаются на основе базовой комплектации, общей для всех заказов. Такой подход значительно уменьшает нагрузку на вычисли­тельную систему со стороны MRP, но приводит к необходимости применения специальных методов и средств построения FAS и ве­дения файла состава изделия.

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

Подсистема CRP выбирает информацию о заказах, порожден­ную в планах MRP, и приписывает заказы к рабочим местам в соот­ветствии с маршрутными технологиями. В маршрутных технологиях задана последовательность производственных процессов для каждо­го заказа. Затем информация о партиях материальных ресурсов пре­образуется в данные о нагрузке на мощности на основе норм затрат труда и времени работы оборудования. Затем составляются графики нагрузки по всем заказам для каждого рабочего места. Если мощ­ность достаточна по всем рабочим местам во всех временных пери­одах, то график MPS утверждается. Если нет, то должно быть выяс­нено, нельзя ли изменить мощности каким-либо рациональным способом — за счет сверхурочных, установки дополнительного обо­рудования или передачей заказов на сторону по субконтракту. Если таких возможностей нет, то необходимо пересмотреть маршруты с целью снижения нагрузки на «узкие места» или пересмотреть гра­фик выпуска с точки зрения изменения в первую очередь сроков запуска и, если возможно, сроков выпуска.

Центральным моментом проверки допустимости графика MPS является построение графиков нагрузки по рабочим местам.

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

Иногда детализация плана MRP до работ не производится, а оценка его допустимости выполняется на основе производственных циклов для компонент и объемно-календарных оценок потребнос­тей в мощностях.


^

ЛЕКЦИЯ 9

Оперативное управление производством



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

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

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

2. Выдаются диспетчерские списки (dispatching list) для каждо­го участка. В диспетчерских списках задается следующая информа­ция: перечень заказов, приоритеты, сроки выпуска заказа из участ­ка. Иногда диспетчерские списки формируются только для отстаю­щих позиций.

3. Постоянно корректируется информация о запасах незавершен­ного производства (work-in-process inventory). Определяются следу­ющие параметры: местонахождение каждого заказа и количество предметов в нем; передачи заказов между участками; уровень брака; количество изделий, требующих доработки; размеры дефицита по заказу.

^ 4. Обеспечивается управление запуском-выпуском по всем уча­сткам. Это возможно на основании информации о передачах работ между участками.

5. Ведется учет производительности и загрузки оборудования и персонала на каждом участке.

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

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

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

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

Рис. 16
Следующий важный момент в оперативном управлении — зада­ние приоритетов для работ на участке. ^ Практическое решение зада­чи оперативно-календарного планирования заключается в приме­нении правил приоритетов.

Широко применяются следующие правила приоритетов:

1. Первый пришел — первым обслужен (First-come first served (FCFS)).

2. По наименьшему времени выполнения (Shortest processing time (SPT)).

3. С наиболее ранней требуемой датой выполнения (Earliest due date (EDD)).

4. Критическое число (Critical ratio (CR)). Первой выполня­ется работа с наименьшим критическим числом, которое представляет собой отношение времени до требуемой да­ты выпуска к общему оставшемуся времени выполнения работы.

5. Наименьшие затраты на переналадку (Least changeover cost (LCC)). Очередность выполнения работ определяется на основе анализа общих затрат на переналадку между этими ра­ботами.

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

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

Наиболее часто применяемый критерий при оценке расписаний работ — длительность совокупного производственного цикла. Ми­нимизация этого показателя удовлетворительно коррелирует с зада­чами минимизации затрат на производство и максимизации загруз­ки оборудования. В общем случае эта задача для п работ, выполняе­мых на т участках (рабочих центрах, станках). Эта задача не имеет точного решения. Как правило, для ее приближенного решения при­меняют такие правила, как SPT, CR, EDD.


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

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

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

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

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

3. Заключение контрактов с поставщиками. В контракты обычно включаются такие условия и требования, как цена, платежи, скид­ки, график поставки, качество, условия эксплуатации, условия оплаты.

4. Обеспечение связи всех подразделений фирмы с поставщиками.

5.Основными документами, с которыми работает отдел заку­пок, являются: материальная спецификация (material specification), заявка на закупку (purchase requisition), запрос о ценах (request for quotation), заказ на закупку (purchase order). Эти и многие другие документы формируются на ЭВМ.

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

Управление осуществляется следующими процессами:

1. Выгрузкой материала из транспортного средства и размещени­ем его во входном складе.

2. Перемещением материала из входного склада к месту входного контроля.

3. Перемещением материала от места входного контроля к месту хранения и его пребывания там, пока он не понадобится.

4. Отпуском материала со склада и подачей его к месту использо­вания в производстве.

5. Перемещением материала между операциями.

6. Перемещением готовой продукции после окончательной сбор­ки в склад готовой продукции.

7. Отпуском готовой продукции и передачей ее на упаковку и отгрузку.

8. Перемещением готовой продукции на грузовую площадку.

9. Загрузкой готовой продукции в транспортное средство на гру­зовой площадке.

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


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

Как правило, в дискретном производстве материалы сначала прибывают на склад, где фиксируется их попадание в запасы. За­тем по заявкам на отпуск (stock requisition), которые исходят от производства, они подаются в назначенное время в требуемое место.

В ходе хранения изменение состояния материального ресурса отмечается в виде записей в базе данных (stock record). Отдельные позиции, для которых делаются отдельные записи, называются еди­ницами хранения (stock-keeping unit (SKU)). В ходе инвентариза­ции все записи обрабатываются, что дает возможность определить наличие, приход, расход и другие изменения, которые влияют на баланс единиц хранения. Кроме того, записи могут отражать ожи­даемые поступления, обещанные к отпуску или распределенные единицы хранения, даже если последние находятся все еще в за­пасах.

Многие фирмы сегодня используют компьютерные системы с непрерывной инвентаризацией (perpetual inventory-accounting system), в которых записи обрабатываются в реальном времени. В этих запи­сях, однако, могут быть ошибки, и для того, чтобы компенсировать их воздействие, в системы включаются режимы периодических под­счетов (cycle counting).

Периодичность подсчетов может быть различной: при достиже­нии точки заказа, при поставке, через определенный временной интервал. Все материалы в зависимости от их ценности делятся на три группы — А, В, С. Для каждой группы может быть установлена своя периодичность. В ходе производства возникают ситуации, тре­бующие корректирующего воздействия типа ускорения (expediting) или замедления (de-expediting) прохождения заказов через систему управления материальными ресурсами. Многие прикладные систе­мы содержат в своем составе процедуры и функции, обеспечиваю­щие адаптивность, которая заключается в изменении скорости про­хождения заказов.

Системы типа ERP активно применяются также для решения задач оптимизации маршрутов перевозок, оптимизации загрузки транспортных средств, обеспечения связи между участниками про­цесса транспортировки и отправителями, формирование планов отгрузки продукции и запасных частей. Одна из тенденций совре­менных ERP-систем -- интеграция систем управления логистикой, транспортировкой и распределительными системами.
^ Новые идеи и методы в ERP
Развитие идей, методов и средств управления производственны­ми системами привело к появлению систем нового поколения, по­лучивших название «продвинутых систем управления» (Advanced Planning and Scheduling System — APS). Их нельзя рассматривать ис­ключительно как новые информационные технологии. Напротив, новые технологии в них используются для реализации новых мето­дов организации и управления производством.

На протяжении 1994—1996 гг. рынок систем ERP развивался вы­сокими темпами. Объем продаж возрастал примерно на 40% в год. Такие темпы считаются необычайно высокими в любой отрасли. В то же самое время объем продаж APS-систем возрастал вдвое бы­стрее. Начинает проявляться тенденция к фундаментальному изме­нению тех концепций управления, на которых строятся современ­ные системы ERP. Многие их этих концепций входят в противоре­чие с требованиями к управлению в динамичных производственных системах. Заказчикам продукции требуются как можно меньшие дли­тельности выполнения заказов в сочетании с высокой точностью выдерживания сроков. Часто эти требования измеряются уже не днями или неделями, а часами и минутами. Кроме того, все отчетливее проявляется такое требование к системам управления, как сочета­ние массового характера производства с индивидуальным исполне­нием изделий (mass customization).

Можно выделить следующие направления, в которых соверша­ется переход от ERP к APS:

• повышение степени детализации при планировании мощнос­тей, что позволяет принимать более обоснованные плановые решения;

• появление новых информационных технологий, позволяющих одновременно повысить степень детализации и решать в ре­альном времени задачи анализа и моделирования;

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

• рассмотрение задач с одновременными ограничениями на до­ступные материальные ресурсы и мощности;

• формирование плановых решений одновременно для многих заводов;

• улучшение обратной связи в виде задач учета фактического состояния процессов за счет повышения точности и опера­тивности;

• широкое применение методов оптимизации плановых решений;

• динамический подход к ведению информации о производ­ственных циклах.

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


Планирование производственной цепочки


Планирование деятельности предприятия

Оценка возможности выполнения

Производственный график


Рис. 19
Планирование производственной цепочки (Supply Chain Plan­ning — SCP) — это высший уровень системы планирования. Подход к планированию предполагает учет необходимых факторов как внут­ри, так и вне предприятия. Могут включаться такие внешние факто­ры, как мощности смежников и поставщиков, уровень спроса со стороны покупателей продукции, варианты организации транспор­тировки.

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

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

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

Оценка возможности выполнения (available-to-promise — АТР) — это средство обеспечения функционирования трех предыдущих уров­ней. Она специально введена в систему, чтобы повысить точность определения обещаемых заказчикам дат выполнения заказов. При решении этой задачи используется информация из имеющегося про­изводственного плана, а также о ресурсах, необходимых для произ­водства уже имеющихся, но не включенных в план заказов. Новая концепция вычисления АТР в реальном времени, то есть на основе не статического, а динамически скорректированного производствен­ного плана, иногда называется задачей о возможности выполнения заказов на основе доступных мощностей (capable-to-promise или capacity-to-promise — СТР).

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

В современных системах APS применяется широкий спектр алго­ритмов оптимизации.

Наиболее часто встречаются следующие подходы.

^ Линейное программирование. Задача оптимизации решается для линейной целевой функции при линейных ограничениях и ограни­чениях на переменные.

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

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

^ Эвристические алгоритмы. Развитая группа методов, доступная благодаря мощности современных ЭВМ. Это, как правило, алгорит­мы неслучайного поиска, которые заключаются в просмотре пере­менных в положительном и отрицательном направлении с целью улучшить план. При этом активно используется специфика задачи. Одна из особенностей реализации эвристических алгоритмов: фир­мы-производители систем APS часто продают их в виде «черных ящиков», не раскрывая их содержания.

Моделирование и поддержка принятия решений — это одно из основных средств подхода APS, особенно тех, которые ориентиро­ваны на планирование верхнего уровня.

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

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

Сегодня многие фирмы-разработчики включают модули APS в ядра своих систем типа ERP или вступают в кооперацию с ведущи­ми производителями.
^ Некоторые особенности развития
Таким образом, концепции MRPII/ERP постоянно эволюцио­нируют и совершенствуются. В каждый момент времени в них можно выделить, условно говоря, три слоя.

В первом слое находятся те методы и средства, которые провере­ны практикой и закреплены в виде стандартов. В США существует система стандартов, которая поддерживается государством, в част­ности Министерством обороны. В этих стандартах сформулированы требования к информационным системам фирм, выполняющих государственные заказы. В результате на стадии заключения контракта повышается уверенность государства в разумном расходовании бюд­жетных средств, а на стадии его выполнения осуществляется все­сторонний контроль за сроками выполнения и фактическими затра­тами. В качестве примера можно упомянуть правительственный до­кумент «Требования к системам управления материальными про­цессами» (Material Management and Accounting System — MMAS).

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

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

Этот слой, жестко не регламентируемый, тем не менее пред­ставляет собой довольно стройную систему взаимосвязанных идей и методов. Главная роль в поддержании этой части концепций MRPII/ ERP принадлежит, безусловно. Американскому обществу управле­ния производством и запасами (APICS), основанному в 1957 г. Се­годня APICS объединяет около 70 000 специалистов из многих стран мира, представляющих около 20 000 компаний. В их числе примерно 500 компаний США, работающих в области систем MRPII/ERP. Среди направлений деятельности APICS — распространение инфор­мационных материалов; оповещение о публикациях и проектах в области образования и переподготовки; реализация двух программ сертификации специалистов — по управлению производством и за­пасами (CPIM) и интегрированными ресурсами (CIRM); проведе­ние очных и заочных конференций. APICS периодически издает тол­ковый словарь «APICS's Dictionary», который содержит сотни тер­минов, относящихся к MRPII/ERP, и способствует унификации терминологии. Этот момент исключительно важен, особенно для потенциальных пользователей в России на стадии анализа и выбора базовой системы. Значительный интерес представляют имеющиеся в Internet рекомендуемые APICS списки литературы по различным вопросам MRPII/ERP. Действует гибкая система членства в APICS, предусматривающая четыре вида членства — для корпораций, спе­циалистов, учащихся университетов и колледжей, пенсионеров. Внутри APICS выделена группа, специализирующаяся в области управления сложными отраслями промышленности (CI SIG), таки­ми, как аэрокосмическая и оборонная.

К третьему слою идей и методов MRPII/ERP следует отнести то новое, что вносят в свои базовые системы фирмы — производители программных продуктов. Реализованные на их основе новые инфор­мационные технологии представляют собой «know-how» фирм-раз­работчиков. Как правило, именно в этом слое можно обнаружить значительные отличия продуктов различных фирм. Некоторые из но­вых технологий в состоянии оказывать серьезное влияние на эф­фективность построения крупных информационных систем. К ним относится, например, «Система динамического моделирования» (Dynamic Enterprise Modeling — DEM) фирмы BAAN, которая пред­ставляет собой проблемно-ориентированную CASE-технологию про­ектирования систем управления предприятиями.

Видное место среди идей и методов систем MRPII/ERP принад­лежит специально разработанным методикам внедрения систем. Ана­лиз литературы и опыт общения со специалистами различных фирм показывают, что на сегодняшний день сложилось устойчивое пред­ставление о том, в какой последовательности и какими методами следует внедрять системы типа MRPII/ERP. Тщательное планирова­ние проектов по внедрению, организация деятельности коллекти­вов, упор на переподготовку персонала всех уровней (особенно выс­шего уровня) — вот далеко не полный перечень условий достиже­ния положительных результатов. Этой работой занимаются сотни консалтинговых фирм различного масштаба, университеты, бизнес-школы.

Наличие мощной инфраструктуры и методологии построения систем способствует достижению высокого уровня эффективности при внедрении систем управления типа MRPII/ERP на промыш­ленных предприятиях. По некоторым оценкам, внедрение подобных систем способно привести к сокращению запасов до 30%, росту производительности труда до 25%, возрастанию количества зака­зов, выполненных в срок, до 20%.

^

ЛЕКЦИЯ 10

ЖИЗНЕННЫЙ ЦИКЛ СИСТЕМЫ


Модели ЖЦ и его основные этапы

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

процесс — цепочка последовательно выполняемых работ;

этапы — последовательные отрезки времени, в течение кото­рого выполняются работы. В течение этапа могут выполняться работы, относящиеся к разным процессам. В основе деятельности по созданию и использованию автомати­зированной системы управления предприятием (АСУП) лежит по­нятие ее жизненного цикла (ЖЦ). ЖЦ является моделью создания и использования АСУП, отражающей ее различные состояния, начи­ная с момента возникновения необходимости в данном изделии и заканчивая моментом его полного выхода из употребления у всех без исключения пользователей.

Традиционно выделяются следующие основные этапы ЖЦ АСУП:

анализ требований;

проектирование;

программирование/внедрение;

тестирование и отладка;

эксплуатация и сопровождение.

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

Существующие модели ЖЦ определяют порядок исполнения эта­пов в ходе разработки, а также критерии перехода от этапа к этапу. В соответствии с этим наибольшее распространение получили три следующие модели ЖЦ:

^ 1. Каскадная модель (в 70—80-е годы) — предполагает переход на следующий этап после полного окончания работ по предыдущему этапу и характеризуется четким разделением данных и процессов их обработки.

^ 2. Поэтапная модель с промежуточным контролем (в 80—85-е го­ды) — итерационная модель разработки с циклами обратной связи между этапами. Преимущество такой модели заключается в том, что межэтапные корректировки обеспечивают меньшую трудоемкость по сравнению с каскадной моделью; с другой стороны, время жиз­ни каждого из этапов растягивается на весь период разработки.

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

^ Специалистами отмечаются следующие преимущества спираль­ной модели:

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

ориентация на развитие и модификацию системы в процессе ее проектирования;

анализ риска и издержек в процессе проектирования

. Отметим, что главная особенность индустрии АСУП состоит в концентрации сложности на начальных этапах ЖЦ (анализ, проек­тирование) при относительно невысокой сложности и трудоемкос­ти последующих этапов. Более того, нерешенные вопросы и ошиб­ки, допущенные на этапах анализа и проектирования, порождают на последующих этапах трудные, часто неразрешимые проблемы и, в конечном счете, могут лишить успеха.

^ Анализ требований

Анализ требований является первой фазой разработки АСУП, на которой требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе дается ответ на воп­рос: «Что должна делать будущая система?». Именно здесь лежит ключ к успеху всего проекта. В практике создания больших систем известно немало примеров неудачной реализации проекта именно из-за неполноты и нечеткости определения системных требований.

Список требований к АСУП должен включать:

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

• описание выполняемых системой функций;

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

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

• архитектуру системы, ее функции, внешние условия, распре­деление функций между аппаратной и программной частями (ПЧ);

• интерфейсы и распределение функций между человеком и системой;

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

• полную функциональную модель требований к будущей сис­теме с глубиной проработки до уровня каждой операции каж­дого должностного лица;

• спецификации операций нижнего уровня;

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

• концептуальную информационную модель требований;

• пакет отчетов и документов по информационной модели;

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

• предложения по оргштатной структуре для поддержки сис­темы.

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

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

• описать, «увидеть» и скорректировать будущую систему до того, как она будет реализована физически;

•уменьшить затраты на разработку и внедрение системы;

• оценить разработку по времени и результатам;

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

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

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

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

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

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

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

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

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

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

•традиционная (текстовая) спецификация системы из-за объе­ма технических терминов часто непонятна заказчику;

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

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

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

•ограниченный контекст, включающий лишь существенные на каждом уровне детали;

• использование строгих формальных правил записи;

• последовательное приближение к конечному результату.

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

• Конструирование системы черных ящиков существенно упро­щается. Намного легче разработать магнитофон или проигры­ватель, если не беспокоиться о создании встроенного усили­тельного блока.

• Облегчается тестирование таких систем. Если появляется пло­хой звук одной из колонок, можно поменять колонки места­ми. Если неисправность переместилась с колонкой, то имен­но она подлежит ремонту; если нет, тогда проблема в усили­теле, магнитофоне или местах их соединения.

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

•Облегчается доступность для понимания и освоения. Можно стать специалистом по магнитофонам без углубленных зна­ний о колонках.

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

Таким образом, первым шагом упрощения сложной системы является ее разбиение на черные ящики (принцип «разделяй и вла­ствуй» — принцип решения трудных проблем путем разбиения их на множество независимых задач, легких для понимания и решения), при этом такое разбиение должно удовлетворять следующим крите­риям:

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

•функция каждого черного ящика должна быть легко понимае­ма независимо от сложности ее реализации (например, в си­стеме управления ракетой может быть черный ящик для рас­чета места ее приземления: несмотря на сложность алгорит­ма, функция черного ящика очевидна — расчет точки при­земления);

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

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

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

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

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

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

функции, которые система должна выполнять,

отношения между данными,

зависящее от времени поведение системы (аспекты реальноговремени).

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

^ DFD (Data Flow Diagrams) — диаграммы потоков данных совмес­тно со словарями данных и спецификациями процессов (мини-специ­фикациями);

ERD (Entity-Relationship Diagrams) — диаграммы «сущность-связь»;

STD (State Transition Diagrams) — диаграммы переходов состо­яний.

Все они содержат графические и текстовые средства моделиро­вания: первые — для удобства отображения основных компонент модели, вторые — для обеспечения точного определения ее компо­нент и связей.

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

Необходимо отметить, что для функционального моделирова­ния наряду с DFD достаточно часто применяется и другая нота­ция — SADT (точнее, ее стандартизованное подмножество IDEFO). Сравнительный анализ этих двух подходов к моделированию фун­кций системы будет приведен ниже.

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

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


Рис. 20

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

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

В настоящее время успешно используются практически все из­вестные методологии структурного анализа, однако наибольшее распространение получили методологии SADT (Structured Analysis and Design Technique), структурного системного анализа Гейна—Сарсона (Gane—Sarson), структурного анализа и проектирования Йодана—Де Марко (Yourdon—DeMarko), развития систем Джексо­на (Jackson), развития структурных систем Варнье—Орра (Warmer— Orr), анализа и проектирования систем реального времени Уорда— Меллора (Ward—Mellor) и Хатли (Hatley), информационного моде­лирования Мартина (Martin).

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

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

по отношению к школам Software Engineering (SE) и Information Engineering (IE);

по порядку построения модели процедурно-ориентирован­ные и информационно-ориентированные;

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

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

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

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

Таблица 2

^ Информационные системы

Системы реального времени

Управляемы данными

Управляемы событиями

Сложные структуры данных

Простые структуры данных

Большой объем входных данных

Малое количество входных данных

Интенсивный ввод/вывод

Интенсивные вычисления

Машинная независимость

Машинная зависимость


Средствами поддержки этих особенностей и различаются соответ­ствующие структурные методологии. Необходимо отметить, что для целей анализа требований к системам реального времени использу­ются специальные типы структурных диаграмм: диаграммы потоков управления, диаграммы переходов состояний, матрицы состояний/ событий, таблицы решений и др. Однако многие из них являются вариациями структурных диаграмм для анализа требований к ин­формационным системам. Более того, известные методологии ана­лиза и проектирования СРВ (в частности, методологии Хатли и Уор-да—Меллора) базируются на перечисленных методологиях анализа и проектирования ИС, расширяя их соответствующими диаграмм­ными техниками.

В табл. 3 приведена классификация наиболее часто используемых методологий в соответствии с вышеперечисленными признаками (данные по частоте использования получены на основе анализа ин­формации по 127 CASE-пакетам).

Как уже отмечалось, наиболее существенное различие между разновидностями структурного анализа заключается в методах и сред­ствах функционального моделирования. С этой точки зрения все раз­новидности структурного системного анализа могут быть разбиты на две группы: применяющие методы и технологию DFD (в различ­ных нотациях) и использующие SADT-методологию. По материа­лам наиболее авторитетной в рассматриваемой области исследовательской компании CASE Consulting Group соотношение примене­ния этих двух разновидностей структурного анализа на практике составляет 90% для DFD и 10% для SADT.
Таблица 3

Методологии

Частота использования

Школа

Порядок построения

Тип целевых систем

Йодан— Де Марко

36.5%

SE

процедурно-ориентированная

ИС. СРВ

Гейн— Сарсон

20.2%

SE

процедурно-ориентированная

ИС. СРВ

Константайн

10.6%

SE

процедурно-ориентированная

ИС. СРВ

Джексон

7,7%

SE

информационно-ориентированная

ИС. СРВ

Варнье—Орр

5.8%

SE

информационно-ориентированная

ИС

Мартин

22.1%

IE

информационно-ориентированная

ИС

SADT

3.3%

IE

процедурно-ориентированная

ИС


Предваряя сравнительный анализ DFD- и SADT-подходов, в ка­честве примера рассмотрим верхний уровень модели требований к системе автоматизации управления компанией, занимающейся рас­пределением товаров по заказам (рис. 21 и рис. 22 соответственно). Заказы подвергаются входному контролю и сортировке. Если заказ не отвечает номенклатуре товаров или оформлен неправильно, то он аннулируется с соответствующим уведомлением заказчика. Если заказ не аннулирован, то определяется, имеется ли на складе соот­ветствующий товар. В случае положительного ответа выписывается счет к оплате и предъявляется заказчику, при поступлении платежа товар отправляется заказчику. Если заказ не обеспечен складскими запасами, то отправляется заявка на товар производителю. После поступления требуемого товара на склад компании заказ становится обеспеченным и повторяет вышеописанный маршрут.



Рис. 21

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

адекватность средств рассматриваемой проблеме;

согласованность с другими средствами структурного анализа;

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

1) Адекватность. Выбор той или иной структурной методологии напрямую зависит от предметной области, для которой создается модель. В нашем случае методологии применяются к автоматизиро­ванным системам управления предприятием, а не к системам вооб­ще, как это предполагается в SADT. Для рассматриваемых задач DFD вне конкуренции.

Во-первых, SADT-диаграммы значительно менее выразительны и удобны для моделирования АСУП (сравните рис. 21 и рис. 22). Так, дуги в SADT жестко типизированы (вход, выход, управление, меха­низм). В то же время применительно к АСУП стирается смысловое различие между входами и выходами, с одной стороны, и управле­ниями и механизмами, с другой: входы, выходы, механизмы и уп­равления являются потоками данных и/или управления и правила­ми их трансформации. Анализ системы при помощи потоков данных и процессов, их преобразующих, является более прозрачным и не­двусмысленным.



Рис. 22

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

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

2) Согласованность. Главным достоинством любых моделей явля­ется возможность их интеграции с моделями других типов. В данном случае речь идет о согласованности функциональных моделей со средствами информационного и событийного (временного) моде­лирования. Согласование SADT-модели с ERD и/или STD практи­чески невозможно или носит тривиальный характер. В свою очередь, DFD, ERD и STD взаимно дополняют друг друга и по сути являют­ся согласованными представлениями различных аспектов одной и той же модели (см. рис. 20 ). В табл. 4 отражена возможность такой интеграции для DFD- и SADT-моделей.

Таблица 4

Название

ERD

STD

^ Структурные карты

DFD

+

+

+

SADT

+

-

-


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

3) ^ Интеграция с последующими этапами. Важная характеристика методологии — ее совместимость с последующими этапами приме­нения результатов анализа (и прежде всего с этапом проектирова­ния, непосредственно следующим за анализом и опирающимся на его результаты). DFD могут быть легко преобразованы в модели про­ектирования (структурные карты) — это близкие модели. Более того, известен ряд алгоритмов автоматического преобразования иерархии DFD в структурные карты различных видов, что обеспечивает логич­ный и безболезненный переход от этапа анализа требований к проек­тированию системы. С другой стороны, неизвестны формальные ме­тоды преобразования SADT-диаграмм в проектные решения АСУП.

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

ЛЕКЦИЯ 11



^ Объектно-ориентированные методы анализа
Важное место в разработках АСУП занимают объектно-ориенти­рованные методологии, основанные на объектной декомпозиции предметной области, представляемой в виде совокупности объек­тов, взаимодействующих между собой посредством передачи сооб­щений. Данный подход не является противопоставлением структур­ному подходу, более того, фрагменты методологий структурного анализа (а именно его базовые модели: DFD, ERD и STD) исполь­зуются при объектно-ориентированном анализе для моделирования структуры и поведения самих объектов.

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

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

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

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

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

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

Известные объектно-ориентированные методологии базируются на интегрированных моделях трех типов:

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

динамической модели, отражающей временные аспекты и пос­ледовательность операций (при этом достаточно часто исполь­зуется STD);

функциональной модели, описывающей потоки данных (с ис­пользованием DFD).

В табл. 5 приведены оценки объемов продаж объектно-ориентиро­ванных методологий поданным International Data Corp. на 1995 г.

Главными недостатками перечисленных объектно-ориентирован­ных методологий являются следующие:

отсутствие стандартизации в рассматриваемой области про­граммотехники (конкретно, для представления объектов и взаимосвязей между ними);

отсутствие метода, одинаково хорошо реализующего этапы анализа требований и проектирования (большинство методов предназначено для объектно-ориентированного анализа, не­которые содержат слабо развитые средства проектирования, метод Booch ориентирован на проектирование). Для преодоления этих недостатков авторы известных методоло­гий Буч (Booch), Рамбо (Rumbaugh) и Якобсон (Jacobson) объеди-

Таблица 5

^ Название методологии

Объем продаж, %

Rumbaugh (OMT)

40

ShIaer—Mellor

16

Booch

11

Martin— Odell

11

другие

22


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

В UML используются следующие ключевые диаграммы:

•диаграмма классов, демонстрирующая статическую структуру системы, ее содержимое — классы, объекты и отношения между ними;

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

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

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

•диаграмма компонентов, описывающая модули системы, в ко­торых определены классы;

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

При этом первые четыре диаграммы являются логическими пред­ставлениями разрабатываемой системы, а последние две — отража­ют ее физическое представление.
^

Разработка технического задания


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

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

• разработку требований к техническим средствам;

• разработку требований к программным средствам;

• разработку топологии, состава и структуры локальной вычис­лительной сети;

•требования к этапам и срокам выполнения работ.

Рассмотрим основные виды работ, которые необходимо выпол­нить, прежде чем приступить к проектированию (созданию проекта на разработку или адаптацию).

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

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

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

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

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

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

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

Проектирование

Этап проектирования дает ответ на вопрос: «Как (каким образом) система будет удовлетворять предъявленным к ней требованиям?». Задачей этого этапа является исследование структуры системы и ло­гических взаимосвязей ее элементов, причем здесь не рассматрива­ются вопросы, связанные с реализацией на конкретной платформе. Проектирование определяется как «(итерационный) процесс получе­ния логической модели системы вместе со строго сформулированны­ми целями, поставленными перед нею, а также написания специфи­каций физической системы, удовлетворяющей этим требованиям». Обычно этот этап разделяют на два подэтапа:

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

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

Другими словами, проектирование является этапом ЖЦ, на ко­тором вырабатывается, как реализуются требования к АСУП, по­рожденные и зафиксированные на этапе анализа. В результате этапа должна быть построена модель реализации, демонстрирующая, как система будет удовлетворять предъявленным к ней требованиям (без технических подробностей). Фактически модель реализации являет­ся развитием и уточнением модели требований, а само проектиро­вание является мостом между анализом и реализацией.
^ Структурное проектирование

Базовыми строительными блоками АСУП при использовании структурного подхода являются модули. Все виды модулей в любом языке программирования имеют ряд общих свойств, из которых су­щественны при структурном проектировании перечисленные ниже:

1) Модуль состоит из множества операторов языка программи­рования, записанных последовательно.

2) Модуль имеет имя, по которому к нему можно ссылаться как к единому фрагменту.

3) Модуль может принимать и/или передавать данные как па­раметры в вызывающей последовательности или связывать данные через фиксированные ячейки или общие области. При структурном проектировании выполняется два вида работ:

проектирование архитектуры АСУП, включающее разработку структуры и интерфейсов ее компонент (автоматизированных рабочих мест), согласование функций и технических требова­ний к компонентам, определение информационных потоков между основными компонентами, связей между ними и вне­шними объектами;

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

При этом происходит расширение модели требований:

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

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

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

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

Структурные карты Константайна являются моделью отношений иерархии между программными модулями. Узлы структурных карт соответствуют модулям и областям данных, потоки изображают межмодульные вызовы (в том числе циклические, условные и па­раллельные). Межмодульные связи поданным и управлению также моделируются специальными узлами, привязанными к потокам, стрелками указываются направления потоков и связей. Фундамен­тальные элементы структурных карт Константайна стандартизова­ны IBM, ISO и ANSI.

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

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

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

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

•уменьшается количество соединений между двумя модулями, что приводит к уменьшению вероятности появления «волно­вого эффекта» (ошибка в одном модуле влияет на работу дру­гих модулей);

• минимизируется риск появления «эффекта ряби» (внесение изменений, например при исправлении ошибки, приводит к появлению новых ошибок), так как изменение влияет на ми­нимальное количество модулей;

• при сопровождении модуля отпадает необходимость беспоко­иться о внутренних деталях других модулей;

•система упрощается для понимания настолько, насколько это возможно.

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

Два модуля А и В нормально сцеплены, если: А вызывает В;

В возвращает управление А; вся информация, передаваемая между А и В, представляется значениями параметров при вызове.

Нормальное сцепление в свою очередь делится на три типа: сцеп­ление поданным, сцепление по образцу, сцепление по управлению. На практике наиболее часто используется сцепление по данным.

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

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

^ Два модуля сцеплены по управлению, если один посылает дру­гому информационный объект — флаг, предназначенный для уп­равления его внутренней логикой. Существует два типа флагов — описательный и управляющий. Описательный флаг обычно описы­вает ситуацию, которая произошла, и именуется с использованием существительных и прилагательных: Конец файла, Введенная кредит­ная карта. Управляющий флаг используется для декларирования определенных действий в вызываемом модуле и именуется с ис­пользованием глаголов: Читать следующую запись, Установить в на­чало. В общем случае управляющие флаги усиливают сцепление и, следовательно, ухудшают качество проекта.

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

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

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

В табл. 6 приведены сравнительные характеристики по каждому типу сцепления.

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

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

Таблица б

^ Тип сцепления

Устойчивость к волновому эффекту

Модифици­руемость

Понятность

Используемость в других системах

По данным

*

хорошая

хорошая

хорошая

По образцу

*

средняя

средняя

средняя

По управлению

средняя

плохая

плохая

плохая

По общей области

плохая

средняя

плохая

плохая

По содержимому

плохая

плохая

плохая

плохая

* — зависит от количества параметров интерфейса

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

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

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

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

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

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

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

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

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

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

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

В табл. 7 приведены сравнительные характеристики для каждого уровня связности.

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

Таблица 7

СВЯЗНОСТИ

Сцепление

Модифици­руемость

Понятность

Сопровож-даемость

функцио­нальная

хорошее

хорошая

хорошая

хорошая

последова­тельная

хорошее

хорошая

близкая к хорошей

хорошая

информа­ционная

среднее

средняя

средняя

средняя

процедурная

переменное

переменная

переменная

плохая

временная

плохое

средняя

средняя

плохая

логическая

плохое

плохая

плохая

плохая

случайная

плохое

плохая

плохая

плохая


шей связности к худшей). Как и сцепление, связность является од­ним из лучших критериев оценки качества про­екта.

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

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

Рассмотрим основные принципы, позволяющие получать каче­ственные системы.

1) ^ Принцип факторизации. Под факторизацией понимается вы­деление подзадачи, реализуемой некоторым модулем, в новый са­мостоятельный модуль. Это может быть сделано с целью:

• уменьшения размеров модуля;

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

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

• отделения собственно вычислений от управления (вызовы и принятия решения);

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

• упрощения реализации.

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

3) ^ Обработка ошибок. Сообщения об ошибках целесообразно формировать и визуализировать в модуле, ко­торый ошибку обнару­живает (и, следовательно, «знает», что это за ошибка). Тексты сооб­щений рекомендуется хранить вместе, так как при таком походе:

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

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

• легче избежать дублирования сообщений;

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

4) ^ Принцип отсутствия памяти состояния. Когда вызванный мо­дуль после выполнения своей функции возвра­щает управление выз­вавшему его модулю, он «умирает», оставляя после себя лишь ре­зультат. При повторном вы­зове он делает свою работу так, будто он только что «родился». Модуль «не помнит», что происходило в его пре­дыдущих жизнях. Однако существует тип модуля, который «зна­ет» о своем прошлом благодаря так называемой памяти состояния. Память состояния — это информационный объект внутри модуля, который продолжает суще­ствовать неизменным между двумя вызо­вами модуля. Работа модуля с памятью состояния в общем случае не­предсказуема, это означает, что хотя модуль вызывался с одина­ковыми фактическими параметрами, исполняться он может по-раз­ному, и результаты его работы при разных вызовах могут быть раз­личными. Сопровождение та­кого модуля резко усложняется.

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

6) ^ Компромисс между ограниченностью и обобщенностью. Огра­ниченный модуль обладает по крайней мере одной из следующих характеристик:

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

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

• включает в себя условия о месте и способе его использова­ния.

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

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

• имеет дело со слишком избыточными типами данных, их значениями и структурами. Например, ис­пользование числа типа REAL вместо INTEGER для того, чтобы следить за ко­личеством болтов на складе, было бы чрезмерным обобще­нием;

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

7) ^ Минимизация избыточности, то есть устранение дублирования. Если любой факт, условие или реализационное решение явно про­являются в более чем одном модуле, то усилия по сопровождению, состоящие из нахождения всех случаев этого факта и их изменения, увеличиваются. Также возникает риск, что человек, сопровождаю­щий такую систему, забудет изменить один из дублей.

8) ^ Нагрузка по входу и выходу. Под нагрузкой модуля по входу понимается количество непосредственных вы­зывающих его моду­лей. Соответственно, нагрузка модуля по выходу — это количество непосредственно подчи­ненных ему модулей. По уже упоминавшим­ся выше причинам нагрузка по выходу не должна превышать 6—7 мо­дулей. Высокая нагрузка по входу требует от модуля хорошей связ­ности.

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

ЛЕКЦИЯ 12


^ Объектно-ориентированное проектирование

Если методы структурного проектирования имели целью упро­щение системной разработки на основе алго­ритмического подхода, то объектно-ориентированные методы решают аналогичную задачу, используя описания классов и объектов, т. е. выразительные сред­ства объектно-ориентированного программирования. Буч (Booch) оп­ределил объектно-ориентированное проектирование как «методо­логию проектирования, соединяющую в себе процесс объектной декомпозиции и приемы представления как логической и физичес­кой, так и статической и ди­намической моделей проектируемой системы».

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

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

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

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

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

^ Реализация (программирование/адаптация)

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

Корректность АСУП является ее самым важным свойством и, несомненно, составляет главный предмет за­боты разработчиков. В идеальном случае под корректностью АСУП понимается отсут­ствие в ней ошибок. Од­нако для большинства сложных программ­ных продуктов достигнуть этого невозможно — «в каждой програм­ме со­держится по крайней мере одна ошибка». Поэтому под коррек­тным обычно подразумевают программный продукт, работающий в соответствии с предъявленными к нему требованиями, другими сло­вами, продукт, для которого пока еще не найдены такие условия, в которых он окажется неработоспособным.

Установление корректности является главной целью рассматри­ваемого этапа жизненного цикла. Следует отме­тить, что этап тести­рования и отладки — один из наиболее трудоемких, утомительных и непредсказуемых этапов разработки АСУП. В среднем при разра­ботке традиционными методами этот этап занимает от '/3 до '/2 полного времени разработки. С другой стороны, тестирование и от­ладка представляют собой серьезную проблему: в некото­рых случаях тестирование и отладка программы требуют в несколько раз больше времени, чем непосредственно программирование.

Тестирование представляет собой набор процедур и действий, предназначенных для демонстрации кор­ректной работы АСУП в заданных режимах и внешних условиях. Цель тестирования — выя­вить наличие ошибок или убедительно продемонстрировать их от­сутствие, что возможно лишь в отдельных тривиальных случаях. Важно различать тестирование и сопутствующее понятие «отладка». Отлад­ка — это набор процедур и действий, начи­нающихся с выявления самого факта наличия ошибки и заканчивающихся установлением точного места, харак­тера этой ошибки и способов ее устранения.

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

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

• формулировку целей тестирования;

• критерии качества тестирования, позволяющие оценить его результаты;

• стратегию проведения тестирования, обеспечивающую дости­жение заданных критериев качества;

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

Для целей тестирования программные элементы АСУП удобно представлять в виде ориентированного графа G = (N, Е),

где N = (N1, N2, ..., Nm) — множество узлов (вершин), соответ­ствующих выполняемым операторам тестируемой программы;

Е= 1, Е2, ..., Еп) — множество ребер (дуг), соответствующих передачам управления между операторами.

Путем (маршрутом) называется последовательность вершин и дуг Р= (N1, E1,2, N2, E2,3 , ..., Ek-1,k, Nk), где каждая дуга Ei,i+l выходит из Nt и входит в Ni+l, причем N1 не обязательно начальный узел. Ветвью называется путь Р, в котором N1 — либо начальный узел, либо узел ветвления, Nkлибо узел ветвления, либо завершающий узел, все остальные N1 не являются узлами ветвления.

Очевидно, что полное тестирование всех возможных маршрутов не реально в связи с огромными затратами труда и времени. Поэтому на практике применяются критерии выбора тестов, не гарантирую­щие полной проверки программы. Общим требованием к этим крите­риям является достижение лишь определенной степени полноты АСУП или ее компонент. Как правило, эти критерии устанавливают требо­вание по крайней мере однократной проверки всех операторов про­граммы, всех ветвей программы, либо всех подпутей специального вида (например, всех под­путей, проверяющих циклы при началь­ном, завершающем и одном из промежуточных значений перемен­ной — счетчика цикла). Самым распространенным критерием тести­рования является критерий, требующий по крайней мере однократ­ной проверки каждой из ветвей программ (критерий С1). Так, напри­мер, тестирование при приемке программного обеспечения для ВВС США производится на основании этого критерия. По ряду независи­мых оценок использование критерия С1 обеспечивает обнаружение от 67 до 90% ошибок.

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

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

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

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

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

^ Автоматизация тестирования и отладки

Система автоматизации тестирования и отладки (САТО) пред­ставляет собой сложный комплекс алгоритмиче­ских и программных средств, предназначенных для автоматизации анализа АСУП, тес­тирования, отладки и оценки ее качества, и позволяет облегчить модификацию компонент АСУП, обеспечить выявление ошибок на ранних стадиях отладки, повысить процент автоматически обнару­живаемых ошибок. На рис. 23 показано, как использование САТО влияет на цену обнаружения ошибок в течение жизненного цикла АСУП. АСУП стано­вится «работоспособной», когда цена обнару­женной ошибки меньше некоторого значения μ, которое отражает уровень терпимости пользователя к программным ошибкам. Число имеющихся ошибок (область под кривой) одно и то же в обоих случаях. Отметим, что число обнаруженных ошибок после того, как АСУП становится ра­ботоспособной, почти постоянно по следую­щим причинам:

1) влияние эффекта «ряби» — исправление ошибки служит ис­точником внесения новых ошибок (практика показывает, что такие ошибки составляют 19% всех обнаруженных ошибок);

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



Рис. 23

I - кривая тестирования с использованием САТО,

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

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

Средства автоматизации, включаемые в САТО, в зависимости от решаемых ими задач разбиваются на средства автоматизации тести­рования и средства автоматизации отладки.

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

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

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

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

4) средства автоматизированного контроля тестирования, позво­ляющие оценить, насколько полная и тщатель­ная проверка АСУП была осуществлена, например, на основе информации о непрове­ренных операто­рах/функциях, непроверенных маршрутах и т. п.;

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

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

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

^ Средства статического анализа классифицируются следующим образом:

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

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

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

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

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

6) средства для контроля последовательности событий, произ­водящие сравнение этой последовательности с правильной, зара­нее заданной последовательностью (например, при работе с фай­лом должна соблюдаться сле­дующая последовательность: создание, открытие, совокупность чтений/записей, закрытие).

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

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

Средства частичной автоматизации позволяют пользователю ав­томатически получать необходимую ему инфор­мацию для дальней­шей локализации ошибок вручную. Среди таких средств наиболее распространены DDT (Di­namic Debugging Tools) — «системы для уничтожения блох« (слово «bug» в английском языке означает не только «ошибка», но и »блоха», а ДДТ — популярное в недавнее время средство борьбы с насекомыми). Управление системой DDT и, соответственно, управление отладкой осуществляются посред­ством языка отладки командного типа, его операторы имеют форму приказов (команд), состоящих из ключевого слова и списка опе­рандов, если последние необходимы. Операторы языка отладки обес­печивают взаимодействие программиста с DDT и инициируют вы­полнение соответствующих отладочных функций, согласно которым они могут быть разбиты на следующие группы:

1) управляющие операторы, обеспечивающие управление вы­полнением АСУП в отладочном режиме, а также гибкий контроль исполнения информирующих и контролирующих операторов;

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

3) контролирующие операторы, осуществляющие контроль зна­чений переменных, маршрутов и т. п. на пред­мет сравнения с зара­нее заданными;

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

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

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

^ Эксплуатация и сопровождение

Основные задачи этапа эксплуатации и сопровождения:

• обеспечение устойчивости работы системы и сохранности ин­формации — администрирование;

• своевременная модернизация и ремонт отдельных элемен­тов — техническая поддержка;

• адаптация возможностей эксплуатируемой системы к текущим

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

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

^ CASE-технологии — инструментарий поддержки ЖЦ

Практически ни один серьезный проект по созданию АСУП не осуществляется без использования CASE-средств. CASE (Computer-Aided Software/System Engineering) представляет собой совокупность методологий ана­лиза, проектирования, разработки и сопровожде­ния сложных программных систем, поддержанную комплексом вза­имоувязанных средств автоматизации. CASE — это инструментарий для системных аналитиков, разработчиков и программистов, заме­няющий им бумагу и карандаш компьютером для автоматизации процесса проектирования и разработки ПО. При применении этого инструментария отмечается значительный рост производительнос­ти труда, составляющий (по оценкам фирм, использующих CASE) от 100 до 600% в зависимости от объема и слож­ности работ и опыта использования CASE. Общее число распространяемых пакетов пре­вышает 500 наименований. Объем рынка CASE-средств превышает 10 млрд. долл. в год, число инсталляций наиболее популярных паке­тов со­ставляет десятки тысяч.

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

Следует отметить, что CASE — не революция в программотехни­ке, а результат естественного эволюционного развития всей отрас­ли средств, называемых ранее инструментальными или технологи­ческими. Однако это и не Confuse Array of Software that does Everything, существует ряд признаков и свойств, наличие которых позволяет классифицировать некоторый продукт как CASE-средство. Одним из ключевых признаков является поддержка структурных и/или объек­тно-ориентированных методологий. С самого начала CASE-средства развивались с целью преодоления ограничений при использовании структурных (а в настоящее время и объектно-ориентированных) методологий (сложности понимания, большой трудоемкости и сто­имости использования, трудности внесения изменений в проект­ные спецификации и т. д.) за счет их автоматизации и интеграции поддерживающих средств.

Помимо автоматизации методологий и, как следствие, возмож­ности применения современных методов сис­темной и програм­мной инженерии, CASE обладают следующими основными досто­инствами:

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

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

• ускоряют процесс проектирования и разработки;

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

• поддерживают развитие и сопровождение разработки;

• поддерживают технологии повторного использования компо­нент разработки.

В настоящее время имеется два поколения CASE. Средства перво­го поколения предназначены для анализа тре­бований, проектиро­вания спецификаций и структуры системы и являются первой тех­нологией, адресованной не­посредственно системным аналитикам и проектировщикам. Они включают средства для поддержки графи­ческих моделей, проектирования спецификаций, редактирования словарей данных и концентрируют внимание на на­чальных шагах проекта — системном анализе, определении требований, систем­ном проектировании, логическом проектировании БД. Средства вто­рого поколения предназначены для поддержки полного жизненно­го цикла разра­ботки. В них в первую очередь используются средства поддержки автоматической кодогенерации, а также обес­печивается полная функциональная поддержка для создания графических сис­темных требований и специфика­ций проектирования; контроля, анализа и увязывания системной информации, а также информа­ции по управ­лению проектированием; построения прототипов и моделей системы; тестирования, верификации и анализа сгенери­рованных программ; генерации документов по проекту; контроля на соответствие стандартам по всем этапам ЖЦ.

CASE-технологии предлагают новый, основанный на автомати­зации подход к концепции ЖЦ ПО. При использовании CASE из­меняются все фазы ЖЦ, при этом наибольшие изменения касаются фаз анализа и проектирования.

В табл. 8 приведены оценки трудозатрат по фазам ЖЦ. В табл. 9 сведены основные изменения в ЖЦ при использовании CASE по сравнению с традиционной разработкой.

Таблица 8

Способ разра­ботки

Анализ, %

Проектирова­ние, %

Кодирование, %

Тестирование, %

Традиционная разработка


20


15


20


45

Использование структурных методологий


30


30


15


25

Использование CASE-техноло­гий


40




40



5


15


Таблица 9


Традиционная разработка

CASE

Основные усилия — на кодирова­ние и тестирование


Основные усилия — на анализ и проектирование

«Бумажные» спецификации


Быстрое итеративное прототипиро­вание

Ручное кодирование

Автоматическая кодогенерация

Ручное документирование


Автоматическая генерация доку­ментации

Тестирование кодов

Автоматический контроль проекта

Сопровождение кодов


Сопровождение спецификаций про­ектирования
1   2   3   4   5   6   7   8   9   10   ...   20



Скачать файл (8603.5 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации
Рейтинг@Mail.ru