Губанов Юрий Александрович, mail Критерии зачёта min 50% посещаемость доклад
| Вид материала | Доклад |
- Тест Протекание процесса cопровождается изменением поверхностного натяжения и площади, 14.96kb.
- Н. И. Губанов, Н. Н. Губанов, 204.22kb.
- Расписание утверждаю, 181.55kb.
- Домашнее задание ответа на зачете Алгоритм формирования оценки таков: вес посещаемости, 76.53kb.
- Открытый конкурс. Наименование, почтовый адрес, номер контактного телефона, 1173.49kb.
- Георгий Владимирович Майер. Приветственное слово. Заместитель Губернатора Томской области,, 738.23kb.
- Прогнозирование потребности в педагогических кадрах в регионе фролов Юрий Викторович, 113.56kb.
- Тюняев Андрей Александрович заведующий сектором, Институт Древнеславянской и Древнеевразийской, 75.03kb.
- Проект технического задания на проведение научной деятельности, 50.64kb.
- Стенографический отчет Заседание секции №6 «Методология мониторинга законодательства, 858.4kb.
Система и ее окружение
Любая система зависит от сигналов или данных, поступающих на ее входы, т.е. система функционирует в определенном окружении, которое влияет на ее функционирование и производительность.
На рисунке показано несколько систем, объединенных в систему жизнеобеспечения офисного здания:
Рассмотрим систему безопасности здания. К ее локальному окружению относятся остальные системы здания, а также внешние системы (системы улицы, города).
Причины, по которым необходимо учитывать окружение системы при их разработке:
- Во многих случаях система предназначена как раз для реагирование на изменение параметров окружения (например, система отопления или кондиционирования)
- Часто функционирование системы может зависеть от параметров окружения самым непредсказуемым образом (например, грозовой разряд индуцирующий гигантские токи в электрических цепях, что может "спалить" телевизор или компьютер)
Кроме физического окружения существует также организационное окружение, которое может быть иметь критическое значение для системы. Например, если при внедрении системы на предприятие персонал потеряет в заработке или понизится требуемый уровень профессионализма (можно будет выгнать профессионалов и нанять низкоквалифицированный персонал), система может быть принята в штыки вплоть до саботажа. К сожалению, эти факторы очень сложно предусмотреть.
В идеале, все сведения о системном окружении следует включить в спецификацию, но это совершенно невозможно в реальной жизни. Поэтому разработчики систем делают предположения об окружении либо на основе опыта эксплуатации подобных систем, либо исходя из здравого смысла.
Моделирование систем
В процессе формализации требований к системе и на этапе проектирования система рассматривается как совокупность компонентов и связей между ними. Архитектуру системы обычно представляют в виде блок-схемы следующего вида:
На этом уровне детализации система разбивается на подсистемы, каждую из которых, в свою очередь, можно далее декомпозировать. Подсистема обычно выполняет несколько функций.
Исторически сложилось так, что модель системной архитектуры используется для разбиения системы на аппаратные и программные компоненты. В современных системах такое противопоставление чаще всего несущественно, потому что компоненты системы чаще всего сами обладают некоторыми вычислительными возможностями (например, сеть, состоящая из репитеров, шлюзов, мостов и т.п. устройств, которые могут содержать внутри себя процессоры и управляющие программы). К тому же зачастую решение, что будет реализовано аппаратно, а что программно, принимается на поздних этапах проектирования (например, в телефонах — "влезает" ли необходимый код в процессор или нет). Поэтому на уровне системной архитектуры имеет смысл классифицировать подсистемы в соответствие с выполняемыми функциями.
Процесс создания систем
Процесс создания систем показан на следующем рисунке:
Основные различия между процессом создания систем и процессом разработки ПО следующие:
- Вовлечение в процесс разработки систем разнообразных инженерных дисциплин. Может привести к значительным затруднениям в разработке систем, поскольку у каждой дисциплины своя терминология. (можно наблюдать уже даже на программных системах — пример с разработкой игр. А что происходит в аппаратно-программных системах!)
- Небольшой масштаб повторных работ. После того, как приняты основные решения, внесение изменений в систему может быть крайне дорогостоящим, перепроектирование же может быть вообще невозможным. Это является одной из причин широкого использования ПО (которое имеет необходимую гибкость) в разработке систем.
Для многих систем существует бесконечное количество способов декомпозиции на подсистемы. Выбор одного из них не обязательно основывается на технических аргументах. Мотивы принятия того или иного решения могут выражать интересы одной из сторон, участвующих в разработке (например, строители при постройке нового радара в системе управления полетами). При этом могут привлекаться и технические аргументы в пользу такого решения.
Проект может меняться также в процессе создания системы. Например, если при создании системы управления полетами выясняется, что один из радаров установлен неправильно, что дает эффект раздвоения изображения на экране локатора, то из двух возможных решений — перенос радара (миллионы долларов) и создание специализированного ПО (десятки тысяч) выберут второе. Причем зачастую потребовав решения без увеличения стоимости аппаратных средств, а также без ухудшения производительности и прочих параметров.
Определение системных требований
На этапе определения системных требований формируются и формализуются требования к системе, как к единому целому (не формируются требования к компонентам). Требования обычно бывают следующих типов:
- Общие функциональные требования. Основные функции, выполняемые системой, на самом высшем уровне абстракции. Детализация этих требований происходит уже на уровне подсистем.
- Системные свойства. Это производные свойства, обсуждаемые чуть выше (производительность, безотказность и т.п.).
- Свойства, которые должны отсутствовать у системы. Иногда важнее указать, что НЕ должна делать система, чем указать, что она делать должна. Пример - не предоставлять избыточную информацию оператору СУП.
Важной частью этапа определения требований является описание множества целей, к выполнению которых должна стремиться система. Обычно именно на языке целей разговаривают высшие менеджеры, решающие проблемы своих организаций (в отличие от языка конкретных решений, на котором обычно разговаривают разработчики). Пример описания целей:
- Система должна обеспечить предупреждение о возгораниях внутри или в непосредственной близости от здания.
- Система должна гарантировать отсутствие серьезных нарушений в нормальном функционировании и эксплуатировании здания вследствие возгорания.
Первая формулировка ограничивает возможности проектирования системы, вторая дает больше свободы и потенциально больше функциональности.
Иногда основная трудность в определении системных требований состоит в том, что система строится для облегчения решения "злостной" проблемы (wicked problem) - проблемы очень большой сложности, не имеющей решения и более-менее точной модели решения. Пример - сейсмические системы (в настоящее время никаких мало-мальски точных прогнозов времени и характера землетрясений не существует). Действия в случае землетрясения невозможно спланировать, их возможно только предпринять во время самого землетрясения.