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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вполне.

Решение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В 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