Pse një ndryshim i vogël në software mund të kërkojë ndryshime në gjithë sistemin?

Në software, përmasat e një ndryshimi nuk përcaktohen gjithmonë nga ajo që shfaqet në ekran.

Shtimi i një fushe të re në një formular, ndryshimi i statusit të një kërkese apo shtimi i një mënyre të re miratimi mund të duken si ndërhyrje të vogla. Por në një sistem kompleks, një funksionalitet rrallë ekziston i izoluar. Ai mund të lidhet me të dhënat, rregullat e procesit, përdoruesit, API-të, raportimin dhe sisteme të tjera.

Prandaj, një nga pyetjet e para në zhvillimin e software-it nuk është vetëm “çfarë duhet të ndryshojmë?”, por edhe “çfarë tjetër ndikohet nga ky ndryshim?”

Ajo që sheh përdoruesi është vetëm një pjesë e funksionalitetit

Marrim një rast të thjeshtë: një platformë ka një proces miratimi dhe duhet të shtohet një nivel i ri aprovimi.

Në ndërfaqe, ndryshimi mund të jetë vetëm një buton, një status i ri apo një hap shtesë. Brenda sistemit, megjithatë, duhet të përcaktohet kush ka të drejtë ta kryejë atë veprim, në cilën fazë lejohet, çfarë ndodh me statusin e procesit, çfarë regjistrohet në historikun e veprimeve dhe cilat procese aktivizohen më pas.

Nëse informacioni përdoret edhe nga sisteme të tjera, ndryshimi mund të vazhdojë më tej. Një API mund të duhet të transmetojë statusin e ri, një raport duhet ta interpretojë saktë dhe një sistem i integruar duhet të dijë si ta trajtojë.

Pra, një element i ri në ekran mund të përfaqësojë disa ndryshime brenda arkitekturës së sistemit.

Software-i funksionon përmes varësive

Sistemet moderne ndërtohen nga komponentë që komunikojnë vazhdimisht mes tyre.

Një modul mund të përdorë të dhëna të krijuara nga një tjetër. Një API mund t’ia dërgojë ato një platforme tjetër. Një raport mund të mbështetet mbi të njëjtën strukturë të dhënash, ndërsa një proces tjetër mund të aktivizohet automatikisht kur informacioni ndryshon.

Këto lidhje janë pikërisht ato që i mundësojnë një sistemi të funksionojë si një i tërë. Por ato nënkuptojnë gjithashtu se ndikimi i një ndryshimi duhet parë përtej komponentit ku ai fillon.

Për këtë arsye, zhvillimi nuk përfundon me implementimin e një kërkese. Duhet kuptuar edhe zinxhiri i varësive që ajo kërkesë prek.

Një ndryshim në të dhëna mund të udhëtojë në gjithë sistemin

Të dhënat janë një shembull i qartë.

Nëse një sistem fillon të ruajë një informacion të ri, nuk mjafton vetëm të krijohet vendi ku ai do të ruhet. Duhet përcaktuar kush e krijon, kush mund ta ndryshojë, ku përdoret, nëse duhet t’u transmetohet sistemeve të tjera dhe si do të shfaqet në raporte apo dokumente.

Edhe ndryshimi i kuptimit të një fushe ekzistuese mund të ketë ndikim. Komponentë të tjerë mund të jenë ndërtuar duke u bazuar në mënyrën e mëparshme të interpretimit të saj.

Kjo është arsyeja pse në sisteme komplekse ndryshimi i software-it është edhe menaxhim i marrëdhënieve mes komponentëve të tij.

Integrimet e zgjerojnë ndikimin përtej vetë aplikacionit

Kjo bëhet edhe më e rëndësishme kur software-i është pjesë e një ekosistemi më të madh.

Një sistem mund të shkëmbejë informacion me platforma financiare, sisteme dokumentesh, shërbime identifikimi, aplikacione të tjera apo platforma të palëve të treta.

Në këtë rast, një ndryshim i brendshëm duhet të vlerësohet edhe nga perspektiva e këtyre integrimeve. Një strukturë e re e të dhënave, një rregull i ndryshëm apo një status i ri mund të kërkojë përshtatje edhe në mënyrën si sistemet komunikojnë.

Sa më i lidhur të jetë një sistem, aq më e rëndësishme bëhet të kuptohet ndikimi i plotë i një ndryshimi përpara implementimit të tij.

Puna më e rëndësishme shpesh ndodh përpara se të ndryshojë kodi

Për këtë arsye, një kërkesë e re nuk duhet të përkthehet menjëherë në kod.

Përpara implementimit, duhet të kuptohet se ku ndërhyn ndryshimi, cilët komponentë prek, cilat të dhëna përfshihen, çfarë integrimesh varen prej tij dhe nëse sjell pasoja në pjesë të tjera të sistemit.

Kjo analizë është veçanërisht e rëndësishme në platforma që kanë evoluar ndër vite dhe ku funksionalitetet, të dhënat dhe integrimet janë të ndërlidhura.

Në Soft & Solution Group, zhvillimi i sistemeve trajtohet pikërisht nga kjo perspektivë: një ndryshim vlerësohet jo vetëm si funksionalitet më vete, por si pjesë e arkitekturës dhe e ekosistemit ku do të funksionojë.

Siç e përmbledh Ermal Beqiri, themelues i Soft & Solution Group:

“Në software, një ndryshim nuk jeton vetëm aty ku e shohim. Ai bëhet pjesë e lidhjeve, të dhënave dhe proceseve që mbajnë sistemin të bashkuar. Të kuptosh këto marrëdhënie përpara se të ndryshosh kodin është po aq e rëndësishme sa vetë implementimi.”

Software-i evoluon vazhdimisht. Funksionalitete të reja shtohen, proceset ndryshojnë dhe sistemet lidhen me teknologji të tjera.

Prandaj, aftësia për të zhvilluar një sistem nuk qëndron vetëm te shtimi i funksionaliteteve të reja. Qëndron edhe te aftësia për të kuptuar se si çdo ndryshim bëhet pjesë e sistemit që ekziston tashmë.