Kako se stvarao Inženjer poslovnih zahtjeva u HPA (Case Study)
Ivan Šćepanović PDS: Informatički menađment Predmet: Upravljanje projektima
Inženjer poslovnih zahtjeva (1) IPZ mora znati dvije poslovice i dvije slike da bi kvalitetno obavljao svoj posao
Inženjer poslovnih zahtjeva (2)
Prije 8 godina, kad sam preuzeo Odjel za ICT, jedan od prvih problema koji mi se ukazao bio je kako korisnika odvojit od programera.
Dio većeg problema: Uvesti metodologiju (red) u proces razvoja softvera
Inženjer poslovnih zahtjeva (3)
Koraci ka rješavanju problema bili su:
UVOĐENJE HELP DESKA
Inženjer poslovnih zahtjeva (4)
DOŠKOLOVALI SMO 2 PROGRAMERA ZA PROJEKTANTA INFORMACIJSKIH SUSTAVA (Arhitekt aplikacija)
Inženjer poslovnih zahtjeva (5)
I tako smo razmišljali i razmišljali i ……………
……….. i odlučili dati šansu inženjeru poslovnih zahtjeva
Inženjer poslovnih zahtjeva (6)
Da li je bliži tehnologiji ili poslovnim procesima? => Poslovnim procesima Što od tehnološkog dijela mora znati? => Nužno potrebno Kojoj strani treba više služiti? => Poslovnoj strani
Inženjer poslovnih zahtjeva (7)
U dogovoru sa arhitektom aplikacije dogovorili smo izgled, oblik i sadržaj dokumenta koji će biti podloga za razvoj svakog novog informacijskog sustava.
Inženjer poslovnih zahtjeva (7a) IPZ poštuje točno određenu proceduru kod razvoja novog softvera: 1. Definirati globalnu sliku sustava 2. Definira poslovne procese u obliku: Tko = Aktivnost = Prateći obrazac 1. Opširnije pojašnjenje poslovnog procesa 2. Analiza postojećeg stanja (podaci u exelicama?) 3. Prikupiti sve prateće obrasce sustava 4. Izvještaji iz sustava (provjera svih ulaznih parametara) 5. Funkcionalna specifikacija 6. Plan potencijalnih rizika projekta
Inženjer poslovnih zahtjeva (8)
Funkcionalna specifikacija => uz dodatak sučelja novog softvera lako prelazi u Korisničke upute za rad na softveru Projektant preuzima i prouči cijelu pričicu dobivenu od IPZ. To je sada puno lakši dio posla nego da je on to trebao s korisnikom sve dogovarati. Sada preskačemo modeliranja, programiranje, programersko testiranje ……..
Inženjer poslovnih zahtjeva (9)
Prvi tester aplikacije sa korisničke strane. Vodi testiranje sa krajnjim korisnikom, tada na testiranju dolazi i arhitekt aplikacije, znamo povest i programera ….
Izrada korisničkih uputa za rad u aplikaciji
Implementacija => Održavanje
Inženjer poslovnih zahtjeva (10) Pismena pošta E – mail Help desk sustav
Alat u koji prikupljaš sve inpute za odražanjem sustava (exel,, share point, ...)
Inženjer poslovnih zahtjeva (11) Obratiti pažnju na ….. (1)
Svaki zahtjev od vanjskog korisnika prokomentirati s istim da se provjeri da je dobro zahtjev shvaćen Utvrditi korisničke prioritete Obavijestiš korisnika da je zahtjev gotov (programeri publish i za njih je to kraj) Zatvarat riješene stvari, imat uredne evidencije “Nategnuti konopac”
Inženjer poslovnih zahtjeva (12) Obratiti pažnju na ….. (2)
Kad predajete posao arhitektu - prenesete jednu pozitivnu energiju Paziti na obuhvat i ono što je van obuhvata, paziti da se ne analizira ono što nije predmet informatizacije Kompleksne probleme (grafička shema)
Inženjer poslovnih zahtjeva (13)
Imati folder sa svim “triki” stvarima: ◦ Pojašnjenja kompliciranijih problema kod održavanja i ostalih bitnih stvari ◦ Sve ono s čim se nisi složio, a drugi naredili da treba drugačije, pismeno uputiti šefu iznad, s obrazloženjem svog stava. Vrijednost IPZ, Help desk suradnika je u tome što jedino oni znaju kako se korisnik osjeća i mogu procijeniti njegovo zadovoljstvo nama kao izvođačima
Inženjer poslovnih zahtjeva (14)
Inženjer poslovnih zahtjeva (15)
Inženjer poslovnih zahtjeva (16)
Inženjer poslovnih zahtjeva (17) 