avl (avl) wrote,
avl
avl

Categories:

10. Количество имеет значение!

(В оригинале Quantify)

Требование «Быстро» фактически требованием не является. Как и не является требованием «Расширяемо» или «Надежно». Самая главная причина этого – это то, что у вас нет объективного способа измерить полученный результат, чтобы сказать, выполнено требование или нет. Однако пользователи часто такие требования ставят. И задача архитектора – сделать так, чтобы проектируемая система обладала этими качествами. Найти баланс между конфликтами и несоответствиями между ними. И без объективных критериев архитектору придется полагаться на добрую волю капризных пользователей («Нет, система все еще работает недостаточно быстро!») и слишком требовательных разработчиков («Мы не можем выпустить релиз, система все еще работает недостаточно быстро!»).

Слишком часто при определении требований к системе записываются такие неопределенные прилагательные как «гибкий», «легко поддерживаемый» и им подобные. И в большинстве таких случаев можно задать некий исчисляемый критерий и определить границы. И если этого не сделать, то у вас не будет основы для критерия сдачи работы заказчику, у разработчиков не будет мотивации для работы, а у архитекторов – четкого видения.

Несколько простых вопросов могут это прояснить. Сколько? За какой период? Как часто? К какому сроку? С какой частотой? Если на эти вопросы не будет ответов, то значит, что потребность клиента не сформулирована. Ответы должны быть на языке бизнеса, использующего систему, в противном случае надо очень хорошо подумать. Если вы проектируете систему и ваш заказчик не хочет или не может назвать вам эти цифры, задайте себе вопрос «Почему?». А потом все же получите эти ответы. И если в следующий раз вам скажут, что система должна быть «масштабируемой», спросите, откуда появятся новые пользователи, сколько их будет и как часто это будет происходить. И не принимайте ответы «Много» и «Часто».

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

«Система должна давать ответ пользователю не позднее чем через 1500 миллисекунд после ввода. Во время нормальной загрузки (определяемой как...) среднее время ответа должно быть в диапазоне от 750 до 1250 миллисекунд. Для времен менее 500 миллисекунд пользователь уже не заметит особой разницы, поэтому тратить ресурс на снижение времени ниже этой границы мы не будем» - вот теперь это требование!

Автор оригинала: Keith Braithwaite

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!
Tags: 97_things_architect_should_know, Программирование, Развитие
Subscribe

  • Один день на яхте

    Давно, очень давно хотелось оказаться на яхте. И вот наконец удалось реализовать мечту, пока что на 1 день. Главное — что оказалось, что никого из…

  • Подарок на 8 марта :)

    Фирма удивила, подарив 8 марта ВСЕМ сотрудникам смарт-часы от неизвестного производителя с нанесенным своим логотипом :) Да, в Словении 8 марта -…

  • Автомобильное...

    Ездишь себе, ездишь, стараешься машины поддерживать в исправном состоянии... А потом подходит очередной техосмотр - и машина вдруг впервые за 7 лет…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 0 comments