Методы системного проектирования

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

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

2. Изучение опыта  применения АСУТП  на аналогичных  объектах. Изучается опыт применения АСУТП по публикациям и путем непосредственного знакомства с наиболее близкими примерами аналогичных АСУТП.

3. Технико-экономическое  обследование объекта  и существующей  системы, управления.

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

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

РАЗДЕЛЫ:

1. «Характеристика  объекта и существующей  системы управления». Указывается место данного ТОУ в производственной структуре предприятия, общая характеристика и оценка перспективности действующего ТОУ. В приложениях приводятся технические условия на сырье, полуфабрикаты и готовую продукцию. Описывается принцип действия ТОУ и приводятся сведения о его конструктивном оформлении. В результате обследования четко формируются цели и критерии управления объектов, отражающие существующую систему материального и морального стимулирования операторов ТОУ всех уровней организационной структуры. Основными источниками количественной информации о принятом порядке стимулирования являются соответствующие разделы технологических инструкций, действующая система премирования и другие подобные материалы и положения.

2. Раздел «Цели,  критерии и ограничения  создания АСУ». Перечислены цели и критерии управления, ограничения, которые необходимо учитывать при создании системы, определяющиеся существующей на предприятии структурой управления, правилами разделения ответственности и функций.

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

3. Раздел «Исходные  технические требования  к АСУТП (функциональные  требования)» должен четкое упорядоченное перечисление желаемых функций создаваемой АСУТП, требований к качеству их выполнения, любых иных дополнительных требований заказчика.

4. Раздел «Дополнительные  исходные материалы,  необходимые для  разработки технического  задания на создание  АСУТП» Содержат сведения о:

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

 

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

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

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

РАЗДЕЛЫ:

1. «Общие сведения  о проекте»

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

2. «Назначение, цели  создания системы»

 I. Назначение системы

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

 II. Цели создания системы

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

 

  3. «Характеристика объекта автоматизации»

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

4. «Требования к  системе» 

I. требования к системе в целом

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

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

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

 III. требования к видам обеспечения.

• требования к математическому, программному, техническому, лингвистическому, информационному и методическому обеспечению АСУ ТП.

5.«Состав  и содержание работ  по созданию системы»

• перечень стадий и этапов работ по созданию системы в соответствии с ГОСТ 34.601 - 90
• сроки выполнения
• перечень организаций-исполнителей
• перечень документов по ГОСТ 34.201 - 89 «Виды, комплектность и обозначение документов при создании автоматизированных систем»
• вид и порядок проведения экспертизы технической документации

6.«Порядок  контроля приемки  системы»

• виды, состав, методы испытания системы и ее частей
• общие требования к приемке работ по стадиям
• порядок утверждения приемных документов
• статус приемочной комиссии.

7.«Требования  к составу и  содержанию работ  по подготовке  объекта автоматизации  к вводу системы  в действие»

• приведение информации, поступающей в систему, к виду, пригодному для ввода в ЭВМ
• создание условий функционирования объекта, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ
• создание необходимых для функционирования системы подразделений и служб сроки и порядок комплектования штатов и обучения персонала

8.«Требования  к документированию»

• перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201 - 89 и научно-технической документации отрасли заказчика.

9.«Источники  разработки»

• документы и информационные материалы (ТЭО, отчеты о законченных научно-исследовательских разработках, информационные материалы на отечественные, зарубежные системы-аналоги).

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

9.     Модели процесса  разработки. 

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

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

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

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

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

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

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

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

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

Артефакт – документ или иной материал, имеющий материальную форму и отчуждаемый от разработчика.

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

Экстремальное программирование (эволюционная стратегия) предложена Кентом Беком: в момент постановки задачи заказчик очень часто не имеет четкого представления о функциональности заказанного ПО, в результате чего образ программного проекта в процессе разработки постоянно меняется в его сознании. Из-за длительных циклов разработки требования, предъявляемые к программному продукту к моменту его готовности, уже не совпадают с заданными изначально.