Вот вам задачка. Управленческая.
У заказчика есть система «а-ля черный ящик». Ну почти. Достоверно и полноценно никто не знает, как «оно» работает. Задача — сделать аналог. Актуальная кстати тема, с учетом блокировок всяких облачных SAP-ов. Гы-гы.
Вы сделали реверс-инженеринг. И описали формально что-то типа ТЗ. Формулы там какие-то. Таблицы. Справочники. Что бы можно было уже начать все кодить.
В итоге у вас на руках есть документ, страниц 20, описывающий работу черного ящика. Это отдельный этап работ. И вам бы хотелось бы его закрыть актом, прежде чем двигаться дальше.
Как действовать адекватно: сдать ТЗ, получить акт и что бы всем польза была?
У нас есть две крайности: «приемка не читая» и «формализм».
Вариант «приемка не читая» (а такое встречается, мало кто любит технические документы) — отметаем. Не интересено. Обе стороны не защищены.
Вариант «формализм»: «заказчик по договору должен принять — вот пусть и читает. Иначе дальше не сдвинемся. Без ТЗ — результат ХЗ» чуть лучше, но не намного. Могут уйти недели + это как-то… Км… Неклиентоориентированно.
Что проделываем? Все очень просто — покрываем ТЗ — тестами: создаем наборы входных и выходных данных. Показываем, что при расчетах по ТЗ результат получается аналогичный тому, что выдает «черный ящик».
Гарантирует ли это на 100% покрытие всех кейсов «черного ящика»? Увы, нет. Такую гарантию дать невозможно. Однако позволяет определить границы типовых сценариев. И запустить на них систему, решающую большинство задач. Кстати, на этом этапе в игру с удовольствием может включиться заказчик, и поподкидывать дополнительных тестовых сценариев. На моей практике был случай, когда после такой процедуры заказчик обнаруживал баги в «черном ящике». Т.е. ошибка в расчетах у него жила годами.
Хитрые же кейсы придется выявлять и докручивать в ходе эксплуатации. Без работы T&M, затрат на пуско-наладку не обойтись. И дай б-г «черный ящик» еще будет доступен до того, как успеют реализовать аналог.
У заказчика есть система «а-ля черный ящик». Ну почти. Достоверно и полноценно никто не знает, как «оно» работает. Задача — сделать аналог. Актуальная кстати тема, с учетом блокировок всяких облачных SAP-ов. Гы-гы.
Вы сделали реверс-инженеринг. И описали формально что-то типа ТЗ. Формулы там какие-то. Таблицы. Справочники. Что бы можно было уже начать все кодить.
В итоге у вас на руках есть документ, страниц 20, описывающий работу черного ящика. Это отдельный этап работ. И вам бы хотелось бы его закрыть актом, прежде чем двигаться дальше.
Как действовать адекватно: сдать ТЗ, получить акт и что бы всем польза была?
У нас есть две крайности: «приемка не читая» и «формализм».
Вариант «приемка не читая» (а такое встречается, мало кто любит технические документы) — отметаем. Не интересено. Обе стороны не защищены.
Вариант «формализм»: «заказчик по договору должен принять — вот пусть и читает. Иначе дальше не сдвинемся. Без ТЗ — результат ХЗ» чуть лучше, но не намного. Могут уйти недели + это как-то… Км… Неклиентоориентированно.
Что проделываем? Все очень просто — покрываем ТЗ — тестами: создаем наборы входных и выходных данных. Показываем, что при расчетах по ТЗ результат получается аналогичный тому, что выдает «черный ящик».
Гарантирует ли это на 100% покрытие всех кейсов «черного ящика»? Увы, нет. Такую гарантию дать невозможно. Однако позволяет определить границы типовых сценариев. И запустить на них систему, решающую большинство задач. Кстати, на этом этапе в игру с удовольствием может включиться заказчик, и поподкидывать дополнительных тестовых сценариев. На моей практике был случай, когда после такой процедуры заказчик обнаруживал баги в «черном ящике». Т.е. ошибка в расчетах у него жила годами.
Хитрые же кейсы придется выявлять и докручивать в ходе эксплуатации. Без работы T&M, затрат на пуско-наладку не обойтись. И дай б-г «черный ящик» еще будет доступен до того, как успеют реализовать аналог.