Разработка 1С:ERP

В статье мы расскажем, как осуществляется разработка многофункционального продукта компании «1С» – «1С:ERP Управление предприятием 2».

«1С:ERP Управление предприятием 2» - уникальный продукт, который позволяет автоматизировать деятельность многопрофильного предприятия с технически сложным производством.

1С:ERP – основа для четырех функционально различных решений:

•   Собственно 1С:ERP – универсальный продукт, который готов для внедрения в средних и крупных компания.
•  1С: Комплексная Автоматизация – решение для малых и средних предприятий, где процессы управления требуют четких и слаженных действий нескольких исполнителей.
•  1С: Управление Торговлей автоматизирует учет, анализ и планирование операций в торговых предприятиях.
•  1С: Управление Торговлей. Базовая версия – вариант для небольших торговых предприятий, позволяющий вести учет от имени юрлица или индивидуального предпринимателя. Этот продукт может использоваться только в типовой конфигурации, работа с информационной базой доступна только одному пользователю, нет поддержки с сервером 1С: Предприятия 8.

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

Как разрабатывается 1С:ERP

Как из одного решения получается четыре

Разрабатывается только одно решение – ERP. Все остальные «дочерние» продукты формируются из ERP автоматически, а изменения переносятся с помощью механизма сравнения и объединения конфигураций. Этот механизм был разработан для автоматизации перехода от старой к новой версии продукта 1С. Механизм на основании анализа конфигураций осуществляет трехстороннее слияние:

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

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

Пример такого перехода показан на схеме

Для каждого решения некоторые объекты нужно писать вручную, например, планы обмена, которые определяют правила объединения одной конфигурации с другим продуктом 1С или внешним оборудованием. Для того чтобы уменьшить количество уникальных для каждого продукта планов обмена, осуществляется переход на единый стандарт EnterpriseData. Такой подход очень удобен для разработчиков. Достаточно написать решение один раз, а использоваться коды, форм, сценарии будут во всех четырех продуктах ERP. Особое внимание уделяется юзабилити продукта.

По международному стандарту юзабилити это

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

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

Разработка 1С:ERP: особенности

Особенностью разработки 1С:ERP является то, что каждая функция может использоваться в «дочерних» продуктах ERP. Для комфортного включения или выключения используется механизм функциональных опций. Этот механизм позволяет, не внося изменения в прикладное решение, найти ту функцию, которую нужно включать или выключать при внедрении. Функциональные опции незаменимый инструмент для настройки продукта 1С под нужды конкретного предприятия. В ERP механизм функциональных опций используется также для выделения производных решений из ERP. Приведем пример: в ERP есть опция «Управление предприятием» (УП), она отвечает за все функции, связанные с управлением на предприятии. Такая опция есть в 1С:ERP. В прикладных решениях «Управление торговлей» (УТ), УТ Базовая, «Комплексная Автоматизация» (КА) она не нужна, поэтому ее можно просто «выключить».

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

• объекты УП, УТ, КА;
•  объекты УП, КА;
•  объекты УП.

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

Что значат цифры в ERP

Каждой новой версии ERP присваивается номер, например, 2.1.3.117. Что значат цифры в номере?

Первая цифра – редакция продукта.

Вторая цифра – подредакция.

Третья цифра – релиз.

Четвертая цифра (число) – обновления, которые выходят примерно раз в две недели.

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

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

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

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

Что может стать поводом для создания требований?

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

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

Запускать ERP можно в режиме интеграции с СППР. Открыть описание функции СППР можно, нажав на кнопку «Открыть функциональную модель».

После нажатия появляется модель рабочего места в IDEF0

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

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

6 главных точек в разработке ERP

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

Над проектом работает команда разработчиков во главе с тим-лидом (руководителем), который принимает непосредственное участие в проектировании и разработке. Также в команду входят тестировщики. Каждая команда отвечает за свою предметную область разработки. Если проект затрагивает «чужую» область, временно команда пополняется разработчиком другой команды, отвечающей за соответствующую область.

Вся ответственность за ведение проекта ложится на тим-лида. Он же осуществляет контроль следующих процессов:

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

1. Открытие проекта

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

2. Согласование концепции

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

3. Согласование прототипа

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

Одной из целей встречи на данном этапе является оценивание трудозатрат на реализацию проекта. В СППР документируются следующие аспекты:

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

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

4. Согласование готового решения

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

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

5. Тестирование и аудит разработанного проекта

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

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

После окончания всех тестов код заливается в основное хранилище. В это же примерно время дописываются справочные материалы по новому продукту. Готовая справка хранится в СППР.

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

6. Проект окончен

Окончанием проекта можно считать тот момент, когда его закрывают в ССПР и присваивают статус «Выполнено».

Выход версии

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

Исправительные сборки

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

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

И еще немного о разработке новых продуктов

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

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

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

Тестирование 1С: ERP

После разработки всех решений ERP – КА, УТ, УТ Базовая – проводятся анализы. Статический анализ проводят два раза в день, после того как конфигурации прикладных решений заливают в их собственные хранилища.

Более детальный статический анализ осуществляются 1С: АПК (1С: Автоматическая Проверка Конфигураций). Что проверяет 1С: АПК?

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

В динамический анализ кода включено регрессионное тестирование.

Операции регрессионного тестирование:

•  открытие форм;
•  осуществление обмена данными между разными прикладными приложениями;
•  проверка отражения документов в учете и др.

Для осуществления регрессионного тестирования используются от десяти до двадцати баз, объем которых составляет 15-70 Гб.

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

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