Раздел 13 — Техническое задание

До сих пор задачу давал преподаватель: условие варианта, примеры, таблица тестов. В работе условия нет — есть заказчик, который хочет «чтобы программа следила за процессами». Путь от этого желания до работающей программы и дальше называют жизненным циклом:

В российских стандартах (Единая система программной документации, ГОСТ 19.102-77) стадии называются иначе — техническое задание, эскизный проект, технический проект, рабочий проект, внедрение, — но порядок тот же, и первая стадия — ТЗ. Ошибка, найденная в ТЗ, стоит исправления абзаца текста. Та же ошибка, найденная после сдачи программы, стоит переделки кода, повторного тестирования и спора о том, кто виноват.

Техническое задание — документ, в котором заказчик и исполнитель письменно договорились, что программа должна делать и как проверить, что она это делает. Оно нужно всем:

• заказчику — получить именно то, что нужно, и иметь основание не принять не то;
• исполнителю — знать, когда работа закончена, и не делать лишнего;
• тестировщику — иметь список того, что проверять;
• тому, кто будет сопровождать программу через год, — понять, что было задумано.

Главное правило: ТЗ описывает, что делает программа, а не как она устроена. «Программа выводит список запущенных процессов с идентификатором и именем» — требование. «Программа вызывает CreateToolhelp32Snapshot и обходит список в цикле while» — решение исполнителя, ему место в проекте, а не в ТЗ. Если в ТЗ написано «как», исполнителю связывают руки, а заказчик берёт на себя ответственность за выбор, в котором не разбирается.

ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению» — часть ЕСПД. Он задаёт состав разделов; раздел, которому нечего сказать, всё равно пишут со словами «требования не предъявляются» — так видно, что о нём подумали, а не забыли.

Раздел 4.1 отвечает на вопрос «что программа делает» так, чтобы по нему можно было написать и программу, и тесты. Удобно идти по той же схеме, что и в модели задачи из раздела 1:

Каждое требование — отдельный пронумерованный пункт с глаголом «должна»: «4.1.3. Программа должна…». Номер нужен, чтобы на пункт можно было сослаться в проверке и в споре. Одно требование — одно проверяемое свойство: пункт «программа должна считать строки и слова и работать быстро» проверить целиком нельзя.

Коды завершения для системной утилиты — тоже требование: по ним другая программа (или скрипт) узнаёт, как всё прошло. Принято: 0 — успех, 1 — неверный запуск (нет аргументов), 2 и дальше — ошибки выполнения. В разделе 14 ваша программа будет получать код завершения дочернего процесса — именно этот.

Если программа читает или пишет файлы, обменивается сообщениями по каналу или сети, формат данных — такое же требование, как функция. Две программы, написанные разными людьми по одному ТЗ, должны понимать файлы друг друга.

Ограничения по размерам — не прихоть: из них исполнитель выберет вместимость массивов (разделы 8 и 10), а тестировщик — граничные тесты. «До 100 записей» проверяется файлами из 100 и 101 записи.

Требование, которое нельзя проверить, ничего не требует: исполнитель скажет, что выполнил, заказчик — что нет, и оба будут правы. Проверяемое требование говорит, при каких условиях и какой наблюдаемый результат должен получиться.

Слова-сигналы непроверяемости: «быстро», «удобно», «надёжно», «современный», «и т. д.», «по возможности», «при необходимости», «достаточный», «оптимальный». Встретили такое слово в своём ТЗ — замените числом, условием или перечнем.

Раздел 8 ТЗ — это та таблица тестов, которую вы составляли в каждой практической работе, только написанная до программы. Для каждого функционального требования — хотя бы одна проверка; для требования об ошибке — проверка, которая эту ошибку вызывает:

Если для требования не получается придумать проверку — значит, требование сформулировано плохо (пункт 06). Этот раздел полезно писать одновременно с разделом 4.1: он сразу показывает непроверяемые пункты. Работа принимается, когда все проверки раздела 8 пройдены — ни больше, ни меньше.

Сокращённое ТЗ на утилиту подсчёта строк, слов и символов — в объёме, который ожидается в практической работе №15. Разделы 4.6–4.7 и 6 — «не предъявляются».

Заметьте, чего в этом ТЗ нет: ни слова о ifstream, getline, массивах и функциях. Как считать — решит исполнитель. Зато есть определения «строки» и «слова»: без них две честные программы дадут разные числа на файле без перевода строки в конце — и обе будут правы.