Разработка системы управления конфигурациями информационных систем

Размещено на http://www.allbest.ru/

Пермский филиал федерального государственного автономного образовательного учреждение высшего образования

Национальный исследовательский университет «Высшая школа экономики»

Факультет экономики, менеджмента и бизнес-информатики

Выпускная квалификационная работа

РАЗРАБОТКА СИСТЕМЫ УПРАВЛЕНИЯ КОНФИГУРАЦИЯМИ ИНФОРМАЦИОННЫХ СИСТЕМ

Плотникова Ксения Алексеевна

Пермь, 2018 год



Оглавление

Введение

1. Аналитический обзор

1.1 Общее понятие конфигурации

1.2 Анализ мировых библиотек знаний

2. Анализ современных систем управления конфигурациями

2.1 Описание бизнес-процессов предметной области

2.2 Моделирование пользовательских сценариев и вариантов использования системы

3. Проектирование данных

4. Реализация системы

4.1 Реализация пользовательских интерфейсов

Заключение

Библиографический список

Аннотация

Приложение



Введение

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

Конфигурационная единица в данном случае - программная (ПО, установленное на учебном или рабочем месте) компонента места, а конфигурация - уникальный набор таких конфигурационных единиц, входящих в состав определенного места. Как правило, компьютерный класс состоит из учебных мест с одинаковой конфигурацией. Рабочие же места преподавателей содержат разный набор программ, требуемых для деятельности, но имеют базовый стандартный набор, хоть и небольшой [1].

Проблема управления конфигурациями учебных и рабочих мест достаточно актуальна для сотрудников Компьютерного центра. На данный момент нет программного модуля, исполняющего данный процесс, но уже есть один из вариантов алгоритма, разработанного одним из студентов НИУ ВШЭ-Пермь [3]. В связи с этим процесс зачастую выполняется недостаточно точно, важные сведения не всегда документируются должным образом. Для хранения информации о конфигурациях специалисты используют множество инструментов, и с каждым новым требованием, предъявляемым к учебным местам, управлять конфигурациями становится всё сложнее, что в первую очередь связано с децентрализованным хранением данных. По мнению специалистов Компьютерного центра [3], данная проблема возникает из-за отсутствия единой информационной системы, которая позволила бы вести учет необходимой в процессе информации и управлять конфигурациями и изменениями, что позволило бы пользователям сократить время, умственные и физические ресурсы, затрачиваемые на управление этим процессом.

Объектом исследования данной работы является процесс управления конфигурациями учебных и рабочих мест в НИУ ВШЭ-Пермь, предметом - информационная система управления конфигурациями.

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

Для достижения цели необходимо выполнить ряд задач:

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

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

3. Выполнить моделирование системы управления конфигурациями:

a. произвести моделирование вариантов использования с помощью диаграммы прецедентов;

b. произвести моделирование предметной области с помощью диаграммы классов;

c. произвести моделирование архитектуры системы с помощью диаграммы компонентов.

4. Разработать информационную систему.

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

b. произвести функциональное и интеграционное тестирование.

В рамках работы используются следующие методы и инструменты:

1. Для моделирования и реализации системы используются методы объектно-ориентированного проектирования и программирования.

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

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



1. Аналитический обзор

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

Задачами главы являются:

1. Анализ мировых практик в области управления ИТ-услугами ITIL и SWEBOK - рекомендаций по организации процесса управления конфигурациями.

2. Анализ существующих систем управления конфигурациями.

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

1.1 Общее понятие конфигурации

Конфигурацией в общем случае называют внешний вид, очертание, образ какого-либо предмета или его части, а также взаимное расположение предметов между собой либо соотношение основных частей сложных предметов [4].

В IT-отрасли конфигурацией называется совокупность конфигурационных единиц (Configuration Item или CI) - любого компонента, который нуждается в управлении для того, чтобы предоставлять услугу [8].

Согласно библиотеке инфраструктуры информационных технологий, называемой ITIL, которая будет рассмотрена более подробно в следующем пункте данной главы, управление конфигурациями отвечает за то, чтобы отдельные компоненты услуги, системы или продукта, были должным образом определены, снабжены всем необходимым и контролировались. Процесс также контролирует все изменения компонентов. Информация о каждой конфигурационной единице регистрируется в форме Записи о конфигурационной единице в Системе управления конфигурациями и поддерживается актуальной в течение всего жизненного цикла процессом Управления конфигурациями. Конфигурационная единица находятся под контролем Управления изменениями. Типичными примерами конфигурационной единицы являются услуги, оборудование, программное обеспечение, здания, люди и документы, такие как Процессная документация и Соглашения об уровне услуг (SLA).

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

1. СI жизненного цикла - бизнес-кейс, планы сервис-менеджмента, проектная документация, планы релизов, изменений и тестирования. Эти конфигурационные единицы предоставляют полную картину об услугах поставщика и их предоставлении, ожидаемых выгод от использования, затратах и сроках релиза.

2. CI услуг:

2.1. возможности услуг - управление, организация, процессы, знания, люди;

2.2. ресурсы услуг - капитал, системы, приложения, информация, данные, инфраструктуры и т.п.;

2.3. модель услуг;

2.4. пакет услуг;

2.5. пакет релизов;

2.6. критерии приемки услуг.

3. CI организации. Некоторая документация определяет характеристики CI, некоторая сама является CI и требует контроля, например, стратегия бизнеса или политика организации:

3.1. внутренние СI - материальные и нематериальные активы, которые необходимы для предоставления и управления услугами;

3.2. внешние CI - требования заказчиков, соглашения, релизы поставщиков и внешние услуги.

4. CI интерфейсов - активы, необходимые для предоставления услуг "от начала до конца" в рамках Интерфейса поставщика услуг. Интерфейс поставщика услуг (Service Provider Interface или SPI) - интерфейс между поставщиком услуг и пользователем, заказчиком, бизнес-процессом, или поставщиком. Анализ интерфейсов поставщика услуг помогает координировать сквозное управление услугами.

Система управления конфигурациями (Configuration Management System или CMS) - набор инструментов и баз данных, которые используются для управления данными о конфигурациях поставщиком услуг. CMS также содержит информацию об инцидентах, проблемах, известных ошибках, изменениях и релизах; и может содержать данные о сотрудниках, поставщиках, местоположениях, бизнес-единицах, заказчиках и пользователях. CMS включает в себя инструменты для сбора, хранения, управления, обновления и представления информации обо всех конфигурационных единицах и их взаимоотношениях.

1.2 Анализ мировых библиотек знаний

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

Библиотека ITIL v3

Согласно официальному определению, «ITIL (IT Infrastructure Library) - это набор публикаций, содержащий лучшие практики в области управления ИТ-услугами» [6]. Таким образом, ITIL является библиотекой рекомендаций по организации в компаниях процессов, связанных с ИТ-услугами.

В 2011 году была опубликована самая актуальная на настоящий момент времени версия библиотеки - ITIL v3. Эта версия основывается на жизненном цикле ИТ-услуг. ITIL v3 в значительно большей степени затрагивает интересы бизнеса. Эта методика базируется вокруг интеграции бизнеса и ИТ и восприятии ИТ в качестве бизнеса. Эта интеграция переводит ИТ-отдел из состояния «сторонней» поддержки (выполняющей вспомогательные функции для основного бизнеса) в равноправного участника бизнес-процессов организации. Достичь этой интеграции организациям поможет внедрение подхода «жизненного цикла» к управлению ИТ-услугами: в новой версии предлагается взглянуть на управление ИТ-услугами с точки зрения их жизненного цикла - от глобальной перспективы стратегии услуги к проектированию услуги, преобразованию услуги, эксплуатации услуги и непрерывному её улучшению. Новый подход, благодаря своей ориентации на интеграцию в бизнес, позволяет проводить оценку затрат и возврата инвестиций, и акценты смещаются от обеспечения функционирования процессов к созданию бизнес-ценности.

ITIL v3 содержит 5 книг, которые иллюстрируют пять основных процессов управления ИТ-услугами. В общей сложности данными процессами поддерживаются 26 функций (рис. 1.1).

Процесс управления конфигурациями рабочих мест заключается в учёте программного и аппаратного обеспечения (конфигурационных единиц), а также в контроле изменений, связанных с конфигурациями рабочих мест. В ITIL за обеспечение контроля над изменениями отвечает три процесса преобразования услуг (Service Transition): Управление изменениями, Управление сервисными активами и конфигурациями и Управление релизами и развертыванием. Последний из этих трёх процессов - Управление релизами и развёртыванием - с точки зрения процесса управления конфигурациями учебных мест заключается во внедрении (инсталляции) конфигураций на учебные места, что не является частью системы управления конфигурациями. Таким образом, данный процесс рассматриваться не будет, и только два процесса будут приниматься во внимание при учёте специфики анализируемых конфигураций.

Рисунок 1.1. Структура книг ITIL v3

Управление сервисными активами и конфигурациями

Управление сервисными активами и конфигурациями включает в себя два подпроцесса: Управление активами и Управление конфигурациями.

Согласно принятым определениям, «Управление активами (Asset Management) - это деятельность или процесс, отвечающий за отслеживание и предоставление отчётности о ценности и владении активами на всём протяжении их жизненного цикла», в то время как «Управление конфигурациями (Configuration Management) - это деятельность или процесс, отвечающий за управление информацией о конфигурационных единицах, необходимой для предоставления ИТ-услуг, включая их взаимоотношения».

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

Задачами процесса управления сервисными активами и конфигурациями с учётом особенностей данной предметной области являются:

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

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

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

На рисунке 1.2 отображена типовая структура процесса управления сервисными активами и конфигурациями. Он состоит из следующего набора деятельностей: управление и планирование, идентификация конфигураций, управление CI (configuration items, конфигурационные единицы, КЕ), отчетность по статусу, верификация и аудит.

Для данной предметной области в качестве критериев эффективности процесса ITIL рекомендует использовать следующие показатели:

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

2. Своевременная идентификация конфигурационных единиц, из-за которых возникают сбои в конфигурациях.

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

4. Улучшение качества и точности информации о конфигурациях и конфигурационных единицах.

5. Устранение ошибок, вызванных работой с устаревшими данными (постоянная актуализация CMDB).

6. Эффективный аудит конфигураций.

7. Уменьшение установок и использования неавторизованных конфигурационных единиц.

Рисунок 1.2. Процесс управления сервисными активами и конфигурациями по ITIL

8. Уменьшение количества неуспешных изменений, причиной чего явилась неверная оценка влияния, некорректные данные в CMS или плохой контроль версий.

Процесс управления ИТ-инфраструктурой требует систему управления конфигурациями (Configuration Management System, CMS) Данная система необходима для хранения всех данных о конфигурационных единицах и конфигурациях.

Управление изменениями

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

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

Рисунок 1.3. Процесс управления изменениями по ITIL

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

В качестве критериев эффективности процесса управления изменениями ITIL рекомендует использовать следующие основные показатели:

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

2. Сокращение количества неавторизованных изменений.

3. Сокращение очереди запросов на изменения, процента незапланированных изменений и срочных исправлений.

4. Сокращение количества изменений, потребовавших восстановления.

5. Сокращение количества неуспешных изменений.

6. Среднее время внедрения изменения.

7. Оценка количества инцидентов, связанных с изменением.

8. Точность оценки изменений.

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

Библиотека SWEBOK v3

SWEBOK (Software Engineering Book of Knowledge) - это научно-технический документ, в котором содержатся рекомендации отечественных и зарубежных специалистов в области программной инженерии [7]. Основные аспекты дисциплины, изложенные в библиотеке, относятся к инженерии требований, проектированию, конструированию, тестированию и сопровождению программного обеспечения. Одной из организационных областей знаний SWEBOK является управление конфигурацией.

Согласно понятийному аппарату SWEBOK, управление конфигурацией (Software Configuration Management, SCM) заключается в идентификации компонентов системы, определении функциональных и физических характеристик аппаратного и программного обеспечения для контроля за внесением изменений и трассированием конфигурации на протяжении её жизненного цикла. Зачастую в SWEBOK этот процесс называют SCCM (Software Configuration and Change Management) - управление конфигурацией и изменениями.

Область знаний SWEBOK «Управление конфигурациями» представлена на рисунке 1.4 и в таблице, вынесенной в приложение А.

Рисунок 1.4. Область знаний процесса управления конфигурациями по SWEBOK

Алгоритм процесса управления изменениями по SWEBOK представлен на рисунке 1.5. Описанный подход гарантирует возможность отслеживания дефектов и сбора метрических показателей о деятельности по обработке и внесению изменений, с группировкой по типу изменений. Как только получен запрос на изменение (SCR), производится техническая оценка запрашиваемых изменений для определения масштабов модификаций, необходимых для удовлетворения параметров запрашиваемых изменений (достаточно часто, в результате такого анализа формулируются соответствующие требования, определяющие содержание необходимых работ, прим. автора). Четкое понимание связей между программными (и, возможно, аппаратными) элементами системы является важной составной частью данной задачи. Наконец, органы, обладающие полномочиями, соответствующими затрагиваемой базовой линии, элементам программной конфигурации и природе изменений, должны оценить технические и управленческие (организационные) аспекты внесения запрашиваемых изменений, а также принять, модифицировать, отклонить или отложить предлагаемые изменения.



Рисунок 1.5. Алгоритм процесса управления изменениями по SWEBOK

В результате обзора библиотек знаний ITIL и SWEBOK были сделаны следующие выводы:

1. Любой существующей инфраструктурой и соответствующей конфигурацией должны управлять процессы ITIL и SWEBOK.

2. Управлению ИТ-услугами с точки зрения инженера систем в большей степени соответствует описание процесса SWEBOK, поэтому они должны управляться данным процессом.

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

4. Процесс управления изменениями и конфигурациями в современных информационных системах (CMS) должен быть реализован в соответствии с сервисным и процессным подходами.



2. Анализ современных систем управления конфигурациями

Данной части главы представляет собой обзор некоторых современных системы управления конфигурациями: Chef, Puppet, SaltStack и Ansible. Для каждой системы приводятся её функциональные возможности и особенности.

Chef

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

Chef используется для упрощения задачи конфигурирования и обслуживания серверов компании, а также может быть встроенной в облачные платформы, такие как Amazon EC2, Google Cloud Platform, OpenStack, SoftLayer, Microsoft Azure и Rackspace, для автоматического обеспечения конфигурациями новых компьютеров. Система не имеет ограничений по размерам систем, имеет разные решения с соответствующими особенностями и ценами диапазонов [9]. Chef использует специальный декларативный предметно-ориентированный язык для описания конфигураций.

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

Chef поддерживает несколько режимов работы. Первый - это клиент-сервер, второй - режим автономной конфигурации, «chef-solo». При работе в режиме клиент-сервер клиентом осуществляется отправка на сервер различных свойств хоста, на котором он расположен. Для индексирования свойств и предоставления API для запроса информации клиентом на стороне сервера используется Solr. Эти свойства могут быть запрошены «рецептами», которые затем могут использовать полученные данные для настройки хоста.

В соответствии с поддерживаемой матрицей для клиентов и серверов Chef имеет поддержку на нескольких платформах. Chef клиент поддерживается на платформах AIX, RHEL/CentOS, FreeBSD, OS X, Solaris, Microsoft Windows и Ubuntu. Дополнительные платформы: Arch Linux, Debian и Fedora. Основные поддерживаемые сервером платформы: RHEL/CentOS, Oracle Linux и Ubuntu.

Chef используется в компаниях Airbnb, Mozilla, Expedia, Facebook, HP Public Cloud, Prezi, Xero, Ancestry.com, Rackspace, Get Satisfaction, IGN, Marshall University, Socrata, University of Minnesota, Wharton School of the University of Pennsylvania, Bonobos, Splunk, Citi, DueDil, Disney и Cheezburger.

Puppet

Puppet является кроссплатформенным клиент-серверным приложением, для централизованного управления конфигурацией операционных систем и программ, установленных на нескольких компьютерах [10]. Также как и Chef в большей степени используется для Linux и является одним из самых актуальных средств конфигурационного управления. Конфигурации также описываются на специальном декларативном предметно-ориентированном языке.

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

Puppet позволяет просто настроить и впоследствии быстро управлять практически любой сетью на базе любой операционной системы Red Hat Enterprise Linux, CentOS, Fedora, Debian, Ubuntu, OpenSUSE, Solaris, BSD, Mac OS X и Microsoft Windows.

Система Puppet является основой конфигурационного управления в таких компаниях как Google, Яндекс, Fedora Project, Стэнфордский университет, Red Hat, Siemens IT Solution, SugarCRM, Mail.Ru.

SaltStack

SaltStack также является одной из самых популярных систем управления конфигурациями и удалённого выполнения операций.

Система SaltStack состоит из двух основных компонентами: Salt Master («мастер») и Salt Minion («ставленник», «приближённый», «миньон»). Мастер является центральной службой. «Ставленники» осуществляют подключение к нему для получения конфигурации [11]. Две определяющих идеи SaltStack: удалённое выполнение операций (remote execution) и управление конфигурациями. Удалённое выполнение функций Python является основой для построения повторяемой и управляемой конфигурации машин, с установленными на них «ставленниками».

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

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

Ansible

Ansible - ещё одна наиболее актуальная система управления конфигурациями. Также включает использования декларативного языка разметки для описания конфигураций. Наряду со всеми вышеописанными системами наиболее используема в управлении конфигурациями для Linux. Ansible входит в состав большинства дистрибутивов Linux. Есть пакеты для Solaris, FreeBSD и MacOS.

Основное преимущество данной системы состоит в том, что целевые системы не требуют установки агента/клиента для работы. Используется для автоматизации настройки и развертывания программного обеспечения [12].

Работая с Ansible, пользователь создаёт определенные «плейбуки» в формате YAML с описанием требуемых состояний управляемой системы. «Плейбуки» являются почти полным подобием «рецептов» в Chef.

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

Графическим интерфейсом для управления и мониторинга работы Ansible является Ansible Tower является. Данное решение является платным и предоставляет пользователям следующие возможности:

1. Визуальная панель состояния.

2. Списки доступа, группы и роли пользователей.

3. Централизованное логирование и аудит.

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

В качестве более узкого примера для реализации требуемой системы используется процесс управления конфигурациями учебных и рабочих мест в НИУ ВШЭ-Пермь. В рамках работы под автоматизированным учебным местом подразумевается аппаратно-программный комплекс - компьютер с установленным программным обеспечением - расположенный в определенном компьютерном классе НИУ ВШЭ-Пермь. Учебные места предназначены для изучения студентами дисциплин. Автоматизированное рабочее место - аппаратно-программный комплекс, расположенный на определённом рабочем месте конкретного сотрудника НИУ ВШЭ-Пермь [1]. Рабочие места предназначены для выполнения подготовки преподавателями к проведению занятий определённых дисциплин, проверки выполненных работ и пр.

2.1 Описание бизнес-процессов предметной области

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

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

Рисунок 2.1. Модель TO-BE бизнес-процесса управления конфигурациями

Рисунок 2.2. Жизненный цикл конфигураций

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

Таблица 2.1. Описание статусов конфигурации

Статус конфигурации	Описание состояния конфигурации	Атрибуты конфигурации
Проект	Конфигурации находится на стадии проектирования.	Состав конфигурации (редактируется).
Утверждено	Конфигурация утверждена специалистами Компьютерного центра и поставщиками требований.	Состав конфигурации.
Протестировано	Создана стратегия установки, проведено интеграционное тестирование.	Состав конфигурации. Стратегия установки. Отчет о тестировании.
Изготовлено	Создан образ конфигурации.	Состав конфигурации. Стратегия установки. Отчет о тестировании. Образ конфигурации. Отчет о создании образа конфигурации.
Эксплуатируется	Конфигурация развернута на учебных местах и эксплуатируется.	Состав конфигурации. Стратегия установки. Отчет о тестировании. Образ конфигурации. Отчет о создании образа конфигурации. Отчет о развертывании.
Выведено из эксплуатации	Конфигурация выведена из эксплуатации по каким-либо причинам.	Состав конфигурации. Стратегия установки. Отчет о тестировании. Образ конфигурации. Отчет о создании образа конфигурации. Отчет о развертывании. Причина вывода конфигурации из эксплуатации.



2.2 Моделирование пользовательских сценариев и вариантов использования системы

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

Управление SCM-процессом

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

Пример содержания Плана управления активами и конфигурациями:

1. Контекст и цель.

2. Охват:

2.1. применяемые услуги;

2.2. среда и инфраструктура;

2.3. географическое месторасположение.

3. Требования:

3.1. требования стратегии и политик;

3.2. требования бизнеса, Управления услугами и контрактов;

3.3. совокупность требований к подотчетности и трассируемости;

3.4. требования Системы управления конфигурациями.

4. Применяемые политики и стандарты:

4.1. политики;

4.2. индустриальные стандарты;

4.3. внутренние стандарты, относящиеся к Управлению конфигурациями.

5. Организация Управлением конфигурациями:

5.1. роли и ответственности;

5.2. комитеты для контроля изменений и конфигураций;

5.3. авторизация.

6. Система и инструменты Управления активами и конфигурациями.

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

7.1. идентификация конфигураций;

7.2. управление версиями;

7.3. управление интерфейсами;

7.4. управление поставщиками;

7.5. управление изменениями конфигураций;

7.6. релиз и развертывание;

7.7. управление сборкой;

7.8. управление снабжением;

7.9. управление CMS.

8. Ссылка на План реализации.

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

Рисунок 2.3. Варианты использования в рамках деятельности "Управление SCM-процессом"

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

Рисунок 2.4. Пользовательский сценарий в рамках деятельности "Управление SCM-процессом"

Проектирование конфигурации

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

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

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

Диаграмма прецедентов данного процесса представлена ниже (рис. 2.5).



Рисунок 2.5. Варианты использования в рамках деятельности "Проектирование конфигурации"

Тестовые сценарии, в которых учтена проверка реализуемости пользовательских сценариев, продемонстрированы на рисунках 2.6-2.8.

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

1. Создать проект конфигурации.

2. Просмотреть проект конфигурации.

3. Редактировать проект конфигурации.

4. Отметить предпочтительные конфигурационные единицы в проекте конфигурации.

5. Утвердить конфигурацию.

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

1. Создать стратегию установки.

2. Просмотреть стратегию установки.

3. Редактировать стратегию установки.



Рисунок 2.6. Пользовательский сценарий в рамках деятельности "Проектирование конфигурации"

Рисунок 2.7. Пользовательский сценарий в рамках деятельности "Проектирование конфигурации"



На рисунке 2.8 продемонстрирован сценарий, в рамках которого реализуются следующие варианты использования системы:

1. Создать отчет о проведении тестирования конфигурации.

2. Просмотреть отчет о проведении тестирования конфигурации.

3. Распечатать отчет о проведении тестирования конфигурации.

Рисунок 2.8. Пользовательский сценарий в рамках деятельности "Проектирование конфигурации"

Изготовление конфигурации

Отчет об изготовлении конфигурации можно создать и просмотреть, а также внести в него изменения. Поскольку на данном этапе отчет является обязательным атрибутом конфигурации, удалить его нельзя. Деятельность «Изготовление конфигурации» проиллюстрирована в виде диаграммы вариантов использования на рис 2.9.

Отчет об изготовлении конфигурации содержит информацию:

1. Имя конфигурации.

2. Имя образа.

3. Дата создания образа.

4. Справочная информация (комментарий в свободной форме).

Рисунок 2.9. Варианты использования в рамках деятельности "Изготовление конфигурации"

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

Рисунок 2.10. Пользовательский сценарий в рамках деятельности "Изготовление конфигурации"



Развёртывание конфигурации

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

Отчет о развертывании конфигурации содержит информацию:

1. Имя конфигурации.

2. Имя образа.

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

4. Дата развертывания.

5. Справочная информация (комментарий в свободной форме).

Рисунок 2.11. Варианты использования в рамках деятельности "Развертывание конфигурации"

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



Рисунок 2.12. Пользовательский сценарий в рамках деятельности "Развертывание конфигурации"

Контроль конфигурации

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

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



Рисунок 2.13. Варианты использования в рамках деятельности "Контроль конфигурации"

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

Рисунок 2.14. Пользовательский сценарий в рамках деятельности "Контроль конфигурации"

Учёт статусов конфигурации

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

Рисунок 2.15. Варианты использования в рамках деятельности "Учет статусов конфигурации"

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

Рисунок 2.15. Пользовательский сценарий в рамках деятельности "Учёт статусов конфигурации"

Аудит конфигурации

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

Отчет о проведении аудита конфигурации содержит информацию:

1. Имя конфигурации.

2. Список учебных мест (компьютерных классов), для которых проведен аудит.

3. Дата проведения аудита.

4. Справочная информация (комментарий в свободной форме).

Рисунок 2.17. Варианты использования системы в рамках деятельности "Аудит конфигурации"

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



Рисунок 2.18. Пользовательский сценарий в рамках деятельности "Аудит конфигурации"



3. Проектирование данных

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

Рисунок 3.1. Схема базы данных

Для представления значений полей, содержимое таблиц БД представлено в табл. 3.1-3.6. Переведем все эти таблицы в SQL.



Таблица 3.1. Поля таблицы MigrationHistory

Название поля	Тип	Описание
MigrationId	nvarchar	Идентификатор
ContextKey	nvarchar	Ключ контекста
Model	varbinary	Модель
ProductVersion	nvarchar	Версия продукта

Таблица 3.2. Поля таблицы AspNetUserRoles

Название поля	Тип	Описание
UserId	nvarchar	Идентификатор пользователя
RoleId	nvarchar	Идентификатор роли

Таблица 3.3. Поля таблицы AspNetRoles

Название поля	Тип	Описание
Id	nvarchar	Идентификатор роли
Name	nvarchar	Наименование роли

Таблица 3.4. Поля таблицы Users

Название поля	Тип	Описание
Id	nvarchar	Идентификатор
Email	nvarchar	Почтовый адрес
EmailConfirmed	bit	Совпадение почтовых адресов
PasswordHash	nvarchar	Хэш пароля
LockoutEndDateUtc	datetime	Время выхода
LockoutEnabled	bit	Выход из системы
AccessFailedCount	int	Количество неудачных входов
UserName	nvarchar	Имя пользователя

Таблица 3.5. Поля таблицы AspNetUserClaims

Название поля	Тип	Описание
Id	int	Идентификатор запроса пользователя
UserId	nvarchar	Идентификатор пользователя
ClaimType	nvarchar	Тип запроса
ClaimValue	nvarchar	Значение запроса



Таблица 3.6. Поля таблицы UserLogins

Название поля	Тип	Описание
LoginProvider	nvarchar	Логин провайдера
ProviderKey	nvarchar	Ключ провайдера
UserId	nvarchar	Идентификатор пользователя

Таблица 3.7. Поля таблицы ConfigutationItemsModels

Название поля	Тип	Описание
Id	int	Идентификатор КЕ
Name	nvarchar	Наименование КЕ

Таблица 3.8. Поля таблицы ConfigutationItemsLinks

Название поля	Тип	Описание
Id	int	Идентификатор связи
ConfigurationId	int	Идентификатор конфигурации
ConfigurationItemId	int	Идентификатор конфигурационной единицы

В общем случае модели данных разрабатываются таким образом, чтобы не зависеть от конкретной базы данных. Поэтому разработанную физическую модель данных можно применить к любой СУБД. В нашем случае это будет Miсrоsоft SQL Server 2014.

Таблица 3.9. Поля таблицы ConfigurationsModels

Название поля	Тип	Описание
Id	int	Идентификатор
Name	nvarchar	Наименование конфигурации
StatusId	int	Идентификатор статуса
Comment	nvarchar	Комментарий к конфигурации
InfoInstallFile	nvarchar	Файл со стратегией установки
InfoInstallUrl	nvarchar	Ссылка на стратегию установки
InfoTestFile	nvarchar	Файл с отчётом о тестировании
InfoTestUrl	nvarchar	Ссылка на отчёт о тестировании
InfoCreatingName	nvarchar	Имя образа
InfoCreatingDate	datetime	Дата создания образа
InfoCreating Comment	nvarchar	Комментарий к созданию образа
InfoTeachCount	nvarchar	Список учебных и рабочих мест для развёртывания
InfoTeachInstallDate	datetime	Дата развёртывания
InfoTeachComment	nvarchar	Комментарий к развёртыванию
InfoAuditCount	nvarchar	Список учебных и рабочих мест для аудита
InfoAuditInstallDate	datetime	Дата проведения аудита
InfoAuditComment	nvarchar	Комментарий к аудиту

Таблица 3.10. Поля таблицы ConfigurationStatusModels

Название поля	Тип	Описание
Id	int	Идентификатор статуса
Key	int	Ключ
Name	nvarchar	Наименование статуса

Таблица 3.11. Поля таблицы ConfigurationQueries

Название поля	Тип	Описание
Id	int	Идентификатор запроса
ConfigurationId	int	Идентификатор конфигурации
UserId	int	Идентификатор пользователя
Sign	nvarchar	Статус запроса

Таблица 3.12. Поля таблицы ConfigurationPlans

Название поля	Тип	Описание
Id	int	Идентификатор CM-плана
Link	nvarchar	Ссылка на CM-план



4. Реализация системы

4.1 Реализация пользовательских интерфейсов

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

Первая форма при входе в систему - это форма авторизации в системе. Авторизация происходит по логину и паролю. Информация о роли пользователя уже хранится в системе. Внешнее представление данной формы представлено на рис. 4.1.

Рисунок 4.1. Окно авторизации

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

Рисунок 4.2. Главное окно системы



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

Рисунок 4.3. Форма добавления конфигурации

При выборе в главном окне кнопки «Составы» осуществляется переход на библиотеку конфигурационных единиц (рис. 4.4).

Рисунок 4.4. Форма, отображающая конфигурационные единицы

Этот список можно пополнить новыми конфигурационными единицами, нажав соответствующую кнопку вверху страницы, после чего откроется новая форма (рис. 4.5).

Рисунок 4.5. Форма, отображающая конфигурационные единицы

Проекты конфигураций просматриваются по нажатию кнопки «Элементы состава». Список отображает нахождение конфигурационной единицы в составе конфигурации (рис. 4.6).

Рисунок 4.6. Форма проектов конфигураций

Кнопка «Создать» открывает новую форму и позволяет добавить одну конфигурационную единицу в состав любой из конфигураций (рис. 4.7).

Рисунок 4.7. Форма добавления конфигурационной единицы в проект



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

Рисунок 4.8. Форма запросов

Окно создания нового запроса выглядит следующим образом (рис. 4.9).

Рисунок 4.9. Форма создания запроса

При переходе по кнопке "Стратегия установки" появляется форма, изображённая на рисунке 4.10. Данная форма позволяет создать или изменить ссылку на стратегию установки.

Рисунок 4.10. Окно стратегии установки конфигурации



При переходе по кнопке "Отчёт о тестировании" появляется форма, изображённая на рисунке 4.11. Данная форма позволяет создать или изменить ссылку на отчёт о тестировании.

Рисунок 4.11. Окно отчёта о тестировании конфигурации

После заполнения форм «Стратегия установки» и «Отчёт о тестировании» в окне о конфигурации активируется кнопка "Отчёт о создании образа конфигурации". При переходе по этой кнопке появляется окно, представленное на рисунке 4.12.

Рисунок 4.12. Окно отчёта об создании образа конфигурации

После заполнения данной форму статус у конфигурации изменяется на "Изготовлено". В окне о конфигурации активируется кнопка "Отчёт о развёртывании". При переходе по данной кнопке появляется окно, представленное на рисунке 4.13.



Рисунок 4.13. Окно отчёта о развёртывании конфигурации

После заполнения данной форму статус у конфигурации изменяется на "Эксплуатируется". В окне о конфигурации активируется кнопка "Отчёт о проведении аудита". При переходе по кнопке "Отчёт о проведении аудита" появляется окно, представленное на рисунке 4.14.

Рисунок 4.14. Окно отчёта о проведении аудита конфигурации

После заполнения статус у конфигурации изменяется на "Выведено из эксплуатации".

Реализация компонентов

После этапа проектирования следует этап реализации и тестирования координатора бизнес-процессов. Инструментальными средствами выступили Visual Studio на языке высокого уровня С#. Возможности среды и языка очень велики, так что выбор инструментария можно считать эффективным.

Система выполнена с помощью ASP.NET MVC Framework - фреймворка для создания веб-приложений, который реализует шаблон Model-View-Controller.

Model-View-Controller (MVC, «Модель-Представление-Контроллер», «Модель-Вид-Контроллер») является схемой разделения данных приложения, пользовательского интерфейса и управляющей логики на три отдельных компонента: модель, представление и контроллер таким образом, что модификация каждого компонента может осуществляться независимо.

Модель (Model) предоставляет данные и реагирует на команды контроллера, изменяя своё состояние.

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