Сборка – пронумерованная отложенная версия установочного exe-файла, доступная на чтение разработчикам, специалистам по тестированию и специалистам по документированию
Дистрибутив – успешно прошедшая тестирование и документирование сборка, оформленная в виде пронумерованного установочного exe-файла с учетом исправленных файлов приложения на этапе тестирования, готовая к установке у заказчиков.
Разовое обновление – пронумерованное обновление, выполненное в виде автоматически устанавливаемой программы. Разовое обновление может быть установлено только на определенную версию дистрибутива, для которого предназначено. Каждое последующее разовое обновление к определенной версии дистрибутива включает в себя все изменения предыдущих разовых обновлений того же дистрибутива. Кроме того, разовое обновление включается в рабочую версию.
Порядок формирования дистрибутива
9.1. К началу каждого календарного месяца руководитель (либо заместитель руководителя) Центра разработки определяет перечень активных заявок, которые должны войти в новую версию дистрибутива. На основании данного списка составляется план работ Центра разработки на месяц.
9.2. В течение 2-х недель с момента утверждения состава новой версии дистрибутива производится разработка в соответствии с настоящим Регламентом. По окончании разработки выпускается новая сборка и сопутствующий ей перечень фактически проведенных изменений (выполненных заявок). Данной сборке присваивается номер.
9.3. В течение 2-х недель с момента выпуска новой сборки производится ее тестирование, доработка и документирование. Доработка производится в рамках фактически проведенных изменений на момент сборки (новый функционал не добавляется).
9.4. По окончании тестирования, доработки и документирования выпускается новый дистрибутив и перечень фактических изменений к нему. Из состава дистрибутива исключаются те заявки, доработка которых не была завершена к моменту его выпуска. Дистрибутиву присваивается номер.
9.5. С момента выпуска дистрибутива цикл разработки новых версий повторяется с п.9.1 настоящего Регламента.
9.6. Если в промежутке до выпуска очередной версии дистрибутива обнаруживается критическая ошибка либо срочно необходимая функциональность, разработка проводится по внутренней заявке в соответствии с настоящим Регламентом. После реализации должно быть выпущено разовое обновление к текущей версии дистрибутива для установки у заказчиков. Данное разовое обновление обязательно должно успешно пройти тестирование и документирование перед выпуском. Выпуск разовых обновлений приостанавливается за неделю до выхода очередного дистрибутива.
Приложение 4
1. Общие положения
1.1. Данный документ описывает порядок обработки информации о поступающих заявках на обслуживание и сопровождение.
1.2. Информационная поддержка указанных процессов осуществляется с использованием внутренней автоматизированной информационной системы (далее - система).
2. Основные участники регламента
2.1. Основными участниками данного регламента являются:
- ответственные руководители;
- специалист-диспетчер;
- разработчик;
- технический писатель;
- специалист по тестированию;
- специалист по внедрению и сопровождению;
- специалист технической поддержки.
3. Регламент регистрации заявок
3.1. Заявки по телефону обязан принимать специалист-диспетчер.
3.2. При поступлении звонка-заявки к любому другому сотруднику он обязан перенаправить звонок на специалиста-диспетчера, кроме случаев адресного обращения к сотрудникам сопровождения и технической поддержки.
3.3. При поступлении заявки по телефону либо электронной почте специалист-диспетчер обязан зарегистрировать заявку в системе, указав следующие сведения:
- способ поступления заявки (звонок, электронная почта, и пр.);
- организация и контактное лицо;
- содержание заявки;
- срочность Заказчика;
- на кого перенаправлена заявка.
3.4. Система автоматически фиксирует номер поступившей заявки и статус «постановка задачи».
3.5. После присвоения заявке номера диспетчер обязан сообщить этот номер источнику заявки, а также на основании ранее указанных сведений перенаправить звонок либо сообщение электронной почты соответствующему специалисту «горячей линии», также сообщив номер заявки. Заявка при этом переходит в статус «на горячей линии».
3.6. В случае адресного обращения к сотрудникам сопровождения и технической поддержки (в частности, по мобильному телефону) либо при поступлении заявки через журнал сотрудник должен обеспечить максимально оперативный ввод заявки в систему, заполнив следующие сведения:
- способ поступления заявки (звонок, электронная почта, и пр.);
- проект;
- реализация в рамках проекта (для заявок на сопровождение ПО);
- организация и контактное лицо;
- срочность Заказчика;
- содержание заявки;
- вид базы данных (SQL, ORACLE, SQL+ORACLE);
- шаги воспроизведения.
3.7. Заявка, введенная сотрудником сопровождения или технической поддержки, поступает на утверждение непосредственному руководителю сотрудника. Дальнейшая обработка заявки производится в соответствии с разделом 5 настоящего Регламента.
4. Регламент обеспечения «горячей линии»
4.1. Специалист «горячей линии» обязан выяснить у пользователя подробности заявки, в т.ч. последовательность действий, приводящую к возникновению проблемы, и заполнить в системе недостающие сведения.
4.2. Специалист «горячей линии» обязан попытаться определить причину и возможность оперативного устранения проблемы. При наличии такой возможности специалист «горячей линии» консультирует пользователя по телефону (либо по электронной почте) и фиксирует содержание консультации в системе по конкретной заявке.
4.3. В случае устранения проблемы специалист «горячей линии» обязан отметить в системе заявку как выполненную. Заявка при этом переходит в статус «выполнена горячей линией».
4.4. В случае если содержание заявки относится к задачам, реализованным на разных базах данных (SQL, ORACLE, SQL+ORACLE), то проблема устраняется для каждой из баз данных;
4.5. В случае невозможности устранения проблемы специалист «горячей линии» обязан сообщить пользователю о том, что его заявка принята к дальнейшей обработке, и перенаправить заявку руководителю соответствующего проекта, фиксируя момент и причины перенаправления в системе, указывая необходимость устранения для всех требуемых баз данных (SQL, ORACLE, SQL+ORACLE).
5. Регламент исполнения заявки в рамках сопровождения
5.1. Руководитель соответствующего проекта при поступлении заявки обязан определить степень сложности проблемы:
5.2. Руководитель либо заместитель руководителя ответственного подразделения Управления обязан:
5.2.1. рассмотреть заявку;
5.2.2. проанализировать наличие похожих задач в оперативном и перспективном планах работы подразделения;
5.2.3. в случае невозможности устранения проблемы сотрудником сопровождения перенаправить заявку в Центр разработки, указав в системе момент и причины перенаправления. Дальнейшая обработка заявки происходит в соответствии с Регламентом учета и выполнения заявок на разработку.
5.2.4. в случае возможности устранения проблемы сотрудником сопровождения включить заявку в перспективный либо оперативный план работы подразделения и назначить исполнителя, сроки устранения; заявка при этом переходит в статус «исполняется сопровождением».
5.3. Сотрудник сопровождения при поступлении заявки к исполнению обязан предпринять все необходимые меры для устранения в срок указанных в заявке проблем, а также обеспечить ввод в систему сведений о фактически проведенных работах по устранению указанных в заявке проблем для всех требуемых баз данных (SQL, ORACLE, SQL+ORACLE).
5.4. В случае устранения проблемы сотрудник сопровождения обязан отразить в системе завершение стадии исполнения заявки.
5.5. В случае невозможности устранения проблемы сотрудник сопровождения обязан перенаправить заявку руководителю соответствующего проекта, фиксируя момент и причины перенаправления в системе.
5.6. При завершении стадии исполнения руководитель проекта переводит заявку в статус тестирования и назначает специалиста, ответственного за тестирование.
6. Регламент тестирования
6.1. Специалист, ответственный за тестирование, изучает материалы заявки и вносит в систему «Методику тестирования», после чего проводит тестирование по написанной методике.
6.2. По завершении тестирования специалист, ответственный за тестирование, формирует и вносит в систему «Отчет о тестировании».
6.3. В случае успешного выполнения тестирования специалист, ответственный за тестирование, отмечает в системе завершение тестирования для всех требуемых баз данных (SQL, ORACLE, SQL+ORACLE). После этого заявка переходит в статус документирования.
6.4. В случае обнаружения ошибок в процессе тестирования специалист, ответственный за тестирование, возвращает заявку на доработку руководителю проекта.
7. Регламент документирования изменений
7.1. Руководитель (либо заместитель руководителя) подразделения, ответственного за документационное обеспечение, при поступлении заявки на документирование назначает ответственного специалиста по документированию.
7.2. Специалист по документированию на основании представленных материалов обновляет документацию, необходимую для документирования выполнения соответствующей заявки (руководство пользователя, руководство администратора и пр.) для всех требуемых баз данных (SQL, ORACLE, SQL+ORACLE).
7.3. После завершения документирования специалист по документированию отмечает в системе завершение документирования, и заявка в системе перенаправляется руководителю проекта.