Перейти к основному содержимому

Экономика производства ПО — итоги

Руководителю Аналитику Студенту

Кратко — что стоит унести из раздела "Экономика производства ПО". Если пункт кажется туманным — откройте указанную главу или оглавление.


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
SCMGit — инструмент; SCM — базовые линии, релизы, traceability3
СопровождениеБольшая доля TCO после акта; SLA и change request4
РВЖёсткие NFR, ранние динамические тесты, целевое железо5
ПриёмкаПМИ, протоколы, сертификация — не замена CI6
КомандаРоли и компетенции — фактор срока и риска7

Agile и формальные модели сосуществуют: заказчик по контракту спросит сколько стоит, как докажете качество и что сдаёте при приёмке — раздел учит отвечать языком стандартов.


Куда идти дальше

Полный маршрут — на странице о разделе.

Соседние темы: SDLC, требования, конструирование, внедрение ERP.


См. также

Другие статьи этого же раздела в боковом меню (как на странице "О разделе").