www.sinera.ru
		<Сисадмин>
Поддержка
Инциденты	♣ 1я линия: <Оператор ТП>	♣ 1я линия: <Сисадмин>
	♣ 2я линия: <Архитектор>
	♣ 3я линия: <Разработчики>
Система	♣ Поддержка среды: <Инженер	♣ Администрирование:
	ТП>	<Сисадмин>
		♣ Установка обновлений
		<Сисадмин>
Документационное обеспечение
Протоколы встреч	♣ Подготовка: <Администратор>	♣ Согласование: <РП>
	♣ Согласование: <РП>
	♣ Контроль исполнения:
	<Администратор>
Дело проекта	♣ Создание: <Администратор>
	♣ Ведение: <Администратор>
	♣ Контроль архива:
	<Администратор>
Отчет РП	♣ Подготовка: <РП>	Согласование: <РП>

3.4Уровни управления и координации

3.4.1Стратегия управления проектом

Управление проектом разделяется на два уровня:

1.Уровень стратегического управления – уровень определения стратегии планирования проектной программы, координации проектных планов, принятия решений по ресурсам. Уровень стратегического управления реализуется Координационным комитетом.

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

3.4.2Координационный комитет Функции Координационного комитета

1.Принятие стратегических решений, влияющих на способы планирования проекта

2.Выделение необходимых ресурсов проекта

3.Проведение необходимых организационных изменений в соответствии с внешними требованиями

4.Решение проблем, требующих повышенного уровня эскалации

5.Утверждение и контроль документов, подлежащих утверждению

6.Утверждение и контроль проектных планов, проектных рамок

7.Утверждение изменений в обязательствах по проекту

8.Утверждение результатов проекта, подлежащих утверждению

Состав Координационного комитета

Таблица 9. Состав Координационного комитета проекта

ФИО	Компания, Должность

Устав проекта

стр. 8 из 17

www.sinera.ru

3.4.3Оперативный совет Функции Оперативного совета

1.Утверждение аналитических материалов

2.Утверждение проектных материалов, требуемых по процессу

3.Утверждение архитектурных и технологических решений

4.Утверждение результатов реализации в проекте

5.Утверждение согласованных изменений в решениях по реализации проекта

6.Разрешение возникающих оперативных проблем

Состав Оперативного совета

Таблица 10. Состав Оперативного совета проекта

	ФИО		Компания, Должность

3.5Порядок взаимодействия проектной группы

Таблица 11. Порядок взаимодействия проектной группы

	№		Деятельность		Инициатор		Частота		Результат
1.		Собрание оперативного совета		Оперативный совет			Еженедельно, Пн.	Протокол собрания
						16:00-17:00
2.		Переписка			Проектная группа		В течение проекта		Электронная почта,
								Форумы e-room,
								Телефон, ICQ

4.ПРОЦЕДУРЫ ВЕДЕНИЯ ПОДРОЕКТА

4.1Порядок изменения данного документа

Изменения в данный регламент могут вноситься на протяжении всего проекта по согласованию сторон. Решение оформляется в виде протокола совещания Управляющего комитета, подписанного обеими сторонами.

4.2Инфраструктура проекта

4.2.1Инфраструктура на стороне Заказчика

[Описывается инфраструктура на стороне Заказчика]

4.2.2Инфраструктура на стороне Исполнителя

[Описывается инфраструктура на стороне Исполнителя]

4.2.3Использование общей инфраструктуры

Для ведения проектной документации используется Информационная система Заказчика с Webдоступом: http://www.gidroogk.com/sites/ksd/default.aspx

При этом должны соблюдаться следующие правила:

1.Размещение проектной документации в течении суток после ее подписания или внесения дополнительных согласованных изменений

2.Размещение протоколов совещаний в течении суток после мероприятия

Устав проекта

стр. 9 из 17

www.sinera.ru

3.Размещение инструкций и регламентов в течении суток после их подписания или внесения дополнительных согласованных изменений

4.3Процедура согласования документов

4.3.1Правила наименования документов

[Правила наименования документов]

4.3.2Отправка документов на согласование

Передача документов на согласование осуществляется автором документа.

Рассылка документа производится по электронной почте. Если документ размещается в системе хранения проектной документации, то в письме указывает ссылка доступа к документу.

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

4.3.3Внесение изменений

Внесение изменений документа производится в режиме правки. Документу присваивается новая версия, которая указывается в названии документа.

4.3.4Сроки согласования

Срок согласования документов – 2 рабочих дня. При необходимости срок согласования документов может быть изменен по согласованию с руководителями проекта со стороны Заказчика и Исполнителя.

4.4Процедура оперативного планирования, контроля, отчетности по проекту

•Календарный поэтапный план основных вех проекта уточняется после согласования ЧТЗ.

•Детальный план проекта разрабатывает Руководитель проекта Исполнителя.

•Детальный план проекта актуализируется еженедельно Руководителем проекта Исполнителя и высылается членам проектной группы в день проведения собрания проектной группы, предварительно, до начала ее проведения.

•Еженедельно руководитель проекта Исполнителя составляет Отчет Руководителя Проекта с указанием статуса проекта и основных вех проекта. Отчет высылается членам проектной группы одновременно с Актуализированным планом проекта.

•Отчет, Актуализированный план согласуется руководителем проекта со стороны Заказчика.

4.5Формирование требований к Системе

Формирование требований к Системе осуществляется совместно Консультантами Исполнителя и предметными специалистами Заказчика.

Обсуждение требований осуществляется на встречах. Планирование встреч производится в рабочем порядке по согласованию представителей Заказчика и Исполнителя. Протоколы встреч по обсуждению требований не ведутся.

Требования к системе оформляются в виде:

•Общих технических требований;

•Частных технических заданий.

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

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

Устав проекта

стр. 10 из 17

www.sinera.ru

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

Для демонстрации прототипов Системы может использоваться виртуальный сервер VM Ware.

4.6Разработка Системы

4.6.1Стандарты кодирования

Весь написанный программный код должен удовлетворять стандартам кодирования, описанным в документах:

•ftp://– стандарты кодирования на языке C++;

•ftp:// - стандарты кодирования на языке Java.

Дополнительные требования к кодированию, не указанные в перечисленных выше документах:

• Комментарии к коду должны быть на русском языке.

Исключение составляют использованный при разработке код open sourceбиблиотек.

4.6.2График релизов

Разработка Системы осуществляется на оборудовании Исполнителя. Функциональность, требующая разработки, распределяется по релизам. График релизов составляется Исполнителем, согласуется с Заказчиком и включается в план проекта.

4.7Тестирование

Тестирование системы производится Исполнителем удаленно на опытном стенде Заказчика.

4.8Развертывание

4.8.1Развертывание Системы

Развертывание системы состоит из следующих этапов:

1.Подготовка оборудования для опытного стенда – Заказчик;

2.Установка СУБД, Documentum – Исполнитель;

3.Развертывание прототипа системы на опытный стенд – Исполнитель;

4.Подготовка оборудования для промышленной эксплуатации системы – Заказчик;

5.Установка СУБД, Documentum – Исполнитель;

6.Администрирование системы до ввода в промышленную эксплуатацию - Исполнитель

7.Развертывание системы на оборудование для промышленной эксплуатации – Исполнитель.

При выходе нового релиза, выполняется следующая процедура развертывания:

1.Развертывание на опытный стенд – Исполнитель

2.Тестирование системы – Исполнитель

3.Развертывание на оборудование для промышленной эксплуатации – Исполнитель

4.Тестовая эксплуатация – Заказчик

4.8.2Формат релиза Системы (уточняется в соответствии с ЧТЗ)

Релиз Системы состоит из:

•Приложение DocApp (одно или несколько);

•Набора Java-классов;

•Web компоненты (возможно в виде war-файла);

•Инструкция по развертыванию релиза;

Устав проекта

стр. 11 из 17

www.sinera.ru

4.8.3Подготовка рабочих мест пользователей

Подготовка рабочих мест пользователей производится силами службы технической поддержки Заказчика.

Подготовка рабочих мест должна быть выполнена до начала этапа тестовой эксплуатации Системы.

4.9Внедрение и опытная эксплуатация

4.9.1Регламент работы пользователей

•Специалисты заказчика вносят изменения в регламентирующие документы Заказчика

•Регламенты работы согласуется со специалистами Исполнителя

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

4.9.2Обучение пользователей

•Для обучения пользователей готовится программа, включающая теоретические занятия и практические задания, а также инструкции работы пользователей в Системе.

•Для обучения пользователи разбиваются по группам, составляется график обучения групп.

•Программа и график обучения утверждается на собрании проектной группы и проводится приказом по Компании.

•По результатам обучения проводится аттестация пользователей на знание работы с системой. Результаты аттестации принимаются на собрании проектной группы.

•Подготовку программы обучения выполняет Заказчик.

•Подготовку инструкций пользователей (общей и ролевых) выполняет Исполнитель.

•Проведение обучения выполняет консультант со стороны Исполнителя совместно с представителем Заказчика.

4.9.3Тестовая эксплуатация системы (ТЭ)

•На этапе тестовой эксплуатации пользователи работают в Системе ежедневно, в течение ограниченного промежутка времени, выполняя действия по обработке нескольких документов.

•Результат работы пользователей в Системе ежедневно заносится в журнал «Журнал опытной эксплуатации». Ведение журнала осуществляет консультант Исполнителя или специалист Заказчика.

•Ошибки системы, замечания и пожелания по работе с Системой заносятся в Базу инцидентов.

•Результаты тестовой эксплуатации обсуждаются на собраниях проектной группы. С целью более эффективного проведения тестовой эксплуатации может быть принято решение об изменении графика собраний проектной группы на ежедневной основе. Обсуждаются:

OЗаведенные/исправленные инциденты

OРезультаты работы с системой пользователей и подразделений за день

•Перевод в Системы в опытную эксплуатацию производится после проведения приемо-сдаточных испытаний на ту часть функциональности, которая намечена к переводу в ОЭ.

•Для перевода системы в опытную эксплуатацию издается приказ по предприятию.

4.9.4Опытная эксплуатация системы (ОЭ)

•На этапе опытной эксплуатации пользователи работают в системе ежедневно, выполняя в системе все операции в полном объеме.

•В период опытной эксплуатации выполняется дублирование операций (ведение журналов регистрации, заполнение контрольных карточек, отражение в

Устав проекта

стр. 12 из 17

www.sinera.ru

информационных системах и т.п.) в соответствии с регламентами, существовавшими в компании до внедрения Системы.

•Результат работы пользователей в Системе ежедневно заносится в журнал «Журнал опытной эксплуатации». Ведение журнала осуществляет консультант Исполнителя или специалист Заказчика.

•Ошибки системы, замечания и пожелания по работе с Системой заносятся в Базу инцидентов.

•Результаты опытной эксплуатации обсуждаются на собраниях проектной группы. С целью более эффективного проведения опытной эксплуатации может быть принято решение об изменении графика собраний проектной группы на ежедневной основе. По результатам проведения опытной эксплуатации на собрании проектной группы принимается решение о переводе системы в режим промышленной эксплуатации.

•С момента перевода Системы в промышленную эксплуатацию дублирование операций по прежним регламентам предприятия прекращается, все операции работы с документами выполняются только в Системе.

•Для перевода системы в промышленную эксплуатацию издается приказ по предприятию.

4.9.5Порядок работы с Журналом опытной эксплуатации

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

Журнал опытной эксплуатации ежедневно высылается проектной команде по электронной почте.

4.9.6Использование базы данных дефектов

Все дефекты, найденные при тестировании, должны фиксироваться в общей БД дефектов в системе Jira, адрес для доступа: https://. Доступ к БД дефектов будет выдаваться участникам со стороны Исполнителя по заявке ответственного со стороны Исполнителя.

При регистрации ошибки, найденной Заказчиком, должна автоматически осуществляться нотификация по e-mail ответственного со стороны Исполнителя, который принимает решение по маршрутизации ошибки на стороне Исполнителя.

Каждой зафиксированной ошибке должен быть проставлен приоритет (критичность) на основе спецификации приоритетов дефектов (Приложение 1). Приоритет ошибки выставляется тестировщиком, зафиксировавшим ошибку, или ответственным по разработке со стороны Исполнителя или Заказчика (в зависимости от того, где зарегистрирована ошибка).

После исправления ошибки Исполнителем, состояние ошибки изменяется с «Открыто» на «Проверка» ответственным со стороны Исполнителя, при этом автоматически осуществляется нотификация ответственного человека со стороны Заказчика. При изменении состояния исполнитель обязан указать номер релиза, в который попадет исправление.

4.9.7Исправление ошибок, найденных в базовом функционале

Ошибки, найденные в базовом функционале платформы (Documentum, ORACLE и т.п.), направляются в службу технической поддержки данных платформ специалистами Исполнителя. Изменения, которые необходимо внести в систему для устранения данного типа ошибок обрабатываются в соответствии с Процедурой обработки запросов на изменения.

4.9.8Исправление ошибок, найденных в Системе

Все ошибки, у которых выставлен приоритет «Высокий», должны быть исправлены к следующей поставке релиза. Ошибки с приоритетом «Средний» должны быть исправлены до окончания опытной эксплуатации. Ошибки с приоритетом «Низкий» могут быть исправлены на этапе промышленной эксплуатации Системы. Перечень ошибок приведен в Таблице «Спецификация ошибок Системы».

Устав проекта

стр. 13 из 17

www.sinera.ru

В случае обнаружения критических ошибок, препятствующих проведению опытной эксплуатации, должна быть осуществлена промежуточная поставка обновлений с исправленными ошибками. Срок исправления критических ошибок на этапе опытной эксплуатации – 72 часа.

Таблица 12. Спецификация ошибок Системы

№	Определение
Высокие

В_1 Дефект, вызывающий повреждение или разрушение операционной системы, за исключением случаев Н_2.

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

В_3 Дефект, делающий невозможным дальнейшую работу или запуск программы.

В_4 Дефект, вызывающий зависание программы или компьютера, а также вызывающий критическую ошибку ОС.

В_5 Дефект, после проявления которого невозможно дальнейшее тестирование какой-либо функциональности, требуемое на данном этапе проекта.

В_6 Не реализованная функциональность, требуемая на данной фазе разработки.

В_7 Дефект, вызывающий непредвиденное использование ресурсов.

В_8 Игнорирование установок безопасности и прав доступа.

Средние

С_1 Появление неправильных сообщений или отсутствие требуемых.

С_2 Дефект, проявляющийся только после определенной последовательности действий.

С_3 Искаженный внешний вид пользовательского интерфейса, который затрудняет работу пользователя, но оставляет возможность работы с программой.

С_4 Дефект, проявляющийся редко, не имеющий четкой последовательности действий к нему приводящей.

Незначительные

Н_1 Искаженный внешний вид пользовательского интерфейса, который затрудняет работу пользователя, но позволяет совершить необходимые действия.

Н_2 После деинсталляции программы остаются файлы и записи в реестре или конфигурационных файлах.

Н_3 Другие дефекты

4.10Порядок приемки результатов проекта

4.10.1Процедура согласования проектной документации

•Проектная документация согласуется в электронном виде в соответствии с процедурой согласования документов, определенными в данном документе.

•Согласованная проектная документация распечатывается в 2х экземплярах, визируется представителями Заказчика и Исполнителя, подписывается руководителями компаний.

•Внесение изменений в проектную документацию производится на основании запросов на изменение системы.

•Подписанный запрос на изменение прилагается к проектной документации. Состав проектной документации приведен в Таблице.

						Таблица 13. Состав проектной документации
	Шифр		Название			Описание
	документа
				Устав проекта			стр. 14 из 17

		www.sinera.ru
	Бюджет проекта	Бюджет расходной части проекта, MS Excel
	План проекта	Оперативный план проекта, MS Project
	Устав проекта	Правила и процедуры управления проектом
	Документ «Отчет об	Документ содержит результаты обследования
	обследовании»	предприятия Заказчика. Содержимое документа
		является основой для разработки документов
		«Концепция», «Техническое задание. ГОСТ».
	Документ «Концепция»	Описание высокоуровневых требований к системе,
		основных функций системы, пользователей
		системы.
		Содержит границы проекта, границы бизнеса
		будущей системы, основные причины ее
		построения.
	Документ «Техническое	Описание общих требований к системе,
	задание. ГОСТ»	оформленных в соответствии с ГОСТ. Не должен
		содержать детализированных требований.
	Документ «Требования к	Спецификация требований к системе, описание
	системе (СРС)»	интерфейсов, сценарии использования системы.
		Документ содержит детализированные требования к
		системе, расширяющие общие требования к
		системе, отраженные в документах «Концепция»,
		«Техническое задание.ГОСТ».
	Документ «Системная	Характеристики оборудования, архитектура
	архитектура»	системы, версии ОС и программного обеспечения
	Документ «Технический	Описание архитектуры программных компонент
	проект»	системы или совокупность ЗНР
	Документ «План	Описание способов, видов и критериев
	тестирования»	тестирования, необходимые ресурсы и порядок
		выполнения тестирования.
	Документ «Спецификация	Руководство для инженера по тестированию по
	проектирования тестов»	правилам составления тестовых сценариев в
		системе управления тестами для данного проекта.
	Документ «Инструкция по	Инструкция для администратора системы по
	развертыванию»	развертыванию и обновлению версий системы
	Документ «Руководство	Описание функций и методов системы в формате
	разработчика»	JavaDoc
	Документ «Описание релиза»	Описание функциональности, добавленной в
		релизы системы, информацию об известных
		ошибках системы.
	Документ «Руководство	Инструкция по использованию системы
	пользователя»
	Документ «Руководство	Инструкция по настройке системы,
	Администратора»	администрированию справочников, пользователей,
		групп, резервному копированию и восстановлению
		системы.
	Документ «ПИМИ»	Программа и методика проведения приемо-
		сдаточных испытаний
	Устав проекта		стр. 15 из 17