Границы и структура системы

Содержание
  1. Системный анализ: лекции и учебные пособия. «Теория систем и системный анализ» (Ю. П. Сурмин)
  2. Разнообразие среды
  3. Практика формирования требований в ИТ проектах от А до Я. Часть 3. Функции системы и Границы проекта
  4. 1. Используем нотацию IDEF0 для определения функций системы и границ проекта
  5. 2. Пример описания функции “Управление требованиями”
  6. 3. Пример описания функции “Сбор потребностей заказчика”
  7. 4. Пример описания функции “Управления спецификациями требований”
  8. 5. Пример описания функции “Управление заданиями”
  9. 6. Пример описания функции “Управление выполнением”
  10. 7. Подведем итоги процесса определения функций системы и границ проекта
  11. 2.3. Границы системы
  12. 2.4. Уровень организованности перевозочной системы
  13. Границы. Границы системы или подсистемы представляют собой «правила, определяющие, кто и как участвует во взаимодействии» (Minuchin
  14. Структура, границы и функции политической системы

Системный анализ: лекции и учебные пособия. «Теория систем и системный анализ» (Ю. П. Сурмин)

Границы и структура системы

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

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

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

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

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

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

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

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

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

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

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

Сама система по отношению к другим системам также представляется таким фактором либо входит в обойму некоторого интегрального фактора.

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

Наконец, по четвертой концепции среда видится некоторой над-системой, т.е. такой, в которую входит данная система.

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

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

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

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

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

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

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

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

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

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

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

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

Еще вчера работник был во внешней среде, искал себе работу, но уже сегодня он работает в фирме, включен во внутреннюю среду и сам ощущает ее как внешнюю для себя.

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

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

Основание классификации Среда Вид Характеристика Масштаб Микросреда Макросреда Положение Внешняя Внутренняя Активность Активная Пассивная Характер активности Благодатная Нейтральная Агрессивная Уровень организованности Стихийная, неорганизованная Организованная Уровень управления Управляемая Неуправляемая Структура среды Гомогенная Гетерогенная Функциональное выражение Ресурсная Информационная Конфликтогенная Миссионерско-реализаторская
Ближайшее окружение системы, воздействующее на нее непосредственно
Широкое окружение системы, воздействующее на нее опосредованно
Окружает систему
Находится внутри системы
Высокая активность по отношению к системе, динамика перемен
Низкая активность по отношению к системе, отсутствие перемен
Представляет для системы источник ресурсов
Нейтральность по отношению к системе
Воздействует негативно на систему, расхищает ее ресурсы
Неорганизованность и непредсказуемость проявлений
Упорядоченность
Возможность регулирования системой
Система не может ей управлять
Однородное образование, включающее системы одной природы
Состоит из систем различной природы
Источник материальных, информационных, энергетических ресурсов
Частный вид ресурсной среды, когда в качестве ресурса выступает информация
Источник конфликтов и противоборства с системой
Поле реализации миссии системы

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

Обратим внимание на важный аспект в понимании среды. Как отмечает В. Г. Афанасьев: «Среда — важный фактор дифференциации целостных систем» [2, с. 158].

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

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

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

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

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

При этом границы системы, прежде всего, устанавливаются в пространстве. В бизнесе — это границы рынка, в государственном управлении — границы государства и т.п.

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

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

Источник: http://victor-safronov.ru/systems-analysis/lectures/surmin/27.html

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

Границы и структура системы

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

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

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

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

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

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

На рисунке 6.1 изображен процесс формализации требований к целевой системе, дополненный подпроцессом определения функций, которые она должна выполнять.
Рисунок 6.1 — модель процесса определения функций

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

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

Применение диаграмм IDEF0 имеет следующие преимущества перед аналогами:

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

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

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

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

Левая сторона блока предназначена для входов, верхняя — для управления, правая — для выходов, нижняя — для механизмов. Для более подробного изучения этой темы обратитесь к [2]. На первом шаге моделирования необходимо определить все потоки данных, поступающих в систему из вне (входные сигналы).

В нашем случае это:

  • Цели проекта;
  • Участники и заинтересованные лица проекта;
  • Потребности участников к функциональности целевого продукта проекта;
  • Методики разработки требований;

Далее определяем все “продукты”, генерируемые системой для внешнего использования (выходные сигналы):

  • Артефакты проекта, в том числе Требования, Модели, Планы и т, д.;
  • Целевой продукт проекта.

Описанные выше потоки данных и глобальная абстрактная функция системы, обрабатывающая эти потоки, отображены на Диаграмме см. Рис. 6.2.
Рис.6.2 – Функциональная модель системы Управления требованиями верхнего уровня Проваливаясь во внутрь функции (блока «Работа») мы попадаем на следующий уровень абстракции функциональности системы. Вначале мы видим только потоки данных, выявленные на предыдущем этапе (уровне), см. рис. 6.3.
Рис.6.3 – Начало работы по детализации функции Управление ИТ проектами Для каждого такого потока необходимо определить процесс, обрабатывающий (преобразующий) или использующий его, добавляя на диаграмме новые блоки «Работ» (функции), связанные с ним. Таким образом, при каждом последующем шаге (проваливаясь внутрь процесса) необходимо: каждому потоку данных, выявленному на предшествующем уровне, сопоставить функцию (процесс) для его обработки. В результате такого моделирования, мы получим перечень функций, детализирующих вышестоящий абстрактный процесс см. Рис. 6.3.
Рис.6.4 – Определение подпроцессов для функции Управление ИТ проектами В нашем проекте, согласно изложенным в главе IV целям и выявленным на первом этапе потокам данных, необходимо автоматизировать следующую группу процессов:

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

Один процесс «Управление заданиями» у нас не получает данные из вне и не предоставляет ничего во внешнее окружение. Получается — он вспомогательный процесс, обеспечивающий функционирование других. Он пока стоит обособлено см. рис. 6.4. Поскольку большинство процессов логически связаны между собой, необходимо установить все потоки данных, обеспечивающие эти связи. Таким образом от функции к функции на диаграмме появляются дуги. Позже, каждая такая дуга (связь), входящая в блок «Работы», должна будет, при моделировании следующего вложенного уровня, “получить” свой процесс обработки. Пример модели этих функций с уже установленными взаимосвязями отображены на Диаграмме см. Рис. 6.5.
Рис.6.5 – Функциональная модель системы Управления требованиями Если такие диаграммы используют в документе необходимо сопровождать их подробным описанием. Дальше приведен пример описания: На рисунке видно, что функциональную архитектуру нашего проекта представлена в виде четырех доменов:

  1. Сбор потребностей заказчика. Группа процессов по учету и анализу целей разработки продукта, основных сценариев его использования и действующих лиц — пользователей продукта.
  2. Управление спецификациями требований. Процессы формирования функциональных требований на основании выявленных потребностей заказчика и будущих пользователей целевого продукта.
  3. Управление формированием заданий. Процессы формирования заданий, направленные на удовлетворение выявленных потребностей заказчика, путем реализации функциональных требований. Фиксация результатов, при выполнении заданий исполнителями, путем изменения состояния требований, по которым оно сформировано.
  4. Управление выполнением. Процессы, выполняющие мониторинг и фиксацию приращения функционала, позволяющего реализовывать потребности пользователей в целевом продукте.

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

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

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

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

6 – Схема домена Сбор потребностей заказчика Функционально домен мы разделили на четыре процесса:

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

    Этот блок должен “покрывать” Пользовательские истории US01, US02

  2. Изменение Пользовательской истории. Процесс управления изменениями в описании потребностей заказчика продукта, включая инициацию процесса изменения связанных с ней системных требований. Этот блок должен “покрывать” Пользовательские истории US02.
  3. Фиксация заинтересованных лиц проекта.

    Выявляются все лица, так или иначе связанные с проектом. Этот процесс должен “покрывать” Пользовательские истории US04

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

    Этот блок должен “покрывать” Пользовательские истории US11. Блок, в качеств управляющего интерфейса, получает «Отчет о реализации требования», поступающий из блока “А2” — «Управление спецификациями требований», на основании которого рассчитывается уровень выполнения.

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

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

  1. Определение бизнес-процессов.

    Выполняется разработка функциональной архитектуры целевого продукта, в том числе, определяется важность и приоритетность автоматизируемых процессов — управление границами проекта. Этот блок должен “покрывать” Пользовательские истории US05, US06.

    В качестве управляющего интерфейса блок получает «Задания», поступающие из блока “А4” — «Управление заданиями» и инициирующие выполнение работ.

  2. Разработка спецификаций требований.

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

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

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

    Этот блок должен “покрывать” Пользовательские истории US10.

  4. Управление состоянием требований. Осуществляется мониторинг процесса продвижения проекта, в части реализации требований. Эта функция должна “покрывать” Пользовательские истории US11. В качестве управляющего интерфейса блок получает отчеты «Выполнение Заданий» поступающие из блока “А4” — «Управление заданиями», для определения текущего состояния и уровня реализации проекта.

Рис. 6.7 – Схема домена Управления спецификациями требований проекта

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

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

  1. Формирований заданий на основании спецификаций требования.

    Формируются задания на реализацию требования в том числе: на проектирование, разработку, тестирование, развертывание, пилотное внедрение. Этот блок должен “покрывать” Пользовательские истории US08.

  2. Формирование заданий на итерацию. Осуществляется управление выставлением заданий по плану итерации.

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

  3. Формирование заданий при наступлении риска. Осуществляется управление выставлением заданий по плану устранения последствий риска.
  4. Учет выполнения заданий. Формируется отчет о выполнении задания.

    Происходит изменение статуса объектов проекта по результатам выполнения заданий. Этот процесс должен “покрывать” Пользовательские истории US09.

Рис. 6.

8 – Схема домена Управления Заданиями проекта При моделировании этого домена, у нас появились процессы, которым мы не можем сопоставить ни одну из Пользовательских историй. Поэтому восполним пробел.

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

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

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

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

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

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

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

  1. Управление продуктом проекта.

    Фиксируется выпуск продукта. Формируются отчеты о выпуске

  2. Управление качеством. Производится анализ исправления замечаний предыдущей проверки. Определяется соответствие Выпуска требованиям. Оформляется отчет о контроле качества. Выявляются новые проблемы.
  3. Управление проблемами. Реагирование на отклонения в ходе выполнения процессов.

    Выполняется приоритезация ошибок, формируются запросы на изменение.

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

    Этот процесс должен “покрывать” Пользовательские истории US11.

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

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

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

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

Из диаграммы видно, что в результате система лишится потока данных — «задания исполнителям», обусловленных работами по нивелированию рисков.

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

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

. Список литературы1. Якобсон А., Буч Г., Рамбо Дж. – «Унифицированный процесс разработки ПО» (2004) 2. Дэвид А. Марк и Клемент МакГоуэн – «Методология структурного анализа и проектирования SADT» 3. Коберн — «Современные методы описания функциональных требований» (2002) 4. Леффингуэлл Дин, Уидрих Дон — «Принципы работы с требованиями к ПО» (2002) 5. Карл И. Вигерс – «Разработка требований к программному обеспечению» (2002) 6. Элизабет Халл, Кен Джексон, Джереми Дик — «Разработка и управление требованиями практическое руководство пользователей» (2005) 7. Скотт Амблер – «Гибкие технологии: экстремальное программирование и унифицированный процесс разработки» (2005) 8. Гринфилд Джек, Кейн Шорт — «Фабрики разработки программ» (2007) 9. Алистэр Коуберн — «Каждому проекту своя методология» 10. Вольфсон Борис- «Гибкие методологии разработки» 11. Лешек А. — «Анализ требований и проектирование систем» 12. Фримен Эрик, Фримен Элизабет — «Паттерны проектирования» (2011) 13. Эванс Эрик — «Предметно-ориентированное Проектирование» (2011)

14. ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»

Источник: https://habr.com/p/336950/

2.3. Границы системы

Границы и структура системы

Каждаяпроизводственная система должна иметьопределенные гра­ницы. Это предположениесоздает возможность в рамках иерархиисис­тем рассматривать какую-либоконкретную систему. Границы системынеобходимы и для того, чтобы определить,какие компоненты можно считатьнаходящимися под контролем лица,принимающего решение, а какие остаютсявне его внимания.

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

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

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

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

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

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

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

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

2.4. Уровень организованности перевозочной системы

Иерархическаяструктура целейпостроена на логической основе, сверхувнизимеетсемь уровней(рис. 2.6):народного хозяйства, меж­отраслевой,отраслевой, территориальный, перевозочныхкомплексов, звеньев икомпонентов.Цели последующего уровня обеспечиваютвы­полнение задач, стоящих передпредыдущим уровнем.

Седьмойуровеньнародноехозяйство преследуетоднуглобаль­нуюцель –планомерное и пропорциональное развитиеотраслей мате­риального производства.

Принятие в качестве «верхушки целей»одного из основных экономических законовразвития общества позволяетувя­затьразвитие всей транспортной отрасли спотребностями общества.

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

Шестойуровень –суперсистема:отрасль материального произ­водства– транспорт –призванобеспечитьэффективное действиеопределеннойотрасли материального производства.Эта цель достига­ется оптимизациеймежотраслевого функционирования.

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

Следуетучитывать, что минимальные затратытранспортной отрасли необ­ходиморассматривать с точки зрения созданияусловий для повышения эффективностиопределенной отрасли.

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

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

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

Перевозочный комплекссоздается для выполнения общественнойфункции – перемещение груза от местапроизводства до места потребле­ния.

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

Этотуровень решает тактические цели –выполнение определенных перевозок поконкретному маршруту или маршрутам смаксимальной эффективностью.Цельэтого уровня–максимальная эффективность перевозочногопроцесса.

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

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

Наиболее важные функцииком­плекса не иерархического характера– это подготовка груза, погрузка,пе­ремещение,разгрузка, хранение груза.

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

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

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

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

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

Не каждое повышение индивидуальной илокальной производительности трудаозначает повышение производительностиобщественного труда.

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

Источник: https://studfile.net/preview/3610839/page:3/

Границы. Границы системы или подсистемы представляют собой «правила, определяющие, кто и как участвует во взаимодействии» (Minuchin

Границы и структура системы

Границы системы или подсистемы представляют собой «правила, определяющие, кто и как участвует во взаимодействии» (Minuchin, 1974, р. 53).

Рассмотрим в качестве примера семью Уорнеров, обратившихся к психотерапевту в связи с тем, что их сын Томми отказывался играть во дворе.

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

  1. Папа может поддерживать дружеские отношения с мужчинами – коллегами по работе и время от времени посещать вместе с ними спортивные матчи. В любых других общественных мероприятиях должна принимать участие супруга. Папе разрешается поддерживать дружеские отношения с женщинами только в том случае, если они намного старше его.
  2. Мама занята неполный рабочий день и может поддерживать дружеские отношения с коллегами, но во внерабочее время ей позволительно встречаться с ними лишь в исключительных случаях. Любой такой случай заранее оговаривается.
  3. Дети, Томми (5 лет) и его младшая сестра Черил (3 года), обычно вместе играют на заднем дворике.
  4. Пригласить в дом другого ребенка имеет право лишь мать, но не дети. Томми может пойти поиграть к кому-нибудь из детей только по предварительной договоренности между матерями.
  5. Несмотря на то, что сестра мистера Уорнера с семьей проживают в соседнем квартале, они, как и другие родственники, видятся только в «плановом порядке», заранее договариваясь об этом по телефону или письменно.
  6. Знакомые Уорнеров знают, что хорошим тоном будет позвонить и заранее договориться о визите.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Члены таких семей мало контактируют друг с другом. Эти семьи представляют собой группу автономных индивидов. Их автономия сочетается с отсутствием взаимной поддержки. С. Минухин (Minuchin, 1974) называет такие семьи разобщенными(disengaged).

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

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

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

Не нашли то, что искали? Воспользуйтесь поиском:

Источник: https://studopedia.ru/11_101888_granitsi.html

Структура, границы и функции политической системы

Границы и структура системы

Итак, в политологию из естественных наук, биологии (Л. фон Берталанфи) и кибернетики (Н. Винер) вторгается системный, в основе своей 'внеисторичный' (синхронный) подход.

На возникновение структурно-функциональной модели политики повлияли труды социологов (Парсонс), антропологов (Радклифф-Браун, Малиновский) и экономистов (Леонтьев), многие из идей и концептов которых были адаптированы к модели политической системы, Наиболее же серьезные разработки в области теории политической системы связаны, как уже отмечалось выше, с 'системной' моделью Д. Истона, 'функциональной' моделью Г. Алмонда и 'кибернетической' моделью К. Дойча.

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

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

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

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

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

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

Политическая система включает организацию политической власти,

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

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

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

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

Функции политической системы:

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

2. Консолидация общественно-политического строя, обеспечение существования общества как единого целого (интегративная функция).

3. Регулятивная функция – связана с потребностями упорядочения и регламентации политического поведения и политических отношений в государственно-организованном обществе.

4. Мобилизационная функция, обеспечивает максимальное использование ресурсов общества.

5. Дистрибутивная функция, направлена на распределение ресурсов и ценностей.

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

Концепция политической культуры. Политическое сознание.

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

Термин ” политическая культура ” впервые был использован в западной литературе в 1956 году американским политологом Г. Алмондом.

В совместной с С. Вербой работе “Культура гражданина” он так определяет сущность политической культуры: “Политическая культура нации есть особое распределение образцов ориентации в отношении политических объектов среди представителей данной нации”.

А по мнению политолога М. Башира, политическая культура – это” тип верований, превалирующий среди членов общества, а также образцы, по которым эти верования формируются, будучи функционально взаимосвязанными в интегральные системы “.

Характерныечерты политической культуры:

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

2. Является продуктом естественно-исторического развития общества, результатом коллективного политического творчества.

3. Имеет тотальный характер, политические отношения “пронизаны, насыщены, пропитаны” политической культурой.

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

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

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

Структура политической культуры:

1. Культура политического сознания, которая включает в себя:

o политические представления и убеждения;

o политические ценности, традиции, обычаи, нормы;

o политические установки.

2. Культура политического поведения:

o культура политического участия;

o культура политической деятельности.

3. Культура функционирования политических институтов это:

o культура электорального процесса;

o культура принятия и реализации политических решений;

o культура восприятия и урегулирования социально-политических

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

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

Политическое сознание включает в себя идеологию и правовое сознание.

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

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

Основой правового сознания являются правовые знания.

Источник: https://studopedia.net/5_71541_struktura-granitsi-i-funktsii-politicheskoy-sistemi.html

Book for ucheba
Добавить комментарий