Проектирование АСОИУ

ЛК1

Лб и Курсовую будет вести Сеньков Алексей Викторович. Помогать будет Захаров Андрей Сергеевич.

Проектирование АСОИУ, что такое АСОИУ.

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

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

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

2. Экономия средств. С этим вопросом надо быть очень аккуратным.

Самое сложное продать продукт, который не решает проблемы. Но такие прецеденты бывали.

После выяснения всех моментов с заказчиком составляется договор. После этого разработчик начинает работу. Задача аналитика – это решения перевести в бизнес-процесс. Он должен сделать на выходе бизнес-процессы как должно быть. Но есть ГОСТ 34 или 19 о разработке приложения. В ГОСТ 34 описан полный набор документов, которые должны быть оформлены на ПО. Главное ТЗ. В нем описываются функции системы. Фактически ТЗ не является описанием решения. Оно содержит в себе требования. Как правило ТЗ является приложением к договору. Аналитик должен сделать ТЗ, но в тоже время он работает по договору. Пред проектное обследование делается за счет разработчика. Бизнес процессы как должно быть описываются в проектной документации(технические проекты – целая папка документации, описывающая то что должно быть у нас на выходе.). В зависимости от того как построен процесс у разработчика какие то части делаются аналитиком а какие то проектировщику. Аналитик – это специалист, имеющие знания в предметной области, знает некоторые типовые решения, может выявить специфические проблемы и создать специфические решения, и некоторым образом описать это в виде бизнес процессе. БП как должно быть на его основании строится предположение как должно работать предприятие после внедрения ПО.

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

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

Получили продукт. Его надо внедрить заказчику. Для крупной системы важная часть обучения пользователей. Им надо рассказать какие были БП и о том как эти процессы будут себя вести после внедрения продукта. Как правило для упрощения Аналитиками создается регламент(регламент эксплуатации). Этот регламент должен описать переход на новую систему и этап штатного использования. Если переход происходит со старого на новую систему, исполнитель берет на себя задачу переноса данных. У всех заказчиков есть IT департамент. Почти у всех заказчиков все серверные мощности забиты под завязку.

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

Лаб . Объедины с КР. Должно получиться 2 документа. Отчет по КР и 2 отчета по лабам. 1-2 Аналитика 3-4 Проектировщик. В КР идет все из лаб + в начале добавляется проблемы, и в конце качество описать.

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

Концепции

Сущность(Действия порты события)связь участники Артефакты

потоки исполнения поток сообщений а

Классификация АСОИУ

Здесь выделяют как часто бывает 2 основных типа и их гибрид, в соответствии с природой процессов, протекающих в АСОИУ при их функционировании. Выделяют:

1. Технические системы

2. Экономические

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

Экономические АСОИУ в первую очередь относятся для управления организацией. К ним относят системы управления отраслями народного хозяйства, информационно-справочные, информационно-поисковые, системы электронного документо-оборота предприятия. Здесь требования по надежности и скорости обработки информации заметно смягчаются по сравнению с техническими системами. На первый план выходят задачи поиска информации и подготовки документов. Длительность процессов больше темп протекания медленне чем в технической системе. Для экономических АСОИУ характерно также долговременное хранение больших объемов информации. Естественно встречаются системы, включающие в себя как технические так и организационне элементы. Их принято называть организационно техническими. Сюда можно отнести системы управления промышленными предприятиями, а также какие либо системы широко применяющие технические средства, работу с которыми обязательно ведут люди.

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

Классификация АСОИУ по размерам ее действий:

1)Системы относительно отдельных процессов и операций

2) системы действующие на уровне предприятия

3) на уровне отрасли

4) на уровне государства

5) глобальные системы.

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

1. Системы реального масштаба времени

2. Системы с контрольным временем

3. Системы со свобоным временем

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

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

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

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

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

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

Техническая документация бывает

-Технологическая

- Монтажная

-конструкторская

-текстовая

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

Укрупненный процесс проектирования.

КТС – компекс технических средств

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

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

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

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

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

РИСУНОК 13-20

НИР-научно иследовательские работы

ОКР – опытно конструкторские работы

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

ЛК5

Фунциональная модель АСОИУ.

Функции выполнемые системой обычно могут быть представлены в виде совокупности взаимосвязанных задач. Функциональн модель АСОИУ – это отображение выполняемых системой функций. Элеменами функциональной модели являются функции системы или решаемой задачи, а связями – информационные связи между функциями. По скольку системы АСОИУ решают большие объемы задач, при чем разноплановых, причем взаимодействующих, построение функциональной модели часто оказывается просто необходимым для грамотного проектирования. В какой то степени те модели которые мы строим на ЛБ это функциональные модели. Функционавльная модель системы составляется обычно в 2 вариантах. То каким образом функционирует система управления до создания АСОИУ и то как она должна функционировать после. В разработке функциональной модели принимабт участие наиболее квалифицированные специалисты по системному анализу и созданию АСУ совместно с экспертами по создаваемой системе. Такая группа не должна быть многочисленной. Порядка 3-5 человек. Квалификация важна тем что такие модели составляются на ранней стадии создания. Ошибка приведет к неправильному созданию модели. Разработка функциональной модели включает себя:

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

2. Оптимизацию структуры создаваемой системы. Например, если самыми разными отделами решается одна и та же задача.

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

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

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

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

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