| Всего |
8 |
9 |
3 |
2 |
5 |
1.Амблер С. Гибкие технологии: экстремальное программирование и унифицированный процесс разработки. Библиотека программиста. СПб.: Питер, 2005.
2.Бек К. Экстремальное программирование. СПб.: Питер, 2002.
3.Браудэ Э. Технология разработки программного обеспечения. СПб.: Питер, 2004.
4.Даешь инжиниринг! М.: Издательство Эксмо, 2005.
5.Константайн Л., Локвуд Л. Разработка программного обеспечения. СПб.: Питер, 2004.
6.Крачтен, Филипп. Введение в Rational Unified Process. 2-е изд. М.: Издательский дом «Вильямс», 2002.
7.Кролл П., Крачтен Ф. Rational Unified Process – это легко. Руководство по RUP. М.: КУДИЦ-ОБРАЗ, 2004.
8.Липунцов Ю.П. Управление процессами. Методы управления предприятием с использованием информационных технологий. М.: Компания АйТи, 2003.
9.Хэлдман Ким. Управление проектами. М.: ДМК Пресс; Академия АйТи, 2007.
П
риложение 1
Образцы внутренних документов
Данный документ является уточняющим для документа «Техническое задание», составляется по каждой значимой функциональности и содержит более подробные описания бизнес-процессов, в т.ч. в нотации UML.
1. Основные сведения
- Название проекта, модуль
- Название функциональности
- Основания для разработки (контракт, пользователь, законодательство, и пр.)
- Необходимость распространения на другие проекты
2. Описание назначения
- Описание функциональности, ссылки на законодательство и пр.
3. Варианты использования
a. Название варианта использования, текстовое описание, UML-схема
b. Название варианта использования, текстовое описание, UML-схема
c. …
4. Диаграммы потоков данных
при необходимости
5. Диаграммы переходов состояний
при необходимости
6. Диаграммы классов
при необходимости
7. Проект пользовательского интерфейса
8. Ограничения
требования к аппаратному обеспечению, производительности и пр.
1. Основные сведения
- Номер заявки (из внутренней системы)
- Название проекта, модуль
- Основания для разработки
2. Описание заявки
- Текстовое описание содержания заявки, при необходимости – ссылки на скриншоты (для ошибок – обязательно)
3. Скриншоты
- копии экранов с выделенными и пронумерованными блоками (для ссылок в текстовом описании)
1. Основные сведения
- Номер заявки (из внутренней системы)
- Название проекта, модуль
- Название функциональности
2. Тестовые примеры
a. Тест 1
o Входные параметры: «название» = «значение»
o Последовательность действий пользователя
o Выходные параметры: «название» = «значение»
b. Тест 2
o Входные параметры: «название» = «значение»
o Последовательность действий пользователя
o Выходные параметры: «название» = «значение»
c. …
1. Основные сведения
- Номер заявки (из внутренней системы) – в случае выполнения разовой заявки
- Название проекта, модуль
- Название функциональности
2. Описание алгоритма
- Общее описание выбранных методов решения задачи
3. Реализация вариантов использования (если были указаны в «Постановке задачи»)
a. Название варианта использования, алгоритм реализации
b. …
4. Описание системных изменений
a. перечень измененных системных объектов (процедур, функций, модулей и пр.), при этом в коде указанных объектов обязательны следующие комментарии:
o дата создания, автор, назначение;
o все входные и выходные параметры, а также используемые внутри переменные должны иметь описание назначения;
o код должен быть разбит на логические блоки (при их наличии), снабженные комментариями об их назначении;
o при каждом изменении в начале после описания назначения должен вставляться комментарий с датой, автором и описанием изменения.
b. видимо, в основном для ИИС – перечень измененных классов, гридов, и пр.
5. Описание интерфейсных изменений
при изменении форм – скриншоты «что было» - «что стало» с выделением изменений
при добавлении форм – скриншоты этих форм
6. Диаграммы классов
при необходимости, видимо, в основном для ИИС
Документ «Краткое руководство» составляется в свободном стиле, при этом он должен отражать описание всех вариантов использования, реализованных для требования.
Данный документ составляется на основании «Программы и методики испытаний» либо «Тестового примера».
1. Основные сведения
- Номер заявки (из внутренней системы) – в случае выполнения разовой заявки
- Название проекта, модуль
- Название функциональности
- Дата тестирования, номер цикла тестирования
- Суммарные данные (% успешно пройденных тестов)
2. Тест 1: пройден/не пройден
- Должно быть:
o Входные параметры: «название» = «значение»
o Последовательность действий пользователя
o Выходные параметры: «название» = «значение»
- Получено:
o Выходные параметры: «название» = «значение»
- Комментарии
3. Тест 2: пройден/не пройден
- …
4. …
«Ведомость замечаний» составляется в двух случаях:
1. При проведении внутреннего тестирования на основании «Отчета о тестировании» составляется перечень замечаний, в который включаются все не пройденные тесты, а также дополнительно обнаруженные в ходе тестирования ошибки.
2. При внедрении и сопровождении системы.
Структура документа является следующей:
1. Основные сведения
- Название проекта
- Дата составления, последовательный номер, автор
- Ссылка на «Отчет о тестировании» либо период внедрения/сопровождения, за который получены указанные замечания
2. Таблица замечаний
| № п/п |
Замечание |
Комментарии |
| формулировка замечания |
дополнительная информация, ссылка на скриншоты |
3. Скриншоты
- копии экранов с выделенными и пронумерованными блоками (для ссылок в комментариях)
1. Основные сведения
- Номер заявки (из внутренней системы) – в случае выполнения разовой заявки
- Название проекта, модуль
- Название функциональности
- Дата составления, последовательный номер
2. Таблица замечаний
| № п/п |
Замечание |
Дата устранения |
Комментарии |
| формулировка замечания |
1. Основные сведения
- Номер обновления/дистрибутива (из внутренней системы)
- Название организации
- Дата установки, ФИО сотрудника, проводившего установку
- При установке у пользователя – ФИО пользователя, должность, комната, телефон
2. Сведения об ошибках в ходе установки
- допустимо использование скриншотов
1. Основные сведения
- Название организации, проекта
- ФИО сотрудника, проводившего обучение
2. Ведомость обучения
| № п/п |
ФИО, должность пользователя |
Дата обучения |
Изученные разделы |
Подпись пользователя |
П
риложение 2
Регламент оперативного мониторинга и информационной поддержки хода исполнения контрактных обязательств
1.
Общие положения
1.1. Данный документ описывает порядок сбора, обработки и хранения информации о контрактных обязательствах, а также регламент оперативного мониторинга хода исполнения контрактных обязательств ответственными исполнителями и руководителями.
1.2. Информационная поддержка указанных процессов осуществляется с использованием внутренней автоматизированной информационной системы (далее - система).
2.
Ответственность и состав информации
2.1. Бухгалтерия организации является ответственной за ввод следующих данных:
- адресные данные юридических лиц;
- банковские реквизиты юридических лиц;
- сведения о подготовке счетов, счетов-фактур;
- сведения о поступлении оплаты по счетам.
2.2. Помощник генерального директора является ответственным за ввод следующих сведений:
- проекты контрактов и этапы в составе данных контрактов;
- сведения о порядке и сроках оплаты этапов контрактов;
- документы к контракту;
- сведения об отправке и получении отчетных документов по этапам работ.
2.3. Руководитель департамента/управления (либо заместитель руководителя) является ответственным за ввод следующих сведений:
- содержание работ по этапам контрактов (для последующего планирования работ начальником отдела).
2.4. Начальник отдела является ответственным за:
- планирование работ по этапам контрактов;
- контроль хода исполнения этапов;
- формирование отчета о ходе исполнения контрактных обязательств.
3.
Регламент учета данных
3.1. Начальник отдела (либо по его распоряжению – заместитель начальника отдела) обязан за 15 дней (если не указано иное) до окончания срока этапа обеспечить подготовку отчет о ходе исполнения этапа с перечислением всех работ, проводившихся в рамках данного этапа.
3.2. Помощник генерального директора обязан за 15 дней (если не указано иное) до окончания срока этапа подготовить акт по данному этапу контракта.
3.3. Бухгалтер обязан за 15 дней (если не указано иное) до окончания срока этапа подготовить счет на оплату работ по данному этапу контракта.
3.4. Отчет, акт и счет на оплату работ прикрепляются к исходящему письму, регистрируются делопроизводителем и отправляются заказчику. В системе при этом автоматически отражаются сведения о сроках отправки документов.
3.5. При возврате документов делопроизводитель отмечает срок подписания и возврата документов.
3.6. При поступлении оплаты бухгалтерия отмечает срок поступления оплаты. В системе автоматически отражаются сведения о закрытии соответствующего этапа.
4.
Регламент оперативного мониторинга
4.1. Ежедневно заместитель руководителя департамента и начальник отдела (либо по его распоряжению – заместитель начальника отдела) контролирует перечень активных задач по контрактным обязательствам и обеспечивает их оперативное выполнение.
4.2. Еженедельно заместитель руководителя департамента и начальник отдела (либо по его распоряжению – заместитель начальника отдела) контролирует перечень этапов, по которым наступили сроки подготовки отчета о выполненных работах и при необходимости готовит либо дает поручение о подготовке указанных отчетов.
4.3. Еженедельно заместитель руководителя департамента, помощник генерального директора и бухгалтер контролирует перечень этапов, по которым наступили сроки подготовки акта и счета на оплату работ. При наступлении сроков подготовки документов:
4.3.1. Помощник генерального директора готовит акт о выполненных работах;
4.3.2. Начальник отдела (либо по его указанию – заместитель начальника отдела), ответственного за выполнение данных работ, готовит отчет о проделанных работах;
4.3.3. Бухгалтер готовит счет на оплату работ.
4.4. После отправки документов помощник генерального директора еженедельно контролирует сроки подписания и возврата документов.
4.5. После возврата документов бухгалтер ежедневно контролирует поступление оплаты по подписанным счетам.
П
риложение 3
Регламент разработки программного обеспечения и выпуска дистрибутивов
1.
Общие положения
1.1. Данный документ описывает внутренний порядок разработки программного обеспечения и выпуска дистрибутивов для установки у заказчиков.
1.2. Информационная поддержка указанных процессов осуществляется с использованием внутренней автоматизированной информационной системы (далее - система).
2.
Основные участники регламента
2.1. Основными участниками данного регламента являются:
- руководитель проекта;
- ответственные руководители структурных подразделений;
- аналитик;
- разработчик;
- специалист по тестированию;
- технический писатель.
3.
Регламент регистрации заявки
3.1. Руководитель проекта обязан обеспечить регистрацию в системе всех заявок на разработку по соответствующим проектам.
3.2. При регистрации заявки руководитель проекта обязан обеспечить ввод следующих сведений:
- проект;
- реализация в рамках проекта;
- организация;
- в рамках какого этапа контракта выполняется работа;
- содержание работы;
- плановые сроки выполнения работы;
- срочность Заказчика;
- приоритет работы;
- вид базы данных (SQL, ORACLE, SQL+ORACLE);
- приложить постановку задачи и все возможные документы, связанные с постановкой задачи.
3.3. При сохранении заявки система должна обеспечить автоматическое присвоение номера заявки.
3.4. Руководитель проекта также должен иметь возможность классификации ранее введенной в систему заявки на обслуживание в качестве заявки на разработку. При этом должны быть заполнены поля, указанные в п.3.2 настоящего Регламента, а также следующие поля:
- пример базы данных;
- шаги воспроизведения.
3.5. Для инициирования процесса обработки заявки руководитель проекта должен:
- перевести задачу на исполнение аналитикам;
- при отсутствии необходимости проведения анализа (например, в случае обнаружения очевидных ошибок разработчика) перевести задачу на исполнение разработчикам.
4.
Регламент анализа постановки задачи
4.1. Руководитель (либо заместитель руководителя) соответствующего подразделения (Управление системных проектов) при поступлении заявки обязан:
4.1.1. проанализировать наличие похожих задач в оперативном и перспективном планах работы подразделения;
4.1.2. включить заявку в перспективный либо оперативный план работы подразделения и назначить исполнителя, сроки устранения.
4.2. Исполнитель (аналитик) проводит работы по систематизации документов, относящихся к постановке задачи и приложенных руководителем проекта.
4.3. Результатом работы аналитика должен быть документ «Постановка задачи», отражающий полное и всестороннее описание работ, указанных в заявке. Данный документ должен использоваться для проведения разработки, тестирования и документирования и является основополагающим.
4.4. Для инициирования процесса разработки аналитик должен отразить в системе завершение стадии постановки задачи. После этого действия заявка переходит в Центр Разработки.
4.5. В случае невозможности разработки «Постановки задачи» аналитик обязан перенаправить заявку руководителю проекта, фиксируя момент и причины перенаправления в системе.
5.
Регламент исполнения заявки Центром разработки
5.1. Руководитель (либо заместитель руководителя) Центра разработки при поступлении заявки обязан определить ответственное подразделение в составе Центра разработки и передать заявку соответствующему руководителю, зафиксировав момент передачи в системе.
5.2. Руководитель (либо заместитель руководителя) ответственного подразделения Центра разработки обязан:
5.2.1. проанализировать наличие похожих задач в оперативном и перспективном планах работы подразделения;
5.2.2. определить область действия заявки (проекты, в которых реализована указанная функциональность, либо все проекты);
5.2.3. включить заявку в перспективный либо оперативный план работы подразделения и назначить исполнителя, сроки устранения.
5.3. Сотрудник Центра разработки при поступлении заявки к исполнению обязан:
5.3.1. предпринять все необходимые меры для устранения в срок указанных в «Постановке задачи» проблем для всех требуемых баз данных (SQL, ORACLE, SQL+ORACLE);
5.3.2. обеспечить ввод в систему сведений о фактически проведенных работах по устранению указанных в «Постановке задачи» проблем.
5.4. В случае устранения проблемы сотрудник Центра разработки обязан:
5.4.1. отметить в системе дистрибутив, в состав которого войдет выполненная заявка для всех требуемых баз данных (SQL, ORACLE, SQL+ORACLE);
5.4.2. приложить «Список измененных модулей», в котором явно отразить участки, подлежащие тестированию для всех требуемых баз данных (SQL, ORACLE, SQL+ORACLE)
5.4.3. при необходимости ввести уточняющие «Постановку задачи» сведения по порядку документирования выполненной заявки;
5.4.4. отразить в системе завершение стадии разработки задачи.
5.5. В случае невозможности разработки сотрудник Центра разработки обязан перенаправить заявку руководителю своего структурного подразделения, фиксируя момент и причины перенаправления в системе.
5.6. При завершении стадии разработки руководитель (либо заместитель руководителя) Центра разработки переводит заявку в статус тестирования и назначает специалиста, ответственного за тестирование.
6.
Регламент тестирования
6.1. Специалист, ответственный за тестирование, изучает «Постановку задачи», «Список измененных модулей», разрабатывает и вносит в систему «Методику тестирования», после чего проводит тестирование по написанной методике.
6.2. По завершении тестирования специалист, ответственный за тестирование, формирует и вносит в систему «Отчет о тестировании» для всех требуемых баз данных (SQL, ORACLE, SQL+ORACLE).
6.3. В случае успешного выполнения тестирования специалист, ответственный за тестирование, отмечает в системе завершение тестирования. После этого заявка переходит в статус документирования.
6.4. В случае обнаружения ошибок в процессе тестирования специалист, ответственный за тестирование, возвращает заявку на доработку в Центр разработки.
7.
Регламент документирования изменений
7.1. Руководитель (либо заместитель руководителя) подразделения, ответственного за документационное обеспечение, при поступлении заявки на документирование назначает ответственного специалиста по документированию.
7.2. Специалист по документированию на основании представленных материалов обновляет документацию, необходимую для выпуска соответствующего дистрибутива (руководство пользователя, руководство администратора, список изменений в дистрибутиве и пр.) для всех требуемых баз данных (SQL, ORACLE, SQL+ORACLE).
7.3. После завершения документирования специалист по документированию отмечает в системе завершение документирования, и заявка в системе перенаправляется руководителю проекта.
8.
Регламент закрытия заявки
8.1. В случае отсутствия замечаний руководитель проекта подтверждает ее выполнение, и заявка переходит в архив.
8.2. В случае наличия замечаний руководитель проекта вносит в систему сведения о необходимых доработках. С этого момента заявка считается вновь принятой в систему.
9.
Регламент формирования дистрибутива
Определения
Рабочая версия
– полный набор файлов приложения, предназначенных для включения в дистрибутив, доступный разработчикам на внесение изменений.
Сборка
– пронумерованная отложенная версия установочного 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. После завершения документирования специалист по документированию отмечает в системе завершение документирования, и заявка в системе перенаправляется руководителю проекта.
8.
Регламент закрытия заявки или возврата на доработку
8.1. В случае отсутствия замечаний руководитель проекта подтверждает ее выполнение, и заявка переходит в архив.
8.2. В случае наличия замечаний руководитель проекта вносит в систему сведения о необходимых доработках. С этого момента заявка считается вновь принятой в систему.
9.
Регламент исполнения заявки в рамках технической поддержки
9.1. Заместитель руководителя Управления системной интеграции при поступлении заявки обязан определить ответственное подразделение в составе Управления и передать заявку соответствующему руководителю, зафиксировав момент передачи в системе.
9.2. Руководитель либо заместитель руководителя ответственного подразделения Управления обязан:
9.2.1. рассмотреть заявку;
9.2.2. проанализировать наличие похожих задач в оперативном и перспективном планах работы подразделения;
9.2.3. включить заявку в перспективный либо оперативный план работы подразделения и назначить исполнителя, сроки устранения; заявка при этом переходит в статус «исполняется технической поддержкой».
9.3. Сотрудник Управления при поступлении заявки к исполнению обязан предпринять все необходимые меры для устранения в срок указанных в заявке проблем, а также обеспечить ввод в систему сведений о фактически проведенных работах по устранению указанных в заявке проблем.
9.4. В случае устранения проблемы сотрудник Управления обязан отметить в системе заявку как выполненную.
9.5. В случае невозможности устранения проблемы сотрудник Управления обязан перенаправить заявку руководителю своего структурного подразделения, фиксируя момент и причины перенаправления в системе.
Приложение 5
Типовая должностная инструкция специалиста-стажера Управления разработки прикладных систем
1.
Общие положения
1.1. Специалист-стажер Управления разработки прикладных систем (далее – специалист-стажер) относится к категории рядовых сотрудников организации.
1.2. Настоящая должностная инструкция составлена на основании действующего законодательства Российской Федерации, Устава организации, Правил внутреннего трудового распорядка организации, Положения об Управлении разработки прикладных систем (далее - Управление).
1.3. Специалист-стажер назначается на должность или увольняется Генеральным директором по представлению начальника Управления и по согласованию с руководителем Центра разработки.
1.4. Специалист-стажер подчиняется непосредственно начальнику Управления.
2.
Квалификационные требования
2.1. Специалист-стажер должен иметь высшее либо незаконченное высшее профессиональное образование.
2.2. Специалист-стажер должен обладать знанием принципов построения реляционных баз данных.
3.
Должностные обязанности
3.1. В соответствии с основными функциями Департамента и отдела специалист-стажер исполняет следующие должностные обязанности:
3.1.1. Организация и реализация технологического процесса:
- Разработка пользовательских форм представления информации;
- Разработка экранных отчётов и выходных форм;
- Подготовка предварительных материалов для эксплуатационной документации;
- Модульное тестирование;
- Интегральное тестирование;
- Регрессионное тестирование;
- Системное тестирование;
- Тестирование удобства и простоты пользования;
- Формирование отчёта о проведении тестирования.
3.1.2. Исполнение административных функций:
- Периодическое ознакомление с обучающими материалами;
- Периодическое прохождение тестирования и аттестации.
3.2. В своей деятельности специалист-стажер обязан:
- неукоснительно выполнять и применять в практической работе нормативно-правовые акты и документы в сфере своей деятельности;
- соблюдать правила внутреннего трудового распорядка;
- поддерживать уровень квалификации, достаточный для исполнения своих должностных обязанностей;
- хранить государственную и иную охраняемую законом тайну.
4.
Должностные полномочия
4.1. Специалист-стажер имеет право на:
- получение в установленном порядке информации, документов, материалов, необходимых для исполнения функциональных обязанностей;
- использование в служебных целях имеющихся в отделе компьютерных и иных технических средств;
- визирование служебной документации в пределах своей компетенции;
- другие права, предусмотренные Трудовым кодексом Российской Федерации.
5.
Ответственность
5.1. Специалист-стажер несет дисциплинарную ответственность за качественное и своевременное выполнение работ, предусмотренных в его должностных обязанностях.
5.2. Специалист-стажер несет материальную ответственность за переданные ему компьютерные и иные технические средства в порядке, установленном Трудовым кодексом Российской Федерации.
П
риложение 6
Таблица. Типовые квалификационные требования к сотрудникам Управления разработки прикладных систем
| Квалификационные требования |
начальник отдела |
заместитель начальника отдела |
специалист-эксперт |
ведущий специалист |
специалист |
специалист-стажер |
| Требования к образованию |
| незаконченное высшее профессиональное образование (студент) |
+ |
+ |
| высшее профессиональное образование |
+ |
+ |
+ |
+ |
| Требования к стажу работы |
| требования не предъявляются |
+ |
| до 1 года |
+ |
| от 1 года до 2 лет |
+ |
| от 2 лет до 3 лет |
+ |
| не менее 3 лет |
+ |
+ |
| опыт руководящей работы |
+ |
| Специализированные требования |
| знание принципов построения реляционных баз данных |
+ |
+ |
+ |
+ |
+ |
+ |
| знание Transact-SQL и(или) PL-SQL |
+ |
+ |
+ |
+ |
| знание VBA |
+ |
+ |
| знание HTML, ASP (в зависимости от специализации) |
+ |
+ |
| знание принципов объектно-ориентированного проектирования информационных систем |
+ |
+ |
+ |
+ |
| знание нотации UML |
+ |
+ |
+ |
+ |
| знание менеджмента и управленческой деятельности |
+ |
+ |
| знание методов управления персоналом |
+ |
+ |
| Требования к знанию внутренних продуктов |
| знание прикладного программного обеспечения "Пользователь" ИИС: |
| знание архитектуры и принципов функционирования ПО "Пользователь" ИИС |
+ |
+ |
+ |
+ |
| знание процедуры установки прикладного ПО ИИС |
+ |
+ |
+ |
| знание элементов интерфейса ПО "Пользователь" ИИС |
+ |
+ |
+ |
| знание возможностей индивидуальной настройки ПО "Пользователь" ИИС |
+ |
+ |
+ |
| знание прикладного программного обеспечения "Администратор" ИИС: |
| знание архитектуры и принципов функционирования ПО "Администратор" ИИС |
+ |
+ |
+ |
+ |
| знание методов построения классов и отношений |
+ |
+ |
+ |
| знание принципов использования аналитик и фильтров |
+ |
+ |
+ |
| знание конструктора форм |
+ |
+ |
+ |
| знание конструктора отчетов |
+ |
+ |
+ |
| знание способов настройки конфигураторов поиска |
+ |
+ |
+ |
содержание ..
620
621
622 ..
|
|