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

Реферат

Пояснительная записка: 54 стр., 9 рис., 3 приложения, 20 источников.

Объект разработки: игровое приложение на базе операционной системы Android с использованием графических библиотек LibGDX.

Цель дипломного проекта: разработать графический модуль для приложения на базе операционной системы Android.

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

В первом разделе речь идет об особенностях девайсов, графических системах и типах игровых приложений. Также описаны методы и средства создания графических систем, и непосредственно описание и особенности среды программирования AndroidStudio.

Во втором разделе описано создание модели графической системы, описание методов и классов графической системы и их реализация в проекте.

В разделе «Экономика» рассчитаны трудоемкость разработки программного обеспечения, расходы на создание ПО и длительность его разработки.

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

Список ключевых слов: ANDROIDSTUDIO, ANDROID, LIBGDX, ИГРА, ИНТЕРФЕЙС, ГРАФИЧЕССКИЙ ДВИЖОК, ГРАФИКА, МОБИЛЬНОЕ УСТРОЙСТВО.

Реферат

Пояснювальна записка: 54 стор., 9 рис., 3 додатка, 20 джерел.

Об'єкт розробки: ігрова програма на базі операційної системи Android з використанням графічних бібліотек LibGDX.

Мета дипломного проекту: розробити графічний модуль для програми на базі операційної системи Android.

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

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

У другому розділі описано створення моделі графічної системи, опис методів і класів графічної системи та їх реалізація в проекті.

У розділі «Економіка» розраховані трудомісткість розробки програмного забезпечення, витрати на створення ПЗ і тривалість його розробки.

Практична значимість проекту полягає у створенні ігрового інтерфейсу для програми Bugs, працюючого однаково на різних мобільних пристроях з операційною системою Android.

Список ключових слів: ANDROIDSTUDIO, ANDROID, LIBGDX, ГРА, ИНТЕРФЕЙС, ГРАФІЧНИЙ ДВИЖОК, ГРАФІКА, МОБІЛЬНИЙ ПРИСТРІЙ.

Abstract

Explanatory note: 54 pages, 9 fig., 3 applications, 20 sources.

The object of the development: the gaming application based on the Android operating system with graphical libraries LibGDX.

The purpose of the diploma project: creation of a fragment of automated information system for of the Dnepropetrovsk area oncological diseases condition analysis.

The introduction describes the communication problems with the object of activity, the problem of the development of graphics systems for a variety of mobile devices.

The first section deals with the peculiarities of devices, graphics systems and types of gaming applications. Also described are methods and tools for creating graphics systems, and direct description and features programming environment AndroidStudio.

The second section describes how to create a graphic model of the system, method, and graphical class systems and their implementation in the project.

In the "Economy" calculated the complexity of software development, the cost of creating the software and the duration of its development.

The practical significance of the project is to create a game interface for the program Bugs, work the same on a variety of mobile devices running Android.

List of key words: ANDROIDSTUDIO, ANDROID, LIBGDX, GAME INTERFACE, GRAPHIC ENGINE, GRAPHICS, MOBILE DEVICES.

Зміст

ПЕРЕЛІК УМОВНИХ СКОРОЧЕНЬ

ВСТУП

1. АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ

1.1 Описання предметної області

1.2 Аналіз ігрових програм

1.3 Операційна система Android

1.4 Архітектура Аndroid

1.4.1 Ядро

1.4.2 Середи виконання ART і Dalvik

1.4.3 Системні бібліотеки

1.4.4 Фереймворк додатку

1.5 Android SDK

1.6 Середа розробки AndroidStudio

1.7 Графічні рушії для створення ігор та додатків

2. ПРОЕКТУВАННЯ ТА РОЗРОБКА ГРАФІЧНОГО МОДУЛЯ

2.1 Постановка та описання задачі

2.1.1 Складання технічного завдання

2.1.2 Описання клієнтської частини

2.1.3 Складання моделі програми

2.2 Розробка алгоритму відображення ігрових об'єктів

2.3 Розробка екранів програми та їх зв'язок

2.3.1 Розробка головного екрану - MainMenuScreen

2.3.2 Розробка ігрового екрану - PlayScreen

2.4 Поєднання ігрових об'єктів з обробкою натискань екрану

3. ЕКОНОМІЧНИЙ РОЗДІЛ

3.1 Визначення трудомісткості розробки програмного забезпечення

3.2 Витрати на створення програмного забезпечення

ВИСНОВОК

Список використаних джерел

ДОДАТОК А ЛІСТИНГ ПРОГРАМИ

ДОДАТОК Б ВІДГУК

ДОДАТОК В РЕЦЕНЗІЯ

ПЕРЕЛІК УМОВНИХ СКОРОЧЕНЬ

OHA - Open Handset Alliance

SDK - Software Development Kit

OS - operating system

ES - Embedded Systems

ІС - інформаційна система

ПЗ - програмне забезпечення

IT - інформаційні технології

МС - модель системи

ВСТУП

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

У міру зростання продаж мобільних пристроїв у всьому світі, зростає і попит на різні додатки для них. Кожна поважаюча себе компанія, прагне мати хоча б один мобільний додаток, щоб бути у свого клієнта "завжди під рукою". А існування деяких компаній і зовсім складно уявити без мобільних пристроїв і спеціалізованих програм, за допомогою яких можна, наприклад, управляти базами даних або стежити за станом свого продукту на ринку в будь-який момент часу.

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

Метою бакалаврського дипломного проекту є «Розробка графічного модуля ігрового Android-додатку Bugs».

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

У виконуваному дипломному проекті бакалавра вирішується завдання проектування графічної системи додатку Bugs і її реалізація за допомогою середовища програмування AndroidStudio, графічного редактора PhotoShop та графічних бібліотек LibGDX.

1. АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ

1.1 Описання предметної області

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

1.2 Аналіз ігрових програм

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

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

Зазвичай ігри в основному класифікуються за жанрами, а також за кількістю гравців. Вони поділяються на кілька типів: квести, екшн, рольові ігри (рпг), файтинги, стратегії, симулятори, логічні та азартні та інші («рис. 1.2»).

Рис. 1.2 Типи ігор

android програмування графічний мобільний

Наразі оглянемо найпопулярніші жанри ігор:

- Квести - здійснюють подорож одного або декількох персонажів до поставленої мети шляхом подолання різноманітних труднощів.

- Екшн (action) - ігри від першої особи - популярні бродилки-стрілялки.

- Рольові ігри або РПГ - гравець виконує роль певного персонажа і виконує поставлені перед ним завдання.

- Стратегії та логічні ігри наслідують діяльності управлінця.

- Симулятор імітують керування автомобілем, космічним кораблем, літаком і т.п.

- Азартні і логічні добре розвивають розумову діяльність.

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

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

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

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

Ігри з відсутністю вибору мають лінійний сюжет (стрілялки). Гравець ототожнює себе з готовим персонажем, вже наділеним характеристиками. Розгалуження сюжету гри залежать не від вибору гравця, а від успіху чи випадковості. В деякі стрілялки можна грати командою. Такі ігри розряджають людини емоційно, а успішне проходження часто залежить від швидкої реакції гравця.

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

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

З боку стратегій в абстракціях головним стає виконання «цілі».

З боку рольових ігор - «підпорядкування».

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

Змістовний склад палітри відеоігор Буденність.

На стику стратегій і бойовиків знаходиться грань «симуляція» («рис. 1.3»). Це повна протилежність «рольових ігор», які борються з «буденністю» цікавим «сюжетом».

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



Рис. 1.3. Межа факторів жанру ігор

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

На стику рольових ігор та бойовиків знаходиться грань «свобода». Це повна протилежність «стратегій», які протиставляють «самотності» «численність» підлеглих у розпорядженні. (Стратегії, звичайно ж, не борються з самотністю в звичайному розумінні, але вони імітують владу - найприйнятніше з видів спілкування).

Для ігор цієї грані характерні великі відкриті простори, відсутність сімуляторной реалістичності, відсутність новизни, відсутність контролю над іншими учасниками.

З боку рольових ігор в «іграх свободи» головним стає відсутність готових рольових зв'язків, можливість самостійного вибору, тобто «рольова свобода».

З боку бойовиків - «спрощення» реальних подій і процесів, у порівнянні з симуляторами.

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

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

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

1.3 Операційна система Android

Android - платформа для мобільних пристроїв яка створена на базі Linux, розроблена бізнес-альянсом OHA, за ініціативою Google. Вона дозволяє створювати Java-додатки, які керують пристроєм за допомогою розроблених бібліотек кампанією Google. Також є можливість писати програми на Сі та інших мовах програмування за допомогою Android Native Development Kit.1.5 (Cupcake) - який створен 30 квітня 2009 року. Серед основних поліпшень з'явилася підтримка запису і перегляду відео в режимі камери; підтримка Bluetooth A2DP; можливість автоматично підключатися до Bluetooth-гарнітурі.

Першим пристроєм, що працює під управлінням Android, став розроблений компанією HTC смартфон T-Mobile G1, презентація якого відбулася 23 вересня 2008 року. Незабаром прослідували численні анонси інших виробників смартфонів про намір випустити пристрої з Android.

У компанії Google виділяють кілька основних переваг, що відрізняють пристрої на базі платформи Android від аналогічних продуктів:

1. Відкритість - Android дозволяє отримати доступ до основних функцій мобільних пристроїв за допомогою стандартних викликів API.

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

3. Рівноправність додатків - для Android немає різниці між основними додатками телефону і стороннім програмним забезпеченням - можна змінити навіть програму для набору номера або заставку екрана.

4. Швидка і легка розробка - в SDK є все, що потрібно для створення і запуску додатків Android, включаючи імітатор справжнього приладу (AVD - Android Virtual Device) і розширені інструменти налагодження.

Гнучкість Android має свою ціну: компанії, які віддають перевагу розробляти власні інтерфейси, змушені постійно гнатися за релізами нових версій ОС. Пристрої, випущені всього кілька місяців тому, стають застарілими, оскільки оператори і виробники не хочуть створювати оновлення ПЗ, щоб користувачі могли застосовувати нові можливості Android. Так, наприклад, багато експертів відзначають, що платформа базується на Java, тому переваги та можливості операційної системи Linux на Android використовуються не повною мірою. Також в платформі не використовується жоден з популярних графічних інструментів (toolkit) і бібліотек (наприклад, Ot або GTK), що робить малоймовірним появу великої кількості додатків, портованих з повноцінного варіанта Linux для домашнього комп'ютера на дану платформу через відсутність за замовчуванням X - сервера і поширених графічних бібліотек. Крім того, з'явилася інформація про те, що Google буде на свій розсуд видаляти додатки з телефонів користувачів, якщо порушуються умови їх використання.

До недоліків платформи можна також віднести і неможливість встановлення деяких програм на карту пам'яті. Це упущення розробників є суттєвим, особливо, якщо у пристрою невеликий обсяг вбудованої пам'яті (наприклад, у T-Mobile G1 він становить всього 70 Мб).

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

Велика частина коду ліцензована під Apache License 2 відкритою і необмеженої ліцензією Допускається вільне використання вихідного коду для створення власних систем. Однак системи, оголошені як сумісні з Android, повинні для початку пройти Android Compatibility Program - процес, що засвідчує базову сумісність зі сторонніми додатками, які створені сторонніми розробниками. Сумісні системи можуть вливатися в екосистему Android, що включає в себе Android Market.

1.4 Архітектура Аndroid

C точки зору програміста, Android - платформа, абстрагує розробника від ядра і дозволяє йому створювати код на Java. Android володіє декількома корисними можливостями. По-перше, це фреймворк, що пропонує великий набір API для створення різних типів додатків і, крім того, що забезпечує можливості повторного використання та заміни компонентів, які пропонуються платформою і сторонніми додатками. По-друге, наявність віртуальної машини Dalvik, що відповідає за запуск додатків на Android. Крім того, наявність набору графічних бібліотек для 2D і 3D-додатків, підтримка мультимедійних форматів (Ogg, MP3, MPEG-4, H.264, PNG, …), API для роботи з камерою, GPS, компасом, акселерометром, сенсорним екраном, джойстиком і клавіатурою. Є навіть спеціальне API для відтворення фонових звукових ефектів, яке знадобиться нам при розробці ігор. Не всі Android-пристрої володіють всіма цими можливостями. Звичайно, список можливостей Android не вичерпується згаданими вище. Однак для розробки ігри вони будуть найбільш важливі. Архітектура Android формується з набору компонентів. Кожен компонент побудований на основі елементів більш низького рівня. На «рис. 1.1» представлений короткий огляд головних компонентів Android.



Рис. 1.1. Огляд головних компонентів архітектури Android

1.4.1 Ядро

Будь операційна система, і Android в тому числі - це набір програм, які керують роботою всього пристрою, і відповідають за запуск додатків, таких як ігри, менеджери файлів, веб-браузери та інші.

Ядро Android є, практично, найголовнішою частиною операційної системи, яка відповідає за взаємодію між всіма «залізом» і програмною частиною системи. Ядро складається з набору драйверів всього наявного в пристрої обладнання та підсистеми управління пам'яттю, мережею, безпекою, та інших основних функцій операційної системи. В нижній частині раніше згаданій ілюстрації - «див. рис. 1.1». видно що ядро Linux пропонує основні драйвери для апаратних компонентів системи. Будь-яке програмне забезпечення потребує того, щоб обладнання планшета або телефону що-небудь зробило, воно звертається за цим до ядра операційної системи. Ядро керує всім обладнанням: Wi-Fi, Bluetooth, GPS, пам'яттю та іншими пристроями. Не є винятком і процесор. Ядро може управляти його частотою і енергопостачанням.

Так як ядро керує всім обладнанням, а обладнання у всіх планшетів і телефонів різне, базове ядро Android допрацьовується виробником для кожного пристрою окремо.

1.4.2 Середи виконання ART і Dalvik

Середовище виконання Android, є надбудовою над ядром і відповідає за породження і виконання додатків Android. Кожна програма працює у власному процесі зі своєю віртуальною машиною (Dalvik або ART).

Dalvik - реєстрова віртуальна машина для виконання програм, написаних на мові програмування Java, яка входить в мобільну операційну сістему Android.

Dalvik оптимізований для низького споживання пам'яті, це нестандартна регістр-орієнтована віртуальна машина, добре підходить для виконання на процесорах з RISC-архітектурою, яка часто використовуються у мобільних та вбудованих пристроях, таких, як комунікатори і планшетні комп'ютери.

Програми для Dalvik пишуться на мові Java. Незважаючи на це, стандартний байт-код Java не використовується, замість нього Dalvik виконує байт-код власного формату. Після компіляції вихідних текстів програми на Java (за допомогою javac) утиліта dx з Android SDK перетворює файли класів (.class) у файли власного формату (.dex), які і включаються в пакет додатки (.apk).

Android Runtime (ART) - середовище виконання Android-додатків, розроблена компанією Google як заміна Dalvik. ART вперше з'явився в Android 4.4 KitKat, в Android 5.0 повністю замінив Dalvik. На відміну від Dalvik, який використовує JIT-компіляцію (під час виконання додатка), ART компілює додаток підчас його установки. За рахунок цього планується підвищення швидкості роботи програм і одночасно збільшення часу роботи від батареї. Для забезпечення зворотної сумісності ART використовує той же байт-код, що і Dalvik.

1.4.3 Системні бібліотеки

Крім бібліотек ядра, що пропонують деяку функціональність Java SE, існує також набір рідних бібліотек на C / C ++, що створюють основу для фреймворку додатку (розташованого на рівень вище, ніж бібліотеки «див. рис. 1.1»). Ці системні бібліотеки в більшості своїй відповідають за складні (промальовування графіки, відтворення звуку, доступ до бази даних), що не дуже підходящі для віртуальної машини Dalvik. API в них обгорнуті за допомогою класів Java під фреймворк додатки, який використовується при написанні ігор.

1.4.4 Фереймворк додатку

Фреймворк додатку пов'язує разом системні бібліотеки та середовище виконання. Фреймворк керує додатками і пропонує продумане середовище, в якому вони працюють. Розробники створюють програми для цього фреймворку за допомогою набору програмних інтерфейсів Java, що охоплюють такі області, як розробка користувацького інтерфейсу, фонові служби, оповіщення, управління ресурсами, доступ до периферії і т.д. Всі ключові програми, що поставляються разом з ОС Android (наприклад, поштовий клієнт), написані за допомогою цих API. Додатки, будь вони з інтерфейсом або з фоновими службами, можуть зв'язуватися з іншими додатками. Цей зв'язок дозволяє одному з додатком використовувати компоненти інших. Простий приклад - програма, яка робить фото-знімок і потім обробна його. Додаток запитує у системи компонент іншої програми, що забезпечує цю дію. Далі перший додаток може повторно використовувати цей компонент (наприклад, від вбудованого програми камери або від фотогалереї). Подібний алгоритм знімає значну частину ноші з програміста, а також дозволяє налаштувати різноманіття аспектів поведінки Android.

1.5 Android SDK

Android SDK (Software Development Kit) використовується для розробки додатків для Android. Він складається з широкого набору інструментів, документації, утиліт і прикладів. У нього також включені Java-бібліотеки, необхідні для створення додатків для Android і містять API для фреймворку програми.

До основних можливостей SDK можна віднести:

1) відладчик, здатний налагоджувати програми, запущені на реальному пристрої або емуляторі;

2) профіль пам'яті і продуктивності, що допомагає виявити витоки пам'яті і знайти неефективний код;

3) емулятор пристрою, заснований на QEMU (віртуальній машині з відкритим кодом, що емулює різні апаратні платформи), він досить точний, хоча не завжди швидкий;

4) утиліти командного рядка для зв'язку з пристроями;

5) скрипти і утиліти для створення пакетів і розгортання додатків.

SDK інтегрований в AndroidStudio - відкрите популярне і функціональне середовище розробки (IDE) для Java. Будь-який хороший SDK повинен супроводжуватися вичерпною документацією. Android SDK не виняток - крім документації з ним поставляється багато прикладів. Крім того, знайти керівництво розробника і повний опис API для всіх модулів фреймворку програми можна на офіційному сайті.

1.6 Середа розробки AndroidStudio

AndroidStudio - середовище розробки, зроблене на основі популярного середовища IntelliJ IDEA Java IDE і володіє тим же набором переваг в частині редагування коду: автодоповнення, рефакторинг, аналіз коду та інше. Останні кілька років Android заохочував розробників використовувати Eclipse ADT (Android Developer Tools) Bundle як середовище для розробки додатків. Ситуація змінилася, коли недавно була анонсована і стала доступна для завантаження Android Studio. Спільноту Android було проінформовано про те, що Android Studio стане офіційною Android IDE. На відміну від ADT Bundle, що базується на Eclipse IDE і системі Apache Ant, Android Studio працює на основі IntelliJ * IDEA і системі Gradle. Незважаючи на те, що основні компоненти та технології значно відрізняються, Android пропонує необхідні інструменти і технологічні схеми для підтримки переходу від використання ADT до Android Studio.

При створенні нового проекту в Android Studio, буде показана структура проекту з усіма файлами, що містяться в каталозі SDK.

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

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

На додаток до всього, нове середовище розробки має функцію Google Cloud Messaging, яка дозволяє вам посилати дані з сервера на Android-пристрою через хмару. Це відмінний спосіб посилати push-повідомлення вашим додаткам.

1.7 Графічні рушії для створення ігор та додатків

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

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

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

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

- Unreal Engine 4,

- Unity 3D,

- Marmalade,

- Project Anarchy (Havok/Intel),

- GameMaker: Studio,

- Corona Game Edition,

- Cocos2Dx,

- AppGameKit,

- libgdx,

- AndEngine.

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

Libgdx - це 2D- і 3D-рушій, який крім Android підтримує Windows, Linux, Mac OS, BlackBerry, iOS і навіть веб. На відміну від багатьох кроссплатформенних середовищ, додатки пишуться на Java, що дуже зручно. Графіка включає API для 2D- і 3D-інтефейс, низькорівневі допоміжні інструменти для OpenGL, а також математичні або фізичні бібліотеки. Підтримуються музичні та звукові ефекти, включені різні допоміжні API - для файлів, переваг і розбору формату файлів. Доступні деякі інструменти для конфігурації проекту, генерації шрифтів і редагування системи частинок. Ігровий рушій libgdx є відкритим і добре підтримується спільнотою. Проект дуже розвинений: він має велику кількість документації і велику галерею додатків і ігор, його використовують, тому став відмінним вибором для рішення поставленого завдання.

2. ПРОЕКТУВАННЯ ТА РОЗРОБКА ГРАФІЧНОГО МОДУЛЯ

2.1 Постановка та описання задачі

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

2.1.1 Складання технічного завдання

Програма Bugs - стратегічна, одиночна гра реального часу. Гра складається з таких елементів:

- ігрова ділянка поділена на сто клітинок , з шириною та висотою - 10 клітинок;

- клітинка ігрової ділянки, як окремий об'єкт з своїми унікальними властивостями;

- жук - персонаж з унікальними властивостями перед іншими можливими жуками, яким може керувати гравець або компьютер, в залежності від тго до якої команди жук входить;

- інформаційна панель - панель с інформацією про стан персонажів та ігри в цілому;

- меню додаткових налаштувань - кнопки для керування опціями додатку.

Ігровий процес повинен поділятися на дві команди: команда користувача, команда комп'ютера. Користувачу надаються можливість керувати положенням «жука» переміщуючи його по клітинкам. Незалежно від кроків користувача, комп'ютер також буде переміщувати свого «жука». Для кожної з сторін буде виділятись задана кількість жуків.

Під час кроку «жука», клітинка на яку він попадає окрашається в колір жука. Таким чино в процесі гри всі клітинки повинні окраситись в кольори граючих команд.

Кожен «жук» має обмежену кількість кроків за гру, яка віднімається при кожному кроку. На ігровій ділянці можна знайти поповнення кількості ходів, а також можливе їх віднімання за рахунок присутності ворожих жуків.

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

Програма Bugs повинна складатись з двох екранів:

1) Головне меню (MainMenuScreen) - початковій, інформаційний екран при запуску програми. На початковому екрані відображені навігаційні елементи-кнопки для початку ігри або виходу с програми.

2) Ігровий екран (PlayScreen) - основний екран - екран ігрового процесу.

2.1.2 Описання клієнтської частини

Для розробки додатку необхідно визначити які елементи необхідно відобразити та визначити основі положення в грі. Виходячи з технічного завдання на ігровому екрані (PlayScreen) будуть відображатися такі елементи:

1) «Жук» - основний елемент ігрового екрану. Повинен відображатися у декількох кольорах, для кожної команди свій.

2) Клітинка ігрового поля - середовище для переміщення «Жука». Повинен відображатися в декількох кольорах так само як і «жук», також можливе змінення зображення клітинки якщо вона містить бонуси для «жуків».

3) Панель стану жука - інформаційна панель з переліком характеристик виділеного жука.

4) Фон - зображення для ігрового екрану (PlsyScreen).

Користувач може взаємодіяти тільки з «жуками», керуючи їхнім переміщенням, в рамках положень:

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

2) «Зміна жука» - якщо у гравця не виділений жоден з його жуків, після чого повернення до режиму «Крок».

3) «Кінець гри» - якщо закінчився запас кроків у всіх «жуків» гравця, або комп'ютера.

2.1.3 Складання моделі програми

В рамках дипломного проекту розробка програми була поділена на дві частини:

1) Розробка поведінкової моделі об'єктів програми;

2) Розробка графічної системи програми.

Для того щоб об'єднати поведінкову і графічну частину програми, була побудована діаграма класів «рис. 2.1», по якій велися б подальші розробки обох частин програми.



Рис. 2.1 - Діаграма класів програми

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

Пращурами всіх об'єктів які будуть відображатися на ігровому екрані являється class Actor з бібліотеки LibGDX. Об'єкти які будуть відображатися на ігровому екрані являються «див.рис. 2.1»:

- Bug - відображається як персонаж «жук»;

- WorldCell - відображається як клітинка поля;

- Buffs - відображається як посилюючі бонусі для «жуків»;

- StatusBar - інформаційна панель жука;

- BackgroundActor - фони екранів.

Усі інші об'єкти моделі являються зв'язками між об'єктами відображення, тим самим створюючи систему відображення.

2.2 Розробка алгоритму відображення ігрових об'єктів

Головним об'єктом гри являється клас MyGdxGame. Він реалізує інтерфейс ApplicationListener. Це спеціальний інтерфейс, в якому є певні методи, які викликаються в певні моменти. Такі методи називаються бекендом. Таким чином, якщо ми хочемо перенести гру на іншу платформу (наприклад, blackberry), нам потрібно написати бекенд для blackberry. Бекенда відповідає за роботу не тільки з графікою - це і звук, введення, файлова система, та інші платформо-залежні деталі. Коли ми хочемо запустити гру - ми передаємо об'єкт класу, який реалізує інтерфейс ApplicationListener в потрібний клас бекенда. У потрібні моменти бекенд і викликає ці методи «(рис. 2.2)».



Рис. 2.2 - Екземпляр класу MyGdxGame

Основною графічною одиницею є текстура. За цією гучною назвою ховається звичайна картинка, збережена в пам'яті особливим чином - так, щоб комп'ютеру було зручно з нею працювати. Тобто, зі звичайної .png або .jpg картинки ми можемо отримати текстуру. LibGDX використовує стандарт OpenGL для текстур. Приклад створення текстури «жука»:

bug_texture = new Texture("bug.png");

Sprite = new Sprite(bug_texture);

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

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

Бувають моменти, коли малювати всю текстуру нам не потрібно. TextureRegion - це частина текстури. Відповідно, для його створення нам потрібно вказати текстуру і координати ділянки, яку необхідно вирізати. Є кілька причин по яким необхідні регіони текстур. По-перше, картинка не завжди буде ступенем двійки - вона може бути довільного розміру, а розміри текстури, повинні бути кратні ступеню двійки. По-друге, продуктивність. OpenGL так влаштована, що при відображенні текстури вона повинна «прив'язатися» (спеціальна OpenGL операція). Це коштовна (в сенсі машинного часу) операція, і часте переключення текстур може серйозно вдарити по продуктивності програми. Тому необхідно мінімізувати кількість текстур в грі, використовуючи атласи текстур. Атлас текстур - це велика текстура, де розміщені потрібні зображення. Потім, використовуючи регіони текстур, ми отримуємо з атласу потрібні зображення. Це досить виснажлива операція - розміщувати вручну потрібні картинки в текстурі, а потім вирізати їх. Тому для цих цілей створюються спеціальні інструменти. Для LibGDX теж є такий інструмент - він називається Gdx Texture Packer «(див.рис. 2.3)», який використовується в цьому проекті. Методика пакування зображень використовується для зберігання різних кнопок меню та для різних видів клітинок ігрового поля.



Рис. 2.3 Інтерфейс інструменту Gdx Texture Packer

Всі відображені об'єкти є акторами. Все ігрове поле - сценою. У кожного актора є свої певні властивості: розмір, положення на екрані, видимість (можуть бути і невидимі актори), кут обертання. Сцена - це та невидима частина, де знаходяться всі актори. Таким чином, концепція акторів і сцени - це зручний спосіб розбити всю гру на незалежні (відносно) частини, які взаємодіють один з одним.

Actor - це абстрактний клас, який сам по собі даремний. За замовчуванням, він не малює себе, він невидимий. Нам потрібно створити новий клас, успадкований від Actor, і перевизначити метод draw().

Список основних методів актора:

- setX (), setY (), setPosition () - ці три методи встановлюють положення актора щодо батька. Батьком може виступати як сцена, так і інший, актор під назвою Group.

- setWidth (), setHeight (), setSize () - ці методи встановлюють розміри.

- setScaleX (), setScaleY (), setScale () - масштаб. Перші два встановлюють масштаб по горизонталі і по вертикалі. Виклик третього встановлює однаковий масштаб і для горизонталі і для вертикалі. Тобто, виклик setScale (0.5f) аналогічний викликом setScaleX (0.5f), setScaleY (0.5f).

- setRotation () - встановлює кут повороту в градусах.

- setOriginX (), setOriginY (), setOrigin () - точка, навколо якої буде обертатися і масштабуватися актор. Точка задається щодо розмірів актора. Наприклад, якщо розміри актора (100, 100), то виклик setOrigin (50, 50) встановить точкою обертання і масштабування в центр актора.

Всі дії вимальовування відбуваються в методі create (): створення нового актора, установка розмірів і координат підключення його до сцени.

2.3 Розробка екранів програми та їх зв'язок

За технічним завданням була розроблена модель взаємодії екранів MainMenu та PlayScreen яка показана на «рис. 2.4».

Рис. 2.4 - Алгоритм взаємодії екранів програми

При старті програми одразу завантажується MainMenuScreen де користувачу надається вибір - розпочати гру або закрити програму. При виборі «розпочати гру», здійснюється перехід за екрану головного меню до ігрового екрану (PlayScreen). Після закінчення гри за умовами ігрового процесу або при достроковому закінченню, надається вибір - закрити програму або повернутися до вибору головного меню.

Як видно на діаграмі класів «див.рис. 2.1», екрани PlayScreen та MainMenuScreen виступають в якості середовища для малювання яке зберігається в центральному класі - MyGdxGame. Цей клас поєднує графічну та логічну системи гри в єдине ціле. Він зберігає всю інформацію про стани об'єктів таких як «жук» або «клітинка», а також зберігає інформацію про середовище малювання об'єктів, та при певних умовах поєднує ці данні, цим самим створюючи картинку на екрані пристрою.

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

2.3.1 Розробка головного екрану - MainMenuScreen

На стадії проектування було вирішено що екран головного меню має містити такі об'єкти:

- кнопки «Розпочати гру», «Завершити програму»;

- фонове зображення;

- логотип програми;

- звукове супроводження.

Екран MainMenuScreen не оперує ігровою інформацією. Його єдина необхідність - переключання екранів програми, або завершення програми. За цих умов, екран головного меню має тільки бібліотечні об'єкти такі як:

- TextButton, Button - кнопки меню;

- Table - об'єкт налагодження позицій візуальних об'єктів таких як Button, Label, та інші;

- Skin - набір властивостей ( шрифт, колір, розмір, та інші) для об'єктів як Button, Label та інші;

- Sound - об'єкт для зберігання і програвання аудіо файлів.

За технічним завданням було створено 2 кнопки «(рис. 2.5)»: кнопка переходу на екран PlayScreen, кнопка выходу з програми.

Рис. 2.5 - Навігація екрану MainMenuScreen.

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

2.3.2 Розробка ігрового екрану - PlayScreen

Ігровий екран або PlayScreen відображає всі елементи ігрового процесу. Все створені об'єкти ігрового процесу ( Bug, WorldCell, …) групуються в класі World («див.рис. 2.1») який в свою чергу передаються до PlayScreen. Таким чином, всі актори які згруповані в World, додаются до акторського списку в PlayScreen. За технічним завданням, акторами PlayScreen являються:

- клас Bug;

- клас WorldCell;

- клас Buffs;

- клас StatusBar;

- клас BackgroundActor.

Всіх акторів споріднює функція «draw(Batch, float);» Ця функція зберігає в собі команди які вимальовують зображення актору. В якості параметрів функція приймає Batch - кисть яка вимальовує зображення, та float - прозорість актору. В тілі функції, функцією «Sprite.draw(Batch);» додаються до кисті (Batch) оголошені спрайти (Sprite), які потім вимальовується «(рис.2.6)».

Рис. 2.6 - Тіло функції draw для StatusBar

Шлях до зображення яке заноситься до спрайту, вказується при оголошенні актора, функцією: Sprite <Ім'я змінної> = new Sprite( new Texture( "<шлях>")).

private Sprite BackGround = new Sprite(new Texture("StatusBar_BG.png"));

private Sprite SpeedIcon = new Sprite(new Texture("Srpeed.png"));

private Sprite HealthIcon = new Sprite(new Texture("Health.png"));

private Sprite PowerIcon = new Sprite(new Texture("Attack.png"));

Для класу Bug було вирішено використовувати одну чорно-білу текстуру, та перекрашувати її колір на колір в залежності від того до якої команди входить жук.

public void draw(Batch batch, float alpha) {

setColor(Name);

Sprite.setOriginCenter();

Sprite.setSize(bound.getSize(),bound.getSize());

Sprite.setPosition(bound.getX(), bound.getY());

Sprite.draw(batch);}

Для класу WorldCell було вирішено застосувати технологію з використанням класу TextureRegion. Для відображення клітинок ігрового поля, в графічному редакторі PhotoShop було створено зображення-карту з десятком різних варіантів клітинок. За допомогою класу TextureRegion за зображення виймаються випадкове зображення клітинки та привласнюється об'єкту WorldCell.

Texture CellTexture = new Texture(Gdx.files.internal("stones.png"));

int TextureElementWidth = CellTexture.getWidth()/5;

int TextureElementHeight = CellTexture.getHeight()/2;

int TextureElementX = TextureElementWidth * new Random().nextInt(5);

int TextureElementY = TextureElementHeight * new Random().nextInt(2);

Sprite = new Sprite(new TextureRegion(CellTexture, TextureElementX, TextureElementY, TextureElementWidth, TextureElementHeight));

Об'єкт StatusBur створений з множини зображень та системи відображення цифрової інформації. Всі зображення відтворюються за подібною системою як в Bug або WorlCell, але цифрове зображення являється грубою спрайтів які знаходяться в масиві з відносними один до одного координатами. Для цього використана система TextureRegion з зображеннями цифр від нуля до дев'яти.

BTextSymbol (int Number) {

Texture NumberTexture = new Texture ( Gdx.files.internal ("Numbers.png" ));

int TextureElementWidth = NumberTexture.getWidth()/10;

int TextureElementHeight = NumberTexture.getHeight();

int TextureElementX = TextureElementWidth * Number;

int TextureElementY = 0;

this.Number = new Sprite(new TextureRegion (NumberTexture, TextureElementX, TextureElementY, TextureElementWidth, TextureElementHeight));

this.Number.setColor(Color.YELLOW);

Останні об'єкти BackgroundActor та Buffs налаштовані точно так же як і елементи WorlCell.

public void draw(Batch batch, float alpha) {

backgroundSprite.draw(batch); }

public void draw(Batch batch, float alpha) {

if (WorKing) {

Sprite.setOriginCenter();

Sprite.setSize(bound.getSize(), bound.getSize());

Sprite.setPosition(bound.getX(), bound.getY());

Sprite.draw(batch); } }

В результаті отримано екран PlsyScreen до сцени якого додано перелічені об'єкти, і в результаті виглядає як зображено на «рис. 2.7».



Рис. 2.7 - Зображення екрану PlayScreen

2.4 Поєднання ігрових об'єктів з обробкою натискань екрану

У libGDX можливості введення зосереджені в модулі Input. Для цих цілей в libGDX є інтерфейс InputProcessor. Необхідно створити клас, який реалізує цей інтерфейс, і передати екземпляр цього класу в Gdx.input.setInputProcessor ().

Gdx.input.setInputProcessor(stage);

Gdx.input.setCatchBackKey(true);

Так само існує інтерфейс - EventListener. Цей клас «вміє» обробляти події введення - приблизно як InputProcessor. Він теж реалізує відомий патерн проектування - слухач. Особливість - можна призначити кожному акторові свого слухача і обробляти свої події.

public boolean addListener (EventListener listener);

public Array<EventListener> getListeners();

Event - це подія. У цьому класі міститься безліч інформації - який актор, яка подія, координати події і інше. Для нас представляє інтерес клас InputListener. Він реалізує інтерфейс EventListener і має декілька інших методів, майже аналогічних інтерфейсу InputProcessor.

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

buttonPlay.addListener(new ClickListener() {

public void clicked(InputEvent event, float x, float y) {

sound_button.play();

((Game)Gdx.app.getApplicationListener()).setScreen(new PlayScreen(game)); }});

buttonExit.addListener(new ClickListener() {

public void clicked(InputEvent event, float x, float y) {

sound_button.play();

Gdx.app.exit();}});

Таким чином, можна «фільтрувати» і не допускати небажані події до цільового акторові. Другий етап - ця ж подія передається цільовим акторам, а потім, якщо потрібно, передається вниз до кореневого актора. Таким чином, capture listeners потрібні для того, щоб фільтрувати події і не допускати деякі до цільового акторові. Звичайні ж слухачі потрібні для нормальної обробки подій.

3. ЕКОНОМІЧНИЙ РОЗДІЛ

3.1 Визначення трудомісткості розробки програмного забезпечення

Q - передбачуване число операторів (1340);

q - коефіцієнт складності програми (1,2);

p - коефіцієнт корекції програми в ході її розробки (0,05) ;

B - коефіцієнт збільшення витрат праці внаслідок недостатнього опису задачі(1.5);

K - коефіцієнт кваліфікації програміста, обумовлений від стажу роботи з даної спеціальності(1.2) ;

Спр - середня годинна заробітна плата програміста з нарахуваннями(20) ;

Смч - вартість машинного часу ЕОМ (7 грн / год) ;

Bk - число розробників (дорівнює 2) ;

Fp - місячний фонд робочого часу ( при 40-годинному робочому тижні Fp= 176 годин) .

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

t = tО + tИ + tА + tП + tОТ + tД, людино-годин (3.1)

де:

- tО - витрати праці на підготовку й опис поставленої задачі (приймається 50);

...