Конструирование ПО — итоги
Доступ к данным — Основы БД, SQL, конфигурации. Карта — о разделе.
Кратко — что стоит унести из раздела "Конструирование ПО". Если пункт кажется туманным — откройте указанную главу или оглавление. Определения для самопроверки — в чек-листе.
FAQ — Часто задаваемые вопросы
Вопросы студентов и джунов на стыке "учебник SDLC" и реальной команды — где конструирование в спринте, зачем PERT, когда Waterfall. Здесь — практика и путаницы; формулировки для зачёта — в чек-листе.
Вопрос. Мы "просто пишем код" в Jira — зачем отдельно говорить про конструирование?
Ответ. Конструирование — это не только набор текста, а артефакты: код, unit-тесты, сборки, интеграция модулей. Без явной стадии легко забыть DoD, ревью и локальную верификацию. Подробнее здесь — глава 1.
Вопрос. Архитектор нарисовал диаграмму — это уже конструирование?
Ответ. Нет, это проектирование (вход). Конструирование начинается, когда решения воплощаются в исходниках, тестах и скриптах сборки. Подробнее здесь — глава 1.
Вопрос. В Scrum "нет фазы кодирования" — где тогда конструирование?
Ответ. Оно каждый спринт: инкремент = working software + тесты по DoD. Фаза не исчезает, она внутри итерации. Подробнее здесь — глава 1, Scrum.
Вопрос. Много файлов в репозитории — значит, модульность хорошая?
Ответ. Не обязательно: важны границы ответственности, связность внутри и слабое сцепление между модулями. "God package" из сотни файлов — не модульность. Подробнее здесь — глава 2.
Вопрос. Поменял одно поле DTO — упало пять сервисов. Что пошло не так?
Ответ. Высокое сцепление и connascence: изменение в одном месте тянет цепочку. Сигнал пересмотреть границы и контракты (OpenAPI, версии API). Подробнее здесь — глава 2.
Вопрос. Преподаватель требует Waterfall, в стажировке — Agile. Кто прав?
Ответ. Оба контекста: регуляторика и фиксированный scope → длинная фаза кодирования после проекта; продукт с обратной связью → инкременты. Универсального процесса нет. Подробнее здесь — глава 3.
Вопрос. V-модель — это то же, что unit-тесты в CI?
Ответ. V-модель — идея парности: уровень кода ↔ unit-тесты, интеграция ↔ integration tests. CI автоматизирует правую "ногу" V на практике. Подробнее здесь — глава 3.
Вопрос. RAD дали на хакатоне — можно так же в банке?
Ответ. RAD ускоряет прототип UI/CRUD, но без плана "закалки" прототип станет продом с дырами. В банке нужны NFR, аудит, тесты — иначе антипаттерн. Подробнее здесь — глава 3.
Вопрос. Критический путь в Gantt "красный" — что делать команде разработки?
Ответ. Задачи на критическом пути без резерва (float = 0) — любая задержка бьёт по сроку релиза. Приоритет ресурсов, снятие блокеров, не распылять людей с CP. Подробнее здесь — глава 4.
Вопрос. PERT дал 6 месяцев, менеджер обещал 3 — кому верить?
Ответ. PERT с O/M/P — диапазон, не wishful thinking. Если P (пессимист) игнорируют, риск срыва на интеграции. Обсудите допущения и резерв. Подробнее здесь — глава 4.
Вопрос. Planning Poker: все сказали "8", один "1" — давить на единицу?
Ответ. Нет — обсудите расхождение: разное понимание scope или рисков. Poker для выявления неопределённости, не голосования большинством. Подробнее здесь — глава 4.
Вопрос. OpenAPI "потом допишем" — можно начать код?
Ответ. Можно параллельно, но без контракта растёт рассинхрон frontend/backend. Минимум — стабильные пути, схемы ошибок, версионирование. Подробнее здесь — глава 5.
Вопрос. Зачем DSL, если есть Python?
Ответ. DSL сжимает доменный язык (правила, конфиги, пайплайны). Избыточен для разовой задачи; полезен, когда правила пишут не только программисты. Подробнее здесь — глава 5.
Вопрос. TDD "не успеваем" — отменить на проекте?
Ответ. TDD — один из способов локальной верификации на конструировании. Без тестов скорость кажется выше, но стоимость дефектов растёт на интеграции. Компромисс — критичные модули с TDD, остальное — тесты после. Подробнее здесь — глава 5.
Вопрос. Цикломатическая сложность — это только для линтера?
Ответ. Конструктору она показывает, где много веток и нужны unit-тесты по путям. Связь с white-box тестированием и рефакторингом. Подробнее здесь — глава 2, культура кода.
Вопрос. CBSE — купили готовый компонент, интеграция "на вечер"?
Ответ. Нужны адаптеры, контрактные тесты, учёт лицензий и версий. COTS экономит время только при явных границах интеграции. Подробнее здесь — глава 3.
Вопрос. Спираль Боэма — это Agile?
Ответ. Спираль — про управление рисками прототипами и витками; Agile — про частую поставку ценности. Пересекаются, но не синонимы. Подробнее здесь — глава 3.
Вопрос. WBS построили, но сроки всё равно плывут — почему?
Ответ. WBS без зависимостей, ресурсов и CP — только список работ. Добавьте Gantt/CPM, резервы, учёт параллелизма команды. Подробнее здесь — глава 4.
Вопрос. "20–30 строк на unit-тест" — жёсткое правило?
Ответ. Ориентир на локальную проверку одного поведения; длинный тест часто проверяет слишком много и ломается непонятно почему. Подробнее здесь — глава 6.
Вопрос. Связность "случайная" — как распознать в своём пакете?
Ответ. Файлы в папке не связаны одной задачей ("utils", "helpers" на всё). Признак — изменения в одном файле не требуют правок соседей по смыслу. Подробнее здесь — глава 2.
Вопрос. ISO 12207 — только для госконтракта?
Ответ. Это справочник процессов ЖЦ; в Agile берут идеи прослеживаемости и интеграции, не обязательно всю бюрократию. Подробнее здесь — глава 1.
Вопрос. Инкремент сдали, но регресс на старом функционале — кто виноват?
Ответ. Часто слабая интеграция и регресс на стадии конструирования: нужны CI, контрактные и integration-тесты между инкрементами. Подробнее здесь — глава 6, тестирование.
Вопрос. RUP — "устаревший Waterfall"?
Ответ. RUP — итеративный фреймворк с фазами; массовое конструирование — на стадии Construction. Не линейный каскад одним блоком. Подробнее здесь — глава 3.
Вопрос. Оценка в человеко-часах vs story points — что ставить в план конструирования?
Ответ. Points — для скорости команды внутри спринта; часы/CPM — для календарного плана релиза. Смешивайте осознанно, не переводите points в рубли линейно. Подробнее здесь — глава 4, команда.
Вопрос. Конфиг в YAML разросся — это уже конструирование или инфраструктура?
Ответ. Конфигурационные языки — часть артефактов конструирования (вместе с кодом и сборкой). Граница с DevOps — там, где начинается эксплуатация сред. Подробнее здесь — глава 5.
Вопрос. Myers: "цель теста — найти дефекты" — значит, QA виноваты, если баг в проде?
Ответ. Нет — качество строится на конструировании (unit, ревью), системное тестирование дополняет. Баг в проде — сигнал улучшить процесс на всех уровнях V. Подробнее здесь — глава 6.
FAQ — Поисковые запросы
Краткие ответы на формулировки, которые часто вводят в Google и Yandex.
Вопрос. Что такое конструирование ПО в жизненном цикле?
Ответ. Стадия SDLC, где проект становится кодом, модулями, тестами и сборками; в Agile — каждый спринт. Подробнее здесь — глава 1.
Вопрос. SDLC жизненный цикл разработки ПО — этапы.
Ответ. Требования → проектирование → конструирование → тестирование → внедрение → сопровождение; в Agile этапы перекрываются. Подробнее здесь — глава 1, методология.
Вопрос. Waterfall модель — что это и когда применяют?
Ответ. Каскад: фазы последовательно, изменения формальны. Уместна при регуляторике и фиксированном scope. Подробнее здесь — модели ЖЦ.
Вопрос. V-модель тестирования — суть.
Ответ. Каждому уровню разработки соответствует уровень тестов: код ↔ unit, интеграция ↔ integration. Подробнее здесь — глава 3.
Вопрос. Связность и сцепление модулей (cohesion coupling) — простыми словами.
Ответ. Связность — насколько элементы модуля про одну задачу; сцепление — насколько модули зависят друг от друга. Цель: высокая связность, низкое сцепление. Подробнее здесь — глава 2.
Вопрос. Критический путь CPM — как рассчитать?
Ответ. Цепочка задач с нулевым резервом (float); задержка любой из них сдвигает срок проекта. Подробнее здесь — планирование.
Вопрос. PERT формула расчёта времени TE = (O+4M+P)/6.
Ответ. Оптимист O, наиболее вероят M, пессимист P — ожидаемое время и разброс для рискованных задач. Подробнее здесь — глава 4.
Вопрос. Planning Poker — что это в Agile?
Ответ. Оценка задач в story points картами; расхождения обсуждают, а не усредняют молча. Подробнее здесь — глава 4, Scrum.
Вопрос. Инкрементальная модель разработки ПО.
Ответ. Поставка порциями работающих инкрементов; каждый добавляет функции к предыдущему. Подробнее здесь — глава 3.
Вопрос. Спиральная модель Boehm — фазы витка.
Ответ. Планирование → риски → прототип/разработка → оценка; следующий виток с новым уровнем детализации. Подробнее здесь — глава 3.
Вопрос. RAD rapid application development — когда уместен?
Ответ. Быстрые прототипы UI/CRUD при неясных требованиях; нужен план закалки перед prod. Подробнее здесь — глава 3.
Вопрос. ISO/IEC 12207 — что описывает?
Ответ. Процессы ЖЦ ПО: реализация, интеграция, верификация — справочник для контрактов и CMMI. Подробнее здесь — глава 1.
Вопрос. Модульность в программировании — зачем нужна?
Ответ. Изолировать изменения, упростить тесты и параллельную работу команды через чёткие границы. Подробнее здесь — глава 2.
Вопрос. Connascence в коде — что это?
Ответ. "Родственная связь": изменение в одном месте тянет правки где-то ещё — сигнал пересмотреть границы модулей. Подробнее здесь — глава 2.
Вопрос. TDD test driven development — как связан с конструированием?
Ответ. Тест → минимальный код → рефакторинг на этапе локальной верификации до интеграции. Подробнее здесь — глава 5.
Вопрос. OpenAPI Swagger — зачем на этапе разработки backend?
Ответ. Контракт API для frontend, тестов и генерации клиентов; снижает рассинхрон. Подробнее здесь — глава 5.
Вопрос. DSL domain specific language — примеры.
Ответ. SQL, regex, Terraform, правила бизнеса — язык под узкую задачу, не замена Python/Java. Подробнее здесь — глава 5.
Вопрос. WBS структура декомпозиции работ — что это?
Ответ. Иерархия задач проекта до листьев с оценкой; основа для Gantt и сметы. Подробнее здесь — глава 4.
Вопрос. RUP Rational Unified Process — стадии.
Ответ. Inception, Elaboration, Construction, Transition; массовое кодирование — на Construction. Подробнее здесь — глава 3.
Вопрос. CBSE component-based software engineering.
Ответ. Сборка из готовых компонентов (COTS) + адаптеры и контрактные тесты. Подробнее здесь — глава 3.
Вопрос. Чем итерация отличается от инкремента?
Ответ. Итерация — цикл работ; инкремент — добавленная работающая часть продукта. В Scrum спринт — итерация, результат — инкремент. Подробнее здесь — глава 3.
Вопрос. SWEBOK Software Engineering Body of Knowledge.
Ответ. Свод знаний инженерии ПО; конструирование — одна из областей вместе с тестированием и конфигурацией. Подробнее здесь — глава 1.
Что запомнить
Краткое резюме. Подробности, примеры и диаграммы — в статьях Конструирование ПО — понятие, жизненный цикл, стандарты–Тестирование на стадии конструирования; самопроверка — в чек-листе.
Конструирование — стадия SDLC, на которой проект превращается в исходный код, модули, тесты и сборки. Она связана с проектированием (вход) и тестированием/внедрением (выход), но в Agile выполняется итеративно, а не одним блоком.
| Тема | Главная мысль |
|---|---|
| Место в ЖЦ | Реализация + локальная верификация; артефакты: код, unit-тесты, скрипты сборки |
| SWEBOK / 12207 | Прослеживаемость, процессы реализации и интеграции |
| Модульность | Высокая связность внутри, низкое сцепление между модулями |
| Connascence | Что ещё придётся менять вместе — сигнал для границ |
| Модели ЖЦ | Waterfall — линейно; инкремент — порциями; RAD — прототипы; спираль — риски; CBSE — компоненты |
| V-модель | Уровень кода ↔ unit-тесты; интеграция ↔ integration tests |
| Планирование | WBS → Gantt; CPM — критический путь; PERT — TE = (O+4M+P)/6; Poker — points + декомпозиция |
| Языки | Программирование + проектирование + контракты + конфиг + DSL + конфигурационный/toolkit |
| Тестирование на коде | Myers: цель — найти дефекты; unit/integration; 20–30 строк — локальная проверка |
| Шкалы СС / СЦ | Связность 0–10, сцепление 1–9 |
Формулы для запоминания
| Метод | Формула |
|---|---|
| PERT (ожидание) | TE = (O + 4M + P) / 6 |
| PERT (разброс) | σ = (P − O) / 6 |
| Float (упрощённо) | LS − ES (у критической задачи = 0) |
Модели и конструирование — одной строкой
- Waterfall / V — длинная фаза кодирования после проекта; тесты "парные" по уровням.
- Инкремент / Scrum — код порциями; нужны CI, DoD и рефакторинг между инкрементами.
- RAD — быстрый UI и CRUD; обязателен план "закалки" прототипа.
- Spiral — прототипы на рисках, затем production code.
- CBSE — интеграция COTS + адаптеры + контрактные тесты.
На качество конструирования влияют культура кода, тестирование и методология — они не заменяют друг друга.
Универсального процесса нет — выбор модели и глубины планирования опирается на контекст (регуляторика, неопределённость, размер команды) — см. Stacey и Cynefin в SDLC.
Куда идти дальше
Полный маршрут — на странице о разделе.
Проверьте себя: Чек-лист самопроверки.