1с сппр что это
Прежде чем говорить об инструментах проектирования, хотелось бы остановиться на немаловажном вопросе: «для чего нужно проектирование информационных систем?». Достаточно популярным, особенно в среде 1С специалистов, является мнение что проектирование системы - это лишние трудозатраты. Я бы сказал, оно не безосновательно. Многие из задач при внедрении систем являются довольно стандартными и требуют лишь трудозатрат на разработку. Очень часто не создается новых механизмов и инструментов, а лишь «дотачиваются» существующие, притом под нужды заказчика, которые регулярно меняются.
В этом случае формальный процесс проектирования навряд ли имеет смысл. Речь идет именно о формализации процесса, т.к. сам процесс проектирования является неотъемлемой частью разработки и конечно будет присутствовать, пусть даже только в голове разработчика.
А когда проектирование имеет смысл:
- Есть общая стратегия компании, и развитие ИТ систем – часть этой стратегии.
- Есть понимание от менеджмента какие задачи требуется решить посредством внедрения/развития информационной системы.
- Есть формальное понимание/описание бизнес процессов компании, или планируется его создание.
Собственно, все начинается со стратегии. Инструментарий для создания стратегии компании редко бывает специализированным. Это скорее нечто, что должно быть в голове у топ менеджера. Далее строится модель бизнес процессов (которая должна присутствовать для достижения стратегических целей). Здесь уже в ход идут инструменты моделирования – 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С:СППР в развитии системы, но есть вещи которых нахватает как в нашей системе так и в типовой 1С:СППР:
1) Управление изменениями. Что поменялось, кто согласовал? На что повлияет это изменение. Очень важный момент, конечно сложный в реализации, но управление изменениями сразу вывело бы систему на новый уровень и повысило бы ее полезность.
2) Связь с хранилищем конфигурации. Конечно последнего этапа в цепочке не хватает немного. Если бы в системе можно было получить информацию по какому заданию/спецификации была эта разработка?
3) Интеграции с ARIS/Business Studio. К сожалению, встроенные средства 1С существенно проигрывают специализированным в плане удобства и функциональности для постраения диаграмм EPC / IDEF .
Итого, 1С:СППР очень функциональный и полезный в практике продукт. Очевидно, что 1С движется в правильном направлении. Может что-то еще не так, чего-то не хватает, поэтому с нетерпением ждем развития системы, ну или дорабатываем сами.
Система проектирования прикладных решений (СППР) предназначена для проектирования прикладных решений (конфигураций) на платформе «1С:Предприятие» и ведения технической документации проекта. СППР может быть использована как в качестве инструмента для проектирования новых информационных систем, разрабатываемых в среде «1С:Предприятия 8», так и для описания и документирования существующих систем, разработанных ранее без использования СППР.
Система проектирования прикладных решений разработана как конфигурация на платформе «1С:Предприятие 8.3».
Преимущества для пользователей
Использование СППР позволяет:
- Организовать централизованный учет требований и пожеланий к информационной системе.
- Выстроить целостную модель системы, отталкиваясь от автоматизируемых процессов, с возможностью проверки корректности модели.
- Управлять изменениями в проекте.
- Формировать план выполнения проекта.
- Контролировать выделение ресурсов в рамках проектов и конкретных задач.
- Анализировать завершенность проекта (выполнение необходимых задач, отсутствие ошибок).
- Упростить подготовку справочной информации в едином стиле, с учетом структуры конфигурации и взаимосвязей различных объектов конфигурации.
- Использовать проектные материалы при подготовке документации и других материалов.
- Получить доступ к проектным материалам, описывающим тестируемую функциональность.
- Организовать систему автоматического тестирования, избавляющую от рутинных действий и ускоряющую процесс тестирования.
- Обеспечить регистрацию и отслеживание ошибок.
- Разобраться в типовом решении, используя проектную документацию.
- Соотнести реальные процессы предприятия с моделью системы, проанализировав покрытие процессов функционалом и выявив необходимость доработок.
- Органично внести собственные доработки в типовую функциональность с выверкой полученной модели.
- Упростить освоение конфигурации пользователями, формировать инструкции по работе с конкретной функциональностью.
Процесс проектирования в СППР
При проектировании информационной системы описываются автоматизируемые процессы. Исходя из описания процессов, строится логическая модель проектируемой системы. На основании логической модели строится физическая модель, воплощаемая в метаданных разрабатываемой конфигурации.
При необходимости внесения изменений в проект используется механизм технических проектов. Изменения основываются на принятых требованиях и документируются c привязкой к изменяемым процессам, а также объектам логической и физической модели.
Описание автоматизируемых процессов
При проектировании конфигурации важно, чтобы ее функциональность отвечала реальным потребностям предприятий. Поэтому важно очертить тот круг процессов, которые позволяет автоматизировать информационная система.
СППР позволяет зафиксировать перечень автоматизируемых процессов, процессы при этом могут быть сгруппированы по усмотрению пользователя.
При описании процесса фиксируется его описание, отражающее суть процесса, события начала и окончания процесса.
Процесс детализируется до отдельных шагов, исполняемых конкретным исполнителем.
Создание логической модели проектируемой системы
Логическая модель системы позволяет описать функциональность конфигурации, увязав ее с составом обрабатываемой информации и исполнителями.
Логическая модель в СППР строится с использованием методологии IDEF0. В рамках создания логической модели описываются функции системы и производится их декомпозиция.
Основой описания функции является ее IDEF- схема. Схема позволяет в наглядной форме отразить взаимосвязь отдельных (дочерних) функций, потоков данных и исполнителей.
Разработка архитектуры
Разработка архитектуры конфигурации выполняется на основе логической модели. При этом метаданные загружаются из разрабатываемой конфигурации в процессе разработки.
ER-диаграмма помогает анализировать структуру метаданных:
Подготовка справки
СППР позволяет автоматически формировать тексты справки для разрабатываемой конфигурации. Подготовленные тексты справки в формате html могут быть выгружены из СППР и загружены в конфигурацию штатными средствами конфигуратора.
Справка формируется в едином стиле, с использованием единой структуры описания, исходя из взаимосвязей подсистем, объектов метаданных и операций функций. Стили оформления справки (шрифты, отступы, выделения) могут настраиваться непосредственно в СППР.
Управление проектом и изменениями
Для управления проектом и изменениями в СППР используется функциональность ведения технических проектов. Данная функциональность позволяет организовать коллективную работу над проектом, с отслеживанием прохождения различных этапов проекта. При этом возможна гибкая настройка этапов, согласование этих этапов, уведомление участников команды разработки об изменениях.
Использование технических проектов обеспечивает внесение изменений в имеющийся проект таким образом, чтобы эти изменения были увязаны с логической моделью, были прозрачны и информативны для других участников проекта
Механизм работы с задачами позволяет удобным образом выстроить процесс управления, согласовании ресурсов, контроля за выполнением проектов.
Тестирование, работа с ошибками
СППР позволяет организовать автоматизированное тестирование: подготовку тестовых сценариев, автоматический прогон тестов, регистрацию ошибок.
Информация об ошибках ведется по разрабатываемым проектам, в разрезе версий, сроков исправления, разделов проекта, статусов и т. д. Функционал системы предлагает готовую методику работы с ошибками, с возможностью формирования различных отчетов, публикации информации об ошибках. Система позволяет настроить связи между проектами, указать, какие проекты-библиотеки включаются в проект, с учетом конкретных версий проектов. Это позволяет получать информацию о наличии в проекте ошибок, источниками которых являются используемые библиотеки.
Прочие возможности
Курс "Внедрение прикладного решения "1С:Зарплата и управление персоналом 8" в 1С:Учебном центре №1 с 16 по 19 мая 2022 года 05.05.2022 12:26:00
Старт продаж новых тарифных планов на 1 месяц при подключении онлайн-касс к оператору фискальных данных "Такском" через сервис "1С-ОФД" 04.05.2022 17:30:00
Очные курсы в 1С:Учебном центре №1. Начало продаж. Расписание на май-июнь 2022 года 29.04.2022 17:08:00
Открытие новых сертифицированных экзаменационных центров (1С:СЭЦ) в городах Брянск и Тверь 29.04.2022 16:19:00
Статья рассматривает способ использования 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.
Переход от оценки труда разработчиков к оценке труда аналитиков и методологов
Значит, задача состоит в том, чтобы подобрать для перечисленных членов команды аналогичный базис, который позволит использовать методику COCOMOII. Вот тут на сцену и выходит он.
Псевдокод
Одним из видов выходных результатов всех сложных проектов по проектированию, созданию и разработке информационных систем являются проектные документы. Это технические задания, концептуальные документы, описания, инструкции, реестры объектов данных, списки аналитик и т.п. Структура оглавления этих документов, тексты содержания, таблицы, рисунки, собранные требования, списки и являются псевдокодом.
И именно этот псевдокод является измерителем результатов работы «непрограммистских» членов команды проекта – аналитиков, методологов, технических писателей, менеджмента проекта, архитектора, проектировщиков и аналогичных участников.
Если проект сдаётся по ГОСТовским требованиям, то структура проектных документов задаётся этими стандартами, в ином случае, она создаётся на усмотрение исполнителя или по требованиям договора с заказчиком.
Интересный момент, если проектная команда и заказчик решат идти в ногу со временем и будут оформлять результаты проекта исключительно по безбумажной технологии как с этим будет связана 1С СППР?
Ответ — самым прямым образом – СППР и содержимое её справочников, заполненных по проекту, будет сама структурированным объектом данных и результатом работы. Который очень удобно передавать заказчику. Все создаваемые в ходе проекта документы будут являться вложенными документами к объектам конфигурации СППР.
Упрощенно выходные проектные документы делятся на следующие группы псевдокода:
- Структура (оглавление) документа;
- Тест документа;
- Строка таблицы документа (таблица);
- Рисунок (графический объект).
Таким образом, аналогом KSLOC в стандартном COCOMO здесь становится строка оглавления выходного проектного документа и/или строка текста этого документа (каждая строка каждой таблицы в этом документе, каждый графический объект). В базис не должны включаться элементы дизайна и разметки документа.
1С СППР и псевдокод
Встаёт вопрос, как разместить в 1С СППР псевдокод.
Это можно сделать через справочник «Объекты данных». Создаётся отдельная группа «ВЫХОДНЫЕ ДОКУМЕНТЫ», внутри неё подгруппы под каждый вид документов, далее ещё подгруппы под каждый отдельный документ, а внутри уже этих подгрупп как элементы справочника строки оглавления проектного документа.
Если будет принято решение включать в базис COCOMOII текстовое содержание, таблицы, графические объекты выходных проектных документов, то тогда строки оглавления проектного документа также следует делать группами справочника «Объекты данных», а внутри них размещать имена таблиц, графических объектов и абзацев текста.
Текст самого проектного документа можно набирать по абзацам как текстовое поле элемента справочника «Объекты данных».
К чему следует стремиться при описании структуры выходных проектных документов в справочнике «Объекты данных»?
Стремиться нужно к тому, чтобы каждый элемент справочника «Объекты данных» мог иметь ссылку на один объект метаданных и/или на один объект данных (из других групп справочника «Объекты данных», которые описывают не структуру выходных документов, а другие виды, создаваемых на проекте данных, например: списки аналитик).
Такая конструкция даст возможность создавать выходные проектные документы автоматически, напрямую из 1С СППР. Это поможет очень существенно сократить затраты времени работы команды на проекте, особенно в условиях постоянно изменяющихся требований заказчика, модификаций информационной системы в т.ч. другими командами и исполнителями, когда необходимо заново пересоздавать выходные документы, но при этом сохранить связанность объектов и их описаний.
При увязке каждого элемента или группы справочника «Объекты данных» с Требованиями (как сформулированные заказчиком, так и членами проектной команды, детализированными до метаданных), то в итоге можно получить сквозную связку Требования – Объекты метаданных – Выходные проектные документы. В СППР 2.0 аналогом «Требований» выступают «Идеи».
По мере накопления опыта исполнения проектов в 1С СППР будет выкристаллизовываться такая структура справочника, которая будет одинаковой на всех однотипных проектах. Следовательно, для нового проекта её достаточно просто скопировать. А для идентичных по выходным результатам проектов можно скопировать и текст (таблицу).
Резюме
Интеграторы и организации, имеющие наработанную базу проектов, проведя ревизию материалов прежних проектов, могут получить в своё распоряжение объективную оценку сроков и стоимости планируемых и текущих проектов.
Это должно существенно облегчить А) торг с заказчиком Б) оценку ожидаемой прибыли.
В чём содержание определения «СППР многими используется неправильно»?
Во-первых, абсолютное большинство использующих СППР взваливают её на разработчиков.
В таких случаях разработчики отвечают за описание функциональности учётных систем в СППР и за составление задач на разработку.
Вот это и есть неправильно.
С такими задачами справится и JIRA и ей подобные бесплатные продукты.
Работа разработчика в СППР не предусмотрена. СППР должна выдавать разработчику задачи на разработку.
Разработчик от СППР, а значит от совсем других участников проекта, должен получать готовые, детально описанные ТЗ.
Во-вторых, даже работа только системного архитектора в СППР недостаточна.
СППР будет эффективна только тогда, когда в ней будет сделано описание бизнес-процессов организации и, отдельно, описание функциональности программного продукта (разрабатываемого или внедряемого).
А архитектор должен связать каждый бизнес-процесс с функцией системы.
Если чего-то не хватает, то либо делается вывод, что система не подходит под процессы клиента, либо функциональность системы дорабатывается (проектируется в СППР!).
Именно об этом 4-й слайд презентации, который показывает, как отличалось бы описание бизнес-процессов по работе на проекте внедрения самой СППР от функциональности СППР заложенной в конфигурацию.
Вывод — любой проект по внедрению СППР обречён на провал, если он вешается на разработчиков.
СППР должна начинать работу гораздо раньше — при сборе требований и описании бизнес-процессов.
P.S. Модная тема СППР+Vanessa…
Если в СППР делать описание процессов (шагов процессов) по операциям пользователей, то,
фактически, можно получить последовательность операндов языка Геркин для Ванессы.
Т.е. почти готовый сценарий.
Опять вывод, из посткриптума — сценарии должны писать не тестировщики, а те, кто описывает процессы.
От тестировщика (разработчика/программиста) требуется всего лишь перевести шаги процессов в точные команды языка (можно ведь и автоматизировать этот момент, учитывая «человечность» языка геркин).
Опыт разработки, накапливаемый на крупных и сложных проектах, воплощается в полезные инструменты и инженерные практики, которыми необходимо обогащать процессы разработки, переосмысливая его целиком раз за разом. Именно осознание ценности приобретенного опыта как артефакта, желание развиваться, привело нас к пониманию необходимости внедрения инструментов и практик в текущие процессы. И мы запустили кардинальный пересмотр подходов к проектированию решений и к процессу разработки в целом. Нет смысла описывать типичные ограничения и недостатки «классического» подхода к командной разработке в мире 1С. На эту тему уже много сказано. Опишу лишь паттерны, которые позволили нам сделать эти недостатки маленькими и почти не страшными.
Итак знакомьтесь, интегрированный стенд разработки!
Общие принципы архитектуры
Проектируя архитектуру стенда, мы стремились охватить весь жизненный цикл внедряемых на проектах решений, имплементировать приобретенный опыт, стандартизировать процессы, автоматизировать рутину. При этом, нужно было заложить потенциал развития, сохранить способность к масштабированию и максимальную простоту, с точки зрения обслуживания, развития и работы пользователей. Инструменты и методики, которые доказали свою эффективность на практике, должны добавляться в процесс. А все бесполезное, мешающее в работе, должно быть удалено.
Процесс
Жизненный цикл любого решения практически не меняется в зависимости от масштаба и сложности проекта. Он включает в себя: анализ, проектирование, разработку, тестирование, внедрение, сопровождение, вывод из эксплуатации. Чтобы получить максимальную эффективность, каждый из этих процессов должен быть выверен и согласован с предшествующими и последующими процессами, объединен в подобие автоматизированного конвейера, который может тиражироваться под неограниченное количество проектов. Решить поставленную задачу, позволила реализация системы в виде связанных через экспортируемые API микросервисов в изолированных контейнерах, которую возможно развернуть как в облачном сервисе, так и в локальной сети предприятия.
Вот так выглядит наш стек, реализующий процесс:
Мы постарались свести к минимуму использование платных сервисов с закрытым исходным кодом, что положительно отразилось на стоимости владения. Практически все сервисы с открытым исходным кодом и работают на ОС Linux.
Процесс построен так, что мы получаем максимальную отдачу от каждого члена команды разработки, а стандартизация и автоматизация избавляют от чрезмерной сложности и рутины.
Проектирование (Сервис Проектирования Прикладных Решений)
Один из наиболее значимых этапов при старте проекта — проектирование будущего решения на основе анализа требований. Основная задача — максимально понятно, однозначно и быстро описать архитектуру будущего решения, в терминах понятных как разработчику/инженеру, так и консультанту. Описать метаданные, алгоритмы реализуемых бизнес-процессов. При этом, хотелось максимально задействовать готовые, быстро настраиваемые под конкретные условия шаблоны, которые можно адаптировать к данным на входе и получить проектную документацию на выходе.
Мы внедрили конфигурацию «1С: СППР» в качестве единого интерфейса для проектирования прикладных решений, значительно переработали концепцию описания бизнес-процессов и функций, а также проектирования ТП (ФДР). Еще автоматизировали процессы генерации документации через интеграцию с функционалом «1С: ДО» и микросервисами по генерации документов формата docx.
«1С: СППР». Редактирование информации о проекте:
«1С: СППР». Отчёт по процессам:
«1С: СППР». Редактирование метаданных объектов:
«1С: СППР». Редактирование схемы бизнес-процесса:
Конечно, нельзя сказать, что процесс проектирования изменился кардинально, однако унификация организационных подходов и автоматизация многих функций уже вносит вклад в качество проектов.
Разработка (Сервисы непрерывной интеграции, инспекции и тестирования)
Мы постарались сфокусироваться на возможности всестороннего, непрерывного, автоматизированного контроля качества разрабатываемого кода, чтобы гарантировать соответствие установленному в КРОК стандарту. Причем, даже если привлекаем сторонние команды разработчиков, методики, инструменты и стандарты разработки которых могут существенно отличаться от принятых у нас.
Gitlab. Теперь возможно прокомментировать любую строку помещаемого коммитом кода:
Gitlab. Провести «Code Review» c подсветкой синтаксиса:
Gitlab. Получить наглядную картину изменений кода в новом коммите:
После каждого коммита в репозитории автоматически запускается процедура статической инспекции кода сервисом SonarQube. BSL код коммита проверяется на соответствие набору правил (профиль качества), описывающих стандарт разработки кода. Процедура выполняется как для кода разрабатываемой конфигурации, так и для внешних механизмов: расширений, внешних отчетов и обработок и, в принципе, любого другого кода проекта, даже на других языках.
SonarQube:
Каждая проверка обновляет информацию отслеживаемых метрик качества кодовой базы, таких как:
- технический долг – суммарные трудозатраты необходимые для исправления выявленных ошибок;
- порог качества – предельно допустимые показатели ошибок, уязвимостей и других недостатков кода, при достижении которых, выпуск релиза считается не возможным;
- дублирование кода – количество строк кода, повторяющихся многократно в рамках разрабатываемой конфигурации;
- цикломатическая и когнитивная сложность – алгоритмы с большим количеством ветвлений, усложняющие поддержку и доработку кода.
Профиль качества может расширяться собственными наборами правил через XPath, а также за счет выпуска новых правил в составе собственной реализации плагина для языка 1С. Это позволяет гибко управлять требованиями качества, исходя из реалий конкретного решения.
Автоматизированный запуск процессов разбора конфигурации, инспекции кода, автоматизированного тестирования и т.д. запускает сервис непрерывной интеграции (сервис Jenkins). Количество и характер таких сборочных линий может быть изменено в соответствии со спецификой того или иного проекта.
Несмотря на относительную сложность описанного процесса, все механизмы конвейера, которые выполняют рутину, скрыты в облачном сервисе. А разработчик имеет дело с привычным для него интерфейсом конфигуратора, а также может развивать свои навыки, используя более продвинутые инструменты. Например, git, репозиторий для внешних механизмов в связке со сторонними редакторами кода и SonarLint, SourceTree, и т.п.
Трудно переоценить эффект от непрерывной, всесторонней проверки кода, за которой следует автоматизированное тестирование разрабатываемого функционала. Это позволяет избавиться от далеко идущих последствий, сделать этапы разработки прозрачными, а вкупе с правильно выстроенными процессами, объективно оценить квалификацию разработчиков, что исключает риски зависимости от подрядчиков. Оценивая параметры текущей кодовой базы, мы можем оперативно выявлять и нивелировать возникающие риски, исправлять недочеты проектирования, своевременно реагировать на меняющиеся требования.
Модульная организация архитектуры стенда позволяет встраивать в процесс новые модули, тиражировать решение для необходимого количества проектов. Схематически она выглядит так:
Тестирование (сервис непрерывного тестирования)
Выше я уже говорил про сервис непрерывного тестирования, который интегрирован в конвейер процесса разработки. На данный момент на стенде реализован прогон дымовых тестов и unit-тестов. Функционал автотестов реализуется с использованием фреймворка xUnitFor1C.
Запуск процессов тестирования, так же как инспекция кода, привязан к событию коммита в репозиторий проекта. Для unit-тестов подразумевается разработка теста параллельно с разработкой функционала. Непосредственно перед их выполнением производится автоматизированное развертывание последней версии конфигурации в подготовленную тестовую информационную базу. Затем запускается клиент, который выполняет сценарии тестирования для уже реализованного функционала. Тесная интеграция сервисов автоматизированного тестирования с BSL плагином SonarQube позволяет вычислить такой параметр как покрытие кода тестами. Результат прогона тестов — отчет, который загружается в систему анализа и визуализации результатов тестирования ReportPortal. Этот сервис представляет собой портал отчетов, в котором агрегируются данные о прогонах тестов (статистика и результаты), производится базовое обучение системы по категоризации падений и дальнейшее автоматическое определение причин. Все параметры прогонов тестов доступны в удобном веб-интерфейсе с различными досками для графиков, диаграмм (виджетов). Для расширения функций портала возможно использовать собственные расширения.
Сервис автоматизированного тестирования — это еще один этап, снижающий риски попадания в релиз кода, который ломает ранее реализованной функционал или работает с ошибками.
ReportPortal. Дашборд:
ReportPortal. Неудачные запуски тестов:
ReportPortal. Типы дефектов:
Развитие
Оценивая результаты проделанной работы, мы видим, что из задуманного уже реализовано, какие идеи уже успешно работают, какие еще только предстоит реализовать.
Из планов на ближайшую перспективу развития стенда — создание портала управления сервисами стенда. Веб-интерфейс портала позволит работать с заявками на подключение проектов к стенду, с калькулятором стоимости сервисов, с их автоматизированным развертыванием по запросу под проект. В результате менеджер сразу же может получить калькуляцию стоимости выбранных услуг и оценить затраты, определить разработчиков на проект.
Мы планируем провести интеграцию портала с облачным решением эксплуатации систем 1С. Это поможет быстро разворачивать тиражируемые типовые решения в связке с сервисами разработки, реализованными на стенде для более эффективной миграции систем заказчика в облако КРОК.
Портал управления планируем также интегрировать с сервисом автоматизированного управления конфигурацией (развертывание, настройка, удаление). Это позволит сократить время развертывания, упростить настройку и обслуживание системы. А для повышения уровня безопасности внедрим сервис сквозной аутентификации по всем сервисам стенда, чтобы использовать одну и ту же учетную запись во всех из них.
Если рассматривать весь процесс с точки зрения истории полного цикла разработки решения, то созданный конвейер позволит собрать и агрегировать большое количество разнообразных метрик как по артефактам проекта, так и по специалистам, которые принимали в нем участие. Такая подробная ретроспектива будет способствовать накоплению и повторному использованию опыта в решении сложных задач, формировать команды из успешных разработчиков для более эффективной и слаженной работы.
UPD. По просьбам в комментариях добавляем список опенсурсных продуктов, которые используем, с ссылками.
Читайте также: