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

Публикация № 915728

Управление - Интеграция

сппр проектирование архитектура

41
Как сделать проектирование функциональной архитектуры ПО технологией. Цель - устранить ряд типовых проблем на сложных проектах. Как использовать для решения этих задач 1С система проектирования прикладных решений (СППР). Статья полезна для директоров франчайзи, системных интеграторов, руководителей проектов, архитекторов и консультантов.

Предыстория.

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

1) хронический дефицит компетентных специалистов и постоянная их сменяемость,

2) смутно-ясное представление о конечном результате,

3) постоянный  прессинг от  заказчика на предмет внезапных изменений в целеполагании и способе исполнения,

4) разбухание объёмов работ слабо контролируемых  со стороны внутренних служб управления проектами,

5) расход времени на заполнение гигантских объёмов документации, наличие которой обязательно по проекту, но мало помогает сопровождению ПО,

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

7) слабая формализованность промежуточных результатов внутрикомандной работы, когда те же методологи передают проектировщикам, а те далее разработчикам задачу в таком виде, который требует отдельного времени на выяснение «что собственно требуется сделать" (называется «слить проблему на программиста»),

8) и т.д. и т.п.

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

- сделай то, не точно знаю что,

- главное сделать что-нибудь и показать, мы все люди умные, авось проскочим,

- три последних дня решают всё,

- всегда так делали и т.п.

Есть ли какое-то решение, способ выйти из замкнутого круга?

Вполне.

 

Решение.

Идея проста, хотя исполнение достаточно сложное.

Суть состоит в том, что исполнение проектов должно быть ТЕХНОЛОГИЕЙ, а не простой последовательностью шагов проекта.  И, не  «согласно принципам системы управления проектами», а согласно «принципам управления производством» в первую очередь.

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

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

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

В качестве такой программы предлагается 1С Система Проектирования Прикладных Решений (СППР).

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

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

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

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

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

 

Общая схема работы 1С СППР.

  1. Уровень работы руководителя/менеджера СУП (Системы Управления Проектами)

Прежде всего, в системе открывается проект.  Это действие носит технический характер и выражается во внесении записи в справочник «Проекты».  Затем в справочник «Разделы проекта» вносятся шаги проекта из договора с Заказчиком или из СУП Исполнителя.  Здесь же, в раздел «Присоединённые файлы», загружаются все проектные документы, которыми должна руководствоваться команда.

В СППР работа с «общим языком» реализована через функционал загрузки метаданных конфигурации в справочник «Объекты метаданных» в справочнике «Проекты» на закладке «Работа с метаданными».

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

  1. Уровень работы бизнес-аналитика

На этом уровне заполняется иерархический справочник «Процессы». Сюда вносятся выявленные бизнес-процессы Заказчика. Особенность этого момента в том, что вносятся бизнес-процессы на таком уровне описания, где в них не входят действия людей.

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

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

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

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

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

Каждый элемент справочника «Шаги процессов» может быть связан с элементом или группой справочника «Функции».

Заполнение справочника «Процессы» и «Шаги процессов» позволяют бизнес-аналитику сделать формализованное описание предметной области безотносительно к функциональности имеющихся или предполагаемых программных продуктов/платформ, на которых прогнозируется разработка. Другими словами, здесь делается независимое от конфигурации 1С описание бизнес-процессов и аналитик свободен от ограничений планируемой платформы для разработки. Заполнения справочника «Шаги процессов», по сути, означает завершение работы бизнес-аналитика (бизнес-архитектора) и передачу работы Архитектору системы и возглавляемым им проектировщикам. Что, впрочем, не исключает параллельности работы по описанию бизнес-процессов и работы команды проектировщиков с архитектором во главе.

           3) Уровень работы системного архитектора

К каждому элементу «Шагов процесса» привязывается  группа или элемент справочника «Функции». Таким образом, происходит связка функциональности проектируемой системы с бизнес-процессами. За проектирование справочника «Функции» отвечает Архитектор. Он должен описать имеющуюся/разрабатываемую  платформу в виде групп и элементов справочника «Функции».

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

Если Архитектор использует готовую систему (платформу, ПО), например: типовую  конфигурацию 1С или доработанную конфигурацию заказчика,  то «общий язык» для работы уже готов, но необходимо все слова языка (объекты метаданных) привязать к справочнику «Функции», т.е. формализовано описать функционал системы. Если какого-либо функционала для реализации бизнес-процессов заказчика недостаёт, то необходимо либо добавить объекты в конфигурацию и/или описать недостающее в справочнике «Функции».

Справочники «Процессы» и «Функции» связаны через подчинённые справочники, соответственно «Шаги процессов» и «Операции».

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

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

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

  1. Уровень работы методологов

Задачей Методологов является сбор требований к системе. Требования собираются как от заказчика и участников проекта с его стороны,  так и от аналитиков и методологов и иных членов команды  исполнителя проекта. В СППР для этого предусмотрен справочник «Требования». 

В виде требований формализуются также отчёты об обследовании и протоколы встреч.

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

Встаёт вопрос:  А как понять, сколько этапов необходимо? Когда методологи могут закончить свою работу и передать её дальше другим участникам проекта?

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

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

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

Таким образом, если задать строгий список видов «Объектов методологии», то методологи смогут детализировать предметную область и требования до Объектов методологии, а Архитектор и проектировщики смогут связать объекты данных с объектами метаданных.

В СППР Объекты методологии являются элементами справочника «Объекты данных».

По предлагаемой технологии каждое требование связывается строго с одним объектом данных через поле «Основание» - тип поля «Объект данных». Отсюда следует, что согласно технологии, если требование может быть реализовано только через несколько объектов данных, то методологи обязаны детализировать требования на несколько подчинённых требований. Таким образом, критерий «одно требование» = один объект данных является ключевым для проектирования системы, поскольку позволяет объективно выразить результат работы методологов и определить точку, в которой их работа может считаться выполненной.

Список видов объектов методологии будет выглядеть следующим образом:

ОБЪЕКТЫ МЕТОДОЛОГИИ (для просмотра изображений, откройте их в новом окне)

  1. Уровень работы проектировщиков

Задачей проектировщиков является связка Объектов методологии (Объектов данных) с Объектами метаданных.

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

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

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

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

  1. Уровень работы разработчика/ служб сопровождения ПО

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

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

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

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

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

  1. Уровень работы Системы управления проектами

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

Во-первых, это создание объектов вида «Регламенты» по типам объектов СППР, т.е. объектами над которыми работает команда. И создание объектов «Стандарты разработки».

Во-вторых, это создание объектов «Целевая задача», привязанных к Требованиям и/или Техническим проектам. Целевые задачи помогают выделить и контролировать ход тех шагов проекта, которые не указаны в «Шагах проекта», т.е в согласованной с заказчиком документации, и которые возникли по ходу проекта и сроки их исполнения нужно отслеживать.  Целевые задачи создают в привязке к конкретному члену команды, ответственному за её исполнение и отчёт по ней.

В-третьих, управляющие комментарии к объектам СППР, они в текстовом формате записываются в поля и закладки вида «Заметки». Это, по сути, внутренняя памятка для членов команды в привязке к объектам СППР. Всё что относится к выдаче заказчику вносится в поля и закладки вида «Описание».

В-четвёртых, это система отчётов и рассылок отчётов. С её помощью проводится мониторинг хода проекта и проектных событий.

В-пятых, и самый интересный инструмент, это функционал «Правила проверки объектов».

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

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

Описав схему работы 1С СППР, можем перейти к описанию собственно предлагаемой технологии.

 

ОПИСАНИЕ ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ АРХИТЕКТУРЫ ПО

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

  1. Вход (стрелка слева)

  2. Выход (стрелка справа)

  3. Управляющее воздействие (стрелка сверху)

  4. Механизм  преобразования входных потоков в выходные (стрелка снизу).

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

В текущих релизах 1С СППР (на момент написания статьи это релиз 1.1.24) описание схемы и связей функций реализовано очень неудобно для пользователей. Объекты схемы создаются рисованием на закладке «Схема функции IDEF0» элемента справочника «Функции», некоторые объекты 1С СППР может отразить на схеме автоматически. Все объекты схемы выводятся в виде списка на закладку «Описание элементов схемы», где единственный элемент управления, доступный пользователю, это поле «Гиперссылка», где он может выбрать тип объекта, отражаемого на схеме и выбрать сам объект из справочника.

При этом на созданной схеме:

  1. Вход/Выход /Управление /Внутренняя связь – это ссылка на элементы справочника «Объекты данных»

  2. Исполнитель – это ссылка на справочник «Профили пользователей»

  3. Функция – это ссылка на справочник «Функции».

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

По предлагаемой мною модифицированной технологии 1С, функция понимается как конечная, если вход в неё не является выходом какой-либо функции. Таким образом, конечная функция на входе имеет только внешние потоки:  информации/сырья/ и т.п.  Тогда архитектор должен (обязан!) декомпозировать функции до тех пор, пока не опишет все входы в систему извне.

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

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

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

При этом обеспечивающими условиями описываемой технологии являются:

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

  2. Нельзя добавить/модифицировать объект метаданных не привязав его к конкретной функции (справочники: Функции и Операции)

  3. Нельзя добавить функцию не привязав её через требования к бизнес-процессам заказчика (справочники: Процессы и Шаги процессов)

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

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

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

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

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

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

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

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

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

Если обратиться к таблице «Объекты методологии» и элементу «Структура проектного документа» и вспомнить какой объём документации разрабатывается на предпроектном этапе и на этапе бизнес-анализа и по итогам сдачи проекта, особенно в формате ГОСТ на ПО, то на основе ранее выполненных проектов можно с помощью метода COCOMOII получать оценку сроков и стоимости будущего проекта. Более детально это можно изложить, если читатели проявят интерес.

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

 

Заключение

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

Для заказчика приёмка результатов работы франчайзи и интеграторов в виде псевдоформализованных под ГОСТ и ISO документов и кода чревата потерями времени и денег, сильной зависимостью, а значит затратами, на сопровождение.

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

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

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

 

Контакты автора:

Роман Кальмансон

89037395655@mail.ru

Приложение  1

 

41

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. kalyaka 478 04.10.18 09:39 Сейчас в теме
Сложность технологии проектирования в том, что одни и те же процессы можно по разному описать, делая различные акценты. Это вечный вопрос: где границы у подпроцессов, где зоны ответственности и т.д.. Могут существовать различные точки зрения: акционера, финансового менеджера, бухгалтера, снабженца и т.д. Чтобы как то справиться со всем этим разнообразием нужно проделать титаническую работу самому объекту автоматизации, а зачастую объект осознает только потребность в автоматизации, но не хочет или не может проделать работу по формированию своего "видения".
Франчу же нужно продать маркетинговое видение + хотелки влиятельных заказчиков (стейкхолдеров). И дело тут не в технологии, а в зрелости объекта автоматизации и пока в подавляющем количестве она низкая. Хотя у франчей своя технология, отличная от описанной :) - это технология продвижения решений на платформе 1С в как можно большем количестве. Франч - это ж технология копирования определенного ведения бизнеса, прописанного в данном случае компанией 1С. Франч не может отклоняться от технологии работы по договору франчайзинга, которую кстати разрабатывает и контролирует сама же 1С.
4. roman72 103 04.10.18 19:57 Сейчас в теме
(1) По поводу "зрелости объекта автоматизации" вы абсолютно правы. Тем не менее, заказчик/объект автоматизации может оставить за собой право не быть специалистом по проектированию и право нанимать на формирование своего "видения" сторонних специалистов. А тем, кто выполняет такие контракты, следует придерживаться какой-то технологии, ведь это их производственный процесс. И тут вы опять правы, такие технологии могут быть разные. В статье я предложил одну из них, но она имеет в базисе математический аппарат, что в потенциале позволит очень хорошо автоматизировать процесс проектирования и автоматизацию проверки качества проектирования.
Насчёт того, что франчи ограничены требованиями 1С в реализации проектов на типовых решениях 1С не согласен. Решений на чистых типовых конфигурациях 1С очень мало. Сложные проекты подразумевают существенную переделку конфигураций и системного ландшафта. Требования 1С сродни требованиям ISO - дают общие границы, но не настолько детальны, чтобы франчи были несвободны в выборе мтодик исполнени япроектов.
2. kembrik 2 04.10.18 14:53 Сейчас в теме
Жаль что функциональные модели для типовых конфигурация пока есть только для "1C:ERP Управление предприятием 2". Ну и с расширениями текущая версия СППР работает, гм, весьма ограниченно. Пока отложили конфу "под сукно".
5. roman72 103 04.10.18 20:11 Сейчас в теме
(2) Модель ERP я пробовал загружать и изучать в 1С СППР. Но эта модель малополезна, поскольку во-первых, она неглубоко и нетщательно написана, в частности бизнес-процессы "заказчика?!" в неё заложены примитивные. Фактически 1С в модели ERP описало функциональность конфигурации простым повторением подсистем ERP из конфигурации. Во-вторых, уровень детализации в модели недостаточен для корректной проектировки. Посмотрите, например, операции пользователей. В большей степени модель ERP от 1С - это демо. С её помощью проблемно автоматизировать проверку качества проектирования.
Я не встретил в СППР принципиальных проблем при работе с расширениями. СППР работает сразу с несколькими конфигурациями. Можно, при желании и проблемах, все расширения описывать в отдельной от основной конфигурации. Всё-равно эти конфигурации не будут переданы разработчику. Они нужны лишь для обеспечения общего языка для бизнес-аудиторов-методологов-проектировщиков-разработчиков-менеджеров проектов.
3. Steelvan 04.10.18 17:24 Сейчас в теме
Автор, что вы думаете по поводу использования https://www.visual-paradigm.com ?

Вроде позволяет больше возможностей. Есть и uml, и bpmn и документация тут же, и задачница.
6. roman72 103 04.10.18 20:59 Сейчас в теме
(3) Посмотрел инструмент по ссылке. Я никогда в нём не работал, поэтому сказать о нём могу немногое. Функционал, заявленный в нём, судя по сайту, шикарный. Но, в статье предлагается технология работы основанная на "общем языке". Заложено ли это в VisualParadigm мне не известно. Если общего языка в нём нет, то весьма проблемно организовать совместную работу бизнес-аналитика, методолога, архитектора, проектировщиков, разработчиков как технологию производства и так, чтобы проверку качества проектирования можно было автоматизировать.

VisualParadigm не единственный инструмент, таких достаточно, но у большинства из них очень сильный упор на графическое описание бизнес-процессов. Это значит, что человек рисует бизнес-процессы в том или ином формате. Это также означает, что возможность описывать сложные бизнес-процессы очень сильно ограничивается ментальными возможностями человека. Человек не в силах держать в голове сложные ментальные и процессные карты. А когда в эти карты следует вносить массовые изменения, то становится ещё хуже.

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

Попробуйте в 1С EDT сформировать ER-диаграмму сразу всей конфигурации 1С:Управление холдингом или 1С:ЕРП, а потом посмотрите насколько удобно работать с промоткой объектов и просмотром взаимосвязей
и как быстро теряется нить связи, если объекты уезжают за границы экрана.

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

Поэтому VisualParadigm как и другие подобные инструменты будут хороши до определённого уровня сложности проекта и сложности самой проектной команды.
Для исполнение сложных проектов качественно необходимы математический аппарат и автоматизация управления качеством проектирования.
7. tindir 05.10.18 12:03 Сейчас в теме
реквестируем более детальный обзор СППР и применимость его для внутренней разработки внутри холдинга
ImHunter; +1 Ответить
9. roman72 103 05.10.18 22:53 Сейчас в теме
(7) Чем по вашему мнению этот детальный обзор должен отличаться от руководства от 1С и от статьи выше?
Касаемо применимости для внутренней разработки холдинга и любой компании, имеющей зоопарк учётного ПО, технология таже самая, что и предложенная в статье.
Разница между интегратором (франчайзи) и "холдингом" только в том, что для интегратора это доходная деятельность, а для холдинга - затратная. Хотя и необходимая.
12. tindir 07.10.18 18:54 Сейчас в теме
(9)
обзор
это больше "обзор" с брошюры. А хотелось бы поглазеть на разбор схемы (хотя бы минимальной). По части доходный/расходный это азбука. Интересна тема по части выхлопа. Можно ли получить больше контроля за доработкой в команде из 5-8 человек (у всех свои контуры правда), что бы не случилось как случилось у нас - два человека с разных сторон заавтоматизировали одну фичу,только для разных подразделений.
13. roman72 103 07.10.18 23:00 Сейчас в теме
(12) Обзор сделан не из "брошюры". В брошюре от 1С совсем другая подача материала и другой подход, в частности 1С не даёт никаких предложений по математическому подходу и алгоритмизации и автоматизации проектирования и разработки. 1С СППР даёт прямой контроль за проектированием, но лишь косвенный контроль за разработкой, код то в 1С СППР не пишется. Команда из 5-8 человек означает что проектировщиков нет. Если хотите контроль за избыточностью фич, то надо проектировать прежде чем разрабатывать. А это удлинение времени исполнения проекта. Схема контроля за избыточностью фич-функционала есть, она простая и в статье в принципе описана: Проектировщик описывает функциональность системы, а разработчик пишет код с ограничением на создание объектов метаданных и с соблюденеим требований по написанию кода в части деления на процедуры. Исключение избыточных фич/функционала делается в 1С СППР через а) обязательное следование математическому описанию функционала в виде незамкнутых графов б) автоматическим контролем качества проектирования средствами СППР.
14. tindir 08.10.18 05:05 Сейчас в теме
(13)
до проектировать прежде чем разрабатывать

оке. Принял. Спасибо за информацию. Вы правильно подметили, что у нас нет проектировщика. Каждый разработчик держит свой блок разработки - производство, зп, бух, продажи. сейчас возникла идея реализовать что-то вроде листа фич под разработку в общем доступе, что бы перед тем как начинать реализацию проверять, а нет ли уже смежных решений от коллег.
15. roman72 103 08.10.18 19:28 Сейчас в теме
(14) Лист фич - верное решение и вполне естественное. Но его будет недостаточно. Надо ещё вести реестр объектов и процедур, используемых под каждую фичу. Плюс ещё надо отслеживать потенциальные проблемы производительности из-за новых объектов и процедур. Плюс ещё отслеживать результат постоянных модификаций взаимосвязи фич/объектов/процедур.
16. tindir 09.10.18 09:50 Сейчас в теме
(15) Дык, это и подразумевается под листом фич. Если разработка больше часа (то есть не "печатные формы") то регистрируется фича (по виду "регистрация проведения тендерных игрищ") и описывается или прикладывается инициализирующие документы (служебка, ТЗ и т.д.), формируется список работ и потом уже реализуется кодовая составляющая. Но тут уже есть проблема, когда коды накодены разработчику будет лень переносить их описание даже в СППР, тут надо пильнуть выгрузку метаданных...
17. roman72 103 09.10.18 13:34 Сейчас в теме
(16) То, что вы называете "описанием кодов которые надо перенести в СППР" это не лень разработчика, а целая отдельная проблема. Которая не решается простым листом фичей. Поскольку помимо регистрации фичей (нового функционала) надо отслеживать пересечение объектов и процедур, как "типовых", так и вновь разрабатываемых. К примеру, одна и таже процедура может делать распределение затрат для типовых объектов 1С и быть частью доработанной процедуры по специфичному для заказчика алгоритму. Если для доработанной процедуры вы повторите типовой алгоритм как "независимый" в отдельной процедуре, то потом может встать вопрос как синхронизировать изменившуюся типовую процедуру с её клоном в фиче. И т. и т.п. Да и кодовая составляющая "фичи" может быть заключена в сонме разросанных по конфигурации объектов - и в глобальном модуле и модуле объектов и т.п. Для программиста выявить все связки и привязать просто к "фиче" это затратно по времени. А если фича будет разделена на две и более фич? Это всё к тому, что если ввязались в управление разработкой через проектирование, то лучше сразу изучить тему и использовать технологию целиком, а не её стартовую часть "лист фич". Постоянно будет запоздалая реакция на ошибки...
10. acanta 48 05.10.18 23:21 Сейчас в теме
Разница в том, что для интегратора это единственная доходная деятельность, а для холдинга - далеко не единственная затратная.
Любой интегратор является конкурентом всех подразделений холдинга за ресурсы и внешних интеграторов прогнуть гораздо сложнее, чем собственный отдел разработки.
11. roman72 103 06.10.18 13:27 Сейчас в теме
(10) Хм, внешних интеграторов прогнуть сложнее? Призываю внешних интеграторов высказаться сюда о прогибании )
18. user884676 11.12.18 12:08 Сейчас в теме
Думаю, основная проблема в том, что роли бизнес аналитика, методолога, архитектора и проектировщика на проектах часто выполняют одни и те же люди. В итоге они обладают недостаточной компетенцией и сильно ограничены во времени. Завести же "каждой твари по паре" мешает рыночная ситуация, в которой бюджеты проектов зачастую просто не выдерживают такой нагрузки на ФОТ команды.
19. roman72 103 11.12.18 22:05 Сейчас в теме
(18) Согласен. Но причине не всегда в бюджетах проектов. Очень часто владельцы ERP не понимают, что к ней нужен совсем другой подход. Нельзя в ERP ставить задачи напрямую программистам. Только через предварительное проектирование.
Оставьте свое сообщение