Приложение №1 к Техническому заданию
Краткая процедура управления новыми требованиями
Цель управления требованиями – достижение в установленные сроки запланированных результатов проекта, систематическая обработка поступающих функциональных требований, контроль функциональных рамок.
Регистрация требований.
Новые требования поступают в единый реестр с ведением сквозной нумерации. Каждому требованию присваивается индивидуальный номер, и ведется параметр «статус».
Предварительный анализ требования.
Полученное требование анализирует консультант Подрядчика.
В случае необходимости консультант начинает анализ с уточнения требования:
Изменение формулировки требования в IT-терминах;
Уточнение у автора сути и особенностей требования;
Если требование повторяет уже зарегистрированное ранее другое требование, консультант фиксирует в комментариях № дублируемого требования;
Если предполагаемый результат нового требования можно получить в Системе другим способом, то консультант фиксирует этот способ;
Если же функционал, который хотелось добавить, будет противоречить уже существующим механизмам системы, то консультант описывает возможную коллизию.
В перечисленных случаях автор требования оповещается о результате анализа, после чего работа по требованию считается оконченной.
Выработка рекомендаций по требованию
Возможны следующие рекомендации:
рекомендовать расширить рамки и включить в разработку (типично для отрасли, критично для работы);
рекомендовать разработать силами IT-специалистов предприятия (эксклюзивно для отрасли, реализуется внешними обработками);
рекомендовать изменение БП, либо использование внешних систем (эксклюзивно для отрасли, не реализуется внешними обработками).
Согласование решения по требованию с Заказчиком;
Отработка решения по требованию
Если необходимо, то по утвержденным в разработку требованиям проводится актуализация документации: бизнес-процессы, ПР, СР, инструкции пользователей, сценарии тестирования.
Оповещение автора
Автору нового требования в течение суток предоставляется информация при изменении статуса по его требованию.
Автору на электронную почту отправляются оповещения в следующих случаях:
Требование зарегистрировано под номером__.
Требование не зарегистрировано с указанием причины. К примеру, если нет возможности для уточнения особенностей требования.
Требование отклонено по причинам__
Требование принято в разработку и запланировано в релизе №__. Плановая дата выхода релиза __
Функционал требования включен в релиз №__
Также автору предоставляется возможность уточнять статус переданных требований. Для этого он может прислать письмо с № требования на электронную почту. Допустимый срок ответа по запросу - сутки.
Закрытие требования.
Требование закрывается в случаях:
Если не удается собрать исчерпывающую информацию по требованию для его анализа и обработки. К примеру, автор требования недоступен (не отвечает на запросы в течение 3-х раб. дней, либо отказывается предоставлять информацию);
Если требование отклонено в рамках проекта по каким-либо причинам, описанным в данном документе;
Если реализация требования включена в релиз.
При закрытии требования обязательно высылается соответствующее оповещение автору.
Приложение №2 к Техническому заданию
требования к проведению обучения
«Разработка и внедрение типового решения унифицированной системы управления ресурсами предприятия базе «1С: Управление производственным предприятием 8» и управление персоналом в программе ЗУП» в ЗАО «Атомтехэкспорт»
Условные обозначения
В данном документе приведен список требовании для проведения обучения ключевых и конечных пользователей, а также график обучения в рамках проекта по внедрению 1С ERP: Росатом в 2012 г.
Требования к проведению обучения 1С ERP:Росатом
1.1. Состав слушателей для проведения курсов обучения.
Планируемое количество предприятий для проведения обучения – 1.
На основании анализа ролей и организационных структур предприятия руководитель рабочей группы на предприятии формирует списки ключевых и конечных пользователей в соответствии с заранее направленными требованиями. Предприятие предоставляет персонализированный список ключевых и конечных пользователей с разбивкой по направлениям обучения. Руководитель проекта утверждает списки пользователей.
В обучении от предприятия могут участвовать как ключевые, так и конечные пользователи системы, но при этом по каждому из направлений обучение должен пройти как минимум один ключевой пользователь системы.
Подрядчик предоставляет Заказчику итоговый график обучения, сформированный в соответствии с методикой и графиком проведения обучения.
1.2. Место, время и порядок проведения обучения.
Обучение проводится по фактическому месту нахождения Заказчика. Предполагается только очная форма обучения.
По результатам прохождения обучения каждый пользователь проходит тестирование/зачет. На основании зачета пользователям будут выданы логины и пароли к системе.
Необходимо предусмотреть дополнительное обучение для тех слушателей, которые не смогли по уважительной причине своевременно пройти курс обучения или требуют повторной сдачи тестирования/зачета.
После каждого учебного курса проводится оценка эффективности обучения (сбор обратной связи от слушателей курсов).
1.3. Персонал Исполнителя для проведения обучения
Обучение проводится силами Подрядчика, с возможным присутствием на обучении в качестве куратора представителя Заказчика.
Для проведения обучения Подрядчик должен использовать специалистов, чьи должностные обязанности непосредственно связаны с проведением обучения пользователей. Не допускается использование Подрядчиком в качестве лекторов разработчиков программного обеспечения, не имеющих опыта проведения обучения.
1.4. Материалы для обучения.
Методические материалы для проведения обучения предоставляются Подрядчиком (как разработка самих материалов, так и тиражирование раздаточного материала в объеме, соответствующем количеству слушателей).
Обучение проводится строго в рамках полной функциональности системы.
Допускается при проведении обучения использовать стандартные методические материалы в части функционала, изменение которого по результатам разработки технического задания не предполагается.
Для всех остальных направлений обучения должны быть разработаны специализированные методические материалы.
В методических материалах должен быть предусмотрен сквозной пример, иллюстрирующий весь функционал системы.
1.5. Методика проведения обучения.
Длительность обучения:
Длительность курса по направлению – от 1 до 6 дней (в соответствии со сложностью функционального блока системы).
Длительность дня обучения - 8 часов (5 часов лекция, 3 часа практика)
Длительность дня обучения для курса «БУ, НУ, МСФО» должна предусматривать два варианта
Полный – 6 дней по 8 часов (5 часов лекция, 3 часа практика)
Сокращенный – 15 дней по 4 часа (3 часа лекция, 1 час практика)
Весь курс обучения состоит из нескольких пакетов методических материалов по каждому функциональному направлению.
Состав пакета методических материалов для обучения по каждому направлению следующий:
Реестр обучающихся. Пустографка в формате MS Word с личными данными обучающегося и результатами тестирования. Заполняется лектором в процессе обучения. В обязательном порядке передается Заказчику совместно с результатами тестирования по завершении курса.
Регламент курса обучения. Документ в формате MS Word, который содержит временную разбивку по дням, часам и темам. Раздается обучающимся и используется лектором.
Презентация в формате MS PowerPoint (читается лектором с экрана проектора, в печатном виде (выдачи) раздается всем обучающимся для ведения записей)
Пакет практических занятий. Документ в формате MS Word, который содержит не очень сложные задачи по теме курса. Каждая задача решается с использованием учебного прототипа Системы, в котором фактически нужно заполнить те или иные справочники и документы, воспользоваться необходимыми обработками, сформировать отчеты.
Пакет ответов к практическим занятиям. Документ в формате MS Word, который содержит ответы к каждой задаче в виде скриншотов правильно оформленных в ИБ объектов метаданных.
Контрольные вопросы/задания по курсу. Документ в формате MS Word, который содержит набор контрольных вопросов. Распечатывается в виде опросника для заполнения каждым обучающимся. С помощью данного документа проводится итоговое тестирование пользователей. Документ с оценкой является дополнением к «Реестру обучающихся» и в обязательном порядке передается Заказчику.
Шаблон интеграционного теста. Документ в формате MS Word, который содержит, в общем виде, описание тестируемого бизнес-процесса. В процессе обучения ключевые пользователи уточняют содержание бизнес-процесса для проведения интеграционного тестирования по процессу2.
Приложение №1
к Тому 2 «Техническая часть»
|
