Do konca strani

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 orodja morajo biti na voljo v delavnici IT mojstrov, č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 orodja, ki dokazano delujejo, saj za vsak problematičen vijak posebej res ni potrebno na novo izumiti izvijača.

Besedilo, ki sledi, je dokaj dolgo in verjetno za splošno javnost precej nezanimivo. Vsekakor pa služi kot uporaben kažipot vsem, ki se odločate za digitalizacijo nekega poslovnega procesa oziroma za razvoj neke nove programske rešitve – naj bo ta namenjena samo ozko poslovni ali splošni rabi.

#1

Analiza izvedljivosti

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

Pomagali vam bomo pri pripravi produktnih oziroma projektnih specifikacij.

Vaša končna analiza stroškov in koristi naj bo realna in brez skritih presenečenj.

Svetujemo tudi na področjih, kjer se srečate z dilemo pravne regulacije zbiranja podatkov ali izvajanja procesov.

Ste odločeni, da želite realizirati informacijski projekt in veste, da bo prinesel organizacijske, ekonomske ali druge koristi – ob tem pa se vam nenehno porajajo dvomi o tehnični izvedljivosti vaše zamisli? Ni problema, tu vključite našo ekipo, ki vam pomaga zagotoviti strokovne tehnične podlage in načrte za optimalno izvedbo vašega projekta.

Pomagali vam bomo pri pripravi produktnih oziroma projektnih specifikacij. Naši analitiki, tehnični 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, ki vam omogoča v naprej izločiti očitne pomembnejše dejavnike, ki bi ovirali ali onemogočili izvedbo projekta.

Pomagamo vam lahko tudi na področjih, kjer se skozi načrtovanje tehnične rešitve srečate z dilemo pravne regulacije zbiranja podatkov ali izvajanja procesov. Z našo pomočjo se izognete različnim interpretacijam vaših zahtev in s tem pogosto tudi previsokim ali povsem napačno ocenjenim stroškom izvedbe projekta. Znanje s področja izvajanja informacijskih projektov po naročilu se v naših ekipah zbira že 35 let in težko boste našli partnerja z boljšimi, bolj realnimi ocenami in predvidevanjem obsega za izvedbo projekta. Vaša končna analiza stroškov in koristi bo zato realna in ne bo dopuščala večjih presenečenj v fazi realizacije.

Več o tem, zakaj je analiza izvedljivosti pomemben element v fazi priprave projekta, si lahko preberete tukaj. Besedilo je v angleščini.

#2

Ekipa

S pomočjo ekipe za podporo uporabnikom lahko priskočimo na pomoč pri predstavitvah rezultatov projekta in »hands-on« usposabljanju za uporabo kompleksnejših rešitev.

Projektni vodja je praktično predstavnik naročnika s pooblastili vodenja pri izvajalcu.

Razvojni vodja projekta mora res odlično poznati uporabljene tehnologije in razumeti postopke.

Razvojno ekipo sestavljajo ljudje, ki v detajle poznajo razvojne platforme, metode, baze in zaščito.

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 potrebujete vsaj:

 

2.1 Razvojni vodja projekta – CTO

Razvojni vodja projekta odlično pozna uporabljene tehnologije in razume postopke, ki z uporabo izbrane razvojne platforme vodijo do cilja. Zato njegova ali njena vloga presega zgolj svetovanje ob izbiri razvojnih orodij in standardov. Sodeluje pri planiranju faz in vmesnih izdelkov projekta ter nadzira izvajanje, pri tem pa sproti identificira možne ovire in pomanjkljivosti ter poišče ustrezne rešitve. Običajno je to tudi oseba, ki neposredno komunicira s člani razvojne ekipe, saj na eni strani vidi celovito sliko vaših zahtev in pričakovanj, na drugi strani pa zna posamične naloge ustrezno tehnično definirati in s tem zagotoviti jasna navodila programerjem.

 

2.2 Vodja projekta – PM

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 z vodjo razvoja 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 predstavnik naročnika s pooblastili vodenja pri izvajalcu.

Naši sodelavci, ki imajo vlogo vodje projekta, so 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 certifikate projektnega vodenja.

 

2.3 Poslovni analitik (BA)

Poslovni analitiki so nekakšni so-oblikovalci vašega projekta. To so ljudje, ki vam prijazno kimajo, ko jim razlagate vizijo in namen in popolnost vašega projekta, potem pa vas pričnejo nadlegovati z neprijetnimi vprašanji. Namen teh neprijetnih vprašanj je zapolnjevanje vrzeli v vašem načrtu. Poslovni analitik bo – potem ko bo natančno razumel namen, ozadje in 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.

Poslovni analitik v končni fazi opredeli vaše zahteve, vire, finančni okvir in vzpostavi meje projekta. Koristi vključevanja analitikov v projekt so zato predvsem v zmanjševanju tveganj in povečevanju natančnosti opredelitve projekta.

 

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

Pogodbo za razvoj nove rešitve sklenemo šele po tem, ko imamo mi in naročnik jasne odgovore na ključna vprašanja.

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

Skleniti moramo dogovor o tem, kakšno okvirno arhitekturo rešitve želite uporabiti.

Preden nadaljujemo, poiščimo odgovore na 7 pomembnih vprašanj.

Poleg analize izvedljivosti (gl. #1) 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. 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 ter naše izkušnje s podobnimi projekti na tem področju.

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. Ker je izvajanje samo enega projekta z razvojno ekipo v praksi skoraj nemogoče, pri pogajanjih o rokih izvedbe ni smiselno pričakovati, da bo vsak razvojni inženir v ekipi delal le na vašem projektu. Tak način dela bi bil enostavno predrag.

 

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 fiksne in vam tako omogočajo mnogo lažje planiranje stroškov. Najbolj realno ponudbo za izvedbo projekta vam bomo pripravili, če smo si v tej fazi č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

Ena od koristnih stvari, ki jih omogoča PoC je tudi pravočasna ustavitev slabe ideje in razmislek o možnih alternativah.

MVP je še nepopolna rešitev, a služi kot skelet, na katerega bomo dodajali funkcionalnosti.

Če želimo pridobiti zadovoljnega končnega uporabnika, je smiselno preverjanje po Kano modelu.

S PoC lahko preverimo ali bo izbrana tehnologija ustrezna za tisto, kar smo si zamislili.

Po tem, ko začnemo z razvojem rešitve, se vaša ideja prične uresničevati v praksi. Kljub vsem analizam in načrtom pa se rado 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 rešitve, izbrana tehnologija ali kombinacija 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.
  • MVP (Minimum Viable Product) je funkcionalno in oblikovno nepopolna rešitev, a služi kot skelet, na katerega bomo dodajali funkcionalnosti, vzpostavljali integracije in pripravili oblikovne in UX rešitve, v kolikor jedro rešitve deluje po pričakovanjih.

 

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.

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 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. Če želimo pridobiti zadovoljnega končnega uporabnika, je smiselno že med razvojem opraviti preverjanje zamisli in vključenih funkcionalnosti po tako imenovanem Kano modelu. To pomeni, da sproti skrbno preverjate funkcionalnosti, design in UX delnih izdelkov projekta z vidika uporabnosti in tudi s performančnega vidika, razvoj uporabniku nepomembnih elementov rešitve – kot so na primer specifični vmesniki za sistemske inženirje, revizijske sledi, API-ji za druge aplikacije in podobno – pa prepuščate zaključnim fazam projekta.

#5

Design

Design rešitve bo uspešen samo tedaj, ko bomo vsi zelo natančno poznali lastnosti končnih uporabnikov.

Čim bolj dodelana vizualizacija končne rešitve je izjemno pomembna.

S čim bolj enostavno, uporabniku prilagojeno izkušnjo poskušamo narediti intuitiven vmesnik.

Del uporabniškega testiranja se nanaša tudi na oceno učinkovitosti grafičnega dela aplikacije.

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. Pomislimo samo na vse »Kickstarter« projekte, v katere zgolj po opisu skoraj nihče ne bi vlagal – zato praktično vsak, ki se loti zbiranja sredstev za nov projekt, poseže po čim bolj dodelani vizualizaciji tega, kar naj bi bila končna rešitev.

 

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 človeku prijazen.

  • 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 smiselno izvajati koordinacije z naročnikom in sproti usklajevati predlagane koncepte 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 tistih, ki pri presoji ustreznosti sodelujejo, še vedno terja kar nekaj domišljije, saj gre več ali manj res zgolj za barvne pravokotnike in »lorem ipsum« besedilo.
  • 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.
  • 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 tekst lahko tudi 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š programirati, znaš to delati z različnim vmesniki, samo prilagodiš se. No, 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 poskusno nadomestimo z drugo, a med seboj so si na koncu koncev dokaj sorodne.

Programerji dobijo dodeljene naloge dokaj 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 s 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)
  • Zagonski elaborat (včasih VDP): ta dokument je dogovor med nami kot izvajalcem in vami kot 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)
  • 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.
  • Ganttov grafikon: tu se seveda nahajajo vsi planirani sklopi nalog in projektnih aktivnosti, njihovo trajanje in roki za zaključek
  • 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
  • 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
  • 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 pogosto tudi predstavnikom naročnika. Ta izmenjava 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

Testiranje je izjemno pomembno, naj bo avtomatizirano ali »ročno« – napake je bolje odkriti v delavnici kot na cesti.

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

Avtomatizacija testiranja je dobra, ni pa vselej vsemogočna.

Po metodi TDD nenehen cikel testiranja celo poganja razvoj programske kode.

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, ni pa vselej vsemogočna in včasih tudi ni racionalna izbira z vidika stroškov projekta. Nekaj dilem, ki jih je smiselno upoštevati:

  • Pri uporabniškem testiranju morate nalogo preverjanja ustreznosti izdelka predati človeku in zaupati v njegovo ali njeno sposobnost za to, da preveri 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 ob relativno majhnem številu 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 situacije, 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, ker naše celovite sposobnosti zaenkrat še kar krepko prekašajo strojne.

Pri odločitvah o tem, kaj testirati kot človek v vlogi uporabnika in kje zaupati testiranje avtomatiziranim simulacijam, 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).

Tisto, kar se je včasih imenovalo »razvojno testiranje«, torej sprotni nadzor ustreznosti in delovanja nove programske kode, se je razvilo v tako imenovan TDD – razvoj, ki ga poganja testiranje. Gre za precej moderen pristop k razvoju, ki izhaja iz stališča, da je koda še najbolj »čista« in najmanj problematična, če njen razvoj poganja nenehno sprotno testiranje. Metoda TDD nadgrajuje tako imenovano metodo »unit« testov predvsem v tem, da se pri slednji uporablja test na nekem najglobljem mikro-nivoju z namenom preverjanja delovanja posamičnega sklopa kode, pri TDD pa z namenom razvoja programske kode. Če je TDD metoda uporabljena v razvoju vašega projekta, lahko pričakujete

  • kratko, pregledno in delujočo programsko kodo
  • odpravljene podvojitve v programski kodi
  • večjo učinkovitost končnega izdelka

prihranke pri času, porabljenem za končno (sprejemno) testiranje.

#8

Implementacija

Implementacija naj bo dobro in natančno načrtovana, odgovornosti naj bodo jasno določene.

Vzpostavitev produkcije zahteva natančno koordinacijo med izvajalcem in tehničnim kadrom naročnika.

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 implementacije 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.

  1. 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.
  2. 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.
  3. Zagotovitev varnosti. Nobena ograja v svetu sodobnih IT rešitev ni zadosti varna, da bi bili lahko 100% prepričani v to, da skozi številne integracije, odvisnosti in nenazadnje zlorabo uporabnikov ne bi prišlo 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.

 

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.

©2022 Vse pravice pridržane SRC d.o.o.

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.