Koris

Prije mnogo godina uveli smo u tvrtku Ellabo mobilni IS za skladišno poslovanje. U travnju ‘22. smo razvili i uveli novo rješenje te namjene: Mob Ellposs. Projektna dokumentacija za Mob Ellposs je ogledni primjer kako pristupamo projektiranju i razvoju informacijskih sustava.

Budući da slika govori 1000 riječi, možete na brzinu baciti pogled na projektnu dokumentaciju Mob Ellpossa preko donjega okvira, isporučenu sa našeg Slideshare kanala. Kratko objašnjenje dokumentacije je u nastavku ovog članka, ispod okvira.

Uvod

U Uvodu je precizno definiran:

1. Rješavani problem.
2. Doseg projekta (project scope).

Ukratko su opisani projektantski programi, lokacije projektnih repozitorija, itd. Okvirno, Uvodom su pokrivene Preliminarna faza TOGAF-a (Preliminary Phase) te Faza A: Arhitektonska vizija (Architecture Vision).

Skladišni procesi

Potom su opisani poslovni procesi za koje treba osigurati aplikacijsku podršku. Opis je:

1. u grafičkom obliku, kao radni dijagram (workflow) po BPMN normi;
2. u tekstualnom obliku, kao pregledna tablica s pobližim opisom objekata radnog dijagrama.

Iz modela procesa je vidljivo koje su aktivnosti čisti “ručni rad”, koje se izvršavaju na korisničkim uređajima (klasičnim ili mobilnim), a koje su automatizirane te će se obavljati “na serveru”. Ovo poglavlje uglavnom odgovara Fazi B: Poslovna arhitektura (Business Architecture) TOGAF-ove Metode razvoja arhitekture (Architecture Development Method: ADM).

Radi boljega razumijevanja poslovnog aspekta čitavog sustava, u ovo poglavlje redovito su uključena potpoglavlja koja opisuju promjene stanja važnih poslovnih entiteta (kao što su skladišni nalozi) tijekom provedbe raznih poslovnih slučajeva. Pobliže su opisane i druge poslovne specifičnosti npr. složenije CRUD funkcionalnosti.

Poseban prostor je posvećen prijedlozima poboljšanja postojećih poslovnih procesa. Važno je naglasiti da se svi ti prijedlozi te, općenito, čitavo ovo poglavlje, odnose na poslovni sustav, a ne na buduću informatičko-računalnu potporu tom sustavu. Drugim riječima, ovo poglavlje je primarno namijenjeno poslovnim stručnjacima, da na sistematiziran način vide poslovne procese te tako dobiju zor što informacijske tehnologije trebaju podržati.

Podatkovni model

Podatkovni model je postavljen u relacijskom obliku dovedenom do barem Treće normalne forme (Third Normal Form: 3NF). Posebno je obrazloženo kako su i zašto odabrani primarni ključi te posebna pažnja poklonjena minimizaciji upotrebe autoinkrementirajućih cijelih brojeva (identity) kao primarnih ključeva.

Ovo poglavlje odgovara prvom dijelu ADM-ove Faze C: Arhitektura informacijskog sustava (Information Systems Architecture), onom u kojem se razvija podatkovna arhitektura (data architecture).

Korisnička sučelja

U ovome poglavlju su napravljene skice korisničkih sučelja (wireframes) za aplikativnu podršku najvažnijim poslovnim procesima. Na taj način, naručitelj može točno vidjeti kako će izgledati korisnički program te s informatičarom “raščistiti” nedoumice i korigirati ta sučelja prije nego li je napisana i jedna jedina linija programskog koda.

Određene specifičnosti poslovnog sustava koje aplikacija mora podržati su također opisane u ovome poglavlju, npr. specifičnosti sortiranja stavki skladišnog naloga kada se preko aplikacije prikazuju skladištaru.

Ovo poglavlje odgovara drugom dijelu ADM-ove Faze C: Arhitektura informacijskog sustava (Information Systems Architecture), onom u kojem se razvija aplikacijska arhitektura (application architecture).

API-ji za integraciju s vanjskim sustavima

Ovo poglavlje opisuje kako će novo rješenje biti integrirano s vanjskim ili postojećim sustavima, ako ta integracija ne bi bila moguća izravno preko zajedničke baze podataka. Integracija se obavlja preko REST web API-ja. Tako se postiže potpuna interoperabilnost bez obzira na tehnologiju izvedbe tih vanjskih ili postojećih sustava.

Ovo poglavlje također odgovara drugom dijelu ADM-ove Faze C: Arhitektura informacijskog sustava (Information Systems Architecture) gdje razvija aplikacijska arhitektura.

Za kraj

Projekt Mob Ellposs je manjega opsega pa:

• Nema detaljnog opisa tehničke arhitekture iz ADM-ove Faze D: Tehnička arhitektura (Technology Architecture) jer je ta arhitektura zadana tj. rješenje se uklapa u postojeće IKT resurse tvrtke Ellabo.
• Nije bilo potrebno razrađivati nova arhitektonska rješenja kao u ADM-ovoj Fazi E: Prilike i rješenja (Opportunities and Solutions) jer Mob Ellposs zamjenjuje Mob Trenis, uz značajno usavršavanje postojećih funkcionalnosti.

Faza F: Planiranje migracije (Migration Planning), Faza G: Upravljanje izvedbom (Implementation Governance) i Faza H: Upravljanje izmjenama arhitekture (Architecture Change Management) su razrađene kroz druge dokumente.

Kada bi se svakom projektu razvoja informacijskog sustava pristupilo na ovaj način, ne bismo slušali mudrovanja o tome kako “veeeliki postotak informatičkih projekata ne uspijeva”. Ne uspijeva zato što ljudi krenu od programiranja korisničkih sučelja umjesto modela poslovnih procesa te zato što uopće ne osmišljavaju relacijsku bazu podataka niti “data storage” uopće pokušavaju normalizirati.

Kada bi se svakom projektu razvoja informacijskog sustava pristupilo na ovaj način, 19 od 20 bi ih uspjelo.