Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Лекции по КиС

.pdf
Скачиваний:
91
Добавлен:
28.03.2015
Размер:
1.96 Mб
Скачать

(life cycle cost). Они складываются из затрат на разработку и производство изделия, а также на ввод изделия в действие, эксплуатацию и поддержание его в работоспособном состоянии. Сокращение затрат на поддержку ЖЦ изделия – одна из целей CALS. Комплекс управленческих технологий, направленных на сокращение этих рас-

ходов, объединяется понятием ИЛП (Integrated Logistic Support).

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

11.5. Базовые управленческие технологии

Информацию, циркулирующую в системе информационной поддержки ЖЦ машиностроительного изделия, можно условно разделить на три класса:

данные о продукции (изделии);

данные о выполняемых процессах;

данные о ресурсах, требуемых для выполнения процессов.

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

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

иих взаимозаменяемости;

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

данные о технических, физических и других характеристиках изделия;

111

классификационные и идентификационные данные об изделии

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

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

текстовая документация;

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

данные о разработчиках;

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

данные о качестве изделий;

данные об эксплуатации изделия.

Приведенный перечень не является полным и может быть расширен.

Многие из перечисленных типов данных требуют для своего представления сложных специфических информационных моделей, учитывающих семантику данных и правила работы с ними. Например, международные стандарты ИСО 10303 и ИСО 15384 регламентируют технологию представления данных об изделии и его компонентах на стадии проектирования и подготовки производства, стандарты ИЛП [DEF STAN 0060] – представление данных об изделии в контексте обеспечения эффективной эксплуатации, стандарты серии ИСО серии 9000 рассматривают данные о качестве изделий.

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

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

112

Классификационные характеристики ресурсов:

По типу физической природы:

материальные;

финансовые;

информационные;

трудовые;

временные;

энергетические;

другие.

По характеру расхода и возобновления:

не расходуемые (используемые);

расходуемые, но возобновляемые;

расходуемые безвозвратно.

По профилю доступности:

доступные постоянно;

доступные в соответствии с расписанием.

По способу измерения величины:

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

измеряемые в логических единицах (есть/нет).

Структуры данных, описывающих ресурсы различного типа, регламентируются стандартом ИСО 15551.

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

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

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

113

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

Рис. 18. Состав данных на различных этапах жизненного цикла

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

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

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

114

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

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

Модели данных (или их части) могут быть представлены с использованием различных технологий (ИСО 10303-11 Express, ИСО 8879 SGML и т.д.), которые должны быть логически взаимоувязанными. При преобразовании данных из одной формы в другую объекты информационных моделей должны интерпретироваться однозначно (mapping). Один из вариантов такой технологии изложен в стандарте ИСО 18876.

Приведение совместно используемых в ходе ЖЦ данных к единой стандартизованной информационной модели существенно упрощает построение интегрированной информационной системы, поскольку позволяет применять коммерческие (COTS) прикладные решения для различных конкретных задач (рис. 19).

Рис. 19. Интеграция прикладных коммерческих решений

115

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

Контрольные вопросы

1.Каково основное назначение CALS-технологии?

2.Каковы основные принципы данной технологии?

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

116

12.ВНЕДРЕНИЕ КИС. МЕТОДИКИ ВНЕДРЕНИЯ КИС. ЖИЗНЕННЫЙ ЦИКЛ КИС

12.1.Жизненный цикл программного обеспечения. Модели жизненного цикла

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

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

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

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

-кодирование (программирование);

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

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

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

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

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

Наибольшее распространение получили три модели ЖЦ:

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

2.Поэтапная модель с промежуточным контролем (80 – 85 гг.)

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

117

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

3. Спиральная модель (86 – 90 гг.) – делает упор на начальные этапы ЖЦ: анализ требований, проектирование спецификаций, предварительное и детальное проектирование. На этих этапах проверяется

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

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

Спиральная модель обладает следующими преимуществами:

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

-происходит ориентация на развитие и модификацию ПО в процессе его проектирования

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

жек.

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

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

Рассмотрим этапы ЖЦ более подробно.

Анализ требований: требования заказчика уточняются, формализуются и документируются. На этом этапе дается ответ на вопрос: «Что должна делать система?».

Список требований к разрабатываемой системе должен включать:

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

-описание функций системы;

118

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

Целью анализа является преобразование общих, неясных знаний

отребованиях к будущей системе в точные (по возможности) определения. На этом этапе определяются:

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

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

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

Этап проектирования: дает ответ на вопрос «Как (каким образом) система будет соответствовать предъявленным требованиям?».

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

Обычно этот этап разбивают на два подэтапа:

-проектирование архитектуры ПО – разработка структуры и ин-

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

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

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

12.2. Подготовка к внедрению или разработке системы. Процесс внедрения

Процесс разработки и внедрения КИС исполняется по следующему сценарию:

1. Делается анализ существующих систем или разработка требований к создаваемой системе

119

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

2.1.Разработка стратегии автоматизации

2.2.Анализ деятельности предприятия.

2.3.Реорганизация деятельности.

2.4.Выбор системы.

2.5.Внедрение системы.

2.6.Эксплуатация.

К типичным проблемам при внедрении КИС относят:

-подготовку предприятия к автоматизации;

-выбор системы.

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

 

 

 

 

 

 

Таблица 1

 

Функции системы и их плюсы использования

 

Функция системы

Позволяет делать

Качественный выигрыш

 

 

существительное

 

 

 

 

1

2

 

 

 

3

 

 

 

Блок проектирования

 

 

 

Item Part Number Control

Управляет структурой из-

Повышение

точности

данных

(Управление

структурой

делия с точностью до ком-

для планирования производст-

изделия)

 

плектующих (узлов и агре-

венной деятельности, обеспече-

 

 

гатов)

 

 

ние стыка с системами проек-

 

 

 

 

 

тирования

 

 

Bill of Materials Control

Контролирует

весь

пере-

Повышение

точности

данных

(Управление

специфика-

чень материалов, требуе-

для планирования производст-

циями продуктов)

мых для производства ко-

венной деятельности, обеспече-

 

 

нечного изделия (как коли-

ние стыка с системами проек-

 

 

чественно, так и в финансо-

тирования

 

 

 

 

вом эквиваленте)

 

 

 

 

 

Блок контроля инженерной документации

 

 

 

 

 

 

 

Routings (Маршрутизация)

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

Оптимальная

загрузка

цехов

 

 

потока заказов

по

цехам

(оборудования)

 

 

 

(рабочим местам)

 

 

 

 

Estimating (Смета)

Оценка влияния изменений

Точный учет затрат, связанных

 

 

 

 

 

с изменениями

 

Design Engineering (Разра-

Подготавливает

техноло-

Оптимальная

технология вы-

ботка технологии)

гию выпуска продукции

пуска продукции

 

 

 

Блок управления закупками

 

 

Vendor Performance (Ис-

Учет исполнения заплани-

Точный учет запасов, повыше-

полненные поставки)

рованных поступлений

ние достоверности планирова-

 

 

 

 

 

ния

 

 

120