Все бы хорошо, и водопад -- самое правильное, но проблемка одна есть.
Вот в этом она:
- хорошо почитать;
- хорошо понять.
Дело в том, что в 80 случаях из 100 (а то и в 95 из 100):
- хорошо почитать нечего, потому что предметная область толком не описана или описана так, что сам черт ногу сломит (см., например, нормативно-правовую базу для госструктур);
- или предметная область описана в расчете на неавтоматизированные процессы, то есть все так и так придется переделывать с нуля;
- хорошо понять тоже сложно, поскольку у заказчика НЕТ людей, хорошо понимающих, чего они на самом деле хотят.
Проблемка усугубляется еще и тем, что заказчик во многих случаях начинает понимать, что ему надо было с самого начала, только после того, как увидит уже работающую систему :-(
И есть еще одна неприятная штука. Вот этот цикл:
- формируются требования к софту
- формируются полные требования к софту
- формируются ваще офигенно детальные требования к софту, по которому написать его может даже макака
- это отливается в граните, полируется и фиксируется навечно в египетских пирамидах документации, с печатями и росписями кровью всех участников
- после чего начинается разработка программы, которая должна вот все это учитывать. В идеале она должна учитывать еще много всех corner cases, но это зависит от ступени упоротости тех, кто писал спецификации.
- после разработки кода, который полностью отвечает требованиями в документации (тут могут быть приемочные тесты человеками, автоматические тесты с реальными данными, автоматические тесты с псевдослучайными данными, нагрузовныет тесты - ну все как у людей короч) - наступает фаза сдачи проекта
- проект принимается или чинится, если найдены несоответствия со спецификацией (ну там, кровь, печати, выпоняли)
- проект вводится в эксплуатацию, все счастливы
в случае сложного проекта может занять несколько лет. А заказчику работать надо уже завтра, в крайнем случае -- с 1 января будущего года (а сегодня 1 декабря текущего, ага).
