Hankeleping Astangu uue veebilehe loomiseks

Kinnitused Käesolevaga kinnitab pakkuja riigihangete seaduse (RHS) § 95 lg 1 p 1- 5 sätestatud hankemenetluse k õrvaldamise aluste puudumist: Kinnitame, et Pakkujat või Pakkuja haldus-, juhtimis- või järelevalveorgani liiget või muud seaduslikku või asjaomase riigihankega seotud lepingulist esindajat ei ole karistatud kuritegelikus ühenduses osalemise, aususe kohustuse rikkumise või korruptiivse teo, kelmuse, terroriakti toimepaneku või muu terroristliku tegevusega seotud kuriteo või sellele kihutamise, kaasaaitamise või selle katse, rahapesualase süüteo või terrorismi rahastamise eest; Kinnitame, et Pakkujat või Pakkuja haldus-, juhtimis- või järelevalveorgani liiget või muud seaduslikku või asjaomase riigihankega seotud lepingulist esindajat ei ole karistatud riigis ilma seadusliku aluseta viibivale välismaalasele töötamise võimaldamise eest; Kinnitame, et Pakkujat või Pakkuja haldus-, juhtimis- või järelevalveorgani liiget või muud seaduslikku või asjaomase riigihankega seotud lepingulist esindajat ei ole karistatud laste tööjõu ebaseadusliku kasutamise või inimkaubandusega seotud teo eest; Kinnitame, et Pakkujal ei ole riikliku maksu, makse või keskkonnatasu maksuvõlga maksukorralduse seaduse tähenduses või maksu- või sotsiaalkindlustusmaksete võlga Pakkuja asukohariigi õigusaktide kohaselt; Kinnitame, et Pakkuja või Pakkuja haldus-, juhtimis- või järelevalveorgani liige ei ole rahvusvahelise sanktsiooni subjekt rahvusvahelise sanktsiooni seaduse tähenduses. Oleme teadlikud, et hankijal on õigus eeltoodud asjaolude õigsuse kontrollimiseks sooritada päringud riiklikesse registritesse ning kontrollida esitatud kinnituste õigsust muul viisil. /allkirjastatud digitaalselt/ Marko Leppik Juhatuse liige Trinidad Wiseman Oü Vastavuskinnitused Pakkuja andmed Pakkuja nimi / Ühispakkujate volitatud esindaja nimi Trinidad Wiseman Oü Registrikood 11244225 Aadress Akadeemia tee 21/4, 12618 Tallinn, Estonia Kontaktisik ja tema andmed Peeter Ossip Telefon 5169171 Elektronposti aadress [email protected] Kodulehekülg www.twn.ee 1. Pakume ennast teostama käesolevat riigihanget ja kinnitame, et oleme tutvunud hanke tingimustega ja meil on olemas rahalised vahendid hankelepingu täitmiseks. 2. Kinnitame, et võtame üle kõik hanketeates, hankedokumentides ja selle lisades esitatud tingimused ja esitame pakkumuse üksnes kõigi nend e asjaolude kohta, mille kohta H ankija soovib pakkumusi. 3. Kinnitame, et meil on intellektuaalse omandiga seotud hankelepingu täitmiseks vajalikud intellektuaalse omandi õigused. 4. Kinnitame, et kõik käesolevale pakkumusele lisatud dokumendid moodustavad meie pakkumuse . Juhul kui hanketingimustes on nõutud meeskonda, siis kinnitame, et pakkumuses esitatud meeskonnaliikmed osalevad hankelepingu täitmisel. 5. Kinnitame, et pakkumus on jõus hanketeates määratud minimaalse tähtaja jooksul . 6. Aktsepteerime Hankija õigust lükata tagasi kõik pakkumused hankedokumentides kirjeldatud juhtudel , sh kui pakkumuste maksumused ületavad Hankija planeeritavat eelarvet . 7. Anname nõusoleku meie poolt esitatud andmete või dokumentide õigsuse kontrollimiseks järelpärimiste tegemiseks kolmandatele isikutele ja nõustume, et Hankija võib kolmandatelt isikutelt saadud dokumendid ja andmed võtta käesoleval riigihankel otsuste tegemisel aluseks. 8. Kinnitame, et oleme nõus hankemenetluses edastatavate dokumentide elektroonilise kättetoimetamisega. Pakkuja ärisaladuse määramine 1. Pakkuja ärisaladuse ulatus RHS § 111 lg 5 kohaselt on pakkuja ärisaladuse piiritlemine pakkuja pädevuses. Trinidad Wiseman OÜ (edaspidi: pakkuja) avaldab, et käesolev pakkumus (sealhulgas pakkumuse lisad) ja pakkuja poolt muul viisil hankijale hankemenetluses avaldatud teave moodustab tervikuna pakkuja ärisaladuse. Pakkumus ja pakkumuse lisad ei moodusta pakkuja ärisaladust osas, milles pakkuja on käesoleva dokumendiga ärisaladuse sõnaselgelt välistanud. Kooskõlas RHS § 111 lg-ga 5 avaldab pakkuja, et pakkuja ärisaladuse hulka ei kuulu: a) pakkumuse maksumus ja osamaksumus osas, milles see on pakkumuste hindamise kriteeriumiks; b) pakkumuste hindamise kriteeriumitele vastavad pakkumust iseloomustavad numbrilised näitajad. Ärisaladusega hõlmatud teabe avalikustamine toob kaasa pakkuja subjektiivsete õiguste olulise riive, majandusliku kahju ning nõudeõiguse teabe avalikustaja vastu. 2. Ärisaladuseks määramise põhjendus Pakkuja ärisaladusena määratud teave vastab järgmistele kriteeriumitele: a) teave on saladus selles tähenduses, et see ei ole kogumis või üksikosade täpses paigutuses ja kokkupanus üldteada või kergesti kättesaadav nende ringkondade isikutele, kes tavaliselt kõnealust laadi teabega tegelevad; b) teabel on kaubanduslik väärtus selle salajasuse tõttu; c) pakkuja on teabe üle seaduslikku kontrolli omava isikuna võtnud kasutusele vajalikke meetmeid, et hoida seda salajas. Pakkuja ärisaladusena määratud teave vastab intellektuaalomandi õiguste kaubandusaspektide lepingu (nn TRIPS leping) artikli 31 lg-s 2 nimetatud teabele, mille osas peab pakkujal olema võimalus takistada tema seadusliku kontrolli all oleva teabe avaldamist teistele või selle omandamist või kasutamist teoste poolt pakkuja nõusolekuta. Pakkuja ärisaladusena määratud teave vastab ärisaladuse definitsioonile, mis on esitatud Euroopa Parlamendi ja nõukogu direktiivis (EL) 2016/943, milles käsitletakse avalikustamata oskusteabe ja äriteabe (ärisaladuste) ebaseadusliku omandamise, kasutamise ja avalikustamise vastast kaitset (direktiivi artikkel 2). Hankemenetluses osalemise eelduseks on pakkuja poolt teatud ärisaladuse avaldamine hankijale. Ärisaladuse hankijale teatavaks saamine ei vabasta hankijat direktiivi 2016/943 kohaselt talle ärisaladuse omaja poolt edastatud teabe konfidentsiaalsuskohustuse ja ärisaladuse kasutamise piirangu järgimise kohustusest. Direktiivi 2016/943 preambuli p-s 18 viidatakse, et konfidentsiaalsuskohustus hõlmab muuhulgas kohustusi seoses avaliku sektori hankijale hankemenetluste raames edastatud teabega, nagu on sätestatud Euroopa Parlamendi ja nõukogu direktiivis 2014/23/EL, Euroopa Parlamendi ja nõukogu direktiivis 2014/24/EL ning Euroopa Parlamendi ja nõukogu direktiivis 2014/25/EL. Riigihangete valdkonna direktiivid kinnitavad hankija kohustusi ärisaladuse kaitsel. Direktiivi 2014/24/EL artikli 21 kohaselt ei avalikusta avaliku sektori hankija talle ettevõtjate poolt edastatud konfidentsiaalsena märgitud teavet, sh tehnika- või ärialaseid saladusi ja pakkumuste konfidentsiaalseid aspekte. Piirang ärihuve kahjustavale andmete avaldamisele on esitatud ka direktiivi 2014/24/EL artikli 55 lg-s 3. Riigikohtu praktika kohaselt ei ole konkurentsiseaduse § 63 lg-s 1 esitatud ärisaladuse definitsioon väljaspool Konkurentsiameti haldusmenetlusi kohaldatav (vt nt Riigikohtu lahend kohtuasjas 3-1-1-46-09). Kahtluse vältimiseks kinnitab pakkuja siiski, et käesoleva dokumendi kohaselt ärisaladusena määratud teave vastab konkurentsiseaduse § 63 lg-s 1 nimetatud kriteeriumitele. Tegemist on teabega pakkuja äritegevuse kohta, mille avaldamine teistele isikutele võib pakkuja huve kahjustada. 3. Selgitus pakkuja poolt hankemenetluses täiendavalt esitatava teabe kohta Kui pakkuja ei ole edasises infovahetuses sõnaselgelt väljendanud vastupidist, on pakkuja poolt järgnevas hankemenetluses ja hankelepingu sõlmimisel esitatav teave pakkuja ärisaladus. Pakkuja märgib edasises teabevahetuses sõnaselgelt ära selle teabe või dokumendid, millele pakkuja ärisaladus ei laiene. 4. Selgitus hankija poolt hankemenetluses täiendavalt kogutava teabe kohta Pakkuja ei välista, et hankija kogub hankemenetluses pakkuja või pakkumuse kohta iseseisvalt täiendavat teavet. Mistahes hankija poolt täiendavalt kogutavale teabele, mis vastab direktiivi 2016/943 artiklis 2 esitatud ärisaladuse definitsioonile, laienevad hankemenetluses ärisaladuse käitlemise nõuded. Kui hankija asub seisukohale, et täiendavalt kogutav teave ei vasta mingis osas ärisaladuse definitsioonile ja selle avaldamine teistele isikutele või avalikkusele võib olla lubatud, taotleb pakkuja sellekohase kinnituse küsimist pakkujalt. Teabe avaldamine pakkuja kinnituseta ärisaladuse puudumise kohta võib tuua kaasa hankija poolt ärisaladuse avaldamise ja pakkuja subjektiivsete õiguste olulise riive. 5. Hankija kohustused ärisaladusega hõlmatud teabe käitlemisel Pakkuja poolt ärisaladuseks määratud teave ei kuulu avaldamisele teabepäringu alusel, samuti vaide- või kohtumenetluses. Hankija on kohustatud korraldama töö ja hankemenetluse läbiviimise viisil, mis välistab ärisaladuse avaldamise teistele isikutele. RHS § 47 lg 5 alusel jätab hankija ettevõtjate teavitamisel oma otsusest esitamata teabe, mille avaldamine rikuks ettevõtjate ärisaladust või kahjustaks konkurentsi. RHS § 83 lg 6 alusel jätab hankija hankelepingu sõlmimise teates märkimata teabe, mille avaldamine rikuks ettevõtjate ärisaladust või kahjustaks konkurentsi. RHS § 113 kohaselt ei avalikusta hankija pakkumuste sisu selles osas, mille pakkuja on pakkumuses ärisaladusena märkinud. RHS § 138 sätestab kõrgetasemelist kaitset nõudva ärisaladuse kaitseks erisused kontsessioonilepingu sõlmimisel. Avaliku teabe seaduse § 31 lg 3 kohaselt peab teabe üldiseks kasutamiseks andmisel olema tagatud ärisaladuse kaitse. Avaliku teabe seaduse § 35 lg 1 p 17 kohaselt on teabevaldaja kohustatud tunnistama asutusesiseseks kasutamiseks mõeldud teabeks teabe, mille avalikustamine võib kahjustada ärisaladust. Võimalikus vaidlustusmenetluses ja sellele järgnevas kohtumenetluses on hankijal kohustus tagada, et ärisaladusena määratud teave ei saaks teatavaks teistele menetlusosalistele ja kohustus esitada selleks vajalikud taotlused (nt taotluse esitamine menetluse kinniseks kuulutamiseks teatud dokumentide või teabe osas). Pakkuja on valmis hankija päringu korral andma ärisaladust puudutatavates küsimustes täiendavaid selgitusi.  Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomise pakkumus Tellija Tervise ja Heaolu Infosüsteemide Keskus Täitja Trinidad Wiseman OÜ Uus-Tatari 25, 10134 Tallinn Akadeemia tee 21/4, Tallinn Tel +372 7943 900 Tel +372 63 11 111 E-post: [email protected] E-post: [email protected] 2018 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine Sisukord 1 Pakkuja lühitutvustus ................................................................................................................................... 4 2 Projekti eesmärk ja ulatus ............................................................................................................................ 6 2.1 Eesmärk ............................................................................................................................................... 6 3 Platvormi valik - Drupal ja selle eelised ........................................................................................................ 6 3.1 Headless Drupal .................................................................................................................................. 8 3.2 Drupali Turvalisus ................................................................................................................................ 9 3.3 Drupali kasutusmugavus ..................................................................................................................... 9 4 Tööprotessid, metoodika ja meeskond ...................................................................................................... 11 4.1 Metoodika ......................................................................................................................................... 11 4.1.1 Projektijuhtimine ja koostöö ........................................................................................................ 11 4.1.2 Dokumentatsioon ......................................................................................................................... 13 4.1.3 Sisuhaldustarkvara kasutuselevõtt ............................................................................................... 13 4.2 Meeskond ......................................................................................................................................... 14 5 Visioon ........................................................................................................................................................ 16 5.1 WCAG 2.1 nõuete ja kasutusmugavuse järgimine ............................................................................ 20 5.2 Lahenduse arhitektuur ja FE raamistiku valik ................................................................................... 20 5.3 Drupali arhitektuur, moodulid ja arenduse optimeerimine ............................................................. 20 5.3.1 Loodava süsteemi tõlkimine ......................................................................................................... 20 5.3.2 Lehe optimiseerimine lõppkasutaja jaoks .................................................................................... 21 5.3.3 Veebilehe leitavuse optimeerimne............................................................................................... 21 5.3.4 Veebivormid.................................................................................................................................. 21 5.3.5 Sisu loomine, erinevad teema lehed ............................................................................................ 22 5.4 Lahenduse Turvalisus ........................................................................................................................ 22 6 Lahenduse hooldus ja garantii.................................................................................................................... 23 6.1 Hooldus ............................................................................................................................................. 23 6.2 Garantii.............................................................................................................................................. 23 7 Riskide halduse tegevuskava ...................................................................................................................... 25 7.1 Riskijuhtimise protsess...................................................................................................................... 25 7.2 Riskikäsitlus ....................................................................................................................................... 26 7.3 Tüüpilised riskid tarkvaraarenduses.................................................................................................. 26 8 Tööde elluviimise ajakava ja eelarve koos põhiliste protsesside ning tööde kirjeldusega ......................... 31 8.1 Töö etappide ja protsesside detailsed kirjeldused ............................................................................ 34 8.1.1 Uue kodulehe analüüsimine ja struktureerimine ......................................................................... 34 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine 8.1.2 Kasutajaliidese disainimine .......................................................................................................... 38 8.1.3 Arendus, testimine ja dokumentatsioon ...................................................................................... 47 8.1.4 Kasutusjuhend ja koolitus ............................................................................................................. 51 3 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine 1 Pakkuja lühitutvustus Trinidad Wiseman on Baltimaade suurim kasutajakogemuse-, e-teenuste disaini ja ärianalüüsi ettevõte ning üks suurimaid ja tuntumaid Drupali arendajaid Eestis. Omame märkimisväärset veebiarenduse, teenusedisaini, kasutajakogemuse disaini ning süsteemi- ja ärianalüüsi kogemust, mistõttu oleme kindlad, et suudame pakkuda kvaliteetset ja ootustele vastavat lahendust. Tarkvaraarenduses on meie tugevaim külg rätseplahenduste loomine Drupalile ja liidestamine erinevate infosüsteemidega. Enam kui 11-aastane kogemus näitab, et suudame rahuldada ka komplitseeritumad nõudmised. Tänaseks on meie käe all valminud sadu veebilehti, poolsada infoportaali ja kliendisüsteemi. Panustame pikaajalistele kliendi- ja partnerlussuhetele. Trinidad Wisemanis töötab tänaseks üle 78 spetsialisti ning me omame ISO 9001:2015 sertifikaati. Käive tuhandetes eurodes 4400 4200 4000 3800 3600 3400 3200 3000 2800 2600 2400 2200 2000 1800 1600 1400 1200 1000 800 600 400 200 0 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 Joonis 1 Trinidad Wiseman OÜ käibe kasv Meie klientideks on muuhulgas: Eesti avalik sektor: Maksu- ja Tolliamet, Päästeamet, Maanteeamet, Patendiamet, Tartu linn, Tallinna linna ettevõtlusosakond, Keskkonnainvesteeringute Keskus (KIK), Riigi Infosüsteemi Amet (RIA), MKM, EAS, SMIT , 4 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine Siseministeerium, Kaitseministeerium, Riigikantselei, Töötukassa, E-tervise SA, PERH, Välisministeerium, Riigikantselei, Eesti Kunstimuuseum jpt. Euroopa Liidu ja erinevate riikide asutused: Afganistani IT ja Kommunikatsiooni Ministeerium, Euroopa Väljaannete Talitus, Euroopa Elu- ja Töötingimuste Parandamise Fond (Eurofound), Euroopa Energiaregulaatorite Koostööagentuur (ACER) Telekommunikatsioon: Telia, Elisa, Skype. Finants ja kindlustus: TransferWise, Bigbank, If P&C Insurance, ERGO, Swedbank, SEB Pank. Logistika: Elron, Tallink, Omniva. Kaubandus: Tallinna Kaubamaja, Selver, Santa Maria. Arendus: Tieto, Nortal, Helmes, TripleDev, Fujitsu, Net Group, Mindware, Celsius Healthcare. Muud: Eesti Energia, Elering, Kvatro, Minirent, Kohtutäiturite- ja Pankrotihaldurite Koda. Meie põhitugevused: • analüüs — kasutajanõuete analüüs, süsteemi- ja detailanalüüs, äri- ja eelanalüüs; • e-teenuse, iseteeninduse, füüsilise teenuse ja kasutajaliidese kasutajakogemuse disain; • kasutatavuse mõõtmine, testimine ja hindamine ning digitaalne juurdepääsetavus; • sihtrühmade vajaduste, motivatsiooni ning käitumise uurimine; • front-end ja back-end arendus (Drupal, NodeJS jt); • eri platvormide liidestamine; • arenduse ja testimise automatiseerimine; • testimine nii virtuaalsete kui füüsiliste seadmetega. Meil on pikaajaline infosüsteemide, iseteeninduste, portaalide ja veebirakenduste loomise kogemus. Meie projektideks on mh olnud: • Sotsiaalkindlustusameti infosüsteemi SKAIS2 kasutajakogemuse disain ja analüüs; • City24.ee kasutajakogemuse disaini ja front-end arenduse tööd; • Tallinki e-lahenduste kasutajakogemuse väljatöötamine mobiilist desktopini; • Elisa e-lahenduste kasutajakogemuse väljatöötamine; • Telia e-lahenduste kasutajakogemuse väljatöötamine, sh digi-TV lahendused; • SMITi turvakriitiliste infosüsteemide analüüs, kasutajakogemuse disain ja front-end arendus 5 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine 2 Projekti eesmärk ja ulatus 2.1 Eesmärk Käesoleva hanke eesmärgiks on luua uus turvaline ja jätkusuutlik platvorm www.astangu.ee kodulehele, mis oleks kasutajamugav nii kliendile kui ka haldajatele. Pakume Tellijale kasutajasõbralikku ja kvaliteetset tarkvaraarendamise sh analüüsi teenust. Kasutame parimaid väljatöötatud metoodikaid ja tänapäeva moodsamaid tehnilisi lahendusi, et tagada parimat arenduseprotsessi kulgu. Järgnevates peatükkides tutvustame lühidalt valitud sisuhaldustarkvara, kirjeldame portaali loomise ja juurutamise tegevusi, riskide haladmist ja töömahtu ning projektiplaani. 3 Platvormi valik - Drupal ja selle eelised See pakkumus on tehtud Drupal1 vabavaralisele platvormile. Drupal ei ole lihtsalt tavaline sisuhaldustarkvara (CMS) vaid on pigem CMF ehk sisuhalduse raamistik ‘framework’, mis annab paindlikkuse ehitada suuremat süsteemi, sobides hästi rätseplahendusteks. Samas on selle administreerimise liides lihtne, loogiline ja intuitiivselt kasutatav. Samuti on Drupal võimekas liidestamiseks kolmandate süsteemidega. Seetõttu on ta eriti levinud just avalikus sektoris ning suurettevõtete seas. Joonis 2 aadressilt: https://cms2cms.com/uncategorized/what-cms-will-be-your-choice-in-2017-facts-and-figures/ Mõned kokkuvõtvad eelised, mis on Drupal tarkvaral võrreldes konkureerivate platvormidega: • Avatud lähtekoodiga veebiarendusplatvorm (sisuhaldussüsteem); • Võimekas ehitamaks suuri veebiportaale; 1 http://www.drupal.org/ 6 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine • Sisaldab vajalikke töövahendeid sisu loomiseks ja avaldamiseks. • Kasutajate autentimine ja erinevate kasutajarollide õiguste määramise võimalus; • Mitmekeelsuse haldamine sisulehe malli vaates; • Nii disain, HTML vaated kui ka arendus on hästi kohandatavad. WYSIWYG tekstiredaktor; • Laiaulatuslik API tugi ja lihtne ühildada 3 osapoolte teenuse pakkujatega: Facebook, Twitter, Google Apps, Google Analytics, YouTube, või arendaja enda poolt loodud kohandatud API jne; • Administreerimise keskkond on tõlgitav; • Paindlik sisuarhitektuur; • Ühe platvormi kaudu on võimalik hallata väga palju veebilehti; • Skaleeruv ehk mobiilisõbralik (vahemikus 5-5000 sisulehte); • Töötab klassikalisel LAMP serveril e Linux, Apache, MySQL ja PHP; • Drupali kasutamine ei nõua litsensitasusid; • Tuhanded lisamoodulid (16 000+), mis on tasuta alla laaditavad sh turvalisuse tugi, CRM-tugi, sotsilaameedia tugi, back-up tugi; • Aktiivne arendajaskond koos suurte firmadega nagu nt Sony jt toel; • Paindlik ja modulaarne struktuur (CMF) võimaldab arendada täpselt nii nagu kliendile vaja; • Turvaline (PCI compliant), nt kasutab seda whitehouse.com; • Väga hea SEO tugi; • Drupalit kasutavad ja usaldavad suured firmad ja organisatsioonid nagu Ameerika Valge Maja (WhiteHouse.gov), McDonalds, Sony, Zappos, CNN, UN jpt. Vabavara puhul on oluline, kui suur on selle levik ja kui aktiivne on vabatahtlike kogukond, kes selle arendamisega tegeleb. Mitte ühelgi CRM vabavaral ei ole sellist kasutajate baasi ja arendajate kogukonda kui seda on Drupalil. Seda toetab rahvusvaheline professionaalsete arendajate ja võimekas entusiastide kogukond, mis tagab tarkvara elujõulisuse, innovaatilisuse ning on platvormi populaarsust üha kasvatanud. Kõik need silmapaarid aitavad hoida Drupali turvalisena ja töötavad selle nimel, et pakkuda kasutajatele rohkem võimalusi ja suurendada kasutajamugavust. Drupal on stabiilne tehnoloogia, mis on ehitatud turvalisust silmas pidades. Drupalit on võimalik konfigureerida nii, et andmepanga krüptreering vastab kõige rangematele turvalisuse nõuetele. Drupalile on võimalik lisada moodul, mis muudab ligipääsu IP põhiseks. Erinevalt paljudest teistest vabavara platvormidest ei ütle Drupal kasutajale, kuidas asju peab tegema, vaid kasutaja saab Drupalile öelda mida ja kuidas on vaja. Drupalil on paindlik sisuarhitektuur, on võimalik määrata, mida üks või teine kasutaja vaadata ja muuta saab. Drupal on äärmiselt paindlik ja vajadustele kohaldatav. Sellega on võimalik ehitada eripalgelisi lahendusi ning Drupalit on võimalik liidestada väga paljude teiste veebiaplikatsioonidega. 7 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine Joonis 3 aadressilt https://www.commercialprogression.com/post/drupal-vs-wordpress-true-cost-opensource-cms- comparison 3.1 Headless Drupal Eraldiseisev Drupali ehitusmetoodika on headless Drupal (vahel kutsutakse ka decoupled Drupaliks). See on metoodika, kus Drupali backend haagitakse lahti frontend loogikast. Külastajatele nähtav osa tehakse kasutades mõnda levinud javascript raamistikku (nt. Angular, Vue.js) ja Drupali hooleks jääb sisuhaldamine ja admin kasutajaliides. Nii on võimalik ehitada väga paindlikke frontende. On tugi nii REST API kui ka GraphQL’ile Liskas pakub headless Drupal mitmeid eeliseid klassikalise Drupal 8 ees: Näiteks lihtsustatud uuendamise protseduuri. CMS uuendus ei mõjutaks külastajatele nähtavat osa, ainult CMS-i. Vigade tuvastamine on lihtsam kuna tegemist ei ole enam ühe suure monoliitse raamistikuga, erinevad osad eristuvad üksteisest selgemini. Lahendust on lihtsam tugevdada regressiooni vastu. Muudatused backendis ei lõhkus enam nii lihtsalt frontendi. Selgem tööjaotus backendi ja frontendi vahel. Backeend ei peaks puutuma CSS’i ja frontend ei peaks muretsema Composeri pärast. Võimalik töötada modulaarselt ja muudatusi kiiremini live lükata. Frontend ja backend võivad töötada samaaegselt ühe vaate kallal, ilma üksteise tööd segemata. Veebilehed avanevad külastaja jaoks kiiremini. Väheneb vajadus lehte muudatuste jaoks taaslaadida (refreshida). 8 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine 3.2 Drupali Turvalisus Drupali kogukonnal on 34. vabatahtlikust koosnev rahvusvaheline turvameeskond, kes tegeleb haavatavuste otsimisega proaktiivselt ja avastatud turvaaukudele paikade kiire loomisega. Ettevõtted usaldavad Drupalit, seda peetakse turvalisemaks kui teised populaarsed CMS’id. Usalduse üks põhjuseid on turvaaukude kiire avastamine ja paikamine. Kõige viimase pahavaraga nakatunud veebisaitide statistika järgi nakatunud Drupali saitide arv väheneb, samas kui näiteks nakatunud Wordpressi lehtede arv suureneb. Joonis 4 aadressilt https://sucuri.net/reports/2017-hacked-website-report 3.3 Drupali kasutusmugavus Drupali haldamine ja sisu loome ei ole teistest CMS’idest keerulisem. Drupal võib esmapilgul näida võrreldes näiteks Wordpressiga kompleksema raamistikuna, see komplekssus garanteerib aga suurema paindlikkuse ja kasutusmugavuse. Sellest paindlikkusest võidavad ka sisu sisestajad, sest sisu sisestamine on võimalik ehitada kasutaja jaoks võimalikult mugavaks. Drupal 8-nda versiooni arendamisel pandi suurt rõhku kasutajaliidese mugavamaks tegemisele, see töö kandis vilja ja on jätkuv. Drupali kogukonnas on töögrupp, mille liikmed suhtlevad aktiivselt, viivad läbi seminare, konverentse, laagreid ja hackathone, seda kõike eesmärgiga muuta Drupalit veelgi kasutajasõbralikumaks. 9 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine Drupal 8. tuumaga tulevad kaasa mitu moodulit, mis suurendavad selle kasutajamugavust. Näiteks „BigPipe“ moodul, mis kasutab Facebooki poolt leiutatud tehnoloogiat, et kuvada lehekülgi kiiresti isegi aeglase internetiühenduse korral. Portaali administraatori poolt kasutatav kasutajaliides kohandub ekraani suurusega, nii on portaali sisu võimalik täiendada ka näiteks nutitelefoniga. „Quick Edit“ moodul võimaldab portaali haldajatel sisu muuta kiiresti, otse külastajale avaneva vaate kaudu. Mitmekeelsus on Drupali tuuma sisse ehitatud, lihtsustades tõlgete lisamist. WYSIWYG editor pakub teksti sisestamiseks Microsoft Wordist tuttavat tööriistariba. See on põgus ülevaade mugavustest, mida Drupal pakkub. Drupalist kokkuvõtvalt • Tegemist on laialdaselt levinud ja tasuta sisuhaldussüsteemiga. • Sisuhaldussüsteem vastab kõikidele tehnilises kirjelduses esitatud nõuetele • Sisuhaldussüsteem on lihtsa ja loogilise ülesehitusega. Oleme Drupaliga sõbrad juba 6. versioonist alates. On mitmeid põhjuseid miks valida just Drupal. See on avatud, paindlik, kasutajasõbralik, skaleeruv, stabiilne ja turvaline platvorm, millel puuduvad litsentsitasud. Drupal toimib pea igas serveris, on häid standardeid järgiv ja kogub aina enam populaarsust ka Eestis. 10 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine 4 Tööprotessid, metoodika ja meeskond Alljärgnevates punktides toome välja metoodika, tööprotsessi ja meeskonna üksikasjad, mis võimaldab garanteerida parima võimaliku lahenduse arvestades hanke piire: 4.1 Metoodika Töid tehakse agiilset arendusmetoodikat jälgides. Täpsed põhimõtted ja tegevused lepitakse Tellijaga kokku enne vastavate töödega alustamist. Sobivad praktikad ning põhimõtted valime tuntud ja kasutatud agiilsetest arendusmetoodikatest nagu Scrum, KanBan ja Lean. Omades pikaajalist kogemust eeltoodud metoodikate ja põhimõtetega, oskame soovitada ka Tellijale erinevaid prakitkaid eeltoodud kogumitest. Rakendatav tööprotsess koosneb alati järgmistest osadest: • projekti rollid ja vastutusalad; • töö tseremooniad (regulaarsed koostöö vormid sh koosolekud, kõned, vestlused jms); • tööde tulemid (sõltuvad paljuski hanke nõuetest); • ajalised raamid tööde teostamiseks (vajalik protsessi ohjamiseks). Tööde tegemisel arvestame Tellijalt eelnevalt Täitjale teatavaks tehtud huve, lähtudes tõhususe, kvaliteedi, säästlikkuse ja otstarbekuse põhimõtetest ning arvestades vastavas tegevusvaldkonnas kehtivaid õigusakte, standardeid ja head tava. Pakkumuse aluseks on hankedokument ning selle lisad. Projekti realiseeritakse iteratiivselt ja ei läbita kõiki protsesse alati järjest, vaid mitmed protsessid võivad toimuda paralleelselt ja erinevate protsesside juurde võidakse vajaduse korral arendusprotsessis tagasi pöörduda. Pakkumise raames realiseeritavate süsteemide puhul on plaanis alustada alati detailanalüüsist ning sealt saadud sisendi alusel teha paralleelselt HTMLiseerimine ja arendustööd. Kõik protsessid toetavad üksteist ja annavad jooksvalt täpsustavaid nõudeid kuni lõplike nõuete vormistamiseni. Kui nõuded vastavad Tellija vajadustele, antakse need sisendina arendusse. Arenduse käigus võib osutuda vajalikuks nõuete täpsustamine, mis tehakse rangelt eelneval Tellija ja Täitja vahelisel dokumenteeritud kokkuleppel. 4.1.1 Projektijuhtimine ja koostöö Edukaks tööprotsessiks Tellijaga tuleb kokku leppida kliendipoolne kontaktisik, kelle poole saaks protsessis tekkivate küsimustega esmajoones pöörduda. On väga oluline, et kontaktisik tunneb töörühmade liikmeid, oskab anda vajalikke kontakte ja aitab töid teostaval meeskonnal planeerida koosolekuid ja tööplaani. Sellisel juhul saab arendusmeeskond töötada kõige efektiivsemalt ja suuremahulisest osalejate ringist ei teki takistusi projekti ajakavas püsimisele. Samas oleme avatud ja meeleldi kaasame igapäevasesse suhtlusse ka arendajaid, et saaks operatiivselt ja otse suhelda, kuna tihti saavad mured ja küsimused niiviisi kiiremini lahendatud. 11 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine Kõik süsteemi arenduse lähteülesanded (kasutuslood) koos lisafailidega lisatakse analüüsi tulemina töödehalduse tarkvarasse, kuhu tekib arendustööde jaoks prioritiseeritud backlog. Peame väga oluliseks, et arendustööde etapis kliendi ja pakkuja kontaktisikud (projektijuhid) kohtuksid vähemalt kord iteratsiooni jooksul (minimaalselt kord kahe nädala jooksul), et vaadata üle eelmise iteratsiooni tööd ning selle tulemid. Tekkinud probleemid või kõrvalekalded projektiplaanis fikseeritakse veahalduse tarkvaras ja lepitakse kokku lahendused. Iga iteratsiooni lõpus lepitakse kokku järgmise itratsiooni tööd ja vaadatakse alati üle ka paari järgmise nädala planeeritavad tööd. See võimaldab tagada samaegselt ka teiste kaasatud süsteemide arenduse sujuvuse. Iteratsiooni planeerimine käib backlogi alusel, mis on prioritiseeritud nii, et iga iteratsiooni tulemusena valmib iseseisev väärtusloov komponent, mida tellijapoolne projektijuht saab testida ning kokkuleppelisel ajal või kujul formaalselt vastu võtta. Veahaldustarkvarast saab arendusprotsessi jooksul igal ajahetkel kõige operatiivsema ülevaate arenduse seisust, kuna seal saab jälgida arenduses oleva iteratsiooni realiseerimise seisu, tekkinud probleeme ja lahenduskäike. Lisaks saab seal tutvuda järgmiste planeeritud töödega. Lisaks kasutame operatiivseks suhtlemiseks elektroonilisi kiirsuhtluskanaleid (nt Skype või Tellija soovil Slack), kuhu on võimalik kaasata terve projektietapi meeskond või teha meeskonna funktsioonide-põhiseid vestlusi. Täpne töökorraldus lepitakse kokku projekti käivitamisel, lähtudes hankedokumendis kirjeldatud nõuetest. Rollid ja vastutusalad Projekti edukaks läbiviimiseks on vajalik lisaks hankes välja toodud projektimeeskonna erinevatele rollidele (projektijuht, analüütik, arhitekt, arendaja, testijate jt) ka Tellija ja Pakkuja koostöö erinevates projektiorganisatsiooni struktuurides. Järgnevalt on väljatoodud erinevad projektiorganisatsiooni rollid nende vastutusalad ja tööpõhimõtted: Projekti meeskond/töörühm — Projekti meeskonda kuuluvad Tellija poolsed projektiga igapäevaselt seotud isikud (projektijuht, valdkonna spetsialistid, jt) ning Pakkuja poolne projektimeeskond (pakkumusest lähtuvalt). Iga meeskonnaliige vastutab temale määratud töölõigu eest, esindab projekti projekti juhtrühmalt saadud volituste piires ja teeb kõik võimaliku projekti edukaks õnnestumiseks. Projekti meeskond töötab igapäevaselt koos, et saavutamaks kokkulepitud eesmärke ning kasutab koostööks erinevaid meeskonnatöö vahendeid ning muid parimaid praktikaid. Projekti meeskonna igapäeva töö tulemid ja väljundid on vastavalt Tellija soovile kajastatud veebipõhises töödehaldussüsteemis. Projekti juhtrühm — Juhtrühma kuuluvad mõlema osapoole projektijuhid ja vajadusel n UX disainer. Juhtrühm vastutab projekti toimivuse ja lõppeesmärgi saavutamise eest. Juhtrühma peamine eesmärk on koordineerida Tellija ja Pakkuja vahelist koostööd sh kinnitada detailsed iteratsioonide tegevusplaanid, võtta vastu ja kontrollida iteratsioonide tulemeid, hinnata jooksvalt projekti riske ja olukorda. Projekti juhtrühm kinnitab täpse projekti tööplaani (ajaline plaan koos tegevustega) ning annab projekti käigust aru projekti nõukogule (minimaalselt iga arendusetapi eel ja järel, kuid vajadusel tihemini). Juhtrühm käib koos vähemalt kord kahe nädala jooksul sh jooksvad juhtimise teemad lahendatakse vastavalt vajadusele sobivate suhtlus kanalite abil. Projekti nõukogu — Vajadusel luuakse Projekti nõukogu, kuhu kuuluvad Tellija ja Pakkuja poolsed organisatsiooni esindajad (lisaks projektijuhtidele soovitavalt projektiga igapäevaselt mitte seotud sõltumatud Tellija ja Pakkuja esindajad). Projekti nõukogu peamiseks eesmärgiks on jälgida sõltumatult 12 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine projekti käiku, olla kursis erinevate suuremate otsuste ning kuludega. Nõukogu teeb vajadusel ettepaneku meeskonna muutmiseks ja vajadusel ka projektijuhi välja vahetamiseks. Projekti nõukogu on olemuselt sõltumatu järelvalvet teostav organ, kes saab projekti juhtrühmalt sisendinformatsiooni projekti käigust. Nõukogu pädevuse on lahendada ka erinevad riskide realiseerumisest tekkida võivad väljakutsed, mis projektimeeskonna volitusi ületavad. 4.1.2 Dokumentatsioon Tööde üleandmisel esitame Tellijale hankes nõutud dokumentatsiooni, mis vastavad etapi spetsiifikale. Lisatööna saame pakkuda ka muid dokumente, näiteks: • UX tööde tulemid (nt prototüüp); • arhitektuuridokument; • testiplaan; • testlood; • testraportid; • automaattestide skriptid; • ligipääsetavuse nõuete täitmise raport; • tarkavara paigaldusjuhend; • tarkvara pakett; • kasutusjuhend. • Varundus ja taasteplaan • Nõuete vastavustabel Tarkvara administreerimise juhend kirjeldab lahti põhilised toimingud ning juhendit on hea kasutada abimaterjalina nii läbiviidava koolituse juures kui ka hiljem, kui Tellijal tuleb uutele sisuhalduritele kasutusel olevat tarkvara tutvustada. 4.1.3 Sisuhaldustarkvara kasutuselevõtt Sisuhaldustarkvara administratiivkasutajate koolitamise kuupäevad lepime kokku projekti käivitamisel. Koolituse viib läbi projektijuht ühiselt arendus- ja analüüsitiimi liikmetega. Drupali sisuhalduse administreerimise juhendi koostame paralleelselt arenduse lõppjärgu töödega ning täiendame vastavalt vajadusele kogu portaali loomise vältel. 13 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine 4.2 Meeskond Võttes arvesse projekti iseloomu ja ajakava, kuuluvad meeskonda erinevates etappides minimaalselt: projektijuht, veebidisainer, kasutusmugavusspetsialist, analüütik, testija ning arendaja (front-end ja back-end) Erinevad rollid projektis teevad omavahel tihedat koostööd ja eesmärgiks on tagada vajaliku töö tegemine kokkulepitud tähtajaks ilma kvaliteedi pealt järeleandmisi tegemata. Lisaks pakutud spetsialistele töötab Trinidad Wisemanis veel mitmeid sama kvalifikatsiooniga kasutajakogemuse disainereid, analüütikuid, graafilisi disainereid, front-end ja back-end arendajaid mistõttu on meil võimalik vajadusel ka rohkem eksperte kaasata. Kogu meeskonna puhkusegraafikud ja vajadusel meeskonna asendused kooskõlastatakse esimese etapi esimestel nädalatel. Pakkumuses on arvestatud meeskonna puhkustega ja sellest kaasnevate võimalike riskidega ning meeskond on asendatav puhkuse ajal samaväärse teise spetsialistiga. Kõik meeskonna vahetused kooskõlastatakse vastavalt hanke nõuetele. Oleme projekti meeskonda valinud inimesed, kes on varasemalt kokku puutunud sarnaste projektidega ning on oma profiililt kõik juhtivad spetsialistid. Kõik projekti pakkujapoolsed meeskonnaliikmed teavitavad takistuste tekkimisel sellest projektijuhti või vajadusel teisi projekti meeskonna liikmeid. Projektijuhi rollis oleva spetsialisti ülesanne on muuhulgas lahendada kriitilisel teel olevate tegevuste teostamise takistusi, võimalusel kiirendada sellel teel olevat ooteaega ning jälgida projekti kulgu võimalike tekkivate takistuste seisukohast. Lisaks korraldab projektijuht projekti kommunikatsiooni erinevate osapoolte vahel – saadab tegevuste ning koosolekute kohta informatsiooni ning jagab informatsiooni tehtud otsuste kohta. Projektijuht kontrollib kokkulepete täitmist ning aitab lahendada võimalikke takistusi nende täitmisel. 14 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine Pakkuja meeskonna rollid ja vastutusalad on järgmised: • Projektijuht — jälgib tööde ajakavas püsimist ja lahendab tööde läbiviimise töökorralduslike küsimusi. Projektijuht tagab projekti läbiviimise ja meeskonnatöö ülesannete täitmise koos projekti meeskonnaga ning koordineerib ülesannete täitmist. Pakkuja projektijuht tagab Pakkuja ülesannete ja kvaliteetse täitmise vastavalt hankelepingule. Pakkuja projektijuht korraldab projektirühmade üld-, teemapõhiseid ja erakorralisi koosolekuid: valmistab ette päevakava ja vajalikud töömaterjalid koostöös ja kooskõlastatuna Tellija poolse kontaktisikuga, juhib koosolekuid, korraldab protokollimise ja vastuvõetud otsuste täitmise. Spetsialist: Peeter Ossip • Analüütik— analüüsib ja disainib ärilisi vajadusi ning probleeme tehnilises vaates. On projekti üks võtmeisikutest tööde planeerimisel ja prototüübi loomisel. Spetsialist: Rene Rebane • Graafiline disainer/veebidisainer - realiseerib kasutajaliidese graafilise disaini tööd, mis valmivad vastavalt teostatud kujundusmallidele. Spetsialist: Johhanna Loomets • UX disainer/kasutajakogemuse analüütik — teeb kasutajauuringuid, prototüübib, viib läbi kasutatavuse teste. Spetsialist: Johhanna Loomets • HTML programmeerija ehk front-end arendaja — realiseerib kasutajaliidese visuaalse funktsionaalsuse vastavalt kujundusele ehk teostab HTMLiseerimise tööd vastavalt kujundusvaadetele. Spetsialist: Jelena Pavlova • Programmeerija ehk back-end arendaja — Drupal programmeerija täiendab ja arendab edasi olemasolevat keskkonda luues uusi mooduleid, sisutüüpe ja funktsionaalsusi. Enne tööde/taski üleandmist testib programmeerija ja veendub, et soovitud tulemus on elluviidud, mis oli planeeritud. Back-end arendaja loob stsenaariumid ning edastab selle testijale. Spetsialist: Risto Mitt • Testija — vastutab testimisega seotud protsessi ja tulemite eest. Spetsialist: Tanel Tromp 15 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine 5 Visioon Kodulehe kujundust iseloomustavad märksõnad avar, õhuline, professionaalne, rõõmsameelne. Kasutatud on logo värve kombineerituna valge tausta ja musta tekstiga. Lehekülgede liigendus on selgelt eristatud värvide ja suurte pealkirjadega. Kontrastsed värvid ja suured pealkirjad toetavad teksti head loetavust. Lehe päis on lihtne ja minimalistlik ning sisaldab lisaks menüüle otsingut, keelevalikut ning viiteid sisupuule ja vaegnägijate valikutele (kontrasti muutmine ja teksti suuruse valmine). Avalehel (vaade 1) järgneb navigatsioonile Astangu keskuse olemust tutvustav illustreeriv pilt ja keskuse põhilised tegevusvaldkonnad. Järgmine sektsioon annab erinevatele kasutajatele võimaluse läheneda informatsioonile vastavalt tema sihtrühmale. Välja on toodud suurimad ja olulisemad teemadegrupid. Siinkohal on oluline mainida, et tegemist on näidetega. Materjalide põhjalikum läbitöötamine ja analüüs selgitab välja tegelikud vajadused. Edulood kirjeldavad keskusega seotud inimeste õnnestumisi ja positiivseid kogemusi. Sündmuste, sotsiaalmeedia ja uudiste sektsioon annab lehe külastajale kiire ülevaate keskuse tegemistest. Jaluses on kiirviited keskusega seotud üldteemadele, uudiskirjaga liitumine, sotsiaalmeedia lingid ning keskuse kontaktid. Avalehe loomisel lähtusime vajadusest, et kõige olulisemad teemad ja teenused oleksid kasutajatele kiiresti ja mugavalt leitavad. 16 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine Vaade 1 - Avaleht 17 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine Alamlehel (vaade 2) on aktiivne menüüpunkt selgelt eristatud ning asukoht veebilehel on välja toodud ka leivapuru abil. Vasakpoolne tulpmenüü on sarnane praegusele kodulehel kasutatud menüüle, et kasutajakogemus oleks tuttav. Samuti on säilinud artiklivaate üldstruktuur. Artiklivaate teemade juurde saab lisada vastava kontaktisiku, vajadusel mitu, et kasutaja pöörduks küsimuste tekkimisel õige spetsialisti poole. Siinkohal tuleb rõhutada, et antud peatüks olev kirjeldus ning vaadete näited on visioon, mis põhineb eelneval kogemusel taolistel projektide loomisel, kuid seal puudub korralik kasutaja uuring ning vajaduste kaardistamine. Selleks, et saaksime välja pakkuda lõpp-kasutajatele parima lahenduse tuleks järgida peatükis 8 Tööde elluviimise ajakava koos põhiliste protsesside ja pakutavate tööde kirjeldus kirjeldatud tegevusi. Lähutvalt tulemustest saame kirjeldada plokid, navigatsiooni ning sealt edasi prototüübi ja visuaali. 18 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine Vaade 2 - Sisuleht 19 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine 5.1 WCAG 2.1 nõuete ja kasutusmugavuse järgimine Jälgime WCAG 2.1 AA taseme suuniseid (soovituslikud suunised alates 05. juunist 2018), mille laiem eesmärk on veebilehtede üldise kvaliteedi ja kasutajamugavuse tõstmine. Nõuete järgimine aitab muuta veebilehe selgemaks, struktuursemaks ja kasutajasõbralikumaks. Parem juurdepääsetavus aitab erivajadustega veebilehe kasutajal vajalikku informatsiooni kiiremini ja mugavamalt kätte saada ning kasutada veebilehte samaväärselt teiste interneti kasutajatega. Suuniste järgimine teeb veebilehe paremini kasutatavaks ka teistele, näiteks vanematele inimestele, algajatele arvutikasutajatele, välismaalastele, aga ka kasutajatele, kellel on aeglane internetiühendus või kes kasutavad vanema riistvara või veebisirvimise tarkvaraga arvuteid. 5.2 Lahenduse arhitektuur ja FE raamistiku valik Sobivaima platvormi valime koos kliendiga analüüsi käigus ja sõltun näiteks sellest, kas kujunduslikult on sobivam Front-end tehnoloogiates kasutame n SASS’i. Erinevaid kolmandate osapoolte JS pluginaid soovime kasutada võimalikult vähe, et leht oleks koodi osas minimalistlik, kiire ja tomiks sujuvalt eri seadmetel. 5.3 Drupali arhitektuur, moodulid ja arenduse optimeerimine Drupali moodulite valikul otsime võimalikud optimaalseid lahendusi aga oskame olla ka kriitilised. Hindame moodulite sobivust loodavasse süsteemi, hetke staatust (beta), populaarsust, turvalisust ja tulevikukindlust jne. Kasutame nii palju kui peab ja nii vähe kui võimalik lisamooduleid. Uute lisamoodulite arendusel järgime turvalisust, kiirust ja head tava. Lisaks enne igat Drupali mooduli/vaate arendust analüüsime, et kuidas saame tagada veebi sisutekstide, menüüde, alajotiste jms kõige optimaalsemat haldust. Püüame lahendada võimalikult ’Drupal way’. 5.3.1 Loodava süsteemi tõlkimine Drupali võimaldab ehitada mitmekeelsena, mitmekeeslsus on Drupali üks tugevusi. Drupal 8. versioonist alates on mitmekeelsuse funktsionaalsus tuuma sisse ehitatud. See teeb mitmekeelsete lehtede ehitamise ja haldamise lihtsamaks. Nii külastajatele nähtav osa kui ka administreerimise osa on võimalik kuvada mitmekeelsena. Iga sisuhaldaja saab valida endale meeldiva keele, milles ta soovib administreerimise kasutajaliidest näha. Keele sõnavarade uuendusi laetakse alla automaatselt (sisuhaldajate poolt sisestatud tõlked on muudatuste eest kaitstud). 20 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine Kõiki Drupali sisutüüpe on võimalik tõlkida ja väljapõhine tõlkimine võimaldab tõlkida veebilehe välju valikuliselt ja soovikorral kuvada külastajale ainult tõlgitud osa veebilehest. Vabastades sisuhaldaja kohustusest tõlkida terveid veebilehekülgi, mis võib olla koormav. Loodava portaali tõlkimise tagavad Drupal 8 tuumaga kaasasolevad moodulid "Content Translation" ja "Interface Translation". "Content Translation" moodul on mõeldud sisu tõlkimise jaoks ning sellega saab määrata välja kaupa, milliseid välju on vaja tõlkida näiteks, töötaja kontakti puhul Nimi väli pole tõlgitav, aga Ametikoht on. "Interface Translation" mooduli kaudu saab tõlkida, erinevaid halduseks kasutatavaid nuppe. 5.3.2 Lehe optimiseerimine lõppkasutaja jaoks Arvestades arendatava rakenduse olulisust, on otstarbekas süsteemi kiirust täiendavalt optimeerida. Drupali enda cache’le lisaks kaalume kasutada muu hulgas ka „Redis’t“ ja „Varnish’it“. Võimaluselt ka MySQLi asemel PostgreSQL. Kõik otsused räägitakse kliendiga läbi esimeses etapis. Lehe kiiremaks laadimiseks kasutatakse süsteemis cachimise funktsionaalsust. Lehel kasutatavad Javascript, CSS ja HTML failid minimeeritakse ja pakitakse kokku. Pildid üleslaadides salvestatakse kausta, samas luuakse lõigatud koopia pildist, mida kuvatakse välja veebilehe külastajale. Veebilehe külastaja näeb originaalset pilti kui ta soovib pilti suuremalt vaadata. Kõik pildid on kokku pakitud. 5.3.3 Veebilehe leitavuse optimeerimne 5.3.3.1 Sisukord ja metainfo Korrektselt seadistatud sitemap ja metainfo aitavad otsingumootoritel selle sisu paremini kuvada. Veebilehe sisukordade ja metainfo kuvamiseks kasutatakse mooduleid "Metatag" ja "Sitemap", mis võimaldavad luua sisukorda ja metainfot vastavalt RDF ja RSS standardile. Sisukaarti XML formaadis võimaldab moodul "Simple XML sitemap". Drupali „Metatag“ moodul, koosneb mitmetest alamoodulitest, mis võimaldab saavutada soovitud tulemi kirurgiliselt. „Metatag“ on mitmekülgne moodul, on võimalik seadistada kogu portaali hõlmavaid metatage ja piirata muudatusi selle üksikutele lehtedele. Ühe lisavõimalusena võimaldab see moodul optimeerida portaali sisu jagamist erinevates sotsiaalmeedia kanalites. 5.3.3.2 URLide genereerimine Inimloetavate URL-ide genereerimiseks kasutatatakse moodulit "Pathauto". Selle mooduliga, saab paika panna vastavalt sisutüübile, milline link genereeritakse. Samaaegselt on võimalik seadistada genereeritavad urlid nii, et nad on otsingu mootorite poolt lihtsalt leitavad. 5.3.4 Veebivormid Drupali „Webformi“ pakub administraatoril võimalust lihtsa vaevaga lisada veebilehele vorme. „Webform“ võimaldab lisada uusi lahtreid, on võimalik valida üle 50 erineva lahtri tüübi vahel. Lisaks on võimalik lisada vihjemulle, määrata elemente mis on nähtavad ainult administraatoritele, siduda lahtreid omavahel konditsionaalse loogika abil, kohandada vea/õnnestumise teateid, kohandada välja saadetavaid emaile, vaadata sisestuste kohta statistikat, eksportida sisestusi, siduda sisestused näiteks „Slack“ keskkonnaga või kasutades „Webform Handlerit“ mõne teise välise teenusega jms. 21 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine „Webform“ mooduliga on võimailik ehitada ka mahukaid mitmetest astmetest/sammudest koosnevaid vorme (Wizardeid). „Webformi“ erinevad väljatüübid ja lisad võimaldavad ehitada paindlike murelahendusteekondi. See tähendab, et vajalik murelahenduskeskkond on võimalik ehitada suuretõenäoususega piirdudes mooduli pakutatava funktsionaalusesega ja kasutades minimaalsel määral rätsepkoodi. Vormidel mis on kuvatud anonüümsetele kasutajatele kasutatakse "ReCaptcha" moodulit, mis võimaldab mugavalt erineva raskustasemega küsimusi küsida kasutajalt enne vormi sisestamist. Selline lähenemine vähendab suurel määral väärinformatsiooni sisestamist ja takistab erinevatel otsingumootoritel vale informatsiooni sisestada. 5.3.5 Sisu loomine, erinevad teema lehed Drupali tugevus on paindlikus ehitada erineva kujundusega vaateid/lehekülgi. Kasutades ära baaspaketiga kaasa tulevaid võimalusi lisada klassifikatsioone ja ehitada blokkidena on võimalik kujundada individuaalseid lehekülgi. Siduda omavahel ühtseks tervikuks teksti, pildi ja tabelite kujul sisestatud sisu. Näiteks kasutades ära „Paragraphs“ moodulit on võimalus pakkuda sisu siestajale võimalust panna ise kokku eriilmelisi lehekülgi eelnevalt kujunduse põhjal valmis seatud „Paragraph’i“ tükkidest. Mitmekülgne sisuloome „Views“ moodul oli Drupali 7. versiooni kõige populaarsem kogukonna poolt loodud moodul. Nüüd on see osa Drupal 8 tuumast. „Views“ võimaldab paindlikult ehitada väga erinevaid vajadusi kattvaid lehekülgi, vajadusel sidudes omavahel mitmest erinevast sisutüübist tuleneva info ühtseks tervikuks. Eraldi sisutüübid on mõistlik teha selle jaoks, et pärast on lihtsam erinevat sisu hallata ja on ka arusaadavam, kuhu sisestatud sisu ilmub. „CKEditor WYSIWYG“ on Drupal 8’s eel installeeritud, see on tekstitoimetaja, mida on lihtne kasutada ja mis on tuttav kõigile, kes on kasutanud näiteks Microsoft Word tekstitoimetajat. See muudab sisu sisestamise ja muutmise lihtsaks inimeste jaoks kellel puudub koodi kirjutamise kogemus. Selle mooduli eelis seisneb ka selles, et sellel on olemas palju pistikprogramme, mis võimaldavad „CKeditor WYSIWYG’i“ abil sisestada mitmekülgset sisu. Moodulite seadistamise ja sisuga sidumise töömaht sõltub lõplikust kujundusest ja protost. 5.4 Lahenduse Turvalisus Turvalisuse tagamiseks jälgib ja teeb sisuhaldustarkvara arendusmeeskond regulaarselt turvauuendusi ja kõrvaldab turvariskid. Sisuhaldustarkvara turvalisuse tagamiseks kasutame monitooringu teenuseid. Turvaklass on vastavalt hankes sätestatud tingimustele. Meie arendusprotsess juhindub vaikimisi ja lõimitud andmekaitse printsiipidest ehk me mõtleme turvalisusele juba analüüsifaasis. Meil on häid kogemusi erinevate riigiportaalide turvatestidega ja teame mida oodata. 22 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine 6 Lahenduse hooldus ja garantii Veebikeskkonna mõnusalt toimiva hooldus- ja garantiitööde jaoks on võimalus seadistada Atlassian Jira Service Deski. 6.1 Hooldus Käesoleva arendusprojekti hankele lisaks pakume meeleldi edasist arendus/hooldusteenust ja regulaarseid turvauuendusi vastavalt hankelepingu tingimustele. Hooldustöödena teostame ja mõistame pakkumuses: • infotehnoloogilise keskkonna muutustest lähtuvalt tarkvara kohandamine (sh turvapaikade uuendamine). • Töökeskkondade platvormtarkvara ning nende paranduspakettide paigaldamine vastavalt vajadusele. • Süsteemi monitoorimine teenuste tasemel. Tekkivatest kõrvalekalletest koheselt Tellija teavitamine ja vea/rikke parandamine vastavalt vea prioriteedile vastavalt nõuetele. • Töökeskkonna hooldustööde (paigaldus, järelevalve, monitooring) teostamine. • Süsteemi seadistamine lähtuvalt infrastruktuuri muudatustest. • Süsteem peab olema käideldav vastavalt hankelepingule. 6.2 Garantii Pakkumuse garantii teostatud töödele on vastavalt hanke dokumentidele Garantiitööd registreeritakse arendaja poolt n Atlassiani keskkonnas, kui Tellijaga kokku pole lepitud teisiti. Kasutame hajutatud versioonihaldust GIT ja harusi (Hotfix branching), millega saame paralleelselt toimetada arenduse ja potentsiaalsete vigadega. Nii saame välistada garantiitööde ja arendustööde konflikti. Piltlik näide veast ning arendusest versioonihalduses: 23 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine Joonis 5 Garantii- ja arendustööde eest vastutab vähemalt kaks inimest, mis välistab võimaliku ohu ressursiprobleemide tekkeks Garantii puhul eristatakse vigade kategooriaid vastavalt, mis on lepingus nõutud ning nende parandamisel järgitakse hankelepingus kokkulepitud tähtaegu. 24 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine 7 Riskide halduse tegevuskava 7.1 Riskijuhtimise protsess Selles projektis on riskijuhtimise eest vastutav projektijuht. Risk määratletakse kui „aktiivne“ (hinnangu kohaselt reaalselt eksisteeriv) või „mitteaktiivne“ (kadunud, likvideeritud, aegunud vms). Kõigil projektimeeskonna liikmetel on kohustus riske märgata ja sellest projektimeeskonna sisestel nõupidamistel teavitada. Kui riski olemasolu aktsepteeritakse, kannab projektijuht selle riski koos kirjeldusega veebipõhisesse tööhalduskeskkonda. Projekti riskide seire on pidev protsess ning riske arutatakse arendaja (Pakkuja) ja Tellija ühistel regulaarsetel projektikohtumistel (ülevaatus), et tagada kõigi osapoolte teavitus, kontroll ja tõhus riskikäsitlus. Riskijuhtimise protsess koosneb järgmistest põhiosadest: • tuvastus • hindamine • käsitlus • seire ja ülevaatus • teavitus ja nõupidamine Riski tuvastamisel ja aktsepteerimisel, antakse hinnang selle esinemise tõenäosusele ja tagajärje raskusele (maksumus, ajaline viivitus vms). See analüüs määrab tõenäosuse ja tagajärje (indeksid), mis koosmõjus määravad riskitaseme. Riskitasemete kaudu paneb projektimeeskond paika riskide prioriteedid. Tõenäosus näitab, et risk on sündmus, mis „võib“ juhtuda ning tagajärg illustreerib asjaolu, et riskil on olemuslikult alati negatiivne mõju. Tagajärgede raskuse alusel hinnatakse ja määratletakse riske järgmisel skaalal: • madal — 1 • keskmine — 2 • kõrge — 3 • väga kõrge — 4 Läbi tõenäosuse hinnatakse ja määratletakse riske järgmisel skaalal: • vähetõenäoline — 1 • võimalik — 2 • tõenäoline — 3 • peaaegu kindel — 4 Riskitase arvutatakse tagajärje ja tõenäosuse indeksite korrutisega. Riskitase määratletakse järgmiste intervallidega (korrutise vahemikud): • 1–4 — madal 25 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine • 5–8 — keskmine • 9–12 — kõrge • 13–16 — väga kõrge Alljärgnev tabel sisaldab võimalikke väärtusi, mis saadakse tagajärgede raskuse ja tõenäosuse indeksite korrutamisel. Tõenäosus Peaaegu kindel 4 8 12 16 Tõenäoline 3 6 9 12 Võimalik 2 4 6 8 Vähetõenäoline 1 2 3 4 Madal Keskmine Kõrge Väga kõrge Tagajärg Tabel 3 Tõenäosuse-tagajärje maatriks 7.2 Riskikäsitlus Riskide käitlemiseks on neli üldist strateegiat: 1. vältimine, otsustades mitte alustada või jätkata tegevust, mis tekitab riski; 2. jagamine (ülekandmine kolmandale osapoolele); 3. võimalikkuse või tagajärgede leevendamine ja sellega mõjurite vähendamine konkreetsete meetmetega; 4. säilitamine (s. o aktsepteerimine) põhjendatud otsusega. Pakkuja on otsustanud lähtuda järgnevast poliitikast riskikäsitlusel: • madala tasemega riskid — säilitatakse, st teadvustatakse ja võetakse arvesse, ent ohje tegevusi ei planeerita ega korraldata; • keskmise tasemega riskid — käideldakse konkreetsete meetmetega; • kõrge tasemega riskid — lisaks eeltoodule nähakse ette lepingulised garantiid riski realiseerumise puhuks; • väga kõrged riskid — vajavad kohest tähelepanu ja sekkumist kõigi osapoolte kõrgeimal tasemel. 7.3 Tüüpilised riskid tarkvaraarenduses IT arendusprojektide riskid jagunevad universaalseteks ning antud projekti spetsiifilisteks riskideks. Tõsisemad tarkvaraprojektide universaalsed riskid on esitatud järgnevalt. 1. Planeeritava tarkvara ulatuse ja skoobi määramatus. Riski realiseerumise tagajärjeks on tihti eelarve ja tähtaegade ületamine ning ebapiisavalt testitud rakenduse juurutamine (või katse seda juurutada). Ebamäärane skoop on iga IT arendusprojekti üks suuremaid riske, tema korralikuks maandamiseks ning kvaliteetse tulemuse saavutamiseks on hädavajalik täieliku ning detailse analüüsi teostamine dokumenteerimisega. 2. Ebatäpsed nõuded, nõuete pidev muutumine. Riski maandamiseks on vajalik projekti eesmärkide ja Tellija äriprotsesside täpne defineerimine. 26 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine 3. Ebarealistlik tööplaan. Ebarealistliku planeerimise põhjuseid: a) nõuete ebatäpsus, nende pidev muutumine; b) ebapiisav Tellija tagasiside (eriti analüüsi etapis); c) ebapiisav analüüs (pinnapealne ja/või ei kata kõiki vajadusi); d) surve „ülevalt“ juurutada projekt teatud kindlaks (ebarealistlikuks) tähtajaks. 4. Töökorralduse ja kommunikatsiooni probleemid, sellest tulenevalt Tellija soovide ja nõuete plaanipäratu menetlemine (a la “keegi ütles, et seda-ja-seda on ka tarvis teha”), mis võib tekitada arusaamatusi, mittevajalikku lisatööd ja tähtaegade venimist. Riski maandamiseks on tarvis kokku leppida ja kehtestada projekti sisemise töökorralduse, eriti nõuete ja tagasiside edastamise reeglid. 5. Tehnoloogilised riskid (ettenägematud probleemid standardtarkvaras ja/või -riistvaras või tarkvara integreerimisel). 6. Projekteerimise ja teostuse tehnilised riskid (n. puudulik kasutajaliides, vajadusi mitterahuldavad ja raskesti laiendatavad arhitektuursed valikud, ebasobivad algoritmilised lahendused, ebakvaliteetne programmeerimine, ebakvaliteetne liidestus sidussüsteemide ja/või integreeritava tehnikaga jms). 7. Kompetentsi puudusega seotud riskid. 8. Projektorganisatsiooni ja vastutuse piiritlemisega seotud segadused. Palju segadust ja arusaamatusi võib tekkida sellest, kui erinevate koostöörühmade vastutus ja funktsioonid ei ole selgelt piiritletud või neist ei peeta kinni. 9. Võtmeekspertide hõivatus, haigestumine, lahkumine või surve teistest projektidest. Võib seada ohtu tähtaegadest kinnipidamise. Riskide juhtimine arendusprotsessis on esitatud järgneval lehel. 27 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine Iden- tifi- Meetmed ja tegevusplaan Olek Nimetus Kirjeldus Hinnang kaa- realiseerumise korral tor Tõe- Ta-ga- Riski- näo- järg tase sus 1 Aktiivne Ootused Tellija pettub 2 3 Kesk- Ootuste ja skoobi projekti lõpptulemites ning mine juhtimine jooksvalt tulemite suhtes soovib kasutada projekti kulgedes, on erinevad projekti raames kaasatud asutuste võrdne lisaressursse. kohtlemine, individuaalne lähenemine. Kui tuvastame ootuste osas kõrvalekalded, viime läbi täiendavad läbirääkimised ootuste ühtlustamiseks. 2 Aktiivne Võtmeisikute Tekib nn benji- 1 3 Madal Puhkuseplaanide varajane ootamatud management efekt, kus infovahetus ning võimalus puhkuse- võtmeisikud käivad leppida perioodiks kokku plaanid projektis sisse-välja. iseseisvad tööd. Lepime Oluline panus ja kokku protseduurides, planeeritud tööde kuidas äraoleku tegemine ei ole informatsiooni haldame. soovitud ajal võimalik. Kohandame alamprotsesside tööplaanid vastavalt inimeste kättesaadavusele. 3 Aktiivne Portaali Tekib ootamatuid 2 4 Kesk- Detailanalüüsis teenuste teenused on keerukusi, mis mine prioritiseerimine. erineva põhjustavad töömahu Tuvastame ja tegeleme valmidus- suurenemist. Portaali eelisjärjekorras nende astmega teenused põhjustavad portaali teenustega, mille projekti venimist. kohta on kvaliteetne Tähtajast ei ole sisendinfo olemas. võimalik kinni pidada. Viitame vajadustele ja puudustele, määrame ajakava puudustega tegelemiseks. 4 Aktiivne Kinnitatud ja Ajakavast ei peeta kinni 2 4 Kesk- Jooksev suhtlus poolte kooskõlas- ja sealjuures pole mine vahel, regulaarne tatud ajakavast tegemist vääramatu aruandlus, ei peeta kinni jõuga. Projekt ei valmi meeldetuletused enne ettenähtud tähtajaks. tähtaegade saabumist. Kokkulepetele jõudmine poolte vahel ning muudetud ajakava koostamine, mis tagaks projekti õigeaegse valmimise, põhjustades samas pooltele võimalikult vähest 28 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine täiendava lisaressursi kaasamist. 5 Aktiivne Projekti Kui projektile või 2 4 Kesk- Kohtumine poolte vahel nõuded jäävad lõpptulemustele mine enne projekti tegevustega Täitjale esitatavad nõuded on alustamist, aktiivne ebaselgeks ebaselged või mitmeti suhtlus poolte vahel, mõistetavad, siis võib Tellija ootuste selgitamine täitja eksida nende ning tähelepanu juhtimine tõlgendamisel ja olulistele aspektidele, projekti lõpptulemus ei tulemuste regulaarne vasta Tellija ootustele. kooskõlastamine. Projekti tulemuste korrigeerimine, vajadusel täiendavate toimingute teostamine. 6 Aktiivne Projekti või Paljudel põhjustel võib 2 4 Kesk- Koostasime realistliku selle etappide projekti üleandmise mine projektiplaani, mida tähtajad on tähtaeg (sh vaadatakse üle ning ebareaalsed vahetähtaeg) venida, kaasajastatakse või antakse töö üle detailanalüüsi käigus. vähendatud Pidev skoobi jälgimine. funktsionaalsusega. 7 Aktiivne Projekti Olulised kokkulepped 1 3 Madal Sisekommunikatsiooni osaliste hulk on ja info jäävad protseduuride ja suur ning tähelepanuta. Projekti töövahendite olemasolu kommunikat- haldamine tekitab ja eelnev kokkuleppimine. sioon ei toimi osalejatele suurt Jooksev kontroll lisatööd. Tööde plaan protseduuridest ei kehti, tekivad nn kinnipidamiseks. „tulekahjud“. Efektiivne projektijuhtimine, sh alamprojekti- ja teemakeskse kommunikatsiooni planeerimine. Räägime läbi kõikide osalejate vastutuse projekti läbiviimisel. 8 Aktiivne Tellija või täitja Ootamatu 1 4 Madal Meeskonnaliikmed on võtmeisik projektiliikme kaotus kursis teiste liikmete lahkub töölt ohustab projekti töödega. Vajadusel saab tähtaegset elluviimist asendusisik töö üle võtta ning eesmärkide või kogutud andmed ja saavutamist. teadmised edasi anda. Meeskonna koosseis on piisavalt mehitatud ning on võimalus kaasata dubleerivaid ressursse. 9 Aktiivne Portaali Kasutajate vajaduste ja 2 3 Kesk- Projekti algusjärgus teeme teenuste portaali teenusete mine kindlaks tulevikusüsteemi võimekus ei võimaluste vahel on lisatavate teenuste võimalda Tellija vastuolu, mis võib funktsionaalsused ning soove takistada soovitavate hindame vastavalt nende realiseerida funktsionaalsuste näitajatele sobilikkust lisamist. portaali integreerimiseks. Teavitame võimalikest 29 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine negatiivsetest stsenaariumitest asjaosalisi ning töötame välja alternatiivse töökava. 10 Aktiivne Töötulemite Üle antavate tööde 2 4 Kesk- Katame projekti perioodi üleandmine kuhjumine projekti mine vahetulemitega, kuhjub projekti lõppjärku tingib planeerime sisse lõppjärku suurema võimaluse vahetestimised ning tähtaega ületada ning jaotame tööplaani takistab tagasiside selliselt, et ootame põhjal tehtavate töödele tagasisidet juba muudatuste projekti varasemates sisseviimist. staadiumites. 11 Aktiivne Tellija Tagasiside venib, võib 2 3 Kesk- Korraldame suhtluse võtmeisikud ilmned hiliseid mine selliselt nagu on pole parandusi ning see kirjeldatud dokumendi tagasisideks omakorda võib töökorralduse oas. kätte- tähendada tähtaja Võtmeisikutele soovime saadavad ületamist. asendajat ootamatuste vältimiseks ja veendume otsustaja rollis olevate isikute kättesaadavuses. 12 Aktiivne Tehnoloo- Ettenägematud 2 4 Kesk- Kaardistame serveri, gilised riskid probleemid mine raamistike ja standardtarkvaras tehnoloogiate võimalikud ja/või -riistvaras või riskid ja loome nende tarkvara põhjal tegevuskavad. integreerimisel. Tabel 4 Riskide juhtimine tarkvara arendusprotsessis 30 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine 8 Tööde elluviimise ajakava ja eelarve koos põhiliste protsesside ning tööde kirjeldusega Oleme jaganud kogu protsessi kolmeks etapiks. Iga etapp jaguneb mitmeks alamprotsessiks ning iga alamprotsess koosneb omakorda mitmest läbiviidavast tegevusest. Mitu etappi võivad agiilselt toimuda paralleelselt. 1. Kodulehe analüüsimine, struktureerimine ja disainimine - Kasutajaliideste disaini põhitingimuste analüüsi– Selles etapis tehakse kogu vajalik eeltöö, et välja selgitada, kellele ja mida luuakse. Etapi tulemused loovad fundamentaalse sisendi järgmistele etappidele millest kasutajaliideste loomisel lähtutakse. Loome ja testime prototüübi ja kasutajaliideste lahendusi, mis vastavad analüüsi töötulemitele. Samuti keskkonna kujunduse ning stiiliraamat, võttes aluseks prototüüp ning visuaalse identiteedi põhimõtted. 2. Arendus, testimine ja dokumentatsioon – Siin etapis toimuvad paralleelselt nii Front-end kui ka back-end arendus. Lõpuks ka testimine ja dokumentatsioon vastavalt hanke nõudmistele. Lisaks teostatakse vana veebi info import uude 3. Koolitus ja juhend – Selles etapis tehakse juhendid ja vastavalt vajadusele koolitused. • Kõik etapid sisaldavad endas puhvrit. Eraldi on arvestatud lisapuhver projekti lõppu • Reaalne arendus toimib agiilselt ja eri tööd paralleelselt. Iga arendusetapp on seesmiselt jaotunud 2 nädala pikkusteks iteratsioonideks. • Projektiplaan on tehtud hetke info põhjal parima äranägemise järgi ja täpsustatakse koos kliendiga esimeses etapis. Vahetulemid, tööde üksteisest sõltuvused, täitja ja tellija poolt kaastatud osapooled ja lahenduse realiseerimiseks pakutavad tegevused, mis tagavad teenuse kvaliteedi, on detailselt kirjeldatud käesoleva dokumendi alljärgnevas peatükis 8.1 Töö etappide ja protsesside detailsed kirjeldused. 31 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine Otoober November Detsember Jaanuar Veebruar Märts Apr Mai (pool kuud) Uue lehe analüüsimine, struktureerimine ja disain Tellija vajaduste täpsustamine ja olemasoleva 24h materjali läbitöötamine Navigatsiooni ja struktuuri loomine 24h Prototüübi loomine ja testimine 100h Kujundus ja võimalikud muudatused 112h 8h Arendus, testimine ja dokumentatsioon Keskkondade seadistus 14h 2h Drupal back-end tööd, tehniline 180h 20h dokumentatsioon ja võimalikud parandused Front-end arendus (HTML) ja võimalikud 160h 16h parandused Testimine 34h Kodulehe vana sisu ületoomine 26h Kasutusjuhend ja kasutajakoolitus 20h 8h Puhver Kliendi poolne testimine ja administreerimine Tabel: Projekti prognoositav ajakava ja mahud, mis täpsustuvad esimeses – analüüsi faasis. Vahetulemid, sõltuvused, täitja ja tellija poolt kaastatud osapooled on detailselt kirjeldatud järgmistel lehtedel Prognoositav avalikustamine: mai 2019 Projekti eelarve: Kokku 748 h x 50€/h = 37 400€ +km Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine Arendustööde mahuhinnang jaguneb rollide lõikes järgnevalt: • Projektijuhtimine: 40 tundi • Analüüs: 40 tundi • UX ja UI tööd: 210 tundi • Front-end arendus: 166 tundi • Back-end arendus, teh dok ja import: 230 tundi • Testimine: 34 tundi • Koolitus, nõustamine: 28 tundi Projekti eelarve: Kokku 748 h x 50€/h = 37 400€ +km Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine 8.1 Töö etappide ja protsesside detailsed kirjeldused Alljärgnevalt toome välja etappide detailsed kirjeldused: 8.1.1 Uue kodulehe analüüsimine ja struktureerimine Kasutajaliideste disaini põhitingimuste analüüsi eesmärk on selgitada välja Tellija ja kasutajagruppide vajadused, tutvuda valdkonna spetsiifikaga, luua tüüpkasutajate kirjeldused ehk persoonad, kaardistada kasutajateekonnad ja teenuse osutamise protsessid ning luua kasutajaliidestele navigatsioon. Etapp on jagatud kolmeks alamprotsessiks: 1) Tellija vajaduste täpsustamine 2) Olemasoleva materjali läbitöötamine 3) Navigatsiooni loomine Iga alamprotsess jaguneb omakorda läbiviidavateks tegevusteks, mida on täpsemalt kirjeldatud alljärgnevates alampeatükkides. Etapi jooksul on igasse alamprotsessi ühel või teisel viisil kaasatud ka Tellija. Tellija peamiseks rolliks on anda UX disainerile kokkulepitud tööde teostamiseks sisendit ärivajaduste kohta ja kooskõlastada alamprotsesside töötulemid. Selle etapi tulemused loovad olulise sisendi kahte järgmisesse etappi, s.t. disaini- ja arendussprinti. Etapi tulemusena valmivad järgmised üleantavad töötulemid: • Tellija ärivajaduste loetelu • Kasutajagruppide vajaduste loetelu • Persoonad • Teemade jaotus portaalis Navigatsiooniskeem 8.1.1.1 Tellija vajaduste täpsustamine Eesmärk on selgitada välja Tellija ja teiste oluliste võtmeisikute vajadused ja ootused projektile Eesmärk ning loodavatele kasutajaliidestele. Sisendid/ • Hankedokumendid sõltuvused Läbiviidavad 1. Projekti avakoosoleku korraldamine tegevused 2. Projekti avakoosoleku läbiviimine 3. Grupiintervjuu kokkuleppimine 4. Intervjuuküsimuste koostamine 5. Grupiintervjuu läbiviimine 6. Tellija ärivajaduste kaardistamine 7. Ärivajaduste loetelu kooskõlastamine Tellijaga Projekti avakoosoleku korraldamine. Tellija lepib vajalike võtmeisikutega kokku avakoosoleku Kirjeldus koha ja aja. Avakoosolekule on kaasatud kõik projekti osapooled, s.t. lisaks Tellijale ja 34 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine võtmeisikutele osalevad ka tööde teostajad. Täitja projektijuht valmistab ette avakoosoleku päevakorra. Koosoleku eesmärk on anda projekti osapooltele ülevaade kokku lepitud projekti töökorralduse ja ajakava kohta ning lahendada tekkinud küsimusi. Avakoosoleku eelduseks on, et osapoolte vahel on töökorralduslikes ja ajalistes küsimustes eelnevalt kokku lepitud. Projekti avakoosoleku läbiviimine. Täitja poolne projektijuht viib avakoosoleku läbi. Koosoleku tulemusel on kõigil osapooltel selge arusaam projekti töökorraldusest ja ajakavast. Grupiintervjuu kokkuleppimine. Täitja projektijuht täpsustab Tellijaga grupiintervjuu aja, koha ja osalejate ringi. Tellija lepib võtmeisikutega grupiintervjuud kokku. Intervjuu vormiks oleme valinud grupiintervjuu, sest see soodustab arutelude toimumist ning on seega hea võimalus lahendada küsimusi, mis on vastuolulised või kaheti mõistetavad. Soovitatav osalejate arv grupiintervjuul on 3-5 osalejat, vajadusel viiakse läbi mitu grupiintervjuud. See vajadus lepitakse eelnevalt Tellijaga kokku. Intervjuuküsimuste koostamine. UX disainer koostab grupiintervjuu tarvis küsimused. Küsimustik ehitatakse üles poolstruktureerituna, s.t. määratletakse ära põhilised teemad ja küsimused, mis võimaldab küsida täpsustavaid küsimusi lähtuvalt antud vastustest. Grupiintervjuu(de) läbiviimine. UX disainer viib läbi grupiintervjuu Tellija ja teiste oluliste võtmeisikutega. Eesmärk on täpsustada nende vajadusi ja ootusi projektile ning kasutajaliidestele. Samuti selgitatakse välja kasutajaliideste võimalikud piirangud ja võimalused. Grupiintervjuu kestuseks planeeritakse umbes 1,5 tundi. Grupiintervjuu salvestatakse helis. Tellija ärivajaduste kaardistamine. UX disainer tuvastab ja kaardistab intervjuu helisalvestiste analüüsi käigus Tellija ärivajadused ja ootused. Selle tulemusel valmib Tellija ärivajaduste loetelu. Ärivajaduste loetelu kooskõlastamine Tellijaga. UX disainer kooskõlastab Tellijaga ärivajaduste loetelu, vajadusel seda korrigeerides. Väljundid • Tellija ärivajaduste loetelu Täitvad rollid • Analüütik • UX disainer Kaasatud rollid • Tellija põhiülesanded: o Avakoosoleku kokkuleppimine võtmeisikutega o Avakoosolekul osalemine o Grupiintervjuu kokkuleppimine võtmeisikutega o Grupiintervjuul osalemine o Äriavajduste loetelu kooskõlastamine • Täitja põhiülesanded: o Avakoosolekul osalemine o Grupiintervjuul osalemine Otsustuspunktid • Kas avakoosolekul osalejate ring on piisav? • Kas grupiintervjuul osalejate ring on piisav? • Kas Tellija kinnitab vajaduste loetelu? 35 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine 8.1.1.2 Olemasoleva materjali läbitöötamine Eesmärk on tutvuda olemasolevate kasutajaliidestega ning koguda kokku ja töötada läbi Eesmärk olemasolev materjal, et saada ülevaade olemasolevate keskkondade spetsiifikast. Samuti tutuvuda seni tehtud uuringutega Sisendid / sõltuvused • Tellija ärivajaduste loetelu (üleantav töötulem) • Olemasolevad materjalid (Tellijalt) Läbiviidavad 1. Olemasoleva materjali kokku kogumine tegevused 2. Kasutajagruppide vajaduste ja valdkonna probleemide kaardistamine 3. Olemasolevate kasutajaliidestega tutvumine Olemasoleva materjali kokku kogumine. Tellija varustab UX disainerit olemasoleva Kirjeldus materjaliga. Tellijale jääb õigus otsustada, missugused materjalid läbi töötatakse ja uute kasutajaliideste disainimisel aluseks võetakse. Olemasoleva materjali hulka võib lugeda näiteks lahenduste visioonid, analüüsidokumendid, praeguse kasutajaliidese kasutusstatistika, äriplaanid, kasutusjuhendid ja materjalid seoses kasutajatoe poole pöördumistega. Kasutajagruppide vajaduste ja valdkonna probleemide kaardistamine. UX disainer kaardistab olemasoleva materjali läbitöötamise käigus kasutajagruppide vajadused ja valdkonna probleemid ning koostab nendest loetelud. Lisaks täpsustab UX disainer materjali põhjal kasutajauuringuteks käsitletavad teemad ning formuleerib täiendavaid küsimusi. Olemasolevate kasutajaliidestega tutvumine. Tellija tagab UX disainerile ligipääsud olemasolevatesse kasutajaliidestesse. UX disainer tutvub olemasolevate süsteemidesse. Eesmärk on saada ülevaade, milline on kasutajagruppide teekond ning millised on loodud funktsionaalsused olemasolevates kasutajaliidestes. Väljundid • Kasutajagruppide vajaduste ja valdkonna probleemide loetelu olemasoleva materjali põhjal • Kasutajauuringutes käsitletavad teemad ja küsimused Täitvad rollid • UX disainer • Analüütik Kaasatud rollid • Tellija põhiülesanded: o Olemasoleva materjali valiku üle otsustamine o UX disaineri varustamine olemasoleva materjaliga o UX disainerile ligipääsu tagamine olemasolevatesse süsteemidesse Otsustuspunktid • Millised materjalid on läbitöötamiseks vajalikud? • Millised ligipääsud olemasolevatesse süsteemidesse on vajalikud? 36 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine 8.1.1.3 Navigatisooni loomine Joonis 5 - Navigatsiooniskeemi näidis Eesmärk Eesmärk on luua kasutajaliidestele navigatsioon, mis aitab kasutajagruppidel jõuda nende soovitud eesmärgini võimalikult mugavalt ja kiirelt. Sisendid / sõltuvused • Intervjuud • Olemasolevad materjalid Läbiviidavad 1. Kasutajateekonna kirjeldamine 2. Navigatsiooniskeemi loomine tegevused 3. Navigatsiooniskeemi kooskõlastamine Kasutajateekonna kirjeldamine. On esimene samm keskkonna infoarhitektuuri loomiseks. Kirjeldus UX disainer, koos Tellija esindajatega viib läbi töötoa vormis arutelu. Ühiselt arutamine ja teekonna kaardistamine on efektiivne viis kirjeldamaks kasutajate eesmärke keskkonnas ning nende ideaalset teekond aeesmärkide saavutamiseks. Töötuba võimaldab lühikese ajaga vastus paljudele küsimustele nign selgitada välja parim lahendus nii kasutajatele, Tellijale kui ka arendajatele. Navigatsiooniskeemi loomine. UX disainer loob töötoas valminud kasutajateekonna/teekondade põhjal kasutajaliidestele navigatsiooniskeemi, kus on ära toodud erinevate tasemete menüüpunktid. Navigatsiooniskeemi kooskõlastamine. UX disainer kooskõlastab loodud navigatsiooniskeemi Tellijaga. Vajadusel korrigeerib UX disainer navigatsiooniskeemi lähtuvalt ärilistest eesmärkidest ja tehnilistest piirangutest. Tegevuse tulemusena valmib üleantava töötulemina navigatsiooniskeem. Väljundid • Navigatsiooniskeem (üleantav töötulem) 37 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine Täitvad rollid • UX disainer Kaasatud rollid • Tellija põhiülesanded: o Navigatsiooniskeemi kooskõlastamine Otsustuspunktid • Kas Tellija kinnitab navigatsiooniskeemi? 8.1.2 Kasutajaliidese disainimine Eesmärk on luua, testida ja parendada kasutajaliideste prototüüpi, luua kasutajaliidestele ekraanivormide näidised. Aluseks võetakse esimese etapi tulemused. Etapp on jagatud neljaks alamprotsessiks: 1) Wireframe tüüpi prototüübi loomine 2) Wireframe tüüpi prototüübi testimine 3) Ekraanivormide näidiste loomine 4) Kujunduselementide ja stiiliraamatu loomine Selle etapi näol on sisuliselt tegemist erinevate disainisprintidega, mis on arendussprindist alati vähemalt ühe sprindi võrra eespool. Enne igat sprinti lepitakse kokku, milliseid funktsionaalsusi hakatakse disainima ja arendama. UX disaineri ja analüütiku ülesanne on jälgida, et wireframe tüüpi prototüübis loodud kasutajateekond ning elemendid vastavad süsteemi võimalustele ning arhitektuurile. 38 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine Disainisprindi lõpus tutvustavad UX disainer ja veebidisainer loodud wireframe tüüpi prototüüpi ja ekraanivormide näidiseid arendajatele. Etapi tulemusena valmivad järgmised üleantavad töötulemid: • Wireframe tüüpi prototüüp • Kujundusega ekraanivormide näidised • Kujundus elemendid ning stiiliraamat Etapi tulemused on sisendiks arendusele. Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine 8.1.2.1 Wireframe tüüpi prototüübi loomine Pilt 2 - Wireframe prototüübi näited erinevatel ekraanidel Eesmärk Eesmärk on luua loodavatele kasutajaliidestele wireframe tüüpi prototüüp, mis vastaks kasutajagruppide vajadustele, Tellija ärivajadustele ja tehnilistele piirangutele ning mille navigatsiooni ja funktsionaalsusi oleks võimalik järgmises alamprotsessis testida. Sisendid / sõltuvused • Tellija ärivajaduste loetelu (üleantav töötulem) • Teemade ja teenuste grupid (üleantav töötulem) • Navigatsiooniskeem (üleantav töötulem) • Kasutajaliideste reaalne sisu (Tellijalt) Läbiviidavad 1. Prototüübitavate vaadete ja funktsionaalsuste kokkuleppimine tegevused 2. Wireframe tüüpi prototüübi loomine 3. Wireframe tüüpi prototüübi kooskõlastamine Prototüübitavate vaadete ja funktsionaalsuste kokkuleppimine. UX disainer lepib Tellijaga Kirjeldus kokku, milliseid funktsionaalsusi ja vaateid hakatakse järgmises sprindis disainima ja arendama. Wireframe tüüpi prototüübi loomine. Prototüübi loomisel lähtub UX disainer loodud persoonade eesmärkidest ja vajadustest, navigatsiooniskeemist ja Tellija ärivajadustest. UX disainer loob wireframe tüüpi prototüübi, mis on interaktiivne, ilma kujunduseta ning reaalse sisuga. Interaktiivsus võimaldab visualiseerida loodavate kasutajaliideste elementide Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine töötamist ning testida järgmises alamprotsessis navigatsiooni ja funktsionaalsusi. Ilma kujunduseta prototüüp tagab, et testimisel langeks fookus elementide paigutusele, funktsionaalsustele ja sõnastustele, mitte visuaalsele disainile. Samuti hoitakse sellega aega kokku. Reaalse sisu kasutamine võimaldab kontrollida, kas testitavate jaoks on sisu arusaadav. Tellija varustab UX disainerit reaalse sisuga. Prototüübi loomisel peetakse silmas ka võimalikke testimise teekondi, et prototüüpi ei peaks järgmises alamprotsessis hakkama vastavalt loodavatele testülesannetele muutma. Prototüübi vaated sisaldavad nii desktopi kui ka mobiili vaateid, et tagada lähtuvalt kasutatavast seadmest ja selle ekraani laiusest kasutajamugavus ning kohanduv disain (responsive design). Interaktiivse prototüübi loomiseks kasutatakse Axure RP 8 tarkvara. Wireframe tüüpi prototüübi kooskõlastamine. UX disainer kooskõlastab loodud wireframe tüüpi prototüübi Tellijaga, et vajadusel prototüüpi enne testimist vastavalt ärivajadustele ja tehnilistele piirangutele korrigeerida. Väljundid • Wireframe tüüpi prototüüp (üleantav töötulem) Täitvad rollid • Projektijuht • Analüütik • UX disainer Kaasatud rollid • Tellija põhiülesanded: o Prototüübitavate vaadete ja funktsionaalsuste kokkuleppimine o UX disaineri varustamine kasutajaliideste reaalse sisuga o Prototüübi kooskõlastamine Otsustuspunktid • Kas prototüübitavad vaated ja funktsionaalsused on kokku lepitud? • Kas prototüüp vastab ärivajadustele? • Kas prototüüp arvestab tehniliste piirangutega? 41 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine 8.1.2.2 Wireframe tüüpi prototüübi testimine Pilt 3 - Paberprototüübi testimine Eesmärk Eesmärk on testida kasutajagruppide peal kasutajaliideste wireframe tüüpi prototüüpi, et tuvastada kasutatavuse probleemid, probleemidele lahendused leida ning prototüüpi parendada. Sisendid / • Wireframe tüüpi prototüüp (üleantav töötulem) sõltuvused Läbiviidavad 1. Testimise eesmärgi defineerimine tegevused 2. Testitavate profiilide defineerimine 3. Testimiste arvu kokku leppimine 4. Testülesannete koostamine 5. Testülesannete kooskõlastamine Tellijaga (vajadusel) 6. Testitavate leidmine ja kohtumiste kokkuleppimine 7. Wireframe tüüpi prototüübi testimise läbiviimine 8. Kasutatavuse probleemide tuvastamine 9. Kasutatavuse probleemidele lahenduste leidmine 10. Lahenduste kooskõlastamine (vajadusel) 42 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine 11. Wireframe tüüpi prototüübi parendamine (vajadusel) 12. Arendusele wireframe tüüpi prototüübi üleandmine Testimise eesmärgi defineerimine. UX disainer defineerib kõigepealt testimise eesmärgi ja Kirjeldus fookuse, millistele funktsionaalsustele testimisel keskendutakse. See põhineb suuresti sellel, mis vaated ja funktsionaalsused sprindi alguses kokku lepiti. Testitavate profiilide defineerimine. UX disainer defineerib testitavate profiilid, mis põhinevad kasutajagruppidel ja persoonadel. Kasutatavad persoonad tulenevad suuresti sprindi alguses kokku lepitud funktsionaalsustest. Testimiste arvu kokku leppimine. UX disainer lepib Tellijaga kokku, mitu testimist läbi viiakse. Parim praktika on viia läbi igast kokkulepitud kasutajagrupist 3-5 testitavaga. Testülesannete koostamine. Lähtuvalt testimise eesmärgist, fookusest ja testitavate profiilidest koostab UX disainer testülesanded. Selleks, et testimise sessioon ei veniks testitava jaoks liiga pikaks, on parim praktika koostada 5-7 testülesannet. Testülesannete kooskõlastamine Tellijaga. UX disainer kooskõlastab vajadusel koostatud testülesanded Tellijaga, neid vajadusel korrigeerides. Testitavate leidmine ja kohtumiste kokkuleppimine. Vastavalt testitavate profiilidele leiab UX disainer testitavad. Vajadusel abistab Tellija testitavate leidmisel või koostatakse selleks veebipõhine küsimustik. UX disainer võtab testitavatega ühendust ning lepib kokku kohtumise aja ja koha. Wireframe tüüpi prototüübi testimise läbiviimine. UX disainer viib testimised individuaalselt läbi. Testimise jooksul annab UX disainer testitavale ükshaaval testülesanded ette ning jälgib, kuidas testitavad käituvad ning mida teevad, et eesmärgini jõuda. UX disainer palub testitavatel valjusti mõelda, et testi läbiviija saaks aru testitava mõttemustritest. Iga testimise sessioon salvestatakse nii helis kui ekraanivaatena. Kasutatavuse probleemide tuvastamine. Peale testimise sessiooni vaatab UX disainer salvestised üle ning analüüsi käigus tuvastab testitavale ebaloogilisena tunduvad kohad ning tegevused, mis võivad suure tõenäosusega pooleli jääda või kolmandate osapoolte abi vajada. UX disainer otsustab, millistele probleemidele tuleb esmajärjekorras lahendused leida, mida ei tuleks lahendada ning mille kohta tuleks rohkem infot koguda. Vajadusel muudetakse ka testülesandeid. Kasutatavuse probleemidele lahenduste leidmine. UX disainer leiab kriitilistele probleemidele lahendusvariandid. Lahenduste kooskõlastamine. Kui UX disaner kooskõlastab lahenduse punktid Tellijaga. Wireframe tüüpi prototüübi parendamine. UX disainer viib lahendused wireframe tüüpi prototüüpi sisse. Arendusele wireframe tüüpi prototüübi üleandmine. Kui kõik kokkulepitud testimised on läbi viidud ning prototüüp parendatud, siis tutvustatakse prototüübi muudatusi ka front-end arendajale ning antakse neile üle, pannes prototüübi vaated või viited arendussprindi tarvis piletitesse nt Jira keskkonnas. Väljundid • Wireframe tüüpi prototüüp (üleantav töötulem) Täitvad rollid • UX disainer Kaasatud rollid • Tellija põhiülesanded: o Testimiste arvu kokku leppimine o UX disaineri abistamine testitavate leidmisel o Lahenduste kooskõlastamine 43 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine Otsustuspunktd • Kas testülesandeid on vaja muuta? • Kas wireframe tüüpi prototüüpi on vaja muuta? 44 8.1.2.3 Kujundatud ekraanivormide näidiste loomine Eesmärk Eesmärk on luua ekraanivormidest kujundatud näidised, et visualiseerida, kuidas loodud kujunduselemente kasutajaliidestes kasutada ning milline peaks olema lõplik visuaalne kasutajaliideste disain. Sisendid / sõltuvused • Wireframe tüüpi prototüüp (üleantav töötulem) Läbiviidavad 1. Ekraanivormide näidiste loomine 2. Ekraanivormide näidiste kooskõlastamine Tellijaga tegevused 3. Arendusele ekraanivormide näidiste üleandmine Ekraanivormide näidiste loomine. Veebidisainer loob wireframe tüüpi prototüübi. Selleks Kirjeldus kasutab ta sketchi, Adobe Illustratorit või muda sarnast programmi, et tagada arendajale võimalikult mugav kujunduse ja interaktsioonidisaini rakendamine ning juurutamine tarkvaras. Näidised luuakse nii desktopi kui ka mobiili jaoks, et tagada ühtne stiil erinevates seadmetes. Ekraanivormide näidiste kooskõlastamine Tellijaga. Kujundatud ekraanivormide näidised kooskõlastab veebidisainer Tellijaga, vajadusel neid korrigeerides. Arendusele ekraanivormide näidiste üleandmine. Disainisprindi lõpus tutvustab veebidisainer loodud ekraanivormide näidiseid arendajatele ning annab need neile üle. Väljundid • Ekraanivormide näidised (üleantav töötulem) Täitvad rollid • Veebidisainer Kaasatud rollid • Tellija põhiülesanded: o Ekraanivormide näidiste kooskõlastamine Otsustuspunktid • Kas Tellija kinnitab ekraanivormide näidised? 8.1.2.4 Kujunduselementide loomine Eesmärk Eesmärk on ühtlustada kasutatavat stiili, luua kasutajaliideste kujunduselemendid ning töötada välja stiiliraamat, et loodavatel kasutajaliidestel oleks ühtne ja arusaadav visuaalne disain ning kujunduselemente oleks mugav ja kiire front-end arenduses kasutada. Sisendid / sõltuvused • Olemasolev stiiliraamat (Tellijalt) Läbiviidavad 1. Olemasoleva stiiliraamatu ja kasutajaliideste kujunduselementide kaardistamine tegevused 2. Stiili ühtlustamine ja uute kujunduselementide loomine 3. Kujunduselementide kooskõlastamine Tellijaga Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine Kirjeldus Olemasoleva stiiliraamatu ja kasutajaliideste kujunduselementide kaardistamine. Tellija varustab veebidisainerit olemasoleva stiiliraamatu ja ligipääsuga olemasolevatesse süsteemidesse. Veebidisainer vaatab üle olemasoleva stiiliraamatu ja kasutajaliidesed ning kaardistab nendes kasutatud elemendid. Stiili ühtlustamine ja uute kujunduselementide loomine. Veebidisainer ühtlustab stiili ning vajadusel loob uued kujunduselemendid. Kujunduselementide kooskõlastamine Tellijaga. Veebidisainer kooskõlastab uued kujunduselemendid Tellijaga. Kui kujunduselemendid vastavad Tellija vajadustele, siis Tellija kinnitab need. Vastasel juhul viib veebidisainer sisse muudatused. Kui kujunduselemendid on Tellijaga kooskõlastatud, loob veebidisainer nende põhjal stiiliraamatu. Väljundid • Kujunduselemendid (üleantav töötulem) Täitvad rollid • Veebidisainer Kaasatud rollid • Tellija põhiülesanded: o Veebidisainerile ligipääsu tagamine olemasolevatesse süsteemidesse o Kujunduselementide kooskõlastamine Otsustuspunktid • Millised elemendid on üleliigsed? • Millistele elementidele on vaja luua uus kujundus? • Kas uued kujunduselemendid vastavad Tellija ärivajadustele? 46 8.1.3 Arendus, testimine ja dokumentatsioon 8.1.3.1 Front-end arendustööd Eesmärk Eesmärk on teha kliendi soovide ja analüüsi järgi sobivaima raamistiku baasil kiire ja levinumates veebilehitsejates hästi toimiv HTML kood Sisendid / sõltuvused • Kujundus • Back-end nõuded Läbiviidavad 1. FE raamistiku valik 2. Drupali spetsiifikaga kooskõlastamine tegevused 3. HTMLi ja CSSi loomine 4. Testimine HTML mallide loomisel lähtume Tellijaga eelnevalt kokku lepitud mahust, kus tööde aluseks Kirjeldus on kujundusmallid võtmelehekülgedest. Töötame välja kõik hankes nõutud kujundusmallide rakendamiseks vajalikud interaktsiooni- ja kujunduselemendid, sh nupud, ikoonid ja graafika. Loodavate elementide hulk katab kujunduskontseptsiooni rakendamise täies mahus. Enne HTML töödega alustamist analüüsime loodavat lahendust ning vajadusel täpsustame mittefunktsionaalseid nõudeid. Valime koos kliendiga front-end raamistiku, mis tagab nõuete täitmise. Üheks valikuks oleks näiteks Bootstrap 4. Panustame, et kood oleks kiire ja sujuv enamustes kaasaegsetes nutiseadmetes. Tänu agiilsele arendusprotsessile saame hakata front-end keskkonda looma paralleelselt analüüsi- ja back-end arendustöödega. Väljundid • HTML ja CSS failid (üleantav töötulem) Täitvad rollid • FE-arendaja Kaasatud rollid • BE arendaja • Tellija põhiülesanded: o FE raamistiku valiku osas nõu pidamine ja omapoolsete soovide väljandamine Otsustuspunktid • Millisene FE raamistik valida? 8.1.3.2 Back-end ehk Drupali arendustööd Eesmärk Eesmärk on siduda HTML kood ja Drupal, mis oleks testitud ja nõuetele vastav Sisendid / sõltuvused • prototüüp • HTML kood • MFN nõuded Läbiviidavad 1. Ligipääsude saamine Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine tegevused 2. Drupali põhiloogika seadistus 3. Lisamoodulite valik ja installeerimine 4. Uute custom-moodulite arendus 5. Portaali statistika jälgimissüsteemi seadistus 6. Testimine Drupal 8 arendust saame alustame paralleelselt front-end töödega. Peame lugu korrektsest Kirjeldus koodist, kommentaaridest, automaattestidest ja dokumentatsioonist. Panustame, et back-end oleks kiire ja turvaline ning Pakkujana kinnitame, et järgmine Tellija poolt esitatud kõiki hankes esitatud turvalisuse nõudeid. Arenduse töid teostame agiilset arendusmetoodikat jälgides. Vastavad põhimõtted ja tegevused lepime Tellijaga kokku enne töödega alustamist. Tööde teostamisel arvestame Tellijalt eelnevalt teostajale teatavaks tehtud huve, lähtudes tõhususe, kvaliteedi, säästlikkuse ja otstarbekuse põhimõtetest ning arvestades vastavas tegevusvaldkonnas kehtivaid õigusakte, standardeid ja head tava. Kuna projekti realiseeritakse iteratiivselt, ei läbita kõiki protsesse alati järjest, vaid mitmed protsessid võivad toimuda paralleelselt ja erinevate protsesside juurde võidakse vajaduse korral arendusprotsessis tagasi pöörduda. Selle pakkumuse raames realiseeritavate süsteemide puhul on plaanis alustada alati analüüsist. Väljundid • Valmis Drupal lahendus Täitvad rollid • Arendaja ja vanemarendaja Kaasatud rollid • FE arendaja • Analüütik • UX disainer • Testija • Toimetaja (saab sisu lisama hakata) • Tellija põhiülesanded: o Serveri ligipääsude jms jagamine Otsustuspunktid • Moodulite valik 8.1.3.3 Keskkondade seadistamine ja juurutamine Eesmärk Eesmärk on saada püsti arenduseks vajalikud keskkonnad Sisendid / sõltuvused • ligipääsud • HTML kood • MFN nõuded • BE kood Läbiviidavad 1. Ligipääsude saamine 2. Kliendi infra meeskonnaga suhtlus 48 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine tegevused 3. Keskkondade ülesseadmine Selles etapis seadistatakse koos kliendi IT toega versioonihaldus, arendus, testimine, Kirjeldus testkeskkond ja live keskkonnad. Lisasoovina on võimalik tellida automatiseerimist ehk Continuous Integration (CI) ja Continuous Delivery (CID) peale. Agiilse ehk kiire ning paindliku tarkvaraarenduse maailmast pärit idee järgi peavad tarkvara parandused ja uuendused jõudma kasutajani võimalikult kiiresti kui need on valmis. "Vanasti" eelistati uuendused kokku koguda ühte suurde kuhja, et siis ühel teatud hetkel kõik korraga ära paigaldada. CID maailmas tehakse seda vajadusel kasvõi mitu korda päevas. Iga tarne kontrollitakse ja testitakse automaatselt, et leida võimalikult kiirelt potentsiaalseidid (inimlikke) vigu. See kiirendab protsessi ja tõstab üldist kvaliteeti. Süsteemi juurutamisel ja lanseerimisel pakub Pakkuja vastavalt vajadusele ja Hankijaga kokkulepitud mahus konsultatsiooni ja kasutajatuge. Väljundid Versioonihaldus, arendus, test, pre-live ja live serverite seadistus ning automatiseerimine Täitvad rollid • Vanemarendaja • BE arendaja Kaasatud rollid • Testija • Tellija põhiülesanded: o Serveri ligipääsude jms jagamine Otsustuspunktid • Infrastruktuuri tehniliste detailide ülevaatamine 8.1.3.4 Testimine Eesmärk Eesmärk on saada kiire, turvaline ja veavaba live lõpptulem Sisendid / sõltuvused • HTML kood • MFN nõuded • BE kood • Analüüs Läbiviidavad 1. HTML testimine 2. Wcag testimine tegevused 3. BE testimine 49 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine Teostatakse inimtestid. Lisasoovina on võimalus tellida ka jõudlus kui ka automaattestid. Kirjeldus Agiilses tarkvara arenduses on automatiseeritud testimine võtmetähtsusega, et pakkuda kvaliteetset tarkvara. See on üks paljudest põhjustest, miks agiilne arendus on muutunud nii edukaks ja on saanud mis tahes jätkusuutliku tarkvara osaks. Automatiseeritud testimine hägustab piiri testimise ja arendamise vahel. Mõlemad osapooled peavad tegema koostööd, et toota vigadeta tarkvara. Testimise aluseks võetakse võimaluse korral ärianalüüs, nõuded ja neile vastavad danalüüsi dokumendid (kasutajalood, aktsepteerimise kriteeriumid). Testimist viiakse läbi testiplaani(de) alusel. Väljundid • Testplaan • Testraportid • Lisasoovina automaattestide skriptid Täitvad rollid • Vanemarendaja • Testija Kaasatud rollid • Tellija põhiülesanded: o Omapoolne lõpptest Otsustuspunktid • Testide ulatus, automatiseerimine? 8.1.3.5 Vigade ja muudatuste haldus Vead ja muudatused dokumenteeritakse kõik veebipõhises tööhalduskeskkonnas. Koos Tellijaga lepitakse kokku vigade ja muudatuste prioriteet ning kas on grantiiline töö või mitte. • “One ticket per bug and one bug per ticket” lähenemine • Vigade puhul on soovitav lisada ka ekraanikuva, link ja internetilehitseja versioon kasutades näiteks lahendust http://www.whatsmybrowser.org. Suuremate muudatuste puhul kaasame analüütiku ja vaatame UI-d ning UX-i. Rakenduse tööd takistavad vead parandame esmajärjekorras. Vigade prioriteedid: Tase Selgitus Reageerimise kiirus Takistav kõrgeima prioriteediga viga/tööülesanne, mis takistab Viga tuleb koheselt parandada. põhifunktsionaalsuse toimimist. Vea tõttu ei ole võimalik edasi töötada või viga muudab edasise töötamise ebaotstarbekaks. Kriitiline kriitiline viga/tööülesanne, mis otseselt ei takista edasi Nõuab viivitamatut töötamist, kuid mis nõuab viivitamatut lahendamist. lahendamist 50 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine Kõrge kõrge prioriteediga viga/tööülesanne, mis tuleb etteantud Tellija määrab mõistliku tähtaja tähtajaks lahendada. Madal madala prioriteediga viga/tööülesanne, mis tuleb lahendada, Määratakse koos tellijaga kuid tähtaega võib edasi lükata vastavalt Tellija ja Teostaja tähtaeg vahelisele kokkuleppele. Triviaalne väga madala prioriteediga viga/tööülesanne, viibimine ei Lisatakse prioriteeditabeli avalda olulist mõju. lõppu Tabel 1 Vigade prioriteedid Analüüsi tähtsus ja vigade varakult avastamine Kvaliteet algab lähteülesandest ja detailanalüüsist. Mida varem viga leitakse, seda lihtsam on seda parandada. Järgnev tabel näitab, kuidas probleemi lahendamise ajakulu sõltub arendamise järgust, mil viga leiti. Millal viga leitakse Nõuded Arhitektuur Ehitus Süsteemi testimine Väljalase Millal viga tehakse Nõuded 1× 3× 5–10× 10× 10–100× Arhitektuur – 1× 10× 15× 25–100× Ehitus – – 1× 10× 10–25× Tabel 2 Vigade avastamine Näiteks, kui probleem nõuetes leitakse pärast väljalaset, siis selle parandamine võtab 10–100 korda rohkem aega, kui siis, kui see viga oleks leitud juba nõuete ülevaatamisel. 8.1.4 Kasutusjuhend ja koolitus Eesmärk Eesmärgiks on tellija kompetents ise portaali hallata ja statistikat jälgida Sisendid / sõltuvused • Analüüs • Drupal admin liides • Kliendi soovid Läbiviidavad 1. Vajaduste kaardistamine 2. Administreerimisjuhendi loomine tegevused 3. Statistika jälgimisjuhendi loomine vajadusel 4. Koolitus 5. Toe pakkumine 51 Riigihange 201015 Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine Teostatakse kliendi soovidele ja oskustele vastav juhend. Tehakse selle toel koolitus(ed) ja Kirjeldus vajadusel täiendatakse juhendit. Mõistlik oleks kliendil koolitada vähemalt ühe peaadministraatori, kes saab organisatsiooni siseselt vastata ise esimestele küsimustele. Eraldi koolitusel tutvustame statistika jälgimissüsteemi, Vajadusel saab pakkuda pimeaajalist hooldust ja tuge. Väljundid • juhend • koolitus • hilisem tugi Täitvad rollid • projekti juht • arendaja Kaasatud rollid • Tellija põhiülesanded: o Koolitusel osalemine o Peaadmistraatori valik Otsustuspunktid • Kui põhjalikku koolitust/juhendit vaja on? • Kas ja kui suures mahus on vaja hilisemat tuge? 52  Pakkumuse maksumuse vorm Pakkumus 191525, pakkuja: Trinidad Wiseman OÜ (11244225) Nr Nimetus Kirjeldus Kogus Ühi Ühiku hind Maksumus KM-ta KM Maksumus KM- Märkused Ei k % ga summeeru kogu- maksumu- sele 1 Pakkumuse kogumaksumus Pakkuja esitab 1 euro 37 400,00 37 400,00 20 44 880,00 hankelepingu alusel teostatavate tööde kogumaksumu se eurodes, kahe komakoha täpsusega. Maksumus kokku KM-ta: 37 400,00 Maksumus kokku KM-ga: 44 880,00 Kriteerium Numbri hindamine Väärtus  HANKELEPING nr 3-9/1503-1 Tervise ja Heaolu Infosüsteemide Keskus (registrikood 70009770), aadressiga Uus-Tatari 25, 10134 Tallinn, keda esindab põhimääruse alusel direktor Katrin Reinhold (edaspidi tellija), ja Astangu Kutserehabilitatsiooni Keskus (registrikoodiga 70003566), aadressiga Astangu 27 Tallinn 13519, keda esindab põhimääruse alusel personali- ja haldusosakonna juhataja direktori ülesannetes Veronika Kaska (edaspidi teenuse saaja), ja Trinidad Wiseman OÜ (registrikood 11244225), aadressiga Akadeemia tee 21/4, 12618 Tallinn, keda esindab põhikirja alusel juhatuse liige Marko Leppik (edaspidi täitja), edaspidi eraldi pool või koos pooled, sõlmisid käesoleva hankelepingu (edaspidi leping) alljärgnevas: 1. Lepingu ese 1.1. Tellija tellib ja täitja kohustub alates lepingu sõlmimise kuupäevast kuni 8 kuu jooksul teenuse saajale looma uue kodulehe „www.astangu.ee“ (edaspidi tööd) järgides lepingus ja selle lisades sätestatud tingimusi. 1.2. Tööde täpsem kirjeldus ja nõuded on toodud lisas 1 „Tehniline kirjeldus“. 1.3. Lepingu sõlmimise aluseks ja lahutamatuteks lisadeks on tellija poolt läbi viidud hanke „Astangu Kutserehabilitatsiooni Keskuse uue kodulehe loomine“ (viitenumber 201015) hankedokumendid ja täitja 01.10.2018 esitatud pakkumus, arvestades lepingus kokkulepitud erisusi. Dokumentide vastuolu korral lähtutakse eelkõige lepingust, seejärel hankedokumentidest ja täitja pakkumusest. 2. Lepingu maksumus ja tasumine 2.1 Lepingujärgne tööde eest tasumisele kuuluv kogumaksumus on 37 400 (kolmkümmend seitse tuhat neli sada) eurot, millele lisandub käibemaks. Tööde teostamise eest tasutakse vastavalt etappide maksumustele ja tähtaegadele järgmiselt: 2.1.1 esimese etapi tööde eest tasutakse 14 960 (neliteist tuhat üheksasada kuuskümmend) eurot ilma käibemaksuta; 2.1.2 teise etapi tööde eest tasutakse 14 960 (neliteist tuhat üheksasada kuuskümmend) eurot ilma käibemaksuta; 2.1.3 kolmanda etapi tööde eest tasutakse 7480 (seitse tuhat nelisada kaheksakümmend) eurot ilma käibemaksuta. 2.2 Lepingu maksumus on tellija jaoks lõplik, sisaldades kõiki täitja kulutusi, mis tekivad seoses lepingu täitmisega. Lepingu maksumus sisaldab tasu intellektuaalomandiõiguse üleandmise eest ja garantiikohustuse täitmise eest. 2.3 Täitja esitab tellijale arve .pdf või XML formaadis e-posti aadressile [email protected] pärast tööde üleandmise-vastuvõtmise akti (edaspidi ka akt) allkirjastamist poolte poolt. 2.4 Tellija tasub tööde eest arvel märgitud kuupäevaks. Maksetähtaeg ei tohi olla lühem kui 21 kalendripäeva alates nõuetekohase arve esitamisest. 3. Töö üleandmise ja vastuvõtmise tingimused 3.1 Täitja annab tööd lõplikult üle aktiga hiljemalt 31.05.2019. Tööd antakse aktidega üle kolmes etapis järgmiselt: 3.1.1 esimeses etapis teostatakse kodulehe analüüs, struktureerimine ja disain ning esimese etapi tööd antakse üle hiljemalt 31.01.2019. 3.1.2 teises etapis teostatakse kodulehe arendus, testimine ja koostatakse tööde dokumentatsioon ning tööd antakse üle hiljemalt 30.04.2019. 3.1.3 kolmandas etapis viiakse läbi koolitus ja antakse üle kodulehe kasutusjuhendid ning tööd antakse üle hiljemalt 31.05.2019. 3.2 Täitja kohustub koos aktiga tellijale üle andma kõik lepingu täitmisel saadud ja loodud materjalid. 3.3 Etappide tööde akti esitamisele järgnevast tööpäevast arvates on tellijal ja teenuse saajal  õigus mõistliku aja jooksul üle antud töö üle vaadata ning anda vajadusel mõistlik tähtaeg töödes esinevate puuduste kõrvaldamiseks. 3.4 Lõpliku töö aktiga üleandmise järgselt on tellijal ja teenuse saajal õigus ühe kalendrikuu jooksul tööd üle vaadata ja testida. Tellijal on õigus vajadusel nimetatud perioodi mõistliku aja võrra pikendada, teavitades sellest enne tähtpäeva saabumist täitjat 3 tööpäeva ette. 3.4 Akti allkirjastamine tellija ja teenuse saaja poolt tähendab poolte antud kirjalikku kinnitust, et tehtud tööd vastavad lepingu tingimustele. 3.5 Kui tellija või teenuse saaja tuvastab täitja poolt teostatud töödes või aktis puudusi, võib ta tööde vastuvõtmisest keelduda või võtta vastu vaid nõuetekohaselt teostatud tööd, mille eest on täitjal õigus saada tasu proportsionaalselt nõuetekohaselt teostatud tööga. Vastuvõtmisest keeldumisel esitab tellija täitjale tööde mittevastavuse kohta kirjalikku taasesitamist võimaldavas vormis teate, kirjeldades selles ära töödes või aktis esinevad puudused ja määrates puuduste kõrvaldamiseks mõistliku tähtaja. 3.6 Juhul, kui täitja ei kõrvalda töödes esinevaid puudusi tellija poolt antud täiendava tähtaja jooksul, loetakse, et täitja on lepingut oluliselt rikkunud. 3.7 Juhul, kui täitja ei kõrvalda puudusi põhjusel, et pooled ei jõua tehtud tööde kvaliteedi või lepingule vastavuse osas kokkuleppele, siis kaasatakse poolte kokkuleppel sõltumatu ekspert. Eksperdi otsus on pooltele täitmiseks kohustuslik. Eksperdi kaasamise kulud tasub süüdiolev pool. 4. Dokumentatsioon 4.1. Täitja varustab tellijat piisava dokumentatsiooniga, mis on vajalik, et tellija saaks käesoleva lepingu alusel loodud töid efektiivselt kasutada, hooldada ja kohandada, täiendades juba olemasolevat dokumentatsiooni või koostades vajadusel uue dokumentatsiooni. 4.2. Lepingu raames koostatavad dokumendid antakse tellijale või tellija poolt määratud kontaktisikutele üle eestikeelsetena. 4.3. Dokumentatsioon peab vastama tööde kirjelduses toodud töödele, sisaldama muudatusi ja olema terminoloogiliselt üheselt mõistetav. 4.4. Täitja uuendab või asendab kõik esinenud vigade või puudustega dokumendid garantiiperioodi jooksul. 4.5. Dokumentide antakse üle elektroonilisel infokandjal või muul tellija poolt näidatud elektroonilisel viisil. 5. Intellektuaalomand 5.1. Täitja annab tellijale ja teenuse saajale üle kõik töö autori varalised õigused nii Eesti kui teiste riikide territooriumite suhtes ilma piiranguteta. Autori isiklike õiguste kasutamiseks annab täitja tellijale ja teenuse saajale lihtlitsentsi kestvusega autoriõiguste kehtivuse tähtaja lõpuni. 5.2. Täitja loovutab tellijale ja teenuse saajale täielikult ja tagasivõetamatult autori varalised õigused originaalteostele ning annab lihtlitsentsi autori isiklikele õigustele tööde üleandmise hetkest, loobudes sellega lepingu alusel üle antud originaalteoste osas õiguste kasutamisest. 5.3. Tasu autoriõiguste loovutamise ning litsentsi andmise eest sisaldub lepingu hinnas. 5.4. Täitja annab tellijale ja teenuse saajale piiramatud õigused töö kasutamiseks, arendamiseks ja mistahes muudatuste tegemiseks töös ning tööde omandiõiguse. 5.5. Tellijal ja teenuse saajal on õigus punktides 5.1 - 5.4 nimetatud õigusi ilma piiranguteta kolmandatele isikutele üle anda või litsentseerida. 5.6. Tööde üleandmisega annab täitja tellijale ja teenuse saajale õiguse tööde testimiseks ja muul viisil kasutamiseks, mis on vajalik tööde vastuvõtmiseks. Tellija ja teenuse saaja omandab punktides 5.1 - 5.4 nimetatud intellektuaalomandi õigused lepingu täitmise käigus tööde eest tasumisest alastes. 5.7. Täitja on kohustatud tagama intellektuaalse omandi õiguste (eeskätt autoriõiguste) olemasolu ja kehtivuse, samuti nende ülemineku tellijale viisil, mis võimaldab tellijal ja teenuse saajal lepingu lõppedes üle võtta täitja funktsioonid. 5.8. Kõik otsesed ja kaudsed kahjud, mis tulenevad sellest, et kolmandal isikul on või väidetavalt on varalisi või mittevaralisi intellektuaalsest omandist tulenevaid õigusi lepingu alusel üle antavate intellektuaalse omandi objektide suhtes, kannab täitja. 6. Garantii 6.1. Täitja annab kõikidele käesoleva lepingu alusel teostatud töödele ühe (1) aastase garantii. Garantii katab kõiki garantii tähtaja jooksul ilmnenud tööde puudusi ja lepingu tingimustele mittevastavusi (edaspidi ka: viga). 6.2. Garantii tähtaeg hakkab kehtima alates töö vastuvõtmisest (akti allkirjastamisest tellija ja teenuse saaja poolt). 6.3. Täitja on garantii kehtivuse ajal (garantii tähtaja jooksul) kohustatud tasuta kõrvaldama töödes avaldunud vead ja lepingu tingimustele mittevastavused, sealhulgas on täitja kohustatud uuendama või asendama kõik esinenud veaga seonduvad dokumendid. 6.4. Tellija informeerib täitjat töös esinevatest vigadest, vea iseloomust ja ulatusest viivitamatult selle ilmnemisel, niivõrd kui seda saab tellijalt mõistlikult oodata. 6.5. Täitja on kohustatud garantii korras teostama eelkõige järgmist: 6.5.1. Vea ilmnemisel vea otsimine (lokaliseerimine), veaolukorrale lahenduse leidmine ja vea parandamine; 6.5.2. Vea põhjuste analüüs ning selle tulemuste kirjalikku taasesitamist võimaldavas vormis (näiteks e-posti teel) esitamine tellijale, samuti ettepanekute tegemine ennetavate meetmete kasutuselevõtmise kohta; 6.5.3. Vea parandamisega seoses paigaldamise ja seadistamise toe pakkumine tellijale, samuti sellega seotud konsultatsioonid; 6.5.4. Vigase või puuduliku dokumentatsiooni parandamine, sealhulgas dokumentatsiooni täiendamine ja uuendamine, kui selline vajadus tuleneb vigade parandamisest. 6.6. Täitja kõrvaldab garantiiperioodil ilmnenud vead sõltuvalt vea iseloomust hiljemalt 5 tööpäeva jooksul. Kui vea kõrvaldamine nimetatud aja jooksul ei ole võimalik, teatab täitja tellijale põhjuse, miks vea parandamine ei ole 5 tööpäeva jooksul võimalik ja millise aja jooksul on võimalik viga parandada. Kui täitja ei kõrvalda viga kokkulepitud tähtaja jooksul, võib tellija korraldada vea kõrvaldamise kolmanda isiku poolt täitja kulul ja riisikol. 6.7. Juhul kui töö hõlmab edasisi arendustöid ja kolmas osapool või tellija teeb tarnitud lähtekoodis täitjaga kooskõlastamata muudatusi, siis garantii katkeb. Garantii ei katke, kui tellija suudab eristada lähtekoodis tehtavaid muudatusi. 7. Poolte vastutus 7.1. Juhul kui tellija ei tasu vastu võetud tööde eest tähtaegselt, on täitjal õigus nõuda tellijalt viivise tasumist suuruses 0,15% iga tasumisega viivitatud päeva eest tähtajaks tasumata summalt, kuid mitte rohkem, kui 30% lepingu kogumaksumusest. 7.2. Juhul kui täitja ei anna töid tellijale üle punktis 3.1 sätestatud tähtaegadeks või viivitab tellija poolt teatavaks tehtud puuduste kõrvaldamisega, kohustub täitja maksma tellijale leppetrahvi 0,15% lepingu kogumaksumusest (lepingu punkt 2.1) iga üleandmise või puuduste kõrvaldamisega viivitatud päeva eest, kuid mitte rohkem, kui 30% lepingu kogumaksumusest. 7.3. Garantiitingimuste rikkumise korral on tellijal õigus nõuda täitjalt leppetrahvi 5% lepingu koguhinnast iga juhtumi korral. 7.4. Tellijal on õigus tasaarvestada leppetrahvi summa täitjale töö teostamise eest tasumisele kuuluvate maksetega või nõuda leppetrahvi tasumist kahe nädala jooksul alates tellija poolt vastava nõude esitamisest. 7.5. Leppetrahvi ja viivise nõuded tuleb esitada hiljemalt kolme kuu jooksul alates nõude aluseks olevast asjaolust teada saamisest kirjalikku taasesitamist võimaldavas vormis allkirjastatult lepingu allkirjastamisõigusliku isiku poolt. 7.6. Lepingust tulenevate viiviste ja leppetrahvide maksmine, samuti tekitatud kahju hüvitamine ei vabasta lepingut rikkunud poolt mistahes lepingujärgsete kohustuste täitmisest. 7.7. Leppetrahvi nõudmine ja tasumine ei välista ega vähenda tellija õigust nõuda täitjalt rikkumise korral kogu põhjustatud kahju hüvitamist ning kasutada täitja osas muid seadusest tulenevaid õiguskaitsevahendeid. 7.8. Tööde vastuvõtmine tellija poolt ei vabasta ega vähenda täitja vastutust Lepingu rikkumise eest. 8. Poolte vahelised teated, kontaktisikud ja tööde teostajad 8.1. Teadete edastamine toimub üldjuhul telefoni, e-posti, või posti teel. Juhul, kui teate edastamisel on olulised õiguslikud tagajärjed, peavad teisele poolele edastatavad teated olema edastatud taasesitamist võimaldavas vormis (s.o kirjalikus vormis või e-posti teel). Informatiivset teadet võib edastada ka telefoni teel. 8.2. Teate edastamise hetkeks loetakse elektronkirja tehniliselt tõendatud saatmise hetk või kirjaliku teate allkirjaga tõendatud vastuvõtmise hetk. 8.3. Tellija volitatud esindajaks täitjale vajaliku informatsiooni andmisel oma pädevuse piires, töö kvaliteedi kontrollimisel, töö vastuvõtmisel ja töö üleandmise vastuvõtmise aktide allkirjastamisel on projektijuht Helen Simisker (tel 521 3172; e-post: [email protected]). 8.4. Teenuse saaja volitatud esindajaks täitjale vajaliku informatsiooni andmisel oma pädevuse piires, Töö kvaliteedi kontrollimisel, töö vastuvõtmisel ja töö üleandmise vastuvõtmise aktide allkirjastamisel on Astangu Kutserehabilitatsiooni Keskuse kommunikatsioonispetsialist Ave Aun (tel 687 7290; e-post: [email protected]). 8.5. Täitja volitatud esindajaks projekti täitjapoolsel läbiviimisel ja töö üleandmise vastuvõtmise aktide allkirjastamisel on Peeter Ossip (tel 516 9171; e-post: [email protected]). 8.6. Täitja on kohustatud kasutama lepingu täitmisel riigihankes tööde teostamiseks esitatud spetsialiste. Spetsialisti vahetumisel lepingu täitmise perioodil teavitab täitja meeskonnaliikme vahetusemisest tellija kontaktisikule. Lisaks riigihankes esitatud spetsialistidele on täitjal õigus kaasata töö teostamisse täiendavaid spetsialiste, kes ei asenda riigihankes esitatud spetsialistide meeskonda, vaid täiendavad neid. 9. Lepingu kehtivus ja muutmine 9.1. Leping jõustub selle allkirjastamisest poolte poolt ja kehtib kuni lepinguga võetud kohustuste täitmiseni. Leping on koostatud eesti keeles ja allkirjastatud digitaalselt. 9.2. Tellija võib Lepingu igal ajal ühepoolselt üles öelda, teatades täitjale 60 päeva ette. 9.3. Tellijal on õigus Leping ühepoolselt etteteatamistähtaega järgimata üles öelda, kui Täitja on Lepingut oluliselt rikkunud. 9.4. Lepingu mõne sätte kehtetuks tunnistamine kohtu või mõne muu pädeva ametiasutuse poolt ei muuda kehtetuks ülejäänud Lepingut. 9.5. Lepingut muudetakse pooltevahelise kirjaliku kokkuleppega lepinguga samas vormis. 9.6. Lepingu muudatused jõustuvad pärast nimetatute poolte poolt allakirjutamist või poolte määratud tähtajal. 10. Lõppsätted 10.1. Lepingu täitmisel tekkinud vaidlused ja lahkarvamused lahendavad pooled läbirääkimiste teel. Kokkuleppe mittesaavutamisel lahendatakse vaidlused Harju maakohtus. 10.2. Lepingu täitmisel ja lepingust tulenevate vaidluste lahendamisel lähtutakse Eesti Vabariigi õigusaktidest. 10.3. Täitjal puudub volitus tegeleda Lepingu raames avalike suhetega ja anda teateid pressile, elektroonsele meediale, üldsusele või teistele auditooriumidele, välja arvatud tellija eelneval kirjalikku taasesitamist võimaldaval nõusolekul. 10.4. Pooled ei tohi lepingust tulenevaid õigusi ja kohustusi üle anda kolmandatele isikutele ilma teise poole kirjaliku nõusolekuta. 10.5. Lepingu dokumendid koosnevad käesolevast lepingust, lepingu lisadest ning lepingu muudatustest, milles pooled võivad kokku leppida lepingu allakirjutamise järgselt. 11. Lepingu lisad: Lepingu lahutamatuteks osadeks lepingu sõlmimise hetkel on järgmised dokumendid: 11.1. Lisa 1. Tehniline kirjeldus ja kodukord; 11.2. Lisa 2. Pakkumus. 12. Poolte allkirjad: Tellija: Teenuse saaja: Täitja: /allkirjastatud digitaalselt/ /allkirjastatud digitaalselt/ /allkirjastatud digitaalselt/ ................... ........................... .................................. Katrin Reinhold Veronika Kaska Marko Leppik direktor direktori ülesannetes juhatuse liige Lisa 1. Tehniline kirjeldus ja kodukord Tervise ja Heaolu Infosüsteemide Keskus (edaspidi hankija) koos Astangu Kutserehabilitatsiooni Keskusega (edaspidi ka tellija või keskus) tellib kodulehe www.astangu.ee visuaalse kujunduse ja kontseptsiooni ning kodulehe tehnilise arenduse, sh andmete migratsiooni vanalt veebiplatvormilt uuele. Tööde tulemusena valmib www.astangu.ee kodulehekülg koos administreerimisliidesega, mille vajalikud funktsionaalsused on tagatud tarkvara laiendamise ja/või seadistamisega ning mille puhul on tagatud käesolevas dokumendis loetletud nõuete täitmine, samuti funktsionaalsuses testimine enamlevinud veebilehitsejatega, sh nutiseadmete veebilehitsejatega. Eesmärk on luua Astangu Kutserehabilitatsiooni Keskusele uus koduleht, mis on kohaldatud ka mobiilile jt nutiseadmetele, kujunduslikult kaasaegne ja kutsuv ning peegeldab paremini tellija rolli erivajadustega inimestega tegeleva innovatiivse asutusena. Uus koduleht peab olema efektiivsemalt administreeritav ning võimaldama Astangu Kutserehabilitatsiooni Keskuse tegevuste ja rollide kuvamist kergelt muuta, kuivõrd keskuse eesmärgid on ajas muutuvad. 1. Hetkeolukord Praegune leht ei võimalda visuaalset materjali lisada või võimaldab seda minimaalselt. Kuna tellija tegeleb erivajadusega inimestega, on väga oluline, et info oleks sihtrühmale arusaadav ning neid kaasav, võimaldades ekraanilugeritel paremini kodulehte lehitseda, muuta kontrastsust ja tekstisuurust, mida olemasolev koduleht ei võimalda. Tellija veebileht on tihti esmaseks kohaks, kust tellija kohta infot otsitakse. Seda teevad nii tellija olemasolevad kui potentsiaalsed kliendid, nende lähedased või nendega tegelevad spetsialistid, koostööpartnerid välisriikidest jt. Praegune koduleht on tehtud aastal 2009. Viimase 9 aastaga on koduleht nii kujunduslikult kui kasutajamugavust silmas pidades ajale jalgu jäänud. Praegune veebileht ei peegelda tellija rolli sotsiaalteenuste ja tööle saamist toetavate teenuste ning kaasava hariduse arendajana Eestis. 2. Kodulehe sihtgrupid 2.1. Teenuse saaja või tema võrgustik – teenuse saaja: keskuse poolt pakutavaid või vahendatavaid teenused kasutav isik; teenust saava inimese võrgustik: nt lapsevanem, õpetaja, kohaliku omavalitsuse töötaja, töötukassa spetsialist jne, kelle huviks on info võimalikult kiiresti ja vähe klikke tehes kätte saada. 2.2. Intellekti-, kuulmis või nägemispuudega erivajadusega inimene – otsib kodulehelt infot, nt keskusesse õppima tuleku, õppetöö korralduse kohta. Info üles leidmiseks ja sellest aru saamiseks on oluline kodulehel sümbolite, piltide ja videote kasutamine, samuti ekraanilugeritele kohandatavus, kontrastid, tekstisuurususe muutmise võimalus jmt. 2.3. Tööotsijad, vabatahtliku töö tegijad –inimesed, kes on huvitatud keskuses töötamisest või siin vabatahtliku töö tegemisest. 2.4. Avaliku teabe otsija – iga inimene, ametnik, ajakirjanik, kes otsib konkreetset avalikku infot. 2.6 Valdkonna spetsialistid, koostööpartnerid Eestis - otsib keskuse veebilehelt infot enesetäiendamise võimalustest, seda nii iseseisvalt omandamiseks (nt käsiraamatud, juhised, metoodika-õpetused), koolitustel osalemiseks kui muudest võimalikest uudsetest lähenemistest (nt webinar, kootsimine, e-õpe vms). 2.5. Koostööpartnerid välismaalt – võimalikult ligitõmbavalt saada kätte põhiline keskust puudutav info ingliskeelselt ja venekeelselt baaslehelt. 2.6. Astangu tooteid osta soovijad – võimalus visuaalselt kuvada keskuse toodangut (ei eelda e-poe vmt loomist). 2.7. Tööandja, kes soovib tulevikus palgata tööle vähenenud töövõimega inimest – edulood, videod. 3. Tellitavad tööd 3.1. Kodulehe www.astangu.ee visuaalne kujundus ja kontseptsioon/struktuur. 3.2. Kodulehe www.astangu.ee tehniline arendus lähtuvalt kokkulepitud kontseptisoonist ja visuaalsest kujundusest, sh andmete migratsioon vanalt veebiplatvormilt uuele. 3.3. Kodulehe administreerimiseks viiakse läbi kasutajaliidese koolitus kuni 5 inimesele. 4. Nõuded kodulehele 4.1. Uus kujundus, kaasaegsem välimus, sh avalehe kontseptsioon, mis paremini erinevatele sihtrühmadele mõeldud teenuseid eristada aitab, nt Haigekassa koduleht (www.haigekassa.ee). See tähendab, et põhimenüü muutub + kitsas illustreeriv pilt esilehele, mida lihtne vahetada oleks. 4.2. Astangu rollide parem eristus, et kompetentsi- ja kutserehabilitatsiooni keskuse pool eristuksid paremini. See tähendab, et kodulehe kasutajatele/külastajatele on info selgelt ja kergelt leitav. Alates 2015. aastast on Astangu kompetentsikeskuse roll suurenenud, seega peaks koduleht toetama keskuse mitmekülgsust. Info peavad üles leidma väga erinevad sihtrühmad alustades keskuse kliendist lõpetades spetsialistidega, keda eelmisel aastal koolitati üle 1500. 4.3. Visuaalse materjali hõlpsam lisamine. Kujunduselemendina piltide ja videote parem lisamisvõimalus, mitte ainult ühe uudise osana (nt Tallinna Tervishoiu Kõrgkooli (TTK) koduleht www.ttk.ee). 4.4. Astangu Facebook’i lehekülg on lingitud kodulehega, et Facebook’i uudisvoog jookseks otse kodulehele (nt Tervise Arengu Instituudi (TAI) koduleht www.tai.ee). 4.5. Sündmuste-koolituste kalender, kus kuvada kõik keskuse korraldatavad koolitused ja üritused kalendri formaadis (nt nii: http://www.tai.ee/et/koolitused-ja-sundmused). Lisaks peab olema võimalus eraldi välja tuua, mis koolitusi keskus üldse pakub, nt tellitavad koolitused. 4.6. Rubriik uudiste ja kvalitatiivsete saavutuste paremaks kuvamiseks, nt „ole kursis“ (nagu TAI esilehel) rubriik vms, kuhu oleksid koondatud keskuse kliendilood - kes kuhu tööle on läinud, mis on neist saanud, õppijate tsitaadid jms - lisaks kvantitatiivsetele tulemustele peaks olema võimalus kvalitatiivseid saavutusi paremini esitleda. 4.7. Esilehe selgem visuaalne ja vormiline liigendatus (nt Tartu Ülikooli koduleht www.ut.ee ), võib eristada kas sümbolitega (nagu kliinikud www.itk.ee ) või pildiga. 4.8. Tööpakkumistele sobilik alamleht - eraldi alamleht keskuse tööpakkumiste jaoks. Praegu peab tellija linkima CV keskuse lehele, sest kodulehel pole head formaati tööpakkumiste kuvamiseks. 4.9. Metoodiliste materjalidele alamleht - kompetentsikeskuse materjalidele eraldi koht, kuhu koondatakse ettekanded, kõned jms (nt https://www.haigekassa.ee/haigekassa/pressile). 4.10. Alamlehtede parem liigendatus – tellija kodulehte külastas juunis üle 2800 üksikkülastaja, külastuste arv kokku oli ligi 3400. Statistikast tuleb välja, et ühe külastuse jooksul lehitseb üks külastaja keskmiselt 10,37 alamlehte, see tähendab, et vajamineva info kättesaamiseks tuleb tal teha üle 10 kliki. Erinevate allikate põhjal oleks veebilehelt vajamineva info kätte saamiseks keskmine umbes 3 klikki. Terve 2015. aasta jooksul külastas tellija kodulehekülge ligi 28 000 üksikkülastajat ning külastuste arv kokku oli 53 729. 2017. aastal on samad numbrid vastavalt kuni 73 000 ning 94 736, seega kodulehe külastajate arv on pidevalt kasvav, mis suurendab vajadust efektiivsemalt kasutatava kodulehe järele. 4.11. Mobiilile kohandatud veeb - juunikuine kodulehe külastatavuse statistika näitab, et Android brauseriga on iseseisvalt www.astangu.ee trükitud sisse 141 korral, see on 0,3% lehekülje külastatavusest. Tabamusi ehk teiste lehekülgede linkide kaudu on Astangu kodulehekülge Android brauseriga juunis külastatud aga ligi 6400 korda. Juulis on kodulehte külastatavate brauserite hulka lisandunud ka iOS brauser. 4.12. .pdf failide parem esitamise võimalus – tellija eeldab pakkujalt .pdf failide asendamiseks mõne muu lahenduse või vormingu esitamist, kuivõrd .pdf failide lugemine ekraanilugejaga on osutunud problemaatiliseks. 4.13. Kontaktide asetsemine kodulehel - kontaktid peaksid asetsema lisaks eraldi kontaktide lehele ka erinevate erialade ääres (nt nagu http://ttk.ee/et/tutvustus), et külastaja kiiremini huvipakkuva teemaga seotud inimesega ühendust saaks võtta. See parandab nii teenuste ligipääsetavust kui toob töötajaid kliendile lähemale. 4.14. Lingitavatele failidele eraldi koht - lisamaterjalid on eraldi paremale välja toodud. 4.15. WCAG 2.0 nõuete käepärasem rakendamine – Koduleht peab arvestama erivajadustega isikutega ning vastama WCAG 2.0 AA taseme edukriteeriumitele. Sealhulgas peab veebileht võimaldama valida 5 erinevat teksti suurust ning vaegnägijatele sobivat kontrastsust (erivärviliste taustade kasutamine). 4.16. Põhiinfoga vene- ja inglise keelne alamleht – hetkel on olemas kodulehe ingliskeelne versioon (http://eng.astangu.ee/ ), kus on kirjas põhiline vajaminev info, täitja ülesanne on luua uue kujunduse ja struktuuriga vene- ja inglise keelne leht arvestades olemasoleva inglise keelse lehe mahtu. Pakkuja ei pea tekste tõlkima vene keelde ega venekeelsele osale looma sisu, kuid peab suutma kodulehe struktuuri ja menüüd tõlkida vene keelde. 5. Kodulehe kasutatavus 5.1. Koduleht peab võimaldama loomulikku suhtlust, olema mugav ja kasutajale intuitiivne. 5.2. Koduleht peab olema lihtsalt ja kergesti leitav ning turvaliselt kasutatav, samuti võimaldama erinevate seadmete ja operatsioonisüsteemide kaudu lehe kasutamist, seda ka erivajadustega inimestele. 5.3. Kodulehte peab saama kasutada kõikide enamlevinud veebisirvimis programmidega, sh enamlevinud nutiseadmete veebisirvijatega. Veebirakendus peab olema kasutatav Android, iOS, Mac OS X ja Windows seadmetes. 5.4. Kodulehele tehakse kujunduslahendus ning see peab olema dünaamiline veebidisain (responsive web disain) ehk kohanduv erinevate arvutiekraani laiustega (1024, 1280, 1366, 1920, 2560 px) ning enamlevinud nutitelefoni ja tahvelarvuti ekraanidega. 5.5. Koduleht peab olema klaviatuuriga navigeeritav. 5.6. Kodulehe valitud asukoht peab olema menüüs rõhutatud, et kasutaja näeks, milliste teemade all lehekülg asub. 5.7. Kodulehel peab olema navigatsiooniriba (breadcrumb). 5.8. Otsingu tulemused peavad olema üksteisest eristuvad ja esile on toodud leitud tulemuste arv. 5.9. Mitteleitud lehe ja serveri veateated (nt Error 404 ja 403) peab olema võimalik seadistada veebimootoris. 5.10. Veebimootori veateated peavad olema inimloetavad, ega anna kasutajale tehnilist informatsiooni vea kohta (nt kataloogide struktuur, koodiread jms). 5.11. Koduleht peab sisaldama läbivalt peamenüüd, keelemenüüd, otsingut, logo, jalust ja viidet sisupuul. 5.12. Igal sisulehel peab olema võimalik artikleid printida koos lehe päises oleva logoga. 5.13. Sisuartiklis kuvatakse kuupäev, millal artikkel on lisatud. 5.14. Otsingu süsteem võimaldab lehekülgede sisust, sissejuhatustest, pealkirjadest ja pildiallkirjadest ja .pdf, .doc, .docx dokumentidest otsida vajalikku informatsiooni koos suuruse muutmise funktsiooniga. Otsingu süsteem annab otsingu võimaluse ka inglise ja vene keelsetest tekstidest. 5.15. Otsingusüsteem peab töötama sisuhaldussüsteemide puhul kasutades solr funktsionaalust. 5.16. Sisulehtede URLid peavad olema koostatud vastavalt sisuhalduses sisestatud sisulehe pealkirjale (clean url). 5.17. Kohandatud skriptid, stiililehed ja mallid peavad paiknema eraldi kataloogis. 5.18. Veebilehestruktuurist peab koostama sisupuu. 5.19. Vaegnägijatel peab olema võimalus kujundust muuta (teksti suuruse, reavahe ja kontrastsuse muutmine). 5.20. Koduleht peab olema kasutajasõbralik ning seda koostades arvestatakse kasutajakeskse veebi lehekülgede disaini uuringuga ning koduleht vastab selles toodud nõuetele. (https://www.mkm.ee/sites/default/files/kasutajakeskse_veebi_lehekylgede_disain.pdf) 5.21. Nutiseadme kohta peab kujundus optimeeritud olema. Optimeerimine peab olema võimalik igale lehele ja pildile lisada läbi tekstivälja. Kogu kodulehe sisu (tekstid, pildid, videoklipid) peab saama tellija ise hallata. 6. Mittefunktsionaalsed nõuded 6.1. Kujundus ning arendused peavad olema teostatud vabavaralisel platvormil Typo3 kõige uuemal LTS versioonil või Drupal LTS kõige uuemal versioonil. 6.2. Typo3 puhul peavad mallide arendused olema realiseeritud Fluidi funktsionaalsusel. 6.3. Arendatud koduleht peab töötama MariaDB viimasel stabiilsel versioonil. 6.4. Arendatud koduleht peab töötama PHP versioonil 7.2 või uuem. 6.5. Kodulehe ülesehitus, struktuuri esitus ja sisu ülesehitus peab olema esmatasandil otsingumootorite jaoks optimeeritud vastavalt Google poolt antud kirjeldusele (http://static.googleusercontent.com/media/www.google.com/et//webmasters/docs/search- engine-optimization-starter-guide.pdf). 6.6. Veebilahenduse disain peab olema rakendusfunktsionaalsusest eraldatud, et oleks võimalik sõltumatult muuta nii rakenduse koodi kui disaini. 6.7. Veebileht peab arvestades käesolevas dokumendis kehtestatud erinõudeid https://www.mkm.ee/sites/default/files/riigi_it_koosvoime_raamistik.pdf. 6.8. HTML-i lõigatud disainivaated ja kujunduse kodeerimine kasutades HTML5i ja CSSi ning selle testimine enimlevinud brauseritega. 6.9. Kodulehe HTML5 ja CSS koodid peavad vastama W3C tehnilistele standarditele. 6.10. Veebisisu kodeeritakse UTF-8 formaadis. 6.11. Veebilehtede paremaks leidmiseks kasutatakse automaatset XML sisukaardi protokolli (toetatud peab olema vähemalt Google Sitemap). 6.12. Koduleht peab olema optimeeritud, et tagada globaalsete otsingumootorite tugi (SEO). 6.13. Kodulehel kasutatakse inimloetavaid veebiaadresse (leheküljele antakse tekstiline veebiaadress vastavalt pealkirjale, see ei ole suvaline numbrite, tähtede ja kirjavahemärkide segu). 6.14. Koduleht peab olema arendatud selliselt, et oleks võimalik selle all olevaid tarkvarasid (CMS, andmebaas, veebiserver jms) vajadusel uuendada ja paigata ilma täiendava arenduseta. 6.15. Koduleht on kasutajasõbralik ning seda koostades arvestatakse kasutajakeskse veebi lehekülgede disaini uuringuga ning koduleht vastab selles toodud nõuetele. (https://www.mkm.ee/sites/default/files/kasutajakeskse_veebi_lehekylgede_disain.pdf ). 7. Nõuded haldusliidesele ja administreerimisele 7.1. Kodulehe haldusliidese kasutajad peavad olema tuvastatavad kasutades kaheastmelist autentimist (2FA – näiteks ID-kaardi/mobiil-ID/SMART-ID vmt) ning süsteem peab võimaldama anda erinevaid õiguseid/privileege (nt kasutajate haldur, sisu haldur jne). 7.2. Autentimine peab olema võimaldatud ka koormusjaoturi kasutamise puhul. 7.3. Administreerimisliidese ligipääsu peab olema võimalik piirata ehk ei tohi olla väljast (internetist) kättesaadav. 7.4. Kodulehe haldusliidest peab saama kasutada enamlevinud veebisirvimise programmidega. 8. Turvalisuse nõuded 8.1. Arvestada tuleb turvalisuse nõuetega süsteemi arhitektuuri loomisel kogu lahenduse elutsükli vältel. 8.2. Kodulehe lahenduste turvalisus vastab OWASP ASVS standardile (level 2, vt http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standa rd_Project) ja kindlasti peavad olema likvideeritud OWASP Top 10 veebirakenduste nõrkused (https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Stan dard_Project). 8.3. ISKE turvaklass on K1T1S1 ja arvestada tuleb minimaalselt moodulite B5.4 ja B5.7 nende meetmetega, mis on realiseeritavad arendaja poolt vt https://www.ria.ee/iske. 8.4. Koduleheküljel tehtavaid tegevustest peab olema võimalik salvestada logi. Kodulehe logist peab olema võimalik tuvastada kes, mida, kus, kust, kuidas tegi ja selle tegevuse tulemus. 8.5. Logi peab olema võimalik salvestada failisüsteemi. 8.6. Koduleht peab võimaldama sisu edastamist üle krüpteeritud kanali (HTTP üle TLS’i ehk HTTPS) - https://en.wikipedia.org/wiki/HTTPS. 8.7. Kõik isikuandmed tuleb edastada üle turvatud ühenduse. 8.8. Kõik sisselogimise teave tuleb vahetada üle turvatud ühenduse. 8.9. Tuleb kasutada HTTP turvapäiseid (HTTP Security Headers - Content Security Policy, X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, Cross-Origin Resource Sharing ning kui leht täielikult HTTPS siis ka Strict-Transport-Security). 9. Muud nõuded 9.1. Arendaja peab koostama vähemalt paigaldusjuhendi ja administreerimisliidese juhendi, sealhulgas peab paigaldusjuhend sisaldama vajalike lisatarkvarade installeerimis-, konfigureerimis- ja kasutamisjuhiseid. 9.2. Arendaja peab tööde valmimisel esitama testraporti, kus arendaja testib kõik kasutuslood üle arvutis (veebileht peab toetama järgmisi operatsiooni süsteeme Windows, Linux ja iOS, Mac OS X ning brauserid: Chrome, Firefox ja IE, Edge, Safari) ning nutiseadmes (operatsiooni süsteemid Android, iOS ja Windows). Testlood luuakse eelduslikult TestLinkis ning testraport edastatakse TEHIK-ule TestLink peal tehtud testlugude põhjal. Arendaja peab TestLinkis peale testimise tulemuste sisestamist genereerima Wordi formaadis testiraporti. 9.3. Arendaja peab arvestama oma ajakavas hankija poolt teostatava testimise perioodiga kuni 1 kuu. Veebilehele teostab TEHIK funktsionaalsuse- ja turvatestimise. 9.4. Arendajal peab olema portaali arendusfaasis võimalik majutada loodavat portaali oma serveris. Täitja peab tõstma teostatud tööd gitlab.sotsiaalministeerium.ee keskkonda. 9.5. Hankija võib eduka pakkujaga tema poolt esitatud lahendust enne tööde teostamisega alustamist täpsustada osas, mis ei muuda pakkumust põhimõtteliselt. Kodukord 1. EESMÄRK 1.1. Kodukorra eesmärk on täpsustada hankelepingu alusel tööde tellimise kord ja põhimõtted, täitja ja tellija omavaheline suhtlus ning tagasiside andmise kord. 1.2. Tellija võib teha kodukorda muudatusi, teavitades täitjat kodukorra muutmisest. 2. MÕISTED 2.1. Töö – Lepingus (hankeleping) fikseeritud töö(d)/tegevus(ed) ja üle antav(ad) tulem(id), mida saab testida või mille valmimist saab kinnitada tellija ja teenuse saaja. 2.2. Üleandmise ja vastuvõtmise akt (Akt) - Töö üleandmist ja vastuvõtmist kinnitav dokument, mis allkirjastatakse täitja, teenuse saaja kui tellija poolt ja mis on Täitjale aluseks arve esitamiseks ning Tellijale arve tasumiseks. 3. TÄITJA, TELLIJA ja TEENUSE SAAJA ÜLESANDED 3.1. Täitja põhiülesanded: - teostada kokkulepitud tööd kokkulepitud ulatuses, mahus ja ajakavas; - koostada ja täiendada tööde teostamise käigus kokkulepitud dokumentatsiooni; - anda selgitusi ja konsultatsioone teostatud tööde kohta; - koolitada tellijat ja teenuse saajat; 3.2. Pooled täpsustavad täitja ülesandeid Lepingu sõlmimisel. 3.3. Tellija ja teenuse saaja põhiülesanded on: - tagada täitjale tööde teostamiseks vajalik informatsioon, dokumentatsioon ja juurdepääsud; - üle vaadata, testida ja kooskõlastada täitja esitatavad tulemid, parandus- ja täiendusettepanekud kokkulepitud tähtaegade jooksul; - tagada tellija hallatavate infotehnoloogiliste keskkondade korrektne toimimine Tööde teostamise vältel, mis on olulised täitja poolsete kohustuste täitmiseks; - maksta tasu nõuetekohaselt teostatud tööde eest. 3.4. Vajadusel täpsustavad Pooled tellija ülesandeid lepingu sõlmimisel. 4. ÜLDINE TÖÖKORRALDUS 4.1. Tööde teostamise metoodika lepitakse kokku projekti esimesel kohtumisel. 4.1.1. Tellija eelistab kasutada arendusmetoodikat, kus arendustööd ja kooskõlastamised toimuvad nädalaste tsüklitena. Selline lähenemine võimaldab arendustööd jagada osadeks ning fokusseerida igal nädalal kindlale lahenduse osale. 4.1.2. Iganädalasel koosolekul tutvustab täitja teostatud tööd ning lepitakse kokku järgmise nädalal teostatavates töödes. 4.2. Lepingu eesmärgi saavutamiseks vajalikud etapid ja etappide tähtajad fikseeritakse vajadusel lepingus. 4.3. Töökorraldus arendustööde testimisel: 4.3.1. Täitja annab tellijale üle omalt poolt testitud Töö (vt tööde kirjeldus p 9.4). Tellija poolel testivad tööd TEHIK kui tellija esindaja (testib tehnilist osa) ja teenuse saaja kui kasutaja (testib sisulist osa). 4.3.2. Tellija esindaja ja teenuse saaja testivad tööd testkeskkonnas. 4.4. Akteerimisele kuulub Töö, mis on edukalt läbinud vastuvõtutestimise tellija testkeskkonnas. 4.5. Lepingu täitmisest tulenev suhtlus toimub eesti keeles. 5. LEPINGU TÄITMISEGA SEOTUD INFOVAHETUS 5.1. Lepingute täitmisega seotud dokumentatsiooni haldamiseks ja jagamiseks kasutatakse Tellija dokumendihalduskeskkonda Confluence. 5.1.1. Dokumentide hoidmise struktuur, selle täiendused ja muudatused lepitakse kokku Poolte projektijuhtide vahel. 5.1.2. Dokumentide lisamise, muutmise ja kustutamise reeglid lepitakse kokku Poolte projektijuhtide vahel, kes tagavad kokkulepitud reeglite järgimise oma meeskonna poolel. 5.2. Konfiguratsiooni- ja arendustööde ülesannete suunamiseks ja jälgimiseks, vigade ja probleemide haldamiseks ning tööaja arvestuseks kasutatakse Tellija projektikeskkonda Jira. 5.2.1. Tellija võib lisaks Jiras registreerimisele viidata leitud vigadele ka e-kirja vm suhtluskanali vahendusel, kuid vea/tööülesandega tegelema hakkamise eelduseks Täitja poolel on vea registreerimine Jiras ning lepingus toodud nimetatud tööde eest vastutava isiku poolt antud korraldus tööde alustamiseks. 5.2.2. Vajadusel täpsustavad Pooled tööülesannete lisamise nõuded (pealkirjad, teemad, ülesannete prioriteetide kategooriad jmt). 5.2.3. Kui ülesande lahendamise prognoositav aeg ületab kolm tööpäeva, peab Täitja ülesande tükeldama väikesemateks alamülesanneteks. 5.3. Rakenduse lähtekoodi hoidmiseks kasutatakse https://gitlab.sotsiaalministeerium.ee. 5.4. Lepingu täitmisega seotud muu, igapäevane teabevahetus toimub e-kirja, telefoni, Skype teel või koosoleku vormis. Poolte projektijuhid tagavad teabe edastamise ja saamise. 6. NÕUDED DOKUMENTEERIMISELE 6.1. Projekti dokumentatsioon peab olema terviklik ja terminoloogiliselt üheselt mõistetav. 6.2. Dokumentatsiooni kvaliteedi eest vastutavad Poolte projektijuhid. Tellija projektijuhil on õigus nõuda Täita poolt koostatud või parandatud dokumentatsiooni täiendamist või muul viisil muutmist, kui dokumentatsioon ei vasta nõuetele või on muul viisil puudulik. 6.3. Nõuded dokumenteerimisele on esitatud dokumendis „Mittefunktsionaalsed nõuded“: https://wiki.sm.ee/pages/viewpage.action?pageId=3834694 alapunktis 8 ja selle alamdokumendis „Nõuded infosüsteemi dokumentatsioonile“: https://wiki.sm.ee/pages/viewpage.action?pageId=3834696. 7. VEA PARANDAMINE ARENDUSE, JUURUTAMISE VÕI GARANTIIPERIOODI KÄIGUS 7.1. Vigade menetlemise käigus registreeritakse kõik Poolte leitud vead Jira projektikeskkonnas. 7.2. Täitja analüüsib vea kirjeldust ning selgitab välja vea põhjuse. 7.3. Vigadele määratakse kriitilisuse aste ning neid asutakse parandama kriitilisuse järjekorras. 7.4. Garantiiperioodil asub Täitja viga parandama vastavalt lepingus sätestatud tingimustele.