Формирование системного окружения

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

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

Например, задана функция принадлежности - цвет элемента. Процедура заключается в переборе всех имеющихся элементов, анализе цветовой характеристики этих элементов и отнесении к системе тех из них, характеристика которых соответствует заданной. Если отобранные элементы имеют пространственное закрепление, то мы получим физическую границу системы. В любом случае до того момента, как мы начнем изготавливать систему, нам достаточно изобразить ее в виде прямоугольника, который имеет четыре грани. Левая - грань исходной информации, “обрабатывая” которую система достигает поставленной цели. Правая - результирующая информация о характеристиках цели, позволяющих сделать однозначное заключение о достижении цели. Верхняя - грань управления, через которую в “систему” передается сформулированная на понятном “системе” языке цель и ограничения, формирующие условия достижения цели.

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

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

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

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

Рассмотрим (рис.2) наиболее часто встречающиеся структурные составляющие системного окружения, пользуясь, в основном, качественными определениями.

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

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

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

1. Спроектировать, изготовить и эксплуатировать коммерческую систему, обеспечивающую пользователей ПЭВМ сервисными услугами.

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

3. Спроектировать, изготовить и эксплуатировать коммерческую систему, реализующую функцию “таможенный склад” в заданном месте.

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

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

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

1. Опытная эксплуатация, выход на достижение заданных параметров результата.

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

3. Ликвидация системы в связи с истечением срока службы, физическим или моральным старением, изменением цели.

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

Стоимость. Любая система проектируется исходя из двух посылок:

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

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

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

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

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

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

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

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

Дата добавления: 2014-11-14; просмотров: 261; Нарушение авторских прав

Мы поможем в написании ваших работ!