Целью определенного проекта могут быть изменения в операционной деятельности —особенно в случае наличия существенных изменений в операционной деятельности в результате создания нового продукта или услуги. Постоянная операционная деятельность находится за рамками содержания проекта, однако существуют точки пересечения двух областей.
Проекты могут пересекаться с операционной деятельностью в различных точках в течение жизненного цикла продукта, например:
- в каждой завершающей фазе;
- при разработке нового продукта, модернизации продукта или увеличении выпуска продукции;
- при улучшении операционной деятельности или процесса разработки продукта;
- до завершения жизненного цикла продукта.
В каждой точке поставляемые результаты и знания передаются между проектами и операционной деятельностью для дальнейшего применения. Это осуществляется через выделение ресурсов проекта для операционной деятельности в конце проекта или через выделение операционных ресурсов под проект в его начале.
Операционная деятельность — это постоянный вид деятельности, который производит повторяющиеся результаты, при этом ресурсы выделяются для выполнения практически аналогичного ряда задач в соответствии со стандартами, внедренными в жизненный цикл продукта. В отличие от операционной деятельности, которая носит постоянный характер, проекты представляют собой временные предприятия.
Содержание
Управление операционной деятельностью
Управление операционной деятельностью — это предметная область, которая находится за рамками содержания формального управления проектом, как описано в данном стандарте.
Управление операционной деятельностью — это область управления, которая связана с постоянным производством продуктов и/или услуг. Сюда относится обеспечение эффективности операционной деятельности за счет использования необходимых оптимальных ресурсов и удовлетворения потребностей заказчиков. Это связано с управлением процессами,
которые превращают входы (например, материалы, компоненты, энергию и труд) в выходы (например, продукты, товары и/или услуги).
Операционные заинтересованные стороны в управлении проектами
Несмотря на то что управление операционной деятельностью отличается от управления проектами потребности заинтересованных сторон, осуществляющих операционную деятельность, являются важными аспектами проектов, которые повлияют на их будущие работы и усилия. Руководители проектов, которые учитывают и надлежащим образом включают операционные заинтересованные стороны во все фазы проектов, приобретают видение и избегают ненужных проблем, которые часто возникают, если их вклад недооценивается.
Необходимо привлекать операционные заинтересованные стороны и учитывать их потребности как часть реестра заинтересованных сторон, а на влияние, оказываемое ими (положительное или отрицательное), следует реагировать в рамках плана управления рисками.
Следующий список представляет собой пример операционных заинтересованных сторон (в зависимости от вида деятельности):
- операторы промышленных предприятий,
- руководители производственных линий,
- персонал службы технического сопровождения,
- аналитики по поддержке производственных систем,
- представитель отдела обслуживания клиентов,
- сотрудники отдела продаж,
- обслуживающий персонал,
- сотрудники отдела телемаркетинга,
- сотрудники call-центра,
- сотрудники отдела розничных продаж,
- руководители структурных подразделений,
- сотрудники отдела подготовки кадров.
Процесс (задача) – абстракция, описывающая выполняющуюся в рамках ОС программу. Для ОС процесс – единица работы, которая потребляет системные ресурсы.
Задачи, решаемые подсистемой управления процессами:
- Планирование процессов — распределение процессорного времени: что, сколько, и когда выполняется;
- Создание и уничтожение процессов — ОС обеспечивает старты, выделяет ресурсы, обеспечивает уничтожение, освобождение ресурсов и т.д.
- Обеспечение процессов системными ресурсами (памятью, различными устройствами)
- Поддержка взаимодействия между процессами (обеспечение межпроцессорного взаимодействия)
С понятием управления процессами в ОС связаны следующие технологии:
- Состояния процесса в ОС
- Алгоритмы планирования процессов в ОС
- Синхронизация процессов в ОС
Состояния процесса в ОС
Состояние процесса в ходе жизненного цикла в ОС
Эти состояния:
- ВЫПОЛНЕНИЕ: активное состояние процесса, во время которого процесс обладает всеми необходимыми ресурсами и непосредственно выполняется процессором.
- ГОТОВНОСТЬ: также пассивное состояние процесса, но в этом случае процесс заблокирован в связи с внешними по отношению к нему обстоятельствами: процесс имеет все требуемые для него ресурсы, он готов выполняться, однако процессор занят выполнением другого процесса.
- ОЖИДАНИЕ: пассивное состояние процесса, процесс заблокирован, он не может выполняться по своим внутренним причинам, он ждет осуществления некоторого события, например, завершения операции ввода-вывода, получения сообщения от другого процесса, освобождения какого-либо необходимого ему ресурса.
В ходе жизненного цикла каждый процесс переходит из одного состояния в другое в соответствии с алгоритмом планирования процессов, реализуемым в данной операционной системе.
В состоянии ВЫПОЛНЕНИЕ в однопроцессорной системе может находиться только один процесс, а в каждом из состояний ОЖИДАНИЕ и ГОТОВНОСТЬ — несколько процессов, эти процессы образуют очереди соответственно ожидающих и готовых процессов. Жизненный цикл процесса начинается с состояния ГОТОВНОСТЬ, когда процесс готов к выполнению и ждет своей очереди. При активизации процесс переходит в состояние ВЫПОЛНЕНИЕ и находится в нем до тех пор, пока либо он сам освободит процессор, перейдя в состояние ОЖИДАНИЯ какого-нибудь события, либо будет насильно «вытеснен» из процессора, например, вследствие исчерпания отведенного данному процессу кванта процессорного времени. В последнем случае процесс возвращается в состояние ГОТОВНОСТЬ. В это же состояние процесс переходит из состояния ОЖИДАНИЕ, после того, как ожидаемое событие произойдет.
Информация о процессе:
- Режим работы процессора.
- Информация об открытых файлах.
- Регистры.
- Состояние внешних устройств.
- Операции ввода – вывода.
Информационные структуры описывающие процессы
Существует две информационные структуры по-разному описывающие процессы — контекст процесса и дескриптор процесса.
Контекст процесса
Контекст процесса содержит информацию о внутреннем состоянии процесса, а также отражает состояние аппаратуры в момент прерывания процесса и включает параметры операционной среды. Содержит часть информации необходимой для возобновления выполнения процесса с прерванного места.
В состав контекста процесса входит:
- содержимое регистров процессора (включает счётчик команд, т.е. на каком этапе находится процесс);
- размещение кодового сегмента;
- информацию об открытых данным процессом файлах;
- информацию о работах с внешними устройствами (+ коды ошибок выполненных процессором, системных вызовов, незавершенных операциях ввода-вывода).
Дескриптор процесса
Дескриптор процесса – это информационная структура, которая описывает внешнюю структуру (информацию) процессе (нужна планировщику для выполнения процесса, а так же нужна ядру в течение всего жизненного цикла процесса)
В состав дескриптора входят:
- Идентификатор процесса;
- Состояние процесса.
- Информация о привилегированности процесса.
- Информация о расположении кодового сегмента.
Дескрипторы присутствуют в качестве элементов списка. Для того, чтобы ОС выбирала процессы надо иметь идентификаторы процессов и т.д., т.е. дескрипторы. Дескрипторы отдельных процессов объединены в список, образующих таблицу процессов. Память для таблицы процессов отводиться динамически в области ядра. На основании соседних в таблице процессов ОС осуществляет планирование и синхронизацию процессов. Потоки образуют очереди готовых и ожидающих потоков путём объединения в списки дескрипторов отдельных потоков. Такая организация очередей позволяет легко их переупорядочить, включать и исключать процессы, переводить процессы из одного состояния в другое.
Алгоритмы планирования процессов в ОС
Задача планирования процессов состоит из трех действий:
- Определение момента времени для смены, выполняемого в данный момент, процесса.
- Выбор того процесса из очереди готовности, которому будет передано управление.
- Переключение контекста (переключение между процессами).
Первые два действия выполняются на программном уровне (специально написанный код) и относятся к планированию, третье – на аппаратном уровне и относится к диспетчеризации.
Создание процесса
Создание процесса:
- ОС создает контекст и дескриптор процесса.
- Загрузка кодового сегмента в оперативную память.
- Дескриптор помещается в очередь процессов, находящихся в готовности.
С этого момента можно считать, что процесс стартовал.
Разберём подробно вопрос создания процесса. Когда запускается приложение, Операционная Система создаёт две информационные структуры: контекст и дескриптор (идентификатор и т.д.). Кодовый элемент грузится в оперативную память (информацию о нём заносится в контекст). Затем дескриптор процесса включается в очередь процессов; далее планировщик решает, что процесс должен быть выполнен, а дескриптор процесса находится в очереди готовых процессов. Прежде прервать выполнение процесса, ОС вначале сохраняет его контекст, чтобы в последствие использовать эту инструкцию для последовательного возобновления. Затем контекст обновляется (переключение контекста) и активный контекст получает информацию о новом процессе. Далее процессу выделяются ресурсы, процессорное время и т.д. При удалении процесса: уничтожается дескриптор и удаляется контекст. Новый процесс может получить дескриптор с тем же номером.
Алгоритмы планирования процессов
В зависимости от того, какие критерии накладываются, алгоритмы планирования могут основываться на:
- Квантовании времени.
- Приоритетах.
Алгоритмы, основанные на квантовании времени
Алгоритмы, основанные на квантовании времени – любому процессу на выполнение отводится определенный квант времени (несколько милисекунд). Переключение активного процесса происходит если:
- Истек срок времени, выделенного на выполнение процесса.
- Процесс завершился.
- Процесс перешел в состояние ожидания.
По истечении выделенного времени планировщик ставит другой процесс. Если до истечения времени процесс находится в режиме ожидания, запускается другой процесс. Кванты времени выделенные процессами, могут быть для разных процессов одинаковыми или различными. Кванты, выделяемые одному процессу могут быть фиксированной величины, а могут и изменяться в разные периоды жизни процесса. Некоторые из процессов используют полученные кванты времени не полностью из-за необходимости выполнить операции ввода-вывода. Тогда возникает ситуация, когда процессы с интенсивными обращениями к вводу-выводу используют только небольшую часть выделенного им процессорного времени. В качестве компенсации за не полностью использованные кванты, процессы получают привилегии при последующем обслуживании (создают две очереди готовых процессов, прежде всего просматривается вторая очередь; если она пуста, квант выделяется процессу из первой очереди)
Выбор новых процессов может быть построен по принципам:
- FIFO (очередь).
- LIFO (стек).
Алгоритмы, основанные на приоритетах
Приоритет – число, характеризующее степень привилегированности процесса (обычно выражается числом). В каждой ОС это число трактуется по своему, оно может быть фиксированным или изменяться. В случае если изменяется, то называется динамическим (начальное значение устанавливает администратор) в отличие от неизменяемых, фиксированных приоритетов. Чем выше приоритет, тем выше привелегия, тем меньше времени проводит поток в очереди.
Существует 2 разновидности таких алгоритмов:
- Использующие относительные приоритеты.
- Использующие абсолютные приоритеты.
Алгоритмы планирования с относительными приоритетами – активный процесс выполняется пока не завершится или не перейдет в состояние ожидания.
Алгоритмы планирования с абсолютными приоритетами – смена процесса происходит в тот момент, когда в системе появляется процесс, приоритет которого выше приоритета выполняемого процесса.
Реально используются смешанные схемы планирования.
Вытесняющий и невытесняющий алгоритмы планирования
Существует два основных типа процедур планирования процессов — вытесняющие (preemptive) и невытесняющие (non-preemptive).
Non-preemptive multitasking — невытесняющая многозадачность — это способ планирования процессов, при котором активный процесс выполняется до тех пор, пока он сам, по собственной инициативе, не отдаст управление планировщику операционной системы для того, чтобы тот выбрал из очереди другой, готовый к выполнению процесс.
Preemptive multitasking — вытесняющая многозадачность — это такой способ, при котором решение о переключении процессора с выполнения одного процесса на выполнение другого процесса принимается планировщиком операционной системы, а не самой активной задачей.
Понятия preemptive и non-preemptive иногда отождествляются с понятиями приоритетных и бесприоритетных дисциплин, что совершенно неверно, а также с понятиями абсолютных и относительных приоритетов, что неверно отчасти. Вытесняющая и невытесняющая многозадачность — это более широкие понятия, чем типы приоритетности. Приоритеты задач могут как использоваться, так и не использоваться и при вытесняющих, и при невытесняющих способах планирования. Так в случае использования приоритетов дисциплина относительных приоритетов может быть отнесена к классу систем с невытесняющей многозадачностью, а дисциплина абсолютных приоритетов — к классу систем с вытесняющей многозадачностью. А бесприоритетная дисциплина планирования, основанная на выделении равных квантов времени для всех задач, относится к вытесняющим алгоритмам.
Основным различием между preemptive и non-preemptive вариантами многозадачности является степень централизации механизма планирования задач. При вытесняющей многозадачности механизм планирования задач целиком сосредоточен в операционной системе, и программист пишет свое приложение, не заботясь о том, что оно будет выполняться параллельно с другими задачами. При этом операционная система выполняет следующие функции: определяет момент снятия с выполнения активной задачи, запоминает ее контекст, выбирает из очереди готовых задач следующую и запускает ее на выполнение, загружая ее контекст.
При невытесняющей многозадачности механизм планирования распределен между системой и прикладными программами. Прикладная программа, получив управление от операционной системы, сама определяет момент завершения своей очередной итерации и передает управление ОС с помощью какого-либо системного вызова, а ОС формирует очереди задач и выбирает в соответствии с некоторым алгоритмом (например, с учетом приоритетов) следующую задачу на выполнение. Такой механизм создает проблемы, как для пользователей, так и для разработчиков.
Для пользователей это означает, что управление системой теряется на произвольный период времени, который определяется приложением (а не пользователем). Если приложение тратит слишком много времени на выполнение какой-либо работы, например, на форматирование диска, пользователь не может переключиться с этой задачи на другую задачу, например, на текстовый редактор, в то время как форматирование продолжалось бы в фоновом режиме. Эта ситуация нежелательна, так как пользователи обычно не хотят долго ждать, когда машина завершит свою задачу.
Поэтому разработчики приложений для non-preemptive операционной среды, возлагая на себя функции планировщика, должны создавать приложения так, чтобы они выполняли свои задачи небольшими частями. Например, программа форматирования может отформатировать одну дорожку дискеты и вернуть управление системе. После выполнения других задач система возвратит управление программе форматирования, чтобы та отформатировала следующую дорожку. Подобный метод разделения времени между задачами работает, но он существенно затрудняет разработку программ и предъявляет повышенные требования к квалификации программиста. Программист должен обеспечить «дружественное» отношение своей программы к другим выполняемым одновременно с ней программам, достаточно часто отдавая им управление. Крайним проявлением «недружественности» приложения является его зависание, которое приводит к общему краху системы. В системах с вытесняющей многозадачностью такие ситуации, как правило, исключены, так как центральный планирующий механизм снимет зависшую задачу с выполнения.
Однако распределение функций планировщика между системой и приложениями не всегда является недостатком, а при определенных условиях может быть и преимуществом, потому что дает возможность разработчику приложений самому проектировать алгоритм планирования, наиболее подходящий для данного фиксированного набора задач. Так как разработчик сам определяет в программе момент времени отдачи управления, то при этом исключаются нерациональные прерывания программ в «неудобные» для них моменты времени. Кроме того, легко разрешаются проблемы совместного использования данных: задача во время каждой итерации использует их монопольно и уверена, что на протяжении этого периода никто другой не изменит эти данные. Существенным преимуществом non-preemptive систем является более высокая скорость переключения с задачи на задачу.
Однако почти во всех современных операционных системах, ориентированных на высокопроизводительное выполнение приложений (UNIX, Windows NT, OS/2), реализована вытесняющая многозадачность. Вытесняющую многозадачность часто называют истинной многозадачностью.
Синхронизация процессов в ОС
Проблема синхронизации процессов
Рассмотрим пример: в системе два прикладных процесса, которые будут работать с очередью печати.
N1, N2, … — указатели на последнюю свободную ячейку. Указатели сдвигаются и изменяются процессом, затем происходит переключение процессов.
Таким образом, существует ресурс, работа с которым должна протекать без прерываний (в данном примере это не учитывается). Системе нужна синхронизация при работе с этими ресурсами.
Метод критической секции
Критическая секция — это часть программы, в которой осуществляется доступ к разделяемому ресурсу.
Задача синхронизации состоит в том, чтобы построить работу так, чтобы в каждый момент в критической секции, связанной с этим ресурсом, находился максимум один процесс. Этот прием называют взаимным исключением.
Рассмотрим способы реализации критической секции.
Запрет прерываний
Простейший способ обеспечить взаимное исключение — позволить процессу, находящемуся в критической секции, запрещать все прерывания. Однако этот способ сложен, так как опасно доверять управление системой пользовательскому процессу; он может надолго занять процессор, а при крахе процесса в критической области крах потерпит вся система, потому что прерывания никогда не будут разрешены.
Использование блокирующей переменной (семафора)
Семафор — переменная, принимающая целые неотрицательные значения, используется для синхронизации вычислительных процессов.
У двоичного семафора D 2 значения:
- D=1: ресурс свободен
- D=0: ресурс занят
Перед входом в критическую секцию процесс проверяет, свободен ли ресурс D. Если он занят, то проверка циклически повторяется, если свободен, то значение переменной D устанавливается в 0, и процесс входит в критическую секцию. После того, как процесс выполнит все действия с разделяемым ресурсом D, значение переменной D снова устанавливается равным 1.
Если все процессы написаны с использованием вышеописанных соглашений, то взаимное исключение гарантируется. Следует заметить, что операция проверки и установки блокирующей переменной должна быть неделимой. Поясним это. Пусть в результате проверки переменной процесс определил, что ресурс свободен, но сразу после этого, не успев установить переменную в 0, был прерван. За время его приостановки другой процесс занял ресурс, вошел в свою критическую секцию, но также был прерван, не завершив работы с разделяемым ресурсом. Когда управление было возвращено первому процессу, он, считая ресурс свободным, установил признак занятости и начал выполнять свою критическую секцию. Таким образом, был нарушен принцип взаимного исключения, что потенциально может привести к нежелаемым последствиям. Во избежание таких ситуаций в системе команд машины желательно иметь единую команду «проверка-установка», или же реализовывать системными средствами соответствующие программные примитивы, которые бы запрещали прерывания на протяжении всей операции проверки и установки.
Реализация критических секций с использованием блокирующих переменных имеет существенный недостаток: в течение времени, когда один процесс находится в критической секции, другой процесс, которому требуется тот же ресурс, будет выполнять рутинные действия по опросу блокирующей переменной, бесполезно тратя процессорное время. Для устранения таких ситуаций может быть использован так называемый аппарат событий. С помощью этого средства могут решаться не только проблемы взаимного исключения, но и более общие задачи синхронизации процессов. В разных операционных системах аппарат событий реализуется по своему, но в любом случае используются системные функции аналогичного назначения, которые условно назовем WAIT(x) и POST(x), где x — идентификатор некоторого события. Если ресурс занят, то процесс не выполняет циклический опрос, а вызывает системную функцию WAIT(D), здесь D обозначает событие, заключающееся в освобождении ресурса D. Функция WAIT(D) переводит активный процесс в состояние ОЖИДАНИЕ и делает отметку в его дескрипторе о том, что процесс ожидает события D. Процесс, который в это время использует ресурс D, после выхода из критической секции выполняет системную функцию, в результате чего операционная система просматривает очередь ожидающих процессов и переводит процесс, ожидающий события D, в состояние ГОТОВНОСТЬ.
Модернизация схемы:
Рассмотрим пример: две программы пишут и читают из буфера.
Программа 1:
#define №256 int e=N, f=0, b=1; void writer { while(1) { PrepNextRec(); P(e); P(b); AddToBuf(); V(b); V(f); } }
Программа 2:
void reader { while( ) { P(f); P(b); GetFromBuf(); V(b); V(e); ProcRec(); } } // e – число пустых ячеек. // f – число дополнительных ячеек. // b – критическая секция (семафор). // Р() – проверяет не равно ли 0 значение. Если нет, то уменьшает его на 1. Позволяет войти в критическую секцию. // V() – увеличивает значение счетчика в любом случае на 1. // PrepNextRec() – проверяет есть ли куда писать. // P(e) – проверяет не равно ли 0 число ячеек. // P(b) – проверяет в каком состоянии семафор. // AddToBuf() – дописывает то, что нужно. // P(f) – проверяет, заполнены ли ячейки. // P(b) – проверяет семафор. // GetFromBuf() – выполняет чтение из буфера. // V(b) – восстанавливает семафор. // ProcRec() – обрабатывает прочитанную запись.
При работе с блокирующими переменными порядок обращения к ним должен быть одинаковым, иначе может вернуть состояние взаимной блокировки.
