Логические и форматные ошибки сообщений

Методы контроля данных. Форматный и логический контроль информации.

Цель работы: освоить основные методы обнаружения ошибок; получить навыки определения форматных и логических ошибок в информационных сообщениях, отработать эти навыки на примере сообщения 02.

Структурный и логический контроль входных сообщений.

Пример выявления ошибок в служебной и информационной фразах сообщения 02.

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

Основными причинами снижения достоверности получаемых результатов (выходной информации) в АСУ являются:

— искажение информации из-за сбоев и отказов аппаратуры подготовки данных (АПД) при ее передаче, обработке и отображении;

— воздействие электромагнитных и других помех в каналах связи при передаче, хранении и обработке информации;

— алгоритмические и программные ошибки;

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

3.1. Основные методы обнаружения ошибок.

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

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

— метод контрольных сумм;

— защита кодов и реквизитов контрольным числом;

— контроль формата сообщения;

Метод контрольных сумм широко используется на этапах подготовки первичной информации, ввода массива данных в ЭВМ, считывании информации с накопителей и записи на них.

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

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

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

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

Различают форматный и логический контроль.

При форматном контроле:

определяется число знаков в каждом введенном показателе и сравнивается с необходимым их количеством,

проверяется наличие допустимого количества показателей во введенном сообщении,

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

При логическом контроле:

проверяется значение каждого показателя сообщения области допустимых значений, которая содержится в НСИ,

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

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

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

При обнаружении ошибок абоненту, пославшему сообщение, выдается диагностическое сообщение 497, содержащее наименование показателей, где обнаружены ошибки и коды ошибок. В табл.1 приведены примеры ошибок, выявляемых в процессе форматного и логического контроля.

Приложение Б (информационное)

Перечень ошибок структурного и логического контроля входных сообщений

Номер исходящего сообщения

Краткая аннотация ошибки

02, 09, 200-205, 333, 241, 242, 244, 249, 555

Несуществующий номер исходящего сообщения

Исправить номер сообщения и ввести его заново в ЭВМ

02, 09, 200-205, 333, 241, 242, 244, 248, 249, 555

Количество показателей в фразе больше или меньше допустимого

Для сообщения 02: служебная фраза может содержать минимум 11 показателей («дата и время» включительно) и максимум 15 показателей («Маршрут» включительно). Информационная фраза — минимум 3 показателя («Ролик» включительно), максимум 15 показателей («Примечание» включительно)

Для сообщения 09: а) служебная фраза — min 11 показателей («Минуты» включительно) и max 12 показателей («Номер парка / номер пути» включительно). Информационная фраза — min 2 показателя («Номер вагона» включительно), max 15 показателей («Примечание» включительно); б) по операции прицепки (код 14): после информационной фразы с кодом корректировки 14 должна следовать информационная фраза с кодом корректировки 00, которая включает номер вагона и необходимые сведения о нем.

02, 09, 200-205, 333, 241, 242, 244, 248, 249, 555

Количество показателей в фразе больше или меньше допустимого

Для сообщения 241: служебная фраза должна содержать 8 показателей («Код операции» включительно). Информационная фраза — минимум 4 показателя («Масса груза» включительно), максимум 13 показателей («Примечание» включительно).

Для сообщения 242: служебная фраза должна содержать 8 показателей («Код операции» включительно). Информационная фраза — минимум 2 показателя («Номер вагона» включительно), для первой фразы — минимум 4 показателя («Код грузополучателя» включительно) и максимум 7 показателей («Примечание» включительно).

Для сообщения 200, 201, 204: служебная фраза может содержать минимум 11 показателей («Дата и время» включительно) и максимум 13 показателей (для номера 200 «Номер пути перегона»; 201, 204 «Признак работы с локомотивом» включительно).

Для сообщения 202, 203, 05: может содержать минимум 11 показателей («Минута» включительно) и максимум 15 показателей («Номер парка / номер пути» включительно).

02, 09, 200-205, 333, 241, 242, 244, 248, 249, 555

Количество показателей в фразе больше или меньше допустимого

Для сообщения 200, 201: информационная фраза может содержать минимум 7 показателей («Табельный номер машиниста» включительно) и максимум 8 показателей («Фамилия машиниста» включительно).

02, 09, 200-205, 333, 241, 242, 244, 248, 249, 555

Отсутствуют информационные фразы или все информационные фразы ошибочны

Неверно оформлен маршрут, группа вагонов, следующих по одной накладной, сцеп, рефрижераторные секции и поезда

Маршрут, группа вагонов, следующих по одной накладной, сцеп, рефрижераторные секции и поезда оформляются согласно инструкции по ДУ-1

02, 09, 241, 242, 248, 249, 555

Не возрастают номера информационных фраз исходного сообщения

Для сообщений 02, 241, 242: если в сообщении нет других ошибок, то сообщение принимается к расчету, при этом ЭВМ нумерует информационные фразы в порядке возрастания фраз (ошибка является предупреждающей)

02, 09, 241, 242, 248, 249, 555

Не возрастают номера информационных фраз исходного сообщения

Для сообщения 09, 248, 249: а) после информационной фразы с кодом корректировки 02, 04, 14, 33, 81, 83, 86, 88, 91 должна следовать информационная фраза с кодом корректировки 00, содержащая номер вагона и необходимые сведения о нем; б) в первой информационной фразе код корректировки не может быть равен 00.

02, 200-205, 333, 241, 242, 244, 248, 249, 555

Отсутствует значение требуемого показателя исходного сообщения

необходимо дополнить фразу требуемыми показателями (NC — номер показателя)

02, 200-205, 333, 241, 242, 244, 248, 249, 555

Значение показателей во фразе не соответствует друг другу

К фразе исходного сообщения NC1 должен соответствовать показателю NC2.

Неверно оформлен маршрут

Если в служебной фразе сообщения 02 признак маршрута проставлен от 1 до 4, то в информационной фразе принадлежность вагона к маршруту указывается цифрой 2. Общая масса маршрута против первого вагона разрешается проставлять только при перевозке грузов прямыми и кольцевыми маршрутами. При формировании маршрутной групповой отправки с признаком от 3 до 6 масса груза должна быть указана против каждого вагона.

200-205, 241, 242, 244, 248, 249, 555

Значение показателей служебной и информационной фраз не соответствуют друг другу

Показатель NC1 служебной фразы должен соответствовать показателю NC2 информационной фразы

02, 09, 241, 242, 248, 249, 555

Одинаковые инвентарные номера вагонов

02, 09, 200-205, 333, 241, 242, 244, 248, 249, 555

Код пункта передачи из автоответа не соответствует станции совершения операций из сообщения

02, 09, 200-205, 333, 241, 242, 244, 248, 249, 555

02, 09, 200-205, 333, 241, 242, 244, 248, 249, 555

Нет начала «(:» или конца «:)» исходного сообщения

В ЭВМ для сообщения 02 есть информация о поезде с подробным индексом

Если при поступлении сообщения 02 установлено, что в ЭВМ есть сведения о поезде с таким же индексом (на который не передавались другие сообщения) и совпадают инвентарные номера хотя бы у трех вагонов, то сообщение принимается к расчету, заменяя предыдущее; в противном случае сообщение принимается к обработке, присваивая третий знак порядковому номеру этого состава (слева относительно двух основных) и информирует от этом абонента

09, 200-205, 244, 333, 555

Информация о данном поезде нет в ЭВМ или в ней имеются ошибки. В ЭВМ нет информации о вагонах, на которые пришло информационное сообщение

Недопустимое значение служебных символов Щ1, Щ2, апостроф

NC — номер показателя, который принимает недопустимое значение. Символ Щ1 используется для пропуска нулевых показателей с 4 по 8 включительно; Щ2 — для пропуска нулевых показателей с 9 по 14 включительно; ‘ (апостроф) — для разделения (начиная с 4-го показателя включительно) буквенного и буквенно-цифрового примечания от остальной информации в случае, когда нужно опустить незначащие реквизиты строки до графы «Примечание»

02, 09, 200-205, 333, 241, 242, 244, 248, 249, 555

Недопустимое значение показателя исходного сообщения

NC — номер показателя, который принимает недопустимое значение. Для сообщений 09: а) код корректировки может принимать только значение 01, 02, 03, 04, 06, 08, 11, 14, 33, 81, 83, 86; б) нельзя удалять группу вагонов из маршрута с одной массой в голове, если масса груза после удаления группы больше, чем суммарная масса вагонов в маршруте

02, 09, 200-205, 333, 241, 242, 244, 248, 249, 555

Количество знаков в показателе больше или меньше допустимого или недопустимый (нецифровой) символ

Корректируемых фраз нет в исходном сообщении

Для сообщения 09 ошибка возникает, когда в составе поезда нет отцепляемого или перецепляемого вагона, вагона, у которого корректируются данные, или вагона, за которым (перед которым) вставляются или прицепляются вагоны. Для сообщений 248, 249 ошибка возникает, когда в ЭВМ нет удаляемого вагона или вагона, за которым должны вставляться вагон или группа вагонов

241, 242, 244, 248, 249

Нарушена порядковая нумерация сообщений

Локомотив отсутствует в числе контролируемых

Недопустимый интервал времени между текущей и предыдущими операциями

Нарушена логическая операция с поездом

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

Время совершения операций дольше текущего

Для сообщений 02, 09 время, указанное в служебной фразе, не должно превышать времени ЭВМ больше чем на 10 минут. Для сообщений 200-205 время, указанное в служебной фразе, не должно превышать времени ЭВМ

Дата и время совершения операций меньше времени предыдущего сообщения

Дата и время совершения операций меньше или равны дате и времени предыдущего сообщения

02, 09, 200, 201, 202, 241, 242, 248, 249, 555

Неверно указан контрольный знак в инвентарном номере вагона (локомотива)

Количество фраз в сообщении больше допустимого предела

Нарушение плана формирования поездов или вагонов

Поезд недогружен (указывается масса недогруза в тоннах — XXX)

Ошибка является предупреждающей и исправлений не требует

Поезд следует с нарушением нормы длины (указывается количество недогруженных вагонов)

Большая Энциклопедия Нефти и Газа

Логический контроль основан и на сравнении с данными прошлого периода. Например, достоверность данных о выпуске продукции по видам может быть проведена сравнением с данными прошлого периода для того же предприятия. Кроме того, логический контроль опирается на представления о пределах возможных значений признака: минимуме и максимуме.  [1]

Логический контроль включает проверку пароля абонентов, отсутствия недопустимых сочетаний признаков. При об-нарушении ошибок запрос к дальнейшей обработке не принимается, а на печать выдается информация об ошибках; б) интерпретация вопроса состоит в распознавании вида запроса: на выдачу показателя и документов, формирование рабочих массивов, изменение и пополнение базы данных; в) поиск данных: обращение к рабочей области в памяти, выборка некоторых данных или их корректировка в базе; г) редактирование: найденные в БД данные тщательно контролируются и анализируются, а затем редактируются ответы, которые выдаются на печать.  [2]

Логический контроль состоит в сопоставлении ответов на взаимосвязанные между собой вопросы программы наблюдения для выявления несовместимых ответов. Например, при переписи населения вопросы о возрасте, грамотности, семейном, положении контролируются один другим. Если, например, окажется, что десятилетний ребенок женат или двухлетний — грамотен, то ясно, что при заполнении бланка допущены ошибки при записи возраста или семейного положения.  [3]

Логический контроль позволяет проверить внутридокументные связи между элементами сообщения.  [5]

Логический контроль основан и на сравнении с данными прошлого периода. Например, достоверность данных о выпуске продукции по видам может быть проведена сравнением с данными прошлого периода для того же предприятия. Кроме того, логический контроль опирается на представления о пределах возможных значений признака: минимуме и максимуме.  [6]

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

Логический контроль состоит в сопоставлении разных показателей отчета ( ответов на разные вопросы анкеты) с целью выяснения их логической совместимости. Если, например, у обследуемого лица указан возраст 10 лет и высшее образование, то, очевидно, один из ответов ошибочен. Важными приемами логического контроля служат сопоставление отчетных данных за смежные периоды, сравнение их с нормативными и плановыми показателями, со средними для совокупности. При значительных отклонениях полученные данные подвергаются всесторонней проверке, отчетную единицу дополнительно запрашивают о правильности представленных данных.  [8]

Логический контроль , так же как и арифметический, основывается на знании взаимосвязей между показателями, но не количественных, а логических. Например, человек в возрасте шести лет не может состоять в браке, поэтому, если в бланке переписи имеются одновременно обе записи, то это показывает, что одна из них не соответствует действительности.  [9]

Логический контроль должен проводиться только на цифровой информации. Значность отдельного реквизита не должна превышать заданного числа знаков с учетом точки и знака числа.  [10]

Логический контроль выполняемых операций осуществляется программно при задании соответствующего режима работы программы. Сеть может проверяться на формальное описание. Некорректные записи программно исключаются; может проводиться корректировка информации о сети и пересчет кратчайшей трассы между заданными точками. Выбранная таким образом трасса будет оптимальна по металлоемкости.  [11]

Логический контроль готового носителя производится на ЭВМ и охватывает контроль формата машинных документов ( записей) и контроль на попадание реквизитов в нужный диапазон. Он должен производиться с помощью специальной стандартной программы, которая должна обеспечивать распечатку ошибочных записей. После исправления ошибок, выявленных в процессе логического контроля, носитель считается годным, если на одну бобину с перфолентой приходится не больше двух склеек. Далее перфолента должна быть снабжена контрольной суммой и передана на копирование.  [12]

Если логический контроль пользователя свйзан с обращением к внешним файлам, то это, как правило, приводит к задержкам в работе всех операторов. Поэтому если ЛКП используется, например, для проверки наличия реквизита в каком-либо словаре или базе данных, то достаточно будет использовать ЛКП только во время ввода, а при верификации отключать.  [13]

Осуществляется структурный и логический контроль информации , описывающей переменные коэффициенты столбца.  [14]

Операция логического контроля и анализа показателей предусматривает проверку плановых и фактических показателей путем их сопоставления между собой и с соответствующими показателями предшествующего отчетного периода. На основе имеющихся статистических данных задается уровень возможного разброса — значений показателя в пределах заданного отчетного периода.  [15]

Что обозначает логический контроль вводимой информации

2. Принципы форматно-логического контроля

2.1. В целях повышения уровня достоверности вводимой Клиентом, пользователем ЕАСАПР СФТО, АСУ ПРАВО информации используются следующие способы контроля вводимых данных:

соответствие вводимых данных требуемому формату;

выбор значения поля из справочников;

проверка заполнения обязательных полей;

проверка нарушения целостности данных.

2.2. Форматный контроль вводимых данных предусмотрен для ввода Клиентом или пользователем ЕАСАПР СФТО, АСУ ПРАВО информации в поля системы при создании или редактировании данных. При этом контроль выполняется для следующих форматов полей:

ввод даты и времени;

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

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

2.4. В случае возникновения ошибок при вводе данных программа выводит соответствующие предупредительные сообщения.

Автоматизируй это

Сколько нужно программистов, чтобы сделать форму для пользователя? Ни одного! Для этого достаточно создать инструмент, с помощью которого создавать формы для web-решений смогут даже домохозяйки.

10 тысяч электронных услуг

Представьте себе портал, с огромным количеством различных пользовательских форм. Например, такой как gosuslugi.ru, где имеется порядка 10 000 электронных форм получения государственных услуг. Представили? А теперь представьте, что людей, которые генерят требования для создания этих форм, то есть заказчиков, примерно в 10 раз меньше чем самих форм — всего-то около тысячи. Ну и, наконец, представьте сколько нужно разработчиков, чтобы сделать около 300 уникальных, со своими тараканами, форм за месяц? Около 100! Причем они должны быть высококвалифицированные, чтобы самостоятельно могли все сделать. Стажеры тут не справятся. А еще каждую форму надо перед разработкой проанализировать, после — протестировать, дать заказчику на приемку, поправить замечания и передать на установку. А это значит, что нужны еще тестировщики и аналитики.

Итого получается около 200 высококвалифицированных человек на месяц. Если предположить, что такую команду и получится собрать, что само по себе почти невозможно, себестоимость такой разработки будет зашкаливать и многократно превышать адекватную на рынке стоимость такой работы. Очевидно, чтобы решить такую задачу, необходимо что-нибудь автоматизировать. Но что?

А что такое услуга?

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

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

Автоматизация, Карл!

По-любому надо что-то автоматизировать, скажете вы. И будете правы. Первый кандидат – пункт 4. Надо сделать сервис, который будет принимать на вход готовый к отправке XML и отправлять его на СМЭВ. ОК, готово, сделали. Еще? Да черт возьми, пункт 3! Процесс подписания-то одинаковый всегда. ОК, готово сделали еще один сервис. На входе XML, на выходе подписанный XML. Круто! Больше автоматизации, Карл! Осталось два пункта – создание формы и генерация XML документа по формату ведомства. Хм, а вот и проблема…

Классика жанра

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

Было решено, что нужен инструмент, позволяющий:
— максимально просто описать внешний вид формы, форматно-логический контроль для полей, логические связи между полями.
— дать возможность максимально просто на основе заполненной формы сгенерировать XML-документ нужного формата.

Что скажет опытный разработчик про такую задачу? Надо писать фреймворк. Сформировали основные требования к нему и побежали кодить:

– Стандартизация внешнего вида форм, создание набора виджетов
– Легкая кастомизация, настройка виджетов
– Возможность подключать к разработке младших разработчиков и стажеров
– Наследование разработанными ранее формами всех последующих изменений в ядре
– Автоматическая генерация выходного XML документа по шаблону

В качестве технологий было выбрано:
– Слой БД: Oracle Database
– Слой приложений: Java 1.6
– Backend-шаблонизатор: Freemarker
– Frontend-фреймворк: набирающий в то время популярность jQuery

Результаты не заставили себя ждать. Буквально через месяц после начала разработки фреймворка выстроилась достаточно простая схема работы:

Аналитик получает ТЗ на разработку услуги, валидирует его и при необходимости прорабатывает с заказчиком, после чего передает разработчику.

Команда разработки ядра состояла в разное время из 4-8 человек – 2 фронта, 2 бэка, тестировщик и тимлид. Минимальная команда разработки услуг составляла 2 человека – половина аналитика, разработчик и половина тестировщика. Внедрение фреймворка позволило сформировать несколько независимых команд разработки услуг, а в последствии и несколько десятков таких команд, распределенных территориально. Каждая команда могла создавать 1-3 услуги в месяц, в зависимости от их сложности, а time-to-market каждой формы составлял в среднем 35-50 дней.

Таким образом производительность двадцати команд (

50 человек) составляла около 40 услуг в месяц. Неплохо. Но недостаточно. Задача была – 300 в месяц. Наращивать состав команды было уже экономически не выгодно, нужно было более оптимальное техническое решение.

Инновациям дорогу!

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

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

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

«Зачем тут вообще разработчики?», спросили мы себя. И действительно, что в нашем случае делал разработчик? Собирал страницу с вызовами виджетов и указывал настройки для них. Почему бы не сделать для этого пользовательский интерфейс? Как в Delphi или Visual Studio.

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

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

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

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

• текстовое поле
• виджет ввода даты
• радиокнопка, чекбокс
• выпадающий список
• поле загрузки файла
• виджет ввода адреса по КЛАДР или ФИАС
• кнопка
• таблица

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

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

– Создаем форму
– Выбираем из выпадающего меню нужные нам элементы, размещаем на форме
– В инспекторе атрибутов настраиваем поля, как нам требуется с помощью галочек, кнопочек и списочков
– Настраиваем валидацию полей, выбирая нужный метод проверки или набор методов из списка доступных
– Настраиваем взаимосвязи между полями
– Подкладываем XSLT шаблон формирования результирующего XML документа
– Указываем реквизиты системы-получателя
– Форма готова!

Еще одно огромное преимущество — независимость описания формы от платформы исполнения. За счет того, что форма хранится в виде метаописания в формате JSON, которое лишь описывает состав компонентов формы и их взаимосвязи, но не описывает представление, достаточно один раз разработать форму в конструкторе и ее можно исполнять на любом устройстве, для которого существует проигрыватель форм: например, на платформе iOS или Android, SmartTV и других.

Какие основные плюсы мы получили на втором витке развития фреймворка? Для разработки самих форм больше не требовались разработчики вообще. От специалиста, создающего формы требовалось только уметь пользоваться графическим интерфейсом конструктора форм и уметь написать простое XSLT-преобразование. Этого хватало для большинства форм. Были, конечно, и сложные случаи, тогда обращались к команде разработки ядра, которая по заказу за неделю-две разрабатывала необходимую функцию или виджет.

Таким образом состав команды разработки услуг удалось сократить до 1-го человека, так как никакой разработки по сути не требовалось. Создавать формы смогли аналитики, не имеющие навыков разработки. За месяц один человек смог делать 5-7 форм, а time-to-market сократился до десяти дней. В итоге производительность тех же пятидесяти человек составила уже около 300 форм в месяц. То что нужно!

Вот отзывы нескольких представителей команд разработки услуг после пилотного периода использования нового фреймворка:

А это отзыв руководителя группы разработки фреймоворка:

Показатели эффективности

Insight

1. В коммерческой компании любые инновации технологические, организационные или какие-то другие должны быть экономически востребованы и обоснованы.
2. Делать задачу «в лоб» в быстро развивающемся IT-мире значит мгновенно потерять конкурентоспособность. Чаще всего из-за завышенной себестоимости и/или сроков.
3. Необходимо «точить пилу» (С.Кови «7 Навыков высокоэффективных людей»). Если вы занимаетесь развитием инструментов, то имеете конкурентное и технологическое преимущество на рынке.

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