Конструирование ПО — понятие, жизненный цикл, стандарты
Конструирование ПО — от требований к коду
В разговорной речи «разработка» часто означает всё сразу: идея, ТЗ, код, тесты, деплой. В инженерной дисциплине полезнее различать стадии жизненного цикла (SDLC — Software Development Life Cycle, жизненный цикл разработки ПО): на каждой — свои цели, артефакты и критерии «готово».
Если вы новичок — где вы в этой цепочке
| Вопрос | Стадия |
|---|---|
| «Что должна делать система?» | Требования |
| «Из каких частей она состоит?» | Проектирование |
| «Как это написано на Java/Python и собрано?» | Конструирование ← вы здесь, когда пишете код |
| «Работает ли целиком для пользователя?» | Системное тестирование |
| «Как выкатить на сервер?» | Внедрение |
Конструирование программного обеспечения (англ. software construction) — это стадия, на которой:
- детализируют проектные решения до уровня исходного кода и модулей;
- пишут, интегрируют и собирают программу;
- создают локальные тесты, документируют API, настраивают сборку;
- следят за стилем, модульностью и техническим долгом на уровне кода.
Проще: проектирование отвечает на вопрос «как устроена система», конструирование — «как это закодировано и собрано», системное тестирование — «работает ли продукт целиком по требованиям».
На стадии конструирования особенно важны две проверки из 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. Речь о инженерной реализации ПО.
Место конструирования в жизненном цикле
Обобщённая модель 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 (упоминание в энциклопедии).
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 | Планирование конструирования |
| Языки программирования и проектирования | Языки конструирования |
Общая карта раздела — в введении.
См. также
Другие статьи этого же раздела в боковом меню (как на странице «О разделе»). Модульность программной системы: определение связности (cohesion) и сцепления (coupling), классические типы, примеры и метрики сложности. Классический, инкрементный, RAD, спиральный и компонентно-ориентированный подходы — как они влияют на стадию конструирования ПО. Планирование производства компонентов: диаграмма Ганта, критический путь, PERT, Planning Poker и связь с тестированием. Языки программирования, проектирования, спецификации и конфигурации на стадии конструирования ПО — роли, примеры, выбор. Краткие итоги раздела «Конструирование ПО». Вопросы для закрепления раздела «Конструирование ПО» с отсылками к статьям энциклопедии.Связность и сцепление модулей
Модели жизненного цикла для конструирования
Планирование конструирования — PERT, CPM, оценки
Языки конструирования программных систем
Итоги — конструирование ПО
Чек-лист самопроверки — конструирование ПО