Экономика производства ПО — итоги
Кратко — что стоит унести из раздела "Экономика производства ПО". Если пункт кажется туманным — откройте указанную главу или оглавление.
FAQ — Часто задаваемые вопросы
Вопросы на стыке учебника и индустрии: зачем COCOMO при Scrum, что сдавать на приёмке, почему Git — это SCM. Здесь — практика заказной разработки; формулы и определения — в главах раздела.
Вопрос. У нас Scrum — зачем студенту COCOMO II?
Ответ. Story points не переводятся в контракт и тендер без истории проекта. COCOMO даёт каркас оценки всего этапа в человеко-месяцах до первого спринта. Подробнее здесь — глава 1.
Вопрос. Заказчик просит "точную смету" до ТЗ — что ответить?
Ответ. Дайте ROM с диапазоном и условиями уточнения после обследования; одна цифра без scope — ложная точность. Подробнее здесь — глава 1, оценка.
Вопрос. KSLOC посчитали с автогенерацией и тестами — COCOMO "врёт".
Ответ. В модель идёт поставляемый исходный код, без мусора и часто без автогенерации — иначе размер завышен и оценка бессмысленна. Подробнее здесь — глава 1.
Вопрос. EAF в COCOMO "на глаз" поставили 1.0 — нормально?
Ответ. 1.0 — редкий "идеальный" проект. Пропуск факторов риска (опыт, сложность, процессы) недооценивает трудоёмкость. Пройдите шкалы осознанно. Подробнее здесь — глава 1.
Вопрос. ISO 25010 — "бумага для сертификатора", разработчику зачем?
Ответ. Это язык NFR: производительность, надёжность, сопровождаемость — то, что ломается в проде, если не формулировать заранее. Подробнее здесь — глава 2.
Вопрос. "Быстрый и безопасный" в одном ТЗ без метрик — как разрулить?
Ответ. Разложите по характеристикам 25010: измеримые пороги (p95, RTO, покрытие). Конфликт станет явным для архитектуры. Подробнее здесь — глава 2, NFR.
Вопрос. Git есть — значит, SCM настроен?
Ответ. SCM шире Git: базовые линии, релизы, traceability требование→коммит→сборка. Без тегов и политики веток это только история файлов. Подробнее здесь — глава 3.
Вопрос. На приёмку принесли "коммит abc123" — достаточно?
Ответ. Нужен идентифицируемый релиз: тег, manifest, checksum, запись в журнале конфигурации. Иначе невозможно воспроизвести поставку. Подробнее здесь — глава 3, глава 6.
Вопрос. Hotfix прямо в prod, потом cherry-pick "когда-нибудь" — риск?
Ответ. Расхождение контуров — классический config drift; следующий релиз откатит hotfix. Дисциплина SCM обязательна даже под давлением. Подробнее здесь — глава 3.
Вопрос. Проект сдали — команда распалась. Кто будет чинить?
Ответ. Без плана сопровождения (L2/L3, SLA, база знаний) стоимость владения взлетает. Сопровождение закладывают до акта, не "потом". Подробнее здесь — глава 4.
Вопрос. TCO сопровождения не закладывали — только разработку.
Ответ. Для заказных систем 60–80% TCO часто после сдачи: исправления, адаптация к законам, инфраструктура. Подробнее здесь — глава 4, ERP.
Вопрос. Заказчик требует "исправление бесплатно год" без лимита часов.
Ответ. Разделите дефекты приёмки и эволюцию; зафиксируйте SLA, классы инцидентов, change request на новые функции. Подробнее здесь — глава 4.
Вопрос. Система реального времени — можно тестировать только "когда соберём железо"?
Ответ. Нужны simulation, HIL, нагрузочные профили заранее; откладывание динамических тестов до конца — типичный срыв сроков РВ. Подробнее здесь — глава 5.
Вопрос. Дедлайн 10 ms, а профилировали на ноутбуке.
Ответ. NFR РВ привязаны к целевой платформе и worst-case; лабораторные замеры без запаса не проходят приёмку. Подробнее здесь — глава 5.
Вопрос. ПМИ по ГОСТ — кто пишет, если команда "Agile"?
Ответ. Для госсектора ПМИ — часть пакета приёмки; user stories и DoD должны трассироваться к сценариям испытаний. Подробнее здесь — глава 6, техписьмо.
Вопрос. "Потыкали неделю" вместо формального UAT — примут систему?
Ответ. На формальной приёмке нужны протоколы, подписи, traceability к требованиям. Неформальная проверка не заменяет испытания по контракту. Подробнее здесь — глава 6.
Вопрос. Сертификация FSTEC/ФСТЭК — это после разработки "галочка"?
Ответ. Требования безопасности закладывают в архитектуру и SCM с начала; "досертифицировать" готовый продукт часто дороже переписать. Подробнее здесь — глава 6.
Вопрос. CMMI level 3 требуют в тендере — что реально проверят?
Ответ. Наличие повторяемых процессов: оценки, ревью, управление конфигурацией, риски — не только папка с политиками. Подробнее здесь — SDLC, глава 7.
Вопрос. В команде один "универсал" на всё — как оценить квалификацию для контракта?
Ответ. Риск bus factor и некомпетентности на приёмке; матрица ролей (architect, QA, ops) и подтверждённые компетенции — часть экономики проекта. Подробнее здесь — глава 7.
Вопрос. Аутстафф дешевле штат — экономия?
Ответ. Меньше прямых затрат, но выше координация, текучка, потеря знаний — в COCOMO это факторы среды. Считайте полную стоимость. Подробнее здесь — глава 1, глава 7.
Вопрос. Reuse чужого модуля без документации — сэкономили?
Ответ. Экономия на старте, долг на интеграции и сопровождении; без контрактных тестов reuse превращается в скрытый риск. Подробнее здесь — компоненты, глава 4.
Вопрос. Change request на +30% scope — пересчитывать COCOMO?
Ответ. Да: размер и факторы изменились — нужна переоценка и допсоглашение, не "доделаем в те же сроки". Подробнее здесь — глава 1.
Вопрос. Качество "и так видно" — зачем модели, если есть CI?
Ответ. CI ловит дефекты кода; 25010 и приёмка — про атрибуты системы (безопасность, удобство эксплуатации), которые unit-тест не измерит. Подробнее здесь — глава 2, тестирование.
Вопрос. Студент: "экономика ПО — не про код", иду только во frontend.
Ответ. Любая фича упирается в оценку, NFR, приёмку и сопровождение — без этого карьера упирается в потолок middle. Раздел связывает код с контрактом. Подробнее здесь — оглавление.
Вопрос. ERP и заказная разработка — одна экономика?
Ответ. Пересекаются TCO, приёмка, сопровождение; ERP добавляет fit-gap и организационные риски. Смотрите оба раздела в связке. Подробнее здесь — ERP, глава 4.
Вопрос. Где в разделе связь с конструированием и тестами?
Ответ. Производственная часть курса — это код, SCM, динамические испытания в связке с конструированием и тестированием. Подробнее здесь — оглавление.
FAQ — Поисковые запросы
Краткие ответы на формулировки, которые часто вводят в Google и Yandex.
Вопрос. COCOMO модель — что это и для чего?
Ответ. Параметрическая оценка трудоёмкости и срока по размеру кода (KSLOC) и факторам проекта; для тендеров и этапов до velocity. Подробнее здесь — COCOMO II.
Вопрос. COCOMO II расчёт — какие входные данные?
Ответ. Размер (KSLOC или FP), режим (organic/semi-detached/embedded), факторы EAF (опыт, сложность, процессы). Подробнее здесь — глава 1.
Вопрос. Человеко-месяц (person-month) — что значит?
Ответ. Абстрактная единица труда: один специалист полный месяц; 5 PM = пять человек месяц или один человек пять месяцев. Подробнее здесь — глава 1.
Вопрос. KSLOC — как считать тысячи строк кода?
Ответ. Поставляемый исходный код без пустых строк; без автогенерации, иначе модель врёт. Подробнее здесь — глава 1.
Вопрос. ISO 25010 качество ПО — характеристики модели.
Ответ. Функциональность, производительность, надёжность, удобство, сопровождаемость и др. — язык NFR и приёмки. Подробнее здесь — ISO 25010.
Вопрос. NFR нефункциональные требования — примеры.
Ответ. Время отклика, RTO, одновременные пользователи, аудит, локализация — то, что не "кнопка X", а как система ведёт себя. Подробнее здесь — глава 2.
Вопрос. SCM software configuration management — что входит?
Ответ. Идентификация версий, базовые линии, релизы, traceability требование→код→сборка. Git — инструмент, не весь SCM. Подробнее здесь — управление конфигурацией.
Вопрос. TCO total cost of ownership программного продукта.
Ответ. Разработка + внедрение + годы сопровождения, инфраструктура, обучение; не только лицензия. Подробнее здесь — сопровождение, ERP TCO.
Вопрос. Сопровождение программного обеспечения — что входит?
Ответ. Исправление дефектов, адаптация к законам, мелкая эволюция, SLA, база знаний — после акта приёмки. Подробнее здесь — глава 4.
Вопрос. Приёмка программного продукта по ГОСТ — этапы.
Ответ. ПМИ, протоколы испытаний, traceability к ТЗ, подписи; formal UAT, не "потыкали неделю". Подробнее здесь — сертификация и приёмка.
Вопрос. ПМИ программа и методика испытаний — что писать?
Ответ. Сценарии, данные, ожидаемые результаты, критерии pass/fail, связь с требованиями. Подробнее здесь — глава 6, техписьмо.
Вопрос. CMMI что это и levels 1–5?
Ответ. Модель зрелости процессов; level 3 — определённые повторяемые практики (оценки, SCM, ревью). Подробнее здесь — SDLC, глава 7.
Вопрос. Заказная разработка ПО — чем отличается от продукта?
Ответ. Контракт, фиксированные требования/приёмка, формальные оценки и акт сдачи; продукт — непрерывный roadmap. Подробнее здесь — оглавление.
Вопрос. Как оценить стоимость разработки ПО с нуля?
Ответ. ROM → обследование → COCOMO/экспертная/FP; story points — после истории команды. Подробнее здесь — глава 1, оценка.
Вопрос. Story points vs человеко-часы — переводить ли?
Ответ. Points — относительная сложность для velocity команды; в часы для контракта переводят через историю, не "1 point = 8 hours" навсегда. Подробнее здесь — глава 1, Scrum.
Вопрос. Change request оценка допработ — как считать?
Ответ. Пересмотр размера и факторов (COCOMO или WBS), допсоглашение; не "втиснем бесплатно". Подробнее здесь — глава 1.
Вопрос. Система реального времени (РВ) — особенности разработки.
Ответ. Жёсткие дедлайны, worst-case, ранние HIL/нагрузочные тесты на целевом железе. Подробнее здесь — заказные системы РВ.
Вопрос. EAF effort adjustment factor COCOMO.
Ответ. Множители среды: опыт, сложность, инструменты, качество процессов — удорожают или удешевляют базовую оценку. Подробнее здесь — глава 1.
Вопрос. Параметрическая оценка проекта — виды.
Ответ. COCOMO, Function Points, аналогии по прошлым проектам — вход измеримый (размер, сложность). Подробнее здесь — глава 1.
Вопрос. Bus factor команды — что это?
Ответ. Сколько людей могут "выпасть", прежде чем проект встанет; один эксперт на всё — риск для контракта. Подробнее здесь — квалификация команды.
Вопрос. Конфигурационная единица CI в CM — не Continuous Integration.
Ответ. Configuration Item — элемент под версионным контролем (модуль, документ, сборка). Подробнее здесь — глава 3.
Вопрос. Сопровождение vs разработка — доля в бюджете.
Ответ. На горизонте 5–10 лет сопровождение часто больше первоначальной разработки; TCO надо считать заранее. Подробнее здесь — глава 4.
Вопрос. Сертификация программного обеспечения ФСТЭК — когда нужна?
Ответ. Для систем в контуре гос/КИИ с требованиями по классу защиты; закладывают в архитектуру с начала. Подробнее здесь — глава 6.
Что запомнить
Раздел собирает университетский курс в маршрут энциклопедии: от оценки и качества на проектировании до производства, сопровождения и приёмки.
| Блок | Главная мысль | Глава |
|---|---|---|
| Оценка | COCOMO II — параметрический прогноз до velocity; KSLOC + факторы среды | 1 |
| Качество | ISO/IEC 25010 — язык NFR и приёмки по атрибутам | 2 |
| SCM | Git — инструмент; SCM — базовые линии, релизы, traceability | 3 |
| Сопровождение | Большая доля TCO после акта; SLA и change request | 4 |
| РВ | Жёсткие NFR, ранние динамические тесты, целевое железо | 5 |
| Приёмка | ПМИ, протоколы, сертификация — не замена CI | 6 |
| Команда | Роли и компетенции — фактор срока и риска | 7 |
Agile и формальные модели сосуществуют: заказчик по контракту спросит сколько стоит, как докажете качество и что сдаёте при приёмке — раздел учит отвечать языком стандартов.
Куда идти дальше
Полный маршрут — на странице о разделе.
Соседние темы: SDLC, требования, конструирование, внедрение ERP.
См. также
Другие статьи этого же раздела в боковом меню (как на странице "О разделе"). На совещании вы слышите — эта фича 8 story points. Это работает внутри команды, когда все знают прошлые спринты. Восемь характеристик качества ПО — что писать в ТЗ, как проверять на приёмке и почему «без багов» мало. SCM простым языком: конфигурационные единицы, baseline, контроль изменений и связь с Git, CI/CD и ГОСТ-документацией. Что происходит с заказным ПО после акта приёмки: виды сопровождения, SLA, экономика и типичные ошибки — простым языком. Что такое системы реального времени, чем hard RT отличается от веба, как формулировать требования и тестировать на стенде — для новичка. Испытания, удостоверение качества и сертификация — простым языком: ПМИ, акт приёмки, ФСТЭК и что закладывать в смету. Какие компетенции нужны PM, архитектору, аналитику, разработчику и QA на заказном проекте — и как это влияет на оценку COCOMO.Модель COCOMO II — прогноз трудоёмкости и стоимости
Модель качества ISO/IEC 25010
Управление конфигурацией программных комплексов
Сопровождение программных комплексов
Заказные системы реального времени
Сертификация и приёмка заказных программных продуктов
Квалификация команды для заказной разработки