Порядок планирования разработок ПО

Порядок планирования разработок/доработок программного обеспечения

1. Общие положения.

1.1. Назначение документа.

Настоящий документ описывает порядок формирования плана разработок/доработок программного обеспечения в интересах Общества.

Участниками выполнения данного документа являются:

1. Заказчик – сотрудник Общества, выступающий инициатором работ по разработке/доработке программного обеспечения от подразделения, по которому требуется выполнение работ. В качестве Заказчика от подразделения выступает заранее определенный лидер.
2. Руководитель процесса разработки – руководитель отдела разработки 1С, организующий планирование и общее руководство разработкой.
3. Специалист (разработчик) – специалист ИТ отдела, отвечающий за разработку программного обеспечения.

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

1.2. Термины и определения.

Термины, определения и сокращения, используемые в настоящем документе:

1.2.1. Общество – ООО «12 ИСТОРИЙ».

1.2.2. ПО – программное обеспечение.

1.2.3. ТЗ – техническое задание.

1.2.4. ЭПС – электронная почтовая система.

1.2.5. ИТ – ИТ отдел.

2. Порядок планирования разработок/доработок программного обеспечения.

2.1. Формирование ТЗ.

С целью повышения эффективности деятельности Общества путем улучшения и автоматизации бизнес процессов, повышения производительности труда, сотрудники ИТ выполняют работы по разработке ПО.

Разработка ПО выполняется на основании ТЗ, согласованного Руководителем процесса разработки и утвержденного руководителем ИТ одела.

Заказчик формирует ТЗ в соответствии с формой технического задания на разработку и создает задачу в Яндекс.трекере в очередь ODINSDEV.

К ТЗ предъявляются следующие требования:

1. Инициатором ТЗ может выступать любой сотрудник Общества. Инициатива излагается Лидеру, который в дальнейшем выступает в роли Заказчика.
2. К разработке допускаются только ТЗ, оформленные в соответствии с утвержденной формой.
3. При согласовании ТЗ и определения приоритета может учитываться экономический эффект от реализации добавляемой функциональности.
4. ТЗ должны направляться Руководителю процесса разработок через Яндекс.Трекер.

Техническое задание создается лидером от подразделения, по которому требуется выполнение работ. Задание направляется в трекер. В течение 1 рабочего дня с момента создания тикета, Руководитель процесса разработки обозначает приоритет выполнения задачи. Приоритет обсуждается с Заказчиком и руководителем ИТ отдела.

Согласование Руководителем процесса разработки ТЗ на доработку/разработку ПО.

Руководитель процесса разработки получает через систему Яндекс.Трекер ТЗ на разработку, проводит его анализ, при необходимости запрашивает обоснование экономического эффекта. Далее делает обобщение полученных ТЗ и составляет список разработок и доработок.

2.2. Планирование разработки.

На основе анализа ТЗ и утвержденного плана разработок и доработок Руководитель процесса разработки в течение 3 рабочих дней определяет круг разработчиков, участвующих в процессе разработки. Совместно с разработчиками по каждой планируемой разработке Руководитель процесса разработки определяет:

1) круг специалистов, входящих в группу тестирования и способ тестирования разработанного ПО,

2) перечень этапов и работ, входящих в общий комплекс работ по разработке ПО,

3) ответственного по каждой работе,

4) приоритеты по каждой работе,

5) план возврата к исходному состоянию,

6) потребность в привлечении дополнительных ресурсов.

7) контрольные точки.

В случае необходимости привлечения дополнительных ресурсов Руководитель процесса разработки согласовывает их с руководителем ИТ отдела. Принимается решение о целесообразности привлечения дополнительных ресурсов.

2.3. Формирование графика выполнения работ.

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

На основе этих данных Руководитель процесса разработки составляет график выполнения работ по разработке ПО.

2.4. Ознакомление исполнителей с планом-графиком работ.

Руководитель процесса разработки доводит до специалистов, участвующих в разработке ПО, план-график работ, а также организует его своевременное и качественное выполнение.

3. Порядок корректировки плана разработок.

Корректировка плана разработок производится в следующих случаях:

1. Внеплановое отсутствие специалиста, отвечающего за разработку ПО.
2. Необходимость оперативного восстановления штатного функционирования ПО.
3. Внеплановое повышение приоритета разработки/доработки руководством Общества.

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

4. Порядок приемки разработок.

После завершения этапа тестирования Руководитель процесса разработки в системе Яндекс.трекер переводит в статус «Тестирование», уведомление об изменении статуса задачи на «Тестирование» приходит в Slack автору задачи. Руководитель процесса разработки в комментарий к задаче кратко пишет результат работы.

После получения информации от Руководителя процесса разработки Заказчик в течение 3 рабочих дней производит проверку ПО на соответствие указанному в ТЗ функционалу на полигоне, к которому ему предоставлен доступ Руководителем процесса разработки. В течение этого периода времени в случае выявления замечаний в работе полученного нового ПО, Заказчик должен предоставить их Руководителю процесса разработки. В случае предоставления замечаний Заказчиком позже отведенного срока, все они оформляются как новое ТЗ.

ФОРМА

ТЕХНИЧЕСКОГО ЗАДАНИЯ НА РАЗРАБОТКУ/ДОРАБОТКУ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

1. Общие сведения.

В данном пункте необходимо указать:

-наименование программного обеспечения (1С: Документооборот, 1С: КА, 1С: БП, 1С: ЗУП),

-наименование подразделения Заказчика,

-вид задачи (баг, обновление, доработка, разработка). Под багом понимается некорректное срабатывание функционала на действия пользователя. Обновление – обновление конфигурации рабочей базы данных на основании релиза поставщика конфигурации. Доработка – добавление новых возможностей имеющегося функционала либо корректировка действия текущего функционала. Разработка – функционал в системе отсутствует, требуется сделать.

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

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

2. Экономическое обоснование.

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

3. Требования к программному обеспечению.

3.1. Требования к программному обеспечению в целом.

В данном пункте нужно указать:

— режим функционирования программного обеспечения и персонала его использующего (24*7, 8*5 и т.д.),

— порядок подготовки персонала (требуется ли разработка инструкций, памяток и т.д.),

— требуется ли дополнительная защита информации или ограничения прав доступа,

В данном пункте можно дополнительно указать:

— специальные требования по усмотрению Заказчика или разработчика.

3.2. Требования к функциям (задачам), выполняемым программным обеспечением.

В данном пункте нужно указать:

— перечень функций, задач, подлежащих автоматизации,

— необходимость создания дополнительных групп, ролей,

— форму представления выходной информации и ее характеристики,

— реакцию ПО на неверные действия пользователя,

— общую схему работы ПО,

— необходимость использования справочников, действующих в Обществе.

3.3. Порядок приемки.

В данном разделе можно указать:

— программа и методика испытаний программного обеспечения,

— группу, на которой будет проводиться тестирование,

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

ПРИМЕР

ТЕХНИЧЕСКОГО ЗАДАНИЯ НА РАЗРАБОТКУ/ДОРАБОТКУ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

1. Общие сведения.

Наименование программного обеспечения: 1С: УПП

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

Вид задачи: разработка

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

Цели, которые будут достигнуты в результате разработки программного обеспечения: повышение эффективности работы сотрудников Розницы

2. Экономическое обоснование.

Сокращение времени на формирование отчета

ПШЕ (общее) =525/1970=0,266

Из расчета формирования отчета в среднем 2 раза в сутки

3. Требования к программному обеспечению.

3.1. Требования к программному обеспечению в целом.

Режим функционирования программного обеспечения и персонала его использующего: 24*7

Порядок подготовки персонала (требуется ли разработка инструкций, памяток и т.д.): требуется разработка инструкции для пользователя по работе с функционалом

Требуется ли дополнительная защита информации или ограничения прав доступа: Право на редактирование карточек конкретных номеров конкретных городов должно быть только у Нач. Юр. отдела или лица им назначенного и только на привязку номера на сотрудника по своей зоне ответственности

3.2. Требования к функциям (задачам), выполняемым программным обеспечением.

Документ «Телефонный справочник»

Вывод в виде отчета списка «Активных» номеров с ФИО, должностью и E-mail (при наличии в карточке сотрудника). Выводятся только записи из карточек номеров с выбранным полем «Отображать в справочнике номеров». Доступ: Доступно для всех.

Образец:

Что требуется:

1. Сохранение/обновление загружаемых данных о расходе за месяц с привязкой к номеру (или коду карточки номера) автоматически при загрузке/изменении/проведении.
2. Сохранение вычисляемого остатка с привязкой к номеру (или коду карточки номера) автоматически при загрузке/изменении/проведении.
3. Сохранение данных из п.1 и п.2 с привязкой к ФИО сотрудника/к коду сотрудника. В случае удаления сотрудника из системы 1С, в регистре сохраняется ФИО сотрудника (на усмотрение программиста).

История изменений должна храниться по блоку «Учет связи» не менее 1 года. Выводится в отдельной вкладке с указанием учетной записи, из которой вносились изменения с указанием конкретных действий, которые произвел пользователь.

Право на редактирование карточек конкретных номеров конкретных городов должно быть только у Нач. УПС или лица им назначенного и только на привязку номера на сотрудника по своей зоне ответственности (по своей дороге).

3.3. Порядок приемки.

Группа, на которой будет проводиться тестирование: Тестирование функционала будет производить сотрудник розницы Иванов И.И.

Место и способы размещения подготовленной документации: документация должна быть предоставлена по ЭПС ведущему специалисту по закупкам Иванову И.И., а также размещена в Confluence в разделе Инструкции