Загрузил sabir dadashev

егламент разработки ПО

реклама
Приложение №7
к Договору оказания услуг № ______________г.
Регламент ведения разработки
1. Предмет и условия настоящего Регламента
1.1 Предметом настоящего Регламента являются требования к процессу разработки
программного обеспечения (программных средств), тестирования, доработки,
модификации программного обеспечения (программных средств) Системы в рамках
оказания услуг по Договору.
1.2 Стороны соглашаются с тем, что Заказчик оставляет за собой право инициировать
внесение изменений в содержание настоящего Регламента, после чего Стороны
согласовывают внесенные изменения в порядке, предусмотренном п.4.1 Договора.
1.3 Стороны придерживаются следующего рабочего порядка согласования
артефактов процесса разработки:
1.3.1 Артефакты, требующие согласования с Представителем бизнеса
Заказчика, согласовываются по электронной почте. Факт согласования отмечается
подписями ответственных лиц на листе согласования артефакта (его сканированной
копии).
1.3.2 Артефакты, требующие согласования с Руководителями проекта,
согласовываются по электронной почте.
1.3.3 Артефакты, не требующие согласования с Руководителями проекта,
согласовываются по электронной почте либо средствами используемого
инструментария, необходимого для их создания, хранения или использования.
1.3.4 Лицо, согласующее артефакт, ответственно и обосновано подходит к
определению срока своего согласования.
2. Термины и сокращения
В настоящем Регламенте используются следующие термины, определения и
сокращения:
BPMN – система условных обозначений (нотация) для моделирования бизнеспроцессов.
MS Word - текстовый процессор, предназначенный для создания, просмотра и
редактирования текстовых документов компании Microsoft. В контексте настоящего
Регламента предусматривается только лишь возможность просмотра артефакта с
помощью используемой Заказчиком версии данной программы.
Артефакт – любой созданный в ходе проекта информационный элемент.
Бэклог – журнал (перечень) работы (рабочих элементов), которую необходимо
выполнить команде.
Гибкая методология разработки – итеративный подход к разработке,
ориентированный на использование серии коротких циклов действий, направленных на
создание рабочей версии программного продукта.
Пользовательский интерфейс – совокупность визуальных элементов компонентов
Системы, а также методов взаимодействия между пользователем и этими
компонентами.
Продуктивная среда – совокупность программно-аппаратных средств, в которой
развернута версия Системы, предназначенная для работы пользователей.
Репозиторий версии системы – программно-аппаратное обеспечение, служащее
хранилищем для компонентов системы, предназначенных для развертывания в
продуктивной среде Заказчика. Для проекта репозиторием версии системы служит
специально выделенная часть ИТ-инфраструктуры Заказчика под управлением ПО
TeamCity
1
Репозиторий документации – программно-аппаратное обеспечение, служащее
хранилищем для артефактов, представленных в виде электронных документов. Для
проекта репозиторием документации служит специально выделенная часть ИТинфраструктуры Заказчика под управлением ПО Confluence
Репозиторий кода – программно-аппаратное обеспечение, служащее хранилищем для
артефактов, представляющих собой исходный код компонентов Системы. Для проекта
репозиторием кода служит специально выделенная часть ИТ-инфраструктуры Заказчика
под управлением ПО Git
Репозиторий требований – программно-аппаратное обеспечение, служащее
хранилищем для артефактов, представляющих собой элементы управления проектом
разработки: требования, задачи, ошибки и т.п. Для проекта репозиторием требований
служит специально выделенная часть ИТ-инфраструктуры Заказчика под управлением
ПО Jira
Система –Система адресного учета металла «ШК-Склад»
Спринт – итерация разработки, жестко ограниченная во времени, в ходе которой
создается версия Системы
Юнит-тест – подпрограмма (скрипт), цель которой заключается в проведении испытаний
компонентов системы, созданная в процессе программирования.
3. Участники, ответственности
3.1 Стороны формируют совместную команду разработки. Контактные данные членов
команды (ФИО, Организация, Должность, Эл.адрес, телефон) с указанием
ролей/оказываемых видов Услуг должны быть занесены в Контактную Карту проекта.
Член команды может иметь несколько ролей. Контактную Карту согласуют
Руководитель проекта Исполнителя и Руководитель проекта Заказчика. Менеджер
проекта поддерживает Контактную Карту в актуальном состоянии в Репозитории
Документации Заказчика.
3.2 Настоящим Регламентом предусмотрены следующие роли/виды Услуг:
3.2.1 Со стороны Заказчика:
Руководитель проекта;
Представитель бизнеса;
Менеджер проекта;
Аналитик;
Архитектор;
Разработчик;
Тестировщик;
3.2.2 Со стороны Исполнителя:
Руководитель проекта;
Аналитик;
Архитектор;
Дизайнер;
Разработчик;
Тестировщик;
Технический писатель.
4. Разработка системы
4.1 Исполнитель должен придерживаться гибкой методологии разработки. В ходе
разработки в спринтах Исполнитель организует коммуникации. Во встречах, связанных
с планированием спринтов, подведением итогов и ретроспективах обязательное
участие принимают Руководитель проекта, Менеджер проекта, Разработчик и Аналитик
со стороны Заказчика. В ходе проекта все артефакты должны поддерживаться
ответственными в актуальном состоянии. После разработки и утверждения
2
допускается внесение изменений в артефакты. Все изменения согласуются с членами
команды в соответствии с их ролями.
4.2 Бэклог бизнес-требований
В рамках услуги «Разработка требований и архитектуры» Исполнитель формирует
документ бизнес-требований, содержащий описания бизнес-процессов в формате
BPMN 2.0. Исполнитель размещает в Репозитории Документации Заказчика и в ходе
всего проекта поддерживает в актуальном состоянии Бизнес-требования в виде
Бэклога бизнес-требований.
Действие
Формирование
списка бизнестребований
Ответственный
Аналитик
Исполнителя
Ведение
Аналитик
Бэклога бизнес- Исполнителя
требований
Расстановка
приоритетов и
утверждение
Менеджер
проекта
Согласующие
Документ/
Объект
Бизнестребования
Руководитель
проекта;
Представитель
бизнеса;
Менеджер
проекта;
Аналитик
Руководитель
проекта;
Менеджер
проекта;
Аналитик
Аналитик
Исполнителя
Инструмент
Прочее
MS Word;
Бизнес-роцессы
Репозиторий должны быть
документации описаны в формате
BPMN 2.0
Бэклог бизнес- Репозиторий В ходе проекта
требований
требований поддерживается
ответственным в
актуальном
состоянии
Бэклог бизнес- Репозиторий В ходе проекта
требований
требований поддерживается
ответственным в
актуальном
состоянии
4.3 Архитектура решения
В рамках услуги «Разработка требований и архитектуры» Исполнитель формирует
документ, описывающий Архитектуру решения.
Действие
Разработка
архитектуры
решения
Ответственный
Архитектор
Исполнителя
Согласующие
Архитектор;
Аналитик;
Разработчик;
Руководитель
проекта;
Менеджер
проекта;
Документ/
Объект
Архитектура
решения
Инструмент
MS Word;
Репозиторий
требований
Прочее
В ходе проекта
поддерживается
ответственным в
актуальном
состоянии
4.4 Бэклог продукта
Бизнес-требования должны быть детализированы перед их реализацией. Детальные
требования к продукту должны быть оформлены в виде Бэклога продукта.
Действие
Ответственный
Ведение
Бэклога
продукта
Аналитик
Исполнителя
Расстановка
приоритетов и
утверждение
Менеджер
проекта
Заказчика
Оценка и
Менеджер
распределение проекта
задач
Согласующие
Руководитель
проекта;
Менеджер
проекта;
Аналитик
Аналитик
Исполнителя
Руководитель
проекта
Документ/
Объект
Бэклог
продукта
Инструмент
Репозиторий
требований
Бэклог
продукта
Репозиторий
требований
Бэклог
продукта
Репозиторий
требований
Прочее
В ходе проекта
поддерживается
ответственным в
актуальном
состоянии
В ходе проекта
поддерживается
ответственным в
актуальном
состоянии
Выполняется на
этапе
планирования
спринта
4.5 Дизайн пользовательских интерфейсов
Должен быть разработан документ Дизайн пользовательских интерфейсов.
Действие
Ответственный
Согласующие
3
Документ/
Объект
Инструмент
Прочее
Разработка
документа,
описывающего
дизайн
пользовательско
го интерфейса
Дизайнер
Исполнителя
Руководитель
проекта;
Представитель
бизнеса;
Менеджер
проекта;
Аналитик
Дизайн
пользователь
ских
интерфейсов
MS
Word;
Репозиторий
документаци
и
В ходе проекта
поддерживает
ся
ответственным
в актуальном
состоянии
4.6 Исходный Код Системы
Должен быть разработан и передан Заказчику весь Исходный Код компонентов
Системы, который может быть собран в версию системы, и она установлена в
продуктивной среде Заказчика. Разработка Исходного Кода Системы должна вестись
по гибкой методологии. Артефакты Исходного Кода Системы должны храниться в
Репозитории Кода Заказчика. Исполнитель должен обеспечить соответствие исходного
кода требованиям Руководства Разработчика. Исполнитель должен разработать юниттесты и обеспечить приемлемый уровень покрытия исходного кода системы. Юниттесты являются частью исходного кода, передаваемого Заказчику.
Действие
Ответственный
Сборка
Менеджер
проекта
Документ/
Объект
Версия
Системы
Выпуск
Менеджер
проекта
Версия
Системы
Инструмент
Прочее
Репозиторий
Версий
системы
Сборка Версии Системы
выполняется в автоматическом
режиме (непрерывная
интеграция). Основная ветвь в
Репозитории исходного кода
(master) должна содержать
готовый для безошибочной
сборки
Выпуск Версии Системы в
продуктивную среду выполняется
в автоматическом режиме
(непрерывное развертывание).
Репозиторий
Версий
системы
4.7 Версия Системы
Должна быть разработана и передана Заказчику Версия Системы - набор исполняемых
файлов, настроек и прочих компонентов, которые могут быть установлены в
продуктивной среде Заказчика. Разработка Версии системы должна вестись по гибкой
методологии. Артефакты Версии Системы должны храниться в Репозитории Версий
Системы Заказчика.
4.8 Техническая документация
Должна быть разработана и передана Заказчику техническая документация.
Артефакты технической документации должны храниться в Репозитории документации
Заказчика.
Действие
Ответственный
Разработка
Технический
Руководства
писатель
администратора Исполнителя
Разработка
Руководства
разработчика
Технический
писатель
Исполнителя
Согласующие
Документ/
Инструмент
Прочее
Объект
Руководитель Руководство
MS Word;
описывается
проекта;
администратора Репозиторий порядок
Менеджер
документации действий для
проекта;
развертывания
Администратор
и
сопровождения
компонентов
версии
системы в
среде
Заказчика
Руководитель Руководство
MS Word;
описываются
проекта;
разработчика
Репозиторий требования к
Менеджер
документации разработке
проекта;
исходного кода
Разработчик
компонентов
системы, а
также
требования к
сборке версии
системы из
4
Разработка
Руководства
пользователя
Технический
писатель
Исполнителя
Руководитель
проекта;
Менеджер
проекта;
Аналитик
Руководство
пользователя
исходного
кода.
MS Word;
может состоять
Репозиторий из нескольких
документации отдельных
Инструкций
Пользователя.
Должно быть
полностью
разработаны
до начала
фазы обучения
пользователей
4.9 Артефакты тестирования
Должны быть разработаны и переданы Заказчику Тестовые сценарии, План
пользовательского (приемочного) тестирования.
Действие
Разработка
тестовых
сценариев
администратора
Ответственный Согласующие
Тестировщик
Исполнителя
Разработка
Тестировщик
плана
Исполнителя
пользовательског
о тестирования
Руководитель
проекта;
Менеджер
проекта;
Тестировщик
Руководитель
проекта;
Менеджер
проекта;
Тестировщик
Документ/
Объект
Тестовые
сценарии
Инструмент
Прочее
MS Word;
Репозиторий
документации
описывается
порядок действий
проверки
работоспособнос
ти системы
Содержит
перечень
тестовых
сценариев и
критерии
успешности для
проведения
пользовательског
о тестирования и
должен быть
разработан до
начала фазы
ввода Системы в
опытную
эксплуатацию
План
MS Word;
пользователь Репозиторий
ского
документации
тестирования
4.10 Управление дефектами
На любом этапе проекта выявленные дефекты (несоответствие ПО требованиям или
технической документации) должны фиксироваться в Репозитории требований
Заказчика. Зарегистрированные дефекты являются частью Бэклога Продукта.
Срок устранения дефекта определяются исходя из важности (степени влияния на
функционирование системы), их приоритета.
Действие
Выявление
дефектов
Оценка
количества
открытых
дефектов
Ответственный
Согласующие
Команда
Документ
/Объект
Дефект
Руководитель
проекта
Исполнитель:
Инструмент
Репозиторий
требований
Репозиторий
требований
Заказчик:
ПАО «Северсталь»
_________________
_________________
5
Прочее
Руководители
проекта
согласовывают и
обеспечивают
приемлемый
уровень количества
открытых дефектов
Скачать