Вместо предисловия И еще раз доброго дня! Продолжаю серию заметок об основах управления конфигурацией программного обеспечения.
Чтобы долго не пересказывать краткое содержание двух предыдущих серий, предлагаю ссылки на них:
- Серия статей по основам управления конфигурацией программного обеспечения.
.О том, что такое CM, каковы его задачи и за что отвечает CM-инженер в рамках проекта.
- Управление конфигурацией программного обеспечения // Конфигурации и базовые показатели .
О том, что такое рабочий продукт с точки зрения SCM, что такое конфигурация, как она стабилизируется, а также что такое базовые конфигурации.
Мы посмотрим на этот класс задач и инструментов с более обобщенной точки зрения.
Отслеживание запросов на изменение
Для начала, как вообще происходят изменения на проекте? Есть всего несколько вариантов:- создается новый функционал продукта;
- изменение функциональности или внутренней структуры при плановых улучшениях (например, рефакторинге);
- найденные ошибки исправляются.
Однако чаще всего они отделены друг от друга – просто потому, что это действительно разные вещи.
Конечно, бывает, что нужно сделать рефакторинг, чтобы исправить ошибку, или написание функционала устраняет некоторые проблемы.
Но в этих случаях все сводится к тому, какой процесс работы над изменениями и какая терминология принята в рамках проекта.
Любой работающий продукт может измениться — это могут быть как исходники, так и требования, тесты — в общем все, что было перечислено в предыдущих материалах.
Важно, что все эти изменения и вносимые изменения необходимо контролировать.
В зависимости от типа и продукта изменения различается и источник его запроса.
В случае с новым функционалом это, скорее всего, будет кто-то из менеджеров или конечный пользователь.
При рефакторинге — технический руководитель или разработчик проекта.
При исправлении ошибки – любой пользователь системы, но, как правило, это тестер.
Итак, есть потребность в переменах, и есть кто-то, кто эту потребность озвучит. Остаётся только начать двигаться.
Начало движения — подача запроса на изменение.
Запрос на изменение — это предложение по улучшению продукта, выраженное в виде записи в системе отслеживания запросов на изменения.
В англоязычных источниках такие запросы называются запрос на изменение (CR) .
Также существует термин проблема или запрос на изменение (PCR) .
В дальнейшем мы будем использовать сокращение ЧР (читай «сэр») В свою очередь, система отслеживания запросов на изменение — программная среда, позволяющая фиксировать предложения по изменению продукта и управлять ответственностью за них.
Ключевые слова во всей цепочке терминов – отслеживание запросов, изменений и ответственности .
В русскоязычных источниках часто используется термин «система отслеживания ошибок» .
В англоязычной литературе есть система управления запросами на изменения, система отслеживания ошибок, система отслеживания проблем .
Как правило, хранилищем в таких системах является база данных, где одна CR — это одна запись (чаще связанный набор записей) в ней.
CR после учреждения имеет следующую обязательную информацию:
- кто начал запись (заявитель);
- краткое название статьи (тема);
- версия модифицируемой системы;
- подробное описание запроса или проблемы.
- описание ожидаемого поведения системы (на случай ошибок);
- настройка программного и аппаратного обеспечения;
- фрагменты журнала работы системы («логи»).
Как правило, проектирование систем слежения можно свести к двум моделям:
- конечный автомат (конечный автомат или конечный автомат), где каждое состояние характеризуется собственным набором полей;
- запись, в которой содержимое существующих полей изменяется по ходу работы и к которой добавляются комментарии.
Самая большая разница во внутренней структуре.
Внешне оно выражается лишь в том, можно ли добавлять новую структурированную информацию по ходу работы над CR. Но, независимо от типа системы, работа над записями протекает в целом одинаково.
Ведь главное организация Процесс разработки, а инструменты являются следствием его выбора и оптимизации.
Давайте рассмотрим типичный сценарий.
Регистрация произведена, нужно приступать к работе.
Однако никакие изменения не должны производиться бесконтрольно.
Поэтому перед началом работы необходимо получить одобрение руководства, отвечающего за функционал, затрагиваемый запросом на изменение.
Роль управления выполняет Плата управления конфигурацией (группа управления конфигурацией) – группа, имеющая права внутри проекта управлять изменениями внутри проекта.
Этот термин также иногда используется Совет по контролю изменений и сокращение ЦКБ .
Простой скрипт
Для дальнейшей работы возьмем систему отслеживания в виде конечного автомата — так будет понятнее.Набор состояний на диаграмме 1 — минимально необходимый; его можно расширить до большего размера и разделить на несколько шаблонов жизненного цикла.
Этот набор мы возьмем для дальнейшего описания.
Диаграмма 1. Жизненный цикл запроса на изменение
Первое состояние, в которое входит любая запись, является начальным состоянием.
На прилагаемой схеме это Новый .
На этом этапе создатель записи вводит все исходные данные, необходимые для процесса разработки проекта.
Далее, CR попадает в поле зрения CCB. Он решает, какому разработчику поручить решение проблемы.
Для того, чтобы заставить CR работать, запись переводится в следующее состояние - Назначенный («назначается ответственному лицу»).
При этом запись «прикрепляется» к разработчику – т.е.
он становится за нее ответственным.
Однако поручение кому-то задачи не означает, что проблема сразу же начнет решаться.
Ведь на одного разработчика может быть возложено несколько задач — одна важнее другой и все нужно сделать еще вчера.
Поэтому когда разработчик реально приступает к работе над задачей, он переводит запись в состояние Открыто («работа началась») ЦКБ, контролирующий работу, видит, что задание выполнено.
Сама задача, как правило, остается «закрепленной» за разработчиком.
По ходу работы ответственные могут меняться в зависимости от того, кому принадлежит код, влияющий на поведение, описанное в CR. Переназначения производятся CCB. Кроме того, может оказаться, что кто-то уже нашел проблему и создал для нее свой CR. В этом случае проблема дублированный , т.е.
закрывается и в соответствующее поле добавляется номер записи, которая была создана ранее.
С этого момента запись считается закрытой.
Также может оказаться, что описанная проблема не является багом (т.е.
это WAD, работает как задумано) или что запрошенный функционал не может быть реализован по разным причинам.
В этом случае запись прекращено , т.е.
завершается комментариями о том, почему работа над проблемой не будет продолжена.
Если работа будет продолжаться, то рано или поздно она закончится — разработчик внес необходимые изменения и готов отправить их на дальнейшую интеграцию.
На этом этапе он перемещает запись в состояние Решено («исправлено» или «решение найдено»).
Этим шагом человек, которому поручено решение, снимает с себя ответственность и показывает те изменения, которые, по его мнению, должны решить проблему.
В этом состоянии ЦКБ должен снова назначить ответственное лицо.
Он проверит, что задача, поставленная в CR, действительно решена правильно и все работает как минимум не хуже, чем было до ее решения.
Поэтому на этом этапе ответственным назначается либо один из тестировщиков, либо сам автор записи.
После назначения инспектор ( "проверяющий" , «верификатор»), которым часто является автор запроса, начинает проверку.
В результате получается 2 исхода:
- перевод в исходное состояние, если проблема не решена;
- передача в штат Закрыто («закрыто»), если ошибка исправлена или новый функционал, описанный в запросе, работает.
За это отвечает инженер управления проектом, для него в системе создается отдельная запись.
О реализации и тонкой настройке
Кстати, стоит добавить, что системы отслеживания запросов на изменения также используются в качестве систем отслеживания назначений и задач на проекте.Ведь любая задача, возникающая на проекте, требует контроля со стороны руководства.
И результатом большинства задач опять же являются какие-то изменения.
Поэтому логично использовать одну систему для всех целей.
Иногда системы отслеживания задач также называют общим термином справочная служба .
Однако смысл от этого не меняется — я также отношу их к системам отслеживания запросов на изменения.
Если предлагаемый жизненный цикл по каким-то причинам не подходит, большинство систем отслеживания позволяют модифицировать этот цикл и создать несколько его типов — столько, сколько необходимо для решения повседневных задач.
Кстати, именно поэтому часто создаются отдельные шаблоны для отслеживания разработки нового функционала и отслеживания процесса исправления ошибок.
Просто потому, что при разработке нового функционала также необходимо разрабатывать требования, дизайн, тесты — и для этого вводятся промежуточные состояния или поля для перечисленных целей.
Мое мнение, что необходимо выбирать системы, позволяющие гибко настраивать цикл работы.
Хотя бы для того, чтобы когда-то неизвестно кем заложенная схема работы не стала догмой для вашего проекта.
Со временем выйти за его рамки становится сложно из-за ограниченности инструментов и проект начинает становиться «тесным».
Поэтому гибкая настройка — наш выбор! Внедрение систем отслеживания запросов на изменения — пожалуй, любимое занятие программистов всего мира.
Некоторые полагают, что его система непременно затмит все существующие.
Некоторые люди уверены, что другим не хватает чего-то из того, что им нужно.
А некоторые люди делают это просто ради собственного удовольствия.
Каждому свое.
Если кто-то не хочет изобретать свое двухколесное транспортное средство, может ознакомиться с существующий велосипедный парк .
Что ж, выбирайте велосипед, который лучше всего подходит для своей задачи.
Кстати, автор имел возможность принять какое-то участие в разработке упомянутого в списке.
eTraxis .
Я бы порекомендовал его при этой возможности.
А как насчет инженеров CM?
Мы научились отслеживать запросы на изменения.Какова роль инженеров проекта CM? Они несут ответственность за:
- внедрение систем отслеживания в процессе разработки;
- разработка политики использования этих систем;
- контроль соблюдения установленных правил.
У меня есть пара советов на этот случай, соответствующий материал даже написан.
впрочем, он будет опубликован чуть позже, следите за обновлениями :)
Ссылки для расширения вашего кругозора
- http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems — сравнение систем регистрации запросов на изменения.
- http://www.etraxis.org/ — система отслеживания запросов, в создании которой автор принимал активное участие.
- Также смотрите ссылки в предыдущих статьях, ссылки на них присутствуют в начале заметки.
Кстати, отслеживание запросов на изменения снова будет затронуто — без этого не обойтись.
Итак, продолжение следует. Теги: #программное обеспечение #Конфигурация #управление #cm #Конфигурация #отслеживание #изменения #отслеживание ошибок #отслеживание ошибок #отслеживание проблем #служба поддержки #служба поддержки #служба поддержки #etraxis #Управление проектами
-
Возрождение Старых Компьютерных Игр
19 Oct, 24 -
Может Ли Кто-Нибудь Объяснить Это?
19 Oct, 24 -
Gdc Europe И Gamescom – Что Полезнее?
19 Oct, 24
