Определяем запас прочности программы

Категория: Технические советы

– Автор: Игорь (Администратор)

Запас прочности - это достаточно неоднозначное понятие, которому, обычно, сопутствует масса вопросов. Начиная от технических характеристик, таких как поддерживаемые объемы данных, размерности данных, требуемые параметры систем и прочие. И заканчивая объемами функциональности.

В последнем случае, речь идет не только о количественной характеристике набора функциональности (количество разнородных возможностей; например, редактор текста - это одна функциональность, формы связи - это другая функциональность), но и о качественной стороне этого набора или, другими словами, насколько детально и точно выполнены эти функции.

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

Пример неоднозначных вопросов, влияющих на запас прочности

Допустим, вам необходимо реализовать небольшой и простой инструмент для ведения учета заявок, который бы поддерживал ежедневно ввод до 100 заявок и который бы успешно справлялся с задачей в течение года. Несложными расчетами, можно получить, что максимально в год такой инструмент должен поддерживать до 36,5 тысяч заявок. Для простоты округлим и умножим на два с половиной, тем более, что для баз данных 100 тысяч записей - это не такая уж страшная цифра, учитывая тот факт, что в день будут редактироваться лишь 100 из них. Так же допустим, что были полностью оговорены все остальные аспекты, включая приоритетность, обязательность и прочие.

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

Так же вы можете рассчитывать на вероятные задачи и реализовать функциональности с расчетом на них, так, например, велика вероятность, что в периоды цейтнота количество просматриваемых заявок за день будет куда больше, чем 100. Или же оставлять такие случаи без внимания. Вы можете смотреть на выполнение задач с точки зрения тех пользователей, которые будут использовать инструмент. Или же реализовывать инструмент строго по договоренности. Вы можете создавать приложение с учетом возможного наличия дополнительных удобных функций или оставлять их без внимания. И прочие...

Как видите, несмотря на договоренности, реальный запас прочности будет зависеть от того, как вы ответите на эти вопросы. Если брать пример, то реализация строго по договоренности, при увеличении числа заявок в 4 раза, приведет к тому, что инструмент очень быстро достигнет своего предела.

Кроме того, внезапная необходимость в массовой проверке, например, для выявления ошибок, без наличия неоговоренных функциональностей, может легко привести инструмент в непригодность, несмотря на то, что прохождение, скажем, по 9000 заявкам, при определенном подходе, легко могло бы поддерживаться системой.

Безусловно, цифры в примере были даны совершенно конкретные, так что достижение предела, в следствие увеличения нагрузки, не является следствием "криворукости" автора программы. Ровно, как и отсутствие неоговоренных инструментов не является следствием некачественной реализации приложения.

Однако смысл примера заключается не в цифрах или определении "плохой" стороны, а в тех возникающих неоднозначных вопросах, которые серьезно влияют на реальный запас прочности.

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

Как же определять запас прочности продукта?

Список неоднозначных вопросов невозможно сформировать. Вы можете создавать и дополнять собственный список. Вы можете искать и находить такие вопросы в схожих проектах. Вы можете использовать готовые опросники и прочие инструменты для анализа. Тем не менее, все равно эти списки будут давать ответы лишь на часть вопросов и в основном относиться к соблюдению тех рамок, которые были поставлены изначально.

Безусловно, все эти данные нужны для оценки прочности, но их нельзя считать реальным показателем запаса прочности.

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

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

И только после вышеперечисленного можно подходить к определению реального запаса прочности.

Понравилась заметка? Тогда время подписываться в социальных сетях и делать репосты!

• Почему, когда речь заходит о технологиях, можно услышать достаточно противоречивые мнения?
• Почему очевидные решения не всегда подходят?