CC BY
80
Process release management information systems Timofeev A.1, Kravchenko A.2 Процесс управления релизами информационных систем Тимофеев А. А.1, Кравченко А. В.2
1Тимофеев Александр Андреевич / Timofeev Alexander - студент магистратуры, направление: прикладная информатика; 2Кравченко Анатолий Васильевич / Kravchenko Anatolii - кандидат технических наук, доцент, кафедра экономической информатики, факультет бизнеса, Новосибирский государственный технический университет, г. Новосибирск
Аннотация: в данной статье рассматривается процесс управления релизами программного обеспечения на основе стандартов ITIL и COBIT. Представлены задачи процесса управления релизами, а также стандарты, регламентирующие данный процесс.
Abstract: this article discusses the software release management process based on ITIL and COBIT standards. Presents the problem management process releases, as well as the standards governing the process.
Ключевые слова: релиз, ITIL, COBIT, тестирование, разработка, процесс, модификация. Keywords: release, ITIL, COBIT, testing, development, process modification.
Задачей процесса управления релизами является обеспечение качества рабочей среды за счет использования формальных процедур и проверок при вводе в работу новых версий программного обеспечения [1].
Рассмотрим два распространенных стандарта, регламентирующих процесс выпуска релизов.
1. ITIL — библиотека, описывающая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий [б].
ITIL рассматривает процесс выпуска релизов во взаимосвязи с другими ключевыми процессами управления ИТ - услугами. Согласно данному стандарту процесс управления релизами входит в процесс управления изменениями. На рисунке 1 показано местоположение процесса управления релизами в структуре управления уровнем обслуживания.
Рис. 1. Управление уровнем обслуживания
Основными целями Управления релизами и развертыванием согласно 1Т1Ь являются:
1. Формирование и согласование планов релизов и развертывания с заказчиками и инвесторами;
2. Гарантия того, что каждый пакет для релиза состоит из набора связанных и совместимых компонентов;
3. Осуществление управления релизом и его компонентами в рамках процессов Внедрения;
4. Гарантия того, что все пакеты для релизов могут быть протестированы, отслежены, проверены, установлены или устранены (при необходимости);
5. Гарантия того, что все изменения управляются в рамках деятельностей по управлению релизами и развертыванием;
6. Ведение отчетов и управление рисками, проблемами, расхождениями, связанными с новой или измененной услугой. Осуществление корректирующих действий при необходимости;
7. Обеспечение доступа к информации для заказчиков и инвесторов, чтобы они могли эффективно использовать новую или измененную услугу;
8. Обеспечение доступа к информации для операционного персонала, чтобы он мог предоставлять, поддерживать и управлять услугой [2].
1Т1Ь описывает два подхода к развертыванию релиза:
1. «Большой взрыв» - новая или измененная услуга развертывается сразу для всех пользователей в рамках одной операции;
2. Пофазовый подход - услуга развертывается поэтапно. Сначала одной части пользователей, затем остальным [5].
На рисунке 2 представлено применение двух подходов.
Рис. 2. Два подхода к развертыванию услуг
СОВ1Т - представляет собой пакет открытых документов, около 40 международных и национальных стандартов и руководств в области управления 1Т, аудита и 1Т-безопасности [4]. Основные требования, которые должны быть соблюдены при выпуске релизов согласно СОВ1Т:
1. Сборка решения:
■ Обеспечить интеграцию компонентов решения и инфраструктуры, учесть все спецификации и требования к качеству.
■ Отразить в документации все финальные требования.
■ Провести проверку сборки, в том числе автоматизированными средствами.
■ Обеспечить учет настроек оборудования и решения, защиту ресурсов, доступность и интегрированность.
■ Обновить сервисные каталоги.
2. Обеспечение качества:
■ Разработать стандарты обеспечения качества (критерии качества, проверка обеспечения качества, кто и как проверяет качество, роли при проверке).
■ Просмотр кода, автоматизированное тестирование разработанного решения, интеграционные тесты. Отчетность перед руководством.
■ Регулярный мониторинг соблюдения процедур обеспечения качества.
■ Выполнение корректировочных мероприятия в случае отклонений по качеству. Учет проверок, результатов проверок, обнаруженных проблем, предпринятых мер.
3. Подготовка к тестированию:
■ Разработать стандарты тестирования для обеспечения проверки работоспособности решения в изолированной среде, отчетности для руководства.
■ Создать тестовую среду, которая бы максимально близко повторяла производственную среду.
■ Разработать планы тестирования, обеспечить участие в тестировании всех заинтересованных сторон.
4. Исполнение тестирования:
■ Исполнение тестирования в соответствии с планом тестирования. Обеспечить участие представителя Заказчика. Тестирование выполнять в среде разработки и тестирования.
■ Найти баланс между автоматизированным и ручным тестированием.
■ Протестировать нефункциональные требования (безопасность, взаимодействие, удобство).
■ Идентифицировать, учесть, классифицировать замечания по итогам тестирования. Убедиться в наличии аудиторских записей.
■ Отчитаться о результатах тестирования руководству.
5. Управление изменениями требований:
■ Оценить влияние запросов на изменение на решение, способы использования, бюджет. Категорировать и приоритезировать запросы на изменение.
■ Информировать заинтересованные стороны о запросах на изменение, согласовывать их с владельцами ресурсов.
■ Исполнить запросы на изменения, обеспечить интеграционное тестирование.
6. Наличие среды тестирования:
■ Должна быть тестовая БД, из нее должны быть удалены данные, которые не могут применяться для тестирования.
■ Защитить важные данные в тестовой среде от разглашения, копирования, уничтожения.
■ Тестовая среда должна быть адекватна производственным задачам, требуемому ПО, нагрузочной пропускной способности.
■ Тестовая среда должна быть безопасной, исключить взаимодействие с производственной средой.
7. Проведение приемочных тестов:
■ Вести учет возникающих при тестировании ошибок.
■ Тестирование должно выполняться не разработчиком, а другим специалистом. Определить объем участия специалистов Владельца в тестировании.
■ Тестирование должно выполняться исключительно в тестовой среде.
■ Убедиться, что результаты тестирования соответствуют приемочным требованиям (если были сформулированы Владельцем).
■ Найти баланс между автоматизированным и ручным тестированием. Провести тесты безопасности. Провести нагрузочное тестирование.
■ Сформулировать результаты тестирования в понятном для бизнеса виде. Подписать акт приемки результатов тестирования у владельца и заинтересованных сторон до переноса в производственную среду.
■ Перед переносом проверить журнал замечаний (убедиться, что все замечания сняты), акты тестирования подписаны.
8. Перенос в производственную среду и управление релизами:
■ Подготовить регламенты, ПО, инструкции, инфраструктуру для переноса нового релиза.
■ Определить необходимость в пилотном проекте или параллельной работе старой и новой систем.
■ Обновить документацию, планы резервного копирования (если необходимо).
■ Обновить установочные диски, старые версии заархивировать и передать в архив. Убедиться, что все материалы выложены в TFS.
■ Убедиться, что новый релиз устанавливается только на те ПК, которые положено. Обеспечить сбор и анализ ошибок установки, убедиться, что установка на всех ПК прошла успешно [3].
Литература
1. Ван Бон Ян. ИТ-сервис менеджемент. Вводный курс на основе ITIL. [Текст] / Ван Бон Ян. Издательский дом: Van Haren Publishing, по заказу ITSMF Netherlands, 2010. 73 с.
2. [Электронный ресурс]: ITIL. Режим доступа: http://www.itil-officialsite.com/ (дата обращения: 26.03.2014). Загл. с экрана.
3. ISACA. COBIT 5: Enabling Processes.USA. ISACA, 2012. 230 p.
4. ИНТУИТ. [Электронный ресурс]: Лекция 9: Управление релизами и развертыванием в рамках Внедрения услуг. Режим доступа: http://www.intuit.ru/studies/courses/2323/623/lecture/13572/ (дата обращения: 23.08.2015). Загл. с экрана.
5. Википедия. [Электронный ресурс]: ITIL. Режим доступа: https://ru.wikipedia.org/wiki/ITIL/ (дата обращения: 26.04.2016). Загл. с экрана.
Safety of ventilation systems Adamyan V.1, Chentsova K.2 Безопасность вентиляционных систем Адамян В. Л.1, Шенцова К. В.2
'Адамян Владимир Лазаревич /Adamyan Vladimir - кандидат технических наук, доцент, кафедра пожарной безопасности и защиты в чрезвычайных ситуациях; 2Шенцова Ксения Владимировна / Chentsova Ksenia — студент, специальность: промышленное и гражданское строительство, Донской государственный технический университет, г. Ростов-на-Дону
Аннотация: приводятся возможные причины возгорания в вентиляционных системах. Указываются основные меры противопожарной безопасности вентиляционных систем. Abstract: describes the possible causes of the fire ventilation systems. Identify the principal fire safety measures ventilation systems.
Ключевые слова: вентиляционные системы, пожар, продукты горения, эвакуация, вытяжные и приточные противодымные вентиляции.
Keywords: ventilation system, fire, products of combustion, evacuation, smoke exhaust and supply ventilation.
УДК 697.92
В последнее время в строительстве применяют современные методы и технологии. Это относится и к коммуникационным системам, в том числе и вентиляции. Особенное внимание уделяют пожарной безопасности этой коммуникации.
При возможных пожарах чрезвычайная ситуация усугубляется тем, что продукты горения содержат 50-100 видов химических соединений, оказывающих токсическое воздействие. Так, при сгорании линолеумов выделяются сероводород и сернистый газ, при горении мягкой мебели, в которой использован полиуретан, выделяется цианид водорода и толуилендиизоцианат. Отравление угарным газом в случае интоксикации чревато летальным исходом [1]. В случае возникновения пожара дым распространится в первую очередь в вентиляционной системе. Во время пожара выделяется тепловая энергия, а также вредные
