Техническое задание на переписывание legacy-приложения на VB6 и VB.NET: структура, чек-лист и приёмка

Переписывание старой программы на VB6 или VB.NET почти всегда начинается с фразы «сделайте так же, только на современном стеке». Проблема в том, что «так же» нигде не записано. Правила расчётов живут в обработчиках кнопок, исключения для отдельных клиентов — в условиях, добавленных десять лет назад, а половину отчётов знает только главный бухгалтер. Техническое задание на переписывание нужно, чтобы превратить это знание в проверяемые требования до того, как начнётся разработка.

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

Ниже — структура ТЗ по разделам, приёмы инвентаризации VB-проектов, способ зафиксировать бизнес-правила тестами, требования к данным и интеграциям, критерии приёмки и чек-лист готовности документа. Если решение «переписывать или дорабатывать» ещё не принято, начните с аудита legacy-кодовой базы на VB.NET: его результаты станут основой для нескольких разделов ТЗ.

Чем ТЗ на переписывание отличается от ТЗ на новую систему?

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

• Обязательная инвентаризация. Перед требованиями идёт опись существующего: формы, отчёты, сценарии, справочники, внешние зависимости, интеграции. Без неё объём работ оценить невозможно.
• Требование совместимости. Новая система должна давать те же итоги на тех же данных. Это формулируется явно, с эталонными наборами и допустимыми расхождениями.
• Реестр отличий. Всё, что в новой системе работает иначе (убранные функции, исправленные ошибки, новый порядок согласований), перечисляется отдельным списком. Иначе на приёмке каждое отличие будет выглядеть как дефект.

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

Из каких разделов состоит ТЗ на переписывание legacy-приложения?

Структура ниже подходит для коммерческого проекта. Если заказчик работает по ГОСТ 34.602-2020, те же сведения раскладываются по его разделам, а инвентаризация и требования к совместимости добавляются как приложения.

Самые недооценённые разделы — бизнес-правила и данные. Именно в них прячется большая часть трудоёмкости, и именно они определяют, совпадут ли итоги новой системы со старой.

Как провести инвентаризацию форм, отчётов и сценариев?

Инвентаризация отвечает на вопрос «что именно мы переписываем». Для VB-проектов многое можно собрать прямо из файлов проекта, не дожидаясь интервью.

Файлы показывают, что есть в программе, но не говорят, что из этого нужно. Поэтому к каждой форме и отчёту добавляется частота использования и владелец. Если в программе нет журнала действий, добавьте простое логирование открытия форм и запуска отчётов на месяц до обследования — статистика быстро покажет, что треть функций никто не открывает.

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

Как извлечь бизнес-правила из старого кода и не потерять их?

Бизнес-правило в ТЗ должно быть записано так, чтобы его можно было проверить: условие, действие, пример с числами. Формулировка «скидка для постоянных клиентов» не годится; годится «если у клиента за последние 12 месяцев больше 10 оплаченных счетов, к сумме строки применяется скидка 5 %, округление до копеек после применения скидки».

Правила ищут в трёх местах: в обработчиках событий форм, в общих модулях и в базе (запросы, триггеры, процедуры). Особое внимание — к поведению, которое зависит от самого VB и легко теряется при переходе на другой язык или библиотеку:

• Округление. Функция Round в VB6 и Math.Round в .NET по умолчанию используют банковское округление: 2,5 превращается в 2, а 3,5 — в 4. Новая система на другом стеке может округлять «по-школьному», и итоги разойдутся на копейки.
• Тип Currency. В VB6 это число с фиксированной точкой и четырьмя знаками после запятой. Промежуточные расчёты в нём дают иные результаты, чем в типе с плавающей точкой.
• Неявные преобразования. Val, CDate и сравнение строк зависят от региональных настроек Windows и параметра Option Compare.
• Пустые значения. Различие между Null, пустой строкой и нулём в старом коде часто несёт смысл: «не заполнено» и «ноль» обрабатываются по-разному.

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

Правило П-14. Скидка постоянному клиенту
Источник: frmInvoice.frm, cmdSave_Click; модуль modPricing.bas, CalcDiscount
Условие:  оплаченных счетов клиента за 12 мес. > 10
Действие: сумма строки * 0.95
Округление: банковское, до 2 знаков, после применения скидки
Эталон:   кол-во 3, цена 833.50 -> 2375.48 (старая программа, 12.10.2026)
Статус:   повторить без изменений

Чтобы правила не остались только на бумаге, до начала разработки поведение старого кода закрепляют характеризационными тестами: они фиксируют то, что программа делает сейчас, даже если это выглядит странно. Как писать такие тесты для кода без швов, разобрано в статье о покрытии тестами legacy VB.NET. Если правило противоречит здравому смыслу, его не исправляют молча, а переносят в реестр отличий и согласуют с владельцем процесса.

Что записать в ТЗ о данных и миграции базы?

Данные переживают любую программу, поэтому раздел о них должен быть подробным. Минимальный состав:

• Источник и объём. СУБД и версия (Access, SQL Server, иногда файлы dbf), число таблиц, объём, рост за год, сколько лет истории переносить.
• Качество. Дубли справочников, записи-сироты, даты в текстовых полях, значения «на всякий случай» вроде клиента «ТЕСТ». Профилирование данных лучше сделать до ТЗ, а не во время миграции.
• Кодировки. Старые базы часто хранят текст в Windows-1251 в однобайтовых полях. Для новой системы нужен переход на Unicode, и это отдельная задача с проверкой.
• Правила переноса. Что переносится как есть, что преобразуется, что уходит в архив только для чтения.
• Репетиции миграции. Сколько пробных прогонов на копии боевой базы, как сверяются итоги (число записей, контрольные суммы, остатки на дату), кто подписывает результат.
• Сосуществование. Если старая и новая системы какое-то время работают на одной базе, в ТЗ фиксируют, кто владеет какими таблицами и как избежать конфликтующих изменений.

Отдельно стоит описать окно переключения: сколько часов допустим простой, в какой момент замораживаются изменения в старой системе и как выглядит откат, если миграция не сошлась.

Как описать интеграции, оборудование и внешние зависимости?

У VB-приложений зависимости часто неочевидны: программа может автоматизировать Excel через COM, печатать на этикеточный принтер, читать файлы из сетевой папки и обмениваться данными с учётной системой через COM-соединение. Для каждой зависимости в ТЗ нужна строка с ответами на четыре вопроса:

1. Что это и как используется: библиотека, компонент, система, устройство, формат файла.
2. В каких сценариях участвует и как часто.
3. Чем заменяется в новой системе: аналогом, API, генерацией файлов на сервере или отказом от функции.
4. Кто отвечает за вторую сторону интеграции и как её протестировать.

Типичные позиции: OCX-гриды и календари, автоматизация Word и Excel, Crystal Reports (варианты замены разобраны в статье о замене Crystal Reports), обмен с банком и учётной системой файлами, сканеры штрихкодов, весы и принтеры через COM-порт, вход по учётной записи Windows. Каждая из них может добавить к проекту недели, поэтому неучтённая зависимость — одна из главных причин срыва сроков.

Какие нефункциональные требования нужны при переписывании?

Удобный приём — формулировать их относительно старой системы, а не абстрактно. Пользователи сравнивают с тем, к чему привыкли.

• Производительность. Ключевые операции не медленнее, чем в старой программе: открытие журнала документов на 50 тысяч строк, проведение документа, формирование месячного отчёта. Замерьте их до начала работ и внесите цифры в ТЗ.
• Безопасность. Проверка прав на сервере, никаких учётных данных базы на рабочих местах, журнал изменений для денег и персональных данных. Уровень требований удобно задать ссылкой на OWASP ASVS.
• Платформа и поддержка. Целевая версия .NET с поддержкой на весь срок эксплуатации, поддерживаемые браузеры или версии Windows. Для сравнения: среда разработки VB6 давно не поддерживается, а среда выполнения работает в Windows по политике поддержки Microsoft с оговорками.
• Сопровождаемость. Документация, покрытие тестами ключевых правил, сборка и развёртывание без ручных шагов.
• Доступность. Если система используется в госсекторе или крупной компании, требования к доступности интерфейса лучше включить сразу, а не дописывать после запуска.

Как сформулировать критерии приёмки, чтобы новая система была не хуже старой?

Приёмка при переписывании — это сверка с эталоном. Хорошо сформулированный критерий проверяется без обсуждения: итог совпал или нет.

• Эталонные наборы. Реальные документы и периоды, на которых старая программа дала известный результат: месяц продаж, квартал зарплаты, годовой отчёт. Итоги новой системы на тех же данных должны совпасть до копейки или в оговорённых пределах.
• Сценарии. Каждый сценарий из инвентаризации проходится пользователем-владельцем от начала до конца, включая печатные формы и выгрузки.
• Параллельная работа. Для критичных модулей — период, когда операции дублируются в старой и новой системах, а расхождения разбираются ежедневно.
• Миграция. Число записей, остатки и контрольные суммы после переноса совпадают с источником.
• Реестр отличий. Всё, что работает иначе, совпадает с согласованным списком; новое отличие без согласования считается дефектом.

Критерии приёмки — ещё и основа для оценки: чем точнее они сформулированы, тем меньше в смете запаса на неопределённость. Как из инвентаризации и критериев получается бюджет, разобрано в статье о том, сколько стоит миграция legacy-приложения.

Как разбить переписывание на этапы в ТЗ?

Переписывать всё разом и включать новую систему в один день рискованно: требования меняются быстрее, чем идёт разработка, а ошибку негде откатить. Надёжнее переносить систему модулями, пока старая программа продолжает работать. Этот подход описан как шаблон «удушающего дерева» в каталоге архитектурных шаблонов Microsoft.

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

Типичные ошибки в ТЗ на переписывание

• «Сделать как в старой программе». Без описания, что именно делает старая программа, эта фраза не проверяется и на приёмке превращается в спор.
• Описывать формы, а не сценарии. Скриншоты всех окон дают объём документа, но не показывают, как работает процесс и что в нём важно.
• Забыть про логику в базе. Запросы Access, триггеры и процедуры остаются за кадром, и часть правил теряется.
• Нет эталонных данных. Без них совпадение итогов нечем доказать.
• Смешать переписывание с перестройкой процессов. Новые требования добавляются по ходу, и проект теряет границы. Улучшения лучше выпускать после переноса модуля.
• Не учесть, кто будет сопровождать результат. Если систему потом поддерживает подрядчик, требования к документации и передаче стоит прописать сразу; как это устроить, описано в статье об аутсорсинге поддержки legacy-приложения.

Чек-лист готовности ТЗ

Перед тем как отдавать документ на оценку, проверьте, что в нём есть:

1. цели, границы проекта и целевой стек;
2. таблица сценариев с частотой использования и владельцами;
3. перечень форм, отчётов, справочников и ролей со ссылкой на сценарии;
4. бизнес-правила в формате «условие — действие — пример» с эталонами;
5. описание правил округления, типов данных и обработки пустых значений;
6. схема данных, объёмы, результаты профилирования и правила миграции;
7. перечень интеграций и внешних зависимостей с вариантом замены каждой;
8. нефункциональные требования с замерами старой системы;
9. реестр отличий от старой программы, согласованный заказчиком;
10. этапы переноса и критерии приёмки для каждого модуля;
11. порядок внесения изменений в ТЗ, пока старая система продолжает развиваться.

Как это делают сегодня

Вопросы и ответы