Развој смартфон-апликација

22.08.2025.

Проблематичне ствари у спецификацијама:

1. Усвојите стандардну структуру и будите досљедни

Базирајте се на шаблону: Почните са стандардним SRS шаблоном (нпр. заснованим на IEEE стандардима). Досљедна структура чини ваш документ професионалним и лаким за навигацију. Типичан оквир треба да укључује сљедеће (а било би боље још да је и разрађен):

1. Увод (Сврха, Опсег, Дефиниције)

2. Општи опис (Перспектива производа, Корисничке класе, Радно окружење)

3. Функције система (Ово је срж – детаљно опишите сваку функцију овдје)

4. Захтеви спољних интерфејса (Кориснички, Хардвер, Софтвер, Комуникације)

5. Нефункционални захтеви (Перформансе, Безбједност, Употребљивост)

6. Додаци (Опциони модели података, дијаграми, итд.)

Одржавајте досљедност језика: Пишите цио документ на истом језику. Ако користите енглеске техничке термине (као што су "Firebase", "API", "backend"), користите их доследно. Избјегавајте мјешање језика унутар исте реченице или одељка.

2. Будите специфични, детаљни и недвосмислени

Избегавајте нејазе изразе: Поред фраза као што су "брз одзив", "стабилан рад" или "ажурирање налога" користите оне са специфичним, мјерљивим и тестираним изјавама.

• Слабо: "Апликација мора бити брза." Јако: "Листа догађаја мора се учитати за мање од 1,5 секунди на стабилној 4G вези."

• Слабо: "Запослени може ажурирати кориснички налог." Јако: "Запослени, након скенирања корисниковог QR кода, мора имати могућност да додаје бодове на кориснички налог на основу следеће формуле: Бодови = Износ куповине (у €) * 0,1. Систем мора одмах приказати нову укупну сумму бодова након трансакције."

Детаљно опишите функционалне захтјеве: За сваку функцију, питајте се како ће радити. Немојте само рећи "Корисник може филтрирати догађаје." Наведите:

• Који филтери су доступни? (нпр. по датуму, категорији, локацији, цијени).

• Како се филтер примјењује? (нпр. падајући менији, чекбоксеви, бирач датума).

• Какав је резултат? (нпр. листа се ажурира динамички без поновног учитавања странице).

3. Немојте игнорисати тзв. нефункционалне захтјеве (NFRs)

Ово је најчешћа слаба тачка. NFR-ови дефинишу квалитет система.

Перформансе: Наведите квантитативне метрике за вријеме одзива, вријеме учитавања и капацитет под специфичним условима (нпр. врста мреже, број корисника).

Безбједност: Идите даље од навођења "Firebase Auth". Дефинишите шта штитете и како.

Наведите правила сложености лозинке (нпр. "мин. 8 знакова, једно велико слово, један број").

Поменуто управљање сесијом (нпр. "Корисничке сесије истекну након 30 минута неактивности").

Наведите како су подаци заштићени (нпр. "Сви PII подаци морају бити шифровани у преносу користећи TLS и у мировању користећи AES-256 шифровање").

Употребљивост: Реферишите се на ваш UI/UX дизајн. (нпр. "Корисничко прочеље мора се придржавати нацрта дизајнираних у Figma [Линк ка Figma датотеци]. Нови корисник мора моћи да заврши процес регистрације без упутства за мање од 2 минута").

Поузданост/Доступност: Дефинишите очекивања о времену рада или понашању у случају отказа. (нпр. "Апликација мора елегантно приказати кеширане податке ако је мрежна веза прекинута, са поруком која обавјештава корисника.").

4. Јасно дефинишите спољне интерфејсе

API-ови: Немојте само рећи да ћете користити "REST API". Наведите кључне ендпоинте и њихову сврху (нпр. GET /api/events, POST /api/register/{eventId}). Наведите технологију ако је позната (нпр. Node.js/Express).

Формат података: Експлицитно наведите да ће размјена података бити у JSON формату.

Услуге треће стране: Наведите их и њихову основну функцију (нпр. "Firebase Cloud Messaging (FCM) за push нотификације", "Google Maps API за приказ локација догађаја").

5. Направите рјечник и дефинишите ограничења

Дефиниције (Речник): Направите табелу за дефинисање кључних термина (Корисник, Админ, Недјеља такмичења, Бодови, итд.). Ово елиминише двосмислености за било кога ко чита документ.

Ограничења: Јасно наведите границе пројекта. То су често пословна правила.

Техничка: "Апликација мора подржавати Android 8.0 (API ниво 26) и новије."

Пословна: "Корисников фантази тим не може прећи буџет од 100 милиона евра." (и не буџите буџете као да нико те документе не чита) / "Дозвољено је највише 3 играча из једног стварног тима." / "Корисници су ограничени на 2 трансфера играча по недјељи такмичења."

6. Будите реални у вези опсега и користите дијаграме

Управљајте опсегом: Будите амбициозни, али реални. Боље је у потпуности спецификовати мањи "Минимални одрживи производ (MVP)" него нејасно набројати стотину функција које не можете имплементирати. Јасно наведите шта је укључено у опсег, а шта није за ову верзију апликације.

Користите визуелне приказе: Једноставан дијаграм може уштедити хиљаду ријечи.

Укључите Дијаграм случајева употребе да визуелизујете актере и функције.

Користите нацрте (из Figma) да илуструјете сложене UI токове.

Дијаграм архитектуре који приказује апликацију, backend и базе података је веома вриједан.

Напомена: Свака измјена SRS-a мора да буде документована у наслову као верзија 2.0, 3.0, 4.0, итд.

10.03.2025.

Презентације остављати под одговарајући директоријум, именоване према сљедећем обрасцу: ime_prezime_24-25.

24.02.2025.

Распоред реферата са додијељеним бодовима

10.01.2025.

Рокови за достављање спецификација (SRS-a) документа:

1. рок: од 15. до 25. маја;

2. рок: од  15. до 25. августа;

Достављање спецификација:

• представник групе треба да формира гугл-директоријум, те да колегама дозволи уредничке привилегије како би могли да отпреме своје спецификације;

• форма спецификација није строго одређена, тј. потребно је да сами истражите и одаберете прикладну форму;

• спецификације "качите" као пдф-документе;

• мени се просљеђује веза на поменути гугл-директоријум 22. априла, како бих могао да преузмем SRS-ове.

10.01.2025.

Teрмини испита (прегледање израда пројектних задатака) за академску 2024/25. годину:

• 24.01. у 16:00

• 10.02. у 16:00

• 08.05. у 16:00

• 13.06. у 16:00

• 27.06. 04.06. у 16:00

• 29.08. у 16:00

• 12.09. у 16:00

• 26.09. у 16:00

25.03.2024.

Како је коришћење сервиса ChatGPT постало стандард, ред је да се покуша  са колико-толико ваљаним преводом неких термина:
Чвокић, Д.Д.; Деспотовић, К.; Кораћ, Д. (2024) Приједлог превода основних термина за рад са великим језичким моделима, МАТ-КОЛ, 30(1), 53-68

20.12.2023.

Напомена о темама за дипломске радове.

1. Теме дипломских радова произилазе из пројектних задатака које су студенти имали да ураде на предметима за које сам надлежан. 

2. Формулација теме се врши по консултацији са студентом који је заинтересован за моје менторство у изради дипломског рада.

3. Узимају се у обзир само групни пројектни задаци са предмета Софтверско истраживање (од 2023. г.), Развој мобилних апликација (од 2024. г.), и Структуре података и алгоритми (од 2023. г.).

4. Потребно ме је благовремено обавијестити како би се теме формулисале и додале на списак који одобрава ННВ ПМФа.

5. Менторисање израде дипломског рада подразумјева:

   • Упознавање са проблематиком, одабир референци (литературе и конкретних научних и стручних радова), и савјетовање о могућим путевима реализације како пројектног задатка, те израде дипломског рада, као својеврсне круне рада на пројекту.

   • Надзор реализације практичног дијела, уз консултације са колегама из индустрије (имају се у виду само компаније које имају потписан уговор о сарадњи са ПМФом).

   • Упознавање студента са правилима и формом писања дипломског рада, те приједлог концепта за његов формалан изглед.

   • Преглед и корекције садржаја/текста.

   • Консултације које се односе на израду презентације, излагање, и одбрану дипломског.

6. Теме за дипломске студенти бирају/узимају у посљедњем 8. семестру, при упису у семестар. С друге стране, списак тема које се могу препоручити студентима се доставља ННВу ПМФа на усвајање почетком 7. семестра (почетком академске године). Ово значи да се потенцијални кандидати за дипломски морају одлучити већ крајем 3. године у случају да планирају да раде дипломски под мојим менторством (да разраде свој пројектни задатак). 

14.10.2023.

Пројектни задаци морају бити спаковани са свим пратећим материјалима у зип-архиву именовану према сљедећем обрасцу rma_22-23_ime_prezime_бр. индекса.zip. На примјер, rma_22-23_marko_markovicc_55-21.zip (за Марко Марковић 55/21 у 2022/23. години).