Большинство методик проектирования ПО, которые можно встретить в литературе, рассчитаны на разработку ПО "с нуля", под требования конкретного Заказчика. До начала разработки такого ПО ни Заказчик, ни разработчик не знают, что получится и как это будет работать.
Формально описанные требования в этом случае, действительно, необходимы, так как они формируют, собственно, задачи разработки. Требования описывают цель работы на языке понятным и Заказчику и разработчику до начала разработки.
Сравнить этот образ будущей программы возможно только с имеющимися аналогами и очень поверхностно, либо вообще нельзя сравнить. Зачастую, разрабатываемое ПО не имеет прямых аналогов, поэтому его и нужно разработать.
Следовательно, ни разработчик, ни Заказчик, не знают точно, что именно будет сделано и каких затрат потребует разработка. Ситуация напоминает обещание писателя за месяц написать роман, удовлетворяющий формальным требованиям издательства (количество авторских листов, жанр, общая схема сюжета, пожелания к образам главных героев). Когда через месяц писатель сдает работу, у издателя нет никаких формальных способов оценить литературные или коммерческие качества романа. Попытки сравнить с аналогами встречают классическое "я так вижу".
Это дает разработчику ПО свободу. Какими бы не были объемными функциональные требования, их всегда можно удовлетворить за разумное время, располагая разумными ресурсами. Соответственно, в литературе о проектах все пляски - вокруг времени и ресурсов. Сама по себе фиксация этих требований проблем не вызывает, если речь идет о разработке прикладного ПО.
Комментариев нет:
Отправить комментарий