Аппаратная разработка — подход к созданию ПО¶
Аппаратная разработка (от англ. apparatus — аппарат, механизм) — подход к созданию программного обеспечения, при котором приложение проектируется и реализуется как жёстко структурированная, детерминированная система с заранее определёнными интерфейсами, протоколами взаимодействия и жёсткими контрактами между компонентами. В отличие от гибких, адаптивных подходов (agile, lean), аппаратная разработка предполагает полное или преимущественное планирование архитектуры до начала реализации, минимизацию динамических изменений и строгое следование спецификациям.
¶Происхождение термина
Термин «аппз» (сокращение от «аппаратная разработка») появился в русскоязычном IT-сообществе в конце 2010-х годов как антитеза гибким методологиям. Он отражает подход, при котором команда разработки работает как единый «аппарат» — жёстко организованная структура с чёткой иерархией, регламентированными процессами и минимальной автономией отдельных участников.
Термин не имеет устоявшегося международного аналога, но по смыслу близок к понятиям «waterfall» (водопадная модель), «plan-driven development» (разработка, ориентированная на планирование) и «rigid architecture» (жёсткая архитектура). В англоязычной литературе схожие по духу подходы описываются как «big design up front» (БДВП — большое проектирование вперёд).
¶Основные характеристики
Аппаратная разработка определяется рядом признаков, отличающих её от других методологий:
- Полное проектирование до начала разработки. Архитектура системы, интерфейсы модулей, форматы данных и протоколы взаимодействия фиксируются в документации до написания основного кода.
- Жёсткие контракты между компонентами. Изменение интерфейса одного модуля требует согласованного изменения всех смежных модулей и обновления документации.
- Минимизация итераций. Циклы разработки длинные, обратная связь от пользователя поступает поздно, изменения в требованиях на поздних этапах считаются исключением.
- Регламентированные процессы. Каждый этап работ (анализ требований, проектирование, реализация, тестирование, развёртывание) имеет формальные артефакты и критерии завершения.
- Централизованное управление. Решения принимаются на уровне архитекторов и руководителей проекта, а не отдельными командами.
¶Сравнение с гибкими методологиями
| Критерий | Аппаратная разработка | Гибкие методологии (agile) |
|---|---|---|
| Планирование | Полное, до начала работ | Итеративное, по мере развития |
| Реакция на изменения требований | Затруднена, требует формальных процедур | Быстрая, встроена в процесс |
| Документация | Объёмная, формализованная | Минимальная, живая |
| Роли | Чёткая иерархия, централизация | Самоорганизация команд |
| Релизы | Редкие, крупные | Частые, инкрементальные |
| Риски | Ошибки в требованиях выявляются поздно | Риски распределены по итерациям |
¶Область применения
Аппаратная разработка традиционно применяется в сферах, где цена ошибки высока, а требования к системе стабильны и формализуемы:
- Промышленное и встраиваемое ПО — системы управления оборудованием, где поведение должно быть полностью предсказуемым.
- Военные и государственные системы — требования фиксируются на этапе тендерной документации, изменения на поздних этапах практически исключены.
- Финансовые и банковские системы — расчёты, клиринг, отчётность, где регуляторные требования жёстко определяют архитектуру.
- Авиационное и космическое программное обеспечение — стандарты DO-178C и аналоги требуют полной трассируемости требований до кода.
- Медицинские системы — регуляторные рамки (например, FDA 21 CFR Part 820) предписывают документирование каждого этапа жизненного цикла.
¶Критика
Основные претензии к аппаратной разработке связаны с её инерционностью:
- Замедленный выход на рынок. Длительный этап проектирования откладывает появление работающего продукта.
- Риск построения «не того продукта». Если требования были неверно интерпретированы, это выясняется только на этапе приёмки.
- Сопротивление изменениям. Даже небольшое изменение требует пересмотра документации и согласования между подразделениями.
- Высокая стоимость на ранних этапах. Привлечение архитекторов и аналитиков до начала разработки увеличивает бюджет.
Приверженцы подхода возражают, что в жёстко регулируемых отраслях альтернативы аппаратной разработке нет: регулятор требует документированного, воспроизводимого и полностью трассируемого процесса.
¶См. также
- Водопадная модель
- Проектирование программного обеспечения
- Контрактное программирование
- DO-178C
¶Источники
- Соммервилл И. Инженерия программного обеспечения. — М.: Вильямс, 2018.
- Макконнелл С. Строка кода. История создания программного обеспечения. — М.: Вильямс, 2020.
- Гилл С. Гибкая разработка на практике. — СПб.: Питер, 2019.
- IEEE/ISO/IEC 12207:2017 — Системы и программная инженерия. Процессы жизненного цикла программного обеспечения.
- DO-178C «Software Considerations in Airborne Systems and Equipment Certification».