Відповіді:
По-перше, не всі вимоги - це жорсткі вимоги, а швидше мінімально підтримуване обладнання. Якщо у когось менше мінімального, він може працювати - але не оптимально, або він взагалі не може працювати. В будь-якому випадку це не підтримується система, а проблеми, які ви маєте, є своїми.
Найпростіший спосіб отримати вимоги до обладнання - це здогадка. Розробник дивиться на їхню машину і каже: «Так, це працює на моїх, це вимоги».
У більш жорстких умовах компанія-розробник має набір тестових систем. Це може бути не вдома (розробники яблук, які не є домашніми, періодично використовують лабораторію сумісності Apple ). У рамках тестового процесу проводиться тестування всього обладнання, яке доступне, та визначаються мінімальні вимоги до його запуску.
Іншим фактором вимог до обладнання є базові вимоги до операційної системи. Теоретично Windows 7 вимагає як мінімум 1 ГБ оперативної пам’яті. Тому тестування на 512 Мб системі під управлінням Windows 7 є безглуздим.
Перевірте роботу системи з 1 ГБ оперативної пам’яті. Це працює? Ні ... оновлення барана. Повторюйте тест і оновлення, поки програма не працює приємно і не перелічіть їх як мінімальні вимоги.
Коли продуктивність стає частиною обіцянки програмного забезпечення, «підтримується» включає в себе те, що крім фактично запущених, операція відповідає мінімальним очікуванням на ефективність.
oпотребує <часу tдля завершення, то будь-яка комбінація обладнання, що задовольняє цій цілі, стає мінімальною специфікацією.
Вимоги до обладнання ставляться до пари різних відра. Часто ви включаєте вимоги з декількох із цих відрізків, визначаючи конкретні вимоги до обладнання для будь-якої створеної програмної системи.
Технічні обмеження в архітектурі
Це такі вимоги, які абсолютно повинні задовольняти побудована система і спеціально розроблені в системі з самого початку. Наприклад, "потрібен процесор x86."
Простий приклад, який спадає на думку, - це Microsoft Office для Mac. Спочатку Macs використовував процесори Power PC, тоді як Microsoft Windows суворо орієнтований на машини, сумісні з IBM (в основному використовуючи процесори x86). Оскільки Windows і таким чином Office працювали лише на x86, для підтримки Office на Power PC для Mac OS було написано абсолютно новий набір коду (з різними технічними обмеженнями). Як тільки Mac перейшла до процесорів Intel x86, старий Power PC, оптимізований Office для Mac, вже не працював - і технічні обмеження знову змінилися для нової версії Office для Mac для Intel. Програми, оптимізовані під 32 та 64 біти, є ще одним простим прикладом.
Неявні вимоги до апаратного забезпечення
Іноді ви активно не вирішуєте себе обмежувати, але інші рішення, які ви явно приймаєте, висувають перед вами вимоги. Спільний сценарій будується на основі будь-яких рамок.
Наприклад, якщо ви будуєте додаток .Net 4.0, .Net 4.0 має вимоги до апаратних засобів, перевірені в лабораторіях апаратури Microsoft. Тепер у вашій програмі потрібні принаймні ті самі вимоги до апаратного забезпечення, які вимагає структура .Net 4.0
Контекстуальні вимоги до апаратного забезпечення
Більшість випадків, коли ви говорите про технічні вимоги, про що ви дійсно говорите, це те, як ви підтримуєте конкретні сценарії атрибутів якості. Такі речі, як продуктивність, надійність, доступність тощо.
Це те, з чим я часто маю справу з наданням апаратних рекомендацій для клієнтів, що будують додатки на базі IBM InfoSphere Data Explorer (в основному це платформа пошукових систем Big Data). Основні вимоги Data Explorer є мінімальними (ви можете запустити його на ноутбуці), але технічні рекомендації для будь-якого конкретного додатка Big Data (читайте: вимоги) зводяться до конкретних сценаріїв атрибутів якості для цього додатка. Як швидко мають бути індексовані дані? Скільки запитів за секунду потрібно обробити? Наскільки допустимий час простою?
Визначення конкретних сценаріїв атрибутів якості виводить лінію в пісок і дозволяє мені зробити рекомендацію щодо мінімальних вимог до обладнання, заснованих на тих сценаріях - X кількість процесорів з Y кількістю оперативної пам’яті, Z гігабайт жорстких дисків, N зайвих систем. У нашому випадку ми маємо основні формули (визначені за допомогою широкого тестування в наших апаратних лабораторіях), які використовують припущення з сценаріїв атрибуту якості, щоб допомогти визначити вихідну точку рекомендацій щодо обладнання. Ця рекомендація стає вимогою до конкретної програми Big Data.
У цьому прикладі для будь-якої виробничої системи ноутбук справді не обійдеться, хоча технічно він відповідає «мінімальним» вимогам. Контекст цієї реалізації - конкретні сценарії та дані, незалежно від того, працює він у виробництві чи ні тощо., Диктують вимоги до обладнання.
Якщо припущення в сценаріях змінюються, то й вимоги до апаратних засобів будуть такими. Отже, фраза "Y GB RAM потрібна для належного запуску програмного забезпечення", насправді означає "Y ГБ оперативної пам’яті потрібно для сканування X мільйонів документів за Z годин або швидкості ABC док / хв".
Мінімальні підтримувані вимоги до обладнання
Тобто технічні характеристики обладнання, які, як очікується, працюють належним чином, і ваша група підтримки готова допомогти у вирішенні проблем. Як правило, це набір апаратних засобів, до яких ви маєте прямий доступ, або через вашу розроблювальну машину, або через якусь тестувальну лабораторію.
Одним із прикладів цього є майже будь-яка програма Android, яка була випущена. Як розробник Android, ви тестуєте додаток через деякі програмні тренажери, ймовірно, принаймні на кількох фізичних пристроях. Але є 1000 тисяч різних пристроїв під керуванням Android, багато з яких мають невеликі ... химерності ..., які можуть спричинити проблеми з вашим додатком. У більшості випадків ви все одно запропонуєте підтримку, якщо у користувача виникнуть проблеми. І в більшості випадків користувачі не матимуть проблем, навіть якщо ви спеціально не перевіряли цю апаратну варіацію. У Microsoft є і ця проблема з Windows - скільки різних відеокарт, материнської плати, процесора, комбінацій пам'яті там?
В основному, ідентифікація мінімально підтримуваного обладнання - це як сказати: "це програмне забезпечення працює на моїй машині, я очікую, що він працюватиме на машинах, подібних до моїх. Багато людей без проблем користувалися цим програмним забезпеченням на багатьох різних машинах. Ваш пробіг може змінюватися, і якщо у вас є проблеми, я зроблю все можливе, щоб допомогти / виправити, але я не можу давати гарантій ".
Для деяких застосувань такі вимоги можуть бути фактично жорсткими, наприклад, коли розробник проаналізував або профілював їх додаток і точно знає, скільки мегафлопсов, MIPS, багатокутників в секунду, розмірів робочих наборів масиву тощо повинні відповідати певним орієнтирам продуктивності. .
Для невеликих розробників проблема може бути проблемою. У них доступна лише одна система, і тому вони заявляють, що характеристики цієї системи є мінімальними, оскільки вони не змогли перевірити додаток на чомусь іншому (повільніше, менше і т. Д.) І мають невелику підказку щодо того, як це зробить додаток з меншими ресурсами.