Показаны сообщения с ярлыком программное обеспечение. Показать все сообщения
Показаны сообщения с ярлыком программное обеспечение. Показать все сообщения

пятница, 11 сентября 2026 г.

Жизненный цикл документа - не спецификация программного обеспечения (и путаница в этом вопросе обойдётся Вам в миллионы), часть 2

(Окончание, начало см. https://rusrim.blogspot.com/2026/09/1_01275264572.html )

Как решается эта проблема?

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

Мой комментарий: По этой постановке вопроса сразу видно государственного архивиста, который предполагает, что в организации есть всё – и деловые системы, и специализированная система управления документами, а электронный архив (причём не абы какой, а соответствующий весьма суровым требованиям модели OAIS). Но как быть какому-нибудь ОАО «Тушканчик», у которого, возможно, кроме облачной электронной почты и мессенджера ничего и нет?   

Чтобы ответить на этот вопрос, я использую то, что я называю «матрицей владения документами» (Matriz de Titularidad Documental, MTD): каждый процесс жизненного цикла имеет, согласно архитектуре, своего владельца, и [нежелательная, с точки зрения автора – Н.Х.] зависимость возникает именно в тот момент, когда какая-то система присваивает себе право владения, которое ей не принадлежит.


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

Преимущества «независимой» архитектуры

В числе преимуществ, обеспечиваемой «независимой» архитектурой, можно назвать следующие:

  • Реальная интероперабельность между порождающими документы деловыми системами, системой управления документами и хранилищем документов;
     
  • Проекты конверсии /миграции ввиду устаревания технологий перестают быть крайне рискованными; 
  • Адаптация к изменениям в законодательстве без переписывания всей системы управления документами;

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

Давайте поразмышляем

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

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

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

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

Джон Гонсалес (Jhon Alexander González Flórez)

Источник: LinkedIn
https://es.linkedin.com/comm/pulse/el-ciclo-de-vida-documental-es-una-especificaci%C3%B3n-y-te-gonzalez-f--qmrge 

четверг, 10 сентября 2026 г.

Жизненный цикл документа - не спецификация программного обеспечения (и путаница в этом вопросе обойдётся Вам в миллионы), часть 1

Данный пост колумбийского специалиста Джона Александра Гонсалеса Флореса (Jhon Alexander González Flórez, или Jhon A. Gonzalez F. – на фото), сотрудника управления проектов электронного документооборота в компании Grupo IB Consulting SAS, был опубликован 27 июля 2026 года в социальной сети LinkedIn.

В течение многих лет сотни тендерных документов и матриц с требованиями, - как в Колумбии, так и других странах региона, - основывались на одной и той же предпосылке: если архивный стандарт описывает планирование, создание, управление и обработку, упорядочение, распространение, окончательное уничтожение / передачу на архивное хранение и обеспечение долговременной сохранности, то и система управления электронными документами (Sistema de Gestión de Documentos Electrónicos de Archivo, SGDEA) должна выполнять каждый из этих процессов.

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

В Колумбии также изначально исходили из этой же предпосылки.

Что же происходит на самом деле?

Жизненный цикл документа - это модель стратегического управления доказательствами, а не диаграмма функциональных возможностей, которые должно поддерживать программное обеспечение. Когда организация буквально переносит эту модель в архитектуру своей системы управления документами, то система перестаёт выполнять архивную функцию и начинает абсорбировать бизнес-логику: правила выполнения процессов и процедур, статусы, функциональные проверки и полные процессы из сферы управления деловыми процессами (Business Process Management, BPM). Документ перестаёт быть независимым институциональным активом и становится зависимым от программного обеспечения, которое, по определению, однажды будет заменено.

Мой комментарий: Читатели моего блога, наверное, заметили, что в настоящее время, наоборот, многие специалисты выдвигают аргументы в пользу большей интеграции документных систем с деловыми процессами – вместо выполнения ими роли исключительно хранилищ «отработанных» в ходе деловой деятельности документов. Те же наши российские СЭД (даже самые что ни на есть «традиционные») всегда поддерживали как минимум процессы управления организацией, контроль исполнения, переписку с внешними сторонами и т.п. – т.е. их роль никогда не сводилась исключительно к роли защищённого хранилища. Причина проста – никто не станет платить деньги за одно лишь хранение отработанных материалов – и никакие ссылки на «идейную чистоту» тут не помогут …

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


Это именно то, что я в своей книге о зависимых и независимых архитектурах определяю как «зависимую (сопряжённую) архитектуру» (arquitectura acoplada) – это экосистема, в раках которой специалист по управлению документами не управляет делом, а является его владельцем (или, как говорится в другом месте, «это модель, в которой технологические решения обусловливают работу архивного инструмента» - Н.Х.).

Мой комментарий: В апреле 2026 года была опубликована новая книга Джона Александра Гонсалеса Флореса (Jhon Alexander González Flórez) «Зависимые и независимые архитектуры систем управления документами: Как проектировать системы, способные пережить институциональные изменения» (Arquitecturas Acopladas y Desacopladas en Gestión Documental: Cómo diseñar sistemas que sobrevivan al cambio institucional), на испанском языке, см. http://amazon.com/dp/B0GY4MP848

Почему данная проблема становится очевидной только через двадцать лет?

Данная проблема становится очевидной обычно только лет через двадцать, потому что большинство организаций оценивают успешность своей системы управления документами по её способности поддерживать деловую деятельность сегодня и сейчас (что, с моей точки зрения, логично – Н.Х.). Почти никто не оценивает её по её способности пережить замену самой системы - но именно это, а не нечто иное, должно быть истинным показателем зрелости.

Симптомы проблемы всегда появляется в одно и то же время – когда происходит миграция технологий. Именно в этот момент поднимаются вопросы, которые никогда не задавались на этапе проектирования. Где именно находится сам документ? Какая часть документов относится к деловой деятельности, а какая - к архиву? Возможно ли реконструировать контекст доказательств без переустановки исходного программного обеспечения?

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

Последствия распространяются и на деятельность по обеспечению долговременной сохранности электронных материалов (электронной сохранности). Эталонная модель OAIS открытой архивной информационной системы четко говорит: необходимо обеспечить сохранность не просто двоичного файла, но и информации, необходимую для понимания этого объекта целевым сообществом спустя десятилетия. Когда смысл документа зависит от проприетарных систем управления деловыми процессами (BPM), обеспечение сохранности перестаёт быть технически осуществимым, независимо от того, сколько PDF/A-файлов было создано.

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

(Окончание следует, см. https://rusrim.blogspot.com/2026/09/2_076805379.html )

Джон Гонсалес (Jhon Alexander González Flórez)

Источник: LinkedIn
https://es.linkedin.com/comm/pulse/el-ciclo-de-vida-documental-es-una-especificaci%C3%B3n-y-te-gonzalez-f--qmrge 

суббота, 4 июля 2026 г.

Росстандарт: Опубликован стандарт ГОСТ Р 72663-2026 «Требования и оценка качества систем и программного обеспечения (SQuaRE). Измерение качества данных»

На сайте Федерального агентства по техническому регулированию и метрологии ( http://www.gost.ru/ ) в июньском 2026 года разделе ( https://protect.gost.ru/default.aspx?control=6&month=6&year=2026 ) был выложен новый национальный стандарт ГОСТ Р 72663-2026 (ИСО/МЭК 25024:2015) «Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Измерение качества данных» объёмом 54 страницы, вступающий в силу 01.08.2026 г. см. https://protect.gost.ru/gost/details/d1c2283d-6708-43be-94d2-cc7b2e3f3e2c .

Стандарт подготовлен Ассоциацией по сертификации «Русский Регистр» на основе собственного перевода на русский язык международного стандарта ISO/IEC 25024:2015 «Системная и программная инженерия - Требования и оценка качества систем и программного обеспечения (SQuaRE) - Измерение качества данных» (Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Measurement of data quality, см. https://www.iso.org/standard/35749.html и https://www.iso.org/obp/ui/en/#!iso:std:35749:en ). Стандарт внесён Техническим комитетом по стандартизации ТК 164 «Искусственный интеллект»

Во вводной части стандарта отмечается:

«Настоящий стандарт устанавливает показатели качества данных для количественной оценки качества данных в терминах характеристик, определенных в [1].

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

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

Настоящий стандарт предназначен для использования лицами, которым необходимо разрабатывать и/или использовать показатели качества данных при выполнении своих обязанностей:

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

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

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

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

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

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

  • менеджером по качеству (физическое лицо или организация, проводящие систематическую проверку данных);

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

Настоящий стандарт учитывает широкий спектр данных целевых объектов.

Настоящий стандарт может применяться во многих типах информационных систем, таких как:

  • традиционная информационная система;

  • хранилище данных;

  • распределенная информационная система;

  • кооперативная информационная система;

  • интернет-пространство.

Область применения не включает:

  • представление знаний;

  • методы сбора сведений из массивов данных;

  • статистическая значимость для произвольной выборки.»

Содержание стандарта следующее:

Предисловие
Введение
1. Область применения
2. Нормативные ссылки
3. Термины и определения
4. Сокращения
5. Общие положения
6. Использование показателей качества данных
7. Формат для документирования показателей качества данных
8. Показатели качества данных
Приложение А (справочное): Элементы измерения качества, используемые для определения показателей качества
Приложение В (справочное): Элементы измерения качества, целевые объекты и показатели качества
Приложение С (справочное): Ссылки на элементы измерения качества
Приложение D (справочное): Показатели качества
Приложение Е (справочное): Идентификаторы показателей качества для характеристик и целевых объектов
Приложение ДА (справочное): Сведения о соответствии ссылочных национальных стандартов международным стандартам, использованным в качестве ссылочных в примененном международном стандарте
Приложение ДБ (справочное): Сопоставление структуры настоящего стандарта со структурой примененного в нем международного стандарта
Библиография

Источник: сайт Росстандарта
https://protect.gost.ru/gost/details/d1c2283d-6708-43be-94d2-cc7b2e3f3e2c

воскресенье, 14 июня 2026 г.

ИСО и МЭК: Опубликована новая редакция стандарта ISO/IEC/IEEE 12207:2026 «Процессы жизненного цикла программного обеспечения»

В апреле 2026 года сайт Международной организации по стандартизации (ИСО) сообщил о публикации новой редакция стандарта ISO/IEC/IEEE 12207:2026 «Системная и программная инженерия - Процессы жизненного цикла программного обеспечения» (Systems and software engineering — Software life cycle processes) объёмом 156 страниц, см. https://www.iso.org/standard/90219.html и https://www.iso.org/obp/ui/en/#!iso:std:90219:en .

Стандарт подготовлен подкомитетом SC7 «Системное проектирование и разработка программного обеспечения» Объединённого технического комитета ИСО/МЭК JTC1. Он заменил предыдущую редакцию ISO/IEC/IEEE 12207:2017.

В России стандарт был адаптирован (в редакции 2008 года) как ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств», см. https://protect.gost.ru/gost/details/350d1d97-8905-4368-8a8c-7ce7c041bb09 

Во вводной части стандарта отмечается:

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

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

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

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

Документ применим как к полной автономной программной системе, так и к программным системам, которые встраиваются и интегрируются в более крупные, сложные и полные системы систем (systems of systems, SoS). Процессы, действия и задачи, описанные в данном документе, также могут применяться при приобретении системы, содержащей программное обеспечение.

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

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

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

Данный документ не детализирует элементы информации в плане названия, формата, явного содержания и носителя информации. Стандарт ISO/IEC/IEEE 15289:2019 «Разработка систем и программ - Содержание информационных элементов, отражающих жизненный цикл систем и программного обеспечения (документации)» (Systems and software engineering - Content of life-cycle information items (documentation), см. https://www.iso.org/standard/74909.html и https://www.iso.org/obp/ui/#!iso:std:74909:en , а также мой пост о редакции 2017 года: https://rusrim.blogspot.com/2017/11/isoiecieee-152892017.html – Н.Х.). определяет содержание информационных элементов (документации) для процесса жизненного цикла.»

Содержание стандарта следующее:

Предисловие
Введение
1. Область применения
2. Нормативные ссылки
3. Термины, определения и сокращения
4. Соответствие
5. Ключевые понятия и их применение
6. Процессы жизненного цикла программного обеспечения
Приложение A: Процесс адаптации
Приложение B: Примеры элементов информации о процессе
Приложение C: Эталонная модель процесса для целей оценки
Приложение D: Системная и программная инженерия на основе моделей (Model-based systems and software engineering, MBSSE)
Приложение E: Обеспечение уверенности с примерами
Библиография

Источник: сайт ИСО
https://www.iso.org/standard/90219.html 
https://www.iso.org/obp/ui/en/#!iso:std:90219:en 



пятница, 5 июня 2026 г.

Локальный ИИ-помощник PlumA для архивного описания документов с использованием ИИ

Данная заметка испанского специалиста, исполнительного директора Испанского общества научной документации и информации (Sociedad Española de Documentación e Información Científica, SEDIC) Виктора Вильяпалоса Пардиньяса (Víctor Villapalos Pardiñas – на фото) была опубликована 14 мая 2026 года в социальной сети LinkedIn,

Новые локальные ИИ-помощники для архивного описания: Локальный ИИ-помощник PlumA для архивного описания документов с использованием ИИ

Мой комментарий: Эта новость интересна тем, что она показывает – начали разрабатываться специализированные ИИ-инструменты для архивистов.

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

Решение PlumA не заменяет архивиста, не автоматизирует процесс принятия профессиональных суждений. Программа считывает оцифрованный документ и предлагает варианты значений для полей, опираясь на стандарты архивного описания ISAD(G), DACS, ISAAR(CPF), ISDF, ISDIAH, а также на упрощенную модель нового стандарта архивного описания «Документы в контекстах» (RiC). При этом каждое предложение программы подкрепляется обосновывающими его буквальными цитатами из исходного документа.

Специалист-человек сохраняет контроль над процессом: он просматривает, корректирует и принимает окончательное решение о том, какие данные следует передать в ArchivesSpace, AtoM или любую иную систему архивного описания.

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

Именно поэтому решение PlumA работает полностью локально, используя контейнерную платформу Docker и локальный движок ИИ на базе Ollama. После установки программы, документы не покидают компьютер архивиста. В системе отсутствуют телеметрия, внешняя обработка данных и подключения к удаленным серверам.

В первую бета-версию включены следующие функциональные возможности:

  • Поддержка стандартов архивного описания ISAD(G), DACS, ISAAR(CPF), ISDF, ISDIAH и упрощенного варианта RiC;

  • Режимы извлечения данных: извлечение только важнейших данных, полное извлечение данных и настраиваемый (пользовательский) режим;

  • Автоматическое определение типа документа;

  • Поддержка текстовых и сканированных PDF-файлов, документов формата DOCX, а также файлов изображений;

  • Экспорт данных в форматы JSON, CSV, EAD3 и EAC-CPF;

  • Предложения и заполнении полей, подкрепляемые цитатами из источника, с использованием индикаторов уверенности;

  • Двуязычный интерфейс (испанский и английский языки).

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

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

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

Ссылка на репозиторий: https://github.com/Token-Vean/Pluma 

Релиз v0.5.0-beta доступен по адресу: https://github.com/Token-Vean/Pluma/releases/tag/v0.5.0-beta ; см. также https://github.com/Token-Vean/Pluma/releases 

Решение PlumA распространяется под лицензией GNU AGPL-3.0.

Виктор Вильяпалос Пардиньяс (Víctor Villapalos Pardiñas)

Источник: сайт LinkedIn
https://www.linkedin.com/feed/update/urn:li:activity:7458244092368625664 
https://www.linkedin.com/feed/update/urn:li:groupPost:2620672-7458243834502672385  

вторник, 26 мая 2026 г.

ИСО и МЭК: Продолжается работа над проектом технических спецификаций ISO/IEC CD TS 20499 «Концептуальная основа для обеспечения совместимости стандартов системной и программной инженерии»

В феврале 2026 года сайт Международной организации по стандартизации (ИСО) сообщил о завершении голосования по проекту комитета новых, довольно любопытных технических спецификаций ISO/IEC CD TS 20499 «Системная и программная инженерия - Концептуальная основа для обеспечения совместимости стандартов системной и программной инженерии» (Systems and software engineering - Conceptual framework for systems and software engineering standards compatibility), см. https://www.iso.org/standard/86296.html 

Над документом работает подкомитет SC7 «Системное проектирование и разработка программного обеспечения» Объединённого технического комитета ИСО/МЭК JTC1.


В аннотации на документ, выложенной на сайте ИСО, отмечается:

«Данные технические спецификации обеспечивают концептуальную основу для достижения совместимости между существующими и будущими стандартами технического подкомитета ИСО/МЭК JTC1/SC7, а также с некоторыми внешними стандартами в области инженерии программного обеспечения и системной инженерии (такими, как стандарты OMG или The Open Group) с использованием семейства взаимосвязанных онтологий.»

Мой комментарий: Здесь упомянута «Группа управления объектами» (Object Management Group, OMG, https://www.omg.org/ ) – это международный консорциум по технологическим стандартам. The Open Group - это глобальный консорциум, созданный для разработки и продвижения нейтральных открытых технологических стандартов для вычислительной инфраструктуры. Он наиболее известен как сертифицирующий орган для торговой марки UNIX и как разработчик стандарта корпоративной ИТ-архитектуры TOGAF (The Open Group Architecture Framework - Концепция архитектуры «Открытой группы»).

Более подробно о проекте рассказывает сайт Британского института стандартов (BSI):

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

Данный проект необходим по следующим причинам:

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

  • Необходимо уважать целостность существующих стандартов, одновременно давая возможность разработчикам и пользователям стандартов интерпретировать их в более широком контексте;

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

  • Одновременное представление стандартов как в форме обычных документов, ориентированных на человека, так и в формализованном виде будет способствовать в конечном итоге разработке машиночитаемых и «умных» стандартов.

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

Целевой аудиторией данных технических спецификаций является сообщество экспертов подкомитета SC7 и, в первую очередь, разработчики стандартов подкомитета SC7. Разработка стандартов в основном представляет собой деятельность экспертов-людей; а для изучения, оценки, внедрения и понимания стандартов необходимо, чтобы результаты усилий по стандартизации были ясными и понятными для сообщества экспертов подкомитета SC7. Другие технические подкомитеты, помимо SC7, а также внешние организации, такие как OMG или The Open Group, также могут быть заинтересованы в изучении предлагаемого подхода.»

Источник: сайт ИСО / сайт BSI
https://www.iso.org/standard/86296.html 
https://standardsdevelopment.bsigroup.com/projects/9024-09989 


воскресенье, 19 апреля 2026 г.

ИСО и МЭК: Начато голосование по финальной версии проекта стандарта ISO/IEC FDIS 9837 «Системная и программная инженерия – Понятия и концепции жизнестойкости систем»

В марте 2026 года сайт Международной организации по стандартизации (ИСО) сообщил о начале голосования по финальной версии проекта стандарта ISO/IEC FDIS 9837 «Системная и программная инженерия – Понятия и концепции жизнестойкости систем» (Systems and software engineering - Systems resilience concepts) объёмом 25 страниц, https://www.iso.org/standard/83604.html и https://www.iso.org/obp/ui/en/#iso:std:iso-iec:9837:dis:ed-1:v1:en . Голосование продлится до 19 мая 2026 года, и в случае его успешного завершения стандарт будет опубликован.

Над документом работает подкомитет SC7 «Системное проектирование и разработка программного обеспечения» Объединённого технического комитета ИСО/МЭК JTC1.

Во вводной части стандарта отмечается:

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

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

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

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

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

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

Примечание: Термин «система» используется в данном документе в соответствии с определением и областью применения этого термина в стандарте ISO/IEC/IEEE 15288:2023 «Системная и программная инженерия - Процессы жизненного цикла системы» (Systems and software engineering - System life cycle processes, см. https://www.iso.org/standard/81702.html ).»

Стандарт содержит большой терминологический раздел, включающий около 70 терминов.

Содержание стандарта следующее:

Предисловие
Введение
1. Область применения
2. Нормативные ссылки
3. Термины и определения
3.1. Основные понятия жизнестойкости систем
3.2. Основные цели
3.3. Способы достижения целей
3.4. Методы обеспечения жизнестойкости
4. Ключевые понятия жизнестойкости и их взаимосвязь
5. Концепция жизнестойкости
Библиография

Источники: сайт ИСО
https://www.iso.org/standard/83604.html 


ИСО и МЭК: Начато публичное обсуждение проекта стандарта ISO/IEC DIS 25023 «Требования и оценка качества систем и программной продукции (SQuaRE) – Измерение качества продуктов»

16 марта 2026 года сайт Международной организации по стандартизации (ИСО) и сайт Британского института стандартов (BSI сообщили о начале публичного обсуждения проекта новой редакции стандарта ISO/IEC DIS 25023 «Системная и программная инженерия - Требования и оценка качества систем и программной продукции (SQuaRE) – Измерение качества продуктов» (Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Measurement of product quality) объёмом 66 страниц основного текста, см. https://www.iso.org/standard/89069.html и https://www.iso.org/obp/ui/en/#!iso:std:89069:en . Он заменит действующую редакцию ISO/IEC 25023:2016.

Над документом работает подкомитет SC7 «Системное проектирование и разработка программного обеспечения» Объединённого технического комитета ИСО/МЭК JTC1.

России действующая редакция стандарта была адаптирована как ГОСТ Р ИСО/МЭК 25023-2021 (ISO/IEC 25023:2016) «Системная и программная инженерия. Требования и оценка качества систем и программной продукции (SQuaRE). Измерения качества системы и программной продукции», см. https://protect.gost.ru/document.aspx?control=7&id=242008 .

Есть возможность до 9 мая 2026 года индивидуально принять участие в публичном обсуждении данного стандарта на сайте Британского института стандартов (BSI) по адресу https://standardsdevelopment.bsigroup.com/projects/2024-02311 (при условии регистрации на сайте). 


Страница публичного обсуждения проекта ISO/IEC DIS 25023 на сайте BSI 

Во вводной части стандарта отмечается:

«Настоящий документ определяет показатели для количественной оценки качества продуктов с точки зрения характеристик и подхарактеристик, определенных в стандарте ИСО/МЭК 25010, и предназначен для использования совместно с ИСО/МЭК 25010. Его можно использовать совместно со стандартами серии ИСО/МЭК 2503x и ИСО/МЭК 2504x, а также для удовлетворения в более широком плане потребностей пользователей относительно качества ИКТ-продуктов и программных продуктов.

Настоящий документ содержит базовый набор показателей качества для каждой характеристики и подхарактеристики. Он включает (в виде справочных приложений) соображения, касающиеся использования показателей качества (приложение А), элементы измерения качества (QME), используемые для определения показателей качества продуктов и систем (приложение В), и подробное объяснение типов измерений (приложение С).

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

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

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

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

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

  • Поставки: договор с заказчиком на поставку системы, программного продукта или услуги в соответствии с условиями договора, например, при валидации качества при прохождении квалификационных тестов;

  • Закупки, включая выбор продукта и приёмочное тестирование в ходе приобретении или закупки у поставщика системы, программного продукта или услуги;

  • Техническое обслуживание: совершенствование программного продукта или системы на основе измерений качества.»

Содержание стандарта следующее:

Предисловие
Введение
1. Область применения
2. Нормативные ссылки
3. Термины и определения
4. Сокращения
5. Использование показателей качества продукции
6. Формат, используемый для документирования показателей качества
7. Показатели качества продуктов
Приложение A. Соображения по использованию показателей качества
Приложение B. Элементы измерения качества (quality measure element, QME) используемые для определения показателей качества программного продукта или системы
Приложение C. Подробное объяснение типов измерений
Приложение D. Применение показателей качества на различных этапах
Библиография

Источники: сайт ИСО / сайт BSI
https://www.iso.org/standard/89069.html 
https://www.iso.org/obp/ui/en/#!iso:std:89069:en 
https://standardsdevelopment.bsigroup.com/projects/2024-02311

суббота, 28 марта 2026 г.

Росстандарт: Опубликован стандарт ГОСТ Р 72497-2025 «Требования и оценка качества систем и программных средств. Обзор и применение моделей качества»

На сайте Федерального агентства по техническому регулированию и метрологии ( http://www.gost.ru/ ) в февральском 2026 года разделе ( https://protect.gost.ru/default.aspx?control=6&month=2&year=2026 ) был выложен новый национальный стандарт ГОСТ Р 72497-2025 «Системная и программная инженерия. Требования и оценка качества систем и программных средств. Обзор и применение моделей качества» объёмом 28 страниц, вступивший в силу 01.02.2026 года, см. https://protect.gost.ru/document1.aspx?control=31&baseC=6&id=270819

Стандарт разработан ООО «Институт стандартизации информационных технологий», Комиссией Российской академии наук по техногенной безопасности и Научным советом Российской академии наук «Информационная безопасность». Стандарт вносит Технический комитет по стандартизации ТК22 «Информационные технологии».

О разработке этого документа я уже рассказывала здесь: https://rusrim.blogspot.com/2025/06/blog-post_17.html 

Документ подготовлен на основе международного стандарта ISO/IEC 25002:2024 «Системная и программная инженерия - Требования и оценка качества систем и программного обеспечения (SQuaRE) - Обзор и применение моделей качества» (Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Quality model overview and usage), см. https://www.iso.org/standard/78175.html  и https://www.iso.org/obp/ui/en/#!iso:std:78175:en  .

Во вводной части стандарта отмечается:

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

Цель разработки настоящего стандарта состоит в предоставлении нормативной поддержки системного анализа показателей качества систем и ПС, оценки рисков и обоснования мер обеспечения качества на приемлемом уровне. Модели качества могут быть использованы как ориентировочный объективный эталон в процессах определения требований, оценки, валидации (аттестации) и верификации систем и ПС (см. ГОСТ Р 57193, ГОСТ Р ИСО/МЭК 12207), а также как формализованное руководство для разработки показателей оценки и критериев в интересах оптимизации различных систем в их жизненном цикле (ЖЦ).

… Настоящий стандарт распространяется на модели качества систем и ПС различного функционального назначения.

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

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

В приложении А приведены примеры учета специфики в применении моделей качества для функционально ориентированных систем различных типов.»

Содержание стандарта следующее:

Предисловие
Введение
1. Область применения
2. Нормативные ссылки
3. Термины и определения
4. Сокращения
5. Обзор моделей качества
6. Связь характеристик, показателей и контекста использования
7. Применение моделей качества
7.1. Общие положения
7.2. Применение для определения требований к качеству
7.3. Применение для обеспечения качества при проектировании
7.4. Применение для оценки качества
7.5. Применение для измерения показателей качества
7.6. Применение для управления качеством
Приложение А (справочное): Примеры учета специфики в применении моделей качества для систем
Библиография

Источник: сайт Росстандарта
https://protect.gost.ru/document1.aspx?control=31&baseC=6&id=270819

ИСО и МЭК: Начато публичное обсуждение проекта стандарта ISO/IEC DIS 25000-2 «Требования и оценка качества систем и программного обеспечения (SQuaRE) – Часть 2: Словарь»

Как сообщил сайт Международной организации по стандартизации (ИСО), с начала февраля по середину апреля 2026 года проводится публичное обсуждение проекта нового стандарта ISO/IEC DIS 25000-2 «Системная и программная инженерия - Требования и оценка качества систем и программного обеспечения (SQuaRE) – Часть 2: Словарь» (Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) - Part 2: Vocabulary) объёмом 15 страниц основного текста, см. https://www.iso.org/standard/91474.html и https://www.iso.org/obp/ui/en/#!iso:std:91474:en .

Стандарт подготовлен подкомитетом SC7 «Системное проектирование и разработка программного обеспечения» Объединённого технического комитета ИСО/МЭК JTC1.

Есть возможность до 13 апреля 2026 года индивидуально принять участие в публичном обсуждении данного стандарта на сайте Британского института стандартов (BSI) по адресу https://standardsdevelopment.bsigroup.com/projects/2025-02381 (при условии регистрации на сайте). 


Страница публичного обсуждения проекта ISO/IEC DIS 25000-2 на сайте BSI

Во вводной части стандарта отмечается:

«В настоящем документе представлены термины и определения, составляющие концептуальную основу, относящуюся к качеству, как оно рассматривается в семействе стандартов «Требования и оценка качества систем и программного обеспечения» (Systems and Software Quality Requirements and Evaluation, SQuaRE). Основное внимание в документе уделяется фундаментальным понятиям и терминологии, которые являются общими для всего семейства стандартов SQuaRE, с целью обеспечить согласованность и способствовать их пониманию.

Термины и определения, специфические для отдельных моделей качества - таких как качество продукта, качество данных, качество ИТ-услуг и качество в процессе использования (quality-in-use) — в данном документе не рассматриваются.

Аналогичным образом не рассматриваются термины, относящиеся к другим типам качества, таким как качество процесса или качество, связанное с искусственным интеллектом.»

Содержание стандарта следующее:

Предисловие
Введение
1. Область применения
2. Нормативные ссылки
3. Термины и определения
3.1. Термины, относящиеся к качеству
3.2. Термины, относящиеся к конструкциям модели качества
3.3. Термины, относящиеся к сущностям
3.4. Термины, относящиеся к ролям
3.5. Термины, относящиеся к измерению качества
3.6. Термины, относящиеся к требованиям к качеству
3.7. Термины, относящиеся к инженерии качества
3.8. Термины, относящиеся к оценке качества
4. Сокращения
Приложение A: Категории терминов и структура подразделов в разделе «Термины и определения»
Приложение B: Принципы отбора терминов из существующих стандартов серии SQuaRE
Приложение C: Руководство по пониманию терминов и определений в стандартах серии SQuaRE
Библиография

Источник: сайт ИСО / сайт BSI
https://www.iso.org/standard/91474.html 
https://www.iso.org/obp/ui/en/#!iso:std:91474:en 


среда, 14 января 2026 г.

CША: Национальный институт стандартов и технологий начал публичное обсуждений новой версии 1.2 «Концепции безопасной разработки программного обеспечения» (SSDF)

14 декабря 2025 американский Национальный институт стандартов и технологий (NIST) в своей новостной рассылке и на веб-сайте (см. https://csrc.nist.gov/pubs/sp/800/218/r1/ipd ) объявил о начале публичного обсуждения первоначального проекта новой версии публикации NIST SP 800-218 Rev.1 «Концепция безопасной разработки программного обеспечения (SSDF), версия 1.2: Рекомендации по смягчению рисков, связанных с уязвимостями программного обеспечения» (Secure Software Development Framework (SSDF) Version 1.2: Recommendations for Mitigating the Risk of Software Vulnerabilities) объёмом 57 страниц, см. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218r1.ipd.pdf .

Публичное обсуждение продлится до 30 января 2026 года; замечания предлагается направлять по адресу ssdf@nist.gov . Документ заменит действующую версию 1.1 (публикация NIST SP 800-218, февраль 2022 года, см. https://csrc.nist.gov/pubs/sp/800/218/final ).

В извещении о начале публичного обсуждения отмечается следующее:

«Национальный институт стандартов и технологий (NIST) опубликовал первоначальный проект для публичного обсуждения специальной публикации NIST SP 800-218 Rev.1 «Концепция безопасной разработки программного обеспечения (SSDF), версия 1.2: Рекомендации по смягчению рисков, связанных с уязвимостями программного обеспечения», - в соответствии с исполнительным приказом (executive order) Президента США № 14306 от 6 июня 2025 года «Об усилении отдельных мер по укреплению кибербезопасности страны и о внесении поправок в исполнительные приказы Президента США №13694 и № 14144» (Sustaining Select Efforts To Strengthen the Nation's Cybersecurity and Amending Executive Order 13694 and Executive Order 14144, см. https://www.federalregister.gov/documents/2025/06/11/2025-10804/sustaining-select-efforts-to-strengthen-the-nations-cybersecurity-and-amending-executive-order-13694 ).

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

Лишь немногие модели жизненного цикла разработки программного обеспечения (software development life cycle, SDLC) явным образом детально рассматривают вопросы безопасности программного обеспечения, поэтому обычно приходится добавлять методы безопасной разработки программного обеспечения в каждую модель SDLC-модель. Публикация NIST SP 800-218 рекомендует использовать «Концепцию безопасной разработки программного обеспечения» (Secure Software Development Framework, SSDF), представляющую собой базовый набор высокоуровневых методов (практик) безопасной разработки программного обеспечения, которые могут быть интегрированы в каждую реализацию жизненного цикла разработки программного обеспечения (SDLC).

Следование таким методам и практикам должно помочь производителям программного обеспечения сократить количество уязвимостей в выпущенном ими ПО, смягчить потенциальные последствия эксплуатации [враждебными сторонами – Н.Х.] необнаруженных или неустраненных уязвимостей, и устранить первопричины уязвимостей, чтобы предотвратить их повторное возникновение в будущем. Поскольку данная Концепция включает общую терминологию в области безопасной разработки программного обеспечения, то закупающие программное обеспечение стороны также могут использовать её как для укрепления информационного взаимодействия с поставщиками в ходе процессов проведения закупок, так и в рамках иной управленческой деятельности.»

Содержание документа следующее:

Резюме для руководства
1. Введение
2. Концепция разработки безопасного программного обеспечения
Литература
Приложение A: Перечень обозначений, сокращений и аббревиатур
Приложение B. История изменений 

Основное место в документе (стр. 7-38) занимает Таблица 1 «Концепция разработки безопасного программного обеспечения (SSDF), версия 1.2», содержащая графы «Методы (практики)», «Задачи», «Характерные примеры реализации» и «Ссылки».

Источник: сайт NIST
https://csrc.nist.gov/pubs/sp/800/218/r1/ipd 
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218r1.ipd.pdf 

четверг, 25 декабря 2025 г.

Доклад А.А. Меницкой на ежегодной клиентской конференции компании ЭОС «Осенний документооборот»

31 октября 2025 на проводимой компанией «Электронные офисные системы» (ЭОС) ежегодной клиентской конференции  «Осенний документооборот – 2025: Вызовы и возможности управления документами в цифровой среде» с докладом «Цифровой архив сегодня» выступила Анастасия Александровна Меницкая (на фото), руководитель направления разработки систем архивного хранения «Масштабные решения» компании «ЭОС». 

Видеозапись выступления А.А.Меницкой доступна по адресу https://rutube.ru/video/02410c8c1b9471e083ed243d5b4280ac/  


Полная запись конференции доступна по адресу: https://rutube.ru/video/1a4686e4115e872241ce4114b4a23410/

Источник: RuTube 
https://rutube.ru/video/1a4686e4115e872241ce4114b4a23410/ 
https://rutube.ru/video/02410c8c1b9471e083ed243d5b4280ac/ 

вторник, 14 октября 2025 г.

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

Федеральный закон от 7 апреля 2025 года №58-ФЗ «О внесении изменений в Федеральный закон «О безопасности критической информационной инфраструктуры Российской Федерации»» вступил в силу 1 сентября 2025 года. 

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

Статья 6. закона «Полномочия Президента Российской Федерации и органов государственной власти Российской Федерации в области обеспечения безопасности критической информационной инфраструктуры» добавила полномочия Правительству РФ, которое теперь должно будет устанавливать:

  • Перечни типовых отраслевых объектов критической информационной инфраструктуры (ОКИИ);

  • Отраслевые особенности категорирования ОКИИ (по согласованию со ФСТЭК России, в банковской сфере и иных сферах финансового рынка - также по согласованию с Центральным банком РФ), определяющие порядок установления соответствия ОКИИ критериям значимости и показателям их значений в целях присвоения ему одной из категорий значимости и включающие в себя отраслевые признаки значимости ОКИИ, соответствующие критериям значимости и показателям их значений, а также порядок расчета значений показателей критериев значимости с учетом особенностей функционирования ОКИИ;

  • Требования к используемым на значимых ОКИИ программно-аппаратным средствам (в банковской сфере и иных сферах финансового рынка - по согласованию с Центральным банком РФ);

  • Порядок и сроки перехода субъектов критической информационной инфраструктуры на использование на значимых ОКИИ программ для электронных вычислительных машин и баз данных (программное обеспечение) и программно-аппаратных средств, соответствующих установленным требованиям;

  • Порядок осуществления мониторинга за исполнением субъектами критической информационной инфраструктуры обязанности по использованию на значимых ОКИИ программного обеспечения и программно-аппаратных средств, соответствующих установленным требованиям.

Мой комментарий: Перечисленные выше нормативно-правовые акты пока Правительством РФ не утверждены.

Статья 7 «Категорирование объектов критической информационной инфраструктуры» дополнена двумя новыми частями:

  • 13. В перечни типовых отраслевых ОКИИ включаются только типы информационных систем, информационно-телекоммуникационных сетей, автоматизированных систем управления, обладающие признаком значимости.

  • 14. Перечни типовых отраслевых ОКИИ подлежат пересмотру и дополнению на основании предложений ФСТЭК и ФСБ.

Статья 9 «Права и обязанности субъектов критической информационной инфраструктуры, а также иных органов и организаций в сфере обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы РФ» дополнена новыми положениями. Субъекты критической информационной инфраструктуры, которым на праве собственности, аренды или ином законном основании принадлежат значимые объекты критической информационной инфраструктуры теперь также обязаны (часть 3):

  • Использовать на значимых ОКИИ программное обеспечение:

    • ­Сведения о котором включены в единый реестр российских программ для электронных вычислительных машин и баз данных;

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

  • Соблюдать требования к используемым на значимых ОКИИ программно-аппаратным средствам;

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

Обязанности распространяются также на руководителей государственных органов (за исключением органов ФСБ, внешней разведки, государственной охраны, федерального органа обеспечения мобилизационной подготовки органов государственной власти РФ, ФСТЭК России), государственных унитарных предприятий, государственных учреждений, государственных фондов, государственных корпораций (компаний), иных российских юридических лиц, которые, если иное не предусмотрено международным договором РФ, находятся под контролем Российской Федерации, и/или субъекта РФ, и/или контролируемых ими совместно или по отдельности лиц, в части информационных ресурсов РФ, принадлежащих таким органам и юридическим лицам на праве собственности, аренды или ином законном основании. При этом под «контролем» понимается возможность определять решения, принимаемые юридическим лицом, в силу наличия права прямо или косвенно распоряжаться более чем пятьюдесятью процентами общего количества голосов, приходящихся на голосующие акции (доли), составляющие уставный капитал данного юридического лица (часть 4).

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

Порядок информирования руководителями ФСБ России о компьютерных атаках и компьютерных инцидентах, связанных с функционированием информационных ресурсов, устанавливается ФСБ (часть 6).

Федеральный закон вступил в силу с 1 сентября 2025 года.

До установления перечней типовых отраслевых ОКИИ, отраслевых особенностей категорирования ОКИИ категорирование осуществляется в соответствии с порядком осуществления категорирования, установленным Правительством РФ (часть 2 ст.2).

Мой комментарий: Требования к защите информационных ресурсов начинает устанавливаться на уровне законодательных актов. Эти требования постоянно уточняются и совершенствуются; усиливается контроль над организацией и осуществлением этой работы в организациях различного уровня.

Источник: Консультант Плюс
https://www.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=502581

пятница, 10 октября 2025 г.

Использование мобильного приложения в рамках контрольного (надзорного) мероприятия

Современные технологии стремительно врываются в систему государственного управления :)

Федеральный закон от 28 декабря 2024 года №540-ФЗ «О внесении изменений в Федеральный закон «О государственном контроле (надзоре) и муниципальном контроле в Российской Федерации»» закрепил в Федеральном законе от 31 июля 2020 г. №248-ФЗ с начала 2025 года возможность использовать мобильное приложение «Инспектор» для проведения профилактических и контрольно-надзорных мероприятий (таких, как профилактический визит, инспекционный визит, выездная проверка, рейдовый осмотр):

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

Для справки: Вот что о мобильном приложении «Инспектор» (МП «Инспектор») удалось найти в интернете:

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

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

Приложение позволяет в режиме реального времени:

  • Отслеживать геопозицию контролируемого лица;

  • Фиксировать и сохранять фото-, видео- и аудиоматериалы проверки (с проставлением геометок);

  • Отслеживать процесс проверки по чек-листу;

  • Подписывать результаты проверки УЭП;

  • Посмотреть историю проверок компании;

  • Получать уведомления с информацией о дате и времени проведения проверки, а также краткой инструкцией по подключению;

  • Пройти профилактический визит или консультирование;

  • Перенести дату и время видеоконференц-связи (ВКС) (новая дата и время отправляется на рассмотрение инспектору. Перенести дату и время можно не менее чем за 24 часа до начала ВКС).

Постановлением Правительства РФ от 7 августа 2025 года №1181 внесены изменения в «Положение о внешнем контроле деятельности аудиторских организаций, оказывающих аудиторские услуги общественно значимым организациям (федеральном государственном контроле (надзоре)», утвержденное постановлением Правительства Российской Федерации от 25 июня 2021 г. №1009, которые вступили в силу с 13 августа 2025 года.

В Положении уточнен порядок проведения обязательного профилактического визита, который Федеральное казначейство (его территориальные органы) проводит «в соответствии с требованиями, установленными статьей 52.1 Федерального закона «О государственном контроле (надзоре) и муниципальном контроле в Российской Федерации» (п.17).

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

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

  • путем использования видео-конференц-связи 

Теперь такая беседа может проводиться с использованием мобильного приложения «Инспектор».

Фотосъемка и видеозапись при проведении осмотра в рамках профилактического визита осуществляются также с использованием мобильного приложения «Инспектор» (раньше фотосьемка и видеозапись не были предусмотрены - Н.Х.)

Положение дополнено пунктом 20 (1) следующего содержания:

20 (1). Выездная проверка, контрольное (надзорное) действие по осмотру, опросу и экспертизе могут проводиться должностным лицом Федерального казначейства (его территориального органа), уполномоченным на осуществление государственного контроля, с использованием средств дистанционного взаимодействия, в том числе посредством видео-конференц-связи, а также с использованием мобильного приложения «Инспектор».

Фотосъемка и видеозапись при проведении осмотра в рамках контрольного (надзорного) мероприятия в виде выездной проверки осуществляются с использованием мобильного приложения «Инспектор».

Мой комментарий: Все виды контрольных мероприятий Казначейством теперь будут фиксироваться фотосъемкой и видеозаписью с использованием мобильного приложения «Инспектор».

Источник: Консультант Плюс / Министерство туризма Хабаровского края
 /Ростехнадзор
https://www.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=512209
https://mintour.khabkrai.ru/Deyatelnost/Gosudarstvennyj-kontrol-nadzor-/Mobilnoe-prilozhenie-quot-Inspektor-quot-/848?version=normal
https://www.gosnadzor.ru/news/67/16563/?ysclid=mey587ljmm85633989 

вторник, 7 октября 2025 г.

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

Федеральный закон от 1 апреля 2025 года №41-ФЗ «О создании государственной информационной системы противодействия правонарушениям, совершаемым с использованием информационных и коммуникационных технологий, и о внесении изменений в отдельные законодательные акты Российской Федерации» ещё не вступил в силу (он начнёт действовать с 1 марта 2026 года), а в него уже внесены изменения :)

Федеральный закон от 31 июля 2025 года №325-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации» дополнил статью 15 «Заключительные положения» этого закона тремя новыми частями, которые вводят понятие «значимых разработчиков российского программного обеспечения» и предусматривают их учёт Министерством цифрового развития, связи и массовых коммуникаций Российской Федерации (Минцифры России).

Разработчик российских программ для электронных вычислительных машин и баз данных признается «значимым» в случае его соответствия следующим требованиям (часть 3):

  • Разработчик является российским хозяйственным обществом, которое, если иное не предусмотрено международным договором Российской Федерации, находится под контролем Российской Федерации, и/или субъекта РФ, и/или муниципального образования, и/или гражданина РФ, и/или контролируемых ими совместно или по отдельности лиц. При этом под контролем понимается возможность определять решения, принимаемые указанным обществом, в силу наличия права прямо или косвенно распоряжаться более чем пятьюдесятью процентами общего количества голосов, приходящихся на голосующие акции (доли), составляющие уставный капитал данного общества;

  • Разработчик заключил с Правительством РФ соглашение о разработке и/или модернизации за счет собственных средств программ для электронных вычислительных машин и баз данных в целях импортозамещения программного обеспечения для реализации особо значимых проектов. Порядок и условия заключения такого соглашения, требования к нему устанавливаются Правительством РФ.

Правительством Российской Федерации могут быть установлены дополнительные требования к разработчикам российского программного обеспечения, указанным в пункте 2 части 3 настоящей статьи (часть 4).

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

Источник: Консультант Плюс
https://www.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=511130 

пятница, 3 октября 2025 г.

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

Федеральный закон от 31 июля 2025 года №325-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации» дополнил статью 2 Федерального закона от 7 апреля 2025 года №58-ФЗ «О внесении изменений в Федеральный закон «О безопасности критической информационной инфраструктуры Российской Федерации»» новыми частями, которые устанавливают, что Минцифры будет с 1 смарта 2026 года формировать и вести два перечня:

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

  • Перечень доверенных российских программ для электронных вычислительных машин и баз данных (программ).

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

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

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

  • ­Российской Федерации, субъекту РФ, муниципальному образованию;

  • ­Российской некоммерческой организации, высший орган управления которой формируется прямо и/или косвенно РФ, субъектами РФ, муниципальными образованиями и/или гражданами РФ и решения которой иностранное лицо не имеет возможности определять в силу особенностей отношений между таким иностранным лицом и российской некоммерческой организацией;

  • ­Российской коммерческой организации, которая, если иное не предусмотрено международным договором РФ, находится под контролем РФ, и/или субъекта РФ, и/или муниципального образования, и/или гражданина РФ, и/или контролируемых ими совместно или по отдельности лиц. При этом под контролем понимается возможность определять решения, принимаемые указанной российской коммерческой организацией, в силу наличия права прямо или косвенно распоряжаться более чем пятьюдесятью процентами общего количества голосов, приходящихся на голосующие акции (доли), составляющие уставный капитал данной российской коммерческой организации;

  • ­Гражданину РФ;

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

Положение о правительственной комиссии, ее состав и порядок принятия ею решений утверждаются Правительством РФ. В отношении программ, исключительное право на которые принадлежит кредитным организациям и некредитным финансовым организациям, указанная правительственная комиссия принимает решение по представлению Центрального банка РФ (ч. 3-3).

Правительством РФ могут быть установлены дополнительные требования к программам, сведения о которых включены в такой перечень (ч.3-4).

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

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

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

  • Исключительное право на программу на территории всего мира и на весь срок действия исключительного права принадлежит одному либо нескольким из следующих лиц (правообладателей):

    • ­Российской Федерации, субъекту РФ, муниципальному образованию;

    • ­Российской некоммерческой организации, высший орган управления которой формируется прямо и/или косвенно Российской Федерацией, субъектами Российской Федерации, муниципальными образованиями и/или гражданами Российской Федерации, не имеющими гражданства другого государства, и решения которой иностранное лицо не имеет возможности определять в силу особенностей отношений между таким иностранным лицом и российской некоммерческой организацией;

    • ­Российской коммерческой организации, которая, если иное не предусмотрено международным договором Российской Федерации, находится под контролем Российской Федерации, и/или субъекта Российской Федерации, и/или муниципального образования, и/или гражданина Российской Федерации, не имеющего гражданства другого государства, и/или контролируемых ими совместно или по отдельности лиц. При этом под контролем понимается возможность определять решения, принимаемые указанной российской коммерческой организацией, в силу наличия права прямо или косвенно распоряжаться более чем пятьюдесятью процентами общего количества голосов, приходящихся на голосующие акции (доли), составляющие уставный капитал данной российской коммерческой организации;

    • ­Гражданину Российской Федерации, не имеющему гражданства другого государства;

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

  • Программа соответствует установленным Правительством РФ по согласованию с ФСБ, и федеральным органом исполнительной власти, уполномоченным в области противодействия техническим разведкам и технической защиты информации, требованиям к обеспечению информационной безопасности;

  • Сведения о программе не составляют государственную тайну, и программа не содержит сведений, составляющих государственную тайну.

Положение о правительственной комиссии, ее состав и порядок принятия ею решений утверждаются Правительством РФ. (ч.3-8).

Правительством РФ могут быть установлены дополнительные требования к программам, сведения о которых включены в перечень доверенных российских программ (ч.3-9).

Правила формирования и ведения перечня, состав сведений, включаемых в него, условия включения таких сведений в перечень и исключения их из него, порядок предоставления сведений, включаемых в перечень, устанавливаются Правительством РФ (ч.3-10).

Случаи использования программ, сведения о которых включены в перечень, определяются федеральными законами, актами Президента РФ и Правительства РФ (ч.3-11).

Федеральный закон вступит в силу с 1 марта 2026 года.

Мой комментарий: Я не совсем понимаю, зачем вести два перечня - неужели нельзя эти данные объединить в один информационный ресурс? А то так можно запутать и себя, и всех участников рынка…

Источник: Консультант Плюс
https://www.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=511130