Сппр 1с что это

8

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Информация для пользователей и партнеров №25985 от 01.07.2019

Фирма «1С» объявляет о выпуске редакции 2.0 конфигурации «Система проектирования прикладных решений». С 09.07.2019 данный продукт будет поставляться с новой редакцией конфигурации и обновленной документацией:

Код

Наименование

Цена для пользователя, руб.

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

Обновление конфигурации «Система проектирования прикладных решений» до редакции 2.0 в других программных продуктах будет произведено позднее, после обновления моделей соответствующих прикладных решений.

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

НОВЫЕ ВОЗМОЖНОСТИ КОНФИГУРАЦИИ

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

Новая реализация функционального моделирования

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

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

Использование функциональных моделей библиотек и других проектов

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

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

Автоматизированное тестирование

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

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

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

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

Следует отметить, что в составе «1С:Корпоративного инструментального пакета 8» (см. http://v8.1c.ru/expert/etp.htm) имеется конфигурация «Сценарное тестирование», которая позволяет создавать сценарии для тестирования конфигураций и выполнять эти сценарии для выявления ошибок. Основное отличие подсистемы автоматизированного тестирования в СППР от конфигурации «Сценарное тестирование» – это работа в единой среде СППР, когда сценарии тестирования увязываются с функциональной моделью и описанием автоматизируемых процессов, позволяя обеспечить и проконтролировать тестовое покрытие разрабатываемой функциональности. При этом регистрация и обработка выявленных ошибок выполняются автоматически непосредственно в СППР с привязкой к метаданным тестируемой конфигурации, версиям конфигурации, ответственным за разработку конкретных объектов конфигурации и т. п.

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

Задачи, согласование ресурсов

В редакции 2.0 СППР реализован новый механизм работы с задачами, планирования и согласования ресурсов. Механизм стал более гибким и универсальным. Так, ведение шаблонов задач обеспечит быстрое создание наборов задач с заданной иерархией, описанием и ответственными. Это позволит выстроить типовые процессы работы с задачами – например, выполнение технических проектов с необходимым контролем.

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

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

Поддержка работы с общими механизмами конфигурации

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

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

Патчи

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

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

Работа с распределенными информационными базами

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

Подробное описание СППР см. в приложении к настоящему информационному письму, а также на странице http://v8.1c.ru/model/. Также доступна онлайн-демоверсия.

ИСПОЛЬЗОВАНИЕ СППР ПОЗВОЛЯЕТ

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

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

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

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

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

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

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

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

Внедренцам

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

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

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

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

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

Наличие формальных правил проверки дает возможность выявить и устранить ошибки и несоответствия в проекте.

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

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

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

ПОРЯДОК ПЕРЕХОДА НА РЕДАКЦИЮ 2.0 ПОЛЬЗОВАТЕЛЕЙ КОНФИГУРАЦИИ «СИСТЕМА ПРОЕКТИРОВАНИЯ ПРИКЛАДНЫХ РЕШЕНИЙ»

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

Для работы редакции 2.0 необходима версия платформы «1С:Предприятие» 8.3.12 или выше.

Версии 2.0.1 конфигурации и 8.3.12 платформы можно получить в сервисе «1С:Обновление программ» на портале 1С:ИТС https://portal.1c.ru/, а также в составе августовского выпуска 1С:ИТС за 2019 год.

Перечисленные дистрибутивы также можно получить через партнеров фирмы «1С».

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

Для эффективного освоения и использования новой редакции выпущено новое описание конфигурации:

Код

Наименование

Цена для пользователя, включая НДС 20 %,
руб.

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

Для пользователей, имеющих действующий договор 1С:ИТС, на сайте its.1c.ru доступна электронная версия документации, см. https://its.1c.ru/db/sppr2doc.

Бумажную книгу зарегистрированные пользователи конфигурации «Система проектирования прикладных решений» могут приобретать в необходимом количестве в соответствии с регламентом, описанным в информационном письме № 8538 от 20.06.2008 года. Для приобретения документации необходимо обратиться к партнеру фирмы «1С» или непосредственно в фирму «1С». Список партнеров-франчайзи публикуется на сайте фирмы «1С» по адресу http://www.1c.ru/rus/partners/franch-citylist.jsp.

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

ПОДДЕРЖКА РЕДАКЦИИ 1.1

Поддержка редакции 1.1 конфигурации СППР предполагается до 01.07.2020.

После указанной даты поддержка редакции 1.1 не планируется. Фирма «1С» рекомендует пользователям переходить на новую редакцию 2.0.

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

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

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

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

Возможности использования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Следующий рисунок иллюстрирует задачи в рамках технического проекта.

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

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

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

На следующем рисунке представлен график ошибок.

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

1С СППР и оценка сроков и стоимости проектов методом COCOMO II

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

Как обосновать заказчику, что данная вами оценка сроков исполнения проекта объективна?

Как измерить маржинальность проекта до его начала, на этапе пресейла?

Каким способом оценить диапазон торга по цене проекта, чтобы предотвратить выход в убыток?

Как объективно рассчитать потребность на проекте в членах команды, которые не являются разработчиками (бизнес-аналитики, методологи, технические писатели и т.п.), как формализовать результат их работы наиболее простым и доступным способом?

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

Вступление

1С Система Проектирования Прикладных Решений выпущена на рынок 6 лет назад и в июле 2019 доросла до версии 2. Основана на технологиях SADT и каскадной модели разработки. Впрочем, позволяет вести Scrum/Agile разработку на отдельных этапах.

Предназначена для сложных, длительных проектов, исполняемых многосоставной командой с частым кадровым замещением. Включает в себя функционал управления проектами, описания бизнес-процессов, проектирования архитектуры и функциональности информационных систем, разработки ПО и сопровождения ИС, а также автотестирования на базе Vanessa / Gherkin.

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

Основная проблема использования 1С СППР в настоящее время

Основной проблемой использования 1С СППР в настоящее время (в основном используется версия 1) является крайне некорректное использование 1С СППР как технологии.

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

С постановкой задач программистам и обработкой тикетов пользователей прекрасно справляются существующие на рынке системы (JIRA и т.п.). При таком использовании на разработчиков СППР ложится ещё одна времяёмкая бюрократическая надстройка, отнимающая время от «чистого» кодинга.

Разработчик становится обязанным описывать функциональность внедряемой/дорабатываемой системы, дабы обеспечить постановку задач программистам со ссылками на объекты метаданных («общий язык» в терминах Эрика Эванса в его работе «Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем»).

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

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

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

А самое главное, как объективно рассчитать потребность на проекте в членах команды, которые не являются разработчиками (бизнес-аналитики, методологи, технические писатели и т.п.), как формализовать результат их работы наиболее простым и доступным способом?

Почему COCOMOII?

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

Как же оценить сроки и стоимость на этапе пресейла в условиях недостатка информации? А по ходу проекта с учётом изменений (бич всех проектов)?

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

Почему 1С СППР?

Всё дело в том, что 1С СППР основана на технологиях SADT и «общего языка» (более подробно это изложено в отдельной моей статье). Именно SADT интегрирует процесс моделирования с процессом разработки на основе «общего языка». А «общий язык» позволяет иметь базис для расчёта оценочных показателей сроков.

Кратчайший курс COCOMOII

Методика COCOMO возникла в 1963 году в ответ на потребность для быстрой и несложной оценки трудоёмкости и сроков разработки программных продуктов в предстоящих проектах. Базисом модели COCOMO и её следующего этапа COCOMOII является число строк программного кода (KSLOC – тысяча строк логического кода, т.е. строки кода выражающей операцию). Этот базис имеет как результат любой проект по разработке ПО, это своего рода квинтэссенция проекта.
(Далее будем иметь в виду, что COCOMO отличается от COCOMOII тем, что скалярные параметры формулы COCOMO заменены на таблицу параметров COCOMOII, но суть метода осталась прежней).
Таким образом, имея накопленный багаж проектов, любой разработчик может иметь рамочную базовую оценку каждого следующего проекта. Разумеется это весьма приблизительная оценка, но на этапе пресейла и такая оценка лучше, чем ничего. Для её уточнения базис KSLOC по определённой формуле корректируется на уточняющие коэффициенты. Мы не будем приводить формулу, она несложна и доступна в интернете. Суть в том, что коэффициенты этой формулы каждый разработчик может разработать сам на основе статистики прежних проектов и сравнивать с каноничными параметрами формулы или… не сравнивать и использовать только свою формулу.
Наличие формулы с параметрами говорит о том, что все проекты системного интегратора (или все внутренние проекты организации) должны быть прокодированы и классифицированы по всем этим параметрам. Чем больше проектов в багаже разработчиков, тем больше однотипных проектов к новому открывающемуся проекту можно подобрать для оценки (отфильтровать непрофильные проекты), тем точнее оценка.

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

Детализацию параметров проектов можно проводить на своё усмотрение и возможности. Чем больше детализации, тем точнее оцениваются сроки и стоимость будущего проекта.
Какой же KSLOG выставляется на этапе пресейла с неточным описанием результата? Только эмпирический из базы данных проектов интегратора (исполнителя). Использоваться при этом может один набор параметров проектов. Если есть точное описание желаемого результата проекта (программного продукта), то может использоваться расширенный набор параметров проекта.
Вот и вся суть метода COCOMO.

Переход от оценки труда разработчиков к оценке труда аналитиков и методологов

Внимательные и опытные читатели воскликнут:
«Ну, ладно! При всех плюсах и минусах метода COCOMO, он предназначен для оценки проектов по созданию программного обеспечения. Труд разработчиков, программистов можно оцифровать в условных KSLOC. Но как быть с аналитиками и методологами, руководителями и менеджерами проектов? А уж при чём тут 1С СППР»

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

Псевдокод

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

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

Если проект сдаётся по ГОСТовским требованиям, то структура проектных документов задаётся этими стандартами, в ином случае, она создаётся на усмотрение исполнителя или по требованиям договора с заказчиком.

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

Ответ — самым прямым образом – СППР и содержимое её справочников, заполненных по проекту, будет сама структурированным объектом данных и результатом работы. Который очень удобно передавать заказчику. Все создаваемые в ходе проекта документы будут являться вложенными документами к объектам конфигурации СППР.

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

1. Структура (оглавление) документа;
2. Тест документа;
3. Строка таблицы документа (таблица);
4. Рисунок (графический объект).

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

1С СППР и псевдокод

Встаёт вопрос, как разместить в 1С СППР псевдокод.

Это можно сделать через справочник «Объекты данных». Создаётся отдельная группа «ВЫХОДНЫЕ ДОКУМЕНТЫ», внутри неё подгруппы под каждый вид документов, далее ещё подгруппы под каждый отдельный документ, а внутри уже этих подгрупп как элементы справочника строки оглавления проектного документа.

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

Текст самого проектного документа можно набирать по абзацам как текстовое поле элемента справочника «Объекты данных».

К чему следует стремиться при описании структуры выходных проектных документов в справочнике «Объекты данных»?

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

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

При увязке каждого элемента или группы справочника «Объекты данных» с Требованиями (как сформулированные заказчиком, так и членами проектной команды, детализированными до метаданных), то в итоге можно получить сквозную связку Требования – Объекты метаданных – Выходные проектные документы. В СППР 2.0 аналогом «Требований» выступают «Идеи».
По мере накопления опыта исполнения проектов в 1С СППР будет выкристаллизовываться такая структура справочника, которая будет одинаковой на всех однотипных проектах. Следовательно, для нового проекта её достаточно просто скопировать. А для идентичных по выходным результатам проектов можно скопировать и текст (таблицу).

Резюме

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

Это должно существенно облегчить А) торг с заказчиком Б) оценку ожидаемой прибыли.

Мастер-класс СППР

В СППР немного объектов метаданных, и все вращается вокруг двух основных объектов – это «Проект» и «Тех. проект».

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

Тех.проект – это изменения конфигурации, либо какая-то выполняемая задача. К тех. проекту могут быть прикреплены ошибки и задачи. В терминах СППР задача – это некоторое задание исполнителю в рамках тех. проекта или в рамках какого-то объекта метаданных.

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

Внутри проекта есть модели. СППР поддерживает две модели – модель процессов и модель функций:

Модель процессов описывается просто в текстовом формате;

А модель функций реализуется в нотации IDEF0.

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

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

Возможность генерации справки – вы можете в процессе работы над тех. проектом, сразу писать справку к объектам, и система будет генерировать ее в HTML-формате. И потом эту справку можно централизованно загрузить в конфигурацию.

Механизмы проверки IDEF-моделей на соблюдение стандартов IDEF.

И еще одна интересная возможность – можно автоматизированно генерировать шаблоны прав.

Процесс работы с СППР. Продвижение тех. проектов по контрольным точкам

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

Почему? В саму СППР заложен очень интересный процесс – это продвижение тех. проектов по контрольным точкам. Он простой, но эффективный. Он позволяет всегда понимать, на какой стадии находится ваш тех. проект. Стадия = контрольная точка. Внутри определенной стадии тех. проекта рождаются какие-то задачи, ошибки. И тех. проект переходит со стадии на стадию. Например, на первой стадии мы назначили задачи, выполняем их, отмечаем, что этот этап согласован, и тех. проект таким образом продвигается.

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

Давайте посмотрим, как это выглядит на практике.

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

Итак, мы выбрали на начальной странице некоторый проект, и теперь список тех. проектов относится именно к этому проекту.

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

Например, если вы работаете с бухгалтерией, у вас может быть этап «Верификация требований главного бухгалтера», под который требуется отдельное согласование. А если вы работаете с УТ, то там вы, возможно, работаете просто по заявкам, без дополнительных согласований.

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

Каким образом ведется работа? Например, пользователь считает, что к этой работе можно приступать. Он вручную ставит здесь статус «Готово к согласованию». И тех. проект приходит ответственному пользователю, за которым закреплена эта контрольная точка.

Дальше – я у себя на главной странице в «Текущих делах» вижу, что тех. проект пришел ко мне на согласование (гиперссылка «Согласовать»).

Я точно так же вручную открываю тех. проект, и проставляю статус контрольной точки «Согласовано». Активизируется следующая контрольная точка. Пользователь в рамках этой контрольной точки что-то выполняет, опять же ставит «Согласовано».

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

Структура этапов работы с тех. проектом

У нас это выглядит таким образом – у нас четыре этапа.

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

А на второй этап нашего проекта, когда идет уже настройка бюджетов, мы открываем два-три тех. проекта (насколько мы параллелим этот процесс).

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

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

Один человек, который отвечает за тех. проект, и хочет его продвинуть дальше.

И второй человек, который проверяет, что работы выполнены правильно – ответственный.

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

Давайте посмотрим, как выглядят задачи. Справа есть маленькая неприметная кнопка «Добавить задачу по контрольной точке» – именно эта кнопка добавляет задачу пользователю по какому-то этапу. Я сейчас нахожусь на этапе согласования требований. Добавляю задачу и могу кому-то что-то поручить таким образом в рамках обрабатываемой контрольной точки.

Здесь есть протокол переписки – можно внутри СППР вести мини-переписку по задаче – друг другу перенаправлять задачу с какими-то комментариями.

У вас появляется задача внутри этапа. Но опять же, еще раз подчеркиваю, это – ручной режим. У вас есть контрольные точки, как состояние технического проекта, основное состояние, которое определяет, где проект сейчас находится.

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

Проектирование в СППР

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

Фирма 1С, как вендор, представляет вам модель для ERP, причем, не секрет, что УТ и КА из ERP просто вырезаются. Следовательно, эта же модель может служить и для анализа КА и УТ. Я в этом примере взял модель от ERP и подключил ее к КА – работает прекрасно.

Процессы и шаги – это просто текстовое описание ваших процессов. Их можно связать между собой.

А функции – это уже описание с помощью IDEF0, это уже действительно моделирование.

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

Например, вас в компании просят автоматизировать процесс учета заказов – вы открываете первый тех. проект, связываете его с процессом «Учет заказов».

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

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

Общая идея всего этого:

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

Тех. проекты эту модель изменяют. Каждый тех. проект вносит какое-то изменение в процессы, и это же изменение вы также отражаете в модели.

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

Давайте посмотрим, как у нас устроено моделирование. У нас есть отдельный раздел «Моделирование системы».

Тут есть процессы. Они сделаны очень просто, никакой графической нотации здесь нет. У процесса есть:

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

Работа с интегрированной моделью системы

А вот с моделью системы уже намного интереснее.

Если мы переключимся на типовой проект «УП(ERP)», модель которого была сюда предварительно загружена, то в разделе «Функции» мы увидим полную модель нашего предприятия.

Здесь мы видим все составляющие, все функции, которые выполняет подсистема и объекты данных.

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

Можно путешествовать по модели и смотреть, какие объекты в нее входят и какие данные. Мы в основном бюджетированием занимаемся. На практике, модель бюджетирования мы фактически пользователям не показываем, потому что в ERP и в КА бюджетирование – это конструктор. И здесь модель отражает, что этот конструктор нужно настроить – для пользователей это никакого смысла не несет. Но другие подсистемы вполне можно использовать для обучения пользователей.

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

После того, как мы в СППР модель настроим, она становится доступна в КА и в ERP. Просто публикуете СППР на веб-сервере, указываете в КА адрес опубликованного веб-сервиса и у вас для каждого разделе появляется команда «Функциональная модель», по которой можно ее прямо отсюда открыть.

Чем это может вам помочь? Когда у вас есть ERP или КА, вы можете в СППР для пользователей прямо здесь, в этой модели делать какие-то подсказки.

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

Им будет удобно – открыли в КА экземпляр бюджетов, а к нему появилась кнопка, показывающая, что в этой модели.

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

Технология разветвленной разработки в СППР

Теперь – самое интересное. СППР рассчитана на технологию разветвленной разработки. Эта технология описана на ИТС, но почему-то, по опыту собеседований, про нее мало кто знает. У меня на предыдущем месте работы было свыше 50-ти сотрудников, я собеседовал очень много людей, и мне только два раза смогли сказать, что эту технологию знают. Технология хорошая и простая. Идея вот в чем:

Есть главное хранилище. В главном хранилище никто не работает, туда изменения заливаются.

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

При начале работы, когда исполнитель получил задание на выполнение тех. проекта, он:

Из главного хранилища создает файл поставки.

На основании файла поставки создает свое хранилище тех. проекта.

Изначально у него все объекты на замках – он точечно снимает замки с тех объектов, которые планирует изменять, и вносит изменения,

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

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

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

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

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

Теперь идем в базу разработки и делаем в ней загрузку конфигурации из файла поставки.

Смотрите, вся наша конфигурация встала на замок.

Теперь мы точечно снимаем все объекты, которые хотим изменять. Почему мы точечно снимаем? Чтобы при втором обновлении из хранилища у нас эти объекты уже не сравнивались, чтобы они автоматически заменились на то, что лежит в хранилище актуальное.

Давайте добавим документ «Покупка» и добавим реквизит в документ «Продажа».

Мы внесли наши изменения в рамках нашего тех. проекта и теперь переносим их в основное хранилище.

Вот, о чем речь – получаем отчет о сравнении конфигураций в текстовом виде.

И идем в СППР, идем в наш тех. проект, в рамках которого мы эти изменения вносим.

Заходим в «Проектные решения» – «Объекты метаданных» – «Заполнить по файлу сравнения конфигураций» – «Добавить с диска» – «Загрузить».

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

В поле «Изменение справки» запишем, что будем делать со справкой — в нашем случае отметим, что изменения не требуются.

Записав изменения, мы отметили, что этим тех. проектом мы изменили эти объекты метаданных.

Далее может встать вопрос – кто в последний раз что-то менял – наш справочник, документ или другой объект. Мы идем в раздел «Разработка» – «Объекты метаданных».

Тут у вас отображается полное дерево. Вот наши объекты.

И уже внутри объекта мы можем получить список тех. проектов, которые изменяли этот объект, и что в нем изменилось. Несложная технология, правда?

Вопросы:

Зачем усложнять схему разработки, применяя промежуточные выгрузки в файлы?

ERP – очень большая конфигурация и пока вы вносите в своей разработческой базе какие-то изменения, другие программисты тоже не дремлют, они меняют другие объекты. Чтобы не разбираться – есть у вас пересечения или нет, вы создаете файл поставки и те объекты, которые вы гарантированно не изменяли (а вы знаете, какие объекты вы не изменяли, потому что вы не сняли с них замки), обновятся автоматически. И вам нужно разобраться только с теми пересечениями, которые изменились и у вас, и у других программистов – где они что-то изменили. Благодаря этой системе «замков» мы отсекаем от сравнения те изменения, те объекты, которые вы не меняли, чтобы не все объекты сравнивать глазами при сравнении-объединении, а чтобы они обновились автоматически.

Если мы меняем приходник и меняем расходник – это разные тех. проекты?

Я для себя вывел такое правило. Тех. проект – это работа не более двух недель. От недели до двух – наиболее эффективно. В таком случае, у вас не может быть столько мелких задач, что изменения рождаются и там, и там. То, о чем вы сейчас говорите – у вас, наверное, тех. проект заведен по заявке. Агрегируйте. Пришло три заявки на улучшение приходника и расходника. Вы создаете тех. проект «Развитие документов приходный и расходный ордер» и обрабатываете в его рамках три заявки.

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

Как я ломал сопротивление? Я требовал отчеты, которые нельзя получить в Jira, но очень удобно сделать в 1С:

сколько объектов метаданных ты изменил на этой неделе;

сколько ты потратил трудозатрат;

сколько закрыл задач.

Три колонки и по дням их расписать. В 1С это делается несложно. Например, у меня был отчет из 8 колонок – прошлая неделя, эта неделя, трудозатраты по дням и куда они пошли.

Трудозатраты отмечаются в задаче.

У меня есть тех. проект, к которому привязана задача «Поручение 1». Пользователь может отметить в задаче, сколько часов запланировано, сколько согласовано. Это считается трудозатратами. Трудозатраты ведутся только по задачам. Если вы хотите указать свои трудозатраты в целом по проекту, вы можете сделать одну верхнюю задачу и по ней поставить общий срок. Потому что в самом тех. проекте можно указать не срок, а календарное время – начало и конец периода. Срока там нет, он есть только в задачах.

Про ошибки я даже показывать не буду, там все совсем просто. Идея такая же, как в задаче – что можно друг-другу сообщения по ошибкам отправлять, и полный протокол переписки сохраняется. Ошибка похожа на задачу. Механизм очень простой, но нам хватает – от багтрекера много не надо.

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

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

В тех. проекте регистрируете ошибку по работе с программой.

Пишете наименование, описание, в каком хранилище ошибка обнаружена и кому назначена.

Можно ли использовать СППР в качестве багтрекера?

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

На слайде показана наша карта покрытия функциональности. Мы в основном в СППР используем следующие блоки:

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

требования, модели – практически не используем. Для требований я использую Sparx Enterprise Architect.

Еще очень удобно делать такое разграничение по проектам:

если вы работаете внутри, у вас проект – это конфигурация,

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

А чтобы отделить управление работ друг от друга, можно использовать целевые задачи. В СППР есть объект «Целевая задача» – используйте их, чтобы дополнительно категоризировать, разбить на какие-то этапы работ.

Вы сказали, что проект – это конфигурация. А если у нас в рамках проекта две конфигурации? Допустим, проект по синхронизации между двумя системами?

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

А есть возможность в системе автоматически уведомлять заинтересованных лиц по изменениям?

В системе есть уведомления по задачам, по ошибкам – это настраивается в проекте. Они не рассчитаны на пользователя. Они рассчитаны на уведомление тех, кто с этой системой работает. Но есть стандартная БСП-шная рассылка отчетов – система автоматически собирает описание к релизу, делаете рассылку этого отчета, и она автоматически его рассылает.

Что при описании в нотации IDEF0 считать функцией и описывать кубиками IDEF0, а что считать процессом и описывать по шагам?

Модель процессов и модель функций – это две параллельные модели, описывающие одно и то же. У вас может быть процесс продажи, который включает в себя доставку. А на верхнем уровне у вас может быть две функции, связанные между собой – продажа и доставка. И дальше это уже декомпозируется до объектов. Это две разные модели.

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

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

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

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

На последнем партнерском семинаре анонсировали, что в СППР будет включена Vanessa – не видели еще?

В СППР сейчас есть интеграция с системой проверки АПК (автоматизированная проверка конфигураций). А про Vanessa – должны выпустить новый релиз, там будем пробовать.

Можно подробнее про документацию – там было поле «Изменение справки», где нужно было проставить признак – надо это документировать или не надо. Это – задание для писателей?

Да, есть отчет, который называется «Проверка выгрузки справки», в котором можно увидеть те объекты метаданных, по которым требуется изменения справки.

Получается, что технический писатель должен писать в СППР?

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

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2023 EDUCATION. Больше статей можно прочитать здесь.

В 2023 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2023 в Москве.