| 1 | | = Забелешки од првата средба |
| | 1 | = Забелешки од првата средба на 17.10.2017 |
| | 2 | |
| | 3 | '''MODELIO''' - препорачан софтвер за правење дијаграми (др опција е IBM Rational Architecture) |
| | 4 | |
| | 5 | Во наредните две недели: |
| | 6 | 0. Да се напише визија за проектот, Eclipse guidance templates има Vision template; |
| | 7 | 1. Да ги поставиме документите од домашните на wiki кои вклучуваат актери (сите видови корисници на нашиот систем) и кориснички сценарија (use case дијаграми), но за почеток може само drafts од нив на хартија да нацртаме и после ревизијата на компјутер. Потребно е да се разгледа кои работи веќе ги имаме и што ново ќе додадеме. |
| | 8 | 2. Да се прочитаат главите за архитектура и да се разгледа кои од нив би ни користеле нам. |
| | 9 | |
| | 10 | Откако ќе се најавиме на develop.finki.ukim.mk/svr/hsm: |
| | 11 | - Во Рreferences да се смени име |
| | 12 | - CamelCase во WikiFormatting |
| | 13 | |
| | 14 | Да се симне subversion client и потоа: |
| | 15 | - Во IDE како plug in може да го симнеме, потоа ќе внесеме URL и ќе се конектираме; |
| | 16 | - Прво се прави ''check out'' на цело repository и сѐ ќе се симне; |
| | 17 | - Се прават фолдери, фајлови и после само '''update''' и '''commit'''. |
| | 18 | |
| | 19 | === За develop: |
| | 20 | - За да нема конфликти да се прават ''View tickets'' за секоја задача и таму може да има реплики, да се поставуваат рокови и да се дискутира како треба да се направи задачата. На крај треба да се пише дека тикетот е затворен и да се затвори. |
| | 21 | - Во Admin -> Components може да се менуваат string-ови. |
| | 22 | |
| | 23 | === За нултата задача (визијата), да се обрне внимание на следниве делови: |
| | 24 | 1.1. Категорија на решението, што е причина за проектот, во што сме подобри од конкуренцијата...[[br]] |
| | 25 | 1.2. Дискусија на проблемот: што е за кого;[[br]] |
| | 26 | 2.2. Problem statement: кои корисници какви проблеми имаат (positioning target customer);[[br]] |
| | 27 | 3.1. Треба да се вклучи опис на конкурентни производи;[[br]] |
| | 28 | 3.2. Опис на сите учесници (stakeholders): да се напишат одговорностите на секој stakeholder, пр. информации за подобрување на средства, за кого би се подобрило нешто или би се влошило...[[br]] |
| | 29 | 3.3. Users summary: кој од тие stakeholders е реален корисник во системот и која е неговата функција за системот;[[br]] |
| | 30 | 3.4. User environment: каде работат тие корисници, што некој stakeholder ќе ни даде (некој документ);[[br]] |
| | 31 | 3.7. Key stakeholder: клучни потреби кои се, кои луѓе...[[br]] |
| | 32 | 4.* Решение за задоволување на потребите: тука спаѓа и опис на постоечкиот софтвер (која била замислата тогаш, а кои се новите потреби, функционалности и корисници -> нова визија), врски меѓу потреби и функционалности (пр. за тоа и тоа има таква и таква функционалност - модул), всушност од тука произлегуваат use cases од кои потоа произлегува програмирањето use case по use case, бидејќи сѐ правиме за тие конкретни проблеми. |
