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

Система – это целенаправленное множество взаимосвязанных элементов любой природы.

Важное свойство – это направленность на достижение цели.

Граница системы – определяет множество элементов, которые входят в рассматриваемую систему. 

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

Границы системы определяются целью.

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

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

2. Общая характеристика процесса проектирования АСОИиУ. Основные стадии процесса проектирования.

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

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

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

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

1. ГОСТ Р ИСО МЭК 15288 – ИТ. СИСТЕМНАЯ ИНЖЕНЕРИЯ. ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА СИСТЕМ
2. ГОСТ Р ИСО 12207-95 Программная инженерия – процессы жизненного цикла программных средств.

1. БАЗОВЫЙ МЕЖДУНАРОДНЫЙ СТАНДАРТ – РУКОВОДСТВО  В ОБЛАСТИ  ПРОГРАММНОЙ ИНЖЕНЕРИИ ЗНАНИЙ (SWEBOK) 
2. UP – УНИФИЦИРОВАННЫЙ ПРОЦЕСС СОЗДАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ 
3. ГОСТ 34.601-90 АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. СТАДИИ СОЗДАНИЯ 

СТАДИИ СОЗДАНИЯ АСОИиУ

ГОСТ 34.601-90 АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. СТАДИИ СОЗДАНИЯ

Стадии	Этапы работ
1. Формирование требований к АС	1.1. Обследование объекта и обоснование необходимости создания АС
	1.2. Формирование требований пользователя к АС
	1.3. Оформление отчета о выполненной работе и заявки на разработку АС (тактико-технического задания)
2. Разработка концепции АС	2.1. Изучение объекта
	2.2. Проведение необходимых научно-исследовательских работ
	2.3. Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователя
	2.4. Оформление отчета о выполненной работе
3. Техническое задание	3.1. Разработка и утверждение технического задания на создание АС
4. Эскизный проект	4.1. Разработка предварительных проектных решений по системе и ее частям
	4.2. Разработка документации на АС и ее части
	8.2. Послегарантийное обслуживание
5. Технический проект	5.1. Разработка проектных решений по системе и ее частям
	5.2. Разработка документации на АС и ее части
	5.3. Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку
	5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации
6. Рабочая документация	6.1. Разработка рабочей документации на систему и ее части
	6.2. Разработка или адаптация программ
7. Ввод в действие	7.1. Подготовка объекта автоматизации к вводу АС в действие
	7.2. Подготовка персонала
	7.3. Комплектация АС поставляемая изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)
	7.4. Строительно-монтажные работы
	7.5. Пусконаладочные работы
	7.6. Проведение предварительных испытаний
	7.7. Проведение опытной эксплуатации
	7.8. Проведение приемочных испытаний
8. Сопровождение АС	8.1. Выполнение работ в соответствии с гарантийными обязательствами
	8.2. Послегарантийное обслуживание

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

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

КОМПОНЕНТЫ АВТОМАТИЗИРОВАННЫХ СИСТЕМ

Регламентируются:

ГОСТ 34.003-90 «АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ Термины и определения»

Включает:

1. Пользователь 
2. Эксплуатационный персонал 
3. Совокупность видов обеспечения 

Виды обеспечения: 

• Программное

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

• Математическое

Совокупность математических методов, моделей и алгоритмов, примененных в АС

• Информационное

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

• Техническое
• Методическое
• Правовое
• Организационное
• Эргономические

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

• Лингвистические

 

4. Модели проектирования программного обеспечения. Каскадная модель. 

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

Фазы идут в таком порядке:

1. Определение требований
2. Проектирование
3. Конструирование (также «реализация» либо «кодирование»)
4. Тестирование и отладка (также «верификация»)
5. Инсталляция
6. Поддержка

Переход от одной фазы к другой происходит только строго после полного и успешного завершения предыдущей

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

]Критика каскадной модели и гибридные методологические решения

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

Каскадная модель

 

5. Модели проектирования программного обеспечения. Спиральная модель

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

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

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

• оценка и разрешение рисков,
• определение целей,
• разработка и тестирование,
• планирование.

На каждом витке спирали могут применяться разные модели процесса разработки ПО. В конечном итоге на выходе получается готовый продукт. Модель сочетает в себе возможности модели прототипирования и водопадной модели. Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная задача — как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Основная проблема спирального цикла — определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. Одним из возможных подходов к разработке программного обеспечения в рамках спиральной модели жизненного цикла является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки программного обеспечения, содержащий 3 элемента:

1. небольшую команду программистов (от 2 до 10 человек);
2. короткий, но тщательно проработанный производственный график (от 2 до 6 месяцев);
3. повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.

Жизненный цикл программного обеспечения по методологии RAD состоит из четырёх фаз:

1. фаза определения требований и анализа;
2. фаза проектирования;
3. фаза реализации;
4. фаза внедрения.

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

Спиральная модель

 

Особенности моделей ЖЦ

 

1. Исходные данные для проектирования АСОИиУ. Исследование объекта автоматизации. Назначение. Методы исследования. Способы представления результатов исследования.

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

• ДАННЫЕ
• ПРОЦЕССЫ
• СОБЫТИЯ

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

Назначение анализа

1. Выяснить объекты, связи, ограничения, действующие в системе.
2. Определить требования к системе
3. Определить цель совершенствования системы
4. Определить критерии оценки достижения цели

Создаваемые результаты

• Глоссарий бизнеса
• Оценка целевой организации
• Бизнес процессы 
• Бизнес-правила

Изобразительные схемы:

Модель бизнес-процессов –IDEF0 

Модель деятельности –IDEF3 

Модель потоков данных — DFD 

Методы получения исходных данных

1. Наблюдения

2. Беседы, интервью 

3. Документы

4. Опросы, анкеты (как дополнение к интервью)

5. Семинары

Методы представления результатов исследования:

• Описательный
• Формализованный

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

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