Требования к производительности программы

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

1. Число поддерживаемых терминалов;
2. Число одновременно поддерживаемых пользователей;
3. Объем и тип обрабатываемой информации.

5.3.4. Логические требования к базе данных

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

5.3.5. Ограничения проектирования

Здесь задаются ограничения проектирования, налагаемые другими стандартами, аппаратурой и т.д.

5.3.5.1. Соответствие стандартам

1. Форматы отчетов;
2. Именование данных;
3. Бухгалтерские процедуры;
4. Протоколирование работы.

5.3.6. Атрибуты программной системы

1. Использования криптографии;
2. Хранение логов или истории;
3. Назначать некоторые функции различным модулям;
4. Ограничивать коммуникации между некоторыми областями программы;
5. Проверять целостность данных для критических переменных.

1. Доля компонентов с машинно-зависимым кодом;
2. Доля машинно-зависимого кода;
3. Использование испытанного переносимого языка;
4. Использование особенного компилятора или подмножества языка;
5. Использование особенной операционной системы.

Источник: studfile.net

Тест производительности ПК

Характеристики производительности приложений .NET Framework

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

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

Почему тормозят игры? Как определить слабое место в компьютере

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

• Исследуя серьезные проблемы производительности веб-сервера в одном из центров обработки данных, мы обнаружили, что они были вызваны использованием для тестирования 4 Мбитного канала с низкой задержкой. Не понимая, какой из показателей производительности играет наиболее важную роль, инженеры потратили несколько десятков дней на оптимизацию самого веб-сервера, который и без того показывал отличную производительность.
• Мы сумели улучшить скорость прокрутки в приложении WPF с графическим интерфейсом за счет тонкой настройки механизма сборки мусора — программного компонента, не имеющего очевидной связи с проблемой. Точный хронометраж операций распределения памяти и настройка поведения сборщика мусора помогли установить и устранить причины задержки в работе графического интерфейса, так раздражавшие пользователей.
• Нам удалось увеличить скорость компиляции в десять раз, подключив жесткий диск к порту SATA и тем самым устранив влияние ошибки в драйвере SCSI-дисков от Microsoft.
• Мы смогли уменьшить размеры сообщений для обмена данными со службой WCF на 90%, заметно улучшив ее масштабируемость и использование CPU за счет настройки механизма сериализации WCF.
• Мы сократили время запуска крупного приложения, насчитывающего 300 сборок, с 35 до 12 секунд на устаревшем оборудовании, за счет сжатия кода приложения и тщательного исследования его зависимостей, с целью выявления тех, что не требуются немедленно на этапе запуска.

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

Требования к производительности

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

Для начала перечислим несколько примеров неправильно сформулированных требований:

• приложение должно сохранять высокую отзывчивость при одновременном доступе нескольких пользователей;
• приложение не должно использовать большой объем памяти при небольшом количестве посетителей;
• единственный сервер базы данных должен быстро обслуживать запросы, даже при наличии нескольких серверов приложений, действующих под высокой нагрузкой.

Основная проблема этих требований в том, что они являются слишком общими и субъективными. Если попытаться вникнуть в их суть, можно обнаружить, что в разных системах отсчета они могут интерпретироваться по-разному. Бизнес-аналитик может считать, что 100 000 одновременно работающих пользователей — это «немного», а технический специалист может с уверенностью сказать, что такое количество пользователей невозможно обслужить, имея единственную машину. Аналогично, разработчик может считать пользовательский интерфейс с задержками 500 мсек вполне «отзывчивым», а эксперт в пользовательских интерфейсах оценивать это как серьезный недостаток.

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

• приложение должно обслуживать каждую страницу в категории «Важные» не дольше 300 мсек (не включая задержки в сети), при условии одновременного обслуживания не более 5000 пользователей;
• приложение должно потреблять не более 4 Кбайт памяти на каждый неактивный сеанс с пользователем;
• нагрузка на CPU и используемый объем жесткого диска на сервере баз данных не должны превышать 70%, а время обработки запросов из категории «Общие» не должно превышать 75 мсек, при условии одновременного обслуживания не более 10 серверов приложений.

В этих примерах предполагается, что категория страниц «Важные» и категория запросов «Общие» четко определены бизнес-аналитиками и архитекторами приложения. Определение требований к производительности для каждого аспекта приложения часто неразумно и не стоит затраченных усилий.

Теперь рассмотрим несколько примеров требований к производительности для типичных приложений (таблица ниже). Этот список не является исчерпывающим и не может служить контрольным списком или шаблоном для определения ваших собственных требований — это всего лишь общий обзор различий в требованиях, предъявляемых к приложениям разных типов:

Примеры требований к производительности для типичных приложений

Тип системы Требование к производительности Ограничения окружения

Внешний веб-сервер	Время от момента получения запроса до момента создания полного ответа не должно превышать 300 мсек	При условии одновременной обработки не более 300 запросов
Внешний веб-сервер	Объем используемой виртуальной памяти (включая кеш) не должен превышать 1.3 Гбайт	При условии одновременной обработки не более 300 запросов и не более 5000 открытых сеансов пользователей
Сервер приложений	Нагрузка на CPU не должна превышать 75%	При условии не более 1000 одновременно обслуживаемых запросов к API
Сервер приложений	Частота следования ошибок обращений к страницам диска не должна превышать 2 ошибок в сек	При условии не более 1000 одновременно обслуживаемых запросов к API
Клиентское приложение	Время от двойного щелчка на ярлыке до появления полного списка клиентов не должно превышать 1500 мсек	—
Клиентское приложение	Нагрузка на CPU в режиме простоя приложения не должна превышать 1%	—
Веб-страница	Время фильтрации и сортировки списка входящих электронных писем не должно превышать 750 мсек, включая время, затрачиваемое на воспроизведение анимационных эффектов	При отображении не более 200 электронных писем
Веб-страница	Объем памяти для хеширования объектов JavaScript в окне не должен превышать 2.5 Мбайт	—
Служба мониторинга	Время от возникновения ошибки до вывода предупреждения не должно превышать 25 мсек	—
Служба мониторинга	Частота следования операций дискового ввода/вывода в отсутствие активных предупреждений должна быть равна 0	—

Параметры аппаратного обеспечения, на котором выполняется приложение, играют ключевую роль в определении ограничений среды. Например, требование к скорости запуска клиентского приложения может потребовать использования твердотельного накопителя или жесткого диска со скоростью вращения шпинделя не менее 7200 об/мин, по меньшей мере 2 Гбайт системной памяти и процессора с тактовой частотой 1.2 Ггц или выше, поддерживающего набор инструкций SSE3. Эти требования к аппаратному обеспечению не стоит повторять в описании каждого требования к производительности, но о них следует помнить.

Когда требования к производительности сформулированы, тестирование производительности, нагрузочное тестирование и последующий процесс оптимизации становятся тривиальным делом. Проверка таких требовании, как «частота следования ошибок обращений к страницам диска не должна превышать 2 ошибок в сек, при условии не более 1000 одновременно обслуживаемых запросов к API» часто может потребовать применения инструментов нагрузочного тестирования и подходящего аппаратного обеспечения. В последующих статьях рассматриваются приемы измерения производительности приложений позволяющие определить степень соответствия предъявляемым требованиям.

Для формулировки требований к производительности нередко необходимо иметь знакомство с характеристиками производительности, о которых рассказывается ниже.

Характеристики производительности

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

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

Список характеристик производительности (частичный)

Характеристика Единицы измерения

Нагрузка на CPU	Процент
Использование физической/виртуальной памяти	Байты, килобайты, мегабайты, гигабайты
Попадания в кеш	Количество,частота попаданий в секунду
Ошибки обращений к страницам диска	Количество, частота следования в секунду
Обращения к базе данных	Количество обращений, частота следования в секунду
Выделение блоков памяти	Количество байтов, количество объектов, частота следования в секунду
Время выполнения	Миллисекунды
Сетевые операции	Количество, частота следования в секунду
Дисковые операции	Количество, частота следования в секунду
Время отклика	Миллисекунды
Сборка мусора	Количество, частота следования в секунду, продолжительность, % от общего времени выполнения
Исключительные ситуации	Количество, частота следования в секунду
Время запуска	Миллисекунды
Конкуренция	Количество, частота следования в секунду

Одни характеристики более важны для одних типов приложений, другие — для других. Например, время доступа к базе данных не является характеристикой, которую можно измерить на стороне клиента. В число наиболее типичных комбинаций характеристик производительности входят:

• для клиентских приложений может оказаться важным время запуска, объем используемой памяти и нагрузка на CPU;
• для серверных приложений, составляющих основу системы, обычно большое значение имеют нагрузка на CPU, попадание в кеш, количество соединений и интенсивность операций с динамической памятью, а также характеристики работы сборщика мусора;
• в веб-приложениях основное внимание, как правило, уделяется объему используемой памяти, операциям доступа к базе данных, сетевым и дисковым операциям и времени отклика.

И последнее наблюдение, касающееся характеристик производительности, — уровень детализации измерений часто может изменяться существенно, что, впрочем, никак не влияет на важность самих характеристик. Например, время выделения памяти или время выполнения могут измеряться на уровне системы, на уровне единственного приложения или даже на уровне отдельных методов или строк. Время выполнения одного конкретного метода может оказаться гораздо важнее, чем общая нагрузка на CPU или время выполнения процесса в целом! К сожалению, увеличение уровня детализации измерений часто влечет за собой дополнительные накладные расходы.

Место производительности в цикле разработки

Куда в цикл разработки следует вставить решение вопросов, связанных с производительностью? Этот, казалось бы невинный вопрос, влечет за собой необходимость модернизации всего процесса разработки. Для этих целей можно было бы выделить отдельный этап. Однако правильнее уделять внимание проблемам производительности на каждом этапе разработки приложения: сначала следует выявить наиболее важные характеристики и определить требования к производительности; затем выяснить, насколько полно приложение отвечает этим требованиям; и, наконец, на этапе дальнейшего развития и эксплуатации следить, как изменяются показатели производительности.

1. На этапе определения требований к приложению начинайте одновременно выяснять параметры производительности, которые было бы желательно получить.
2. На этапе проектирования очертите круг наиболее важных характеристик производительности для вашего приложения и определите конкретные их значения.
3. На этапе разработки как можно чаще выполняйте тестирование производительности прототипов или незавершенных функций, чтобы убедиться, что их производительность находится в установленных границах.
4. На этапе тестирования выполняйте всеобъемлющие нагрузочные испытания и тестирование производительности, чтобы убедиться, что производительность системы в целом соответствует установленным требованиям.
5. В дальнейшем, во время разработки и сопровождения, выполняйте дополнительные нагрузочные испытания и тестирование производительности перед выпуском каждой новой версии (желательно ежедневно или хотя бы раз в неделю), чтобы быстро выявить снижение производительности, вызванное добавлением новых или изменением существующих функций.

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

Источник: professorweb.ru

Нефункциональные требования: как не пустить систему ко дну

Привет, Хабр! Меня зовут Елена, я ведущий аналитик ИТ-компании SimbirSoft. Сегодня хочу затронуть такую тему, как нефункциональные требования к ИТ-продукту, которым не всегда уделяется должное внимание, а зря. Их несоблюдение может привести к потере прибыли, клиентов, репутации, остановке производственных процессов и большим штрафам, хотя с первого взгляда их влияние на осуществление пользовательского функционала неочевидно.

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

• мощности и производительности;
• безопасности, соответствию стандартам и законодательству;
• переносимости и совместимости.

При проектировании системы чаще всего говорят о её функциональности: что она должна делать для того, чтобы соответствовать целям бизнеса, как решать те или иные проблемы пользователей, какие ценности им поставляет, как оптимизирует процессы в компании и т.п. Ключевая формулировка – «ИТ-продукт должен делать то-то и то-то». Но это даже не вершина айсберга, это Титаник. Айсбергом в этом случае станет среда, в которой ИТ-система будет существовать после релиза.

Как известно, причиной трагедии на Титанике стало стечение многих факторов: технологические аспекты крепления листов стали по корпусу, использование материалов ненадлежащего качества, недостатки конструкции, отсутствие необходимого количества спасательных шлюпок, недостаточная подготовка персонала и прочее. Можно ли сказать, что лайнер при этом не выполнял свои функции? Нет. Он комфортно перевозил на своём борту более двух тысяч человек, обеспечивая их сервисом и развлечениями.

Так и с ИТ-системой: она может быть изящной, эффективной, функциональной, даже гениальной и уникальной, но вдребезги разбиться о реалии своего существования. Нужно ли говорить о том, какие за этим стоят риски для бизнеса?

Что такое нефункциональные требования и какими они бывают

Функциональные требования описывают, что необходимо реализовать в продукте или системе. Они содержат ту ценность системы, ради которой она создаётся – логику, взаимодействие её компонентов и пользователей с ней.

Нефункциональные требования (НФТ) описывают, как должен работать программный продукт и какими свойствами или характеристиками обладать, чтобы доставить ту ценность, которую несёт система, с учетом условий ее существования. Такие требования вносят вклад в инфраструктуру, а не в поведение системы.

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

Нефункциональных требований достаточно много. Подробно они описываются в BABOK (руководство к Своду знаний по бизнес-анализу), в ISO / IEC 25000. В рамках данной статьи мы рассмотрим три:

1. Требования, описывающие производительность и мощность. Должны содержать информацию о планируемых нагрузках, которые ваша система должна выдерживать в пиковые моменты ее работы.
2. Требования к безопасности и соответствию законодательству и стандартам. Гарантируют, что все данные внутри системы или ее компонентов будут защищены от вредоносных атак или несанкционированного доступа.
3. Требования к переносимости и совместимости системы. Они описывают среду, в которой будет использоваться система – устройства, операционные системы, браузеры, другие системы, с которыми приложение должно работать.

О том, как мы работаем с требованиями, – в нашем видео. А теперь расскажем подробнее о каждой группе и дадим рекомендации о том, на что стоит обратить внимание.

Производительность и мощность

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

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

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

При проектировании системы от представителей бизнеса очень важно получить данные об ожидаемом количестве пользователей в единицу времени при стандартной нагрузке и в пиковые часы.

При формировании требований к системе для вычисления потенциальной рабочей нагрузки полезно выявить наиболее важные с точки зрения бизнеса и пользовательских сценариев, а для каждого из них определить профиль нагрузки, который включает: количество операций и объём получаемых / отправляемых данных в единицу времени, скорость ответа, объем хранимых данных.

Плохой пример нефункциональных требований:

«Приложение должно максимально быстро реагировать на действия пользователя»

Хороший пример нефункциональных требований:

«Пользователь, находясь в сети 3G, должен получать расчёт стоимости услуги не более чем за 2 секунды»

Чек-лист «Как определить требования к производительности и мощности»

1. Сколько запросов в секунду предполагается для системы:

1. В обычном режиме;
2. В периоды пиковой нагрузки.

1. В обычном режиме;
2. В периоды пиковой нагрузки.

1. Первичная загрузка;
2. Повторная загрузка.

1. Активных:

1. На старте;
2. Через год;
3. Через 2 года.

1. На старте;
2. Через год;
3. Через 2 года.

1. В обычном режиме;
2. В периоды пиковой нагрузки.

1. Сколько данных можно хранить и что с ними нужно делать:

1. Ожидаемое число объектов различного типа в день / неделю / месяц / год, а также в пиковые периоды (например, позиций в каталоге, количество сформированных заказов);
2. Каковы прогнозируемые темпы роста;
3. Типы хранимых файлов и их объем (документы, изображения, аудио, видео):

1. Максимальный размер файла;
2. Есть ли ограничения по количеству загружаемых к объекту/сущности файлов?
3. Как долго эти данные надо хранить в системе (например, можно удалить их через N лет)?

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

Безопасность, соответствие стандартам и законодательству

К нефункциональным требованиям по безопасности можно отнести:

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

Самые чувствительные в этом отношении проекты связаны с хранением и безопасностью персональных данных. Например, FinTech и банковские приложения должны соответствовать как международным стандартам, так и стандартам безопасности отдельных стран. Например, в России – есть требования Федеральной службы по техническому и экспортному контролю, 152-ФЗ «О персональных данных», а за рубежом – требования GDPR.

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

Под безопасностью также подразумеваются:

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

Рекомендуем ознакомиться с топ-10 OWASP. Этот стандарт отражает наиболее критичные угрозы для веб-приложений. В этой статье мои коллеги как раз рассказывали о веб-уязвимостях.

Плохой пример:

Приложение должно соответствовать стандартам безопасности

Хороший пример

Клиент должен взаимодействовать с сервером посредством протокола SSL.

Чек-лист «Как определить требования к безопасности системы»

1. От каких угроз вы хотите защитить систему. Например:
   — при каких обстоятельствах может произойти несанкционированный доступ;
   — какие могут быть прецеденты утечки данных;
   — какие виды вредоносных атак хотите отразить.

1. Какие роли пользователей предусмотрены в системе и какими правами они должны быть наделены.
2. Какая схема авторизации и аутентификации предусматривается:

1. Требуется ли SSO, нужна ли интеграция с LDAP, Active Directory;
2. Нужна ли двухфакторная аутентификация;
3. Какие требования к парольной политике;
4. Какие требования к продолжительности сессии. Например:
   — должен ли пользователь быть разлогинен через какое-то время без активности;
   — удаляется ли текущая сессия при завершении сеанса;

1. Нужно ли шифровать межсервисный трафик (HTTP, HTTPS).
2. Предусматривается ли работа с персональными данными:

1. Обработка;
2. Хранение (если да, то на какой срок);
3. Передача третьим сторонам;
4. Где должны располагаться сервера, хранящие данные.

1. Наличие резервной копии;
2. Наличие и правила создания точек сохранения БД.

Ответы на эти вопросы помогут не только грамотно спроектировать архитектуру приложения, но и повлияют на функциональные требования, например, в части авторизации и аутентификации пользователя, предоставления им согласия на обработку и хранение ПД, хранение cookie-файлов и прочее.

Переносимость и совместимость

Переносимость определяет, насколько успешно действия системы в рамках одной платформы или конфигурации будут выполняться в других условиях. Описывает, как система и ее компоненты могут быть запущены в определенной среде – на том или ином оборудовании, с использованием конкретного ПО и т.п.

Совместимость – это дополнительный аспект переносимости. Она описывает, как система может существовать и взаимодействовать с другими системами и процессами в той же среде.

Например, программное обеспечение, установленное на операционной системе, должно быть совместимо с ее брандмауэром или антивирусной защитой.

Переносимость и совместимость определяются с учётом операционных систем, аппаратных устройств, браузеров, программных систем и их версий.

На данный момент общепринятый стандарт для веб-приложений — кроссплатформенное, кроссбраузерное и мобильное решение.

Нефункциональные требования к переносимости обычно основываются на предварительных исследованиях рынка, полевых исследованиях или аналитических отчётах о типах программного обеспечения и устройств, которыми пользуется целевая аудитория. Определить это помогут аналитические платформы, такие как Google Analytics, Firebase и т.д.

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

Плохой пример

Приложение должно полноценно работать на iPhone и Android

Хороший пример

Приложение должно поддерживать устройства, работающие на операционных системах:

1. iOS 9.0- 16.0

2. Android 7.0 – 12.0 (учитывая специфические особенности марок Xiaomi, Sony, Huawei)

Чек-лист «Как определить требования к совместимости и переносимости»

1. На каких типах устройств планируется использовать приложение.
2. На каких операционных системах должно работать приложение.
3. В каких браузерах и их версиях должно работать приложение.
4. Каковы минимальные требования к устройствам и другому оборудованию, необходимые для нормальной работы приложения.
5. Требования к подключению. Использование каких сетей предполагается для работы приложения и какова их пропускная способность:

1. Локальная;
2. Широкополосный интернет;
3. Мобильный интернет;
4. Спутниковая связь;
5. Оффлайн.

Исходя из предполагаемых устройств и ОС, формируются требования к дизайну: размеры экранов, ориентация, наличие анимации, использование нативного дизайна и т.д.