Методи формування системних вимог до аз для громіздких 3D програм

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Методи формування системних вимог до аз для громіздких 3D програм

В наш час розробляється багато власних комп'ютерних програм (додатків), для роботи з якими використовуються різні конфігурації апаратного забезпечення (АЗ). Кожен такий програмний продукт потребує певного обсягу ресурсів робочої станції -- чи то персонального комп'ютера, чи іншого пристрою. Залежно від типу та складності додатку змінюється навантаження конкретних ресурсів апаратної складової комп'ютера -- процесора, опертивної пам'яті, відеокарти, жорсткого диску та інших. Визначитися з тим, чи здатна робоча станція ефективно працювати з конкретним програмним додатком, не викликаючи при цьому дискомфорту користувача, мають допомогти системні вимоги. Ці системні вимоги формує розробник для свого програмного забезпечення (ПЗ).

У даній статті розглядається проблема визначення мінімальних та номінальних системних вимог на прикладі розробленого нами програмного продукту, що пов'язане з аналізом даних отриманих емпірично, та за допомогою математичних розрахунків.

Виходячи з поставлених задач, виникають питання, які стосуються проблеми збору даних з програмного продукту та представлення їх у вигляді таблиці. Окрім вищезазначеної проблеми існує також питання вибору програмного забезпечення для обробки зібраних даних та винесення вердикту, отримання кінцевого результату у вигляді мінімальних та рекомендованих системних вимог.

Перш ніж розглянути питання збору даних з програмного забезпечення необхідно визначитись з:

— піддослідними стендами, тобто ПК, на яких будуть проводитись дослідження;

— ПЗ, для якого формуватимуться системні вимоги;

— алгоритмом визначення системних вимог;

— ПЗ для вимірювання необхідних даних, пов'язаних з навантаженням певних вузлів апаратної частини;

— ПЗ для аналізу отриманих даних та представлення його у прийнятному для користувача вигляді.

Методи тестування програмного забезпечення є надзвичайно актуальною і розглядались багатьма дослідниками [1 - 5 ], однак жоден з них не розглядав проблему формування системних вимог до АЗ для конкретних додатків.

Для того, щоб розпочати процес отримання необхідних даних, слід визначитись з апаратним забезпеченням, яке буде використовуватись для дослідження. Необхідно мати хоча б 3

— 4 робочих станції різної конфігурації. Тоді віднаходження “золотої середини” в параметрах швидкодії додатку буде значно простішим. Вибір апаратного забезпечення здійснюється на основі аналізу багатьох факторів, проте вирішальною в нашому випадку стала сама наявність конкретних робочих станцій. Для даного дослідження було вирішено обрати чотири ПК, що були у нас у наявності, з наступними конфігураціями (таблиця).

програма додаток користувач

Конфігурації робочих станцій для тестування програмного забезпечення

Визначившись з робочими станціями для тестування, необхідно обрати ПЗ, на основі якого будуть проводитись дослідження і формуватися системні вимоги. Як відомо, в даний час існує достатня кількість “тяжких” та “легких” програмних продуктів, тому вибір великий. Одним з головних критеріїв вибору об'єкта дослідження є необхідність його тестування з метою формування системних вимог. Нами для дослідження обрано додаток власного виробництва -- “3D модель замку Любарта”. [3]

Далі слід перейти до наступного етапу планування дослідження, а саме вибору методики проведення цього дослідження. Існує два основних шляхи досягнення результату розробника ПЗ, який прагне визначити системні вимоги для свого додатку, це:

— емпіричний;

— статистичний.

Під чисто емпіричним дослідженням розуміється проведення низки практичних тестів, які і вкажуть на вирішення проблеми, допоможуть визначити необхідні характеристики для комп'ютера користувача під певний додаток. Проте цей шлях часто є мало ефективним, адже вимагає практичного виконання програми на всіх робочих станціях, а це може зайняти велику кількість часу, що, в деяких випадках, є неприпустимим для розробника, який працює з ПЗ на останній стадії розробки -- тестуванні. Проте безумовним плюсом цього методу є перевірка додатку вживу, без використання математичних розрахунків та штучного підбору ідеального АЗ. Розробник має можливість прямо контактувати зі своїм додатком в процесі роботи та аналізувати ефективність використання того чи іншого тну АЗ.

Існує також інший тип дослідження -- статистичний. Звичайно, невід'ємною частиною статистичного аналізу є емпіричне дослідження, але воно проводиться за певним планом з метою отримання необхідних статистичних даних з метою їх подальшого оброблення. Мінусом цього методу є те, що в результаті оброблення ми отримуємо середньостатистичні дані, однак у разі використання не лише середніх значень, а й дисперсії досліджуваних параметрів, ми маємо змогу об'єктивно підходити до процесу формування системних вимог. Плюсом даного методу є значне прскорення процесу тестування та отримання результатів, підтверджених об'єктивними розрахунками. В даній статті буде розглянуто обидва методи аналізу даних.

Після того, як розробник обрав метод дослідження швидкодії програмного продукту, необхідно звернути увагу на ПЗ, завдяки якому можна буде отримувати дані про стан апаратних частин робочої станції в певний період часу. Серед таких програм є: MSI Afterburner, та платна Aida 64. Здійснювати Моніторинг АЗ з допомогою цих програм здійснюється за певні проміжки часу. Критерієм вибору ПЗ для вищевказаних цілей є: легкість у використанні, мала вартість, рівень адаптованості до поставленої задачі та особистий досвід користування. Зваживши всі варіанти, враховуючи безкоштовність та зручність у використанні, було обрано програму MSI Afterburner. Вона дозволяє здійснювати моніторинг системи в режимі реального часу, не згортаючи при цьому додаток.

Маючи в розпорядженні робочі станції, обраний метод дослідження та програму для моніторингу, слід здійснити аналіз щодо ПЗ для роботи з отриманими числовими даними та їх інтерпретування у зрозумілу форму навіть для звичайного користувача. Найбільш популярними серед таких програм є: Microsoft Office Excel, LibreOffice Calc, Google Tablets, доступна з будь якого браузера. Критеріями вибору одного з вище перерахованих додатків є: вартість, простота у використанні, набір необхідних інструментів, особистий досвід. Всі програми з даного списку володіють необхідним функціоналом для задоволення наших потреб та зручні у використанні. За доступністюі безумовним лідером є Google Таблиці, проте вибір було зроблено на користь програми Microsoft Office Excel, через великий досвід роботи з нею та наявність її на комп'ютері, де проходитиме збір усіх даних та подальший їх аналіз.

На цьому кроці етап планування закінчений і необхідно переходити до наступного -- збору даних, потрібних для визначення системних вимог додатку “3D модель замку Любарта”. Першим кроком буде встановлення програми MSI Afterburner на всі робочі станції: N1 1050, N2 1050ti, N3 630M. N4 630 HD. Далі необхідно провести налаштування цього додатку для коректного відображення інформації під час тестування (рис. 1а, рис. 16, рис. 1в).

Після проведення всіх налаштувань, можна запускати програму “3D модель замку Любарта”. Одразу після запуску додатка в лівому верхньому куті з'явиться вся необхідна для тестування інформація (рис. 2).

Впевнившись в тому, що зчитування даних працює належним чином, можна переходити з головного меню в гру. Для прикладу, були взяті значення з комп'ютера №3 (630М) (рис. 3).

Ознайомившись з територією замку на протязі хвилини, були записані значення CPU load, GPU load, FPS. Інтервал між замірами -- 3 секунди. В результаті був отриманий наступний графік значень (рис. 4).

Середні значення вищевказаних показників: CPU load -- 55.8%, GPU load -- 98.1%, FPS -- 14.8. Дисперсія показників: CPU load -- 7.32, GPU load -- 1.04, FPS -- 0.27. Дисперсія протестованих показників представлена нижче (рисунок 5).

Судячи з отриманих даних, можна зазначити, що для комфортного відтворення додатку представлена вище конфігурація в цілому не підходить, оскільки середнє значення FPS (frames per second) в районі 14.8 не є прийнятним для користувача. Слід зауважити, що прийнятний рівень показника кадрів за секунду становить від 25 до 60.

Вузьким місцем представленої вище системи N3 630M є відеочіп, в той час як процесор завантажений в середньому на 55,8%. Проте високий рівень дисперсії значень завантаження процесора у відсотках говорить про те, що він працює нестабільно. Також були проведені тести на інших системах, результати яких описані нижче (рис. 6а, рис. 66, рис. 6в).

Рисунок 1а. Налаштування Рисунок 16 -- Налаштування Рисунок 1в -- Налаштування MSI MSI Afterburner MSI Afterburner Monitoring Afterburner Monitoring

Рисунок 2. MSI Afterburner під час виконання програми, яку тестують

Рисунок 3. Зображення з гри

програма додаток користувач

Рисунок 4. Графік значень протестованих параметрів стенда N3 (630M)

Спираючись на отримані тести, можна зазначити, що для мінімальних системних вимог додатку допустимим буде рівень процесору зі стенда N3 630M, адже він показав невисокий рівень завантаженості. В той же час відеокарта 630M для мінімальних системних вимог занадто слабка, тому слід звернути увагу на GPU рівня Intel 630HD, що забезпечить системі прийнятний рівень швидкодії у вигляді 24 - 26 кадрів на секунду.

Вище був представлений приклад аналізу даних для виявлення мінімальних системних вимог додатку. Далі буде коротко описано теоретичний метод отримання системних вимог, але вже не мінімальних, а номінальних.

Номінальні системні вимоги додатка вказують на характеристику АЗ, рівня потужності якого достатньо для досягнення найкомфортнішого відтворення цього додатка. Щоб одержати синтетичну оцінку відеокарти, слід звернутись до бази даних процесорів та відеочіпів на сайті https://www.futuremark.com/hardware/gpu. Вибрати 630M, побачимо коефіцієнт швидкодії 530. Нехай це число 530 відповідає середній частоті кадрів 15 для нашого додатка. Для отримання значення орієнтовно 60, що означатиме комфортний режим роботи додатка, слід помножити 15 на 4, і, відповідно, коефіцієнт 530 також варто помножити на 4. Отримаємо відеочіп, коефіцієнт швидкодії якого приблизно відповідає значенню 2120 (рисунок 7).

Таким чином, для отримання системних вимог до АЗ під конкретний додаток необхідно вибрати різні типи робочих станції, встановити на них необхідне ПЗ, протестувати роботу додатку через певні проміжки часу. Запропоновані два основних шляхи формування системних вимог до АЗ під конкретний додаток - емпіричний та статистичний.

Література

1. Лайза Криспин, Джанет Грегори. Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд = Agile Testing: A Practical Guide for Testers and Agile Teams.-- M.: «Вильямс», 2010. -- 464 c.

2. Канер Кем, Фолк Джек, Нгуен Енг Кек. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений. -- Киев: ДиаСофт, 2001. -- 544 с.

3. Калбертсон Роберт, Браун Крис, Кобб Гэри. Быстрое тестирование. -- М.: «Вильямс», 2002. -- 374 с.

4. Синицын С. В., Налютин Н. Ю. Верификация программного обеспечения. -- М.: БИНОМ, 2008. -- 368 с.

5. Бейзер Б. Тестирование чёрного ящика. Технологии функционального тестирования программного обеспечения и систем. -- СПб.: Питер, 2004. -- 320 с.

Размещено на Allbest.ru