1С проектирование прикладных решений

Система проектирования прикладных решений

Демонстрационная база на сайте «1С»

Назначение системы

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

Система проектирования прикладных решений разработана как конфигурация на платформе «1С:Предприятие 8.3».

Преимущества для пользователей

Использование СППР позволяет:

Руководителям проектов

  • Организовать централизованный учет требований и пожеланий к информационной системе.
  • Выстроить целостную модель системы, отталкиваясь от автоматизируемых процессов, с возможностью проверки корректности модели.
  • Управлять изменениями в проекте.
  • Формировать план выполнения проекта.
  • Контролировать выделение ресурсов в рамках проектов и конкретных задач.
  • Анализировать завершенность проекта (выполнение необходимых задач, отсутствие ошибок).

Разработчикам

  • Спроектировать функциональность в общем контексте проекта.
  • Учитывать при проектировании зафиксированные требования и пожелания.
  • Единообразно документировать проект.
  • Планировать собственную работу.
  • Отслеживать необходимость собственного участия в смежных проектах.
  • Организовать обмен сообщениями с участниками проекта, в контексте интересующих объектов.

Техническим писателям

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

Тестировщикам

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

Внедренцам

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

Процесс проектирования в СППР

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

  • Описание автоматизируемых процессов
  • Создание логической модели проектируемой системы
  • Разработка архитектуры
  • Подготовка справки
  • Управление проектом и изменениями
  • Работа с ошибками
  • Тестирование, прочие возможности

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

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

Описание автоматизируемых процессов

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

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

Процессы

При описании процесса фиксируется его описание, отражающее суть процесса, события начала и окончания процесса.

Описание процесса

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

Шаги процесса

Создание логической модели проектируемой системы

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

Логическая модель в СППР строится с использованием методологии IDEF0. В рамках создания логической модели описываются функции системы и производится их декомпозиция.

Функции системы

Основой описания функции является ее IDEF- схема. Схема позволяет в наглядной форме отразить взаимосвязь отдельных (дочерних) функций, потоков данных и исполнителей.

IDEF- схема

Разработка архитектуры

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

Объекты метаданных

ER-диаграмма помогает анализировать структуру метаданных:

ER-диаграмма объекта

Подготовка справки

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

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

Подготовка справки

Управление проектом и изменениями

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

Использование технических проектов обеспечивает внесение изменений в имеющийся проект таким образом, чтобы эти изменения были увязаны с логической моделью, были прозрачны и информативны для других участников проекта

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

Работа с задачами

Тестирование, работа с ошибками

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

Сценарий работы пользователя

Информация об ошибках ведется по разрабатываемым проектам, в разрезе версий, сроков исправления, разделов проекта, статусов и т. д. Функционал системы предлагает готовую методику работы с ошибками, с возможностью формирования различных отчетов, публикации информации об ошибках. Система позволяет настроить связи между проектами, указать, какие проекты-библиотеки включаются в проект, с учетом конкретных версий проектов. Это позволяет получать информацию о наличии в проекте ошибок, источниками которых являются используемые библиотеки.

Ошибка сценария График ошибок по датам

Прочие возможности

Помимо перечисленных возможностей, СППР содержит следующую функциональность:

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

1С:Управление проектным офисом

Управление ресурсами предприятия

Система поддерживает три варианта управленческой структуры предприятия:

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

В системе используются ролевая структура трудовых ресурсов и двухуровневое планирование проектных работ: на этапе предварительного планирования работы планируются по ролям (специальностям), затем на этапе оперативного планирования производится распределение работ между трудовыми ресурсами.

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

На уровне пула трудовых ресурсов система позволяет производить:

  • Моделирование ресурсных ограничений предприятия путём ввода в систему плановой мощности для каждой из ролей (специальностей). Сопоставление плановой и фактической мощности ролей трудовых ресурсов, выявление «узких мест».
  • Анализ запланированной и фактической загрузки ресурсов, выявление «перегруженных» и «недогруженных» трудовых ресурсов.

Реализованные в системе концепции «диспетчера» и «владельца ресурсов» позволяют персонализировать взаимодействие с системой тех исполнителей, которые не имеют физического доступа к системе (работа на объектах, аутсорсинг, и т.п.).

Управление проектами

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

  • Ручной ввод соответствующих документов через панель управления проектом.
  • Загрузка данных проекта из файла MS Project.
  • Загрузка данных проекта из шаблона, хранящегося в системе.

Также план проекта может быть введён в систему комбинированным способом: часть данных берётся из шаблона, часть загружается из файла MS Project, часть данных вводится и/или корректируется вручную.

Система поддерживает два метода оперативного планирования проектных работ:

  • С использованием ролевой структуры трудовых ресурсов и матричной структуры управления. В этом случае «проектный» руководитель управляет планом проекта, а «функциональный» руководитель управляет выполнением работ. Назначение трудовых ресурсов на конкретные работы производится с учётом выполняемых ролей.
  • Без использования ролевой структуры трудовых ресурсов и матричной структуры управления. В этом случае «проектный» руководитель управляет и планом проекта, и выполнением работ. Назначение трудовых ресурсов на конкретные работы производится без учёта выполняемых ролей.

Жизненный цикл проекта в рамках системы состоит из пяти стадий:

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

Ключевым механизмом контура управления проектами является механизм актуализации проекта: на основании данных о фактическом выполнении (или же срыве выполнения) проектных работ нижнего уровня декомпозиции система производит полный перерасчёт календарных сроков всех элементов проекта. Актуализация проекта, выполняемая регулярно, позволяет руководителю получать достоверную информацию о состоянии работ и оперативно реагировать на возникающие проблемы.

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

  • План-фактный анализ проектных задач по срокам, длительности, стоимости, затратам ресурсов.
  • Анализ контрольных событий проекта, расчёт прогнозируемых и фактических финансовых санкций.

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

Управление финансами

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

Для бюджета расходов по проекту в системе предусмотрена функция автоматического формирования элементов бюджета. Бюджет расходов формируется по информации о затратах, запланированных на привлечение трудовых, материальных и финансовых ресурсов к выполнению проектной задачи. Автоматическое формирование производится на основании схемы распределения суммы, запланированной на привлечение того или иного ресурса, по статьям затрат. Схема распределения настраивается пользователем, причём допустима ситуация, когда по статьям бюджета расходов распределяется не вся запланированная сумма, а только какая-то часть.

Ключевой особенностью контура управления финансами проекта является неявная привязка элементов бюджета к календарным периодам. При планировании бюджетов период задаётся в виде набора правил, описывающих привязку элемента бюджета к временным рамкам проектной задачи. При изменении сроков проектной задачи (в том числе и при выполнении актуализации проекта) система производит автоматический перерасчёт финансовых планов.

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

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

На уровне бюджетов проекта система позволяет производить:

  • План-фактный анализ бюджета доходов, расходов и движений денежных средств по проекту в разрезе проектных задач, статей бюджета, контрагентов, договоров и календарных периодов.
  • Анализ отклонений между данными текущего финансового плана, любой из версий финансового плана и фактическим положением дел, выявление отклонений.

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

Прежде чем говорить об инструментах проектирования, хотелось бы остановиться на немаловажном вопросе: «для чего нужно проектирование информационных систем?». Достаточно популярным, особенно в среде 1С специалистов, является мнение что проектирование системы — это лишние трудозатраты. Я бы сказал, оно не безосновательно. Многие из задач при внедрении систем являются довольно стандартными и требуют лишь трудозатрат на разработку. Очень часто не создается новых механизмов и инструментов, а лишь «дотачиваются» существующие, притом под нужды заказчика, которые регулярно меняются.

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

📌 Реклама Отключить

А когда проектирование имеет смысл:

  1. Есть общая стратегия компании, и развитие ИТ систем – часть этой стратегии.
  2. Есть понимание от менеджмента какие задачи требуется решить посредством внедрения/развития информационной системы.
  3. Есть формальное понимание/описание бизнес процессов компании, или планируется его создание.

Ниже схематично представлены предпосылки к созданию проекта системы:

Собственно, все начинается со стратегии. Инструментарий для создания стратегии компании редко бывает специализированным. Это скорее нечто, что должно быть в голове у топ менеджера. Далее строится модель бизнес процессов (которая должна присутствовать для достижения стратегических целей). Здесь уже в ход идут инструменты моделирования – ARIS, Business Studio. И только после этого речь заходит о модели ИТ процессов. У «продвинутых» западных вендоров для этого есть специализированные средства – УSAP интегрированный ARIS, у IBM – RUP, у Microsoft – MSF, интегрированная в Visual Studio. Вот и у 1С появился собственный инструмент – 1С:СППР.

📌 Реклама Отключить

Теперь возникает второй вопрос: «А как на практике используется 1С:СППР»? В данном случае могу рассказать только о своей личной практике. К сожалению, она может не совпадать с тем, для чего в 1С планировали 1С:СППР. В моей практике 1С:СППР использовался для следующих задач:

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

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

📌 Реклама Отключить

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

В итоге, все функции, которые, на мой взгляд, должны лечь на 1С:СППР можно разбить на следующие 4 части:

1) Функции моделирования

a. Модель системы, связь с моделью БП (в разных нотациях)

b. Связь модели системы с метаданными и алгоритмами 1С

c. Интеграция со средами моделирования

2) Функции коллективной работы

a. Работа с требованиям

b. Работа с ошибками

📌 Реклама Отключить

3) Функции документирования

a. Связь документации с моделью

b. Экспорт документации в 1С и Word

4) Функции организации разработки и тестирования

a. Спецификации и задачи на разработку

b. Результаты тестирования и отработки ошибок

В типовой 1С:СППР очень хорошо реализован блок (1), за исключением того, что хотелось бы конечно иметь возможность представлять модель в разных нотациях. Нам была ближе EPC, в 1С:СППР реализована только IDEF0.

Функции коллективной работы в текущей версии реализованы в полном объеме, на мой взгляд конечно, чаще всего это необходимо при работе с ошибками и требованиями.

С документированием возникают уже проблемы. Основной функционал, которого не хватает 1С:СППР – экспорт в Word. Ведь итогом работы проектировщика должна быть спецификация на разработку (ТЗ/ЧТЗ – кто как называет). А спецификация — это нечто, что человек должен иметь возможность прочитать; то есть текстовый файл. Опять же, вордовским файлом должна оформляться документация по системе и проектная документация. Но традиционно 1С не сильно любит интегрироваться с продуктами Microsoft Office. Это противоречит принципам кроссплатформенности, делает решение зависимым от внешних приложений и существенно увеличивает сложность разработки.

📌 Реклама Отключить

Функционала для организации разработки и тестирования в 1C:СППР просто не существует. Хотя не понятно почему. Редко встретишь опытного разработчика, который хоть раз в своей жизни не написал бы систему учета задач. Если ориентироваться на тот же SAP – в Solution Manager есть как функционал проектирования так и полноценный Service Desk.

Собственно, данный функционал относительно СППР был доработан – основные доработки 1С:СППР касались вывода в Word и создания системы учета задач.

Теперь более подробно рассмотрим функционал типовой 1С:СППР новой версии:

📌 Реклама Отключить

Итак, относительно первой версии появилось много чего интересного:

1) Нормальная работа с метаданными – загрузка метаданных непосредственно из конфигурации, представление, дополнительные свойства объектов метаданных. На разработку подобного функционала в первой версии мы потратили значительное количество времени.

2) Моделирование системы в нотации IDEF. 1С много затратили на разработку данного функционала. Действительно существенный шаг вперед, но, как писал выше, для нас оказалась привычнее и удобнее нотация EPC. Она в 1С:СППР, к сожалению, не реализована.

3) Сбор требований. Функционал очень нужный на проектах.

4) ER модель метаданных. Первое впечатление было «мечта студента». Если кто-то писал диплом по 1С это бы существенно помогло. На самом деле функционал очень полезен и в повседневной рабочей практике. Даже просто загрузив в 1С:СППР механизмы типового прикладного решения построив ER диаграмму по нужным объектам можно гораздо быстрее и проще разобраться как работает тот или иной механизм. О пользе подобных диаграмм при составлении спецификаций можно и не говорить. За данную возможность можно сказать «большое спасибо».

📌 Реклама Отключить

5) Работа с ошибками, тоже очень нужный, но достаточно простой механизм системы.

6) Есть даже инструментарий для написания справочной информации. Он не очень мощный и удобный больше вследствие ограниченности встроенного в 1С редактора текстов, но привязка справки к метаданным и экспорт справочных файлов очень удобный функционал, которым теперь можно пользоваться.

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

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

📌 Реклама Отключить

Итак, что мы получаем от использования 1С:СППР:

1) Разработчики отделены от проектировщиков. Best Practice из SAP welcome. Наверное, это правильно, но для того, чтобы это было возможно, система просто необходима. В то же время, при наличии такой системы мы можем сказать, что практически любой разработчик способен выполнять работы практически по любой задаче. Это «открывает двери». Например сегодня у вас 3 разработчика, а завтра может стать 30… т.е. варианты для привлечения внешних подрядчиков не ограничены.

2) Генерация проектной документации. В нашем случае ее просто тома. Представьте к примеру задачу описать все метаданные УПП… 1С:СППР просто в десятки раз упрощает данный процесс.

📌 Реклама Отключить

3) Учет задач – когда он интегрирован это очень удобно. Разработчик может сразу видеть все по назначенной задаче. При необходимости может подняться «уровнем выше» чтобы что-то понять/уточнить для себя. Как проектировщик так и разработчик могут оценивать трудозатраты на разработку и согласовывать оценки. Разработчик может писать вопросы к спецификациями и оперативно наблюдать изменения в них

4) Весь проект есть в системе. По каждому объекту метаданных вы можете отследить когда, для чего и зачем он был сделан.

Мы уже пошли в чем то дальше чем 1С:СППР в развитии системы, но есть вещи которых нахватает как в нашей системе так и в типовой 1С:СППР:

1) Управление изменениями. Что поменялось, кто согласовал? На что повлияет это изменение. Очень важный момент, конечно сложный в реализации, но управление изменениями сразу вывело бы систему на новый уровень и повысило бы ее полезность.

📌 Реклама Отключить

2) Связь с хранилищем конфигурации. Конечно последнего этапа в цепочке не хватает немного. Если бы в системе можно было получить информацию по какому заданию/спецификации была эта разработка?

3) Интеграции с ARIS/Business Studio. К сожалению, встроенные средства 1С существенно проигрывают специализированным в плане удобства и функциональности для постраения диаграмм EPC/IDEF.

Итого, 1С:СППР очень функциональный и полезный в практике продукт. Очевидно, что 1С движется в правильном направлении. Может что-то еще не так, чего-то не хватает, поэтому с нетерпением ждем развития системы, ну или дорабатываем сами.

Процесс проектирования в СППР

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

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

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

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

При описании процесса фиксируется его описание, отражающее суть процесса, события начала и окончания процесса.

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

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

Основой описания функции является ее IDEF- схема. Схема позволяет в наглядной форме отразить взаимосвязь отдельных (дочерних) функций, потоков данных и исполнителей.

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

Проектирование интерактивных операций

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

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

Работа с требованиями

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

Работа с ошибками

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

Помимо перечисленных возможностей, СППР содержит следующую функциональность:

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

  • 1С:Предприятие 8. Конфигурация «Система проектирования прикладных решений». Редакция 2.0. Руководство пользователя
    • Введение
      • Структура руководства
      • Соглашение о терминах и сокращениях
    • Глава 1. Концепция проектирования прикладных решений
      • 1.1. Основные задачи, решаемые системой
      • 1.2. Основные возможности системы
      • 1.3. Этапы проектирования
    • Глава 2. Описание автоматизируемых процессов
    • Глава 3. Логическое проектирование конфигурации
      • 3.1. Последовательность проектирования логической модели
      • 3.2. Проектирование функциональной модели
        • 3.2.1. Построение дерева функций
        • 3.2.2. Проектирование конечной функции и описание ее свойств
        • 3.2.3. Нотация схем функциональной модели IDEF0
      • 3.3. Проектирование профилей пользователей
      • 3.4. Пример проектирования логической функциональности
      • 3.5. Использование функциональных моделей библиотек и других проектов
        • 3.5.1. Настройка использования функциональной модели
        • 3.5.2. Работа с заимствованными объектами функциональной модели
        • 3.5.3. Обновление используемой модели, сравнение моделей
    • Глава 4. Разработка архитектуры
      • 4.1. Общие принципы разработки архитектуры
      • 4.2. Синхронизация данных
      • 4.3. Проектирование подсистем
      • 4.4. Проектирование объектов метаданных
    • Глава 5. Проектирование работы пользователя с интерфейсом
      • 5.1. Принципы проектирования работы пользователей с интерфейсом
      • 5.2. Проектирование форм объектов метаданных
    • Глава 6. Проектирование прав доступа
      • 6.1. Проектирование ролей
      • 6.2. Проектирование ограничений доступа
      • 6.3. Проектирование профилей пользователей
    • Глава 7. Аудит формальных правил проектирования
    • Глава 8. Управление проектом и изменениями
      • 8.1. Целевые задачи
      • 8.2. Ведение технических проектов
      • 8.3. Управление идеями
      • 8.4. Работа с идеями и ошибками в рамках технических проектов
      • 8.5. Работа с задачами по техническим проектам
      • 8.6. Порядок работы с хранилищами технических проектов при разработке
      • 8.7. Проектные решения
      • 8.8. Контрольные вопросы по проекту
      • 8.10. Контроль выполнения технических проектов
    • Глава 9. Работа с ошибками
      • 9.1. Регистрация ошибки
        • 9.1.1. Регистрация ошибки пользователем
        • 9.1.2. Автоматическая регистрация ошибки
      • 9.2. Рассмотрение ошибки
      • 9.3. Исправление ошибки
      • 9.4. Подтверждение исправления ошибки
      • 9.5. Отзыв ошибки
      • 9.6. Работа с ошибками, требующими проектирования
      • 9.7. Ошибки наследуемых версий
      • 9.8. Возврат ошибки
      • 9.9. Отчеты по ошибкам
      • 9.10. Автоматическое формирование патчей для исправления ошибок
    • Глава 10. Встраиваемые механизмы
      • 10.1. Концепция документирования процесса встраивания
      • 10.2. Инструменты для документирования процесса встраивания
      • 10.3. Управление статусами встраиваемых функций механизмов
    • Глава 11. Механизм автоматизированного тестирования
      • 11.1. Тестовые сценарии и язык Gherkin
      • 11.2. Инфраструктура тестирования
      • 11.3. Методология автоматического тестирования
        • 11.3.1. Жизненный цикл сценария автоматического теста
        • 11.3.2. Методология тестирования
      • 11.4. Настройка подсистемы тестирования
      • 11.5. Процессы
      • 11.6. Сценарии работы пользователей
        • 11.6.1. Синтаксис языка Turbo Gherkin для СППР
        • 11.6.2. Команды управления тестовым сценарием
        • 11.6.3. Порядок формирования тестового сценария
      • 11.7. Шаги сценариев пользователей
      • 11.8. Эталонные базы тестирования
      • 11.9. Реализация методологии с использованием Vanessa-Automation и СППР
        • 11.9.1. Концепция тестирования с помощью обработки Vanessa-Automation
        • 11.9.2. Настройка конфигурации для работы с обработкой Vanessa-Automation
      • 11.10. Запуск сценариев и и анализ ошибок
        • 11.10.1. Запуск сценариев
        • 11.10.2. Анализ ошибок по результатам работы теста
    • Глава 12. Разработка обработчиков обновления информационной базы
    • Глава 13. Подготовка справки
      • 13.1. Формирование справки
      • 13.2. Загрузка справки в конфигурацию
      • 13.3. Автоматическая загрузка справки в хранилище
    • Глава 14. Механизм задач
      • 14.1. Создание задачи
        • 14.1.1. Создание новой задачи
        • 14.1.2. Создание задачи по шаблону
        • 14.1.3. Права на изменение задач
        • 14.1.4. Взаимодействие членов команды по задаче
      • 14.2. Взаимосвязи задач
      • 14.3. Статусы задач
      • 14.4. Согласование ресурсов по задачам
        • 14.4.1. Настройки для согласования ресурсов
        • 14.4.2. Процесс согласования ресурсов по задачам
        • 14.4.3. Настройки хода согласования в списках
      • 14.5. Протокол взаимодействия по задаче
      • 14.6. Контроль за исполнением задачи
      • 14.7. Формы списков задач
        • 14.7.1. Список «Задачи процесса»
        • 14.7.2. Список «Мои задачи»
        • 14.7.3. Список «Задачи предмета»
        • 14.7.4. Список «Связанные задачи»
        • 14.7.5. Быстрые отборы в списках
    • Глава 15. Внутренние сервисы
      • 15.1. Сервисы автоматической регистрации ошибок тестирования
      • 15.2. Механизм использования ключевых операций
        • 15.2.1. Хранение перечня ключевых операций
        • 15.2.2. Ключевые операции в технических проектах
        • 15.2.3. Выгрузка ключевых операций
        • 15.2.4. Загрузка ранее встроенных ключевых операций
      • 15.3. Механизм контроля исполнения стандартов разработки
        • 15.3.1. Список стандартов разработки
        • 15.3.2. Команды управления списком стандартов
        • 15.3.3. Создание стандарта разработки
        • 15.3.4. Настройка и синхронизация стандарта разработки
        • 15.3.5. Статистика изучения стандартов разработки
        • 15.3.6. Привязка стандартов к ошибкам
    • Глава 16. Сервисные возможности
      • 16.1. Контроль изменений
      • 16.2. Групповое изменение объектов
        • 16.2.1. Команда «Изменить выделенные»
        • 16.2.2. Ключевые реквизиты объекта
        • 16.2.3. Особенности группового изменения реквизитов администратором
      • 16.3. Поиск объектов по коду
      • 16.4. Работа с файлами
        • 16.4.1. Настройка программы
        • 16.4.2. Присоединенные файлы
        • 16.4.3. Общие файлы
      • 16.5. Полнотекстовый поиск
        • 16.5.1. Настройка программы
        • 16.5.2. Настройка параметров полнотекстового поиска
        • 16.5.3. Использование полнотекстового поиска
      • 16.6. Дополнительные реквизиты и сведения
        • 16.6.1. Настройка программы
        • 16.6.2. Назначение новых дополнительных реквизитов и сведений
        • 16.6.3. Использование дополнительных реквизитов и сведений
      • 16.7. Работа с отчетами
        • 16.7.1. Панель отчетов
        • 16.7.2. Работа с отчетом
        • 16.7.3. Отправка отчета при формировании отчета
    • Глава 17. Настройка программы и администрирование
      • 17.1. Ведение списка пользователей
      • 17.2. Персональные настройки пользователей
        • 17.2.1. Общие сведения о пользователе
        • 17.2.2. Настройки работы с файлами
        • 17.2.3. Работа с базами
        • 17.2.4. Настройка уведомлений
        • 17.2.5. Настройка тестирования
      • 17.3. Основные настройки программы
        • 17.3.1. Уведомления пользователей о сборках
        • 17.3.2. Работа с «1С:Предприятием» на сервере
        • 17.3.3. Настройки работы с ошибками
        • 17.3.4. Задачи
        • 17.3.5. Публикация информационной базы
        • 17.3.6. Контактная информация
        • 17.3.7. Дополнительные реквизиты и сведения
        • 17.3.8. Полнотекстовый поиск данных
        • 17.3.9. Электронная подпись и шифрование
        • 17.3.10. Тестирование
      • 17.4. Настройки проектов
        • 17.4.1. Общая информация
        • 17.4.2. Работа с метаданными
        • 17.4.3. Загрузка метаданных
        • 17.4.4. Работа с ошибками
        • 17.4.5. Использование проектов-библиотек
        • 17.4.6. Настройка уведомлений
        • 17.4.7. Прочие настройки
        • 17.4.8. Разделы проекта
        • 17.4.9. Версии проекта
        • 17.4.10. Сборки версии проекта
      • 17.5. Настройка учетных записей
        • 17.5.1. Настройка системной учетной записи
        • 17.5.2. Учетные записи электронной почты
      • 17.6. Печатные формы, отчеты и обработки
        • 17.6.1. Настройка макетов печатных форм
        • 17.6.2. Расширения
        • 17.6.3. Внешние компоненты
        • 17.6.4. Дополнительные отчеты и обработки
      • 17.7. Графики работы
        • 17.7.1. Ввод новых графиков работы
      • 17.8. Разделы общих задач
      • 17.9. Стили форматирования
      • 17.10. Замещение пользователей по работе с ошибками
      • 17.11. Обслуживание системы
        • 17.11.1. Журнал регистрации
        • 17.11.2. Активные пользователи
        • 17.11.3. Блокировка работы пользователей
        • 17.11.4. Удаление помеченных объектов
        • 17.11.5. Отчеты и обработки
        • 17.11.6. Регламентные операции
        • 17.11.7. Корректировка данных
        • 17.11.8. Результаты обновления программы
      • 17.12. Настройки интеграции
        • 17.12.1. Автоматизированная проверка конфигураций
        • 17.12.2. Настройка интеграции с конфигурацией «Документооборот»
        • 17.12.3. Публикация веб-сервиса интеграции
        • 17.12.4. Настройка параметров системы
        • 17.12.5. Персональные настройки пользователя
        • 17.12.6. Настройки заполнения объектов
        • 17.12.7. Использование интеграции
      • 17.13. Выгрузка и загрузка проектной информации
    • Глава 18. Организация работы с использованием распределенных информационных баз
      • 18.1. Настройка использования распределенных информационных баз
        • 18.1.1. Настройка синхронизации в центральной базе
        • 18.1.2. Настройка синхронизации в подчиненном узле
        • 18.1.3. Обновление распределенной информационной базы
        • 18.1.4. Общие рекомендации по настройке синхронизации данных
      • 18.2. Выполнение синхронизации данных