Leping

Ravimiameti infosüsteemi Samtrack arendus- ja hooldustööd Raamleping nr 3-9/2203-1 Tervise ja Heaolu Infosüsteemide Keskus (edaspidi t ellija ), registrikood 70009700, aadress Uus-Tatari 25, Tallinn, keda esindab põhimääruse alusel direktor Katrin Reinhold ja Industry62 OÜ , (edaspidi täitja ), registrikood 11124544 , aadress Toompuiestee 35 , Tallinn 10133 , keda esindab juhatuse liige Andrus Altrov , edaspidi nimetatud ka eraldi pool või koos pooled , sõlmisid raamlepingu alljärgnevas: Raamlepingu eesmärk Tellija poolt korraldatud riigihanke „ Ravimiameti infosüsteemi Samtrack arendus- ja hooldustööd “ (riigihanke viitenumber 214847 ) alusel sõlmitud raamlepingu eesmärk on kirjeldada raamlepingu kehtivuse ja raamlepingu alusel tellitud tööde teostamise ajal kehtivad poolte õigused, kohustused ja vastutus ning määrata kindlaks tööde tellimise tingimused. Raamlepingus fikseeritakse tööde tellimise tingimused ning poolte õigused ja kohustused kogu raamlepingu alusel tööde teostamise perioodiks. Raamlepingu alusel tellitavate tööde sisu, maht ja teostamise tähtajad lepitakse kokku hankelepingus v õi tellimuskirjades . Raamleping ei kohusta tellijat täitjalt töid tellima. Raamlepingu ese Raamleping u esemeks on infosüsteemi Samtrack tarkvara arendus- ja hooldustööd ning juurutustööd, sh kasutamise ja funktsioneerimise tagamisega seotud veaparandustööd (edaspidi töö(d) ), mida täitja kohustub teostama lähtudes raamlepingu alusel sõlmitud hankelepingus või tellimuskirjas kokku lepitud tingimustest. R aamlepingu alusel tellitakse vähemalt infosüsteem ning Samtrack infosüsteemi hoolduseks vajalikud tööd. Täpsem ülevaade tellitavatest töödest on välja toodud tehnilises kirjelduses (lisa 1) . Tööde tellimused ja nende sisu lepitakse kokku raamlepingu alusel sõlmitavates hankelepingutes . Tööde teostamisel lähtutakse lisaks raamlepingule hankelepingu tingimustest ja kodukorra regulatsioonist . Tellija võib kodukorra kehtestamisel teha kodukorda muudatusi, teavitades täitjat kodukorra muutmisest. Kui hanke lepingus kirjeldatud tingimus erineb raamlepingu tingimusest, loetakse ülimuslikuks hanke lepingu tingimus. R aamlepingu juurde kuuluvateks lahutamatuteks osadeks loetakse raamlepingu lisad, riigi hanke alusdokumendid ja t äitja riigihankes esitatud pakkumus. Raamlepingu täitmise käigus võib kokku leppida täiendavaid tingimusi, kui need on vajalikud välisvahendite rakendamisest tulenevate nõuete täitmiseks. Juhul , kui raamlepingu alusel tellitavaid töid rahastatakse välisvahenditest, on täitjal kohustus järgida vastavaid nõudeid, sh kasutada programmi tingimustes nõutud sümboolikat ja tingimusi . Üldtingimused Pooled teevad raamlepingu ja selle alusel sõlmitud hankelepingute täitmiseks ja nende eesmärkide saavutamiseks koostööd . Pooled kohustuvad tegema kõik vajalikud pingutused, et täita hanke l eping õigeaegselt ja vastavalt kokkulepetele, lähtudes hanke alusdokumentides, raamlepingus, hanke l epingu s ja nende li sades fikseeritud ning õigusaktides sätestatud kohustustest. Tellija eeldab, et täitja on hanke lepingu esemeks olevate t ööde tarkvaraarenduse valdkonna professionaal, kes saab aru ni ng võtab teadlikult enda kanda hanke l epingu funktsionaalsete ja mittefunktsionaalsete nõuete täidetavuse ja tulemuse saavutatavuse ris ki. Sellest tulenevalt laieneb täitjale ka selliste t ööde tegemise kohustus, mida ei ole hanke l epingus kokku lepitud, kuid mis om a olemusest lähtuvalt kuuluvad hanke lepinguga seotud tööde hulka. Nimetatud t ööde tegemine ei kuulu teistsuguse kirjaliku kokkuleppe puudum isel eraldi tasustamisele ning täitja teostab kirjeldatud t öö d hanke l epingu täitmise raames. Töö käigus tuvas tatud vastuolu korral teavitab t äitja vast uolu esinemisest viivitamatult t ellij at. Tööde teostamisel juhindub täitja t ellija poolsetest suunistest hanke l epingu eesmärkide saavutamisel, pöördudes juhiste saamiseks või läbirääkimisteks vajadusel t ellija poole . K ui tööde teostamisel tekivad täitja ja t ellija vahel erimeelsused, lähtutakse hanke lepingu eesmärkidest t ellija seisukohalt . Tellijal on õigus jooksvalt hanke l epingu täitmist kontrollida. T ellijal on õigus anda täitjale suuniseid hanke lepingu täitmiseks ning täitja kohustub neid järgima. Täitja on kohustatud viivitamatult informeerima tellijat tööde teostamist takistavatest asjaoludest, mis segavad hanke lepingus toodud tööde teostamist ja tähtaegadest kinnipidamist või püstitatud eesmärgi saavutamist. Kui pool on teinud teisele poolele hanke lepingu täitmisega seotud küsimuses päringu, on pool kohustatud sellele sisuliselt reageerima (asjakohast tagasisidet andma) võimalikult kiiresti, kuid hiljemalt 3 tööpäeva jooksul . Pooltel on kohustus osa võtta töökoosolekutest töö käigus tekkinud probleemide lahendamiseks ja infovahetuseks tellija juures kohapeal või virtuaalselt . Töökoosolekutel osalemist t ellija ei tasusta, välja arvatud juhul, kui hankelepingus on kokku lepitud teisiti . Tööde teostamise keel on eesti keel, muuhulgas on see ka tellimuste esitamise, töökoosolekute jm suhtluse ning tööde dokumenteerimise keel . Tööd teostatakse arvestades tellija poolt esitatud arendus- ja hooldusnõudeid. Täitja kohustub teostama tööd kvaliteetselt ning vastavalt valdkonna headele tavadele ja praktikale. Poolel on õigus teha teisele poolele ettepanekuid teenuse kvaliteedi tõstmiseks . Täitja peab takistama juurdepääsu tellija infosüsteemidele töödega mitte seotud isikutele . Tellija võib vajadusel kaasata tarkvara kvaliteedi ja/või turvalisuse hind a miseks välise eksperdi või audiitori. Puuduste avastamisel täitja töös on täitja kohustatud kõrvaldama avastatud puudused tellija poolt antud mõistliku tähtaja jooksul või vastavalt garantii tingimustele. Puuduste kõrvaldamata jätmisel on tellijal õigus raamleping ja/või hanke leping ennetähtaegselt üles öelda , taganeda või kasutada teisi õiguskaitsevahendeid . Tellija võib kontrollida täitja poolt tööde teostamiseks kasutatava alltöövõtja osas kõrvaldamise aluste puudumist vastavalt RHS § 95 lõigetes 1 ja 4 sätestatule. Kui tellija t uvastab, et alltöövõtjal esineb RHS § 95 lõikes 1 sätestatud alus, nõuab ta pakkujalt sellise alltöövõtja asendamist. Kui alltöövõtjal esineb § 95 lõikes 4 sätestatud alus, võib hankija nõuda pakkujalt sellise alltöövõtja asendamist (RHS § 122 lg 7) . Kui töö teostamisel, sh vigade kõrvaldamisel tekivad täitja ja tellija vahel erimeelsused, lähtutakse tõlgendamisel eelkõige töö eesmärkidest tellija seisukohalt . Poolte õigused ja kohustused Täitja kohustub: teostama tööd hanke lepingus kokkulepitud tingimustel ja ulatuses, sh tagama tööde õigeaegse alustamise, teostamise, valmimise ja tellijale üleandmise ; tagama tellimuse täitmiseks vajalike ressursside olemasolu, sh tagama tööde teostajate kõrge professionaalse taseme ning vajalik u tehnoloogia ja metoodikate väga hea tundmise ning tehtud tööde dokumenteerimise vastavalt tellija suunistele, samuti omama tööde teostamiseks sobivaid keskkondi, koos kõige sinna juurde kuuluvaga, sh kasutatava tarkvara litsentsid , või kasutama tellija olemasolevaid jagatud keskkondi. Jätkuarenduste puhul on täitja kohustatud litsentsimudeli valikul arvesse võtma tellija varem soetatud tarkvara litsentsitingimusi võ i juhinduma tellija vajadustest; tegema koostööd tellija palvel kolmandate osapooltega (nt äritellijaga, teiste tellija arenduspartneritega jne) ; andma selgitusi ja konsultatsioone teostatud tööde kohta ; informeerima viivitamatult tellijat tööde teostamist takistavatest asjaoludest, mis segavad tellimuses toodud tööde teostamist ja tähtaegadest kinnipidamist või püstitatud eesmärgi saavutamist; j uhindu ma tellija suunistest tellimuse eesmärkide saavutamisel, pöördudes juhiste saamiseks või läbirääkimisteks vajadusel tellija poole. Töö käigus tuvastatud vastuolu korral teavitab täitja vastuolu esinemisest tellijale viivitamatult; täitma kõiki tellija juures kehtivaid ja õigusaktidest tulenevaid andmekaitsealaseid ja andmete turvalisust puudutavaid eeskirju, kui need on täitjale teatavaks tehtud; arvestama , et ärinõuete täitmiseks võib olla vajadus muuta ja täiendada olemasoleva t koodi ning tagama protsesside ja funktsionaalsuse tervikluse pärast koodi muutmist või täiendamist ; kasutama tööde teostamisel meeskonnaliikmeid, kes on riigihanke pakkumuses tööde teostamiseks nimetatud, kui pooled e i ole kokku leppinud teisiti; teostama t ööd kuni kokku lepitud tööde üleandmise ja vastuvõtmiseni oma ressursside arvel , kui pooled ei ole kokku leppinud teisiti; kasutama tööde teostamisel tellija tööajahalduse ja projektijuhtimiskeskkondi, mis on täitjale kättesaadavaks tehtud ; töö tunni põhiselt tellitavate tööde puhul esitama tellijale tööde teostamise ajaaruandeid (iga meeskonnaliige isiklikult) ; tagama rakenduste hooldusteenuste osutamiseks valmisoleku ja omapoolse abi kuni veaolukorra kõrvaldamiseni vastavalt tehnilises kirjelduses toodud tingimustele, vajadusel ka väljakutse korras kohapeal ; osutama telli jale teostatud töö osas tuge, s h pakkuma konsultatsiooni kuni garantiiaja lõpuni . Täitjal on õigus: saa da tööde teostamise eest hankel epingus kokkulepitud ulatuses ja korras tasu ; asendada objektiivsel põhjusel ja t ellija eelneval kirjalikul nõusolekul meeskonnaliikmeid tingimusel, et meeskonnaliikmed asendatakse riigihankes nõutud kompetentsiga isikutega ; kasutada t ööde teostamisel all töövõtjaid, kooskõlastades all töövõtjate kasutamise eelnevalt t ellijaga . Alltöövõtjat e tegevuse ja tegevusetuse eest vastutab tellija ees t äitja . Tellija kohustub: tasuma t äitjale vastu võetud tööde teostamise eest hankel epingus kokkulepitud ulatuses ja korras ; tagama täitjale ligipääsu (sh kaugjuurdepääsu) tööde teostamiseks vajalikule informatsioonile ja keskkondadele, mis võivad olla hanke lepingu täitmiseks olulised või mida täitja mõistlikkuse piirides hanke lepingu täitmiseks nõuda võib ; tagama tööde teostamise perioodil nende tellija hallatavate infotehnoloogiliste keskkondade korrekt se toimimi s e, mis on olulised täitja poolsete kohustuste täitmiseks ; võtma aktiga vastu t äi tja poolt üle antud puudusteta t ööd mõistliku aja jooksul või vastavalt hankelepingus kokku lepitud tähtajale; teavitama täitjale üle antud t öödes esinevatest puudustest ja andma puuduste kõrvaldamiseks mõistliku täiendava tähtaja, kui tähtaeg ei tulene muudest kokkulepetest. Tellijal on õigus : kontrollida jooksvalt hankelepingu täitmist ja anda täitjale selleks suuniseid ; keelduda osaliselt või t äielikult tasu maksmisest, kui täitja ei teostanud nõuetekohaseid t öid kokku le pitud tähtajaks ja täitja poolne rikkumine ei ole objektiivselt põhjendatud (nt on tegemist objektiivse põhjendusega, kui tööde teostamine on viibinud tellija või kolmanda osapoole tegevuse tõttu); kontrollid a igal ajal tööde vastavust kokkulepitud tingimustele ja nõuda täitjalt informatsiooni hankelepingu täitmise kohta; kaasata hankelepingu täitmiseks tellija poolel kolmandaid osapooli (eelkõige maksja rollis), nt teisi riigiasutusi (eelkõige Sotsiaalministeeriumi valitsemisala asutused). Kolmanda osapoole kaasamine tellija poolt ei ole käsitletav raamlepingu muutmisena riigihangete seaduse mõttes. Nõuded dokumentatsioonile ja kasutusjuhenditele Dokumentatsioon on tarkvara oluline osa. Dokumentatsiooni hulka kuulu vad kasutusjuhend, administreerimisjuhend, konfiguratsioonijuhendid, integratsiooni - juhend, varundamise- ja taasteplaan, paigaldusjuhend, andmemudel, komponendi mudel ja RIHAle vajalikul kujul teostatud või muudetud dokumentatsioon. Dokumentatsioon peab olema eesti keeles ja terviklik, vastama t ööle, sisaldama muudatusi ja olema terminoloogiliselt üheselt mõistetav ning detailne vastavalt t ellija suunistele, et t ellija saaks käesoleva teostatud t ööd kasutada, hooldada ja kohandada, täiendades juba olemas olevat dokumentatsiooni või koostades vajadusel uue dokumentatsiooni . T ööde dokumentatsioon ja kasutusjuhendid peavad tagama tellijale võimaluse tööde tulemit tulevikus parandada ja arendada, samuti koolitada ja juhendada oma töötajaid tööde kasutamisel. Tööde dokumentatsioon peab olema laetud üles tellija määratud keskkonda . Täitja kohustub lähtekoodi dokumenteerimisel juhinduma tehnilisest kirjeldusest. Tööde käigus loodud lähtekood peab olema kirjutatud ja dokumenteeritud selliselt, et vajadusel oleks tellija või kolmas isik võimeline aru saama tarkvara loogilisest ülesehitusest ning jätkama lähtekoodi arendusega . Tööde tulem peab olema dokumenteeritud konkreetsete tööde iseloomust lähtudes, juhindudes kehtivast kodukorrast selle olemasolul ning raamlepingu lisades sätestatust, kui hanke lepingus ei ole kokku lepitud teisiti . Raamlepi n g u hind Riigihanke hinnapakkumuses pakutud tööde ühe töötunni maksimaalne maksumus ilma käibemaksuta fikseeritakse kogu raamlepingu kehtivuse ajaks . Raamlepingu maht on maksimaalselt 1 500 000 ( üks miljon viissada tuhat ) eurot ilma käibemaksuta. Arendus tööde teostamise maksimaalne ühe töötunni hind käibemaksuta on vastavalt pakkumusele 50 , 00 ( viiskümmend ) eurot. Hooldustööde teostamis e ühe töötunni hind käibemaksuta on vastavalt pakkumusele 55.00 ( viiskümmend viis ) eurot. Täitjal ei ole lubatud raamlepingu kehtivuse ajal hanke lepingus sätestatud ühe töötunni maksimaalset hinda tõsta, t äitja võib pakkuda madalamat hinda . Tööde eest tasutakse mõlemapoolselt allkirjastatud tööde üleandmise-vastuvõtmise akti (edaspidi akt ) alusel , kui hankelepingus ei ole kokku lepitud teisiti . Täitja esitab arve tellijale e-arvena, millel peab olema märgitud riigihanke viitenumber 214847 , hankelepingu number ja tellija kontaktisik . Arve tasumiseks annab täitja minimaalselt tähtaja 21 kalendripäeva alates nõuetekohase arve laekumisest . Täitja meeskond Täitja tagab riigihankes pakkumusega esitatud meeskonnaliikmete osalemise tööde teostamisel, v.a juhul, kui täitjast mittesõltuval asjaolul ei ole seda võimalik teha ja meeskonnaliige on asendatud tellija kirjalikku taasesitamist võimaldaval nõusolekul uue samaväärse meeskonnaliikmega . Täitja meeskonnaliikme ettevõttest lahkumise, haigestumise jms juhtumite korral asendab täitja konkreetse spetsialisti hiljemalt kahe nädala jooksul. Täitja võib lisada täiendavaid meeskonnaliikmeid juhul, kui riigihankes pakkumusega esitatud meeskonnaliikmed on tellitud tööde täitmisega hõivatud . Täitja kohustub tellija nõudmisel meeskonnaliikme asendama , kui isik osutub tellija põhjendatud arvamuse kohaselt lepingujärgsete ülesannete täitmiseks ebakompetentseks või ebasobivaks või kui tema lepingujärgsete ülesannete täitmine kahjustab pidevalt hanke lepingu korrektset ja õigeaegset täitmist. Täitja kannab kõik asendusest tulenevad või sellega kaasnevad kulud . Tellija võib hanke lepingu sõlmimisel tellida lisaks kokku lepitud mee skonnaliikmete rollidele uusi rolle, kui see on tingitud tellitavate tööde iseloomust ja tööde efektiivseks teostamiseks on otstarbekas kaasata teistsuguse kompetentsiga meeskonnaliikmeid. Tööde tellimine Tööde teostamine toimub sõlmitud hanke lepingute alusel, milles määra takse tööde sisu ja üle antavad tulemid (tööde loe telu), võimalusel tööde maht , ajalised ja eelarvelised piirangud jm olulised tingimused. Tingimused võivad olla fikseeritud ka etapiti. Esimene hankeleping sõlmitakse vastavalt riigihankes avaldatud esimese hankelepingu alusdokumentidele ja täitja riigihankes esitatud pakkumusele. Järgnevate h ankel epingu te sõlmimiseks esitab tellija täitjale kirjalikku taasesitam ist võimaldavas vormis ettepaneku ja annab mõistliku aja pakkumuse esitamiseks, arvestades tellitavate tööde keerukust. Pakkumuse esitamisel tuleb järgida kõiki tellija poolt esitatud nõudeid. Täitja esitab tellijale ettepanekus määratud tähtajaks pakkumuse töö teostamiseks, mis sisaldab tellija nõutud andmeid. Tellijal on õigus pidada täitjaga läbirääkimisi esitatud pakkumuse osas ja küsida vajadusel täiendavaid kinnitusi ja andmeid tööde teostamiseks vajalike eelduste olemasolu kohta. Tellijal on õigus lükata pakkumus tagasi ettepanekus määratud tingimustel. Pakkumuse vastuvõtmisel sõlmib tellija t äitjaga hankelepingu vastavalt pakkumuskutse tingimustele. Täitja kohustub hankelepingu allkirjastama hiljemalt 3 tööpäeva jooksul hankelepingu allkirjastamiseks saamisest. Tööde tellimiseks eeldatava mahuga vähem kui 20 000 eurot ilma käibemaksuta, võib t ellija esitada t äitjale tellimuskirja, mida käsitletakse raamlepingu kontekstis hankelepinguna. Täitja esitab t ellijale omapoolse kinnituse tellimuskirja vastu võtmise ja valmisoleku kohta tellimuskirja alusel t ööde teostamisega alustamise osas. Tellimuskirja alusel t ööde teostamisega alustamiseks allkirjastavad p ooled tellimuskirja. Tööde üleandmine ja vastuvõtmine Tööde ül eandmise ja vastuvõtmise kord, teostamise etapid ja tähtajad ning tööde testimiseks esitamise tähtajad ja kord ning muud tööde teostamiseks vajalikud kokkulepped lepitakse poolte vahel kokku hanke lepingu sõlmimisel , kui pooled ei ole kokku leppinud teisiti . Kõik t öö tulemused dokumenteeritakse ja hallatakse t ellija dokumendihaldus - keskkonnas või/ja koodihalduskeskkonnas (näiteks wiki, gitlab, SVN). Dokumendihalduskeskkonnas ja koodihalduskeskkonnas fikseeritakse muuhulgas ka t öö tellimise ning üleandmise aeg (ajahetk), milleks on t öö teostamiseks vajaliku viimase dokumendi salvestamise aeg. Kui t öö on jagatud etappideks, annab t äitja etappide tulemused t ellijale üle vastavalt hanke lepingus kokkulepitud etappide tähtaegadele . Täitja kohustub tööd üle andma hanke lepingus kokkulepitud tähtaegadel ja tingimustel . Tööde lahutamatuks osaks, mis tuleb üle anda koos töödega, on tööde juurde kuulu v nõuetekohane dokumentatsioon , kommenteeritud lähtekood ja intellektuaalomandi õigused. Üleantavad t ööd tuleb t äitja poolt enne t ellijale üle andmist testida, koostada testiraportid ja testilood . Tarne , mis on hanke lepingu alusel teostatud töö üleandmine paketina, mille kirjeldus ja spetsifikatsioon on lisatud dokumendihalduskeskkonda, peab olema konfigureeritud korrektselt toodangusse paigaldamiseks ja lisatud koodihalduskeskkonda. Täitja lisab tarne kohta t arneteatise lisades tarnega seotud testimise juhendi ning vajadusel automaattestid . Täitja annab teostatud töö üle omalt poolt allkirjastatud aktiga. Tööd loetakse nõuetekohaselt teostatuks ja vastu võetuks , kui t ööd vastavad hankelepingus kokkulepitule , vastuvõtutestid on vigadeta läbitud ja t öö on aktiga t ellija poolt vastu võetud. Tellija võtab tööd vastu akti allkirjastamisega pärast edukat vastuvõtutestimist kehtivas kodukorras või hanke lepingus kirjeldatud tingimustel . Tellija võib tööd vastu võtta, kui töödes esineb üksikuid ja tellija jaoks väheolulisi pisivigasid, mis fikseeritakse aktis. Tellija poolne pisivigadega tööde vastuvõtmine ei vabasta täitjat kohustusest vead kõrvaldada ning üle anda vigadeta tööd. Tellijal on õigus määrata mõislik tähtaeg pisivigade parandamiseks . Tellijal on õigus keelduda t öö vastuvõtmisest kui t öö ei vasta esitatud nõuetele ja/või kvaliteedile või neis esineb muid vigu (vastuvõtutestide tulemus on negatiivne) . Juhul , kui t ellija esitab oma vastuväited t ööle, eeskätt töö mittevastavuse kohta tellimuse tingimustele, peab täitja tegema töös vastavad parandused, muudatused või täiendused tellija poolt määratud mõistliku tähtaja jooksul. Kui täitja ei ole tellija antud tähtaja jooksul kõrvaldanud avastatud puudusi, võib tellija töö ise parandada või lasta seda teha kolmandatel isikutel ja nõuda täitjalt selleks tehtud mõistlike kulutuste hüvitamist . Alates teisest kordustestimisest võib t ellija kordustestidega seotud kulutused ( tellija kulutatud tööaeg ja/või t ellija testimispartnerite poolt esitatud arvete alusel) t äitjalt välja nõuda . Kui t öö teostamisel, sh vigade kõrvaldamisel tekivad t äitja ja t ellija vahel erimeelsused, lähtutakse tõlgendamisel eelkõige töö eesmärkidest t ellija seisukohalt . Vigadest teavitamine ja veaparanduste teostamine T ellija teavitab tema poolt avastatud rakenduse ja t arkvara vigadest t äitjat esimesel võimalusel, tehes kande tööde halduskeskkonda, registreeri des vea, märkides võimalusel vea põhjuse, eeldatava vea parandamise tähtaja ning kriitilisuse ja suunab selle t äitjale . Täitja võib teavitada omalt poolt avastatud vigadest t ellijat, tehes kande t ööde halduskeskkonda, registreeri des vea, märkides võimalusel vea põhjuse, eeldatava vea parandamise tähtaja ning kriitilisuse ja suunab selle t äitjale . Tellija suunab veateated täitjale täitmiseks tööde halduskeskkonna vahendusel ja määrab vea kriitilisuse. Täitja garanteerib t ellijale teenindusajal veakahtluste korral veaallika tuvastamiseks vajaliku tasuta konsultatsiooni . Täitja on kohustatud veaparanduse teostama vähima võimaliku aja jooksul . Maksima a lsed lahendusajad ja vigade eristamise kriitilisuse astmed on toodud raamlepingu t ehnilise kirjelduse lisa 1.6 punktis 5 . Kui veaparandus ei ole objektiivsetest asjaoludest tulenevalt võimalik maksimaalse lahendusaja jooksul, kohustub t äitja sellest t ellijat informeerima kirjalikku taasesitamist võimaldavas vormis, näidates ära põhjused, miks veaparandus ei ole nimetatud aja jooksul võimalik ning esitades töö teostamise tähtaja, mille jooksul t äitja on reaalselt võimeline vea parandama . Kui täitja annab vigade parandamise järgselt üle tööd, milles tellija vastuvõtutestimise käigus esineb jätkuvalt vigu (teistkordne vigadega tööde üleandmine), võib tellija otsustada, kas anda täitjale uus tähtaeg vigade parandamiseks, kõrvaldada vead ise või kolmanda isiku kaasabil, vähendades täitjale makstavat tasu võrdeliselt vigade parandamiseks tehtud kulutustega . Kõigi lepingujärgsete tööde vastuvõtmise ajaks loetakse viimase akti allkirjastamise aeg või aktis märgitud hilisem kuupäev . Intellektuaalne omand Täitja kinnitab hanke lepingu allkirjastamisega, et talle kuuluvad tööde teostamiseks vajalikud autoriõigused, litsentsid ja muud intellektuaalse omandi õigused, mis on vajalikud hanke lepingu järgsete tööde teostamiseks ja õiguste loovutamiseks tellijale ning nende suhtes ei ole õigusi ega nõudeid kolmandatel isikutel . Tasu autoriõiguste loovutamise ning l itsentsi andmise eest sisaldub hanke l epingu hinnas . Täitja loovutab tellijale t ööde teostamise käigus loodud t ööde kõik autori varalised õigused ning annab lihtlitsentsi autori isiklikele õigustele koos all-litsentsi andmise õigusega kogu autoriõiguste kehtivuse ajaks ilma geograafiliste piiranguteta tööde üleandmise hetkest, loobudes sellega hanke lepingu alusel üle antud originaalteoste osas õiguste kasutamisest. Täitja tagab , et isiklikud õigused on ilma t äitja nõusolekuta teostatavad muuhulgas järgnevas ulatuses : tellijal on õigus tööd kasutada mis tahes eesmärgil ja viisil; tellijal või t ellija tellimusel kolmandatel isikutel on õigus teha üle antud töödes muudatusi ning neid täiendada ; tellijal või t ellija tellimusel kolmandatel isikutel on õigus teostatud töid muuta või töödele lisada tellija või kolmandate isikute poolt loodud töid; t ööde üleandmisega t ellijale kinnitab t äitja, et t ööd on üldsusele avaldamiseks valmis . Täitja tagab t e llijale kõik vajalikud õigused hanke l epingu täitmise käigus loodava töö kontrollimiseks, testimiseks ning süste emi paigutamiseks ka ajal, mil t ööd on vastuvõtutestimise ks üle antud, kuid ei ole veel t ellija poolt aktiga vastu võetud . Selles alapeatükis kirjeldatud õigused ja litsentsid loetakse t ellijale lõplikult üle läinuks pärast töö vastuvõtmist. Täit ja on kohustatud tagama intellektuaalse omandi õiguste (eeskätt autoriõiguste) olemasolu ja kehtivuse, samuti nende ülemineku t ellijale viisil, mis võimaldab t ellijal hanke l epingu lõppedes üle võtta täitja funktsioonid. Täitja kohustub lahendama kõikvõimalikud lepingujärgsete t öödega seotud intellektuaalse omandi õigustest tekkivad vaidlused kolmandate isikute või oma töötajate või koostööpartneritega , v.a. juhul, kui tarkvara või tarkvara osa lits entside soetamise kohustus oli t ellijal või kolmandal osapoolel . Juhul, kui eeltoodust tekib tellijale rahaline või muu kohustus või juhul, kui tellija on kohustatud lõpetama hanke lepingu alusel teostatud ja vastuvõetud tööde kasutamise, on tellijal õigus nõuda täitjalt sellega kaasneva rahalise või muu kohustuse täitmist ja/või samaväärse töö loomist ilma täiendavat tasu nõudmata võimalikult lühikese aja jooksul, hoidudes mistahes viivitustest tarkvara arendamises, kasutuselevõtmises ja kasutamises tellija poolt . Kõik tellijale kaasnevad otsesed ja kaudsed kahjud, mis tulenevad sellest, et kolmandal isikul on või väidetavalt on varalisi või mittevaralisi intellektuaalsest omandist tulenevaid õigusi hanke l epingu alusel üle antavate intellektuaalse omandi objektide suhtes, kannab t äitja . Garantii Täitja annab hanke lepingu alusel teostatud töödele garantii 12 kuud . Garantii hakkab kehtima hetkest, mil tellija paneb töö toodangukeskkonda . Kui tellija ei pane tööd toodangukeskkonda 3 kuu möödumisel alates tööde vastuvõtmisest, algab garantii nimetatud aja möödumisel . Garantiiga on hõlmatud kõik garantii tähtaja jooksul tarkvaras ilmn evad vead ja mittevastavused kokkulepitule, mis ei ole tekkinud t ellija või kolmandate osapoolte tegevuse tagajärjel. Garantiiga on hõlmatud ka kõik tööde muudatused ja modifikatsioonid, mis on tehtud täitja poolt ja mis ei ole oluliselt muutnud varasemalt tehtud tööd. Täitja on garantii kehtivuse ajal kohustatud kõrvaldama t öödes avaldunud vead ja hanke l epingu tingimustele mittevastavused tasuta, sealhulgas on t äitja kohustatud uuendama või asendama kõik esinenud veaga seonduvad dokumendid . Täitjale peab saama edastada teateid garantiiga hõlmatud vigade ilmnemise kohta vastavalt kehtiva kodukorra regulatsioonile garantiist tulenevate õiguste teostamiseks vähemalt igal tööpäeval ajavahemikul kell 9 :00 kuni 17:00 . Täitja on kohustatud garantii korras teostama eelkõige järgmist : v ea ilmnemisel vea otsimine (lokaliseerimine), veaolukorrale lahenduse leidmine ja vea parandamine ; v ea põhjuste analüüs ning selle tulemuste kirjalikku taasesitamist võimaldavas vormis (näiteks e-posti teel) esitamine t ellijale, samuti ettepanekute tegemine ennetavate meetmete kasutuselevõtmise kohta ; v ea parandamisega seoses paigaldamise ja seadistamise toe pakkumine t ellijale, samuti sellega seotud konsultatsioonid ; v igase või puuduliku dokumentatsiooni parandamine, sealhulgas dokumentatsiooni täiendamine ja uuendamine, kui selline vajadus tuleneb vigade parandamisest . Tellija määrab võimalusel, milline on vea kriitilisuse aste või kas tegemist on muu garantiikohustusega hõlmatud puudusega ning võib määrata vea kõrvaldam iseks tähtaja, lähtudes hanke lepingus fikseeritud vigade kriitilisuse astmetest . Kui tegemist on kriitilise veaga ( blocker ja critical ), teatab täitja hiljemalt 24 tunni jooksul alates kriitilise vea kohta teate saamisest oma esialgse hinnangu kriitilise vea võimalike põhjuste kohta ning juhtnöörid, kuidas tööde tulemit edasi kasutada. Kriitiline viga peab saama kõrvaldatud hiljemalt 3 tööpäeva jooksul alates vea kohta teate saamisest, kui pooled ei ole kokku leppinud teisiti . Kui tegemist on häiriva vea ( major ), pisivea ( minor ) või muu garantiikohustusega hõlmatud puudusega, teatab täitja hiljemalt 48 tunni jooksul alates selle kohta teate saamisest oma esialgse hinnangu häiriva vea, pisivea või muu puuduse võimalike põhjuste kohta ning vajadusel juhtnöörid, kuidas tööde tulemit edasi kasutada. Häiriv viga peab saama kõrvaldatud hiljemalt 10 tööpäeva jooksul alates vea kohta teate saamisest, kui pooled ei ole kokku leppinud teisiti . Täitja garantiist tuleneva te kohustuste täitmine on arvestatud hanke l epingus kokkulepitud tasu hulka . Juhul, kui t äitja tõendab, et kõrvaldatu d viga või muu puudus ei olnud garantiiga hõlmatud, hüvitab tellija t äitja kantud otsesed kulud seoses nimetatud vea või puuduse kõrvaldamisega. Kulude hüvitamisel võetakse aluseks hanke lepingus, mille raames teostatud töödes on viga või puudus ilmnenud, fikseeritud t ööde teostamise ühe töötunni hind. Tellija tagab t äitjale kaasaabi garantiikohustuse alla käivate vigade ja puuduste kõrvaldamisel tellija võimekuse ja võimaluste piires. Kui täitja ei suuda vigasid kokkulepitud tähtajaks kõrvaldada, võib tellija nimetatud ise kõrvaldada või korraldada nende kõrvaldamise kolmanda isiku kaasabil, teavitades sellest t äitja le. Tellijal on õigus t äitjalt nõuda kõigi kulutuste hüvitamist, mis tekkisid seoses eelkirjeldatud viisil vea kõrvaldamisega, kui tegemist oli garantiiga hõlmatud vea. Garantii kaotab kehtivuse, kui tellija muudab t äitjaga kooskõlastamata lähtekoodi, välja arvatud tööde osale , mida ei ole muudetud, kui t ellija suud ab eristada lähtekoodis tehtud muudatusi . Poolte vastutus Pooled vastutavad oma lepinguliste kohustuste rikkumise eest, välja arvatud, kui rikkumine on vabandatav. Rikkumine on vabandatav, kui esineb vääramatu jõud. Nimetatud asjaolu esinemist peab tõendama pool, kes sellele tugineda soovib . Pool vastutab teise poole ees muuhulgas hanke lepingu rikkumise eest, mis tuleneb poole poolt hanke lepingu täitmisele kaasatud isikute tegevusest või tegevusetusest (sh alltöövõtjate tegevuse eest, keda täitja tööde teostamisel kasutab) . Pool ei vastuta lepinguliste kohustuste rikkumise eest, mis tulenes teise poole kohustuste rikkumisest või kolmandate isikute tegevusest või tegemata jätmistest. Nimetatud asjaolu esinemist peab tõendama pool, kes sellele tugineda soovib . Poole lepingulise kohustuse rikkumise korral on teisel poolel õigus kasutada kõiki seadusest tulenevaid õiguskaitsevahendeid. Leppetrahvi, viivise ja tekitatud kahju hüvitamine ei vabasta hanke lepingut rikkunud poolt lepingujärgsete kohustuste täitmisest. Kui rikkumise eest on võimalik kohaldada mitut õiguskaitsevahendit ja/või leppetrahvi, valib õiguskaitsevahendi ja/või leppetrahvi rakendamise tellija. Kui t ellija viivitab omapoolsete kohustuste täitmisega ja nende kohustuste mittetähtaegne täitmine ei võimalda t äitjal omapoolseid kohustusi t ähtaegselt täita, pikendatakse t ööde üleandmise tähtaega proportsionaalselt vastava aja võrra . Poolte rah aline koguvastutus on piiratud raam l epingu kogumaksumusega, kuid nimetatud piirang ei kehti tahtliku rikkumise korral , intellektuaalomandiõiguse või andmekaitsealaste kohustuste rikkumise korral. Juhul, kui tellija satub täitjale t ööde eest tasu maksmisega viivitusse, on t äitjal õigus esitada viivise nõue , mille suuruseks on 0,2 % lepingujärgse konkreetse töö eest maksmisele kuuluvalt tasult iga tasumiseg a viivitatud kalendripäeva eest, kuid mitte rohkem kui 25% konkreetse töö eest tasumisele kuuluvast kogusummast. Täitja esitab viivise nõude tellijale allkirjastatult vähemalt kirjalikku taasesitamist võimaldavas vormis. Täitja poolse l epingu liste kohustuste rikkumisena käsitletakse eeskä tt olukorda, kus tööd ei vasta osaliselt või täielikult hanke l eping u tingimustele , sealhulgas kokkulepitud hooldus- või veaparandustööde tingimustele või esineb muid täitja poolseid lepingu rikkumisi (näiteks töö ei ole teostatud vastavalt kokku lepitud kvaliteedile, ei ole üle antud tähtaegselt või esineb muu t äitja pool ne hanke l epingu s kokku lepitud tingimuste rikkumi ne ). Hooldus tööde lahendusaegadest mittekinnipidamisel, on t ellijal õigus nõuda t öö üleandmisega viivitamise või mittenõuetekohase t öö teostamise eest leppetrahvi 50 eurot iga t ööde üleandmisega viivitatud päeva eest, kuid mitte rohkem kui 30% kokkulepitud t öö maksumusest . Juh ul, kui täitja rikub lepingulist kohustust (sh garantiist tulenevat kohustust), on tellijal õigus nõuda leppetrahvi tasumist, mille suuruseks on 200 eurot iga rikkumises oldud kalendripäeva eest, kuid mitte rohkem kui 25% hanke lepingu kogumaksumusest. Kui tööde teostamine on kokku lepitud etappide kaupa, siis mitte rohkem kui 25% etapi kogumaksumusest. Juhul , kui täitja poolsetest viivitustest tingitult (st täitja ei suuda täiendava aja jooksul tööde valmimist tagada) ei ole t ö öde kasutuselevõtt enam realistlik või vajalik , puudub tellijal kohustus tellitud tööde eest maksta ja täitja on kohustatud tegema juba makstud osa eest tellijale tagasimakse. Hankel epin gu olulise rikkumise korral on t ellijal õigus esitada t äitjale leppetrahvi nõue 1 0 000 eurot iga rikkumise eest. Oluliseks lepingurikkumiseks loetakse punktis 15. 4 kirjeldatut. Täitja poolse olulise hanke lepingu rikkumise korral ei pea t ellija määrama täitjale l epingu täitmiseks võlaõigusseaduse §-s 114 nime tatud täiendavat tähtaega ning t ellijal on muu hulgas õigus hanke l eping üles öelda või hanke l epingust taganeda . Leppetrahvi nõude kohustub t ellija esitama mõistliku aja jooksul, kuid mitte hiljem kui 3 kuu jooksul alates päevast, mil t ellija sai teadlikuks leppetrahvi nõude aluseks olevast asjaolust. Leppetrahvi nõude vaidlustamine ei vabasta t äitjat selle maksmise kohustusest enne vastava kohtuotsuse jõustumist . Täitja on kohustatud leppetrahvi tasuma 2 nädala jooksul alates t ellija poolt vastava nõude esitamisest , kui leppetrahvi nõudes ei ole määratud teisiti. Tellijal on õigus tasaarvestada leppetrahvi summa täitjale töö teostamise eest tasumisele kuuluvate maksetega. Tasaarvestamise korral ei rakendata leppetrahvi tasumise kohustust. Tööde vastuvõtmine t ellij a poolt ei vabasta ega vähenda t äitja vastutust hanke l epingu rikkumise eest . Konfidentsiaalsuskohustus Pooled kohustuvad vastastikku hoidma salajas ja mitte avaldama kolmandatele isikutele ükskõik missugust konfidentsiaalseks peetavat informatsiooni, mis on saadud teiselt p oolelt raamlepingu alusel tellitud t ööde teostamise käigus või muul viisil või juhuslikult . Täitja peab võtma kasutusele isikuandmete ja t ellija infosüsteemide kaitseks organisatsioonilisi, füüsilisi ja infotehnilisi turvameetmeid, lähtudes muuhulgas kehtivatest õigusaktidest. Täitja ei tohi töödelda arenduskeskkondades reaalseid ja isikustatud andmeid . Juhul, kui hanke lepingu täitmise raames osutub vajalikuks isikuandmete töötlemine, lepivad pooled isikuandmete töötlemise tingimused kokku hanke lepingus, juhindudes isikuandmete kaitse üldmääruse artiklis 28 kirjeldatust . Konfidentsiaals e informatsiooni all mõistavad p ooled igasugust informatsiooni (s h ärisaladusi, isikuandmeid, lepingute andmeid , infosüsteeme, turvasüsteemide kirjeldusi, riistvara ja tarkvara kirjeldusi, pakkumuse kirjeldusi, kasutatavaid tehnoloogiaid, spetsifikatsioone jms), mis on saadud seoses tööde teostamisega ja mille sattumine kolmandate isikute kätte võib p ooltele põhjustada turvariske või majanduslikku kahju või kolmandate isikute (eelkõige t ellija klientide) eraelu puutumatuse rikkumist. Kahtluse korral eeldatakse informatsiooni konfidentsiaalsust . Konfidentsiaalne informatsioon ei hõlma endas informatsiooni, mille avalikustamise k ohustus tuleneb õigusaktidest või mille avalikustamiseks p ooled on andnud nõusoleku . Pooled võivad edastada konfidentsiaalset informatsiooni ainult nendele isikutele, kes on tellitud t ööde täitmisega otseselt seotud. Täitja kohustub tagama, et isikud, keda ta oma kohustuste täitmisel kasutab, oleksid konfidentsiaalsuse kohustusest teadlikud ning nõudma nimetatud isikutelt selle kohustuse tingimusteta ja tähtajatut täitmist. Vastutus konfidentsiaalsus kohustuste täitmise eest lasub t äitjal . Pooled ei kasuta raamlepingu täitmisel neile teatavaks saanud konfidentsiaalset informatsiooni oma huvides e ga muul eesmärgil, kui tellitud tööde teostamiseks. Konfidentsiaalsuskohustus jääb kehtima tähtajatult, ka raamlepingu ja raamlepingu alusel sõlmitud hanke lepingute lõpetamise või lõppemise järgselt . Täitja on teadlik, et raamleping ning raamlepingu alusel sõlmitud hanke lepingud ja kokkulepped on avalikud, v.a osades, mis on avaliku teabe seadusest tulenevatel alustel määratud asutusesiseseks kasutamiseks või märgitud täitja poolt ärisaladuseks. Konfidentsiaalsuskohustuse r ikkumise korral kohustub täitja hüvitama kõik kahjud, mis sellise rikkumise tagajärjel tellijale või kolmandale isikule tekkisid , sõltumata sellest, kas rikkumine pandi toime hanke lepingu kehtivuse ajal või lepinguliste kohustuste lõppemise järgselt. Raamlepingu kehtivus ja ülesütlemine Raamleping jõustub sõlmimise hetkel ja kehtib 48 kuud. Hankel epingud tuleb sõlmida raamlepingu kehtivuse ajal, kuid võivad kehtida kauem . Tellija võib raamlepingu igal ajal ühepoolselt üles öelda, teatades t äitjale 60 päeva ette. Raamlepingu ülesütlemine ei muuda automaatselt kehtetuks selle alusel varem sõlmitud hanke lepinguid . Tellijal on õigus raamleping ühepoolselt etteteatamistähtaega järgimata üles öelda, kui täitja on oluliselt raamlepingut rikkunud või juhul, kui täitja suhtes on algatatud pankrotimenetlus ; pankrot on välja kuulutatud ; t äitja varad arestitakse ; täitja finantsseisund halveneb t ellija põhjendatud hin nangul oluliselt ja see muudab hanke l epingu nõuetekohase täitmise vähetõenäoliseks . Raamlepingu oluliseks rikkumiseks täitja poolt loetakse lisaks võlaõigusseaduses sätestatule muuhulgas : mõjuva põhjuseta hanke lepingu sõlmimata jätmine ; valeandmete või valeinfo esitamine; täitjal puuduvad hanke l epingu täitmiseks vajalikud õigused (sealhulgas load, litsentsid, intellektuaalse omandi õigused ); intel lektuaalse omandi õiguste ja nende kasutamise tingimuste rikkumine; korduv (vähemalt kahel korral) meeskonnaliikme asendamine isikuga, kes ei vasta kokku lepitud nõuetele või meeskonnaliikme asendami ne ilma t ellija eelneva vähemalt kirjalikku taasesitamist võimaldavas vormis antud nõusolekuta ; konf identsiaalsuskohustuse rikkumine; lepingujärgsete kohustuste, sh garantiikohustuste korduvat (vähemalt kahel korral) täitmata jätmist; samuti tähtaegselt tööde teostamata jätmist nii, et tehnilises kirjelduses sätestatud eesmärgi täitmine ei ole enam tähtaegselt realistik ja/või täitja poolse tegevuse või tegevusetuse tõttu ei ole võimalik enam kasutada hankelepingu rahastamiseks ettenähtud vahendeid ; l epin gujärgsete kohustuste üleandmine kolmandale isikule , saamata selleks eelnevalt t ellija poolset kirj alikku taasesitamist võimaldavat nõusoleku t. Poolte vahelised teated ja kontaktisikud Teadete edastamine toimub üldjuhul e-posti teel , lähtudes kehtiva kodukorra tingimustest . Juhul, kui teate edastamisel on olulised õiguslikud tagajärjed, peab t eade olema edastatud digi allkirjastatult poole allkirjaõigusliku isiku poolt. Tellija kontaktisik(ud) on: Merle Kale , telefon +372 5100922 , e-post: [email protected] . Täitja kontaktisik(ud) on: Taavi Tasuja , telefon + 372 56697986 , e-post: [email protected] . Kontaktisikute pädevuses on anda teisele poolele vajaliku informatsiooni ja juhiseid oma pädevuse piires, kontrollida teostatud töö kvaliteeti, anda töö üle ja võtta töö vastu ning allkirjastada akt ning esitada ja allkirjastada tellimusi mahus kuni 20 000 eurot (käibemaksuta). Kontaktisiku muutumisest teavitab pool kirjalikult teist poolt viivitamatult. Lõppsätted Kogu suhtlus raamlepingu täitmise perioodil toimub tellija ja täitja vahel eesti keeles, sh töökoosolekud, arupärimised, tagasiside andmine, tellimuste esitamine, hanke lepingute sõlmimine jmt. Täitjalt oodatakse raamlepingu perioodil operatiivset tagasisidet tellija arupärimistele. Pakkuja peab tagama, et meeskonnaliikmetega oleks võimalik eesti keeles ilma põhjendamatute viivitusteta informatsiooni vahetada . Raamlepingu alusel sõlmitud hanke lepingutele kohalduvad raamlepingu tingimused, olenemata raamlepingu kehtivusest. Täitjal ei ole õigust ilma t ellija kirjaliku nõusolekuta raamlepingut või sellest tulenevaid kohustusi kolmandatele isikutele üle anda. Kolmas isik on mistahes füüsiline või juriidiline isik, kes ei ole selle raam lepingu pooleks . Raamlepingut muudetakse pooltevahelise kirjaliku kokkuleppega raamlepinguga samas vormis. Täitjal puudub volitus tegeleda raamlepingu osas avalike suhetega ning anda teateid pressile, elektroonilisele meediale, üldsusele või teistele auditooriumidele, välja arv atud tellija eelneval kirjalikku taasesitamist võimaldaval nõusolekul . Raamlepinguga seotud vaidlused, mida pooled ei ole suutnud läbirääkimiste teel lahendada, antakse lahendamiseks Harju Maakohtule. Raamlepingule kohaldub Eesti õigus . Kui raamlepingu mõni säte on vastuolus Eesti Vabariigis kehtivate õigusaktidega, ei mõjuta see ülejäänud sätete kehtivust . Lisad Lisa 1 – Tehniline kirjeldus ja selle lisad L isa 2 – Nõuded pakkuja meeskonnale Lisa 3 – Hankelepingu projekt Lisa 4 – Kodukord Poolte allkirjad Tellija: Täitja: ( allkirjastatud digitaalselt ) ( allkirjastatud digitaalselt ) Ravimiameti infosüsteemi Samtrack arendus- ja hooldustööd Raamlepingu Lisa 1 Tehniline kirjeldus Hanke objekt Raamlepingu objektiks on Ravimiameti infosüsteemi Samtrack arendus- ja hooldustööd e teostamine vastavalt raamlepingu alusel sõlmitavatele hankelepingutele . Hanke eesmärk Hanke eesmärk on leida uue ravimitega seotud me netlusprotsesside infosüsteemi Samtrack ja sinna juurde kuuluvate komponentide (teenuste, liideste jms) analüüsi - , arendus- ja hooldustööde teostaja , tagamaks Samtracki loomine, areng ja tõrgeteta töö. Infosüsteem luuakse mitmes etapis. Esimene arendustööde etapp teostatakse vastavalt esimese hankelepingu tehnilisele kirjeldusele. Raamlepingu alusel tellitakse arendus- ja hooldustööde teostamist nelja aasta jooksul, maksimaalse eeldatava mahuga 1 500 000 euro km-ta ulatuses. Töid tellitakse vastavalt vajadusele ja võimalustele , mistõttu t ellija ei garanteeri tööde tellimist maksimaalses mahus ning raamleping ei lõppe eeldatava mahu täitumisel. Taustainfo Ravimiameti roll on tagada, et Eestis kasutatavad ravimid on kvaliteetsed, ohutud, efektiivsed ning inimestele kättesaadavad. Oluline on ajakohase ja kontrollitud ravimiinfo kättesaadavus kõigile (arstid, patsiendid, loomaomanikud), et tagada ravimite õige ning ratsionaalne kasutamine. Selle rolli täitmiseks vajame menetlusi toetavat infosüsteemi, mis vastaks kaasaegse infoühiskonna nõuetele ning võimaldaks elektroonilist infovahetust Eestis ning rahvusvaheliselt. Probleemi kirjeldus R avimiamet k asutab hetkel enamuse oma p õhifunktsioonide täitmiseks Samt rack infosüsteemi, mis on R avimiameti tellimuse alusel loodud 2001. aastal. Infosüsteem koosneb kuuest moodulist, mis kasutavad samu loendeid ja ühiseid ravimite andmeid. Andmebaas on liidestatud teiste Ravimiameti infosüsteemidega (dokumendihaldussüsteem Dora , Ravimiregister , Ravimiameti kliendiportaaliga ) ja riigi tugiteenuste keskusega (SAP). Alates 2002. aastast on iga-aastaselt tellitud infosüsteemile juurde erinevaid funktsioone, täiendusi ja parandusi, peamiselt lähtuvalt õigusruumi muudatustest. Olemasolev infosüsteem täidab hetkel talle pandud kohustusi, kuid suured muudatused põhiprotsessides on muutnud olemasoleva infosüsteemi kohmakaks ja aeglaseks. Vananenud on nii tehniline platvorm kui ka andmebaasi arhitektuur. Muudatuste sisseviimine ühes moodulis/protsessis põhjustab sageli probleeme infosüsteemi töös, sest andmeväljade ja funktsioonide seosed on muutunud väga keeruliseks. Käesolevaks hetkeks on infosüsteemi suuremad arendused peatatud ning tehakse vaid hädavajalikke hooldustöid. Ravimiametis läbi viidud auditid ning väline infosüsteemi audit on toonud välja vajaduse arendada välja uus infosüsteem, kasutades kaasaegset tarkvara ja infosüsteemidele esitatud nõudeid ning lähtudes protsessidest, mida infosüsteem peaks toetama. Hanke eseme kirjeldus Hangitav infosüsteem peab toetama müügilubade väljastamist. Ravimiamet (edaspidi RA) väljastab ravimitele müügilubasid, mille alusel võib neid Eestis turustada. Eesti RA annab välja müügiloa, kasutades mitut erinevat menetlust – riiklik, detsentraalne ja vastastikuse tunnustamise menetlus. Kõigi müügilubade menetluste haldamine, st taotluste andmete sisestamine, esmane hinnang, sisuline hinnang ja müügiloa otsused peavad olema hallatavad RA infosüsteemi poolt. Taotlused omakorda jaotuvad muudatuste, uuendamiste ja korduvtaotlusteks, mille haldamise etapid on samad, kuid ajaperiood, mille jooksul tuleb toimetada, on erinev. Eesti RA võib detsentraalse ja vastastikuse tunnustamise menetluses olla kaasatud riik, mis tähendab, et RA ei teosta taotluse sisulist hindamist, vaid tunnustab teiste riikide ekspertide hinnangut, või referentsriik, mille raames RA eksperdid koostavad hinnanguraporti, mida teised riigid tunnustavad. Mõlemal juhul on Eestil kohustus pidada ajagraafikut menetluse kohta ja edastada infot EL-i kesksesse Comm unication and Tracking System (CTS) andmebaasi. Euroopa Ravimiamet (EMA) annab välja ravimite müügilubasid, mis kehtivad kogu EL-is (tsentraalne müügiloa menetlus). Nende ravimite müügiloa väljastamise dokumentatsiooni põhiline haldus toimub EMA-s . RA infosüsteem peab võimaldama taotluste sisestamist, olulisemate muudatuste sisestamist ja ravimiinfo haldamist. Ka tsentraalse menetluse puhul on Eesti RA mõnede taotluste puhul määratud riigiks, kes koostab hinnanguraporti, kas siis raportööri, kaasraportööri või eelhindajana. Nende taotluste puhul on tulevikus tõenäoliselt vaja, et minimaalsete andmetega esmane kaart ajagraafikute pidamiseks oleks seotud Euroopa Ravimiamet (EMA) andmebaasiga SiaMed . EL tasemel on loodud elektrooniline taotlusvorm ning kasutatakse andmeedastusportaali Common European Submission Portal (CESP). Lisaks ravimitele tuleb andmebaasis hallata ka ravimite toimeainete dokumentatsiooni ja luua seoseid toimeainet kasutava ravimiga. Nõuded t ehnili sele lahendus ele Loodav uu s infosüsteem tuleb teostada veebipõhise rakendusena, mis peab kohanduma lõppkasutaja seadmetele. Infosüsteem peab a rvesta ma teenuspõhise arhitektuuri nõuetega, kasuta ma X-tee liidestust, mis tagab ravimite andmete ajakohasuse ravimiregistris, retseptikeskuses ja ravimite käitlejate andmebaasides. Infosüsteem peab v õimalda ma kahepoolset liidestamist EL teenustega ( täpne tehn iline lahendus selgub arenduse käigus, XML põhinev) ja paberivaba ning automatiseeritud asjaajamist ja andmete taaskasutust. Samuti peab infosüsteem võimaldama olemasolevas info süsteemis menetluses olevate ja kehtivate müügilubade, ravimi andmete ja pakendikoodide ülekandmist loodavasse infosüsteemi selle juurutamisel . Infosüsteemi kasutajad Loodava uue infosüsteemi sihtgrupiks on: Ravimiam e ti töötajad , kes panustavad müügilubade menetlusse, umbes 50 RA töötajat (45% personalist) ja kes kasutavad oma igapäevatöös ravimite andmeid, umbes 6 0 RA töötajat (55% personalist). Asutused ja ettevõtted, kes kasutavad oma igapäevatöös ravimite andmeid – Haigekassa, Sotsiaalministeerium, haiglad, perearstid, ravimite tootjad, hulgimüüjad ja apteegi d. Kõik Eesti kodanikud, kes kasutavad ravimeid, kuna tegemist on ravimite põhiandmetega, mida kasutavad nii retseptikeskus kui ka Eesti haiglad/perearstid/apteegid/hulgimüüjad (infosüsteem annab andmed ravimiregistrile ja sealt saab andmeid digiretsepti infosüsteem). Ravimiregister on suunatud kõigile kodanikele objektiivse ja kaasajastatud raviminfo saamiseks ( www.ravimiregister.ee ) Andmebaasiga on kaudselt seotud müügiloa hoidjad (umbes 500), kes esitavad müügilubade taotlusi. Raamlepingu alusel tellitavad tööd Raamlepingu alusel on planeeritud tellida uue infosüsteemi Samtrack terviklahendus, mille läbiviimiseks on tellija tänase parima teadmise põhjal planeerinud kolm arendustööde teostamise etappi. I ga etapi eeldatavaks ajaliseks kestuseks on 16-18 kuud (koos turvatestimise ja vigade parandusega). Samuti on planeeritud raamlepingu alusel tellida infosüsteemi hooldamiseks vajalike tööde teostamine (täpsemalt kirjeldatud dokumendis hooldustööde osutamise reeglid). R aamlepingu alusel tellitakse vähemalt järgmised tööd: infosüsteemi Samtrac k analüüs (sh UX/UI analüüs) ; arendustöö vastavalt analüüsi tulemitele ; arenduse testimine (sh automaattestide kirjutamine) ; dokumentatsiooni koostamine ; paigalduspakettide koostamine ja paigalduse automatiseerimine ; konsultatsioon ja koolitus ed seoses arendustöödega. Samtracki loomiseks on tellija koostanud dokumendi „ Samtrack nõuded ( Esimese HL tehnilise kirje lduse lisa 1.1.), millest täitjal tuleb infosüsteemi loomisel juhinduda. Tänase parima teadmise põhjal on tellija planeerinud tellida Samtrack terviklahenduse loomise kolmes arendusetapis. Esimene hankeleping sõlmitakse täitjaga pärast raamlepingu sõlmimist vastavalt esimese hankelepingu skoobile ja riigihankes esitatud pakkumusele . Teise ja kolmanda arendusetapi tööde skoop, täpsed realiseerimistingimused ja maht lepitakse poolte vahel kokku konkreetsetes hankelepingutes . Nimetatute osas järgnevalt toodud informatsioon on indikatiivne ja võib aja jooksul muutuda. Tööd tellitakse konkreetse hankelepingu alusel. Esimese arendusetapi tulemusena peab valmima 1. etapp ehk uus infosüsteem, v astavalt esimese hankelepingu tehnilisele kirjeldusele . Loodav infosüsteem peab lähtuma punktis 3.3 toodud n õuetest ja dokumendist Samtracki nõuded ( esimese HL tehnilise kirjelduse lisa 1.1. ). Teise arendusetapi tulemusena peab valmima 2. etapp , mille käigus arendatakse infosüsteemile juurde järgmised funktsionaalsused: Müügiloata ravimite kasutuslubade andmine Ravimite sisse/väljaveo lubade ja teavituste andmine Ravimistatistika koostamine Tarneraskuste andmete edastamine Ravimi kõrvaltoimeteatise edastamine Ravimi riskiminimeerimise dokumentide menetlemine . Kolmanda arendusetapi tulemusena peab valmima 3. etapp , mille käigus infosüsteemile arendatakse juurde järgmised funktsionaalsused: Ravimistatistika aruanded, et tagada statistika aegread Kehtivad sisse- ja väljaveo load . Paralleelselt tellitakse hooldustööde teostamis t vastavalt vajadusele, milleks sõlmitakse poolte vahel samuti hankeleping. T ööde tellimine Tööde teostamiseks sõlmitakse hankelepingud või esitatakse tööde tellimuskiri , milles lepitakse kokku tööde teostamise täpsed tingimused, skoop, tähtajad jm olulised tingimused . Pakkuja ülesandeks on olla valmis: teosta m a arendustöid funktsionaalsuse põhiselt, kus sisendiks on konkreetse tulemi (skoobi) tellimus, sh tähtaeg ja/või piirsumma; teosta m a arendustöid arendusmeeskonna töötundide põhiselt, kus arendused realiseeritakse agiilse arendusprotsessi põhimõtetel; viima läbi arendustöödega seot ud konsultatsioone ja koolitusi. Lisad: Lisa 1.1. Samtracki arhitektuur Lisa 1.2. IT-profiil Lisa 1.3. M ittefunktsionaalsed nõuded Lisa 1.4. Nõuded infosüsteemi dokument atsioonile Lisa 1.5. Versioonihalduse kirjeldus Lisa 1. 6 Hooldustööde osutamise reeglid Ravimiameti infosüsteemi Samtrack arendus- ja hooldustööd Nõuded pakkuja meeskon nale Pakkuja peab komplekteerima ja esitama raamlepingu täitmiseks minimaalselt kaheksaliikmelise meeskon n a, kuhu peavad kuuluma vähemalt : analüütik (1) ; projektijuht (1); arendajad ( minimaalselt 3 ) ; v anemarendaja /arhitekt (1) ; UI (veebidisainer) ja / või UX disainer (kasutajakogemuse disainer) (1); testija ( 1 ). M eeskon na liige ei tohi olla erinevates rollides , vaid igasse rolli tuleb esitada erinev isik . Arendajad ja vanemarendaja/arhitekt rollis olev isik ei tohi teha süsteemi testimisi. Meeskonnas peab vähemalt ühel meeskonna liikmel olema Scrum Masteri kogemus selle rakendamisel vähemalt kahes projektis. Esitatavad meeskonnaliikmed peavad asuma pakkuja edukaks tunnistamisel hankelepingu alusel töid teostama. Pakkuja esitab hankija poolt nõutud andmed alltoodud vormidel, millest peab nähtuma hankija poolt esitatud nõuetele vastamine. A rendusmeeskond Projektijuht (nimi, isikukood) : ..... ............... Nõude kood Nõuded Kas vastab esitatud nõudele (JAH/ EI) Täpsustus selle kohta kus/millal/kuidas on nõue täidetud. Projektidele viitamisel märkida projekti tellinud asutus, tellija kontaktisik ja projekti nimi , projekti kestvus kalendrikuudes arvestades, et hankijal on õigus kontrollida esitatud andmeid viidatud kontaktisiku vahendusel. Välja täitmine on kohustuslik. 1 Omab vähemalt 3 -aastast töökogemust tarkvara arenduse projektijuhina. Tuua välja (kokku) 3- aasta ke stvusega projekte, millest nähtub töökogemuse omandamine. 2 On juhtinud vähemalt ühte tarkvara arendusprojekti viimase 3 aasta jooksul alates hanke väljakuulutamisest , mille maht nende 3 aasta jooksul ületab 5000 töötundi. 3 Scrum Master kogemus vähemalt kahes projektis Analüütik (nimi, isikukood) : ................. Nõude kood Nõuded Kas vastab esitatud nõudele (JAH/ EI) Täpsustus selle kohta kus/millal/kuidas on nõue täidetud. Projektidele viitamisel märkida projekti tellinud asutus, tellija kontaktisik ja projekti nimi , projekti kestvus kalendrikuudes arvestades, et hankijal on õigus kontrollida esitatud andmeid viidatud kontaktisiku vahendusel . Välja täitmine on kohustuslik . 1a Omab kõrgharidust ja Omab vähemalt 3 - aasta st töökogemust tarkvara arenduse projektides analüütikuna või tarkvara projekteerijana . Tuua välja (kokku) 3- aasta ke stvusega projekte, millest nähtub töökogemuse omandamine. 1b Omab vähemalt 5- aasta st töökogemust tarkvara arenduse projektides analüütikuna või tarkvara projekteerijana . Tuua välja (kokku) 5- aasta ke stvusega projekte, millest nähtub töökogemuse omandamine. 2 On osalenud analüütikuna vähemalt ühes IT projektis viimase 3 aasta jooksul alates hanke väljakuulutamisest , mille maht nende 3 aasta jooksul ületab 5000 töötundi. 3 Omab töökogemust: 3.1 Menetlussüsteemide arendamisel ja/või analüüsimisel 3.2 äriprotsesside optimeerimisel 3.4 UML-iga ( Unified Modeling Language ) 3.5 Prototüüpide koostamisel 3 .6 Konteinerlahenduse loomisel 4 Scrum Master kogemus vähemalt kahes projektis Arendaja 1 (nimi, isikukood): ................ Nõude kood Nõuded Kas vastab esitatud nõudele (JAH/ EI) Täpsustus selle kohta kus/millal/kuidas on nõue täidetud. Projektidele viitamisel märkida projekti tellinud asutus, tellija kontaktisik ja projekti nimi , projekti kestvus kalendrikuudes arvestades, et hankijal on õigus kontrollida esitatud andmeid viidatud kontaktisiku vahendusel . Välja täitmine on kohustuslik. 1a Omab kõrgharidust infotehnoloogia või m atemaatika – füüsika valdkonnas ja O mab vähemalt 3-aastast töökogemust IT arendajana. Tuua välja (kokku) 3- aasta ke stvusega projekte, millest nähtub töökogemuse omandamine. 1b Omab vähemalt 5-aastast töökogemust IT arendajana . Tuua välja (kokku) 5- aasta ke stvusega projekte, millest nähtub töökogemuse omandamine. 2 On osalenud arendajana vähemalt ühes IT projektis viimase 3 aasta jooksul alates hanke väljakuulutamisest , mille arendusmaht on nende 3 aasta jooksul olnud rohkem kui 5000 töö tundi ning milles on kasuta nud Spring ja Hibernate raamistikke ja REST/SOAP protokollil baseeruvaid veebiteenuseid. 3 Omab arendajana vähemalt 2 - a astast töökogemust relatsiooniliste andmebaaside ja Java’ga . 4 Omab töökogemust järgmiste töövahendite , raamistike ja keskkondadega: 4 .1 GIT 4 . 2 Intellij IDEA/ Eclipse 4 . 3 Spring raamistik 4 . 4 Hibernate raamistik 4 . 5 REST / SOAP protokollil baseeruvad veebiteenused 4. 6 Konteinerlahenduse loomisel 4. 7 PostgreSQL 5 Scrum Master k ogemus vähemalt kahes projektis Arendaja 2 (nimi, isikukood): ................ Nõude kood Nõuded Kas vastab esitatud nõudele (JAH/ EI) Täpsustus selle kohta kus/millal/kuidas on nõue täidetud. Projektidele viitamisel märkida projekti tellinud asutus, tellija kontaktisik ja projekti nimi, projekti kestvus kalendrikuudes arvestades, et hankijal on õigus kontrollida esitatud andmeid viidatud kontaktisiku vahendusel. Välja täitmine on kohustuslik. 1a Omab kõrgharidust infotehnoloogia või matemaatika – füüsika valdkonnas ja Omab vähemalt 3-aastast töökogemust IT arendajana. Tuua välja (kokku) 3- aasta ke stvusega projekte, millest nähtub töökogemuse omandamine. 1b Omab vähemalt 5-aastast töökogemust IT arendajana. Tuua välja (kokku) 5- aasta ke stvusega projekte, millest nähtub töökogemuse omandamine. 2 On osalenud arendajana vähemalt ühes IT projektis viimase 3 aasta jooksul alates hanke väljakuulutamisest , mille arendusmaht on nende 3 aasta jooksul olnud rohkem kui 5000 töö tundi ning milles on kasutanud Spring ja Hibernate raamistikke ja REST/SOAP protokollil baseeruvaid veebiteenuseid. 3 Omab arendajana vähemalt 2-aastast töökogemust relatsiooniliste andmebaaside ja Java’ga . 4 Omab töökogemust järgmiste töövahendite, raamistike ja keskkondadega: 4.1 GIT 4. 2 Intellij IDEA/ Eclipse 4. 3 Spring raamistik 4. 4 Hibernate raamistik 4. 5 REST / SOAP protokollil baseeruvad veebiteenused 4. 6 Konteinerlahenduse loomisel 4. 7 PostgreSQL 5 Scrum Master k ogemus vähemalt kahes projektis Arendaja 3 (nimi, isikukood): ................ Nõude kood Nõuded Kas vastab esitatud nõudele (JAH/ EI) Täpsustus selle kohta kus/millal/kuidas on nõue täidetud. Projektidele viitamisel märkida projekti tellinud asutus, tellija kontaktisik ja projekti nimi, projekti kestvus kalendrikuudes arvestades, et hankijal on õigus kontrollida esitatud andmeid viidatud kontaktisiku vahendusel. Välja täitmine on kohustuslik. 1a Omab kõrgharidust infotehnoloogia või matemaatika – füüsika valdkonnas ja Omab vähemalt 3-aastast töökogemust IT arendajana. Tuua välja (kokku) 3- aasta ke stvusega projekte, millest nähtub töökogemuse omandamine. 1b Omab vähemalt 5-aastast töökogemust IT arendajana. Tuua välja (kokku) 5- aasta ke stvusega projekte, millest nähtub töökogemuse omandamine. 2 On osalenud arendajana vähemalt ühes IT projektis viimase 3 aasta jooksul alates hanke väljakuulutamisest , mille arendusmaht on nende 3 aasta jooksul olnud rohkem kui 5000 töö tundi ning milles on kasutanud Spring ja Hibernate raamistikke ja REST/SOAP protokollil baseeruvaid veebiteenuseid. 3 Omab arendajana vähemalt 2-aastast töökogemust relatsiooniliste andmebaaside ja Java’ga . 4 Omab töökogemust järgmiste töövahendite, raamistike ja keskkondadega: 4.1 GIT 4. 2 Intellij IDEA/ Eclipse 4. 3 Spring raamistik 4. 4 Hibernate raamistik 4. 5 REST / SOAP protokollil baseeruvad veebiteenused 4. 6 Konteinerlahenduse loomisel 4. 7 PostgreSQL 5 Scrum Master k ogemus vähemalt kahes projektis Vanemarendaja /arhitekt (nimi, isikukood): ................ Nõude kood Nõuded Kas vastab esitatud nõudele (JAH/ EI) Täpsustus selle kohta kus/millal/kuidas on nõue täidetud. Projektidele viitamisel märkida projekti tellinud asutus, tellija kontaktisik ja projekti nimi , projekti kestvus kalendrikuudes arvestades, et hankijal on õigus kontrollida esitatud andmeid viidatud kontaktisiku vahendusel. Välja täitmine on kohustuslik. 1a Omab kõrgharidust infotehnoloogia valdkonnas ja o mab vähemalt 5-aastast töökogemust vanemarendaja või tarkvara arhitektina . Tuua välja (kokku) 5- aasta ke stvusega projekte, millest nähtub töökogemuse omandamine. 1b Omab vähemalt 7 -aastast töökogemust vanemarendaja või tarkvara arhitektina. Tuua välja (kokku) 7- aasta ke stvusega projekte, millest nähtub töökogemuse omandamine. 2 On osalenud vanemarendaja või tarkvara arhitekt ina vähemalt ühes IT projektis viimase 3 aasta jooksul alates hanke väljakuulutamisest , mille arendusmaht nende 3 aasta jooksul on rohkem kui 5000 tundi . 3 Omab vähemalt 5 -aastast töökogemust vanemarendaja või tarkvara arhitekt i na relatsiooniliste andmebaaside ja Java’ga . Tuua välja (kokku) 5- aasta ke stvusega projekte, millest nähtub töökogemuse omandamine. 4 Omab töökogemust menetlus- ja infosüsteemide p rojekteerimisel ja arendamisel. 5 Omab töökogemust järgmiste töövahendite , raamistike ja keskkondadega : 5 .1 Liquibase 5 .2 Enterprise Architect 5.3 GIT 5 .4 Linux/Unix operatsioonisüsteemidega 5 .5 V irtualiseerimistehnoloogiate ning „ continuous integration “ töövõtete ning seadistamisega 5 .6 SOA ja Mikroteenustel põhinevate arhitektuurilahenduste projekteerimisel ning realiseerimisel 5 .7 Konteinerlahenduse loomisel 5 . 8 Spring raamistikuga 5 . 9 Hibernate raamistikuga 5 . 10 REST ja SOAP veebiteenused 5 .1 1 Angular raamistikuga 5.12 Konteinerlahenduse loomisel 5.1 2 PostgreSQL 6 Scrum Master k ogemus vähemalt kahes projektis UI (veebidisainer) (nimi, isikukood): .................. Nõude kood Nõuded Kas vastab esitatud nõudele (JAH/ EI) Täpsustus selle kohta kus/millal/kuidas on nõue täidetud. Projektidele viitamisel märkida projekti tellinud asutus, tellija kontaktisik ja projekti nimi , projekti kestvus kalendrikuudes arvestades, et hankijal on õigus kontrollida esitatud andmeid viidatud kontaktisiku vahendusel . Välja täitmine on kohustuslik. 1 Omab vähemalt 3 -aastast töökogemust veebidisainer. Tuua välja (kokku) 3- aasta ke stvusega projekte, millest nähtub töökogemuse omandamine. 2 On osalenud veebidisainerina vähemalt 6 veebilehe kasutajaliidese (e-kommerts, iseteenindus või samaväärne) disaini projektis viimase 3 aasta jooksul. 1. 2. 3. 4. 5. 6. 3 Omab töökogemust: 3.1 veebilehtede graafilise disaini loomisel 3.2 Wireframe ja prototüüpide loomisel 3.3 On osalenud vähemalt 2 projektis viimase 3 aasta jooksul alates hanke väljakuulutamisest, kus on järgitud minimaalselt WCAG 2.0 AA-taset . Lisa link Lisa link 3.4 On osalenud vähemalt 2 projektis viimase 3 aasta jooksul hanke väljakuulutamisest, kus ta on testinud vastavust WCAG 2.0 AA-taseme nõuetele. Lisa link Lisa link 4 Scrum Master kogemus vähemalt kahes projektis UX disainer (kasutajakogemuse disainer) (nimi, isikukood): .................. Nõude kood Nõuded Kas vastab esitatud nõudele (JAH/ EI) Täpsustus selle kohta kus/millal/kuidas on nõue täidetud. Projektidele viitamisel märkida projekti tellinud asutus, tellija kontaktisik ja projekti nimi, projekti kestvus kalendrikuudes arvestades, et hankijal on õigus kontrollida esitatud andmeid viidatud kontaktisiku vahendusel. Välja täitmine on kohustuslik. 1 Omab vähemalt 3 -aastast töökogemust kasutajakogemuse disainerina . Tuua välja (kokku) 3- aasta ke stvusega projekte, millest nähtub töökogemuse omandamine. 2 On osalenud kasutajakogemuse disainerina vähemalt 6 kasutajaliidese (e-kommerts, iseteenindus või samaväärne) disaini projektis viimase 3 aasta jooksul. 1. 2. 3. 4. 5. 6. 3 Omab töökogemust: 3.1 persoonade loomisel 3.2 töövoogude kirjeldamisel 3.3 Wireframe ja prototüüpide loomisel 3.4 kasutatavuse (UX) analüüside teostamisel . 4 Scrum Master kogemus vähemalt kahes projektis Testija (nimi, isikukood): ...................... Nõude kood Nõuded Kas vastab esitatud nõudele (JAH/ EI) Täpsustus selle kohta kus/millal/kuidas on nõue täidetud. Projektidele viitamisel märkida projekti tellinud asutus, tellija kontaktisik ja projekti nimi, projekti kestvus kalendrikuudes arvestades, et hankijal on õigus kontrollida esitatud andmeid viidatud kontaktisiku vahendusel. Välja täitmine on kohustuslik. 1 Omab vähemalt 2 -aastast töökogemust testijana või programmeerijana . Tuua välja (kokku) 2 - aasta ke stvusega projekte, millest nähtub töökogemuse omandamine. 2 On osalenud vähemalt kahes tarkvara arenduse projektis viimase 3 aasta jooksul alates hanke väljakuulutamisest , kus on teostanud testide automatiseerimist. 3 T eadmised GitLab’st , kuidas kasutada, commit’da muudatused ja hoida projekti ajakohasena . 4 T eadmised, kuidas kasutada GitLab Pipeline . 5 O mab põhiteadmisi Java kasutamiseks ja skriptimiseks – Webdriver , JUnit , TestNG , JMeter . 6 O skus kasutada ja kirjutada skripte JSON, XML, REST. 7 Scrum Master kogemus vähemalt kahes projektis Raamlepingu Lisa 3 Hankelepingu projekt HANKELEPING nr ..... Tervise ja Heaolu Infosüsteemide Keskus (edaspidi nimetatud ka t ellija ), registrikood 70009700, aadress Uus-Tatari 25, Tallinn, keda esindab põhimääruse alusel direktor Katrin Reinhold ja Industry62 OÜ , (edaspidi nimetatud ka t äitja ), registrikood 11124544 , aadress Toompuiestee 35 Tallinn 10133 , keda esindab Maris Siilbek edaspidi koos või eraldi nimetatud ka p ool või p ooled, sõlmisid t ellija läbiviidud riigihanke s „ Ravimiameti infosüsteemi Samtrack arendus- ja hooldustööd “ raamlepingu nr . 214847 alusel hankelepingu (edaspidi nimetatud ka leping) alljärgnevas. LEPINGU ESE Lepingu esemeks on tööd ja nendega seonduv konsultatsioon koos garantiiteenustega (edaspidi t öö), mis on kirjeldatud l isas 1 ja t äitja poolt esitatud pakkumuses. Teostatavate tööde loetelu, t öö teostamise tingimused ja muud olulised lepingu täitmise kokkulepped on fikseeritud lisas 1 (tehniline kirjeldus) . Lepingu t ööde maht on ....... (hankelepingu sõlmimisel lepitakse kokku hankelepingu maht kas konkreetsetes või maksimaalsetes töö tundides, fikseeritud hinnana kogu teostatava töö eest , vmt moel vastavalt poolte kokkuleppele ) . Vajadusel on tellijal õigus tellida l epingu esemega seotud täiendavaid t öid kuni 20% ulatuses kokkulepitud mahust. Täiendavate t ööde tellimine j a sellega kaasnevad muudatused lepingu täitmisel lepitakse p oolte vahel kokku vähemalt digitaalselt allkirjastatud vormis. LEPINGU ÜLDTINGIMUSED Pooled teevad lepingu täitmiseks ja l epingu ees märkide saavutamiseks koostööd. Lepingu täitmisel kohustuvad p ooled tegema kõik vajalikud pingutused, et täita l eping õigeaegselt ja vastavalt kokkulepetele , lähtudes l epingus , raamlepingus ja õi gusaktides kirjeldatud kohustustest . Lepingus reguleerimata osas juhinduvad p ooled raamlepingus fikseeritud tingimustest. TÖÖDE ÜLEANDMISE JA VASTUVÕTMISE TINGIMUSED Täitja kohustub nõuetekohase t öö üle andma hiljemalt .... ( tähtaeg /tähtajad – kui töö teostatakse etappides, fikseeritakse etappide üleandmise ajad ). Töö antakse vastuvõtu testimiseks üle iga arendustsükli/etapi /lepingu lõpptähtaja vmt lõpus kokku lepitud tähtajal vastavalt lepingu lisades kokkulepitud tingimustele . Töö antakse üle allkirjastatud üleandmise ja vastuvõtmise aktiga (edaspidi ka akt ) . Koos üle antava tööga annab täitja tellijale üle kõik t ööde intellektuaalse omandi õigused vastavalt raamlepingus kirjeldatule . Tööde üleandmisel ja vastuvõtmisel lähtuvad pooled raamlepingus fikseeritud tingimustest. TÖÖDE MAKSUMUS JA ARVELDUSTE KORD Tellija tasub üksnes l epingu alusel te llitud, teostatud ja üle antud t ööde või töötundide eest ( kui tööde teostamine tellitakse töötundide põhiselt, lepitakse kokku ajaaruannete alusel tasumine, ajaaruande esitamise kohustus ja sisu ). Ü he töötunni maksumuseks t ööde teostamise l on 50.00 ( viiskümmend ) eurot ilma käibemaksuta ( L epitakse kokku punktis 1.3 sätestatud t ööde mahust lähtudes . Vajadusel, nt fikseeritud tasu kasutamise korral, ühe töötunni hinda eraldi välja ei tooda, vaid märgitakse fikseeritud tasu suurus ). Tellija tasub l epingu alusel tellitud t ööde eest kokku ..... ( maksumus sõnadega) eurot ilma käibemaksuta ( L epitakse kokku lähtudes punktis 1.3 sätestatud t ööde mahust , kui tööde teostamine on kokku lepitud etappides, fikseeritakse ühtlasi etappide maksumused ) . Täitjal on õigus esitada arve pärast t ööde vastu võtmist, mis toimub t ellija poolse a kti allkirjastamis ega /Täitjal on õigus esitada arve pärast ajaaruande tellija poolt allkirjastamist ( valida alternatiiv vastavalt konkreetse lepingu sisule ) . Täitja annab t ellijale arve ta sumiseks tähtaja minimaalselt 21 kalendri päeva alates arve esitamisest. Arvel tuleb märkida riigihanke viitenumber ja nimetus ning lepingu number. T eostatud t öö eest võib tasuda ka kolmas isik ( m aksja). Sellisel juhul sõlmitakse l eping kolmepoolselt t ellija, t äitja ja m aksja vahel ning selles lepitakse vajadusel kokku tasustamise täpsed tingimused ning kord. LEPINGU LÕPETAMINE JA ÜLES ÜTLEMINE Lepin g lõpeb kohustuste täitmisega, l epingu lõpetamise kokkuleppe sõlmimisega, muul l epingus ettenähtud või seadusest tuleneval alusel. Tellijal on õigus l eping igal ajal üles öelda , teatades sellest 6 0 kalendri päeva ette. Poolel on õigus l eping etteteatamistähtaega järgimata igal ajal üles öelda, kui teine Pool on l epingut oluliselt rikku nud või esineb raamlepingu punktis 15.3 nimetatud alus l epingu üles ütlemiseks . Olulise lepingurikkumisena mõistavad pooled raamlepingu punktis 1 5 .4 kirjeldatut . ESINDAJAD Tellija kontaktisik(ud) on: Merle Kale , telefon +372 5100922, e-post: [email protected] Täitja kontaktisik(ud) on: Taavi Tasuja , telefon +372 55641595, e-post: [email protected] Esindajate pädevuses on anda teisele poolele lepingu täitmisega seonduvat informatsiooni ja juhiseid, esitada päringuid seoses lepingu täitmisega, allkirjastada tööde üleandmise ja vastuvõtmise või ajaaruannete aktid . LÕPPSÄTTED T äitjal puudub volitus tegeleda l epingu raames avalike suhetega ning anda teateid pressile, elektroonilisele meediale, üldsusele või teistele auditooriumidele, välja arv atud t ellija eelneval kirjalikku taasesitamist võimaldaval nõusolekul. Leping, lisad ja muud selle alusel või selle täitmiseks sõlmitavad kokkulepped jõustuvad alla k irjutamisel ning kehtivad kuni p oolte kõikide kohustuste täitmiseni. Kõik teated seoses l epingu täitmisega esi tatakse e-posti või kirja teel l epingus nimetatud aadressi l või mõnel muul aadressil, mille p ool on teisele p oolele teatavaks teinud. Informatiivset teadet võib edastada ka telefoni teel. Informatiivseks loetakse teade, millega ei kaasne iseseisvaid õiguslikke tagajärgi. L epingut saab muuta p oolte kirj alik u l kokkuleppel . Kõik l epingu muudatused tuleb sõlmida l epinguga samas vormis ja need jõustuvad allkirjastamisel . L epingu täitmisest tulenevad vaidlused ja la hkarvamused püütakse lahendada läbirääkimiste teel. Kokkuleppe mittesaavutamisel lahendatakse vaidlus Harju Maakohtus. Lepingule kohaldub Eesti õigus. LISAD Lisa 1 - Hankelepingu eseme tehniline kirjeldus (ja selle lisad) ; Lisa 2 - Täitja poolt esitatud pakkumus (või selle väljavõte) ; Lisa 3 - .... . POOLTE ALLKIRJAD Tellija Täitja (allkirjastatud digitaalselt) (allkirjastatud digitaalselt) Kodukord Raamlepingu lisa 4 Ravimiameti infosüsteemi Samtrack arendus- ja hooldustööd Eesmärk Kodukorra eesmärk on täpsustada hanke lepingute alusel (edaspidi nimetatud ka projekt) tööde tellimise korda ja põhimõtteid, T äitja ja T ellija omavahelist suhtlus t ning tagasiside andmise korda. Tellija võib teha kodukorda muudatusi, teavitades T äitjat kodukorra muutmisest. Mõisted Töö – Lepingus (hankeleping või tellimuskiri ) fikseeritud töö(d)/tegevus(ed) ja üle antav(ad) tulem(id), mida saab testida või mille valmimist saab kinnitada T ellija. Ü leandmise ja vastuvõtmise akt (A kt) - T öö üleandmist ja vastuvõtmist kinnitav doku ment, mis allkirjastatakse nii Täitja kui Tellija poolt ja mis on T äitjale aluseks arve esitamiseks ning T ellijale arve tasumiseks. Loodava i nfosüsteemi kasutaja – Ravimaimet (RA), kes hakkab Töös tellitud infosüsteemi kasutama, sh testib üle antud töid sisuliselt. T äitja ja Tellija ülesanded T äitja põhiülesanded: teostada kokkulepitud tööd kokkulepitud ulatuses, mahus ja ajakavas; koostada ja täiendada tööde teostamise eelselt ja käigus kokkulepitud dokumentatsiooni; anda selgitusi ja konsultatsioone teostatud tööde kohta; k oolitada Tellijat tööde valmimise järgselt ; esitama Tellija le tööde teostamise detailsed ajaaruanded n ing täit m a muid Lepingust tulenevaid kohustusi. Pooled täpsustavad Täitja ülesandeid Lepingu sõlmimisel. Tellija 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õue tekohaselt teostatud tööde eest. Vajadusel täpsustavad Pooled Tellija ülesandeid Lepingu sõlmimisel . Üldine töökorraldus Arenduste läbiviimise metoodika kehtestab Tellija konkreetse Lepingu sõlmimise tingimusena. Arenduste läbiviimine toimub kas: funktsionaalsuse põhiselt, kus sisendiks on konkreetse tulemi (skoobi) tellimus, sh tähtaeg ja/või piirsumma või arendusmeeskonna töötundide põhiselt, kus arendused realiseeritakse agiilse arendusprotsessi põhimõtetel. Agiilse arenduse all peame silmas, et me hindame inimesi, oleme ise motiveeritud ja motiveerime teisi, tihedat koostööd, kohtumisi, koostöötamist, suutlikkust muutuvas olukorras langetada teenuse kasutajat silmas pidades parim otsus, soovi otsida pidevalt parimaid lahendusi. Lisaks eeldame, et iga töö tellimise puhul Täitja esitab Tellijale töö teostamiseks vajamineva hinnangulise tundide arvu ja Pooled püüavad leida konsensuse iga otsuse langetamisel – näiteks sprintide tööde prioritiseerimis e l . Töid tellitakse vastavalt Tellija reaalsele vajadusele ning Täitja peab olema valmis võimalike ajaliste pauside tekkimiseks tööde tellimuste esitamise vahepealsel ajal. Täitja peab arvestama, et Tellija võib vajada tellimuste esitamisel tööde teostamiseks erinevaid meeskonnaliikmeid erinevas koosseisus (st iga tellimuse täitmisel ei ole vajalik 8-liikmelise meeskonna rakendamine , nt hooldustööde tellimisel ). Esimese hankelepingu täitmiseks kaasatakse vähemalt kõik riigihankes nõutud meeskonnaliikmeid. Lepingus fikseerivad Tellija ja Täitja selle alusel teostatavad Tööd. Iga Töö osas fikseeritakse selle maht ja valmimise tähtaeg, sh agiilse arendusmeetodi kasutamise korral. Arendustööde puhul fikseeritakse tarne tähtaeg(-ajad) ja planeeritav Live keskkonda paigaldamise tähtaeg. Arendustööde vahetarnete tsükkel (sprint) on kaks nädalat, kui Lepingus ei ole kokku lepitud teisiti. Lepingu eesmärgi saavutamiseks vajalike tegevuste täpsem kirjeldus ja tähtajad fikseeritakse Lepingus. Töökorraldus arendustööde testimisel: Täitja annab Tellijale üle omalt poolt testitud Töö. Tellija poolel testivad Tööd TEHIK kui Tellija esindaja (testib tehnilist osa) ja RA kui Teenuse kasutaja (testib sisulist osa). Tellija esindaja ja Teenuse kasutaja testivad Tööd Testkeskkonnas ja Prelive keskkonnas. Üldjuhul viiakse Töö Testkeskkonnast Prelive keskkonda pärast vigade parandamist. Pisivigadega Tööd võib viia Prelive keskkonda, kui Tellija ja Täitja vahel on kokku lepitud pisivigade kõrvaldamise aeg. Juhul kui Töö valmib etapiviisiliselt, kuid tuleb kasutusele võtta tervikuna, toimub pärast Töö etappide valmimist ja enne Live keskkonda panemist kogu Töö Tellija poolne vastuvõtutestimine Prelive keskkonnas ( kindlustamaks Töö nõuetele vastamine ja toimimine tervikuna).Tellija projektijuht otsustab, kas Töö on võimalik viia järgmisesse testimise etappi (nt Testkeskkonnast Prelive keskkonda jmt). Akteerimisele kuulub Töö, mis on edukalt läbinud vastuvõtutestimise Prelive keskkonnas. Täitja poolne Tööde teostamine ei tohi tekitada häireid Tellija mistahes teiste liidestatud süsteemide või teenuste talitluses, v.a juhul kui Täitja lähtus Töö teostamisel Tellija poolsetest juhistest ja kokkulepetest, kuid sellele vaatamata tekkisid häired. Juhul, kui Töö teostamine toimub Tellija ruumides, peavad Tellija ruumides viibivad Täitja esindajad kinni pidama Tellija juures kehtivatest sisekorraeeskirjadest, sh turvanõuetest, mis on Tellija poolt teatavaks tehtud. Lepingu täitmisest tulenev suhtlus toimub eesti keeles. Tööde teostamise meeskond ja vastutused Tööde teostamiseks moodustatakse projektimeeskond. Kumbki Pool nimetab tööde teostamiseks omapoolse projektijuhi. T äitja projektijuht juhib Täitja poolt tööde tulemi kokkuleppimist, vastutab tööde teostamise ajaplaani koostamise eest ning tagab kokkulepitud tööde tulemi valmimise ja ajaplaani täitmise. Tellija projektijuht juhib Tellija poolt tööde tellimuse ja ajaplaani kokkuleppimist ning tööde teostamist. Tellija projektijuhil on õigus kontrollida Lepingu täitmise käiku ning kohustus anda Täitjale töödega seotud informatsiooni ja ju hiseid vastava nõude esitamisel. K umbki Pool peab tagama, et tema projektijuhil on vajalik ajaressurss ning kõik vajalikud õigused ja pädevus vastava Poole nimel tegutseda. Projektimeeskonna liikmed (teostajad) vastutavad, et nende poolt teostatud tööd on teostatud ja dokumenteeritud vastavalt kokkulepitud töö eesmärgile ning Tellija suunistele ja nõuetele ning valdkonnas kehtivatele parimale praktikale. Kumbki Pool peab tagama, et tema kaasatud teostajal on kõik vajalikud teadmised, oskused ja kogemused ning piisav ajaressurss vastava Poole nimel töid teostada. Juhul kui ilmnevad takistused, mille tõttu vähemalt üks Pooltest ei saa kokkulepitud töid teostada, tuleb sellest koheselt informeerida mõlema Poole projektijuhte. Sõltuvalt sellest, millise ulatusega on tööde teostamise viivitus, tuleb vajadusel korrigeerida ka seotud tööde plaani. Sõltuvalt probleemi ulatusest peavad vastavad projektorganisatsiooni liikmed analüüsima tekkinud olukorra põhjusi ja vajadusel võtma tarvitusele abinõud, et ennetada sarnase olukorra tekkimist. Täitja on kohustatud kasutama tööde teostamisel pakkumuses nimetatud meeskonnaliikmeid ning meeskonnaliikmete lisandumisel või asendamisel järgima ra amlepingus sätestatud tingimusi. Töötunnipõhiste tellimuste täitmisel kuuluvad Tellija poolt tasustamisele üksnes reaalselt töö teostamiseks kulutatud efektiivsed töötunnid, mis loovad Tellijale väärtust. Tellija ei tasusta ega aktsepteeri ajaaruannetes seadusest tulenevate pauside arveldamist (nt lõunapausid, paus silmade p uhkamiseks jmt). Vajadusel täpsustavad Pooled hankelepingu sõlmimisel meeskonnas teostajate rollid. Tellija juures töötab projekti juhtrühm, mis jälgib raamlepingu alusel sõlmitud Lepingute täitmist. Juhtrühmal on pädevus teha otsuseid mikrotasandil. Tellija juures töötab projekti töörühm, mis koordineerib igapäevast tegevust. Lepingu täitmisega seotud infovahetus 6.1 Lepingute täitmisega seotud dokumentatsiooni haldamiseks ja jagamiseks kasutatakse Tellija poolt nimetatud keskkonda (nt Confluence). Tellija tagab täitjale keskkonna kättesaadavuse. Dokumentide hoidmise struktuur, selle täiendused ja muudatused lepitakse kokku poolte projektijuhtide vahel. Dokumentide lisamise, muutmise ja kustutamise reeglid lepitakse kokku poolte projektijuhtide vahel, kes tagavad kokkulepitud reeglite järgimise oma meeskonnas. Konfiguratsiooni- ja arendustööde ülesannete suunamiseks ja jälgimiseks, vigade ja probleemide haldamiseks ning tööaja arvestuseks kasutatakse tellija poolt nimetatud töövahendit (nt Jira). 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. Rakenduse lähtekoodi hoidmiseks kasutatakse https://gitlab.sotsiaalministeerium.ee . Lähtekoodi haldamisel ja versioneerimisel tuleb lähtuda http://nvie.com/posts/a-successful-git-branching-model/ mudelist. 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. Teabevahetuse vormid ja reageerimisajad: Koosolek – koosoleku kokkukutsumisel esitatakse päevakord ja eesmärk. Võimaluse korral lepitakse projekti alguses kokku korralised koosolekud. Korralisi koosolekuid võib poolte kokkuleppel tühistada (hiljemalt samal päeval 2-tunnise etteteatamise ajaga). Muude koosolekute kutsed tuleb esitada vähemalt 2 (kaks) tööpäeva enne koosoleku toimumist. Koosoleku toimumise järel koostatakse memo (vastutab koosoleku korraldaja), otsused protokollitakse ja saadetakse e-kirjaga koosolekul osalenutele teadmiseks/vajadusel kinnitamiseks. E-kiri – kasutatakse igapäevase suhtluskanalina (v.a kui infot tuleb vastavalt kodukorrale edastada täitja projektikeskkondade kaudu). Skype ja muud sarnased sõnumivahetuskeskkonnad – kasutatakse kiireloomuliseks ja operatiivseks suhtluseks. Skype’i kõneteenuse või telefoni kaudu kokku lepitud otsused tuleb kinnituseks fikseerida Jira piletiga, e-kirjaga või arutada ja protokollida koosolekul. Pooled säilitavad projekti e-kirjad, Skype'i ja/või muudes sõnumivahetuskeskkondades toimunud vestlused projekti ja garantiiperioodi kehtivuse ajal. Poolte projektijuhid lepivad kokku e-posti, Skype'i ja muude sarnaste sõnumivahetuskeskkondade gruppide loomise. Telefon - kasutatakse operatiivse ja olulise informatsiooni edastamiseks, samuti kriisisituatsioonides. Telefonikõnele mitte vastates tuleb tagasi helistada esimesel võimalusel, aga mitte hiljem kui järgmise tööpäeva lõpus. Olulistel juhtudel (näiteks arendustööde juurutusfaasis) peavad mõlema poole projektijuhid olema telefoni teel kättesaadavad ka pärast ametlikku tööpäeva lõppu. Valmisolek lepitakse eraldi kokku. Stand-up kohtumine – Toimub tööde teostamise ajal vastavalt tellija ja täitja kokkuleppele ning t äitja esindajate osalusel. Stand-upi osalejad ja täpsem formaat lepitakse kokku enne esimese töö tellimist. Nõuded dokumenteerimisele Projekti dokumentatsioon peab olema terviklik ja terminoloogiliselt üheselt mõistetav. Dokumentatsiooni kvaliteedi eest vastutavad poolte projektijuhid. Tellija projektijuhil on õigus nõuda täitja 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. Nõuded dokumente erimisele on esitatud dokumentides "Mittefunktsionaalsed nõuded arendustele " ja „Nõuded infosüsteemi dokumentatsioonile“ . Arendus-, test-, prelive - ja live keskkonnad Arenduskeskkond asub tellija juures, kes tagab selle olemasolu ja toimimise. Tellija testkeskkond koosneb vähendatud võimsusega komponentidest. Täitjal võib olla tellija testkeskkonnale lugemisõigusega ligipääs. Tellija prelive keskkond koosneb live keskkonnale sarnastest komponentidest, sh andmebaasid, rakendusserverid ning väliste süsteemide liidesed. Täitjal puudub alaline ligipääs tellija p relive keskkonnale. Live keskkonna konfiguratsioon lepitakse kokku arenduse käigus. Täitjal puudub ligipääs tellija live keskkonnale. Pooled teevad mõistlikud pingutused tagamaks, et tellija testkeskkond sarnaneks live keskkonnale järgmises osas: arvutivõrgu konfiguratsioon; liidesed kolmandate süsteemidega; andmemahud; kui maksimaalne sarnasus ei ole majanduslikult põhjendatud või tulenevalt andmekaitse piirangutest võimalik, kohustub pool informeerima teist poolt test- ja l iv e keskkondade disainitud erinevustest. Vajadusel lepivad pooled kokku alternatiivse võimaluse keskkondade erinevuse puudujäägi kompenseerimiseks. Keskkondade ning nende ligipääsude haldamise ja tarnete paigalduse reeglid lepitakse kokku projekti alguses. Vea parandamine arenduse, juurutamise või garantiiperioodi käigus Vigade menetlemise käigus registreeritakse kõik poolte leitud vead tellija poolt nimetatud keskkonnas (nt Jira). Täitja analüüsib vea kirjeldust ning selgitab välja vea põhjuse. Vigadele määratakse Tellija poolt kriitilisuse aste ning neid asutakse parandama kriitilisuse järjekorras või muus T ellija poolt teatavaks tehtud järjekorras. Garantiiperioodil asub täitja viga parandama vastavalt raamlepingus sätestatud tingimustele. Kriisisituatsioonide haldamine Kriisisituatsiooniks loetakse olukorda, kus poolte esindajad ei suuda kokkuleppele jõuda või on muutunud võimatuks võtmeisikute osalemine tööde teostamisel või ilmnenud on muud asjaolud, mis võivad oluliselt mõjutada tööde edukat elluviimist ja/või satuvad olulisse ohtu kokkulepitud tähtajad ja/või funktsionaalsus. Kriisi tekkimisel on pool kohustatud sellest teise poole esindajat viivitamatult kirjalikult teavitama. Kriisist väljumiseks teevad mõlemad pooled kõik endast sõltuva kriisist väljatulekuks ja mõlemat poolt rahuldava lahenduse leidmiseks. Kriisi vältimise ja kriisist väljumise eest vastutavad poolte projektijuhid. Kui kriisi ei suudeta likvideerida, rakendatakse lepingus sätestatud meetmeid. SamTrack a rhitektuur Dokumendi versioonid Versioon Kuupäev Autor Kommentaar 0.1 20.09 .2019 Artur Novek Esmane versioon, dokumendi struktuur, esialgsed EA joonised - komponentmudel, paigaldusmudel, mõnede komponentide ja liideste kirjeldused; keskkonnad 0.2 07 . 10.2019 Artur Novek Mudelite täiendused 0.3 10 .10.2019 Artur Novek Lisatud migratsioon ja väikesed täiendused 1.0 18 .10.2019 Artur Novek Arvestatud tagasisidega Ravimiametist 1.1 03.12.2019 Artur Novek Komponendid „RA kliendiportaali liidestus“, „RA kodulehe liidestus“, „Retseptikeskuse liidestus“, „Äriregistri liidestus“ ja „ADS liidestus“ on nüüd joonistel märgistatud kollasega – realiseeritakse järgmistes etappides. Täpsustatud CTS ja CESP liidese kirjeldus t. Sisukord TOC \o "1-3" \h \z \u Dokumendi versioonid PAGEREF _Toc22295212 \h 1 Sisukord PAGEREF _Toc22295213 \h 1 Sissejuhatus PAGEREF _Toc22295214 \h 2 Komponentdiagramm PAGEREF _Toc22295215 \h 3 Paigaldusvaade PAGEREF _Toc22295216 \h 5 Rajadokument PAGEREF _Toc22295217 \h 7 Kasutaja arvuti PAGEREF _Toc22295218 \h 7 Esitluskiht PAGEREF _Toc22295219 \h 7 Teenuste kiht PAGEREF _Toc22295220 \h 8 Struktureeritud andmete mikroteenused PAGEREF _Toc22295221 \h 8 Andmete kiht PAGEREF _Toc22295222 \h 8 TEHIKu baasplatvormi teenused PAGEREF _Toc22295223 \h 9 Euroopa süsteemide liidestused PAGEREF _Toc22295224 \h 9 X-tee liidestused PAGEREF _Toc22295225 \h 9 RA teenuste liidestused PAGEREF _Toc22295226 \h 10 Analüütika kiht PAGEREF _Toc22295227 \h 10 Ravimiameti teenused PAGEREF _Toc22295228 \h 10 TEHIKu jagatud teenused PAGEREF _Toc22295229 \h 11 Välised süsteemid PAGEREF _Toc22295230 \h 11 Euroopa süsteemid PAGEREF _Toc22295231 \h 11 Hetkel teada olevad X-tee alamsüsteemid, millega on vaja liidestada PAGEREF _Toc22295232 \h 12 Riigi jagatud teenused PAGEREF _Toc22295233 \h 12 Sertifitseerimiskeskuse teenused PAGEREF _Toc22295234 \h 12 Andmete ülekanne PAGEREF _Toc22295235 \h 13 Süsteemi arhitektuuris kasutatavad tehnoloogiad PAGEREF _Toc22295236 \h 13 Sissejuhatus Dokumendis kirjeldatakse SamTrack arhitektuurilist visiooni. Dokumendis välja toodud komponendid ja nende omavaheline suhtlus ei ole lõplik ja on teostajale suuna ning põhimõtete näitajaks. Täpsem komponentide loend ja vajadus selgub detailanalüüsi käigus. Diagrammidel roheliselt on märgitud osad, mis vajavad loomist SamTrack esimeses etapis, k ollaselt märgitud komponendid vajavad loomist järgmistes etappides. Siniselt on välja toodud komponendid, mis vajavad seadistusi ning väiksemaid muudatusi, et neid SamTrack arendustööde raames kasutada. Roosalt on välja toodud komponendid, mille seadistused ja muudatused ei ole Sam T rack tööde osa. Komponentdiagramm Allolev komponentdiagramm sisaldab Samtrack-i s paiknevaid tehnilisi ja äriloogilisi komponente. Infosüsteem on laias laastus jagatud järgmisteks osadeks: e sitluskiht , struktureeritud andmetega seotud mikroteenuste kiht, l iideste kiht , andme kiht , TEHIKu baasplatvormi teenuste kiht. Olulised Samtrack-iga seotud välised osad on järgmised: analüütika kiht, Ravimiameti infosüsteemid, TEHIKu jagatud teenused, Riigi jagatud IT teenused, seotud X-tee alamsüsteemid, seotud Euroopa infosüsteemid. Paigaldusvaade Paigaldusvaade kirjeldab süsteemi komponentide paigaldust ning omavahelist suhtlust. Komponendid peavad suhtlema omavahe l üle standardsete protokollide, kõikide komponentide liidesed peavad olema dokumenteeritud. Loodavad komponendid peavad olema skaleeritavad, koormust juhitakse konteinerlahenduses oleva proxy teenusega. Loodavate komponentide omavaheline suhtlus teenuste kihis ja esitluskihis käib üle JSON REST teenuste. A ndmebaasi , jagatud teenuste ja väliste teenuste puhul kasutatakse neile vastavaid protokolle. Avalikus võrgus olevad komponendid peavad kasutama SSO põhimõtet, ülejäänud komponentide vaheline suhtlus peab olema kaitstud API võtme või sertifikaadi autentimisega. Täpsem lähenemine selgub detailanalüüsi käigus. Infosüsteem kasutab UTF8 kodeeringu t. Keskkonnad SamT rack infosüsteemil on vähemalt 4 keskkonda: Arenduskeskkond : Arendajatele mõeldud keskkond. Kasutab arenduse X-teed. Testkeskkond : Vastuvõtutestide tegemiseks mõeldud keskkond. Kasutab test X-teed. Turvatesti keskkond : Turvatestide tegemiseks mõeldud keskkond. Kasutab test X-teed. Tootmiskeskkond : Päris andmed. Kasutab toodangu X-tee d . Rajadokument Kasutaja arvuti Brauser Standardne v eebibrauser (Chrome , Internet Explorer ) Protokollid ja tehnoloogiad: HTTPS, HTML5, CSS3, AJAX EURS klient EURS paks töölaua klient taotluste andmete salvestamiseks EURS serverisse Kontoritarkvara (MS Office) Outlook E-posti klient E-posti jaoks SMTP või IMAP; Tõenäoliselt peab olema liidestatud RA dokumendihaldusega, arenduse käigus tuleb leida selleks kasutajatel sobiv viis; Word Tekstiredaktor Failisüsteemi doc või docx vormingus dokumendid; Peab olema liidestatud RA dokumendihaldusega, arenduse käigus tuleb leida selleks kasutajatel sobiv viis; Excel Tabelarvutussüsteem Failisüsteemis xls või xlsx vormingus failid; Tõenäoliselt peab olema liidestatud RA dokumendihaldusega, arenduse käigus tuleb leida selleks kasutajatel sobiv viis; Adobe Acrobat PDF dokumentide lugemise ja loomise tarkvara; Failisüsteemis pdf vormingus failid; Esitluskiht Esitluskiht realiseeritakse kasutades RIA poolt jagatavat stiiliraamatut „Veera“ ning selle realisatsiooni Angular komponentidega. Esitluskiht suhtleb teenuste kihiga HTTPS ja REST/JSON protokollide abil. Esitluskihis on vähemalt järgmised alamjaotised. Admin - Isikute, ettevõtete, nende aadresside ja muude kontaktandmete haldus; loendite haldus ; rollide haldus, etappide haldus; dokumendi- ja e-kirja mallide haldus; Juhtumi menetlus Müügiload Müügiloata ravimite kasutusload Sisse-väljaveo load Ravimiohutus Tarneraskused Ravimistatistika Ravimikaart Töölaud Otsing Teenuste kiht Teenuste kiht pakub REST/JSON (mikro)teenuseid teistele komponentidele ja sealhulgas ka kasutajaliidesele. Struktureeritud andmete mikroteenused Üldised – Loendid, Isikud, Ettevõtted, Kontaktid, Aadressid Juhtumi m enetlus –Müügiload, Sisse-v äljaveo load, M üügiloata ravimi kasutusload , Ravimiohutus, Tarneraskused, Ravimistatistika Ravim – Ravimid, Pakendid , Ained Andmete kiht Andmebaasid Struktureeritud andmed salvestatakse relatsioonilisse PostgreSQL andmebaasi Protokoll: SQL; Java rakenduste korral JDBC; RA dokumendihaldus Realiseeritakse Alfresco Community Edition -it kasutades Toetab standardeid : CMIS (Content Management Interoperability Services); WebDav,FTP; MS Office Services; IMAP, SMTP; Failihoidla Protokollid ja tarkvara lepitakse kokku arenduse käigus TEHIKu baasplatvormi teenused Redis NoSql andmebaas sessioonide hoiustamiseks Kasutatav protokoll: RESP Töövoo - ja otsustus mootor Camunda Töövoogude ja otsuste automatiseerimise platvorm Protokollid: protsesside halduseks BPMN, otsustusmootor DMN Sõnumite vahendaja RabbitMQ Kasutatakse komponentide vaheliseks asünkroonseks suhtluseks Protokoll : AMQP (Advanced Message Queueing Protocol) Teenuste kihis on veel : Dokumendi- ja e-kirja generaator Genereerib malle ja sisendandmeid kasutades dokumente ja e-kirju Euroopa süsteemide liidestused CESP portaali liides tus – CESP saadab Ravimiameti sftp serverisse taotlus t e dokumentatsiooni CESP-ist . Automaatne regulaarne protsess või failisüsteemi muudatustele reageeriv protsess (näiteks Linux inotify https://www.linuxjournal.com/content/linux-filesystem-events-inotify ) asub saadetud taotlust töötlema. Taotluse dokumentatsioon koosneb .ZIP failist (sisaldab muuhulgas enamasti taotluse andmete .PDF ja .XML faile) ja delivery fail ist (.XML fail, mis näitab ära ka riigid, kus taotlus on esitatud). CESP-i kaudu esitatud taotluse .ZIP faili on taotleja eelnevalt spetsiaalse rakendusega genereerinud ja seejärel läbi CESP-i edastanud. Taotluse .XML fail on eAF (EU Electronic Application Forms) vormingus ( http://esubmission.ema.europa.eu/eaf/ ). eAF vorming on CESSP projekti käigus muutmisel ning esmase müügiloa taotluse vormi jaoks avaldatakse uued skeemid 2020 esimese poolaasta jooksul. Esialgne versioon skeemidest on avaldatud http://esubmission.ema.europa.eu/eaf/eAF_1.23.1.2/XSDs.zip . Taotluse andmed tuleb eAF vormingus failist Samtrack-i lisada. Kasutaja peab eelnevalt saama üle vaadata ja soovi korral muuta Samtracki laetavaid taotluse andmeid. Lisaks tuleb laadida Samtrack-i zip failis olevast dokumentatsioonist kasutaja poolt valitud failid. CTS liides tus – ko mponendis on realiseeritud CTS REST API ( CTreSt ) liidese kasutamine. Kahjuks ei ole CTS REST API dokumentatsiooni veel avaldatud. Teada on nii palju, et see baseerub OData standardil https ://www.odata.org/documentation / ja avaldatakse swagger dokumentatsioonina. Alustatakse kolme ressursiga: protseduurid, ravimid ja dokumendid, mis on seotud ravimite ja protseduuridega. Teada on, et CTS sisaldab ajagraafikuid, ravimiametite kommentaare protseduuride kohta ja menetluse käigus loodud dokumentide versioone (sh lõplikud heakskiidetud ravimiinfod ja avalikud hinnanguraportid). Päring esitatakse URL-na ja vastus JSON dokumendina. Näidis päringust ja vastusest on selline: https://s-api.cts-mrp.eu/v3/odata/Procedures?$expand=Events(%24filter%3DKey%20eq%20'PSTN')&$filter=Key%20eq%20'DE%2FH%2F4230%2F001%2FDC'&$select=Key%2CProductName "@odata.context": " https://s-api.cts-mrp.eu/v3/odata/$metadata#Procedures(Key,ProductName,Events) ", "value": [ { "Key": "DE/H/4230/001/DC", "ProductName": "DULOXETINE SUBSTIPHARM 30 mg", "Events": [ { "ProcedureKey": "DE/H/4230/001/DC", "CountryKey": "DE", "Key": "PSTN", "CmsName": "Germany", "Done": "2014-12-17T00:00:00+01:00", "Value": "Selected", "Comment": "", "IsEmpty": false, "IsRms": true, "Created": "2014-12-16T14:51:31.59+01:00" } ] Esialgu on CTS REST API-s kavas alustada kasutajanime ja paroolipõhise autentimisega (basic authentication). Samtrack esimeses etapis tuleb realiseerida minimaalselt ajagraafikute päringud CTS-ist. SPOR liides tus – SPOR API saab alla laadida lehelt https://www.idmp1.com/download-spor-api-documentation/ Common Repository liidestus – Common Repository liidese dokumentatsiooni saab arenduse ajal PSUR Repository liidestus – API kirjeldus asub siin http://esubmission.ema.europa.eu/psur/api/PSUR-Repository-API-Specification.pdf X-tee liidestused RA tegevuslubade registri liides tus - https://www.riha.ee/Infos%C3%BCsteemid/Vaata/ra-kaitlejad Retseptikeskuse liides tus – Liidestus on kahesuunaline teenused Samtracki X-tee alamsüsteemis rais ( arst_taotlus_lisa, arst_taotlus_otsus, arst_taotlus_otsus_omad) ja teenused Digiretsepti X-tee alamsüsteemis rets (mlt_otsuseta_retseptid, mlt_otsuse_saatmine) . RTK SAP liides tus – RTK SAP-i teenused on ära toodud vanas RIHA-s https://vana.riha.ee/riha/main/inf/riigi_personali-_ja_palgaarvestuse_andmekogu_sap_x-tee_alamsusteem Ravimiregistri liides tus – Samtrack pakub ravimiregistrile teenuseid X-tee alamsüsteemis rais koodide ja ravimite info sünkroniseerimiseks; Äriregistri liides tus – Eesti ettevõtete andmete pärimine üle X-tee. Vajalikud andmed ja kasutatav X-tee teenus ed lepitakse kokku arenduse käigus. ADS liidestus – aadresside päri mine üle X-tee. Vajalikud andmed ja kasutatavad X-tee teenused lepitakse kokku arenduse käigus. Terviseameti registrite liidestus – Tervishoiutöötajate , apteekrite ja tervishoiuteenuse osutajate tegevuslubade andmete pärimine üle X-tee. Vajalikud andmed ja kasutatavad X-tee teenused lepitakse kokku arenduse käigus. RA teenuste liidestused RA kliendiportaali liidestus - senine MS SQL DBLinki kasutav Samtrack1 andmebaasi sünkroniseerimise liides tuleb ümber teha. Põhimõtteliselt tuleb läbi Samtrack andmete mikroteenuste sünkroniseerida kliendiportaali MSSQL andmebaasiga andmeid. RA kodulehe liidestus – arenduse käigus lepitakse kokku, kuidas liidestatakse RA koduleht (kodulehel avaldatakse patsiendile suunatud info (PIL), kodulehe kaudu võetakse vastu kõrvaltoime teatisi, avaldatakse tarneraskuste- ja ravimiohutusega seotud infot). Analüütika kiht Analüütika TEHIKus eelistatud lahendus aruannete loomiseks ja kuvamiseks andmelao andmete pealt on Tableau; Kasutatav protokoll: HTTPS, HTML; Kasutab andmete saamiseks peamiselt andmeladu, kuid võimalik on ka näiteks operatiivsüsteemist või mujalt andmete lugemine; Andmelao laadimine Andmeanalüüsi tarvis andmete ülekande skriptid operatiivandmete baasidest andmelattu Kasutatav tehnoloogia: Pentaho ETL Kasutatav protokoll: SQL(Java korral JDBC) Andmeladu Andmeladu analüüsi ja raportite tarvis Kasutatav tehnoloogia: Vertica DB Kasutatav protokoll: SQL(Java korral JDBC) Ravimiameti teenused EURS Server - Müügiloa taotluse dokumentatsioon (mis on müügiloa taotleja poolt koostatud rahvusvaheliselt kokku lepitud nõuetele vastavas elektroonilises formaadis) imporditakse EURS-i ning kontrollitakse tehnilise validaatoriga dokumentatsiooni formaadi vastavust. Ravimiameti kliendiportaal – Tegemist on klientide pöördumiste kanaliga . Tegemist ei ole iseseisva infosüsteemiga vaid täiendava võimalusega elektrooniliseks infovahetuseks Ravimiameti klientidele (lisaks emaile, faksile, tava kirjadele). Ravimiameti koduleht - http://www.ravimiamet.ee/ TEHIKu jagatud teenused Turvaserver Standardne RIA poolt loodud X-tee turvaserver X-teel teenuste pakkumiseks või tarbimiseks Kasutatav protokoll: SOAP E-posti server Teenuse e-kirjade vahetamiseks Kasutatav tehnoloogia: Microsoft Exchange Kasutatavad protokollid: kirjade lugemiseks ja saatmiseks SMTP; Active Directory Teenus Windowsi domeeni kasutajate ja nende paroolide haldamiseks Kasutatav protokoll: LDAP S Identiteedi- ja pääsuhaldus Teenus kasutajate ja nende rollide haldamiseks; selle abil realiseeritakse Samtrackis autentimine ja autoriseerimine; Autentimine on võimalik nii kasutajanime ja parooli, kui ka ID-kaardiga või Mobiil-ID-ga Kasutatav tehnoloogia : KeyCloak Kasutatavad protokollid : LDAP (Active Directory kasutamiseks), OpenID-Connect(TARA kasutamiseks) Välised süsteemid Peatükk nimetab ja kirjeldab lühidalt välised süsteemid, mi llega Samtrack tuleb liidestada. Euroopa süsteemid CESP (Common European Submission Portal) CTS ( Communication and Tracking System) SPOR (data management services for substances, products, organisations and referentials ) Jaguneb neljaks alamosaks. Substance Management Services (SMS) Product Management Services (PMS) Organisation Management Services (OMS) Referentials Management Services (RMS) PSUR Repository EudraVigilance Eudra WebMail Hetkel teada olevad X-tee alamsüsteemid, millega on vaja liidestada Ravimiregister – Register on mõeldud arvestuse pidamiseks Eestis kehtiva müügiloaga ravimite üle ning avalikkusele nende kohta teabe andmiseks. Ravim iameti tegevuslubade register - Registri eesmärk on pidada arvestust ravimite käitlemise, ravimite vahendamise ning rakkude, kudede ja elundite käitlemise tegevuslubade omajate ja nende erialase tegevuse üle, samuti ravimite käitlemise ja vahendamise ning rakkude, kudede ja elundite käitlemisega seotud järelevalve tegemise üle, eesmärgiga saada andmeid ravimipoliitika ning rakkude, kudede ja elundite käitlemise poliitika juhtimise ja korraldamise ülesannete täitmiseks ning apteegiteenuse osutamise statistika tegemiseks. Terviseameti registrid – Registrites hallatakse tervishoiutöötajate ja tervishoiuteenuse osutajate tegevuslubade andmeid. ADS – Maameti aadressandmete süsteem; Aadresside sünkroniseerimine on vajalik kõikidele Eesti aadresside puhul. Äriregister - Äriregistrisse tehakse päringuid süsteemis olevate Eesti ettevõtete kohta äriregistrikoodi alusel; Retseptikeskus – Müügiloata ravimite kasutusloa taotluste esitamine ja otsused kasutusloa otsuste kohta; RTK SAP – arvete edastamine Riigi jagatud teenused TARA - Riigi autentimisteenus on keskselt osutatav teenus, millega asutus saab oma e-teenuses autentida ID-kaardi, mobiil-ID, smart-ID ja ka välisriigi kasutaja. https://www.ria.ee/ee/tara-autentimisteenus.html Avalik dokumendiregister - RIK-i Deltas avaldatakse Ravimiameti avalike dokumentide ja kirjade andmed . Sertifitseerimiskeskuse teenused Sertifikaatide kehtivuskinnitusteenus – Kehtivuskinnitusteenust kasutatakse sertifikaadi kehtivuse reaalajas kontrollimiseks, mis kindlustab turvalisima sertifikaadi kasutamise isikutuvastamiseks või digitaalseks allkirjastamiseks. https://www.sk.ee/teenused/kehtivuskinnituse-teenus/ Ajatempliteenus – ajatempliteenus tõendab, et teatud andmed eksisteerisid vastaval ajahetkel. Kasutatakse digiallkirjastamisel ASIC-E BDOC-TS profiiliga allkirjade puhul. https://www.sk.ee/teenused/ajatempliteenus/ Andmete ülekanne Andmete ülekanne( migratsioon) tuleks teostada Samtrack1 MS SQL andmebaasist andmete üle kandmisega Samtrack2 PostgreSQL mikroteenuste andmebaasidesse. Migratsiooni võib teha ka läbi Samtrack2 teenuste kihi. Tavaliselt on migratsioonil probleemiks vanade andmete kvaliteet. Sellisel juhul tuleb mõelda, kas ja kuidas eemaldada teenustes migratsiooni ajaks sisendandmete kontrollid või kas võib jätta üle kandmata selgelt ebakvaliteetsed andme d . Süsteemi arhitektuuris kasutatavad tehnoloogiad Kubernetes Konteinerlahenduste orkestreerimis- ja majutus lahendus Java LTS Komponentide loomisel kasutatav keel ja virtuaalmasin . Lahenduse loomisel kasutada viimast Java LTS versiooni, mis on kättesaadav. Postgre SQL Samtrack raames kasuta ta v andmebaasi mootor. Lahenduse loomisel tuleb kasutusse võtta viimane kättesaadav versioon. Angular Es itluskihis kasutatav raamistik. Swagger Komponentide teenuste dokumenteerimis raamistik masin-masin liidestuse tarvis Lisaks on lubatud kasutada tehnoloogilisi lahendusi, mis on välja toodud raamlepingu t ehnilise kirjelduse l isas 1.2 „ IT profiil “ , kuid see peab olema põhjendatud ja kokkulepitud TEHIK-u poolse arhitektiga projektis. IT-Profiil Versioon: 1.1 Käesolev dokument (edaspidi IT-profiil) sätestab tehnilised nõuded Sotsiaalministeeriumi haldusala e-teenustele, lähtudes olemasolevatest infosüsteemidest ja infrastruktuurist. Tehnoloogilise standardi kasutuselevõtu eesmärgid: 1. haldus-, hooldus- ja koolituskulude vähendamine olemasolevale infosüsteemile; 2. tekkida võivate probleemide ja kulude minimeerimine läbi erinevate infosüsteemi osade integreerimise; 3. jätkuva arengu garanteerimine kõigile kasutatavatele infotehnoloogilistele (edaspidi IT) lahendustele Sotsiaalministeeriumi haldusalas; 4. kasutatava tarkvara ja riistvara ühtsuse saavutamine, mille abil on tsentraliseeritud hangete kaudu võimalik märkimisväärselt kokku hoida; 5. süsteemidele mõjuvate turvariskide minimeerimine; 6. tekitada süsteemide kasutajatele efektiivne, turvaline ja mugav töökeskkond. Eeltoodud eesmärkide saavutamiseks järgitakse IT toodete ja komponentide valikul järgmisi põhimõtteid: 1. sama funktsionaalsusega, kuid erinevate tootjate komponentide arv peab olema viidud miinimumini. Standard riistvara soetamisel eelistada soovitavalt ühe tootja seadmeid, mis tagab kogu IT infrastruktuuri parema toimivuse ja seadmete ühilduvuse; 2. kõik valitud tooted peavad de facto vastama kehtivatele tööstusstandarditele, kusjuures tuleb eelistada avatud standardeid; 3. testistaadiumis (beta, release candidate jne) tarkvara võib kasutada ainult testimise eesmärgil; 4. komponendid ja tooted peavad vastama asutuse poolt määratud turvareeglitele; 5. komponentide ja tootete, mis ei ole antud dokumendis kajastatud, kasutuselele võtmine vajab eelnevat arhitektuurinõukogu heakskiitu. Kehtib nii olemasolevate süsteemide uudendamise kui ka uute süsteemide loomise kohta (Applies to building brand new systems and also to refactoring existing systems) KOMPONENTIDE STANDARDID ja TEHNOLOOGIAD ÜLEVAADE (STANDARDS and TECHNOLOGIES) (COMPONENT OVERVIEW) STANDARDID TOOTJAD, TÖÖRIISTAD ja LAHENDUSED KOMMENTAARID (C (STANDARDS) (VENDORS, TOOLS & SOLUTIONS) OMMENTS) TEHNOLOOGIA Eelistatud Aktsepteeritav Mitte valida Eelistatud Aktsepteeritav Mitte valida KOMMENTAARID KOMPONENT (TEC (Preferred) (Acceptable) (Do not select) (Preferred) (Acceptable) (Do not select) (COMMENTS) HNOLOGY COMPONENT) Kliendi kiht (Client Layer) Lauaarvuti ja sülearvuti OS / Windows Linux keskkond macOS (Desktop & laptop client OS / environment) Lauaarvuti ja sülearvuti kliendi HTML5 HTML 4 EDGE Safari avalik kasutajaliides Chrome Native for COTS (Desktop & laptop (commercial off- client user interface) the-shelf) in special cases Lauaarvuti ja sülearvuti asutuse Internet Explorer sisene kasutaja Chrome kasutajaliides (Desktop & laptop client user interface) Mobiilse kliendi OS / keskkond iOS Windows Phone (Mobile client OS / Android Java application environment) (Java ME Runtime Environment) Mobiilse kliendi kasutajaliides HTML5 Native App HTML 4 Chrome HTML5 IE for mobile (Mobile client user Safari packaged into Opera interface) Android browser Native app Native App Eelistatud Aktsepteeritav Mitte valida Eelistatud Aktsepteeritav Mitte valida KOMMENTAARID (Preferred) (Acceptable) (Do not select) (Preferred) (Acceptable) (Do not select) (COMMENTS) Esitluskiht (Presentation Layer) Portaali raamistik Liferay MS Sharepoint (Portal framework) Sisuhaldussüsteem (Web content Typo3 Drupal Wordpress management system) Joomla Esitluskihi raamistik (Presentation MVC pattern Java: JSP Microsoft .Net framework (View)) JS: JSF Python Angular* Bootstrap Veebiserver Apache Microsoft IIS (Web server) Nginx (for Microsoft based applications) Funktsionaalne testimine Selenium (Functional testing) Eelistatud Aktsepteeritav Mitte valida Eelistatud Aktsepteeritav Mitte valida KOMMENTAARID (Preferred) (Acceptable) (Do not select) (Preferred) (Acceptable) (Do not select) (COMMENTS) Rakenduskiht (Application Layer) Rakenduse raamistik For Javascript include (Application MVC pattern Java: Spring Microsoft .Net tools from Yeoman, framework) JS: AngularJS Karma, Jasmine Java: Digidoc4j Persistence Updates pending framework ORM Java: MyBatis jOOQ frameworks Hibernate Otsingumootori indeks Elasticsearch (Search Engine Index) Integratsioon (External integration SOAP AQ SOAP: Apache AQ (integration to other REST JMS Axis 2, Apache JMS systems)) AMQP CXF RabbitMQ REST: Language based frameworks Andmete laadimine (Data Loading - ETL) Pentaho iWay service manager Sybase ETL Aplikatsiooniserver (Application server) Java .NET Tomcat WildFly Java EE: Java EE WSGI .NET: MS IIS Apache Webmethods JServ Integration Server Sun Java System Applicatio n Server SAP IBM WebSphe re Oracle iAS Oracle iPlanet Web Server WebLogic Aplikatsiooni haldus- ja monitooringu JMX Plumbr NewRelic raamistik Appdynamics (Application management framework) Funktsionaalne testimine SoapUI (Functional testing) Eelistatud Aktsepteeritav Mitte valida Eelistatud Aktsepteeritav Mitte valida KOMMENTAARID (Preferred) (Acceptable) (Do not select) (Preferred) (Acceptable) (Do not select) (COMMENTS) Andmekiht (Persistence Layer / Database layer) Andmebaasi migratsioon Liquibase (Database migration) Relatsiooniline andmebaas SQL PostgreSQL MariaDB (OLA: Sybase (Relational DBMS) XML (OLA: Standard) Standard) MS SQL Server (OLA: Ärikriitiline) Oracle (OLA: Ärikriitiline) Mitterelatsioonilised andmebaasid: MongoDB Memcached NoSql, puhver, CouchBase sessioonihoidla Redis (Non-Relational DBMS: NoSql, Cache, Session store) Andmeladu (Data Warehouse) Vertica Sybase IQ CouchBase Andmete replikatsioon Oracle Active PostgreSQL (Data Replication) Data Guard Londiste Postgres-BDR Eelistatud Aktsepteeritav Mitte valida Eelistatud Aktsepteeritav Mitte valida KOMMENTAARID (Preferred) (Acceptable) (Do not select) (Preferred) (Acceptable) (Do not select) (COMMENTS) Infrastruktuuri kiht (Infrastructure Layer) Directory services LDAP v3 MS Active OpenLDAP Directory OpenDJ Oracle Internet Directory Autentimine KeyCloak on (Authentication) Kerberos SAML MS AD (Local JASIG CAS liidestatud TARAga. OpenID Java network) Atlassian Crowd Dokumentatsioon: http Connect Authentication SSO (KeyCloak) s://www.keycloak.org and /documentation.html Authorization API OAUTH Ühekordne KeyCloak on sisselogimine SSO (KeyCloak) liidestatud TARAga. (Single Sign On - Dokumentatsioon: http SSO) s://www.keycloak.org /documentation.html Kasutajaõiguste KeyCloagi poolne haldus RBAC MS AD Atlassian Crowd kasutatav rollide lib: ht (Authorization) Application tps://koodivaramu. specific eesti.ee/tehik/sso/tree Keycloak + rollide /master/keycloak- api teenuse pool skais-userinfo Identiteedi haldus (Identity management) Konfiguratsioonihaldus SaltStack Ansible Spacewalk (Configuration MS SCCM management) Logihaldus (Log management) SysLog RSysLog RELP ELK Stack GreyLog Süsteemi haldamine ja järelevalve SNMP Agent Zabbix ja zabbix Nagios (System agendid Inhouse built management and Extreme Cacti monitoring) Management Oracle Center Enterprise Manager Koormusjaotur (Traffic management) Nginx F5 (OpenResty) A10 Puhverdamine (Caching) Nginx Squid (OpenResty) Varnish Tööde ajastamine (Job scheduling) Application Webmethods IS specific scheduler decision ie Quartz or cron, windows scheduler Serveri operatsioonisüsteem Linux Unix Linux Debian (OLA: IBM AIX (Server OS) Windows RedHat Standard) Other UNIXs (OLA: Ärikriitiline) CentOS (OLA: Standard) Ubuntu (OLA: Ärikriitiline) Oracle Linux (OLA: Ärikriitiline) Windows: MS (64 bit) (OLA: Ärikriitiline) Tootja poolt viimane pikaajalise toega või stabiilne versioon Konteinerid Docker Virtualiseerimine (Virtualization) Full Paravirtualization VMWare OracleVM Hyper-V virtualization Xen Serveri riistvara (Server HW) x86 RISC HP IBM Power Varundamine (Backup) Centralized SW: Mitte- Veritas tsentraalset Netbackup hallatavaid asju Symantec Backup Exec HW: HP IBM Qualstar Storage HW SAN Hitachi HDS NAS Fujitsu LAN Extreme Networks HP Juniper VPN SSL VPN PulseSecure Checkpoint IPSec Microsoft DA SAN Fibre Channel iSCSI Brocade Cisco Riistvaraline krüptomoodul Utimaco Thales Gemalto (HSM - Hardware security module) Tulemüür (Firewall) NGFW Juniper Checkpoint Eelistatud Aktsepteeritav Mitte valida Eelistatud Aktsepteeritav Mitte valida KOMMENTAARID (Preferred) (Acceptable) (Do not select) (Preferred) (Acceptable) (Do not select) (COMMENTS) Muud aspektid (Other Aspects) Programmeerimiskee led ja raamistikud Java .NET (Programming JavaScript C/C++/C# languages / PHP framework) Python Webmethods flow iWay Functional Language Java virtuaalmasina implementatsioon OpenJDK Oracle JDK Versioonihaldus (Version control GitLab SVN system) Atlassian Bitbucket Tarkvara binaar repositoorium (Artifac JFrog artifactory ts repository) Pidev tarne/Pidev integratsioon (Contin Jenkins uous integration) Gitlab CI Lähtekoodi analüüs (Code analysis) SonarQube Analüütika (Analytics) Tableau Webfocus Qlik Sense Oracle BI Publisher SAP® Business Objects Legend Kuidas valida? Ohutu valik tugeva Vajab arhitektuuri- Ära raiska aega Ohutu valik tugeva Vajab arhitektuuri- Ära raiska aega (How to select?) toetusega nõukogu heakskiitu (Do not waste toetusega nõukogu heakskiitu (Do not waste time) (Safe selection (Needs Architecture time) (Safe selection with (Needs Architecture with strong Board acceptance) strong support) Board acceptance) support)  SamTrack infosüsteemi arendustööd Mittefunktsionaalsed nõuded Versioon: 1.0 Käesolev dokument määrab kvaliteedi- ja mittefunktsionaalsed nõuded SamTrack infosüsteemi arendustele ning nende dokumentatsioonile. Käesolevat dokumenti tuleb vaadata kui arenduste kvaliteedi- ja mittefunktsionaalsete nõuete põhidokumenti. Põhidokumendi ja viidatud dokumentide erisuste puhul tuleb lähtuda põhidokumendis kirjeldatust. Põhidokumendi s viidatud TEHIK-u poolt koostatud dokumentide ja kolmandate osapoolte poolt koostatud dokumentide erisuste puhul tuleb lähtuda TEHIK-u poolt loodud dokumentides kirjeldatust. Kui mõnda nõuet ei ole võimalik või otstarbekas täita, tuleb selle mittetäitmise fakt ja põhjendus välja tuua pakkumuse esitamisel. Nõudeid tuleb järgida ka olemasolevate infosüsteemide versiooniuuendustel nii palju kui versiooniuuenduse käigus on võimalik. Nõude nr. Nõude sisu Seletused Koostamise eest vastutaja Vastavus üldistele standarditele 1.1 Lahenduse X-tee teenused peavad vastama RIA nõuetele. https://www.ria.ee/ee/xtee-juhendid.html https://www.ria.ee/et/riigi-infosusteem/andmevahetuskiht-x-tee.html Arendaja 1.2 Lahendus peab vastama TEHIK-u IT profiilile. Käesoleva hankega kaasolev dokument nimega IT-profiil. Arendaja 1.3 Infosüsteem peab olema kirjutatud arvestades selle infosüsteemi poolt töödeldavatele andmetele määratud ISKE turvaklassi nõudeid. SamTrack infosüsteemi ISKE turvaklass on K1T2S2. https://www.ria.ee/et/kuberturvalisus/infosusteemide-turvameetmete-susteem-iske.html Arendaja 1.4 Lahendus peab vastama veebide koosvõime raamistikule. https://www.mkm.ee/sites/default/files/veebide_raamistik.pdf Arendaja 1.5 Veebirakenduse kasutajaliides peab vastama vähemalt WCAG 2.0 tasemele AA. http://www.w3.org/TR/WCAG20/ Arendaja 1.6 Veebipõhine kasutajaliides peab ühilduma täielikult standarditega vähemalt eelistatult HTML 5 ja CSS 3 Valideerimiseks kasutatakse vastavaid validaatoreid: http://validator.w3.org/ Kui on tegu olemasoleva info süsteemi edasiarendusega, siis tuleb järgida olemasolevat HTML ja CSS versiooni. Arendaja 1.7 ID-kaardiga allkirjastam isel on eelistatud veebipõhine DigiD oc-teenuste kasutamine Arendaja loodud lahenduse dokumentatsioonis (nt detailanalüü s vms) peab olema välja toodud DigiD oc-teekide versioonid ja kasutuskohad Arendaja 1.8 Veebirakendus peab probleemideta läbima OWASP ASVS baasil põhineva testi Kui pole arenduse eraldi kokku lepitud teisiti, siis on OWASP ASVS viimase kehtiva versiooni tasemeks 2 ( https://www.owasp.org/index.php/Category: OWASP_Application_Security_Verification_Standard_Project ). Kinnise lähtekoodiga kommertstoote kasutamisel ei eeldata ligipääsu kinnisele lähtekoodile. Tellija poolset turvatestimist teostab kolmas sõltumatu pool. Selline esmane kolmanda poole turvatestimine tellitakse tellija finantseeringul. Ilmnenud vigade korral ja peale nende parandamist peab järel testimise rahaliselt kompenseerima arendaja, kui tellija vastava nõudmise esitab. Arendaja 1.9 Krüptoalgoritmide ja räsifunktsioonide kasutamisel tuleb järgida uusimat RIA kodulehel avaldatud krüptograafiliste algoritmide kasutusvaldkondade ja elutsükli uuringut, st lahendustes ei tohi kasutada uuringus väljatoodud ebaturvalisi algoritme ja võtmepikkuseid Arendaja loodud lahenduse dokumentatsioonis (nt detailanalüüs vms) tuleb välja tuua kasutatavad krüpto- ja räsialgoritmid, nende võtmepikkused, kasutuskohad, sh SSL /TLS sertifikaatide kasutuskohad. Värskeima uuringu leiab aadressilt https://www.ria.ee/ee/kruptouuringud.html Arendaja 1.10 Andmete edastus peab välisvõrgu liikluses olema kaitstud kasutades turvalisi ja üldteada andmeedastusprotokolle - Arendaja 1.11 Infosüsteem peab kasutama serveri kellaaega ja ajatsooni - Arendaja 1.12 Infosü steemi edasiarendamisel/loomisel peab arvestama selle võimaliku laiendamisega nii andmemahtude, kui ka kasutajate arvu osas. - Arendaja 1.13 Infosüsteem peab olema tehniliselt tükeldatud vastavalt loogilisele jaotusele. Saadud osised peavad olema eraldi versioneeritavad ja paigaldatavad Näiteks, kui infosüsteemil on eraldi turvakontekstidega liidesed ametnikule ja kodanikule, peab infosüsteem olema jagatav kaheks eraldi liidesekomponendiks ning nende mõlema poolt kasutatavaks andmebaasiks. Arendaja Nõuded infosüsteemi arhitektuurile 2.1 Infosüsteemi , andmebaas i ja kolmanda osapoole komponend id peavad olema sellised, mille eluea lõpp (EO L) pole teadaolevalt vähem kui kahe aasta pärast. Arendaja loodud lahenduse dokumentatsioonis (nt detailanalüüs vms) peab olema välja toodud kasutatavate komponentide nimetused ja versioonid. Versiooni eluea lõppu ei loeta võrdseks terve komponendi eluea lõpuks, st versiooni tugi võib aeguda, kui uus versioon on välja lastud. Arendaja 2.2 Tulevase ja olemasolevate infosüsteemide platvormid (rakendusserver, andmebaas, kolmanda osapoole komponendid) ja topoloogia peab olema enne reaalse arend use algust TEHIK-u poolt projekti kaasatud tarkvara arhitektiga kooskõlastatud . Infos üsteemi jõudlus peab vastama kokkulepitud topoloogial eelanalüüsi ja lähteülesande käigus välja toodud jõudlusnäitajatele. Arendaja 2.3 Rakendusserver peab võimaldama töötamist andmebaasiserverist eraldi serveril. - Arendaja 2.4 Rakendusserver peab olema vajadusel klasterdatav aktiivklastris (kasutajasessioon ei tohi olla klastri node põhine). - Arendaja 2.5 Infosüsteemi peab saama ilma ümberprogrammeerimata liigutada erinevate domeenide ja domeeni saitide vahel Lahendus se ei tohi olla sisse kompileeritud absoluutseid UR Li -sid Arendaja 2.6 Infosüsteemi liidesed peavad olema tõrkekindlad kolmandate osapoolte süsteemide vigade suhtes Väliste liidestatud süsteemide tõrke korral ei tohi süsteem hanguda, vaid väljastama mõistliku (võimalikult lühikese) aja jooksul ajakohase veateate. Võimalusel tuleb kasutada asünkroonseid liideseid. Arendaja 2.7 Infosüsteemi konfiguratsiooniparameetrid tuleb ühte kohta kokku tuua nii, et nende muutmisel ei peaks r infosüsteemi uuesti kokku kompileerima (nt ühte tekstipõhisesse konfiguratsioonifaili, andmebaasi tabelisse). Infosüsteem peab neid sealt ka kasutama (mitte kopeerima parameetreid käivitamisel kolmandatesse kohtadesse), logimise seaded võivad olla infosüsteemi konfiguratsioonifailist eraldi ühes lisakonfiguratsioonifailis (näit Log4net). Samuti on väga soovitatav eraldi konfiguratsioonifailis hoida arendaja ja administraatori vastutusala parameetrid. Infosüsteem peab olema seadistatav konfiguratsiooniparameetrite(de) abil. Konfiguratsioonifailiks ei saa lugeda faili, kus hoitakse lisaks konfiguratsioonile ka muud programmikoodi. Parameetrid, mida võib olla vajadus muuta Infosüsteemi töökäigus, võib talletada andmebaasis, kuid see peab olema kokkulepitud TEHIK-u poolt projekti kaasatud tarkvara arhitektiga . Arendaja 2.8 Infosüsteemi kompileerimine, saidi taaskäivitus, konfiguratsiooni muutmine vms peaks toimuma mõistliku aja jooksul. Maksimaalselt 30 sek. Kui Infosüsteem vajab indekseeritud sisu ja see pole kättesaadav, siis peab infosüsteem väljastama selle kohta selge teate Arendaja 2.9 Infosüsteem peab kasutama 64-bitist arvutiarhitektuuri kui ei ole kokku lepitud teisiti. Suund on 64-bitiste infosüsteemi op süsteemide kasutamise poole. Arendaja 2.10 Kõik andmed, andmebaasid, SQL skriptid ja infosüsteem peavad kasutama UTF-8 kodeeringut. Alternatiivina on kokkuleppel tellijaga lubatud ka UTF-16. - Arendaja 2.11 Infosüsteemi loomisel tuleb eelistada objektorienteeritud mudelit Eelistuse eiramine tuleb kooskõlastada projektijuhiga enne arendamise alustamist Arendaja 2.12 Ühest andmetabelist teise viitamisel tuleb kasutada väliseid võtmeid ( Foreign key ). - Arendaja 2.13 Kõik välised võtmed ( Foreign Key ) peavad olema indekseeritud. Andmebaasis peab kasutama indekseid või muid meetmeid, et nõuded infosüsteemi jõudlusele oleksid täidetud ka tulevikus. (1, 3, 5 või 10 aasta pärast – vastavalt planeeritud kasutusajale). Arendaja 2.14 Tuleb kasutada päringumuutujaid ( Parameter Binding ). SQL päringute väljakutsumisel väljastpoolt andmebaasi, peab kasutama päringumuutujaid, et vältida SQL vahemälu fragmentseerumist ( When calling SQL code from outside the database, Parameter Binding should be used to prevent SQL cache fragmentation ) Arendaja 2.15 Kõigis andmebaasi tabelites peab olema defineeritud üks primaarvõti. Andmebaasi objektide nimetused peavad olema sisulised ja andma aimu nende otstarbest. Kasutada vastava andmebaasisüsteemi nimetamise parimaid praktikaid. Arendaja 2.16 Andmebaasis defineeritakse üldjuhul kaks või enam kasutajat: Infosüsteemi peakasutaja, kellena luuakse objektid ja skeemid. Infosüsteemi piiratud õigustega kasutaja, kellena pöördub rakendusserver/rakendus. Objektide loomiseks vajalikud õigused ja ressursid on loetletud infosüsteemi dokumentatsioonis. Need õigused, mis on vajalikud ainult infosüsteemi baasi loomiseks, on eraldi välja toodud ja tuleb peale installi ära võtta. Arendaja 2.17 Failide hoidmise asukoht lepitakse igakord kokku. Kuid failid ja failide indeks peavad olema replikeeritavad teise serveriruumi. Failide hoidmine klassikalises andmebaasis on kulukas ja seab kõrgendatud nõudmised ja piirangud andmebaasiserveritele. Lahenduse dokumentatsioonis tuleb ära tuua failide hoidmise asukoht. Arendaja 2.18 Peab olema minimiseeritud vajadus, et haldur teeb haldustoiminguid otse baasis. St infosüsteemil peab olema haldusliides, mille kaudu infosüsteemi haldur saab teha tavapäraseid haldustoiminguid. Halduri haldustoimingud lepitakse tellijaga kokku detailanalüüsi käigus. Arendaja 2.19 Infosüsteem peab olema võimeline kasutama keskkonnamuutujaid (serverinimi, kuu, päev jne). Näiteks logifailides. Arendaja 2.20 Andmebaas peab toetama nii külm- kui ka kuumvaru (peegeldamist) teise serviruumi. Ei tohi kasutada teenuseid, mis välistav ad andmebaasi peegeldamist (nt failstream ). Arendaja 2.21 Sorteerimisreeglistik peab olema Eesti tähestikule vastav. Tõusutundlikkus peab olema välja lülitatud. Accent peab olema sisse lülitatud. Näiteks MS SQL puhul Estonian_CI_AS. Arendaja 2.22 Kui infosüsteemid saadavad e-kirju, peavad nad kasutama välist e-mailiserverit. Kirja saatmisel peab infosüsteemi veenduma, et e-mailiserver võttis meili vastu. E-kirjade vormindamine peab järgima interneti standardeid (RFC 5322). Saatja ja adressaadid, pealkiri ja sisu ei tohi olla infosüsteemi kodeeritud, vaid on muudetavad konfiguratsioonifaili kaudu. Genereeritud kirjade puhul peab tagama kirjade jälitatavuse (näiteks lisada X-päise kodeeritud kirje, milles on kirjeldatud, mis protsess/skriptifail/kasutaja kirja genereeris jms abistav info). Arendaja 2.23 Konfiguratsiooniparameetrite nimed peavad olema sisulised. Kui see ei ole võimalik, siis peab kõrval olema seletus. Näiteks : X-tee Turvaserver, mitte XTTS või viitenumber, mitte vk_seb jne Arendaja 2.24 Infosüsteemides on eessüsteemid ( front end ; presentatsiooni kiht) ja tagasüsteemid ( back end ; äriloogika kiht) arhitektuuriliselt selgelt lahutatud. Koostöövõime raamistik 2011. Punkt 3.1. Tagasüsteemide ülesanneteks on andmete haldamine ja võrguteenuste pakkumine. Tagasüsteemid ei tegele lõppkasutaja autentimise ja autoriseerimisega. Lõppkasutaja autoriseerimise tagavad eessüsteemid. Välise süsteemi tõrge tohib mõjutada ainult sellest otseselt sõltuvate kasutuslugude toimimist . Välise süsteemi taastumisel peab süs teem olema suuteline oma tööd jä tkama taaskäivitamata. Arendaja 2.25 Konfiguratsioonifailid peavad olema vastavalt rakendusserveri tüübile vaikimisi kaitstud failid Näiteks IIS: *.config , *.resources Apache: *.conf, .htaccess. Arendaja peab välja tooma konfifailide listi, kui neid on mitu. Arendaja 2.26 Infosüsteemi failid, mida kasutaja näha ei tohi, peavad olema vaikimisi kaitstud kaustades. Näiteks: IIS: Bin,App_Code, App_Data, App_Browsers, App_GlobalResources, App_LocalResources, App_Themes, App_WebReferences Arendaja 2.27 Konfiguratsiooniparameetrite taaskasutus. Erinevaid sama sisuga parameetreid ei tohi konfiguratsioonis eksisteerida. Kõiki parameetreid tuleks konfiguratsioonis kirjeldada vaid korra, tuleb vältida korduseid ja kasutada muutujaid vajalikes kohtades . Arendaja 2.28 Kõik Infosüsteemi liidesed peavad olema võimelised t öötama kõrgkäidelda valt. Infosüsteemides tohib kasutada vaid masinapõhiseid teenuseid, mis lubavad kõrgkäideldavaid (klaster) lahendusi. Kõrgkäideldav lahendus on selline, mida saab samaaegselt käitada erinevates masinates. Arendaja 2.29 Keskkonnapõhised muutujad peavad olema konfiguratsioonifailist seadistatavad. Näiteks WSDL ei tohi sisaldada viiteid arendusserveritele. Arendaja 2.30 Infosüsteemis peab olema võimalik piirata ebaõnnestunud logimisi ajaühiku kohta (mobiil-ID, ID-kaart, , Smart-ID ) ühelt IP-aadressilt. Eelistama peaks IP-aadressipõhist blokeeringut. Erandina tellijaga kokkuleppel võib kasutada captchat või konto lukustamist. Blokeeringute ajavahemikku ja logimiskatsete arvu peab saama konfiguratsioonifailist muuta. Arendaja 2.31 Infosüsteemi äriloogika tuleb realiseerida andmebaasist eraldi sõltumatus rakenduskihis. Andmebaas ei tohi sisaldada äriloogikat, mis muudab andmetabelites olevaid/sinna kirjutatavaid andmeid, va trigerid, mis tekitavad logi. Arendaja 2.3 2 Infosüsteem eeldab eraldi kasutajate, rollide ja õiguste registri pidamist ja infosüsteem peab kasutama Riigi autentimis teenust TARA TARA info: https://www.ria.ee/et/riigi-infosusteem/eid/partnerile.html#tara Arendaja 2.33 Uniform resource identifier (URI) pikkus ei tohi ületada ühegi IS poolt toetatava brauseri maksimaalset lubatud väärtust. Harilikult on piiriks 2000 tähemärki, kuid iga IS puhul tuleb seda eraldi järele uurida sõltuvalt IS komponentidest. Asjakohased viited: RFC 3986 ja RFC 7239. Arendaja 2.34 SOAP teenuseid pakkuva infosüsteemi WSDL peab olema üles ehitatud nii, et see toetaks teenuste versioneerimist. Näiteks: Alajaotis definitions/types/schema: * complexType defineerimisel tuleb sellele lisada any element . Arendaja 2.3 5 Infosüsteemis peab olema võimeline töötama koormusjaoturitega varustatud taristul. Vajadusel võimaldama SSL offload -i . Arendaja 2.36 Sidusinfosüsteemide mitte kättesaadavus ei tohi segada infosüsteemi töötamist. Sidusinfosüsteemidega andmevahetamisel tekkinud vead logitakse ja kasutajat hoiatatakse. Sidussüsteemi tõrge tohib mõjutada ainult sellest otseselt sõltuvate kasutuslugude toimimist. Sidussüsteemi taastumisel peab süsteem olema suuteline oma tööd j ä tkama taaskäivitamata. Arendaja 2. 37 Kui ajastatult käivitatav taustatöö, ei ole mõeldud käima paralleelselt, peab selles olema realiseeritud kontrollmehhanism, mis tagab, et sama taustatööd ei ole võimalik käivitada uuesti enne, kui eelmisena käivitatud instants on oma töö lõpetanud. - Arendaja 2.38 Ühe tarkvarakomponendi raames ei tohi sama parameetri seadistamine toimuda rohkem kui ühes kohas. Näiteks kui infosüsteemi komponent pöördub andmebaasi või veebiteenuse poole, siis selle pöördumise parameetrid peavad olema muudetavad vaid ühes kohas. Arendaja 2.39 Infosüsteemi ühenduste (s.h. andmebaasi ja sidusinfosüsteemide ühendused) realiseerimisel tuleb kasutada ühenduste puulimist ( connection pooling ). Implementeeritud peab olema vähemalt maksimaalsete ühenduste arvu piirang ja päringu aegumise aeg ( request timeout ) . Infosüsteemi ühenduste tõrge tohib mõjutada ainult sellest otseselt sõltuvate kasutuslugude toimimist. Ühenduste taastumisel peab infosüsteem olema suuteline oma tööd j ä tkama taaskäivitamata. Tekkinud vead logitakse ja kasutajat hoiatatakse. Arendaja 2.40 Infosüsteemi uuendustega kaasnevad andmebaasi muudatused tuleb automatiseerida. Näiteks Liquibase või Flyway . Arendaja Turvalisuse tagamisega seotud nõuded 3.1 Sisemised infosüsteemi liidese autentimised pea vad olema lahendatud TARA-ga ja rolli valikul peab arvestama kasutaja kontoga seotud piira n gutega Active directory -s . Näiteks: konto on lukus, parool aegunud, konto aegunud, paroolipoliitika jne. Arendaja 3.2 Kliendi ja serveri vahel peab autenditud kasutajasessioonide korral olema sessioon krüpteeritud HTTPS-protokolli kasutades. - Arendaja 3.3 SSL veebiserver peab kasutama turvalisi ja SSL/TLS versioone ja šifrikomplekte https://www.ssllabs.com/ssltest/ Arendaja 3.4 Infosüsteem tohib kasutada vaid sessiooni küpsiseid. Muude küpsiste kasutamine on keelatud. - Arendaja 3.5 Kui andmebaasis olevate andmete ISKE tervikluse turvaosaklass on 2 või kõrgem, siis tuleb kõik klass 2 infot sisaldavad andmebaasi kirjed/tabelid versioneerida. St kõik andmemuudatused peavad baasis säilima. Andmete muutmisel andmeid ei kustutata, vaid tehakse uus kirje uute andmetega. Vana muudetakse kehtetuks. Iga uus kirje peab sisaldama järgmist informatsiooni: *viide kirjele, mille ta kehtetuks muutis (kui on) *kasutaja, kes kirje lõi *kirje loomise aeg *sessiooni-ID (kui on olemas). Iga kehtetuks tunnistatud kirje peab omama järgmist informatsiooni: *kasutaja, kes kirje kehtetuks tunnistas *kirje kehtetuks tunnistamise aeg. Arendaja 3.6 Kui infosüsteemi poolt töödeldavate andmete konfidentsiaalsuse turvaosaklass on 2 või kõrgem, peab infosüsteemiga kaasas olema lahendus, mis suudab toota toodangu andmetest testandmed, mis ei sisalda konfidentsiaalset informatsiooni. Testandmed peavad säilitama kõik toodangu andmete omadused (pikkuse, tüübi) ja omavahelised suhted. Arendaja 3.7 Andmebaasis olevate infosüsteemi kontod peavad omama ainult minimaalselt infosüsteemi tööks vajalikke õiguseid. Ei resource, dba, ANY ega muud sellist. Nõude täitmiseks vajalikud vahendid (skriptid) peavad kuuluma infosüsteemi juurde ja nende sisu peab olema kontrollitav. Kontodele vajalikud õigused peavad olema kirjeldatud infosüsteemi installijuhendis. Arendaja 3.8 Infosüsteemi ja andmetele tohib olla ligipääs vaid dokumenteeritud ja tellimuses kirjeldatud teid mööda ning dokumenteeritud autentimisprotseduure kasutades. St infosüsteemides ega andmebaasides ei tohi olla ligipääsemiseks teisi võimalusi. Arendaja 3.9 Infosüsteemis ei tohi teostada X-tee päringut otse kasutajaarvutist. Kasutajaarvutitest otse X -tee päringute tegemine on arvutivõrgu tasemel kinni. Rakendusserverist tehtavate päringute teostamiseks on mõistlik kasutada vahekomponenti rakendusserveri ja X -tee vahel. Arendaja 3.10 Veebipõhised välise veebilehega infosüsteemid , mis on keskmise või kõrgema ISKE turbeastmega, peavad kasutama vahendeid kaitsmaks infosüsteemi lubamatute päringute eest. IIS puhul peab kasutama näiteks URL scan, apache puhul modsecurity või vastavat tööriista. Lubatud päringud on kõik päringud, mis ei ole detailanalüüsi käigus vastavalt kasutusjuhtudele ette nähtud. Kasutama peab whitelisting põhimõtet, mitte blacklisting . Arendaja 3.11 Kui infosüsteemi mõni ISKE turvaosaklass on 2 või kõrgem, peab infosüsteemis sisenemisel näitama pä rast õnnestunud siss logimist eelmise õnnestunud sisse logimise aega. Kui on toimunud ebaõnnestunud sisse logimise katseid, siis peab kuvama ka, millal need toimusid, mitu neid oli ja mis IP-aadressilt pöörduti. Kasutaja peab saama soovi korral veenduda, kas keegi pole tema nime all vahepeal sisse loginud. Riikliku autentim ismooduli TARA kasutamise puhul tuleb talletada info ka ebaõnnestunud autentimise puhul. Arendaja 3.12 Kõigil infosüsteemidel peab olema konfigureeritav kasutajasessiooni aegumise aeg. Aeg peab olema muudetav koos teiste konfiguratsiooniparameetritega. Arendaja 3.13 Krüpteerimise ja/või räside arvutamise korral tuleb kasutada tugevaid algoritme. Järgida tuleb uusimat RIA kodulehel avaldatud krüptograafiliste algoritmide kasutusvaldkondade ja elutsükli uuringut. Lubatud on: AES-256, Blowfish-256, RSA-2048, SHA-2, RIPEMD-160 või tugevamaid. Lahenduses tuleb välja tuua kõik krüptoalgoritmid, võtmepikkused ja kasutuskohad. Arendaja 3.14 Autenditud sessiooni tunnust ei tohi ainult lihtsa küpsisega lahendada. Sessiooni ei tohi olla võimalik üle võtta sessioonitunnuse kopeerimisega ühest arvutist teise. Arendaja 3.15 Tagada tuleb rollide lahusus. Halduritel ei tohi olla võimalik muuta ega näha infosüsteemi konfiguratsiooni. Administraatoril, halduril ja tavakasutajal on erinevad tööülesanded. Rollide/õiguste kirjeldus peab lähtuma detailanalüüsist ja kasutusjuhtudest. Arendaja 3.16 Kui kasutajaid hallatakse ka infosüsteemis , tuleb sisse logimisel kõigepealt kontrollida kasutaja olemasolu infosüsteemis ja alles siis pöörduda AD poole. Eesmärk vähendada AD koormust. Arendaja 3.17 Arendus peab olema orienteeritud toodangukeskkonnas toimimiseks. Toodangukeskkonna infosüsteem ei tohi sisaldada osiseid, mis toodangu keskkonnas on ebavajalikud või segavad (näiteks kasutuseta funktsionaalsus ja komponendid, mõeldud testimiseks testkeskkonnas, arendusabiks arenduskeskkonnas jne). Arendaja 3.18 Infosüsteemis ei tohi lubada ühe kasutajaga mitut samaaegset sessiooni. Juhul kui lähteülesanne spetsiaalselt ei ütle teisiti. Arendaja 3.19 Veebirakendus ei tohi jätta sulgemisel kasutaja tööjaama maha ajutisi faile. Paksu kliendi korral ei tohi infosüsteemi kasutaja tööjaama jätta maha krüpteerimata kujul ajutisi faile, mis sisaldavad või võivad sisaldada konfidentsiaalse või kõrget terviklust nõudvat informatsiooni. Kui paks klient kasutab ajutisi faile, tuleb tagada nende perioodiline kustutamine tagamaks, et ei koormata liigselt kasutaja arvutit. Nõude eesmärk on tagada, et infosüsteemi sulgemisel ei jääks kasutaja arvutisse maha informatsiooni, mida sinna jääda ei tohiks, sh pääsuandmeid, isikuandmeid, andmekogu sisulisi andmeid jms Arendaja 3.20 Infosüsteem ja selle komponendid peavad võimaldama kasutada keskkondade lahusust Arendaja arendab arenduskeskkonnas ja annab tarne üle tellijale paigalduspakkidena. Tellija paigaldab selle testkeskkonda ja testib ning seejärel paigaldab tarne toodangu keskkonda. Reaalseid andmekogu andmeid tohib töödelda üksnes toodangu keskkonnas. Kokkuleppel tellijaga võib antud protsess erineda kirjeldatust mille vajadus tuleneb näiteks konteinerlahenduse kasutamisele võtul. Arendaja 3.21 Infosüsteemis peab võimaldama hõlpsalt välja vahetada aegunud ja ebaturvalise krüptoalgoritmi. Krüptograafiat kasutav rakenduskood ei tohi nimeliselt välja kutsuda krüptograafilisi algoritme, vaid peaksid seda tegema vahendavate vaheteekide kaudu üldiste funktsioonide järgi (nt krüpteerimine, dekrüpteerimine, signeerimine, signatuuri verifitseerimine jne). Dokumentatsioon peab kajastama üldist kirjeldust, kuidas vajadusel ebaturvaline krüptoalgoritm välja vahetada. Arendaja 3.22 Infosüsteemi andmebaasi krüpteerimisega seotud andmeväljad peavad olema muudetava pikkusega. Andmebaasides kasutatavad krüpteerimisfunktsioonidest tingitud lisaväljad peaksid olema muudetava pikkusega, et formaati muutmata saaks kasutada teistsuguste parameetritega krüpteerimisalgoritme. Arendaja Logimine, debuggimine , testimine 4.1 Infosüsteemil peab olema masinloetav testleht (JSON, XML). Testlehe kättesaadavus erinevatest arvutivõrkudest peab olema konfigureeritav. Testleht peab uuendama ennast lehe pärimisel. Testleht peab sisaldama custom built infosüsteemi versiooni numbrit, standardsed komponendid (veebiserver, andmebaas, CMS'id jms) ei tohi oma versioone reeta. Samuti peab testlehel olema infot infosüsteemi (vajadusel tema erinevate osade) ja tema kõigi väliste liideste staatuse kohta (töötab, ei tööta). Infosüsteemi , andmebaasi ja liideste töökorda kontrollitakse testpäringute teel, mis tuleb tellijaga kokku leppida eelanalüüsi käigus. Testleht peab oma konfiguratsiooni võtma infosüsteemi üldisest konfiguratsioonist (baasistring, välised ühendused). Arendaja 4.2 Infosüsteemi kõik üleantavad versioonid peavad enne tellijale üle andmist olema testitud Testitulemused tuleb edastada tellijale koos infosüsteemi üleandmisega . Vaata lisaks nõuet 4.23 ja 4. 24 . Arendaja 4.3 Infosüsteem peab logima kasutaja edukat ja ebaedukat autentimist ja sessiooni lõpetamist, kasutaja IP ja autentimismeetodit (ID-kaart, mobiil-ID vms), eduka autendi puhul tuleks logida ka kasutaja isikukood ja mobiil-ID ning Smart-ID puhul telefoninumber Logima peab ka autentimise ebaõnnestumise koos põhjusega (vale parool, aegunud konto jne). Logida tuleks IP-aadress, meetod ja kui võimalik kasutajatunnus (mobiil-ID puhul telefoni number, ID-kaardi puhul isikukood). Kui infosüsteem kasutab kasutajate autentimiseks TARA , siis leppida projektijuhiga eraldi kokku autentimise detailsus ehk mis kajastatakse TARA-s ja mis infosüsteemis . Arendaja 4.4 Erinevate logifailide kirjeid peab olema võimalik seotud komponentide logidega loogiliselt kokku viia. Tegevuste sidumiseks peab olema võimalik logikirjeid siduda ühise välja abil. Selleks ei sobi kellaaeg ega IP. Sobib näiteks unikaalne ID, mis ei tohi olla sessiooni ID, sest seda saaks logist välja lugeda ja rünnakuks ära kasutada. Võib olla ka sessiooni ID räsi Arendaja 4.5 Infosüsteem peab suutma logida kõiki X-tee teenuste kaudu liikuvaid andmeid. Peab olema võimalus logimist sisse-välja lülitada. Vajalik eelkõige silumiseks ja toodangu keskkonna probleemide lahendamiseks. Arendaja 4.6 Kui infosüsteemi ISKE konfidentsiaalsus turvaosaklass on 2 või kõrgem, peab infosüsteem logima kõiki konfidentsiaalsus klassiga 2 või kõrgemate andmete loomist, muutmist (sh kustutamist) ja vaatamist. Andmetöötlust peab olema võimalik kokku viia konkreetse kasutajaga ning sessiooniinfoga. Isikuandmete kaitse seadus §25 lg2 p3: (Isikuandmete töötleja on kohustatud) ära hoidma isikuandmete omavolilist salvestamist, muutmist ja kustutamist ning tagama, et tagantjärele oleks võimalik kindlaks teha, millal, kelle poolt ja milliseid isikuandmeid salvestati, muudeti või kustutati või millal, kelle poolt ja millistele isikuandmetele andmetöö tlussüsteemis juurdepääs saadi. Arendaja 4.7 Kui infosüsteemi ISKE tervikluse turvaosaklass on 2 või kõrgem peab infosüsteem logima kõiki tervikluse klassiga 2 andmete loomist ja muutmist (sh kustutamist). Andmetöötlust peab olema võimalik kokku viia konkreetse kasutajaga ning sessiooniinfoga. Isikuandmete kaitse seadus §25 lg2 p3:(Isikuandmete töötleja on kohustatud) ära hoidma isikuandmete omavolilist salvestamist, muutmist ja kustutamist ning tagama, et tagantjärele oleks võimalik kindlaks teha, millal, kelle poolt ja milliseid isikuandmeid salvestati, muudeti või kustutati või millal, kelle poolt ja millistele isikuandmetele andmetöötlussüsteemis juurdepääs saadi; Arendaja 4.8 Logimiseks tuleb kasutada standardseid komponente kogu logiahela ulatuses. Näiteks java-s log4j/logback ... , transpordiks syslog, logi formaadiks JSON või CSV või tabeldus-eraldus. Failid peavad olema loetavad tekstilisel kujul. Logid peavad olema kujul, et neid saaks töödelda masinloetavalt ja inimloetavalt. Arendaja 4. 9 Andmete loomise/vaatamise/muutmise/kustutamise tegevused peavad olema kajastatud logides . Logikirjes peab sisalduma piisavalt informatsiooni, et vastata küsimustele kes, mida, kus, kust, millal, kuidas ja tulemus. Arendaja 4.10 Logid peavad olema jaotatud loogiliselt. Seansilogi - info sisselogimiste, väljalogimiste ja seansi aegumiste kohta. Vigased sisselogimise katsed. Info õiguste suurendamise kohta. Peab olema logitud ka tühja või puuduvate parameetritega logimise katsed. Tegevuslogi - kogu informatsioon kasutajate tegevuste kohta koos tegevuse tüübi, seansi parameetrite (korreleerimaks seansi- ja tegevuslogi) ja kasutaja poolt esitatud sisendparameetritega (sh. väliste ressursside kasutamise kohta). Logida tuleb nii õnnestunud kui ka ebaõnnestunud tegevusi. Tehniline logi - rakendusserveri poolt loodud logi Vealogi - erinevate veaolukordade info Silumislogi - arendajate jaoks vajalik debug info Arendaja 4.11 Kui parameetri väärtus on tühi, tuleb see logis märkida asendusväärtuse g a . Näiteks NULL Arendaja 4.12 Logis tuleb kõik mitte kuvatavad ( non-printable ) sümbolid kodeerida . N äiteks reavahetused -> \n, non-printable sümbolid - 0x00..0x1f, 0x7f..0xff . Arendaja 4.13 Logides peab olema maksimaalselt üks sündmus ühel real. Mitme realiste sündmuste puhul kasutada kodeerimist või JSON formaati. Mitme realiste sündmused võivad olla tehnilises-, vea- või silumislogis kui rakendusserver ei oska seda kodeerida . Arendaja 4.14 Ühe ja sama sündmuse väljad peavad olema erinevatel logikirjetel samas järjekorras - Arendaja 4.15 Logida tuleb päringud mille vastus on puhverdatud . - Arendaja 4.16 Logimine peab olema optimeeritud. Informatsiooni dubleerimist logides tuleb vältida kui ei ole nõutud teisiti. Arendaja 4.17 Infosüsteemiga peab olema kaasas skript jõudlustestide tegemiseks. Jõudlustestide täpne kirjeldus tuleb kokku leppida detailanalüüsi käigus. Arendaja peab koos Infosüsteemiga tarnima skripti ja vajalikud tarkvaralised vahendid kokkulepitud jõudlustestide läbiviimiseks. Jõudlustestide läbiviimine ei tohi nõuda tellijalt omapoolset tarkvara arendamist, skriptide kirjutamist või litsentside ostmist. Arendaja 4.18 Infosüsteem peab logima kõiki infosüsteemis tekkivaid tehnilisi vigu. Logi sisaldab minimaalselt vea tekkimise aega, veakoodi, veakirjeldust ( stack trace, traceback vms), võimalusel kasutaja andmeid, HTTP-, GET- ja POST-parameetrid ja nende väärtusi. Logimise detailsusrežiimi ( info, warning, errog, debug ) peab saama muuta. Arendaja 4.19 Infosüsteemi funktsionaalsuse kirjeldusega tuleb luua ka logimise dokumentatsioon ja loginäidised. Koos funktsionaalsuse arendamisega tuleb luua ka loodava funktsionaalsuse logimine ja selle dokumentatsioon Mida logitakse, kuidas sündmused on logifailidesse jagatud, logiridade näited . Arendaja 4.20 Logimisparameetreid peab saama muuta infosüsteemi taaskäivitamata. Näiteks log4j konfiguratsiooni failis " monitoring-interval ". Arendaja 4.21 Arhitektuuriline lahendus peab olema 75% ulatuses kaetud komponenditestidega ( unit test ). - Arendaja 4.22 Arhitektuuriline lahendus peab olema 50% ulatuses kaetud vastuvõtutestidega. - Arendaja Nõuded infosüsteemi lähtekoodile 5.1 Lähtekoodi kommentaarid peavad kõigis lahenduse kihtides ( infosüsteemi enda kood, andmebaas, jne) olema kirjutatud eelistatult inglise keeles, vähem eelistatud alternatiivina eesti keeles. NB! Nõuet ei arvestata arendustarkvara poolt automaatselt genereeritavate koodilõikude puhul – neid ei ole vaja tõlkida. Samuti ei rakendata nõuet kolmandate osapoolte poolt toodetud lähtekoodile – nt igasugu erinevad lahtise koodiga koodilõigud jms. Kui on tegu olemasoleva süsteemi edasiarendusega, siis peaks kommentaarides kasutama eelnevalt kasutatud keelt. Arendaja 5.2 Lähtekoodi kommentaarid peavad olema selged, arusaadavad ja sisuliselt kirjeldama vastavat koodi, mille juures nad on ning moodustama vähemalt 20% koodi mahust. Infosüsteemi kood peab olema piisavalt hästi kommenteeritud, et erialast haridust omav tarkvaraarendaja on võimeline süsteemile jätkuarendusi teostama. Arendaja 5.3 Muutujate, tüüpide ja funktsioonide nimed peavad olema sisulised ja andma aimu nende otstarbest. Parim praktika Arendaja 5.4 Koodis kasutatavad konstandid ja lühendid tuleb kirjutada suurte tähtedega. Parim praktika. Nt Identifikaator --> ID Arendaja 5.5 Koodis kasutatavaid konstante ei tohi selle kasutamise koha s väärtusena hardcodeda – need tuleb defineerida muutujatena ja kasutada läbi nende. - Arendaja 5.6 Koodis defineeritud andmetüübid peavad olema nimetava käände ainsuses. Kõik andmemassiivid tuleb nimetada nimetava mitmuses (st igasugu collectionid, arrayd , jms). N:Isik; Menetlus; jne. Andmebaaside struktuurikirjeldustes/andmemudelis ei tohi kasutada täpitähti. Arendaja 5.7 Andmetabelites sisalduvad võõrvõtmed peavad nime järgi seostuma tabeli ja väljaga millele need viitavad. Kasutada tuleb konkreetse andmebaasisüsteemi nimetamise parimaid praktikaid. Nt kui on tegu tabelitega ’Isikud’ ja ’Autod’, siis seos ’isiku autod’ oleks: Isikud.ID=Autod.Isik_ID Arendaja 5.8 Andmebaasi väljade pikkused tuleb kirjeldada sümbolites, mitte baitides. Selle asemel, et eraldada väljale x baiti, tuleb eraldada x tähemärki. ( Instead of allocating x bytes of storage for the field, x chars of storage must be allocated ). Arendaja 5.9 Kui kokku pole lepitud teisiti, siis JAVA rakenduse kood peab olema kirjutatud vastavalt "Oracle Java Code convention" dokumendile. Checkstyle ( http://checkstyle.sourceforge.net/ ) ei tohi käivitamisel järgmise konfiguratsioonifailiga väljastada ühtegi viga. Arendaja 5.10 Automaatne koodivalideerimine TEHIK-us on automaatseks koodivalideerimiseks kasutusel SonarQube ( https://www.sonarqube.org/ ). Ennem üleandmist tuleb veenduda, et koodis puuduvad: Turbedefektid Blokeerivad ja kriitilised vead Mõistlik on koodivalideerimine automatiseerida Gitlabi või Jenkinsi abil. Sõltub milline lahendus on projektis kasutusel. 5.1 1 Kasutuses mitteolev kood tuleb infosüsteemi lähtekoodist kõrvaldada. - Arendaja 5.1 2 Arendamisel kasutatakse DRY ja SOLID printsiipe http://en.wikipedia.org/wiki/Don%27t_repeat_yourself http://en.wikipedia.org/wiki/SOLID_(object-oriented_design) Arendaja 5.1 3 Üleantavas koodis ei tohi olla paroole, mida on kasutatud arenduse käigus Kehtib ka siis, kui need on välja kommenteeritud. Kõik sellised paroolid tuleb asendada fraasiga “<password>“. Arendaja 5.1 4 Infosüsteemide lähtekoodi tasemel ei tohi olla ühtegi sisse kodeeritud parameetrit, väljade nimetust, veateadet. Eelpoolmainitu haldamine toimub failis või andmebaasis. Arendaja Andmekvaliteet ja standardid 6.1 Eesti a adressiandmete sisestamisel, kuvamisel ja hoidmisel tuleb lähtuda Vabariigi Valitsuse määrusest "Aadressiandmete süsteem". Liidestatakse Maa-ameti X-tee teenusega. https://www.riigiteataja.ee/akt/103102017005?leiaKehtiv Arendaja 6.2 Infosüsteem peab võimalikult palju informatsiooni eeltäitma automaatselt (kirje sisestamise kuupäev, kasutaja nimi jne). Välja arvatud logimisvormi lahtrid autentimisel Arendaja 6.3 Tegevusalade andmete sisestamisel, kuvamisel ja hoidmisel tuleb lähtuda Vabariigi Valitsuse 10. Jaanuari 2008. a määrusest nr 11 "Klassifikaatorite süsteem" ja kasutada EMTAK infosüsteemis kehtivat klassifikaatorit. - Arendaja Kasutajaliides 7.1 Kasut ajaliidese kõik disainiotsused peavad olema kooskõlastatud tellijaga enne nende realiseerimist - Arendaja 7.2 Veebipõhine kasutajaliides peab olema kasutatav enamlevinud veebibrauseritega, sh nutiseadmetel (Android, IOS, Windows Phone) Minimaalselt Internet Explorer, Mozilla Firefox, Chrome ja Safari arenduse testimise hetkel tootja poolt toetatud versioonid. Täpsemad nõuded on välja toodud Arendaja 7.3 Infosüsteem peab kasutama SF sümboolikat. Kuna tegemist on struktuurfondide projektiga on lisaks nõutud ka SF sümboolika kasutamine . Arendaja 7.4 Infosüsteemi k asutajaliides peab olema eestikeelne. Kõik loendid , mallid ja teated nii inglise kui ka eesti keelsed. Arendaja 7.5 Lahenduse esitluskiht peab olema graafiliselt eskaleeruv ja mugavalt kasutatav kõigi enamlevinud seadmete resolutsioonidega. Toetatud peavad olema vähemalt resolutsioonid: 2560x1440, 1920x1200, 1920x1080, 1680x1050, 1600x1200, 1440x900, 1366x768, 1360x768, 1280x1024, 1280x960, 1280x800, 1280x768, 1152x864, 1024x768, 1024x600, 768x1024, 720x1280, 375x667, 360x640, 320x480. Ühegi nimetatud resolutsiooni korral ei tohi tekkida horisontaalset kerimisriba. Arendaja 7.6 Hüpikaknaid (pop-up) ei tohi kasutada. Silmas on peetud uusi veebilehitseja aknaid avavaid hüpikaknaid Arendaja 7.7 Kasutajaliideses toiminguni (põhi- ehk enamkasutatavad tegevused) navigeerimiseks peab kehtima 3 kliki printsiip, väljalogimiseks 1 kliki printsiip. Kõik infosüsteemi kasutajaliidesest tehtavad toimingud tohivad üksteisest olla maksimaalselt 3 hiirekliki kaugusel. Toimingut ei pea nende 3 klikiga tehtud saama. Väljalogimise nupp/link peab olema ühe kliki kaugusel ja arusaadavas/intuitiivses kohas. Arendaja 7.8 Kasutajaliides peab alati küsima kinnituse andmete kustutamise ja muutmise kohta kui pole kokku lepitud teisiti. - Arendaja 7.9 Infosüsteemi kasutamisel tekkinud veale peab kasutajaliides vastama kasutajale kasutajasõbraliku veateatega, mis sisaldab soovituslikult ka vea koodi. Teade peab olema kasutaja poolt lahendust kasutatavas keeles. Veateated peavad olema sellised, mis võimaldavad IT-abil võimalikult lihtsalt tuvastada vea olemuse ja asukoha. Arendaja 7.10 Kasutajaliides peab olema ilma infosüsteemi koodi muutmata tõlgitav teise keelde, v.a kui ei ole kokkulepitud teisiti. Uue keele lisamine peab olema teostatav konfiguratsiooni failist või administreerimisliidesest. Arendaja 7.11 Infosüsteemi tausta, menüüde ja teksti värvid peavad olema ilma rakenduse koodi muutmata vahetatavad. - Arendaja 7.12 Infosüsteemi kasutajaliides peab teavitama kasutajat ette sessioon aegumisest. Ette teavitamise aeg peab olema konfigureeritav. Arendaja 7.13 Kui vormile sisestatakse mahukaid andmevälju peab kasutajaliides kokku lepitud ajavahemike järel salvestama välja sisu, et sessiooni aegumisel või võrgu katkestuse korral juba sisestatud andmed ei kaoks. Kui vorm koosneb paljudest väiksest andmeväljadest (nt taotlus), siis jagatakse vorm etappideks ning salvestatakse vastava etapi lõpus. Arendaja 7.14 Sisestusvormidel andmete sisestamisel peab saama väljade vahel vastavalt äriloogikale liikuda klaviatuuri abil tabulaatoriga. - Arendaja 7.15 Interaktiivsete vormide puhul (näiteks faili üleslaadimine), ei tohiks lehe värskendamisega tegevust korrata (faili taas üles laadida, andmeid saata, avaldust esitada). - Arendaja 7.16 Kui päring võtab aega kauem kui 3 sekundit, peab kasutaja saama visuaalse teate, et info süsteem tegeleb päringu läbiviimisega. Ikoon peab muutuma liivakellaks ja/või kuvatakse teade: päringut sooritatakse või muu tellijaga kokkulepitud indikaator. Arendaja 7.17 Esilehel (sisse logimata) ja ka pärast kasutaja sisse logimist peab olema lihtne võimalus teavitada kasutajat (sisse loginud kasutaja puhul ka vastavalt tema rollile või temaga seotud ettevõtte tegevusalale) muudatustest või probleemidest. Teavitus peab olema halduri poolt lihtsalt lisatav ja olema kasutajale märgatav. Näiteks võimalikud teavituses: mingi info süsteemi osa on vigane, tuli mingi uus funktsionaalsus, vahetage oma parool, uuendage isikuandmeid jne. Arendaja 7.18 Infosüsteem peab funktsionaalse vea (näiteks kohustuslikkude väljade täitamata jätmisel) korral kasutajale kuvama kasutajasõbraliku veateate. Veateated peavad olema hallatavad. - Arendaja 7.19 Päringu vastusena kuvatud tabeli veerge on võimalik andmete/teksti tähestikulises järjekorras sorteerida. - Arendaja 7.20 Andmeväljade kohustuslikkus peab olema infosüsteemi väljadel märgitud tärniga (*). Võib olla mõni muu viis, mis on tellija poolt soovitud. Arendaja 7.21 Infosüsteemi andmeväljade mõisted peavad olema üheselt identifitseeritavad, korrektses keeles (ilma kirjavigadeta) ja vajadusel sisaldama selgitavat teksti. Abiinfo (kasutusjuhendid) peab olema kättesaadav infosüsteemi toimimise erinevatel etappidel. - Arendaja Dokumentatsioon 8.1 Kogu infosüsteemi dokumentatsioon peab olema kirjutatud eesti keeles. Erandiks võivad olla kolmanda osapoole komponentide (mis pole kirjutatud tellija jaoks) dokumentatsioon. Samuti võib erandiks olla välispooltega seotud projektid. Erandid tuleb kooskõlastada tellijaga enne dokumentatsiooni koostamist Arendaja 8.2 Infosüsteem kirjeldatakse RIHA määruse nõuete kohaselt. https://www.riigiteataja.ee/akt/12933746?leiaKehtiv#para6 Arendaja / Projektijuht / Tellija RIHA haldur 8.3 Infosüsteemi dokumentatsioon peab sisaldama tabelite-andmete-logide mahu kasvu arvestuslikku hinnangut infosüsteemi sihipärase kasutamise korral ettenähtud arvu kasutajate poolt. (MB/GB kuus/aastas). Esialgne kirjete mahu hinnang peab tulema lähteülesandest, ning täpsustuma eel ja detailanalüüsi käigus. Mahuhinnang peab sisaldama ka logide säilitamise, arhiveerimise tähtaegu. Arendaja 8.4 Iga uue versiooniga peab alati välja tooma versiooni muudatuse kirjeldused ( release notes ). Release notes peab kajastama kõiki muudatusi eelmise ja uue versiooni vahel. Arendaja 8.5 Infosüsteemi dokumentatsioon peab vastama ka dokumendis "Nõuded infosüsteemi dokumentatsioonile" kirjeldatud nõuetele Täpsemad nõuded on välja toodud Tehnilise kirjelduse Lisas 1.2.1 Nõuded infosüsteemi dokumentatsioonile. Arendaja Versioonihaldus 9.1 Kõik infosüsteemi testimiseks, koolituseks või implementeerimiseks üle antavad tarkvarapaketid peavad olema versioneeritud. Kasutama peab Tellija versioonihalduse repositooriumi. Arendajale antakse selleks õigused Tellija versioonihalduse repositooriumi, kus ta peab hoidma oma erinevaid versioone. Versioonihalduse repositooriumi juurdepääsutaotlus esitatakse Tellija kasutajatoele läbi projektijuhi . Arendaja 9.2 Arendaja peab veenduma, et teeb muudatusi aktuaalsesse koodi. Ehk paralleelse arendamise puhul võetakse igal hommikul versioonihalduse repositooriumist viimane seis koodist. - Arendaja 9.3 Paigalduspaketile koostatakse kontrollkood (checksum), mis pannakse eraldi .sum failina tarnele kaasa. Räsialgoritmiks tuleb kasutada SHA256. Linuxi käsurealt kontrollkoodi koostamiseks: $ sha256sum filename [filename2] ... > kontrollkood.sum Arendaja 9.4 Nii arendamisel kui ka hoolduslepingute korral kasutatakse Tellija veahalduse keskkonda. Arendajale antakse selleks õigused Tellija veahalduse keskkonda. Juurdepääsutaotlus esitatakse Tellija kasutajatoele läbi projektijuhi Arendaja Paigalduspaketi kooste 10.1 Tarnitava lahenduse koosseisus üle antava lähtekoodiga peavad kaasas olema kirjeldused sellest paigalduspaketi koosteks. Näiteks võib lahenduse paigalduspaketi koosteprotsess ette näha, et käivitada tuleb rida shell-käske või võivad lahenduse koosseisus olla valmis (ant, ..) koosteskriptid või mis iganes muu moodus paigalduspaketi tekitamiseks. Eelistatud on kasutada GitL abi pipeline . Arendaja 10.2 Kooste kirjelduste alusel valmiv paigalduspakett tohib sisaldada ainult minimaalse infosüsteemi käitamiseks vajamineva failikomplekti. Näiteks: kompileeritavate keelte puhul ei tohi sisaldada lähtekoodi, kui see pole vajalik infosüstemi käitamiseks. Arendaja 10.3 Kooste kirjelduste alusel valmivat paigalduspaketti peab olema võimalik liigutada erinevate masinate vahel. Näiteks ei tohi tekitada olukorda, kus infosüsteem jooksutamiseks uues serveris tuleb see tingimata just sealsamas kokku kompileerida. Arendaja 10.4 Lähtekoodi kompileerimine peab olema teostatav ka võrguühenduse puudumise korral. Kasutada tuleb tellija poolset Artifactorit. Arendaja 10.5 Andmebaasi paigalduse skriptid ei tohi olla kompileeritud. Administraator tahab veenduda skripti sisus. Arendaja Nõuded infosüsteemi dokumentatsioonile Raamlepingu tehnilise kirjelduse lisa 1. 4 Ravimiameti infosüsteemi Samtrack arendus- ja hooldustööd Dokumendid peavad vastama vähemalt alljärgnevatele tingimustele: Andmemudel (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> Andmemudel) Eeldus dokumendile: Teenuste/kasutuslugude dokumentatsioon Otstarve: Kirjeldada andmeobjekte ja nendevahelisi seoseid Sisu: Andmebaasi põhjal luua andmetabelite ja -objektide seosdiagramm. Sihtgrupp: Tellija, peakasutajad, rakenduse administraatorid Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel üleandmisel Kirjeldada andmemudelit kontseptuaalse mudelina interaktioone/seoseid jah jah Kasutaja õiguste ja tegevuste vastavustabel (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> Kasutaja õiguste ja tegevuste vastavustabel) Eeldus dokumendile: Süsteemi üldine kirjeldus Otstarve: Kirjeldada kasutaja rollide õigusi erinevates kasutuslugudes ja tegevustes Sisu: CRUD maatriks Sihtgrupp: Tellija äriprotsesse valdavad kontaktisikud, ärianalüütikud, süsteemianalüütikud, täitjast sõltumatud tarkvara hooldajad, arendajad ja edasiarendajad, testijad , arhitektid, projektijuhid. Ajakava: enne esimese arendusetapi algust enne igat arendusetap i algust igakordsel üleandmisel Nimetada kasutaja rollid jah jah Teenuste/kasutuslugude dokumentatsioon (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> Teenused ja kasutuslood) Eeldus dokumendile: Süsteemi üldine kirjeldus Otstarve: Kirjeldab detailselt üleantavaid teenuseid/kasutuslugusid. Sisu: Teenuste/kasutuslugude detailse kirjelduse sisuks on: • Infosüsteemi kasutusloo/andmevahetuse teenusepõhised nõuded (ärinõuded ja neile vastavad detailsed funktsionaalsuse nõuded); • Tehnilised parameetrid; • Veateated/Hoiatused; • Teostatavad kontrollid; • Funktsionaalsuse enda põhiprotsess ja mõned sagedami ni esinevad alternatiivsed protsessid (vastavalt vajadusele); • Üldine kirjeldus, kuidas ja kus kajastub antud teenus/kasutuslugu tervikprotsessis; • Nõudeid ja reegleid toetavad (sisu mõistmisele kaasaaitavad) pildid, diagrammid, tabelid, loendid • Andmev ahetuse teenuste kirjeldus (andmete küsimine/vastuvõtmine, turvalisus, teenuse andmestik, klassifikaatorid, xml / xsd schema ) Sihtgrupp: Tellija äriprotsesse valdavad kontaktisikud, ärianalüütikud, süsteemianalüütikud, täitjast sõltumatud tarkvara hoolda jad, arendajad ja edasiarendajad, testijad , arhitektid, projektijuhid. Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel üleandmisel Nimetada kasutuslood jah jah Arhitektuuridokument (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> Arhitektuur) Eeldus dokumendile: Süsteemi üldine kirjeldus Otstarve: Dokumendi eesmärgiks on kirjeldada loodava süsteemi üldist ehitust. Kirjeldatakse rakenduse loogilist struktuuri, näidates ära selle kihtideks jagunemise korda. Kirjeldatakse ka füüsilist arhitektuuri, antakse ülevaade kasutatavatest tehnoloogiatest ning v ahenditest. Sisu: Dokument peab rahuldama vähemalt alljärgnevaid sisunõudeid (Arhitektuuridokumendimall_v1.1): 1. topoloogia, süsteemi füüsiline arhitektuur (süsteemi komponendid andmebaasiserver, rakendusserver, meiliserver jms) 2. Nõuded arhitektuuri le (operatsioonisüsteem, andmebaasid, liidestused , rakendusserverid, raamistikud, teenused) 3. Nõuded käideldavusele (süsteemi soovituslikud näitajad komponentide kaupa, näiteks andmesidekiirused, kättesaadavus, andmemahud, protsessori kiirus, mälumaht, ko mponentide arv süsteemi osade kaupa, kettasüsteemi jõudlus jms) 4. liidesed teiste süsteemidega (x-tee, meilisüsteemid) ja sõltuvused teistest süsteemidest. Liideste kirjeldused/otstarve 5. süsteemi tehnilised (sh automaatsed) protsessid ehk töövoog – komp onentide omavahelised suhtlusstsenaariumid ja koostoimimine (näiteks, mis komponent ja millal pöördub X teenuse poole) 6. kolmandate osapoolte poolt toodetud kasutatavad tarkvarad/riistvarad, mis on vajalikud süsteemi toimimiseks Sihtgrupp: Arhitekt, administraator, turvaspetsialist Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel üleandmisel Dokumendi esialgne versioon jah Seadmete ja tarkvara kasutajakesksed juhendid (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> -> Seadmete ja tarkvara kasutajakesksed juhendid) Eeldus dokumendile: Teenuste/kasutuslugude dokumentatsioon Otstarve: Teenuse funktsionaalsuse kasutamiseks ja kasutus lugude läbimiseks vajalikud juhised Sisu: Igale esitluskihile peab olema koostatud eraldi kasutusjuhend, mis kirjeldab vastava komponendi funktsionaalsuse kasutusvoo põhiselt. Kirjeldus tarkvara ja seadmete kasutamise üldisest protsessist, protsessi olulisemate sammude kirjeldus. Koostatakse proje kti lähteanalüüsi aluseks võttes. Tarkvara kasutusjuhend on aluseks kasutajate koolitamisel. Kasutajajuhend kirjeldab kõiki kasutajate funktsionaalsusi koos tööprotsesside kirjeldusega ning ekraanipiltide vormis näidetega. Haldusliidese kasutusjuhend (peak asutaja ja rakenduse administraatori funktsionaalsus) peab olema eraldi tavakasutaja kasutusjuhendist. Esitluskihi kasutusjuhendi minimaalne ülesehitus: lühitutvustus üldine kirjeldus koos komponentidega autentimine (kui eksisteerib) komponentide detailne kirjeldus koos kõikide funktsionaalsustega Rollide kirjeldus ja õigused Sihtgrupp: Tarkvara kasutajad, peakasutaja, rakenduse administraator Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel üleandmisel jah Paigalduse ja administreerimise juhend (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> Paigalduse ja administreerimise juhend) Eeldus dokumendile: Arhitektuuridokument Süsteemi üldine kirjeldus Otstarve: Juhend on aluseks süsteemi administreerimisele Sisu: Juhend peab rahuldama vähemalt alljärgnevaid sisunõudeid: 1. süsteemi parameetrite (seadistuste) kirjeldus ning nende muutmiste mõjud ja protseduurid. Konfiguratsioonifailide kirjeldus koos asukohtadega failisüsteemis; 2. logimise realisatsiooni kirjeldused (kuhu, mida, logide struktuur 3. rutiinsete hooldusprotseduuride kirjeldus (komponentide taaskäivituse vajadus parameetrite muutmisel); 4. paigaldamise protseduurid. Juhendis kirjeldatak se iga realiseeritud osa rakendamine ( deployment ) koos spetsiifiliste seadistustega. Paigaldamise protseduurid peavad olema kirjutatud selliselt (samm sammult), et süsteemiadministraator suudab rakenduse paigaldada ilma kõrvalise abita. 4.1 Nõuded rakendus e komponentidele 4.2 Rakenduse paigaldus (Vajalik tarkvara ja konfigureerimine, rakenduse pakkimine ja paigaldamine) 4.3 Andmete alglaadimine 4.4 Varundusskript 4.5 Monitooringu kirjeldus Sihtgrupp: Peakasutaja, projektijuht, süsteemiadministraator Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel üleandmisel jah Lähtekood (sh andmebaasi struktuur) ( Kuuluvus:Lähtekoodi üleandmine lepitakse kokku Tellijapoolse projektijuhiga) Eeldus dokumendile: Arhitektuuridokument Teenuste/kasutuslugude dokumentatsioon Andmemudel Kasutaja õiguste ja tegevuste vastavustabel Prototüüp Otstarve: Lähtekood on vajalik selleks et kompileerida rakendust, ning võimaldada tulevikus rakenduse muutmist. Sisu: Lähtekood peab olema hästi struktureeritud, piisavalt dokumenteeritud ning võimalikult lihtne, et sellest saaksid aru ka teised arendajad. Lähtekood peab vastama MFNile Lähtekood peab olema pakendatud vastavalt versioonimisjuhendile . Rakenduste lähtekood p eab olema piisavalt modulaarne , et seda saaks tulevikus lihtsasti täiendada ning muuta. Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel üleandmisel Minimaalselt iga nädalal tagant uuendada versioonihalduskeskkonnas. Testide ettevalmistuse dokumentatsioon (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> Testiplaanid) Eeldus dokumendile: Teenuste/kasutuslugude dokumentatsioon Prototüüp (ainult kasutajaliidesega rakenduse puhul) Arhitektuuridokument Otstarve: Määrata kindlaks arendusetapil testitavad kasutuslood ja liidesed (sh välja tuua need, mille puhul rakendatakse koormusteste) tuue s välja nende järjekorra. Sisu: Järjestatud (võib olla ka paralleelne) nimekiri kasutuslugudest ja liidestest (vajadusel määrates nende ulatust) koos märkega, mis on koormustestiga tagatud ning millel on testandmed Sihtgrupp: Tellijapoolne projektijuht, vastuvõtutestijad Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel üleandmisel Nimetada kasutuslood, mille puhul rakendatakse koormusteste jah Testimise tulemite dokumentatsioon (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> Testimise tulemid) Eeldus dokumendile: Testide ettevalmistuse dokumentatsioon Otstarve: Anda tellijale ülevaade läbiviidud testimise tulemustest ning esitada soovitused testandmete ja dokumentatsiooni parendamiseks (ettevalmistus, paigaldus, kasutuslugude kirjeldus jne). Sisu: Teostatud arenduste testimisel saadud informatsioon (näiteks te stlood, testraport, testiplaan, testide kood jms). Peab vastama „Nõuded testimisele“ dokumendile. Dokumenteeritakse iga testimise eesmärgid (testimise maht ja ulatus), tegevused ja tulemused. Sisaldab jõudlus- ja mahutestide infot ning versiooni infot. Te ste mitteläbinud testlugudele on lisatud parandused või ülesjäänud vead. MFNi vastavustabel Sihtgrupp: Arhitekt, süsteemiadministraator, turvaspetsialist Ajakava: enne esimese arendusetapi algust enne igat arenduseta pi algust igakordsel üleandmisel jah Taasteplaani tegemise juhend (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> Taasteplaani juhend) Otstarve: Kirjeldada erisused, millega tuleb arvestada taasteplaani loomisel Sisu: Taasteplaan peab rahuldama vähemalt alljärgnevaid sisunõudeid: 1. süsteemi halvamist võimaldavad riskid ja nende esinemise võimalikkus; 2. varundamisele kuuluvate komponentide ja asukohtade loetelu (nt rakenduse konfiguratsioonifailid rakendusserverist ja andmebaas jne), nende kirjeldused ja kasutuselevõtu protseduurid; 3. süsteemi komponentide asendusvõimalused, nende alternatiivkomponentide spetsifikatsioonid Sihtgrupp: Süste emiadministraator Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel üleandmisel jah Andmekogude semantiline kirjeldus ja andmekoosseis (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> [Loomise kuupäev YYYY-MM-DD]_[ Tervise_infosüsteem_alamsüsteemi_nimi ]. owl ; [Loomise kuupäev YYYY-MM-DD]_[ Tervise_infosüsteem_alamsüsteemi_nimi ]. xmi ) Sisu: Andmekogu(de) semantiline kirjeldus masinloetaval kuju l (OWL-formaadis) ja andmekoosseis (XMI-formaadis) vastavalt RIHA määrusega kehtestatud nõuetele ning infosüsteemi ontoloogiat kirjeldav dokument. Sihtgrupp: Tellija, tellijapoolne projektijuht Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel üleandmisel Esitada viimasel etapil UML vaated (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> [ Tervise_infosüsteem_alamsüsteemi_nimi ]. eap ) Otstarve: Protsessi, kasutuslugude, süsteemi arhitektuuri vaadete kaudu muuta süsteem läbipaistvamaks ja ülevaatlikumaks Sisu: Loogiline vaade ( Logical view ) - komponendid, liidesed, rakenduskihi ja ärikihi loogika Protsessi vaade ( Process view ) – jõudlus, skaleeritavus , läbilaskevõime Rakendus vaade ( Deployment diagram ) – süsteemi topoloogia, kasutuselevõtmine, paigaldamine Sihtgrupp: Peakasutaja, projektijuht, süsteemiadministraator, arhitekt Ajakava: enne es imese arendusetapi algust enne igat arendusetapi algust igakordsel üleandmisel jah jah Üldised nõuded: Üleantav dokument peab sisaldama sisseviidud muudatusi nii, et on väljatoodud muutunud ja lisandunud osa (võrreldes viimati üleantuga ) TEHIK Versioonihalduskeskkond Juhend Anti Urm 4.08.2017 Versioon Kuupäev Muutja Kommentaar 1.0 04.08.2017 Anti Urm Esmaversioon 2.0 02.07.2018 Martin Õunap Dokumendi nime muudatus; lähtekoodihaldus --> versioonihaldus; dokumendist infosüsteemi nime kaotamine Dokumendi eesmärk Kirjeldatakse ära lahenduste arenduse käigus tekkiva lähtekoodi halduse reeglistik . Üldine kirjeldus Versioneerimistarkvara L ähtekoodi hallatakse GIT tarkvaraga. Tsentraalne versio o nihaldustarkvara asub TEHIKus aadressil https://gitlab.sotsiaalministeerium.ee/ Iga tarkvara arendaja võib teha enda versioneerimistarkvarasse koopiaid TEHIKu versioonihalduskeskkonnast . Tarkvara paigalduspakettide kokku ehitamine toimub TEHIKu versioonihalduskeskkonnast . Loodava koodi üleslükkamine ( commit ja push ) Iga koodi kinnitamine ( commit ) ja üleslükkamine ( push ), peab sisaldama endas Jira ülesannete loetelu, mida antud kinn i tami n e/üleslükkamisega lahendatakse või luuakse . Lisaks Jira ülesande numbrile, peab sisaldama ka lühidat ülevaadet teostatud muudatuse kohta. Versioonihalduse harude haldus Peamised harud TEHIKu versio o nihalduskeskkonnas on kohustuslike harudena olemas Master Develop Versioonihalduse harus origin/master hoitakse Live keskkonnas oleva tarkvara lähtekoodi seisu. Versioonihalduse harus origin/develop hoitakse arenduse keskkonnas oleva tarkvara lähtekoodi seisu. Kui lähtekood on saavutanud stabiilse seisu, et paigaldada see Live /Test/... keskkonda, siis kõik D evelop harus olevad muudatused tuleb mestida M aster harusse ning silditada vastava tarkvara versiooni numbriga. Toetavad harud Iga uue arenduse algul loob arendaja ühe alljärgnevatest versioonihalduse harudest Feature Release Hotfix Feature haru Väljavõte tehakse: Develop Mestimine tehakse: Develop Haru nime kuju: [projekti lühinimetus]-*, või Jira taski number Feature haru kasutatakse tarkvara uue funktsionaalsuse arendusteks. Release haru Väljavõte tehakse: Develop Mestimine tehakse: Develop ja Master Haru nime kuju: release-* Release harus kasutatakse tarkvara live mineku ettevalmistamiseks. Selles võib teostada nn viimase minuti tarkvara korrigeerimise tegevusi. Lisaks on veel lubatud pisikesi veaparandusi ning meta-andmete täiendusi. Peale tööde lõppu Release harus, peab Develop harus olema kogu vajalik lähte kood järgmisteks suuremateks arendusteks. Hotfix haru Väljavõte tehakse: Master Mestimine tehakse: Develop ja Master Haru nime kuju: hotfix-* Hotfix harus kasutatakse live keskkonnas oleva tarkvara vigade parandamiseks. Kasutatud materjalid: http://nvie.com/posts/a-successful-git-branching-model/ Raamlepingu tehnilise kirjelduse lisa 1.6 H ooldustööde osutamise reeglid Ravimiameti infosüsteemi Samtrack arendus- ja hooldustööd Hooldustööde osutamise reeglid on koostatud tänase parima teadmise põhjal ja sõltuvalt konkreetsest vajadusest võivad hooldustööde tellimisel t ingimused täpsustuda. T e llitavad tööd : Tegevused Tulemus 1. Infosüsteemi ja selle liideste töös probleemide tuvastamine ja lahenduste leidmine; Logide analüüs Andmebaasi andmete analüüs Nende tegevustega seotud arendustööd muudatusettepanek veapilet tagasiside kliendile nt infosüsteem käitub vastavalt analüüsile või konsultatsioon funktsionaalsuse korrektseks kasutamiseks muudetud infosüsteem 2. Vigaste andmete tuvastamine andmebaasis; Logide analüüs Andmebaasi andmete analüüs Nende tegevustega seotud arendustööd muudatusettepanek veapilet tagasiside kliendile nt infosüsteem käitub vastavalt analüüsile või konsultatsioon funktsionaalsuse korrektseks kasutamiseks muudetud infosüsteemi andmeid 4. Muud infosüsteemi ja selle liidestega seotud tööd, mis on vajalikud infosüsteemi ja selle liideste käideldavuse tagamiseks; Majutajalt ja teistelt koostööpartneritelt tulnud tähelepanekute analüüs ja n ende tegevustega seotud arendustööd muudatusettepanek tagasiside kliendile 5. Tellijat esindavate töötajate konsulteerimine rakenduse administreerimise ja andmebaasi päringute osas; Sam t rack funktsionaalsuse analüüs Andmemudeli analüüs ja n ende tegevustega seotud arendustööd muudatusettepanek tagasiside kliendile andmebaasi päring 6. Tarnete paigalduste toetamist Sam t rack test - , toodangu - ja muude s s e keskkondades se ja selle käigus tekkivate veaolukordade lahendamine. Paigalduslogide analüüsimine Majutaja küsimuste analüüs ja nende tegevustega seotud arendustööd tagasiside kliendile skript Tööde hulka ei kuulu vigade kõrvaldamine tarkvaras, kui tegemist on garan tiiliste vigadega. Garantiiga tagatud tarkvaravead kõrvaldatakse garantii korras vastavalt raamlepingu sätestatud tingimustele. Töökorraldus Täitja tagab t ööde osutamise ks valmisoleku ja omapoolse abi kuni veaolukorra kõrvaldamiseni vastavalt käesolevas dokumendis ja poolte vahel hankelepingu sõlmimisel kokku lepitud tingimustele. Tööd esitatakse tellija töödehalduse keskkonnas, milleks täna on Jira , Sam t rack hooldustööde projekti kaudu. Kõik t öödega seo nduv info dokumenteeritakse Jira -s (sh tarneteatised, juhendid, spetsifikatsioonid, testiraportid, tuvastatud vead/probleemid ja nende lahendused). Kriitilis e tööga seoses tuleb lisaks Jira kandele töö tekkimisest teada anda ka telefoni teel. Töö tulemusena muudetud lähtekood esitatakse GitLabi kaudu. Lähtekoodi muutmise dokumentatsioon esitatakse vastavalt kokku lepitud dokumenteerimise nõuetele. Täitja saab sisendi t ööde ga alustamiseks ja teostamiseks üksnes Jira pileti kaudu ja/või t ellija kontaktisikult. Tellija kontaktisik määrab J ira -s raporteeritud probleemi või tööülesande pileti tüübiks "Hooldus “ . Pärast probleemi lahendamist kirjeldab täitja Jira piletis kõik tegevused, mida ta probleemi lahendamiseks teostas. Kui t öö on täitja poolt teostatud, märgib täitja t öö olekusse " In Test " ja suunab töö t ellija määratud kontaktisikule üle vaatamiseks ja testimiseks. Tellija kontaktisik korraldab 5 tööpäeva jooksul t öö testimis e ja vastuvõtmise. Vastuvõetud t öö määratakse staatusesse „ Done “. Juhul kui t ellijal on pretensioone või vastuväiteid teostatud t ööle, määrab t ellija kontaktisik t öö staatuseks „ In Progress “ ja suunab t öö täitjale uuesti täitmiseks. Täitja peab tegema t öös parandused poolte vahel kokkulepitud aja jooksul. Kui kokkulepet ei saavutata, tuleb täitjal kõrvaldada vead t ellija poolt määratud tähtaja jooksul. Ligipääsud t ellija keskkondadele Täitja peab esitama nimekirja isikutest, kes hakkavad teostama infosüsteemi hooldustöid . Esitatud isikutele tekitatakse vajadusel vastavad ligipääs ud tööde teostamiseks vajalikesse keskkondadesse . Täitja tagab oma töötajate poolt konfidentsiaalsus kohustuse täitmise vastavalt raamlepingus toodud tingimustele. Live - keskkonna juurdepääsu d kooskõlastatakse eelnevalt t ellija kontaktisikuga. Täitja töötajad saavad Sam t rack l ive - keskkonna andmebaasidele andmete lugemise õigused jooksvalt , kui selleks tekib vajadus . Andmebaasis teostab muudatused t ellija. Kui hooldus tööde teostamise käigus on vaja andmeid andmebaasis muuta , koostab täitja andmete muutmise skriptid. Valminud skriptide käivitamise korralda b t ellija kontaktisik. Raporteeritud hooldustööde r eageerimise - ja lahendamise ajad Vea prioriteet Kirjeldus Reageerimise aeg tööpäeviti kell 9:00 – 17:00 Lahendamise aeg Ülikriitiline viga ( b locking ) Tarkvaral põhinev teenus või süsteem ei toimi ja seda ei ole võimalik kasutada, näiteks süsteem on andmed rikutud; kasutajasessioonid on katkenud; probleem mõjutab süsteemi käideldavust ja andmete terviklikkust; mõjutatud on kõik Tarkvara kasutajad; tõsine finantsmõju; Kiireim võimalik aeg, kuid mitte hiljem , kui 1 töötund 4 töötundi Kriitiline viga ( critical ) Tarkvaral põhinev teenus või süsteem ei toimi ega ole kasutatav, näiteks on andmed rikutud; esineb kasutajasessioonide ebanormaalne katkemine; probleem mõjutab süsteemi käideldavust ja andmete terviklikkust; mõjutatud on enamus Tarkvara kasutajatest; vastukaal probleemi vältimiseks praktiliselt puudub; tõsine finantsmõju; Kiireim võimalik aeg, kuid mitte hiljem kui 4 töötundi 6 töötundi Häiriv viga ( major ) Tarkvaraga seotud probleem ei sega teatavate reservatsioonide järgimisel igapäevast töötamist; mõjutatud ei ole kõik Tarkvara kasutajad; väiksema tähtsusega funktsionaalsused pole käideldavad, kasutatavad või süsteemi jõudlus on madalamal maksimaalsest nõudest; eksisteerib ajutine aktsepteeritav vastukaal probleemi vältimiseks. 3 tööpäeva 40 töötundi ehk 5 tööpäeva Pisiviga ( minor ) väikesed puudused minimaalse mõjuga Tööde kasutajatele või klientidele; kosmeetilised probleemid (ekraanikomponendid on nihkes, kuid see ei takista komponendi eesmärgipärast kasutamist); pikaajaline vastukaalu kasutamine kasutajatele vastuvõetav. 10 tööpäeva 14 tööpäeva Reageerimise aeg – maksimaalne lubatud aeg Jira-s registreeritud ja täitmiseks suunatud vea lahendamis ega alustamiseks . Kui Jira -s on viga registreeritud enne kella 14:00 (tööpäeval), siis algab kõikide prioriteetide korral reageerimise aeg raporteerimise momendist. Pärast kella 14:00 registreeritud probleemide korral algab probleemide reageerimisaja arvestus järgmise tööpäeva kella 9:00-st, v.a ülikriitilise vea puhul. Töö välisel ajal k riitiliste vigad e lahendamise valmisoleku tegevus plaan tuleb t ellija ja täitja esindajate poolt eelnevalt kokku leppida . Sellistel juhtudel t ellija teavitab täitjat vigadest kontakt telefoni teel. Tööaeg on tööpäevadel (v.a riiklikud pühad) kell 9:00 kuni kell 17:00. Lahendamise aeg – maksimaalne lubatud aeg Jira - s registreeritud ja täitmiseks suunatud vea kõrvaldamiseks . Kui hooldustöö teostamine eeltoodud tabelis märgitud lahendusaja jooksul ei ole võimalik, teavi tab täitja t ellijat töö lahendamist tähtaegselt takistavatest asjaoludest ja annab teada, millise aja jooksul on töö teostamine võimalik, mille alusel lepivad pooled kokku töö teostamise aja.