ГОСТ 34 и 19
В госзаказе, банках и на крупных предприятиях это рабочая реальность, а не архаика из прошлого века. Спрашивают, чтобы понять, сможешь ли ты писать документы в принятом там формате, не переучиваясь полгода.
Стержень: ГОСТ 34 описывает автоматизированную систему целиком и состав документов на каждой стадии, ГОСТ 19 - документацию на программное изделие. На практике их комбинируют, и это нормально.
// Формулировки: «какие разделы в техническом задании по ГОСТ?», «чем 34 отличается от 19?», «как совместить ГОСТ с бэклогом?»
Что регламентирует каждый комплекс
ГОСТ 34 смотрит на систему в целом, а не на одну лишь программу: в поле его зрения попадают люди, оргструктура, технические средства и регламенты работы. Он описывает стадии создания от формирования требований до сопровождения и говорит, какие документы появляются на каждой.
ГОСТ 19, он же единая система программной документации, спускается на уровень программного изделия: спецификация, описание программы, руководство оператора, руководство программиста.
Обычная практика - брать структуру технического задания из тридцать четвёртого, а руководства пользователя из девятнадцатого. Комплексы действуют параллельно и не заменяют друг друга, поэтому выбирать между ними не приходится.
// Отдельно стоит знать, что стандарт задаёт состав разделов, но не запрещает добавлять свои и не требует канцелярского языка. Убеждение, что по ГОСТ надо писать тяжеловесно, - фольклор, а не требование.
Разделы задания и что в них живёт
Содержательное ядро документа - раздел «Требования к системе». Он делится на требования к системе в целом, к функциям и задачам, к видам обеспечения. Именно здесь живёт то, ради чего документ вообще пишется, и именно сюда стоит смотреть, оценивая чужое задание.
Раздел «Порядок контроля и приёмки» не менее важен, хотя его читают реже. Он фиксирует виды испытаний, их участников и критерии, по которым принимается решение. Для исполнителя это прямая защита от бесконечной приёмки: перечень проверок ограничен документом, и добавить в него новую задним числом уже нельзя.
// Остальные разделы отвечают на другие вопросы, и это полезно держать в голове, чтобы не искать содержание не там. Основания объясняют, почему работа вообще начата. Состав и содержание работ - что делается и в какие сроки. Требования к документированию - какие документы будут на выходе.
Форма без содержания и как жить с бэклогом
Стандарт задаёт состав разделов, но не гарантирует их осмысленность, и это его главное ограничение. Классический результат - толстый том, где в разделе требований написано «система должна обеспечивать надёжное функционирование». Формально всё на месте, все подписи собраны, принять по этому нельзя ничего.
Второй частый вопрос - как совместить документ по стандарту с работой по спринтам. Смертельная ошибка здесь одна: держать два независимых описания. Они разъедутся за пару спринтов, и никто уже не сможет сказать, где правда, а сверять их вручную никто не будет.
// Работает подход «единый источник, разные представления». Требования живут в трекере с идентификаторами, атрибутами и связями, а документ нужной структуры формируется из них выгрузкой к вехам согласования. Команда работает привычно, заказчик получает документ в требуемой форме, и второго описания не появляется.
Как отвечать: «Мы работаем по спринтам, а заказчик требует ТЗ по ГОСТ. Как быть?»
Главное - не заводить два независимых описания. Они разойдутся за пару спринтов, и потом никто не скажет, где правда, а сверять их вручную не будет никто. Я держу единый источник: требования живут в трекере с идентификаторами, атрибутами и связями, а документ по структуре стандарта формируется из них выгрузкой к моменту согласования. Тогда команда работает привычным способом, а заказчик получает документ в нужной форме, и никакого двоемыслия не возникает. Отдельно слежу, чтобы форма не подменила содержание: разделы можно аккуратно заполнить и остаться с непроверяемыми формулировками, а по ним приёмка всё равно встанет - только уже на этапе, когда всё сделано.
Ответ решает реальный организационный конфликт конкретным приёмом и не забывает про качество формулировок - то, ради чего документ и существует.
На чём валятся
- −− Соблюдают форму без содержания: разделы на месте, требования непроверяемы.
- −− Ведут бэклог и документ независимо и получают гарантированный рассинхрон.
- −− Относят требование про отечественную СУБД (система управления базами данных) к функциональным вместо ограничений.
- −− Думают, что стандарт запрещает англицизмы или дополнение структуры своими разделами.
- −− Забывают, что в госзаказе задание входит в контракт и любая расплывчатость играет против исполнителя.
Проверьте себя
Пять вопросов из банка по этой подтеме. Всего их 13, остальные разбираются в тренажёре.
- Какой раздел ТЗ по ГОСТ 34 задаёт, что именно система должна делать?A)Основания для разработкиB)Требования к системеC)Порядок контроля и приёмкиD)Состав и содержание работ
показать ответ и разбор
+B)Требования к системе// разбор: Раздел требований — содержательное ядро документа: требования к системе в целом, к её функциям и задачам, к видам обеспечения. Соседние разделы отвечают за другое: основания объясняют, почему работа начата, порядок приёмки — как будут проверять, состав работ — что и в какие сроки делается.
- Что даёт раздел «Порядок контроля и приёмки» в ТЗ по ГОСТ?A)Список ответственных за разработку модулейB)Календарный график релизов системыC)Смету на проведение работD)Правила проверки: виды испытаний и критерии
показать ответ и разбор
+D)Правила проверки: виды испытаний и критерии// разбор: Раздел фиксирует, какими испытаниями подтверждается соответствие требованиям, кто участвует и по каким критериям принимается решение. Для исполнителя это защита от бесконечной приёмки: перечень проверок ограничен документом. Для заказчика — гарантия, что результат будет проверен по понятной процедуре, а не на глаз.
- Команда ведёт бэклог в трекере, а заказчик требует ТЗ по ГОСТ. Как совместить?A)Отказаться от трекера в пользу документаB)Собирать документ из требований, ведя единый источникC)Вести оба независимо и сверять раз в кварталD)Оформить бэклог как приложение к договору
показать ответ и разбор
+B)Собирать документ из требований, ведя единый источник// разбор: Смертельная ошибка — держать два независимых описания: они разъезжаются за пару спринтов, и никто не знает, где правда. Работает подход «единый источник, разные представления»: требования живут в трекере с атрибутами и связями, а документ по нужной структуре формируется выгрузкой к вехам согласования.
- Почему в госпроектах формулировки требований проверяют особенно придирчиво?A)Заказчик обычно менее опытен в техникеB)Стандарт запрещает использовать англицизмыC)ТЗ — часть контракта, и по нему принимают работыD)Документ обязательно публикуется в открытом доступе
показать ответ и разбор
+C)ТЗ — часть контракта, и по нему принимают работы// разбор: Техническое задание становится приложением к контракту, и приёмка идёт строго по нему. Расплывчатая формулировка играет против исполнителя: заказчик вправе трактовать её широко и не подписывать акт. Формулировка с числами и явной процедурой проверки защищает обе стороны и делает спор разрешимым.
- В ТЗ по ГОСТ попало требование «использовать СУБД из реестра отечественного ПО». Как это классифицировать?A)Как функциональное требование к системеB)Как пожелание, необязательное к исполнениюC)Как требование к производительности хранилищаD)Как внешнее ограничение проекта
показать ответ и разбор
+D)Как внешнее ограничение проекта// разбор: Это ограничение, наложенное регулированием: команда не выбирает СУБД по инженерным критериям, а работает внутри заданной рамки. Классификация не формальность — от неё зависит, что можно обсуждать. Ограничение не оптимизируют, его учитывают в архитектуре и в оценке сроков, а оспаривают только у источника.
дальше
Теорию прочитали. Навык ставится повторением
В Сеньорчике эта подтема идёт в ежедневных сессиях: движок возвращает её, пока ответы не станут уверенными, и ведёт прогресс отдельно по каждой подтеме. Теория внутри тоже бесплатна, лимит только на количество вопросов в день.