Сразу начнём с ключевой мысли, которую нужно помнить в течение всей работы над госпроектом:
! все, что написано в контракте, в техническом задании, должно быть выполнено на 100% в указанные сроки.
Если сделать работу только на 95% или опоздать со сдачей на день — это фиаско, друзья. Без соблюдения этих требований нет смысла вникать в детали и разбираться, как устроена такая разработка.

Количество пользователей

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

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

• непрерывная система тестирования и доставки

• отказоустойчивость и дублирование критичных систем

• заложенная в архитектуру проекта масштабируемость и возможность расширения аппаратной части

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

• серверную архитектуру,

• архитектуру приложений,

• прорабатывать систему под эти конкретные нагрузки

Тестирование и ввод в эксплуатацию

В коммерческой разработке тестирование — нормальная часть рабочего процесса во время запуска продукта. Работает это примерно так:

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

2. Также сразу встраивается система мониторинга — так разработчики или техническая поддержка всегда будет моментально в курсе того, как работает сервис.

3. После публичного запуска проводится ещё одно тестирование на рабочих серверах.

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

5. Так, шаг за шагом, компания получает продукт, который работает без сбоев.

Но при разработке государственных сервисов этого недостаточно.

Госпроекты — это ГОСТы, внутренние стандарты и соответствие целому ряду ФЗ. Когда мы сдаем контракт госзаказчику, сначала идут предварительные испытания — для этого собирается комиссия с нашей стороны и со стороны заказчика. И дальше мы вместе проходим по всей документации и смотрим, что как работает.

Например, у нас есть программа методика испытаний, где написано: «Для того чтобы авторизоваться в системе, пользователь должен ввести пару логин-пароль. После этого по нажатию кнопки „Вход“ должна произойти авторизация в системе». И во время сдачи каждого этапа работ исполнитель это всё показывает, а комиссия должна сказать, засчитано или не засчитано. И так по каждому пункту в исходной документации.

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

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

Notamedia как компания ответственно подходит к процессу тестирования любого продукта и уделяет этому этапу достаточно большое количество времени и ресурсов. Здесь всё просто — это наша репутация как разработчика. Также мы много уделяем времени развитию компетенций с точки зрения тестирования: не просто «смотрю, вижу ошибку и исправляю», а полноценная автоматизация тестирования и развитие компетенций тестировщиков. Каждый наш сервис или продукт мы тщательно тестируем, независимо от того, госзаказ это или коммерческая разработка.

Илья Юрасов
Notamedia Integrator

Требования со стороны ГОСТов и отраслевых стандартов

Отдельный момент разработки, про который забывают многие начинающие команды — требования ГОСТов и внутриведомственные рекомендации. Например, в них может быть прописано:

• начертание и размер шрифта для разных версий сайта

• форматы адресов и телефонных номеров

• порядок указания фамилий или должностей

• правила оформления документации, если мы делаем сервис документооборота

• и что угодно ещё, что регулируется соответствующими документами.

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

Сопроводительная и техническая документация

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

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

Используемые технологии и решения

При работе над государственными сервисами чаще всего предпочтение отдаётся отечественным решениям. Дело в том, что отечественное ПО, на котором можно разрабатывать государственные платформы, должно пройти все сертификации. В случае Notamedia, мы работаем только с сертифицированными решениями, а системы, которые разрабатываем, проходят сертификацию ФСТЭК. Благодаря этому мы можем быть уверены, что это ПО отвечает государственным требованиям по информационной безопасности. Зарубежное ПО таких сертификатов не имеет.

Чаще всего в качестве базового продукта мы выбираем Битрикс24 — у него огромное количество интеграций, модулей и возможностей, которые можно настроить почти под любые задачи. Во время работы мы существенно его кастомизируем и часто добавляем много самописных решений и коннекторов, а также создаем сложную архитектуру связей с другими ИС и БД в государственных ведомствах. При этом мы используем зарубежные фреймворки и технологии, которые обеспечат максимальную эффективность продукта, сервиса, решения и при этом соответствуют политике безопасности.

Стандарты безопасности и сертификации

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

Если мы не берем Битрикс как систему, нам нужно сделать с нуля свою систему управления сайтом. Это нормально в коммерческих заказах, но часто неприемлемо в государственных. Нельзя просто так запустить сайт, пока эта самописная система не сертифицирована. К примеру, в CMS по требованию ФСТЭК должен быть определён специальный пользователь — администратор безопасности, у которого прописаны отдельные права. Если этого пользователя нет или функционал не соответствует регламентному — всё, сертификация не пройдена. И таких нюансов очень много.

Вместо выводов

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