Аналіз розробки комп'ютерної гри незалежним розробником

Вступ

Метою дослідження є аналіз процесу розробки комп’ютерної гри незалежним розробником з точки зору випуску готової ігри в зазначений термін і оцінка її успішності.

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

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

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

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

Теоретична частина

Методології розробки

Розробка програмного продукту має багато гідних методологій. Вибір залежить від специфіки проекту, обмеження коштів, суб'єктивних переваг і навіть темпераменту розробника. В роботі описані методології, які можуть бути застосовані в процесі розробки [4].

" Waterfall Model" (Каскадна модель або «Водоспад»).

У моделі Waterfall легко керувати проектом. Завдяки її жорсткості, розробка проходить швидко, вартість і термін визначаються заздалегідь. Але це «палиця з двома кінцями». Каскадна модель буде давати відмінний результат тільки в проектах з чіткими вимогами і способами їх реалізації. В ній немає можливості зробити крок назад, до тестування можна приступати тільки після того, як закінчена розробка.

Рис. 1 — Модель водопад

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

Ця модель використовується у наступних випадках:

• · Коли вимоги відомі, зрозумілі і зафіксовані. Суперечливих вимог немає.
• · У відносно невеликих проектах.

" V-Model" .

Успадкувала структуру «Крок за кроком» від каскадної моделі. V-подібна модель застосовна до систем, яким особливо важливо безперебійне функціонування. Наприклад, прикладні програми в клініках для спостереження за пацієнтами. Особливістю моделі є те, що вона спрямована на ретельну перевірку та тестування продукту, що знаходиться вже на початкових стадіях проектування. Стадія тестування проводиться одночасно з відповідною стадією розробки, наприклад, під час кодування пишуться модульні тести.

Рис. 2 — V-Model

Проект виконується за чітким ТЗ до якого включений етап тестування інтерфейсу, функціоналу, навантаження і інтеграції.

Ця модель використовується у наступних випадках:

• · Якщо потрібне ретельне тестування продукту, то V-модель виправдає закладену в себе ідею: validation and verification.
• · Для малих і середніх проектів, де вимоги чітко визначені і фіксовані.

" Incremental Model" (Інкрементна модель).

У інкрементної моделі повні вимоги до системи поділяються на різні збірки. Термінологія часто використовується для опису поетапної збірки ПЗ.

Модель має кілька циклів розробки, які складають життєвий цикл «Мульти-водоспад». Цикл розділений на більш дрібні легко створювані модулі. Кожен модуль проходить через фази визначення вимог проектування, кодування, впровадження та тестування. Процедура розробки за інкрементною моделлю передбачає на першому великому етапі випуск продукту в базовій функціональності, а потім вже послідовне додавання нових функцій, так званих «інкрементів». Процес продовжується до тих пір, поки не буде створена повна система.

Рис. 3 — Інкрементна модель

Інкрементні моделі використовуються там, де окремі запити на зміну ясні і можуть бути легко формалізовані і реалізовані.

Ця модель використовується у наступних випадках:

• · Коли основні вимоги до системи чітко визначені і зрозумілі. У той же час деякі деталі можуть доопрацьовуватися з часом.
• · Потрібно ранній висновок продукту на ринок.
• · Є кілька ризикових особливостей або цілей.

" RAD Model" (Швидка розробка).

RAD-модель — різновид інкрементної моделі. У RAD-моделі компоненти і функції розробляються кількома командами паралельно, ніби кілька міні-проектів. Тимчасові рамки одного циклу жорстко обмежені. Створені модулі потім інтегруються в один робочий прототип. Синергія дозволяє дуже швидко надати замовнику для огляду щось робоче з метою отримання зворотного зв’язку і внесення змін.

Рис. 4 — RAD-модель

RAD-модель включає наступні фази:

• · Бізнес-моделювання: визначення списку інформаційних потоків між різними підрозділами.
• · Моделювання даних: інформація, зібрана на попередньому етапі, використовується для визначення об'єктів та інших сутностей, необхідних для циркуляції інформації.
• · Моделювання процесу: інформаційні потоки пов’язують об'єкти для досягнення цілей розробки.
• · Збірка програми: використовуються засоби автоматичного складання для перетворення моделей системи автоматичного проектування в код.
• · Тестування: тестуються нові компоненти і інтерфейси.

Коли використовується RAD-модель?

" Agile Model" (Гнучка методологія розробки).

Рис. 5 — Гнучка методологія розробки

У «Гнучкій» методології розробки після кожної ітерації замовник може спостерігати результат і розуміти, задовольняє він його чи ні. Це одна з переваг гнучкої моделі. До її недоліків відносять те, що через відсутність конкретних формулювань результатів складно оцінити трудовитрати і вартість, необхідні на розробку.

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

Методологія використовується:

• · Коли потреби користувачів постійно змінюються.
• · Зміни на Agile реалізуються за меншу ціну через часті інкрементів.
• · Коли для старту проекту досить лише невеликого планування.

" Iterative Model" (Ітеративна модель).

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

На діаграмі показана ітеративна розробка Мони Лізи. Як видно, у першій ітерації є лише начерк Джоконди, у другій — з’являються кольори, а третя ітерація додає деталей, насиченості і завершує процес. У інкрементній моделі функціонал продукту нарощується по шматочках, продукт складається з частин. На відміну від ітераційної моделі, кожен шматочок являє собою цілісний елемент.

Рис. 6 — Ітеративна модель

Як оптимально побудувати ітеративну модель?

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

" Spiral Model" (Спіральна модель).

Рис. 7 — Спіральна модель

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

Спіральна модель передбачає 4 етапи для кожного витка:

• · Планування.
• · Аналіз ризиків.
• · Конструювання.
• · Оцінка результату і при задовільній якості перехід до нового витка.

У сучасній практиці моделі розробки програмного забезпечення багатоваріантні. Немає єдиного вірного для всіх проектів. Методології частково перетинаються в засобах і місцями схожі одна на одну [4].