Что такое границы системы

граница системы

3.32 граница системы (system boundary): Совокупность критериев, определяющих единичные процессы, являющиеся частью системы жизненного цикла продукции.

3.32 граница системы (system boundary): Совокупность критериев, определяющих единичные процессы, являющиеся частью системы жизненного цикла продукции.

6.6 граница системы (system boundary): Совокупность критериев, определяющих единичные процессы (6.4.1), являющиеся частью системы жизненного цикла продукции (6.1).

Полезное

Смотреть что такое «граница системы» в других словарях:

граница системы (в экологическом менеджменте) — Линия раздела между продукционной системой и окружающей средой или другими продукционными системами. [http://www.14000.ru/glossary/main.php?PHPSESSID=25e3708243746ef7c85d0a8408d768af] EN system boundary Interface between a product system and the… … Справочник технического переводчика

граница или предел ввода регулирующих стержней системы управления и защиты при аварии ядерного реактора — — [А.С.Гольдберг. Англо русский энергетический словарь. 2006 г.] Тематики энергетика в целом EN control rod insertion limit … Справочник технического переводчика

Граница эксплуатационной ответственности систем теплоснабжения — граница эксплуатационной ответственности линия раздела элементов системы теплоснабжения по признаку обязанностей (ответственности) по эксплуатации тех или иных элементов систем теплоснабжения, устанавливаемая соглашением сторон; при отсутствии… … Официальная терминология

Граница балансовой принадлежности объектов электросетевого хозяйства — граница балансовой принадлежности линия раздела объектов электроэнергетики между владельцами по признаку собственности или владения на ином предусмотренном федеральными законами основании, определяющая границу эксплуатационной ответственности… … Официальная терминология

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

Граница раздела — поверхность, отделяющая друг от друга фазы, макроскопические части физико химической системы, различающиеся по свойствам и/или составу. [Ушеров Маршак А. В. Бетоноведение: лексикон. М.: РИФ Стройматериалы. 2009. – 112 с.] Рубрика термина:… … Энциклопедия терминов, определений и пояснений строительных материалов

Граница зоны обнаружения — 3.5 Граница зоны обнаружения Условная линия, соединяющая точки, расположенные на наибольших радиальных расстояниях во всех направлениях, на которых извещатель выдает извещение о проникновении при обнаружении им стандартной цели, перемещающейся к… … Словарь-справочник терминов нормативно-технической документации

Граница — (Border) Содержание Содержание 1. Виды границ 2. Государственная 3. Установление границ 4. Обозначение границы 5. Регламентация пересечения границы 6. Охрана границы 7. Граница как объект архитектуры 8. Граница Граница — это реальная или… … Энциклопедия инвестора

интерфейс системы управления лифта — 3.4 интерфейс системы управления лифта: 1 Граница системы управления лифта; 2 Интерфейс, специально предназначенный для получения электрического сигнала(ов) из системы пожарной сигнализации. Источник: ГОСТ Р 52383 2005: Лифты. Пожарная… … Словарь-справочник терминов нормативно-технической документации

логическая система (сети и системы связи) — Объединение посредством логических узлов всех связывающихся прикладных функций, которые выполняют общую задачу управления подстанцией. Примечание. Граница системы задается ее логическими или физическими интерфейсами. [ГОСТ Р 54325 2011 (IEC/TS… … Справочник технического переводчика

Источник

Что такое границы системы

При самом упрощенном понимании среда представляет собой то, что выступает некоторым окружением системы, а при более сложном подходе средой данной системы будет система, состоящая из элементов ей не принадлежащих. Подчеркнем, что среда — это не просто окружение системы, а то из этого окружения, что жизненно важно для системы.

Значительный вклад в понимание природы среды внес один из самых выдающихся социологов ХХ ст., ведущий представитель системного и функционального подходов в социологии немецкий социолог-теоретик Никлас Луман (1927-1998). В центр своего исследования он поставил отношение «система — окружающий мир», где возникает точка отсчета для понимания природы как системы, так и среды. Система характеризуется тем, что она отграничена от окружения как область меньшей «комплексности» от области большей «комплексности». Н. Луман постоянно подчеркивает, что система и среда органично связаны и не могут быть поняты друг без друга. Система начинается там, где идет отграничение от окружающей среды.

Граница системы — это совокупность объектов, которые одновременно принадлежат и не принадлежат данной системе. Н. Луман писал, что если система возникла, то способна к самоограничению и благодаря этому отграничивает себя от окружающей среды. При этом следует обратить внимание на то, что границы системы и среды всегда зыбки и текучи. Каждая функция системы задает свои границы. Поэтому система отделена от окружающей среды не четкой линией, а пограничным пространством, которое соткано из границ системы, образуемых при реализации ею той или иной функции. Например, фирма как организация имеет одни границы, которые не совпадают с границами ее как субъекта рыночных отношений, и совокупность ее функций формирует границы системы.

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

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

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

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

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

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

Исходя из этого по отношению к среде можно выделить несколько важнейших тезисов.

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

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

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

Четвертый — среда вездесуща, находится не только за пределами системы, но и внутри нее. Внешняя среда выступает средой обитания системы, а внутренняя — ее жизни (рис. 13). Это означает, что из внешней среды система черпает жизненные ресурсы, а внутренняя выступает организмом системы. Внутренняя и внешняя среда системы находятся во взаимной зависимости и взаимной обусловленности.

Рис. 13 — Внутренняя и внешняя среда системы

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

Разнообразие среды

Среда характеризуется известным разнообразием, различающимся по масштабам, степени активности и характеру воздействия на систему (табл. 15).

Таблица 15 — Типология среды

Обратим внимание на важный аспект в понимании среды. Как отмечает В. Г. Афанасьев: «Среда — важный фактор дифференциации целостных систем» [2, с. 158]. И далее: «В связи с тем, что внешняя среда имеет огромное значение для функционирования целостной системы, в познании следует учитывать зависимость свойств системы как от внутренних факторов — состава и структуры, так и от процессов, происходящих в окружающих ее условиях. Окружающие условия — это необходимый фон, на котором и при участии которого развертывается функционирование целого» [2, с. 159]. Отсюда следует зависимость, обусловленность системы средой является важнейшим направлением научных исследований систем любой природы, их анализа и осмысления.

Углубление понимания среды показывает, что среда представляется неоднородной. Для нее свойственны следующие характеристики:

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

Источник

Практика формирования требований в ИТ проектах от А до Я. Часть 3. Функции системы и Границы проекта

VI Определяем функции системы и границы проекта

Каждая модель ограничена в своих ответах, но нет ограничения на то, как и что моделирует модель, как нет ограничения на человеческую мысль
Дуглас Т. Росс

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

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

Границы проекта (project scope) показывают, какая область конечного продукта будет реализована в текущем проекте. Другими словами, определяется черта между тем, что мы будем делать сейчас и тем, что отложим на потом или от чего вообще сможем отказаться. Для этого в арсенале команды должен быть инструмент, позволяющий не просто строить модели создаваемого продукта, а помогающий наглядно очертить рамки автоматизируемых процессов, а также предоставлять возможность легко выносить процессы за границу или включать их обратно. Это очень важно для осознания и более качественного планирования объемов работ. Подобный инструмент полезен не только для «борьбы» с непомерными желаниями заказчика, но и для маневров менеджмента со стороны разработчиков.

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

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

Рисунок 6.1 — модель процесса определения функций

1. Используем нотацию IDEF0 для определения функций системы и границ проекта

Наиболее удобной методикой функционального моделирования, с точки зрения определения границ проекта, на мой взгляд является “старая добрая” методология проектирования SADT, использующая иерархическую декомпозицию сверху вниз. Применение диаграмм IDEF0 имеет следующие преимущества перед аналогами:

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

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

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

2. Пример описания функции “Управление требованиями”

Хочу напомнить основные постулаты стандарта IDEFO. Графическую конструкцию стандарта составляют: понятие «Работа» (Activity) для обозначения действия, представленная в виде блока; четыре вида интерфейса: «Вход» (Input), «Выход» (Output), «Управление» (Control) и «Механизм» (Mechanism), представленный в виде дуг. Левая сторона блока предназначена для входов, верхняя — для управления, правая — для выходов, нижняя — для механизмов. Для более подробного изучения этой темы обратитесь к [2].

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

Рис.6.2 – Функциональная модель системы Управления требованиями верхнего уровня

Проваливаясь во внутрь функции (блока «Работа») мы попадаем на следующий уровень абстракции функциональности системы. Вначале мы видим только потоки данных, выявленные на предыдущем этапе (уровне), см. рис. 6.3.

Рис.6.3 – Начало работы по детализации функции Управление ИТ проектами

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

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

Рис.6.4 – Определение подпроцессов для функции Управление ИТ проектами

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

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

Пример модели этих функций с уже установленными взаимосвязями отображены на Диаграмме см. Рис. 6.5.

Рис.6.5 – Функциональная модель системы Управления требованиями

Если такие диаграммы используют в документе необходимо сопровождать их подробным описанием. Дальше приведен пример описания:

На рисунке видно, что функциональную архитектуру нашего проекта представлена в виде четырех доменов:

Из диаграммы видно, что блок “А1” имеет обратную связь от блока “А2”, в виде управляющей информации, доводящей о степени реализации требований, сформированных по Пользовательским историям (дуга «Отчет о реализации требований»). Эта связь позволяет отследить ход и полноту реализации Пользовательской истории в конечном продукте по цепочке, через спецификации требований.

Второй блок, как показано на схеме, получает на вход обработанные пожелания заказчика в виде Пользовательских историй, потребностей пользователей и т.п. уже в формализованном виде. На основании этих данных в нем формируются функциональные требования к разрабатываемому продукту и формализуются в виде спецификаций требований. Дальше эти спецификации передаются в четвертый блок “А4”, отвечающий за выставление задания исполнителям на их реализацию. Из диаграммы видно, что задания могут выставляться и на выполнение работ с требованиями (дуга «Задания», входящая в качестве управления в блок “А2”). Обратите внимание на то, что во второй функциональный блок возвращаются данные об исполнении заданий по спецификациям, что позволяет в этом домене определить приращение функциональности, полученное в ходе разработки.

В третий блок направим из блока “А2”, в качестве управляющих инструкций, ключевые показатели спецификаций. На основании их можно определить степень достижения заданной функциональности, используя отчет о выполнении задний, выставленных по этим спецификациям исполнителям. Отчет поступает в виде входящих параметров из блока “А4”.

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

3. Пример описания функции “Сбор потребностей заказчика”

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

Заглянем в блок А1 на рисунке 6.4, представляющий домен «Сбор потребностей заказчика». Его детализация показана на рисунке 6.5. Все потоки данных, которые входили в блок А1 на рисунке 6.4, соответственно попали и в детализирующую его диаграмму см. рис. 6.6.

Рис. 6.6 – Схема домена Сбор потребностей заказчика

Функционально домен мы разделили на четыре процесса:

4. Пример описания функции “Управления спецификациями требований”

Следующее уточнение произведем с доменом «Управление спецификациями требований проекта» (А2). На рисунке 6.7 изображена диаграмма этой модели.

Функционально домен делим на четыре процесса:

5. Пример описания функции “Управление заданиями”

На рисунке 6.8 изображена диаграмма, представляющая домен Управления Заданиями проекта (А4). Функционально домен мы разделили на четыре процесса:

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

Для процесса 5.2 опишем следующую Пользовательскую историю:

US12. На основании плана итераций проекта отобрать пул задач, которые необходимо реализовать на данном этапе.
Цель: Получить список задач для реализации в текущей итерации проекта.

Процесс 5.3 затрагивает несколько Пользовательских историй:

US13. Подготовить требования, которые необходимо будет реализовать, при наступлении прогнозируемого риска.
Цель: Выработать альтернативные решения для реализации потребности заказчика, при возникновении проблем.

В случае наступления риска, выполняется пользовательская история US8.

6. Пример описания функции “Управление выполнением”

На рисунке 6.9 изображена диаграмма, представляющая домен Управления выполнения проекта. Реализация этого домена немного выходит за рамки нашего проекта, но тесно с ним связана. Поэтому рассмотрим и его.

Рис. 6.9 – Схема домен Управления выполнения проекта

Функционально домен мы разделили на четыре процесса:

7. Подведем итоги процесса определения функций системы и границ проекта

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

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

В итоге, опираясь на разработанные нами диаграммы, мы можем на первом этапе вынести за рамки проекта функции группы «А3 Управления выполнением», а также функции «А4.2 Формирование заданий на итерацию» и «А4.3 Формирование заданий при наступлении риска». Из диаграммы видно, что в результате система лишится потока данных — «задания исполнителям», обусловленных работами по нивелированию рисков.

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

В следующей части мы будем детализировать процессы, включенные в рамки системы ссылка
.

Источник