Как перебрать мешок крупы

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

О чем речь? Вместо предисловия

Давайте проанализируем ситуацию от начала создания ТЗ на модификацию ПО до момента фактической приемки работ. Укрупненные группы процессов приведены на схеме 1.

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

Где мы? Разберемся с окружением

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

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

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

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

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

Чтобы провести корректное тестирование (как внутреннее, так и внешнее), необходимо иметь план, в соответствии с которым и производить проверку бизнес-приложения. Как правило, для качественного тестирования больших систем в крупных компаниях применяется ПиМИ (программа и методика испытаний ГОСТ 19.301-79), а для простых систем принято использовать так называемый «контрольный пример». Культурно-компетентная составляющая среднестатистического партнера «1С» предполагает работу с составлением именно контрольного примера, а не полноценного ПиМИ. Это обусловлено как экономической целесообразностью, так и отсутствием необходимых компетенций сотрудников. Составление ПиМИ для партнера «1С» – это высший пилотаж, притом что трудоемкость этого процесса, как и проведения работ по тестированию в соответствии с ПиМИ, гораздо выше, чем при использовании контрольного примера, что не может не сказываться на стоимости и продолжительности этих работ. Да и зачем, если подумать трезво, использовать технологию тестирования, которая существенно усложняет процедуру сдачи работ заказчику, если заказчик ее не требует или не готов за нее платить? В итоге все контрольные примеры и даже большая часть ПиМИ создаются крайне упрощенными, ориентированными на проверку функционала и не дают ответа на вопросы соответствия содержимого, то есть кода, требованиям ИТ и ИБ. В результате такой подготовки к тестированию ожидать на выходе добротного решения практически бессмысленно.

Последняя группа процессов – тестирование. Тестирование и часто приравненная к нему приемка работ осуществляются в основном ключевыми сотрудниками заказчика, которые участвовали в составлении требований к программному обеспечению. Что они могут проверить? В лучшем случае соответствие реализованного функционала системы и корректность расчетных задач на соответствие ТЗ. Это напрямую следует из предыдущего пункта. Но такая проверка не дает возможности проверить принимаемый программный продукт на соответствие требованиям ИТ, таким как производительность бизнес-приложения, документирование кода и пр. Кроме того, программный продукт не проверяется на наличие уязвимостей по ИБ, что в свете последних событий не менее важно. При внедрении типового программного продукта качество кода и отсутствие уязвимостей обеспечивает сам разработчик, в случае же модификации программного продукта мы вынуждены доверять квалификации специалистов внешнего исполнителя, что, как показывает практика, не всегда оправданно.

Добавим к сказанному реальную ситуацию, в которой работают ИТ-директора крупных компаний:

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

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

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

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

Что делать? Ищем выход

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

Что делать, чтобы нивелировать проблемы, создаваемые некачественным кодом? Можно:

а) развивать компетенции сотрудников, что долго и не всегда возможно;

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

в) каждый раз привлекать экспертов для ручного анализа – существенно удорожает любой проект;

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

д) автоматизировать часть дорогостоящей экспертизы.

Ввиду невозможности осуществления первых четырех вариантов мы и пошли по последнему. Попробуем понять, что можно автоматизировать в данном случае.

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

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

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

Ответ на вопрос, каким образом автоматизировать проверку исходного кода в «1С», был найден случайно в разговоре с коллегой, где обсуждались возможности математического движка сканера уязвимости Appercut. Идея состояла в том, чтобы научиться анализировать программный код «1С» и выявлять некорректные кодовые конструкции в автоматическом режиме. В итоге сформулированная задача распалась на две составляющие: с одной стороны, адаптировать математический движок под возможность работы с кодом «1С», а с другой – создать библиотеку паттернов (правил), которые позволят сформулировать для этого движка правила разбора данного кода. Что мы сделали и как это работает, показывает схема 5.

Не буду описывать сам процесс создания продукта для анализа кода «1С», обращу лишь внимание на две особенности. Во-первых, обрабатывать этот самый код оказалось значительно сложнее, чем любой другой (интерпретатор Appercut хотя и умеет работать более чем с 50 языками, но для работы с встроенным языком «1С» пришлось здорово повозиться на уровне самого движка). Во-вторых, наши надежды, что где-то есть описанные правила работы с кодом «1С», не подтвердились. На текущий момент ни у кого из опрошенных нами партнеров нет формализованных правил или описаний некорректностей кода. Это говорит о многом, в частности, почему так страдает качество. Фактически это некое тайное знание языка «1С», которое хранится конкретными экспертами, и получить его можно только у них (впрочем, они не стремятся им делиться по понятным причинам).

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

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

- категория,

- приложение,

- версия платформы.

Мы строили, строили… Что на выходе?

Не вдаваясь в технологические подробности этого проекта, скажу, что результатом автоматизированной проверки кода приложения «1С» стал отчет, вместивший в себя все ALERTы, которые смогла определить автоматизированная система обработки кода. Конечно, не каждый из них в конечном итоге обусловит уязвимости или нарушения требований ИТ, но обратить внимание внедренцев (разработчиков) на данные разделы кода нужно обязательно.

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

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

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

Послесловие

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

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