Meeskond:Taandarendajad

From ICO wiki
Revision as of 23:31, 1 November 2014 by Kaelias (talk | contribs)
Jump to navigationJump to search

Meeskond

  • Priit Üksküla (projektijuht)
  • Meelis Talvis
  • Kaido Hendrik Elias

Idee

Luua koduse raamatukogu WPF rakendus. Kindlasti peab rakendus vastama juba ülesandepüstituses olevale baasfunktsionaalsusele:

  • Võimaldaks sisestada kodused raamatud
  • Võimaldaks luua laenutajate profiile
  • Raamatuid välja laenutada (tähtajaliselt)
  • Laseks koostada erinevaid aruandeid (kodusolevad raamatud, väljalaenutatud raamatud, tähtaja ületanud laenutused jne)

Lisaks põhinõuetele tuleb funktsionaalsust juurde mõelda :

  • Analüüsida ülesande püstituses välja pakutud lisafunktsionaalsusi - ehk on midagi huvitavat, mida valida?
  • Mõelda ise, millist huvitavat/väärtuslikku lisafunktsionaalsust võiks rakendusele juurde lisada

Kui rakenduse arendamise kõrvalt aega jääb, siis võimalusel luua rakendusele lihtsamat sorti veebiliides

Analüüs

Mida rakendus endas sisaldab?

Loodav rakendus peab võimaldama kasutajatel luua oma privaatset kodust raamatukogu. Kasutajatel peavad olema oma profiilid, võimalus välja laenutada tähtajaliselt oma raamatuid ja ise laenata teiste kasutajate raamatuid, vahendid oma raamatute sisestamiseks ja võimalus erinevate andmete kuvamiseks (näiteks kodusolevad raamatud, väljalaenutatud raamatud, tähtaja ületanud laenutused jne).

Mis on selle eesmärk?

Rakenduse eesmärgiks on anda inimestele võimalus oma kodusele raamatukogule uue elu andmiseks – aastaid kasutuna raamaturiiulis tolmu kogumise asemel võiksid inimesed neid teistele soovijatele välja laenutada. Teisalt pakub rakendus inimestele võimaluse leida laenutamiseks raamatuid, mida nad lähedalasuvatest tavaraamatukogudest ei leiaks. Paljude jaoks võib teiste inimeste käest raamatute laenutamine ka lihtsalt võrreldes raamatukogu külastamisega mugavam tunduda. Alternatiivina saaks rakendust kasutada ka erinevate õppematerjalide jagamiseks (keskkooli eksamivihikud jms) kasutajate vahel nii täidetud kui ka täitmata kujul.

Mida tavakasutaja sellega teha saaks?

Tavakasutajatel on ühelt poolt võimalik sisestada rakendusse oma kodus leiduvaid raamatuid ning pakkuda nende laenutamise võimalust teistele kasutajatele. Teisalt saab rakenduse abil leida teiste inimeste poolt laenutamiseks pakutavaid raamatuid.

Must have

  • Kasutajate profiilid – Kasutajal peab olema võimalik rakenduses endale isiklik profiil luua. Soovi korral peab kasutaja saama ka profiilis muudatusi sisseviia. Profiilis võiks sisalduda :
    • Kasutajanimi
    • Eesnimi
    • Perenimi
    • Vanus (Kuvatakse vastavalt sünniajale, mis jääb privaatseks)
    • Telefoninumber
    • E-posti aadress
    • Raamatukogu suurus (raamatute hulk, mida kasutaja on profiili lisanud)
  • Raamatute sisestamine – Kõik kasutajad peavad saama sisestada ja eemaldada rakendusest oma raamatuid. Sisestada peaks saama järgmiseid andmeid (* kohustuslik) :
    • Raamatu nimi *
    • Raamatu autor *
    • Konkreetse raamatu väljatrüki aasta (kasutajaid võib huvitada konkreetne trükk)
    • Lehekülgede arv (aitab samuti välja selgitada konkreetset trükki)
    • Raamatu seisukord *
    • Kasutajal peab olema võimalik raamatuid mitteaktiivseks teha (eemaldada raamat laenutatavate raamatute nimekirjast ilma, et selle peaks täielikult süsteemist kustutama)
  • Raamatute laenutamine – Kasutajad peavad saama omavahel välja laenata raamatuid teatud tähtajaks. Tähtaja määrab raamatu omanik ning laenamise toimumisega aktsepteerib laenaja etteantud tähtaega. Asjaolu, et raamatu laenamise tehing kahe kasutaja vahel on toimunud, peab olema rakenduses sisestatav ning kontrollitav.
  • Tähtaegade määramine – Kasutajad peavad saama süsteemi sisestada raamatute tagastamise tähtaegu. Raamatute tagastamistähtajad võivad omavahel erineda - mõnda raamatut võib välja laenutada pikemaks ajaks, mõnda aga lühemaks.
  • Aruannete koostamine – Kasutaja peaks saama teha andmebaasi päringuid, mis tagastaks soovitud infot selle kohta :
    • Mis raamatud on kasutaja väljalaenutamiseks oma kodusesse raamatukokku sisestanud
    • Mis raamatud ja milliste tähtaegadega on kasutaja väljalaenutanud
    • Mis raamatuid ja milliste tähtaegadega on kasutaja ise laenutanud
    • Milliste laenatud ja väljalaenatud raamatute tähtaeg on ületatud
  • Ilus, meeldiv ja mugav kasutajaliides – loodav rakendus peaks võimaluste ja oskuste piires hea välja nägema ning mugav kasutada olema. Kindlasti muutuks keeruliseks professionaalse väljanägemisega rakenduse loomine, kuid sellegi poolest tuleb lisaks funktsionaalsuse tagamisele rõhku panna ka disainile ja kasutajakogemusele. See tagab tervikliku rakenduse loomise.

Nice to have

  • Teavitused – Näiteks, kui kasutaja on oma E-posti aadressi sisestanud meie andmebaasi, siis on võimalik saata teavitus laenutähtaja ületamisel automaatselt E-posti aadressile. Samuti võiks ka rakenduse käivitamisel ja sisselogimisel kuvada kasutajale teavitusi selle kohta, kui mõni väljalaenutatud või laenatud raamat hakkab tähtaega ületama või on seda juba teinud.
  • Tagasiside süsteem – Kui kaks kasutajat on omavahel raamatuid laenutanud, siis võiks olla võimalik teise kasutaja profiili tagasisidet jätta. See võiks olla kas hinnang positiivne / neutraalne / negatiivne või lühike kirjalik tagasiside profiili (miks mitte ka mõlemad korraga). Hinnanguid peaks olema võimalik anda ka korduvalt, sest kaks kasutajat võivad tehingut sooritada mitmeid kordi ja iga kogemus on väärt järjekordset tagasisidet. Antud tagasiside peab olema nähtav kõigile teistele kasutajatele. See võimaldab hõlpsasti tuvastada kasutajate usaldusväärsust.
  • Tähtaegade pikendamine – Kasutajatel võiks olla võimalik väljalaenatud raamatute tagastamistähtaega edasi lükata. Kui kaks kasutajat on omavahel kokku leppinud, et raamat tagastatakse hiljem, siis oleks mõlemapoolselt ebameeldiv jääda edasi saama teateid selle kohta, et tähtaeg on ületatud.
  • Raamatute piltide lisamine – Kasutajatel võiks olla võimalik lisada enda raamatute juurde ka pildid. See eeldab aga suuremamahulise andmebaasi loomist.
  • Veebiliides – veebileht, kus on osa rakenduse funktsionaalsusest realiseeritud. Näiteks kasutajate olemasolevate raamatute kuvamine, endale kasutaja loomine või rakenduse allalaadimine.

Milliste osade realiseerimine võib osutuda problemaatiliseks?

Üheks probleemi allikaks on kindlasti rakendust kasutavate kasutajate turvalisus. Keskkond peab olema piisavalt turvaline, et kasutajate andmed oleks kaitstud teiste eest. Selle jaoks tuleb kõik kasutajate andmed krüpteerida.

Teiseks probleemiks on laenutuskohtade määramine. Võib olla ei taha kõik kasutajad oma koduaadressilt raamatuid laenutada teistele vaid soovivad näiteks postiga saata või kasutada kolmandat osapoolt vahendamiseks. Kas on mõtet luua kohale toimetamise meetodite ja asukohapõhist funktsionaalsust või piisab rakenduse mõttes ka lihtsalt teadmisest, et raamat on välja laenutaud (kasutajad saavad suhelda näiteks telefoni teel väljaspool rakendust)?

Probleemiks võib saada ka raamatute tagastamise tähtaegade määramine. Tuleb otsustada, kas tähtaegasid peab saama lisada kalendripõhiselt kuupäeva järgi (vastavalt tagastamise tähtaja kuupäevale pannakse paika ka laenutusperioodi pikkus) või tuleks vastupidiselt kasutada laenutusperioodi pikkuse põhist lähenemist (määratakse, kui kauaks raamatut laenatakse ja vastavalt sellele tekib ka raamatu tagastamise tähtaja kuupäev).

Samuti võib probleemseks kujuneda raamatute tagastamise kindlustamine. Kasutajatele peab jääma mingit sorti turvavõrk olukordadeks, kus laenutatud raamatut ei tagastata õigeaegselt või siis üldse mitte. Antud probleemi likvideerimiseks peaks looma kasutajate vahel mingit sorti laenutuslepingu, mis on kirjeldatud rakenduse kasutamistingimustes (terms of service).

Kuna tegemist on esmakordselt meeskondlikus vormis rakenduse loomisega, siis võib probleemiks osutuda ka tööjaotus. Välja tuleb töötada viis, kuidas jagada koodi erinevate osade kirjutamist meeskonna liikmete vahel. Samuti ei saa grupitööna valmiva rakenduse puhul koodi nö. puusalt tulistades arendada. Sellest tuleneb ka järgnev probleem, millest üle tuleb saada:

Rakenduse arhitektuur tuleb üritada enne arendamise juurde asumist võimalikult täpselt läbi mõelda ja paika panna (klassid - objektid, klassimuutujad, meetodid, back-end ja front-end omavaheline sidusus, andmebaasi tabelid jne.). Selline ettemõtlemine loob aluse selleks, et meeskonna siseselt tööd üldse jaotada saaks.


Logi

23.10.14

  • Meeskonnale wiki lehe tegemine
  • Esmase idee valik ja kirjeldus
  • Visual Studio Online loomine ja kasutajate lisamine (sh. õppejõud)

01.11.14

  • Wikisse analüüsi lisamine