Регламент тестирования

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

6.2. По завершении тестирования специалист, ответственный за тестирование, формирует и вносит в систему «Отчет о тестировании» для всех требуемых баз данных (SQL, ORACLE, SQL+ORACLE).

6.3. В случае успешного выполнения тестирования специалист, ответственный за тестирование, отмечает в системе завершение тестирования. После этого заявка переходит в статус документирования.

6.4. В случае обнаружения ошибок в процессе тестирования специалист, ответственный за тестирование, возвращает заявку на доработку в Центр разработки.

Регламент документирования изменений

7.1. Руководитель (либо заместитель руководителя) подразделения, ответственного за документационное обеспечение, при поступлении заявки на документирование назначает ответственного специалиста по документированию.

7.2. Специалист по документированию на основании представленных материалов обновляет документацию, необходимую для выпуска соответствующего дистрибутива (руководство пользователя, руководство администратора, список изменений в дистрибутиве и пр.) для всех требуемых баз данных (SQL, ORACLE, SQL+ORACLE).

7.3. После завершения документирования специалист по документированию отмечает в системе завершение документирования, и заявка в системе перенаправляется руководителю проекта.

Регламент закрытия заявки

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

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

Регламент формирования дистрибутива

Определения

Рабочая версия – полный набор файлов приложения, предназначенных для включения в дистрибутив, доступный разработчикам на внесение изменений.

Сборка – пронумерованная отложенная версия установочного exe-файла, доступная на чтение разработчикам, специалистам по тестированию и специалистам по документированию

Дистрибутив – успешно прошедшая тестирование и документирование сборка, оформленная в виде пронумерованного установочного exe-файла с учетом исправленных файлов приложения на этапе тестирования, готовая к установке у заказчиков.

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

Порядок формирования дистрибутива

9.1. К началу каждого календарного месяца руководитель (либо заместитель руководителя) Центра разработки определяет перечень активных заявок, которые должны войти в новую версию дистрибутива. На основании данного списка составляется план работ Центра разработки на месяц.

9.2. В течение 2-х недель с момента утверждения состава новой версии дистрибутива производится разработка в соответствии с настоящим Регламентом. По окончании разработки выпускается новая сборка и сопутствующий ей перечень фактически проведенных изменений (выполненных заявок). Данной сборке присваивается номер.

9.3. В течение 2-х недель с момента выпуска новой сборки производится ее тестирование, доработка и документирование. Доработка производится в рамках фактически проведенных изменений на момент сборки (новый функционал не добавляется).

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

9.5. С момента выпуска дистрибутива цикл разработки новых версий повторяется с п.9.1 настоящего Регламента.

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

П риложение 4

Регламент исполнения заявок на обслуживание и сопровождение

Общие положения

1.1. Данный документ описывает порядок обработки информации о поступающих заявках на обслуживание и сопровождение.

1.2. Информационная поддержка указанных процессов осуществляется с использованием внутренней автоматизированной информационной системы (далее - система).