Шаг 1. Идентифицируйте конечные продукты проекта, то есть то, что должно быть сделано для того, чтобы добиться успеха проекта.
Шаг 2. Определите основные результаты проекта, которые являются промежуточными результатами.
Шаг 3. Декомпозируйте основные результаты до уровня детализации, подходящего для управления и интегрированного контроля проекта.
Шаг 4. Рассматривайте и совершенствуйте СРР до тех пор, пока заинтересованные в проекте лица не согласятся с тем, что планирование проекта может быть успешно закончено, а контроль за исполнением проекта обеспечит создание желаемых конечных результатов.
Алгоритм разработки СРР по методу снизу вверх
Шаг 1. Идентифицируйте все конечные результаты (или пакеты работ), относящиеся к проекту.
Шаг 2. Логически свяжите конечные результаты или пакеты работ в группы.
Шаг 3. Агрегируйте результаты данного уровня в совокупные конечные результаты следующего более высокого уровня.
Шаг 4. После того как данная группа связанных задач была агрегирована в родительский элемент, проанализируйте подмножество элементов снова, чтобы гарантировать, что вся рассматриваемая работа была охвачена на 100 %.
Программирование «Сверху вниз». Тестирование. Отладка. АиАЯ. 1 курс, 17 лекция
Шаг 5. Повторяйте агрегирование до тех пор, пока все подэлементы не будут сведены к одному родительскому элементу первого уровня, представляющему проект целиком.
Шаг 6. Рассматривайте и совершенствуйте СРР до тех пор, пока заинтересованные в проекте лица не согласятся с тем, что планирование проекта может быть успешно закончено, а контроль за исполнением проекта обеспечит создание желаемых конечных результатов.
ПОДГОТОВКА ПРОЕКТНОЙ ДОКУМЕНТАЦИИ (ЛОКАЛЬНЫХ НОРМАТИВНЫХ АКТОВ)
При реализации внутренних HR-проектов такой документ, как Описание содержания проекта должен включать проекты документов (иначе говоря, проектную документацию), разработанные командой проекта в соответствии с выбранными направлениями совершенствования той или иной области управления персоналом.
Необходимо исходить из утверждения о том, что предприятие – это формальная социально-экономическая система, деятельность которой регламентирована рядом организационно-правовой и распорядительной документации. Поэтому любые изменения организационных процессов, в том числе процессов управления персоналом должны сопровождаться корректировкой действующих или разработкой новых регламентирующих документов.
Существует следующий состав документации, используемой в управлении персоналом:
1. Организационно-правовая и организационно-кадровая документация: учредительный договор, устав организации; структура и штатная численность персонала; правила внутреннего трудового распорядка; штатное расписание; положения о подразделениях; трудовые договоры; должностные инструкции; инструкции по охране труда и др.
2. Организационно-распорядительная документация: приказы; распоряжения; постановления; решения; положения; акты; протоколы и др.
3. Информационно-справочная документация: письма; факсы; телефонограммы; докладные и объяснительные записки; справки и т. д.
Python 3 #15: делаем «Сапер», проектирование программ «сверху-вниз»
4. Плановаядокументация: плановые задания по кадровым вопросам; заявки на молодых специалистов; наряды; расчеты по численности, оплате труда и т. п.
5. Отчетно-статистическая документация – по численности; балансу рабочего времени; учету труда; зарплате; производительности труда; высвобождению работников и т. п.
6. Документация по личному составу: анкеты; заявления; автобиографии; рекомендации; личные карточки; удостоверения; трудовые книжки; копии документов об образовании; аттестационные листы; личные дела.
7. Документация по социальному обеспечению – по пенсиям; пособиям; льготам; социальному страхованию и т. д.
Таким образом, в зависимости от потребностей проекта команда может разрабатывать проекты положений, приказов, договоров, протоколов, инструкций, актов, анкет, памяток и т. п.
Разработка проектной документации должна осуществляться в соответствии с требованиями законодательства в сфере работы с кадровыми документами – Трудовым кодексом РФ, Гражданским кодексом РФ, соответствующими Федеральными законами, требованиями соответствующих государственных стандартов (например, ГОСТ Р 6.30–2003).
В процессе подготовки документу присваивается статус проекта с указанием этого в правом верхнем углу документа. На этапе приемки результатов проекта после прохождения процедур согласования и возможной доработки документ утверждается руководителем организации или другим лицом, наделенным определенными полномочиями. После утверждения документ утрачивает статус проекта и становится обязательным для исполнения.
Контрольные вопросы
2. Как соотносятся между собой продукты и результаты проекта?
4. Что такое проектная документация? Каковы ее формы для различных видов проектов?
5. В чем состоит суть структуризации (декомпозиции) проекта?
6. Какие типы иерархических структур проекта могут быть применены для структурирования и описания содержания проекта?
7. Назовите основные требования к разработке структуры разбиения работ по проекту?
8. В чем состоит сущность построения структуры разбиения работ по методам сверху вниз и снизу вверх?
10. Какие виды документации могут быть разработаны при выполнении HR-проектов?
ЛЕКЦИЯ 5. ПЛАН УПРАВЛЕНИЯ ПРОЕКТОМ
1. Понятие и виды планов проекта.
2. План по вехам.
3. Сетевые графики.
4. Диаграмма Ганта.
5. Матрица распределения ответственности.
Основная цель планирования состоит в построении модели реализации проекта. Она необходима для координации деятельности участников проекта, с ее помощью определяется порядок, в котором должны выполняться работы. Планирование начинается с наиболее общего представления целей, движется к более детальному описанию того, когда, как и какие работы должны быть выполнены для достижения поставленных целей.
В общем виде план управления проектом состоит из трех уровней:
1. Первый уровень – концептуальный план проекта.
2. Второй уровень – стратегический план реализации проекта.
3. Третий уровень – тактические (детальные) планы реализации проекта.
ПОНЯТИЕ И ВИДЫ ПЛАНОВ ПРОЕКТА
План управления проектом – это сводный документ, который интегрирует все базовые и вспомогательные планы, разработанные в рамках разных процессов планирования проекта.
К базовым планам проекта относятся:
— базовый план по стоимости или бюджет;
— базовый план по содержанию.
К вспомогательным планам относятся:
— план управления расписанием;
— план управления стоимостью;
— план управления качеством;
— план усовершенствования процессов;
— план управления человеческими ресурсами;
— план управления коммуникациями;
— план управления рисками;
— план управления закупками.
Состав и степень детализации планов зависят от требований заказчика и потребностей исполняющей организации в управлении и контроле проекта. Для небольших проектов может быть разработан один детальный план вместо всех перечисленных. Для инвестиционного проекта, на финансирование которого планируется привлечь деньги инвесторов или кредит банка, как правило, разрабатывается технико-экономическое обоснование и / или бизнес-план.
План управления проектом утверждается представителем заказчика и уполномоченным лицом от исполняющей организации после того, как согласованы и определены все ключевые вопросы относительно того, как будет исполняться проект, проводиться его мониторинг, контроль и закрытие.
После утверждения план управления проектом может изменяться, если в этом будет потребность, появившаяся на последующих фазах проекта.
Основные процедуры процесса планирования можно представить в виде последовательности шагов, которые отвечают на простые и понятные вопросы.
Последовательность основных процедур планирования
и их методическое обеспечение
| Шаг | Вопросы | Что нужно сделать | Обеспечение |
| 1 | Зачем? | Разработка концепции и планирование целей проекта | Описание целей проекта по требованиям SMART |
| 2 | Что? | Декомпозиция целей проекта | Структура разбиения работ (СРР) |
| 3 | Кто? | Формирование команды проекта и определение ответственных за отдельные работы по проекту | Структурная схема организации (ССО) проекта. Матрица ответственности |
| 4 | Как? | Разработка стратегии реализации проекта | План по вехам |
| 5 | Подробно как? | Разработка тактики проекта | Сетевые графики |
| 6 | Идеально когда? | Разработка идеального календарного графика работ | Диаграмма Ганта |
В зависимости от содержания и масштаба проекта структура плана управления проектом может варьироваться. Задача данной лекции состоит в раскрытии сущности планов управления расписанием (план по вехам, сетевые графики, диаграмма Ганта) и человеческими ресурсами (матрица ответственности) в проекте. Этому будут посвящены следующие разделы лекции 5.
ПЛАН ПО ВЕХАМ
После построения структуры разбиения работ проекта появляется возможность проставить и согласовать с заказчиком основные этапы проекта (вехи). Именно по этим этапам заказчик будет контролировать ход исполнения проекта.
Веха – событие или дата в ходе осуществления проекта. Веха используется для отображения состояния завершенности тех или иных работ. В контексте проекта менеджеры используют вехи для того, чтобы обозначить важные промежуточные результаты, которые должны быть достигнуты в процессе реализации проекта.
План по вехам – графическое или табличное представление взаимосвязанных ключевых вех проекта с указанием сроков их наступления и ответственных за выполнение этих сроков.
Важным отличием вех от работ является то, что они не имеют длительности. Вехи – это своего рода контрольные точки, которые оцениваются по шкале «выполнено – не выполнено». Эти контрольные точки соответствуют промежуточным целям, требуемым для достижения общей цели. При обзоре выполнения работ вехи позволяют руководству быстро понять, на какой стадии находится проект, и оценить, достигнуты ли основные состояния, необходимые для успешного завершения работ.
Рис. 5.1. План по вехам
Практические рекомендации по построению плана по вехам состоят в следующем:
1. Составляется с конца, начиная с события успешного завершения проекта (достижения цели, получения результата).
2. Для каждого события указывается время его наступления, ответственное лицо.
3. В качестве событий целесообразно использовать моменты начала и/или завершения работ, представленных в структурной декомпозиции работ. Учитывая ограниченный объем плана по вехам, целесообразно ограничиваться верхними уровнями декомпозиции.
4. Сроки достижения вех должны быть согласованы со всеми участниками. После этого каждая из вех становится контрольной точкой и должна быть включена в план контроля и отчетности проекта.
План по вехам становится основой для дальнейшей разработки расписания любого уровня детализации, вплоть до рабочих заданий исполнителям. Задача планировщика – заполнить промежутки между основными вехами конкретными пакетами работ.
СЕТЕВЫЕ ГРАФИКИ
Важнейшим инструментом планирования проекта являются сетевые модели. Главная задача сетевого планирования заключается в том, чтобы сократить до минимума продолжительность проекта. Наиболее известными методами, используемыми для решения этой задачи, являются методы критического пути.
Сетевой график представляет собой граф, отображающий все необходимые для достижения цели проекта операции в технологической взаимосвязи. Основными элементами сетевого графика являются работа, событие, путь.
Работа – это трудовой процесс, требующий затрат времени и ресурсов. В сетевой модели работа изображается в виде сплошной стрелки, над которой стоит цифра, показывающая ее продолжительность (обычно в днях). Работа идентифицируется номерами начального и конечного события (например, работа 1–2, 3–4).
Событие – это результат выполнения одной или нескольких работ, позволяющий начинать следующую работу. Как правило, в сетевых моделях событие изображается в виде кружка.
Путь – это непрерывная последовательность работ от исходного до завершающего события сетевой модели. Суммарная продолжительность работ, лежащих на пути, определяет длину пути.
Максимальный по продолжительности полный путь в сети называется критическим; работы, лежащие на этом пути, также называются критическими. Критический путь определяет общую продолжительность проекта.
Рис. 5.2. Пример сетевого графика
Представленная модель имеет пять путей:
— путь 1, проходящий через события 0–1–3–5, имеет продолжительность 17 дней.
— путь 2, проходящий через события 0–1–2–3–5, имеет продолжительность 23 дня.
— путь 3, проходящий через события 0–1–2–4–5, имеет продолжительность 18 дней.
— путь 4, проходящий через события 0–2–4–5, имеет продолжительность 19 дней.
— путь 5, проходящий через события 0–2–3–5, имеет продолжительность 24 дня.
Путь 5 по своей продолжительности превосходит все остальные, следовательно, именно этот путь и является критическим. Работы, лежащие на критическом пути, являются узкими местами, поэтому руководитель проекта должен сосредоточить свое внимание именно на этих работах, так как от них зависит выполнение всех работ в установленный срок.
Метод критического пути позволяет рассчитать возможные календарные графики выполнения комплекса работ на основе описанной логической структуры сети и оценок продолжительности выполнения каждой работы, определить критический путь проекта.
Основное достоинство метода критического пути состоит в возможности изменения сроков выполнения работ, не лежащих на критическом пути, связанной с наличием временного резерва. Временной резерв – это разность между самым ранним возможным сроком завершения работы и самым поздним допустимым временем ее выполнения. Другими словами, для работ, лежащих вне критического пути, можно определить даты их раннего и позднего начала, а также даты раннего и позднего окончания. Работы, лежащие на критическом пути, имеют временной резерв, равный нулю, что означает, что их ранние и поздние сроки выполнения совпадают.
Управленческий смысл резерва времени заключается в том, что при необходимости урегулировать технологические, ресурсные или финансовые ограничения проекта он позволяет руководителю задержать работу на этот срок без влияния на срок завершения проекта в целом.
При построении сетевого графика необходимо соблюдать следующие правила:
1. Плавило последовательности изображения работ: сетевые модели следует строить от начала к окончанию, то есть слева направо.
2. Правило пересечения стрелок. При построении сетевого графика следует избегать пересечения стрелок: чем меньше пересечений, тем нагляднее график.
3. Правило обозначения работ: между обозначениями двух смежных событий может проходить только одна стрелка.
4. Правило запрещения замкнутых контуров (циклов, петель). Недопустимо, чтобы один и тот же путь возвращался в то же событие, из которого он вышел.
5. Правило запрещения тупиков. В сетевом графике не должно быть тупиков, то есть событий, из которых не выходит ни одна работа, за исключением завершающего события.
6. Правило запрещения хвостовых событий. В сетевом графике не должно быть хвостовых событий, то есть событий, в которые не входит ни одна работа, за исключением начального события.
ДИАГРАММА ГАНТА
Основным результатом процесса планирования времени, необходимого на выполнение всех работ по проекту, является разработка расписания проекта.
Базовое расписание представляет собой особую версию расписания проекта, сформированную командой проекта на основе анализа и оптимизации сетевой модели проекта с учетом основных требований заказчика, а также всех ограничений и допущений. В базовом расписании проекта должны быть разрешены все ресурсные конфликты, определены даты старта и финиша проекта.
Общепринятыми формами представления расписания проекта являются ленточные диаграммы Ганта, названные в честь американского инженера, сподвижника Фредерика У. Тейлора, Генри Л. Ганта.
Рис. 5.3. Пример диаграммы Ганта для проекта совершенствования
системы целевой подготовки специалистов
Предназначенная первоначально для применения в управлении производством диаграмма Ганта начала активно использоваться в управлении проектами в 1930-х годах. Первое известное применение графика Ганта на крупном проекте относится к строительству плотины Гувера (Hoover Dam, США) в 1931-1936 гг.
Новый всплеск популярности диаграммы Ганта наблюдается после 1990 годов и связан с разработкой компанией Microsoft операционной системы Windows, открывшей большие возможности по визуализации планов управления проектами.
Современные модификации расписаний проектов, которые разрабатываются на основе диаграммы Ганта, включают три основные разновидности:
1) общее расписание проекта (Базовая диаграмма Ганта);
2) расписание контрольных точек проекта (Диаграмма контрольных точек);
3) расписание проекта с логическими связями (Сетевая модель расписания, привязанная к шкале времени).
Дата: 2018-12-21, просмотров: 551.
Источник: findout.su
Программирование 2 курс / Программирование(4172,4173) / Лекции / Лекция 10. Разработка программ сверху вниз.Примеры зачетных задач
Любая сложная система состоит из более мелких частей, таким же образом можно представить любой алгоритм или программу. На первом этапе проектируемый алгоритм представляется в виде одного блока. Затем определяется структура этого блока, исходный алгоритм разбивается на части и т.д. На рис.10.1 представлены нисходящая (сверху вниз) и восходящая (снизу вверх) технологии алгоритмизации.
Рис. 10.1. Нисходящая и восходящая технологии алгоритмизации
Часто отдельные части сложной программы оформляют в виде отдельных подпрограмм. При разработке программы по принципу «сверху вниз» вначале проектируется алгоритм главной программы (функции main), на втором этапе – блоков или подпрограмм, вызываемых из главной программы, затем – блоков или подпрограмм следующего уровня и т.д.
Задача. Сортировка числовой последовательности.
Дано целое n и вещественные x1, x2, . xn. Составить программу печати заданных вещественных чисел в порядке возрастания (не убывания).
Тест. Вход: Введите количество чисел 5
Введите числа 12.5 6 14 -3 10
Выход: Упорядоченные числа: -3.0 6.0 10.0 12.5 14.0
Разработаем алгоритм программы нисходящим методом.
Для хранения данных нужен массив. Исходные данные вводятся в массив, там сортируются по возрастанию, а затем выводятся. Оформим в виде отдельных подпрограмм ввод данных и сортировку массива.
Функциональную структуру программы можно представить в виде дерева на рис. 10.2.
Рис. 10.2. Функциональная структура программы
1 этап. Разработка алгоритма функции main().
Алгоритм (на псевдокоде):
1. n = Vvod(x); // Ввод n и массива x
2. Sort (x,n); // Сортировка массива x по возрастанию;
3. Вывод сортированного по возрастанию массива x;
2 этап. Детализируем шаги алгоритма. Это можно делать в любом порядке. Начнем, например, с вывода упорядоченного массива x.
// 3. Вывод массива x
Вывод заголовка «Упорядоченные числа:»;
Теперь рассмотрим алгоритм функции ввода данных.
int Vvod (float x[])
Осталось рассмотреть функцию сортировки массива x. Существует много различных методов сортировки массивов. Рассмотрим метод последовательного нахождения максимума.
Вначале наибольший элемент ищется среди всех n элементов, после чего происходит перестановка его с последним элементом. Далее максимальный элемент ищется уже среди n-1 элементов и меняется местами с предпоследним элементом. Затем эта процедура повторяется для n-2 элементов и т.д. Последний раз наибольший элемент находится из первых двух элементов и переставляется местами со вторым элементом.
2.5 6 14 -3 10 // рассматривается n элементов
2.5 6 10 -3 // рассматривается n-1 элементов
2.5 6 -3 // рассматривается n-2 элементов
2.5 — 6 // рассматривается n-3 элементов
Алгоритм функции сортировки массива x по возрастанию:
void Sort (float x[], int n)
его индекса imax.
3 этап. Рассмотрим определение максимума среди элементов x[0], . , x[k] и его индекса imax.
if (x[i] > x[imax]) imax = i;
#define NMAX 100 /* Макс-е количество входных чисел */
/* Функция ввода данных * /
int Vvod (float x[])
int n; /* Количество чисел */
int i; /* Индекс текущего числа */
printf («nВведите количество чиселn»);
printf («Введите числаn»);
/* Функция сортировки x массива по возрастанию */
void Sort (float x[], int n)
int k; /* Максимальный индекс просмотра*/
float r; /* Для обмена */
int imax; /* Индекс максимального элемента */
int i; /* Индекс текущего числа */
if (x[i] > x[imax]) imax = i;
/* Обмен x[imax] и x[k] */
/* Главная функция */
int n; /* Количество чисел */
int i; /* Индекс текущего числа */
/* 1. Ввод массива x */
/* 2. Сортировка массива x по возрастанию */
/* 3. Вывод массива x */
Примеры зачетных задач
Рассмотрим примеры задач, предлагаемых на зачете по программированию студентам заочной и очно-заочной форм обучения. Билет включает две задачи разных типов. В 1-й задаче дана готовая программа с подпрограммой, нужно составить к программе схему алгоритма и определить результат работы программы при заданных исходных данных. Ко второй задаче необходимо составить схему алгоритма, программу на языке С и трассировочную таблицу выполнения программы для одного или двух тестов (тесты подобрать самим).
1. Составить схему к программе:
int f3 (char s[81])
printf («%d %dn»,f3(s1),f3(s2));
Что выведет программа, если ввести следующие строки:
Зима весна лето.
2. Дана числовая последовательность в виде n, x1 , x2 , . xn .
Проверить, упорядочены ли числа x1 , x2 , . xn по убыванию.
Решение задачи 1:
Источник: studfile.net
Программирование сверху-вниз
Программирование сверху –вниз –это некоторая многоуровневая дисциплина написания программ. На верхнем уровне, исходный алгоритм представляется в виде иерархической системы, элементы которой описываются на естественном для данной проблемы языке.
Каждое такое описание, рассматривается, как последовательность комментариев, заготовок или команд некоторой гипотетической проблемно –ориентированной машины. Каждая команда такой машины моделируется или расписывается командами другой гипотетической машины, более низкого уровня, до команд реальной машины или операторов языка программирования.
На рис.18 представлена унифицированная форма организации ПС проектирования ТП. Уровни детализации можно развивать и далее. Проектирование ПС ведется так, что описание системы на верхнем уровне, не зависит от описания блоков на низком уровне. Вся система проектируется и отлаживается по уровням – сверху–вниз. Каждый верхний уровень отлаживается на тестах, полученных и проверенных на предыдущем верхнем уровне. В целом, технология программирования сверху –вниз, позволяет:
1) Начать программирование почти одновременно и параллельно с разработкой алгоритмов;
2) Формально, в виде программы некоторой гипотетической машины, фиксировать каждый этап разработки соответствующего алгоритма;
3) Легко модифицировать программу по уровням, путем замены одной гипотетической машины на другую;
              |
 |
4) Упрощать отладку программ путем рассредоточения ее по уровням и проведения независимо от нижерасположенных уровней детализации.
Программирование сверху–вниз, часто называют нисходящим проектированием или систематическим программированием, или иерархическим проектированием программы, или взрывным проектированием. Все эти вариации программирования сверху –вниз, имеют один и тот же принцип проектирования программ. Но хотя этот принцип весьма прост, необходимо иметь в виду многие особенности его приложения.
Во-первых, при программировании возникают затруднения, связанные с организацией начала обработки групп записей и формированием заголовков и окончаний в соответствии, с переходом обработки от одной группы записей, к другой, а так же при проверке правильности вводимых и определяемых внутри программ данных. Поэтому, в любых системах программирования должны предусматриваться возможности для управления программой при переходе обработки от одной группы записей, к другой, для проверки правильности данных, а так же для одновременной обработки данных, поступающих в разное время. Кроме того, каждая система программирования должна объединять средства управления физической организацией некоторых данных (например, распределением информации по страницам) с логической организацией обработки.
Во-вторых, при пошаговом уточнении программы на каждом следующем этапе детализации, определяются программы очередного, более низкого уровня (для этого используется процедурные системы программирования). Первоначально, задается заголовок программы, соответствующий ее главной функции, например:
procedure обработка пакетов
Затем определяются основные шаги обработки пакетов информации:
procedure обработка пакетов;
сортировать записи по управляющим полям;
отделить правильные записи от неправильных и обрабатывать.
endprocedure
С помощью расширения шагов процедуры, выполняется дальнейшее уточнение программы. Причем, если какая-то операция реализуется стандартной программой (уже имеющейся), то она не разбивается на шаги. Например, в нашем случае это операция сортировки. Если же такой стандартной программы нет, то операция уточняется дальше, с целью написания стандартной программы. В процессе уточнения, может появиться необходимость в использовании управляющих структур. Например:
procedure обработка пакетов;
сортировать записи по управляющим полям;
взять первую запись
while не конец (входной файл) do
взять правильную управляющую группу
обработать группу записей
обработать неправильную управляющую группу
endprocedure
В третьих, следует помнить, что на все расширения можно откладывать на более поздний срок. Допустим, что отсортированная информация помещается в файл с последовательным доступом. Если метод доступа к данным на этой стадии проектирования не известен, можно использовать какое-либо нейтральное выражение, такое, как “ while еще есть данные do ”.
На следующем шаге уточнения, можно приостановить определение каких-либо других предложений, выделяя их в вызываемые функции и процедуры, в том случае, если они функционально независимы от основной процедуры обработки или если необходимо отложить их детализацию:
procedure обработка пакетов;
сортировать записи по управляющим полям;
взять первую запись
while не конец (входной файл) do
взять управляющую группу
until найдена правильная группа или конец
файла (входной файл)
обработать заголовок группы;
обработать записи группы;
обработать окончание группы;
обработать неправильную управляющую группу
endprocedure
В-четвертых, при проектировании программы на конкретном уровне детализации не надо увлекаться обсуждением несущественных для этого уровня деталей задачи.
В-пятых, следует на каждом уровне детализации записать в явном виде реализацию некоторого модуля, для которого определены входы, функции и выходы.
В-шестых, проектированную структуру данных следует уделять не меньше внимания, чем проектированию процессов и алгоритмов. Во многих случаях в состав этих данных входят требования к межмодульным интерфейсам, и проектирование этих модулей не продвинется существенно до тех пор, пока не будет тщательно описаны соответствующие интерфейсы.
Воспользуйтесь поиском по сайту:
studopedia.org — Студопедия.Орг — 2014-2023 год. Студопедия не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования (0.007 с) .
Источник: studopedia.org