Izrada softverske aplikacije Elektronski dispečerski dnevnik u RDC

TEHNIČKE SPECIFIKACIJE.pdf TEHNIČKE SPECIFIKACIJE NAPOMENA: Ponuđač podnošenjem ponude prihvata navedene tehničke specifikacije i obavezan je da u slučaju dobijanja ugovora ispuni sve navedene zahteve kako sledi. Ponuđač popunjava Tabelu 4 iz tehničke specifikacije i dokument učitava uz elektronsku ponudu. 1. Uvod Predmet projekta je kreiranje, implementiranje, testiranje i pružanje tehničke podrške (tehnička podrška u garantnom roku od najmanje 12 meseci od momenta ''go live'') aplikacije Dispečerski dnevnik RDC (u daljem tekstu: EDD RDC) kroz integraciju sa platformom Integration Hub proizvođača Synsoft implementiranog u EMS AD. Synsoft sistem je specijalizovani programski paket baziran na mikroservisnoj arhitekturi, namenjen elektroenergetskim sistemima, koji se sastoji od više modula (servisa): User Manager, API Flux, Energy Flux, Schema Flux, Registry, Administration, Integration Hub . Kroz njih se obezbeđuje pokrivanje funkcionalnih specifičnosti u procesu obrade podataka i supervizija elektro -energetskih sistema iz oblasti prenosa električne energije, posebno imajući u vidu obradu podataka sa SCADA sistema, složene modele stanja različitih sistema, modele sistemskih procesa, kao i otvorenost interfejsa (REST API) prema drugim sistemima iz oblasti prenosa električne energije. Integration Hub (communication interface) obezbeđuje integraciju (povezivanje) sa eksternim sistemima kao što su: • SCADA • MMS • EDD NDC • EDOP • Radovi (dvosmerna veza) • Energy Flux • Scalar • POI – planiranje isključenja i održavanja • EPD TS • SAP Modul upravljanje vremenom • ... druge aplikacije (npr. automatsko preuzimanje vremenskih uslova i slično) Softverska aplikacijska Dispečerski dnevnik predstavlja nadogradnju modula Integration Hub (communication interface) Synsoft sistema baziranu na web -u i služi dispečerskim centrima EMS -a za upravljanje evidentiranjem događaja u elektroenergetskom i prenosnom sistemu. EDD RDC koriste operateri dispečerskih centara (u daljem tekstu: dispečeri), različiti korisnici aplikacije u skladu s pravima pristupa. EDD RDC dispečerima u smeni pruža mogućnost unosa podataka u realnom vremenu o raznim događajima kao što su promene stanja elektroenergetskog sistema, prekidi i kvarovi opreme, promena topologije mreže, problematika raspoloživosti generatora i ostal ih informacija relevantnih za rad prenosnog sistema u nadležnosti centra upravljanja koji koristi EDD RDC. EDD RDC bi trebao da osigura pouzdano čuvanje i zaštitu informacija o događajima, kao i da omogući brz i kvalitetno organizovan pristup korisnika aplikacije. Nova aplikacija se razvija da bi programski paket bio opremljen najnovijim i najsigurnijim alatima jer je stara aplikacija razvijena u zastarelim alatima. Tako bi se povećala sigurnost, brzina evidentiranja i distribuiranja informacija o radu prenosnog sistema. Potrebno je definisati infrastrukturu koju zahteva aplikacija, kako bi po potrebi obezbedila sredstva za nabavku hardvera i pratećih licenci. 2. Opšte informacije EDD RDC treba da omogući unošenje i trajno skladištenje operativnih i poslovnih podataka generisanih iz rada el ektroenergetskog sistema. Dispečerski dnevnik treba da prikazuje sve evidencije i unose koje registruje dispečer tokom jedne smene. S obzirom da EMS AD ima pet RDC-ova potrebno je da se EDD RDC instalira u svih pet centara kao jedinstvena aplikacija. Sve evidencije treba voditi tako da svaki zapis u dispečerskom dnevniku treba da bude pod jednom šifrom evidencije ( u daljem tekstu: brojem naloga). Prilikom kreira nja novog zapisa u EDD RDC potrebno je generisati jedinstveni broj naloga. Zbog toga je neophodno da se brojevi naloga generišu sa predznakom svakog RDC. Za svaki RDC se automatski generiše predznak: • 011 Beograd; • 014 Valjevo; • 021 Novi Sad; • 030 Bor; • 037 Kruševac. Nakon gore definisanog broja, broj naloga treba da započinje brojem meseca u godini, rastućim trocifrenim brojem počevši od 001 i treba da se resetuje početkom svakog novog meseca. (npr: za RDC Beograd: 011.11.226 poslednji nalog u mesecu novembru, a 011.12.001 prvi nalog za mesec decembar). Za NDC predlažem da ostane bez prefiksa. Svaka smena tre ba da poseduje svoju jedinstvenu šifru smene koja se automatski dodeljuje novoj smeni po završetku primopredaje smene. Ove šifre je nabolje organizovati prema datumima sa dodatkom slova koje označava noćnu ili dnevnu smenu (primer noćne smene 17.02.2022: šif ra smene 17022022N). Pristup aplikaciji EDD RDC treba da bude omogućen korisni cima koji pristupaju svojim username/pasword, sa posebno definisanim pravima pristupa. Administraciju korisničkih naloga potrebno je implementirati kao poseban modul koji nije na menjen dispečerima već korisnicima sa posebnim definisanim admin/supervizor pravima. 3. Arhitektura i tehnička specifikacija 3.1. Funkcionalna i tehnička specifikacija Dispečerski dnevnik RDC-a je potrebno napraviti u skladu sa sledećim principima i zahtevima: • Web aplikacija (MVC) • Mikroservisna arhitektura • Podržan istovremen rad više korisnika (multi user mode) • Prava pristupa definisana RBAC (Role Based Access Control) • Prijava korisnika korišćenjem korisničkog imena i lozinke • Bezbednost podataka • Dodavanje novih funkcionalnosti (modularnost i skalabilnost) • Konfigurabilnost (fleksibilan i efikasan sistem konfiguracije u slučaju promene biznis procesa) • Arhiviranje podataka • Generisanje predefinisanih izveštaja u različitim formatma (pdf, word, excel) 3.2. Arhitektura sistema Softversko rešenje za Dispečerski dnevnik predstavlja web aplikaciju za manuelni unos, pretragu i izveštavanje o događajima u elektroenergetskom sistemu. Prilikom unosa novih zapisa o događajima neophodno je kategorisati elemente stavki unosa u skl adu sa postojeć om klasifikacijom elemenata elektroenergetskog sistema (usklađivanje sa TIS bazom podataka). Osim ručnog unosa zapisa, web aplikacija treba da obezbedi i evidentiranje događaja iz eksternih informacionih sistema kao što su SCADA, EDD NDC, ED TS, „Radovi“, SCALAR itd . Ručni unos podataka iz drugih informacionih sistema treba da bude podržan mogućnošću operatora (dispečera) da izabere način unosa kao i mogućnošću ručnog editovanja unesenih podataka bez obzira iz kog sistema se preuzimaju, a sve u toku jedne smene. Aplikacija Dispečerski dnevnik RDC-a ima mogućnost procesiranja različitih tipova događaja koji u bazu aplikacije dolaze posredstvom Integration Hub (communication interface) komponente. Ova komponenta obezbeđuje integraciju (povezivanje) sa eksternim sistemima kao što su: • TIS baza podataka • SCADA (povlačenje signala o problemima, ispadima i njihovo povezivanje sa nalozima) • EDD NDC (preuzimanja informacija o isključenjima nekih elemenata EES) • Aplikacija ’’Radovi’’- (preuzimanje informacije o zahtevima i dozvolama) • Energy Flux (slanje obaveštenja - notifikacije) putem mobilne aplikacije • SCALAR – vremenske prilike • POI • EPD Trafostanica EMS-a • SAP Modul upravljanje vremenom • ... druge aplikacije (npr, automatsko preuzimanje vremenskih uslova, i slično) Izgled arhitekture sistema: 3.3. Integracija podataka Integration Hub ( Flux Hub ) je softverski proizvod koji omogućava povezivanje i integraciju različitih aplikacija i informacionih sistema u okviru jedne ili više organizacija. On omogućava brzo i lako povezivanje različitih sistema koji međusobno dele podatke u mikroservisnoj arhitekturi. Integration Hub podržava više pristupa za integraciju aplikacija. Različiti pristupi mogu se podeliti u četiri osnovna tipa integracije: • Prenos datoteka - svaka aplikacija proizvodi datoteke deljenih podataka koje drugi mogu da konzumiraju. Integration Hub obezbe đuje skup osnovnih operacija za rad sa datotekama, kao i mogućnost parsiranja, konverzije i programske obrade standardnih formata (XLSC, XML, JSON) • Zajednička baza podataka - aplikacije skladište podatke koje žele da dele u zajedničku bazu podataka. Ukoliko aplikacije koriste različite instance (pa čak i tipove) baza podataka, Integration Hub omogućava direktno povezivanje na baze i „presipanje“ podataka (ETL) iz jednog u drugi sistem, implementiraju ći mogućnost konekcije postojećim standardizovanim protokolima (drajverima) (JDBC, ODBC). • Daljinsko pozivanje procedura - aplikacija izloži neke od svojih procedura tako da se mogu pozvati na daljinu, a druge aplikacije ih pozivaju da bi pokrenule razmenu podataka. Za daljinsko pozivanje mogu se koristiti neki od standardnih protokola kao sto je REST, SOA, JMS, SNMP. Integration Hub ima mogućnost kako izlaganja daljinskih procedura (server) tako i pozivanja (klijent). • Razmena poruka - aplikacija se poveže na zajednički sistem za razmenu poruka (MOM – message oriented midleware) i razmenjuje podatke pomoću poruka. Ovaj metod se koristi za asinhronu integraciju slabo povezanih aplikacija (loosly coupled) u okviru distribuiranog sistema (mikroservisna arhitektura). Integration Hub implementira svoj message oriented midleware (MOM) ali se mo že konektovati i na druge/eksterne MOM sisteme koji podržavaju neki od standardnih protokola (JMS, STOMP, MQTT, REST ) Da bi konekcija ka raznorodnim softverskim komp onentama bila moguća Integration Hub implementira veliki broj standarnih protokola, upravljanja tokom podataka (dinami čko rutiranje) i obezbe đuje metode za obradu i transformaciju podataka (transformacija) tokom integracije. Integration Hub omogućava dijagram toka podataka (vizu elizaciju), monitoring toka podataka u realnom vremenu kroz web interfejs, kao i mogućnost konfigurisanja i dinamičkog pokretanja integracionih ruta kroz web interfejs za administraciju. U novoj aplikaciji EDD RDC je potrebno omogućiti korišćenje podataka iz perioda od nastanka prethodne aplikacije EDD RDC. 4. IT infrastruktura i okruženje 4.1. Softverske licence Ponuđač je dužan da u svoju ponudu uključi cenu za sve licence za sistemski i aplikativni (tzv. Third Party) softver neophodan za funkcionisanje ponuđenog softvera. Izabrani ponuđač nema pravo da od Naručioca tokom implementacije zahteva dodatne softverske licence koje povlače obavezu plaćanja za EMS AD. Za potrebne licence izabrani ponuđač je dužan da obezbedi podršku u trajanju od najmanje jedne godine od momenta puštanja u produktivni rad. 4.2. IT arhitektura platforme IT arihtektura platforme je predmet usaglašavanja predstavnika izabranog ponuđača i EMS AD tokom faze dizajn sistema. Izabrani ponuđač sačinjava predlog preporučene sistemske infrastrukture za optimalan rad budućeg sistema kao arhitekturu sistema u svom ponuđenom rešenju, odnosno strukturu, broj i funkciju aplikativnih i baznih servera koji se u njemu nalaze, sa detaljnim opisom načina rešenja za redundantnost sistema, uz opis funkcionalnosti i bezbednosnih mehanizama, koji mora biti usvojen od strane EMS AD nakon usaglašavanja. Koncept platforme u domenu IT bezbednosti mora ispunjavati uslove najbolje svetske prakse u smislu zaštite podataka od neovlašćenog pristupa i izmena. Naručilac treba da poseduje standardne sisteme za zaštitu korporativne mreže (firewall, WAF, PKI infrastruktura i slično) pri čemu je u upotrebi interni (LAN) u javni (DMZ) segment mreže. Ukoliko se za rad platforme bude koristio neki od javnih servisa (cioud, hosting u slič no), izabrani ponuđač je u obavezi da obezbedi sve zaštitne mehanizme i o tome dostavi potvrdu EMS AD. Eventualno korišćenje javnih servisa i obrada podataka na infrastrukturi koja nije u vlasništvu EMS AD moguće je samo u slučajevima kada je to tehnički opravdano i mora biti odobreno od strane EMS AD. Izabrani ponuđač, kroz dizajn sistema, mora da obezbedi primenu odgovarajuće politke lozinki (kompleksnost, periodičnost promene itd) kao i zaštitu od automatskog generisanja zahteva za registraciju (captcha). Deo platforme na resursima EMS AD mora da ima mogućnost rada na virtuelizovanoj serverskoj infrastrukturi VMware. EMC AD će za serversku infrastrukturu obezbediti resurse (VCPU, RAM, storage prostor u skladu sa usvojenom arhitektur om). EMS AD obezbeđuje Virtualizovano serversko okruženje (VMware) neophodno za instalaciju softvera i svih neophodnih komponenti za rad ponuđenog rešenja. EMS AD će za potrebe serverske infrastrukture obezbediti okvirno 16 GB RAM i 500 GB storage prostora. Opravdani dodatni resursi mory biti odobreni za korišćenje nakon faze Dizajn sistema. Izabrani ponuđač je u obavezi da EMS AD dostavi detaljnu specifikaciju sistema na osnovu koje će se konfiryrisati zaštitni mehanizmi IT mreže u vlasništvu EMS AD. Na dodeljenim virtuelnim mašinama (VM), izabrani ponuđač je obavezan da kontinuirano obezbeđuje: • redovno ažuriranje operativnog sistema i aplikativnog softvera (update/upgrade), • instalaciju i primenu svih bezbednosnih zakrpa isporučenih kroz IS naručioca • upravljanje i pravovremeno obnavljanje digitalnih sertifikata (SSL/TLS i drugih relevantnih) u dogovoru sa naručiocem, • primenu politika lozinki i ostalih mera definisanih tokom faze dizajna, • procedure za backup i restore aplikativnih komponenti koje se nalaze na tim VM , • evidenciju i izveštavanje o svim aktivnostima vezanim za bezbednosne incidente ili probleme u radu. 5. Osnovni moduli aplikacije Aplikacija EDD RDC treba da ima nekoliko osnovih funkcionalnosti implementiranih kroz sledeće delove/module aplikacije • Administracija i upravljanje korisničkim nalozima • Raspored rada dispečera • Prijavljivanje korisnika i primopredaja smene • Klasifikacija podataka i katalozi • Evidentiranje podataka o radu sistema • Generisanje i slanje Izveštaja • Dokumentacija 6. Administracija i upravljanje korisničkim nalozima Dispečer započinje rad u aplikaciji prijavom/logovanjem na sistem. Pristup aplikaciji Dispečerski dnevnik je omogućen samo za prijavljene korisnike. Neophodno je implementirati poseban modul za administraciju korisničkih naloga kome će imati pristup samo određena grupa korisnika sa Admin/Supervisor pravima. Modul za administraciju korisnika treba da omogući kreiranje, izmenu i deaktivaciju korisničkih naloga, kao i dodelu različitih nivoa pristupa tj. prava. Osnovni podaci koje jedan korisnički nalog treba da sadrži su: • Ime korisnika • Prezime korisnika • Korisničko ime • Email • Lozinka • Prava korisnika na osnovu kojih je moguće odrediti koje akcije korisnika su omogućene u aplikaciji • Pozicija u organizaciji (npr. dispečer pripravnik, operativni dispečer, koordinator – rukovodilac smene...) Potrebno je omogućiti čuvanje i dodatnih podataka za korisnički nalog koji mogu biti kasnije prošireni i definisani, npr. broj telefona i ostali kontakt podaci. 7. Raspored rada dispečera Trenutno se raspored o radu dispečera pravi u vidu u obliku .excel dokumenta. Ovaj fajl sadrži raspored rada dispečera po smenama za svaki dan (plan) u narednih mesec dana. U jednoj smeni je potrebno planirati različite uloge/kvalifikacije: • X1 Vodeći dispečer smene (u dnevnoj smeni / (u noćnoj smeni) • X2 Samostalni dispečer u smeni (u dnevnoj smeni / (u noćnoj smeni) • X3 Samostalni dispečer u smeni (u dnevnoj smeni / (u noćnoj smeni) • A Asistent dispečer na obuci (u dnevnoj smeni / (u noćnoj smeni) U okviru postojećeg RBAC (Role Based Access Control) sistema potrebno je predvideti različite kvalifikacije dispečera u smeni (samo vodeći dispečer smene može biti raspoređen na oba radna mesta u okviru jedne smene (X1, X2 i H3), ali samostalni dispečer može biti raspoređen samo na mesto dispečera X2/3. Pored neophodnih uloga u smeni moguće je definisati i dodatne statuse u planu: • O Obuka • DS Dispečerski sastanak • SP Službeni put • KS Krsna slava • 8 Redovno radno vreme • PO Plaćeno odsustvo • B Bolovanje • P Pripravnost • G Godišnji odmor • SD slobodan dan (nije raspoloživ) • Proizvoljan unos broja sati (od 1 do 8) • editabilno prazno polje Prikaz treba da sadrži drugačije bojenje vikenda i da predvidi da administrator može da obeleži dane koji se vode kao praznici drugačijim bojenjem. Modul za planiranje rada dispečera treba da prati postojeći proces koji se odvija kroz .excel tj treba da sadrži četiri funkcionalnosti: Planiranje rasporeda za dispečere za svaku smenu u planiranom mesecu. Ova forma prikazuje matricu sa X osom – dani u mesecu i Y osom – dispečeri. Rukov odilac sektora/šef službe RDC pravi plan popunjavajući matricu sa jednim od gore navedenih statusa za svakog dispečera i za svaki dan u mesecu. Potrebno je napraviti ograničenja za nemoguće unose (noćna smena pre dnevne, obuke vikendom...). Takođe ova forma treba da predvidi upozorenja kada se unese nepredviđeni režim rada, na primer tri iste smene za redom ili prebacivanje dozvoljene nedeljne norme od 60 radnih sati, veći ili manji broj zaposlenih od propisanog u jednoj smeni itd. Za sva ova upozorenja potrebano je da dispečer koji radi potvrdi da želi da radi u ovakvom režimu. Pregled popunjenosti rasporeda predstavlja matricu sa X osom – dani u mesecu i Y osom – statusi (tj uloge dispečera) iz rasporeda. Ovaj pregled omogućava jasan i sumaran pregled popunjenosti rasporeda (jasno se vidi ako za neki dan nedostaje dispečer sa određenom ulogom ili kvalifikacijom ) Sedmični (detaljni) pregled rasporeda prestavlja kalendar sa danima u sedmici i dodatim dispečerima (sa određenim kvalifikacijama) po danima. Pretraga kojom je potrebno predvideti rad dispečera tokom praznika i voditi evidenciju broja prazničnih smena za svakog dispečera. Takođe, potrebno je predvideti filtriranje rasporeda rada po dispečeru sa statistikom koliko je smena radio u toku zadatog perioda pretrage, k oliko je dana radio u režimu sa redovnim radnim vremenom. U okviru ove funkcionalnosti potrebno je predvideti i računanje preostalog broja dana godišnjeg odmora na osnovu podatka koji administrator unosi na početku svake godine. Godišnji odmor može imati dve kvalifikacije ``stari`` i ``novi``, gde se ne može trošiti novi godišnji odmor dok se ne iskoristi stari, a isto tako da se za prvi deo „novog“ godišnjeg mora koristiti najmanje 10 dana Dati modul treba da omogućava izveštavanje za izabrani mesec u .pdf formatu i to • Izveštaj za raspored rada • Izveštaj rasporeda rada za izabranog dispečera • Izveštaj za raspored dispečera u smenama Izveštaji ne treba da prikažu drugačije bojenje polja u kom je dispečer obeležio da neće biti raspoloživ. Omogućiti da, nakon završetka kalendarskog meseca Rukovodilac sektora/šef službe RDC potvrdi realizovani raspored rada dispečera i automatski, povezivanjem sa aplikacijom SAP/ upravljanje vremenom, popuni obračun sati u datoj aplikaciji. Modul treba da ima mogućnost automatskog slanja izveštaja i potrebno je predvideti kontrolu pristupa funkcionalnostima u ovom modulu dodavanjem novih prava pristupa u okviru postojećeg RBAC (Role Based Access Control) sistema. 8. Prijava korisnika i primopredaja smene Da bi dispečer započeo unos događaja o radu sistema, u aplikaciju mora prethodno da se prijavi na sistem. Na kraju smene, kada su svi zapisi dnevnika uneti, aplikacija mora da omogući zatvaranje i primopredaju smene. Neophodno je da aplikacija obezbedi izvođenje postupka primopredaje smene dispečera. Ne sme se dopustiti ’’prazan hod’’ u smislu da je u nekom trenutku trenutna smena odjavljena , a da sledeća nije prethodno prijavljena (npr. da se trenutna smena odjavi u 19:01, a da se naredna prijavi u 19:02). Za vreme primopredaje smene, za sve događaje u smeni odgovorna je trenutna smena tj. dispečeri koji trenutno predaju smenu. Primopredaja nije moguća ako nisu prisutni svi dispečeri (trenutna i sledeća smena), sem u specijanim slučajevima kada je moguće napraviti izuzetak, a što će biti detaljno def inisano u fazi izrade aplikacije. Kada stignu, dispečeri iz sledeće smene prijavljuju se u aplikaciju da potvrde svoje prisustvo i spremnost, i za vreme primopredaje ne mogu da menjaju ili ubacuju zapise. Prija va na sistem može se vršiti sa bilo kog računara na kome je aplikacija instalirana u dispečerskoj sali. • Dispečeri iz sledeće smene se prijavljuju na sistem i potvrđuju spremnost za prijem informacija označavanjem polja za potvrdu „spremno za prijem“ (ili se samom prijavom na sistem može smatrati da su dispečeri spremni). • Nakon usmene predaje, štampanja svih izveštaja i potpisivanja, odlazna smena može zatvoriti smenu. • Kada se smena zatvori, automatski se dodeljuje nova šifra smene (otvara se nova smena sa podacima o prisutnim dispečerima) i „dispečeri sledeće smene“ mogu da ubace nove zapise pa su od tog trenutka oni odgovorni za događaje u narednoj smeni. Štampani izveštaj o smeni treba da sadrži odštampane sve zapise dnevnika tokom smene koja se zatvara i primopredaje. Na kraju odštampanog smenskog izveštaja potrebno je ostaviti prostor za potpis dispečera koji predaju smenu. Nakon zatvaranja smene, zapise dnevnika treba zaštititi od promene i brisanja. Dodavanje evidencije u zatvorenoj smeni takođe treba da bude onemogućeno. U slučajevima kada je neophodna prom ena, brisanje ili dodavanje evidencije u zatvorenoj smeni, treba predvideti posebnu proceduru. 9. Klasifikacija podataka i katalozi U aplikaciji je potrebno koristiti postojeće (bez mogućnosti promene od strane administratora EDD RDC) klasifikacije podataka: • vrste objekata • elementi • događaji • uzroci • uticaji • oprema • relejna zaštita • sopstvena potrošnja • komunikacije po kojima će se vršiti praćenje operativnih događaja. Na osnovu klasifikacija potrebno je implementirati šifrarnike koji će se koristiti u aplikaciji i prikazati listu vrednosti u poljima (koja se pojavljuju u obrascima za evidenciju podataka) na osnovu kojih korisnik može odabrati željenu vrednost a administrator EDD RDC dodati novu za sledeće kategorije prilikom unosa : • Manipulacije • Elementi elektoenergetskog sistema • Isključenja • Rad APU • Vremenski uslovi • Tip obaveštenja 10. Evidentiranje podataka o radu sistema Da bi se jedan događaj evidentirao potrebno je obezbediti najmanje: • Nedvosmislenu identifikaciju događaja i aktivnosti o radu sistema • Identifikaciju vremena događaja ( vreme koje se upisuje može biti različito za različite događaje. N a primer, ukoliko se radi o ispadu nekog elementa, vreme može biti upisano ručno (prethodno provereno na SCADA sistemu ili sa rukovaocem T S) ili automatski povučeno sa SCADA sistema, ali obavezno sa mogućnošću ručne korekcije od strane dispečera. • Nedvosmislenu identifikaciju elemenata elektroenergetskog sistema (u smislu manipulacije ili ispada ili obaveštavanja u slučaju aktivnosti u radu sistema). • Osnovne karakteristike događaja u radu sistema ili aktivnosti u radu sistema • Identifikaciju drugih bitnih karakteristika događaja u radu sistema • Tekstualni opis događaja Svakom zapisu dnevnika treba automatski dodeliti vreme kada je upisan u bazu podataka i korisnika koji ga je upisao (Ovo vreme se razlikuje od gore opisane vremenske identifikacije događaja). Sve promene naloga/zapisa će sistem automatski evidentirati, tako da se mora sačuvati trag prethodnog sadržaja, vreme promene i korisnik koji je izvršio promenu. Ovim podacima može pristupiti samo ovlašćeno lice. Promene/dopune naloga u otvorenoj smeni su dozvoljene samo za prijavljene korisnike u toj smeni. Specifične promene u zatvorenim smenama su dozvoljene samo ovlašćenom korisniku EDD RDC-a, Informacija o promeni se pridružuje promenjenom nalogu. Ostale promene izvesti preko dopune događaja/smene. Informacije o radu sistema koje dispečer treba da unosi u Dispečerski dnevnik moguće je podeliti na nekoliko vrsta/tipova : • Evidentiranje podataka uklopnih stanja i topologije sistema o Evidentiranje podataka o manipulacijama (isključenjima i uključenjima) o Evidentiranje podataka o ispadima (outage) • Evidentiranje dozvola za izvođenje radova u EES • Evidentiranje informacija o proizvodnji el. energije ( npr. ulazak u pogon posle remonta, ispadi generatora...) • Evidentiranje informacija o sopstvenoj potrošnji i komunikacionim sistemima (relevantne dozvole D4 iz EPD TS, prekidi komunikacije,.... ) • Evidentiranje informacija o prekidima napajanja i ispadima proizvodnih jedinica • Evidentiranje napajanja prioritetnih kupaca/proizvodnje Zajedničke karakeristike za sve tipove događaja su: • Broj naloga (automatski se generiše, može imati prefiks u zavisnosti od tipa) • Osoba koja vodi evidenciju (prijavljeni korisnik) • Tip zapisa (izbor jednog od gore navedenih tipova događaja) sa predefinisanim maskama za unos podataka u zavisnosti od tipa događaja • Element sistema (izbor sa liste vrednosti) • Naslov zapisa evidencije (automatski se generiše, tip + element sistema) – korisnik može da izmeni tekst • Datum/vreme događaja (automatski se generiše – vreme, moguća manuelna ispravka/unos) • Napomena (automatski prenos iz planera ispada ili ručni unos) • Odgovorno lice od koga je primljen i/ili kome je dat nalog iz: NDC-a, trafostanice, elektrane ili drugog KPS , • Dodatni kategorisani podaci (planirani/neplanirani /remont/hitno, povezani nalozi za rad, povezani drugi zapisi evidencije itd.) • Specifičnosti za taj događaj (na primer, ako se radi o ispadu, mora postojati polje gde se upisuje tip relejne zaštite koja je reagovala i dodatna polja za k arakteristike te zaštite... npr . distantna zaštita, stepen 2, faza ’’0’’, zemljospoj, lokator 54 km). 10.1. Evidentiranje podataka o manipulacijama (isključenjima i uključenjima) Aplikacija treba da omogući evidentiranje podataka o manipulacijama (isključenjima i uključenjima) kao i evidentiranje podataka o prekidima iz tačaka 10.7 i 10.8. Promenu statusa topologije mreže registruje SCADA sistem, i ove podatke je neophodno povezati sa bazom podataka Kategorizacije elemenata EES -a i preneti u aplikaciju EDD RDC preko odgovarajućih interfejsa ili upisom ovih podataka u bazu aplikacije EDD RDC. Pošto se status topologije mreže prenet iz postrojenja prenosi u SCADA sisteme, može doći do pogrešnog prenosa, prekida prenosnog puta ili nevalidnog upisa pa zbog toga dispečer mora imati mogućnost da ručno ažurira/ispravlja zapise u EDD RDC. Aplikacija treba da omogući evidentiranje sledećih podataka: • Standardni podaci koji se unose za sve evidencije • Krajevi (ako postoje) elementa (automatski ili ručni unos - izbor sa liste vrednosti preuzimanje podataka iz ED TS) • Polje za napomenu odnosno opis događaja/razlog manipulacije, ukoliko je potrebno 10.2. Evidentiranje podataka o ispadima (outage) Aplikacija treba da omogući da određena grupa evidencija bude logički povezana u jednu celinu koja se unosi u unapred definisanu formu kao u sadašnjem EDD RDC , ispunjeni dodatnim (master) informacijama i povezani sa zapisom u bazi podataka koji mogu da se unose automatski/ručno. Takođe, aplikacija treba da vrši evidentiranje podataka o prekidima iz tačaka 10.7 i 10.8. Aplikacija treba da omogući evidentiranje sledećih podataka: • Standardni podaci koji se unose za sve evidencije • Krajevi (ako postoje) elementa (automatski ili ručni unos - izbor sa liste vrednosti) • Vrsta zaštite (automatski ili ručni unos - izbor sa liste vrednosti) • Signal zaštite (automatski ili ručni unos - izbor sa liste vrednosti) • Datum/vreme okidanja (automatsko ili ručno ubacivanje ako nema zapisa u SCADA sistemu) • Kvalitet rada (automatski ili ručni unos - izbor sa liste vrednosti) • Uzrok ispada ukoliko je poznat (predefinisana lista i mogućnost dodatnih izmena-editovanja) • Polje za napomenu odnosno opis događaja ukoliko je potrebno (primer: DV je ispao zbog neovlašćene seče šume na trasi, pri čemu je došlo do pucanja faznog provodnika u fazi ’’8’’. Nema povređenih lica, na licu mesta se vrši uviđaj MUP...) • Manipulacije prouzrokovane ispadom (ukoliko ih je bilo) • Polje gde se opisuju eventualne posledice događaja U slučaju havarije: aplikacija treba da omogući generisanje unapred definisanog dokumenta u doc i pdf formatu koji opisuje havariju. 10.3. Evidentiranje dokumenata za rad Podaci o dokumentima za radove u EES se obezbeđuju iz eksternog planera tj. aplikacije ’’Radovi’’ i POI. Aplikacija treba da omogući pregled dokumenata za rad (izdatih i zatvorenih) i ubacivanje u naloge za manipulacije. Takođe, sve dozvole koje su trenutno na snazi moraju imati crveni ’’ flag’’ koji je lako uočljiv za sve dispečere u smeni. 10.4. Sopstvena potrošnja Aplikacija treba da omogući evidentiranje podataka o radu sopstvene potrošnje automat skim prevlačenjem sa SCADA sistema ili ručnim unosom. 10.5. Evidentiranje informacija o komunikacionim sistemima Aplikacija treba da omogući evidentiranje podataka o stanju komunikacionih sistema automatskim prevlačenjem sa SCADA sistema ili ručnim unosom: • Oprema (izbor sa liste vrednosti) • Tip događaja (izbor sa liste vrednosti) • Preuzimanje podataka o relevantnim D4 dozvolama iz EPD TS • Dodatni kategorisani podaci 10.6. Evidentiranje važnih informacija (za primopredaju smene) o statusima glavnih elemenata elektroenergetskog sistem Aplikacija treba da omogući primopredaju smene u kome bi se evidentirali sledeći podaci: • Elementi kojima je promenjeno uklopno stanje u smeni koja se završava, • Elementi čije je isključenje najavljeno u smeni koja se završava, • Naponske prilike, • Elementi ili oprema koji su neraspoloživi duže od jednog dana. Izveštaj treba da sadrži tip elementa, naponski nivo, naziv elementa, razlog neraspoloživosti, reagovanje uređaja za APU, vremenski period neraspoloživosti, vreme trajanja neraspoloživosti. • Podaci o Proizvodnji, podaci o ostaloj opremi (SKADA, IKT sistem..), • Učitani rezultati analize sigurnosti • Stanje proizvodnih kapaciteta Podaci o stanju proizvodnih kapaciteta u elektoenergetskom sistemu treba automatizovati, tako da se tracking vrednost automatski računa u procesu importa. Unosiće se pre primopredaje smene. 10.7. Evidentiranje informacija o prekidima napajanja Aplikacija treba da omogući i posebno evidentiranje prekida napajanja kroz posebnu formu koja treba da sadrži sledeće podatke: • Standardni podaci koji se unose za sve evidencije • EEO koji je ostao bez napajanja (izbor sa liste vrednosti) • Vrsta prekida (planiran – neplaniran) • Uzrok prekida isporuke (izbor sa liste mogućih razloga: EMS, Drugi subjekat, treća strana..). U slučaju izbora EMS-a obezbediti podmeni izbor sa liste mogućih razloga: prolazan/trajan kvar na DV... • Ispala snaga i vreme trajanja prekida (vrednost u MW unosi korisnik, a vreme trajanja prekida i neisporučena energija se generišu na osnovu unosa) • Naziv i broj mernih mesta na kojima je prekinuta isporuka iz padajućeg menija • Dodatni kategorisani podaci • Komentar o prekidu 10.8. Evidentiranje informacija o prekidima proizvodnje Aplikacija treba da omogući i posebno evidentiranje prekida proizvodnje kroz posebnu formu koja treba da sadrži sledeće podatke: • Standardni podaci koji se unose za sve evidencije • EEO koji je prestao sa proizvodnjom (izbor sa liste vrednosti) • Vrsta prekida (planiran – neplaniran) • Uzrok prekida proizvodnje (izbor sa liste mogućih razloga: EMS, Drugi subjekat, treća strana..). U slučaju izbora EMS-a obezbediti podmeni izbor sa liste mogućih razloga: prolazan/trajan kvar na DV... • Ispala snaga i vreme trajanja prekida (vrednost u MW unosi korisnik, a vreme trajanja prekida i neisporučena energija se generišu na osnovu unosa) • Podacio o ulasku u pogon/raspoloživosti • Dodatni kategorisani podaci • Komentar o prekidu 10.9. Pridruživanje dokumenata nalozima (attachment) Za sva dokumenta koja su nastala van aplikacije, a neophodno je da budu deo naloga, aplikacija mora da omogući njihovo pridruživanje nalogu. U okviru aplikacije treba omogućiti prikaz poslatih i primljenih email poruka bez napuštanja aplikacije. Ovaj servis bi trebalo da povlači poslate i primljene email poruke sa predefinisanog email naloga i da ih prikazuje u aplikaciji. Ukoliko pristigne nova poruka, korisnik bi trebalo da budu obavešten. Dokumenta se „upload“-uju i vezuju za sam nalog. Podržani formati: - PDF - Word - Excel - CSV - JPG - PNG Dati modul treba da predvidi mogućnost povezivanja sa aplikacijom EDOP (elektronski dnevnik operativnog planiranja) korišćenjem ``activity stream`` funkcionalnosti. 10.10. Problematika pogona mreže Omogućiti unos teksta koji se formira od odabranih obaveštenja unetih u smeni. Formiranje informacije može se omogućiti odabirom od strane dispečera već unetih obaveštenja kao i manuelnim unosom. 10.11. Nezavršeni događaji Aplikacija treba da omogući završavanje događaja tipa: Ispad, Rad TSU, Rad TK i Sopstvena potrošnja. 11. Generisanje i slanje izveštaja Neophodno je da aplikacija EDD RDC omogući pokretanje unapred definisanih izveštaja i lako kreiranje različitih izveštaja na osnovu uskladištenih podataka. Aplikacija treba da omogući pregled i štampanje posebnih izveštaja za proizvoljno vreme koji sadrži evidentirane podatke o: • Manipulacijama Uključenjima/Isključenjima • Ispadima (outage) • Dokumentima za rad • Statusima elemenata elektroenergetskog sistema • Prekidima napajanja i prekidima proizvodnje • Izveštaj o angažovanju rukovaoca DU TS • Obaveštenja (nespecificirani podaci) Takođe aplikacija treba da omogu ći štampanje izveštaja o smeni koji treba da sadrži od štampane sve zapise dnevnika tokom smene koja se zatvara i primopredaje i to poređane po rednim brojevima naloga. Aplikacija treba da omogući distribuciju predefinisanog izveštaja o smeni elektronskom poštom definisanim grupama. Aplikacija treba da omogući izradu i distribuciju predefinisanog objedinjenog izveštaja o smeni svih RDC+NDC (omogućiti izradu grupa centara prema potrebi izveštaja: bilo koji/svi RDC i/ili NDC respektabilno) elektronskom poštom definisanim grupama koji treba da budu hronološki poređ ani na osnovu vremena zauzimanja naloga iz pojedinih centara upravljanja ili objedinjeno po centrima upravaljanja (NDC, RDC Bgd, RDC Va, RDC NS, RDC Bor i RDC Kš). Na osnovu unetih podataka u aplikaciju o ispadima, kvarovima i manipulacijama kao i prekidima napajanja potrošnje i proizvodnje aplikacija treba da omogući generisanje i distribuciju izveštaja o poremećaju. Nakon kreiranja izveštaja potrebno je omogućiti automatsko čuvanje izveštaja na predefinisanoj lokaciji u okviru foldera Dispečerska dokumentacija nako n primopredaje smene. Radi lakše pretrage potrebno je uvesti novu opciju u okviru polja ''Tip naloga'' čije ime će biti definisano konceptualnim dizajnom. Aplikacija treba da omogući kreiranje i distribuciju 1. i 2. informacije o pokretanju ekipe elektronskom poštom definisanim grupama. Aplikacija treba da omogući kreiranje i distribuciju izveštaja o angažovanju rukovaoca DU TS elektronskom poštom definisanim grupama. Aplikacija treba da omogući kreiranje, slanje, prijem i prikaz konverzacije SMS-om prema/od definisanih grupa ili pojedinca Aplikacija EDD RDC treba da omogući pregled različitih tipova datoteka (PDF, slike u popularnim formatima, MS Excel, MS Word, audio/video datoteke) prilikom procesa evidentiranja događaja. Aplikacija treba da omogući kreiranje izveštaja koji bi prikazivao neraspoloživost elemenata prenosnih kapaciteta u nekom vremenskom periodu. Izveštaj treba da sadži tip elementa, naponski nivo, naziv elementa, razlog neraspoloživosti, reagovanje uređaja za APU, vremenski period neraspoloživo sti, vreme trajanja neraspoloživosti, broj koliko puta je element bio neraspoloživ u zadatom vremenskom periodu, kao i kumulativno vreme neraspoloživosti za svaki element u zadatom vremenskom periodu. Ovaj izveštaj je potrebno lako filtrirati po svim kriterij umima koji se koriste za kreiranje izveštaja. Potrebno je ovakav izveštaj generisati u .xls i .pdf formatu. Svaki priloženi dokument treba da ima opciju da bude označen kao „sadržaj dokumenta treba da bude odštampan u izveštaju o smenama“ ili „samo priložen kao dodatna informacija“. Ukoliko je priložena datoteka označena za štampanje, potrebno je omogućiti pregled sadržaja datoteke i štampanje u okviru smenskog izveštaja. 12. Dokumentacija Potrebno je u meniju aplikacije dodati novi modul koji bi omogućio brz pristup dokumetima iz sledećih kategorija: • Kategorizacija • Limiti i zaštite • Karakteristike elemenata • Šeme objekata Prve tri kategorije su trenutno dostupni kao .xlsx dokumenti i dispečerima je veoma često potreban uvid i pretraga ovih informacija. Aplikacija bi trebala da omogući direktan pristup datim dokumentima (aktuelnim verzijama) bez napuštanja aplikacije. Proces kategorizacije je već prebačen u aplikaciju EDOP te treba predvideti opciju da se dispečerima učini dostupnim forma sa prikazom aktuelne kategorizacije koja se vodi aplikativno. Takođe, potrebno je obezbediti pristup svim jednopolnim i dispozicionim šemama 400 kV, 220 kV i 110 kV EES. Potrebno je predvideti i kontrolu pristupa ovom modulu dodavanjem novih prava pristupa u okviru postojećeg RBAC (Role Based Access Control) sistema. 13. Pregled dodatnih funkcionalnosti EDD RDC 13.1. Unos naloga u okviru smene: - tip naloga (manipulacije, ispadi ...definisati naknadno kao i filtriranje) - naslov - manipulacije (stavke) (pod ovim se podrazumeva unos manipulacija: mogućnos t preuzimanja signala manipulacija: • direktno sa SCADA sistema (predefinisanje filtera SCADA sistema za manipulacije), • ručni unos signala manipulacija, • mogućnost povlačenja signala manipulacija iz ED TS - mogućnost pretrage naloga po: • broju • imenu dispečera • pretraga naloga po karticama (grid) - unos napomena (napomene vezane za zatvorene događaje koja nosi informacije o radnom zadatku koji je zatvoren se direktno povlače iz aplikacije “Radovi“.) - povezivanje naloga koji su u međusobnoj vezi uz opciju biranja mogućnosti štampe (povezivanj e dva ili više naloga vezani za isti događaj ) - unos predefinisanih/ručnih imena rukovaoca, dispečera PDC-ova i DDC-ova, kao i rukovalaca razvodnih postrojenja EPS-a i KPS-a iz aplikacije „Radovi“ direktno u EDD vezano za manipulaciju. - mogućnost pretrage događaja sa SCADA sistema u EDD (ispis sa SCADA sistema direktno učitavati u EDD uz filtriranje signala pojedinih zaštita). - unos elektronskih dokumenata sa više stranica. - filtriranje primedbi upućenih tehničkoj podršci (prekid komunikacije sa trafostanicama, dalekovodnim poljem, kvar video nadzora, angažovanja rukovaoca, neraspoloživost DU, INT signal, itd...) - prikaz dozvola koje su na snazi i pozivanje dozvole klikom (veza sa aplikacijom „Radovi“) - mogućnost evidentiranja ispada i kvarova, kao i povlačenje signala sa SCADA sistema koji su u vezi sa ispadom. - nemogućnost upisa vremena uključenja elementa EES ako prethodno dozvola za radove na tom elementu nije zatvorena - pored opcije manipulacije, uvesti opciju „od ranije“ za element isključen od ranije - ispad sopstvene potrošnje TS. - izrada obaveštenja i komentara smene. - prikaz INT signala sa SCADA sistema koji se nije deaktivirao nakon 2-3 min. - evidentiranje D4 dozvola koje mogu promeniti uklopno stanje i komunikaciju sa trafostanicama (preuzimanje podataka iz ED TS). - nalozi za elektrane gde postoji izbor elektrane, kao i način angažovanja elektrane , ime dispečera NDC-a koji je izdao nalog i ime rukovaoca komande elektrane. 13.2. Izveštaj za tekuću smenu (primopredaja smene, zadržati postojeće stavke) - upis elemenata koji nisu raspoloživi duži vremenski period - evidentiranje elektrana koje su na mreži - analiza sigurnosti - upis dispečera za sledeću smenu - mogućnost štampanja izveštaja 13.3. Informisanje o promeni uklopnog stanja elemenata EES elektroenergetskog sistema i direktnog slanja istog ka EDOP. 13.4. Pomoć (inf. o brojevima telefona ljudi zaduženih za EDD) 13.5. Unos predefinisanih podataka sa Scalar-a (slika kao prilog). 13.6. Obaveštavanje o novim dokumentima sa čekiranjem sadržaja 13.7. Izveštaj o stanju proizvodnih jedinica sa SCADA sistema 13.8. Omogućiti u dnevniku prebacivanje teksta iz latinice u ćirilicu i obrnuto. 13.9. Automatska opomena da se element nalazi u nezavršenim događajima i izbacivanje iz te liste 13.10. Aplikacija mora da omogući da prilikom primopredaje smene noć/dan, automatski odabrani događaji tipa Ispad, Manipulacije, Rad TSU, Rad TK, Sopstvena potrošnja pređu u Pogonski izveštaj, kao i automatsko zatvaranje Pogonskog izveštaja za prethodni dan 13.11. Aplikacija mora da omogući da se podaci o Prekidima korisnika i proizvodnje prenesu u BI 14. Planiranje i upravljanje projektnim aktivnostima Navedena nabavka ima formu projekta i prati odgovarajuću projektnu metodologiju. 14.1. Preliminarni plan i priprema projekta Imajući u vidu aktivnosti koje je neophodno spr ovesti u procesu implementacije, očekuje se da ponuda obuhvati metodologiju implementacije predmetnog rešenja. U pripremnoj fazi projekta potrebno je dostaviti Preliminarni Plan projekta koji treba da obuhvata: • Okvirni plan organizacije i upravljanja projektom (u formi nacrta obzirom da će isti biti usaglašen u fazi pripreme projekta). • Okvirni plan projekta (kojim su obuhvaćene sve faze u toku implementacije, navedene očekivane aktivnosti sa predviđenim vremenom početka i odgovornostima učesnika na projektu). • Okvirni plan obuke korisnika (sa informacijama o potrebnim predznanjima). • Okvirni plan testiranja sistema. • Predviđene procedure upravljanja rizicima (identifikacija, verovatnoća nastajanja, značaj, odgovor). U pripremnoj fazi projekta , potrebno je usaglasiti navedene planove u saradnji sa EMS AD i integrisati ih u Poslovnik projekta, koji treba da se usvoji od strane rukovodstva projekta. Poslovnikom projekta potrebno je detaljnije definisati procedure i pravila koja će važiti na projektu EDD RDC. Poslovnik treba da sadrži: osnovne informacije o Projektu, projektnu organizaciju (odnosno informacije o projektnom timu koji će biti angažovan na realizaciji projektnih zadataka, procesima koji se odnose na rad i upravljanje Projektom), projektnu dokumentaciji koja će biti vođena tokom realizacije Proj ekta kao i proceduru prihvatanja dokumentacije, upravljanje zahtevima za izmenu, smernice za komunikaciju tokom realizacije projektnih obaveza, proces upravljanja potencijalnim rizicima i problemima, strategiju testiranja i prihvatanja rešenja. Osim navedenog obavezna je izrada/usaglašavanje Detaljnog plana projekta (vremenski gantogram) sa definisanim fazama projekta koji može da bude osnov za periodična plaćanja ukoliko se dogovori fazno plaćanje, po realizaciji određene faze projekta. 14.2. Izrada konceptualnog dizajna rešenja Nakon završetka pripremne faze projekta i usvajanja poslovnika projekta obavezna je izrada Konceptualnog dizajna EDD RDC koji treba da bude obostrano usaglašen. Konceptualni dizajn treba da definiše arhitekturu sistema kao i detaljan dizajn tehničkog i tehnološkog rešenja EDD RDC po kojem će se izvršiti implemeatacija istog. 14.3 Projektni tim EMS AD EMS AD će imenovati najrelevantnije poznavaoce poslovne problematike u stalno članstvo projektnog tima i obezbediti stalnu podršku projektu. U toku projekta angažovaće se i povremeni članovi za specifične zadatke. Projektni tim mora biti integrisan kao deo tima Ponuđača. Dok će odgovornost za implementaciju sistema biti na Ponuđaču, uloga tima EMS AD će biti da pruži pomoć Ponuđaču i obezbedi sve relevantne informacije, kako bi Ponuđač bio u mogućnosti da implementira rešenja koja su predmet implementacije 14.4 Projektna organizacija Minimalna predložena organizacija projekta koja se uobičajeno obezeđuje na sličnim projektima obuhvata: • Direktora projekta EMS AD koga imenuje EMS AD i koji promoviše implementaciju ove aplikacija u organizaciji, dodeljuje resurse potrebne za uspeh, odgovoran za nadzor implementacije rešenja i rešavanje svih pitanja koja mogu da utiču na napredak projekta. • Rukovodioce projekta sa strane EMS AD i strane Isporučioca. Odgovornost rukovodilaca projekta će biti međusobna saradnja, izveštavanje Nadzornog odbora o statusu projekta i obezbeđivanje napredka projektnih aktivnosti i isporuku ugovorenih obaveza u okviru plana. • Tim za implementaciju u koji će, pored predstavnika Isporučioca, biti uključeni relevantni predstavnici IKT, izabrani članovi poslovnih službi kao članovi tima za dizajn sistema iz EMS AD. Odgovornost tima za implementaciju je uvođenje i konfiguracija sistema, kao i stavljanje sistema u stanje operativnosti. Veoma je značajno da članovi tima za implementaciju blisko sarađuju tokom implementacije. Isporučilac će u saradnji sa EMS AD, u pripremnoj fazi projekta, usaglasiti organizacionu strukturu projekta i formirati projektne timove sastavljene od njegovih konsultanata i zaposlenih iz EMS AD koji će raditi na realizaciji projektnih aktivnosti. 14.5 Ostala podrška na projektu Pored obezbeđenja kadrova za rukovodstvo projekta i projektne timove , EMS AD će timu Isporučioca za implementaciju prema potrebi obezbediti i: • Kancelarijski prostor za tim Isporučioca dok je na lokaciji. • Pristup salama za sastanke. • Pomoć u organizaciji sastanaka sa osobljem i rukovodstvom EMS AD. Isporučilac će u saradnji sa EMS AD, u pripremnoj fazi projekta, usagl asiti specifikaciju ostale podrške projektu koju treba da obezbedi EMS AD. 15. Faze realizacije projekta Tabela 2: Faze realizacije projekta Faza 1: Priprema projekta Aktivnosti • Formiranje projektnih timova • Planiranje projekta • Izrada detaljnog plana projekta Izlazna dokumentacija • Plan organizacije i upravljanja projektom (Poslovnik projekta koji treba da obuhvati i: Plan upravljanja rizicima, Plan testiranja rešenja, Plan obuke korisnika) • Plan projekta (tok implementacije sa planiranim vremenom početka i kraja svake aktivnosti i odgovornostima) • Specifikacija podrške projektu koju obezbeđuje EMS AD Verifikacija završetka faze Izveštaj projektnog tima o uspešno realizovanim aktivnostima na pripremi projekta usvojen od rukovodstva projekta Faza 2: Izrada konceptualnog dizajna Aktivnosti • Izrada konceptualnog dizajna rešenja Izlazna dokumentacija • Konceptualni dizajn sistema – (engl. Business Blueprint) Verifikacija završetka faze Nakon uspešno realizovanih Faza 1 i 2, Naručilac i Isporučilac potpisuju Zapisnik o izvrš enoj realizaciji Faze 1 i Faze 2 , koji predstavlja potvrdu o završetku navedenih faza i osnov za plaćanje u skladu sa ugovorom. Faza 3: Implementacija rešenja (Razvoj, testiranje i puštanje u rad) • Faza 3a: Razvoj, prilagođavanje i integracija Aktivnosti • Konfigurisanje i razvoj rešenja u skladu sa zahtevanim funkcionalnostima • Prikaz razvijenog rešenja Izlazna dokumentacija • Izveštaj o realizovanoj podfazi 3a – Razvoj, prilagođavanje i integracija Verifikacija završetka podfaze Izveštaj projektnog tima o uspešno realizovanoj podfazi 3a usvojen od rukovodstva projekta • Faza 3b: Testiranje sistema Aktivnosti • Testiranje u skladu sa zahtevima konkursne dokumentacije i usvojenim Planom testiranja rešenja Izlazna dokumentacija • Dokumentacija o testiranju sistema (engl. Acceptance Testing Documentation) • Izveštaj o uspešno izvršenom testiranju Verifikacija završetka podfaze Izveštaj projektnog tima o uspešno realizovanoj podfazi 3b usvojen od rukovodstva projekta • Faza 3v: Priprema i puštanje u produkciju Aktivnosti • Priprema pred produkciju • Puštanje u rad (GoLive) Izlazna dokumentacija • Odluka projektnog tima o početku produkcionog rada Verifikacija završetka podfaze Izveštaj projektnog tima o uspešno realizovanoj podfazi 3v i uspešnom puštanju sistema u produkcioni rad usvojen od rukovodstva projekta Verifikacija završetka faze 3 Nakon uspešno realizovanih podfaza 3a, 3b i 3v, Naručilac i Isporučilac potpisuju Zapisnik o izvršenoj realizaciji Faze 3, koji predstavlja potvrdu o završetku Faze 3 i osnov za plaćanje u skladu sa ugovorom. Faza 4: Obuka korisnika Aktivnosti • Obuka za korišćenje sistema (ključnik i krajnjih korisnika) • Obuka za administraciju implementiranog rešenja (opciono) Izlazna dokumentacija • Korisnički priručnici • Tehnički priručnici • Izveštaj o izvršenoj obuci korisnika Verifikacija završetka faze Nakon uspešno realizovane obuke, Naručilac i Isporučilac potpisuju Zapisnik o izvršenoj realizaciji Faze 4, koji predstavlja potvrdu o završetku Faze 4 i osnov za plaćanje u skladu sa ugovorom. 16. Testiranje Prilkom isporuke softvera neophodno je da se dostavi lista neophodne projektne dokumentacije u fazi testiranja. Testiranje se vrši na osnovu dobijenih test scenarija. Na osnovu testiranja se vrši verifikacija softvera. Korisnici iz EMS AD će uraditi samostalno nestrukturirane testove kako bi se osigurao kvalitet dostavljenog rešenja. Testovi treba da potvrde integritet, performanse i funkcionalnosti pojedinačnih integracija i da demonstriraju njihovo funkcionisanje u integrisanom sistemskom okruženju. Ovi testovi bi trebalo da potvrde da su sve zahtevane integracije u potpunosti implementirane. U slučaju da rezultati testiranja nisu zadovoljavajući, svi uočeni nedostaci ili greške biće dokumentovani u izveštajima o neusklađenosti na osnovu kojih će se izvršiti potrebne korekcije i testiranja će se ponoviti. Ovaj postupak će se ponavljati sve dok rezultati testa ne budu pozitivni. 17. Obuka korisnika Obzirom na značaj koji sistem ima za poslovanje EMS AD, posebna pažnja mora da se posveti obuci korisnika (ključnih i krajnjih korisnika), kako bi se osiguralo da se kod njih razviju potrebna znanja i veštine. Način i rokovi za sprovođenje obuke korisnika biće definisani kroz Plan obuka u fazi pripreme projekta. Plan minimalno treba da obuhvati: • Obuku za korišćenje EDD RDC. Predviđeno je da ova obuka bude realizovana u trajanju od 2 dana po lokaciji sedišta RDC (do 15 polaznika) na kraju projekta. • Prema potrebi, obuku za administraciju i održavanje implementiranog rešenja u ukupnom trajanju od 2 dana (do 10 polaznika). Nakon završene obuke zaposleni moraju biti osposobljeni za