Hermetis
Технологии · Подгорица
Выглядит устойчивоСигналов риска нет
- Выручка 2025
- 216 066 €
- Прибыль 2025
- 57 673 €
- Сотрудники
- 1
- Выигранные госконтракты
- 385 650 €
11 госконтрактов от 1 заказчика с 29 нояб. 2022 г. · 11 с этим заказчиком (385 650 €)
Открытая процедура · Услуги
Контракт заключён
Поставщик: Hermetis
Технологии · Подгорица
11 госконтрактов от 1 заказчика с 29 нояб. 2022 г. · 11 с этим заказчиком (385 650 €)
PREDMET NABAVKE 1. MINISTARSTVO UNUTRAŠNJIH POSLOVA - Nabavka usluge izrade softvera za MUP CPV: 48000000, 72212110 Procijenjena vrijednost: 165289.26 EUR USLOVI UČEŠĆA 1. U postupku javne nabavke može da učestvuje samo privredni subjekat koji: 1) nije pravosnažno osuđivan i čiji izvršni direktor nije pravosnažno osuđivan za neko od krivičnih djela sa obilježjima: a) kriminalnog udruživanja; b) stvaranja kriminalne organizacije; c) davanje mita; č) primanje mita; ć) davanje mita u privrednom poslovanju; d) primanje mita u privrednom poslovanju; dž) utaja poreza i doprinosa; đ) prevare; e) terorizma; f) finansiranja terorizma; g) terorističkog udruživanja; h) učestovanja u stranim oružanim formacijama; i) pranja novca; j) trgovine ljudima; k) trgovine maloljetnim licima radi usvojenja; l) zasnivanja ropskog odnosa i prevoza lica u ropskom odnosu. 2. U postupku javne nabavke može da učestvuje samo privredni subjekat koji je izmirio sve dospjele obaveze po osnovu poreza i doprinosa za penzijsko i zdravstveno osiguranje, što se dokazuje na osnovu uvjerenja ili potvrde organa uprave nadležnog za poslove naplate poreza, odnosno nadležnog organa države u kojoj privredni subjekat ima sjedište. 3. U postupku javne nabavke može da učestvuje samo privredni subjekat koji je upisan u Centralni registar privrednih subjekata ili drugi odgovarajući registar u državi u kojoj privredni subjekat ima sjedište što se dokazuje dostavljanjem dokaza o registraciji u Centralnom registru privrednih subjekata ili drugom odgovarajućem registru, sa podacima o ovlašćenom licu privrednog subjekta. 4. Ispunjenost uslova za učešće u postupku javne nabavke dokazuje se Izjavom privrednog subjekta. 5. 60 dana od dana otvaranja ponuda. 6. Ponuđač je dužan dostaviti bezuslovnu i na prvi poziv naplativu garanciju ponude u iznosu od 2 % procijenjene vrijednosti javne nabavke, kao garanciju ostajanja u obavezi prema ponudi u periodu važenja ponude i 15 dana nakon isteka važenja ponude. Garancija ponude će se aktivirati ako ponuđač: 1) odustane od ponude u roku važenja ponude i/ili 2) odbije da zaključi ugovor o javnoj nabavci ili okvirni sporazum. 7. Za Partiju 3:Rok izvršenja 6 mjeseci i počinje da teče od dana zaključivanja Ugovora. 8. Mjesto izvršenja ugovora je adresa naručioca u Podgorici. 9. 30 dana od dana uredno dostavljene i potpisane fakture, odobrene od strane stručnog lica Službe za informacione sisteme 10. Virmanski. 11. Kontrolu kvaliteta izvršena usluge vršiće stručne službe i to: Služba za inofrmacione tehnologije Ministarstva unutrašnjih poslova i Odsjek za kriminalističko obavještajne poslove Uprave policije 12. Obaveza ponuđača je da prilikom realizacije svih funkcionalnosti, traženih ovim projektnim zadatkom, koristiti već uspostavljani model podataka i striktno poštuje realizovana programska rešenja i platforme koje su u upotrebi u MUP-u. 13. Obaveza ponuđača je da prilikom realizacije softverskog rješenja da isti integriše u postojeći informacioni sistem (IS) i da će ono koristiti platforme koje su u upotrebi u Ministarstvu kao i da poštuje uspostavljenu politiku bezbjednosti. 14. Izabrani dobavljač će svaku verziju aplikacije morati da generiše (bilduje) na razvojnom okruženju podignutom u MUP-u. Nakon generisanja aplikacije ista se prvo instalira i testira na testnom okruženju. Po uspješnom testiranju aplikacije ista se instalira na produkciono okruženje. 15. Izvorni kod (source code) kao i sva autorska prava pripadaju naručiocu posla. 16. Obaveza izabranog dobavljača je da podigne razvojno okruženja na opremi koju će obezbijediti MUP. MUP će sprovesti testiranje prihvatljivosti u skladu sa uslovima i terminima koji se definišu Ugovorom. 17. Za Partiju 3: Garantni rok je minimum 12 mjeseci i počinje da teče od dana puštanja sistema u rad, u sklopu kojeg ponuđač mora da se obaveže da će izvršiti, eventualne, izmjene u softverskim rješenjima koje mogu biti zahtijevane ako u garantnom periodu dođe do izmjena zakonske regulative i/ili se naknadno otkriju bezbjednosni nedostaci ili neispravno ponasanje sistema (bug-ovi). 18. Nakon završetka finalne razvojne faze softvera testiranje prihvatljivosti će biti izvršeno na Softveru u njegovoj cjelosti kako bi se utvrdilo da li Softver zadovoljava kriterijume prihvatljivosti i da li radi na način koji suštinski odgovara specifikacijama u Projektnom zadatku i funkcionalnoj analizi. Testiranje prihvatljivosti radi MUP u prisustvu izabranog Dobavljača. Kada se na testovima prihvatljivosti utvrdi da je razvijeni Softver u skladu sa kriterijumima prihvatljivosti i kada izabrani ponuđač dostavi neophodnu dokumentaciju razvijeni Softver je prihvaćen. 19. Za Partiju 1: Garantni rok je minimum 12 mjeseci i počinje da teče od dana puštanja sistema u rad, u sklopu kojeg ponuđač mora da se obaveže da će izvršiti, eventualne, izmjene u softverskim rješenjima koje mogu biti zahtijevane ako u garantnom periodu dođe do izmjena zakonske regulative i/ili se naknadno otkriju bezbjednosni nedostaci ili neispravno ponasanje sistema (bug-ovi). 20. Za Partiju 1:Rok izvršenja 12 mjeseci i počinje da teče od dana zaključivanja Ugovora. 21. Za Partiju 2:Rok izvršenja 12 mjeseci i počinje da teče od dana zaključivanja Ugovora. 22. Za Partiju 4:Rok izvršenja je 12 mjeseci i počinje da teče od dana zaključivanja Ugovora. 23. Za Partiju 2: Garantni rok je minimum 12 mjeseci i počinje da teče od dana puštanja sistema u rad, u sklopu kojeg ponuđač mora da se obaveže da će izvršiti, eventualne, izmjene u softverskim rješenjima koje mogu biti zahtijevane ako u garantnom periodu dođe do izmjena zakonske regulative i/ili se naknadno otkriju bezbjednosni nedostaci ili neispravno ponasanje sistema (bug-ovi). 24. Za Partiju 4: Garantni rok je minimum 12 mjeseci i počinje da teče od dana puštanja sistema u rad, u sklopu kojeg ponuđač mora da se obaveže da će izvršiti, eventualne, izmjene u softverskim rješenjima koje mogu biti zahtijevane ako u garantnom periodu dođe do izmjena zakonske regulative i/ili se naknadno otkriju bezbjednosni nedostaci ili neispravno ponasanje sistema (bug-ovi). 25. Posebni osnovi za isključenje iz postupka javne nabavke: 1) je u postupku stečaja ili likvidacije; 2) je učinio teški profesionalni propust koji dovodi u pitanje njegov integritet, u skladu sa zakonom; 3) ima utvrđenu odgovornost na osnovu odluke nadležnog organa za zaštitu konkurencije jer je zaključio sporazum ili se dogovarao sa drugim privrednim subjektima, radi narušavanja konkurencije, u periodu od tri prethodne godine do isteka roka za podnošenje prijave, odnosno ponude; 4) u periodu od tri prethodne godine do isteka roka za podnošenje prijava, odnosno ponuda ima sa tim ili drugim naručiocem raskinut ugovor o javnoj nabavci, ugovor o javno-privatnom partnerstvu ili ugovor o koncesiji ili kojem je aktivirano sredstvo finansijskog obezbjeđenja ugovora, naplaćena šteta ili druga sankcija u skladu sa zakonom, zbog značajnih i trajnih nedostataka tokom sprovođenja ključnih zahtjeva iz prethodnog ugovora o javnoj nabavci, ugovora o javno-privatnom partnerstvu ili ugovora o koncesiji; 5) je u periodu od tri prethodne godine do isteka roka za podnošenje prijava, odnosno ponuda u ranijim postupcima javnih nabavki tom naručiocu dostavio neistinite podatke koji su potrebni za provjeru ispunjenosti uslova za učešće u postupku, odnosno nepostojanje osnova za isključenje iz postupka ili nije dostavio zahtijevane dokaze. 26. Ponuđač mora dostaviti najmanje tri reference realizovane u sektoru bezbjednosti, u poslednje tri godine, koje se odnose na realizaciju softverskih rješenja koja su realizovana u .net tehnologiji i MSSQL Database i/ili Oracle Database. 27. Privredni subjekat je dužan da posjeduje minimum stručnih i kadrovskih kapaciteta koji su potrebni za izvršenje ugovora što se dokazuje dokazom o angažovanju radne snage (kopija radne knjižice, prijava za osiguranje ili ugovor o radu) sa odgovarajućim referencama koje su potrebne za izvršenje predmeta nabavke u skladu sa zakonom i to: minimum 1 angažovano stručno lice, za izvršenje predmetne nabavke, i minimum jedna referenca/potvrda (za svako angažovano stručno lice) o angažovanju na izvršenju istih ili sličnih poslova iz oblasti predmeta nabavke. KRITERIJUMI ZA IZBOR Projektni zadatak za izradu aplikacije Pretrage, izradu API za eksterne organe, kao i integraciju eksternih WEB servisa: cijena 90 bodova; kvalitet 10 bodova. Održavanje i dorada softvera za Registar boravka do 90 dana: cijena 90 bodova; kvalitet 10 bodova. Izrada aplikacije za unos zabrana za prelazak državne granice: cijena 90 bodova; kvalitet 10 bodova. Dorada aplikacije Dežurna služba: cijena 90 bodova; kvalitet 10 bodova. 1. Cijena 2. Za Partiju 1: 1. Iskustvo stručnih lica kojima će biti povjereno izvršeje predmeta nabavke........... 10 bodova Maksimalan broj bodova, po ovom parametru dodjeljuje se ponuđaču koji je dostavio najveći broj referenci/potvrda kojima se potvrđuje da su stručna lica kojima će biti povjereno izvršenje predmeta nabavke bila angažovana na izvršenju istih ili sličnih poslova iz oblasti predmeta nabavke. Pod sličnim poslovima podrazumijevaju se poslovi na projektovanju, implementaciji, održavanju i praćenju IT sistema, dok se bodovi ostalim ponuđačima, po ovom parametru, dodijeljuju proporcionalno, u odnosu na najveći broj referenci/potvrda stručnih lica kojima će biti povjereno izvršenje predmeta nabavke, po formuli: Broj referenci/potvrda stručnih lica kojima će biti povjereno izvršenje predmeta nabavke Broj bodova = ----------------------------------------------------------- x 10 Najveći broj referenci/potvrda stručnih lica kojima će biti povjereno izvršenje predmeta nabavke Kao osnov za vrednovanje navedenog parametra, uzimaju se dostavljeni dokazi (reference/potvrde) stručnih lica (minimum stručnih i kadrovskih kapaciteta koji su potrebni za izvršenje ugovora - zahtijevano u dijelu stručne i tehničke sposobnosti) kojima će biti povjereno izvršenje predmeta nabavke, iznad predviđenih minimalnih zahtjeva stručne i tehničke sposobnosti (minimum po jedna referenca/potvrda (za svako angažovano stručno lice) o angažovanju na izvršenju istih ili sličnih poslova iz oblasti predmeta nabavke). Pod sličnim poslovima podrazumijevaju se poslovi na projektovanju, implementaciji, održavanju i praćenju IT sistema. Zahtijevano se dokazuje dostavljanjem dokaza nadležnog organa i/ili ovlašćene organizacije, odnosno pravnog lica, u skladu sa odredbama Pravilnika o metodologiji načina vrednovanja ponuda u postupku javnih nabavki ("Službeni list Crne Gore", br. 74/20, 71/23). Dostavljene reference/potvrde bodovaće se kumulativno za sva stručna lica (minimum stručnih i kadrovskih kapaciteta koji su potrebni za izvršenje ugovora - zahtijevano u dijelu stručne i tehničke sposobnosti). 3. Za Partiju 2: 1. Iskustvo stručnih lica kojima će biti povjereno izvršeje predmeta nabavke........... 10 bodova Maksimalan broj bodova, po ovom parametru dodjeljuje se ponuđaču koji je dostavio najveći broj referenci/potvrda kojima se potvrđuje da su stručna lica kojima će biti povjereno izvršenje predmeta nabavke bila angažovana na izvršenju istih ili sličnih poslova iz oblasti predmeta nabavke. Pod sličnim poslovima podrazumijevaju se poslovi na projektovanju, implementaciji, održavanju i praćenju IT sistema, dok se bodovi ostalim ponuđačima, po ovom parametru, dodijeljuju proporcionalno, u odnosu na najveći broj referenci/potvrda stručnih lica kojima će biti povjereno izvršenje predmeta nabavke, po formuli: Broj referenci/potvrda stručnih lica kojima će biti povjereno izvršenje predmeta nabavke Broj bodova = ----------------------------------------------------------- x 10 Najveći broj referenci/potvrda stručnih lica kojima će biti povjereno izvršenje predmeta nabavke Kao osnov za vrednovanje navedenog parametra, uzimaju se dostavljeni dokazi (reference/potvrde) stručnih lica (minimum stručnih i kadrovskih kapaciteta koji su potrebni za izvršenje ugovora - zahtijevano u dijelu stručne i tehničke sposobnosti) kojima će biti povjereno izvršenje predmeta nabavke, iznad predviđenih minimalnih zahtjeva stručne i tehničke sposobnosti (minimum po jedna referenca/potvrda (za svako angažovano stručno lice) o angažovanju na izvršenju istih ili sličnih poslova iz oblasti predmeta nabavke). Pod sličnim poslovima podrazumijevaju se poslovi na projektovanju, implementaciji, održavanju i praćenju IT sistema. Zahtijevano se dokazuje dostavljanjem dokaza nadležnog organa i/ili ovlašćene organizacije, odnosno pravnog lica, u skladu sa odredbama Pravilnika o metodologiji načina vrednovanja ponuda u postupku javnih nabavki ("Službeni list Crne Gore", br. 74/20, 71/23). Dostavljene reference/potvrde bodovaće se kumulativno za sva stručna lica (minimum stručnih i kadrovskih kapaciteta koji su potrebni za izvršenje ugovora - zahtijevano u dijelu stručne i tehničke sposobnosti). 4. Za Partiju 3: 1. Iskustvo stručnih lica kojima će biti povjereno izvršeje predmeta nabavke........... 10 bodova Maksimalan broj bodova, po ovom parametru dodjeljuje se ponuđaču koji je dostavio najveći broj referenci/potvrda kojima se potvrđuje da su stručna lica kojima će biti povjereno izvršenje predmeta nabavke bila angažovana na izvršenju istih ili sličnih poslova iz oblasti predmeta nabavke. Pod sličnim poslovima podrazumijevaju se poslovi na projektovanju, implementaciji, održavanju i praćenju IT sistema, dok se bodovi ostalim ponuđačima, po ovom parametru, dodijeljuju proporcionalno, u odnosu na najveći broj referenci/potvrda stručnih lica kojima će biti povjereno izvršenje predmeta nabavke, po formuli: Broj referenci/potvrda stručnih lica kojima će biti povjereno izvršenje predmeta nabavke Broj bodova = ----------------------------------------------------------- x 10 Najveći broj referenci/potvrda stručnih lica kojima će biti povjereno izvršenje predmeta nabavke Kao osnov za vrednovanje navedenog parametra, uzimaju se dostavljeni dokazi (reference/potvrde) stručnih lica (minimum stručnih i kadrovskih kapaciteta koji su potrebni za izvršenje ugovora - zahtijevano u dijelu stručne i tehničke sposobnosti) kojima će biti povjereno izvršenje predmeta nabavke, iznad predviđenih minimalnih zahtjeva stručne i tehničke sposobnosti (minimum po jedna referenca/potvrda (za svako angažovano stručno lice) o angažovanju na izvršenju istih ili sličnih poslova iz oblasti predmeta nabavke). Pod sličnim poslovima podrazumijevaju se poslovi na projektovanju, implementaciji, održavanju i praćenju IT sistema. Zahtijevano se dokazuje dostavljanjem dokaza nadležnog organa i/ili ovlašćene organizacije, odnosno pravnog lica, u skladu sa odredbama Pravilnika o metodologiji načina vrednovanja ponuda u postupku javnih nabavki ("Službeni list Crne Gore", br. 74/20, 71/23). Dostavljene reference/potvrde bodovaće se kumulativno za sva stručna lica (minimum stručnih i kadrovskih kapaciteta koji su potrebni za izvršenje ugovora - zahtijevano u dijelu stručne i tehničke sposobnosti). 5. Za Partiju 4: 1. Iskustvo stručnih lica kojima će biti povjereno izvršeje predmeta nabavke........... 10 bodova Maksimalan broj bodova, po ovom parametru dodjeljuje se ponuđaču koji je dostavio najveći broj referenci/potvrda kojima se potvrđuje da su stručna lica kojima će biti povjereno izvršenje predmeta nabavke bila angažovana na izvršenju istih ili sličnih poslova iz oblasti predmeta nabavke. Pod sličnim poslovima podrazumijevaju se poslovi na projektovanju, implementaciji, održavanju i praćenju IT sistema, dok se bodovi ostalim ponuđačima, po ovom parametru, dodijeljuju proporcionalno, u odnosu na najveći broj referenci/potvrda stručnih lica kojima će biti povjereno izvršenje predmeta nabavke, po formuli: Broj referenci/potvrda stručnih lica kojima će biti povjereno izvršenje predmeta nabavke Broj bodova = ----------------------------------------------------------- x 10 Najveći broj referenci/potvrda stručnih lica kojima će biti povjereno izvršenje predmeta nabavke Kao osnov za vrednovanje navedenog parametra, uzimaju se dostavljeni dokazi (reference/potvrde) stručnih lica (minimum stručnih i kadrovskih kapaciteta koji su potrebni za izvršenje ugovora - zahtijevano u dijelu stručne i tehničke sposobnosti) kojima će biti povjereno izvršenje predmeta nabavke, iznad predviđenih minimalnih zahtjeva stručne i tehničke sposobnosti (minimum po jedna referenca/potvrda (za svako angažovano stručno lice) o angažovanju na izvršenju istih ili sličnih poslova iz oblasti predmeta nabavke). Pod sličnim poslovima podrazumijevaju se poslovi na projektovanju, implementaciji, održavanju i praćenju IT sistema. Zahtijevano se dokazuje dostavljanjem dokaza nadležnog organa i/ili ovlašćene organizacije, odnosno pravnog lica, u skladu sa odredbama Pravilnika o metodologiji načina vrednovanja ponuda u postupku javnih nabavki ("Službeni list Crne Gore", br. 74/20, 71/23). Dostavljene reference/potvrde bodovaće se kumulativno za sva stručna lica (minimum stručnih i kadrovskih kapaciteta koji su potrebni za izvršenje ugovora - zahtijevano u dijelu stručne i tehničke sposobnosti). TEHNIČKA SPECIFIKACIJA 1. Izrada aplikacije Pretrage, kao i izrada API za eksterne organe, kao i integraciju eksternih WEB servisa shodno Projektnom zadatku, koji predstavlja sastavni dio ove tehničke specifikacije, i nalazi se u dijelu "Dokumenti" pod "Dopuna tenderske dokumentacije". Projektni zadatak za izradu potrebnih Rest API i aplikacije Pretrage, putem koje će službenici moći da na jednom mjestu naprave uvid u podatke iz svih evidencija Uprave Policije (u daljem tekstu UP), kao i pozovu web servise u cilju dobijanja podataka iz eksternih evidencija tj evidencija Ministarstva unutrašnjih poslova (u daljem tekstu MUP) i drugih organa korišćenjem API (proxy API). Pored aplikacija za korisnike MUP-a i UP-a, ovim projektnom će se realizovati REST API putem kojeg će druge institucije koje imaju pravni osnov preuzimati podatke iz evidencija/registara MUP-a i UP-a. Količina: 1 sistem 2. Dorada postojećeg sistema za Registar boravka do 90 dana 1 PRAVNI OSNOV • Zakon o zaštiti podataka o ličnosti • Zakon o informacionoj bezbjednosti • Zakon o strancima • Zakon o registrima prebivališta i boravišta • Zakon o unutrašnjim poslovima • Zakon o graničnoj kontroli Pored naznačenog i sva podzakonska akta koja proizilaze iz navedenih zakona i Uredbe. 2 PREDMET PROJEKTNOG ZADATKA Predmet ovog projektnog zadatka je nadogradnja postojećeg sistema za registraciju boravka do 90 dana (u daljem tekstu RB90). Ovo podrayumijeva nadogradnju backend web servisa i izradu novih klijentskih aplikacija. 3 OPIS POSTOJEĆEG STANJA Sistem RB90 obuhvata više organizacija koje vrše unos ili prijem podataka iz ovog sistema, kao i organizacija koje iz ovog sistema crpe podatke. Sistem je napravljen u sledećim tehnologijama: - WEB aplikacija i WEB servisi– Java programski jezik - Desktop aplikacija – MS Visual Studio, .NET razvojni alati - ORACLE baza podataka Vlasnik sistema je Ministarstvo unutrašnjih poslova (MUP) dok su učesnici u sistemu, odnosno izvori podataka: Davaoci smještaja (pravna lica - hoteli, fizička lica, turističke organizacije), Uprava policije i Ministarstvo ekonomskog razvoja, odnosno Centralni Turistički Registar (CTR). Korisnici podataka su MUP, Uprava policije i Ministarstvo ekonomskog razvoja. 3.1 AUTENTIFIKACIJA KORISNIKA Autentifikacija svih korisnika sistema se vrši na osnovu digitalnog certifikata (DC) koji korisnici posjeduju i koji su izdati od strane: • Autorizovane organizacije za izdavanje DC na nivou države za sve Davaoce smještaja • Internog CA Ministarstva unutrašnjih poslova za sve zaposlene MUP-a, administratore sistema i ovašćene službenike Uprave policije koji imaju pravo pristupa sistemu, unosa i pretrage podataka iz Registra. Autentifikacija korisnika sistema prilikom pristupa podacima vrši se na osnovu prezentiranog DC korisnika koji pristupa sistemu. Svi upisi i upiti u Registar se potpisuju odgovarajućim DC u cilju nesporne identifikacije korisnika koji je napravio izmjenu ili unos podataka. Svi unosi i upiti u RB90 se loguju unutar baze podataka. Sistem se sastoji od sledećih cjelina: - WEB aplikacija za administriranje korisnika - WEB aplikacija za prijavu i odjavu gostiju - Desktop aplikacija za službenike Uprave policije za prijavu lica, pregled registra, provjere potrebnih evidencija prilikom izdavanja dozvola - WEB servisa za prijavu i odjavu gostiju - WEB servisa za preuzimanje podataka iz RB90 evidencije - WEB servisa za pretragu registra od strane CRS-a 3.2 UNOS, IZMJENA I BRISANJE PODATAKA Unos, izmjena i brisanje podataka u RB90 vrši se na sledeće načine: - Preko PublicWS - web servisa koji je vidljiv sa Interneta i koji služi za unos i izmjene podataka. Ovaj servis može biti pozvan od strane hotelske aplikacije ili bilo koje druge aplikacije koju koristi Davaoc smještaja. - Putem web aplikacije. Davaoc smještaja može pozivom ovog portala pristupiti sistemu za unos podataka o gostima uz predhodnu autentifikaciju korišćenjem DC-a. Poslije autentifikacije korisnika i popunjavanja forme, web aplikacija unesene podatke potpisuje na radnoj stanici korišćenjem prezentiranog DC a zatim podatke unosi u sistem koristeći WS. - Turističke organizacije na isti način unose podatke kao i davaoci smještaja (preko WEB servisa ili WEB aplikacije). - Korišćenjem policijske desktop aplikacije koju isključivo koriste službenici. Desktop aplikacija podliježe svim standardima aplikativnog softvera Uprave policije, od načina autentifikacije, centralizovanog održavanja novih verzija aplikacije, njihovog pozivanja i logovanja svih akcija. Unos novog boravka se vrši pozivom odgovarajuće metode na web servisu PublicWS. Ista metoda se koristi i za unos podataka kroz Web GUI tako što se poziva od strane Java script-a (JS) koji se izvršava u web browser-u korisnika. Po unosu podataka u formu, Java skript prikuplja podatke i u web pretraživaču klijentskog računara vrši potpisivanje podataka ključem koji je priložio korisnik sistema. Po potpisivanju podataka, Java script vrši poziv odgovarajuće metode PublicWS servisa i preko nje unosi podatke u sistem. Prijavu boravka mogu vršiti Davaoci smještaja, ovlašćeni službenici UP i ovlašćeni službenici TO. Gerenalno, izmjene podataka o boravku će moći da uradi samo korisnik koji je podatke unio. Ipak, postoji odstupanje od ovog pravila - Administrator hotelskog objekta može izvršiti izmjenu podataka za svog gosta (gosta koji je prijavljen u njegovom objektu) koji je unijet od strane UP ili TO. Brisanje podataka ne podrazumijeva brisanje podataka iz baze podataka, već samo promjenu statusa. 3.3 ADMINISTRACIJA KORISNIKA Web aplikacija (Administrativna aplikacija) služi za unos podataka o Davaocima smještaja i za definisanje uloga svih ostalih korisnika sistemu i njihovih privilegija, kao i konfiguraciju servisa. 3.4 PRETRAGA PODATAKA Pretrage podataka unešenih u RB90 vrši se na sledeće načine - korišćenjem web servisa UPWS i kroz desktop aplikaciju pristup podacima vrše ovlašćena lica Uprave policije i MUP-a - korišćenjem MTWS web servisa pristup podacima vrši Ministarstvo ekonomskog razvoja - Pretraga iz CRS-a ima mogućnost da prozove metodu web servisa, koja za rezultat vraća informaciju o tome da li lice ima pravo da podnese zahtjev za privremeni boravak. 3.5 OBEZBJEĐENJE NEPORECIVOSTI UNEŠENIH PODATAKA Sistem potpisivanja ulaznih podataka pri pozivu web servisa podrazumjeva da se korišćenjem privatnog ključa Davaoca smještaja obezbijedi neporecivost unesenih podataka koristeći slijedeći niz koraka: 1. Davaoc smještaja se loguje u aplikakciju koristeći svoj token na kom se nalazi DC 2. Davaoc popunjava podatke iz forme za unos podataka o novom gostu 3. Po unosu podataka, pritiskom na odgovarajuću kontrolu za upis podataka u sistem aplikacija pravi digitalni potpis unešenih podataka. Podaci se šalju web servisu, a u sklopu skupa podataka nalazi se digitalni potpis. 4. Web servis po prijemu podataka vrši provjeru digitalnog potpisa 5. Web servis dekriptuje dobijeni potpis javnim ključem koji je definisan za Davaoca smještaja koji podatke unosi i koji se nalazi u internoj bazi podataka 6. Web servis upoređuje originalni potpis podataka i svoju verziju potpisa – ukoliko su dobijeni potpisi identični podaci se upisuju u sistem. U slučaju komunikacije hotelske aplikacije sa javnim web servisom, procedura je identična. U svrhu prenosa nomenklatura i šifarnika postoji poseban web servis, sa sledećim nomenklaturama. • Drzave • Gradovi • MjestaResponse • Dokumenta 3.6 IZVJEŠTAJI U policijskoj aplikaciji postoje sledeći izvještaji: 1. ŠTAMPA REGISTRA 2. IZVJEŠTAJ O LICIMA UPISANIM U REGISTAR BORAVKA DO 90 DANA 3. IZVJEŠTAJ O PROMJENAMA U REGISTRU 4. STATISTIČKI IZVJEŠTAJ TIP GOSTA I POL 5. STATISTIČKI IZVJEŠTAJ PO DRŽAVAMA 6. STATISTIČKI IZVJEŠTAJ PO OPŠTINI BORAVKA 7. STATISTIČKI IZVJEŠTAJ PO DAVAOCU USLUGA U WEB aplikaciji za administriranje korisnika postoje izvještaj o logovima, odnosno akcijama korisnika sistema. 3.7 PROVJERE EKSTERNIH BAZA PODATAKA Ova funkcionalnost predstavlja provjeru eksternih baza podataka putem WEB servisa. Informacije o provjerama se čuvaju u bazi podataka, u kojoj se za svako lice koje ima aktivan boravak, putem vremenski preciziranih operacija provjeravaju navedeni eksterni web servisi i zapisuju informacije o tim provjerama. Ove informacije se zatim mogu isporučiti policijskoj aplikaciji na zahtjev putem WEB servis metode, razvijene u tu svrhu. Samo korisnici policijske desktop aplikacije imaju ovu funkcionalnost. 4 FAZE I DORADE SOFTVERSKOG RJEŠENJA Faza upoznavanja sa postojećim sistemom: - U ovoj fazi izabranom dobavljaču biće omogućen uvid u source kod, bazu podataka, omogućeno podizanje razvojnog/testnog okruženja, kao i pružena sva potrebna tehnička pomoć kako bi se upoznao sa implementacijom postojećeg rješenja Faza I: - Izraditi predlog arhitekture novog sistema - Izraditi predlog redizajna aplikacija (aplikacija za inspektore za strance kao i za korisnike Ministarstva unutrašnjih poslova trebaju da se izrade nove a ne da se vrši njihova nadogradnja. Aplikacije treba uraditi u .net tehnologiji tj win forme sa upotrebom devexpress kontrola) Faza II - U skladu sa usaglašenom arhitekturom i dizajnom izvršiti redizajn i potrebna podešavanja - Doraditi sve WEB servise tako da se zadrži funkcionalnost koja osigurava sigurnost i neporecivost unešenih podataka - Izvršiti redizajn WEB aplikacije ili izraditi novu korisničku aplikaciju tako da se zadrži postojeća funkcionalnost koja osigurava sigurnost i neporecivost unešenih podataka, a da se izbjegne trenutna zavisnost od Java appleta (koje je nemoguće pokrenuti u novijim verzijama web pretraživača), kako bi krajnji korisnik mogao lakše manipulisati aplikacijom, a podrška u instaliranju aplikacije bila svedena na minimum. - Izvršiti redizajn i izradu nove desktop aplikacija za službenike Uprave policije za prijavu lica, pregled registra, provjere potrebnih evidencija prilikom izdavanja dozvola. - Izvršiti izmjenu autorizaciju i automatizaciju korisnika MUP-a i UP-a (certifikati provjeravati iz aplikacije sertifikati) - Izvršiti ispravljanje eventualnih bug-ova u aplikaciji Faza III - Izraditi WEB servis za preuzimanje podataka o davaocima smještaja iz Centralnog turističkohg registra (Ova stavka se implementira ukoliko nadležno ministarstvo omogući API za preuzimanje podataka). - Izraditi web servis pomoću kojeg bi Lokalne turističke organizacije mogle imati uvid u podatke iz svoje opštine. Mora postojati mogućnost uvida u statistiku kao i u analitiku. - Prilagoditi softver, eventualnim promjenama zakonske regulative Faza IV - Testiranje aplikacije (testovi operativne primopredaje). Faza V - Izraditi tehničku dokumentaciju – projekat izvedenog stanja za predmetni sistem i korisnička uputstva. 5 TESTOVI OPERATIVNE PRIMOPREDAJE Obaveza izabranog Dobavljača je da za Fazu II i Fazu III dostavi predlog testova operativne primopredaje. Testove operativne primopredaje treba da odobri ili da, u pisanoj formi, primjedbe MUP u roku od 5 radnih dana od njihovog dobijanje od strane izabranog Dobavljača. Ako je MUP dao primjedbe na Testove oprativne primopredaje izabrani Dobavljač je dužan da ih ispravi u roku od pet dana i dostavi MUP-u na odobrenje. Ako po dobijanju predloga Testova oprativne primopredaje MUP ne da primjedbe u roku od pet dana smatra se da je iste odobrio. Predlog testova treba da bude u sledećoj formi: • Broj testa: • Naziv testa: • Koraci u sprovođenju testa: • Očekivani rezultati: 5.1 FINALNO TESTIRANJE U okviru Faze IV vrši se finalno testiranje prolaskom kroz testove opearativne primopredaje. Ako Softver ne zadovoljava kriterijume prihvatljivosti, Poručioc će Dobavljaču dostaviti obavještenje u pisanoj formi navodeći zašto je Softver neprihvatljiv. Dobavljač će imati 5 radnih dana od dana prijema obavještenja da ispravi nedostatke. Poručioc će zatim da izvrši inspekciju, testiranje i ponovnu procjenu Softvera. Ako Softver i dalje ne zadovoljava kriterijume prihvatljivosti, Poručioc će imati sledeće opcije: • i) ponavljanje procedure koja je gore navedena, ili • ii) da prekine ovaj Ugovor bez ostavljanja dodatnog roka. Dobavljač se obavezuje da detaljno testira sve naknadne verzije (release), nakandna poboljšanja i nadogradnje. 6 ROKOVI IMPLEMENTACIJE Stavka Rok (T predstavlja datum potpisivanja ugovora) Broj iteracija Faza upoznavanja sa postojećim sistemom T + 1 mjesec neprimjenjivo Faza I T + 3 mjesec 3 Faza II T + 9 mjesec neprimjenjivo Faza III T + 10 mjesec Faza IV T + 11 mjesec Faza V T + 12 mjesec Tabela 1 Broj iteracija – predstavlja broj koliko puta isporučioc može dostaviti predlog arhitekture i/ili dizajna na usaglašavanje. Obaveza ministarstva je da u roku od 5 radnih dana pisanim putem ili putem maila dostavi primjedbe isporučiocu na predlog dostavljenih dokumenata iz Faze I. Ukoliko se ne usaglasi predlog ahitekture i dizajna aplikacija u predviđenom broju iteracija, ovaj ugovor će se raskinuti bez obaveze plaćanja isporučiocu. Obaveza ponuđača je da da garantni rok od 12 mjeseci od dana puštanja softvera u produkciju. U garantnom roku isporučioc je u obavezi da otkloni sve naknadno uviđene bugove odnosno greške u radu sistema. Build verzije za test i produkciju je neophodno napraviti na MUP-ovom razvojno okruženju koje je u obavezi da podigne izabrani dobavljač. Izvorni kod (source code) kao i sva autorska prava pripadaju naručiocu posla. Ukoliko se pojavi potreba u fazi implementacije za kupovinom dodatnih biblioteka iste mora da nabavi izabrani dobavljač bez dodatnih troškova za Količina: 1 sistem 3. Projektni zadatak za doradu postojeće aplikacije za zabranu ulazaka stranaca u Crnu Goru, uz migraciju svih potrebnih postojećih podataka. Projektnim zadatkom je predviđeno i prebacivanje aplikacije na novije tehnologije uz korišćenje REST WEB servisa, umjesto dosadašnjih SOAP, kao i izrada novih API-ja za pretraživanje i prikupljanje podataka iz ovih evidencija. Projektnim zadatkom je predviđena i dorada aplikacije u dijelu autentifikacije korisnika (korišćenjem digitalnih sertifikata), administracije korisnika, omogućavanje pretraživanja ove evidencije i audit-a korišćenja aplikacije. 1. Pravni osnov • Zakon o unutrašnjim poslovima • Zakon o zaštiti podataka o ličnosti • Zakon o informacionoj bezbjednosti • Zakon o Centralnom registru stanovništva Pored naznačenih i sva podzakonska akta koja proizilaze iz navedenih zakona. 2. Cilj projekta Cilj projekta je da se izvrši adaptacija postojeće elektronske evidencije zabrane ulazaka stranaca u Crnu Goru, kako bi se pratili novi radni procesi iz ove oblasti. Prebacivanje aplikacije na novije tehnologije uz korišćenjem REST WEB servisa, umjesto dosadašnjih SOAP i izrade API-ja za pregledanje i prikupljanje podataka iz ovih evidencija, omogućiće se lakšu integracija sa kompletnim sistemom Ministarstva unutrašnjih poslova i Uprave policije (u daljem tekstu MUP i UP) 3. Klijenti Pristup bazi podataka sa stane klijenta dozvoljen je isključivo preko WEB servisa. Klijent može da „vidi” samo aplikativni i/ili web server. Komunikacija klijenta sa aplikativnim i/ili web serverom je isključivo preko HTTPS protokola. Sa spoljnjim WEB servsima klijent može da „priča” samo preko aplikativnog i/ili web servera MUP-a (proxy service). Direktan pristup bazi podataka ima isklučivo aplikativni i/ili web server. Pristupni parametri bazi podataka moraju biti konfigurabilni. Arhitektura mora podržavati dodavanje dodatnih aplikativnih i/ili web servera MUP-a. Autentifikacija i autorizacija mora biti sa digitalnim certifikatom. Aplikacije prilikom prijave treba da provjere da li korisnik ima validan sertifikat i da obezbijedi automatski, aplikativno kontrolisani, update aktuelne verzije aplikacije i njoj pripadajućih fajlova. Potrebno da se izradi kao “debeli” klijent (.net C#) u višeslojnoj arhitekturi. MUP posjeduje licence za korišćenje devexpres bibloteka. Desktop aplikacija mora biti kompatibilna sa aplikativnim rješenjem CRA (centralni registar aplikacija) koji prilikom startovanja treba da provjeri i obezbijedi automatski update aktuelne verzije aplikacije i njoj pripadajućih fajlova. 4. API U okviru izrade softvera potrebno je napraviti REST API koji će se koristiti u komunikaciji sa aplikacijom Granica, za već postojeće alarmiranje službenika prilikom granične kontrole. U okviru ovog projekta neophodna je izrada REST API tj web API kojima se razmjenjuju podaci unutar informacionog sistema MUP-a i sa eksternim korisnicima za navedene evidencija. Kod autorizacije neophodno je za svaki od servisa dodijeliti pravni osnov korisniku za uvid u podatke, kao i posebno dodijeliti pravo za korišćenje, i dodijeliti broj rezultata koji je dozvoljen da se vrati korisniku za svaki od omogućenih servisa. 5. Generalni zahtjevi Nadležnost za unos mjera prema licima je sledeća: 1. Mjere zabrane ulaska u Crnu Goru unosi SBPK na osnovu rješenja koje donosi direktor Uprave policije , a pretražuju se prilikom evidentiranja putnika prilikom prelaska državne granice 2. Mjere zabrane ulaska u Crnu Goru ili druge mjere koje unosi SGP ili druge organizacione jedinice na osnovu rješenja suda i drugih nadležnih organa i to pojedinačnim unosom ili uvozom iz predefinisanog fajla, a pretražuju se prilikom evidentiranja putnika prilikom prelaska državne granice 3. Sve mjere koje se preduzimaju prema licima a ne odnose se na zabranu ulaska u Crnu Goru, unose ih organizacione jedinice Uprave policije, a pretražuju se prilikom evidentiranja putnika prilikom prelaska državne granice 1. Mjere zabrane ulaska na osnovu rješenja koje donosi direktor Uprave policije Zabrana ulaska se realizuje na osnovu rješenja koje donosi direktor Uprave policije, a na osnovu predloga organizacionih jedinica unutar policije ili drugih nadležnih organa van policije. Mjere zabrane mogu biti izrečene zbog unutrašnje bezbjednosti, nacionalne bezbjednosti i javnog zdravlja. Organizacione jedinica Uprave policije koja je zadužena za unos podataka u elektronsku evidenciju, radi to na osnovu ovog rješenja, za koje, pored unosa detaljnih podataka sa rješenja, treba da postoji mogućnost skeniranja i štampanja skeniranog rješenja kroz aplikaciju. Trajanje zabrane ulaska ne može biti duže od dvije godine, sa mogućnošću prekidanja zabrane u okviru tog perioda, ili produžavanja zabrane poslije isteka tog perioda, ali ponovo ne duže od dvije godine. Organizaciona jedinica koja je dala predlog za zabranu ulaska, mora biti obaviještena o unosu lica u elektronsku evidenciju, kao i o isteku važenja mjere 30 dana prije isteka, na unaprijed definisanu e-mail adresu ili putem SMS notifikacije. Mjere zabrane koje nisu produžene automatski se deaktiviraju nakon isteka roka važenja. Službenici granične policije, koji rade na kontroli prelaska državne granica, kroz aplikaciju Granica, bivaju alarmirani da za lice postoji zabrana ulaska, sa već definisanim podacima koji postoje u aplikaciji Granica, i koji se crpe iz ove evidencije. Policajac na graničnom prelazu je dužan da licu uruči Zapisnik o upoznavanju stranca o postojanju zabrane, koji sa potrebnim podacima treba da se generiše iz ovog softverskog rješenja, ili korišćenjem razvijenog API-ja, za generisanje zapisnika iz aplikacije Granica, pri čemu lice kojem je donesena mjera zabrane ulaska, treba da saopšti adresu, na koju mu se šalje rješenje o zabrani ulaska i koja će biti sadržana u ovom zapisniku. Za ove zabrane ne treba da postoji mogućnost uvoza podataka iz predefinisanog fajla. 2. Mjere koje se unose na osnovu rješenja suda ili drugih nadležnih organa u SGP-u U postojećoj aplikaciji postoji mogućnost unosa mjera zabrane prelaska državne granice po nalogu i rješenjima sudova, čiji unos vrši granična policija. Modul treba nadograditi najmanje podatkom o JMB lica, datumu važenja mjere, organ koji je tražio mjeru, broj akta, datum akta, i kao u prethodnom modulu vršiti alarmiranje službenika o isteku roka važenja, kao i automatskom deaktiviranju mjere nakon isteka važenja. Službenici granične policije, koji rade na kontroli prelaska državne granica, kroz aplikaciju Granica, bivaju alarmirani da za lice postoji zabrana ulaska, sa već definisanim podacima koji postoje u aplikaciji Granica, i koji se crpe iz ove evidencije Prilikom unosa ovih zabrana potrebno je omogućiti uvoz podataka iz unaprijed definisanog fajla (CSV, XLSX). 3. Ostale mjere prema licima za potrebe rada policije Pored mjera zabrana ulaska u Crnu Goru kroz aplikaciju se evidentiraju i ostale mjere prema licima kao što su detaljna kontrola i sl. a koje se kroz aplikaciju Granica aplikuju na isti način kajoi mjere zabrane ulaska u Crnu Goru. Modul treba nadograditi podatkom o JMB lica i datumu važenja mjere i kao u prethodnom modulu vršiti alarmiranje službenika o isteku roka važenja, kao i automatskom deaktiviranju mjere nakon isteka važenja. Službenici granične policije, koji rade na kontroli prelaska državne granica, kroz aplikaciju Granica, bivaju alarmirani da za lice postoji navedena mjera, sa već definisanim podacima koji postoje u aplikaciji Granica, i koji se crpe iz ove evidencije Prilikom unosa ovih zabrana potrebno je omogućiti uvoz podataka iz unaprijed definisanog fajla (CSV, XLSX). Pored postojećih, softver treba da ima sledeće funkcionalnosti: - evidentiranje podataka o rješenju kojim se donosi zabrana - evidentiranje podataka o licu kojem se zabranjuje ulazak u Crnu Goru - evidentiranje podataka o dokumentima lica kojem se zabranjuje ulazak u Crnu Goru - evidentiranje podataka o organizacionoj jedinici koja je podnijela zahtjev za zabranu (organizaciona jedinica i e-mail) - alarmiranje službenika o isteku zabrane e-mail-om, i generisanjem pripadajućeg izvještaja - prijevremeno ukidanje zabrane - produžavanje zabrane - skeniranje rješenja - automatsko deaktiviranje zabrane poslije njenog isteka - generisanje Zapisnika o upoznavanju stranca o postojanju zabrane na graničnom prelazu - izvještavanje o zabranama ulaska u Crnu Goru - praćenje svih izmjena za svaku zabranu, uz prikaz izmjena u formi za unos zabrana za svako lice pojedinačno - logovanje svih pretraživanja evidencije mjera zabrana ulaska u Crnu Goru - audit svih izmjena i pretraživanja podataka u okviru aplikacije - administriranje korisnika i korisniičkih grupa, odnosno oblasti (sektora) U okviru izrade softvera potrebno je napraviti API koji će se koristiti u komunikaciji sa aplikacijom Granica, za već postojeće alarmiranje službenika prilikom granične kontrole, kao i za generisanje Zapisniku o upoznavanju stranca o postojanju mjere. Najmanji set podataka koji treba da se evidentiraju o rješenju - Broj rješenja zabrane - Datum rješenja - Razlog zabrane - Na čiji prijedlog je donešeno rješenje o zabrani - E-mail adresa organizacione jedinice koja je predložila zabranu - Datum početka zabrane - Datum važenja zabrane (ne može biti duži od godinu dana, od dana ) - Mjera koja se preduzima - Napomena Najmanji set podataka o licu kojem se zabranjuje ulazak u Crnu Goru je - Prezime - Ime - Datum rođenja - JMB - Država rođenja - Mjesto rođenja - Država prebivališta - Mjesto prebivališta - Adresa prebivališta Najmanji set podataka koji se evidentira o dokumentima lica kojem se zabranjuje ulazak u Crnu Goru je: - Vrsta dokumenta - Država izdavanje - Broj - Datum validnosti dokumenta Najmanji set podataka koji se evidentira o Zapisniku o upoznavanju stranca o postojanju mjere je sledeći: - Prezime - Ime - Srednje ime - Jedinstveni matični broj - Datum rođenja - Državljanstvo - Vrsta dokumenta - Broj dokumenta - Prebivalište - Granični prelaz - Vrijeme - Mjesto - Broj rješenja - Adresa stranca - Napomena - Policijski službenik - Potpis policijskog službenika - Potpis lica Svi navedeni podaci mogu biti u manjem obimu dopunjeni, prilikom izrade i dizajniranja sistema. Administracija korisnika Softver treba da omogući nezavisan pristup korisnicima u tri gore navedene podvrste evidecija. Softver treba da omogući nezavisan unos za grupe korisnika (SBPK, SGP,...), odnosno da su ovim grupama korisnika dostupni samo podaci koje unose. Svaki korisnik treba da pripada određenoj grupi korisnika (npr. SGP, SBPK). Nivoi pristupa korisnika mogu biti sledeći: - Administracija korisnika i korisničkih grupa - Unos zabrana ulaska u Crnu Goru na osnovu rješenja direktora Uprave policije (unos podataka o zabranama i skeniranje rješenja) - Unos zabrana ulazaka i drugih mjera na osnovu rješenja sudova i drugih organa - Unos ostalih vrsta mjera prema licima za potrebe rada policije - Pregled podataka - Izdavanje zapisnika na graničnom prelazu (generisanje zapisnika) - Audit aktivnosti u aplikaciji 6. Pregledi i izvještaji 1. Pregled zabrana sa svim unešenim podacima po sledećim uslovima - Period - Broj rješenja zabrane - Datum rješenja - Razlog zabrane - Na čiji prijedlog je donešeno rješenje o zabrani - Mjera - Prezime - Ime - Datum rođenja - Vrsta dokumenta - Država izdavanje - Broj 2. Pregled zapisnika o upoznavanju stranca sa svim unešenim podacima po sledećim uslovima - Prezime - Ime - Jedinstveni matični broj - Datum rođenja - Državljanstvo - Vrsta dokumenta - Broj dokumenta - Granični prelaz - Period - Broj rješenja - Policijski službenik Svi izvještaji moraju imati mogućnost štampe i eksporta podataka ( .xls, .pdf...) 7. Licence MUP posjeduje sledeđe licence: • Devexxpress universal kontrole • Oracle DB • MSSQL Enterprise • Windows server 2022 Ponuđač je obavezan da svojom ponudom obuhvati sve licence/biblioteke neophodne za rad ponuđenog rješenja. Ukoliko se pojavi potreba u fazi implementacije za kupovinom dodatnih biblioteka i/ili licenci iste mora da nabavi dobavljač bez dodatnih troškova za MUP. 8. Faze izrade softverskog rješenja Faza 1 - upoznavanja sa postojećim sistemom: U ovoj fazi izabranom ponuđaču biće omogućen uvid u postojeće aplikacije, realizovane web servise, bazu podataka, omogućeno podizanje razvojnog/testnog okruženja, kao i pružena sva potrebna tehnička pomoć kako bi se upoznao sa postojećim rješenjima. Ova faza će obezbijediti izabranom ponuđaču poznavanje evidencija/registara, servisa i kompletnog sistema kako bi mogao na adekvatan način realizovati fazu 2. Faza 2 – funkcionalna analiza Obaveza Dobavljača je da izradi dokument (u daljem tekstu: Funkcionalni zahtjevi) koji predstavlja Specifikaciju funkcionalnosti produkta i koji treba da sadrži najmanje: aktivnosti koje se planiraju izvesti kao zahtjevi, izvore, aktere, ulazne podatke/dokumente, izlazne dokumente, model podataka, preliminarni user interface, validacije i poslovna pravila (workflou) za svaki proces ponaosob, arhitekturu sistema. Funkcionalne zahtjeve treba da odobri ili da primjedbe MUP. Ako je MUP dao primjedbe na Funkcionalne zahtjeve Dobavljač je dužan da ih ispravi u roku od pet dana i dostavi MUP-u na odobrenje. Dobavljač ne može pristupiti realizaciji posla prije nego što dobije pisanu saglasnost MUP-a na dokument Funkcionalni zahtjevi. Ako Dobavljač i MUP ne usaglase Funkcionalne zahtjeve, odnosno ako MUP ne potpiše saglasnost na funkcionalne zahtjeve Ugovor o izvršenju usluga koje su predmet ovog projektnog zadatka biće raskinut bez ostavljanja dodatnog roka. Faza 3 - implementacija i migacija postojećih podataka U ovoj fazi Dobavljač će da razvije zahtjeve tražene projektnim zahjtevima i usaglašenom funkcionalnom analizom. Obaveza izabranog Dobavljača u ovoj fazi je i da za poslove definisane u Projeknom zadatku dostavi predlog testova operativne primopredaje. Testove operativne primopredaje treba da odobri ili da, u pisanoj formi, primjedbe MUP u roku od 10 dana od njihovog dobijanje od strane izabranog Dobavljača. Ako je MUP dao primjedbe na Testove oprativne primopredaje izabrani Dobavljač je dužan da ih ispravi u roku od pet dana i dostavi MUP-u na odobrenje. Ako po dobijanju predloga Testova oprativne primopredaje MUP ne da primjedbe u roku od 7 dana smatra se da je iste odobrio. Predlog testova treba da bude u sledećoj formi: • Broj testa: • Naziv testa: • Veza sa: Funkcionalni zahtjevi za fazu : • Koraci u sprovođenju testa: • Očekivani rezultati: 4 Faza – Testiranje prihvatljivosti U ovoj fazi vrši se finalno testiranje prolaskom kroz testove opearativne primopredaje. Ako sistem ne zadovoljava kriterijume prihvatljivosti, Poručioc će Dobavljaču dostaviti obavještenje u pisanoj formi navodeći zašto je sistem neprihvatljiv. Dobavljač će imati 15 radnih dana od dana prijema obavještenja da ispravi nedostatke. Poručioc će zatim da izvrši inspekciju, testiranje i ponovnu procjenu sistema. Ako sistem i dalje ne zadovoljava kriterijume prihvatljivosti, Poručioc će imati sledeće opcije: • ponavljanje procedure koja je gore navedena, ili • da prekine ovaj Ugovor bez ostavljanja dodatnog roka. Nakon završetka finalne razvojne faze navedene u vremenskom rasporedu u Ponudi, testiranje prihvatljivosti će biti izvršeno na sistemu u njegovoj cjelosti kako bi se utvrdilo da li sismte zadovoljava kriterijume prihvatljivosti i da li radi na način koji suštinski odgovara Specifikacijama u Projektnom zadatku. Poručioc će imati maksimum deset (10) radnih dana da izvrši takvo testiranje. Ako završeni sistem ne zadovoljava kriterijume prihvatljivosti, stranke će pratiti procedure o prihvatljivosti navedene u prethodnim tačkama. Ako i kada se na testovima prihvatljivosti utvrdi da je razvijeni sistem nakon završetka bilo koje razvojne faze u skladu sa kriterijumima prihvatljivosti, Poručioc će odmah obavijestiti Dobavljača da je razvijeni sistem prihvatljiv. Dobavljač se obavezuje da detaljno testira sve naknadne verzije (release), nakandna poboljšanja i nadogradnje. Faza 5 - Obuka U ovoj fazi će se detaljnno obučiti administratori za administriranje kompletnog sistema, kao i sa arhitekturom Sistema, prezentovaće se source kod, proći kroz konfigurabilnosti sistema…. Faza 6 - Puštanje u produkciju Obaveza izabranog ponuđača je da nakon uspješno sprovedenih testova operativne primopredaje je da aplikaciju instalira na produkcionom okruženju i da preda: • Detaljan tehnički opis produkcionog okruženja (detaljno šta je sve instalirano na aplikativnom i web serveru, procedure izmejne pristupnih podataka, opis svih konfiguracionih fajlova, opis backup politike, preduslovi za rad klijentskog dijela aplikacije i slično). • Izvedeno stanje sistema • Detaljno uputstvo za administraciju aplikacije • Detaljno korisničko uputstvo. 9. Rokovi implementacije Rok (T predstavlja datum potpisivanja ugovora) Faza I T + 1 mjesec; Faza II T + 2 mjeseca - Broj iteracija 3; Faza III T + 4 mjeseci; Faza IV T + 5 mjeseci; Faza V T + 6 mjeseci; Faza VI T + 6 mjeseci; Broj iteracija – predstavlja broj koliko puta dobavljač može dostaviti predlog funkcionalne analize na usaglašavanje. Obaveza ministarstva je da u roku od 7 radnih dana pisanim putem ili putem maila dostavi primjedbe dobavljaču na predlog dostavljenih dokumenata iz Faze 2. Ukoliko se ne usaglasi predlog funkcionalne analize u predviđenom broju iteracija, ovaj ugovor će se raskinuti bez obaveze plaćanja dobavljaču. Količina: 1 sistem 4. Projektni zadatak za doradu aplikacije ’’Dežurna služba’’, kojim će se doraditi postojeće evidencije lica lišenih slobode i zadržanih lica, kao i uraditi nova evidencija dovedenih lica. Projektnim zadatkom je predviđeno i prebacivanje aplikacije na novrije tehnologije uz korišćenje REST WEB servisa, umjesto dosadašnjih SOAP, kao i izrada novih API-ja za pretraživanje i prikupljanje podataka iz ovih evidencija. 1. Pravni osnov • Zakon o unutrašnjim poslovima • Zakon o zaštiti podataka o ličnosti • Zakon o informacionoj bezbjednosti • Zakon o Centralnom registru stanovništva Pored naznačenih i sva podzakonska akta koja proizilaze iz navedenih zakona. 2. Cilj projekta Cilj projekta je dorada aplikacije aplikacije ’’Dežurna služba’’, kojim će se doraditi postojeće evidencije lica lišenih slobode i zadržanih lica, kao i uraditi nova evidencija dovedenih lica. Prebacivanje aplikacije na novije tehnologije uz korišćenjem REST WEB servisa, umjesto dosadašnjih SOAP i izrade API-ja za pregledanje i prikupljanje podataka iz ovih evidencija, omogućiće se lakšu integracija sa kompletnim sistemom Ministarstva unutrašnjih poslova i Uprave policije (u daljem tekstu MUP i UP) 3. Klijenti Pristup bazi podataka sa stane klijenta dozvoljen je isključivo preko WEB servisa. Klijent može da „vidi” samo aplikativni i/ili web server. Komunikacija klijenta sa aplikativnim i/ili web serverom je isključivo preko HTTPS protokola. Sa spoljnjim WEB servsima klijent može da „priča” samo preko aplikativnog i/ili web servera MUP-a (proxy service). Direktan pristup bazi podataka ima isklučivo aplikativni i/ili web server. Pristupni parametri bazi podataka moraju biti konfigurabilni. Arhitektura mora podržavati dodavanje dodatnih aplikativnih i/ili web servera MUP-a. Autentifikacija i autorizacija mora biti sa digitalnim certifikatom. Aplikacije prilikom prijave treba da provjere da li korisnik ima validan sertifikat i da obezbijedi automatski, aplikativno kontrolisani, update aktuelne verzije aplikacije i njoj pripadajućih fajlova. Potrebno da se izradi kao “debeli” klijent (.net C#) u višeslojnoj arhitekturi. MUP posjeduje licence za korišćenje devexpres bibloteka. Desktop aplikacija mora biti kompatibilna sa aplikativnim rješenjem CRA (centralni registar aplikacija) koji prilikom startovanja treba da provjeri i obezbijedi automatski update aktuelne verzije aplikacije i njoj pripadajućih fajlova. 4. API U okviru ovog projekta neophodna je izrada REST API tj web API kojima se razvmjenjuju podaci unutar informacionog sistema MUP-a i sa eksternim korisnicima za navedene evidencija. Kod autorizacije neophodno je za svaki od servisa dodijeliti pravni osnov korisniku za uvid u podatke, kao i posebno dodijeliti pravo za korišćenje, i dodijeliti broj rezultata koji je dozvoljen da se vrati korisniku za svaki od omogućenih servisa. 5. Generalni zahtjevi U okviru aplikacije ''Dežurna služba'' postoje evidencije, sa osnovnim podacima, o licima lišenim slobode i zadržanim licima. Ove evidencije je potrebno doraditi i dodati novu evidenciju dovedenih lica, kako bi se pratio kompletan radni tok prilikom ovih aktinosti, kao i praćenje i generisanje propratne dokumentacije, uz mogućnost skeniranja eksterne dokumentacije. Shodno ovim doradama potrebno je doraditi i administraciju korisnika i modula za pretraživanje. Radni proces je sljedeći: U okviru događaja koji se evidentiraju u aplikaciji, policijski službenici mogu izvršiti dovođenja lica u policijske prostorije, prilikom čega se od lica uzimaju potrebni podaci i izjave, i lice se evidentira u evidenciji dovedenih lica. Dovedeno lice se u policijskim prostorijama može zadržati do 6 sati, nakon čega se pušta ili se lišava slobode. Za određene organizacione jedinice treba da postoji mogućnost unosa dovedenih lica bez povezivanja sa događajem evidentiranim u aplikaciji Dežurna služba. Nakon završetka potrebnih radnji dovedeno lice može biti pušteno ili lišeno slobode. Evidentiranje lica lišenog slobode se može vršiti preuzimanjem iz evidencije dovedenih lica ili direktnim unosom podataka u evidenciju lica lišenih slobode, a na osnovu unešenog događaja. Lice se lišava slobode do 12 sati za prekršaje i do 24 sata za krivična djela, pri čemu se vrijeme računa od trenutka dovođenja lica. Nakon završetka potrebnih radnji lice lišeno slobode može biti pušteno ili zadržano, a u evidenciju zadržanih lica se upisuje preuzimanjem iz evidencije lica lišenih slobode. Lice se može zadržati najduže do 24 sata za prekršaje i 72 sata za krivična djela. Softver treba da prati ove rokove, i alarmira policijske službenike o isteku rokova. U procesu dovođenja, lišenju slobode na licu mjesta , lišenju slobode za prekršaje može učestvovati bilo koji policijski službenik, dok u procesu zadržavanja lica učestvuju službenici koji rade u pritvorskim jedinicama. Shodno ulogama službenika u ovim procesima potrebno je doraditi administraciju korisnika u aplikaciji Dežurna služba. Nove korisničke grupe bi bile: - Dovođenje lica i lišavanje sobode (unos podataka i obrazaca za dovedena lica i lica lišena slobode) - Zadržavanje lica (unos podataka i obrazaca o zadržanim licima) Dovedena lica Softver mora da omogući službeniku koji je doveo lice izbor događaja, registrovanog u Dežurnoj službi, za koji je postupanje vezano ili da direktno upisuje lice u evidenciju. Mora omogućiti unos potrebnih podataka o dovedenom licu, skeniranje potrebne dokumentacije, kao i generisanje i štampanje obrazaca koji prate dovođenja lica: službene zabilješke, zapisnik o obavještenju prikupljenom od građana, potvrda o oduzetim predmetima i sl. pri čemu će se za svaki obrazac učitavati već pounjeni podaci i dopunjavati podaci vezani za obrazac. Pored podataka iz samog obrasca evidentiraće se i najmanje sledeći podaci: vrsta dokumenta/ obrasca, nazivu dokumenta, vremenu dokumenta, Službenici koji unose podatke u ovu evidenciju nemaju mogućnost izmjene podataka o samom događaju, što je nadležnost službenika koji rade u dežurnim službama. Najmanji set podataka koji trebaju da se evidentiraju u evidenciji dovedenih lica, zajedno sa podacima iz pripadajućih obrazaca su: • Organizaciona jedinica koja dovodi lice • Razlog dovođenja (provjera identiteta, prikupljanje obavještenja...) • Zakonski osnov dovođenja lica (samostalno ili ko je ocijenio) • Datum dovođenja • Vrijeme dovođenja • Mjesto dovođenja • Broj kancelarije • Ime lica • Prezime lica • JMBG • Ime oca • Ime majke • Rođeno prezime majke • Datum rodjenja • Mjesto rodjenja • Država rođenja • Punoljetno / Maloljetno • Prebivalište i adresa stana • Državljanstvo • Broj telefona • Na osnovu čega je utvrđen identitet • Lične karte • Pasoša • Vozačke dozvole • Ostalo • Vrijeme kada je lice zatečeno • Mjesto gdje je lice zatečeno • Opis dogadjaja/Obrazloženje • Zadobijene ili druge vidljive povrede prije preduzimanja službene radnje dovođenja • Vidljiva oštećenja odjeće i obuće prije preduzimanja službene radnje dovođenja • Drugi bolovi / tegobe(da/ne ako je da koji) • Upoznavanje lica sa razlozima dovođenja (da/ne, akoje ne unijeti razlog, ako je da unijeti vrijeme) • Upoznavanje lica sa pravima (da/ne, akoje ne unijeti razlog, ako je da unijeti vrijeme) • Upotrijebljena sredstva prinude (da/ne i ako je da koja su upotrebljena • Povrede od upotrebe sredstava prinude • Ko je obavješten o dovođenju lica (roditelj, staratelj, lice od povjerenja, ako je da onda Prezime i ime lica koje je obaviješteno, Vrijeme obavještavanja, Način obavještavanja ) • Angažovan advokat (da/ne ako je da Prezime i ime advokata, Vrijeme obavještenja advokata, Da li je pristupio, Vrijeme pristupanja) • Obavješten dežurni starješina/ neposredni rukovodilac (da/ne ako je da Prezime i ime) • Izjava lica o zdravstvenom pregledu (da/ne ako je da unijeti Prezime i ime doktora, datum i vrijeme) • Oduzeti predmeti (da/ne, ako je da unose se predmeti) • Štampanje potvrde o oduzetim predmetima (Obrazac: D-4) • Ishodu dovođenja • Datum i vrijeme napuštanja službenih prostorija (promjena statusa) • Izvještaj o primjeni policijskog ovlašćenja dovođenja (Obrazac: D-1). • Izvještaj o primopredaji lica (Obrazac – D-2) • Policijski službenik koji je predao lice (prezime i ime, organizaciona jedinica, broj službene legitimacije) • Policijiski službenik kojem je predato lice (prezime i ime, organizaciona jedinica, broj službene legitimacije) • Mjesto primopredaje • Vrijeme primopredaje • Prisustvo drugih lica prilikom primopredaje (da/ne, ako da ko je bio prisutan) • Dovedemo lice odbilo da potpiše izvještaj • Primmjedbe na rad policijskog službenika (da/ne, ako je da opis)) • Potvrdu da je građanin pozvan na razgovor u službene prostorije (Obrazac: D-3) • Datum pozivanja lica • Vrijeme pozivanja lica • Način pozivanja lica • Razlog pozivanja lica • Napomena Unos podataka o dovedenom licu vrši se kao i za sva ostala lica u aplikaciji Dežurna služba, korišćenjem web servisa o licima iz CRS, ili ako lice nije crnogorski građanim, ručnim unosom podataka. Svi relevantni podaci se prosledjuju narednim fazama, bez potrebe za novim unosom podataka. Lica lišena slobode Lice koje se lišava slobode se može preuzeti iz evidencije dovededenih lica ili direktno unijeti u evidenciju lica lišenih slobode na osnovu događaja unešenog u Dežurnu službu. Može se lišiti slobode na osnovu događaja koji je kvalifikovan kao prekršaj ili krivično djelo Ukoliko se radi o događaju koji je kvalifikovan kao Prekršaj Javnog reda i mira, a ima za posljedicu lišenja slobode lica, postupajući Inspektor popunjava Službenu zabilješku tog tipa (Prilog 1). Svi relevantni podaci se prosledjuju narednim fazama, bez potrebe za novim unosom podataka. Softver mora da omogući službeniku da unese najmanje sledeće podatke iz Službene zabilješke kao i štampu iste • Organizaciona jedinica - organ koji lišava/zadržava • Datum • Ime lica • Prezime lica • JMBG • Ime oca • Ime majke • Djevojacko prezime majke • Datum rodjenja • Mjesto rodjenja • Država rođenja • Prebivalište i adresa stana • Državljanstvo • Broj telefona • Na osnovu čega je utvrđen identitet • Lične karte • Pasoša • Vozačke dozvole • Ostalo • Datum I vrijeme lišenja slobode • Zakonski osnov lišenja slobode (Član, Stav i Tačka Zakona) • Opis dogadjaja • Obavješten koji sudija za prekršaje • Kada je obavješten sudija za prekršaje, Datum i vrijeme • Kada je sudija naložio dovođenje lica • Sredstva prinude jesu-nisu, i ako jesu koja su upotrebljena • Povrede od upotrebe sredstava prinude • Ko je obavješten o privodjenju od strane uhapšenog lica Ukoliko se radi o događaju koji je kvalifikovan kao Krivično djelo, a ima za posledicu lišenja slobode lica, postupajući Inspektor popunjava Službenu zabilješku tog tipa (Prilog 2) Svi relevantni podaci se prosledjuju narednim fazama, bez potrebe za novim unosom podataka. Softver mora da omogući službeniku da unese najmanje sledeće podatke iz Službene zabilješke kao i štampu iste: • Organizaciona jedinica - organ koji lišava/zadržava • Datum • Ime lica • Prezime lica • JMBG • Ime oca • Ime majke • Djevojačko prezime majke • Datum rodjenja • Mjesto rodjenja • Država rođenja • Datum I vrijeme lišenja slobode • Zakonski osnov lišenja slobode (Član, Stav i Tačka Zakona) • Opis dogadjaja • Obavješten koji postupajući Tužilac • Kada je obavješten postupajući Tužioc, Datum i vrijeme • Kvalifikacija krivičnog djela • Datum I vrijeme privođenja u Tužilaštvo • Sredstva prinude jesu-nisu, i ako jesu koja su upotrebljena • Povrede od upotrebe sredstava prinude • Ko je obavješten o privodjenju od strane uhapšenog lica Osim dijela podataka koji se odnosi na Službenu zabilješku, postupajući Inspektor unosi, po potrebi, i ostale operativne podatke Softver treba da omogući unos i ostalih Operativnih podataka: Mjesnu nadležnost Tužioca Lične karakteristike lica (tetovaže, ozlede, deformacije…) Zavisnosti, bolesti ili sklonosti Napomenu o ponašanju lica tokom hapšenja (otpor, sklonost bjekstvu…) Napomenu ako se radi o više lica, koja lica ne bi trebalo da borave u istoj prostoriji Spisak oduzetih predmeta koja mogu biti vezana za krivično djelo, omogućiti vezu podataka sa postojećim u aplikaciji Dežurna služba. o Ako je lice strani državljanin Ime i prezime Policijskog službenika za strance koji je obavješten Datum I vrijeme obavještenja Diplomatsko konzularno predstavništvo koje je obavješteno Datum I vrijeme obavještenja Kome je informacija dodatno poslata: • Inspektor za stance • Vojna policija • Diplomatsko Konzularno Predstavništvo • Datum I vrijeme obavještenja Zadržana lica Lice koje se zadržava mora se preuzeti iz evidencije lica lišenih slobode Softver treba da: • Omogući uvid služenicima u sve prethodno unijete informacije • Obavjesti službenike u pritvorskoj jedinici o procesu privođenja, broju lica kao i eventualnim napomenama bitnim za ovaj proces. • Omogući unos podataka sa Zapisnika o obezbjedjenju lica lišenog slobode/ zadržanog lica u momentu privođenja (Prilog 3, Polja broj 2, 3, 4, 5, 7) • Ime i prezime službenika koji predaje lice (Lista) • Datum I vrijeme preuzimanja (Sistemski sat) • Ime i prezime službenika koji preuzima lice (Lista) • Podaci o dokumentu o zadržavanju (Službena zabilješka) • Prisustvo alkohola (Da/Ne) • Prisustvo psihoaktivnih supstanci (Da/Ne) • Odbio testiranje (Da/Ne) • Testiranje nije vršeno (Da/Ne) • Vidne povrede (Da/Ne) • Lice se žali na povrede (Da/Ne) • Lice ima potrebu za ljekovima ili medicinskom pomoći (Da/Ne) • Da li je lice sklono samoubistvu/samopovredjivanju (Da/Ne) • Da li je lice zavisnik (alkohol, narkotici …) (Da/Ne) • Da li lice koristi terapiju ili medikamente (Da/Ne) • Da li je lice klaustrofobično (Da/Ne) • Da li lice boluje od zaraznih bolesti (Da/Ne) • Da li lice trenutno u nekoj fazi religijskog ili zdravstvenog posta (Da/Ne) • Ako jeste, kojeg • Napomena • Privremeno oduzimanje stvari … • Naziv i opis oduzetih stvari • Količina/Broj oduzetih stvari • Količina/Broj vraćenih stvari • Napomena • Informativni list • Primio/Odbio Informativni list za lice (Da/Ne) • Ljekarska pomoć (višestruki unos) • Pružena ljekarska pomoć (Da/Ne) • Datum I vrijeme pružanja pomoći • Mjesto pružanja pomoći • Ustanova/institucija pružanja pomoći • Ime i prezime ljekara • Napomena • Ko je inicirao pomoć • Žalba na rješenje o zadržavanju • Lice uložilo žalbu na rješenje o zadržavanju (Da/Ne) • Datum I vrijeme preuzimanja žalbe • Službenik koji je preuzeo žalbu (Lista) • Datum I vrijeme predaje žalbe nadležnom organu • Naziv nadležnog organa • Pritužba na rad Policijskih službenika • Lice podnijelo pritužbu na rad Policijskih službenika (Da/Ne) • Datum I vrijeme preuzimanja pritužbe • Službenik koji je preuzeo pritužbu (Lista) • Datum I vrijeme predaje pritužbe nadležnom rukovodiocu • Službenik koji je predao pritužbu Praćenje vremena i rokova u vezi uhapšenih lica Softer mora blagovremeno da informiše Postupajućeg Inspektora, Šefa Dežurne službe i Službenike u pritvorskoj jedinici o svim važnim rokovima u vezi zadržanih lica Praćenje promjena u vezi uhapšenih lica Softver treba da omogući i evidentiranje svih ostalih promjena koje se tiču zadržanih lica, a definisana su Zapisnikom o obezbjedjenju lica lišenog slobode/ zadržanog lica (Prilog 3, Polja broj 8, 9, 10 • Smještanje, izvođenje i preuzimanje lica • Dalji postupak - sprovodni list • Prestanak daljeg zadržavanja Slanje notifikacije i informacije kroz Infostream, ulogama koje su definisane, o promjeni statusa lica. 6. Pregledi i izvještaji - Izvještaj o zadržanim i lica lišena slobode za period (Prilog 4) - Izvještaj o dovedenim licima ( U okviru postojeće forme za pretraživanje potrebno je dodati tab za pretraživanje dovedenih lica) Obzirom da su navedeni prilozi, službena policijska akta, uvid u iste može se ostvariti u službenim prostorijama MUP-a. 7. Licence MUP posjeduje sledeđe licence: • Devexxpress universal kontrole • Oracle DB • MSSQL Enterprise • Windows server 2022 Ponuđač je obavezan da svojom ponudom obuhvati sve licence/biblioteke neophodne za rad ponuđenog rješenja. Ukoliko se pojavi potreba u fazi implementacije za kupovinom dodatnih biblioteka i/ili licenci iste mora da nabavi dobavljač bez dodatnih troškova za MUP. 8. Faze izrade softverskog rješenja Faza 1 - upoznavanja sa postojećim sistemom: U ovoj fazi izabranom ponuđaču biće omogućen uvid u postojeće aplikacije, realizovane web servise, bazu podataka, omogućeno podizanje razvojnog/testnog okruženja, kao i pružena sva potrebna tehnička pomoć kako bi se upoznao sa postojećim rješenjima. Ova faza će obezbijediti izabranom ponuđaču poznavanje evidencija/registara, servisa i kompletnog sistema kako bi mogao na adekvatan način realizovati fazu 2. Faza 2 – funkcionalna analiza Obaveza Dobavljača je da izradi dokument (u daljem tekstu: Funkcionalni zahtjevi) koji predstavlja Specifikaciju funkcionalnosti produkta i koji treba da sadrži najmanje: aktivnosti koje se planiraju izvesti kao zahtjevi, izvore, aktere, ulazne podatke/dokumente, izlazne dokumente, model podataka, preliminarni user interface, validacije i poslovna pravila (workflou) za svaki proces ponaosob, arhitekturu sistema. Funkcionalne zahtjeve treba da odobri ili da primjedbe MUP. Ako je MUP dao primjedbe na Funkcionalne zahtjeve Dobavljač je dužan da ih ispravi u roku od pet dana i dostavi MUP-u na odobrenje. Dobavljač ne može pristupiti realizaciji posla prije nego što dobije pisanu saglasnost MUP-a na dokument Funkcionalni zahtjevi. Ako Dobavljač i MUP ne usaglase Funkcionalne zahtjeve, odnosno ako MUP ne potpiše saglasnost na funkcionalne zahtjeve Ugovor o izvršenju usluga koje su predmet ovog projektnog zadatka biće raskinut bez ostavljanja dodatnog roka. Faza 3 - implementacija i migacija postojećih podataka U ovoj fazi Dobavljač će da razvije zahtjeve tražene projektnim zahjtevima i usaglašenom funkcionalnom analizom. Obaveza izabranog Dobavljača u ovoj fazi je i da za poslove definisane u Projeknom zadatku dostavi predlog testova operativne primopredaje. Testove operativne primopredaje treba da odobri ili da, u pisanoj formi, primjedbe MUP u roku od 10 dana od njihovog dobijanje od strane izabranog Dobavljača. Ako je MUP dao primjedbe na Testove oprativne primopredaje izabrani Dobavljač je dužan da ih ispravi u roku od pet dana i dostavi MUP-u na odobrenje. Ako po dobijanju predloga Testova oprativne primopredaje MUP ne da primjedbe u roku od 7 dana smatra se da je iste odobrio. Predlog testova treba da bude u sledećoj formi: • Broj testa: • Naziv testa: • Veza sa: Funkcionalni zahtjevi za fazu : • Koraci u sprovođenju testa: • Očekivani rezultati: 4 Faza – Testiranje prihvatljivosti U ovoj fazi vrši se finalno testiranje prolaskom kroz testove opearativne primopredaje. Ako sistem ne zadovoljava kriterijume prihvatljivosti, Poručioc će Dobavljaču dostaviti obavještenje u pisanoj formi navodeći zašto je sistem neprihvatljiv. Dobavljač će imati 15 radnih dana od dana prijema obavještenja da ispravi nedostatke. Poručioc će zatim da izvrši inspekciju, testiranje i ponovnu procjenu sistema. Ako sistem i dalje ne zadovoljava kriterijume prihvatljivosti, Poručioc će imati sledeće opcije: • ponavljanje procedure koja je gore navedena, ili • da prekine ovaj Ugovor bez ostavljanja dodatnog roka. Nakon završetka finalne razvojne faze navedene u vremenskom rasporedu u Ponudi, testiranje prihvatljivosti će biti izvršeno na sistemu u njegovoj cjelosti kako bi se utvrdilo da li sismte zadovoljava kriterijume prihvatljivosti i da li radi na način koji suštinski odgovara Specifikacijama u Projektnom zadatku. Poručioc će imati maksimum deset (10) radnih dana da izvrši takvo testiranje. Ako završeni sistem ne zadovoljava kriterijume prihvatljivosti, stranke će pratiti procedure o prihvatljivosti navedene u prethodnim tačkama. Ako i kada se na testovima prihvatljivosti utvrdi da je razvijeni sistem nakon završetka bilo koje razvojne faze u skladu sa kriterijumima prihvatljivosti, Poručioc će odmah obavijestiti Dobavljača da je razvijeni sistem prihvatljiv. Dobavljač se obavezuje da detaljno testira sve naknadne verzije (release), nakandna poboljšanja i nadogradnje. Faza 5 - Obuka U ovoj fazi će se detaljnno obučiti administratori za administriranje kompletnog sistema, kao i sa arhitekturom Sistema, prezentovaće se source kod, proći kroz konfigurabilnosti sistema…. Faza 6 - Puštanje u produkciju Obaveza izabranog ponuđača je da nakon uspješno sprovedenih testova operativne primopredaje je da aplikaciju instalira na produkcionom okruženju i da preda: • Detaljan tehnički opis produkcionog okruženja (detaljno šta je sve instalirano na aplikativnom i web serveru, procedure izmejne pristupnih podataka, opis svih konfiguracionih fajlova, opis backup politike, preduslovi za rad klijentskog dijela aplikacije i slično). • Izvedeno stanje sistema • Detaljno uputstvo za administraciju aplikacije • Detaljno korisničko uputstvo. 9. Rokovi implementacije Rok (T predstavlja datum potpisivanja ugovora) Faza I T + 1 mjesec; Faza II T + 3 mjeseca - Broj iteracija 3; Faza III T + 10 mjeseci; Faza IV T + 11 mjeseci; Faza V T + 12 mjeseci; Faza VI T + 12 mjeseci; Broj iteracija – predstavlja broj koliko puta dobavljač može dostaviti predlog funkcionalne analize na usaglašavanje. Obaveza ministarstva je da u roku od 7 radnih dana pisanim putem ili putem maila dostavi primjedbe dobavljaču na predlog dostavljenih dokumenata iz Faze 2. Ukoliko se ne usaglasi predlog funkcionalne analize u predviđenom broju iteracija, ovaj ugovor će se raskinuti bez obaveze plaćanja dobavljaču. Količina: 1 sistem DOKUMENTI 1. Projektni zadatak Za Partiju 1 (1) (1).pdf https://cejn.gov.me/api/common/downloadFile/2169083 2. TENDERSKA DOKUMENTACIJA.docx https://cejn.gov.me/api/common/downloadFile/2173136 3. SCAN0325.PDF https://cejn.gov.me/api/common/downloadFile/2292109 4. P1.PDF https://cejn.gov.me/api/common/downloadFile/2344443 5. P2.PDF https://cejn.gov.me/api/common/downloadFile/2344444 6. P3.PDF https://cejn.gov.me/api/common/downloadFile/2344446 7. P4.PDF https://cejn.gov.me/api/common/downloadFile/2344448
0 сопоставленных платежей
Сопоставленных казначейских платежей пока нет.
Сопоставление эвристическое: по нормализованному названию субъекта и 24-месячному окну платежей. Открыть историю платежей поставщику для полного контекста.
| Лот | Статус | Оценка | Присуждено | Дата контракта |
|---|---|---|---|---|
| Projektni zadatak za izradu aplikacije Pretrage, izradu API za eksterne organe, kao i integraciju eksternih WEB servisa | Присуждено | — | 74 500 € | 4 апр. 2025 г. |
| Održavanje i dorada softvera za Registar boravka do 90 dana | Присуждено | — | 39 900 € | 4 апр. 2025 г. |
| Izrada aplikacije za unos zabrana za prelazak državne granice | Присуждено | — | 9 900 € | 4 апр. 2025 г. |
| Dorada aplikacije Dežurna služba | Присуждено | — | 39 000 € | 4 апр. 2025 г. |
В этой категории контракты обычно заключаются на 99 % от оценочной стоимости (средняя половина 94 %–100 %), по 616 присуждённым тендерам. Типичный контракт — 17 927 €.