Использование СППР для управления проектами разработки.

Использование СППР для управления проектами разработки.

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

Общее описание, цели использования системы

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

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

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

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

Демо версия предоставлена компанией 1с —СППР

Общее описание разделов системы

В рамках одной системы может идти проектирование разных программ (например, ДО и ERP). Для разделения разрабатываемых систем — нужно выбрать текущий «Проект» на Рабочем столе.

Ведение технических проектов обеспечивается разделом «Проектирование и разработка» — Технические проекты». Следует заполнять соответствующую информацию на указанных полях и вкладках:

  • Раздел проекта
  • Цель
  • Концепция
  • Описание (после завершения, для подготовки документации)

Программа позволяет регистрировать список требований, для дальнейшей реализации, см. «Проектирование и разработка — Требования»

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

Работа с техническими проектами

Инструкция по порядку заполнения технических проектов

Переходим в раздел технических проектов. Главное -Технические проекты

2. Выбираем или создаем технический проект

3. Каждая самостоятельная доработка – должна быть оформлена отдельным техническим проектом.

4. На вкладке «Основное» необходимо заполнить:

  • Наименование – это краткое наименование задачи. Оно должно отражать краткую суть задачи.
  • Ответственный – это основной ответственный за реализацию задачи (как делаем). 
  • Проект — принадлежность к проекту.
  • Раздел проекта (Если используется) – это крупные этапы проекта, к которым относится задача. Если задача относится к нескольким разделам, например, затрагивает справочники или бизнес-процессы других разделов, то необходимо указывать «Дополнительные разделы»
  • Код – присваивается автоматически. Этот код необходимо использовать в комментариях в программном коде.
  • Статус – статус «Активен» — значит, что задача в разработке. Статус «Выполнен» — значит, что решение уже в хранилище.  Статус «Отменен» — значит, что задача больше не актуальна и если был код, то он закомментирован или убран. Статус «Не активен» — значит задача в очереди на разработку или проектирование.
  • Участники – это список консультантов, программистов, проектировщиков, которые участвуют в проектном решении (часть задачи могут сформулировать, спроектировать, реализовать различные люди, но отвечает в целом за задачу «Ответственный»).
  • Цели – в этом поле необходимо написать зачем мы что-то делаем и кому это нужно. Также необходимо дать ссылку на задачу (задачи) из документооборота.

Концепция

Пункты 1-4 необходимы руководителю проекта чтобы согласовать концепцию, их не нужно описывать слишком детально. Пункт 6 – технические детали для программиста, все детали нужно указывать тут.

На вкладке «Концепция» необходимо заполнить:

  • Типовой функционал («Что известно») по задаче с точки зрения типовой конфигурации. Это необходимо, чтобы понимать контекст и понимать, что в типовой конфигурации нет данной функции.
  • «Варианты использования» — это изложение того, как будет взаимодействовать пользователь с программой при  реализации функции.
  • Концепция доработок («Что делаем») — что необходимо изменить в программе, в общих чертах, это Концепция доработок.
  •  «Ограничения» проекта (задачи). Например, какие-то типовые функции или при каких-то настройках программы, данная функция не будет работать.
  • Прочая информация, необходимая для того, кто далее будет выполнять задачу. Иногда полезно написать, что важно протестировать.
  • «Как делаем (ТЗ)» — это подробное описание реализации, необходимое когда не очевиден подход к выполнению доработок, или когда проектировщик и разработчик – разные сотрудники.
Пример концепции
Еще один пример концепции

Идеи

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

Проектные решения

На вкладке «Проектные решения» по факту пишутся объекты, которые будут изменены. Это делается по факту разработки.

Для указания объектов метаданных отдельная вкладка

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

Задачи

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

Проект

Контрольные точки

На вкладке «Общее» у технических проектов есть контрольные точки, отображающие проверку технического проекта тем или иным ответственным, например:

  • Концепция согласована руководителем проекта
  • Согласованны трудозатраты (с исполнителем)
  • Согласовано с заказчиком (концепция и трудозатраты)
  • Доработка выполнена и протестирована

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

Обсуждение закрыто.