Синхронизация задач в СРВ. 3 страница

2. Создание более совершенных условий для функционирования объекта.

3. Трудоемкость и периодичность решения задач.

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

5. Наличие необходимых ресурсов.

6. Степень подготовленности предприятия к внедрению системы

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

Список не полный. Все зависит от конкретного объекта автоматизации.

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

1) Уровень цели;

2) Уровень показателей достижения целей;

3) Уровень подсистем;

4) Уровень задач.

Состав и структура АСОИУ: обеспечивающие и управляющие подсистемы

Состав и структура АСОИУ.

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

1) Функциональная подсистема;

2) Обеспечивающие подсистемы.

Обеспечивающие (управляющие) подсистемы.

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

При однотипности задач можно формировать следующие блоки:

1) Блок отслеживания работы критичных программных частей;

2) Блок отслеживания готовности устройств к работе;

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

4) Блок отслеживания аварийной ситуации, как на самом объекте, так и в системе.

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

Для обеспечения рабочей структуры системы следует:

1) Определить цель, которая должна быть достигнута при создании системы;

2) Сформировать концепцию системы;

3) Обследовать объект;

4) Проанализировать и получить ответ на вопрос «можно ли создать систему для достижения определенных целей в соответствии с формулированной концепцией»;

5) Уточняется состав и структура системы (если ответ «да»).

Под целями понимаются:

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

2) Коренное изменение и улучшение процесса управления объектом;

3) Достижение экономического эффекта.

19.Концепции системы: цели предприятия, цели АСОИУ. Содержание ТЗ на проектирование АСОИУ.

Концепции системы: цели предприятия

Концепция – система взглядов на что либо, основные мысли.

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

- Оптимизация процесса управления и сбора информации.

- Сокращение численности управленческого аппарата.

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

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

- Автоматизация отдельных функций управления.

- Изменение временных периодов функций управления (имеется в виду сокращение сроков).

- Повышение достоверности, своевременности сбора и обработки многофакторной информации.

Цели для поисковой системы:

· Многопараметровое формирование наборов данных и значений.

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

Определение целей связанно со следующими признаками:

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

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

· Средства сбора информации. Количество точек измерения иди терминалов, количество параметров, их характеристики, характеристика различных видов информации и вид её представления и отображения.

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

· Метод управления, диагностирования, поддержки обеспечения. Имеется в виду централизованный, сосредоточенный, смешанный, анализ ситуации по причинно-следственным диаграммам и показателям, прогнозирование – анализ работы системы.

· Средства реализации. ПК, суперПК, сети и т.д.

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

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

· Описание структуры производства и связей между структурами.

· Описание системы управления.

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

· Установить, какие вычислительные средства имеются на предприятии.

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

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

· Состав технических средств, их расположение и характеристики, способы решения задач, перечень основных показателей, способы представления данных.

· Состав основных требований к системе.

· Этапность реализации проекта, сроки выполнения.

· Финансовые и материальные затраты

Далее делается оценка возможности реализации выбранного проекта. Т.е.

· Наличие достаточного финансирования.

· Возможность реализации в заданные сроки.

· Наличие достаточного опыта и знаний для выполнения проекта.

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

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

· Для систем реального времени определить возможность соблюдения временных требований по обработке сигналов и их отображению.

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

· Изучение предметной области, построение концептуальной модели данных и знаний.

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

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

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

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

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

· Сбор и анализ информации.

· Подсистема обучения.

· Подсистема тестирования.

· Экспертная подсистема.

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

· Могут быть включены модули связи, мосты.

Все эти блоки можно отнести к обеспечивающим подсистемам.

· В общем виде концептуальное проектирование – это:

· Разработка будущей модели или системы, в том числе и информационной модели объекта.

· Способы решения задач, представления данных и знаний.

· Порядок реализации системы, включающий этап обследования, проектирования подсистем, реализация всей системы и её внедрение.

Концепции системы: цели АСОИУ

Для обеспечения рабочей структуры система должна:

1. Определить цели нашей системы

2. Сформулировать концепцию системы

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

4. Сформулировать состав системы и содержание системы

Под целями понимаются:

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

2. Коренное изменение и улучшение процесса управления объектом;

3. Достижение экономического эффекта.

----------

В общем виде концептуальное проектирование это:

1. Разработка модели будущей системы и информационной модели объекта;

2. Выбор способов решения задач представления данных и знаний;

3. Рассмотрение порядка реализации системы.

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

1. Описание структуры производства и связь между структурами;

2. Описание системы управления;

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

4. Есть ли ПК, периферия и какое используется ПО.

Далее необходимо провести концептуальное проектирование или сформировать черновой вариант системы, в котором надо определить:

1. Структуру системы;

2. Состав технических средств;

3. Выбрать способ решения задач, перечень основных показателей, определить способы представления данных;

4. Состав основных требований;

5. Определить этапы реализации проекта, сроки, финансовые и материальные затраты.

Далее делается оценка возможности реализации выбранного проекта. Сюда входит:

1. Наличие достаточного финансирования;

2. Возможность реализации в заданные сроки;

3. Определить наличие достаточного опыта и знаний для реализации проекта;

4. Наличие или возможность приобретения требующихся технических средств (ТС).

Далее следует этап концептуального проектирования. Здесь работа проводится в двух направлениях:

1. Изучение предметной области и построение концептуальной модели данных и знаний;

2. Разработка структуры предметной области.

Далее следует этап специфицирования. На нем:

1. Формируются все требования и показатели;

2. Составляется перечень документов и форм их представления в системе;

3. Описание связей в системе;

4. Описание всех режимов работы системы и всех ее подсистем.

В состав системы на этапе концептуального проектирования могут быть включены такие блоки:

1) Подсистема обучения; 2) Подсистема тестирования; 3) Экспертная подсистема.

Содержание ТЗ на проектирование АСОИУ

Техническое задание.

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

Содержание технико-экономического обоснования:

1) Характеристика объекта в данном предприятии, которое необходимо автоматизировать;

2) Цели, функции, задачи создания автоматизированных систем;

3) Ожидаемые технико-экономические результаты;

4) Выводы и предложения.

Разработка ТЗ при создании АСОИУ является завершающим этапом проектной стадии и заключается в предоставлении данных, необходимых для разработки системы.

ТЗ включает в себя:

1. Требования к комплексу и задачам;

2. Требования к техническим средствам;

3. Требования к информационному обеспечению;

4. Требования к математическому обеспечению.

При разработке ТЗ устанавливается очередь создания АСОИУ с указанием перечня подсистем и задач, входящих в состав системы.

Очередность разработки системы обуславливается следующими факторами:

1. Возможностью реализации данной подсистемы;

2. Возможностью использования технических средств;

3. Возможностью внедрения в наименьшие сроки тех или иных подсистем;

4. Подготовленностью предприятия;

5. Наиболее целесообразной технологической реализации всей системы с точки зрения общей суммы затрат;

6. Возможностью использования в последующих подсистемах результатов предыдущих подсистем;

7. Возможностью создания информационной базы системы.

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

ТЗ должно содержать:

1. Характеристику объекта и/или существующей системы управления;

2. Цели, функции, задачи создания АСОИУ;

3. Ожидаемые технико-экономические результаты.

Разделы ТЗ:

1. Наименование;

2. Основание для создания;

3. Цели;

4. Требования к АСОИУ;

5. Состав, содержание и организация работ по подготовке объекта к вводу системы в действие;

6. Показатели эффективности;

7. Порядок контроля и приемки системы;

8. Источники разработки.

Требования к системе обычно содержат:

1. Перечень автоматизированных органов управления с указанием условий и режимов эксплуатации АСОИУ;

2. Перечень функциональных подсистем и их основные характеристики;

3. Место АСОИУ в иерархии управления, ее взаимосвязи с системами управления других уровней;

4. Перспектива развития, модернизации, наращивание подсистемы.

Требования к функциям системы:

1) Перечень функций с указанием объемов и видов входной, выходной информации;

Требования к качеству и характеристикам реализации функции:

1. Точность;

2. Время решения данной функции;

3. Достоверность выдачи результата;

4. Периодичность форм представления информации;

5. Продолжительность и режим вычисления;

6. Режимы работы системы;

7. Режим работы рабочих мест.

Требования к совместимости с другими системами, способы обмена информацией с другими системами.

Требования к техническим средствам:

1. Виды технических средств;

2. Характеристики технических средств.

В ТЗ следует указать:

1. Требования по защите информации;

2. Требования по документированию;

3. Требования по надежности;

4. Требования к ПО.

В раздел состав/содержание необходимо включить:

1. Набор обеспечивающих систем;

2. Условия функционирования систем, при которых гарантируется соответствие требованиям ТЗ;

3. План работы, перечень организаций-соисполнителей;

4. Обоснование очередности работы.

Раздел «показатели эффективности» должен содержать:

1. Общие затраты по созданию АСОИУ по годам (месяцам), в том числе на НИР и ОКР, на приобретение техники, ее установку и пуск;

2. Ожидание экономии от внедрения системы;

3. Срок окупаемости затрат.

Раздел «порядок контроля и приемки» должен содержать:

1. План, форму испытаний;

2. Описание конкретных задач и примеров.

Раздел «источники разработки» должен содержать:

1. Перечень НИР;

2. Отчеты по ОКР;

3. Перечень защищенных авторами разработок на тему АСОИУ;

Список технической и научной литературы.

20.Требования к технологии проектирования систем. Стандарты проектирования, оформление проектной документации, использование интерфейса.

Требования к технологии проектирования систем Общие требования к методологии и технологии:

Технология – жесткая последовательность действий, приводящая к цели.

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

Технология проектирования определяется как совокупность трех составляющих:

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

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

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

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

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

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

2.технология должна обеспечивать гарантир достиж цели разработки ИС заданного качества и в установ время;

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

4.технология должна обеспечивать возможность проведения работ по пров. подсистем небольшими группами (3-7 человек). Это обусловлено принципами управляемости коллектива и повышение производительности за счет минимизации числа внешних связей;

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

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

7.технология должна обеспеч независимость выполняемых реш от средств реализации ИС (языки программ);

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

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

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

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

К таким стандартам относятся:

1. стандарты проектирования;

2. стандарты оформления проектной документации;

3. стандарты пользовательского интерфейса.

Стандарты проектирования должны устанавливать:

1. набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации;

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

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

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

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

1. комплектность, состав и структуру документации на каждой стадии проектирования;

2. требования к ее оформлению (содержание разделов, подразделов, графиков, таблиц);

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

4. требования к настройке издательской сист, используемой в качестве встроенного ср-ва подготовки докум-ции;

5. требования к настройке case-средств в соответствии с установленными требованиями.

Стандарты пользовательского интерфейса должны устанавливать:

1. правила оформления экранов, состав и расположение окон и элементов управления;

2. правила использования клавиатуры и мыши;

3. правила оформления текстов помощи;

4. перечень стандартных сообщений;

5. правила обработки реакций пользователя.

21.Моделирование потоков данных. Накопительные процессы данных, потоки данных

Моделирование потоков данных

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

Диаграммы верхних уровней иерархии определяют основные процессы и подсистемы ИС с внешними входами и выходами. Они детализируются с помощью диаграмм нижнего уровня.

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

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

Таким образом, основными компонентами диаграмм потоков данных являются: внешние сущности (входные данные), системы/подсистемы, процессы, накопители данных, потоки данных.

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

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

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

Накопительные процессы данных, потоки данных

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

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

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

Диаграммы верхних уровней иерархии определяют основные процессы и подсистемы ИС с внешними входами и выходами. Они детализируются с помощью диаграмм нижнего уровня.

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

Используется в АСОИУ, при проектировании структур баз данных.

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

Инструментом семантического моделирования являются различные варианты диаграмм «сущность – связь» или ER – диаграмм.

Сущность – это класс однотипных объектов, информация о которых должна быть учтена в модели. Каждая сущность должна иметь наименование (например, поставщик, сотрудник, сервис и т.д.).

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

Основные понятия ER – диаграмм

Основными компонентами диаграмм потоков данных являются:

1. Внешние сущности.

2. Системы и подсистемы.

3. Процессы.

4. Накопители данных.

5. Потоки данных.

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

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

1 название подсистемы

Подсистемы еще, как правило, нумеруются (для идентификации).

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

1.1 название процесса

В некоторых случаях процессы заменяются функциями.

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

D5 наименование данных

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