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

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

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

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

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

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

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

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

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

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

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

Тестерам

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

Внедренцам

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

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

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

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

На рисунке представлены взаимосвязи основных понятий СППР.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отраслевые и специализированные продукты, расширяющие функциональность «1С:ERP Управление предприятием 2»

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

Итак, перед нами стоит задача создания отраслевых/специализированных решений, которые:

• соответствуют потребностям рынка;
• разрабатываются с минимально возможным привлечением ресурсов собственно фирмы «1С»;
• обладают гарантированным качеством реализации.

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

Сотрудничество с партнерами «1С-Совместно»

• Мы ищем востребованную рынком функциональность, еще не реализованную в наших продуктах, и составляем функциональные требования к новому продукту;
• Мы объявляем конкурс на разработку новых «1C-Совместных» решений, а также принимаем заявки на выпуск продуктов по инициативе партнеров;
• Мы определяем партнеров с наибольшими компетенциями и готовностью долгосрочного развития направления;
• Мы заказываем партнеру разработку, развитие и поддержку продукта.

График качества

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

Цель – единая бесшовная информационно-управленческая система, построенная на базе «1C:ERP» и других решениях «1С:Предприятие 8»:

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

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

• Формирование линейки продуктов, взаимодействующих как на уровне интеграционного ядра «1С:ERP», так и между собой
• Упрощение создания единого решения для пользователей из набора отраслевых и специализированных решений
• Минимизация трудозатрат по изменению состава модулей решения и дальнейшему сопровождению решения
• Исключение дублирования общих функциональных подсистем в различных продуктах

На момент написания статьи количество уже выпущенных решений линейки – 31 (18 партнеров-разработчиков), с учетом планов разработки, во 2 квартале 2017г. количество решений достигнет 52 (24 партнера-разработчика).

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

Взаимодействие разработчиков в единой среде проектирования

• 28 территориально распределенных команд разработчиков;
• 44 активных проекта;
• 19 новых решений.

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

СППР для отраслевых и специализированных решений (СППР ОР/СР) – CASE-средство для совместного проектирования решений

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

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

• Возможность построения модели сложной системы
• Управление жизненным циклом продукта
• Мультипроектность
• Кастомизируемость
• Интеграция со средой разработки
• Доступность для партнеров-внедренцев 1С

Цели

• Проектирование и документирование проектных решений
• Контроль результатов разработки

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

Управление жизненным циклом выпуска продуктов

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

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

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

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

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

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

Логическая модель решений в методологии IDEF0

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

Описание нотации СППР

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

• Функциональный блок (Activity Box) – некоторая конкретная функция создания новой информации в рамках рассматриваемой системы
• Связь – информация, которая обрабатывается функциональным блоком (входы и выходы) или оказывает иное влияние на функцию (управление и исполняющие связи – профили пользователей):
  • Вход функции – связь (информация), потребляемая функцией. На схеме отражается в виде стрелки, направленной к левой стороне функционального блока
  • Выход функции – связь (информация), порождаемая в результате выполнения функции. На схеме отражается в виде стрелки, исходящей из правой стороны функционального блока
  • Управление (управляющее воздействие на функцию, правило) – связь (информация) анализируемая для принятия решений в рамках функций. На схеме отражается в виде стрелки к верхней стороне функционального блока.
  • Исполнение (профиль пользователя) – воздействие на функцию со стороны одного или нескольких пользователей системы. На схеме отражается в виде стрелки к верхней стороне функционального блока.

Варианты поставки продуктов

• функциональность в составе «1С:ERP»,
• функциональность в виде самостоятельно работающей конфигурации,
• функциональность для интеграции в «1С:ERP».

Например, «1С:ERP Управление строительной организацией 2» (партнер – разработчик «1С-Рарус») содержит в своем составе:

• функциональные возможности типовой «1С:ERP»,
• собственную оригинальную отраслевую функциональность,
• функциональность отдельных решений:
  • «1С:Смета 3»,
  • Модуль «1С:Риэлтор. Управление продажами недвижимости для 1С:ERP»,
  • Модуль «1С:Аренда и управление недвижимостью для 1C:ERP»,
  • Модуль «1С:Управление автотранспортом для 1С:ERP».

Библиотека функциональных подсистем 1С-Совместно

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

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

Уведомление ответственных о ходе реализации технических проектов

• Ответственные за проект
• Ответственные за разделы проекта
• Ответственные за технические проекты

• Контроль выполнения технических проектов - еженедельно
• Контроль активности партнеров-разработчиков - еженедельно
• Уведомления о необходимости выполнения действий в базе (задачи, сообщения и т.п.) - ежедневно
• Уведомления о наличии ошибок в моделях - ежедневно

• Сроки выполнения контрольных точек (этапов)
• Сроки выполнения технических проектов
• Изменения объектов метаданных типовой конфигурации
• Ошибки и предупреждения в модели
• Актуальные задачи
• Активность работы над техническим проектом

Примеры отчетов

Подготовка конфигураций к тиражированию

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

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

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

Сервис 1С:Облачная карта решений

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

• Функция «Комплексная информационная система управления на базе 1С:ERP Управление предприятием 2»
• Функция «1С:PDM Управление инженерными данными»

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

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

• Изучение функциональности готовых решений для автоматизации отраслевых и специализированных бизнес-процессов, определение продуктов, содержащих требуемую функциональность.
• Возможность выбрать партнера, ознакомиться с условиями приобретения, информационными материалами, успешными проектами внедрения, а также принять участие в ближайших мероприятиях и получить доступ к демонстрационной базе (при наличии такой возможности), путем перехода на страницу продукта сайта http://solutions.1c.ru
• Расширение областей автоматизации в рамках используемых решений путем изучения и применения всех заложенных функциональных возможностей.

Использование сервиса партнерами

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

Команда разработчиков – команда профессионалов

В заключение

Прежде чем говорить об инструментах проектирования, хотелось бы остановиться на немаловажном вопросе: «для чего нужно проектирование информационных систем? ». Достаточно популярным, особенно в среде 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С:СППР реализована только IDEF 0.

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

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

Функционала для организации разработки и тестирования в 1 C :СППР просто не существует. Хотя не понятно почему. Редко встретишь опытного разработчика, который хоть раз в своей жизни не написал бы систему учета задач. Если ориентироваться на тот же 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) Управление изменениями. Что поменялось, кто согласовал? На что повлияет это изменение. Очень важный момент, конечно сложный в реализации, но управление изменениями сразу вывело бы систему на новый уровень и повысило бы её полезность.

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

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

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

************

Приглашаем вас на новую конференцию .

Прежде чем говорить об инструментах проектирования, хотелось бы остановиться на немаловажном вопросе: «для чего нужно проектирование информационных систем?». Достаточно популярным, особенно в среде 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С:СППР реализована только IDEF 0.

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

С документированием возникают уже проблемы. Основной функционал, которого не хватает 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) Управление изменениями. Что поменялось, кто согласовал? На что повлияет это изменение. Очень важный момент, конечно сложный в реализации, но управление изменениями сразу вывело бы систему на новый уровень и повысило бы ее полезность.

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

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

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

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

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

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

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

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

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

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

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

Тестерам

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

Внедренцам

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

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

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

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

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

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

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

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

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

Система поддерживает работу в режиме тонкого и веб-клиента.