Razvoj programske opreme po meri.

Kdaj nas običajno vključijo#

• obstoječi sistem ne zadošča več
• delo poteka v preglednicah
• podatki se podvajajo med sistemi
• potrebujete novo aplikacijo
• želite prenoviti star sistem
• razvijate nov digitalni produkt

Sistem ostane vaš#

• izvorna koda
• tehnična dokumentacija
• podatkovni model
• dostop do okolij
• navodila za namestitev
• uporabniška dokumentacija
• izobraževanje ekipe

Kaj to pomeni za vas#

• Manj preglednic in ročnih statusov.
• Manj podvajanja podatkov med sistemi.
• Enoten pregled procesa za vodstvo in ekipo.
• Sistem, ki raste skupaj s podjetjem.
• Manj odvisnosti od posameznika, ki »edini ve, kako gre«.

Problem → rešitev#

Kaj razvijamo#

• interne poslovne sisteme
• spletne aplikacije
• administracijske sisteme
• uporabniške portale
• CRM module
• rezervacijske sisteme
• platforme
• podatkovne sisteme
• API-je
• integracije med sistemi

Kdaj je razvoj po meri smiseln#

• uporabljate več nepovezanih sistemov
• veliko dela poteka v Excelu
• podatki se podvajajo in si nasprotujejo
• standardni CRM ne ustreza vašim procesom
• potrebujete zelo specifične uporabniške vloge
• razvijate nov digitalni produkt
• obstoječega sistema ni več mogoče nadgraditi

Kaj konkretno izvajamo#

Kako poteka projekt#

Primeri uporabe#

Celoten življenjski cikel razvoja#

Razvoj poslovnega sistema ni samo programiranje. Med prvim pogovorom in dnem, ko sistem prevzame delo v podjetju, je vrsta korakov, ki jih je treba opraviti v pravem vrstnem redu: razumeti proces, zapisati zahteve, določiti arhitekturo, oblikovati uporabniško izkušnjo, razviti, testirati, prenesti podatke, uvesti, dokumentirati in prevzeti v vzdrževanje.

Projekt lahko prevzamemo v celoti ali kot posamezen projektni sklop. Če ima naročnik lastno razvojno ekipo, se lahko vključimo samo v analizo, arhitekturo, mobilni del, integracije, QA ali uvedbo. Pri večjih projektih določimo projektnega vodjo, odgovornosti ekip, roke, način komunikacije in poročanja.

Poslovna analiza pred razvojem#

Največ napak v projektu ne nastane pri programiranju, ampak prej: pri nerazumljenem procesu. Zato pred razvojem popišemo, kdo dela kaj, v kakšnem vrstnem redu, kje se proces ustavi, kje se podatki prepisujejo ročno in katera pravila v resnici veljajo - vključno z izjemami, ki jih v postopkovniku ni.

Rezultat analize je dokument, ki ga razume tudi nekdo, ki ni tehnik: proces, uporabniške vloge, poslovna pravila, seznam sistemov, s katerimi se je treba povezati, in seznam odprtih vprašanj. Ta dokument je podlaga za obseg dela in za merila prevzema.

• cilji sistema in merilo, po katerem bo projekt ocenjen kot uspešen
• uporabniške vloge in kaj sme videti in spreminjati vsaka od njih
• proces po korakih, vključno s koraki, ki danes potekajo zunaj sistemov
• poslovna pravila in izjeme od njih
• obstoječi sistemi, ki ostanejo v uporabi, in način povezave z njimi
• viri podatkov, njihovo stanje in lastništvo
• omejitve: varnostne, zakonske, infrastrukturne in organizacijske

Funkcionalne in nefunkcionalne zahteve#

Funkcionalna zahteva določa, kaj mora sistem narediti. Nefunkcionalna zahteva določa, pod kakšnimi pogoji mora to narediti. Projekti, ki popišejo samo prve, se običajno zapletejo pozno - takrat, ko se izkaže, da sistem sicer deluje, vendar ne dovolj hitro, ne za dovolj uporabnikov hkrati ali ne dovolj varno.

Nefunkcionalne zahteve zapišemo v merljivi obliki takrat, ko so znane. Kjer številke niso znane ali dogovorjene, jih ne izmišljamo - določimo jih skupaj z naročnikom pred razvojem, ne po njem.

Tipična arhitektura poslovnega sistema#

Večina poslovnih sistemov ima podobno hrbtenico. Uporabnik dela v spletnem, mobilnem ali portalnem vmesniku; ta govori z aplikacijskim vmesnikom, ki ga varuje prijava in preverjanje pravic; za njim je poslovna logika, ki uveljavlja pravila; podatki so v bazi in v dokumentnem delu; integracijski sloj skrbi za pogovor z zunanjimi sistemi; poročanje bere iz teh virov.

Tehnične odločitve prilagodimo projektu#

Vsak projekt ne potrebuje mikrostoritev, mobilne aplikacije, umetne inteligence, podatkovnega skladišča ali kompleksne infrastrukture v oblaku. Arhitekturo določimo glede na število uporabnikov, obseg podatkov, integracije, varnostne zahteve, pričakovano rast in način vzdrževanja po uvedbi. Pretirana arhitektura je pri manjšem sistemu prav tako napaka kot premalo premišljena pri velikem.

Kaj lahko vključuje obseg razvoja#

Spodnji seznam ni obvezen nabor. Je pregled sklopov, ki jih projekt lahko vsebuje; kaj od tega je v obsegu, se določi po analizi in zapiše v pogodbeni obseg.

Nov sistem, nadgradnja ali prevzem#

Okolja, objave in nadzor delovanja#

Razvojno, testno in produkcijsko okolje so ločena. V testnem okolju ne uporabljamo pravih osebnih podatkov. Spremembe gredo skozi pregled in testiranje, preden se objavijo v produkcijo; pri večjih spremembah je predvidena tudi vrnitev na prejšnjo različico.

Po uvedbi je pomembno, da je vidno, kaj se v sistemu dogaja: dnevniki aplikacije, meritve infrastrukture, sledenje napakam, stanje integracij in opozorila. Brez tega se napake odkrijejo takrat, ko jih prijavi uporabnik - običajno prepozno.

• Docker
• Kubernetes
• Terraform
• CI/CD
• GitHub Actions
• GitLab CI/CD
• Grafana
• Prometheus
• AWS
• Microsoft Azure
• Google Cloud
• on-premise

QA, merila prevzema in uporabniško testiranje#

»Razvito« in »sprejeto« nista isto. Za pomembne funkcije zato vnaprej zapišemo, kaj je vhod, kaj je pričakovan izhod, kako se sistem obnaša v mejnih primerih in pod katerimi pogoji je funkcija sprejeta. To odpravi večino kasnejših razprav o tem, ali nekaj deluje pravilno.

Testiranje poteka po testnih scenarijih, ročno in avtomatizirano, vključno s testi v CI/CD. Po potrebi lahko QA izvaja ekipa, ločena od razvojne. Uporabniško prevzemno testiranje izvedejo ključni uporabniki naročnika po scenarijih iz njihovega vsakdanjega dela; napake se zabeležijo, popravijo in ponovno preverijo pred potrditvijo.

• merila prevzema za pomembne funkcije
• funkcionalno in regresijsko testiranje
• testiranje integracij in API-jev
• testiranje v različnih brskalnikih in na napravah
• testiranje zmogljivosti, kadar je to zahteva
• varnostni pregled pred uvedbo
• uporabniško prevzemno testiranje in evidenca napak

• Playwright
• Cypress
• API testiranje
• regresija
• CI/CD

Varnost in osebni podatki#

Varnost ni razdelek na koncu projekta. Prijava, uporabniške vloge, pravice dostopa po načelu najmanjših potrebnih pravic, revizijska sled, ravnanje s skrivnostmi, posodabljanje odvisnosti in varnostne kopije so del zasnove sistema.

Pri sistemih z osebnimi podatki je treba že v zasnovi določiti namen obdelave, pravice dostopa, čas hrambe, izvoz, brisanje in revizijsko sled. To ni pravno svetovanje; pravno presojo opravi naročnik oziroma njegova pooblaščena oseba, mi poskrbimo za tehnično izvedbo dogovorjenih zahtev.

• prijava, enotna prijava in dvofaktorsko preverjanje, kadar je zahtevano
• uporabniške vloge in pravice po načelu najmanjših potrebnih pravic
• revizijska sled za spremembe pomembnih zapisov
• šifriranje prenosa in hrambe v skladu z dogovorjenimi zahtevami
• ločeno ravnanje s skrivnostmi in dostopi
• redne varnostne posodobitve in upravljanje odvisnosti
• varnostne kopije in preverjena obnovitev

Tipična projektna ekipa#

Ekipa se sestavi glede na projekt; ni nujno, da vsak projekt vključuje vse spodnje vloge. Pri manjšem sistemu jih nekaj združi ena oseba, pri večjem so vloge ločene in imajo vsaka svojega nosilca.

Jedrno projektno strukturo Epixa lahko pri večjih projektih razširimo s preverjenimi specialističnimi in partnerskimi razvojnimi ekipami. V širši projektni in specialistični mreži je na voljo več kot 190 strokovnjakov različnih profilov; koga vključimo, določajo zahtevane kompetence, tehnologije, obseg, roki in pogoji naročnika. Naročnik kljub temu sodeluje skozi eno jasno določeno projektno strukturo.

Kaj potrebujemo od naročnika#

Projekt teče hitreje, kadar so na strani naročnika znani nosilci odločitev in dostopi. Rok projekta namreč ni odvisen samo od razvojne ekipe: nanj vplivajo tudi dostopi, zunanje integracije, tretji ponudniki, potrditve, stanje podatkov in spremembe zahtev.

• odgovorno osebo za vsebinske odločitve
• ključne uporabnike, ki proces dejansko izvajajo
• seznam obstoječih sistemov, ki ostanejo v uporabi
• obstoječo dokumentacijo, tudi če ni popolna
• dostop do API-jev in testnih okolij zunanjih sistemov
• vzorčne podatke za testiranje in migracijo
• poslovna pravila in izjeme, ki v postopkovniku niso zapisane

Kaj naročnik prejme#

• delujoč sistem v produkcijskem okolju
• izvorno kodo v skladu z dogovorjenim modelom projekta
• tehnično dokumentacijo: arhitektura, podatkovni model, integracije, okolja
• navodila za uvedbo in postopek objave
• uporabniško in administratorsko dokumentacijo
• rezultate testiranja in evidenco napak ob prevzemu
• dostope, skrivnosti in podatke o zunanjih storitvah
• seznam znanih omejitev in odprtih zadev

Izvorna koda in podatki so last naročnika; dokumentacija, dostopi in gesla so del primopredaje. Licence, pravice uporabe in dostop do posameznih komponent se natančneje določijo v pogodbi glede na model projekta. Končni seznam predanih rezultatov je del pogodbenega obsega.

Kaj gre pogosto narobe in kako to obravnavamo#

Vzdrževanje po uvedbi#

Po uvedbi lahko prevzamemo nadzor delovanja, odpravo napak, tehnične in varnostne posodobitve ter nadaljnji razvoj. Obseg podpore se dogovori s pogodbo; prijave razvrstimo po resnosti, odzivni časi pa se določijo glede na kritičnost sistema in dogovor z naročnikom.

Univerzalnih odzivnih časov ne objavljamo, ker so odvisni od kritičnosti sistema in dogovorjene ravni podpore.

Kako sistem zgradimo#

Varnost, kakovost, uvedba#

Sorodno delo#

Tehnologije#

• TypeScript
• React
• Next.js
• Node.js
• Python
• PostgreSQL
• Redis
• REST
• GraphQL
• Docker
• CI/CD
• AWS · Azure · GCP

Podstrani#

Pogosta vprašanja#

Preberite tudi#

Sorodne rešitve#