Razvoj projektov po naročilu

Proces izdelave novih rešitev in izvedbe projektov digitalizacije poslovanja

V tem prispevku vam poskušamo predstaviti metode, projektna pravila in dobro prakso, ki se uporablja pri razvoju novih aplikacij, spletnih storitev, portalov in drugih izdelkov, ki jih s skupnim imenom označimo kot rešitve. Do postopkov, ki jih uporabljamo v tem procesu, nismo prišli naenkrat. Skozi leta izkušenj in z izvedbo več sto projektov smo prišli do nekih spoznanj o tem, katera razvojna orodja in metode moramo uporabiti, če želimo na koncu naročnikom dostaviti izdelke, s katerimi bodo zadovoljni in bodo skozi leta uporabe upravičili investicijo. Seveda ne želimo teh korakov, faz in metod razglašati za naše lastno znanje – nasprotno, podobne metode boste našli skoraj pri vsakem sodobnem podjetju, ki se realno ukvarja z digitalizacijo ali razvojem rešitev po naročilu. Vsak se pri reševanju težav najprej ozre naokrog in poskuša najti primere dobre prakse. Metod, ki preverjeno delujejo, ni potrebno izumiti na novo.

Besedilo, ki sledi, je dokaj dolgo in verjetno za splošno javnost precej nezanimivo. Ta prispevek je zato namenjen predvsem tistim, ki se odločate za digitalizacijo nekega poslovnega procesa oziroma za razvoj neke nove programske rešitve – naj bo ta namenjena samo ozki poslovni ali vsesplošni rabi.

#1

Izvedba analize

Naši analitiki izvajajo poglobljene intervjuje z deležniki in sodelujejo tudi pri oblikovanju vsebinskih specifikacij povsod tam, kjer imamo ustrezno domensko znanje.

Analitiki lahko nudijo pomoč pri pripravi produktnih oziroma projektnih specifikacij.

Končna analiza stroškov in koristi mora biti realna.

Za številne projekte je koristna tudi analiza področja pravne regulacije v zvezi z zbiranjem podatkov ali izvajanjem določenih procesov.

Vsaka ideja o realizaciji obsežnejšega informacijskega projekta je hkrati povezana z dvomi o izvedljivosti celotne zamisli. Čeprav vemo, da bi izvedba prinesla organizacijske, ekonomske ali druge koristi, se soočamo z dilemami o stroških dela pri izvajalcu, o primernosti izbranih tehnologij in podobno.  Namen ekipe izkušenih analitikov je ravno v tem, da pomaga zagotoviti strokovne tehnične podlage in načrte za optimalno izvedbo projekta.

Analitiki nudijo pomoč pri pripravi produktnih oziroma projektnih specifikacij. Skupaj s tehničnimi eksperti in načrtovalci rešitev izvajajo poglobljene intervjuje z deležniki in sodelujejo pri:

  • definiranju seznama zahtev projekta ali produkta;
  • skupnem oblikovanju poslovnega koncepta;
  • natančnem popisu vseh pričakovanih funkcionalnosti informacijske rešitve;
  • analizi stroškovne učinkovitosti s primerjavo alternativnih možnosti;
  • oblikovanju vsebinskih specifikacij povsod tam, kjer imamo ustrezno domensko znanje;
  • analizi tveganj, s pomočjo katere v naprej izločimo očitne pomembnejše dejavnike, ki bi ovirali ali onemogočili izvedbo projekta.

 

Tudi poznavanje zakonodaje je dejavnik, ki ga ne smemo zanemariti, kadar načrtovanje tehnične rešitve trči ob dileme pravne regulacije zbiranja podatkov ali izvajanja določenih poslovnih procesov. Z ustreznimi pravnimi pojasnili se izognemo različnim laičnim interpretacijam in s tem lahko tudi previsokim ali povsem napačno ocenjenim stroškom izvedbe projekta. Celovito znanje s področja izvajanja informacijskih projektov po naročilu v ekipah zbiramo že več kot tri desetletja. Za naročnike je pomembno, da izberejo partnerja, ki poda realne ocene vrednosti projekta in realno predvidevanje trajanja projekta. Samo realna končna analiza stroškov in koristi bo omogočila, da v fazi izvedbe ne bo prihajalo do večjih presenečenj.

V določenih primerih je koristna tudi priprava analize izvedljivosti. Osnovne informacije o tem lahko najdete tukaj. Besedilo je v angleščini.

#2

Ekipa

Ekipa za podporo uporabnikom pomaga pri predstavitvah rezultatov projekta, usposabljanju v primeru kompleksnejših rešitev in tudi v fazi vzdrževanja.

Projektni vodja organizira delo, skrbi za vire in porabo, hkrati pa je v vlogi predstavnika naročnika s pooblastili vodenja pri izvajalcu.

Tehnični vodja (TL) mora biti ustrezno usposobljen človek z bogatimi izkušnjami, saj mora zagotoviti odlično poznavanje uporabljene tehnologije in v celoti razumeti postopke.

Razvojno ekipo sestavljajo ljudje, ki v detajle poznajo razvojne platforme, metode, baze in varnostne mehanizme.

Za izvedbo projekta digitalizacije oziroma kateregakoli projekta na področju informatike je ključnega pomena ekipa z ustreznim strokovnim znanjem in izkušnjami. Pri izvajanju projektov razvoja informacijskih rešitev po naročilu običajno potrebujemo vsaj:

2.1 Tehničnega vodjo projekta – TL (Technical Lead)

Tehnični vodja je izkušen in tehnično vrhunsko usposobljen posameznik, ki odlično pozna vse uporabljene tehnologije in v celoti razume tudi postopke, ki z uporabo izbranih razvojnih platform vodijo do cilja. Bistvo njegove ali njene vloge v projektu je vzpostavitev najprimernejše arhitekture za končno rešitev problema, ki ga posamični projekt naslavlja. Odgovarja za tehnični del razvoja in z nasveti pomaga programerjem ter drugim članom projektne ekipe, ki se ukvarjajo s tehničnim delom izvedbe. Definira ključne tehnične naloge in njihovo optimalno zaporedje, standarde razvoja, ki jih je pri izvedbi treba upoštevati in z izvajanjem peer-review postopkov zagotavlja tudi kvaliteto razvojnih artefaktov projekta.

2.2 Vodja projekta – PM (Project Manager)

Vodja projekta ima vlogo nadzornika in koordinatorja, ki zagotavlja pravočasno izvedbo projekta in skrbi za to, da so ovire in morebitni zapleti med izvedbo čim prej odpravljeni – na strani izvajalca in tudi na strani naročnika. Pomemben del vloge vodje projekta je tudi zagotavljanje izvedbe v okviru dogovorjenih finančnih okvirov.

Vodja projekta s tehničnim vodjem uskladi projektni načrt in nadzira izvedbo skozi vse faze. Poleg tega, da zagotavlja izdelke v dogovorjenih rokih, mora seveda skrbeti tudi za to, da so izvajalci nalog na voljo v pravem trenutku in da so morebitni kadrovski zapleti pravočasno in ustrezno rešeni. Projektni vodja je tako do določene mere tudi predstavnik naročnika s pooblastili vodenja pri izvajalcu.

Sodelavci, ki jim je zaupana vloga vodje projekta, morajo biti opremljeni z ustreznim strokovnim in organizacijskim znanjem ter s številnimi izkušnjami že realiziranih projektov na področju informacijske tehnologije. Nekateri med njimi imajo pridobljene tudi najzahtevnejše mednarodno priznane certifikate s področja projektnega vodenja.

2.3 Poslovni analitik (BA)

Poslovni analitiki so nekakšni so-oblikovalci vašega projekta. To so strokovno vrhunsko usposobljeni ljudje, ki vam pomagajo sooblikovati vizijo in namen in izpopolniti vaš informacijski projekt. Skozi intervjuje pridemo do zapolnjevanja vrzeli v vašem načrtu. Poslovni analitik bo – potem ko bo natančno razumel namen, ozadje in druge obstoječe rešitve na katerih temelji vaš projekt – izpostavil probleme in vprašanja, ki bi utegnila ključno vplivati na uspešnost v fazi izvedbe.

Strokovnost poslovnega analitika pripomore k temu, da imate v končni fazi natančno opredeljene zahteve in vire, kar bistveno pripomore  temu, da boste z vodjo projekta realno definirali tudi finančni okvir ter vzpostavili vsem razumljive, jasno začrtane meje projekta. Koristi vključevanja analitikov v projekt so zato predvsem v zmanjševanju tveganj nesporazumov in nejasnosti na relaciji med uporabnikom oziroma naročnikom na eni strani in razvojno ekipo na drugi strani. Vsak naročnik, ki je že kdaj izvajal večji projekt na področju informatike pozna to tveganje in ceni strokovno znanje analitika, ki s svojim delom zapolni ta razkorak in manjkajoče informacije med zahtevami in pričakovanji ter ekipo za konkretno izvedbo programske kode.

2.4 Načrtovalec informacijske rešitve

Načrtovalec je naslednji strokovnjak v procesu nastajanja informacijske rešitve. Poleg samega razvoja ima v mislih tudi čim lažje vzdrževanje bodoče rešitve. Vloga načrtovalca je v tem, da zagotavlja, da bo z izborom tehnologij, razvojnih platform in varnostnih mehanizmov končni informacijski sistem usklajujen z zahtevami in potrebami podjetja, ki jih je natančno opredelil poslovni analitik. Zagotavlja izbor učinkovitih, varnih in zmogljivih tehnologij. Načrt temelji na potrebah naročnika in opredeljuje izbiro ter način upravljanja programske opreme, implementacijo in morebitno nadgradnjo sistemov ter eventualno tudi platforme za podporo uporabnikom. Načrtovalec informacijskih rešitev mora zato svoje delo opraviti v sodelovanju z različnimi ekipami in posamezniki na strani naročnika in izvajalca, da zagotovi smernice za učinkovito delovanje bodoče rešitve in tako pomaga naročniku doseči zastavljene cilje. Od strokovnjaka v vlogi načrtovalca rešitve zato dobimo različne konkretne rešitve in predloge, kot so na primer podatkovna struktura, vizualni in interaktivni elementi uporabniškega vmesnika, vključno z izhodišči optimalne uporabniške izkušnje.

2.4 Razvojna ekipa

Projekte na področju informatike lahko realiziramo samo z ljudmi, ki dejansko vzpostavijo infrastrukturo, napišejo programsko kodo, konfigurirajo baze in naredijo uporabniške vmesnike. To so razvojni inženirji, strokovnjaki za informacijsko varnost in infrastrukturo, arhitekti računalniških baz, oblikovalci uporabniških vmesnikov in eksperti za uporabniško izkušnjo. Te ekipe realizirajo projekte, to so ljudje, ki v detajle poznajo razvojne platforme, metode, baze, zaščito. Da bi razvojne naloge zaključili čim prej in s čim manj težavami, jim s sprotnim testiranjem izdelkov priskoči na pomoč tako ekipa za podporo, kot tudi avtomatizirani CI/CD procesi. Vzpostavljene imamo tudi standarde, po katerih smo naročnikom dolžni zagotavljati visok nivo kvalitete izdelkov (QA).

S pomočjo naše ekipe za podporo uporabnikom si lahko omislite tudi predstavitve rezultatov projekta za uporabnike in usposabljanje v primerih kompleksnejših rešitev. Prav tako za rezultate projektov, ki smo jih izvajali mi, omogočamo vzdrževanje, uporabo klicnega centra in posodabljanje rešitev, narejenih po naročilu.

 

#3

Izdelava ocene in plana

Dobra analiza, načrt, znane omejitve in izkušnje so ustrezna izhodišča za realno oceno stroškov razvojnega projekta.

Vodja projekta vam bo natančno predstavil celoten proces, ki bo vodil do cilja in rokovnik projekta.

Dogovoriti se moramo o tem, kakšno okvirno arhitekturo rešitve želite uporabiti.

Ključnih 7 vprašanj za realno oceno vrednosti projekta.

PPoleg izvedbe analize lahko še pred pripravo projektnega plana skupaj preverimo specifične rešitve, ki so že na trgu in delno ali v celoti ustrezajo vašim ciljem. Skupaj ocenimo prednosti in slabosti in se dogovorimo o tem, ali projekt razvijamo povsem na novo ali s prilagoditvami obstoječih rešitev, če le-te seveda omogočajo prilagoditve. Dogovorimo se o tem, katere tehnologije, standardi ali podatkovni viri so skladni s strategijo vaše organizacije. Prav tako si v naprej odgovorimo na vprašanja o tem, ali bo rešitev v oblaku, na vaši infrastrukturi ali hibridna.

3.1 Groba ocena vrednosti projekta

V tej fazi smo o vašem projektu izvedeli dovolj, da lahko pripravimo grobo oceno stroškov. Kombinacija analize in popisa vaših zahtev, pričakovanj in omejitev projekta, načrt ter naše izkušnje s podobnimi projekti na tem področju, so ustrezen temelj za pripravo realnega pregleda stroškov razvojnega projekta.

Groba ocena stroška, ki vključuje glavne sklope opravil, licenčnih in drugih stroškov, je tudi izhodišče za izdelavo natančnega popisa vseh nalog in procesa (WBS), ključnih mejnikov in izdelkov projekta. Vodja projekta vam bo tako v sodelovanju z analitikom in razvojnim vodjem natančno predstavil celoten proces, ki bo vodil do cilja in rokovnik projekta.

3.2 Natančna ocena vrednosti projekta

Glede na vaša pričakovanja, zahteve in omejitve, smo tako prišli do dokaj natančne vrednosti vaše investicije v projekt. Kljub temu moramo do sklenitve pogodbe in razgrnitve vseh stroškov razvoja po naročilu skleniti še dogovor o tem, kakšno okvirno arhitekturo rešitve želite uporabiti. Tu vam lahko nudimo dovolj pestro izbiro, da se za vsako organizacijo lahko najde ustrezen model, naj gre za kompaktno več-nivojsko arhitekturo, mikro storitve, uporabo klienta za dostop do strežnika in še druge možnosti. Če se odločite za rešitev v oblaku vam lahko nudimo tudi najem našega poslovnega oblaka, kjer so cene za gostovanje posamične zaključene rešitve fiksne in vam tako omogočajo mnogo lažje planiranje stroškov. Najbolj realno ponudbo za izvedbo projekta vam bomo pripravili, če smo si do te faze čim bolj natančno odgovorili na »magičnih« 7 vprašanj:

  1. Kakšen je namen programske opreme, ki bo razvita po naročilu?
  2. Ali imamo natančen opis rešitve, kot jo vidi naročnik?
  3. Kakšne funkcije mora podpirati rešitev in kaj točno mora narediti?
  4. Kakšen nivo odzivnosti programske rešitve naročnik pričakuje v produkciji?
  5. Kakšne so ne-funkcionalne zahteve?
  6. Kako povezljiva mora biti rešitev z drugimi sistemi ali napravami?
  7. Kakšne so oblikovne zahteve ali omejitve?

 

Preden sklenemo pogodbo o razvoju in zaženemo projekt, vam po potrebi lahko poleg ocene tehnične in operativne izvedljivosti projekta pomagamo pripraviti tudi oceno pravne skladnosti, še posebej v tistih segmentih rešitev, ki se dotikajo varstva osebnih podatkov (GDPR), splošnih pogojev uporabe in avtorskih pravic.

#4

Prototipi in PoC

Kdaj je smiselno preveriti rešitev s PoC in kdaj z MVP?

Preverjanje v fazah razvoja nudi večjo varnost in zmanjšuje tveganje za neuspeh projekta.

Pri rešitvah za končne uporabnike s pomočjo MVP lahko razrešimo tudi dileme o tem, katere funkcionalnosti morajo biti del končnega izdelka.

PoC omogoča varno preverjanje tehnoloških ali konceptualnih tveganj na projektu.

V fazi razvoja oziroma programiranja rešitve se vaša ideja prične uresničevati v praksi. Kljub vsem natančnim analizam in načrtom se lahko zgodi, da pogled na rešitev in njena uporaba ne prineseta točno tistega, kar ste si kot naročnik zamislili. Z namenom izdelave čim bolj uporabnih in prijaznih rešitev je smiselno sproti nadzirati realnost načrtov in optimalno izvedbo, tako s funkcionalnega, integracijskega kot tudi povsem uporabniškega vidika. Da bi v fazi izvajanja projekta čim manjkrat zašli na stranpoti ali pričakovali nemogoče, imamo na voljo dve močni orodji:

  • PoC (Proof of Concept), ki ga je smiselno uporabiti tedaj, kadar nismo povsem prepričani v to, da bo določen segment v konceptu rešitve ali kombinacija z obstoječimi sistemi in platformami naročnika uspešno delala tisto, kar smo si zamislili. Če na primer nismo prepričani v to, da se bo nek naš obstoječ sistem uspešno povezoval z bodočo rešitvijo v oblaku, potem je PoC namenjen zgolj rešitvi te dileme. Omogoča nam pridobitev jasnega odgovora z uporabo le delčka celotnega vložka v razvoj in relativno varen razmislek o alternativah v primerih, ko PoC pokaže, da smo v delu projekta izhajali iz nerealnih predpostavk.
  • Preverjanje in testiranje idej in ciljev v fazah razvoja vam omogoča večjo varnost in zmanjšuje tveganje za neuspeh projekta. V kolikor se izkaže, da neka ideja ni v celoti uresničljiva, boste s testiranjem prototipov prišli do dejstev, na podlagi katerih je možno iskati alternativne rešitve.

 

Preverjanje in testiranje idej in ciljev v fazah razvoja vam omogoča večjo varnost in zmanjšuje tveganje za neuspeh projekta. V kolikor se izkaže, da neka ideja ni v celoti uresničljiva, boste s testiranjem prototipov in delnih izdelkov prišli do dejstev, na podlagi katerih je možno iskati alternativne rešitve.

Izdelava PoC ali MVP seveda ni nek obvezen element v izvedbi projekta. Kadar ste vi prepričani v to, da je vaš projektni načrt zanesljivo in preverjeno možno realizirati in mi na strani izbranih platform in razvojnih okolij potrdimo, da prav tako iz izkušenj vemo, da je projekt v celoti tehnično izvedljiv, je izdelovanje prototipov seveda nesmiselno.

Kadar je vaš projekt usmerjen h končnim uporabnikom, ki jih tehnične integracije in platforme v ozadju ne zanimajo kaj dosti, je morda smiselno z uporabo MVP tudi razrešiti kakšne dileme v zvezi s funkcionalnostmi, ki so ali bodo vključene v končni izdelek.

#5

Design

Oblikovalci in UX strokovnjaki morajo dobro vedeti, kdo so končni uporabniki.

Zelo koristna je vizualizacija uporabnikove poti.

Z UX načrtovanjem poskušamo ustvariti čim bolj intuitiven vmesnik.

Pomemben del uporabniškega testiranja je tudi preizkus oblikovne rešitve vmesnika.

Skoraj vsak projekt, kjer nastaja neka nova rešitev, potrebuje vsaj minimalno vizualizacijo. Uporabniki si šele tedaj, ko vidijo vmesnik, res predstavljajo namen, koristi in vlogo končnega izdelka. Pogosto velja nekaj podobnega tudi za tiste, ki v razvoj novih rešitev investirajo, saj šele s kliki in tipkanjem dobimo vtis, da je končni izdelek na dobri poti in lahko tudi ocenimo, ali se nam prikazane funkcionalnosti zdijo uporabne in koristne ali ne.

Design končnega izdelka se mora vedno opreti na tisto, kar je bila že na začetku definirana potreba uporabnikov. Oblikovalci in UX strokovnjaki morajo dobro vedeti, kdo so končni uporabniki in kaj je tisto bistvo, ki ga rezultat projekta rešuje. Zato je v fazi izdelave designa rešitve priporočljivo uporabljati metode, ki prispevajo k temu, da na koncu ne bomo imeli le »lepega« in »modernega« uporabniškega vmesnika, ampak izdelek, ki bo res ustrezno umeščen v okolje in prijazen do uporabnika.

  • Definiranje uporabnikov in informacijske infrastrukture. V fazi izdelave designa rešitve bi moralo biti oboje že kristalno jasno definirano, saj ta naloga sodi v inicialne faze projekta in oblikovalec mora imeti te informacije že na voljo, sicer projekt verjetno ne teče po poti, ki bi zagotavljala kakšno večjo možnost uspeha. Če kot končne uporabnike vidimo zelo različne tipe in interese ljudi, ki bodo rešitev uporabljali v zelo različne namene in na različne načine, si je smiselno iz metod marketinga izposoditi tako imenovane uporabniške persone in jih predstaviti oblikovalcem.
  • Izhodiščne zahteve. Običajno ekipi, ki se ukvarja z oblikovanjem, pripravimo dokument, v katerem povzamemo ključne namene oziroma cilje projekta. Na vsem razumljiv način definiramo zahteve in izdelke projekta ter navedemo omejitve, če obstajajo – na primer CGP naročnika ali podobno.
  • Zelo koristna je tudi vizualizacija uporabnikove poti. Ta predstavi korake oziroma načine uporabe končne rešitve in poskuša celo vključiti oceno izkušnje, ki jo je imel uporabnik po tem, ko je v aplikaciji naredil vse, kar je imel namen narediti. Večinoma delamo rešitve za poslovne uporabnike, a kljub temu želimo ustvariti vmesnike, kjer bo končna izkušnja čim bolj prijetna in v uporabniku ne bo nenehno tlela skrita želja po tem, da aplikacijo čim prej zapre.
  • Pozicioniranje grafičnih vmesnikov v WBS. Omenili smo že, da na samem začetku projekta vodja pripravi natančen popis nalog in vsaj grobe opise vmesnih faz in izdelkov, ki tvorijo končni rezultat. Koristno je, če so v tem načrtu še posebej označene naloge, katerih rezultat je vizualizacija, saj oblikovalci na ta način dobijo še bolj natančno predstavo o tem, kako so elementi rešitve medsebojno povezani in kaj mora posamičen člen vmesnika nuditi uporabniku.

 

V fazi načrtovanja uporabniškega vmesnika (ali vmesnikov) je smiselna redna koordinacija z naročnikom in sprotno usklajevanje predlaganih konceptov grafičnega dela končnega izdelka.

Pri oblikovanju vmesnika in uporabniške izkušnje si običajno pomagamo še na naslednje načine:

  • Žični okvir oziroma »wireframe«. Tu lahko vidimo, kaj bodo osnovni bloki končne rešitve, kako bodo razporejeni na zaslonih, kaj in kje bo izpostavljeno, kolikšen delež bo pripadel posamičnemu bloku in podobno. Žični okvir od vseh sodelujočih še vedno terja kar nekaj domišljije.
  • Tako imenovani »mockup«. Tu so grafični elementi končne rešitve že bolj jasno predstavljeni. Še vedno gre zgolj za sliko vmesnika, ki še ne podpira nobenih klikov ali vnosov, sortiranj, iskanj ali podobno. Vendar je mockup že dovolj jasno predstavljen, da si lahko dokaj natančno predstavljamo, kako ekipa oblikovalcev vidi končni izdelek za uporabnika.
  • Načrtovanje uporabniške izkušnje – UI/UX design. Z načrtovanjem čim bolj enostavne, uporabniku prilagojene izkušnje poskušamo doseči stanje, kjer bo vmesnik tako intuitiven, da uporabnik nekega dodatnega časa za uvajanje v končni produkt sploh ne potrebuje. Še posebej v primerih, ko imamo različne tipe uporabnikov in različne namene končne rešitve, je ta element oblikovnega procesa zelo dobrodošel, saj nam lahko bistveno poveča naklonjenost bodočih uporabnikov.

 

Uporabniško testiranje. Tudi če končni rešitvi funkcionalno in performančno nič ne manjka, je korektno izveden uporabniški test lahko dober preizkus oblikovne rešitve vmesnika. Del uporabniškega testiranja se namreč nanaša tudi na oceno učinkovitosti grafičnega dela aplikacije, njene intuitivnosti in natančnosti pri izpolnitvi osnovnih zahtev in potreb, ki so bile izhodišče projekta.

#6

Razvoj

Naše razvojne ekipe že dolgo uporabljajo agilne metode.

Spoznajmo  se z artefakti razvojnega procesa.

Kratki dnevni »stand-up« sestanki omogočajo hitro reševanje odprtih vprašanj ali težav.

Natančna tehnična dokumentacija je nujni sestavni del vsakega razvojnega projekta.

Programerji včasih rečejo, da ni nekih bistvenih razlik med razvojnimi orodji – če znaš en programski jezik, se hitro naučiš tudi drugega, saj je pomemben predvsem način razmišljanja. Nekaj podobnega velja tudi za metode, ki se uporabljajo v procesu razvoja programske rešitve. Kot vsako sodobno podjetje v IT industriji tudi mi uporabljamo agilne metode razvoja, včasih morda eno agilno metodo nadomestimo z drugo, a med seboj so si na koncu koncev dokaj sorodne.

Programerji dobijo dodeljene naloge podrobno opisane v podpornem sistemu. Pri nas je to Jira, standardno orodje, ki povezuje razvoj s projektnim vodenjem, designersko ekipo, pogodbenimi partnerji, celo z managementom in včasih tudi neposredno z naročnikom. Krovnemu popisu dodeljenih nalog v žargonu rečemo SOW, kar izhaja iz angleškega izraza Statement of Work. Kot smo že omenili, je za ta SOW zadolžen projektni oziroma razvojni vodja, ki natančno definira odgovore na vprašanja o tem kaj, zakaj, v kakšnih mejah, z uporabo katerih virov in orodij, s kolikšnimi stroški, do kdaj in pod kakšnimi kriteriji sprejemljivosti rezultata mora biti narejeno. Statusi posamičnih nalog seveda dajejo zelo jasno sliko o tem, kje se z razvojnega vidika projekt nahaja in katere delne izdelke že lahko testiramo ali celo uporabljamo.

Artefakti razvojne faze IT projekta

Naročniki imajo preko tako imenovanih artefaktov vpogled v razvojne naloge in spremembe ter možnost in v nekaterih primerih celo dolžnost sodelovanja.

  • Rokovnik sestankov: tu so določeni termini, v katerih boste obveščeni o statusnih spremembah v razvoju elementov rešitve in način tega obveščanja (na primer sestanki, koordinacija na daljavo, poročilo v e-pošti ali drugo)
  • Vzpostavitveni dokument projekta: ta dokument je dogovor med izvajalcem in naročnikom in definira namene projekta, cilje, ki morajo biti doseženi, vse vpletene deležnike, vire, standarde ter vloge in odgovornosti vseh vpletenih.
  • RACI matrika: tu se nahajajo vloge v življenjskem ciklu razvojnega projekta (oznaka izhaja iz angleščine: Responsible, Accountable, Consulted in Informed)
  • Projektni plan oziroma »roadmap«: iz tega načrta boste razbrali vsebino posamičnih verzij izdelkov oziroma dogovorjene funkcionalnosti, ki so v posamični verziji že zagotovljene. Ključne aktivnosti, njihovo trajanje in roki izvedbe so običajno vizualizirani v obliki Ganttovega grafikona.
  • Seznam tveganj: ta vsebuje vsa ključna tveganja, ki jih je v zvezi z realizacijo projekta moč predvideti, kar vam omogoča pravočasno in učinkovito odstranjevanje ovir na poti do realizacije
  • Seznam sprememb: tu je zabeležen seznam vseh sprememb in zahtev za spremembe, naj te izhajajo iz tehničnih razlogov na strani izvajalca ali iz drugih razlogov s strani naročnika.
  • Uporabniške zgodbe: opredeljeni s strani analitika so ti zapisi odmik od strogo tehničnega razvojnega jezika in opisujejo načine, na katere bo končni izdelek predvidoma uporabljen.

 

Za agilni razvoj je značilna redna izmenjava informacij med člani ekipe in v nekaterih primerih tudi predstavnikom naročnika. Ta izmenjava informacij se praviloma izvaja v obliki kratkih sestankov, kot so:

  • Zagonski (»kick-off«) sestanek za seznanitev z vsebino, nameni in parametri projekta
  • Dnevni (»stand-up«) sestanki s povzetkom plana za tekoči dan in izmenjavo predlogov ter idej za sprotno reševanje odprtih vprašanj ali težav
  • Zagonski sestanki za vsak posamični »sprint«, kjer se določijo cilji posamične etape in aktivnosti, ki so v ta »sprint« vključene
  • Zaključni sestanki za vsak »sprint«, kjer se predstavi rezultate in oceni dosežene cilje
  • Retrospektivni sestanki za »sprinte«, kjer se iz težav predhodnih faz ustvarja novo znanje za enostavnejši in hitrejši razvoj v prihajajočih fazah

 

Ena od ključnih aktivnosti razvoja je seveda tudi sprotno ustvarjanje tehnične dokumentacije, ki naročniku kasneje nudi enostavnejše, trajnejše in cenejše vzdrževanje končnega izdelka.

#7

Testiranje

Prednosti uporabe testnih scenarijev in strategij.

Testiranje poleg odprave napak v kodi zagotavlja tudi skladnost z zahtevami in pričakovanji.

Avtomatizacija testiranja je dobra, a včasih to ni optimalna izbira z vidika stroškov projekta.

Uporaba »unit« in »stress« testov.

Testiranje je postalo s kompleksnostjo rešitev vse pomembnejša faza v razvoju novih aplikacij, portalov in sistemov. Brez intenzivnega sprotnega testiranja bi bila danes velika večina projektov na področju digitalizacije poslovanja oziroma razvoja novih rešitev obsojena na neuspeh.

Kot vsako drugo sodobno IT podjetje tudi mi zagotavljamo ustreznost in kvaliteto izdelkov (QA), ki nastanejo kot rezultat razvoja po naročilu. Obseg in metode testiranja so integralni del aktivnosti vsakega razvojnega projekta. Ustvarimo testne scenarije in strategijo, ki naročniku zagotavlja:

  • skladnost z zahtevami in pričakovanji, ki so definirana že vse od faze analize naprej;
  • sledenje zaznanim napakam in njihovo odpravljanje;
  • pred-produkcijsko regresijsko testiranje po praktično vsaki odpravljeni napaki, tudi v DevOps okolju;
  • uporabniško testiranje v vseh primerih, kjer je to bolj smiselno od avtomatskega.

Avtomatizacija testiranja je dobra, vendar včasih to ni optimalna izbira z vidika stroškov projekta. Nekaj dilem, ki jih je smiselno upoštevati, ko tehtamo kaj je bolje:

  • Pri uporabniškem testiranju morate nalogo preverjanja ustreznosti izdelka predati človeku in zaupati v to, da je zmožen preveriti vse različne možnosti in poskuša razkriti napake. Avtomatizacija testiranja po tem, ko so testne skripte narejene, seveda ni več odvisna od eventualnih človeških napak in tudi zagotavlja rezultate hitreje.
  • Kljub temu, kar smo pravkar ugotovili, avtomatsko testiranje ne omogoča uporabniške percepcije delnega ali končnega izdelka.
  • Na manjših projektih je avtomatsko testiranje lahko občutno dražje od uporabniškega, saj je treba za avtomatsko testiranje pripraviti ustrezne skripte, kar v primeru manjšega obsega načrtovanih funkcionalnosti utegne povzročiti nesorazmerne stroške.
  • Včasih se je treba skozi razvoj projekta dinamično prilagajati tudi na področju zagotavljanja kakovosti, kar pomeni, da je treba nekaj testirati drugače kot je bilo prvotno pričakovano, ali pa takšen test sploh ni več potreben.
  • Kadar nastane situacija, ki terja izvajanje ad-hoc testiranj seveda ni skript, ki bi kaj takega omogočale.

Ne glede na avtomatsko ali uporabniško testiranje na koncu s QA procesi upravljamo ljudje.

Pri odločitvah o uporabi avtomatizacije testiranja je zato smiselno ohraniti razum in biti racionalen pri porabi sredstev v ta namen. Iz naših izkušenj bi priporočali avtomatizirano testiranje v situacijah, kjer:

  • bo obseg testiranja zelo velik in frekventen;
  • ljudje testa sploh ne morejo izvesti (npr. veliko število prijavljenih uporabnikov, performančne obremenitve in podobno);
  • je projekt tako velik, da ni smiselno ali možno uporabiti toliko testerjev, da bi s človeškimi viri lahko zagotavljali kvaliteto končnega izdelka;
  • obstaja potreba po testiranju ustreznega odziva na različne varnostne grožnje (tako imenovani penetracijski testi).

Pri razvoju programske opreme po naročilu se skoraj vedno uporabljajo tako imenovani »Unit testi«. S to metodo se testira posamični del programske kode v testnem okolju. Namen unit testa je v tem, da se prepričamo, da vsak del oziroma vsaka enota končne programske rešitve deluje pravilno. Skozi unit test se torej preveri, ali vsaka enota kode deluje tako kot je načrtovano in tudi to, ali je posamična enota programske kode ustrezno združljiva z ostalimi deli kode. Številni unit testi se lahko izvajajo v avtomatizirani obliki, kar omogoča visoko kvaliteto vsake različice končnega izdelka, saj je programska koda tako redno preverjena, morebitne napake pa so hitro razkrite.

Druga vrsta testov, ki se izvedejo praktično ob vsakem razvoju nove programske opreme, so stresni testi (»stress test«). S tovrstnimi testi se preveri, kako dobro se sistem obnaša ob obremenitvah, ki presegajo najvišje pričakovane obremenitve v produkcijski postavitvi. S temi testi se zagotovi robustnosti končnega sistema in pravočasno odkrije morebitne slabosti, ki bi se utegnile pojaviti ob veliki obremenitvi. Stresni testi se izvajajo na primer s povečevanjem števila uporabnikov preko meja pričakovanega končnega števila, z uporabo zahtevnejših poizvedb od pričakovanih ali s podobnimi kazalniki delovanja v simulaciji preobremenitve. Stresne teste je možno izvajati avtomatsko, z ustrezno specialno programsko opremo, ki lahko simulira visoko obremenitev programske rešitve in pri tem meri njeno odzivnost. Na ta način lahko preverimo sposobnost delovanja rešitve v situacijah, kot so na primer:

  • število sočasnih uporabnikov presega pričakovanja;
  • frekvenca in kompleksnost poizvedb (uporabniških, preko API-jev…) je večja od pričakovane;
  • uporabniki polnijo sistem z nepričakovano velikim obsegom podatkov (npr. z daljšimi besedili od pričakovanih, z večjimi datotekami, z višjo frekvenco od pričakovane in podobno)…

 

V primeru testiranja specifičnih scenarijev, kjer obremenitev rešitve lahko povzroči posamični uporabnik, je seveda smiselno tudi klasično, torej ne-avtomatizirano testiranje.

#8

Uvedba v produkcijo

Vzpostavitev produkcije mora biti odlično koordinirana med naročnikom, izvajalcem in tehničnim kadrom naročnika.

Potrebno je poznati odgovore na vprašanja o tem, kako se bo izvedla implementacija, kdo je odgovoren in kdo bo rešitev vzdrževal.

Metoda CI/CD je v razvojno – vzdrževalnem procesu nekakšen vodovod ali plinovod.

Infrastruktura rešitve naj bo nemudoma vključena v sistem varnostnega kopiranja.

Ko vaša nova rešitev uspešno prestane sprejemni test, je pripravljena za implementacijo v produkcijsko okolje. Naj gre za vašo lastno informacijsko infrastrukturo ali zasebni oblak, hibridni ali javni oblak – v vsakem primeru tudi faza uvedbe v produkcijo sledi nekim pravilom, ki zagotavljajo višji nivo varnosti in enostavnejše nadgradnje v prihodnosti.

Vzpostavitev produkcije torej terja dobro, natančno koordinacijo med naročnikom, izvajalcem in tehničnim kadrom naročnika oziroma orkestracijo.

  • Vzpostavitev in konfiguracija strežnikov. Danes praktično ni več aplikacij in rešitev, ki bi delovale le na neki izolirani delovni postaji. Vse deluje na strežnikih. Priporočamo, da se strežniška oziroma cloud infrastruktura implementira v skladu z DevSecOps prakso, ki združuje DevOps in informacijsko varnost.
  • Vzpostavitev CI/CD infrastrukture. Metoda CI/CD je v razvojno – vzdrževalnem procesu kot nekakšen izjemno koristen vodovod ali plinovod. CI (kratica označuje Continuous Integration) in CD (Continuous Delivery) poenostavita in pospešita procese dobave novih različic, izboljšav in popravkov programske opreme in obenem vzpostavita upoštevanje dobre prakse skozi z uporabo standardiziranega procesa.
  • Zagotovitev varnosti. Skozi številne integracije, odvisnosti in nenazadnje tudi z zlorabo uporabnikov lahko pride do ogrožanja vaše nove rešitve. Zato je ključnega pomena, da je infrastruktura, na kateri rezultat projekta deluje, nemudoma vključena v sistem varnostnega kopiranja in tako pripravljena na eventualno restavriranje v delujoče stanje.
  • Performančna konfiguracija infrastrukture. Najboljšo odzivnost dosežemo, če s pomočjo smernic strokovnjakov vzpostavimo optimalno konfigurirano strojno in programsko okolje, na katerem se bo nova rešitev izvajala. To lahko pomeni vse od rezervacije ustrezne količine pomnilnika in procesorjev, do finih omrežnih nastavitev ali specifičnih parametrov podatkovne baze.
  • Jasna delitev odgovornosti. Za uspešno plasiranje vašega novega programskega produkta je pomembno tudi to, da je popolnoma jasno, kako se bo izvedla implementacija v produkcijsko okolje, kdo je odgovoren za te naloge in kdo bo skrbel za vzdrževanje.

#9

Vzdrževanje

Dolgoživost rezultatov projekta je odvisna od načina vzdrževanja – z upoštevanjem vseh vidikov vzdrževanja dosežemo najboljše rezultate.

Izvajanje korekcij je le en od razlogov za vzdrževanje rešitve.

Vzdrževanje je kot streha projekta, planirajte ga v naprej – že v fazi razvoja.

…in poskrbite za aktivno varnost!

Naša in vaša nova rešitev je torej ugledala luč sveta. Žal to nikoli ni nek avtonomen sistem, ki bi v nedogled sam skrbel za sebe in deloval ne glede na spremembe, ki so v informatiki stalnica. Vsak zagon produkcije je zato hkrati tudi zagon vzdrževalnega procesa. Odločitev o tem, ali boste za izboljšave, nadgradnje, prilagoditve in samo infrastrukturo skrbeli sami ali z našo pomočjo je seveda povsem vaša – vsekakor pa je zelo pomembno, da pričnete z vzdrževanjem rezultatov razvojnega projekta že na prvi dan produkcije.

Če se odločite za lastno vzdrževanje, potem vam priporočamo, da sklenete neke vrste interni pisni dogovor, ki bo čim bolj natančno opredelil, kaj vse je predmet vzdrževanja, kakšni so pogoji, ki morajo biti za to izpolnjeni in kako hiter bo odziv v primeru če pride do težav. Če boste nalogo vzdrževanja zaupali nam, potem bomo te pogoje, odgovornosti in druge parametre vzdrževanja seveda dogovorili s pogodbo.

Tudi pri vzdrževanju rezultatov razvojnega projekta ni potrebno izumljati tople vode, ampak lahko dobro prakso razberemo kar iz standardov, ki to področje urejajo. Tak standard je ISO/IEC 14764:2006, ki daje smernice za načrtovanje, izvajanje, nadzor, evalvacijo in zaključek vzdrževalnega procesa. Standard se ukvarja z različnimi vidiki vzdrževalnega procesa:

  1. Korekcijski vidik. Če v programski opremi, ki je že v produkciji, zaznate programskega hrošča – in morda to celo ni posledica napake izvajalca, ki vam je na izdelek po vsej verjetnosti dal garancijo – potem bo potreben poseg, s katerim bo takšna napaka popravljena. Tu gre torej za zagotavljanje storitve v situacijah, ko v naši rešitvi zaznamo napako in potrebujemo človeka oziroma ekipo s tehničnim in vsebinskim znanjem, ki bo to napako odpravila. Če izvajalec ne nudi vzdrževanja in je bila celotna projekta ekipa že razpuščena, potem je takšna situacija lahko precej nerodna.
  2. Preventivni vidik. Ta je podoben vzdrževanju kvalitetnega vozila. Tudi če ni z avtom nič narobe, ga enkrat letno peljete na servis. Tam z menjavo olja, filtrov in pregledom točk obrabe poskrbijo za to, da boste varni na cesti tudi naslednje leto. Z rezultati vašega razvojnega projekta ni kaj dosti drugače – vsaj občasno je treba preveriti, ali je rešitev še vedno usklajena s sistemskimi in razvojnimi okolji, v katere je umeščena, ali je potrebna kakšna posodobitev, nadgradnja, odprava novih varnostnih tveganj in podobno.
  3. Vidik nenehnih izboljšav. Kot vidimo pri vsakdanji uporabi programske opreme, se ta nenehno izboljšuje, posodablja, optimizira in prilagaja novim napravam ali tehnologiji. Tudi vaša rešitev, čeprav morda namenjena le interni javnosti, bi se morala nenehno posodabljati in izboljševati. Le tiste rešitve, ki so podvržene nenehnim izboljšavam, lahko preživijo dolgo obdobje uporabe. Pomislite na Microsoftove pisarniške izdelke, ki so ravno zaradi nenehnega prilagajanja in izboljšav z nami vse od časov, ko nam je zadoščal operacijski sistem DOS. Tudi sami smo razvili rešitve, ki ostajajo v uporabi že par desetletij in so ta čas preživele samo zaradi nenehnih izboljšav in prilagoditev.
  4. Vidik prilagajanja. Podobno kot pri nenehnih izboljšavah, moramo poleg samega rezultata razvojnega projekta opazovati tudi okolico. Če je rešitev nastala pred desetimi leti in vidimo, da se naše poslovanje vse bolj seli v računalniški oblak, potem moramo nekaj ukreniti za to, da bo tudi naša, sicer morda redno vzdrževana, a na videz konceptualno zastarela rešitev lahko delovala v oblaku. Če vidimo, da komponente, ki so bile tedaj uporabljene za razvoj niso več konkurenčne, moramo poiskati sodobne nadomestke.

 

Pri planiranju vzdrževanja mora lastnik nove rešitve vedno razmišljati vsaj o naslednjih stvareh:

  • Kakšen obseg vzdrževalnih storitev je treba zagotavljati za rezultat projekta? Odgovoriti si moramo na vprašanje o tem, katere vzdrževalne storitve in pod kakšnimi pogoji morajo biti na voljo, da bomo čim dlje in čim bolj učinkovito pokrivali cilje, ki smo si jih s projektom zastavili.
  • Kdo bo odgovorna oseba oziroma katera vloga v organizaciji bo skrbela za to, da se bo vzdrževanje izvajalo optimalno?
  • Kako bo potekalo vzdrževanje dokumentacije – spremembe, ki se bodo v okviru vzdrževanja izvajale, terjajo tudi spremembe v dokumentaciji. Brez tega bi hitro zašli v območje tipanja v temi ali celo zavajajočih informacij v ne-vzdrževani dokumentaciji.
  • Kako bo tekel proces sprememb? Kdo bo tisti, ki lahko zahteva spremembo, kdo bo o tem razmislil, kdo odobril, kdo realiziral? Brez jasnih pravil o tem, kako naj bi prihajalo do vsebinskih, programskih ali drugih sprememb programske opreme zaidete v situacijo, kjer se odločitve sprejemajo konfuzno, morda celo z vidika enega samega uporabnika in posledično kot plaz rušijo vse, kar ste skozi razvojni projekt koristnega naredili.
  • Kako hiter naj bo odziv, ko rabite vzdrževalno ekipo, kakšni stroški bodo s tem nastopili? Ni namreč vseeno, ali zahtevate rešitev nekega postranskega problema praktično v hipu ob 23h zvečer ali v treh delovnih dneh in med običajnim delovnim časom.
  • Kdo skrbi za strežniške platforme, ki poganjajo vašo rešitev? Je to vaša lastna ekipa, nek tretji ponudnik? Kakšna zagotovila vam daje, kakšen nivo varnosti, koliko sploh imate vpliva na to, kaj bo ta ponudnik delal za vas?
  • Kakšen nivo zagotavljanja kvalitete v fazi vzdrževanja pričakujete? Če smo se v fazi razvoja zavezali nekim visokim normam zagotavljanja kvalitete – bo to izničeno v fazi vzdrževanja?
  • Kakšen način komunikacije in kakšen način poročanja pričakujemo od ekipe, ki bo vzdrževanje izvajala?

 

Iz navedenega je dokaj jasno razvidno, da si na vsa vprašanja v zvezi z vzdrževanjem ne boste odgovorili tistega dne, ko boste rešitev zagnali v produkcijskem okolju. O vzdrževanju je smiselno razmišljati že v fazi razvoja, preigrati različne možnosti in si ustvariti varno mrežo še preden prvi uporabnik sploh naredi prvi klik ali »tap« v produkcijski različici rešitve. Brez te mreže je padec lahko izjemno boleč. Pravočasno razmišljajte o tem, kakšne so vaše lastne kadrovske kapacitete za vzdrževanje rezultatov razvojnega projekta, kakšne možnosti imate na voljo za vzdrževanje infrastrukturnega okolja in seveda kolikšne finančne rezervacije potrebujete za to, da bo v bodoče vaša nova rešitev delovala stabilno in bo še dolgo v koraku s časom.

 

 

…in ne pozabite na informacijsko varnost!

 

Čudovito je imeti na voljo novo rešitev, ki modernizira in optimizira naše poslovanje ali morda celo služi splošni javnosti. Vendar v navdušenju niti za hip ne smemo pozabiti na to, da je praktično vsak izdelek v okviru informacijske tehnologije izpostavljen nenehnim grožnjam. Poskusi vdorov, vohunska programska oprema, kripto napadi, prevare z lažnim predstavljanjem, trojanski konji in številne druge pretnje so kot plevel na polju naših pridelkov. Običajno rastejo hitreje od našega sadja in zelenjave. Zato je ključnega pomena, da naredimo vse za to, da smo čim bolje zaščiteni pred zlikovci in njihovim orožjem.

SRC posveča informacijski varnosti veliko časa in sredstev. Nenehno se usposabljamo na tem področju, da smo v koraku z idejami, metodami in tehničnimi rešitvami tistih, ki samo čakajo na to, da bi pogledali vstran. Skrb za varnost je integrirana že v naš razvojni proces in storitve izvajamo po ključnem standardu na tem področju, to je ISO 27001. Ne glede na to, ali vaša organizacija ima potrebe po upoštevanju tega standarda ali ne, vam za varno uporabo rezultatov razvojnih projektov priporočamo vzpostavitev nekaterih osnovnih norm, ki predstavljajo vsaj tisti temeljni nivo zaščite, ki je nujno potreben za obrambo pred grožnjami, ki so v tesno prepletenem svetu sodobne informatike prisotne praktično ves čas. Zato je dobro na organizacijskem nivoju sprejeti naslednja izhodišča:

  • Popišite oziroma jasno formulirajte tveganja. Ocenite verjetnost posamičnega potencialnega tveganja. Ni potrebe po tem, da ustvarite 100 km dolg dokument, ki bi bil sam sebi v namen, vsekakor pa je koristno skleniti nek zavezujoč interni dogovor, ki bo definiral odgovore na vprašanja o tem, kako obvladujete oziroma upravljate tveganja na področju informatike, kje beležite varnostne incidente, kako usposabljate zaposlene za prepoznavanje nevarnosti in prevar ter podobno.
  • Definirajte vsaj osnovna pravila vaše varnostne politike. Kako preprečujete prost dostop do vaše strežniške infrastrukture, kakšne minimalne varnostne mehanizme morate uporabljati za preprečitev vdora v vaš informacijski sistem, kako se mora izvajati varovanje podatkov, kaj je minimalna varnostna zahteva za oddaljen dostop do vašega sistema, kdo mora zagotavljati redna izvajanja varnostnih pregledov informacijskega sistema, kdo in kako upravlja s pooblastili za dostop in podobno.
  • Opredelite metode zagotavljanja varnostnih kopij, preverite ali potrebujete rezervno lokacijo s strežniško infrastrukturo, opredelite postopke, ki se morajo izvesti za restavriranje podatkov v primeru okvare, vdora, zlonamernega kriptiranja podatkov ali podobno.
  • Odgovorite si na vprašanja v zvezi z zagotavljanjem neprekinjenega poslovanja. Kako verjetno je, da bo vaš informacijski sistem še vedno deloval v primeru naravne nesreče, kaj lahko izboljšate s ciljem rešitve takšnega problema? Kako uporaben je bil vaš sistem v obdobju epidemije in kako lahko izboljšate učinkovitost v bodoče? Imate vsaj zagotovljene alternativne vire v primeru daljšega izpada električne energije? Je dostopnost vašega informacijskega sistema v celoti odvisna od enega samega telekomunikacijskega ponudnika? Teh vprašanj je še veliko, nanizanih je le nekaj, za lažjo predstavo.

 

V kolikor z zagotavljanjem informacijske varnosti nimate izkušenj in tudi nimate virov, ki bi se s tem poglobljeno ukvarjali, se lahko vedno obrnete na nas. Poleg tega, da smo že v osnovi ponudnik poslovnega računalniškega oblaka s posebnim poudarkom na informacijski varnosti,  nudimo tudi specialne storitve s področja varovanja sistemov SRC Secure, varnostno operativni center SRC SOC, rezervni podatkovni center in druge storitve s tega področja.

©2024 Vse pravice pridržane SRC d.o.o.
small_c_popup.png

Obvestilo o ponovni dostopnosti storitev

Vse uporabnike storitev v računalniškem oblaku obveščamo, da se vsi sistemi ponovno normalno odzivajo. Po doslej zbranih informacijah je ob izvajanju gradbenih del prišlo do prekinitve linije, na kar je programska oprema za upravljanje z diskovnim poljem odreagirala napačno. S pomočjo proizvajalca diskovnega sistema smo uspeli sanirati problem okrog 11h dopoldne. Zaradi velikega števila strežnikov, ki se nahajajo v računalniškem oblaku je ponovna vzpostavitev v polno funkcionalno stanje trajala okrog 50 minut.

Spletno mesto uporablja piškotke zaradi boljše uporabniške izkušnje. Z uporabo naše spletne strani potrjujete, da se z njihovo uporabo strinjate.