Конструирование ПО — понятие, жизненный цикл, стандарты
Доступ к данным — Основы БД, SQL, конфигурации. Карта — о разделе.
Конструирование ПО — от требований к коду
В разговорной речи "разработка" часто означает всё сразу — идея, ТЗ, код, тесты, деплой. В инженерной дисциплине полезнее различать стадии жизненного цикла (SDLC — Software Development Life Cycle, жизненный цикл разработки ПО): на каждой — свои цели, артефакты и критерии "готово".
Если вы новичок — где вы в этой цепочке
| Вопрос | Стадия |
|---|---|
| "Что должна делать система?" | Требования |
| "Из каких частей она состоит?" | Проектирование |
| "Как это написано на Java/Python и собрано?" | Конструирование ← вы здесь, когда пишете код |
| "Работает ли целиком для пользователя?" | Системное тестирование |
| "Как выкатить на сервер?" | Внедрение |
Конструирование программного обеспечения (англ. software construction) — это стадия, на которой:
- детализируют проектные решения до уровня исходного кода и модулей (4.02 Код — о разделе, структура проекта);
- пишут, интегрируют и собирают программу;
- создают локальные тесты, документируют API, настраивают сборку;
- следят за стилем, модульностью и техническим долгом на уровне кода.
Проще — проектирование отвечает на вопрос "как устроена система", конструирование — "как это закодировано и собрано", системное тестирование — "работает ли продукт целиком по требованиям".
В учебниках по программной инженерии то же разграничение описывают через SWEBOK Software Construction — детальное создание рабочей системы кодированием, верификацией, модульным и интеграционным тестированием и отладкой. Границы с проектированием и тестированием размыты — в Agile все три идут параллельно в итерации.
Технология конструирования ПО (ТКПО) — система инженерных принципов для создания экономичного ПО, которое надёжно работает на реальном железе. В неё входят:
| Компонент ТКПО | Примеры |
|---|---|
| Методы | Планирование, анализ требований, проектирование структур, кодирование, тестирование, сопровождение |
| Средства (утилиты) | Компиляторы, IDE, линтеры, генераторы кода |
| Процедуры | Последовательности шагов, регламенты review и CI |
| CASE-системы | Наборы утилит для автоматизации методов (Computer Aided Software Engineering) |
Последовательности шагов ТКПО называют парадигмами — они вносят в разработку организованный инженерный порядок вместо хаотичного "просто пишем код".
На стадии конструирования особенно важны две проверки из ISO (международных стандартов качества ПО):
-
Верификация — "строим ли правильно?" Код соответствует проекту, тестам, стандартам.
Пример: в проекте заложили интерфейсPaymentPort— вы реализовали классStripeAdapter, unit-тесты зелёные, SonarQube без критичных замечаний. Это верификация. -
Валидация (частично на этой стадии) — "строим ли то, что нужно бизнесу?"
Пример: заказчик смотрит demo "оплата в один клик" на staging и говорит: "кнопка не там". Вы ещё до приёмочных тестов узнали, что UX не тот. Feature toggle и canary (выкатка на 5% пользователей) — тоже ранняя валидация.
| Верификация | Валидация | |
|---|---|---|
| Вопрос | Соответствует ли артефакт спецификации/проекту? | Решает ли продукт задачу пользователя? |
| Кто чаще ловит | Разработчик, QA по тест-кейсам | Пользователь, заказчик, продукт |
| На конструировании | Unit-тесты, code review, lint | Demo, прототип, A/B, canary |
Guide to the Software Engineering Body of Knowledge (SWEBOK) выделяет knowledge area Software Construction — минимизация сложности, стандарты, управление конструированием, модели данных, логика, интерфейсы, безопасность на уровне кода.
Этот раздел энциклопедии — практичная выжимка той же области для базового курса.
В русскоязычных учебниках "конструирование" — устоявшийся перевод construction из SWEBOK и ISO.
Речь о инженерной реализации ПО.
Конструирование тесно связано с другими knowledge areas SWEBOK:
- Software Design — детальный дизайн часто идёт параллельно с кодом;
- Software Testing — unit/integration на стадии конструирования;
- Software Configuration Management — версии кода и сборок;
- Software Engineering Tools and Methods — самая "инструментальная" стадия;
- Software Quality — код как главный артефакт качества;
- Computer Science foundations — алгоритмы и практики кодирования;
- Software Project Management — планирование и контроль реализации.
Если конструирование проведено неполно (слабая архитектура модулей, размытые границы), пользователи начинают просить "мелкие улучшения" по готовым веткам — а глобально переделать уже поздно.
Накапливаются локальные заплатки.
Профилактика — модульность, traceability к требованиям и ранние прототипы на рисках.
Место конструирования в жизненном цикле
Обобщённая модель SDLC (подробнее — в главе про жизненный цикл):
Что происходит до конструирования
| Стадия | Результат для конструктора |
|---|---|
| Требования | Что система должна делать; критерии приёмки |
| Проектирование | Архитектура, интерфейсы, модель данных, NFR |
Без этого код превращается в угадывание. Конструктор (разработчик) может уточнять проект на месте — осознанно — через ADR (запись архитектурного решения), рефакторинг, согласование с архитектором.
Аналитик описал: "пользователь оплачивает заказ картой".
Архитектор решил: отдельный сервис billing, событие PaymentCompleted.
Конструирование — вы пишете класс StripeAdapter, миграцию таблицы payments, unit-тест на отказ при нулевой сумме.
Если в процессе выяснилось, что нужен СБП — вы возвращаетесь к требованиям, а не "тихо дописываете if".
Что происходит после и параллельно
- Тестирование — на стадии конструирования уже пишут модульные и интеграционные тесты; системные и приёмочные часто идут дальше по SDLC (раздел "Тестирование").
- Внедрение — сборка, CI/CD, деплой (DevOps).
- Эксплуатация — баги и доработки снова проходят цикл "изменение → конструирование → тест → релиз".
В Agile и Scrum фазы не идут строго по очереди: в каждом спринте вы одновременно уточняете требования, проектируете кусок и конструируете инкремент. Стадия "конструирование" не исчезает — она укорочена и повторяется.
Основные виды работ на стадии конструирования
По SWEBOK и практике индустрии на конструирование приходится:
- Детализация проекта — выбор структур данных, алгоритмов, паттернов внутри модуля (принципы проектирования, паттерны).
- Кодирование — написание исходного текста на языках программирования (раздел "Код").
- Модульность — пакеты, библиотеки, границы (связность и сцепление).
- Конструирование данных — схемы БД, миграции, сериализация (частично пересекается с проектированием).
- Сборка — компиляция, линковка, bundler, артефакты (сборка и зависимости).
- Верификация на уровне кода — unit-тесты, статический анализ, code review (культура кода, unit-тесты).
- Документирование реализации — комментарии к неочевидному, README модулей, OpenAPI для реализованных endpoint'ов.
Если вы коммитите код в репозиторий и этот код участвует в сборке продукта — вы работаете на стадии конструирования.
Настройка Jenkins или написание ТЗ — уже соседние стадии.
Артефакты конструирования
| Артефакт | Назначение |
|---|---|
| Исходный код | Основной результат стадии |
| Unit- и integration-тесты | Доказательство корректности модулей |
| Скрипты сборки | Makefile, package.json, .csproj, Dockerfile |
| Конфигурация | appsettings, .env.example, Helm values |
| Зависимости | lock-файлы, SBOM (в зрелых процессах) |
| Журнал code review | История решений и качества |
| Метрики кода | Покрытие, сложность, lint-отчёты |
В Waterfall и госконтрактах часть артефактов дублируется в формальных документах (описание программы по ГОСТ 19). В Agile живой код и тесты часто и есть документация реализации.
Стандарты и нормативные рамки
Конструирование регулируется набором процессов и практик.
ISO/IEC 12207 и ГОСТ Р ИСО/МЭК 12207
Международный стандарт ISO/IEC 12207 описывает процессы жизненного цикла ПО. Для конструирования важны группы:
- Процессы соглашения — требования, архитектура (вход для конструирования).
- Процессы проекта — планирование, контроль, управление конфигурацией.
- Технические процессы — в том числе реализация (implementation), интеграция, верификация.
Стандарт не диктует "писать на Java", но требует, чтобы реализация была прослеживаема — от требований к коду, версионирование, контроль изменений. В России адаптация — ГОСТ Р ИСО/МЭК 12207-2010 (упоминание в энциклопедии).
ГОСТ 34.601-90 (отечественный ЖЦ)
Для госконтрактов и классических ТЗ часто ссылаются на ГОСТ 34.601-90 "Автоматизированные системы. Стадии создания". Этапы включают обследование, техническое задание, эскизный и технический проект, рабочую документацию, ввод в действие и сопровождение. Конструирование в широком смысле попадает в блоки "Рабочая документация" и реализация по ТП — с формальными артефактами (описание программы, текст программы по ГОСТ 19). В Agile-продукте роль формальных документов частично берут на себя репозиторий, CI и OpenAPI.
Внешние и внутренние стандарты
| Вид | Источник | Примеры |
|---|---|---|
| Внешние | ISO, IEEE, отраслевые, вендоры | 12207, 25010, 29119, OWASP, coding guides IBM/Google |
| Внутренние | Организация или команда | Style guide, DoD, шаблон PR, регламент ADR, соглашения об именовании API |
Внутренние стандарты согласуют участников проекта — единые термины, ожидания от review, правила обработки изменений и рисков. В связке с внешними они задают "правила игры" для конструирования — от lint до обязательного покрытия новых веток.
IEEE / ISO для качества и тестов
- ISO/IEC/IEEE 29119 — процессы тестирования (связь конструирования с QA: основы тестирования).
- ISO/IEC 25010 — модель качества ПО (функциональность, сопровождаемость, надёжность…); подробный разбор — модель ISO/IEC 25010.
Корпоративные и отраслевые стандарты кодирования
- Coding standards — соглашения по стилю (PEP 8, Google Style Guide, внутренние guideline).
- Security — OWASP, CWE для безопасного кодирования.
- Отрасли — DO-178C (авионика), IEC 62304 (медизделия): формальные требования к traceability кода и тестов.
В энциклопедии практики стиля и качества собраны в Культуре кода; процессы SDLC — в Методологии.
Связь с методологиями
| Подход | Как выглядит конструирование |
|---|---|
| Waterfall | Большой блок "кодирование" после проектирования; изменения дороги |
| Инкремент / итерация | Повторяющиеся циклы "спроектировали кусок → закодировали → проверили" (модели ЖЦ) |
| Scrum | Конструирование — основная работа спринта; DoD включает код + тесты |
| XP | TDD, парное программирование, непрерывная интеграция во время конструирования |
| DevOps | Конструирование не заканчивается коммитом — артефакт проходит pipeline до production |
Выбор методологии — в главе про SDLC. Конструирование есть при любой методологии — меняется только ритм и формализация.
Типичные ошибки на стадии конструирования
- "Сначала код, потом подумаем" — без проектных границ нарастает связность, техдолг.
- "Код без тестов — норма" — стоимость исправления растёт к концу SDLC (кривая стоимости изменений в 7-03/1).
- "Стандарты для галочки" — lint и review не в CI, стиль плавает между модулями.
- Смешение стадий в голове — аналитик ждёт от разработчика ТЗ уровня контракта внутри спринта без участия команды.
Стоимость изменений и качество конструирования
Классическая кривая стоимости дефекта — ошибка, найденная на конструировании (unit-тест, review), обходится дешевле, чем на приёмке или в production. Отсюда практики стадии:
| Практика | Зачем на конструировании |
|---|---|
| Unit-тесты + TDD | Ловить регрессию до merge |
| Code review | Вторые глаза на границы модулей |
| Статический анализ | Стиль, уязвимости, мёртвый код |
| CI на каждый PR | Сборка + тесты = верификация |
| Definition of Done | "Готово" = код и тесты и документация API |
Подробнее о кривой — в 7-03/1; о DoD в Scrum — там же.
Пример Definition of Done (фрагмент)
- Код в main через PR с ≥1 approve.
- Покрытие новых веток unit-тестами (или обоснование в PR).
- OpenAPI обновлён для новых endpoint'ов.
- Нет blocker/critical от SonarQube.
- Задача задеплоена на staging и прошла smoke QA.
Рекомендую читать дальше в этом разделе
| Тема | Статья |
|---|---|
| Модульность, связность, сцепление, сложность | Связность и сцепление модулей |
| Инкремент, RAD, спираль, компонентная модель | Модели жизненного цикла |
| PERT, CPM, Planning Poker | Планирование конструирования |
| Языки программирования и проектирования | Языки конструирования |
| Тестирование при кодировании | Тестирование на стадии конструирования |
Общая карта раздела — в введении.