УСТАВ ПРОЕКТА <ПРОЕКТ> Версия: Дата: Код: 1.00 00.00.00 NNN-02 Москва www.sinera.ru СОДЕРЖАНИЕ 1. 1.1 1.2 1.3 ОБЩИЕ СВЕДЕНИЯ .................................................................................................... 3 Цель документа ............................................................................................................ 3 Ссылки на документы .................................................................................................. 3 Термины и определения .............................................................................................. 3 2. 2.1 2.2 2.3 2.4 2.5 ОПИСАНИЕ ПРОЕКТА ................................................................................................ 3 Цели проекта ................................................................................................................ 3 Область изменений ...................................................................................................... 3 Поставляемы продукты и услуги ................................................................................ 4 Риски ............................................................................................................................. 4 Обязательства Заказчика ............................................................................................ 5 3. 3.1 3.2 3.3 3.4 3.5 ОРГАНИЗАЦИОННАЯ СТРУКТУРА ПРОЕКТА ........................................................ 5 Состав проектной команды ......................................................................................... 5 Структура взаимодействия ......................................................................................... 6 Разделение обязанностей ........................................................................................... 6 Уровни управления и координации ............................................................................ 8 Порядок взаимодействия проектной группы ............................................................. 9 4. 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 ПРОЦЕДУРЫ ВЕДЕНИЯ ПОДРОЕКТА ..................................................................... 9 Порядок изменения данного документа ..................................................................... 9 Инфраструктура проекта ............................................................................................. 9 Процедура согласования документов ...................................................................... 10 Процедура оперативного планирования, контроля, отчетности по проекту ........ 10 Формирование требований к Системе ..................................................................... 10 Разработка Системы .................................................................................................. 11 Тестирование .............................................................................................................. 11 Развертывание ........................................................................................................... 11 Внедрение и опытная эксплуатация......................................................................... 12 Порядок приемки результатов проекта .................................................................... 14 Процедура обработки запросов на изменение ....................................................... 16 Процедура управления резервами ........................................................................... 17 ПЕРЕЧЕНЬ ТАБЛИЦ Таблица 1. Ссылки на документы ......................................................................................... 3 Таблица 2. Термины и определения .................................................................................... 3 Таблица 3. Аспекты изменений деятельности Заказчика .................................................. 3 Таблица 4. Этапы и сроки выполнения работ ..................................................................... 4 Таблица 5. Поставляемые продукты .................................................................................... 4 Таблица 6. Риски проекта ...................................................................................................... 4 Таблица 7. Обязательства заказчика ................................................................................... 5 Таблица 8. Структура взаимодействия ................................................................................ 6 Таблица 9. Состав Координационного комитета проекта .................................................. 8 Таблица 10. Состав Оперативного совета проекта ............................................................ 9 Таблица 11. Порядок взаимодействия проектной группы .................................................. 9 Таблица 12. Спецификация ошибок Системы ................................................................... 14 Таблица 13. Состав проектной документации ................................................................... 14 Устав проекта стр. 2 из 17 www.sinera.ru 1. ОБЩИЕ СВЕДЕНИЯ 1.1 Цель документа Целью данного документа … к системе <Проект>. 1.2 Ссылки на документы Таблица 1. Ссылки на документы № Документ Описание Д1. 1.3 Термины и определения Таблица 2. Термины и определения Термин Определение 2. ОПИСАНИЕ ПРОЕКТА 2.1 Цели проекта 1. 2. 3. 4. 5. 6. 7. 2.2 Описываются цели проекта и проблемы Заказчика, которые проект должен решить. Не использовать общие заявления типа: снижение затрат, увеличение продаж и т.п. Определить измеряемые критерии, по которым можно будет формально оценить проект: Сдача всех поставляемых продуктов в срок по договору Выполнение всех работ по проекту в рамках бюджета по договору Поставка всех определенных в договоре продуктов Сдача всех промежуточных продуктов в срок в пределах 10% Трудозатраты по группам задач в пределах 10% Плотность ошибок после поставки не более 10% от нормы Сдача поставляемых продуктов не более чем с 3го раза Область изменений Определяются, какие аспекты Заказчика будут затронуты проектом и как. Раздел необходим для оценки рисков и рекомендаций Заказчику Таблица 3. Аспекты изменений деятельности Заказчика Аспект Описание влияния Бизнес-процессы Акцент на деятельности, которую выполняет организация. Какие бизнес-процессы затрагиваются или изменяются, в каких точках, как. Устав проекта стр. 3 из 17 www.sinera.ru Организация (роли, структура, культура, функции) Акцент на персонал организации. Какие кадровые, ролевые, организационные изменения потребуются, включая изменения функций сотрудников. Местоположение (географические точки присутствия Заказчика) Изменения, затрагиваемые как в географическом местоположении, так и физическом размещении предприятия, подразделений. Приложения В каких информационных системах Заказчика произойдут изменения функционала, структуры данных, интерфейса, правил работы. Технологии Программные, аппаратные технологии, коммуникации, в которых произойдут изменения. Данные Акцент на содержании и структуре деловой информации Заказчика, взаимоотношениях с контрагентами, которые будут подвержены изменениям. 2.3 Поставляемы продукты и услуги 2.3.1 Сроки выполнения работ Таблица 4. Этапы и сроки выполнения работ № Этап Дата начала Дата завершения Длительность 1. 2.3.2 Поставляемые продукты Описывается список продуктов или услуг, которые должны быть поставлены Заказчику. Таблица 5. Поставляемые продукты Работы Результат <Работа 1> § <Результат 1> § <Результат 2> <Работа 2> § <Результат 1> § <Результат 2> 2.4 Ответственный за приемку Риски Таблица 6. Риски проекта Риск Потенциальное влияние на проект Оборудование не будет поставлено своевременно Несвоевременное начало задач по установке и настройке системы у Заказчика. Срыв общих сроков проекта. Превышение бюджета проекта вынужденного простоя персонала, связанного с несвоевременным выполнением работ по установке системы и настройке. Потребуется дополнительное время и трудозатраты на управление проектом. Несоответствие поставленного Система не заработает корректно на поставленном Устав проекта стр. 4 из 17 www.sinera.ru оборудования заявленным требованиям оборудовании. Потребуется дополнительное время и трудозатраты на тестирование и доработку системы. Несвоевременная выдача рецензий Заказчиком на документы проекта, затягивания процесса согласования документов. Несвоевременное завершение этапа системного проектирования. Несвоевременное начало этапа технического проектирования. Срыв общих сроков проекта. Превышение бюджета проекта за счет увеличения времени согласования и доработки документов, длительности этапа системного проектирования. Потребуется дополнительное время и трудозатраты на управление проектом. Смена ключевых сотрудников, участвующих Потребуется дополнительное время на ознакомление новых в управлении проектом. сотрудников с проектной документацией. Возможное изменение задач проекта, необходимость перепланирование проектных работ. .... 2.5 ... Обязательства Заказчика Таблица 7. Обязательства заказчика Обязательства Срок Ответственный Поставка серверного оборудования Закупка лицензий СУБД Закупка лицензий Документум Установка и настройка ПО на серверное оборудование Поставка и настройка рабочих станций пользователей системы Предоставление рабочих мест сотрудникам Исполнителя, оборудованных доступом в Интернет. ... 3. ОРГАНИЗАЦИОННАЯ СТРУКТУРА ПРОЕКТА 3.1 Состав проектной команды 3.1.1 Проектная команда Заказчика № п/п ФИО Роль Телефон e-mail 1. 3.1.2 № Проектная команда Исполнителя ФИО Роль Телефон Устав проекта стр. 5 из 17 www.sinera.ru п/п e-mail 1. 3.2 Структура взаимодействия Таблица 8. Структура взаимодействия Вид Заказчик Исполнитель Контрактные вопросы Финансовые вопросы Организационные вопросы Управление требованиями Технические вопросы 3.3 Разделение обязанностей Артефакт Исполнитель Заказчик Устав проекта § Подготовка: <РП> § Согласование: <Куратор> § Согласование: <РП> Планирование § Подготовка: <РП> § Согласование: <Куратор> § Согласование: <РП> Проектный офис § Требования: <РП> § Подготовка: <РП> Система проектного архива § Развертывание: <Инженер ТП> Инициация проекта Система управления требованиями § Развертывание: <Инженер ТП> Определение требований Анкета для расчета архитектуры § Подготовка: <Инженер ТП> § Согласование: <Архитектор> § Заполнение: <Сисадмин> Отчет об обследовании § Подготовка: <Консультант> § Согласование: <Кл.пользователи>, <РП> Концепция § Подготовка: <Консультант> § Согласование: <Архитектор> § Согласование: <Кл.пользователи>,<Продакт менеджер>,<РП> § Подготовка: <Консультант> § Согласование: <Архитектор>, <Тестировщик> § Согласование: <Кл.пользователи>, <РП> Процедура миграции § Проектирование: <Разработчик> § Согласование: <Архитектор> § Данные: <Сисадмин> § Согласование: <Продакт менеджер> Системная архитектура § Проектирование: <Архитектор> § Консалтинг: <Консультант> § Согласование: <Продакт менеджер>,<РП> Технический проект § Подготовка: <Архитектор> § Консалтинг: <Консультант> § Согласование: <Продакт менеджер>,<РП> Системное проектирование Требования к системе Техническое проектирование Устав проекта стр. 6 из 17 www.sinera.ru Реализация Среда разработки § Развертывание: <Разработчик> Среда тестирования § Развертывание: <Инженер ТП> Система контроля версий кода § Развертывание: <Инженер ТП> Система управления инцидентами § Развертывание: <Инженер ТП> Скрипты для сборки билдов § Разработка: <Разработчик> Код § Разработка:<Разработчик> § JavaDOC: <Разработчик> Инструкция по развертыванию § Подготовка: <Разработчик> ПИМИ § Разработка: <Тестировщик> § Консалтинг: <Консультант> § Согласование: <Консультант> Тест план § Подготовка: <Тестировщик> § Консалтинг: <Консультант> § Согласование: <Консультант> Релиз § Подготовка: <Разработчик> § Описание релиза: <Архитектор>/<Вед.разработчи к> § Тестирование установки: <Инженер ТП> § Протокол установки: < Инженер ТП > § Тестирование: <Тестировщик> Руководство пользователя § Подготовка: <Консультант> Руководство администратора § Подготовка: <Инженер ТП> Регламент работы сотрудников § Согласование: <Консультант> Дистрибутив § § § § Подготовка: <Инженер ТП> Поставка: <Инженер ТП> Развертывание: <Инженер ТП> Сдача ПИМИ: <Консультант> § Согласование: <Кл.пользователи>, <РП> § Подготовка: <Кл.пользователи> § Согласование: <РП> § Получение: <РП> § Приемка ПИМИ: <Кл.пользователи> Ввод в действие Рабочие места пользователей § Требования: <Инженер ТП> § Контроль: <Инженер ТП> Среда ОЭ § Развертывание: <Инженер ТП> Оборудование: <Продакт § Администрирование: <Инженер менеджер> ТП> Терминальный доступ: <Сисадмин> План ОЭ § Подготовка: <Консультант> § Согласование <РП> § Приказ ОЭ: <РП> Обучение § Программа: <Консультант> § Обучение кл. пол: <Консультант> § Обучение пользователей: <Кл.пользователи> ОЭ § Журнал ОЭ: § Работа с системой: <мл.Консультант>/Администрат <Исполнители> ор Аттестация § Программа: <Консультант> § Проведение: <Консультант> Среда ПЭ § Подготовка: <Сисадмин> § Проведение: <Кл.пользователи> § Проверка: Кл.пользователи § Приказ ПЭ: <РП> § Оборудование: <Продакт менеджер> § Развертывание: <Сисадмин> § Администрирование: Устав проекта стр. 7 из 17 www.sinera.ru <Сисадмин> Поддержка Инциденты § 1я линия: <Оператор ТП> § 2я линия: <Архитектор> § 3я линия: <Разработчики> § 1я линия: <Сисадмин> Система § Поддержка среды: <Инженер ТП> § Администрирование: <Сисадмин> § Установка обновлений <Сисадмин> Протоколы встреч § Подготовка: <Администратор> § Согласование: <РП> § Контроль исполнения: <Администратор> § Согласование: <РП> Дело проекта § Создание: <Администратор> § Ведение: <Администратор> § Контроль архива: <Администратор> Отчет РП § Подготовка: <РП> Документационное обеспечение 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 1. 2. Использование общей инфраструктуры Для ведения проектной документации используется Информационная система Заказчика с Web- доступом: http://www.gidroogk.com/sites/ksd/default.aspx При этом должны соблюдаться следующие правила: Размещение проектной документации в течении суток после ее подписания или внесения дополнительных согласованных изменений Размещение протоколов совещаний в течении суток после мероприятия Устав проекта стр. 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. 3. 4. 5. 6. 7. 1. 2. 3. 4. 4.8.2 Развертывание системы состоит из следующих этапов: Подготовка оборудования для опытного стенда – Заказчик; Установка СУБД, Documentum – Исполнитель; Развертывание прототипа системы на опытный стенд – Исполнитель; Подготовка оборудования для промышленной эксплуатации системы – Заказчик; Установка СУБД, Documentum – Исполнитель; Администрирование системы до ввода в промышленную эксплуатацию - Исполнитель Развертывание системы на оборудование для промышленной эксплуатации – Исполнитель. При выходе нового релиза, выполняется следующая процедура развертывания: Развертывание на опытный стенд – Исполнитель Тестирование системы – Исполнитель Развертывание на оборудование для промышленной эксплуатации – Исполнитель Тестовая эксплуатация – Заказчик Формат релиза Системы (уточняется в соответствии с ЧТЗ) Релиз Системы состоит из: • Приложение 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 www.sinera.ru Документ «План опытной эксплуатации» Описывает правила проведения опытной эксплуатации, сроки проведения, роли пользователей, мероприятия, проводимые в рамках опытной эксплуатации. Документ «Регламент работы» Описывает регламенты работы сотрудников компании с учетом работы в системе. Документ «План обучения пользователей» План и программа обучения пользователей работе с системой. Документ «Программа аттестации» Набор аттестационных заданий для проведения аттестации пользователей. Документ «Протокол приемосдаточных испытаний» Результаты выполнения заданий, содержащихся в ПИМИ. Документ «Результаты аттестации пользователей» Оценки, выставленные пользователям, при проведении аттестации. Документ «Журнал опытной эксплуатации» Документ, содержащий ошибки и пожелания пользователей, , выявленные в ходе опытной эксплуатации. Документ «Протокол о переводе системы в промышленную эксплуатацию» Документ содержит результаты совещания Координационного совета по вопросу перевода системы в промышленную эксплуатацию. Документ «Приказ о переводе Приказ, издаваемый на предприятии Заказчика о системы в промышленную переводе системы в промышленную эксплуатацию. эксплуатацию» 4.10.2 Документ «Отчет о внедрении» Результаты внедрения проекта, оценка качественных показателей, заданных в начале проекта. Документ «Рекомендации по реинженерингу процесса производства» Описание дальнейших этапов автоматизации и реинжениринга Процедура приемки Системы • Приемка системы осуществляется на основании Программы и методики испытаний (ПИМИ). ПИМИ разрабатывается Исполнителем, согласуется и принимается Заказчиком в соответствии с процедурой приемки проектной документации. • Для приемки Системы создается экспертная комиссия из сотрудников Исполнителя и Заказчика и назначается дата проведения приемо-сдаточных испытаний. • По итогам приемо-сдаточных испытаний составляется протокол с указанием результатов испытаний, выявленных замечаний и датой исправления замечаний. • В случае если в ходе испытаний были выявлены замечания, Исполнитель производит доработку системы, после чего назначается дата повторных испытаний. • Если испытания прошли без замечаний, подписывается протокол сдачи-приемки Системы. 4.11 1. Процедура обработки запросов на изменение После согласования Технического задания (ТЗ) действует следующая процедура обработки запросов на изменение: Все поступающие от Заказчика замечания будут классифицироваться Исполнителем по следующей шкале: Устав проекта стр. 16 из 17 www.sinera.ru • "технические" - не приводящие к изменению смысла требований; • "существенные" - приводящие к изменению смысла требований, но не влияющие на план работ; 2. 3. 4. 5. 6. 4.12 • "критические" - влияющие как на смысл требований, так и на состав, длительность и стоимость работ. Изменения по замечаниям типа "технические" принимаются Исполнителем на исправление и реализуются в очередном релизе системы. Изменения типа "существенные" вносятся с изменением версии ТЗ и подтверждением принятия новой версии ТЗ. Изменения такого типа принимаются Исполнителем на реализацию по результатам принятия согласованного между Сторонами решения о возможности реализации изменений и сроках их реализации. При идентификации замечаний типа "критические" Исполнитель информирует Заказчика о факте их получения и предлагает дату рассмотрения замечаний по существу. До момента рассмотрения замечаний изменения не принимаются. Результаты рассмотрения фиксируются протокольным решением. Обновленный состав задач, сроки работ и их стоимость вносятся в протокол. Стороны заключают дополнительное соглашение на реализацию изменений. При внесении изменений в ТЗ производятся соответствующие изменения в остальные проектные документы: Системная архитектура, ПИМИ, Руководство пользователя, Руководства администратора, и т.п. Процедура управления резервами На протяжении проекта Исполнитель обязуется принять на реализацию изменения, запрошенные Заказчиком, общая продолжительность работ разработчиков Исполнителя над которыми не превышает 40 часов. Оценка трудозатрат разработчиков по запрошенным изменениям выполняется Исполнителем и верифицируется Заказчиком Устав проекта стр. 17 из 17
