Обновить
512K+

Управление разработкой *

Планирование, отслеживание и контроль

516,62
Рейтинг
Сначала показывать
Порог рейтинга

Разработчики из команды «Яндекса» выложили в открытый доступ первое решение на базе большой языковой модели (LLM) для автоматизации миграции iOS‑проектов с Objective‑C на Swift, современный язык Apple. Оно особенно актуально для крупных проектов, накопивших сотни тысяч строк устаревшего кода. Решение ускоряет процесс миграции в 2,5 раза, позволяя разработчикам переключиться с рутинных задач на проверку качества.

Решение Migration toolkit for Swift разработано при миграции кодовой базы «Яндекс Браузера». Команда при переписывании кода столкнулась с целым рядом проблем: затраты времени и ресурсов, неизбежные при ручной работе ошибки, и всё это — при необходимости параллельно развивать проект. В результате за пять лет удалось сократить технический долг только наполовину.

Новый подход на базе LLM не только ускорил миграцию, но и позволил освободить разработчиков от монотонного переписывания кода — вместо этого они валидировали корректность миграции и выполняли сложный рефакторинг. За два месяца команда интегрировала 106 пул-реквестов, переписав около 97,5 тысячи строк устаревшего кода и более двух тысяч файлов. Обработка такого объёма данных вручную заняла бы больше года.

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

Готовые промпты автоматически подгружаются в контекст диалога в большинстве современных агентских IDE, поэтому решение совместимо с популярными инструментами для работы с кодом. Все промпты, скрипты и шаблоны проекта доступны на GitHub и SourceCraft.

Теги:
+3
Комментарии0

Ускорили разработку в 2 раза за счет AI? Понятно.
Вот только релизы не стали быстрее, time-to-market не сократился.

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

Agile создавался как ответ на высокую сложность разработки, но AI эту сложность уже снизил. А значит, текущая модель команд начинает устаревать.

В апреле на Product Focus Club наш CPTO Саша Бондаренко поделился своим видением трансформации команд. 

Он рассказал:
— почему инвестиции в AI не дают эффекта без пересборки процессов (на данных Klarna и DORA)
— как появляется новая роль Product Engineer вместо набора узких специалистов
— почему команды из 7-9 человек трансформируются в компактные поды из 2-3 инженеров
— как Platform Engineering становится системой контроля и масштабирования, а не поддержкой
— как выглядит Team Topologies 3.0 и с чего начать переход

Запись выступления доступна для просмотра на YouTube и VK Видео

Кстати, в рамках эксперимента мы запустили три pod-команды у нас в Garage Eight. И у ребят уже есть крутые результаты! Обязательно поделимся ими в нашем телеграм-канале.

Теги:
+4
Комментарии0

РБПО по ГОСТ Р 56939—2024: вебинар №11 из 30 – Динамический анализ кода программы

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.11. – "Динамический анализ кода программы". На YouTube. Слайды.

Цели 11-го процесса по ГОСТ Р 56939—2024:

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

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Теги:
+1
Комментарии0

Написал большую статью на Habr — От написания промптов к проектированию контекста. Или один очень обширный материал про Context Engineering

Полезно всем, кто работает с агентами Claude Code | Codex 🍦

Что внутри

Context rot и reasoning shift — почему длинный контекст это плохо

Типы Attention и как считается сложность в современных трансформерах

Из каких 7 слоёв состоит контекст Зачем нужен CLAUDE.md / AGENTS.md / GEMINI.md
Что такое MEMORY.md Секция про Skills, MCP, Subagents

Архитектура AGENTS LOOP

Как работает Prompt caching Как считается стоимость токенов

Что отличает Новичка от Мастера в работе с современными агентами

А какие там иллюстрации, мммм

А завтра онлайн в 18 мск буду читать лекцию по этой статье, залетайте послушать https://calendar.app.google/TDm1ZZusNtX5w394A

Теги:
+3
Комментарии0

Представлен проект под названием «Кладбище 100 ИИ‑проектов», которые прекратили свою работу или были приобретены и интегрированы в другие продукты. Список поддерживается в рамках предварительной проверки — каждая запись представляет собой реальный продукт, зарегистрированный на ToolDirectory.AI до прекращения его работы.

Теги:
+3
Комментарии0

РБПО по ГОСТ Р 56939—2024: вебинар №10 из 30 – Статический анализ исходного кода

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.10. – "Статический анализ исходного кода". На YouTube. Слайды.

Цели десятого процесса по ГОСТ Р 56939—2024:

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

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Рассмотрение 10-го процесса в ГОСТ Р 56939—2024 неразрывно связано с другим ГОСТ Р 71207—2024 "Статический анализ программного обеспечения". В нём говорится о том же, только более подробно и конкретно.

Про ГОСТ Р 71207—2024 я отдельно рассказывал в цикле из пяти вебинаров:

  1. Общее описание и актуальность;

  2. Терминология;

  3. Критические ошибки;

  4. Технологии анализа кода;

  5. Процессы.

Разрабатываемый нами анализатор кода PVS-Studio совместим с ГОСТ Р 71207—2024 и закрывает 10-й процесс ГОСТ Р 56939—2024 для языков C, C++, C#, Java. Сейчас в процессе реализации поддержка языков Go, JavaScript, TypeScript. Попробовать PVS-Studio.

Теги:
0
Комментарии0

Прокрустово ложе

В недавнем видосе я рассказывал, что сейчас читаю Талеба (в частности, его идеи вокруг “Антихрупкости”). И вот на днях на работе поймал идеальный личный пример одной из его любимых метафор Прокрустова ложа.

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

А теперь к практике. Как говорят таксисты: блог и инди-хакинг - это для души, а вообще у меня и настоящая работа есть. Я бэкенд-лид в команде, которая пилит платформу для масс-найма (курьеры, сборщики).

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

А дальше классика: 20% эйчаров закрывают 80% вакансий. И тут возникает моя самая наивная мысль: ну так давайте пилить фичи специально под этих топов!

Но тут кроется засада. Выясняется, что процессы самых эффективных ребят очень сложно загнать в рамки. У них свои паттерны, подходы, интуиция. И когда пытаемся натянуть на них стандартный флоу, мы строим для них то самое Прокрустово ложе. Пытаясь впихнуть нестандартного, сильного спеца в удобные для системы формочки, мы буквально “отрубаем ему ноги”. Мы заставляем его работать “как положено”, лишая тех самых фишек, которые и делали его звездой.

Получается забавный парадокс: классическая автоматизация мешает сильным, но отлично помогает “слабым”. Среднего сотрудника надо меньше учить, он быстрее вкатывается. А если он уйдет, найти замену гораздо проще, а порог входа сильно снижается за счет жесткого и автоматизированного рабочего процесса.

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

Дебаж 🐞с ноги 🦶

Теги:
0
Комментарии0

У тебя есть ровно 2–3 часа настоящей работы в день. Не больше.

Не потому что ты ленишься. А потому что всё остальное время — встречи, переписка, уведомления, «быстрые вопросы» в чате — это не работа. Это шум, который притворяется работой.

По данным Hubstaff 2026, средний офисный сотрудник проводит в состоянии реальной концентрации лишь 25–37% рабочего дня. Остальные 61% — это переключение между задачами, митинги и реакции на чужие приоритеты. У менеджеров ещё хуже: глубокий фокус занимает всего 27% времени.

И это не частная проблема — это системная. ActivTrak фиксирует: за год средняя сессия глубокой работы сократилась ещё на 8%. Корпоративная культура «занятости» буквально пожирает способность думать.

Что с этим делать?

Первое — перестать считать «занятость» синонимом продуктивности. Ты можешь провести 8 часов в офисе и не создать ничего ценного.

Второе — защитить свои лучшие часы физически. Тайм-блокинг: 90 минут с утра — только одна задача, никаких мессенджеров. Это не роскошь, это гигиена.

Третье — сократить встречи. Исследования показывают: минус 40% встреч = плюс 71% к продуктивности. Большинство созвонов можно заменить голосовым сообщением или коротким текстом.

No-Meeting Day — когда целый день без звонков — это уже не стартаперская экзотика, а норма в сильных командах.

Твои 2–3 часа концентрации — это и есть ты в лучшей форме. Вопрос только в том, кому ты их отдашь: своим целям или чужим срочностям.

Теги:
0
Комментарии0

В команде Apple вайбкодят приложения — разработчики случайно оставили файлы Claude .md в обновлении Apple Support. После того, как этот инцидент стал публичным в соцсетях, то в Apple выпустили новую версию обновления 5.13.1 без следов вайбкодинга.

Теги:
+2
Комментарии1

Искусственный интеллект Claude Opus от Autropic размышляет не только на английском, но и на русском и китайском языках. Блоки ответов ИИ иногда содержат текст «процесса мышления» на разных языках.

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

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

Теги:
+2
Комментарии0

Дорожная карта Agentic AI. Level 4. Своя кузница — локальный запуск моделей

Дорожная карта Agentic AI — Level 4. Своя кузница: локальный запуск моделей
Level 4. Своя кузница — локальный запуск моделей

Не всё имеет смысл отдавать в облако. Причин у этого как минимум три:

  1. Приватность. Стоит начать пересылать в чужой API персональные данные клиентов, внутреннюю переписку или код с коммерческой тайной, как логи стороннего провайдера превращаются из абстрактной строчки в SLA во вполне конкретный риск утечки. Локальная модель эту головную боль снимает: данные просто не покидают периметр компании, и обсуждать с безопасниками становится по сути нечего.

  2. Автономность. Когда провайдер прилёг, сети легли или вашему региону внезапно прикрыли доступ, локальный агент этого даже не заметит и продолжит работать, как ни в чём не бывало.

  3. Стоимость. Здесь всё упирается в масштаб. Если вы просто экспериментируете у себя на ноутбуке, локальный запуск получается полностью бесплатным: ни подписок, ни платы за токены, и докупать ничего не придётся, всё поедет на том железе, что уже стоит на столе. Когда же речь идёт про нагруженный прод, картина меняется: нужен сервер с GPU, и экономика там сходится не сразу. На сотнях запросов в день локальный инференс вряд ли отобьётся, а вот на десятках тысяч он уже выгоднее облака.

Что вообще получится запустить

Проприетарные модели уровня GPT-5, Claude Opus 4.7 или Gemini 3.1 локально вы, конечно, не запустите: они закрытые и слишком огромные. Зато опенсорс быстро подтягивается следом. Qwen3 от Alibaba, DeepSeek R1 и V3.1, Mistral Small и Magistral это вполне рабочие модели, которые в квантизованных версиях помещаются на одну видеокарту. Даже OpenAI в прошлом году выложила свою открытую gpt-oss, сразу в 20B и 120B параметров.

Чем крутить локально

Проще всего начать с Ollama: ставится одной командой, ещё одной скачивается модель, и всё. Никаких плясок с CUDA, Python и зависимостями, из коробки есть и GUI, и REST-API. Если хочется чего-то более «приложенческого», посмотрите в сторону LM Studio или Jan; у LM Studio при этом есть приятная мелочь: она ещё до скачивания подскажет, хватит ли у вас ресурсов на конкретную модель.

Как встроить в свой код

Самое важное даже не в том, как удобно поднять модель у себя, а в том, что интегрировать её в код ваших приложений так же легко, как сменить провайдера. У всех этих инструментов OpenAI-совместимый API, поэтому в клиенте OpenAI достаточно поменять base_url с облака на localhost, и тот же самый код из прошлых постов продолжит работать без единой правки.

Что брать в продакшен

Эта связка работает, пока вы экспериментируете на ноутбуке. В продакшене ставки выше: опенсорс-модель надо крутить под реальной нагрузкой, и стандарт здесь это vLLM. Он оптимизирован под высокий RPS и параллельный инференс, реально выжимает из GPU всё, что она способна отдать.

Вообщем, не относитесь к локальному запуску, как к большому инфраструктурному проекту. На практике это один спокойный вечер экспериментов: поставили Ollama, скачали Qwen3, поменяли base_url в агенте и погнали…

🔔 Следующая тема: Few-shot learning, как учить модель прямо в промпте.

⬅️ Предыдущая тема: Level 4. Новые чувства — мультимодальность

Подписывайтесь, пожалуйста, чтобы не пропустить!

Больше про ИИ — в ТГ-канале и ВК. Каталог наших курсов, услуг и кейсов по ИИ-агентам. По вопросам — пишите в личку.

Теги:
+1
Комментарии0

4 статьи для безопасного проектирования и разработки программ


Привет, Хабр! Подготовили для вас подборку полезных материалов по безопасной разработке ПО.

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

Что внутри:

  • Процессы и основные риски безопасной разработки.

  • Требования безопасности

  • Принципы безопасного проектирования

  • Безопасное использование сторонних компонентов.

Читайте и сохраняйте в закладки →

Теги:
+5
Комментарии0

РБПО по ГОСТ Р 56939—2024: вебинар №09 из 30 – Экспертиза исходного кода

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.9. – "Экспертиза исходного кода". На YouTube. Слайды.

Цели девятого процесса по ГОСТ Р 56939—2024:

Обеспечение соответствия исходного кода ПО предъявляемым к нему требованиям.

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Теги:
+1
Комментарии0

Ближайшие события

7 способов убить проект в длииинной Excel-таблице — и один, чтобы спасти

1. Создайте таблицу с 15 вкладками

Сначала все логично: «Общее», «Январь», «Февраль», «Последняя версия»... Через полгода никто не помнит, куда смотреть.

2. Используйте «В работе» как универсальный статус. 

Пусть все, что не упало в «Готово», автоматически числится в процессе. Когда на самом деле задача будет выполнена? Неизвестно. Пора вмешаться? Не понятно.

3. Храните переписку, файлы и задачи порознь

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

4. Собирайте статусы раз в неделю вручную

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

Еще три способа упереться в край возможностей Excel и приблизить конец игры, а также о роскошном минимуме для управления проектами — в новой статье, здесь на Хабре.

Теги:
+2
Комментарии0

Лог в реальном времени: берём госзаказ и закрываем его агентной разработкой

На днях Оскар Хартманн довольно жёстко высказался за вайбкодинг. Тем временем на Пикабу из 45 программистов в профессиональном сообществе вайбкодят только 9. В госсекторе — единицы.

Пока остальные спорят, костыли это или нет — я берусь за реальный тендер и публикую всё как есть.

Подписывайтесь — первый пост как только войду в торги на понижение.

Теги:
+2
Комментарии0

РБПО по ГОСТ Р 56939—2024: вебинар №08 из 30 – Формирование и поддержание в актуальном состоянии правил кодирования

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.8. – "Формирование и поддержание в актуальном состоянии правил кодирования". На YouTube. Слайды.

Цели восьмого процесса по ГОСТ Р 56939—2024:

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

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Теги:
+1
Комментарии0

Автоматизируем процессы в VSCode с помощью расширения n8n-atom, которое заберёт всю рутину. Проект выдаёт цепочки из ИИ-агентов, действий и вызовов инструментов. Atom преобразует n8n-воркфлоу в обычные файлы, чтобы их могли читать нейронки вроде ChatGPT, Claude и Gemini. ИИ читает код пользователя, редактирует его и дает советы по оптимизации сервисов.

Теги:
0
Комментарии0

Оптимизация контекста для Claude Code на большом проекте (иногда и 50% экономия токенов)

Работаю над большим C++ проектом - реализация сетевого протокола. Использую Claude Code как основной инструмент. Со временем заметил: каждый новый чат начинается с того, что агент долго читает README.md, который разросся до 1000+ строк и 60 КБ.

Проблема

В CLAUDE.md была прописана команда читать README.md в начале каждого диалога, агенту нужно дать контекст проекта. Пока проект был небольшим это работало нормально. Но README рос вместе с проектом и в итоге стал содержать всё: архитектуру, логику DTLS, настройки веб-интерфейса, описание протокола, инструкции по сборке.

И как результат:

  • Агент тратит тысячи токенов на анализ файла до начала работы

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

Решение

Вместо одного большого файла использовать иерархию маленьких, в отдельной папке claude-context/:

claude-context/
├── context-claude.md       # общая архитектура и навигация (~90 строк)
├── context-AC-claude.md    # Access Controller
├── context-WTP-claude.md   # WTP Agent
├── context-WEB-claude.md   # Web Interface
└── context-TESTS-claude.md # тесты

Главный файл context-claude.md содержит краткое описание проекта и таблицу-навигатор: какой файл читать для какой области. В дочерних файлах описана детализация по модулям, каждый 100-130 строк.

Инструкция в CLAUDE.md теперь выглядит так:

“Start each new conversation by reading claude-context/context-claude.md. For deeper context on specific areas, read the relevant file from that directory.”

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

Замер

Чтобы проверить эффект, я поставил Claude одну и ту же задачу в двух разных конфигурациях:

“Добавь тесты для WtpConfigController и WtpRadioController, проверь что если WTP address не строка, то возникает исключение std::runtime_error”

| Параметр             | README.md (60 КБ) | Иерархический контекст | Разница  |
| :------------------- | :---------------- | :--------------------- | :------- |
| Токены на сообщения  | 36.8k             | 17.6k                  | -53%     |
| Всего токенов        | 56.7k             | 37.6k                  | -34%     |
| Рост usage за задачу | +11%              | +6%                    | В 2 раза |
| Скорость анализа     | Заметная пауза    | Почти мгновенный старт |          |

Важный момент

README.md остался нетронутым - это документация для людей. Файлы в claude-context/ - отдельный артефакт, написанный под AI: плотно, без лирики, с ASCII-схемами и таблицами. Я старался не смешивать два разных назначения в одном файле.

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

Теги:
+3
Комментарии8

РБПО по ГОСТ Р 56939—2024: вебинар №07 из 30 – Моделирование угроз и разработка описания поверхности атаки

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.7. – "Моделирование угроз и разработка описания поверхности атаки". На YouTube.  Слайды.

Цели седьмого процесса по ГОСТ Р 56939—2024:

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

5.7.1.2 Уточнение модели угроз и описания поверхности атаки по результатам разработки кода и его изменений.

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Теги:
0
Комментарии0

РБПО по ГОСТ Р 56939—2024: вебинар №06 из 30 – Разработка, уточнение и анализ архитектуры программного обеспечения

Прошёлся сегодня по использованию вайб-кодинга без соответствующих мер контроля результата – Ревью вайб-кода с гнильцой, который притворяется оптимизированным С++ кодом. А теперь продолжим тему, как создавать качественные, надёжные и безопасные приложения. Это всё, кстати, актуально и для веб-кодинга, но, к сожалению, пока мало кто это осознаёт :(

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.6. – "Разработка, уточнение и анализ архитектуры программного обеспечения". Слайды.

Цели шестого процесса по ГОСТ Р 56939—2024:

5.6.1.1 Создание условий для снижения количества возможных недостатков при разработке архитектуры ПО.

5.6.1.2 Уточнение архитектуры ПО в процессе разработки кода.

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Теги:
0
Комментарии0
1
23 ...