Готовим СМК IT-компаний по ГОСТ Р 53624-2009: требования к разработке ПО, поставке, эксплуатации, сопровождению, записям и аудиту.
Сертификация по ГОСТ Р 53624-2009 нужна организациям, которые разрабатывают, поставляют, эксплуатируют или сопровождают программное обеспечение и должны подтвердить управляемость качества в ИТ-процессах. Этот стандарт не про менеджмент знаний. Его область — информационные технологии, информационно-вычислительные системы, программное обеспечение и требования к системе менеджмента качества при создании ПО.
ГОСТ Р 53624-2009 применяют, когда заказчику важно видеть не только готовую программу, но и порядок её разработки: требования, проектирование, кодирование, тестирование, выпуск, сопровождение, управление изменениями, исправление дефектов и ответственность команды. Стандарт может использоваться при подготовке СМК к сертификации, повышении результативности процессов и поддержании работоспособности уже сертифицированной системы.
Сертификация по ГОСТ Р 53624-2009: что проверяют
Аудитор смотрит, есть ли у компании управляемый жизненный цикл программного обеспечения. Если требования заказчика меняются в переписке, дефекты теряются между разработчиком и тестировщиком, релизы выкатываются без протокола, а сопровождение живёт отдельно от разработки, СМК будет слабой. Нужны не только регламенты, но и записи по реальным проектам.
| Блок | Что готовят | Типичная проблема |
|---|---|---|
| Требования | ТЗ, backlog, согласования, изменения, критерии приёмки | Заказчик меняет требования устно, следов решения нет |
| Разработка | Планы, роли, архитектура, код-ревью, контроль версий | Процесс зависит от конкретных разработчиков |
| Тестирование | Тест-планы, протоколы, дефекты, повторная проверка | Ошибки исправляют, но причины не анализируют |
| Сопровождение | Релизы, обращения, исправления, эксплуатационная документация | Поддержка не связана с разработкой и управлением изменениями |
Кому подходит стандарт
ГОСТ Р 53624-2009 полезен разработчикам заказного ПО, интеграторам, поставщикам информационных систем, компаниям сопровождения, разработчикам встроенного ПО, SaaS-проектам, подрядчикам государственных и корпоративных заказчиков. Особенно если в договоре важны прослеживаемость требований, качество поставки, сопровождение, работа с дефектами и управляемость изменений.
Сертификат может потребоваться в тендере или при квалификации ИТ-поставщика. Но реальная ценность шире: меньше спорных требований, понятнее статус релиза, проще доказывать качество работ, легче передавать проект между командами и поддерживать продукт после внедрения.
Когда ГОСТ Р 53624-2009 не нужен
Если компания делает разовые небольшие сайты, не участвует в закупках с требованиями к СМК и не сопровождает сложные системы, отдельная сертификация может быть лишней. В таком случае достаточно нормального договора, технического задания, контроля версий, тестирования и понятного порядка передачи результата заказчику.
Стандарт не заменяет сертификацию средств защиты информации, регистрацию российского ПО, лицензии ФСТЭК или ФСБ, требования по персональным данным, аттестацию информационных систем и испытания по специальным методикам. Он относится к системе менеджмента качества процессов разработки и сопровождения ПО.
Сроки и стоимость
В карточке услуги указана стоимость от 8000 рублей и срок 25-30 рабочих дней. Если у компании уже есть ISO 9001, система управления задачами, репозиторий, тестовая документация, релизный порядок и поддержка, подготовка идёт быстрее. Если процессы живут в чатах, а документы собираются только перед сдачей проекта, потребуется больше времени на восстановление прослеживаемости.
| Состояние ИТ-процессов | Что делаем | Ориентир |
|---|---|---|
| Есть ISO 9001 и SDLC | Дорабатываем требования ГОСТ Р 53624-2009, записи, аудит | 20-25 рабочих дней |
| Процессы есть, документов мало | Описываем жизненный цикл, роли, тестирование, релизы | 25-30 рабочих дней |
| Проекты ведутся хаотично | Сначала выстраиваем минимальный управляемый процесс | после диагностики |
Какие документы потребуются
Обычно нужны область применения СМК, политика и цели качества, порядок управления требованиями, проектированием, разработкой, тестированием, релизами, сопровождением, конфигурациями, изменениями, дефектами, документацией и поставщиками. Отдельно готовят формы записей: протоколы согласования требований, планы проекта, тест-кейсы, отчёты о тестировании, реестр дефектов, акты приёмки, журнал изменений и результаты внутренних аудитов.
Для ИТ-компаний важно не дублировать инструменты бумажными формами. Если задачи ведутся в Jira, YouTrack, GitLab, Redmine или другой системе, можно использовать выгрузки и правила работы с ними. Главное — показать, что данные полные, управляемые и связаны с процессами качества.
Частые ошибки
Первая ошибка — описывать разработку слишком общо: “получаем требования, пишем код, тестируем”. На аудите нужны конкретные роли, входы, выходы, критерии готовности и записи. Вторая — разрывать разработку и сопровождение. Ошибка клиента после внедрения должна попадать в управление дефектами и изменениями, а не растворяться в переписке поддержки.
Третья ошибка — считать, что наличие репозитория и трекера задач уже является СМК. Инструменты помогают, но сами по себе не задают ответственность, критерии качества, анализ причин дефектов и управленческий контроль.
Кейс из практики
Разработчик корпоративной системы участвовал в закупке, где заказчик запросил подтверждение СМК для разработки ПО. У компании были сильные программисты и рабочий GitLab, но документы по качеству отставали от практики: требования фиксировались в разных местах, тестирование зависело от конкретного аналитика, релизные заметки не всегда совпадали с фактическим составом поставки.
Мы начали с одного завершённого проекта и восстановили цепочку: требование, задача, изменение кода, тестирование, дефект, исправление, релиз, приёмка. После этого оформили порядок управления требованиями, тестирования и релизов так, чтобы он совпадал с реальной работой команды. На аудите сотрудники объясняли процесс своими словами, а не читали чужой регламент.
Как помогает «Реестр Гарант»
Мы сначала смотрим реальные ИТ-процессы: как принимаются требования, где ведутся задачи, как устроены репозитории, тестирование, релизы, поддержка и управление дефектами. Затем готовим документы по ГОСТ Р 53624-2009 без лишней бумажной нагрузки и помогаем собрать доказательства по действующим проектам.
Для первичной оценки можно связаться с «Реестр Гарант» по телефону +7 920-898-17-18, написать в WhatsApp или Telegram, либо отправить вводные на reestrgarant@mail.ru. В сообщении лучше указать тип ПО, число проектов, используемые системы управления задачами и кодом, наличие ISO 9001 и требования заказчика.
Частые вопросы
ГОСТ Р 53624-2009 относится к менеджменту знаний?
Нет. Стандарт относится к информационным технологиям, информационно-вычислительным системам, программному обеспечению и требованиям к системе менеджмента качества при создании ПО.
Это обязательная сертификация?
Нет, сертификация добровольная. Она становится необходимой через тендер, договор, внутренний стандарт заказчика или квалификацию поставщика программного обеспечения.
Нужен ли ISO 9001 перед ГОСТ Р 53624-2009?
Наличие ISO 9001 помогает, потому что ГОСТ Р 53624-2009 связан с системой менеджмента качества. Но даже без готового ISO 9001 можно строить СМК под процессы разработки ПО.
Можно использовать данные из GitLab или Jira?
Да. Если в этих системах действительно фиксируются требования, задачи, дефекты, релизы и проверки, их данные можно использовать как доказательства работы СМК.
Требования и условия
- описать область применения СМК для разработки, поставки или сопровождения ПО;
- наладить управление требованиями, проектированием, разработкой, тестированием и релизами;
- связать задачи, код, дефекты, изменения и приёмку в прослеживаемую систему;
- собрать записи по проектам, тестированию, дефектам, релизам, аудитам и улучшениям.
Необходимые документы
- карточка компании и описание сертифицируемых ИТ-процессов;
- ТЗ, backlog, планы проектов, регламенты разработки, тестирования и релизов;
- выгрузки из трекеров задач, репозиториев, реестров дефектов и систем поддержки;
- протоколы тестирования, акты приёмки, внутренние аудиты и корректирующие действия.