25.08.2014 |  support@ida-web.ru

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

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

 

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

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

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

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

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

 

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

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

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

Компания "IDA-Web" надеется, что данный материал позволит Вам лучше понимать специфику понятия запаса прочности.



Так же советуем

Обратная связь

Я согласен с вашими правилами и условиями

Опыт Знания Умения